New Quest: Guidepost Metadata (ref,ele,name)

[qugebert]

General

Affected tag(s) to be modified/added: ref,ele,name Question asked: What ref is signed on this guidepost?

Checklist

Checklist for quest suggestions (see guidelines):

• [X] 🚧 To be added tag is established and has a useful purpose For example, waymarkedtrails shows at least ele and name at their map.
• [X] 🤔 Any answer the user can give should have an equivalent tagging (SCEE quests may not be answerable in all cases, but please keep this rare) we can use ref:signed=no,ele:signed=no,name:signed=no if there is data not signed It depends on region, if there is a ref,ele and name signed on guideposts. e.g. in my area, about 95% of hiking-guideposts have all of them signed, But afaik SCEE quests are inactive by default, so only those who have such metadata signed on guideposts and want to survey them can activate the quests and define their own rules (e.g. in my area, i would only survey those with hiking=yes). For this reason the quest should be asked after the activity-quest #467.
• [X] 🐿️ A survey is necessary (may require knowledge of the subject, though easy answering for everyone is preferred) Currently, i'm taking pictures and manually add the information later at home, it would be much easier to have a fast way to check if the information is still in osm and if not to add this information on site.
• [X] 💤 Not an overwhelming percentage of quests have the same answer (No spam)
• [X] 🕓 Applies to a reasonable number of map data (Worth the effort)

Ideas for implementation

Element selection: override val elementFilter = """ nodes with information = guidepost and !ele and !ele:signed and !~"ele:.*" and hiking = yes """ and similiar for the name and ref-tags. As in SCEE everyone can define their own criteria, those who have these data signed on other guideposts than hiking can change this anyway.

Metadata needed: I don't think we need any metadata. everyone can chose on his/her own responsibility if it's worth using this quest in their area.

Proposed UI:

I would chose a simple text input.

[Helium314]

I had a look at the wiki for ele: It should be made clear that "Elevations posted on official signs are usually relative to the national reference system of the respective country and have to be converted to WGS84/EGM96.", and that "Sources for elevation values can be signs or values from literature. Such values should however also be checked for plausibility since elevation signs and official mountain heights are known to be frequently inaccurate.". So as far as I understand it, just tagging what is signed can be wrong. Not sure how this is usually handled in practice.

Users should be made aware that GPS altitude is likely not acceptable due to inaccuracy and potential need for conversion. Further, ele:signed has very low usage and is not documented in the wiki. I do not want to push such almost unused tagging by having it in an other answer.

As in SCEE everyone can define their own criteria, those who have these data signed on other guideposts than hiking can change this anyway.

SCEE quests should still have reasonable default filters, better a little too strict than too loose. (Not complaining about your proposed filter, just a general statement on this).

I would chose a simple text input.

Limitation to numbers seems reasonable in case of ele ref could suggest recently entered vlaues (from same session) and ref from nearby paths and routes (though the routes might not be in the database iirc).

ref has the issue of using a bunch of similar tags, and from wiki it's not really clear to me when which one should be used. This seems to be mostly relevant for cycling guideposts though. Further it should be clarified how to deal with multiple reference numbers (simply separate using semicolon?).

[qugebert]

I had a look at the wiki for ele: It should be made clear that "Elevations posted on official signs are usually relative to the national reference system of the respective country and have to be converted to WGS84/EGM96.", and that "Sources for elevation values can be signs or values from literature. Such values should however also be checked for plausibility since elevation signs and official mountain heights are known to be frequently inaccurate.". So as far as I understand it, just tagging what is signed can be wrong. Not sure how this is usually handled in practice.

Users should be made aware that GPS altitude is likely not acceptable due to inaccuracy and potential need for conversion. Further, ele:signed has very low usage and is not documented in the wiki. I do not want to push such almost unused tagging by having it in an other answer.

Ok, we can skip ele completely if this is too problematic...

As in SCEE everyone can define their own criteria, those who have these data signed on other guideposts than hiking can change this anyway.

SCEE quests should still have reasonable default filters, better a little too strict than too loose. (Not complaining about your proposed filter, just a general statement on this).

I would chose a simple text input.

Limitation to numbers seems reasonable in case of ele ref could suggest recently entered vlaues (from same session) and ref from nearby paths and routes (though the routes might not be in the database iirc).

