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â
With one big parking and varying orientations, tag only on the aisles.
With one big parking and just single orientation, tag only on parking area
With parking blocks as per the example, only parking details on the blocks, not on aisles
Tag it on all.parking areas and aisles.
That 's of course for those who care to tag parking particulars at all.
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=serviceservice=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.
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.
⊠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.
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.
This is a best practices question, so forgive the resurrection of this thread if thatâs generally not how things work around here. Iâm new to the forum, OSM, and finding all the information channels, contradictory theories, etc a bit overwhelming.
Iâm mostly working through StreetComplete at present. When asked to tag parking lots, Iâm obviously going to default to the lotâs signage, but what to do when I canât find a sign or no sign exists. Do I assume itâs open to the general public, customers only, or requires permission? Can I use my knowledge of the area when no sign exists?
My assumption is that most lots are either customer or private unless the lot is clearly intended for anyone. I just want to be sure thatâs how we approach things.
The short answer is yes. In some countries, these restrictions are always explicitly signposted, so mappers expect to record them literally, while in other countries, you need to incorporate some common sense or local knowledge. For example, in some U.S. states, a parking lot on private property might not be marked as such, but you might be able to infer customers if fronts a shopâs front door or private if itâs behind the building and gated off. If in doubt, StreetComplete should also have an option that corresponds to unknown.
I decided to try to extend the sidewalk on the west side of the street. When I get to this driveway (red circle), I get an error/warning âSidewalk crosses Drivewayâ when the actual on-the-ground geometry is the opposite.
Locally, most sidewalks are concrete and extend from end-to-end (roughly of the block, but we do have many places where thatâs not true in my city). So the drivewayâs asphalt ends at the sidewalk and generally a concrete ramp then completes the auto path between the sidewalk and the street.
I get there are issues with breaking paths for either autos or pedestrians and this could get overly complex really quickly if I was to map what technically exists onsite. Further, while my primary interest is to map out my local pedestrian infrastructure so I have a backup to my mental map should I find myself in an area I visit infrequently, I donât want to render the maps useless for other users.
Anyway, I selected âDriveway/Service Road crosses Sidewalkâ. There are two options: âConnect the featuresâ and âConnect using a crossingâ. Whatâs the difference? (sorry, searched the Wiki but so far no explanation pops out). And again, any suggestions on best practices?
Also, in the reply above Minh has customers, private, and unknown formatted as Preformatted text? Is this a preference for the forum (as opposed to my putting things in quotations)? Again, just trying to understand the lay of the land, or forum, as it were.
The warning is that the driveway and sidewalk cross over each other without being connected at a node. This can be a problem for routing engines, especially if it should be possible for a pedestrian to turn from the sidewalk onto the driveway or vice versa.
Both options connect the driveway and sidewalk, silencing the warning. The second option additionally turns that node into a Pedestrian Crossing (highway=crossing). Normally, the first option is good enough if the sidewalk continues uninterrupted past the driveway, but youâd use the second option if thereâs something more substantial such as curb cuts or markings, like you might find outside a business.
(Thereâs an ongoing discussion about whether we need to somehow explicitly indicate the more mundane case too, but there isnât a concrete proposal yet.)
I donât think anyone is picky about the formatting. Around here, when you see preformatted text like that, or something of the form key=value, this refers to a tag. In the iD editor youâre using, you normally donât have to fuss with tags, because presets and fields are available for all of the common feature types, but you can expand the Tags section of the sidebar to see the raw tags on a selected feature.
Around here, when you see preformatted text like that, or something of the form key=value, this