Add height over sea level to the API and box configuration dialog

[hakan42]

Currently, we can configure the location of a senseBox.

Having information about the height over sea level would be very useful in statistical analysis of pressure, temperature and lighting data.

If a box has no height information, or the user does not want to find and provide any information, a checkbox in the GUI could tell the API to use the height from openDEM ( http://opendem.info/download_srtm.html ). For the already existing boxes, this checkbox should be initialized to "true" so all boxes immediately have valid height information.

Also, this information should be returned in the "loc" item of the API call.

[noerw]

Good idea! In my fork - which implements support for mobile sensors - a height coordinate is included. It allows an optional height field in accordance to the new GeoJSON spec: as height above the WGS84 ellipsoid. As GeoJSON is used for most location queries, this should also be the output reference system for height.

It would indeed be nice to support other input formats. What comes to mind is: height above...

1. WGS84 ellipsoid (used by gps-tracked sensors)
2. terrain (manually determined for fixed sensors)
3. sea level (???)

For case 2 an input transformation could be implemented using the mentioned OpenDEM.

However I am not sure if the transformation to arbitrary output reference systems should be part of the API. Instead this could be delegated to the API user, to keep the API logic & -interface lean. Also I am opposed to setting the default-height of a sensor to OpenDEM. When no height data is available, it is not available; anything else would distort the dataset.

[hakan42]

You are right, height above WGS84 would be the right way to go. I only mentioned "über Normalnull" because this is the data item that is easiest to obtain for novice users. Simply look up your city on the Wikipedia and you have the height :)

I am thinking by now whether we could have two height fields, one for height above the WGS ellipsoid and one for height above ground. This is the way the netatmo devices report their locations.

[ubergesundheit]

Currently the locations of the boxes are stored as GeoJSON Point geometry. We then should conform to the spec and only extend the point geometry with a height above the WGS84 Ellipsoid. I think this would be the easiest to implement and would also only require the extension of the coordinates array in the point geometry.

I am not sure though how to get to the height value then. We could add a field for users to specify height above the ground. But WGS height + user height isn't neccessarily the correct height then.

I agree with @noerw that transformation shouldn't be the job of the api.

A height for sensors or boxes would be nontheless a really useful feature.

[Adorfer]

I would suggest to make a radiobutton selection "height over ground" and "standard elevation zero".

Since most people just have a GNS to get the WGS84 height, which is -by design depending on the precision the firmware provider the chipset paied for- something with +/-50m deviation depending on the region you are in. Meassuring the height over ground (even when just counting the floors and multiplying by 3m) and adding the elevation from SRTM is far more accurate in most regions.

(And please do not start talking about "über Normalnull" otherwise i will suggest using psi for pressure and F for temperature. Alternativly provide a flux capacitor to take us all back into the 1980ies.)