Parking lane quest deletes previous data

[Mannivu]

I've noticed that the parking lane quest (activated via the dedicated layer) deletes the old tags on the way. See for example this way in which SC deleted parking:condition:both:time_interval, parking:condition:both:default and parking:condition:both keys.

[westnordost]

This is deliberate. Whenever the parking has been changed, any subtag may have become wrong, so it is removed. I know, it is unfortunate that there is still no quest in StreetComplete with which the condition can be (re)surveyed, but in any case it is better to delete potentially wrong data then keep it.

E.g. smoothness is also removed when the surface is changed.

[Mannivu]

I understand, but in a case like the one I presented, the only data missing from the way was the parking:lane:both:parallel key, everything else was right. Maybe the app could ask the user to check if the existing data are still up to date (unfortunately, I am not aware if this is possible, so if this can be done, I understand that the deleting of the existing info might be better than leaving potentially right data).

[westnordost]

Well yeah, you know that but the app doesn't. The situation could just as well be that the street (parking situation) was redesigned.

If the user changes nothing, the app also doesn't delete anything (duh!). Asking if the existing data is still up to date would necessitate that StreetComplete understood these condition-tags and it does not understand them (yet) because there is also no quest for it. Also, the OSM street-parking guy (@SupaplexOSM) started to work on a proposal to straighten up the whole parking schema, so (that) parsing of conditions is in flux, too (thankfully, the current scheme is quite bad):

https://wiki.openstreetmap.org/wiki/Proposed_features/street_parking_revision

[westnordost]

Anyway, I am sorry and I acknowledge that this is problematic, but of two evils (deleting too much vs. keeping wrong data) it is IMO the lesser one. As far as I know, @matkoniecz has some half-finished implementation of parking conditions lying around, so maybe there will be something soon to fill that hole.

[Mannivu]

Yeah, I thought the app couldn't (yet) handle this kind of check. Don't worry, I didn't know this was intended, but I understand the thinking behind this behaviour. Manuel, ***@***.*** Il ven 14 ott 2022, 17:57 Tobias Zwick ***@***.***> ha scritto:

…

Anyway, I am sorry and I acknowledge that this is problematic, but of two evils (deleting too much vs. keeping wrong data) it is IMO the lesser one. As far as I know, @matkoniecz <https://github.com/matkoniecz> has some half-finished implementation of parking conditions lying around, so maybe there will be something soon to fill that hole. — Reply to this email directly, view it on GitHub <#4501 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKGEKUDQEBDWBAD6PCDVWXTWDF7FNANCNFSM6AAAAAARFIMSIY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Discostu36]

I think SC should only delete sub tags in case of changing parking lane tags, because then it is reasonable to assume that the other tags are out of date. SC shouldn't delete when it is only adding missing tags because then the most likely scenario is that the parking situation hasn't changed but that the data was only incomplete.

[scaidermern]

I fully agree with @Discostu36 here. Adding so little data while deleting so much is not an acceptable situation:

Sorry for the harsh words but the goal of StreetComplete should be to improve OSM, not to make it worse.

If StreetComplete encounters tags it doesn't understand then it shouldn't touch them. If this might lead to ambiguous tagging then StreetComple should disable this particular quest in this particular situation until StreeteComplete has been improved accordingly.

[westnordost]

You two say different things, yet agree with each other.

[westnordost]

If you only agree in that the current situation is not tenable, then what should be the solution? I somewhat more agree with @Discostu36 here, whatever subtag of parking:...:<side>:* there is, if that side changed, it is not far fetched to assume that this changed also.

Besides, StreetComplete does tag parking:condition:<side> - for no_parking, no_stopping etc. so the rule can't be about what tags StreetComplete knows or not. Also, assuming that ...residents is basically the capacity tag which very likely will never be supported by StreetComplete - if the parking changes, of course that will change too.

[scaidermern]

whatever subtag of parking:...:<side>:* there is, if that side changed, it is not far fetched to assume that this changed also

If a parking:lane:<side> tag changes then dropping all corresponding parking:condition:<side> tag could be an acceptable solution. This is far from optimal, of course. However, dropping all parking:condition:<side> tags just because a parking:lane:<side> tag was added is clearly not acceptable.

[riQQ]

Also, assuming that ...residents is basically the capacity tag which very likely will never be supported by StreetComplete - if the parking changes, of course that will change too.

No, <side>:residents specifies which kind of permit residents need for parking. Usually there are different permits so only residents from adjacent blocks can park in a specific area.

[westnordost]

I ended up changing my opinion about this:

[...] makes me start to wonder if it is really necessary / correct to clear all those subtags if the parking position and orientation changed.

The argument has been that if that changed, likely the street (parking) was redesigned, so anything parking related could have changed. But with this argumentation, we would also need to remove lanes, cycleway etc. as all this is something that could have been changed after a street redesign. So, the argumentation [for clearing everything parking related] is not the same as for removing smoothness when changing surface, as these two properties are directly connected to each other...

...while whatever signs say when/how long/if paid/etc. you may park somewhere just happens to be in the same parking:* tagging space but are separate properties.

see #4549 (comment)

So, I created PR #4552. It...

1. parking:condition is not at all tagged by the parking overlay anymore. This reduces a lot of complexity and makes it easier for the user to just select "no parking cars here / not allowed"
2. no parking subtags other than those tagged are removed/replaced