Timeline for Recommended way to explicitly distinguish 2D from 3D locations
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 20, 2014 at 6:29 | comment | added | Chris W | @heltonbiker In theory, yes. If it's z-enabled it at least has the option of storing that data even if not currently present, whereas non-z must always be derived. But in practice, if the values are all null for whatever reason then as far as use goes it's no different than 2D data. | |
| May 20, 2014 at 2:25 | comment | added | heltonbiker | That seems very reasonable, and was exactely the kind of reasoning I was looking for. You correctly inferred my interest is on data-types and by the aforementioned distinction, I believe it's qualitatively different to have a z-enabled type where elevation data wasn't available and thus is null, and a different, inherently planar or "terrestrial" data-type where z is a direct function of lat/lon, and is to be determined indirectly somehow (either by GPS, being then a special case of a 3d trajectory, either via DEM querying). What do you think? | |
| May 20, 2014 at 1:31 | history | answered | Chris W | CC BY-SA 3.0 |