I spotted what I suspect to be one of these at an airport and while I don’t actually have the confidence in that one to map it definitively I noticed that the one at Heathrow is tagged as if it is a normal taxi rank.
If I understand correctly these aren’t actually places where a member of the public can get a taxi but are used to hold the “excess” queue of taxis before sending them onto the actual amenity=taxi at the terminals.
Has anyone been mapping these in a pore precise way? If so how?
Would it be over-simplifying things if you just declared it amenity=parking access=no taxi=yes?
@38446, that doesn’t seem “overly simple,” it seems slightly confusing to me as a human and I’m not sure how confusing (at least “somewhat,” I suppose), to data parsers / consumers.
@InsertUser 's original question does summarize “what these are” pretty well, but I don’t have a suggested set of tags “better” than yours. I agree amenity=parking is at least one good tag, but the access=no and taxi=yes tags do seem confusing to me. However, again, I’m not sure what is better. (I don’t think it should be these, is what I’m trying to say, as both humans and parsers would likely find the combination confusing).
Maybe we need to “coin” a new tag for this? Maybe parking=taxi_queue_overflow or something like that?
I think the issue with this is that I don’t think it works like normal parking, and from what I’ve seen you might not even be able to get your taxi out again unless you’re lucky with where you end up or are near one end of the queue.
If these were common enough features then to model them fully I think we might need a relation tying the passenger waiting area and the remote waiting areas for the taxis themselves. Probably along the lines of the public transport stop area relations.
If it needs a new tag it might be something to put under the public_transport=* umbrella without an amenity tag as anything surfacing these would probably be quite a specialist application rather than something showing public facing amenities.
Potential tags:
public_transport=taxi_feederpublic_transport=taxi_overflowlanduse=depot + depot=taxi_waitinghighway=rest_area might work, but would spring a new condition on existing data consumersamenity=parking + parking=taxi_queue_overflow as suggested by @steveaI think highway=rest_area is too forward-facing; I’d get confused looking for a rest area, but then be surprised (at some point in time or at some level) and even frustrated by “oh, only for taxi drivers.”
Bouncing this off of / soliciting the feedback of those deeply involved with public_transport=* seems wise.
I’m familiar with neither * landuse=depot nor depot=taxi_waiting (I am familiar with landuse=*). A bit of research shows Tag:landuse=depot - OpenStreetMap Wiki offering a purple triangle warning of:
“Consider using rather landuse=industrial with industrial=depot providing the same information in a structured way.”
Thanks for mentioning a possibility of amenity=parking + parking=taxi_queue_overflow (which was coined ad hoc, still not a terrible idea, especially as coined “any tags you like” are more-widely vetted).
As I think about it, tagging access with access=no and/or taxi=yes doesn’t seem wrong. Maybe, yes?
Ball seems to be in your court, Original Poster. Looks like a pretty blue sky from here. Proposal? Wiki entry? Wider consensus? In-the-wild-tagging-in-our-map? A bit of taginfo and/or OT research? Up to you, really.
Yeah this seems to be beyond the Q&A style of this particular category, I have started a related thread on a more discussion oriented part of the forum.