iD incorrectly tries to convert old to new parking scheme

[wielandb]

I noticed a lot of streets in my vicinity started to pop up in the StreetComplete parking overlay as "no data", and after investigation, I found that the iD suggestions do incorrectly and/or incompletely convert the data, leading to information loss and corrupt data.

Examples:

https://www.openstreetmap.org/way/1039535438
https://www.openstreetmap.org/way/1053141214

Suggested action:

iD should not try to convert the old to the new street parking scheme. (Or there needs to be much more sturdy rulesets)

[tordans]

This is probably from #1390. can you spot where the rules are wrong?

[wielandb]

From what I could see so far (and citing from my own ruleset for my maproulette challenge):

• The parking position seems to get lost on some more occasions, but I'm not sure if it's consistent
  • painted_area_only (becomes on_street with additional tag parking:<side>:markings=yes)
    • Instead it gets converted to a generic "yes" and the parking position is lost
  • half_on_kerb should become parking:<side>=half_on_kerb
    • but instead just becomes yes and the parking position is lost
• A conversion should not happen if additional tags from the old parking scheme, especially conditions and restrictions are present and not also converted

I will try to dig into the concrete rulesets and try to suss out a solution.

[tordans]

TBH I wonder if we should just remove the rules again. The schema update is quite complex and it will be hard to build rules that are more right than wrong…
Other ways to update the data like your MR challenge are the better approach IMO.
Btw, did you test the new MR integration in Rapid? Unfortunately they don't support fix tag challenges, yet (see facebook/Rapid#1340). But for regular challenges this integration is really useful.

[wielandb]

I would be in favour of removing the rules too, if we cannot make them work properly. I will try my best to understand how the rules work.

Btw, did you test the new MR integration in Rapid? Unfortunately they don't support fix tag challenges

I guess you mean cooperative challenges in general, not TagFix Challenges specifically.
I have not dabbled in other cooperative challenges yet, and I did not know Rapid has a MR integration. 😳 But didn't iD also once considered implementing something like that? (that = beeing able to load .osc files into the editor)
It would certainly be useful!

[tordans]

But didn't iD also once considered implementing something like that? (that = beeing able to load .osc files into the editor)

openstreetmap/iD#10758 is the issue on adding MR to iD (based on what Rapid did)
openstreetmap/iD#10407 is the PR about adding external data to iD directly. You can test it at https://kyle.kiwi/iD/ AFAIK

[matkoniecz]

@tiptoptom are you capable of fixing this?

[tiptoptom]

The problem is that we don't change all the tags. https://osmlab.github.io/osm-deep-history/#/way/1039535438

parking:lane:both=perpendicular gets converted to parking:both=yes + parking:both:orientation=perpendicular
but parking:lane:both:perpendicular=painted_area_only remains as it is instead of getting parking:both=lane + parking:both:markings=yes

Is there a way to not do the conversion if there are additional tags from the old parking scheme?
if yes: I think we could add exceptions
if no: It would be best to remove the rules, as otherwise it will become even more complex.

[tordans]

if no: It would be best to remove the rules, as otherwise it will become even more complex.

AFAIK this is the way forward. And then use some other tooling to update the data.

[wielandb]

And then use some other tooling to update the data.

Like e.g. this challenge by myself. ;)

[wielandb]

I have created an updated version of the file in wielandb@b970a31 that would at least solve my first point, but not my second one.

Would it be a preferrable solution nonetheless?

[matkoniecz]

in order of preferability, in my opinion:

1. working replacement that does not cause errors

2. no replacement all

3. broken replacement

[tyrasd]

fixed in #1849 by removing the respective tag deprecation rules