It would be nice to have blue-filled oceans, seas, and lakes on the Slippy Map. This page suggests one method.
The examples are in Perl, but should be applicable to your favourite programming language.
Get coastline data
Data is available in shapefiles from National Geospatial-Intelligence Agency (NGA); search for "PGS", or Prototype Global Shorelines.
We have a Perl script capable of reading these files at Almien coastlines (PGS), which is used for the coastline import into OSM, but could be adapted for other uses.
Similarly, any library capable of processing shapefiles will do...
What we need are lots of tiles that are either blue (sea), white (land), or some combination of the two (coastal). These should correspond with the tiles being generated by tiles@home, Mapnik, etc. (and the same coordinate system as Wikipedia:Google Maps)
See the Slippy map tilenames for details on how to convert lat/long to tile coordinates.
(If you store the tiles in an appropriate directory structure, you can even browse your coastline tiles using an OpenLayers slippy map, or add your land/sea layer to one of the existing map viewers)
When done, you should have 16,777,216 tile images (256×256 pixel) at zoom level 12, 67,108,864 images at zoom level 13, etc. up to zoom level 17.
You may wish to replicate the tiles@home "bug", whereby the edges of a zoom-12 tile are calculated correctly, but latitude-to-y conversions within that area are linearly interpolated. This will make it correspond with the data being generated by tiles@home renderers
Merge into tiles@home
The tiles@home program currently generates tile images and uploads them. This needs to be modified slightly.
- Make it generate a transparent tile image instead of one with a white background
- Make it download the appropriate land/sea tile that you created in the previous step
- Make it merge the two together, to create a tile with blue-filled seas as appropriate, and the road maps on top
- Then upload as usual
Tiles at zoom levels 0 to 11 are created by merging together zoom-12 tiles, so they will automatically pick up your oceans when they're next generated.
Perhaps you can think of a different way that tiles@home can be modified to fill the ocean areas?
I (Kleptog) have been playing around with this. First results are attached in this PNG image. It's a 4096x4096 B&W image, each pixel represents one zoom-12 tiles. All the white pixels are where there is a coastline, all the black will be constant colour (either all land, or all sea). The image is not yet complete, as evidenced by the gaps in the coastlines around the place.
Initial estimates indicate that around 200,000 zoom-12 tiles will have to be indidivually drawn, whereas the remainder of the 16 million will be constant colour.
Kleptog 12:00, 22 January 2007 (UTC)
I've got it so far as rendering the final detail that will be needed for zoom-17 tiles. Basically how I'm going approach it is:
- Make a world map that tracks which zoom-11 tiles contain a peice of coastline (done)
- For a given zoom-11 tile, render everything in there at a resolution of 16384x16384 (done)
This resolution is chosen because that means you can make 2^12 256x256 tiles out of that, which happen to be zoom-17 tiles. Basically this one image has all the info needed to generate all tiles between zoom-11 and zoom-17.
Yes, these images will be 256MB raw, but they compress really well (about 130KB). On my sample so far it seems to only take 30 seconds per tile, and we'll only need around 78,000 of them.
- Fill in areas that are sea with blue (not done yet)
It looks like the segments are all drawn so that the sea is on the right when following the segment. I hope so, as this will make it much easier to colour them in.
- Make snipping program to take each of these images and make 2^12 zoom-17 times, 2^10 zoom-16 tile, etc... (not done)
Kleptog 21:57, 24 January 2007 (UTC)
Well, I've got the point where, given a location, I can generate zoom-11 through zoom-17 tiles for that place. It creates the files in zoom/x/y.png layout with optimisation for constant colour tiles. I'm in the process of turning the result into a slippy map you can browse.
Kleptog 14:37, 7 February 2007 (UTC)
- I've not followed this effort closely, but should we not ultimately aim at having the coastline in osm (i.e. in our data base), so that everyone can edit it, instead of linking the data in in a later step? (Or have you extracted your data from osm?) Depends of course on who should have the last word on coastline - our users and contributors, or whoever has created the coastline data... if at all possible, I would be much in favour of loading the coastline into OSM and rendering from there. If osmarender cannot be persuaded to use the data, then the tiles@home tile generation would have to be modified so that osmarender and your script are run one after the other, and the results merged into one tile. --Frederik Ramm 15:19, 7 February 2007 (UTC)
I've rendered the Netherlands and Denmark and most of England. It turns out the the issues with "holes" in the map play at the lower level also. Some of the smaller islands don't go completely closed either. The code deals with that to some extent, but you do end up with odd edges where it can't be decided whether you're on land or sea...
In response to Frederik comment, while I admire the idea of being able to modify the coastline I'm not sure it's practical. Basically, the coastlines are millions of points, most of which no person will ever visit. Norway alone has 50,000km of coastline and no-one is going to check it, seriously. Coastline data is fairly static (relative to other data) and I really don't think OSM is the right place.
- Nevertheless, people have in fact been correcting the coastline data in OSM around Oslo. This is very easy using the Yahoo! imagery. The PGS data is very low resolution, and a map of Oslo would not look good without corrected data. Even if is the coastline is kept in a separate database, it must allow corrections to be made. Håkon 13:36, 10 March 2007 (UTC)
I'm also considering the issue of what happens if we find a better source of data. Currently we're using PGS, but what if they release a newer version? How do we merge user changes? That's a fairly unresolved problem. Rather than merging everything into a single server, make a seperate server just for coastlines and teach JOSM how to use it...
Also, I don't think the land/sea tiles should be merged onto the osmarender layers, but rather they should appear as a base layer on which the others can display. I'm thinking in the future we might have height information also, and making seperate tiles to display the various combinations is silly. Better allow the user to overlay them at viewing time. To that end I'm just building the tiles directly now.
Kleptog 22:56, 13 February 2007 (UTC)