Hi, I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please? I hesitate to whine about contributions to mkgmap as I don't want to stop them arriving but if we can't easily work out how the code works then it doesn't bode well for maintenance and bug fixing when the original author has moved on. I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.) I realise that this is dependent on the performance of the MP stuff but it seems to me that generating the right polygons in the first place would be a good start. I guess that the Baltic area is probably rather a challenge for the current state of the art. Thanks, Mark
On Dec 28, 2009, at 19:54, Mark Burton wrote:
I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.)
I, unfortunately, can't help you specifically with the generate sea stuff. I can only comment that my previous tests with this option were not particularly satisfactory. Since distinguishing land from water seems to be an important feature of marine maps, I wonder if it makes sense to generate a one-off sea layer using cGPSmapper instead of mkgmap, until the generate sea problems are resolved? Or do most marine units have a sufficiently detailed base map? In that case a transparent OSM map (with POIs and other features) might be more appropriate, as this could be layered over the base sea map. Cheers.
On 28.12.2009 21:22, Clinton Gladstone wrote:
On Dec 28, 2009, at 19:54, Mark Burton wrote:
I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.)
I, unfortunately, can't help you specifically with the generate sea stuff. I can only comment that my previous tests with this option were not particularly satisfactory. Since distinguishing land from water seems to be an important feature of marine maps, I wonder if it makes sense to generate a one-off sea layer using cGPSmapper instead of mkgmap, until the generate sea problems are resolved?
Or do most marine units have a sufficiently detailed base map? In that case a transparent OSM map (with POIs and other features) might be more appropriate, as this could be layered over the base sea map.
Cheers.
cgpsmapper produced maps may not be used CCBYSA 2.0 (only non commercial). It would probably nevertheless be best to create a layered sea map instead of creating it each time. mapnik/osmarender also only periodically render the sea/shoreline.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Dec 28, 2009, at 21:27, Felix Hartmann wrote:
cgpsmapper produced maps may not be used CCBYSA 2.0 (only non commercial). It would probably nevertheless be best to create a layered sea map instead of creating it each time.
Yes, that's true regarding the license. I suppose it would still be possible to generate the sea polygons from another (public domain) source and distribute the sea layer separately from the OSM layer, but that's a hassle both for the person generating the map, and users of the map. Cheers.
On 28.12.2009 23:22, Clinton Gladstone wrote:
On Dec 28, 2009, at 21:27, Felix Hartmann wrote:
cgpsmapper produced maps may not be used CCBYSA 2.0 (only non commercial). It would probably nevertheless be best to create a layered sea map instead of creating it each time.
Yes, that's true regarding the license. I suppose it would still be possible to generate the sea polygons from another (public domain) source and distribute the sea layer separately from the OSM layer, but that's a hassle both for the person generating the map, and users of the map.
Cheers. Well I don't see anyhow why cgpsmapper should be able to correctly render them. Anyhow the most convenient would be to have static osm sea only files, which are in such a format that mkgmap can use them easily. Then it would be just a matter of adding for each country the respective sea data (static) in osm format.
Hi, One option would be to use GroundTruth to generate MP (polish) files for sea polygons and then use mkgmap to generate the IMG from these. I'm the author of GroundTruth and I also received a request to help generate marine maps for http://www.boat-duesseldorf.com/ I had some success with sea filling algorithm (I use the same for Kosmos): http://igorbrejc.net/openstreetmap/groundtruth-coastline-rendering-improved Unfortunately I'm quite busy with coding Kosmos so I cannot invest too much time in making GroundTruth's MP files compile in mkgmap. But I'm willing to help in the effort, since I've become annoyed with incompatibility of cgpsmapper's license and that of OSM - it effectively prohibits any maps generated with GroundTruth and OSM data from being distributed. Regards, Igor Felix Hartmann wrote:
On 28.12.2009 23:22, Clinton Gladstone wrote:
On Dec 28, 2009, at 21:27, Felix Hartmann wrote:
cgpsmapper produced maps may not be used CCBYSA 2.0 (only non commercial). It would probably nevertheless be best to create a layered sea map instead of creating it each time.
Yes, that's true regarding the license. I suppose it would still be possible to generate the sea polygons from another (public domain) source and distribute the sea layer separately from the OSM layer, but that's a hassle both for the person generating the map, and users of the map.
Cheers. Well I don't see anyhow why cgpsmapper should be able to correctly render them. Anyhow the most convenient would be to have static osm sea only files, which are in such a format that mkgmap can use them easily. Then it would be just a matter of adding for each country the respective sea data (static) in osm format.
Hi! Am 28.12.2009 23:22, schrieb Clinton Gladstone:
I suppose it would still be possible to generate the sea polygons from another (public domain) source and distribute the sea layer separately from the OSM layer, but that's a hassle both for the person generating the map, and users of the map.
Unfortunately, it seems that this approach is currently still state-of-the art. When I was looking for sea polygons for my map, I was unable to find any satisfactory mechanism for producing them automatically. I was given some manually created sea polygons for the German coasts by chris66 and I have created some for the mediterranean sea from the coast shapefiles used by mapnik. bye Nop
2009/12/28 Mark Burton <markb@ordern.com>:
Hi,
I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please?
I hesitate to whine about contributions to mkgmap as I don't want to stop them arriving but if we can't easily work out how the code works then it doesn't bode well for maintenance and bug fixing when the original author has moved on.
I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.) I realise that this is dependent on the performance of the MP stuff but it seems to me that generating the right polygons in the first place would be a good start.
Hi Mark! I can't help you with the code directly, but I'm facing a similar problem because i use elevation contours as polygons for visualisation of terrain shapes and have to do a _lot_ of manual fixing with JOSM just to close the ways of my rather small srtm tiles. What I do is the following (described how i think a program could do it): 1. find the end node of a way tagged with the lowest elevation level that is on the tile boundary. 2. as my srtm tiles are generated by "ground truth", contour lines always go clockwise around a peak (higher terrain is on the right hand side). So I follow the tile border clockwise until I either hit a corner node (i have to insert them manually), which I would then append to the way and continue, or hit a start node of a contour with the same elevation, which I would combine with my way and continue *at the new end node of the current way*(this is important because there can be other ways in between which should form a polygon on thier own). 3. If I hit the start node of the way i'm currently working on, i close the way and look for others I did'nt touch before 5. if there are none left, i add all counter-clockwise ways not touching the boundary to a multipolygon with role=inner and move on to the next elevation step I think the scheme is pretty simple and should work for sea, but I since I can't write code, I can't create a tool that does the job for me. If you work on the generate-sea-code, maybe you could consider to make the close-ways-(anti)clockwise-around-tile-borders-to-form-polygons functionality usable for other things, too - such as creating usable polygons from elevation contours? I'll upload a 1°x2° test area map of this stuff within the next days, in case someone wonders what the hell this guy is talking about. ;-) -Martin
2009/12/28 Martin Simon <grenzdebil@gmail.com>:
Hi Mark!
I can't help you with the code directly, but I'm facing a similar problem because i use elevation contours as polygons for visualisation of terrain shapes and have to do a _lot_ of manual fixing with JOSM just to close the ways of my rather small srtm tiles.
What I do is the following (described how i think a program could do it):
...
I'll upload a 1°x2° test area map of this stuff within the next days, in case someone wonders what the hell this guy is talking about. ;-)
-Martin
OK, I finally managed to complete the test area map, it's uploaded here: http://osm-topo.bplaced.net/download/topo-garmin.zip Just the elevation coloring tiles and the .typ file for use in QLandkarteGT (or mapsource if you know how to install a map) can be downloaded here: http://osm-topo.bplaced.net/download/topo-gelaende-qlandkarte.zip Some pictures and a description in german can be found here: http://osm-topo.bplaced.net If someone is interested, I can also provide the source .osm-Files for the elevation coloring plus the corresponding style file. cheers, Martin
On 12/28/2009 07:54 PM, Mark Burton wrote:
I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.) I realise that this is dependent on the performance of the MP stuff but it seems to me that generating the right polygons in the first place would be a good start.
I guess that the Baltic area is probably rather a challenge for the current state of the art.
If a static Baltic Sea is of any use to you you can use the sea tile from my topo Germany map. Handmade polygons, but it works.
Am 20:59, schrieb Mark Burton:
Hi,
I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please?
Thanks,
Mark
Hi, I'm working for a while on the flooded island problem. Here's what I found: While parsing the OSM file all ways tagged as "natural=coastline" are added to "List<Way> shoreline" (in method Osm5XmlHandler::endElement). The main work is done in method generateSeaPolygon called from Osm5XmlHandler::endDocument. First all not closed ways are tryed to be closed by finding ways with matching end and start points (method concatenateWays). All closed ways are added to a "seaRelation". For the remaining non closed ways its assumed they hit the tile boundary. There is a class EdgeHit which contains the information which tile border was hit and where. A HashMap holds this info for every start and end point of the non closed ways. The method EdgeHit::compareTo is used to decide how these ways are closed along the tile bordes by adding points at the required corners (lines 1164 to 1225). I'm not sure if this is really done with the "water on the right" convention, but it works fine ;-). The problems I found are caused by what is done with the ways not hitting the tile borders. This may happen with data from e.g. geofabrik, where the data does not fill the whole tile border. If such a way exists there is a check if the way is nearly closed. If this check fails the way is added as an "outer way" to the seaRelation, preventing the bounding box to become the "outer way". Tiles being cut in a sea part and land part are the visible effect of this. To solve this I added code to find the nearest border and add a point at this border. There should be no new problem through this because the created point is in an empty area. (sea attached patch) The rest is done by the multipolygon code. In this class is also a major bug which causes flooded islands. While connecting the inner ways with the outer way, the connection for the current inner way is always added at the shortest distance to the already created result polygon. If a later inner way is nearer to the outer way the connection lines will cross the islands. So MapSource and perhaps other renderes of img files will not know where the sea is and the islands become flooded. I hope this helps a bit. Ronny
Am 30.12.2009 01:13, schrieb Ronny Klier:
Am 20:59, schrieb Mark Burton:
Hi,
I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please?
Thanks,
Mark
Hi,
I'm working for a while on the flooded island problem. Here's what I found:
To solve this I added code to find the nearest border and add a point at this border. There should be no new problem through this because the created point is in an empty area. (sea attached patch)
I hope this helps a bit.
Ronny
Sorry, I forgot to attach the patch in my last mail
I am doing some test as well. These are 3 problem islands I notice in my area: http://osm.org/go/4jc4Tp http://osm.org/go/4ymKMQ3 http://osm.org/go/4zK1EaT When creating a map for the whole country the above group of islands are always flooded. The data seems to be correct. I then created separate maps within the bbox of the island and the sea polygon is OK. Very common in the 3 examples are the very small islands almost close to each other. See example links: http://osm.org/go/4ymKGZcnJ-- http://osm.org/go/4zK1OZBs1-- On Wed, Dec 30, 2009 at 8:18 AM, Ronny Klier <ronny.klier@s1999.tu-chemnitz.de> wrote:
Am 30.12.2009 01:13, schrieb Ronny Klier:
Am 20:59, schrieb Mark Burton:
Hi,
I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please?
Thanks,
Mark
Hi,
I'm working for a while on the flooded island problem. Here's what I found:
To solve this I added code to find the nearest border and add a point at this border. There should be no new problem through this because the created point is in an empty area. (sea attached patch)
I hope this helps a bit.
Ronny
Sorry, I forgot to attach the patch in my last mail
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
participants (9)
-
Clinton Gladstone -
Felix Hartmann -
Igor Brejc -
maning sambale -
Mark Burton -
Martin Simon -
Nop -
Ralf Kleineisel -
Ronny Klier