4

I'm working on an application where I want to present bathymetric visualizations of different bodies of water on top of a slippy map. In essence these are geographically contained topographic visualisations based on interpolated DEM data. The result I'm after is something in the line of:

enter image description here

I have written code to interpolate the DEMs from depth samples and have a proof of concept in place where I store these in non-tiled rasters in PostGIS (one raster per body of water) which works fairly well.

I do believe however that I will have to replace this concept with some kind of tile based solution since bodies of water can be of almost arbitrary size and the visual aspects should probably be adjusted based on zoom-level etc.

If this was all there was to it, I would probably just mimic regular elevation raster generation concepts described in various places, often based on Mapnik. However, here is where the fun starts..

Ideally I do not want to present raster data, but rather vectors (or perhaps a combination of the two). I want my map to be more interactive than is generally possible with raster data (unless the raster data is teared apart and analyzed using for example D3 - more on this later). I want to have the possibility to change equidistance (distance and value of contour lines) dynamically based on user interaction.

I would love to have some clever input as how to arrange this stack. Some ideas I want to ventilate:

1. Raster tiles only Elevation DEM rasters are generated based on classical 256x256 mercator concepts. These are downloaded dynamically by the client browser and either displayed as-is, or colour mapped using canvas/D3. On top of this I use the canvas API to extract vector contours using D3. This would be a fairly clean solution but I suspect that it will be to slow (the image inspection part).

2. Raster tiles in combination with vector tiles Elevation DEM rasters are still generated as they constitute a good way to represent and store the interpolated data. The raster tiles may still constitute a graphical overlay on the map, but in essence the elevation contours consist of vector tiles fetched seperately (based on GeoJSON or TopoJSON). These tiles are generated based off the raster riles.

Since I want to be able to change the equidistance on the fly I must be able to unify and combine vectors, for example using D3. I had a look a the d3.geom.contour plugin but it seems a bit limited, for example it seems like there can be no local peaks, but rather a pyramid like topology.

Last, but not least, I want to perform light client side line interpolation (or something similar) for aesthetics. I.e. the resolution of the bathymetric map may be lower (since higher resolution really has no value) but at this resolution contours typically become clunky. Perhaps this is an argument for TopoJSON and it's possibilities with simplification? Here's an example I've made with D3 (using server side generated non-tiles GeoJSON):

enter image description here Any suggestions are welcome!

Hugolpz
  • 17,296
  • 26
  • 100
  • 187
averas
  • 545
  • 1
  • 6
  • 15

1 Answers1

3

The best way to do this depends largely on how much flexibility you want to have in the end. Here's a suggestion that would give you at least some degree of flexibility.

In the initial screen, show a "sensible default", i.e. something that looks nice and doesn't require loading too much data. I've done something along those lines here, although I would probably use TopoJSON if I did it again today.

Then for each user interaction, load new data as required. There're basically two types.

  • User zooms/pans, you want to show something with more detail. Resolution shouldn't be a problem if you're using vectors, but you might want to do things like showing intermediate contour lines. For this, you can simply load the additional contour lines from JSON.
  • User chooses different height intervals/etc. Again for this you can simply load the new data. This implies that you don't allow to change these things arbitrarily, but only have a certain number of discrete levels for which the data is precomputed. Makes it much easier on the browser and programming as well.

To make it work with vectors in general, you will probably have to simplify the geometries for the initial load -- again, you could dynamically load the more detailed paths as the user zooms in.

If I understood what you're trying to do correctly, I wouldn't recommend raster tiles. They offer you basically no flexibility at all and won't be required. The amount of data (unless you want to show very large regions) should be manageable, especially if you only load more detailed data as required.

Lars Kotthoff
  • 107,425
  • 16
  • 204
  • 204
  • For answering to a hard question by newbies who rarely validate the first anwser they got: +1! – Hugolpz Sep 09 '13 at 16:18
  • Great Answer and great example! I will give it a shot and try to establish a model like you described. A follow-up question: You imagine that my interpolated data that I store in my rasters today would instead make way for a direct interpolation to vector routine? I imagine that the elevation vectors the reside in your own example originate from raster DEMs (from NASA). Perhaps you're right - the intermediate raster step is perhaps redundant - it's just that it's to easy to make contour polygons out of the rasters in PostGIS... :) So - in essence Interpolation -> Vectors (or vector tiles). – averas Sep 09 '13 at 19:12
  • Not entirely sure what you mean. If everything you want to show can be vectorized easily and the amount of data won't get too large, then I'd certainly recommend that. – Lars Kotthoff Sep 09 '13 at 19:52
  • Note: topojson is not better than GeoJSON for bathymetric/topographic maps, where polygons don't share arcs. – Hugolpz Sep 10 '13 at 04:27
  • Hugolpz, I kind of came to the same conclusion - a bit depending on how the contours are vectorized however. If each elevation step constitutes a vector covering its elevation plus the levels above (imagine a pyramid) there will be no shared arcs, however, you could vectorize it so that all vectors are next to each other instead of on top of each other (much like DumpToPolygons will produce), whereas they will definitely share arcs. The former makes is a lot easier to show and hide certain levels, whereas the later ought to offer a bit more compact representation. Lars example seems to be #2. – averas Sep 10 '13 at 04:40
  • Indeed. One last thing I/we forgot to state : topojson by default reduce the image-size to 10.000/10.000px and so the weight. This can be seen as an improvement over Geojson. – Hugolpz Sep 11 '13 at 21:50