Proposal talk:Boundary markers proposal
Key name
I am not sure that marking is a good choice. An alternative that came up in a previous discussion is subject. --Lkw (talk) 05:40, 7 September 2022 (UTC)
- To elaborate, there are multiple different attributes using "marking" with different forms. Spelling singular and plural can be confusing, although they can be interpreted as being a noun vs gerund here.
- lane_markings=*
- crossing:markings=*
- cycleway:*:marking=* corresponding to cycleway:*:separation=*
- road_marking=*
- Worse, marking:*=* is proposed to be used in marking=* as top-level feature attribute, corresponding to separation:*=*. (Is it further possible to have a marker marking different things on both sides?)
Markers may be compared to signs. In traffic_sign=* and perhaps tourism=information or advertising=*, the info signposted is currently being directly tagged the same, unlike eg destination:*=* being prefixed. New namespacing needs some more consideration.
--- Kovposch (talk) 05:58, 18 September 2022 (UTC) - This collision with street markings is a problem. "indicating" seems a to be a better option and I cannot think of similar collisions when using this term. --Lkw (talk) 14:20, 19 September 2022 (UTC)
Inscription
Maybe inscription should be used for the things written on the marker that are not the ref of the marker --Lkw (talk) 05:40, 7 September 2022 (UTC)
Address marking globally
In recent discussion about other topics, we thought about subject=* to describe which feature the marker indicates without impersonate it. Should we propose a complete set of values for proposed marking=* including pipeline, minestone, cable and so on? Fanfouer (talk) 07:47, 7 September 2022 (UTC)
I don't really like marking=* because it's a verb and most tags are nouns. I was unsure about subject=* because I associate it with school subjects or content of texts (like science or history) but I am not a native speaker so my feeling might mislead me. Extending the scope is a good idea because it leads to consistent tagging. A distinction between utility=* and subject=*/marking=* is needed. Something like subject=pipeline for the kind of infrastructure and utility=heating for the purpose. --Lkw (talk) 08:24, 7 September 2022 (UTC)
- Not a native speaker her neither, but marking is not a verb, it is a gerund. --Hungerburg (talk) 21:40, 7 September 2022 (UTC)
- I would rather choose to "address subject globally". Currently museum*=* and artwork*=* etc have the same issue in separating the general category from the specific identity the entity is.
subject=* should be a freeform text for the name, as this is the most common usage contrary to Key:subject documentation (cf Proposed features/Subject). This should be adopted, rather than adding a subject:name=*. In contrast, the the category should be separately tagged.
artwork:subject=* was proposed to be used differently from the pre-existing artwork_subject=*, However I doubt this is scalable (from marker_subject=* to a *_subject=* for everything) , clear enough, or error-proof. Another possibility is subject:for=*. Although *:for=* is popularized for the user group (viz social_facility:for=*, there doesn't seem to be any conflict here. This avoids introducing new *:ref=*, *:name=*, etc by marking:*=*. Then you can add any needed attribute under subject:*=*.
Example: subject:for=pipeline + subject=Nordstream 2 + subject:wikidata=Q21644350 + subject:ref=NS2 (hypothetical)
--- Kovposch (talk) 09:02, 7 September 2022 (UTC)
- After reading Proposed features/Subject I don't have the impression that this should be solved with the same key as the marker issue because the markers always mark something specific that is nearby. But for artworks it is the theme that can be a historic event (World war 2), person or abstract concept. Therefore I suggest that subject should not be used for the markers to avoid a clash of keys with the subject for artworks.
- Instead marker:for=* or marker:of=* could be a solution. And then replace marking:ref=* by marker:for:ref=* etc.
--Lkw (talk) 13:47, 7 September 2022 (UTC)
proposal for an already approved tad
you sad "It is proposed to use marker=* key to map boundary markers according to their shape" but it's already the case, marker tag is approved with this meaning. it could be a good idea to improve the sentence so as not to give the impression of proposing what is already approved Marc marc (talk) 08:01, 7 September 2022 (UTC)
Resolved: I have changed it--Lkw (talk) 10:27, 7 September 2022 (UTC)
marker=* + boundary=* is not wrong
I don't see marker=* + boundary=* as a wrong combination.
--- Kovposch (talk) 09:02, 7 September 2022 (UTC)
- So do I. Nevertheless, I see the need for a "glue" key, e.g. by an identity: where the value of the tag is the name of the key of another tag, that gives further details on the subject. Such that consumers can link/chain the discovery of attributes, providing detail. I just improvised "marking" for that, but it may be a different one instead. No strong opinions on naming of the key, yet, discovery by identity is a well know practice. --Hungerburg (talk) 21:50, 7 September 2022 (UTC)
Do you mean marker=* + boundary=marker or marker=* + boundary=administrative etc? Allowing both does not work on the same object. --Lkw (talk) 05:29, 8 September 2022 (UTC)
- I am fairly positive, that
Kovposch (on osm, edits, contrib, heatmap, chngset com.) meant boundary=* as to the asterisk in place of administrative, protected_area, forest_compartment etc. See below, why jumps might not be so evil after all. Perhaps, even no matter the number of them, as long as there exist a glue key whose value hits somewhere. (In order to make the jump comprehensible for humans (and software too.)) [It was Kovposch, who made me aware of the paving_stones example in another talk page.] --Hungerburg (talk) 01:20, 10 September 2022 (UTC)
- Fairly simple to me: A marker isn't a boundary, just like a river or a road aren't neither. Let's keep keys consistent with their definition. That would lead to deprecate boundary=marker as well, since it's inconsistent with boundary=administrative or boundary=hazard. Fanfouer (talk) 23:37, 11 September 2022 (UTC)
- The actual border indicated by type=boundary, not boundary=*. It's only a common practice to add boundary=* on lines forming one. Some consider this bad. Kovposch (talk) 06:03, 12 September 2022 (UTC)
- Fairly simple to me: A marker isn't a boundary, just like a river or a road aren't neither. Let's keep keys consistent with their definition. That would lead to deprecate boundary=marker as well, since it's inconsistent with boundary=administrative or boundary=hazard. Fanfouer (talk) 23:37, 11 September 2022 (UTC)
Namespacing, a.k.a. discovery of properties
Imagine a marker. It has some physical properties. They go into the marker=*, material=*, colour=* tags. It has some other properties, they go into the operator=*, ref=* tags. Last but not least, a marker also marks something, a boundary, a utility, a pipeline, etc. So how to tag the properties of the entities marked, that are not properties of the marker itself? In a way, that its easy to decide, which tag carries a property of the marker, and which tag carries a property of the other entity?
Imagine a road: highway=residential; surface=paving_stones; paving_stones:pattern=square; paving_stones:*=*.
Following that scheme, I'd get: marker=plate; marking=boundary; boundary=administrative; boundary:admin_level=9.
Both "surface" and "marking" keys act like a namespace unaware glue, an operator, that imports the properties of the other entity into the set of the base entity (highway, respectively marker).
The proposal as of today treats the "marking" key differently. I think it is wrong, to use marking as a placeholder for the marked thing. That would be like tagging surface=paving_stones; surface:pattern=square. If you want to do namespacing, it should spell out surface:paving_stones:pattern=square instead. For markers then that should result in: marking=boundary; marking:boundary=administrative; marking:boundary:admin_level=9.
While the no-namespace version might be amenable to automated discovery of properties, the namespaced version certainly makes such easier. --Hungerburg (talk) 09:32, 8 September 2022 (UTC)
- I wanted to avoid boundary=* because of this post: https://community.openstreetmap.org/t/how-to-tag-markers-of-forest-compartments/2322/13 (boundary=* only for ways) Do you know if all similar schemes use the same pattern as surface?
- marking=boundary; marking:boundary=administrative; marking:boundary:admin_level=9 would achieve that. Other opinions? --Lkw (talk) 12:36, 8 September 2022 (UTC)
- So I read the forum post and the proposal linked from there: As far as I understand, "utility" there does exactly what "marking" does here. @Fanfouer: I consider that a very poorly chosen term, because utility is for power, gas, etc. According to this, you'd have to tag: marker=plate; utility=boundary; marker:utility:boundary=forest_compartment to get a truly nice parse tree. --Hungerburg (talk) 17:54, 8 September 2022 (UTC)
- utility is not a bad term because it describes what it is intended for: the utility of the thing eg heating. The discussion in https://lists.openstreetmap.org/pipermail/tagging/2022-August/065146.html is about the problem that you cannot use utility if you want to tag that it is a marker of a pipeline because a pipeline can be used for fresh water, heating water, oil, gas etc.
- @Fanfouer:'s suggestion was to extend this proposal so that marking=* can be used for all kinds of markers and should contain the kind of thing that is marked (a boundary, a pipeline, a cable...). utility=* can then be used in addition to describe the usage of the pipeline or cable (heating, gas, oil... for a pipeline, telecommunication, power... for a cable). It is not identical to marking=*. utility makes no sense for a boundary. --Lkw (talk) 19:04, 8 September 2022 (UTC)
- Sorry for the noise, I just misread the sentence "utility=* to state at which activity they refer to". From the explanation here. I conclude, that utility does not refer to the thing, that the marker marks, but the use of the thing that the marker marks. I see a shortcut there too, otherwise a marker with "uitility=heating" would have to be "material=wood"? Seen like this, there still remains a gap in tagging, a key to map, what the marker actually marks. --Hungerburg (talk) 10:33, 9 September 2022 (UTC)
- Yes to have it really consistent it will be necessary to add namespacing to utility=* because it is a property of the marked thing. --Lkw (talk) 12:42, 9 September 2022 (UTC)
- The single most compelling reason for namespacing, in programming languages and properties tagging schemes alike, is that it helps avoiding naming collisions: The ref of the marker can be clearly distinguished from the ref of the boundary/pipeline/etc. I might be overly optimistic, but jumping the first redirection could be workable. marker=plate; ref=123; marking=boundary; boundary:ref=456 works just as well as marker:marking:boundary:ref. For boundaries and pipelines at least. No idea for utility, because it would be: marking=pipeline; pipeline:utility=heating. Humans will get it, but can this be automated to short-circuit utility=heating into the private namespace of marker? Mind you, there are two jumps now. If so, why bother with namespacing at all? --Hungerburg (talk) 01:04, 10 September 2022 (UTC)
- Yes to have it really consistent it will be necessary to add namespacing to utility=* because it is a property of the marked thing. --Lkw (talk) 12:42, 9 September 2022 (UTC)
- Sorry for the noise, I just misread the sentence "utility=* to state at which activity they refer to". From the explanation here. I conclude, that utility does not refer to the thing, that the marker marks, but the use of the thing that the marker marks. I see a shortcut there too, otherwise a marker with "uitility=heating" would have to be "material=wood"? Seen like this, there still remains a gap in tagging, a key to map, what the marker actually marks. --Hungerburg (talk) 10:33, 9 September 2022 (UTC)
Namespacing options overview
How namespacing will be done is not decided yet. An overview of the options to facilitate the discussion:
A
| Photo | Location | Tagging | Note |
|---|---|---|---|
 |
Germany |  marker=platemarking=boundary boundary=forest_compartment ref=123 name=Schützenacker operator=Stadtwald Gießen |
A plate marking the boundary of forest compartment. |
Pro:
- easy to map
- just render ref or name and it becomes useful for orienteering
Con:
- if the marker has its own ref (which is common for utility markers see overpass turbo) there is a conflict.
- Conversely you could use marker:ref=*? --- Kovposch (talk) 05:57, 12 September 2022 (UTC)
B
| Photo | Location | Tagging | Note |
|---|---|---|---|
|
Germany | marker=plate marking=boundary marking:boundary=forest_compartment marking:ref=123 marking:name=Schützenacker operator=Stadtwald Gießen |
A plate marking the boundary of forest compartment. |
Pro:
- Avoids conflicts
Con:
- Inconsistent use of key "marking": 1) as a property of the marker, 2) as a substitute for the marked entity.
C
| Photo | Location | Tagging | Note |
|---|---|---|---|
|
Germany | marker=plate marking=boundary boundary=forest_compartment boundary:ref=123 boundary:name=Schützenacker operator=Stadtwald Gießen |
A plate marking the boundary of forest compartment. |
Pro:
- distinguishes properties of the marker and properties of the boundary (or infrastructure)
- same pattern as e.g. some surface tags
Con:
- Use of a key (e.g. boundary), that can be mistaken as being the mapped entity. How to make certain, that the node is for the marker? (For humans easy on boundaries and piplines.)
- If a marker is very large, mappers might map the marker as area. -> A data user not checking marker=* will mistake it a for a real (albeit tiny) boundary. Maybe this is overthinking but micromapping is increasing.
- I prefer A, then C, or B + C marking:boundary=* + boundary:*=*. I don't find marking:*=* useful to introduce yet. That's what I dislike more. --- Kovposch (talk) 05:55, 12 September 2022 (UTC)
D
| Photo | Location | Tagging | Note |
|---|---|---|---|
|
Germany | marker=plate marking=boundary marking:boundary=forest_compartment marking:boundary:ref=123 marking:boundary:name=Schützenacker operator=Stadtwald Gießen |
A plate marking the boundary of forest compartment. |
Pro:
- Avoids boundary= on nodes
Con:
- very long keys
Consistency in Tagging schemes
I agree with your assessment that boundary=marker is suboptimal tagging an does not comply with the tagging scheme of other kinds of markers. Anyhow I do not believe that creating a new key "marking" to interlink the tag "marker=*" with the markers subject = boundary is a very good idea as again this would not comply with the tagging scheme of other markers.
Actually there are 2 tagging schemes for markers, one for traffic ways and one for utilities.
Traffic ways: highway/railway/waterway=milestone + marker=plate/stone/post (the tagging of historic=milestone and historic=boundary_stone fits in here)
Utilities: marker=* + utility=* (Note there is no interlinking tag in between marker and utility)
Following the traffic ways scheme the tagging for boundary markers could be: boundary=boundary_stone + marker=plate/stone/post etc. + boundary_stone=forest_compartment (note that boundary_stone is an existing value already and used with historic=*)
Following the utilities scheme the tagging for boundary markers could be: marker=* + boundary=forest_compartment (apparently no interlinking tag necessary)
Moreover the name (here: Schützenacker) is a property of the forest_compartment and should not be added to the marker (as it is neither the name of the marker nor the boundary).
(Frage: wie fügt man seinen Username am Ende eines Beitrages ein? Hier: Map_Hero 22:10 17 September 2022) Vier Tilden: https://de.wikipedia.org/wiki/Hilfe:Signatur --Lkw (talk) 11:50, 18 September 2022 (UTC)
- "boundary=boundary_stone + marker=plate/stone/post etc. + boundary_stone=forest_compartment" is not suitable because using boundary_stone for things that are not stones is confusing. (boundary=marker has been introduced because many markers are not stones) --Lkw (talk) 14:32, 19 September 2022 (UTC)
- When "milestone" works for mileage markers of all kind why should "boundary_stone" not work for boundary markers of all kind? Both milestone and boundary stone are common terms and have generally been made of stone in historic times whereas these days normally other materials are in use, for milestones as well as for boundary stones. Map HeRo (talk) 20:01, 25 September 2022 (UTC)