Trouble getting some multipolygons to render in mkgmap
Hi, I'm having trouble getting mkgmap to render (using either the default style or my custom style) some multipolygons which I'm fairly sure are OK. The first is this one: http://www.openstreetmap.org/browse/relation/552313 The inner water way renders fine, but the outer way (leisure=park / barrier=wall) only renders the wall and not the park polygon. It renders fine both in mapnik and in osmarender. Another is the paired set of nested multipolygons at the nearby equestrian club: http://www.openstreetmap.org/browse/relation/414803 and http://www.openstreetmap.org/browse/relation/1184439 These both look fine in mapnik but this time osmarender only shows the inner multipolygon and mkgmap shows neither. And finally: http://www.openstreetmap.org/browse/relation/660096 Which renders fine in mapnik and osmarender, but not mkgmap I'm assuming I somehow tagged these mps wrongly as I created them...can someone point out my error? I'm sure it'll be a "doh" moment for me. -- Charlie
Hi Charlie, The only problem I could find for the first relation is the water is reversed. I am about to look at the others http://www.openstreetmap.org/browse/relation/552313 Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero Sent: Friday, 24 September 2010 3:42 PM To: Development list for mkgmap Subject: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap Hi, I'm having trouble getting mkgmap to render (using either the default style or my custom style) some multipolygons which I'm fairly sure are OK. The first is this one: http://www.openstreetmap.org/browse/relation/552313 The inner water way renders fine, but the outer way (leisure=park / barrier=wall) only renders the wall and not the park polygon. It renders fine both in mapnik and in osmarender. Another is the paired set of nested multipolygons at the nearby equestrian club: http://www.openstreetmap.org/browse/relation/414803 and http://www.openstreetmap.org/browse/relation/1184439 These both look fine in mapnik but this time osmarender only shows the inner multipolygon and mkgmap shows neither. And finally: http://www.openstreetmap.org/browse/relation/660096 Which renders fine in mapnik and osmarender, but not mkgmap I'm assuming I somehow tagged these mps wrongly as I created them...can someone point out my error? I'm sure it'll be a "doh" moment for me. -- Charlie _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
The other relations seem to have water reversed also. For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter. Markus_g For the -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Markus Sent: Friday, 24 September 2010 4:00 PM To: charlie@cferrero.net; 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap Hi Charlie, The only problem I could find for the first relation is the water is reversed. I am about to look at the others http://www.openstreetmap.org/browse/relation/552313 Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero Sent: Friday, 24 September 2010 3:42 PM To: Development list for mkgmap Subject: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap Hi, I'm having trouble getting mkgmap to render (using either the default style or my custom style) some multipolygons which I'm fairly sure are OK. The first is this one: http://www.openstreetmap.org/browse/relation/552313 The inner water way renders fine, but the outer way (leisure=park / barrier=wall) only renders the wall and not the park polygon. It renders fine both in mapnik and in osmarender. Another is the paired set of nested multipolygons at the nearby equestrian club: http://www.openstreetmap.org/browse/relation/414803 and http://www.openstreetmap.org/browse/relation/1184439 These both look fine in mapnik but this time osmarender only shows the inner multipolygon and mkgmap shows neither. And finally: http://www.openstreetmap.org/browse/relation/660096 Which renders fine in mapnik and osmarender, but not mkgmap I'm assuming I somehow tagged these mps wrongly as I created them...can someone point out my error? I'm sure it'll be a "doh" moment for me. -- Charlie _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 24/09/2010 10:42, Markus wrote:
The other relations seem to have water reversed also.
For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter.
Markus_g
For the Markus,
Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon "usage" section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: "The direction of the ways does not matter" -- Charlie
Not sure if it maters. But in JOSM validator it reversed water:land not on left side. This is why I thought it was correct. Markus_g -----Original Message----- From: Charlie Ferrero [mailto:charlie@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap On 24/09/2010 10:42, Markus wrote:
The other relations seem to have water reversed also.
For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter.
Markus_g
For the Markus,
Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon "usage" section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: "The direction of the ways does not matter" -- Charlie
Hi Charlie, With the tests I have just done I have found the leisure tag no longer works with multipolygons. Regards, Markus_g -----Original Message----- From: Charlie Ferrero [mailto:charlie@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap On 24/09/2010 10:42, Markus wrote:
The other relations seem to have water reversed also.
For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter.
Markus_g
For the Markus,
Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it. Also, the multipolygon "usage" section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: "The direction of the ways does not matter" -- Charlie
Hi, Markus is right. The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list. Attached patch extends this list by the tags "leisure", "military", "man_made", "place", "tourism", "amenity". I have found them by analyzing the europe OSM dump so this should catch most cases. By the way: the direction of ways is not evaluated. WanMil
Hi Charlie,
With the tests I have just done I have found the leisure tag no longer works with multipolygons.
Regards,
Markus_g
-----Original Message----- From: Charlie Ferrero [mailto:charlie@cferrero.net] Sent: Friday, 24 September 2010 4:31 PM To: Markus Cc: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap
On 24/09/2010 10:42, Markus wrote:
The other relations seem to have water reversed also.
For the last relation I would try reversing the swimming pool way and the outer way to match the coastline way. Although I wouldn't have thought that this would matter.
Markus_g
For the Markus,
Thanks for looking into this. Are you sure the sense of the way around water matters? I know that it is important for coastlines, but couldn't find any suggestion that it matters for other inland water masses, e.g. natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) doesn't mention it.
Also, the multipolygon "usage" section on the wiki (http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states: "The direction of the ways does not matter"
-- Charlie
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area. There shouldn't be a list of concerned tags, since any area tags may be used. Gruss Torsten
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. WanMil
Gruss Torsten
It appears that --generate-sea=polygons no longer works as I get the following error. Note --generate-sea=multipolygons doesn't come up with this error. Regards, Markus_g java.lang.NullPointerException at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.removeAntiIslands(SeaGe nerator.java:452) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.end(SeaGenerator.java:1 98) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingH ooksChain.java:69) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDa taSource.java:74) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:149) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:217) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source ) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Exiting - if you want to carry on regardless, use the --keep-going option
On 25/09/10 05:59, Markus_g wrote:
It appears that --generate-sea=polygons no longer works as I get the following error.
Thanks for reporting this. It should now be fixed in r1706. The fix relates to --generate-sea=polygons in spite of the commit message. ..Steve
Thanks Steve, It works now. Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Steve Ratcliffe Sent: Saturday, 25 September 2010 4:52 PM To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Help. Unknown Source when --generate-sea=polygons is used? On 25/09/10 05:59, Markus_g wrote:
It appears that --generate-sea=polygons no longer works as I get the following error.
Thanks for reporting this. It should now be fixed in r1706. The fix relates to --generate-sea=polygons in spite of the commit message. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I have tried the patch and have looked around Australia and I can't find any problems. Seems to be a good addition as some multipolygons I have never seen now appear in mapsource. Charlies missing multipolygons also now appear. Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 2:59 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code. You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know. WanMil
Gruss Torsten
Thanks for testing it. Before committing I would like to compare hard facts. How many mps are handled ok with the extended polygon tag list and how many mps are handled with the non polygon tag list. Unfortunately I don't have time to do this. So anybody should feel free to start investigations. WanMil
I have tried the patch and have looked around Australia and I can't find any problems. Seems to be a good addition as some multipolygons I have never seen now appear in mapsource.
Charlies missing multipolygons also now appear.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 2:59 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
WanMil
Gruss Torsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, Here is a spread sheet of the Polygon numbers using the default style with each unique patch version. Patched with Mkgmap r1706. The numbers are the total of each across all zoom levels. Also the total number of Polyline and Polyline roads are included. This is for Austalia. I understand if you need someone to try another part of the world due to different tagging schemes. Not sure why the Polygons have decreased with the patch that allows all tags. I ran each twice to check. Also I started from a fresh trunk download for each patch. Regards, Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 7:18 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons torender inmkgmap Thanks for testing it. Before committing I would like to compare hard facts. How many mps are handled ok with the extended polygon tag list and how many mps are handled with the non polygon tag list. Unfortunately I don't have time to do this. So anybody should feel free to start investigations. WanMil
I have tried the patch and have looked around Australia and I can't find any problems. Seems to be a good addition as some multipolygons I have never seen now appear in mapsource.
Charlies missing multipolygons also now appear.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 2:59 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
WanMil
Gruss Torsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Wow, great work! If you filter the types with decreased polygon numbers you get: Residential City Park Large lake Medium lake Major river Forrest I *guess* that in most cases the multipolygon is tagged with name=XXX but not with the polygon tag (natural=* etc.). With patch mp_stricttagrule_v1 these polygons are tagged only with name=XXX but not with a polygon tag and therefore no rule in the style file matches. But the difference (<1%) is not as big as I expected. Maybe it is time to commit the mp_stricttagrule_v1 to squeeze mappers to tag mps correctly. Can you repeat your analysis for parts of europe? WanMil
Hi WanMil,
Here is a spread sheet of the Polygon numbers using the default style with each unique patch version. Patched with Mkgmap r1706.
The numbers are the total of each across all zoom levels.
Also the total number of Polyline and Polyline roads are included.
This is for Austalia. I understand if you need someone to try another part of the world due to different tagging schemes.
Not sure why the Polygons have decreased with the patch that allows all tags. I ran each twice to check. Also I started from a fresh trunk download for each patch.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 7:18 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons torender inmkgmap
Thanks for testing it. Before committing I would like to compare hard facts. How many mps are handled ok with the extended polygon tag list and how many mps are handled with the non polygon tag list.
Unfortunately I don't have time to do this. So anybody should feel free to start investigations.
WanMil
I have tried the patch and have looked around Australia and I can't find any problems. Seems to be a good addition as some multipolygons I have never seen now appear in mapsource.
Charlies missing multipolygons also now appear.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 2:59 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
WanMil
Gruss Torsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Wanmil, I tried running the program I used for the analysis of Australia on the UK but it crashes. Looks like it can't handle to many img files. I will try again with a smaller slice. Would be great if mkgmap was able to create a log file output with this type of analysis for testing purposes. Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Sunday, 26 September 2010 12:05 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons torender inmkgmap Wow, great work! If you filter the types with decreased polygon numbers you get: Residential City Park Large lake Medium lake Major river Forrest I *guess* that in most cases the multipolygon is tagged with name=XXX but not with the polygon tag (natural=* etc.). With patch mp_stricttagrule_v1 these polygons are tagged only with name=XXX but not with a polygon tag and therefore no rule in the style file matches. But the difference (<1%) is not as big as I expected. Maybe it is time to commit the mp_stricttagrule_v1 to squeeze mappers to tag mps correctly. Can you repeat your analysis for parts of europe? WanMil
Hi WanMil,
Here is a spread sheet of the Polygon numbers using the default style with each unique patch version. Patched with Mkgmap r1706.
The numbers are the total of each across all zoom levels.
Also the total number of Polyline and Polyline roads are included.
This is for Austalia. I understand if you need someone to try another part of the world due to different tagging schemes.
Not sure why the Polygons have decreased with the patch that allows all tags. I ran each twice to check. Also I started from a fresh trunk download for each patch.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 7:18 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons torender inmkgmap
Thanks for testing it. Before committing I would like to compare hard facts. How many mps are handled ok with the extended polygon tag list and how many mps are handled with the non polygon tag list.
Unfortunately I don't have time to do this. So anybody should feel free to start investigations.
WanMil
I have tried the patch and have looked around Australia and I can't find any problems. Seems to be a good addition as some multipolygons I have never seen now appear in mapsource.
Charlies missing multipolygons also now appear.
Regards,
Markus_g
-----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of WanMil Sent: Saturday, 25 September 2010 2:59 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap
WanMil schrieb am 24.09.2010 17:35:
The mp code must check if the mp itself contains the relevant polygon tags or if the tagging should be taken from the outer ways. For this purpose a list of known polygon tags is used and up to now leisure is not in this list.
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
There shouldn't be a list of concerned tags, since any area tags may be used.
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was neccessary when I implemented the mp code.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
WanMil
Gruss Torsten
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil schrieb am 24.09.2010 19:29:
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations. I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon. As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area) Right now polygon A seems to be missing in the resulting map. Gruss Torsten
Torsten Leistikow (de_muur@gmx.de) wrote:
WanMil schrieb am 24.09.2010 19:29:
My understanding of the multipolygons is, that the tags may EITHER be in the relation OR on the outer polygons. So the outerpoylgons are only to be used, when there are no tags on the relation. If the relation itself is tagged and there is a tag on the outerpolygons, this does logical mean, that the outerpolygon tags apply to the complete area including the inner-area.
You càn check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
I tried your patch today, and I think it looks quite promising. Implementing such a strict scheme will certainly show some faulty multipolygon (e.g. Aussenalster in Hamburg), but perhaps this will encourage a cleaner tagging of such relations.
I think the patch has still one problem: If the tags of the outerpolygon are not used for the multipolygon area, they must still be used as a stand-alone polygon.
As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area)
Right now polygon A seems to be missing in the resulting map.
But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)? -- Charlie
charlie@cferrero.net schrieb am 27.09.2010 15:20:
As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area)
Right now polygon A seems to be missing in the resulting map.
But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)?
It should use both: The nature reserve should cover the complete area. The wood should cover only the area defined by the multipolygon. This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be: 1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B 2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B 3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B 4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area). Gruss Torsten
Torsten Leistikow (de_muur@gmx.de) wrote:
charlie@cferrero.net schrieb am 27.09.2010 15:20:
As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area)
Right now polygon A seems to be missing in the resulting map.
But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)?
It should use both:
The nature reserve should cover the complete area.
The wood should cover only the area defined by the multipolygon.
This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be:
1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B
2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B
3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B
4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B
I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area).
Gruss Torsten
OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon & water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control). -- Charlie
charlie@cferrero.net schrieb am 27.09.2010 16:49:
OK, but in practical terms if mkgmap generated a nature reserve polygon, a wood multipolygon and an inner water polygon, wouldn't the visible results be undefined? In other words, you could end up with either: a) Wood multipolygon & water polygon hidden underneath a nature reserve polygon, or b) A nature reserve polygon hidden underneath the wood mp and water polygon depending on draw order of the polygons (which afaik you can't control).
You can control the draw order of the polygons via the style file. So depending on the targeted use of your map, the result will look differently but clearly defined. In case of the example: My map style would display the wood and the water next to each other. The nature reserve is displayed on top of both, but it is a semi transparent texture. Gruss Torsten
charlie@cferrero.net schrieb am 27.09.2010 15:20:
As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area)
Right now polygon A seems to be missing in the resulting map.
But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)?
It should use both:
The nature reserve should cover the complete area.
The wood should cover only the area defined by the multipolygon.
This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be:
1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B
2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B
3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B
4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B
I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area).
Gruss Torsten
Hi Torsten, I am back and I have thought about your request. It would be possible to implement a patch which keeps the original polygons in case they are tagged differently to the multipolygon. I have also read Charlies answers and before digging in the code I would know if this feature is really needed and useful? Can you estimate how many multipolygons are affected? WanMil
Am 13.10.2010 22:09, schrieb WanMil:
charlie@cferrero.net schrieb am 27.09.2010 15:20:
As an example take a nature reserve consisting of a wood with a lake inside. This migth be mapped with two polygons and a relation: polygon A: leisure=nature_reserve (the complete area) polygon B: natural=water (only the inner area) multipolygon relation: natural=wood and outer=polygon A and inner=polygon B (only the surrounding area)
Right now polygon A seems to be missing in the resulting map.
But how would mkgmap know which of the two outer polygon types to use (ie nature reserve or wood)?
It should use both:
The nature reserve should cover the complete area.
The wood should cover only the area defined by the multipolygon.
This is (one of) the intended tagging of the multipolygons. Allowed alternatives (with the same logical interpretation) would be:
1. You could use an additional polygon for the outer limit of the multipolygon (polygon C) which would have the same nodes as polygon A. Polygon A and B would stay unchanged. multipolygon relation: natural=wood and outer=polygon C and inner=polygon B
2. You could put all tags from the relation on polygon C, polygon A and B would stay unchanged. polygon B: natural=wood multipolygon relation: outer=polygon A and inner=polygon B
3. You could move the nature reserve tag into the multipolygon area and the inner area. polygon A: polygon B: natural=water and leisure=nature_reserve multipolygon relation: natural=wood and leisure=nature_reserve and outer=polygon A and inner=polygon B
4. And you could move the tags from the relation of variant 3 to the outer polygon. polygon A: natural=wood and leisure=nature_reserve polygon B: natural=water and leisure=nature_reserve multipolygon relation: outer=polygon A and inner=polygon B
I think these five possibilities are all allowed under the actual accepted multipolygon scheme and they should all result in nearly the same garmin map. (Alternative 3 and 4 split the nature reserve into to areas, but in the end it covers teh same area).
Gruss Torsten
Hi Torsten,
I am back and I have thought about your request. It would be possible to implement a patch which keeps the original polygons in case they are tagged differently to the multipolygon.
I have also read Charlies answers and before digging in the code I would know if this feature is really needed and useful? Can you estimate how many multipolygons are affected?
WanMil
Hi, I have posted a patch (Improved tagging of multipolygons) that should fix it. Please test it! WanMil
WanMil (wmgcnfg@web.de) wrote:
I agree. But the real world does not strictly follow this definition. Unfortunately very lots of mps are tagged with some non polygon tags and therefore I introduced the list of well known polygon tags. At least this was necessary when I implemented the mp code.
You can check yourself if it's now the time to remove this polygon list. I have attached a patch that follows your proposal. Just test it and let us know.
WanMil
Hi - is there a chance we could one of these two patches committed? Either way, the current code omits a fair number of multipolygons due to not catching appropriate tags. -- Charlie
participants (7)
-
Charlie Ferrero -
charlie＠cferrero.net
-
Markus -
Markus_g
-
Steve Ratcliffe -
Torsten Leistikow -
WanMil