Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Altitude mode #8

Closed
pdavidc opened this issue Aug 26, 2016 · 2 comments
Closed

Altitude mode #8

pdavidc opened this issue Aug 26, 2016 · 2 comments

Comments

@pdavidc
Copy link
Contributor

pdavidc commented Aug 26, 2016

Support for shape altitudes relative to ground and relative to the ellipsoid. From the COE requirements document:

Altitude Modes – Applies to all Features

Support for altitude above ground level (AGL)
Altitude relative to the underlying elevation of the given terrain directly beneath the geospatial coordinate. A vertex with an altitude value of zero or higher will always be visible above the terrain

Support for Mean Sea Level (MSL)
Altitude relative to sea level which does not account for terrain elevation. A point may appear under terrain, or below sea level.

Support for Height Above Ellipsoid
Altitude relative to the ellipsoid used to render the globe

Support for Clamp to Ground
This altitude mode forces the vertex and connecting lines to always appear at the ground terrain level and enable draping of lines, points, and polygons over terrain. In this case no portion of a Feature should be hidden by the underlying terrain. The feature should appear as if it were painted on top of the terrain.

@pdavidc pdavidc added this to the v0.5.0 milestone Aug 26, 2016
@pdavidc
Copy link
Contributor Author

pdavidc commented Aug 26, 2016

Clarification from the COE team:

We should not impose geodetic nuances on the core rendering engine. Simply state the rendering engines core world coordinate system as ECEF cartesian meters or similar. There exists no less than three vertical domains. Geometric, geopotential, and geodetic. All three are ALWAYS confused and intertwined; and most often incorrect. The core rendering engine should only be concerned with graphics. A 'geo layer api' should be introduced for this.

All the rest of the mentioned coordinate systems below are just models that require routines to translate between.

Our intent was to ensure that the NASA WW app can support the OGC/NSG geospatial data formats and services (GeoPackage, WMS, etc ) that are essential to the Army Geospatial Enterprise and not to dictate how NASA WW should handle these data internally. It makes perfect sense that ECEF is how data is handled by the core rendering engine, and that a "geo layer api" will handle transformations.

@pdavidc
Copy link
Contributor Author

pdavidc commented Sep 27, 2016

We have established support for shape altitudes relative to ground and relative to the ellipsoid for polylines, polygons, placemarks and labels. The following altitudes are currently supported:

  • Absolute
  • Clamp to Ground
  • Relative to Ground

@pdavidc pdavidc closed this as completed Sep 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

1 participant