Dynamic Map Generation

Gaia v1.0 uses precomputed maps, one per day, which must up updated when new instruments or new data is added. Clearly this approach is not scalable. Some kind of dynamic map creation is therefore required. In addition Gaia v1.0 uses client-side image maps (created when geographic maps are created) to convert user clicks to site locations. This imposes restrictions on what a site comprises.

With dynamic maps the client or server could locate all sites (if necessary restricted by project, instrument type, data availability etc) within a certain distance of where the user clicked. It will be necessary to map (x,y) pixel locations to (latitude,longitude). Obviously this approach is not compatible with using HTML imagemaps.

Possible solutions

MapServer

The MapServer software is intended to be used with a webserver, and it will not work from a command-line interface. Very sophisticated, large choice of output formats, reputed to be fast but appears complicated. Lots of documentation (including image maps) but little indication of how to include actual map data! Plenty of input formats are listed if you know what data you need to include. Web Mapping Illustrated may be helpful for using MapServer.

Probably too complex for our needs right now.

Useful references for MapServer

Web Mapping Illustrated by Tyler Mitchell. Published by O'Reilly).

Build AJAX-Based Web Maps Using ka-Map by Tyler Mitchell. Provides information about how to get data for MapServer.

Generic Mapping Tools (GMT)

GMT appears much simpler than MapServer, but is aimed at generating PostScript output. Could have problems converting to good bitmap output, also with setting specified image sizes. Could also have problems using image maps, as there appears to be no support for mapping back from map position to latitude and longitude values.

Looks useful for publications but probably not what we want.

Pre-computed maps with layers for each site

An alternative approach is to generate the coastline maps using the m_map toolkit for Matlab, or IDL's mapping functions. Sites would be constructed as separate, transparent layers which would be positioned over the coastline map, either at the webserver (reliable and browser-independent) or client-side using JavaScript (avoids latency). Server-side image maps could be implemented by using a pre-computed lookup table to convert from pixel (x,y) locations to latitude and longitude values. The database could store map name, latitude, longitude, x and y columns to enable bi-directional lookups as a web service.

Sounds clunky but it should work, and be fast. The tools for overlaying images at the server will probably be needed anyway for applying colourmaps to greyscale images. Low overhead to set up and maintain. Slight overhead when adding new stations (no longer a matter of just inserting data into the database), however, the url_tools toolbox for Matlab (written by SteveMarple) will allow us to import station locations using the REST webservices directly into Matlab for processing.

NCAR Graphics and EZMAP

Fortan library (partially available as C?)for generating images. Can convert (latitude,longitude) values to pixel (x,y) values. Results look ugly. See http://ngwww.ucar.edu/ and http://ngwww.ucar.edu/ngdoc/ng4.4/supplements/ezmap.

Java

Google Maps

http://www.google.com/apis/maps/

MapIt!

http://www.mapit.de

JavaScript and fixed, simple projections

If a simple map projection is used then JavaScript can be used to convert between pixel locations and latitude/longitude, and all layers could be added in the browser. One suitable projection would be the Equidistant Cylindrical, which is made by treating every degree of latitude and longitude as equal in length, resulting in a perfectly rectangular map with a 2:1 width-to-height ratio. See Mapping Hacks, Ch. 3 § 9. Equidistant cylindrindical is better than Mercator for the polar regions.

For the polar maps a suitable projection might be azimuthal equidistant, where the radial distance is proportional to co-latitude. Mathews map projection software (MMPS) can be used to change from equidistant cyclindrical to other projections.

Images can be obtained from:

• NASA
• Flat planet

There is an online example taken from Mapping Hacks. See also hack #41, which describes how to plot points on an interactive map using DHTML.

If we allow some limited generalisations (cropped images, polar maps may be rotated around the pole) then I think we should be able to handle all the maps we need with simply equidistant cylindrical and azimuthal equidistant projections. Note that with this method we could still have the server overlaying images onto the plain map, which would allow users to save an image for offline viewing, printing, including in presentations etc. -- SteveMarple - 16 Feb 2007

Sample images

The images below were created from Andrew Sumners day map (see http://flatplanet.sourceforge.net/maps/natural.html) and converted to alternative projections using MMPS.

Equidistant cylindrical projection, resized from Andrew Sumner's day map (see flatplanet).:

Northern hemisphere orthographic projection, radial distance limited to 41°, the map shows latitudes >= 49° N:

Northern hemisphere azimuthal projection, radius 40 degrees (ie latitudes >= 50N are shown) and rotated by 255 degrees. Terminator for day 37 (6th February) 7UT shown.

Resources

• Mapping Hacks, Tips & Tools for Electronic Cartography by Schuyler Erle, Rich Gibson, Jo Walsh. First Edition June 2005.
• Northern hemisphere orthographic projection, radius 40 degrees (ie latitudes >= 50N are shown):