[x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.
Richard F. Puk
puk at igraphics.com
Sun May 13 21:40:28 PDT 2018
Hi –
Please review the “extended geospatial component” specification which supports all of the items suggested plus many others. It is intended to add full support for ISO/IEC 18026—Spatial Reference Model. It does so in a fully upwards compatible form. The only change that I would make would be to add support for the Petroleum Institute codes which are used by many. The proposed replacement geospatial component is attached. Unzip to empty folder.
n 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: <mailto:puk at igraphics.com> puk at igraphics.com
\******************************************
From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of GPU Group
Sent: Sunday, May 13, 2018 1:10 PM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.
John, thanks for checking.
Hypothesis: Maybe I forgot to check the [x] public checkbox when making a spec comment? I meant for it to be public, And I hope the recommendations are adopted in some future version of the specs, and implemented by browser developers.
I'll make it public here and do another submission.
-Doug
Here's what I submitted Mar 26, 2018
==============================================================
GeoSpatial Component Comments Mar 2018
Acronyms:
GL - GeoLocation
GVP - GeoViewpoint
GEG - GeoElevationGrid
GPS - GeoProximitySensor
GP - GeoPlanet
XTM - UTM or 3TM
3TM - like UTM, except 3 degree zones, .9999 scale factor and no false northing / false easting
user coords - coords matching geosystem, authored in scene file, could be GC, XTM, GD
TCS/LGS - Topocentric Coordinate System aka Local Geodetic System, as described in specs for GeoLocation:
-- tangent to ellipsoid at a given geo location, -Z north, Y up
LCS - Local Coordinate System - as described in specs for numerical precision
-- shared cartesian coordinate system used internally
A. Proposed nodetype: GeoPlanet
Implicit in the web3d geospatial specs: all geoNodes are on the same planet.: earth That should cover 99.99999% of uses. And even if you have 2 planets, the transform stack will keep them separate for most use cases. The exception being node-node interactions such as GVP-GEG, GL-GEG, and GPS-GEG as I'll explain later for the relativeHeight feature.
x3d usage:
<GeoPlanet planetId='#'>
... geonodes for planet...
</GeoPlanet>
where
planetId - an Int32 field that can be used to discriminate between planets, could also be called planetName or planet
example scenefile:
<http://dug9.users.sourceforge.net/web3d/tests/geo/World/earthriseGP.x3d> http://dug9.users.sourceforge.net/web3d/tests/geo/World/earthriseGP.x3d
http://dug9.users.sourceforge.net/web3d/temp/freeWRL2018_GeoPlanet.mp4
feature details:
1. similar to GeoTransform (GT) it wraps geonodes, but instead of converting to TCS/LGS it converts to GC
- allows orbital mechanics on multiple planets using planet centers and Z as rotation axis
- same job could in theory be done by modifying the specs for GeoTransform, to allow converting to GC instead of TCS/LGS, and a field for planetId, but adds a connundrum: 2 geoTransforms for the same planet could sport different translation, rotation etc, which doesn't make sense.
2. for node-node interactions such as GVP-GEG and GL-GEG helps keep the planets separate
- internally planetId is pushed and popped during scenegraph traversal, so when visiting a the code can tell which planet it's working on
a) for GVP-GEG:
-- when visiting GVP to start the modelview matrix, store the planetId in the GVP
-- when visiting GEG, check the current planetId (applies to GEG) against the GVP._planetId, use if same
b) for GL-GEG:
-- after loading scene/inline/externProto body, on first traveral add each GEG to a per-planet list of GEGs
-- when visiting a GL with relativeHeight TRUE, look through the current planet's list of GEGs, and get the highest terrain height, if any GEGs covering that location.
GeoPlanet : X3DGroupingNode {
SFInt32 [] planetId 0 [0,∞)
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFNode [in] addChildren [X3DChildNode]
MFNode [in] removeChildren [X3DChildNode]
MFNode [in,out] children [] [X3DChildNode]
SFVec3f [] bboxCenter 0 0 0 (-∞,∞)
SFVec3f [] bboxSize -1 -1 -1 [0,∞) or −1 −1 −1
}
B. Proposed nodetype: GeoConvert
Web3d specs allow a different geoSystem on each geo node. And each as fields in user/geoSystem coordinates that can be routed to/from. But no way to convert between geoSystems.
Proposed GeoConvert node
- allows you to convert between GeoSystems via routing and 2 GeoConvert nodes
myGeoNode1 -> set_geoCoord (geoConvert1) gcCoord_changed -> set_gcCoord (geoConvert2) geoCoord_changed -> myGeoNode2
where geoConvert1.geoSystem == myGeoNode1.geoSystem
and geoConvert2.geoSystem == myGeoNode2.geoSystem
<http://dug9.users.sourceforge.net/web3d/tests/geo/World/World33geoConvert.x3d> http://dug9.users.sourceforge.net/web3d/tests/geo/World/World33geoConvert.x3d
GeoConvert : X3DNode {
SFVec3d [in] set_geoCoords
SFVec3d [in] set_gcCoords
SFNode [in,out] metadata NULL [X3DMetadataObject]
MFString [] geoSystem ["GD","WE"] [see 25.2.3]
SFVec3d [out] geoCoords_changed
SFVec3d [out] gcCoords_changed
}
C. Proposed field for GVP, GL and GPS: .relativeHeight
Sometimes you don't know the exact height of something above the ellipsoid, but you know you want it at ground level, and you have a GEG in the scene covering the area. It would be convenient to put 0 for the geoCoords/center height, if they are GD or XTM user coords (not GC), and have the browser adjust the height to terrain level.
For GL and GPS if relativeHeight = TRUE, then on each frame when visiting the node, check the list of GEGs registered for the current GeoPlanet, and add the highest of those (if any) to the .geoCoords / .center height if in GD or XTM, to convert from user to internal GC, and subtract if going from GC back to user.
For GVP, the behaviour is similar, but only for initial positioning, because browser-supported navigation modes likely want to adjust the relative height:
- WALK + Collide: maintain relative height to terrain, by climbing/falling while navigating on GEG
- FLY + Collide: maintain height relative to ellipsoid
- FLY (no collide aka FREEFLY): allow height to be adjusted
Example scene (GVP and GL):
http://dug9.users.sourceforge.net/web3d/temp/freeWRL2018_relativeHeights.mp4
http://dug9.users.sourceforge.net/web3d/tests/geo/World/World33GLrelativeHeight.x3d
Field descriptions:
GeoLocation : X3DGroupingNode {
.. as per specs ..
SFBool [] relativeHeight FALSE
}
GeoViewpoint : X3DViewpointNode {
.. as per specs ..
SFBool [] relativeHeight FALSE
}
GeoProximitySensor : X3DEnvironmentalSensorNode {
.. as per specs ..
SFBool [] relativeHeight FALSE
}
D. Proposed geoSystem additions
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#Spatialreferenceframes
D1. A, IF, F, R
An assumption of the specs: all geoNodes are for one planet: earth, and the list of allowed ellipsoids are for earth.
Online samples include a Mars scene, and it uses default earth ellipsoid:
http://www.web3d.org/x3d/content/examples/Basic/#Geospatial
Here are some additions to geoSystem to allow users to specify the ellipsoid parameters:
# - a number like a 6378137 or 298.257223563
"A#" - semimajor axis
"IF#" - inverse flattening
"F#" - flattening
"R" - radius
coherent combinations include:
A and F
A and IF
R
D2. 3TM
3TM is like UTM, except with (built-in) central meridan scale factor .9999 (instead of .9997 for UTM) and no false easting or false northing (so coordinates can be negative). Typically used for cities, and GIS packages export 3TM often without mentioning the zone or central meridian. In that case you can set Z0. Otherwise its generally 2x the UTM zone or 2x- 1.
coherent combinations include
3TM
3TM and Z
along with other UTM-compatible options except no FalseEasting or FalseNorthing.
================================================================
and April 9, 2018 addendum:
======================================
(refering to a previous spec submission from the same commentor which included new nodetype GeoPlanet)
GeoPlanet - there's a preference among freewrl users that instead of numerical planetId='#' it would be an SFString ie planet='earth', which would be easier for scene authors to keep straight in their own minds.
SFString planet "earth"
========================================
On Sun, May 13, 2018 at 10:58 AM, John Carlson <yottzumm at gmail.com> wrote:
You may want to resubmit your 3TM and Planet changes to Mantis. I searched for 3TM and Planet in Mantis (All Projects) and got nothing significant back.
However, I was denied access to:
http://www.web3d.org/node/1694/submission/1671
Why?
and there’s:
http://www.web3d.org/member-only/mantis/view.php?id=1215
Not that I want to imagine writing schema for such a thing…that’s why I hope to get geoSystem into more reasonable shape in the Unified Object Model (we need volunteers, I think) before trying to do it in schema.
John
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: GPU Group <mailto:gpugroup at gmail.com>
Sent: Sunday, May 13, 2018 9:16 AM
To: X3D Graphics public mailing list <mailto:x3d-public at web3d.org>
Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.
I think N should be OK, just as you say a redundant default.. I proposed several new things in the geoSystem field, submitted to spec comments a few months ago, so I hope your processor works on the new things if ever adopted.
-Doug
R,A,B,F,IF - ways to drectly specifiy the shape of the ellipsoid so other planet shapes and sizes could be modeled
3TM - similar to UTM (except 3degree zones, no false northing or easting, different central meridian scale factor .9999)
...
I also proposed a Planet node - allows multiple planets in one scene
On Sun, May 13, 2018 at 6:14 AM, John Carlson <yottzumm at gmail.com> wrote:
The object model is expressive enough to list conforming values, yet accept others, but as far as I know (I may be wrong here), it is not expressive enough to express supported geoSystem values. This is a problem. How do we resolve it, and should we, if we are accepting other values? Is it resolved in X3DJSAIL? Should I get rid of Roy's JSON subschema for geoSystem?
John
On Sun, May 13, 2018, 7:43 AM John Carlson <yottzumm at gmail.com> wrote:
I believe the purpose of schema is to support minimally acceptable files. It should flag files which are questionable. If a file can be brought into conformance easily, shouldn't it be?
Yes, you should be able to ignore the results of the schema validation...at your own risk.
What is the purpose of the X3D resources examples, but to show a good example practice? Or are we testing tools to make sure certain values are acceptable? If that's the case, then the schema should be updated for ALL versions.
John
On Sun, May 13, 2018, 7:31 AM John Carlson <yottzumm at gmail.com> wrote:
Then the version of the document should be upgraded to 4.0 or above, and the corresponding schema updated. I can upgrade the schema for all versions, since it is hard coded into the schema generator. But really we need support from the object model if possible. Right now, I have to explicitly allow it for all versions, since I use stdin/stdout instead of files. Does the unified object model specify a version # in its contents? When the unified object model supports "N" in a usable fashion, then I can code something into the schema, or delete the requirement to check geoSystem.
Thanks, away from computer presently, or I would check.
I don't see why Roy went to all the effort to create a schema, if we are going to ignore it?
This applies in many areas...if we merely have supported values, yet others must be accepted, why is there a standard?
I don't believe it's ambiguous in this case of X3D. A missing "N" means Northern Hemisphere.
John
On Sun, May 13, 2018, 12:46 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
http://www.web3d.org/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference <http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference>
lists the supported strings for the geoSystem MFString field.
The prose choosing 'supported' over 'legal' or 'conforming' could be taken to mean that other than listed strings may be allowed to be supported as well by some browsers.
However, previous discussions indicate that schemas are not sufficiently expressive to describe unknown but conforming string values.
One resolution was to explicitly allow 'N' in upcoming X3D version, and perhaps silently allow it for 3.3.
Outside of X3D UTM zones often have the N hemisphere identifier to avoid ambiguity.
Andreas
Date: Sat, 12 May 2018 19:54:17 -0400
From: John Carlson <yottzumm at gmail.com>
To: Don Brutzman <brutzman at nps.edu>, X3D Graphics public mailing list
<x3d-public at web3d.org>
Subject: [x3d-public] Invalid geoSystem values in X3D Resources Basic
Geospatial examples.
Message-ID: <5af77ea8.1c69fb81.7da1f.13e3 at mx.google.com>
Content-Type: text/plain; charset="utf-8"
Don, These files contain "N" in geoSystem, which I believe is not valid, and should be removed (default is Northern Hemisphere, in the standard, I believe. "S" can be specified?not in this case).
Is there a tool which hasn?t been changed which is
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180513/211d2e9a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EnhancedGeospatialComponent_2008_06_23.zip
Type: application/x-zip-compressed
Size: 1102410 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180513/211d2e9a/attachment-0001.bin>
More information about the x3d-public
mailing list