[Tagging] Naming boundary ways

Frederik Ramm frederik at remote.org
Thu Oct 4 07:41:47 BST 2012


Hi,

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.

> Q1: which naming of border line piece do you consider valid and which do
> you prefer?
> Q1a: Municipality1 — Municipality2?
> Q1b: Highest-level1 — Highest-level2 (Europe — Asia)
> Q1c: Municipality1 — Municipality2 (Highest-level1 — Highest-level2) ?
> Q1d: nothing

Q1d, clearly.

> 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.

> 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.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"



More information about the Tagging mailing list