Proposal talk:Parking

I have added some talking points for certain aspects of this proposal -- Flaimo 23:41, 13 March 2011 (UTC)

Since my mother togue isn't englisch, I would also appreciate it, if a native speaker could cross-read the proposal for spelling and grammar errors. -- Flaimo 12:25, 14 March 2011 (UTC)

Should highways be added to the relations?

should ways tagged with highway=service + service=parking_aisle be added to the relations? i personally don't see the need for that. -- Flaimo 23:41, 13 March 2011 (UTC)

ref instead of parking_*_id?

Resolved: Flaimo 13:09, 27 April 2011 (BST)

should the ref tag be used instead of parking_lot_id, parking_area_id, parking_entrance_id and parking_id? -- Flaimo 23:41, 13 March 2011 (UTC)

If think it would be better to use ref. If tags are only used by third party apps or data importers I think the precedent is <app/import id>:ref=blah - eg Naptan imported data in the uk--Pobice 01:06, 14 March 2011 (UTC)

i changed it to ref -- Flaimo 12:18, 14 March 2011 (UTC)

parking=* instead of amenity=*

Resolved: Flaimo 13:09, 27 April 2011 (BST)

what do you think of replacing the amenity tag with a dedicated parking tag? so instead of amenity=parking_lot/parking_entrance/parking_area we could use parking=lot/entrance/area -- Flaimo 22:41, 14 March 2011 (UTC)

I second this. amenity=parking is to be used for the whole parking area (including details like name) which stores the parking facility in the db (allowing e.g. routers to identify the whole area) while you want to map single parking lots inside this area. This should use another tag (not only a subtag) to avoid confusion. -- Dieterdreist 11:37, 18 March 2011 (UTC)

user achadwick has some valid arguments for using amenity=parking for backwards compatibility (see topic below). if a different interpretation of the amenity tag is necessary, that could be done by checking if there is a parking_type tag on the same element or not. -- Flaimo 20:22, 18 March 2011 (UTC)

Terminology

Resolved: Flaimo 13:09, 27 April 2011 (BST)

A "parking_lot" is incorrect English for single car parking spaces (as you mention, each "parking_lot" in your spec counts as capacity=1): see the images and text at [1]. One might say "parking_space", however. IMO mapping individual car parking spaces as areas is absurd. If you must, bundle areas of similar parking as "parking_spaces", with a higher level construct of a "parking_zone" for named zones of multiple space types (e.g. "Public Car Park A"). --achadwick 22:43, 14 March 2011 (UTC)

1) so the right terms would be amenity=parking_space/parking_zone/parking_entrance? 2) the only way to pin down a special kind of parking space is by actually mapping it. you can't do that right now without cluttering the map with blue "P"s, since the renderer can't know which spaces belong together. if you have similar kinds of spaces you could use "parking area / parking zone". but by using tools like the terracing plugin in josm, splitting up areas shouldn't be much of a problem. it's meant for big parking lots anyway. if you just want to map 5 spaces in front of a house you should stick to amenity=parking. -- Flaimo 15:47, 15 March 2011 (UTC)

Can see some cases where mapping out one space would be useful otherwise its better to map them as groups of spaces where needed. Having said that if you've run out of things to map and want to micro-map to level don't let me stop you--Pobice 23:16, 14 March 2011 (UTC)

it's not so much about micromapping, but to lay the groundwork for possible third party applications. "door to door" routing, or better "parking space to parking space" rounting, won't work with amenity=parking. but I will rephrase the proposal so, parking space and parking area/zone are seen as equal. -- Flaimo 15:47, 15 March 2011 (UTC)

Reinvention of wheels, backwards-compatibility

Resolved: Flaimo 13:09, 27 April 2011 (BST)

