Avoid creation of undefined piste:type=yes tags

[yvecai]

Description, Motivation & Context

With this particular preset, a tag piste:type=yes is set by default, with no real useful meaning if the mapper forget to enter a value in the piste:type field.
Ski pistes or other winter sports are extensively covered by the other piste:type=* presets, and are easy to find with the translations available, so deleting this preset shouldn't change much for users, except they have to choose the right piste:type= value for their mapping.

Related issues

https://community.openstreetmap.org/t/rfc-deprecate-piste-type-yes-winter-sports/116927/1

Links and data

Relevant OSM Wiki links:
See https://wiki.openstreetmap.org/wiki/Tag:piste:type=yes

Relevant tag usage stats:
https://taginfo.openstreetmap.org/tags/piste:type=yes#overview
https://taghistory.raifer.tech/#***/piste%3Atype/yes

[yvecai]

For history, initial preset creation on Id repo:
openstreetmap/iD@3296176

[github-actions]

🍱 You can preview the tagging presets of this pull request here.

[yvecai]

Preview works as expected, a after / before image:

[tordans]

Testing

Query: https://overpass-turbo.eu/s/1PUu

@yvecai I don't think this is right, yet.

Old	New
Link	Link

I think what we need is a generic piste preset which has a field for piste:type which has "option strings" that explain the values. The "yes" value could then be "Unspecified piste type" which nudges users to pick a better value.

[yvecai]

Why would we put 'yes' as a value, if 'yes' is undocumented, undefined, without useful meaning?
Apart 'tag as you want' of course, one is free to put anything in the raw tag editor.
This lead to my next question, I'm not versed into Id validation, so what triggers this odd validation error 'should be a closed area'?

[tordans]

Why would we put 'yes' as a value, if 'yes' is undocumented, undefined, without useful meaning?
Apart 'tag as you want' of course, one is free to put anything in the raw tag editor.

The issue I see @yvecai is, that we are suggesting that something is not a feature but some unkown tagging which I consider a very big change. Before we showed something as Piste, now we don't recognize it as a line only which is not true, the tagging tells us that it is an unspecified piste.

I think that incremental tagging (AKA tagging something unspecified first and then improve the tagging over time) is a very common and important practice in OSM. Which is why I suggested to still show this as a piste but use wording that indicates that it is unspecified and the tagging should be improved.

This lead to my next question, I'm not versed into Id validation, so what triggers this odd validation error 'should be a closed area'?

I don't know why this shows either. I expected some preset that matches piste:type with a geometry field that only says "area" but they all have line and area as geometries.

But I would rather fix the first case then look further into this one.

[tyrasd]

Yeah, just removing the preset is probably not the solution here: This preset is the "fallback" preset for values of the piste:type tag which don't have a dedicated preset yet (for example, say, piste:type=fatbike). Without the fallback preset, these features would not be recognized as a piste anymore. The value yes is coming from the fallback mechanism of the field, which is in place because we cannot and don't want to set an empty tag (e.g. "piste:type"="") if a user leaves the field empty.

What we could do is to make the preset hidden ("searchable": false), then it will not be offered for newly created features, but will still be used for existing features mapped as piste:type=fatbike, etc.

[tyrasd]

I think that incremental tagging […] is a very common and important practice in OSM

True, but as far as I can see, there is really no intended way to tag a piste as "unspecified". For all I know, this might have been even intentional, as the different pistes can be very different from each other (compare a ski jump piste with a snow hiking "piste" for example). This is quite similar to the tagging of roads, where there is also not really a good way to tag an unspecified type of road. What I want to say is that we don't need to force a workflow onto a tagging scheme which simply does not work for that particular tag.

[yvecai]

"we cannot and don't want to set an empty tag"
I suppose there's no way to not set a tag at all if value is let empty?

And yes, it was my intention at the time I created the preset not to allow "unspecified" values for piste:type : the practices are so different amongst the available values that it makes no sense at all.

[tordans]

I am looking at https://openskimap.org/?obj=6f9e5e0f9004bacf7216f97676512b77716644ec#14.48/47.62314/12.58004 and the yes objects like this one are not displayed there.

Are there any other relevant data consumers that might handle the yes? Otherwise I agree that in this case, yes should never be used.

---

So I think we have two options:

A. Remove the preset so "yes" shows as an unkown line like in #1312 (comment)
B. Add an unsearchable fallback preset for "yes" and make sure the wording signals that a propper value should be picked, similar to my suggestion in the same comment.

I would pick (B) because it handles the fact better, that we used to allow/tag yes via iD and the migration is cleaner and better guided. But I think it is fine to merge (A) as well.

---

In any case, it would be great to have a MapRoulette Challenge to fix those tagging errors.

[yvecai]

I can confirm Opensnowmap.org doesn't use it. I recently contacted Youstiti Solutions that added a few of them in the Alps. These piste:type=yes either looks like piste:type=connection or a quick edit to allow routing. No reply yet.

I agree (B) is a good solution, and would prevent adding a piste:type=yes by mistake. Keeping a general piste preset when clicking on a fancy piste:type=* is certainly a good thing.

[yvecai]

Ah, and the MapRoulette challenge is here, it's advertised on the forum just not public.

[yvecai]

(See previous comment)

Hi, I think requested change has been done in the last commit, restoring the preset and make it not searchable.

[tordans]

I updated the name to include "(Unspecified Type)" which we use in a few places where we want to signal to users that they should pick a better preset.

• Other cases with "unspecified type" https://github.com/search?q=repo%3Aopenstreetmap%2Fid-tagging-schema%20unspecified&type=code
• Martin on the topic kerb: Update name of general preset #1077 (comment)

It looks like this now – Example

I will merge it now.