On 18.04.2010 21:35, WanMil wrote:
Hi Felix, yes that's exactly what the patch does and should do. Up to now the boundary information is available at many different places. For some boundaries the tags are in the relation. For some the tags are in the relation and some lines are additionally (and iconsistently) tagged with the boundary information. Other relations are not tagged and get their tags from the outer ways. And in all situations some ways contain other tags like highway=residential and so on. From my point of view the situation is quite chaotic.
The patch standardizes the above situation in the way that for each boundary a line is created with the boundary tags and these tags are removed from the source lines. So in the end I get distinct lines for each boundary. As you have observed this results in overlapping lines if you have multiple boundaries (which is usual).
So far so good. That's a good base to discuss what is really needed by you and other style implementors. My knowledge of the style system is quite basic so I don't know what's useful. But I am quite sure that's not the chaotic situation described above.
WanMil
I have one other idea that might be useful:
If the relations are more useful for style writers than the line information the specialized multipolygon code could ensure that the boundary tagging is always and completely in the relation. Boundary information from the lines would be removed.
Example: Relation 1: mp: type=multipolyon, boundary=administrative way 1: role=outer, boundary=administrative, admin_level=4, name=ABC region, ... way 2: role=outer, boundary=administrative, admin_level=4, highway=residential, name=ABC region way 3: role=inner, boundary=administrative, admin_level=4, name=ABC region, ...
After processing: mp: type=multipolyon, boundary=administrative, admin_level=4, name=ABC region way 1: ... way 2: highway=residential way 3: ...
Relation 2: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: role=outer, boundary=administrative, admin_level=5, ... way 2: role=outer, boundary=administrative, admin_level=5, highway=residential, name=Weaverstreet way 3: boundary=administrative, ...
After processing: mp: type=multipolygon, boundary=administrative, admin_level=5, name=Other region way 1: ... way 2: highway=residential, name=Weaverstreet way 3: ...
So with other words: Style implementors can alway rely on the relation information and need not to filter out boundary information from the lines.
WanMil
Well IMHO the best would be to have a) the possibility to directly create (routable) lines from the relations style-file file. b) the possibility to have the relations being added to the lines - so you can choose i.e. to only display boundary=administrative & admin_level=4 if boundary=adminstrative & admin_level=2 does not exist. One can do this currently really nicely by not applying directly from the relations file, but by using boundary=administrative & admin_level=4 {set adminboundary4=exist; set adminboundary4name={$name};.......} Then inside the lines file one can put rules like adminboundary2!=exist & adminboundary4=exist {set boundary=administrative; set admin_level=4; set name={$adminboundary4name} } adminboundary2!=exist & adminboundary4!=exist & adminboundary5=exist {set boundary=administrative; set admin_level=5; set name={$adminboundary5name} } ..... What is missing here is that if there are several relations of type admin_level=4 on the same way and you want all of them. Then you will only have one. Therefore for things were one would like to have all displayed (e.g. route=bicycle & network=ncn) - one directly includes them into the map from the relations file. Therefore I propose to use, instead of your patch, the patch by Thilo, and (if consensus) change the relations file in the default style to directly write boundaries from the relations file, and not from the lines file. What I don't understand is why you want to filter out boundary information from the lines, that what we have the rules section for and the continue/continue_with_actions command. So I don't see any benefit in your other idea over implementing the patch by Thilo into the main trunk.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev