Thanks for the DEFRA link - has some potential :-) The first issue I was raising was that for convenience some (commercial) OSM mappers were using a value like 0.75 per building level (or something similar) so that their rendering software could deal directly with OSM data without post-processing it. Effectively a 100 level set of flats would be marked as building:level=75.
The second issue is how to ensure that height values used for 3D mapping aren't just being made up (given previous behaviour) - or coming a source that isn't appropriate for OpenStreetmap. Unfortunately, I haven't managed to get the editors to cite the data source they are using for building (part) heights, etc. -- but I do note that the area isn't mapped by DEFRA lidar! Cheers, Neil P.S. Any suggestions on how I can measure buildings "on-foot" greatly apreciated... On 18/03/2019 15:31, SK53 wrote: > How very useful; had completely forgotten about this! > > However, I don't think that is Neil's issue, which is that > building:levels should have integer values (or just possibly steps of > a half). Some 3D renders make assumptions about what a default height > for a single storey (level) will be. A good example is > here: https://demo.f4map.com/#lat=52.9755467&lon=-1.2013530&zoom=18 (I > accidentally typed the house number into the building:levels tag). > > Jerry > > On Mon, 18 Mar 2019 at 15:13, Brian Prangle <bpran...@gmail.com > <mailto:bpran...@gmail.com>> wrote: > > Try this site > > <https://buildingheights.emu-analytics.net/?x=-2.0983833663121914&y=53.529861700711535&z=8.405213088272887>: > origin of building height data is Environment Agency LIDAR data > under OGL > > Regards > > Brian >
_______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb