i.e. vehicle inspection pit open for public is a place where you can go under the car the inspect / work on underside of it.
E.g. things like this:
The best I could find is Way History: 1268418583 | OpenStreetMap, but not really happy with it…
Any ideas? Current usages?
ah, found it: amenity=vehicle_ramp
yours doesn’t look like a ramp…
I’m not quite sure what you’re refering to:
are you saying there is better tag for that inlined picture above in 1st post; or that the amenity=vehicle_ramp as defined by osm wiki does not match what that picture depicts? To me it looks like pretty good fit. (both by OSM wiki wording, by example pictures on it, historical examples given, and by the linked wikidata item)
or are you saying that OSM tag (not invented by me) does not match the meaning of a term “car ramp” in the same way as the English dictionary would, and that e.g. amenity=vehicle_inspection_pit for the same concept would’ve been better naming of a tag?
But then the wikipedia for the term car ramp as a prime example also shows “A horizontal concrete car ramp in Scotland” which seems pretty similar to me?
In any case, that water seems to have long passed under that bridge, as we’re not inventing a new tag here, but discussing one used for a decade and a half… 
or are you just noting that the meaning of the full English term “vehicle ramp” does not fully match the meaning of each of component English words.
IOW, you’re wondering why the original inventor of the term (not me either 
) decided to use an idiom (i.e. “an established phrasal expression whose meaning may not be deducible from the literal meanings of its component words”) to describe the contraption, instead of some more sensible/deducible approach?
While I’d generally love leisurely discussing the latter two (preferably over beer 
) as much as the next guy[1]; at the moment I’m mostly interesting in first bullet point only.
I’d add “or gal”, but for a fact that the most gals I’ve had experience with are not really that much into it. Or, like, at all. YMMV. Also, that would invoke the question why I haven’t mentioned 2SLGBTQQIPAA+ etc. But if I stick with just “guy”, one might take it as a somewhat benigh careless use of an old common phrase ingrained in memory by momentarily lack of judgement, or one might interpret it that I’m not trying to be misogynist, but that “next guy” means a singular specific person, wink-wink-nudge-nudge-youknowwhoimean ↩︎
this. There is no ramp in your situation hence the tag doesn’t apply
You added “or pit” to the wiki definition for vehicle_ramp, but it doesn’t make sense, it was “maybe also has a pit” so “ramp or pit” significantly changed the definition and should be reverted
it’s on the border of what is a ramp, there is still some slope to get on and it is laterally delimited, the first picture in this thread shows a paved area with a pit, indeed it is also how you called it. A ramp IMHO has to have some slope, and is a linear element (although it could be quite large, i.e. wider than long).
for your example, this is clearly a perfect fit. Probably not for all ramps, as the wiki article says a pit is optional. If we’d want to lump them together, something without either ramp nor pit in the name would have been best, and we could have added e.g. ramp=yes and pit=no. If we established a new “main” tag for pits, and kept the ramp tag, it wouldn’t be clear which one to add if it is both.
I referred to original proposal in that wiki change comment, which says “Definition: A ramp (or sometimes a pit) where vehicles can be inspected or repaired by their owners.”
If it was imperative for it to always have a ramp, I would expect a wording like “A ramp (sometimes additionally having a pit) where vehicles […]”
Wording “ramp or pit” to me clearly indicates that it may be either (or both[1]), and term “sometimes” only clarifies that one is likely more popular then the other.
Also, it later mentions tags to be used with it, among them:
incline=yes/no- whether it’s a ramp (yes, default) or just two horizontal tracks with a hole between them (no).
which to me also clearly indicates that the incline might not be present (despite the amenity=vehicle_ramp naming of the tag[2]).
Well, in OSM amenity=vehicle_ramp is often tagged on nodes (both as documented, and in practice).
As for the syntax (wording) of the tag, I’ve tried to note earlier that (a) OSM tag is not an English dictionary, and (b) even in English dictionary, some terms might be idioms (e.g. “grease pit” mentioned in that wikipedia article does not really have to have any actual grease either).
So it IMHO mostly makes sense to propose better wording before the tag gets widely used, not after.[3]
I’m personally doubtful that it would be worthwhile, but if you do run a proposal for it, please do link it here too so interested parties could follow.
especially if we prefer boolean algebra ↩︎
an aside: each day I am getting a more and more convinced that human-agnostic wikidata identifiers are way superior idea to OSM human-readable tags. Sure, they’re harder to remember by heart, but the sheer enormity of time wasted on pointless discussion of OSM tag syntax, instead of on actually important semantics that it more then compensates. A rose by any other name would smell as sweet, eh? And I’d assume most people use presets nowadays anyways, so that disadvantage might not be even noticed by many. Not that I’m likely to propose such change at this point in time, for hopefully obvious reasons ↩︎
I mean, sure, highway=street_lamp is stupid hierarchy for lamps as they are not highways, and and often not even near highways, as is shop=hairdresser (you’re exchanging money for service and not goods there), and many other examples; but it is enormous waste of time trying to correct them now. ↩︎
it is abandoned
in the example you posted there is no ramp, no incline and also no horizontal tracks, there is just a hole
I don’t understand why you opened a discussion here if you are not open to listen to arguments.
You cited from wikipedia and they distinguish an inspection pit from a ramp: Vehicle inspection pit - Wikipedia
For me, there’s the micro possibility to draw 2 features next to each other at the same time in detail. =vehicle_ramp for the ramps, and =vehicle_pit for the pits in between.
But it’s obviously poorly named. Referring to amenity=vehicle_inspection , the structure could be man_made=vehicle_inspection
incline= seems abused. It could reuse ramp= eg ramp:motor_vehicle= / ramp:vehicle_inspection=
There’s further an ambiguity for whether the ramps or pits themselves are inclined
ORM users suggested simply railway=pit for pits OpenRailwayMap/Tagging - OpenStreetMap Wiki
TL;DR: The tag was IMHO clearly documented to be used for both ramps and pits. Its chosen name was bad (and its suggested extra tags could’ve been better). Is deprecation of existing tag and proposal of a new tag(s) worth the effort - and the suggestions for it.
Yes; the proposal was not completed; yet the community still used it to tag more than thousand occurrences, as there was a need and nothing better proposed. That is often how it goes in OSM (unfortunately).
But Even if you look not at the proposal but at the actual Tag:amenity=vehicle_ramp wiki page history, you’ll see that from the very beginning it explicitly talked about it covering both the ramp and the pit cases, i.e.
incline=yes/no- whether it’s a ramp (yes, default) or just two horizontal tracks with a hole between them (no).
To me it seem there was a clear intention from the very start for that tag (despite badly chosen name) to serve both purposes.
Yes. And from the wiki, its preceding proposal and the actual usage it seems quite clear to me that the OSM tag amenity=vehicle_ramp was both intended and is actually used to cover both structures described by those two different Wikipedia pages.
Do you agree with that at least? Or if you don’t agree, what are your arguments that the OSM tag amenity=vehicle_ramp was not supposed to cover the cases without the ramp?
And yes, I absolutely agree with you that it should’ve been more properly named amenity=vehicle_ramp_or_a_pit_or_both[1], but it is what it is - I (nor you, I’d assume) can’t change the past.
Initially, if you look at message flow, because I wasn’t aware of the existence of amenity=vehicle ramp (if I were, I wouldn’t have opened the discussion)
I am willing to listen to them, I’m just not willing to accept them if they’re not making sense to me. You seem to be ignoring the document wiki history[2] of that tag and how it was documented (and thus allegedly actually used) in preference to how you would like it should’ve been proposed, documented and used all those years ago.
While I agree with your wishes (I too would’ve liked if that proposal was not abandoned decades ago and instead more people worked on it, and with its proponent found better name and ideal solution how to tag both ramps and pits used for vehicle inspection / repairs in better way), that was not to be.
Assuming we can’t modify history, and that we really should try NOT changing the meaning of tags that are already in wide use (lest the tag become skunked), that IMHO limits what can be done at this point.
I agree.
I am open on discussion / proposal how to deprecate amenity=vehicle ramp and replace it with different tag(s) which better (in less confusing way) allows for tagging such structures “intended for persons to do vehicle inspection and repair themselves”.
I think this would be good to keep in mind when designing such solution:
amenity=* namespace (which is overused, but then again this is actually an amenity IMHO), or is some other namespace better fitting (man_made?)That is also a possibility for micromapping, perhaps tagging the ramp or horizontal tracks as a way with one tag, and a pit as an separate area with layer=-1 under that way.
But that would lose the simplicity I’ve suggested above. I think it would be better if the same general tag could be added on a node, a way or an area, and extra tags used to add details (e.g. whether its a ramp, a pit, or both)
I don’t know, I have not mapped many of these so far, but generally the current documentation is relevant, especially the parts that are unchanged for a longer time and when there are more instances of the tag than just a handful. I do not believe you can make changes to the established definition just by referring to the original proposal of many years ago, and even less if it was abandoned rather than approved.
it was originally documented by a user in 2018 and the same user changed the part about the pit in 2022 to say that the ramps are required but the pit is optional: Tag:amenity=vehicle ramp: Difference between revisions - OpenStreetMap Wiki
I agree with this. IMHO we could introduce a new tag for pits, and maybe a property for “has a pit” for ramps? Distinguishing features by form is fine as it would be by pure function. If someone was to introduce a place where you could inspect the bottom of your car with a video camera, we wouldn’t want to extend the meaning of vehicle_ramp to mean video cameras, would we?
If the name was generic, I would be fine with a generic tag interpretation (and subtagging if we wanted to distinguish more), but as the term is specific, I think it is best to use it for things which fit to the specifics.
I can work with that. So if we use E to symbolize meaning is “either ramp or pit”, and R to symbolize “ramp, sometimes with pit”, we can guess that
So:
EE.All in all, one could guesstimate that between 70-85% of uses were E, and 15-30% was R (not that exact numbers matters match for final decision – in any case, non-significant number of different meanings would be in the database). Now, given that R is a clear subset of E, the options (that do more good than harm) that I see are:
E. That way, 100% of the data remains correct (as E is superset of R). This is what I did.E is only for uses strictly done before 2018, and that everything added between 2018 and 2026 is R only, and that the tag should be hence defined as skunked and the {{Questioned}} template added to it to warn the editors and data consumers of what they should expect.amenity=vehicle_ramp (that is what I outlined in previous post)Do you see more possibilities that produce more good than harm?
Adding just a new tag for only the pits would however only solve half of the problem; i.e. amenity=vehicle_ramp would still remain skunked. So you’d need new tag for ramps too. Only way to minimize problem of skunking of this tag is to use a definition which covers both E and R at the same time – and that happens to be E in this case.
That way, the meaning of the tag is always going to be 100% correct, but some 15-30% of the uses of the tag might be less detailed then envisioned by the mappers at the time – i.e. they might’ve (or might’ve not) wanted to add the detail that there is incline=yes (as in original usage) but not added it as they though it was implied by changed definition.
If we were discussing a new, yet unused tag, I’d fully agree. However, given that the tag is already in use, I preferred option (1) above.
Option (3) is technically superior, but several orders of magnitude more work. But if someone were to put majority of effort into it, I’d try to back them up as much as my free time permits.
Option (2) is basically just giving up (i.e. simply noting that there is an issue that nobody is willing to put in the effort to solve) - but is easy, states the unassailable facts only and thus avoids any potential disagreements / conflicts about its factual accuracy.
We wouldn’t, but only because it does only a small part of the job (even if the camera was fully mobile). The meaning of the tag is that it is used for “vehicle inspection and repairs”. Camera (even mounted on a perfectly miniaturized drone with AI) would still allow only for half of that definition, i.e. “inspection” (and not “repairs”).
Better example would be “what if the amenity had an anti-gravity field which would allow you get below the car and inspect and work on it just like you would on one with regular ramp, without there being any physical support for car to stand on”… Nice question, but yeah, IMHO it would qualify for amenity=vehicle_ramp + ag_field=yes (provided we were still using OSM in its current form).
But we can discuss that one is more detail when they make it available 
It is tagged as an amenity=* in OSM, and it makes sense to me - it is something that you’ll actively seek out to do certain things. When you need to inspect and repair your car by yourself - you’ll go out and seek those. Just as you might seek out an amenity=restaurant when you don’t feel like cooking at home.
Small technical implementation details like whether the vehicle needs to go a little up, down, or straight during setup, or whether it’s made of metal or concrete, are of significantly less importance. You’ll manage to inspect and repair (or not) your car equally well in either case regardless of that detail in vast majority of uses.
One might prefer to record (and use) some details in some cases (e.g. if you motor is dead you’ll likely prefer an amenity with no or little incline instead of having to push the car upward manually), but that is IMHO a reason for extra detailing tag (i.e. incline=yes/no that original tag used for 9+ years), and not for a wholesome new different main tag (e.g. amenity=foobar_without_incline).
TL;DR: Duck tagging would determine what it makes sense to tag with amenity=vehicle_ramp.
from a utility point of view, yes. What about bridge and tunnel, couldn’t we tag all tunnels as bridges, because they both are just features to avoid level crossings? Whether you go over or under another feature is just an implementation detail that can be recorded with additional tags, what counts is the fact you don’t have to share the space. Admittedly kind of a stretch, but it serves to illustrate that functionality is not the only characteristic we look at.
Ummm, I don’t know about place where you live, but over here, tunnels are not only (or even primarily) used as a features to “avoid level crossings”. We like to use them to e.g. avoid cris-crossing over the mountain and have shorter, faster and protected road through the mountains, or to allow access inside building blocks (tunnels through the building) etc.
And neither are many of the bridges for that matter – we also like to use them to cross over bodies of water and other chasms, something we don’t use tunnels for.
IOW tunnels and bridges generally function quite differently (and only in some smaller percentage of cases could they be used interchangeably) - which is why I asked whether amenity=vehicle_ramp with incline=yes functions fundamentally differently then one with incline=no in your experience for significant number of its users?
(because, IME, and contrary to the tunnel/bridge example, amenity=vehicle_ramp doesn’t differ all that much regardless of the incline, thus duck tagging applies)
In any case, (apart from enjoyable friendly banter) what do you think should be an actionable way forward regarding amenity=vehicle_ramp tag? I.e.:
I think using the ramp tag for something that isn’t a ramp is confusing, what would be next, including also hoists? I’d go with a new tag for inspection pits, but would not deprecate the ramp tag.
Despite the photo description, it’s neither a ramp nor a pit. We need a new tag for this kind of structure, then.
TL;DR: how/why do you think such half-solution would help? I don’t see it at all, I see only extra problems being created and no existing problems solved.
Sure. Many tags in OSM have confusing names which is not ideal - e.g. highway=street_lamp might imply street lamps are types of highway (when in fact they do not need to be even related to highways in any way, much less be one), or natural=water + water=canal (even though such canals are completely man made and unnatural), or any of the other Counterintuitive keys and values.
Yes, such situations are confusing. That is why one should think hard at tag creation time (i.e. ideally follow proposal process, as several minds are better then one), as when such tags becomes well-used if will be far too late to fix it properly.
It is also why one absolutely should read tag documentation before starting to use new unfamiliar tag and not assume[1] “Oh I know this English word so this tag must mean this thing, so I’ll just assume it should be used here” – because it would often (maybe even more often then not?) result in incorrect tagging[2].
I’m confused what such half-solution is supposed to accomplish? AFAICT, it would:
amenity=vehicle_ramp which is for both ramps and pits - and is more popular; or should I tag it as man_made=new_pit_tag - which is pits only but much less popular; or should I dual tag both?”[3]), andIOW, doing it half-way (only introduce one new tag, do not touch old tag) would be lose-lose situation.
Could you clarify what you hope it would accomplish (and why / how)?
To me, is seems to boil down to the this root question: “is the difference between those two amenities (being used for the same purpose) important?”:
incline=* to specify differences if you’d still like to note them, even if vast majority of data consumers won’t care).And one related research question if I may (there are no wrong answers, it is curiosity only to help me understand how people think): if the OSM was using “item=Q6921” format[5] instead of “amenity=vehicle_ramp” to refer to the same thing on the ground, would your recommendation about one new and one old tag still hold, or would it change? (And why/why not?)
as the saying goes, when you assume, you make an ass of u and me ↩︎
e.g. “apartment” is nice simple word, yet assuming that the building that has apartment for rent is apartments building is simply wrong ↩︎
see e.g. healthcare=* namespace for example how well-intentioned efforts for “tidying up” may backfire and waste huge amount of resources and end up being a big net negative for OSM ↩︎
propose the tag and push it to acceptance, get data consumers to support it, advertise it to the new and old mappers, organize resurvey parties to re-tag some of them to get a base level of usage, etc. ↩︎
i.e. dataitems like wikidata.org uses for example ↩︎