[x3d-public] GeoPlanets
GPU Group
gpugroup at gmail.com
Tue May 15 09:41:55 PDT 2018
Q. was this 'proposed geospatial enhancements'
http://www.igraphics.com/Standards/EnhancedGeospatialComponent_2007_10_30/Part01/components/geodata.html
submitted through specs comments, or by a web3d member who signed something
saying it released claims?
-Doug
On Tue, May 15, 2018 at 8:29 AM, GPU Group <gpugroup at gmail.com> wrote:
> > 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:
>> >> >> > <CAM2ogRfXeWAaqvS9WvLRrYUoGXM
>> NHb1NWyR7+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/3e78c42c/attachment-0001.html>
More information about the x3d-public
mailing list