Add field sidewalk on highway presets

[tordans]

Following the long discussion in #454 this PR add the field sidewal.

Supported values: yes|no|separate
Autocomplete is disabled to prevent miss tagging – improving the situation described in #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 #454 (comment).

The third tagging practice of using the values left, right, both will be supported once openstreetmap/iD#10839 is implemented. Update: See also openstreetmap/iD#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]

🍱 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 Add sidewalk field #454 (comment)) but that is separate from this PR
• It links to https://wiki.openstreetmap.org/wiki/Item:Q699 which is fine

Wording

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

[Dimitar5555]

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

---

• 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.

[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]

Thanks a lot, LGTM!

[matkoniecz]

and say tertiary is inheriting from primary fields

[tordans]

Right, we only need to change this one place; it follows the same pattern that cycleway has.

[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:

🤔

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?

[tordans]

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.

This is what openstreetmap/iD#10935 would add, right? (I might be missunderstanding it…)

[1ec5]

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:

By the way, in terms of length, the subkeys are about 40% as common as the values, so not as stark as the raw way counts:

• 403 077 km of sidewalk=left/right/both/separate
• 159 671 km of sidewalk:left/right/both=yes/separate

[lumikeiju]

@1ec5, worth noting the trend, too - a week and a half later, those queries now return 360,066 km "unsided" (~89%) and 162,924 "sided" (102%) (and I did not mass convert them or anything, though maybe someone is?)

[matkoniecz]

openstreetmap/iD@9266707 just appeared in iD

would closing/reopening PR to trigger rebuild would deploy preview with it included? Or is it taking latest released iD?

[matkoniecz]

Yes, it pulled latest iD commit from master branch, so it can be tested properly here.

I will try to find some bugs.

[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

I opened openstreetmap/iD#11950

[matkoniecz]

Is it just me or is there noticeably 0.5s lag after selecting option from dropdown menu?

EDIT: apparently just me, and even for me it stopped happening

[matkoniecz]

one cute part: where single way has say sidewalk:both=no sidewalk:right=separate interface will display "Multiple values" for right side. I was not expecting this to be handled!