|
Hello, Please do not only reply technically (once), please state your preferences (sort of poll). This is how, traditionally, municipalities, provinces, ..., countries, continents are traced. A: The land area is a polygon relation assembling the border pieces, with following tags: type=boundary admin_level=8, or 7, or ... for municipality, or province, or ... name=* (e.g. town or country) ... others describing the area, such as postal code, ... B: This is how a boundary way (border line piece) is tagged: boundary=administrative admin_level=8, or 7, or ... name=? plus possible non-boundary data indicating material object such as waterway=* 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. It seems that the best identification is the pair of names of the smallest area on each side: municipality1 — municipality2. A hint of that appears clearly when you watch or make a 3-border point and notice that the border names are M1-M2, M2-M3 and M3-M1, anything else is an error. Some persons say that this naming must follow the same rule (below) as admin-level : "highest level wins". The question is then: how many municipality boundary pieces must be named Europe — Asia and is that name a good identification? However, knowing that the boundary piece is of a high level may be considered important. In that case, M1 - M2 (Europe — Asia) is an option too. (...) is optional. 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 Q1e: you're inventive... 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. Hence, that number not only seems unnecessary but also meaningless. I wonder how long that "FIXME level must not be 4" has been on the English border (and why it doesn't say what it should be, instead). Q2: do you see any use for that apparently useless number? Could it be omitted? 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? In the example below, the long series of many Liège - Verviers pieces could be a single route made of M1-M2, M2-M3, M3-M4 ... municipality pieces and itself be called Liège - Verviers, which in turn would participate in the now 4 parts of boundary Liège, all that like матрёшки. And the border Europe - Asia would be made of a reasonable number of countries C1-C2, C2-C3, C3-C4, ... instead of an incalculable number of municipalities. Q3a: can boundary recursion be made? Q3b: else, would you like it to be done? Q3c: do you prefer eggs or chicken? Best regards,
Real examples: Q1a: a border around a municipality. All pieces identified by municipalities. Q1b: same when 2 pieces belong to higher level border Liège-Verviers. 2 pieces clearly identified only by number. The higher level boundary for Liège sharing 2 pieces with the above. The only clearly identifiable piece, Saint-Georges-sur-Meuse — Flémalle, is a mistake. Q1c: same municipality, showing both information. Q1d: part of the English border:
|
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
