Add parking=street_side

[jdhoek]

Adds a preset for street-side parking.

The proposal for parking=street_side has been approved, and the tag is in use. This PR adds the preset for the explicitly mapped variant. The implicitly mapped variant uses the parking:lane tag on the highway itself instead of mapping the areas separately and will be offered via a separate PR later.

---

This seems to work, but when I preview this in iD I see this:

• The wiki-link for the preset seems to be Key:parking rather than Tag:parking=street_side. Any idea why?

• The label in the preset for parking:street_side is just parking/street_side. How do I set the label to the value of label in data/fields/parking/street_side.json?

• No wiki documentation for the field parking:street_side either, but that may because the page has only recently been created.

Are there more files I should edit?

[SupaplexOSM]

Note: "parking:street_side" should be changed to "parking:orientation" after it has been renamed during the implementation of the proposal (see footnote 1 on proposal page: https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side).

[jdhoek]

@SupaplexOSM Oh that's right! Commit amended.

[TheAdventurer64]

Wow! I was just going to add this. Nice work!

[maro-21]

I fully support parking=street_side tag and I like it but I think we shouldn't have a separate preset for it, just an item on the list like we have for other values would be enough.

We already have separate presets for Multilevel Parking Garage and Underground Parking (for me not necessary either), but we don't have it for e.g. parking=surface - the most common value.

One preset, "Parking Lot" would be enough. Then a user can choose the type of the parking.

The reason for this is that after typing "parking" (at least in my language) I would like to see the main presets:

1. amenity=parking
2. amenity=bicycle_parking
3. and amenity=motorcycle_parking.

But what I see is:

1. Underground Parking
2. Bicycle Parking
3. Parking Lot
4. Motorcycle Parking
5. Multilevel Parking Garage
6. Park and Ride Lot.

If we add another one, the main preset, "Parking Lot" will be even lower. But it should be on the first position becasue it's one of the most popular and basic preset/tag on OSM.

The wiki-link for the preset seems to be Key:parking rather than Tag:parking=street_side. Any idea why?
No wiki documentation for the field parking:street_side either, but that may because the page has only recently been created.

The answer to both question is: because there is no data item, like this: https://wiki.openstreetmap.org/wiki/Item:Q7598

[jdhoek]

I fully support parking=street_side tag and I like it but I think we shouldn't have a separate preset for it, just an item on the list like we have for other values would be enough.

parking=street_side is unique amongst the parking-values in having the parking:orientation tag. I don't see how that can be easily supported without a preset.

If we add another one, the main preset, "Parking Lot" will be even lower. But it should be on the first position becasue it's one of the most popular and basic preset/tag on OSM.

That sounds like an issue with priorities in sorting. I agree that the generic parking preset should show up on top. I think there is some support in the tagging language that allows for some results to be prioritised, but I'm not knowledgeable enough about that. It's better to open a separate issue for the sorting problem to keep this PR topical though.

[jdhoek]

@quincylvania Any idea how I can address the three bullet-points in the OP?

[imagoiq]

Could it be addressed in some ways by using a preset_category?

[ireun]

+1

[mbrzakovic]

Solid change, street-side parking are starting to be used intensively.

I just double checked locally (built this code and pushed to the iD) and I am confirming that appropriate wiki page is being linked in the iD for amenity/parking/street-side preset.

source_strings.yaml should be updated, thought I don't consider this a pr blocker (usually this is done via: npm run build)

[1ec5]

A bit of copyediting:

[jdhoek]

source_strings.yaml should be updated, thought I don't consider this a pr blocker (usually this is done via: npm run build)

Done.

[jdhoek]

Note for a follow-up PR: in the year since I've submitted this PR parking=lane has gotten more strictly defined alongside parking=street_side. parking:orientation can be used with parking=lane as well, so it might benefit from the same approach.

parking=lane is not as common as parking=street_side because it competes more directly with the attribute-based tagging via parking:lane on the highway=*, but it is well used.