Proposal talk:Utility markers proposal

Is it really a marker?

Resolved: That's not a proper marker and it have been removed Fanfouer (talk) 08:01, 16 July 2019 (UTC)

The "casing vent marker" doesn't look like a marker to me. As far as I know, pipes of that sort are part of the pipeline, providing ventilation, pressure relief, or similar functions. It should probably be tagged as "pipeline=vent" or something of that nature. --Carnildo (talk) 05:47, 15 July 2019 (UTC)

That's right and thank you for pointing this out. I've removed the item and it will need a proposal about piping accessories. Fanfouer (talk) 08:01, 16 July 2019 (UTC)

Recommended related tags

Resolved: Material became optional Fanfouer (talk) 16:03, 22 July 2019 (UTC)

Currently, both support and material are recommended. For me, support is much more important than material for rendering. I would render markers on poles on a hiking map, since they provide a landmark, a reference point. Markers on the ground are useless for that purpose. So I would say support is as good as mandatory, since for hiking maps I am more interested in the pole than the marker. The material of the pole is not really relevant to me. Sjoerder (talk) 08:29, 22 July 2019 (UTC)

Hi and thank you. It's true that material=* could be optional. The proposal has been updated accordingly Fanfouer (talk) 16:03, 22 July 2019 (UTC)

Pipelines in Belgium

Resolved: Impoved examples with Belgian situations thanks to M!dgard Fanfouer (talk) 22:46, 7 August 2019 (UTC)

@Fanfouer:: a few months ago I started documenting pipeline markers in my area at User:M!dgard/Pipelines in Belgium, you might find that interesting. —M!dgard [ talk ] 12:07, 29 July 2019 (UTC)

This is really valuable and will surely help to have more worldwide examples instead of lot of French situations. I'll pick up some pictures of yours to complete proposal shortly. Thank you Fanfouer (talk) 22:24, 2 August 2019 (UTC)

cover : 2 meaning

Resolved: Will be handled in a further proposal with kind of frame=* Fanfouer (talk) 14:51, 31 August 2019 (UTC)

cover seem to have 2 meaning https://wiki.openstreetmap.org/wiki/Key:cover https://wiki.openstreetmap.org/wiki/Proposed_features/Key:cover the meaning related to marker is the most used https://taginfo.openstreetmap.org/keys/cover#values Marc marc (talk) 10:07, 5 August 2019 (UTC)

There is a redirection from the first link to the second link, what is the second meaning?

Despite the pipeline marker usage is the most important in database,i'm not so happy to call it a roof nor a proper cover. It's more about its shape, structure or even its design (useful for render) Fanfouer (talk) 12:08, 6 August 2019 (UTC)

I plan to move cover=roof to frame=aerial because those markers are intended for aerial monitoring of underground pipelines

This is not a question specific to underground markers but to traffic signs also: they have different shapes for different purposes and often holds on a support as to be seen by people standing next to them Fanfouer (talk) 14:39, 31 August 2019 (UTC)

Well, this could fill a dedicated proposal as to mutualise utility markers and traffic signs. Fanfouer (talk) 14:51, 31 August 2019 (UTC)

Oppose deprecating pipeline=marker and marker=stone

Resolved: Proposal has been reworked and now includes used marker=stone. pipeline=marker is still proposed for deprecation Fanfouer (talk) 21:34, 19 September 2019 (UTC)

This proposal is quite long and complicated-looking. I believe it would be better to clarify exactly what tags are new: for example, "support", "material" etc are existing tags, not new tags.

I I've added to proposal chapter a sentence that makes it clear.

Nevertheless, I would like to understand what makes this proposal complicated-looking while I took time to add a a list of impacted pages and keys to replace. I see no elements that would imply that support or material are new Fanfouer (talk) 18:34, 6 September 2019 (UTC)

Don't mention unrelated tags in the main part of the proposal, for example here: https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal#Tagging there's "marker" but also "support", "material", "location", "ref", "operator", "colour" - none of those tags are part of the proposal, so they don't need to be mentioned. Note that I did not vote or comment on a couple of your recent proposals because I found them difficult to understand as a non-expert on the topic. It's better to keep the proposal simple. Additional tags that would be added to the new wiki pages do not need to be mentioned if they are already "de facto" or "approved". --Jeisenbe (talk) 00:14, 7 September 2019 (UTC)

