boundary relations in splitter
Hi all, the keep-complete processing in current splitter (r283) ignores all type=boundary rels, means, they are not added to the problem list. This is done to avoid adding thousends of ways to each tile because of administrative boundaries covering huge areas. (Boundary rels are treated like type=multipolygon rels, so splitter will calculate the bounding box of the rel and add the members to all tiles intersecting this bbox. The discussion in this thread http://gis.19327.n5.nabble.com/Commit-r2478-Use-outer-polygon-tags-if-the-mu... shows a need for more detailed filters. I see some options to handle this: 1) a) we can add type=boundary relations if they have a boundary=xyz tag and xyz is in a hard coded include list b) we can add type=boundary relations if they DON'T have a boundary=xyz tag and xyz is in a hard coded exclude list I looked at taginfo and found quite a lot of candidates for both lists: http://taginfo.openstreetmap.org/keys/boundary?filter=relations#values 2) we can pass the include / exclude lists as parameters (eg. --incl-boundary-filter=national-park,national-forest or --excl-boundary-filter=administrative,postal_code 3) we can add (parts of) the style system to splitter to allow the same filters My opinion: option 1) is too simple, option 3) is too complex (for me) On the other hand, we may also filter type=multipolygon rels , for example taginfo shows that type=multipolygon is often used with boundary=administrative. Comments? Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/boundary-relations-in-splitter-tp5749069.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Why is option 1 too simple? Most important is that it is effective and customizable. I would go for 1a, add an include list and I can add my own options, like national_park and protected_area. Maybe a good idea to exclude mp boundaries too.
Hi Minko, Minko-2 wrote
Why is option 1 too simple? Most important is that it is effective and customizable. I would go for 1a, add an include list and I can add my own options, like national_park and protected_area.
Maybe a good idea to exclude mp boundaries too.
Just to make sure: with hard coded I meant hard coded in java source, so you can't customize it without changing the source and compile the changes. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/boundary-relations-in-splitter-tp5749069p5749... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Ah ok, Then option two, to set your own include parameters would be nice. Or else option 1 with all administrative boundaries excluded. That would be >90% and maybe more if mp's and political bounds are excluded too.
Just to make sure: with hard coded I meant hard coded in java source, so you can't customize it without changing the source and compile the changes.
Gerd
Hi all, I've committed r285 in the problem-list branch: Changes compared to r283: the tag key "boundary" is checked against an exclude list {"administrative", "postal_code", "political"}. If a type=multipolygon rel also has the excluded boundary tag, it is no longer added to the list of problem relations. If a type=boundary rel doesn't have the excluded tag, it is now added to the list of problem relations. This is the simple solution 1b plus the mp filter. Gerd Minko-2 wrote
Ah ok, Then option two, to set your own include parameters would be nice. Or else option 1 with all administrative boundaries excluded. That would be >90% and maybe more if mp's and political bounds are excluded too.
Just to make sure: with hard coded I meant hard coded in java source, so you can't customize it without changing the source and compile the changes.
Gerd
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-relations-in-splitter-tp5749069p5749... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (2)
-
GerdP -
Minko