[Tagging] Naming boundary ways

[David ``Smith'']

On Oct 4, 2012 2:46 AM, "Frederik Ramm" <frederik at remote.org> wrote:
> On 10/04/12 03:17, A.Pirard.Papou wrote:
>> 1) While the A name= of the relation is the name of the area, such as
>> London or Wales, the possible B name has nothing to do with the area.
>> The B name can be that of a river, of a road, or the border piece can be
>> immaterial or chosen not to be represent the physical way.
>> If the border line is immaterial, the name, if any, can be chosen
>> perfectly arbitrarily and serves only to identify the border line at
>> best when you look at configuration data or on the map.
>
> In these cases I tend to omit the name tag altogether. After all, the
immaterial line doesn't really have a name; what you are talking about is
more of an "annotation", a "note", a "description" or somesuch.
>> Q1d: nothing
> Q1d, clearly.

+1
(Unless of course the way also represents a physical map feature with its
own name)

>> 2) The admin_level itself is redundant in ways. It is in fact contained
>> in the boundary relations, and as it possibly has multiple values if the
>> border is for several area levels.
> The consensus is to use the highest of all applicable admin levels. You
are right in saying that it is redundant (as is the boundary=administrative
tag, btw.) but it does make things easier for those users who simply want
to draw a line on their map - they don't have to evaluate the, possibly
broken, polygons for that.

+1

>> 3) One can make routes of routes, that is, relations of relations.
>> Or, at least, routes of hiking routes.  It seems that the recursion
>> support  is an application matter.
>> And we're ruled by chickens and eggs.
>> Hiking software has implemented recursion, then hiking routes, then more
>> software.
>> How extended is the recursion support of routes?
>> Could it be used for boundaries?
>
>
> You mean like this
>
> http://www.openstreetmap.org/browse/relation/1111111
>
> or this
>
> http://www.openstreetmap.org/browse/relation/11980
>
> As you can see, cascading relations are already in use for boundaries,
it's just that nobody is really sure how to do it right ;)
>
> My position has always been that there should be generic cascading for
relations in any linear context, i.e. if you expect a way but get a
relation then you will automatically use all ways in that relation and
treat them as one long line. That would work for situations like the first
example but not for the second where individual sub-regions have been
collected into a larger whole - which also makes sense.

I don't think it's right to say that relations in general should behave a
certain way.  (And we really need to kill the idea that ways automatically
inherit tags from any parent relations...)  Specific relation types, on the
other hand, are a different matter.  "Collected Way" relations
(type=collection) actually do have the property that member ways are meant
to inherit the relation's tags.  A collected way relation should be a valid
substitute for a way in multipolygon or boundary relations.  Multipolygon
relations represent features distinct from their member ways, and no tag
inheritance should be assumed (except for backwards compatibility in
limited, simple cases where the "outer" way has the tags that really belong
in the relation...).  Boundary relations (which may be type=boundary or
type=multipolygon) may contain subarea relations as a kind of metadata, but
the ways (or collected-way relations) of the boundary itself should still
be members of the boundary relation; don't expect data consumers to derive
a country's boundary geometry by taking a union of all the political
subdivisions.  This may seem to introduce redundancy and possibilities of
inconsistency, such as part of an admin area not being part of any of its
subareas; but I think this is acceptable, in case that's actual truth, or
simply to allow the map to exist in an incomplete state without being
wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20121006/49ca9677/attachment.html>