fzi-forschungszentrum-informatik / Lanelet2

Map handling framework for automated driving
BSD 3-Clause "New" or "Revised" License
800 stars 327 forks source link

Lanelet2 Height Standard #80

Closed icolwell-as closed 4 years ago

icolwell-as commented 4 years ago

Hi There, I'm looking for some clarification on height in Lanelet2.

The docs here state the following:

OSM data is stored in WGS84 (aka EPSG:4326) as are GPS positions by definition. It assumes the Earth is an ellipsoid (the corrected WGS84/EGM96; it's quite ok) and references the height w.r.t. this ellipsoid as altitude. However, as we assume that the map is ground-located, we'll refer to this as elevation (as it's done in the OSM standard).

However this seems to conflict with this OSM page that describes the "ele" tag in respect to what height the "ele" tag should have. The OSM page states "ele" should represent MSL height, but the lanelet doc seems to suggest WGS84 height. I also found this which confirms Lanelet2 uses WGS84 height.

So is this correct? Lanelet2 uses WGS84 heights for the "ele" tags while OSM uses MSL for the "ele" tags?

poggenhans commented 4 years ago

It seems so, yes. The as its done in the OSM standard part is supposed to explain why we use the term "elevation" instead of e.g. "altitude" or "height".

I suppose the MSL convention is used by OSM because it is a more "human understandable" definition of elevation. For lanelet2, we thought that the pure geometric definition from WGS84 makes more sense. I would also consider it less error-prone, because the evelation in maps usually comes from GNSS receivers that output elevation in WGS84 and not MSL.

icolwell-as commented 4 years ago

@poggenhans thanks for the clarification! From what I can tell, the OSM community rarely uses the "ele" tag. https://help.openstreetmap.org/questions/72717/clarification-about-elevation-data-in-osm https://help.openstreetmap.org/questions/9681/adding-elevation-data-to-existing-routes-conflation

I agree that WGS84 is best for the reasons you mentioned. Although MSL elevation can be useful since some projections use MSL height (but this can be accounted for in the projection conversion).

Would it make sense to use a "wgs84_height" (or "ell_height" for ellipsoid) tag instead of "ele" so that it doesn't conflict with OSM? Most places I see WGS84 data, the field name is "height". Or is it best to simply leave as-is and let the user decide which height/elevation is best for their use case?

I'm happy to open a PR to clarify this in the docs once we sort it out.

poggenhans commented 4 years ago

My impression is that elevation data is generally handled very inconsistently in OSM and is almost always wrong or at least very unreliable. The OSM community seems to be a bad example in this regard. Due to that, I can very well live with the different definition used for the ele tag because the temptation to "copy 'n' paste" elevation data from OSM and hope it works will be quite low.

All other options are worse, I would say. "height" is usually used to indicate the height above ground, "alt" or "altitude" rather indicates the height above sea level and "wgs84_ele" or similar is too verbose. If your intention is to express "my data is really WGS84 and accurate", I would rather use a separate tag like "ele_is=wgs84". We could also think about using "ele:wgs84" as proposed but deprecated here. but I am not sure if OSM editors could flag that in the future.

Also note that we only encourage to use WGS84 and assume that this is true by default, but there are also users where the height is e.g. always zero. In this case using "wgs84_ele" or "wgs84_height" instead would even be wrong and misleading.

icolwell-as commented 4 years ago

Sounds good, makes sense to me! I'll try to get a PR up soon that clarifies all this in the docs.