How can I mention the proposed marker=* will be used in combination with existing tags then? The point isn't to make them approved but to list the values they can have in this context. Outside of the proposal, such changes can be rejected on behalf of the lack of reviewing and vote. Fanfouer (talk) 13:13, 8 September 2019 (UTC)

But there are 2 tags that are being deprecated: pipeline=marker and marker=stone. I don't see the benefit in moving the first from the pipeline=* key, where it's really clear that "this is a marker for a pipeline" to a new marker key, where the values will be mixed between power, communications, pipeline and fire hydrand features (and possibly others in the future).

As explained in rationale, pipeline=marker may imply that the marker is involved in pipelines operations (like a pipeline=valve for instance) while such marker aren't even part of the pipe. As marker is also a commonn concept, not restricted to pipelines, I find interesting to define its own key marker=*. Note that the sentence "This marker refers to a pipeline" gets a better semantic translation with marker=pipeline than pipeline=marker. Fanfouer (talk) 18:34, 6 September 2019 (UTC)

I also think that it's not reasonable to deprecate marker=stone without clearly discussing what tag is supposed to replace it. The current proposal page mentions marker=miletsone as an alternative, but it's not clear if that tag would be considered "approved" if this proposal is voted "yes". According to taginfo, almost all uses of marker=stone are combined with boundary=marker, so these are boundary marker stones, "a robust physical marker that identifies the start of a land boundary or the change in a boundary, especially a change in direction of a boundary." These are not milestones, which would be tagged historic=milestone. --Jeisenbe (talk) 07:02, 6 September 2019 (UTC)

The proposal doesn't deprecates marker=stone. It just states that what is proposed is inconsistent with current usage. It shows a solution of what could be done in the future, but there is no point to make marker=milestone approved after this vote. Let's take this occasion to discuss about instead.

Strong problem: despite 6k uses, there is no documentation for marker=* values.

Please remove the line "mappers could be encouraged to carefully move to marker=milestone + support=pedestal + material=stone instead." - this seems to be part of the proposal. Don't mention new tags that are not part of the proposal on the actual proposal page, especially in this case since marker=* isn't usually related to milestones. (A better replacement would be historic=boundary_stone in some cases, though that doesn't work for non-historic boundary markers, or just material=stone, but if you look at the page boundary=marker it's clear that the mappers who added this tag did not like using historic=boundary_stone for modern boundary markers.) --Jeisenbe (talk) 00:14, 7 September 2019 (UTC)

Discussion shows that marker=stone should be consistent with newly proposed values. I'll do it when rewoking the whole document. Nevertheless I think it conflicts a lot with marker=* + material=stone, whatever the purpose of such markers can be. Fanfouer (talk) 13:13, 8 September 2019 (UTC)

Should colour=* be recommended?

Resolved: Colour is optional but utility=* is recommended as a marker always regards a given utility but don't always have a colour Fanfouer (talk) 21:32, 19 September 2019 (UTC)

https://wiki.openstreetmap.org/wiki/Key:colour says that the key colour was originally intended for the "official colour" of things like public transit routes, not to describe the color of a physical object. I don't see much use in using colour=* for a marker which will often have more than one color, as shown in some of the examples. Since this tag isn't actually part of the proposal, I'd remove this. --Jeisenbe (talk) 00:30, 7 September 2019 (UTC)

The colour page also states than it is often used to reflect the colour of a physical object like amenity=bench. Currently, colour is part of optional tagging for power=tower. Again, the point made here is to use colour in association with markers to document the dominent colour, not to change its signification or make it more approved than it already is. Fanfouer (talk) 13:26, 8 September 2019 (UTC)

How about man_made=marker as top-level tag?

The proposal as-is seems reasonable to me, but it seems to lack a top-level or physical tag. marker=* is sufficient for identifying the object, but man_made=marker makes it seem "more complete" in my opinion. Also, it helps because in some cases it's not clear what the marker is for. Mueschel (talk) 17:00, 8 September 2019 (UTC)

