[OSM-dev] Blue sea for tiles at home

Frederik Ramm frederik at remote.org
Mon Apr 23 20:49:21 BST 2007


Hi,

    I have just committed a t at h extension (new version name "Glencoe") 
that creates blue sea tiles.

The algorithm is a bit complex (over 700 lines of Perl code), and if
anyone finds a simpler way to do it, please step forward and submit
patches or redo it.

It works like this:

* If the tile being rendered has no "natural=coastline" ways, then
   look up the tile coordinates in a table (which is supplied as a
   4 MB binary file covering every single level-12 tile in the world,
   thanks to Martijn for providing it!).

   o If the table says there should be water at this location, then
     draw an artificial "coastline" rectangle so that the tile gets
     rendered blue.

   o Otherwise don't change anything. Martijn said his index is not
     100% complete for non-Europe parts of the world so in some cases
     there may be no water where there should be, but that can be
     fixed by improving the index.

* If the tile being rendered has any coastline segments at all, then
   throw away the coastline ways, and re-arrange all the segments into
   one big way, connecting the loose ends coming into the visible area
   from the outside or leaving the visible area, so that closed ways
   are formed.

   o This method requires us to know which side of a segment the water
     is on. We assume it is always on the right.

I have rendered the whole of the UK coastline with this algorithm, at
zoom levels 12 and smaller only, and you can inspect the results here:

http://openstreetmap.gryph.de/slippymap/ukcoast.html

Typical problems, which we'll have to fix over the course of the next
few days and weeks, are:

a) coastline drawn so that water is on the left - will show islands in
blue on a white background; most of the Scottish Isles suffer from that
problem (shown here is Eigg):

http://openstreetmap.gryph.de/slippymap/tiles/osmarender4/10/494/314.png

b) broken coastline or, especially devious, a single segment turned
"against the flow", will cause unpredictable results (shown here is
Chepstow, where the coastline contained one single segment in the
wrong direction - meanwhile fixed):

http://openstreetmap.gryph.de/slippymap/tiles/osmarender4/11/1008/679.png

c) no coastline at all will create a rough coastline (with "pixels" of
level-12 tile size) like this example near Norwich:

http://openstreetmap.gryph.de/slippymap/tiles/osmarender4/9/258/167.png

I realise that in some areas this makes the slippymap uglier than it
was before, but I believe the quality gain for those areas which have
a proper coastline outweighs that (by a lot). It should not be too
difficult to at least sketch a coastline from landsat where no
imported one exists.

This mechanism is mainly intended for coastal or near-coastal tiles;
the high-level tiles are still created from the level-12 tiles using
bitmap operations, and thus level-7 tiles somewhere in the Atlantic
will not turn blue.

We could fix that by running t at h for every ocean tile, but that would
add roughly 16 billion tiles to the repository (down to zoom level 17
for everywhere on the ocean). We do not want that. We should probably
instead modify lowzoom.pl to use level 12 tiles where they exist and
otherwise use the same table lookup used by tilesGen.pl to determine
wheter an area should be blue or not. That would mean that we would
not normally create level 12 tiles for all-blue areas, and that
zooming in from an all-blue level-11 tile will land you in nothingness
rather than in water, but this approach would only mean 1 million
extra tiles.

More on coastline here:

http://wiki.openstreetmap.org/index.php/Tiles@home/Dev/Interim%20Coastline%20Sup
port

It is called "interim" because in the long run we might be better off
merging pre-created coastal tiles (which seldom change) with our OSM
data. But that would require infrastructure for the ocean tile 
repository and would also make it difficult to actually change a 
coastline in your editor, <godmode>something that I personally find 
important</godmode>.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'




More information about the dev mailing list