Simpler approach to start with?
I find this too complicated already. Why don't we hijack parking=* for highway=*s, and take it from there? I don't think the specific shape of the parking spots is particularly interesting in itself, but restrictions are more more important, like vehicle size, time of day, maximum stay, etc. parking=* could grow a couple more values, plus we could use other keys already in use for amenity=parking. In it's most simple form, parking=yes would indicate that some form of parking is explicitly allowed. --Stefan Bethke 21:08, 31 May 2009 (UTC)
- I'm just playing along here with what the original proposer came up with; that's likely the better choice for the main key. Alv 21:31, 31 May 2009 (UTC)
- This is exactly what I have been searching for! Tags like parking:left=inline would be great to mark some parts of a street with parking possibilities without having to tag an area for this. Additionally, I would propose some tag like parking:left=bay if there's an area that goes along with the street but is separated from it in some way (e. g. little areas with trees between) and clearly designed to be a parking area. --L3u 18:44, 30 March 2010 (UTC)
- I'm definitely in favor of a simpler approach like described. what do others think and how should we proceed? --Marc 13:50, 17 December 2009 (UTC)
- This is relevant to the newer proposed format with
parking:lane:*, too. IMO rather just
parking:left=*etc. Alv 07:42, 28 April 2010 (UTC)
- Is it possible to map parking signs, rather than parking lanes? The signs could indicate left/right/both sides of road, forward/back/both, and sign content? Sign content could be added progressively (as data), or as text alone? Maps could render the sign contents, for instance forward to the next sign. In some instances a sign might relate to a whole town, like a speed limit, or only a street, like park two hours. The benefit of this approach is to more simply map only signs and let logic and renderers do all the interpretation work. When we map areas, we are doing the heavy interpretation lifting with brain power, not computer power. This approach could be used for speed signs. Maps the signs, not the road that the signs apply to. For instance, the 30 signs in the parking photo examples. areff2000 04 February, 2011
- Use case. (1) I am interested in using the parking data and OSM to make a 'Free Parking' app for iPhone. I could interrogate OSM based on my current position and current (or future) time and day to find parking space which have no parking restrictions (within displayed map). Alternatives would include one or two hour parking. (2) Disabled parking spaces should be priority to map and discover. areff2000 04 February, 2011
What about mixed parking situations?
Especially in residential areas you'll often find a mixed situation with both parallel and perpendicular parking lanes mixed on each side of the street that cannot properly be described with the existing keys in your proposal (parking:lane:XY) unless the street is splitted into dozens of individual segments. I suggest to add an additional key parking:lane:mixed or something similar to handle these situations easily. --@themis 19:04, 9 March 2011 (UTC)
time_limit vs. maxstay
- That's a good idea, and I adopted it onto the main proposal page. Kay D 19:55, 27 April 2010 (UTC)
right / left ?
Besides the possible confusion between right ( opposite of left ) and the right ( as authorisation ) , the
use of right / left makes only sense if the direction of the road is known. Except for one way streets this is not obvious and may be changed deliberately or by accident.
I therefore propose the use of absolute geographic directions like north, south, east or west. Fx99 06:52, 23 May 2010 (UTC)
- Which then isn't unambigous for curved roads, depending on the angle of the turn (say, up to 180 degrees). In all editors the direction of the way element is shown to the user, and some editors even propose to change :left to :right when the way with such tags is reversed. Also, where the map is sufficiently complete that mappers have the time and energy to map these parking restrictions, the direction of any (highway) ways in the area is very unlikely to be reversed anymore - as they more often are in areas where users are just sketching in the roads on a blank canvas. Alv 08:28, 23 May 2010 (UTC)
Migration to parallel and perpendicular
I suggest to do a one-time complete transition in the database, converting all instances from
parallel etc. Normally this is not a desirable solution to perform (people should decide whether to adopt a better scheme), but in this special case I suggest this handling because:
- There is only a limited set of usages of the tags in quesion
- Only a limited number of users contributed yet to the scheme
- It is only a change in spelling, not in function or interpretation
- The migration is a 1:1 change, no information is lost or weakened
- The new spelling is more intuitive and will facilitate people to adopt the tags.
There are currently (to my knowledge) only two tools that handle these tags:
- The JOSM-Presets (by Ij) will be provided in the updated form (thanks, Ij!)
- The mapnik stylesheet on parking.openstreetmap.de will be changed by myself.
Kay D 12:20, 12 September 2011 (BST)
This proposal should be merged into already approved one
Although i like the ideas in this proposal, there is already approved proposal which addresses very similar situation Proposed features/parking so I think it is not good idea to have different system for parking lanes and parking sites. I also think that the approved Proposed features/parking can benefit from some of the ideas raised here, so we can incorporate some ideas to that one. Let's find which are the cases in which the approved one can benefit from approach on this page. --Jakubt 23:02, 17 August 2011 (BST)
Isn't splitting up ways for the sake of parking problematic for finding cross streets?
This might not be exclusive to parking, but in general, isn't splitting up a way between two intersections problematic for finding ways comprising a stretch on a street between intersections later? For example, in the diagram on the right, I might want to "find all parking tags on 'On Street' between "Cross Street 1" and "Cross Street 2". Finding nodes N2 and N5 is easy, because they're at the intersections of the two cross streets, but determining that "way3" is part of that stretch becomes hard, especially if you add more different parking sections than just way2, way3, and way4 between the two cross streets on the main street.
Is this a common problem with Openstreetmap? Maybe even the reason why you can't search for a location between two cross streets with the Nominatim API? If anyone here has any pointers as to how to solve this problem, that'd be great. Thanks in advance.--Schmike 01:01, 26 September 2011 (BST)
- Ways are split for various reasons, "midblock" or even several intersections apart, whenever the lane count, speed limit, surface, street lighting etc. change. It's true that there could be a need for a more sophisticated, ready-to-use preprocessing tool to mangle the data to a structure better suited for, for example, the use case you mentioned. Such tool could, for example, split each way at every intersection, if not already split, and add (in their local database) a tag to each such way indicating which cross streets cross at the ends. Then the necessary ways would be, for example, selectable with simple SQL. With some coding it doesn't then matter where and how many times the ways are split. As to searching, you'll have to ask at Talk:Nominatim. Alv 16:20, 3 October 2011 (BST)
currently there are only german pictures and examples in the proposal. i think you should use more international examples (USA, japan, …). this way mappers from other countries could better identify with it, which again should broaden the acceptance of the proposal --Flaimo 15:56, 14 January 2012 (UTC)
- I see exactly two images and no Germany-specific examples. If complain would be more specific then maybe something could be changed, but maybe it simply referred to an ancient version of that page Mateusz Konieczny (talk) 11:07, 14 July 2020 (UTC)
Marker on map
Is there any chance to set markers to your parking map? I want to use it on our page (http://hackerspace-bamberg.de/Anfahrt) to show our guests where we are and where to park. Thanks four your help. Spicewiesel 07:10, 18 January 2012 (UTC)
Sides on two way roads
I'm trying to figure out what means left on a two way residential road. I can think of endless cases where such a road allows parking only on one side. One could assume left and right should be according to house numbering. But then again, you have Japan where no such thing exists. So what's the startpoint of a residential road? This ambiguity could be partly addressed with north/east/south/west, but has been quickly dismissed above, without giving a usable alternative or explaination. I suggest documenting more explicitly how to use this key on two way roads. --Keystorm 21:06, 22 November 2012 (UTC)
- Every way on OSM has a way, even a two-way street. You can check it on the arrows icon on Potlatch toolbox, for example. --Nighto 21:13, 22 November 2012 (UTC)
- The answer is also given in the Wiki: Forward_&_backward,_left_&_right. Kay D 12:34, 2 January 2013 (UTC)
parking.openstreetmap.de render server is dead
- As the values remains inside OSM data you can use a custom map done with uMap called Parking OSM whenever the OSM data about parking conditions exists . --yopaseopor 11:17, 19 August 2016 (UTC)
- The best web app to show and also edit parking lanes to my knowledge is https://zlant.github.io/parking-lanes/ --Tordans (talk) 06:47, 3 November 2018 (UTC)
- Seems resolved, dead link is removed Mateusz Konieczny (talk) 11:02, 14 July 2020 (UTC)
Just make sure it's flexible enough
The possibilities of left, right, and centre parking are all independent of each other, and are going to need to be specified separately. I can think of a location near me that has all three, and certainly the restrictions are different in two of them.
(Although now that I think about it, a street with centre parking is usually modelled as two separate ways...which makes it complicated to decide which of those ways owns the centre...) Stevage 15:41, 3 December 2009 (UTC)
In France some streets have alternate side of allowed parking depending on the day in the month. The first 15 days of the month you need to park on one side, the rest of the month you need to park on the opposite side. Julien Balas 15:15, 15 april 2010
parking-slots mapped as area
Where should also be an possibility to tagg parking-slots as an area, because in some areas also the streets are mapped as an area. I think amenity=parking should be tagged and parking=lane. --Aighes 14:51, 28 April 2010 (UTC)
Wie ist der Rest?
Was ist mit einer Zone, wo parken nur in erlaubten Flächen erlaubt ist? Die erlaubten zu taggen ist ja klar. Aber was ist mit dem Rest? So?
--ChristianKnorr 11:09, 15 April 2010 (UTC)
- Just use
=no_stopping. Trying to put non-parking-zones into the database is quite difficult otherwise: Polygons are not the correct thing to do so (they are only 2 dimensional and fail for situations with bridges). So for the moment I just propose to tag each street with no_parking for whatever reason it is not allowed to park there. And in the end, a user (navi) of the data does not really care why he is not allowed to park... Kay D 21:39, 29 April 2010 (UTC)
Thinking about this a bit, are we sure the default should be no parking? Maybe the default could be parking=both, and we could tag parking=no for highways where parking is not allowed. Anthony 01:11, 24 October 2009 (UTC)
- I think yes, it should be no parking. local law is what the user should know before parking, no matter what OSM or any navigation service based on OSM is telling him. If parking is allowed he can put his car everywhere he wants. Even so there can be dedicated parking spots or at least streets that are manly used for parking by locals whereas others are not, although law would permit it (but you just don't put your car everywhere, even if you could). And thats what we should map: some sort of "common sense" used by locals / visitors of the region. By setting the default to no we encourage the community to map parking spaces that are explicitly used by residents / local population, regardless of if they are marked on the street or not. If indeed all the streets in city are used for parking, then map it like that, as long as it does make sense to do so. but most times it just doesn't. the other argument is rendering: useless if the default is yes. I would say the default is "no" in the sense of law tells you what to do. areas marked with explicit no parking signs can be tagged with no (therefore an explicit tag exists, and a renderer can interpret that by adding the corresponding style to a street), streets with parking allowed with yes/both/left/right. --Marc 14:01, 17 December 2009 (UTC)
- Default is not mentioned anywhere, and anyway what is considered as default depends on a data consumer and their needs. I just implemented code that assumed that in case of not tagged parking lane status highway=tertiary/residential/living_street has 90% of chance for parking lane (for A/B Street traffic simulator) Mateusz Konieczny (talk) 11:22, 14 July 2020 (UTC)
- marking as resolved as default is not mentioned anywhere Mateusz Konieczny (talk) 06:12, 20 October 2020 (UTC)
In the UK especially a restriction of no waiting is very common in urban areas, denoted by a single yellow line down the side or the road, a sign or both. It's more permissive than no_parking and no_stopping but less so than parking, specifically it allows loading/unloading, picking up/setting down passengers but not parking ie leaving the vehicle for an extended period (occupied or not) beyond for those purposes. In a way it could be considered to be a short stay parking situation as it is timed usually to a maximum of 40 minutes unless stated otherwise however there is a caveat namely that it must be obvious to the parking enforcement officer that the vehicle is in the process of loading or unloading and that the goods are too large or heavy to carry (ie it may not be simply for convenience) so just tagging it as short stay parking seems inappropriate. I don't know about other countries but this restriction is highly common in the UK, no on all roads by all means but common enough I think there should be some way to tag it.
Any ideas, could we include no_waiting into this proposal? MttJocy 23:10, 4 November 2011 (UTC)
- From the discussions around these parking tags, it has become apparent that in different countries there are different views of what is considered parking; mainly, whether a vehicle standing still for any other reason than loading/unloading (or due to a traffic obstruction, naturally) is always parking, or not. As to allowed use that you describe above, at least in Nordic countries that is just the case we consider "stopping"; car is standing still for loading/unloading people or goods, at most for the time it takes to carry the stuff to the intended destination, or to the car. If you have to wait for a passenger, then you're parking - technically it might be at the very start of the wait, but in practice anything from few seconds to few minutes is legally ok depending on the location and the traffic. The enforcement officers will hang around for like five minutes anyway if the loading case seems plausible, so if you're carrying stuff somewhere you'll get back to them in time for them to cancel it right away. There's a rough guideline, that if you have to pay for the object you're loading before you carry it, it's not allowed "stopping for loading" anymore. And, on the other hand, if you're moving home, the car could be in a no_parking section for a full hour or more legally. Some places that have cars frequently waiting for passengers then feature parking places with a maxstay of 5 to 15 minutes. Alv 15:10, 5 November 2011 (UTC)
- I realise this is rather 'late in the day', but to set the record straight: there is no such thing as "no waiting" (distinct from no parking) in the UK. MttJocy seems to have got confused by a number of unrelated matters.
- 1. Signs historically used the term 'no waiting' (rather than the diagonal barred blue circle used today) to mean 'no parking' so the legal definition is the same.
- 2. A single yellow line (in the gutter) means no parking but with restrictions that fall short of Mo-Su 00:00-24:00 (ie: there are some times in the week when you are allowed to park)
- 3. Markings on the kerb which indicate loading restrictions.
- 4. I have no idea where the 40-minute limit concept has come from. Loading/unloading is self-explanatory.
- Should you wish, you can check the UK Highway Code to verify this - The section on road markings is the most useful.
- If, as is common in most settings, there are no kerb markings and no signs saying otherwise, you can legally load/unload on a single- or double-yellow-line, even though 'parking' is not permitted. The only exception is the normal common-sense thing about not causing an obstruction, which is implicit in all these tags anyway. In some larger cities, single- and double-red-lines are common: these ban both parking and stopping. In short: The existing tags already cover this.--CunningPlan What's on your mind? 08:31, 3 August 2014 (UTC)
- I'm not sure but if that's valid for all countries, but I'd draw the line in those edge cases betweend "do I leave the car unattended" or not. I.e. when I find myself being an obstacle, am I able to depart right away. Then I'd say I was only stopping. I think this is also the definition of "loading": staying next to your car so that others see that you are able to move along "real soon now". Even in German, the law says it is parking (as opposed to stopping) when you "leave the car" (and is as vague as English language leaving it open whether that means "go out of the car" or "go away from the car"). -- Kay D (talk) 04:51, 5 August 2014 (UTC)
Parking in the center lane
- This is a good question on the concept of center in OSM in general. Many other linear features, such as flush median / marked island (no physical barrier separating) or shoulder=* on roads, could use this new side suffix. More detailedly, because the center isn't consider a lane, tagging of properties in the space between unsegregated lanes could be explored. In the meantime, perhaps use amenity=parking_space? I can find that Talk:Tag:amenity=parking_space#parking:lane had concerns, but I would think it is a difference in detailedness on line vs area mapping, and there's no worked out detailed area mapping of roads yet. -- Kovposch (talk) 08:22, 19 March 2020 (UTC)
- If there is a parking lane in the middle, the roadway is de-facto split into two one-way parts much like a dual carriageway. So, I'd split the direction up in two directions and then either map the parking lane in the middle as a parking-area or use the parking:lane scheme accordingly --Westnordost (talk) 14:10, 7 December 2021 (UTC)
- I mark this as resolved because there is a way to map this situation without the necessity to think about how to improve this scheme --Westnordost (talk) 14:23, 7 December 2021 (UTC)
No parking and no stopping examples for around the world?
It would be helpful to have some examples (with pictures) what makes an area no parking and what it makes no stopping. I recently learned that in the UK, apparently two yellow lines demark a no-parking (or no stopping?) zone: https://en.wikipedia.org/wiki/Yellow_line_(road_marking)#Single_yellow_lines --Westnordost (talk) 20:23, 16 November 2020 (UTC)
In the U.S., parking restrictions are more reliably signposted than marked on the ground. MUTCD/R#R7: Parking, Standing, and Stopping lists a number of standard U.S. parking signs and their tagging equivalents (or just as commonly, big question marks). Some of the other traffic sign indices may be relevant too. – Minh Nguyễn 💬 10:47, 17 November 2020 (UTC)
|In Japan, signposts for parking restriction are almost everywhere in urban streets. The lower one means |
Parking, stopping, and standing
This article currently states that no_parking is "Equivalent to 'loading zone' rules in the United States" and that no_stopping is "Equivalent to 'no parking' rules in the United States". Not only is this equivalence counterintuitive and extremely likely to be mistagged by Americans, but I'm not sure that it accounts for all the distinctions commonly made on curbside parking signage according to the MUTCD:
fire_lane sounds possibly appropriate for the "No Stopping" sign, but this isn't intuitive either, because some jurisdictions put up signs that explicitly say "No Parking: Fire Lane".
The documented values originally came from this page, then given as examples based on these standard German signs, and finally glossed for an American audience. Here's my best attempt at detailing the specific actions allowed or disallowed under each German and U.S. sign:
|Driver may…||Stop for passenger||Put vehicle in Park||Exit vehicle||Load/unload goods||Turn off ignition||Leave vehicle|
|Documented values based on German signs|
|Standard federal and state MUTCD signs|
|No Parking Fire Lane||yes||yes||yes||yes||no||no|
|Passenger Loading Only||yes||yes||yes||no||no||no|
|No Stopping Fire Lane||no||no||no||no||no||no|
- “What is the difference between No Parking, No Standing, and No Stopping?”. New York State Local Technical Assistance Program. Ithaca, New York: Cornell University Local Roads Program. June 15, 2021. Retrieved August 8, 2021.
- Rubel, Abigail (January 5, 2020). “No parking vs. no standing explained”. Times Union. Albany, New York. Retrieved August 8, 2021.
- “California Vehicle Code Section 463”. California Legislative Information. California Legislature. Retrieved August 8, 2021.
- I added "no standing" to the wiki page. The others not (yet) because maybe this should/could be solved with the reason-tag --Westnordost (talk) 14:12, 7 December 2021 (UTC)
How to distinguish between on_street and street_side?
It's not obvious to me how to decide between parking:lane:side:parallel=on_street and ...:parallel=street_side. I assume it's on_street if the kerb is completely straight for the whole block. What changes would make it street_side? If there are bulb-outs at the corners? If there are trees in the parking lane in the middle of the block? If there's a gutter between the parking and the travel lanes? --Jeffrey Yasskin (talk) 21:20, 18 July 2021 (UTC)
- Yes to all those. on_street is the implicit way of mapping parking=lane, and street_side is the implicit way of mapping parking=street_side — that is, you either use parking:lane=* or draw the actual parking areas with a suitable amenity=parking type and tag parking:lane=* as separate; the choice is yours, but the documentation for those two has more information on when to use them which applies to parking:lane=* as well. The first paragraph of parking=street_side explains:
- Area suitable or designated for parking, which is directly adjacent to the carriageway of a road — either single parking areas (often only for a few vehicles) or chains of "bays" or "pockets" alongside the roadway which, in contrast to parking lanes, are structurally designed and therefore regularly interrupted by structural elements like curb extensions or islands for street furniture.
- Also with on_street (or parking=lane) it is generally possible to change the parking into a lane for driving (or cycling) with minimal changes: remove the parked cars and any minor barriers like removable bollards from the street surface, then change the road markings and signs. With street-side parking it is generally necessary to remove trees, kerbs, bits of sidewalk, crossing driveways, traffic signs, utility poles, lamps, fire hydrants, et cetera as well. --JeroenHoek (talk) 06:49, 19 July 2021 (UTC)