logo separator

[mkgmap-dev] [PATCH v1] Handling of boundary multipolygons

From Felix Hartmann extremecarver at googlemail.com on Sun Apr 18 21:10:03 BST 2010


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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>    



More information about the mkgmap-dev mailing list