Proposal for a rework of the parking:lane schema

[tordans]

Hey! For anyone who did not see it, yet: There is a proposal in the works with the goal of improving and reworking the parking:lane schema.

• Proposal https://wiki.openstreetmap.org/wiki/Proposed_features/street_parking_revision
• Discussion on the Wiki discussion page

It would be awesome to get your input on this. A explicit position of StreetComplete on this proposal would help a lot to either stop things before too much time is invested … or push things forward to a better solution.

Apart from StreetComplete, the most important part that help is needed with is IMO the question of data migration. Any help with this is very welcome.

I know @westnordost already is aware of this. So this is FYI for @matkoniecz in particular.

[SupaplexOSM]

The issue of data migration (i.e. updating data mapped according to the previous scheme) is crucial if this proposal succeeds. Perhaps StreetComplete can become a central tool for "translating" old data with a suitable quest ("Is this parking layout still correct?"). Support for this would be really great.

As far as I know, @matkoniecz has already started working on parking restrictions for StreetComplete, right? This would make it possible to update both the physical and the legal properties. (There have been discussions (#4501) recently about StreetComplete deleting data when a physical property changes - this would then no longer be necessary).

As part of the proposal, a "translation guide" is planned to provide very clear rules on how to "translate" old tags in new ones.

[SupaplexOSM]

Is a mass edit out of question? It would make a lot much easier

I have no experience with an automated edit on this scale, but so far I don't think it is a realistic option. Such an approach is too undesirable in the OSM community - and the mapped data are probably too confusing and inaccurate. The error rate would probably be unacceptably high. At the very least, a human should roughly check each situation (on aerial or street images or on the ground) to see whether physical and legal properties are (still) correct and how "special", incorrect/inaccurate or difficult-to-interpret tags should be dealt with.

[westnordost]

There are guidelines for automated edits, yes. That doesn't mean that they are undesirable. It just needs to be documentedand discussed beforehand, just like a proposal.

If there is a 1:1 mapping for each value, i don't think that someone needs to check on-site if it was mapped correctly. That whole argumentation is based around the notion that the last edit timestamp on an element kind of denotes when (all properties of?) an element have last been checked. This assumption doesn't work at all for roads, as they are frequently split up to account for an ever increasing level of detail and dozens of tags on it.

[SupaplexOSM]

It could be possible to automatically update at least the physical tagging (mainly position and orientation of the parking, but also attributes like surface, capacity, etc.) and standard cases of restriction tagging (former parking:condition schema, e.g. "both=free" without other condition tags). But I think it's impossible to translate a lot of non-standard restriction tagging in a meaningful automated way without human interpretation. The previous schema (especially the old schema without conditional tagging that was valid until a year ago and that is still common in the wild) was far too ambiguous with an wide variety of different tags and interpretations. Physical and restriction tagging are independent, so it could be OK to just update physical properties without touching the restriction properties in this cases.

Nevertheless, I don't have the know-how to write a bot/tool for this. Someone would need to do that.

If the propsal is successful, what could be a good way to update the tagging of the StreetComplete parking overlay quickly? At the moment, a massive amount of data is being added by SC (+15% within the first month), which is totally great, but the effort to clean it up grows from day to day. On the other hand, this also means that StreetComplete users would be able to record more data according to the "new" schema within a few months than there are still in the database tagged with the 12 years "old" schema (if tagging is changed quickly in SC).

It would be a pity to pause the overlay, because some mappers seem to be very motivated to use it ;)

[westnordost]

To switch out the tagging as soon as possible after the proposal has been approved, my suggestion would be to

1. If the proposal has good chances to be accepted, already start (and finish) an implementation in a (draft) pull request and have it reviewed by me or other SC contributors, so it can simply be merged on approval of thenew scheme and can go right into the next version.
2. The implementation would necessarily need to be extended, not replaced. I.e. StreetComplete will have to understand both the new and old tagging, but always (re-)tag to the new tagging. This probably necessitates extensive testing, hence point 1. This effort would be reduced by a lot, really a lot, if this wasn't necessary and StreetComplete could just ignore old tagging. And not only for SC of course, but any other application that parses parking lane stuff.

The overlay as it is now will of course not be paused only because there may be a new tagging scheme on the horizon. The effort to clean it up does not grow from day to day if the clean-up is done with one mechanical edit.
On how to do this: I also haven't done that myself, so I can't help. I would expect to find some resources in the wiki. Maybe @matkoniecz knows?

[westnordost]

And I can help by pointing out the location in the StreetComplete code at which the parsing and tagging is done and answer questions for that.

[tordans]

@westnordost @matkoniecz The proposal is now officially in it's RFC state. It would be great if you could take the time to check it (again) and comment on any issues you see for SC. A statement on "support and planned adoption" from SC as a major editor would help the proposal a lot for it's voting phase.

Such an endorsement could IMO happen here as a comment or on the discussion page.

On the topic of data migration:

We are experimenting with a tool that would help migrating the tags. More at https://github.com/osmberlin/osm-tag-updater. IMO this looks promising…

[matkoniecz]

We are experimenting with a tool that would help migrating the tags. More at https://github.com/osmberlin/osm-tag-updater. IMO this looks promising…

I did something kind-of similar with https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/retag_old_style_parking_conditions_in_Poland

[SupaplexOSM]

For documentation (to not post this off topic in #4664) once again the reasons that currently prevent us from doing a mechanical/automated edit (at least that is how I perceive it):

• We have no experience with this, especially with the development and implementation of a bot.
• A mechanical edit is only reliably possible for the physical level of parking, i.e. the parking:lane schema. The legal level, i.e. the parking:condition schema, was too complex and fuzzy in its actual use, so that it cannot be interpreted objectively in a large number of cases. A mechanical edit would therefore either remain partial (ignore all non-standard cases) or would lead to a split between the physical and legal tagging (renewed physical, but deprecated legal tagging), which is not impossible, but also not desirable.
• Parking has been mapped in the past (before the SC overlay) with noticeable geographic concentrations (i.e. only in a finite number of cities), which makes it more likely that deprecated taggings will be systematically updated. Since in many cases the parking informations are already many years old (5-12 years), a manual check might be appropriate anyway.

Instead, we are preparing some tools that will make it easier for mappers on a local basis to manually update parking informations, if they are interested to do so (Tag Translator, JOSM stylesheet, probably MapRoulette Challenge...). From my own experience I can report that it is possible to update large areas relatively quickly (ok, may not be representative ;-) ).

After some time, we should monitor how the numbers of the old variant are developing and possibly take further action to get them down.