I’d been recently pondering how to go about tagging street-side parking in my city. If I were to follow the schema according to Street parking - OpenStreetMap Wiki, here’s what but one sole block’s worth of parking tagging would look like:
Broken up into five little chunks, with eyewateringly complicated tagging. Is this really the preferred way of doing it?
EDIT: I just realized I missed tagging the middle section with “parking:left:zone=1537”, and the second from the right with “parking:left:zone=1538”, lol…
Broken up into five little chunks, with eyewateringly complicated tagging. Is this really the preferred way of doing it?
it is possible to add this level of detail, but you don’t have to. One might even argue that we don’t map temporary features, nobody in their sane mind is expecting society to tolerate forever filling up the public space with private vehicles while they are not used, aka parking on public land.
Recently asked a similar question for a street of about 250m long that had orientation sections of first perpendicular, then changing to diagonal and towards the end parallel. In the end found ‘multi’ in TagInfo suiting well for this, no silly splitting (JMO) and for any parking that has all sorts for different sections even difference from left and right side of oneway parking aisles. Used ‘marked’ before but had no real traction so swapped those to multi where I came across those I did before. No mech edit.
If the parking restrictions are very fragmented and you want to map them in this level of detail, then it is possible or even necessary to split it this way. An alternative, especially for marked parking areas, would be to map the parking areas separately. Then you wouldn’t have to fragment the street line and overload it with tags. Both is ok.
By the way, I found some more bugs in your tags
In the two big boxes you use parking:both:restriction=no_stopping @ (...) - but if you use a conditional restriction with @, the key must be parking:both:restriction:conditional.
In the small boxes you use parking:right:restriction:reason=bus_stop in each case. I would either add another parking:right:restriction here, or probably better, just use parking:right:reason=bus_stop, since it refers to the parking:right=no and complements/explains this.
In the bottom of the three small boxes, the primary key parking:left is missing.
Also in the same box, I would either leave out parking:left:restriction=no_stopping or better add parking:left:restriction:taxi=none (because otherwise the no-stopping rule would also apply to taxis).
Almost all boxes are missing parking:*:orientation. In my opinion this is perhaps the most important attribute for parking evaluations (as it indirectly determines the number of parking spaces). Probably its parallel everywhere? But there is no “default” so better tag it explicitely.
The big box on the right says “streetside”, but it should be street_side (maybe just a typo by mistake).
But apart from that, it looks fine. Mapping street parking in this level of detail can be extremely stressful I hope you still have fun! Maybe we have better tooling one day helping with mapping such stuff.
While nothing is wrong with this kind of mapping, the example shows that mapping parking spaces (in this detail) is a kind of data is somewhat costly to maintain.
I guess this applies to many instances of micro-mapping but even more so to data that is added to existing ways, like here, because on a normal map, it is invisible.
Personally, I follow the rule that I do not add data that I’d not be willing to maintain. After all, generally, wrong (because outdated) data is worse than no data at all.
So, if I add street parking data, I usually do not add any more detail than whether they park at all and if yes, 1. where they park and 2. in which orientation. Which incidentally is what you can map with StreetComplete. If the parking is in any way conditional, like in your example, I often do not map it at all because the alternative would be to either spam notes or add a kind of incomplete information that might as well be regarded as wrong (because if just the parking position and orientation is tagged, the default assumption is that the parking there is not conditional).
I think, trying to map street parking data without a WYSIWYG editor that displays all this information (which does not exist yet) is pointless, it’s too much and the potential for error when tagging it manually via JOSM is too high.
Although, your example is not from a residential area. It is from the middle of downtown
The tagging for a real residential area is going to look a lot more boring:
Yes, I did pick a street in the downtown core as my example, because I think it’s more important for street parking to be mapped there than it is almost anywhere else, precisely because there are so many restrictions. That said, what also prompted my question is a somewhat controversial new municipal government policy that homeowners are charged an annual fee for residential parking permits, where permit zone restrictions exist. (Believe it or not our municipal government used to just hand these passes out for free!) There are many parking zones, with varying restrictions block-by-block outside of the downtown core, none of which have been mapped at all. I just thought, “Y’know, that’s probably something that would be quite useful to have mapped…”
Likewise I don’t think it’s worth tagging this info if it isn’t tagged complete with restrictions and conditions, because as you wrote: if the orientation/position is the only thing tagged, the default assumption is that parking there isn’t conditional.
That said, I disagree a bit with your own personal ‘rule’ to not add data that you’re not personally willing (or able) to maintain. Everything on the map is somewhat fleeting; at least in my little corner of the world, old buildings get demolished and replaced with new, roads are demolished and rebuilt with new, businesses close and re-open all the time. I can’t maintain it all myself, so if I followed your rule I’d just not contribute at all. But I’m being a little reductionist and absurd here
I think what you mean in spirit here is that by its very nature these sorts of parking restrictions are easily changed by replacing a few placards on signposts. In reality these parking restrictions are actually quite longstanding; for the exemplar stretch of 5th Ave SW between 5th and 4th Street, other than the implementation of automated plate reader enforcement and the use of parking zones in place of curbside meters about 15 years ago, the underlying no-parking and no-stopping restrictions have been there for as long as I can remember (20 years or more).
That said, I disagree a bit with your own personal ‘rule’ to not add data that you’re not personally willing (or able) to maintain.
Well, I mean the kind of data, not the specific data I contribute in particular.
E.g. I do map opening hours but I do not feel inclined to make sure all opening hours I ever contributed are up to date. That would be ludicrous. I just make sure that I not only add opening hours, but also update them if I notice that they are wrong. (All with StreetComplete, which basically takes care of the updating part.)
(because if just the parking position and orientation is tagged, the default assumption is that the parking there is not conditional).
the default assumption is fine but where it doesn’t hold I would add access=no access:conditional=yes@… because it breaks on the safe side if you don’t evaluate the conditional tag
It’s up there with public transport - very detailed schemas requiring so much effort that even if someone does map it, nobody then bothers to maintain it (anecdotal evidence, YMMV, I’ve tried the old parking lane schema and gave up when the new one came out).
It’s not made easier by the fact there is only one proper editor for it (that I know of) - Parking lanes viewer
I just stick to nodes/areas, especially since parking=street_side has taken off
In my view, the overhaul of street parking tagging has made it possible to map street parking as separate areas without tradeoffs, by unifying how access and time restrictions are tagged in parking lots versus on streets versus at a single space. Backwards compatibility is not as much of a concern because so few data consumers are relying on this data for “mission-critical” purposes at this time.
I think we’ll ultimately find that many of the localities where sidewalks and crosswalks are mapped as separate ways will also have street parking mapped as separate areas, because the local community will be comfortable with large-scale micromapping. At the same time, non-drawing-centric editors like StreetComplete and Every Door will probably find it more convenient to prompt users for details to tag on the roadway, which mappers can move to separately drawn areas in a second pass.
