Proposal talk:Markers subject refinement

Syntax

As I might have said before, subject=* can be a freeform text, as recorded in Proposed_features/Subject#Rationale. This means it can be used as eg subject=Nord Stream 2 + subject:wikidata=Q21644350 for individual subjects. So I should have suggested at least pipeline:subject=* if this is to be used for pre-defined.
Perhaps eg pipeline:object=* , following object:*=* from object:street=* etc. But I will emphasize I don't like "object" due to vagueness. --- Kovposch (talk) 22:27, 17 April 2023 (UTC)

The proposal is currently pretty confusing. It acknowledges that subject=* already exists and proceeds to propose an incompatible syntax for it. If the purpose of this key is to indicate what kind of infrastructure the marker indicates, how about marker:for=* or marker:marks=*? There is precedent for using a verb or preposition as a subkey in the absence of a more fitting noun. Alternatively, if the idea is that other things besides markers may need a similar key in the future, how about subject:type=*, by analogy with operator:type=*? – Minh Nguyễn ^💬 01:55, 18 April 2023 (UTC)

I did suggest marker:for=* at first in other discussions. Then starting thinking better suffixes for it.
I don't find subject:type=* enough to solve the same problem found in artwork_subject=*, museum=*, and memorial:subject=* for separating the specific entity and its categories.
--- Kovposch (talk) 04:35, 18 April 2023 (UTC)

That is very valid points thank you, we'll think about that to improve the proposed solution. By the way, :type suffix should be avoided, we'll find a more precise term for that if needed. Fanfouer (talk) 07:35, 18 April 2023 (UTC)

Two other options come to my mind: topic=* and purpose=* with same values as proposed now. topic=* is interesting to combine with subject=*: topic=pipeline + subject=Nord Stream 2. Fanfouer (talk) 15:05, 18 April 2023 (UTC)

"Topic" and "subject" might be too easy to mix up, since they translate to exactly the same word in some languages, but at least topic=* seems to be used for roughly this purpose already. In an ideal world, the more specific usage of subject=* would've been called referent=* instead, but we're far too late for that kind of change. Another option would be to accept that subject=* and subject:wikidata=* can be broad sometimes and specific sometimes, but this means you wouldn't be able to query for all pipeline markers without knowing that Nordstream 2 is a pipeline (using Wikidata, for example). – Minh Nguyễn ^💬 03:11, 23 April 2023 (UTC)

I agree here. However, I can't find any proper definition of referent on English dictionaries and finally, when solved, why can't we use referent=pipeline/cable/... on markers? Fanfouer (talk) 11:56, 24 April 2023 (UTC)

@Fanfouer: A "referent" is the specific thing that something refers to. Intuitively, a given sign or marker's referent would be more specific than its subject/topic. So while there's nothing technically stopping us from using referent=* for the subject, it would be semantically backwards. When giving the fields human-readable names in English or any other language, editor developers would have to decide whether to align the terms "subject" and "referent" with literal keys or plain English; either option would prove confusing for a different audience. – Minh Nguyễn ^💬 19:29, 25 April 2023 (UTC)

Thank you for clarification, it's clear now. On the other hand, even if referent=* would be semantically backward, being unable to refine subject=* definition due to its usage is a flaw as well. No perfect solution nor wording here, right? Fanfouer (talk) 17:32, 26 April 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ The proposed key has a lot in common with message=*: the marker is communicating a message that [insert value here] is nearby. Or perhaps marker:message=* if there's any concern about mixing the advertising message categories with the pipeline message categories. – Minh Nguyễn ^💬 06:45, 28 April 2023 (UTC)

Oh that one is very interesting, thank you. I wasn't aware about it. Well, I'll have a little more thinking about that while on weekend Fanfouer (talk) 22:23, 5 May 2023 (UTC)

Hello, I'm coming back on this proposal after a few weeks away. Even if message=* would be fine, what about... about=* as well? Fanfouer (talk) 19:36, 9 August 2023 (UTC)

