Best practise of tagging in parking areas

Saw a few discussions to include which ways on a parking are considered aisles and which are service (the connecting ways so to speak). Some parkings have the blocks split such as the example below, the blocks having numbers such as P5 or Lane 7. The question is in the latter case of split parking blocks, is it best to only tag the parking/orientations on the parking blocks or only on the aisles or both where the wiki Parking - OpenStreetMap Wiki does not appear to make a recommendation, and starting to lean towards “depends on the mapped situation”

  1. With one big parking and varying orientations, tag only on the aisles.
  2. With one big parking and just single orientation, tag only on parking area
  3. With parking blocks as per the example, only parking details on the blocks, not on aisles
  4. Tag it on all.parking areas and aisles.

That 's of course for those who care to tag parking particulars at all.

What you say?

Those diagonal corners are a terrible example of road mapping.

2 Likes

For the shown example I would map 1 amenity=parking and optionally ~70 amenity=parking_space.

But as everything in OSM world, this is a matter of personal taste.

Personally, just looking at this aerial photo without more context, I would try to coalesce these areas into a single amenity=parking area, corresponding to what a layperson would call “a parking lot” by common sense.

Otherwise, the granular areas here would inevitably be inconsistent with other parking lots. For example, if the whole lot has a name and address, would you add the name and address redundantly to each row of parking spaces? If someone takes the time to draw each individual amenity=parking_space area, these row-based amenity=parking areas would become redundant.

Moreover, the service=parking_aisle definition excludes the major circulatory roads in a parking lot, because we don’t need to tag the fact that a service road is located in a parking lot. After all, the data consumer can simply test whether its geometry intersects with the amenity=parking area. But that heuristic fails if the parking areas hew so tightly to the parking spaces.

With this additional context, I can understand why someone would be tempted to make the parking areas hew closely to the parking spaces. But I don’t think that should prevent the whole parking lot from being mapped as an area. if a lane itself is numbered, the number can go in a ref tag on the highway=service service=parking_aisle way.

Many large parking lots are also divided into zones, sections, or blocks that are numbered, color-coded, or otherwise visually distinct.

But these zones aren’t parking lots per se. Mapping them as individual amenity=parking areas reminds me of mapping cemetery sectors as landuse=cemetery areas, a practice that would be discouraged in favor of cemetery=sector if not for inadequate renderer support. Maybe there needs to be a new tag for an identifiable section of a parking lot.

2 Likes

Thanks for your input. Need to mull this a bit

The ease of tagging just being on lanes when not single way orientation (diagonal/parallel/perpendicular) with orientation=marked and multi also in circulation that bit not needed if going into the single parking space mapping. Done that a few times but not my thing, at most do it where special parking spots are for disabled, delivery and yes there’s some who mark out parking spots for the police to have their quick coffee.

thanks again.

PS Tried ref but that wont render on the most common map, maybe it will on transport type ones. The P5 is literally on a lit board at the head of the parking lot segment. Tagging that on a lane would become kind of messy as in fact the aisle would be running between blocks P5 and P6 and the aisle one over between P4 and P5.

Almost 2 months later got back to this and started carving out the individual parking spaces, discovered an area which at the yankee side they’d call ‘cart corral’ and mapped the encompassing ‘parking lot’, WIP because mapping the parking spaces is time consuming, searching for the most efficient and homogeneous sizing of each space. FTM left the blocks, removed the parking tags, tagged is as a single parking space and started drawing the individual spaces using the Alt-X shortcut to propagate the tags. Only the basics on them as the parking lot has what applies to all, lit, surface, fee free etc, supervision, covered etc. See no sense in repeating that on 200 plus individual spaces. Stop spots at every corner, mama papa parking included.

If someone has a quicker way and connect the parking space corners in a lane, I’m all ears.

1 Like

… and to get your individual parking spaces evenly sized, select all nodes along one edge (sample below red nodes) and hit Shift+B, rinse repeat for all and the result is perfect. Made me discover one whole block was reserved for handicap parking as much wider.

You can use Gridify to get equal sized squares. Then you add/remove spaces to get the right result.

Adding capacity=1 to amantiy=parking_space is a bit redundant.

1 Like

Thanks, that truly made it lots easier… map area, set tags as were it one space, Atl+Shft+Y to launch, set matrix and done. Makes it much more attractive to do even larger parkings.