[x3d-public] GeoSpatial Component v4 Proposal rev1

GPU Group gpugroup at gmail.com
Mon Jun 29 15:14:50 PDT 2020


Thanks - so should we drop the planet field? I found geoViewpoint
helpful on the moon, for navigating in a way that keeps vertical up.
Would be nice to use some of those things on other planets without
having to write separate nodes for each planet.
-Doug

On Mon, Jun 29, 2020 at 3:14 PM Richard F. Puk <puk at igraphics.com> wrote:
>
> If I am on Mars, specifying Mars coordinates in terms of Earth coordinates
> yields very inconvenient and non-intuitive coordinates.
>
>   -- Dick
>
> /******************************************
> | Richard F. Puk, Ph.D., President
> | Intelligraphics Incorporated
> | 7644 Cortina Court
> | Carlsbad, CA  92009-8206
> | Tel: +1-760-753-9027  Mobile:  +1-760-809-9027
> | Email:  puk at igraphics.com
> \******************************************
>
>
>
> -----Original Message-----
> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of GPU
> Group
> Sent: Monday, June 29, 2020 11:29 AM
> To: X3D Graphics public mailing list
> Subject: Re: [x3d-public] GeoSpatial Component v4 Proposal rev1
>
> #2 GeoSystemExplicit - some have asked why not convert all geo data to
> WGS84 UTM or GD
> - then no need to change  MFString geoSystem to X3DGeoSystemNode +
> GeoSystem + GeoSystemExplicit
> There's a lot of old mapping data that includes contours, and contours
> don't convert well - you can triangulate the points and regenerate new
> triangles, but doesn't look as well and very complex ie breaking
> contours over roads and streams.
> So having a single Level 3 extension node to cover any possible
> geospatial coordinate ssytem -for those that need it - is a wonderful
> accommodation, and the node refers to an ISO standard 18026, and there
> is at least one opensource implementation of that standard. So
> implementers don't have to work very hard to implement.
> - basically a little glue code copying and pasting values.
> -Doug
>
> On Mon, Jun 29, 2020 at 8:58 AM GPU Group <gpugroup at gmail.com> wrote:
> >
> > Any geospatial people on x3d-public? I;d love some comments on
> > proposed v4 changes
> > Thanks,
> > -Doug Sanden
> >
> >
> http://dug9.users.sourceforge.net/web3d/temp/geospatial_june28_SRF_Convert_W
> alkSurface_Nav_Tile_Sys.html
> >
> > 1) GeoSRF renamed GeoSystemExplicit
> > 2) Node signature for GeoSystemNode and GeoSystem
> > - not shown: geoNodes would have new SFNode field to take either
> > GeoSystem or GeoSystemExplicit
> > - alternate approach: GeoSystemExplicit would have a name= field, and
> > 'register' and the current geoSystem would refer to it by name like it
> > does pre-defined (2007 method)
> > 3) GeoTileSet, GeoChildTile  (aka GeoTile) node signatures
> > - goal: compatibility with cesium tileset, tiles
> > https://github.com/CesiumGS/3d-tiles/tree/master/specification
> > 4) GeoViewpoint > navigation types added, benchmarked against
> > googleEarth and Cesium
> > - walkSurface for bathy; other variants possible, such as listing
> > water nodes ...
> > 5) GeoConvert
> > .. given GC coords, can convert to any surface or vice versa, or
> > between surface coord systems, via routing / scripting
> >
> > Generally: none of this is implemented in freewrl except a variant of
> > GeoConvert with different node signature. geo WALK, FLY have been
> > working for a few years, and walkSurface coded but not tested.
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>



More information about the x3d-public mailing list