I would say marker=* could be considered a top-level tag, in the same way as the fairly new club=*. An unidentified marker could be tagged with marker=yes. (I'm not the author, just an interested mapper.) —M!dgard [ talk ] 20:14, 8 September 2019 (UTC)

I agree, man_made=marker would be a better idea. This could be used for any marker, even if the user does not recognise if it's for a pipeline or buried cable or whatnot, and it's helpful for database users if all unique features use one of a limited set of "feature keys", like man_made=* - if you are using osm2pgsql to import a database, you need to include a list of every single key that represents a unique feature, and it's annoying to add "marker=" to this list when a standard key like pipeline=* or man_made=* could be used instead. Note that club=* is debated, some think it should be added to a feature like amenity=community_centre: see Key:club#Recommended_combinations and concerns at Talk:Proposed_features/Club ---Jeisenbe (talk) 00:17, 9 September 2019 (UTC)

Proposition of @Dieterdreist: in @tagging was to set values of marker=* according its appearence : post, aerial, plate... and use another key to say which utility it refers to (if applicable).

Semantically, man_made=marker is ok. I find it less useful if we make marker=* more usable for any situation and not only for utilities.

Given this situation, would you prefer man_made=marker + marker=post + utility=telecom or simpler marker=post + utility=telecom? Fanfouer (talk) 11:18, 9 September 2019 (UTC)

Missing distinction between marker types

Resolved: Proposal now use marker=* to distinguish on visual appaearence and utility=* for infrastructure the marker regards Fanfouer (talk) 21:30, 19 September 2019 (UTC)

I don't like the fact that many very different kinds of markers are merged into one tag. There are the huge pillar-hat-things that are visible from the air and there are small signs on the wall that are more like a label for a tiny object close by. Adding support=* doesn't really help, because both types can be mounted on e.g. poles. On the other hand, if used as a reference point for "regular users", it's much more important to know how the marker looks like than to know for what it stands. I would change the marker=* to handle this distinction, and have the object (water, pipeline...) as a secondary tag. Mueschel (talk) 17:06, 8 September 2019 (UTC)

Agreed and that's how I think to rework this proposal. See upside, this pole warning about the presence of optical fibre underground (initially marker=telecom + support=pole) would change to marker=post + utility=telecom at least. Wait for it Fanfouer (talk) 11:22, 9 September 2019 (UTC)

New Utility=* key: why not use existing main keys?

The newly reworked proposal now suggets using marker=* to describe the type of marker and support. Now a new utility=* key is proposed to specify what the marker is marking, e.g. utility=pipeline. However, a "pipeline" isn't a specific utility, but a feature that can be used by utility companies as well as other industrial and transportation purposes: it can carry crude oil, refined petroleum products, natural gas, water, or even mineral slurry at a mine. Instead, why not just keep the existing structure? Let's keep using pipeline=marker, power=marker and cable=marker. This also allows database users to just check for these common keys, instead of having to add marker=* as a new feature tag to import into their databases, and it avoids deprecating a fairly common tag used over 35,000 times. --Jeisenbe (talk) 23:39, 15 September 2019 (UTC)

utility=pipeline isn't part of the list of proposed values. utility=* is similar to street_cabinet=*, which should be abandonned in favour of this much generic tag in the future.

As explained before, pipeline=marker, power=marker and cable=marker aren't a good idea as they let us think the marker is part of (kind of accessory) pipelines or cables. It's not. I would preserve pipeline=* or power=* keys from values that don't describe directly related devices of pipelines or power. Just like waterway=fuel is a non-sense.

I understand the point of view of DBA who want to limit the amount of tag to import, the issue will occur if you want to render all markers but no pipelines or power cables: you'll have to import all keys with maker value instead of one key. Fanfouer (talk) 21:04, 16 September 2019 (UTC)

Additionnaly on this point, I think using pipeline=marker, power=marker and cable=marker... reinforces the idea of creating silos which is not a good thing. The marker concept doesn't need 3 keys to exist where a single can do the same job Fanfouer (talk) 22:05, 25 September 2019 (UTC)

Thoughts about utility=hydrant value

I was perplex about the add of utility=hydrant to the proposal. However, a dedicated value was required since many markers indicate an actual hydrant is installed beside.
This is currently a good opportunity to consistently separate the needs of emergency=* guys and those of networks/infrastructure ones. utility=hydrant} could indicate all stuff dedicated to the hydrant feeding (pipes mainly) and markers indicating them. Firemen only need to know the exact point where they will be able to get water while infrastructure development requires to know much more information about how hydrants and other utilities are built. Then I think it's a good option to have emergency=fire_hydrant and utility=hydrant in different objects. Fanfouer (talk) 21:57, 25 September 2019 (UTC)

Various Issues

This proposal deals with improving the mapping of things which are already mapped to a limited extent, perhaps both because the current tags are obscure and it is often a degree of micro-mapping beyond most people. However, I think there are various important issues which need addressing. Here are various comments which quickly occur to me (forgive me if these overlap with other points) SK53 (talk) 12:03, 16 October 2019 (UTC):