I give a try to indication=* that has advantages to not be used yet and not being a verb. Fanfouer (talk) 23:20, 18 February 2025 (UTC)

Among OSM topics, I would think of road traffic or rail signals for "indication". But I can't think of better words immediately.
—— Kovposch (talk) 04:55, 19 February 2025 (UTC)

Indeed but isn't it already described with destination=*? Fanfouer (talk) 18:15, 19 February 2025 (UTC)

I noticed you mentioned indication:ref=* now. That would be handled by subject:ref=Road number perfectly in the sense of having subject=Road name for it. I think we really need to conceive how to categorize subject=* , as this issue occurs too often. https://community.openstreetmap.org/t/undiscussed-wiki-edits-by-the-user-rtfm-museum-open-air/125667
—— Kovposch (talk) 20:53, 27 February 2025 (UTC)

To give an argument for other use of message=* to facilitate consideration , first 2 examples could be message=safety , from the yellow triangle or diamond sign. Similar to hazard=* warnings. They seem different from Example 3.
—— Kovposch (talk) 21:10, 27 February 2025 (UTC)

@Fanfouer: Sorry for the delayed response. about=* has a certain elegance to it, but unfortunately I think it's also very easy to confuse with message=* or subject=*. Yeah, there's probably no perfect solution here. indication=* is interesting. I've only ever countered this word in highly specific technical contexts ("turn lane indication") or in medicine. Since it's such an obscure word, it could work, though I could imagine a newer mapper getting confused between indication=* and inscription=*, just as mappers are often confused between destination=*, designation=*, and denotation=*. – Minh Nguyễn ^💬 22:01, 27 February 2025 (UTC)

Thank you both for answers!

subject=* can't hold Road name as a value (inconsistent with documented values) and according previous discussion, subject=* is more indefinite than demonstrative and indication=* could be appropriate to hold demonstrative values.

I don't plan to ask message=* for review now, it would be too broad for current proposal which focuses on what the marker is about

No problem @Minh Nguyen:, No perfect solution but indication=* sounds more suitable here than about=*. Mappers will get hints and help from presets in editors and usual combinations, I'm not afraid by possible confusions Fanfouer (talk) 22:09, 27 February 2025 (UTC)

If you are looking at Key:subject#Common_values , it's not accurate, only reflecting a certain method in tourism=museum compared to museum=* etc. subject:wikidata=* has already been used to extend it to everything. subject=* is mostly proper nouns, man_made=flagpole especially. Also it has been used for ~15k marker=* + subject=pipeline in France, although that should be migrated.
—— Kovposch (talk) 05:20, 28 February 2025 (UTC)

I see you mentioned boundary=marker in latest. subject=* is suitable for country and subdivision names.
—— Kovposch (talk) 05:28, 28 February 2025 (UTC)

Well, usage in France wasn't legit and it should be moved yes. This proposal won't prevent people to use subject=* to refer to a particular road (or pipeline) if they want to, but consumers won't be up to look for any road name to find all roadmarkers, so we need something like indication=road on top of it. Fanfouer (talk) 11:35, 28 February 2025 (UTC)

Anther idea I thought about is indicating:*=* for indicating:man_made=pipeline , indicating:pipeline=valve , indicating:power=cable , indicating:emergency=fire_hydrant
—— Kovposch (talk) 06:37, 28 February 2025 (UTC)

That's interesting in the way it links the marker to existing OSM tagging without redefining it. I fear that would not be widely appreciated due to long key names it will encourage. Do we know other features than markers that could get benefit from that? Fanfouer (talk) 11:35, 28 February 2025 (UTC)

Fire hydrant

Resolved: indication=hydrant tells that the marker refers to a hydrant

I don't agree it is utility=water simply because they use water, as I have been questioning the content vs activity differentiation. What is the utility=* of foam hydrants, or {a {tag|marker}} for gaseous fire suppressant equipment??? They are emergency=* features, and not very related to utility=* as a whole. --- Kovposch (talk) 22:27, 17 April 2023 (UTC)

