[x3d-public] GeoSpatial Component v4 Proposal rev1

[GPU Group]

#3 GeoChildTile - just call it GeoTile
#2 GeoSystem - already used as an MFString field name, so putting a
SFNode field with the same name would break. Could you call it .system
or srf?
- if a different name, then it would be a non-breaking version change:
-- browser could check first if there.s a SFNode GeoSystem and if not
read the geoSystem MFString.
Q. a bit late for v4?
Q. have ohter browsers implemented any cesium-tile-compatible nodes?
Q. what if any of the proposed changes are most likely to see eventual
2 implementations?
-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_WalkSurface_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.