|
A shop has several parking places reserved for customers. How would I tag the parking places to indicate that they are reserved to that particular shop's customers? In most cases such places are adjacent to the shop's building, but in one case the parking places are actually on the opposite side of a I think perhaps that could be mapped as a multipolygon with the shop and the parking places as role='outer' members, or with a 'site' relationship with both the shop and the parking places as role='' members. Thoughts? Other options? |
|
I thought the common way to map this is, is with access=customers; operator=... Perhaps not on the complete parking but on the amenity-parking_space in this case Wouldn't operator= on the parking indicate who operates the parking --- who may be a subcontractor of the shop? E.g., if I saw an operator= on this hotel's parking, I would assume the hotel outsourced the operation of the parking lot.
(12 Jul '17, 20:43)
dsh4
I mean, if I saw operator=something other than "Travelodge" on that parking.
(12 Jul '17, 20:44)
dsh4
Yes, operator will work in some cases but won't in others.
(12 Jul '17, 21:00)
scai ♦
|
|
Hi read these lines, http://wiki.openstreetmap.org/wiki/Key:access, following that you should use access=private and you could add access:conditional=customers "name". And add operator="name" to the area as well. |
There is actually a little used, and presumably NEVER consumed, relation type for exactly this problem called associatedParking. It might not be consumed but at least captures the information.
@SK53: This kind of relation is probably the only universally applicable solution. But please use associated_parking, not associatedParking. The naming conventions for OSM tags suggest lowercase words separated by underscores, not camelCase. And given the low usage numbers and lack of application support, there's no reason to keep the problematic spelling around for compatibility.
For posterity, the current uses of associatedParking has the main entity as a member with role="" and the parking as a member with either role="" or role="parking".
I still feel, though, that a 'site' relation with role="parking" members would scale better (if somebody wants to invent another thing that's associated with a shop, besides its parking spaces).
@Tordanik I merely provide an example which someone else had created and which I used 2-3 times. I suspect along the lines of associatedStreet which has 250k+ instances. Consistency is always good, but needless duplication for the sake of consistency less so.
Regarding site relations, I did have a look at consuming them for map display, but after looking at their usage I couldn't really figure out which ones were useful and which ones weren't - they seemed to be used (in the UK) for a whole range of "X is somehow associated with Y" that it wasn't easy to do anything useful with at rendering time (not a technical problem - knowing what the user meant was the problem).
If you're going to use either a site relation (or some other sort of relation) for parking add a dozen or so examples and say what you're doing in the changeset comment and discussion, and document it in somewhere in the wiki.