[x3d-public] GeoPlanets
GPU Group
gpugroup at gmail.com
Tue May 15 07:29:36 PDT 2018
> I am pretty sure the result was that 'geographic coordinates' does
> mean any kind of geo-coordinates (GD, GC, or UTM) in the geoSystem
> provided. The geovalue_changed is the interpolated coordinate in the
> same geoSystem while the value_changed coordinate is the scene
> coordinate system (GC with optional GeoOrigin applied (subtracted)).
OK thanks Andreas for clarification, will conform if not already.
-Doug
...
Yes I agree 'geospatial coordinates' sounds a bit more abstract and
suitable than 'geographic coordinates', for what I've been calling 'user
coordinates' in freewrl code (user meaning the scene author, covering
{GC,XTM,GD}, and goes with geoSystem scene author specifies).
> 18026 is an actual ISO standard but really is overwhelming.
'Implementability' and 'scene authorability' might be helpful metrics to
score spec proposals, if the desire is to see them implemented by browser
developers and used by scene authors.
...
And there may be more than one way to implement.
In a spec comment for DIS I suggested keeping the DIS standard in a
separate DIS2X3D bridge module. Then do a simple node-synchronization
mechanism Browser.send() Browser.recv() in Script nodes.
I have a thought on enhanced geospatial I'll put in a spec comment when
that page is working again.
On Mon, May 14, 2018 at 3:12 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:
> > Date: Mon, 14 May 2018 12:59:14 -0600
> > From: GPU Group <gpugroup at gmail.com>
> >
> > Andreas
> > Thanks for the tips - I have a few things wrong in freewrl I'll fix.
>
> Well, maybe not. Let's see.
>
> > -Doug
> >
> > 1.freewrl uses a double precision transform stack, so doesn't need a
> offset
> > for precision: GeoOrigin or autoOrigin or LCS. The only reason I did that
> > stuff was to do what I thought the specs were saying to do. I'll change
> to
> > GC on the transform stack. Then GeoPlanet doesn't need to convert from
> LCS
> > to GC.
> >
> > 2. GeoPositionInterpolator uses the term 'geographic coordinates' and so
> > does 25.2.4 when talking about {GD, GC, UTM} - but apparently they mean
> > different things. I'll change GPI in freewrl to assume only GD
> coordinates
> > are allowed in key,value pairs.
>
> We had a exchange on the geospatial list a while ago on that since it
> is confusing.
>
> I am pretty sure the result was that 'geographic coordinates' does
> mean any kind of geo-coordinates (GD, GC, or UTM) in the geoSystem
> provided. The geovalue_changed is the interpolated coordinate in the
> same geoSystem while the value_changed coordinate is the scene
> coordinate system (GC with optional GeoOrigin applied (subtracted)).
>
> There is an additional question how the interpolation should be
> performed. I think the consensus was that it should be slerp on a
> great circle but lerp is acceptable for small distances.
>
> > 3. I looked at the 2008 Geo proposal and some things complement
> -GeoPlanet,
> > GeoConverter, .relativeHeight- and some things overlap/conflict
> -specifying
> > ellipsoid parametrically, specifying another mapping plane
> > - I suspect the SRF could be done with fewer nodes, more complete
> coverage
> > of mapping planes, and less painfully- by doing the MFString approach
> used
> > by geoSystem rather than struct/info nodes for specific mapping planes.
> > Whether that's in a separate node or enhansements to geoSystem I don't
> know.
> >
> > more detail...
> >
> > I can see how I made the mistakes, and there's a bit of confusing
> > terminology in the specs.
> >
> > 1) LCS/autoOrigin not needed, use GC:
> > 25.2.2 last paragraph: """
> > Internally, an X3D browser will transform all geographic coordinates into
> > earth-fixed geocentric coordinates (i.e., an (x,y,z) displacement from
> the
> > center of the earth in units of length base units). ... In addition, an
> > offset may be applied to these geocentric coordinates if a (now
> deprecated)
> > GeoOrigin node is supplied (see 25.2.5 Dealing with high-precision
> > coordinates).
> > """
> > versus my reading 25.2.5 3rd paragraph:
> > """
> > The GeoOrigin node and all geoOrigin fields are deprecated since browsers
> > can automatically provide local origins as necessary).
> > """
> > PROPOSED FIX: tinker with the 3rd and 4th paragraph from 25.2.5 which
> talk
> > about LCS, so that its clearer that there's 3 techniques:
> > A. offset
> > 1. geoOrigin (deprecated)
> > 2. auto-Origin
> > B. no offset
> > 3. use GC on the transform stack as per 25.2.2 last paragraph
>
> There is also an opening parenthesis missing, indicating perhaps
> unconscious ambivalence.
>
> Generally, it would be good to get rid of GeoOrigin. auto-Origin
> should work except that it makes it difficult to use regular
> coordinates (outside of a GeoLocation) in parallel with
> GeoCoordinates. Currently, in a scene without a GeoOrigin, one can
> assume that scene coordinates are GC, eg. the origin is at the center
> of the earth. With a GeoOrigin there is an offset which is predictable
> (but may be hard to determine for authors). With auto-Origin it would
> be hard to know which is the first GeoCoordinate which is encountered
> to be used as an origin. I always thought that instead of having to
> define the same GeoOrigin for each Geo-node it would make sense to
> include it as a field in a scene wide node such as Scene (but Scene
> should not be infected by the geospatial component). The default could
> be an 'auto' special value or 'null' if no offset is desired.
>
> On the other hand it is not unreasonable to just require
> GeoCoordinates in a geospatial scene.
>
> > 2) GPI uses GD as value for key,value pairs
> > Andreas: """
> > GeoPositionInterpolator has both geovalue_changed which does not
> > convert and value_changed which does convert to GC (but for you
> > perhaps to LCS=TCS) as I understand it.
> > """
> > versus my reading of 25.2.4 which uses the term 'geographic coordinates'
> in
> > the first sentence, as an abstract type
> > geographic_coordinate = {GD, UTM, GC}
> > (I use the term 'user coordinates')
> > and 25.3.7 first sentence
> > """
> > key values are specified in geographic coordinates and the interpolation
> is
> > performed within the specified spatial reference frame.
> > """
> > It didn't say GD or geodetic coordinates, it used the term 'geographic
> > coordinates'
> > PROPOSED FIX: change 'geographic coordinates' to 'geodetic coordinates'
> in
> > 25.3.7 or come up with a different abstract name for {GD, UTM, GC} in
> 25.2.4
>
> I think your reading is correct although I would prefer 'geospatial
> coordinates' (since for some 'geographic' can mean the X3D 'geodetic'
> kind). The question is more about the output of the Interpolator.
> value_changed is supposed to give the output in scene coordinates
> whereas geovalue_changed in geoSystem coordinates.
>
> >
> > 3) 2008 enhanced geospatial proposal
> > x didn't see GeoPlanet equivalent mechanism to support multiple planets
> in
> > the same scene (if there are node-node interactions that the transform
> > stack itself doesn't separate/clarify, like relativeHeight)
> > x didn't see .relativeHeight equivalent
> > x didn't see GeoConverter equivalent
> > So I don't think there's a conflict/overlap with 2008 on the above.
> > Where there's overlap Doug vs 2008 geospatial proposals:
> > - specifying ellipsoid parameters parametrically
> > - specifying more mapping planes (I took a shortcut with 3TM, 2008 does
> it
> > parametrically)
> > https://www.iso.org/standard/54166.html
> > - its from 2009, a year after web3d 2008 enhansed geospatial proposal
> > - (previous versions of 18026 submissions were 'withdrawn')
> > x it talks about SRM, not SRF, so the 2008 proposal has different
> > terminology
> > x costs 198 CHF. I don't have 198 CHF on me right now.
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> ISO_IEC_18026_COVER.html
>
> may be the current version (edition 2), for free. The PDF links work in
> Firefox.
>
> I think SRM and SRF are two different concepts. SRM is the general
> model, and SRF are the specific reference frames (coordinate systems).
>
> > It has a bit of the feel of DIS, where its wrapping some giant external
> > standard and assuming you know/have spent a year studying/have access to
> > that standard, because it jumps into terminology defined in the external
> > standard -a lot of links into it- and leaves details to the standard
> > "... see 11.9.2 in ISO/IEC 18026 ..."
> > "... fully described in 8.5 of ISO/IEC 18026 ..."
> > x I don't understand why 2008 defines more mapping planes with specific
> > nodes like "GeoObliqueMercator". I suspect there are a zillion possible
> > mapping planes. I have a thick book on them, and found more when working
> on
> > projects in EU.
>
> These are the most commonly used projections. The included ones
> probably do cover the majority of official projections globally.
>
> > - if you do it in such a way that you can pass it all to proj4 or
> > equivalent back end, then you don't need all those specific nodes
> > - I think the geoSystem style of using an MFString is better that way.
> > Fewer specific node types, one general parameter list frees you up to
> > service a lot of possiblities / hand it all off to proj4.lib or
> equivalent
>
> I agree that epsg codes, WKT and proj4 are just the defacto standard.
> To its credit, 18026 is an actual ISO standard but really is
> overwhelming. There are free java and cpp high quality implementations
> by SEDRIS. As Dick indicated one could map the epsg codes to the way
> projections are defined in 18026. Of course, proj4 does that already.
>
> The enhanced geospatial component references all of the following:
>
> RT (reference transformation) code (Int32) values are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_ANNEX_E.PDF
>
> (There are 342! )
>
> dss (designated spatial surface) codes are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_DSS_VOS.PDF#T_9_2
>
> (There are 9)
>
> ORM (Object reference model) codes are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_ANNEX_E.PDF
>
> (There are 252, these include celestial objects).
>
> SRF (spatial reference frame) codes are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_SRF.PDF#T_8_30
> and following
>
> (There are 14)
>
> SRFS (SRF sets) and member codes are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_SRF.PDF#T_8_48
> and following
>
> (There are 7, each with members)
>
> SRFT (SRF template) codes are here:
>
> http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/
> text/ISOIEC_18026E_SRF.PDF#T_8_3
>
> (There are 26).
>
> In theory, all of those would need to be implemented. So the only
> realistic chance is to use the provided SEDRIS libraries. (I had made
> some progress converting them to javascript with what is now web
> assembly).
>
> -Andreas
>
> >
> >
> > On Sun, May 13, 2018 at 6:39 PM, Andreas Plesch <andreasplesch at gmail.com
> >
> > wrote:
> >
> >> To be honest, I have not heard of the 3TM projection. Googling shows
> >> it is widely used in Canada but I am not sure that it is commonly used
> >> elsewhere.
> >>
> >> The scale factors for the UTM/3TM projection is related to the width
> >> of the zones. They are designed such that there is true scale at two
> >> meridians symmetric to the central meridian. A scale factor of 1.0
> >> would yield true scale only at the central meridian. So it just
> >> depends where your city is relative to the two meridians with true
> >> scale, both for UTM and 3TM. The smaller width of 3 degrees per zone
> >> is really what makes distortions a little less severe with 3TM at the
> >> expense of having to deal with more zones. I suspect that this is a
> >> the cm to mm scale relative improvement. Most regions have their own
> >> preferred projection.
> >>
> >> But 3TM and 10TM would be easy to add as you say once the zones are
> >> figured out. If it helps with adoption why not.
> >>
> >> 25.2.2 states
> >>
> >> 'Internally, an X3D browser will transform all geographic coordinates
> >> into earth-fixed geocentric coordinates (i.e., an (x,y,z) displacement
> >> from the center of the earth in units of length base units).'
> >>
> >> This allows to mix geo-coordinates and predictable regular coordinates
> >> in a scene.
> >>
> >> My understanding is that the deprecation of GeoOrigin assumed that
> >> browsers would be able to use internally high precision (with doubles
> >> or better).
> >>
> >> The TCS based on the first geo-coordinate is a good idea but would
> >> need to be standardized.
> >>
> >> GeoPositionInterpolator has both geovalue_changed which does not
> >> convert and value_changed which does convert to GC (but for you
> >> perhaps to LCS=TCS) as I understand it.
> >>
> >> I agree that the browser internal coordinate conversions may just as
> >> well be exposed.
> >>
> >> Walk mode currently just recognizes any mesh, surface or grid
> >> underneath and will use it to stay above, in x3dom (with GeoOrigin).
> >> Stepping off currently means falling in x3dom, I believe.
> >>
> >> -Andreas
> >>
> >> > Date: Sun, 13 May 2018 17:10:05 -0600
> >> > From: GPU Group <gpugroup at gmail.com>
> >> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> > Subject: Re: [x3d-public] GeoPlanets, was: Invalid geoSystem values in
> >> > X3D Resources BasicGeospatial examples.
> >> > Message-ID:
> >> > <CAM2ogRdsLO+dNzBrHhuFt2Bwfd5qFw-QL2LtEwaWRGa4BYi-TQ at mail.
> >> gmail.com>
> >> > Content-Type: text/plain; charset="utf-8"
> >> >
> >> > Andreas,
> >> > Thanks for those links to those detailed Geospatial proposal. I hadn't
> >> see
> >> > that. I'll read it in more detail.
> >> >
> >> > 3TM is commonly used by cities around the world in their GIS
> department,
> >> > because the scale factor is close to 1 so when you take measurements
> it's
> >> > close to the surveyor's tape measure..
> >> >
> >> > And it uses the same transverse mercator math functions as UTM, so
> just a
> >> > scale factor and 2 offsets different - a very easy thing for browser
> >> > developers to add to their UTM support capture the city GIS crowd.
> >> >
> >> >> the underlying assumption is that in the scene regular (nongeo)
> >> >> coordinates are geocentric, eg. relative to the center of a single
> >> planet.
> >> >
> >> > Not quite or that's not how freewrl is working, not my understanding.
> In
> >> > the Precision section of Geospatial, it talks about GeoOrigin
> (deprecated
> >> > in v3.3) or something done automatically in the place of GeoOrigin.
> >> That's
> >> > called the Local Coordinate System. Not at the center of the earth.
> Its
> >> > somewhere nearby to the scenery you have on the surface of the earth,
> to
> >> > reduce coordinate precision required (from double to float) as the
> specs
> >> > describe.
> >> > In freewrl, in place of deprecated GeoOrigin, freewrl uses the TCS
> >> > -Topocentric Coordinate System, as described for GeoLocation- of the
> >> first
> >> > GeoNode it parses, or more precisely, the TCS of the first GeoNode in
> the
> >> > planet, as the arbitrary LCS origin.
> >> > Then non-geo nodes are in this LCS by default.
> >> >
> >> >
> >> >> I think regular coordinates within a GeoPlanet node would be
> geocentric
> >> > only
> >> >> to that planet.
> >> > They are LCS. So one job of GeoPlanet is to convert from LCS to GC /
> >> > geocentric - or more precisely push onto the transform stack a
> transform
> >> > that will do that - so the parent scenery sees the planet in
> geocentric
> >> > coords like you were thinking.
> >> >
> >> >> In a multiplanet scene it would be necessary to also
> >> >> specify the positions of the planets relative to each other.
> >> > Yes. Once each planet is wrapped in GeoPlanet then you can use normal
> >> > transforms to position the planets, and scripts to animate the
> planets.
> >> > The EarthRise_GP.x3d scene I mentioned does that - its got moon, sun,
> and
> >> > earth (although at shorter non-realistic distances).
> >> > I haven't done a formal release of a freewrl version that does all
> that,
> >> > but the develop version has been doing it all since March.
> >> >
> >> >
> >> >> GeoPositionInterpolator converts to GC
> >> > Really? Uh-oh. I missed that. I thought it was just working in double
> >> > precision coordinates, and left it up to you to decide GD, GC or XTM,
> but
> >> > without converting anything for you.
> >> > That's the main benefit I was targeting with the GeoConverter node
> >> > proposal. So if you do need conversion its available. And for browser
> >> > developers, its one of the easiest GeoNodes to add, because you
> already
> >> > have the conversion functions internally.
> >> >
> >> >
> >> >> relativeHeight: sounds interesting. Why use the highest point on the
> >> >> GEG and not the height at the actual location ?
> >> > It does/should use the GEG height at your location. But if you had
> >> > overlapping GEGS then takes highest one at your location.
> >> > That's handy if you have a low-resolution GEG covering for example the
> >> > whole planet, and want to put a high res GEG for a small local area of
> >> > interest. Rather than cut a hole in a GEG (awkward code), you can
> lower
> >> the
> >> > heights a bit, and your higher res GEG will take over.
> >> >
> >> >> What if the registered
> >> >> GEG is somewhere else than the GL ? Just fall back to
> >> >> Geoid,eg.sealevel ?
> >> >
> >> > Yes - fall back to relative-to-sealevel, for GL (or if you know you're
> >> not
> >> > going to be on a GEG, use absolute / leave .relativeHeight FALSE)
> >> > For GVP, a more common use case is starting out over a GEG and running
> >> off.
> >> > Lets say you start out on a small local GEG, with relativeHeight 100,
> and
> >> > you're in walk mode, and feeling the bumps in the terrain as you
> navigate
> >> > along. Then you hit the edge of the GEG and want to keep going. In
> >> freewrl,
> >> > with no GEG adjusting the height, you stay at the absolute (above
> >> sealevel)
> >> > height you were at when you hit the edge. If you turn and go back on
> at a
> >> > different place, the relative height you specified kicks back in, and
> >> > you're back at your 100m height walking on the GEG.
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Sun, May 13, 2018 at 1:50 PM, Andreas Plesch <
> andreasplesch at gmail.com
> >> >
> >> > wrote:
> >> >
> >> >> Hi Doug,
> >> >>
> >> >> here is my unfinished response to your earlier posting:
> >> >>
> >> >> there may be planetary geoSystems or spatial reference frames
> proposed
> >> >> in the enhanced geospatial component proposal.
> >> >> http://www.igraphics.com/Standards/EnhancedGeospatialComponent_
> >> >> 2007_10_30/Part01/components/geodata.html
> >> >> http://www.sedris.org/wg8home/Documents/18026_FDIS/C030811e_
> >> >> FILES/MAIN_C030811e/ISOIEC_18026E_TOC.HTM
> >> >>
> >> >> But a more streamlined proposal seems very useful.
> >> >>
> >> >> I think geospatial nodes can only deal with scenes on a single planet
> >> >> since the underlying assumption is that in the scene regular (nongeo)
> >> >> coordinates are geocentric, eg. relative to the center of a single
> >> >> planet. Your proposal seems to address somewhat that question. I
> think
> >> >> regular coordinates within a GeoPlanet node would be geocentric only
> >> >> to that planet. In a multiplanet scene it would be necessary to also
> >> >> specify the positions of the planets relative to each other.
> >> >>
> >> >> An expansion may be a solarcentric mode, where the center of a solar
> >> >> system is the origin. Each planet would have its center given
> relative
> >> >> to a central sun (ignoring precision issues for the moment). I think
> >> >> astronomy also uses galactic coordinates.
> >> >>
> >> >> And here additional feedback:
> >> >>
> >> >> 3TM and 10UTM seems to be only used in Canada ? 3TM seems to have
> >> >> meridians based on province ? If we allow additional projections,
> they
> >> >> should be truly global and well defined. I do not see it as a big
> >> >> burden to convert to GD or UTM. The other route to is allow all epsg
> >> >> codes which can be converted by a library such proj which means
> >> >> essentially all possible projections.
> >> >>
> >> >> GeoPositionInterpolator converts to GC but there is no way to convert
> >> >> to UTM or GD which may be useful for reporting coordinates.
> >> >>
> >> >> relativeHeight: sounds interesting. Why use the highest point on the
> >> >> GEG and not the height at the actual location ? What if the
> registered
> >> >> GEG is somewhere else than the GL ? Just fall back to
> >> >> Geoid,eg.sealevel ?
> >> >>
> >> >> -Andreas
> >> >>
> >> >> > Date: Sun, 13 May 2018 12:10:21 -0600
> >> >> > From: GPU Group <gpugroup at gmail.com>
> >> >> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> >> >> > Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources
> >> >> > BasicGeospatial examples.
> >> >> > Message-ID:
> >> >> > <CAM2ogRfXeWAaqvS9WvLRrYUoGXMNHb1NWyR7+aFDTos_-mp3zg at mail.
> >> >> gmail.com>
> >> >> > Content-Type: text/plain; charset="utf-8"
> >> >> >
> >> >> > 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/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
> >> >> >
> >> >> >
> >> >> > 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 <gpugroup at gmail.com>
> >> >> >> *Sent: *Sunday, May 13, 2018 9:16 AM
> >> >> >> *To: *X3D Graphics public mailing list <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/8defb5db/attachment.html>
> >> >> >
> >> >> > ------------------------------
> >> >> >
> >> >> > Subject: Digest Footer
> >> >> >
> >> >> > _______________________________________________
> >> >> > x3d-public mailing list
> >> >> > x3d-public at web3d.org
> >> >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >> >> >
> >> >> >
> >> >> > ------------------------------
> >> >> >
> >> >> > End of x3d-public Digest, Vol 110, Issue 31
> >> >> > *******************************************
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Andreas Plesch
> >> >> Waltham, MA 02453
> >> >>
> >> >> _______________________________________________
> >> >> 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/75e39192/attachment.html>
> >> >
> >> > ------------------------------
> >> >
> >> > Subject: Digest Footer
> >> >
> >> > _______________________________________________
> >> > x3d-public mailing list
> >> > x3d-public at web3d.org
> >> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >> >
> >> >
> >> > ------------------------------
> >> >
> >> > End of x3d-public Digest, Vol 110, Issue 35
> >> > *******************************************
> >>
> >>
> >>
> >> --
> >> Andreas Plesch
> >> Waltham, MA 02453
> >>
> >> _______________________________________________
> >> 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/20180514/63ab5bf0/attachment.html>
> >
> > ------------------------------
> >
> > Subject: Digest Footer
> >
> > _______________________________________________
> > x3d-public mailing list
> > x3d-public at web3d.org
> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
> >
> >
> > ------------------------------
> >
> > End of x3d-public Digest, Vol 110, Issue 43
> > *******************************************
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
> _______________________________________________
> 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/20180515/4440136f/attachment-0001.html>
More information about the x3d-public
mailing list