Or perhaps that should be rephrased start browser-based raster GIS?
GIS data is split into two base types – vector data – geometric shapes, usually further split into points, lines, and polygons, and raster data – cell-based or “pixelated” data.
Graphics on the web mirror this divide. On the vector side SVG – scalable vector graphics, is used in many browsers to display geometric shapes. On the raster side “dumb” images come in many well known formats such as bitmaps, GIFs, PNGs, and JPEGs.
Vector geometries are easily manipulated after drawing as they have an abstract model to work with (the SVG, or KML document), which the browser can then convert to the DOM. As an example OpenLayers includes two vector renderers – one for SVG (see source code), one for VML (used by the ever-unique IE), and since the start of this year a new canvas renderer.
The canvas renderer is used to draw features to the new canvas element which is part of the HTML5 specification. This allows access to images loaded into the canvas through new programming interfaces such as the Canvas 2D Context API. It is this part of the HTML5 specification that could change the way we work with raster data on the web.
Linear 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.
The MapFish print module used by both MapFish and GeoExt generates PDF maps that can be saved to clients machines. Over time you can acquire hundreds of different PDFs, but unfortunately Windows XP does not generate thumbnail previews to help find them again later.
The script below solves this problem by generating a PNG image of all the PDFs in a folder. The image to the left shows the results of the script when run on a series of UN Mission Maps.
This relies on two programs to be installed. ImageMagick – a free image conversion software package, and GhostScript another free program that can be used to access, read, and create PDF files. You may have to reboot your machine after installing these programs for the script to run successfully.
The script uses a convert utility program which comes with ImageMagick. Read more
A common requirement in GIS is to be able to find the number of points in a polygon to answer a question such as “how many towns are in this county.”
With the spatial operations in SQL Server this can be calculated dynamically, however for large spatial datasets it can often take several minutes to run the query. If a user is running the query through a web interface they will either give up, or the connection will time out.
It can be useful to assign all features to a parent polygon in the database so these calculations are almost instant. To do this run the following SQL:
Due 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:
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. Read more
I recently asked a question on GIS Stack Exchange on how to create a buffer around a point that took into account the curvature of the earth. OpenLayers has support for geodesic measurements, but not creating geodesic polygons. Drawing a standard polygon on a Mercator projected map can produce features with very different measurements from their intended “on the ground” equivalents.
Paul Ramsey pointed out that “the scale errors for Mercator are very high indeed (infinite, in fact, at the poles) increasing as you head north/south from the true scale latitude.” In fact drawing a circle (in Ireland – 53 degrees North) with a 10km geometric radius produced a circle with an on the ground radius of 6km. A huge margin of error over a very short distance (see a previous post on the same subject).
After a useful answer from Dan Shoutis, it appeared most of the work to implement geodesic circles was already available in the OpenLayers API. The OpenLayers’ geodesic functions are based on code adapted from Chris Veness work at http://www.movable-type.co.uk/scripts/latlong-vincenty-direct.html.
The code to create a regular (non-geodesic) polygon can be seen in the OpenLayers source here. There is a function added after the class OpenLayers.Geometry.Polygon.createRegularPolygon that can be used to “create a regular polygon around a radius. Useful for creating circles and the like.”
This function only required a couple of changes – notably using Longitude and Latitude and rather than X and Ys, to produce geodesic polygons. If you are using the Mercator projection then transformations requires proj4js support. Read more
This is a guest post by Adrià Mercader.
Even in the current digital era, being able to print maps from geospatial applications is still a very commonly requested feature. Traditionally, there have been two main approaches to the map printing on browser applications: handling it either on the client or on the server. In the first case, a new page is opened with the suitable size for a common paper format (e.g. A4 portrait) and is printed with the browser’s print function. This is probably the easiest way to go if you have a very basic map and you don’t need a complex layout, and big guys like Google Maps do it this way. The second option is based on sending all necessary information to a remote printing service, which will produce an output file (generally a PDF) ready to be printed. This allows for more complex layouts, different page sizes, etc. but with the drawback of being more difficult to build and maintain.
Fortunately though, the MapFish mapping framework includes a powerful printing module that allows you to define complex layouts and provides a protocol that can be integrated seamlessly with GeoExt based applications. The layouts can include legends, attribute tables, external images and custom variables sent from the client, and are configured via files with the YAML format. The MapFish site has a complete reference of the configuration file syntax.