And in turn I think that tagging of both way and relations is an unwanted 
duplication
- I think that it is preferable to tag just relations.

23. Oct 2018 19:13 by [email protected] <mailto:[email protected]>:


> Hi, Nelson:
>
> The wiki says also that "Because boundaries can be rendered both from 
> relations and individual ways, tagging the ways is, in the strictest sense 
> optional.
>
> My opinion is that, being this an import, it would be better to include those 
> tags for the boundary ways, as that can be done easily by software (including 
> the admin_level tag).
>
> Cheers,
>
> Rafael.
>
> On 23/10/18 03:20, Nelson A. de Oliveira wrote:
>> On Mon, Oct 22, 2018 at 8:52 AM Rafael Avila Coya <>> [email protected] 
>> <mailto:[email protected]>>> > wrote:
>>> I've seen that border ways aren't tagged. At least they should have the
>>> following tags [1]:
>>>
>>> boundary=administrative
>>> admin_level="the highest (lowest number) level it shares"
>>>
>>> [1] >>> https://wiki.openstreetmap.org/wiki/Relation:boundary#Way_tags 
>>> <https://wiki.openstreetmap.org/wiki/Relation:boundary#Way_tags>
>>
>> This really doesn't seem to be necessary and it seems that it's based
>> on old behaviors/assumptions.
>>
>> It says that "Boundary relationships are useful for many tools, but
>> not necessary for rendering purposes, which is why boundary lines
>> should be tagged to allow for the renderer to use them again." but, at
>> least, the standard and humanitarian styles/renderers and OsmAnd can
>> fully understand (and render) administrative boundaries without any
>> tag on the ways.
>>
>> Most probably this part should be reviewed at the wiki.
>>
>
> _______________________________________________
> Imports mailing list
> [email protected] <mailto:[email protected]>
> https://lists.openstreetmap.org/listinfo/imports 
> <https://lists.openstreetmap.org/listinfo/imports>
_______________________________________________
Imports mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports

Reply via email to