Apologies for what ended up quite a long email, and for adding the wrong subject line in the header [facepalm emoji]
Merry Christmas to those who celebrate :-) -- Tony Furnell Date: Fri, 26 Dec 2025 11:30:06 +0000 > From: Tony Furnell <[email protected]> > To: [email protected] > Subject: Re: [OSM-talk-ie] Map locations for teaching OSM > > 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 > > > > 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