Why not attempt backwards compatibility? It seems you're reinventing the wheel here. The *huge* advantage to being 100% backwards compatible is that existing renderers will be forced to change merely to support this new kind of parking (which, take it from me, they will not do unless you personally supply patches and see through getting them integrated. I trust you are planning to do this.) If you must map to this level of detail, I suggest you use the existing amenity=parking for your amenity=parking_area. It can be refined at "lower resolution" by aggregating them with relations, and at "higher resolution" by declaring new tags for additional areas and points to be placed within existing amenity=parking blocks.

For example: cycle parking is already well served by amenity=bicycle_parking. Reuse that, place it within larger areas of parking if you must. Or hey, give it equal billing with amenity=parking :) --achadwick 22:59, 14 March 2011 (UTC)

Personally I think that's the better idea. Possibly map the lots/special areas with parking=lot leaving off the amenity tag. Could then do a amenity=parking for the area as a whole and add them together with a relation. --Pobice 23:12, 14 March 2011 (UTC)

i can't use parking as a tag because it is already taken for parking=underground/surface/multi-storey. i'm using "parking_type" now though -- Flaimo 20:19, 18 March 2011 (UTC)

1) seems to be a good idea: amenity=parking + parking=space/entrance/group would still render. i probably will update the proposal to that. 2) i don't see the purpose, why we still need a separate tag exactly for bicycles. there are no tags amenity=bus_parking or amenity=motorcycle_parking? bicycle_parking was invented when there were hardly any access rules. but now there are, so the way with general parking tags combined with access tags seems more logical. -- Flaimo 16:03, 15 March 2011 (UTC)

there is one problem when using parking=space/area/entrance. in conflicts with parking=surface/underground/multi-storey. one defines the type, the other the location. -- Flaimo 19:56, 15 March 2011 (UTC)

on the tagging mailing list a fellow mapper argued that the amenity=parking tag shouldn't be misused for single parking spaces. he suggests using amenity=parking for the whole facility and use new tags to map areas/spaces/entries inside the parking lot. i argued, that this would only work as long as parking facilities are not split up (through a non related road for example). i think using the site-relation still seems the better solution, especially since it a generic site-relation which is familiar to users. -- Flaimo 13:47, 18 March 2011 (UTC)

also not using a relation and relying on a surrounding amenity=parking area definitely won't for underground parking if all you have are entrance nodes. also nesting of relations would help to stop the tag cluttering of the individual parking spaces and areas. something that's also not possible with just a surrounding amenity=parking area. -- Flaimo 20:38, 18 March 2011 (UTC)

Well, I still believe that using amenity=parking on single parking spaces has no truly beneficial effects. It clearly contradicts current usage of a tag that could continue to be useful in the future. More detailled tagging should not replace more generalized tagging, but be used in addition to it: If you map some or even all of the individual trees in a patch of forest, then you should not tag these trees as forests, and you should not delete the forest area. Instead, you should place the trees, mapped with a distinct tag (natural=tree), within the forest area. Similarly, if you map some or even all of the individual parking lots in a parking facility, you should do so with a distinct tag, and this should not interfere with the mapping of the parking facility as a whole. That's my opinion at least.

Whether or not to use a relation is another issue. You could use amenity=parking on a site or multipolygon relation, too - even if you use a different tag for the individual parking spaces. I personally think that, where possible, a simple area should be used. Of course it's not always possible - sometimes you need that relation. But the relatively few cases where an area isn't enough didn't stop anyone from mapping a lot of schools or supermarkets as areas and map only those schools and supermarkets as relations only where doing so is necessary. Why should that be any different with parking facilities?

About tag cluttering: I don't quite understand what you mean with that. Can't you just put the tags you would have put on the relation on the enclosing area instead? --Tordanik 17:50, 19 March 2011 (UTC)

