Talk:Tag:amenity=parking
maxspeed ?
Some carparks have speed limits (usually in Germany: 10km\h or 20km\h). I think this could be a useful tag for this item.--MapperOG 23:23, 19 May 2008 (UTC)
- sounds reasonable. Seems that you would probably put maxspeed=* on the ways within the lot, though, like on the parking_aisle. —Fudoreaper 21:19, 2 April 2009 (UTC)
Parking streets
What with the streets along which there are parking places (with sign of parking etc.)? They are quite long so there is no point in marking them per-node and thin so area also is not correct option. --Uzytkownik 23:34, 12 August 2008 (UTC)
- At the moment streets are tagged with ways, not areas. Everything on or along the street, which is tagged with ways, could be tagged only als additional tags to the highway tag, at the moment. --HoH 00:17, 13 August 2008 (UTC)
- What about introducing a new tag parking=left|right|both for streets that have dedicated parking lots at the sides? --ThyMythos 20:58, 10 June 2009 (UTC)
- That's not enough. There are parking lanes, cycling lanes, footways and lines of trees. Left/right does not help to bring them into order. --Lulu-Ann 06:29, 11 June 2009 (UTC)
- I'm supporting the parking=left|right|both proposition. I don't understand the previous objection, since we consider here only parking slots alongside the road. We don't need a very precise mappingof the different lanes, only a conventional rendering way for the road, which indicates a parking amenity all the road long. This would be very useful, for by the moment the only way is to draw a long and narrow parking area alongside the highway. It's time-consuming and not robust. I think that this discussion could be followed on the Roads page... Gall 20:40, 27 September 2009 (UTC)
- We do need very precise mapping of the different lanes, at least for OSM for the blind. --Lulu-Ann 07:01, 28 September 2009 (UTC)
- So you are saying that we need very precise mapping of car lanes for the benefit of the blind? I agree that for footpaths etc, careful mapping for the blind can be good. But for driving? parking=no makes sens for streets. As does parking left/right/both, but as usual such lateral tagging is prone to errors when a way is reversed etc. It needs support in the editors, maybe it already has. Norpan 11:55, 28 September 2009 (UTC)
- We do need very precise mapping of the different lanes, at least for OSM for the blind. --Lulu-Ann 07:01, 28 September 2009 (UTC)
- I did not talk about driving. I was talking about parking lanes, where blind persons often break their white canes in car wheels or damage cars, because they do not know there is a parling lane. I agree that any lane proposal needs to be supported by all editors, as soon as we have one that works! --Lulu-Ann 14:42, 28 September 2009 (UTC)
- There is a proposal parking lane. --Scai 22:24, 15 June 2010 (UTC)
- I did not talk about driving. I was talking about parking lanes, where blind persons often break their white canes in car wheels or damage cars, because they do not know there is a parling lane. I agree that any lane proposal needs to be supported by all editors, as soon as we have one that works! --Lulu-Ann 14:42, 28 September 2009 (UTC)
Exclusive disabled_spaces
How should we mark parking areas where all spaces are reserved for holders of disabled parking permit? disabled_spaces=exclusive is an option, but since they usually are quite small the number of spaces is also interesting. How can we combine this? --Cohan 09:04, 4 September 2008 (UTC)
- Just had an idea: this could be accomplished by using parking=disabled and disabled_spaces=number --Cohan 09:06, 4 September 2008 (UTC)
I faced this problem a few days ago. I think there should be some better solution, maybe we should create a feature proposal. I used capacity=0 disabled_spaces=2, but i don't think it's pretty. Pauluzz 21:53, 12 July 2009 (UTC)
- Well done. It does not have to be pretty, it has to be easy, and it definitely is. --Lulu-Ann 12:17, 15 July 2009 (UTC)
- I have changed it to capacity:disabled so we have the same scheme for all special spaces. Can somebody do a bot run, please?. --Lulu-Ann 12:44, 19 August 2009 (UTC)
- so how do I map exclusive parking areas for disabled people now? The manual says capacity="The amount of parking lots available. (Including all special parking spaces e.g. disabled spaces) Read talk page on this." but talk page says "capacity=0 capacity:disabled=2" (which I find more helpful, as anyone searching particulary for a disabled parking lot may use the subkey but anyone searching for an ordinary parking lot will see capacity 0 and won't have to start calculating with capacity:disabled, capacity:parents, capacity:whatever to get a total of ordinary parking lots). --Jot (talk) 06:32, 20 April 2013 (UTC)
- I have the same question. The discussion below explains why it makes sense to set all places in capacity. Si I could set capacity=5 and capacity:disabled=5, and smart people would understand that only disabled persons can use this parking... But I am afraid many software will not be that intelligent and might display this parking without the proper warning. Therefore I prefer not to map the parking at all for now, since the information might be misleading to most users.
- Maybe this problem could be solved with an access=disabled tag or a disabled=yes/notdisabled=no pair of tags (similar to subway=no/bus=yes for a public transportation station), which could be also used elsewhere (e.g. on the way that leads to the parking or on some elevators). Thbz (talk) 15:29, 15 April 2015 (UTC)
- so how do I map exclusive parking areas for disabled people now? The manual says capacity="The amount of parking lots available. (Including all special parking spaces e.g. disabled spaces) Read talk page on this." but talk page says "capacity=0 capacity:disabled=2" (which I find more helpful, as anyone searching particulary for a disabled parking lot may use the subkey but anyone searching for an ordinary parking lot will see capacity 0 and won't have to start calculating with capacity:disabled, capacity:parents, capacity:whatever to get a total of ordinary parking lots). --Jot (talk) 06:32, 20 April 2013 (UTC)
- I have changed it to capacity:disabled so we have the same scheme for all special spaces. Can somebody do a bot run, please?. --Lulu-Ann 12:44, 19 August 2009 (UTC)
- Well done. It does not have to be pretty, it has to be easy, and it definitely is. --Lulu-Ann 12:17, 15 July 2009 (UTC)
Count disabled spaces in capacity?
Please do not count disabled spaces in the ordinary capacity, as they are not available for ordinary drivers, and therefore they are not of interest for them. --Lulu-Ann 21:17, 23 July 2009 (UTC)
- It was clearly defined to include all spaces before you changed it. Shouldn't you maybe discuss this first? (There is currently a discussion on talk-de, for example, which was why people noticed the change (see "Nur Rollstuhl-Parkplatz" in the list archives).) --Tordanik 21:51, 23 July 2009 (UTC)
- I am not used to discuss changes that are obviously an error in the data model - sorry - , but I am happy to tell you that there was only agreement on that change. Nobody is interested in the sum of parking spaces. You obviously only search for one kind, except you are in the minority of drivers of not walking disabled persons (blind...), who can choose to park on both kinds. If you are disabled, you depend on the lowered curb and the short way to the entrance, if you are not, you don't want to be guided to a capacity=0, disabled=1 place. --Lulu-Ann 13:40, 24 July 2009 (UTC)
- But why negate/cripple an accepted tag like capacity, that by the meaning of the word stands for all available spaces, and not, when this fact is so important, add another tag like normal_spaces?--Landwirt 14:35, 24 July 2009 (UTC)
- This is not "crippling" an accepted tag, this a a correction of a not atomized data field. Read "Normalization", "1st normal form" and "atomic" concerning databases on wikipedia. It has beed discussed on the talk-de mailing list and it was agreed that the sum of different kinds of parking spaces are not of interest for disabled persons and not for not disabled persons. Btw, disabled persons are normal persons. Check your wording, please. I agree that having a new tag would be nicer. Any suggestions? Standard_spaces? --Lulu-Ann 18:10, 27 July 2009 (UTC)
- I see a reason in tagging the overall-capacity with capacity. If you have for example satelite-pictures of the parking-lot you will only be able to see how many spaces there are (you only see the sum). Another possibility is, that you counted the spaces but did not take notes about special-spaces. In this concept: If you have a parking-lot with capacity=10 and nothing else you know there are parking spaces, but there is no data about disabled-spaces. if you have capacity=10 and capacity:disabled=0 there are no disabled-spaces but 10 normal. If capacity was the number of standard-spaces, then my first example would mean there are no spaces for disabled, but 10 normals. This is not how tagging is done in reality, because sometimes you want to tag a "don't know" and therefore we should avoid to normalise in this case.
- What about "Reserved" spots? A carpark may list itself as having 529 normal spaces, 9 mobility (disabled) spaces, and 340 reserved spaces (not available to the public, but staff of specific businesses). In this case, is the total capacity 529+9=538? Or 529+9+340=878? Gobeirne 20:22, 2 January 2011 (UTC)
- I would map this as a two parking lots: One with 529+9 and another with 340 with access=private. --Lulu-Ann 16:59, 3 January 2011 (UTC)
- I agree. Reserved parking spaces are not really interesting to most others and don't count as available parking spaces anyway, so one should probably not sum them up. --Scai 12:30, 7 January 2011 (UTC)
- I would map this as a two parking lots: One with 529+9 and another with 340 with access=private. --Lulu-Ann 16:59, 3 January 2011 (UTC)
- I just wanted to point out that in JOSM, when using the parking preset, the capacity key is titled "Capacity (overall)". Chtfn (talk) 03:51, 31 August 2013 (UTC)
Parking Slots
Number of spaces seem to commonly be tagged as parking_slots. For disabled mayby disabled_parking_slots=XX ?
--Alexm 12:35, 27 September 2008 (UTC)
- Is this relevant? I mean, I am always interested in the number of FREE parking slots, but never in the number of parking slots that exist. --Lulu-Ann 11:09, 30 September 2008 (UTC)
- It might be relevant for urban planer and even for rendering: The rendering of a parking should depend on the number of parking-slots on different zoom-levels.--KartoGrapHiti 15:02, 3 November 2008 (UTC)
- OK, good argument! I agree. --Lulu-Ann 18:03, 22 November 2008 (UTC)
- Yes, it also makes sense in a strange place if you want to guess what lots might have the most space. Also, if the parking is underground, or multi-story, it's hard to get a sense of how large the lot is in 2D view. Also thinking, can we tag the number of levels of parking, in underground or multi-story arrangements? Buildings, too... —Fudoreaper 21:00, 2 April 2009 (UTC)
- OK, good argument! I agree. --Lulu-Ann 18:03, 22 November 2008 (UTC)
- It might be relevant for urban planer and even for rendering: The rendering of a parking should depend on the number of parking-slots on different zoom-levels.--KartoGrapHiti 15:02, 3 November 2008 (UTC)
type=multi-storey and building=yes?
If we have a multi-storey parkade, is it also a building? Or is that only fur human occupancy structures (protection against the elements, etc.) In Canada most of our multi-storey parkades do not really have walls, and provide only basic shelter from the elements, and certainly not against the cold. However, underground parking lots are generally heated, and do have walls. So, do we mark these as some kind of building? Ideas? —Fudoreaper 21:16, 2 April 2009 (UTC)
- They're all buildings -- Harry Wood 21:24, 16 October 2010 (BST)
Motorcycle
Being able to tag motorcycle parking bays would be quite useful for UK mapping. Often motorcycle bays are free for motorcycles and are quite difficult to find. Njd27 15:36, 31 July 2007 (BST)
- See amenity=motorcycle_parking Aharvey (talk) 00:45, 20 September 2017 (UTC)
Fee and Restrictions
Proposal for tagging the fee value
In cities like San Francisco, it may be common to find paid parking lots with wildly different rates, across the street from each other. I imagine that urban dwellers would be interested in tagging the $10/hour lot vs. the $3/hour lot.
Can we define some tags for how much parking costs?
And how about different tariffs for different lengths of stay. e.g.:
eek! Personally I can't actually be bothered to tag this, but those who like devising super-complex tagging schemes ... knock yourself out :-)
-- Harry Wood 21:36, 16 October 2010 (BST)
fee only during the day?
Especially in bigger cities, it's really interesting, when I can park for free (often at night) - how long I can part in the daytime with a parking meter or how much one hour is. Maybe we can already tag - also when osmarender and so on the information not using yet. --Dktz 19:06, 11 March 2008 (UTC)
In germany small parking-lots in the city are often free only outside of business hours (e.g. fee time Mo-Fr 9-18 o'clock , Sa 9-13 o'clock). Such a parking-lot is neither fee=yes nor fee=no - any suggestion how to tag this? GeoJ 08 Jul 2008
- May be value of fee as in opening hours (like fee=9:00-20:00) --LEAn 09:11, 8 July 2008 (UTC)
- Yes, it would be simplest to use the same syntax as with the Key:opening_hours as the value of the fee key. So the acceptable values would be: fee = yes/no/<interval>.
Please see also the proposal for lane parking where time intervals for fees (or other things like residents-only parking) are defined in a similar way. --Kay D 20:47, 2 May 2010 (UTC)
- I would rather use fee:conditional=* using conditional restrictions syntax - it keeps value of fee tag usable without extensive processing Mateusz Konieczny (talk) 22:20, 8 February 2018 (UTC)
- Agree with Mateusz Konieczny, fee:conditional=* using conditional restrictions syntax is much for flexible and many possible conditions are already extensively documented in the syntax, compared to simply using fee=<opening_hours>. For example,
- * customers may have different restrictions compared to the public (Free to park fee=no, except Mo-Fr 09:00-17:00 fee:conditional=yes @ (Mo-Fr 09:00-17:00), unless you're a customer then no fee, fee:conditional=yes @ (Mo-Fr 09:00-17:00); no @ (customers)), or
- * no fee under 2 hours, fee after 2 hours stay fee=yes + fee:conditional=no @ (maxstay < 2 hours).
- --Aharvey (talk) 05:14, 14 May 2022 (UTC)
pass/not public ?
In this area there are a variety of parking structures which charge a fee, but will waive the fee with appropriate validation from a local merchant. Is there a way to tag this? -Fennecfoxen 18:50, 19 February 2009 (UTC)
In Latvia we have some parkings that are dedicated for shop clients/firm visitors only or are allowed to park if you have pass.
May be we can use someting like public=yes/no ? Ursus 10:02, 4 June 2008 (UTC)
- Use Key:access for this --LEAn 09:12, 8 July 2008 (UTC)
Parking restrictions
In Sweden, the parking signs often have restrictions. These are of a standard form. Look under additional plates. This is useful information to tag. As you can see, the restrictions can get quite complicated. So, how to add multiple additional restrictions? A lot of the above questions, if not all, fits into this system. Norpan 01:18, 18 November 2008 (UTC)
Distinguish car park/bus park
How to indicate that a parking is only for busses (/trucks/...). And how to indicate that it is only for busses on weekdays from 8 to 17:00 and also for cars on other times?
- This should be handled with the access restrictions framework motorcar=no+bus=yes. Varying vehicle type with time should be handled by extending the access restrictions system, not here. --Hai-Etlik 09:51, 14 January 2011 (UTC)
- It seems for a user looking at the map, the name field needs to mention that it is a bus parking lot too. Else without consulting air photos, a parking lot with 500 buses will look like one with 500 cars it seems. Jidanni (talk) 23:55, 8 November 2023 (UTC)
Disc parking
How should we tag Disc parking (german: "Parkscheibe")? I see the following possibilities:
- disc_parking = yes General information that a parking-lot requires a parking disc
- disc_parking = 1.5 Parking-lot requires a parking disc and the maximum parking time is 90 minutes (one and a half hour)
GeoJ 13:39, 15 August 2008 (UTC)
Perhaps these should be extended to show all the different parking types e.g.
- parking:payment=free
- parking:payment=pay_and_display
- parking:payment=pay_on_return
- parking:payment=pay_on_exit
- parking:payment=permit
- parking:payment=disk
The time limits could then be specified in the following format:
- parking:max_duration=90
- parking:no_return=120
Kevjs1982 12:17, 8 August 2009 (UTC)
- What to do if the the first 1H30 stay are free but after this you have to pay 4.60euros after the second hour 5.60 after the third hour 9.40 and if you lost your ticket you have to pay the max 9.40?--Yod4z 22:00, 15 September 2010 (BST)
pay by mobile/phone
I'll crosslink a mailing list discussion by Paul Berry on tags for paying by mobile/phone (website, app, automated phone system) for car parking. But EdLoach points out there's already a scheme here too: Key:payment#Payment via phone
-- Harry Wood (talk) 13:52, 1 August 2016 (UTC)
I'd like to start adding the app needed for payment. I can't see any progress after 2 years. 'payment:app' appears 45 times, but only with 'yes'.
--May jay wiki (talk) 10:56, 20 August 2018 (UTC)
company parking
I disagree that company parking should not be mapped. If you have access to the data, go ahead and map it, and tag it so that it's clear that it's not a public car park. access=private or access=no or whatever. If the renderers or some routing application doesn't respect this, fix it. Robx 06:51, 12 June 2008 (UTC)
Agree. I have also tagged our company parking places ([1] Ford in Cologne) because there are many business people around which might want to know where they need to go in order to park their car.
But I had an issue with "private" and "no" access. Unfortunately Osmarender draws an ugly red grid on those areas. But I would really prefer a different symbol for restricted parking sites. Anyhow we need to have additional ones for Park & Ride and such stuff, maybe also for multi-storey car parks.
My temporary solution is that I have removed the access tag and provided a name to the area ("Ford" in this case) which shall tell the user that it´s not public. Apart from that those areas are mostly part of the industry area around it - another hint that it´s not public. --Krza 22:00, 9 July 2008 (UTC)
I agree that company or semi-public parking should be taged. Visitors of these companies (or public autorities etc.) need this information. We migth need a special icon for public/non public. Until we have a special icon, I would recommend to tag private parking wih access=private.--Makracht 16:46, 2 November 2008 (UTC)
I guess we even need a difference between company parking for employees and for visitors! See VW in Wolfsburg. --Lulu-Ann 15:44, 17 November 2008 (UTC)
- For "customer parking only" I'm using access=destination and (for example) operator=VW. Is it common enough to add to the page itself? Alv 07:09, 26 March 2009 (UTC)
have been thinking along similar lines to Krza's, Makracht's and Lula-Ann's comments above would like to be able to tag a parking area as to the type of user, with the hope the renderes could indicate the difference on the maps. i.e. public free parking, public charged parking, private company and visitor parking, parking for shoping area/outlet (am tagging as parking=shop for time being) parking for tourist attraction (how about parking=tourism to tie in the tourism=value tag)
- Some good ideas here. I definitely agree that all car parks should be tagged, whether public or not. Otherwise, how would you indicate the land use? I think it would be nice if the renderers could reserve the white-on-blue P for public car parks, and some other muted colour scheme, e.g. white-on-grey, for other types. I'm going to use the access=private tag for all types of restricted parking until there's a better policy. I'm not sure about the access=destination idea. Perhaps that would be better reserved for highways. --Jeff 12:23, 29 August 2009 (UTC)
Time Limits?
How can I map limits for the parking time?
Like: Max parking duration: 4 hours.
How can I map a limit of 4 hours for parking during Mon-Fri 08:00-18:00? Outside of Mon-Fri 08:00-18:00, there is no limit. I have also seen signs where different limits apply for different periods, with no parking permitted during other time periods.
- A simple time limit can be tagged as maxstay=4 hours.
- For the more complex variants, try Conditional restrictions. Your more complex example would look like this:
maxstay:conditional = 4 hours @ Mo-Fr 08:00-18:00
- --Tordanik 14:40, 3 May 2014 (UTC)
Garage complexes?
How does one properly map a garage complex where people from surrounding blocks-of-flats keep their cars? While they are private access features, they are certainly huge landmarks and they are quite abundant in former Soviet states, thus marking them would make sense. landuse=garages? amenity=garages? amenity=parking access=private?
- What about building=garage? It will be compatible with current use of building tag and also semantically right. --Vrabcak 17:34, 28 July 2009 (UTC)
- I suppose building=garage is incorrect because usualy this is area with separate garages. example. Usualy this area belong to garage cooperative with own chairman, budget, rules, etc. Each garage cooperative has hame and number. I suppose we should use landuse=garages or amenity=garages for this. --Kos32 07:39, 7 August 2009 (UTC)
- Depending on the country and area probably so: in other areas they're multi-storey buildings (there's even a documented value of parking=multi-storey), number of levels varies from two to several. For your example picture I would first draw an area (the whole of it) as a amenity=parking + access=private (foot=yes if applicable) - the whole area is still for private parking. Once there's time to do more detailed work, add two buildings (building=garage) on both long sides (the back walls share nodes with the parking area edge) and a highway=service + service=parking_aisle (+foot=yes) in the middle. It would be possible and exact to draw each garage as an individual building and sharing the inside walls, but that seems overkill for quite some time. It can be deduced that a 6 meter wide but long building tagged as a building=garage has separate spaces for each car.Alv 08:10, 7 August 2009 (UTC)
- landuse=garages is suggested as new feature. Please see Proposed features/tag:landuse=garages -- Zkir 21:43, 12 September 2009 (UTC).
- I suppose building=garage is incorrect because usualy this is area with separate garages. example. Usualy this area belong to garage cooperative with own chairman, budget, rules, etc. Each garage cooperative has hame and number. I suppose we should use landuse=garages or amenity=garages for this. --Kos32 07:39, 7 August 2009 (UTC)
Operator
Should we be tagging the operator? This would allow those with permits allowing discounts/pre-paid parking in car parks owned by a specific operator to find them easy - e.g. "Find car parks operated by NCP near here" Kevjs1982 12:20, 8 August 2009 (UTC)
- If known and significant, yes. Some use the tag operator also to indicate which shop the parking belongs to, for example with access=destination operator=Tesco, where the operator is not a part of some parking specific company. Alv 09:58, 9 August 2009 (UTC)
Parking on top of buildings (rooftop parking) and multi-level parking (parking garages)
Just my thoughts on how these should be tagged and rendered:
Rooftop parking (parking where at least the top level of the structure has parking) or free-standing multi-storey parking structures
amenity=parking and parking=multi-storey OR amenity=parking and bridge=yes
This would result in a parking area being rendered with a black border, similar to how bridges are rendered by Mapnik.
Buildings which have parking but doesn't have parking on the top level of the structure) amenity=parking, parking=multi-storey and building=yes
This would be really helpful when mapping shopping centres, which often have multiple levels of parking scattered around with numerous bridges, service roads intertwining everywhere with buildings all mixing in. The current rendering is unrealistic for what is actually really there, and gives a distorted picture to what the scope of the actual area is in relation to the rest of the map. --Lakeyboy 09:11, 11 August 2009 (UTC)
- Please do not use bridge=yes only to get a special rendering. Because of multi_storey does not fit the rooftop parking, why not propose a new tag with parking=rooftop. Then it could be rendered as you want.--Vsandre 10:19, 15 August 2009 (UTC)
Thanks for the advice. I will propose this new tag on the wiki very soon. --Lakeyboy 01:24, 19 August 2009 (UTC)
Do not use parking=park_and_ride
The key parking=* defines what is the physical structure the parking amenity, not it is used for. In my opinion at park and ride place you could park in a multi-storey or a underground car park or at the surface. The possibility to use a park and ride service is better placed in a separate tag, see Proposed_features/Park_and_Ride--Vsandre 10:19, 15 August 2009 (UTC)
Do we need parking=one-storey?
Until now it is not used, so I reverted the insert to discus it. We does not have multi-underground or one-underground, so do we need a one-, two- or multi-storey differentiations. I think it would be better to use tags such as level=30 and level:multi-storey=1.--Vsandre 11:17, 19 August 2009 (UTC)
Long term/Short term/Visitor
How to tag the difference between long term and short term parkings? They are often located differently at airports, long terms might be far from the airport with a separate coach service. Same also how to tag dedicated visitor parking on i.e. hospitals, where there are defined visiting hours, and the parking area must be emptied outside such hours? Short Term and Long Term parking is often defined by the length of the stay, usually if you have to stay over more than one night you need to park on long term. Some short term does not allow overnight stay. Also the form of payment can be different, and long term is almost always attended. --Skippern 00:29, 20 August 2009 (UTC)
- Suitable combination of maxstay=*, fee=* (some prefer charge=*) and opening_hours=* are widely acknowledged. Some use the combination access=destination + operator=Example Hospital for visitor dedicated spaces. Alv 07:47, 20 August 2009 (UTC)
Neither public nor private car parks
Either I'm not looking hard enough or there isn't a feature to mark a car park as 'patrons only'. Things like garden centres, supermarkets, pubs, etc. have car parks that aren't public (but aren't private) and are to be used only for those visiting specific places. Would access=destination suffice?; could one do something with relations, perhaps? Kevin Steinhardt 11:25, 17 October 2009 (UTC)
- Some or many are using just that, access=destination, possibly with, for example, operator=Coton Orchard Garden Centre. There's no support for that in any any software, yet, but it should be enough to store the data. Depending on the location and local customs some add a foot=yes, too. Alv 11:34, 17 October 2009 (UTC)
parking area and service highways
One thing bothers me since Keepright started complaining about it several days ago: is it necessary to interconnect the amenity=parking area with the service=parking_aisle ways leading to/from the parking area or is it sufficient to draw them just above the area? Either way, this should also be mentioned in the wiki.
I wonder if routing engines need this information or not. On the one hand, they need to know how to reach the parking area, so interconnections help by simply combining those two objects. On the other hand, a simple connection does not give any information whether the route leads to or from the parking space and even using the center of the parking area as a hint does not help, because the center may be even outside the parking area. So I guess, the whole area needs to be looked at in any case. So, is it necessary to combine them or not? :) --Scai 12:59, 19 August 2010 (BST)
- While it's in a way more elegant presentation to share a node, no one has reasoned why it would be necessary. As with house addresses, navigators generally find the point closest to the destination on the nearest road as the routing destination, which should work without them sharing a node. Especially if the parking_aisles are drawn. Alv 09:37, 23 August 2010 (BST)
Individual parking spaces inside parking lot
The current parking concept with "amenity=parking" does not cover individual parking spaces inside parking lot/carpark. Being able to tag individual parking spaces would help e.g. to support disabled people looking specifically for such amenities. It seems obvious that this requires another tagging scheme, like "parking_space=<normal|woman|parent|disabled|bus|yes>". What do you think? --Geonick 21:55, 18 October 2010 (BST)
- i second that. with high res bing images available you can actually make out single parking spaces and if they are for disabled/women/parents. example: http://www.bing.com/maps/?v=2&where1=Leonding%2C%20Austria&q=leonding&cp=48.27099606257206~14.267918989063988&lvl=20&encType=1
- maybe amenity=parking can still be used to map those (for backward compatibility), but it would require some sort of relation to bundle those single spaces together. this relation could also hold metadata for all the common properties the single spaces have (like fee, covered, surface,…). renderers could then use this relation to render only one "P". Flaimo 14:55, 17 February 2011 (UTC)
- I'm all for this as well. In addition to indicating where disabled/parent/etc spots are located, it also enables tagging individual spaces with a reference number as some lots have. I'd say using a relation to tie them all together makes since, to avoid hundreds of P's :). Also, for the reference number issue, it might be helpful to have a range of numbers that get interpolated. However, for my interest in tagging parking spots in a residential area, the numbers are certainly not in ascending order, which forces me to tag each spot individually. And for those haters who thinks this is a waste of time, at least it's our time we're "wasting" :). See micromapping. - Joshdoe 18:59, 7 March 2011 (UTC)
- i started a proposal for mapping parking spaces grouped together using relations: it's basically RFC: http://wiki.openstreetmap.org/wiki/Proposed_features/parking -- Flaimo 22:13, 17 March 2011 (UTC)
- proposal has been approved. i have included a brief description on this wiki page. --Flaimo 09:33, 2 May 2011 (BST)
Lay-bys: simple roadside parking for taking rests
Many roads which are not motorways in the UK have places to park alongside them marked with a blue parking "P" sign, called lay-bys, or unhyphenated: laybys. This is what's called a "turnout" or a "pullout" in the US, according to Wikipedia. The idea is that it's a quick place to stop and rest on a long journey on older style roads; many can be quite large to accommodate lorries (trucks), and some feature coffee or fast-food stands. They're fairly unremarkable things, but their locations are noteworthy. I dare say they're not especially international.
Without getting embroiled in the previous argument about these things, and not seeing them as long enough to be called "lanes", it seems to me the simplest thing to do when tagging these is to just place a node at the appropriate side of the road and tag it thus:
| Tag combination | Meaning |
|---|---|
parking=layby |
Any problems with this? I stuck with the UK form of the word in the end since it is the most common value for "parking intended for taking brief breaks from driving" in taginfo at present.No it isn't - see below! --achadwick 14:33, 31 October 2011 (UTC)
--achadwick 00:18, 30 October 2011 (BST)
- What about highway=rest_area? Is there any difference between those two? Should both tags be applied? --Scai 07:58, 30 October 2011 (UTC)
- Good spot! They're exactly the same thing, and I've edited the page you linked to reflect it. There may be cause for mentioning the parking-ness of the things as well: see Talk:Tag:highway=rest_area. --achadwick 14:33, 31 October 2011 (UTC)
- I disagree - 'lay-by' and 'services' are the commonly used terms in the UK and in actual fact a 'rest area' in Europe is usually more akin to 'services' - as per the wikipedia page referred to above. To me a 'rest_area' would at least imply some sort of facilities (benches, toilets) seperated from the main highway so I don't think it should be used for basic lay-bys.
- I would prefer to use amenity=parking parking=lay-by as above, and if it is actually seperate from the main highway then you can map that and add highway=service service=lay-by (note singular service not services). -- PealRinger 02 November 2011
- Then we differ in opinion. They are identical in meaning as described in the docs for highway=rest_area. "Rest area" is the more descriptive term, and is arguably more international than "lay-by", which is a parochial term even if we use en_GB most of the time here. GCIDE states "[Chiefly Brit.]". We are of course referring to a hierarchy of provision here: at bottom merely an area to stop your car and rest void of services, at top something similar with lots of services provided in addition. Having them both use the same key is probably a good thing.
- From your wikipedia link describing the situation in Europe, only France and Germany are mentioned. Both the French and German terms make the distinction between large service areas and small rest areas (Aire de service/Aire de repos, and Raststätte/Parkplatz). Neither of course use the English term, but we can use translations. However, this is equivocal; literal translations are Aire de repos==stilling,rest,stop area (supports me because this is the smaller), but raststätte==rest,break place,location (supports you because this is the larger). (Source: wiktionary's translations and my schoolboy French/German). I think we should let the Aussies name our tag; they have more need for the things, after all!
- BTW, both are established in JOSM, and get the cute blue [P] icon ☺ However I fear that making these very minor things use the same tag as potentially very large parking structures may create problems for users and rendering rule writers. If the lay-by doubles as a more formal, long-term car park for something, then you have the option of adding amenity=parking to it, which is more expressive. Finally, highway=rest_area is an order of magnitude more established then your proposed refinement to (presumably) amenity=parking.
- In the end, I'll use what's most popular in the DB; see below. --achadwick 13:42, 4 November 2011 (UTC)
| parking=layby | highway=rest_area |
|---|---|
- The first mention of highway=rest_area on this wiki (that I could find now) is only from [June 2011]. Someone would need to check if it comes from JOSM presets older than that. At least here they are signposted as parking areas, sometimes with a, say, 24h maxstay limit. Hence I've been (and other mappers, too) just using amenity=parking, with the picnic_table and other amenities drawn individually. These come in different sizes and mapped to various levels of detail: from what looks like widened road shoulders with room for several cars, to small areas with a small service road through it (similar but bigger), and plain parking areas by the motorway, or even bigger areas with more structured driving routes, be it with a cafe, or without. All these tag can coexist, until something makes use of them. Alv 15:42, 5 November 2011 (UTC)
- highway=rest_area seems to have been introduced in [changeset 3526], dated 2010-09-14.
- I'd say there's scope for combining it with amenity=parking, either on the same object or by tagging an enclosed object as amenity=parking. But probably only if you can meaningfully park for non-rest_area type reasons - being able to leave your vehicle unattended for an extended period, perhaps. That's based purely on an intuition that more interesting mapped spaces demand more layers of meaning in their tags. Rest areas by themselves are not very interesting. Would that be a suitable criterion (I suppose you'd have to add, is that what everyone means by "parking-ness")? --achadwick 16:59, 8 November 2011 (UTC)
Charging station
Is there a key to identify a parking place where you could charge your electric car, while stying there? This is related to Charging station --Dariopnc (talk) 10:37, 13 May 2013 (UTC)
how to tag underground multi-storey parking?
How to tag a parking which is underground but on many different floors?
Should it be tagged parking=underground or parking=multi-storey ?
Is parking=multi-storey intended for overground parking only?
At the moment there is no description at all for these two values. (I mean in the table in the page about amenity=parking ) -- AnyFile (talk) 16:23, 6 May 2014 (UTC)
residential underground parking
Should we really map private underground parking lots for residents? I was looking for playgrounds and came across one in Mapnick that was marked witha "P" instead of the usual kids on a seesaw. Only going into edit mode I found that there was an amenity=parking/parking=underground/access=private mapped right underneath the playground. Since these parking lots are strictly for residents only and are no landmarks visible for anyone (except the entry/exit ramps) I suggest to omit them. Any thoughts? -- TZorn (talk) 11:49, 5 January 2015 (UTC)
- I do agree that the area of an underground parking shouldn't be mapped (at least not with amenity=parking). We already have the tag amenity=parking_entrance to indicate the existence of underground parking. --Jgpacker (talk) 12:26, 5 January 2015 (UTC)
- Public underground parking should definitely be mapped with an amenity=parking area imo. It could be argued that only mapping the entrances makes sense for private facilities (and of course we often don't have more information than that anyway). However, I believe that this is ultimately a rendering issue, not a data issue. --Tordanik 22:27, 8 January 2015 (UTC)
Capacity question
I was adding the capacity:disabled on some parking lots near government offices, then came across this issue: some of these lots are mostly for employee parking, but also have some public parking. What would be the best way to tag the public parking capacity? Just "capacity", or capacity:public, or...? Neuhausr (talk) 18:38, 29 January 2015 (UTC)
- In this case, would it be possible to draw different polygons for the private parking area and the public parking area? --Jgpacker (talk) 19:02, 29 January 2015 (UTC)
- In some cases it might be possible, but it would be a pain to survey and trace. In others, like a new multi-story ramp, that seems pretty unwieldy. To me, it seems more important to let people know that there are spaces available at a lot and how many, and less so exactly where the spaces are within the lot. Neuhausr (talk) 20:52, 30 January 2015 (UTC)
stop mentioning type=site here
According to what I found type=site is poorly described, rarely used, unsupported and overly complicated tagging method. In addition "it should not be mapped a second time using amenity=parking" contradicts its proposal.
I propose to remove "The type=site relation can be used with site=parking to group parking spaces(...)" paragraph from this page Mateusz Konieczny (talk) 12:11, 24 July 2015 (UTC)
- To me, it would already be an improvement if the "it should not be mapped a second time using amenity=parking" was removed. But if we can agree to remove the recommendation of the site relation entirely, all the better. --Tordanik 12:19, 24 July 2015 (UTC)
- As the author of the accepted (!) parking_space proposal I find this discussion pointless, since the purpose of the proposal was to offer a mapping alternative for complex parking areas where simple areas cannot be used and relations are needed. If you still like areas better you can use the old/classic way of mapping parking areas, just not in combination with amenity=parking_space. Please read the proposal from start to finish again Flaimo (talk) 23:41, 25 July 2015 (UTC)
- I removed recommendation to remove amenity=parking Mateusz Konieczny (talk) 13:20, 24 July 2015 (UTC)
- As an area? It may be a rough guess at first, and can still be improved later once a mapper has surveyed the facility in person. --Tordanik 13:05, 24 July 2015 (UTC)
- Okay. I guess that is a solution. The thing is that currently it ends up looking kind of weird like this: http://www.openstreetmap.org/#map=19/43.31192/-1.90735 but I guess that is just a rendering problem that can be fixed. I therefore support removing the information about type=site. --K1wi (talk) 13:43, 24 July 2015 (UTC)
- Also, using type=site would not help with that rendering problem Mateusz Konieczny (talk) 13:50, 24 July 2015 (UTC)
- Okay. I guess that is a solution. The thing is that currently it ends up looking kind of weird like this: http://www.openstreetmap.org/#map=19/43.31192/-1.90735 but I guess that is just a rendering problem that can be fixed. I therefore support removing the information about type=site. --K1wi (talk) 13:43, 24 July 2015 (UTC)
- And maybe mention multipolygons, these have nearly all of benefits of site=parking (possibility of marking disjointed areas as one element) without drawbacks Mateusz Konieczny (talk) 13:20, 24 July 2015 (UTC)
- As the author of the parking_space proposal I find this discussion pointless, since the purpose of the proposal was to offer a mapping alternative to simple areas. If you like areas better you can use the old/classic way of mapping. Just not in combination with amenity=parking_space.
- That requirement to use a relation is completely arbitrary, though. Mapping parking facilities as areas is perfectly compatible with mapping individual parking spaces. The relation adds nothing to that. --Tordanik 15:27, 26 July 2015 (UTC)
- There are cases where areas are not feasible and that's what the relation (and the whole proposal) is for. If you can map it as a single area you don't have the need to map individual parking spaces anyway. In this example a simple area would span across two streets and buildings: http://wiki.openstreetmap.org/wiki/File:Mapquest-mockup.png. Those things where discussed at length during RFC.
- Therefore the description on this wiki page is fine as it is. If someone wants to use the new mapping scheme, he can follow the link to the proposal for more information, but don't encourage a mapping style that is contrary to the proposal (which you approved BTW). Flaimo (talk) 20:33, 26 July 2015 (UTC)
- Handling cases like that two-part parking area is the job of multipolygons. And there are a lot of reasons for mapping parking spaces (such as 3D rendering or finding disabled parking). What do those have to do with site relations?
- And yes, I agreed to the proposal because I liked the idea of parking space mapping. Unfortunately, this was coupled with the pointless relation requirement, which I did already criticize back then. That was 4 years ago. So perhaps we could finally agree to fix that and move on? --Tordanik 09:08, 27 July 2015 (UTC)
- You can map whatever you want, but don't change the wiki. The wiki describes the outcome of a proposal and/or the current overall way of mapping a certain element, not how some mappers would like it to be. As a seasoned member I thought you knew that. Flaimo (talk) 15:01, 27 July 2015 (UTC)
- Wiki describes both proposals and real tagging. Mateusz Konieczny (talk) 19:02, 5 August 2015 (UTC)
- You can map whatever you want, but don't change the wiki. The wiki describes the outcome of a proposal and/or the current overall way of mapping a certain element, not how some mappers would like it to be. As a seasoned member I thought you knew that. Flaimo (talk) 15:01, 27 July 2015 (UTC)
- I've checked, and a majority of amenity=parking_space elements are not part of a parking site relation. So it seems the current overall way of mapping is in conflict with the wiki page. Coupled with the fact that the reason for the relation was weak to begin with, that's a very good reason to change the wiki. --Tordanik 16:45, 5 August 2015 (UTC)
- I overhauled Relations/Proposed/Site. Site=parking is accepted. Rather than removing, better improve documentation! If parking_space is left aside I find nothing complex in 5 nodes and a relation to describe an underground parking garage. Of course it should not be accompanied by a separate amenity=parking area. The only discussion point in my eyes could be to use amnity=parking instead of site=parking on the relation--Jojo4u (talk) 07:44, 12 August 2015 (UTC)
- Most of the other ways of tagging on this page should be moved to [Parking].--Jojo4u (talk) 07:53, 12 August 2015 (UTC)
- As of August 2015, the site relation is omitted in most cases. -> what do you mean by that? That sounds like it could be used in parallel, but I think you mean that amenity=parking as an area is much more common than type=site+(site=parking/amenity=parking) relation?--Jojo4u (talk) 14:21, 12 August 2015 (UTC)
- What I mean is that most parking spaces in the database are not grouped together with a site=parking relation. So basically, you can do it, but it is not the norm.
- My addition is unrelated to the following sentence about using an area and a relation together. I still believe that said sentence should be removed, and that the prohibition to use them both together is in no way justified by the proposal vote, but imo that's a separate issue. --Tordanik 16:50, 12 August 2015 (UTC)
- Even if the use of multipolygons for surface parking would work, you still need a way to group entrances for underground or multistorey parking together to one logical parking site. Those are cases where you often don't know the physical dimensions of the parking facility so you cannot do that with multipolygons. That is also one of the reasons I used site=parking consistently for all three kinds of parking possibilities. This is easy to remember: amenity=parking → old/simple way of mapping parking areas; site=parking → New/detailed way of mapping parking areas. Suggesting a totally different way for just one of the three major cases would unnecessarily complicate things. So if you think that for surface parking multipolygons can be used too, we could add that to the description, but that doesn't invalidate site=parking and therefore doesn't justify it's removal from the description on the wiki page. Flaimo (talk) 20:06, 12 August 2015 (UTC)
I firmed up the language in the relevant paragraph, while still leaving the reference to the "new" parking page in. Following discussions in https://github.com/gravitystorm/openstreetmap-carto/issues/1678#issuecomment-123814281 and https://github.com/gravitystorm/openstreetmap-carto/issues/2032#issuecomment-176689194 , and also based on a quick scan of the current (rare but very varied) usage of type=site to see if I needed to render it (for my own use). --SomeoneElse (talk) 12:20, 29 January 2016 (UTC)
Multi-level underground parking?
There is no tag for multi-level underground parkings. In the article it is said that parking=underground is: One level of parking in the basement. So what do we use for multi-level underground parkings? Should we change the definition of parking=underground? --K1wi (talk) 11:42, 9 April 2016 (UTC)
- Map multiple areas, one for every level? It would be obnoxious to edit, but I see no better solution Mateusz Konieczny (talk) 20:57, 9 April 2016 (UTC)
- Currently this should be tagged with parking=underground - the change to one level is quite recent from 2014-12 and probably without much thought. I see no reason to restrict this tag and removed the wording until this is sorted out.--Jojo4u (talk) 10:55, 10 April 2016 (UTC)
Access
I think access=private should be the default, although perhaps not for parking:lane. In the real world, when a parking lot is observed, it is assumed to be owned and accessed privately, unless specific signs indicate otherwise (for example "Public Parking" signs.) The OSM data should work the same way. --Mtc (talk) 14:49, 24 August 2016 (UTC)
maxheight
maxheight=* is often important if the parking is restricted for larger cars. It is already commonly used with amenity=parking, even though its not mentioned on the wiki page. Are there any votes against to endorse the usage here on the wiki page? Hakuch (talk) 12:09, 4 April 2017 (UTC)
- If these maximum heights are signed or otherwise legally enshrined, I agree. Otherwise, I would prefer maxheight:physical=*. --Tordanik 23:04, 4 April 2017 (UTC)
clarify what area should include
Maybe it would be a good idea to explicitly mention what amenity=parking area should include? Jest place where vehicles park? Also access roads? Entire parking area (footways between rows of cars, trees on the parking lot, grass between rows of cars etc) Mateusz Konieczny (talk) 17:01, 10 November 2017 (UTC)
- My practice to draw one outline of everything dedicated to the purpose of parking. For a large shopping centre carpark, this includes the parking_aisles, the service road for accessing the parking, but excludes the area of the service road for the delivery entrance. It includes the narrow green stripes with trees that separate parking rows, but excludes the green areas around the feature. It follows the one feature - one element paradigm, so I prefer not to split a parking area for one shopping centre (unless it is physically separated, such as in front and in the back).--Polarbear w (talk) 19:39, 10 November 2017 (UTC)
- This is what I typically do, too, although I could see excluding the greenery using a multipolygon as valid. (There isn't really a good alternative that I know of, and subtags such as surface=* of the parking area don't apply to it.) --Tordanik 18:08, 13 November 2017 (UTC)
- Punching internal greens out with multipolygon is unnecessary IMHO, as they are part of the car park. Such as a pond in a leisure=park is part of the park and does not need to be excluded. --Polarbear w (talk) 18:45, 13 November 2017 (UTC)
- Well, I think I agree with that in principle. In that case, surface=* be treated pragmatically as the main surface type instead of applying to the whole area. In fact, that's already what we assume when the parking aisles have their own surface tags, so perhaps the root of the issue for me is that there's an established tagging for ponds and roads, but not for parking space greenery... --Tordanik 20:21, 13 November 2017 (UTC)
- Punching internal greens out with multipolygon is unnecessary IMHO, as they are part of the car park. Such as a pond in a leisure=park is part of the park and does not need to be excluded. --Polarbear w (talk) 18:45, 13 November 2017 (UTC)
- This is what I typically do, too, although I could see excluding the greenery using a multipolygon as valid. (There isn't really a good alternative that I know of, and subtags such as surface=* of the parking area don't apply to it.) --Tordanik 18:08, 13 November 2017 (UTC)
I have seen a paved car parking lot area mapped so as not only to include its entrances/exits but to terminate at (and include as its boundary one or more nodes of) the service road. It followed its parking_aisle to this intersection, "to the T," if you will. The motivation behind mapping like this would be to consider the aisle as a proper subset (relation) of the car parking area, whereby it would be contradictory to say that the parking (aisle) extends beyond the boundary of the (car) parking. To remedy this thought problem, one may say that the parking_aisle should end at the last parking_space and be continued there as a service road. In any case, should car parking areas ever connect with the streets that contain (or otherwise help to define or shape the boundary of) it at these entrances/exits? The answer to this question (or similar ones about the relation between parking ways and areas) may help in answering the question to what area amenity=parking should include.
I’m going to try and document the three primary ways I have seen surface parking lots mapped in OSM.
1. Map the entire area associated with the carious entrances and exits into and out of the parking, up to the kerb and up to the adjacent road area (whether or not the road area is mapped) as one contiguous closed way.
2. Map the parking lot area associated more restrictively with the parking lots themselves. Think of the parking aisles and their associated entrances.
3. Map the parking area either nearly or entirely associated exclusively with the parking lots themselves.
I am more of the opinion that the first definition is most accurate parking mapping available, however we could define a number of cases that would help extend/shrink the possible parking area. A common example I can think of (in the U.S.), is the drive-through. Making it clear whether or not the area associated with service=drive_through should be incorporated into the parking area, may dramatically increase or decrease the parking lot area. IanVG (talk) 21:26, 28 June 2022 (UTC)
I'll try traffic_calming=island for the islands. Jidanni (talk) 00:07, 22 November 2022 (UTC)
- No, they are usually not qualifying for traffic-calming in terms of lateral deflection. area:highway=traffic_island is the general one. --- Kovposch (talk) 07:25, 22 November 2022 (UTC)
Example image
The example should already be in the new rendering form. Maybe you can update it? Or we make a map but I don't know where it is. --geozeisig (talk) 17:55, 19 November 2017 (UTC)
- I agree it could be updated. Besides current rendering, the example does not make clear why there are multiple areas mapped. Basically you could crate a map shot from any larger shopping area, as long as it is correctly tagged (major service highways for access and parking_lane between them). I'd prefer a static shot over a live map view, since it prevents somebody mistagging the map automatically spoiling the example. --Polarbear w (talk) 23:02, 19 November 2017 (UTC)
- Do you know a good example? An example would be IKEA but it may be too confusing. I would prefer live map view because it stays current, but you are right that did not change a picture so easily.--geozeisig (talk) 08:00, 20 November 2017 (UTC)
- Well, it is an example for tagging mistakes, see below. As these errors are fixed now, this shows that a static image is better than a map view, even if that has to be updated occasionally. The style does not change every day. I'd also prefer a simpler situation for an example.--Polarbear w (talk) 12:51, 20 November 2017 (UTC)
- Do you know a good example? An example would be IKEA but it may be too confusing. I would prefer live map view because it stays current, but you are right that did not change a picture so easily.--geozeisig (talk) 08:00, 20 November 2017 (UTC)
- Danke das du die oben aufgezeigten Fehler korrigiert hast. Das Beispiel ist aber für eine Wiki-Seite zu komplex. Ich habe den Parkplatz von Beispiel der deutschen Seite ebenfalls bezüglich service und parking_aisle korrigiert. Da ist sicher noch Handlungsbedarf auf anderen Parkplätzen, aber auf den Wiki-Seiten ist es schon richtig beschrieben.--geozeisig (talk) 10:34, 23 November 2017 (UTC)
- Ja, da stimmen wir überein, ich hatte ja oben auch geschrieben "prefer a simpler situation for an example", eben weil es für ein Beispiel zu komplex ist. --Polarbear w (talk) 10:23, 24 November 2017 (UTC)
- Danke das du die oben aufgezeigten Fehler korrigiert hast. Das Beispiel ist aber für eine Wiki-Seite zu komplex. Ich habe den Parkplatz von Beispiel der deutschen Seite ebenfalls bezüglich service und parking_aisle korrigiert. Da ist sicher noch Handlungsbedarf auf anderen Parkplätzen, aber auf den Wiki-Seiten ist es schon richtig beschrieben.--geozeisig (talk) 10:34, 23 November 2017 (UTC)
Handicapped Parking hours
How would you tag this:
.jpg)
I presume that the parking spaces is reserved for handicapped from 7 to 21. But that it can be used for parking 24/7. Elgaard (talk) 15:22, 11 January 2018 (UTC)
- My understanding is that it's reserved for disabled people from 7am to 9pm, but allowed to any user from 9pm to 7am. It makes sense as outside business hours less disabled people will want to reach the clinic. No Danish guy to clarify? --Nospam2005 (talk) 20:17, 12 June 2019 (UTC)
- I would have assumed User:Elgaard already knew what the sign means, and was merely asking which tag(s) to use to describe the situation. Not sure, though. In any case, I believe it could be mapped using Conditional restrictions. --Tordanik 18:29, 24 June 2019 (UTC)
Parking for campervans
It would be helpful to be able to tag if campervans are allowed or not. Here in Portugal there are some parking places, where campervans are completely forbidden, some places campervans can park during the day but not during the night and some spaces allow campervans also during the night or have no posted restrictions.
My suggestion would be an additional tag like
campervans = yes | no
campervans:opening_hours = (like key opening hours) --Beaconeer 19:18, 24 November 2018
- For campsites tourism=camp_site we use campers=yes. I suggest to use campers=yes here too. And maybe campers:opening_hours but you can add tags in opening_hours. Yes a very rare usage. --Nospam2005 (talk) 20:13, 12 June 2019 (UTC)
Clarification for name tag on parking
I think the table of tags should include a clarifying note for the name tag along the lines of "Parking should not be named after an adjoined business". Posting to discussion because perhaps I'm wrong about that? --TheEditor101 (talk) 09:17, 20 August 2019 (UTC)
Cell phone parking lots
How should we tag a cell phone waiting lot? Folks on OSMUS Slack took a look at airports around the U.S. and found some tagged with maxstay=* and/or fee=no, but most with no distinguishing tag other than name=Cell Phone Waiting Lot or somesuch. What would be a good way to indicate that the driver may not leave the vehicle while parking there? Such a tag would also be useful as part of the parking:condition=* tagging scheme for parking lanes that are designated as loading or pickup zones. amenity=car_pooling implies something similar, but cell phone lots are usually located far enough away from the airport terminal that the passenger isn't expected to come to the parked car. – Minh Nguyễn 💬 05:54, 1 January 2020 (UTC)
Surface parking with underground levels
How are we to map surface parkings with one or more additional underground levels?
This example was tagged with parking=multi-storey while from the outside there is but a visible surface parking area and one underground level. The definition for parking=multi-storey mentions "a building designed for car parking" but I'm not sure if this would apply to cases like this. Perhaps rather mark the area as parking=surface and (if known) map the location of the underground parking entrance separately using amenity=parking_entrance and parking=underground? --Daikan (talk) 02:46, 6 February 2020 (UTC)
- I tagged a similar structure a while ago (https://www.openstreetmap.org/way/40831444) with parking=multi-storey too. It isn't a very satisfying solution. I understand you're talking about structures with surface parking and underground levels, but no above-ground levels (on floors 1,2... if surface is 0). I'm thinking maybe it should be split into two areas, one with parking=surface and another with parking=underground, but there's gotta be a better way. Rostaman (talk) 16:30, 8 February 2021 (UTC)
Parking zones
Is there a tag or relation for marking city-wide parking zones? In many cities, paid parking spaces are grouped in several zones, each of which has a specific maxstay, cost per hour and operating hours. I'd rather avoid duplicating the same fee=* and conditional restrictions on thousands of ways and areas. Rostaman (talk) 16:36, 8 February 2021 (UTC)
Leave car keys
Do you have any ideas on how to map a parking lot that requires you to leave your car keys to the parking operator? --Valeriobozz (talk) 09:45, 29 December 2021 (UTC)
- I noticed the Wikipedia article w:Valet parking that describes perfectly my situation and I've adopted valet_parking=only. --Valeriobozz (talk) 20:58, 21 May 2022 (UTC)
No parking areas within parking areas
Mention areas of a parking lot with slashes / stripes / X's etc. on the pavement are probably to be mapped as footway=access_aisle. (Thus they should be thought of as ways, not areas, too.) Jidanni (talk) 18:03, 22 November 2022 (UTC)
- Guessing: amenity=parking access=no . Jidanni (talk) 00:53, 1 July 2023 (UTC)
- No, and I highly doubt it is parking=street_side or parking=lane. Use some area:highway=* for it first. Where are they? On the traveling lane, intersections, kerbside, or bays? --- Kovposch (talk) 10:09, 1 July 2023 (UTC)
All I know is my attempts to indicate places where people are not supposed to park (signed tow-away zones), backfired and got rendered as encouraging people to park there. So I'm out of answers. Jidanni (talk) 17:57, 1 July 2023 (UTC)
- I always map such areas with area:highway=prohibited and the local traffic_sign code, but in future I would like to find a solution for this in the form of a well thought-out proposal for (road) markings. Somethink like "marking=no_parking" could be part of that.
- (See also the same thread at Parking Talk Page, where @Jidanni: posted a link to a street view photo of this situation.) --Supaplex030 (talk) 21:26, 1 July 2023 (UTC)
Wait, they must be Tag:traffic_calming=painted_island! Jidanni (talk) 19:39, 11 August 2023 (UTC)
Grass islands in parking lots
What is the final ruling about e.g., these four grass/garden islands on the left side of this parking lot?
Just landuse=grass, or do users have learn about multipolygons, etc... ? Jidanni (talk) 16:56, 10 July 2023 (UTC)
- I simply map such grass islands with landuse=grass and have also often seen it like this by other mappers. Multipolygons are absolutely unnecessary imho, because they make the geometry unnecessarily complicated and the grass islands are somehow also "on" the parking lot. --Supaplex030 (talk) 08:41, 11 July 2023 (UTC)
- I can confirm that
gets rendered! Jidanni (talk) 08:29, 25 August 2023 (UTC)landuse=grass
surface=grass
traffic_calming=island
Building in the middle of a parking lot
OK, I made the parking lot that surrounds the building.
Now what is the best way to say that the parking lot doesn't extend under the building?
In other words what is the best way to cut a building-sized doughnut hole in the parking lot? Jidanni (talk) 08:03, 26 January 2024 (UTC)
- Just map the parking lot as a multipolygon.
Therefore, in addition to the parking lot geometry, you need a second, smaller geometry that represents the "hole" (a new line on the "inner boundary" of the parking lot or the building area, if this exactly represents the hole). Both of these are added to a multipolygon relation: the original parking lot has the role "outer", the hole has the role "inner".
If you have never created a relation before: Don't worry! A multipolygon is the simplest form of a relation and therefore perfect for learning :) Supaplex030 (talk) 10:51, 26 January 2024 (UTC)