search

zlant / parking-lanes

Parking lanes viewer from OpenStreetMap
https://zlant.github.io/parking-lanes/
MIT License
77 stars 13 forks source link

Provide a way to upgrade tags to the updated parking:lane schema #93

Open tordans opened 2 years ago

tordans commented 2 years ago

https://github.com/zlant/parking-lanes/pull/83 add the new schema to the editor which means all new tagging will follow the new schema. However, to fully support the new schema https://github.com/zlant/parking-lanes/issues/61, local communities also need to update their existing tags.

This issue meant is to track ideas and solutions for this effort.

I created https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Parkraum/parking:lane-Schema-Update as a shared place to document how to programmatically (or not) update the existing tags.

jakecoppinger commented 2 years ago

My preferred method for doing this is migrating tagging to the new schema on edit of a particular way - that way there is always a human in the loop, but it's fast and easy.

We could add a function which takes in takes in the old tags and returns the new equivalent tags.

If we wrote such a function I'd like to unit test it heavily, say by adding dozens of tests for at least every scenario on https://wiki.openstreetmap.org/wiki/Key:parking:condition and https://wiki.openstreetmap.org/wiki/Key:parking:condition/complex. This would mean that we (and anyone reviewing the code) would be absolutely confident that it is correct.

I'm not sure of the best way to track where tags are outdated and need to be migrated.

tordans commented 2 years ago

We talked a bit about the upgrade path (I still have to update the Wiki with what was written in the Matrix chat).

It looks like, most tags could be updated automatically. But there are a few that are easier handled manually (by a JOSM user…).

I was thinking about something like this:

a. Add an update button on the map. b. Which opens a modal with a long table. c. The table shows each way of the map with the current tags and what the update would make of it. d. There is a button per line to apply the changes and one to apply all.

This way, the update is still pretty automated, but allows for a manual check by a(n experienced) user.

…unit tests…

Agreed. In addition, we should start with the common and easy changes and call out to handle the complex changes manually.

I'm not sure of the best way to track where tags are outdated and need to be migrated.

Luckily, this is not a PTv2 situation… Some keys/values are deprecated now and should always be updated to the new tagging.

I expect the complexity in to rise when the update path requires a specific sequence; when edge cases where tagged in a non standard way; and when values where used in an unexpected way. The wiki above hints at those situations.