I understand, hydrants are sourced by the municipal water supply, which is operated by a utility company. This Deprecate utility=hydrant in favour of utility=water + subject=hydrant seems overreaching though. Not sure, hydrants are candidates for emergency, as they are of no us to lay persons, instead trained fire brigades. But why subject? --Hungerburg (talk) 23:38, 17 April 2023 (UTC)

It's not hydrants that get utility=* currently, only the markers. And in several countries, these markers are regulated in regard of main water connection (and display information about those mains), then utility=water sounds legit. Markers nor hydrant are forced to get utility=*, then foam or dry fire outlets won't be covered obviously.

subject=* (or whatever proposed) is dedicated to markers, not hydrants themselves. subject=hydrant tell people this marker refers to a near hydrant, that's all. Fanfouer (talk) 07:33, 18 April 2023 (UTC)

What qualifies as utilities

Another changed I noticed you didn't describe well is replacing utility=hydrant with utility=water + *=hydrant without much explanation. Yesterday, Australia discussed utility=power for backup electricity to street_cabinet=traffic_control in Australian_Tagging_Guidelines/Utilities_and_infrastructure#Traffic_Signal_Controllers currently. It repeats an issue I discussed Proposal_talk:Utility_facilities#deprecate_old_street_cabinet_values previously. Talk:Key:utility#Traffic_signals
Currently there are 31 nwr["utility"="hydrant"][!marker][emergency!=fire_hydrant]; , including man_made=street_cabinet , man_made=utility_pole (don't know what it looks), man_made=pumping_station (could be moved to eg pumping_station=hydrant instead or alongside), man_made=storage_tank , and pipeline=valve , ignoring those untagged. They won't be replaceable by indication=hydrant or equivalent.
—— Kovposch (talk) 21:00, 27 February 2025 (UTC)

utility=* follows United Nations ISIC classification for utilities activities and hydrants (nor traffic signals) are not part of it.

31 occurrences of utility=hydrant you mention are likely bogus and may be moved towards emergency=*. pumping_station=* is currently discussed to be discouraged in favour of utility=* (at least most values of it). Note that a mass edit isn't proposed and replacement of utility=hydrant will be done with manual review of each occurrence. Fanfouer (talk) 22:45, 27 February 2025 (UTC)

But where in ISIC are you referring to exactly? Strictly speaking, it seems only the construction of them is defined. The activities themselves are scattered in different sections, not directly mentioned as utilities.
F-4220 won't include utility=street_lighting , which seemed squeezed into utility=* from street_cabinet=street_lighting . It's what I disagree the most, while you could say it's related to electricity.
Technically D-35 only include utility=gas fuel supply, not utility=chemical . Nor even usage=transmission , which falls into H-4930. Rigorously, utility=oil neither, as utilities refer to gas supply only.
In any case, I see that a separate proposal can be used to tidy up the utility=* list, including the deprecation of utility=highway and utility=traffic_signals mentioned here and recently. It can be then handle auxiliary equipment, and mismatch between the equipment and utilities (eg water for electricity generation and cooling example mentioned in the past). So utility=hydrant can be deprecated later there.
—— Kovposch (talk) 06:08, 28 February 2025 (UTC)

Sections D and E are explicitly described as utilities (electric and gas utilities, water and sewerage utilities). utility=street_lighting was distinguished from public electricity distribution since it relies on dedicated and wide infrastructures in most streets and looks more like a public network infrastructure than a punctual furniture or device (which traffic lights or hydrants are). By the way, why do you assume that F-4220 won't include street lighting?

Why not refining utility=* values afterwards, yes. However it's not possible to introduce indication=hydrant here prior of utility=hydrant removal, nothing more. Fanfouer (talk) 11:08, 28 February 2025 (UTC)