Id: Are preset tags exclusives?

[yvecai]

Say I draw a line, uses the presets to tag it waterway=river.
Then I use the preset to tag it boundary=administrative, admin_level=2.
Then it's no longer a river ?

Or did I don't do it properly ?

[bhousel]

Say I draw a line, uses the presets to tag it waterway=river.
Then I use the preset to tag it boundary=administrative, admin_level=2.
Then it's no longer a river ?

Yes, a feature can only really match one preset in iD.

[yvecai]

Wow, then the presets are a bit useless, isn't it?
Is this intended or just hard to fix?

[bhousel]

Wow, then the presets are a bit useless, isn't it?
Is this intended or just hard to fix?

No they aren't useless - people are supposed to tag one feature per element in OSM:
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

You shouldn't use a single way to be both a boundary and a river.

[yvecai]

Hmm, you're taking this too literally, even this page mentions exceptions.
My issue at hand: What if a road is a ski piste in winter?

[bhousel]

My issue at hand: What if a road is a ski piste in winter?

My recommendation is to just draw an extra line for the ski piste, next to the road. It's easier for people to understand and easier for piste-map-makers to consume the data that way.

[yvecai]

Huh, what? 8-)

[yvecai]

A good part of the ski pistes mapped are also highways (37%, or 61 789 elements). This mapping pattern is quite common, and your suggestion doesn't make a lot of sense. I won't even comment on duplicate, offset geometries ;-). I guess one can argue that being a piste in winter is a property of the underlying highway, and as a data consumer, I'm please to know that.

But in this state of things, this means that having pistes presets in iD is not a good idea, given that the contributor using them risk to erase highway without notice.
However, from a UI point of view, I think that using preset to map piste is very good.

What would be the way to go forward ?

[yvecai]

1408

[yvecai]

Apparently, using the highway field like in #1408 preserve highway=yes.
Like in:

{
    "icon": "maki-skiing",
    "fields": [
        "name",
        "piste/type",
        "piste/difficulty_nordic",
        "piste/grooming_nordic",
        "oneway",
        "lit",
        "highway"
    ],

Maybe it should preserve highway=whatever.

[bhousel]

Apparently, using the highway field like in #1408 preserve highway=yes.

That wouldn't really work because if you set a highway tag, iD will recognize the feature as a highway.
Presets are still exclusive and I don't see an easy way to change this in iD.

It's kind of like tram tracks that share with a highway. You probably _could_ just put all the tags on a single way, but most people split them up because they are easier to understand and edit that way. If you combined the railway=tram and highway=secondary iD would probably do something weird.

[yvecai]

A solution could arise from the mappers or from iD before these preset can be used safely.
See https://taginfo.openstreetmap.org/keys/piste%3Atype#combinations for reference.

[yvecai]

The change to avoid removing existing tags is easy.

However as you pointed out, then the preset editor displays back the preset with the highest "matchScore" as soon as you change a field.
To prevent this, from a UI point of view, the entity editor could display several presets. The ones with the lowest matchScore would be collapsed by default (yes, this is the big thing).
Plus, the preset schema have an explicit "removeTags" section if really needed.

Would it be considered an heresy if the entity editor supports several presets for a selected entity ?
To my mind, it's closest to the tagging spirit of OSM. On one side there is the One Feature One element good practice, but in principle people are also free to tag the tram on the highway or aside.

[bhousel]

Would it be considered an heresy if the entity editor supports several presets for a selected entity ?

Yeah, let's not do this.. It would be a huge effort to change the entity editor to match multiple presets, and end up being really confusing. Sorry!

[dieterdreist]

In the case of a river, it does not violate the OSM rule if the river is both, a border and a river. Rivers can be the actual border (and if the river changes, the border may change in some cases). Removing the river tag is an error, if you insist on a dedicated element for the border, than it must become a relation with the river as member.

[Adamant36]

The case of a river, it does not violate the OSM rule if the river is both, a border and a river.

In ever case I've seen them the border and river are seperate ways that are attached to each other. Otherwise, its a pain to move one without moving the other. Plus, a border isn't really a property of a river anyway. So they should be mapped as a seperate thing IMHO. Would it be correct to add a tag like border=yes? Probably not.

[dieterdreist]

The question wasn't though what you have seen, it was about how the border works. If it is defined as "the river", it is desirable that the border moves when the river moves. If it is defined as a series of coordinates that happen to be in the river, then it is desirable that it doesn't move (and that it is composed exactly from those defined coordinates).
Generally for borders, the question is what both sides of the border think about it.