Hi, While geocaching on Saturday, I noticed an area of the map that was flooded. It seems the following relation is the culprit: http://www.openstreetmap.org/browse/relation/169902 It renders correctly in the openstreetmap, but the mkgmap generated map floods a large area with water: http://www.openstreetmap.org/?lat=36.13856&lon=-78.9059&zoom=15 Any thoughts? Francisco
Francisco, please post the splitters areas.list file. The tile borders are important for analyzing flooding problems. Also important: - Where did you download your data files (geofabric, cloudmade etc.) - Which splitter settings do you use? - Which mkgmap parameters do you use? WanMil
Hi,
While geocaching on Saturday, I noticed an area of the map that was flooded. It seems the following relation is the culprit:
http://www.openstreetmap.org/browse/relation/169902
It renders correctly in the openstreetmap, but the mkgmap generated map floods a large area with water:
http://www.openstreetmap.org/?lat=36.13856&lon=-78.9059&zoom=15
Any thoughts?
Francisco _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 2:59 PM, WanMil wrote:
please post the splitters areas.list file. The tile borders are important for analyzing flooding problems. Attaching the areas list on this email. Also important: - Where did you download your data files (geofabric, cloudmade etc.) Data downloaded from geofabric, North Carolina extract: http://download.geofabrik.de/osm/north-america/us/north-carolina.osm.pbf - Which splitter settings do you use? Splitter was used as follows:
java -Xmx1792m -ea -jar %SPLITTER%/splitter.jar --no-trim --max-areas=150 --cache=cache --mapid=63240001 --max-nodes=1200000 --write-kml=world.kml --geonames-file=cities15000.zip --pbf north-carolina.osm.pbf
- Which mkgmap parameters do you use?
mkgmap settings: java -Xmx1792M -ea -jar %MKGMAP%/mkgmap.jar --road-name-pois --adjust-turn-headings --latin1 --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --remove-short-arcs --make-opposite-cycleways --route --description="NC Routable" --series-name="NC Routable" --country-name="UNITED STATES" --country-abbr="US" 6324*.osm.pbf REM MERGE java -Xmx2048M -jar %MKGMAP%/mkgmap.jar --index --overview-mapname=63240000 --series-name="NC Routable" --latin1 --description="NC Routable" --product-id=4 --family-id=2053 --tdbfile --nsis --gmapsupp *324*.img M0000805.TYP
On Mon, Jun 06, 2011 at 03:51:51PM -0400, Francisco Moraes wrote:
Splitter was used as follows:
java -Xmx1792m -ea -jar %SPLITTER%/splitter.jar --no-trim --max-areas=150 --cache=cache --mapid=63240001 --max-nodes=1200000 --write-kml=world.kml --geonames-file=cities15000.zip --pbf north-carolina.osm.pbf
Is this with or without Steve's pbf-finish.patch to add the serializer.switchTypes() call to finishWrite() in BinaryMapWriter.java? If without, this is probably the faulty step. Marko
On 2:59 PM, Marko Mäkelä wrote:
Is this with or without Steve's pbf-finish.patch to add the serializer.switchTypes() call to finishWrite() in BinaryMapWriter.java?
I am sure (100%) that I have the patch. I recompiled the splitter and redid it all and I still have the problem. But the flooding is only happening within that one tile (63240017): 63240017: 1681408,-3680256 to 1705984,-3647488 # : 36.079102,-78.969727 to 36.606445,-78.266602 Any thoughts on what I should look for and what mkgmap settings I can use to debug the problem? The default log options don't seem to show any problem. I guess I will try using the XML output path and see if I still have the issue.
On 2:59 PM, Francisco Moraes wrote:
Any thoughts on what I should look for and what mkgmap settings I can use to debug the problem? The default log options don't seem to show any problem. I guess I will try using the XML output path and see if I still have the issue. Tried again with the splitter XML output and got the same exact result. The area between Eno River and Little River is still flooding. Thoughts?
On Tue, Jun 07, 2011 at 08:09:13AM -0400, Francisco Moraes wrote:
On 2:59 PM, Francisco Moraes wrote:
Any thoughts on what I should look for and what mkgmap settings I can use to debug the problem? The default log options don't seem to show any problem. I guess I will try using the XML output path and see if I still have the issue. Tried again with the splitter XML output and got the same exact result. The area between Eno River and Little River is still flooding. Thoughts?
You do not seem to provide -Dlog.config to the mkgmap run. Can you try with my logging.properties at http://www.polkupyoraily.net/osm/ please? Look for warnings about multipolygons, coastline, and unclosed areas. The splitter --pbf seems to work well with Steve's patch in place. I generated finland.osm.pbf today using the PBF splitter and got a few legitimate warnings for unclosed polygons and anti-islands. Yesterday, it gave me the same warnings about dead-end oneways as the XML splitter. So, I do trust your work on the PBF splitter now. Marko
On 2:59 PM, Marko Mäkelä wrote:
You do not seem to provide -Dlog.config to the mkgmap run. Can you try with my logging.properties at http://www.polkupyoraily.net/osm/ please? Look for warnings about multipolygons, coastline, and unclosed areas. Well, I found this:
2011/06/07 13:51:35 WARNING (MultiPolygonRelation): 63240017.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/169902 contains errors. Not very informative but it seems like the relation is indeed broken. Any thoughts? I will take a look but I am not yet exactly sure of what I am looking for. There are a few other problems in that tile but I don't know if the message that happens right after that relation is relevant or not to the problem: 2011/06/07 13:51:35 WARNING (MultiPolygonRelation): 63240017.osm.gz: Polygon 4611686018427417347(9330P)(37530594[1519P],37530542[718P],107036527[25P],107036529[719P],97129165[198P],37530536[175P],105082387[1486P],37530662[47P],65200293[37P],103323627[227P],103323621[144P],106442699[3P],106521867[16P],106521842[749P],37530684[1727P],37530658[1554P]) carries role outer but lies inside an outer polygon. Potentially its role should be inner.
The splitter --pbf seems to work well with Steve's patch in place. I generated finland.osm.pbf today using the PBF splitter and got a few legitimate warnings for unclosed polygons and anti-islands. Yesterday, it gave me the same warnings about dead-end oneways as the XML splitter. So, I do trust your work on the PBF splitter now. Ok, glad that's working properly. I am wondering if we should keep the output option as-is (--pbf) or change it to --output=pbf as suggested before.
On Tue, Jun 07, 2011 at 02:02:03PM -0400, Francisco Moraes wrote:
Well, I found this:
2011/06/07 13:51:35 WARNING (MultiPolygonRelation): 63240017.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/169902 contains errors.
Not very informative but it seems like the relation is indeed broken. Any thoughts? I will take a look but I am not yet exactly sure of what I am looking for.
I fired up JOSM, hit ctrl-l, typed http://api.openstreetmap.org/api/0.6/relation/169902/full and invoked the JOSM Validator on it. No errors found. Then I fired up the relation editor and noticed that all ways forms nice loops. I selected all the inner ways, and hit '3' (zoom to selection) and then zoomed in to one inner way at a time, checking that the inner way does not reside outside the outer way. I deselected each inner way, hit '3' again and zoomed in again, until I had reviewed and deselected every island. The map data looks correct but very detailed. The problem seems to be insufficient Garmin precision. Many islands are closer than 5 meters to the riverbank. I guess that the coordinates get rounded or truncated so that the islands will sometimes overlap with the riverbank. There are some multipolygons like that in Finland, for some golf course and maybe buildings. I am filtering out warnings for such multipolygons on a case-by-case basis. WanMil is our multipolygon expert. Could the code be made smarter in some way? When rounding the coordinates of inner ways, try to move them inside the outer way. If the inner way polygon gets too small, drop it entirely. Something like that? Marko
please post the splitters areas.list file. The tile borders are important for analyzing flooding problems. Attaching the areas list on this email. Also important: - Where did you download your data files (geofabric, cloudmade etc.) Data downloaded from geofabric, North Carolina extract: http://download.geofabrik.de/osm/north-america/us/north-carolina.osm.pbf - Which splitter settings do you use? Splitter was used as follows:
java -Xmx1792m -ea -jar %SPLITTER%/splitter.jar --no-trim --max-areas=150 --cache=cache --mapid=63240001 --max-nodes=1200000 --write-kml=world.kml --geonames-file=cities15000.zip --pbf north-carolina.osm.pbf
- Which mkgmap parameters do you use?
mkgmap settings:
java -Xmx1792M -ea -jar %MKGMAP%/mkgmap.jar --road-name-pois --adjust-turn-headings --latin1 --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --remove-short-arcs --make-opposite-cycleways --route --description="NC Routable" --series-name="NC Routable" --country-name="UNITED STATES" --country-abbr="US" 6324*.osm.pbf
REM MERGE
java -Xmx2048M -jar %MKGMAP%/mkgmap.jar --index --overview-mapname=63240000 --series-name="NC Routable" --latin1 --description="NC Routable" --product-id=4 --family-id=2053 --tdbfile --nsis --gmapsupp *324*.img M0000805.TYP
The flooding is caused by incomplete relatian data in the tile. This is a well known splitter problem. In such a case mkgmap must do a best guess and in this case it does not produce the expected result. I have uploaded all outer ways of the relation in the tile after joining (http://files.mkgmap.org.uk/detail/26). The GPX files can be openend with JOSM. That helps much for a better understanding of the mp processing. 1. MP joins all input ways. This creates three ways. One is a small part of the river but two ways cover most of the river bank. The ways are not closed because some little parts in the west are missing in the tile. 2. MP tries to close ways. All ways that can easily be closed outside the bounding box are now closed by mp. Most of the time this is the correct behaviour but in this case the two polygons of both river banks are closed to itself which causes the flooding. At the moment I have no idea how to fix that. mkgmap has to guess here and that also means that sometimes its guesses are wrong. In this case reducing the overlap of splitter might help. If endpoints of the river banks are not directly closeable without touching the bounding box the mp algorithm first tries to connect outer ways. This was committed in r1953. WanMil
On 2:59 PM, WanMil wrote:
please post the splitters areas.list file. The tile borders are important for analyzing flooding problems. Attaching the areas list on this email. Also important: - Where did you download your data files (geofabric, cloudmade etc.) Data downloaded from geofabric, North Carolina extract: http://download.geofabrik.de/osm/north-america/us/north-carolina.osm.pbf - Which splitter settings do you use? Splitter was used as follows:
java -Xmx1792m -ea -jar %SPLITTER%/splitter.jar --no-trim --max-areas=150 --cache=cache --mapid=63240001 --max-nodes=1200000 --write-kml=world.kml --geonames-file=cities15000.zip --pbf north-carolina.osm.pbf
- Which mkgmap parameters do you use?
mkgmap settings:
java -Xmx1792M -ea -jar %MKGMAP%/mkgmap.jar --road-name-pois --adjust-turn-headings --latin1 --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --remove-short-arcs --make-opposite-cycleways --route --description="NC Routable" --series-name="NC Routable" --country-name="UNITED STATES" --country-abbr="US" 6324*.osm.pbf
REM MERGE
java -Xmx2048M -jar %MKGMAP%/mkgmap.jar --index --overview-mapname=63240000 --series-name="NC Routable" --latin1 --description="NC Routable" --product-id=4 --family-id=2053 --tdbfile --nsis --gmapsupp *324*.img M0000805.TYP
The flooding is caused by incomplete relation data in the tile. This is a well known splitter problem. In such a case mkgmap must do a best guess and in this case it does not produce the expected result. I have uploaded all outer ways of the relation in the tile after joining (http://files.mkgmap.org.uk/detail/26). The GPX files can be openend with JOSM. That helps much for a better understanding of the mp processing. 1. MP joins all input ways. This creates three ways. One is a small part of the river but two ways cover most of the river bank. The ways are not closed because some little parts in the west are missing in the tile. 2. MP tries to close ways. All ways that can easily be closed outside the bounding box are now closed by mp. Most of the time this is the correct behaviour but in this case the two polygons of both river banks are closed to itself which causes the flooding. At the moment I have no idea how to fix that. mkgmap has to guess here and that also means that sometimes its guesses are wrong. In this case reducing the overlap of splitter might help or also increasing the overlap. If endpoints of the river banks are not directly closeable without touching the bounding box the mp algorithm first tries to connect outer ways. This was committed in r1953. WanMil
On 2:59 PM, WanMil wrote:
At the moment I have no idea how to fix that. mkgmap has to guess here and that also means that sometimes its guesses are wrong. In this case reducing the overlap of splitter might help or also increasing the overlap. If endpoints of the river banks are not directly closeable without touching the bounding box the mp algorithm first tries to connect outer ways. This was committed in r1953. Would it work better if the relation was split into two or three parts, one for the north riverbank and one for the south one?
On 2:59 PM, WanMil wrote:
At the moment I have no idea how to fix that. mkgmap has to guess here and that also means that sometimes its guesses are wrong. In this case reducing the overlap of splitter might help or also increasing the overlap. If endpoints of the river banks are not directly closeable without touching the bounding box the mp algorithm first tries to connect outer ways. This was committed in r1953. Would it work better if the relation was split into two or three parts, one for the north riverbank and one for the south one?
Yes, that's another option.
participants (3)
-
Francisco Moraes -
Marko Mäkelä -
WanMil