[x3d-public] GeoSpatial Component v4 Proposal rev1

[GPU Group]

Dick,
I'll do another revision - I can see now I missed some things, and
need to refer to the chapter 11 tables if I'm not going to list all
the choices.
-Doug
The int32 planet ordinal (0,1,2..)  I put  is for internal
optimization when more than one planet, to allow browsers to skip the
transform stack when looking for elevation grids for walking and
picking. .

On Mon, Jun 29, 2020 at 6:43 PM Richard F. Puk <puk at igraphics.com> wrote:
>
> The operations in the SRM can be used with any of the SRFs.
>
>   -- 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: GPU Group [mailto:gpugroup at gmail.com]
> Sent: Monday, June 29, 2020 5:24 PM
> To: Richard F. Puk
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] GeoSpatial Component v4 Proposal rev1
>
> My understanding - with the GeoSystemExplicit / SRF / 18026 node, in
> theory any planet can use our GeoViewpoint navigation and other nodes,
> without having to write special planet-specific nodes.
> -Doug
>
> On Mon, Jun 29, 2020 at 4:14 PM GPU Group <gpugroup at gmail.com> wrote:
> >
> > 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
> > >
>