Hi Colm, I agree regarding individual mapping of parking spaces. It seems like an awful lot of wasted effort and time, which as you say will result in additional wasted effort and time in the future if and when changes are required. Less onerous is at least mapping clumps of spaces with single polygons, but it's not something I would do routinely for the same reasons.
My approach so far has been to map the outer car park polygon, but also on occasion to map any clumps of accessible spaces with a single polygon, to help provide location of such spaces. I wasn't aware that numbering tags in the parking space polygon (e.g. 8 total spaces, of which 8 accessible) where also included in the car park polygon (e.g. 200 spaces, of which 8 accessible) would result in navigation showing 16 accessible spaces in total. Is there evidence of this in practice? Perhaps there is a solution to map areas, but only include number tags in one or other polygon (spaces polygon or car park polygon)? The only other parking space mapping I use is where I've come across clumps of spaces *within* the car park already mapped as individual "car park" polygons. Navigation then sees e.g. six car parks instead of one. Rather than deleting all of these shapes and undoing someone's work, I have usually converted these to the "spaces" tag and then mapped the boundary of the car park. Again, I don't know whether this has any negative connotation in navigation, but it's more correct than it was. On your final separate point - it depends on whether the parking area is really a "car park" with an access road through it, or a road that happens to have "street-side" parking. This is down to interpretation really. Your first example is already tagged as street-side parking, so makes sense – although I tend to join these to the adjacent road, otherwise routing does not know how the parking area is accessed. Example 2 does have two distinct parking areas, separated from each other – I'd instinctively map this as one car park with additionally-mapped barrier=hedge, but depending on the use case, they might be considered separate car parks on the ground (one for staff, one for customers etc). The only strange thing is that the L-shaped parking is mapped in constant contact with and only on one side of the service road, which usually only makes sense when mapping street-side parking. If it's really a "car park" then I would map the entire tarmac area. Example 3 could be considered individual plots of street-side parking (which would make sense given the road is tagged as a residential rather than service road) *or* over-mapping of a larger car park area, meaning the current polygons should really just be amenity=parking_space. Again, if the former, I would join the edge of street-side areas with the road. -- Tony Furnell Date: Wed, 17 Dec 2025 16:17:06 +0000 > From: Colm Moore <[email protected]> > To: "[email protected]" <[email protected]> > Subject: [OSM-talk-ie] Mapping individual parking spaces within car > parks > Message-ID: > < > db9p193mb292182db8588ff73653c66c7bd...@db9p193mb2921.eurp193.prod.outlook.com > > > > Content-Type: text/plain; charset="Windows-1252" > > Hi, > > This email refers to the mapping of individual parking spaces > amenity=parking_space within car parks amenity=parking, where the car park > is also mapped. It does not refer to ad-hoc groups of 1-5 parking spaces. A > few mappers have mapped like this. I?ve long been sceptical about the > practice but haven?t acted. And, while it might be marginally useful (even > ?cute?) to show the spaces, it feels like 'mapping for the renderer'. > Mapping the car park outline and the parking aisles probably achieves as > much, but with much less effort. > > Specific issues that I have encountered: > > * It is double mapping, which can result in the number of spaces, in total > or in any category, being miscounted. OSM has the principal of one object > in the real world, one object on the map. Yes, there are sometimes > complications that need nuanced mapping, but I don?t think this is one. > > * Some car parks have dedicated wheelchair-accessible, family-friendly, > bus or other special category parking spaces. Double counting them might be > a particular problem - someone expecting 4 bus parking spaces at a site > shows up to find that there are only 2. Yes, showing people where the > special category parking spaces are located is useful, but these are > usually located according to a (not always obeyed) hierarchy of what is > closest to the destination entrance - public transport, bike spaces, > wheelchair accessible spaces, family-friendly spaces, electric vehicles, > other vehicles. > > * The number of spaces are sometimes miscalculated by the mapper, e.g. > there are 9 parking spaces in a row, but only 8 are mapped covering the > area of the 9. This results in a need to change all the individual spaces, > instead to only one car park. > > * During the lifecycle of the parking space, details can change. For > example, the Blanchardstown Centre has 7,000 parking spaces (not all > mapped) that are being converted to pay parking. > > * When a car park is removed / built upon, potentially hundreds of > individual parking spaces have to be retagged / removed. There were 867 > parking spaces in this temporary car park: > https://www.openstreetmap.org/way/1167858985 and they are now all gone. > There are approximately 1,431 parking spaces in these car parks, with a > chunk of them now built on: https://www.openstreetmap.org/way/1296475241 > and https://www.openstreetmap.org/way/1365517863 Hundreds of more spaces > have been added in the real world (not yet mapped). Grange Castle probably > has 8,000 parking spaces (not all mapped), most of them are temporary > spaces for construction workers that will disappear in 1-2 years. > > Overall, it creates an unnecessary maintenance burden, especially when > mappers want to add more tags or deal with removal. > > There is a separate, but similar issue of car parks (with say 50 spaces) > being mapped as several separate car parks (say 5 car parks each with 10 > spaces), for fear of mapping across a non-parking aisle service road, path > or patch of grass, e.g. here: > https://www.openstreetmap.org/way/1429772350/ or here: > https://www.openstreetmap.org/way/42873673/ or here: > https://www.openstreetmap.org/way/905605692 > > Any thoughts? > > Thank you > > Colm > > > > _______________________________________________ Talk-ie mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-ie
