I’m currently mapping all the parking conditions in my suburb, and I noticed that there is a grey area when using parking:<side>=separate, because it doesn’t say what the parking conditions are outside the separately mapped areas: no_parking or no_stopping in case of Germany.
So the question is: are you actually using parking:<side>=separate, and if so, what would you consider the rest of the street to be parking-restriction-wise?
Or are you just setting parking:<side>=no + parking:<side>:restriction=no_stopping/no_parking when mapping parking spaces separately?
Translates to “No stopping anytime, for both sides of the road, including turning circle, except for marked areas”.
So the whole street is parking:both=no_stopping, except for the amenity=parkings that I added. But should I use parking:both=no_stopping or parking:both=separate?
In contrast to this, living streets in Germany are no_parking, except for marked areas. Again: in case of separately mapped parking spaces, should I use parking:both=no_parking or parking:both=separate?
In both cases, parking:both=separate feels wrong, because you lose the distinction, but what then is the use of it?
I’m only going from this wiki page, but as it describes separate parking:<side>=* and parking:<side>:restriction=* options then I would expect that you’d do both parking:both=separate and parking:both:restriction=no_stopping as the first tag is the physical description and the second is the legal restriction. The separately mapped bays could then have their own legal access defined for clarity.
We wouldn’t be including the sign’s caveat about marked spaces on the road but we would have it recorded in the spaces which seems reasonable.
I don’t see this option listed on the wiki, I think this is only a parking:both:restriction value?
In regards to your question proper: I guess it is a fluent transition when one should still use separate and when no.
It helps to see it from the data consumer’s point of view. separate means that yes, there is a parking, but it is mapped separately. So, data consumers interested only in a lower level of detail, not wanting to process all those separately mapped areas, could interpret these as “yes, parking”. Data consumers interested in the full details interpret these as similar to “no parking”, to not count these twice.
The distinction between no and separate is thus only really useful for the former group, hence if the number of parking spaces in your example road is so small that it is almost “no parking” then I’d tag parking:<side>=no, even if there are a few parking spaces after all. In al other cases, I’d use separate.
You can also split up the road if there are sections with no parking at all.
In diesem Falle ja. Aber in verkehrsberuhigten Zonen z.B. gilt Parkverbot, außer in markierten Bereichen. Wir haben davon einige, wo auf 150m nur insgesamt 3 einzelne Parkplätze kommen, da muss ich einzeln erfassen.
My understanding has been that parking:<side>:restriction=* implies parking:<side>=no, because it describes that “why”. If the common agreement is that I can map
then I’m happily going to use it. I don’t see the current documentation agreeing with it, though, and I fear that QC software will point this out as a tagging mistake.
I think that’s something I can agree with. So if the majority of the road is no parking/no stopping, with just an occasional spot where it is allowed, setting parking:<side>=no. I think I’ll take that for now.
In that case, it’s 5 marked parking spots along a 200m road. So not really feasible. And of course some are left, some are right …