the school example you mention is a problem anyway, because by tagging the area as also the individual schools as amenity=school leads to three search results for schools in that area, even though only the two buildings on it are actually schools and the area is a shared ground. correct would be a landuse=education in such a case (which doesn't exist though).

btw, i took a look at the key:parking page again and nothing there says that the area automatically defines all elements inside as part of the parking lot. and even if you would interpret it like that, the parking_type key in my proposal, would be enough for renderers and routing programs to distinguish between "old" amenity=parking areas and "new" parking spaces just like a dedicated key would, but without loosing backwards compatibility with renderers.

for the cluttering example: take a car rental service with 4000 parking spaces, divides into 4 sections which again have 10 rows each containing 100 spaces. spaces in section 3 and 4 have a different surface than the other sections, section 1 and 2 are covered and row 6 in section 4 as also row 8 in section 2 is reserved for electric vehicles only. since you probably won't nest 3 amenity=parking areas inside each other to achieve inheritance, you would have to tag all those spaces individually. also you have no possibility to reference third party parking managment systems to individual sections or rows. the attached image from the proposal should illustrate that much better: http://wiki.openstreetmap.org/wiki/File:Big_car_rental_service.png . as you see, i had complicated situations in mind when drafting that proposal. for your average mid sized supermarket with 100 similar parking spaces, you can stick with the current scheme anyway.

also a mixture of using areas in one case and relations in others would lead to even more confusion, that's why my proposal uses relations constantly all the way through. --Flaimo 04:37, 20 March 2011 (UTC)

after going through the pros and cons of this discussions and sleeping over it, i guess it will come to this:

1) i'll switch amenity=parking + parking_type=space/entrance back to amenity=parking_space/parking_entrance (like it was in the original draft). this way i don't step on anyone's toes who sees amenity=parking as some sort of collection of elements inside it's area. of course it might not get rendered then, as Achadwick stated out. if the proposal gets approved, i would write a ticket for mapnik and ask if at least they could render amenity=parking_space with the same yellow background as amenity=parking, but without the blue "P".

2) i'll keep the relation in, since it is the cornerstone of the proposal to deal with complex situatons. now that there is no double usage for the amenity=parking tag anymore, the two mapping stiles can coexists without problems.

to me, that seems like a good compromise, both parties can live with. --Flaimo 13:31, 20 March 2011 (UTC)

I can't speak for others, but I can certainly live with that. --Tordanik 18:41, 20 March 2011 (UTC)

Don't use 2 tags for the same thing (parking space vs area)

Resolved: Flaimo 13:09, 27 April 2011 (BST)

amenity=parking + parking_type=space is basically the same feature as amenity=parking + parking_type=area. I would prefer amenity=parking + parking_type=space + capacity=* instead of amenity=parking + parking_type=area. If you know the size of a parking space you won't even need the capacity because you can determine it from the size (usually 2,50 x 5,00 m) -- Dieterdreist 12:32, 18 March 2011 (UTC)

sounds reasonable. i guess the important part still is the parking_type=space, otherwise renderers and routing programs have no way to distinguish different kind of elements or areas with the plain old amenity=parking tag. i would suggest the default capacity value should be interpreted as "1", any other value the user has to explicitly tag. but i would like to hear some more comments on that from other users for or against this suggestion before i rewrite it. -- Flaimo 12:58, 18 March 2011 (UTC)

one problem is see, is that your suggestion somehow interferes with mapping a single space as a node (as another mapper suggested should be possible). if i combine space and area to one element, the scheme would also have to allow nodes for areas, which somehow defeats the purpose of this proposal for more detailed mapping. i think either you go the full way and map everything in detail or you stick with the current simple scheme of just using a singe amenity=parking. -- Flaimo 14:03, 18 March 2011 (UTC)

parking_space and parking_area are now merged to one element (space). please cross read it to check if i forgot to change any passages -- Flaimo 23:58, 18 March 2011 (UTC)

Bicycle parking

Resolved: Flaimo 13:09, 27 April 2011 (BST)

What about mapping separate bicycle parking? Already has amenity=bicycle_parking. If use scheme amenity=parking + parking_type=area + vehicle=no + bicycle=permissive, then need to propose allow mapping parking_type=area as .--Canabis 14:48, 18 March 2011 (UTC)

