Multipolygon broken without warning
Hi WanMil, The Vanajavesi multipolygon looks partially inverted on my map, as you can see in the attached crop of a QLandkarte screenshot. The bay to the south of the pointer is way http://www.openstreetmap.org/browse/way/43149608 and the lake is this multipolygon: http://www.openstreetmap.org/browse/relation/302922 The eastern tip of the inverted triangle could be near the east endpoint of the way, http://www.openstreetmap.org/?lat=61.1396522&lon=24.3896432&zoom=18 None of these have been edited recently. It seems to be this map tile: 63240002: 2822016,969728 to 2916352,1172416 # : 60.553894,20.808105 to 62.578125,25.157318 It would be easier to troubleshoot this if splitter produced something that can be cut by Osmosis. Any ideas what could be causing the issue? Marko
Hi Marko, I replaced the natural=water from the outer ways to the multipolygon-relation. Same error I had with Vuohijärvi. Maybe this works better. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Multipolygon-broken-without-warning-tp572388... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi aighes,
I replaced the natural=water from the outer ways to the multipolygon-relation. Same error I had with Vuohijärvi. Maybe this works better.
I guess you are suggesting that if some of the three role=outer ways of the Vanajavesi coastline had natural=water set, mkgmap could close these lines, assuming them to be polygons? I just checked (ctrl-L in JOSM, and loaded http://api.openstreetmap.org/api/0.6/relation/302922/full). None of the relation members have anything set, except place=island and name for two islands: http://www.openstreetmap.org/?lat=61.1801363&lon=24.0677991&zoom=16 (I guess place=islet would be more appropriate than place=island, given that large populated islands in Helsinki are tagged as place=islet.) Marko
Hi, I thought, that tags, which discribe the multipolygon have to be taged in the relation and tags which belong to the way or the hole polygon have to be taged on the ways. I don't know, if this is the cause of the error, but other things seems to be ok. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Multipolygon-broken-without-warning-tp572388... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, On Wed, Nov 10, 2010 at 02:54:57AM -0800, aighes wrote:
I thought, that tags, which discribe the multipolygon have to be taged in the relation and tags which belong to the way or the hole polygon have to be taged on the ways.
I don't know, if this is the cause of the error, but other things seems to be ok.
I was trying to say that this is already the case for this multipolygon, which was last edited by you, by the way: http://www.openstreetmap.org/browse/relation/302922 I'm sure that WanMil will figure out what is causing the mistranslation. Best regards, Marko
Mmh, I don't know what happened there. You might run mkgmap again with a detailed logging (the level of the class MultipolygonRelation should be set to FINE). Then you can search in the logfile for the link http://www.openstreetmap.org/browse/relation/302922. All messages until the next relation link belong to the creation of this multipolygon. If you can't make sense out of it send me a link to the logfile. Then I will have a look on it. WanMil
Hi,
On Wed, Nov 10, 2010 at 02:54:57AM -0800, aighes wrote:
I thought, that tags, which discribe the multipolygon have to be taged in the relation and tags which belong to the way or the hole polygon have to be taged on the ways.
I don't know, if this is the cause of the error, but other things seems to be ok.
I was trying to say that this is already the case for this multipolygon, which was last edited by you, by the way:
http://www.openstreetmap.org/browse/relation/302922
I'm sure that WanMil will figure out what is causing the mistranslation.
Best regards,
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I logged both broken multipolygons (303344 and 302922) with logging-level FINE and seperated the details of both relations. You can find the loggs at http://hscholland.de/data/mkgmap.log.7z aighes -- View this message in context: http://gis.638310.n2.nabble.com/Multipolygon-broken-without-warning-tp572388... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I logged both broken multipolygons (303344 and 302922) with logging-level FINE and seperated the details of both relations. You can find the loggs at http://hscholland.de/data/mkgmap.log.7z
aighes
Ok, things are clear now. The multipolygon was tagged only with name=Vanajavesi and the three outer ways were tagged with natural=water. Since r1711 mkgmap generally uses the tags from the multipolygon if it has at least one tag (type=multipolygon does not count). So the mp (which means the merged polgons) is tagged only with name=Vanajavesi. The tags of the outer ways are not removed so they still use natural=water. This leads to the described effect as they are autoclosed (I don't know where this happens). Correct tagging is now necessary for a correct processing. Before r1711 the tags were taken only from the multipolygon if it had at least one known "polygon"-tag (like natural, landuse etc.). But there was the problem that the list of known polygon tags could not be complete. So we decided to require a clean tagging. WanMil
On Thu, Nov 11, 2010 at 08:52:59PM +0100, WanMil wrote:
Correct tagging is now necessary for a correct processing.
Could mkgmap issue a warning when it closes an unclosed polygon, then? My issue with this error is that mkgmap produced an incorrect map (from incorrect data) without writing anything to the logs. Marko
Hi, I've fixed some more mp's with this error in finland. Should be in extract of 13.11 (I think it was to late for tomorrows extract). I would prefer a WARNING in case of closing an unclosed polygon, too. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Multipolygon-broken-without-warning-tp572388... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Wed, Nov 10, 2010 at 09:29:19PM +0100, WanMil wrote:
Mmh, I don't know what happened there.
Me neither. Today's data is OK.
You might run mkgmap again with a detailed logging (the level of the class MultipolygonRelation should be set to FINE).
I will do that with yesterday's data, which I saved. Marko
So it seems to be a tagging-problem. Befor I changed the lakes, natural=water was tagged on the three outer ways. This means, that you have three ways with a polygon-tag -> will cause errors. Now it's tagged as documented in the wiki. ( http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Forest_with_2_lakes... ). Is there an easy way to find some more wrong multipolygons? aighes -- View this message in context: http://gis.638310.n2.nabble.com/Multipolygon-broken-without-warning-tp572388... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Thu, Nov 11, 2010 at 12:40:15AM -0800, aighes wrote:
So it seems to be a tagging-problem. Befor I changed the lakes, natural=water was tagged on the three outer ways. This means, that you have three ways with a polygon-tag -> will cause errors.
Right, I see this difference in the FINE logging output: (MultiPolygonRelation): 63240002.osm.gz: Construct multipolygon http://www.openstreetmap.org/browse/relation/302922 [natural=water,type=multipolygon,name=Vanajavesi] (MultiPolygonRelation): 63240002.osm.gz: outer http://www.openstreetmap.org/browse/way/11286420 [] (MultiPolygonRelation): 63240002.osm.gz: outer http://www.openstreetmap.org/browse/way/25551892 [] (MultiPolygonRelation): 63240002.osm.gz: outer http://www.openstreetmap.org/browse/way/43149608 [] In yesterday's data, the natural=water would be missing from the multipolygon but present in the three outer members.
Is there an easy way to find some more wrong multipolygons?
If the inverted triangle was caused by mkgmap closing unclosed polygons, I think that mkgmap should warn about the unclosed polygons. Is there any reason why it does not do so currently? Marko
On Thu, Nov 11, 2010 at 09:59:00AM +0200, Marko Mäkelä wrote:
You might run mkgmap again with a detailed logging (the level of the class MultipolygonRelation should be set to FINE).
I will do that with yesterday's data, which I saved.
I added this to logging.properties: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE This relation is in exactly one of the input files: $ zgrep 'relation.*302922' *.osm.gz 63240002.osm.gz:<relation id='302922'> $ zgrep 'way.*43149608' *.osm.gz 63240002.osm.gz:<way id='43149608'> 63240002.osm.gz:<member type='way' ref='43149608' role='outer'/> I compiled just this tile in order to get the output. Otherwise there would have been too much output at the FINE level. The output for this multipolygon (and the first line for the following multipolygon) are attached, in bzip2 format. Again, the bounding box for this tile is: 63240002: 2822016,969728 to 2916352,1172416 # : 60.553894,20.808105 to 62.578125,25.157318 If you need a copy of the 63240002.osm.gz or any other files, let me know. I loaded this map in QLandkarte and verified that the lake is still broken in the same way with this input. It is OK today. Best regards, Marko
participants (3)
-
aighes -
Marko Mäkelä -
WanMil