Add field `sidewalk` on `highway` presets

[tordans]

Following the long discussion in https://github.com/openstreetmap/id-tagging-schema/pull/454 this PR add the field sidewal.

Supported values: yes|no|separate Autocomplete is disabled to prevent miss tagging – improving the situation described in https://github.com/openstreetmap/id-tagging-schema/pull/1278

Supported key: sidewalk|sidewalk:both|sidewalk:left|sidewalk:right It will use sidewalk:both when user change date or add new data based on the evaluation in https://github.com/openstreetmap/id-tagging-schema/pull/454#issuecomment-2731787841.

The third tagging practice of using the values left, right, both will be supported once https://github.com/openstreetmap/iD/issues/10839 is implemented. Update: See also https://github.com/openstreetmap/iD/pull/10935

All those parts have already been discussed in the linked PR.

The main part that is new here is, which presets show the field. I added the field to all presents, that have the "cycleway" field today. Just like the cycleway field the sidewalk field is placed in the moreFields. We could do more data crunching and analysis to find out if we would want to move the field to the fields section in some cases but I suggest to do this later to keep this PR simple.

[github-actions[bot]]

:bento: Your pull request preview is ready

Please use this preview to check your changes. Ideally use the test documentation template and document your test results by commenting on the PR. This will speed up the review process for everyone.

FYI, once this PR is merged, you can use the iD Editor Preview to test your changes in interaction with all other changes.

[tordans]

Test-Documentation

… for https://pr-1507--ideditor-presets-preview.netlify.app/id/dist/#locale=en&map=19.43/14.65478/121.06335&disable_features=boundaries&background=Bing&id=w4095389

Preview links & Sidebar Screenshots

• Looks good. But ich changed the label to "Sidewalks" after taking this screenshot

  

• The "old" tagging does not look ideal. But given that we have a plan to improve this and given that it does give a strong signal to users to click and update the field (which will improve the data) it think that is OK

  

Search

All good:

Info-i

Info-i looks good

• That links to https://wiki.openstreetmap.org/wiki/Key:sidewalk which I think should be updated (see https://github.com/openstreetmap/id-tagging-schema/pull/454#issuecomment-2777839092) but that is separate from this PR
• It links to https://wiki.openstreetmap.org/wiki/Item:Q699 which is fine

Wording

• [x] American English
• [x] name, aliases (if present) use Title Case
• [x] terms (if present) use lower case, sorted A-Z

[Dimitar5555]

• [x] The order of the items in the placeholder and the order of the dropdown values doesn't match.

---

• [x] none and None may look a bit confusing when they are on top of each other (a mapper might ask "Why is one blue and the other black?"). It might be better to use 'No' for 'sidewalk*=no` label.

---

• [ ] Clicking on =none shows None with dark grey background (which is likely due to the search ability of the field. It may seem like it is the selected option.

[tordans]

Thanks @Dimitar5555 I just pushed some changes to change the order and labe. We use "None" for other value labels like Cycleways. But I agree that the "no" is better here. I updated your comment to check of those two things.

Clicking on =none shows None with dark grey background (which is likely due to the search ability of the field. It may seem like it is the selected option.

This is now better with the change wording. I don't see a lot we can do here. It would be something to change in iD but I think the UI is fine as is.

[Lumikeiju]

Thanks for all your recent work on this @tordans! I agree that "No" is better than "None".

[waldyrious]

Nice! Looking forward to see this finally be in iD 😃

I tested the preview a bit, and noticed that when there's sidewalk=both, the two fields show the value "both" (which I guess is inevitable; at least, I can't think of an alternative). But when I change one of them to e.g. "No", the result is sidewalk:left=no+sidewalk:right=both, with doesn't seem like the right choice. If it's already changing sidewalk to sidewalk:right, it might as well include a change from both to yes, which not just prevents the extra step of modifying the right sidebar by hand, but actually prevents inserting (😱) an erroneous tag value.

[tordans]

@waldyrious let me refer this to …

The third tagging practice of using the values left, right, both will be supported once https://github.com/openstreetmap/iD/issues/10839 is implemented.

Which is where we should discuss this to not derail the conversation if how and when to merge this PR. You fill find a Draft PR attached over there which mentions this case. Let me also point out that a spirit of incremental optimization will help us get at least something going and faster.

[waldyrious]

Got it, thanks for the pointers :) I'll follow that thread.

Let me also point out that a spirit of incremental optimization will help us get at least something going and faster.

Absolutely! To be clear, I only commented here because you asked for feedback in #1278. I definitely agree that this PR is an improvement over the current state of things and I support its integration regardless of the issue I pointed out.

[gy-mate]

I wanted to try out this new field but unfortunately the Netlify preview isn't available anymore :(

[tordans]

I wanted to try out this new field but unfortunately the Netlify preview isn't available anymore :(

Your wording change just now triggered a new build. It will, however, not include the changes that are part of https://github.com/openstreetmap/iD/pull/10935, yet

[gy-mate]

Your wording change just now triggered a new build.

Great—thanks for the heads-up! :)

Are highway=service roads left out from this PR on purpose? If yes, why?

[tordans]

Are highway=service roads left out from this PR on purpose? If yes, why?

my understanding is that those should never have sidewalk… AFAIK StreetComplete does not show them on the overlay either.

However I did not analyse existing data (maybe per country).

We do not want to end up with spammy „no“s when the no is the clear default.

[gy-mate]

those should never have sidewalk…

Here is a highway=service having a sidewalk:right=yes next to a major road: https://www.mapillary.com/app/?pKey=1888368401897025&focus=photo&lat=47.505925&lng=19.0642848&z=17&x=0.46743980464896&y=0.46606918556018295&zoom=0.8779940119760465

We do not want to end up with spammy „no“s when the no is the clear default.

Wouldn't "hiding" the field in moreFields already prevent this?

[tordans]

Wouldn't "hiding" the field in moreFields already prevent this?

Agreed, I just added it. (The cycleway field is not present on service but I left that untouched.)

[gy-mate]

Thank you so much! :) Just two additional minor suggestions:

[gy-mate]

Thanks a lot, LGTM!

[matkoniecz]

closed/reopened to redeploy for testing

[matkoniecz]

left/right and way direction is deeply nonobvious but I have no great ideas how to better handle it

maybe have a visual GUI like StreetComplete has? but it is not exactly so intuitive

maybe show sidewalk sides on map if user edits these fields? but I have no idea how to code it

[tyrasd]

The "old" tagging does not look ideal. But given that we have a plan to improve this and given that it does give a strong signal to users to click and update the field (which will improve the data) it think that is OK

It's a bit of a bummer that it does not handle this more gracefully. It's still the most used tagging version according to the raw usage numbers:

:thinking:

What we would need here is a way to define "equivalent" tagging variants, e.g. sidewalk=left is the same sidewalk:left=yes + sidewalk:right=no. For now we could hard-code that for the sidewalk tag in iD & co, but it would be good to think whether we should include something like that in the schema-builder.

@tordans do you think the following would be a good approach to tackle this: 1) implement hardcoded tag-equivalents as outlined in the paragraph above, 2) release iD, 3) merge this PR, 4) release tagging schema with sidewalk field, 5) discuss more generic handling of such cases in schema-builder repo. What do you think?