maybe that problem solves itself if i merge "space" and "area" to one tag as proposed one topic above yours. than node and area would be possible. -- Flaimo 20:16, 18 March 2011 (UTC)

I think the kind of parking space should be more generic, so use something like vehicle:type=*. --Fabi2 19:25, 19 March 2011 (UTC)

the kind of transportation is already covered with the generic access rules. though i would like to see a cleand up access version, i don't think it should be part of this proposal. --Flaimo 19:30, 23 March 2011 (UTC)

Parking space as node  ?

Resolved: Flaimo 13:09, 27 April 2011 (BST)

I think the parking space can not be mapped as .--Canabis 14:48, 18 March 2011 (UTC)

Since I'm the one who suggested this addition on the tagging mailing list, I feel it's my task to explain it. Of course, the ideal solution is to draw a parking space as an area. However, that's not easy when you don't have access to aerial imagery (or only bad aerial imagery). Even if you cannot represent the shape correctly, though, you can still map the position, simply from surveying on the ground. That's certainly worthwhile for spaces dedicated to special interest groups. --Tordanik 15:32, 18 March 2011 (UTC)

i second that now. because it could very likely be that a company, like hertz for example, already has geolocations of all their parking spaces, probably not as shapes, but maybe as simple coordinates. it should be possible to import those without generating fake areas just to stick with a too strict proposal. best practice should definitely be to map those as areas though, and i think the wording in the proposal reflects that. -- Flaimo 20:12, 18 March 2011 (UTC)

Probably, if we aren't have shape of parking area, then use amenity=parking, and if we have shape, then use amenity=parking + parking_type=space. Forgot sign it. --Canabis 10:50, 30 March 2011 (BST)

Use of a relation to gain nothing

Resolved: Flaimo 13:09, 27 April 2011 (BST)

I think using a relation is not needed here, as the indivual parking spaces are contained in a bigger area and can be found as belong together by an "is in"-check. So using relations would only made you schema more complex to handle. So, that e.g. the disabled parking spaces belonging to a bigger area of a prking lot, can be found out, because they are in the bigger parking space, even if they may have somme different meta data. --Fabi2 19:38, 19 March 2011 (UTC)

simple areas can't handle complex situations as mentioned a couple comments above. and if a situation is that simple, that you can cover it with one area, than you should stick with the old mapping style anyway. --Flaimo 19:54, 19 March 2011 (UTC)

Realistic rendering of spaces / marking

Resolved: --Flaimo 13:41, 2 May 2011 (BST)

Now that we hopefully have a working compromise on the amenity=parking issue, I'm thinking about how a renderer aiming for a generally "realistic" style (primarily osm2world, of course ;)) would best handle individually mapped parking spaces. For example, should it assume that there are markings around the parking spaces? How should these markings look by default? I'm not necessarily expecting definite answers here, just wondering whether anyone already has ideas on the issue. --Tordanik 19:14, 20 March 2011 (UTC)

