[PATCH v2] - handle "anti-islands"
v2 - now checks to see if an anti-island is surrounded by water or land. If surrounded by water, it is converted back into an island (tagged with the land tag) and a warning message is issued. Tested with the GB map, it detected a handful of anti-islands that should have been islands but their points were in the wrong order (backwards). --------------- This patch extends the sea generation stuff to cope with anti-islands (water inside, land outside and, presumably, where the anti-treasure is hidden). Anti-islands are tagged natural=water (you can't use natural=sea because it will be beneath the surrounding land polygon). Note that if your map contains any islands whose direction is incorrect, they will now be filled with water. To help find such islands, a warning message is output when an anti-island is discovered. The upside is that if your map contains anti-islands whose direction is correct, they will now become visible. Mark
Hi Mark, On Tue, Jan 26, 2010 at 05:51:07PM +0000, Mark Burton wrote:
v2 - now checks to see if an anti-island is surrounded by water or land.
If surrounded by water, it is converted back into an island (tagged with the land tag) and a warning message is issued.
Tested with the GB map, it detected a handful of anti-islands that should have been islands but their points were in the wrong order (backwards).
I tested with the FI map, but did not get any anti-island warnings. I tested both without and with --generate-sea=polygons. Sorry, I did not run --generate-sea=polygons without your patch. With generate-sea, I found some anti-treasure like the following. 2010/01/26 22:41:52 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427399860) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes! This looks like a generated way (bogus browse URL) and a generated node at a tile boundary, lat=62.226562. The generated node is very close to a real coastline node. Can you avoid adding a node when it is "Garmin equal" to an existing node? There are many lakes (tagged as natural=coastline) at my tile boundaries. 2010/01/26 22:41:47 WARNING (Osm5XmlHandler): Non-closed coastline segment does not hit bounding box: 28953387 (60,51214/27,91898) 28953375 (60,50997/27,91529) http://www.openstreetmap.org/?mlat=60.51214&mlon=27.91898&zoom=17 This ought to be at the Geofabrik finland.osm.bz2 boundary, i.e., nothing to worry about, for now. The coastline segment belongs to Russia since WW II. Best regards, Marko
Hello Marko,
I tested with the FI map, but did not get any anti-island warnings. I tested both without and with --generate-sea=polygons. Sorry, I did not run --generate-sea=polygons without your patch. With generate-sea, I found some anti-treasure like the following.
2010/01/26 22:41:52 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427399860) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
This looks like a generated way (bogus browse URL) and a generated node at a tile boundary, lat=62.226562. The generated node is very close to a real coastline node. Can you avoid adding a node when it is "Garmin equal" to an existing node? There are many lakes (tagged as natural=coastline) at my tile boundaries.
I don't know what's happening there. This generated node you refer to, where's it coming from? That message comes from the short-arc removal code so the node was either in the original OSM data or it has been introduced by the sea generation or possibly by the "soft clipping" code. Does it go away if you don't generate sea?
2010/01/26 22:41:47 WARNING (Osm5XmlHandler): Non-closed coastline segment does not hit bounding box: 28953387 (60,51214/27,91898) 28953375 (60,50997/27,91529) http://www.openstreetmap.org/?mlat=60.51214&mlon=27.91898&zoom=17
This ought to be at the Geofabrik finland.osm.bz2 boundary, i.e., nothing to worry about, for now. The coastline segment belongs to Russia since WW II.
OK. Mark
Hi Mark,
I tested both without and with --generate-sea=polygons. Sorry, I did not run --generate-sea=polygons without your patch. With generate-sea, I found some anti-treasure like the following.
2010/01/26 22:41:52 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427399860) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
This looks like a generated way (bogus browse URL) and a generated node at a tile boundary, lat=62.226562. The generated node is very close to a real coastline node. Can you avoid adding a node when it is "Garmin equal" to an existing node? There are many lakes (tagged as natural=coastline) at my tile boundaries.
I don't know what's happening there. This generated node you refer to, where's it coming from? That message comes from the short-arc removal code so the node was either in the original OSM data or it has been introduced by the sea generation or possibly by the "soft clipping" code. Does it go away if you don't generate sea?
Yes, it goes away if I don't generate sea. I reran --generate-sea=polygons without your anti-island patch: 2010/01/26 23:26:58 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418078) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes! Different generated way id, same warning. Marko
Marko,
Yes, it goes away if I don't generate sea. I reran --generate-sea=polygons without your anti-island patch:
2010/01/26 23:26:58 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418078) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
Different generated way id, same warning.
OK - I think I know where it's coming from. The sea generation code will clip the coastline where it hits the tile boundary so that's where the new node is coming from. I will look at that code and see if it can be smarter about reusing existing points. Mark
Marko,
2010/01/26 23:26:58 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418078) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
Can you please check to see whether this location is situated very close to the corner of a tile? I am guessing that the coastline cuts the corner of a tile and so you end up with nodes on each of the tile's edges at the corner. Actually, the coastline doesn't really need to have the short arc removal done on it anyway because it's not a routable way but as the short arc removal is done before the styling, it doesn't know if a way is routable or not so it treats all ways the same. There's probably a solution to this Mark
Hi Marko, Please try the attached patch and see if it gets rid of the "can't be merged" error you are getting when generating sea. Mark
Hi Mark, On Tue, Jan 26, 2010 at 10:53:48PM +0000, Mark Burton wrote:
Hi Marko,
Please try the attached patch and see if it gets rid of the "can't be merged" error you are getting when generating sea.
Sorry, no dice. I still see several of the warnings, including the one that I reported last night: 2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418010) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes! In another message, you asked:
Can you please check to see whether this location is situated very close to the corner of a tile? I am guessing that the coastline cuts the corner of a tile and so you end up with nodes on each of the tile's edges at the corner.
Like I wrote in the message you replied to, it is at the tile border, lat=62.226562. If you go to the browse URL, the marker is very slightly SSW of a node of http://www.openstreetmap.org/browse/way/23553585 (the coastline). I would guess that this is some rounding issue. Initially, mkgmap thinks that the pre-existing node is not at the tile border and adds a node there, and later it notices that the coordinates are equal after all. The complete set of my options are: java -Xmx1024m -ea -Dlog.config=logging.properties -jar mkgmap.jar \ --family-name=foo --generate-sea=polygons -c mkgmap.args This is based on osm2img.sh at http://www.polkupyoraily.net/osm/, just adding --generate-sea=polygons. Best regards, Marko
Hi Marko,
Please try the attached patch and see if it gets rid of the "can't be merged" error you are getting when generating sea.
Sorry, no dice. I still see several of the warnings, including the one that I reported last night:
2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null (http://www.openstreetmap.org/browse/way/4611686018427418010) has consecutive nodes with the same coordinates (http://www.openstreetmap.org/?mlat=62.22656&mlon=25.82736&zoom=17) but they can't be merged because both are boundary nodes!
Actually, that's a rather silly message anyway because if the nodes have the same coordinates they could be merged without problem. I shall look at that.
In another message, you asked:
Can you please check to see whether this location is situated very close to the corner of a tile? I am guessing that the coastline cuts the corner of a tile and so you end up with nodes on each of the tile's edges at the corner.
Like I wrote in the message you replied to, it is at the tile border, lat=62.226562. If you go to the browse URL, the marker is very slightly SSW of a node of http://www.openstreetmap.org/browse/way/23553585 (the coastline). I would guess that this is some rounding issue. Initially, mkgmap thinks that the pre-existing node is not at the tile border and adds a node there, and later it notices that the coordinates are equal after all.
Yeah, I know it's on the border but is it at a tile corner? The patch I posted does (read should) fix a bug in the sea code because when it's making up the edges of the land mass that is clipped at the tile's edge it doesn't notice if the coastline reaches the tile edge exactly at a corner of the tile. In that (albeit unlikely) case, the existing code would generate a consecutive point and you would get a message like the above. Mark
Hi Mark,
Can you please check to see whether this location is situated very close to the corner of a tile? I am guessing that the coastline cuts the corner of a tile and so you end up with nodes on each of the tile's edges at the corner.
Like I wrote in the message you replied to, it is at the tile border, lat=62.226562. If you go to the browse URL, the marker is very slightly SSW of a node of http://www.openstreetmap.org/browse/way/23553585 (the coastline). I would guess that this is some rounding issue. Initially, mkgmap thinks that the pre-existing node is not at the tile border and adds a node there, and later it notices that the coordinates are equal after all.
Yeah, I know it's on the border but is it at a tile corner?
Sorry, no, it is not. The tile corners are more than 100 km to the west and east.
The patch I posted does (read should) fix a bug in the sea code because when it's making up the edges of the land mass that is clipped at the tile's edge it doesn't notice if the coastline reaches the tile edge exactly at a corner of the tile. In that (albeit unlikely) case, the existing code would generate a consecutive point and you would get a message like the above.
I did not look at the map output yet. So far, I haven't enabled generate-sea in my "release" maps, because last time I checked, the output was unusable due to flooding. I am planning to enable it near term. Marko
participants (2)
-
Mark Burton -
Marko Mäkelä