Tiles@home/Dev/Interim Coastline Support

This page describes how coastlines and blue oceans are painted by tiles@home.

See also Tiles@home/Dev/Coastline for another discussion of the problem.

The problem

Tiles@home never sees the whole map, it only downloads parts of it. While it is simple to paint blue water around an island, it is not simple to know which side of a coastline that cuts your area from left to right has to be painted blue and which side is land.

Also, if your tile is completely empty you do not know if it is a sea tile or a land tile.

But maps without blue water don't look right!

Interim solution

Beginning with software version Glencoe, tiles@home includes (yet another) preprocessor, called close-areas.pl, that is run on OSM data after it is read from the server. The preprocessor roughly does the following:

• If the tile has no coastline at all, check a precompiled index (index file created by User:kleptog, see Tiles@home/Dev/Coastline) to find out wheter it is a sea tile. If yes, put a coastline rectangle around the visible area so that it is rendered 100% blue.
• If the tile has coastline in it, combine coastline segments into continuous lines. If there are lines that enter and leave the visible area, connect their non-visible ends outside of the visible area so that the coastline forms an area that can be filled. Assume that water is always on the right hand side of a coastline segment.
• Unconnected parts of coastline "floating" around in the area are discarded.

This solution leads to nicely rendered coast lines and blue water.

The downsides:

• Coastline uses up a lot of space on the OSM server (it is fairly static data)
• May paint inland areas blue if care is not taken

Tips for mappers

• Make sure your coastline has water on the right hand side.
• It doesn't matter if your coastline is made up of multiple ways as long as they meet at one node. If your coastline is broken, it will be ignored.
• Make sure that all your segments are pointing in the right direction. One little segment pointing in the wrong direction is enough to break rendering.
• Coastlines must not branch.

Debugging

The most likely problem you will have with this solution is that you have an island which is rendered like a lake (i.e. the water around it is white, and the island blue). In that case, your coastline segments are in the wrong direction - you want the water on the right, so the segments need to go around the island counter-clockwise. Simply select the coastline way in JOSM and use the "reverse ways" command from the Tools menu.

If you get strange filling results - inland tiles mostly blue or sea tiles white, or things that look like a flood fill has gone wrong, or sometimes no fill at all - then it is very likely that you do not have a continuous, unidirectional coastline.

1. Rendering will also break if there is a "hole" in your coastline. Holes can be near invisible in JOSM if you have two unconnected strings of coastline whose endpoints are different nodes that are on (almost) exactly the same position. If they are part of the same way, an easy test in JOSM is to issue the "split way" command when the way is selected. If the way is continuous, JOSM will show an error message - if not, it will split the way into continuous parts, allowing you to see the fissure.

As a last resort, you can modify close-areas.pl to generate specially tagged coastline ways from non-continuous strings of segments. A suitable way to do this is:

1. change tahlib.pm by commenting out the "unlink" call in "killAFile". This will lead to all temporary files being kept locally.
2. change close-areas.pl by setting "$make_open_ways=1" where it says "$make_open_ways=0".
3. run tilesGen.pl in xy mode for the tile that doesn't work.
4. now start JOSM and load the data-xxxx-close-areas.osm file that has been created. You should see the coastline ways that have been created (they carry a "close-areas.pl:debug" tag with a value of "open_way"), and you can now inspect their endpoints to find out why they have not been connected to the rest of the coastline.

If this all fails to detect the cause of bad rendering, you have probably found a bug in close-areas.pl. Fix it and earn the respect of the community!

Extending this solution to work with large inland areas

t.b.d.

Using this solution with stand-alone Osmarender

close-areas.pl should theoretically work when running it on single OSM files outside of the t@h mechanism, however, it has not been thoroughly tested.

Osmarender stand-alone users will need to download the Tiles@home client [1] and copy tahproject.pm, close-areas.pl, and the folder png2tileinfo and its contents (from the tiles@home client) to the same directory which contains the .OSM file that are you rendering.

To close the open coastline, close-areas.pl needs to know which part of the OSM file is inside the visible area and which isn't. In t@h, this information is passed to the program by putting the X and Y coordinates of the level-12 tile being rendered on the command line. In standalone mode, you will instead have to pass four values describing the visible area (minlat minlon maxlat maxlon). These would normally be the exact same values that you used for downloading the area from the server.

Run close-areas as follows:

./close-areas.pl minlat minlon maxlat maxlon < input.osm > output.osm

Render the output.osm file as you normally would and the coastline should now have water.

Future solution

For a future solution, it may be desirable to use pre-rendered water tiles and combine them at the viewer or tile-renderer level as described on Tiles@home/Dev/Coastline, provided that ways can be found for mappers to change the coastline if necessary (nothing is more frustrating than some piece of software painting water where you put your roads before).