for a start rendering of amenity=parking_space shouldn't differ from amenity=parking, except maybe without the blue "P"s over them. in a later stage relations could be parsed to get the name, but i guess – at least for mapnik – we'll have to wait until parsing for generic site relations get implemented (see mapquest mockup screens i added to the proposal yesterday: http://wiki.openstreetmap.org/wiki/File:Mapquest-mockup.png).

with amenity=parking_entrance it gets a bit more complicated, since the node itself not necessarily has all the important information available. important tags for renderers (like parking=underground/multi-storey) could be tagged for the parent relation only. --Flaimo 02:17, 22 March 2011 (UTC)

That's certainly a good suggestion for renderers like Mapnik, and I hope that the suggestions will quickly become part of their style sheets when usage of the proposed tags catches on. I was, however, thinking of the niche category of non-abstract renderings: where parking is not yellow, and does not have a blue P hovering above it, but rather has an asphalt/gravel/... texture. A rendering like that should probably also contain markings (white lines on asphalt, colored paving stones, ...) around the parking spaces if there are markings in reality. Should it be assumed that a separately mapped space has markings like that, or can that information not be inferred from your proposed tags? --Tordanik 22:04, 22 March 2011 (UTC)

if a single parking space is tagged and its surface is asphalt/paved, it can be assumed, that there are markings. same goes with grass_paver, but the lines are normally made from a different kind of paving stone. as soon as a capacity tag is mapped to a amenity=parking_space that is higher than 1, i wouldn't paint any markings.

a special tag would be interesting. something like parking_space:markings=* . the value tag could contain an array of four sub values for the marking on each side: "top", "right", "bottom" and "left". basically the same way borders are defined in CSS. each of the four sub values could contain one of the following strings: line, stones, none. additional strings could be defined later on. of course this tag could also be applied to the relation, so it doesn't have to be attached to every single parking space. one problem i see here is, what defines the top/right/bottom/left of the parking space itself? --Flaimo 00:58, 23 March 2011 (UTC)

Describing the style of the markings (lines, stones, etc.) is probably not hard, it's mostly an issue of collecting a comprehensive set of values. What indeed wouldn't be straightforward is describing where the markings are, especially if a solution is supposed to handle even the rare non-rectangular spaces. What can be easily decided, though, is whether an edge is between spaces or on the outer boundary of a block of spaces, because if I'm looking at your examples correctly, adjacent amenity=parking_space areas will share nodes.

So I'll probably first implement a solution where I draw a generic style of markings between individually mapped (capacity 1) spaces on certain surfaces. That will already provide a reasonable visualization for common cases. If people want more detail, it's something that can be addressed in a future proposal - this one is already complex enough. ;) --Tordanik 19:21, 23 March 2011 (UTC)

key structure

Stale: Flaimo 13:11, 27 April 2011 (BST)

Please notice: The key capacity is combined with women instead of woman.

i don't understand. capacity in this proposal is actually not tied to any role at all (in contrast to the current amenity=parking). it rather describes the number of physically available parking spaces, independent of any interest groups. --Flaimo 19:35, 23 March 2011 (UTC)

Mapped Examples

Resolved: Flaimo 13:09, 27 April 2011 (BST)

Are there some mapped examples we could share? I tried it out in a local shopping center, as you can see here:

• Large shopping center - 1529923 1529923
• Nearby bank - 1529922 1529922

These might not be complete however. I'm pretty happy with the proposal so far, though I'll need to carefully read through the entirety of it and the discussions. -- Joshdoe 17:06, 6 April 2011 (BST)

i wouldn't set access to no for the disabled spaces, since the roles and mode of transportation are two separate things. i would add an access=permissive + access:customer=permissive to both relations and access:disabled=permissive to the spaces for disabled people. --Flaimo 19:34, 6 April 2011 (BST)

Another Example where i tried it out:

• Toom Market (It's also a shopping center) - 2504270 2504270

I even added ALL of the Single Parking Spaces there, was a hell of a work, but really funny to try it. --Keichi 02:40, 17. October 2012 (CET)

Entrances for surface parking

Stale: Flaimo 13:11, 27 April 2011 (BST)

The proposal says entrances are mandatory, however it also seems to imply that it is intended for multi-storey and underground parking. If you look at the mapping I did of the large shopping center, I really have no idea where I'd add the amenity=parking_entrance nodes, I can see at least 7 that would need it, but it's far from clear. Of course for some parking I've seen it's very clear there's just one or two entrances. -- Joshdoe 17:09, 6 April 2011 (BST)

entrance nodes are actually only for underground and multi storey parking as a substitute for fully mapped underground areas. in case of surface parking those aren't needed --Flaimo 19:36, 6 April 2011 (BST)

Why do you not want all entrances of parkings to be mapped as amenity=parking_entrace, but rather reduce it's use to "Entrances to underground or multi-storey parking facilities, in case their physical presence can’t be fully mapped." I don't see why the entrance of a parking that is not underground or mulistorey should not be mapped with this tag. I also don't see why this should not be mapped in case that it is possible to fully map their physical prensence.

Why not simply: "General entrances to a parking facility". The rest of your definition could become an example (rather then beeing used to exclude other usages). (I used "general entrance" here as opposed to "all entrances", which might not be accessible to the public). There should also be a way to distinct entraces for pedestrians and those for cars. --Dieterdreist 13:00, 18 April 2011 (BST)

how would you want to use parking entrances on surface parking? also the distinction between entrances for cars and pedestrians is defined by the way connected to the entrance node or the access definitions (foot, vehicle, wheelchair,…) assigned to it. you can also explicitly map it to the entrance node itself --Flaimo 19:13, 18 April 2011 (BST)

Exits from parking facilities?

Resolved: Flaimo 13:09, 27 April 2011 (BST)

What about exits from parking facilities? I think it could be integrated into this proposal how to mark them. --Dieterdreist 13:00, 18 April 2011 (BST)

this is defined by the oneway tag (or lack thereof) of the connecting way which shares a node with the parking entrance. --Flaimo 19:09, 18 April 2011 (BST)

also rephased the paragraph about the old amenity=parking a bit. --Flaimo 19:24, 18 April 2011 (BST)

Pedestrian Entrances / Exits from parking facilities?

Shouldn't those tags be specified in the proposal as this is a common parking feature ? More specifically elevators from ground level could be part of the relation. --Samusz (talk) 10:04, 21 June 2013 (UTC)

DO use entrances for surface parking

I think that parking_entrance has perfect sense even for large surface parkings. In fact it is nearly as important (or maybe even more) than a location of parking itself for if you have a look at the map and you want to drive to the parking, it is often difficult to tell quickly where is an entrance to the parking. Especially paid parking sites can be very complex, but have only few entrances (and exits) with lift gates. Supportive argument for this is also fact, that often when you approach the site there are lots of signes and arrows navigating you to the entry of parking (quite naturally) even if the parking itself is just behind a hedge. It also may help navigation software.

Role values in the relation

Which role values should be used in the relation type=site?

Is there a way to make a distinction beetween the entrance/exit and other thing (and should the entry marked here in the relation role different from the exit).

One more question. What about the case I can only mark the entry/exit of the parking but I have no other details for the parking? Should I just map the entry (or the entries and exits) with amenity=parking_entrance ? (btw at the moment just marking a node with amenity=parking_entrance give no rendering on the map). And what about if just a node tagged with amenity=parking is already present? Should it be added to the relation? And which role for that?

AnyFile (talk) 08:58, 2 October 2013 (UTC)

Usage

Is this mapping scheme used in any apps or website? --K1wi (talk) 09:07, 11 September 2014 (UTC)

access:role <> access:roles

this tag is sometimes used in singular (~600 according taginfo) or plural (~30). The proposed features also use both. So I harmonized it with the singular

electric vehicle charging

One of my local supermarkets just installed two charging stations (four sockets between them). Each charging station takes up part of a former parking space, which is now marked as no parking. The two adjacent parking spaces are signposted as for charging electric vehicles only, not for other parking. I assume an access:<role>=yes would be sensible for the places where electric vehicles park to be charged. Any suggestions for the role? The spaces aren't long enough to accommodate anything other than a car, but other charging stations might be placed in sizes appropriate to trucks or RVs, so access:car_charging might not be the best way to go (there are arguments both ways). Any way to tag the parking space that you could fit a short car (like a Smart) into if it weren't marked as "don't do that"? And can I tag only those spaces that are devoted to charging without having to map every other space in the car park? --Brian de Ford (talk) 23:40, 23 August 2019 (UTC)