if only some points are in the sea, response contains a geometry with points for which elevation is known, but points in the sea are omitted from the geometry.
Is this the expected behavior?
It seems sea is outside of elevation boundaries, but still the behavior should be more consistent so that it is easier to process on client side:
point request should return a specific “unknown” error code (to be distinguishable from execution errors)
line should always return a geometry with same number of points as the request, points with unknown elevation may simply have no elevation data (only coordinates)
Does this look reasonable?
Any chance to have sea/ocean area covered by elevation service?
yes, you’re right, we’re only importing SRTM thus far, which doesn’t include sea at all.
Thanks for the report, I agree with your points. I’ll see what I can do to make things more consistent and add some tests. Although a PR is always appreciated:)
line should always return a geometry with same number of points as the request, points with unknown elevation may simply have no elevation data (only coordinates)
On this I’m not so sure. I can see you’d want the input coordinates returned in the response for easier processing, rather than returning null for unfound elevations (which I’d have done tbh). I can do [lon, lat, null]? Rather than just returning [lon, lat] for those entries? To make it a little more clear.
Not so sure how geometry interpreting libs are commonly handling None z values. Any clue?
Thanks for your positive feedback.
I agree with your suggestion to return [lon, lat, null] instead of [lon, lat].
Such update would definitely help processing elevation responses. I won’t be able to do a PR, but I am available to help on testing if this is helpful.
Keep up the good work.
Actually I’m expecting ocean elevations to be 0, I’m not interested in ocean deepness.
For ORS it could make sense to return one or the other value depending on a request parameter.
It’s a little of a philosophical question I guess, if you consider earth surface to be bathymetry or sea surface. Since I actually cut out all 0 values (sea surface) from SRTM the semantically correct way would be null.
However, we should get many more elevation datasets to combine them. Bathymetry would have a great many use cases, but those usually require higher resolution than what is freely available for the whole planet.
I have an idea who to ask to have a look at alternative datasets, I’ll keep you updated.