• The existing usage, for pipeline markers, in particular, MUST be much better documented (18k examples). This is not the introduction of a new tag, but a proposal to replace tags which have been in use for some years. For instance, I mapped a few gas pipeline markers in Heidelberg during SotM.

It actually regards already mapped features but also brings a lot of potential regarding non mapped objects Fanfouer (talk) 12:41, 16 October 2019 (UTC)

You don't properly address the issue of the large number of objects mapped under existing agreed tags. This is a fundamental weakness of an otherwise OK proposal. SK53 (talk) 20:10, 20 October 2019 (UTC)

Reasonable tagging changes are a necessity to make OSM evolve. I know this cause many workload and change in existing render/extract tools. Keeping pipeline=marker may legitimate kind of power=marker or cable=marker which are not desirable. One of the goal of such proposals is to clean and bring consistency, with a plan to move from existing tagging to new one. We're dealing with 40k existing markers against dozen of milions remaining to be mapped with proposed tagging Fanfouer (talk) 23:17, 21 October 2019 (UTC)

• The photo examples seem to be very DE-specific, a selection of examples from different countries should be included and the country-specific descriptions moved elsewhere. Pipeline markers in Britain are of several types the most noticeable ones being red and white striped poles. In towns they are small concrete objects with a plaque mounted on them. I'll try & find some for you.

It's true that most examples are from western Europe. What do you mean by DE-specific? No problem to extend the examples list on keys pages once proposal reviewed. You'll be welcome with different pictures to do so Fanfouer (talk) 12:41, 16 October 2019 (UTC)

• In the UK fire hydrants, service valves and a variety of other utilities are marked by quite distinctive concrete or metal posts (similar to gas pipelines above). (When I was a kid you could buy a book in the I-Spy series which told you all about them). I think Alex Kemp wrote a blog post about them. I'm not sure if people mapping fire hydrants in the UK are mapping the actual location or the marker post (which is much easier to notice & verify). This needs to be checked with mappers who've mapped fire hydrants in the UK (also see your comment above, which I agree with). Again I'll try and find some examples.

This can be adressed right now for many situations. Examples and use cases will be completed as soon as a different situation is found. Fanfouer (talk) 12:41, 16 October 2019 (UTC)

• The tag mounting is used in various forms for describing man made objects mounted on poles/walls etc. The most widespread use is post_box:mounting=*, where certain wall postboxes are enclosed in a brick pillar. Again I used it 'raw' form for sundry objects around Heidelberg (mainly cigarette vending machines which appeared under-mapped, and may be standalone on poles, or attached to walls). This seems to me to be a partially established tag which can be used generically for a range of objects.

mounting=* and support=* are both passive keys : marker is mounted on or marker is supported by. Describing the shape of markers with marker=* makes the support key uneccessary in many cases. However it's possible to complete with mounting=* if mapper find it relevent even if this proposal don't mention it. Fanfouer (talk) 12:41, 16 October 2019 (UTC)

Mounting (& support) only really need to be added if the method of mounting/support is different from usual, or if the technique varies on a case by case basis. I suspect they are largely synonyms of each other. SK53 (talk) 20:10, 20 October 2019 (UTC)

I'd be ok with this. This could be documented in marker=* example sections without changing so much proposed tagging. We'll see with concrete situations Fanfouer (talk) 23:17, 21 October 2019 (UTC)

• Utility=hydrant is hugely confusing compared with emergency=fire_hydrant when what is discussed is a marker not the utility itself. Far better to have something like man_made=utility_marker with a subtag for the different types.

See upside chapter §10 : markers are part of the infrastructure although they're not involved in its operational process. utility=* could be suitable for markers and other things including network themselves. Sorry I don't get how a main tag like man_made=utility_marker allow to distinguish hydrant markers from pipeline markers since both are utilities Fanfouer (talk) 12:41, 16 October 2019 (UTC)

Simply use sub- or adjectival tagging. utility_marker=*. I think this is better than the introduction of an entirely new top-level tag. SK53 (talk) 20:10, 20 October 2019 (UTC)

Markers aren't restricted to utilities and utility is a suitable word for many objects. Defining two separate keys allow to reuse them in other situations (marker=* without utility=* is suitable for highway milestones or private property limits). There is no point to define utilities for markers only, aren't you? Fanfouer (talk) 23:17, 21 October 2019 (UTC)