In my understanding, one characteristic of 'ref' is, that it is kinda unique, at least for the same operator/network/area. Sure, it happened to me too that i've seen identical refs signed on nearby guideposts, but this is really rare, so in general, it doesn't make so much sense to me, to suggest a existing ref as possible value of a nearby ref.

ref has the issue of using a bunch of similar tags, and from wiki it's not really clear to me when which one should be used. This seems to be mostly relevant for cycling guideposts though. Further it should be clarified how to deal with multiple reference numbers (simply separate using semicolon?).

Hmm, wiki says to use ref= and taginfo lists a few other 'ref'-combinations , but 'ref=' is definitely leading

[Helium314]

Ok, we can skip ele completely if this is too problematic...

I really don't know how the tag is actually handled by people who add ele data. Are elevations really converted to EGM96, or checked in some ways? Or are they in practice just taken from some sign?

ref

Then using ref should be fine. Though it needs to be clear what goes into ref. Is it some guidepost id, or refs of signed (hiking) routes?

[mcliquid]

I really don't know how the tag is actually handled by people who add ele data.

to be honest, i've entered several thousand signposts and never converted the elevation on the sign. or how do we do that for summits, mountain passes or elevations on buildings? i enter it exactly as it is written on the sign.

one example to come up with some concerns: https://commons.wikimedia.org/wiki/File:Dornbirn_Wegweiser_Talstation_Karrenseilbahn.jpg we have a name with "Karrenseilbahn". we have a ele with "455" (i wouldn't convert it). but now, we have two refs here! we have a ref (VWW 20.086) for the hiking guidepost on top and a second ref (20.086M) for the MTB guidepost. and fun fact from small Vorarlberg, Austria: we have sometimes four refs on one pole! e.g. "VWW 20.086" for hiking=yes, "VWW 20.086.R" for bicycle=yes, "VWW 20.086W" for snow shoe hiking and "VWW 20.086M" for MTB - yay! currently they are mostly added as one node per "transport mode", so we have four nodes for "one guidepost". but some are adding them to one guidepost - whatever is correct.

[Helium314]

to be honest, i've entered several thousand signposts and never converted the elevation on the sign. or how do we do that for summits, mountain passes or elevations on buildings? i enter it exactly as it is written on the sign.

I suspect that's how most ele values found their way into OSM, despite of what the wiki says. I'm not sure how to best do it, but there should still be some sort of warning to check for plausibility, and to not enter raw GPS altitude.

[Helium314]

currently they are mostly added as one node per "transport mode", so we have four nodes for "one guidepost".

I guess the ref quest will need to show the tagged "transport modes", or any user unaware of the guidepost split will likely enter all refs on the first one. And the form should allow simple input of multiple refs, like the AMultiValueQuestForm.

[mnalis]

I'd guess that ref on a guidepost is a ref of guidepost itself; e.g. on a node network - as for regular guideposts (e.g. on crossing of regular hiking/cycling routes) it would not exist.

For information=guidepost, I'd expect direction_*:ref to indicate the ref of the hiking/cycling/etc routes for that direction. I must say that I personally do not see much value in trying to tag that "route ref" information on guideposts. It should definitely be tagged on relations containing the ways that pass that guidepost; and guidepost node itself might be useful for people to verify their location (weak GPS under canopy etc); but directions of ways on guidepost node are IMHO hard to tag and of much less utility than hiking/cycling route ref on their proper place (i.e. on relations of ways) .

---

Because even if you tag e.g. direction_northwest:ref=20 it is very problematic (and not only because of issue with multiple signs mentioned above!):

• you don't have option to attach other related tags (e.g. how would one know if that is a hiking route or cycling one? its length? its website?); at least unless you invent them (and then they likely won't get much support from data consumers)
• is it really NW, or maybe NNW? Or maybe 339 degrees? Do we even have a convention to map precise direction or just those very coarse ones?
• what if multiple paths matches approximate "NW" direction? Is compass a must for tagging that? And if so, do we use magnetic north (i.e. regular boyscout magnetic needle compass) or true north (and can we trust people they can calculate it properly)? What about magnetic drift over time?
• what about if a way starts to NW, but after hundred meters bends and goes straight to N? Do we tag it as NW or N? What about if it does that after only a dozen meters? After 1 meter?

All those issues are avoided if we tag ref and associated tags directly on route relation object; instead on guidepost node.