Commit: r2478: Use outer polygon tags if the multipolygon is tagged with name only
Version 2478 was committed by wanmil on Wed, 06 Feb 2013 Use outer polygon tags if the multipolygon is tagged with name only Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479) This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags. Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here. I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
I did some other tests, the geofabrik extract from Bulgaria didnt show those "borders", maybe because the international boundaries were incomplete. I also downloaded the border relation from Bulgaria as well as rel.1338717 (bg.osm) and process this file with mkgmap 2479, there were no issues at all. In my first testmap I used the europe extract, and the strange thing is that not all ways from rel. 1338717 were converted into borders but only in one tile, see attachment. So maybe it is related to the splitter keep-complete process in combination with r2478? I have uploaded this tile for further analysis: http://mijndev.openstreetmap.nl/~ligfietser/test/10133095.zip http://mijndev.openstreetmap.nl/~ligfietser/test/bg.osm The splitter coordinates are 10133095: 1951744,1124352 to 1990656,1206272 # : 41.879883,24.125977 to 42.714844,25.883789
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479)
This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon
No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags.
Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here.
I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko, splitters keep-complete option doesn't care much about boundaries (means it doesn't keep them complete). I think you have to use precompiled boundaries. Gerd Date: Fri, 8 Feb 2013 18:03:17 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only I did some other tests, the geofabrik extract from Bulgaria didnt show those "borders", maybe because the international boundaries were incomplete. I also downloaded the border relation from Bulgaria as well as rel.1338717 (bg.osm) and process this file with mkgmap 2479, there were no issues at all. In my first testmap I used the europe extract, and the strange thing is that not all ways from rel. 1338717 were converted into borders but only in one tile, see attachment. So maybe it is related to the splitter keep-complete process in combination with r2478? I have uploaded this tile for further analysis: http://mijndev.openstreetmap.nl/~ligfietser/test/10133095.zip http://mijndev.openstreetmap.nl/~ligfietser/test/bg.osm The splitter coordinates are 10133095: 1951744,1124352 to 1990656,1206272 # : 41.879883,24.125977 to 42.714844,25.883789
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479)
This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon
No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags.
Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here.
I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, Precompiled boundaries could be a solution, but the main problem is mkgmap r2478 is messing things up. rel.1338717 doesnt have any admin_level=2 tags at all but r2478 copies them somewhere from the international borders and puts them in the middle of the country. If it happens with boundary relations it could happen to other relations too...?
Onderwerp: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only Hi Minko,
splitters keep-complete option doesn't care much about boundaries (means it doesn't keep them complete). I think you have to use precompiled boundaries.
Gerd
Date: Fri, 8 Feb 2013 18:03:17 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only
I did some other tests, the geofabrik extract from Bulgaria didnt show those "borders", maybe because the international boundaries were incomplete. I also downloaded the border relation from Bulgaria as well as rel.1338717 (bg.osm) and process this file with mkgmap 2479, there were no issues at all.
In my first testmap I used the europe extract, and the strange thing is that not all ways from rel. 1338717 were converted into borders but only in one tile, see attachment. So maybe it is related to the splitter keep-complete process in combination with r2478?
I have uploaded this tile for further analysis: http://mijndev.openstreetmap.nl/~ligfietser/test/10133095.zip http://mijndev.openstreetmap.nl/~ligfietser/test/bg.osm
The splitter coordinates are 10133095: 1951744,1124352 to 1990656,1206272 # : 41.879883,24.125977 to 42.714844,25.883789
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479)
This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon
No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags.
Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here.
I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Gerd, This explains also why the national parks (boundary = national_park) polygons are broken on my maps or lacking pois. Is there a way to add precompiled boundaries to the splitted files (I guess those are not the same as the locator uses).
splitters keep-complete option doesn't care much about boundaries (means it doesn't keep them complete). I think you have to use precompiled boundaries.
Gerd
Hi Minko, I am not sure what you want to have, but you can still use the --problem-file option to tell splitter to keep selected rels or ways complete. You can also change line 1000 in MultiTileProcessor.java and remove the comment that excludes boundaries from being kept complete and compile your own version of splitter. Does that help? Gerd Minko-2 wrote
Gerd, This explains also why the national parks (boundary = national_park) polygons are broken on my maps or lacking pois. Is there a way to add precompiled boundaries to the splitted files (I guess those are not the same as the locator uses).
splitters keep-complete option doesn't care much about boundaries (means it doesn't keep them complete). I think you have to use precompiled boundaries.
Gerd
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks Gerd, I can try the --problem-file option next time for some large National Parks that cover multiple tiles. See for example Peak District National Park (rel 2176657) in the attachment. It would be more convenient to list key=value combinations instead of way or rel id's in the problem file list. For instance boundary=national_park and not rel 2176657, rel .... Also the problem with r2478 remains, maybe Wanmil can have a look at it?
I am not sure what you want to have, but you can still use the --problem-file option to tell splitter to keep selected rels or ways complete. You can also change line 1000 in MultiTileProcessor.java and remove the comment that excludes boundaries from being kept complete and compile your own version of splitter.
Does that help?
Gerd
Hi Minko, I agree that ids in the problem-file are not a good solution. I also think that we did only intend to exclude administrative boundaries. I don't want to code a complex rule parser, but I can probably add an option to enable the keep-complete function also for all type=boundary rels. (If you don't want to edit the source as suggested) Gerd Minko-2 wrote
Thanks Gerd, I can try the --problem-file option next time for some large National Parks that cover multiple tiles. See for example Peak District National Park (rel 2176657) in the attachment. It would be more convenient to list key=value combinations instead of way or rel id's in the problem file list. For instance boundary=national_park and not rel 2176657, rel ....
Also the problem with r2478 remains, maybe Wanmil can have a look at it?
I am not sure what you want to have, but you can still use the --problem-file option to tell splitter to keep selected rels or ways complete. You can also change line 1000 in MultiTileProcessor.java and remove the comment that excludes boundaries from being kept complete and compile your own version of splitter.
Does that help?
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
np.jpg (94K) <http://gis.19327.n5.nabble.com/attachment/5748646/0/np.jpg>;
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I don't want to code a complex rule parser, but I can probably add an option to enable the keep-complete function also for all type=boundary rels. (If you don't want to edit the source as suggested)
Gerd
Editing the source is too complicated for me ;-) I don't know if adding type=boundary relations will have a big negative impact on the performance? Some boundaries are tagged as type=multipolygon, are they handled at the moment by the keep-complete function?
Hi Minko, there are two places in the source that filter the data: In ProblemListProcessor.java we select on relations with one of these types: WANTED_RELS = {"restriction", "multipolygon" ,"through_route"}; Other relations are not passed to the keep-complete routines. So, yes, type=multipolygon relations are handled by the routine. Reg. performance: please see this thread: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co... Gerd Minko-2 wrote
I don't want to code a complex rule parser, but I can probably add an option to enable the keep-complete function also for all type=boundary rels. (If you don't want to edit the source as suggested)
Gerd
Editing the source is too complicated for me ;-) I don't know if adding type=boundary relations will have a big negative impact on the performance? Some boundaries are tagged as type=multipolygon, are they handled at the moment by the keep-complete function? _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
there are two places in the source that filter the data: In ProblemListProcessor.java we select on relations with one of these types: WANTED_RELS = {"restriction", "multipolygon" ,"through_route"}; Other relations are not passed to the keep-complete routines. So, yes, type=multipolygon relations are handled by the routine.
Reg. performance: please see this thread: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co...
In this thread Wanmil wrote: - Shouldn't boundary relations like multipolygons be complete in the tile? Yes, but... Adding all related boundary data to a tile increases the tile size very much and makes sense only if the boundaries are used as polygons. At the moment we don't know anybody who uses boundaries as polygons but lots of users use them as lines to display the border names. Since I render only type=boundary & boundary=national_park as polygon (not all boundary=administrative) is it possible and not too much work to add this rule to the keep-complete process? I dont think there are too many of them in OSM that it will affect the performance. As workaround, I could grab all of those relations and put them in the problem list with osmfilter or overpass api.
Hi Minko, -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Minko, please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar Change: keep-complete: do not exclude all type=boundary relations, but only those that have the boundary=administrative attribute Gerd Minko-2 wrote
Hi Gerd
there are two places in the source that filter the data: In ProblemListProcessor.java we select on relations with one of these types: WANTED_RELS = {"restriction", "multipolygon" ,"through_route"}; Other relations are not passed to the keep-complete routines. So, yes, type=multipolygon relations are handled by the routine.
Reg. performance: please see this thread: http://gis.19327.n5.nabble.com/splitter-relations-to-be-checked-with-keep-co...
In this thread Wanmil wrote: - Shouldn't boundary relations like multipolygons be complete in the tile? Yes, but... Adding all related boundary data to a tile increases the tile size very much and makes sense only if the boundaries are used as polygons. At the moment we don't know anybody who uses boundaries as polygons but lots of users use them as lines to display the border names.
Since I render only type=boundary & boundary=national_park as polygon (not all boundary=administrative) is it possible and not too much work to add this rule to the keep-complete process? I dont think there are too many of them in OSM that it will affect the performance.
As workaround, I could grab all of those relations and put them in the problem list with osmfilter or overpass api.
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks Gerd, I'll run it tonight on the europe extract and post the results later. Gerd wrote:
please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar
Change: keep-complete: do not exclude all type=boundary relations, but only those that have the boundary=administrative attribute
Thanks Gerd, the boundaries of national parks looks complete now so far I have tested it!
Gerd wrote:
please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar
Hi all, I think this change should be merged into trunk. Any objections? Gerd
Date: Sun, 10 Feb 2013 11:41:29 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only
Thanks Gerd, the boundaries of national parks looks complete now so far I have tested it!
Gerd wrote:
please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, it's ok for me but there are also some other administrative like boundaries, e.g. boundary=political. As far as I know they are quite often used in the UK. Maybe they should also be ignored. WanMil
Hi all,
I think this change should be merged into trunk. Any objections?
Gerd
Date: Sun, 10 Feb 2013 11:41:29 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only
Thanks Gerd, the boundaries of national parks looks complete now so far I have tested it!
Gerd wrote:
please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I also thought about that. I will look at it again before merging. Gerd WanMil wrote
Hi Gerd,
it's ok for me but there are also some other administrative like boundaries, e.g. boundary=political. As far as I know they are quite often used in the UK. Maybe they should also be ignored.
WanMil
Hi all,
I think this change should be merged into trunk. Any objections?
Gerd
Date: Sun, 10 Feb 2013 11:41:29 +0100 From:
ligfietser@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] Bugs in r2478: Use outer polygon tags if the multipolygon is tagged with name only
Thanks Gerd, the boundaries of national parks looks complete now so far I have tested it!
Gerd wrote:
please try r284 in the problem-list branch: http://www.mkgmap.org.uk/download/splitter-problem-list-r284.jar
mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... Sent from the Mkgmap Development mailing list archive at Nabble.com.
@Gerd No objections to merge it into Trunk ;-) @Wanmil, I will test it as soon as I can download the last version
Hi, has the problem been solved or is there still something to explain? If the greater tolerance of mkgmap for mapping errors (ignore mp tags if name is set only) causes problems I think I should revert that. WanMil
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479)
This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon
No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags.
Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here.
I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
Hi, On Mon, Feb 11, WanMil wrote:
Hi,
has the problem been solved or is there still something to explain? If the greater tolerance of mkgmap for mapping errors (ignore mp tags if name is set only) causes problems I think I should revert that.
I think you should revert that change. Looking at this example, the outcome is not always what we expect, and you cannot fix it in the style file. Thorsten
I see on my maps that all ways from http://www.openstreetmap.org/browse/relation/1338717 are rendered as country border now (mkgmap r-2479)
This relation contains only two tags: name = Hires coverage of Bing in Bulgaria type = multipolygon
No other tags, and yet it gets a admin_level=2 somehow. I think the relation contains ways with admin_level2 borders and gets 'contamined' with those tags.
Tested it with the default styles as well as mine, both render all those lines as international border. In mkgmap r2459 those lines were not rendered at all (as it should be), so i think there is a serious bug here.
I also get marine borders at some borders inland now (tagged with maritime=yes but they dont have those tags at all).
Use outer polygon tags if the multipolygon is tagged with name only
Quite a lot of mps are errorneously tagged with name only. This was ignored by the mp algorithm some time ago but at any point of time it disappeared. Fixing that now.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On Mon, Feb 11, 2013 at 02:04:17PM +0100, WanMil wrote:
Hi,
has the problem been solved or is there still something to explain? If the greater tolerance of mkgmap for mapping errors (ignore mp tags if name is set only) causes problems I think I should revert that.
+1, it will be an endless source of garbage-in/garbage-out. One thing that is always OK to do is to issue a warning for inconsistent tagging, such as when both the role=outer way and the multipolygon relation are carrying tags that the style files care about. (This should avoid generating unnecessary warnings for source=* and similar tags.) Some 'auto-correction' could be OK when issuing a warning, but not otherwise. Marko
Better revert it Wanmil, I still have problems rendering the country borders...
Hi, I've reverted it. I also fixed another thing I introduced by mistake. If the loader removes tags because they are not required it adds a special mkgmap: tag. This was ignored by r2478. Should be fixed now. Anyhow I think the example mp is also tagged wrong. It has a name tag only. So what is it? Why does it have a name tag? From my point of view it should have a kind of "maintenance" tag which denotes non map specific entries. WanMil
Better revert it Wanmil, I still have problems rendering the country borders...
Thanks Wanmil. I agree that this Bulgarian example shouldnt be on OSM in the first place ;-) But it was a good example that r2478 copied the tags from some members (international greek/bg border) to all the ways of this relation and I think that was not intended? I noticed also that the whole Slovenian border got maritime=yes tags so there was clearly something going wrong.
I've reverted it. I also fixed another thing I introduced by mistake. If the loader removes tags because they are not required it adds a special mkgmap: tag. This was ignored by r2478. Should be fixed now.
Anyhow I think the example mp is also tagged wrong. It has a name tag only. So what is it? Why does it have a name tag? From my point of view it should have a kind of "maintenance" tag which denotes non map specific entries.
WanMil
Thanks Wanmil. I agree that this Bulgarian example shouldnt be on OSM in the first place ;-) But it was a good example that r2478 copied the tags from some members (international greek/bg border) to all the ways of this relation and I think that was not intended? I noticed also that the whole Slovenian border got maritime=yes tags so there was clearly something going wrong.
Of course it was not intended :-) Can you please give a short feedback if the slovenian border is also ok now? Reverting was no problem for me because it was just a tolerant acceptance of a common tagging error. Maybe it is better not to support OSM errors at all but to trigger mappers to tag in a correct way. WanMil
participants (7)
-
Gerd Petermann -
GerdP
-
Marko Mäkelä -
Minko -
svn commit -
Thorsten Kukuk -
WanMil