I would like to ask how to map a multi-level stack parking.
It is like the one shown in the photo, and it is commonly used as parking for residents of apartment buildings in Japan.
I assume that the parking area, including the entire parking aisle space, would be mapped as an area with amenity=parking + parking=multi-storey. But should the mechanical structures themselves also be mapped?
It might be possible to enclose the machinery and tag it as building=parking, but since the definition of a building is “a structure with a roof,” I hesitate to apply the building tag to machinery without a roof. If anything, would man_made=parking be more appropriate?
parking=multi-storey is for parking structures with multiple stories that vehicles can drive to via ramps. The levels of these stack structures are a bit different since the vehicles are not driven to them by ramps but instead raised and lowered by mechanical lifts. Seems like this could be worth differentiating with a distinct parking=* sub-tag. It’s not documented yet, but parking=mechanical_lifts shows a bit of use on TagInfo. Seems like it might be for this sort of parking structure.
I also think it should be a different type than multi-storey. Such structures can be automated or with manual control, I have seen smaller ones also in private garages (where you can stack two cars only and the owner operates it themselves) but there are also fully automated systems where you checkin your vehicle and it gets transported „away“ until you request it for checkout. Quite different situation and infrastructure.
Just found an article from 2020 which says the one I know was closed after 15 years of operation:
I have listed some ideas. Examples with Japanese terms and products are given. User:Kovposch/Proposal:Mechanically-assisted, mechanized, automatic parking - OpenStreetMap Wiki
I didn’t decide on what feature it should be. Although man_made=parking is a nice idea, quite a few existing building= don’t have roofs (viz =slurry_tank ), or aren’t proper “buildings” (=digester ; non-converted =storage_tank , =water_tower ). On the other hand, their existence inside building=parking does argue against building= , as building:part=parking would be misleading. That being said, this still needs to consider structures that are buildings (ie vertically-circulated paternoster-type, and lifting-type towers), which will end up with man_made=parking + building=parking ?
=mechanical_lift may be misunderstood elevator-accessed-only =multi-storey and =underground
The fundamental problem is these can exist in all of =surface , =multi-storey , and =underground , blocking parking=
Ok, I’m referring to them on single-storey ground-based carparks. But the message stands: a new parking= won’t solve it, as they exist inside =underground and =multi-storey
Comparison: Forgot where there’s a question about canopy covers on roofs (or similar), ie a mix of =rooftop and =carports
These can also be available on only a part of the space. Still I think we should distinguish robotized fully automated systems (check in check out) from simple lifts on individual parking spaces.
Yes, exactly.
As shown in the photo, some parking lots include both surface parking areas and mechanical lift areas on a single site, so it would be useful to map them together.
I think it’s acceptable to map as “building=parking” a multi-story parking building without a roof, so it might be okay to map a mechanical lift using “building=parking” as well.
What do you think about following the idea of “building:part” and tagging each parking type area as “parking:part=surface”, for example?
In the case of the photo, the entire parking area could be tagged as “parking=surface;mechanical_lifts” (or “parking=multi”), and each respective section could be tagged as “parking:part=surface” and “parking:part=mechanical_lifts”.
I see. I’ve seen standalone mechanical lift parking towers that are not within some other sort of parking area or structure. This would be the sort of thing that a distinct parking=* value would make sense for. I agree this doesn’t make as much sense for smaller mechanical lift structures that are within a surface parking lot or multi-storey garage (above or below ground).
I generally agree. I guess the question is when parking area has surface spaces as well as a mechanical lift structure, do we map that as:
A. One amentity=parking polygon containing both parking types since it is conceptually just one parking area B. Two separate amenity=parking polygons since there are two different types of parking=*
If it’s option A, and tagging the whole thing as parking=surface is wrong because part of the parking area is mechanical lifts, then I guess we’d need a different value that means “combined surface and mechanical lift parking”. We could also rationalized parking=surface as still being appropriate because the mechanical lift is accessed from the surface parking area, even though the car can end up lifted above the surface.
Following the explanation of “Partially boxed parking areas” in the “parking=garage_boxes” wiki, it seems that parking=surface is acceptable even when surface and mechanical_lifts are mixed.
Maybe, this wikipage was created less than 6 months ago and has only 2 revisions both by the same person, I would not expect it to necessarily represent any common agreement.
The specific page about surface parking doesn’t suggest there could be mechanical lifts to multiply parking lots:
