imageLinear referencing is used to define features in relation to existing line features. These new features can either be points or lines. For example a water monitoring station can be defined as 300m along a section of river, or a stretch of road can be defined as requiring repairs, from 220m along to 270m along. Most GISs implement this functionality – for details look at the ESRI and GRASS help pages.

In terms of storing linear referenced point features, you only need three fields – an ID of the original line feature, an ID of the  feature to reference along the line, and a M value – the measurement along the original feature. Line features require two measurement fields, a starting distance, and an end distance.

Continue reading »

Proxy ServerDue to the same origin policy any data from a remote server cannot be (easily) added to a web application on your own server. This issue also applies to WFS (Web Feature Services) and OpenLayers. There is a Python script that can be used to get round this issue, but I preferred to have a native .NET equivalent.

On the OpenLayers Mailing List Diego Guidi pointed to an opensource .NET proxy. A proxy makes a request to a remote URL, reads the response, and then sends it to the client so it appears all data comes from the same server.

The .NET proxy is written by Paul Johnston, and can be found at http://code.google.com/p/iisproxy/. I made a few minor changes as follows:

  • increased the byte size for reading responses to resolve this issue
  • added support for PUT requests
  • temporarily removed GZIP compression due to invalid responses and a possible bug in .NET

The proxy can be used for any requests and is not limited to just OpenLayers. My source files can be found at http://bitbucket.org/geographika/openlayers/src/bfeab6a9971a/iisproxy/

I’d recommend reading the original project’s README file which goes through compilation and installation, but I’ve added my own notes below. Continue reading »

All projects I’ve worked on have a few days set aside for the dreaded “documentation.” Clients often try and reduce the billable hours set aside for documentation and when project delivery times are closing its often the last thing on a developers mind, so it gets cut from both sides.

I’ve come to the conclusion that a detailed and long word document, while it may tick the box on the client’s checklist, is an exercise in futility. No-one ever reads it, you’re lucky if you can even find it a year later, and its out of date the moment its written (or  if its a rehash of the technical specification its never actually in-date).

My key requirements for user documentation are:

  • make it easily accessible from within and from without the system
  • have only one repository for the user documentation
  • allow people other than the developer to create and edit the documentation
  • auto-generate when and if possible

Continue reading »