Been estimating building heights and roof heights for longer when these are deemed (by me) as incorrect from the standard extrapolation, e.g. an apartment building with 5 floors and a ground commercial/retail floor I estimate as 4.5+5x3 (the standard assumption), + whatever a roof height by approximation, which can be from very low angle sloped to skillion, low gabled, or normal etc. Whenever heights are estimated I enter, if not forgetting, source:height=estimated as a tag in use since about 2014 See source:height=estimated | Tags | OpenStreetMap Taginfo
Yesterday in a discussion est_height popped up (never encountered myself) and now see on an object which I mapped last week a change to roof:est_height for the top part. Looking in TagInfo shows 13 uses. So, whatās up with this as I see no actual discussion of estimated height tagging of recent, some comments like āI never use height tags on buildingsā or something with that intend.
Itās wurscht to me, but it would have been nice if there actually had been a write up of this rather than a shoehorn.
estimated is not a documented value for Key:source - OpenStreetMap Wiki. For a good reason IMHO - it is pure guess, and OSM strives to be be verifiable. So if I estimate it is 27m, and you estimate it is 23m, what should be mapped? height=20-30? height=25+-5?
While it is helpful that you add source:height=estimated (because next mapper who comes by with different information knows they can discard your value without prejudice), it does not really help data consumer apps (which would not parse all the possible values of source set of tags).
Yesterday in a discussion est_height popped up (never encountered myself)
Well, did you read height=* wiki? It does mention it.
So the compromise was the est_height tag. Not verifiable (it is in the name!), but still allows people to add at least some approximate estimation if no other more useful information is available.
which I mapped last week a change to roof:est_height for the top part. Looking in TagInfo shows 13 uses.
Sure, does not seem much. However, it also shows 0 uses of source:roof:height, so est_height wins here too. One should really apply same level of detail when comparing different tags. (OTOH, if one looked at the more generic tags, there is 5k source:height=estimated vs. 5.8k est_height=*, so est_height wins again the popularity contest, but by much smaller margin)
My opinion on this is more or less the opposite to what @Matija_Nalis wrote:
Iām in favor for using āheightā combined with āsource:heightā (and in the same way for all other est_* tags that exist), for a couple of reasons:
using est_height tags means that every data consumer needs to check two tags to find height information
there is no clear rule when to use one or the other tag. What is an āestimationā and what is a āmeasurementā? Counting the number of levels and multiplying by the measured height of the first floor - is this an estimate?
the information that itās only an estimate is mainly important for other mappers who can try to get a better estimation or measurement but not for data users.
most data consumers donāt need to differentiate between estimates and measurements - they show or list an object with the height that is tagged. If the distinction is important, they can still check the source tag for details.
The same holds for āmeasurementsā when both users have different sources or measure at different points on the object.
Iām also curious about this āexampleā on the est_height wiki page. I donāt think this makes much sense as a generic description - this only works for buildings which are very close to each other, and should not be used as general advice how to map.
From the point of view of a developer, mapping estimated heights using height=* can be preferable ā specifically if I prefer an estimate over having no height data at all, and if my application does not need to treat estimated heights differently from precise heights. In the context of 3D rendering, this will almost always be the case, so it would be more convenient for me if mappers used source:height=estimated (which I could then simply ignore because it doesnāt matter to me that the height is estimated) instead of an entirely different key.
Developers of an application which really cares about precision and would rather not have any data than inaccurate data might find it more convenient if estimates were banished to est_height=*. But I suspect this isnāt as common.
Of course, the current situation where both approaches are too common to ignore manages to be equally inconvenient for everyone.
Verifiability is about the ability to demonstrate that information is correct. Which comes in precisely when thereās such a disagreement: One of you can win the argument by getting a precise measurement and proving the other mapperās estimate wrong.
Verifiable isnāt quite the same as verified, after all. And iterative refinement isnāt uncommon in OSM, itās what happens when someone first draws a way based on a single coarse GPS track (or even just from memory!) and others improve it later based on additional tracks, high-quality imagery or other sources.
One thing about āforgettingā Iāve remedied swiftly by enhancing my JOSM Simple 3D building custom preset and add the source:height=* with selection (the tag and value that actually also existed in ID Editor when I started active mapping in 2020ā¦)
At 13x used, easy to visit them all, 13x used in the span of almost 10 years to include last night. That really gave it traction, all looked at and got to find one miracle use which goes on 1 object.
roof:est_height=3
roof:height=3
A tag for all seasons.
PS It is rather obscuring to see oneās (semi) established tags being replaced by something so rarely used., the chronology truly ahum, to include going from 16 back to 12.
