OpenStreetMap
I think there should be a method for tagging individual parking spaces rather than entire lots. At least one other individual has mentioned this on the wiki on the amenity=parking talk page.
Why would we want to do this? The obvious reason (at least to me) is to differentiate between general parking, handicap parking, mothers/parents/elderly parking, etc. However this can also be useful for parking lots which have reference numbers assigned to each space, such as shown in the associated map. There's nothing preventing people from mapping individual spaces now, the only problem is there is no way for data consumers (including renderers) to know that these individual spaces are related.
How to do this? Well I don't think we really need any new tags, just a new relation, and it should work no matter how a parking lot is mapped. If an individual space is mapped, it will have capacity=1, and maybe even capacity:disabled=1 if it's a handicap spot. If you have a whole row of spaces of the same type you can just draw them all with one closed way, and tag it with the appropriate capacity=*.
Then what we need is a relation to tie all these ways together to represent a logical parking lot. Perhaps there can be a role=label member node which designates where the P symbol and/or parking lot name should be drawn. This prevents renderers from drawing dozens or hundreds of P's. I'm not sure what type=* the relation should be, or what role=* the parking spaces (individual or group) should have. It's such a simple relation I almost feel like something out there should already work.
If you have any suggestions, please comment, and I'll try and turn this into a proposal.
Discussion
Comment from ALE! on 16 March 2011 at 17:48
Just one comment: That is too much detail!
Comment from JoshD on 16 March 2011 at 18:03
Haha, for most, yes. But it's good to start thinking about these things. I think it's very useful for a routing engine to be able to direct a handicapped driver to an appropriate spot. This doesn't require mapping every single space individually, but mapping blocks of spaces makes sense.
Comment from keinseier on 16 March 2011 at 19:10
Too much detail for which applicatione? Navigation? Perhabs, but there will be use cases for such detailed geodata. Who needs all the benches, vending machines for sweets and excrement_bags today? I map all of them when possible and with high resolution DOP I will draw each parking lot, if there is a common tagging scheme. For me it's fun, it's because we can, but one day people will make money with this data, because they found a business case for these detailed information.
Comment from keinseier on 16 March 2011 at 19:20
A better question is: why a relation? We don't tag for the renderer, are there other reasons for a relation? The lots are connected with highway=service, service=parking_aisle and the sharing nodes - isn't this enough?
Comment from JoshD on 16 March 2011 at 19:40
keinseier,
This is a benefit for all data consumers, not just renderers, it's just the most obvious example. Your argument can be used to shoot down virtually all use cases for relations. The point is that relations can make highly difficult situations easy to process for computers. You're asking quite a lot from data consumers to process all the connecting parking aisles and try to calculate what parking areas belong together.
However I do feel like there should be a more general purpose relation, which basically allows for breaking down complex objects into small objects with finer detail. Simple applications just join all members together, and perhaps the smarter ones would sum capacity=# in the case of parking, but more sophisticated apps could route a handicapped driver right to where they can park. This is almost just a multipolygon, but not quite.
Comment from Sundance on 16 March 2011 at 22:30
I'm not sure about every single space, but groups of parking spaces that have common restrictions sure.
For example when I'm going through TIGER data and come across rest areas, I tag the parking with
hgv=yes/no motorocar=yes/no for the appropriate parking area
Comment from JoshD on 17 March 2011 at 00:18
I phrased it as mapping every single space for dramatic effect. :) Realistically it's more likely to see several blocks of parking spaces than hundreds, just that in some rare cases it's possible and justified to map every one.
Comment from rainer111 on 17 March 2011 at 07:27
Hello JoshD, I has spent the last weeks with it, all offziellen disabled person's parking bays of the city of Augsburg too day-to, and because I already, besides, was also the places before supermarkets, cinemas etc.
Unfortunately, still no own Icon is economical of the Renderer on places with capacity=disables and/or wheelchair=yes, this is why I manage with it the parking bays with name=1 disabled person's parking bay to name. I put the places also as node and not as a surface, because another web page, namely wheelmap.org, takes up only as node marked places with. Surfaces are not (still considered there. Therefore there remains first with the name name=xxx. To me was already accused, I thereby abuse an order and it becomes too blind. But there I join keinseier, there is something "more insignificant one" which makes the maps more blind ;-)
Comment from Strash on 17 March 2011 at 08:44
What I miss is a way to tag streets with parking spaces on each side (or on only one side). I think this is quite different from parking areas, and may be useful (ie: I need to go to this area of town, where is the nearest street where I can park my car for free ?)
Comment from craigloftus on 17 March 2011 at 09:19
@Strash there is a rather complicated proposal covering that: http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane
Comment from flaimo on 17 March 2011 at 21:28
you don't need to start a new proposal because i started one for the exact same reason a couple of days ago: http://wiki.openstreetmap.org/wiki/Proposed_features/parking
i will move the status from draft to RFC on the weekend, but everybody feel to add your thoughts in the comments starting now.