[OSM-dev] Blue sea for tiles at home

80n 80n80n at gmail.com
Tue Apr 24 11:15:59 BST 2007

This is great work.  The results really look good, and the approach taken
appears to be the right one.

The colour used for the sea is slightly lighter blue than that used for
rivers.  At the mouth of large rivers there is a clear boundary between sea
and river.  Is this desirable or should one or the other be changed so that
all water is the same colour everywhere?


On 4/23/07, Frederik Ramm <frederik at remote.org> wrote:
> 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'
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070424/5d56deb2/attachment.html>

More information about the dev mailing list