You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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:
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.
The text was updated successfully, but these errors were encountered: