<div dir="ltr"><div>> I am pretty sure the result was that 'geographic coordinates' does</div><div>> mean any kind of geo-coordinates (GD, GC, or UTM) in the geoSystem</div><div>> provided. The geovalue_changed is the interpolated coordinate in the</div><div>> same geoSystem while the value_changed coordinate is the scene</div><div>> coordinate system (GC with optional GeoOrigin applied (subtracted)).</div><div><br></div><div>OK thanks Andreas for clarification, will conform if not already.</div><div><br></div><div>-Doug</div><div>...</div><div>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).</div><div><br></div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><span style="font-size:12.8px">> 18026 is an actual ISO standard but really is </span><span style="font-size:12.8px">overwhelming.</span> <br></div></div><div>'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.</div><div>...</div><div>And there may be more than one way to implement. </div><div>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.</div><div>I have a thought on enhanced geospatial I'll put in a spec comment when that page is working again.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 14, 2018 at 3:12 PM, Andreas Plesch <span dir="ltr"><<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Mon, 14 May 2018 12:59:14 -0600<br>
> From: GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>><br>
><br>
<span class="">> Andreas<br>
> Thanks for the tips - I have a few things wrong in freewrl I'll fix.<br>
<br>
</span>Well, maybe not. Let's see.<br>
<span class=""><br>
> -Doug<br>
><br>
> 1.freewrl uses a double precision transform stack, so doesn't need a offset<br>
> for precision: GeoOrigin or autoOrigin or LCS. The only reason I did that<br>
> stuff was to do what I thought the specs were saying to do. I'll change to<br>
> GC on the transform stack. Then GeoPlanet doesn't need to convert from LCS<br>
> to GC.<br>
><br>
> 2. GeoPositionInterpolator uses the term 'geographic coordinates' and so<br>
> does  25.2.4 when talking about {GD, GC, UTM} - but apparently they mean<br>
> different things. I'll change GPI in freewrl to assume only GD coordinates<br>
> are allowed in key,value pairs.<br>
<br>
</span>We had a exchange on the geospatial list a while ago on that since it<br>
is confusing.<br>
<br>
I am pretty sure the result was that 'geographic coordinates' does<br>
mean any kind of geo-coordinates (GD, GC, or UTM) in the geoSystem<br>
provided. The geovalue_changed is the interpolated coordinate in the<br>
same geoSystem while the value_changed coordinate is the scene<br>
coordinate system (GC with optional GeoOrigin applied (subtracted)).<br>
<br>
There is an additional question how the interpolation should be<br>
performed. I think the consensus was that it should be slerp on a<br>
great circle but lerp is acceptable for small distances.<br>
<div><div class="h5"><br>
> 3. I looked at the 2008 Geo proposal and some things complement -GeoPlanet,<br>
> GeoConverter, .relativeHeight- and some things overlap/conflict -specifying<br>
> ellipsoid parametrically, specifying another mapping plane<br>
> - I suspect the SRF could be done with fewer nodes, more complete coverage<br>
> of mapping planes, and less painfully- by doing the MFString approach used<br>
> by geoSystem rather than struct/info nodes for specific mapping planes.<br>
> Whether that's in a separate node or enhansements to geoSystem I don't know.<br>
><br>
> more detail...<br>
><br>
> I can see how I made the mistakes, and there's a bit of confusing<br>
> terminology in the specs.<br>
><br>
> 1) LCS/autoOrigin not needed, use GC:<br>
> 25.2.2 last paragraph: """<br>
> Internally, an X3D browser will transform all geographic coordinates into<br>
> earth-fixed geocentric coordinates (i.e., an (x,y,z) displacement from the<br>
> center of the earth in units of length base units). ... In addition, an<br>
> offset may be applied to these geocentric coordinates if a (now deprecated)<br>
> GeoOrigin node is supplied (see 25.2.5 Dealing with high-precision<br>
> coordinates).<br>
> """<br>
> versus my reading 25.2.5 3rd paragraph:<br>
> """<br>
> The GeoOrigin node and all geoOrigin fields are deprecated since browsers<br>
> can automatically provide local origins as necessary).<br>
> """<br>
> PROPOSED FIX: tinker with the 3rd and 4th paragraph from 25.2.5 which talk<br>
> about LCS, so that its clearer that there's 3 techniques:<br>
> A. offset<br>
> 1. geoOrigin (deprecated)<br>
> 2. auto-Origin<br>
> B. no offset<br>
> 3. use GC on the transform stack as per 25.2.2 last paragraph<br>
<br>
</div></div>There is also an opening parenthesis missing, indicating perhaps<br>
unconscious ambivalence.<br>
<br>
Generally, it would be good to get rid of GeoOrigin. auto-Origin<br>
should work except that it makes it difficult to use regular<br>
coordinates (outside of a GeoLocation) in parallel with<br>
GeoCoordinates. Currently, in a scene without a GeoOrigin, one can<br>
assume that scene coordinates are GC, eg. the origin is at the center<br>
of the earth. With a GeoOrigin there is an offset which is predictable<br>
(but may be hard to determine for authors). With auto-Origin it would<br>
be hard to know which is the first GeoCoordinate which is encountered<br>
to be used as an origin. I always thought that instead of having to<br>
define the same GeoOrigin for each Geo-node it would make sense to<br>
include it as a field in a scene wide node such as Scene (but Scene<br>
should not be infected by the geospatial component). The default could<br>
be an 'auto' special value or 'null' if no offset is desired.<br>
<br>
On the other hand it is not unreasonable to just require<br>
GeoCoordinates in a geospatial scene.<br>
<span class=""><br>
> 2) GPI uses GD as value for key,value pairs<br>
> Andreas: """<br>
> GeoPositionInterpolator has both geovalue_changed which does not<br>
> convert and value_changed which does convert to GC (but for you<br>
> perhaps to LCS=TCS) as I understand it.<br>
> """<br>
> versus my reading of 25.2.4 which uses the term 'geographic coordinates' in<br>
> the first sentence, as an abstract type<br>
> geographic_coordinate = {GD, UTM, GC}<br>
> (I use the term 'user coordinates')<br>
> and 25.3.7 first sentence<br>
> """<br>
> key values are specified in geographic coordinates and the interpolation is<br>
> performed within the specified spatial reference frame.<br>
> """<br>
> It didn't say GD or geodetic coordinates, it used the term 'geographic<br>
> coordinates'<br>
> PROPOSED FIX: change 'geographic coordinates' to 'geodetic coordinates' in<br>
> 25.3.7 or come up with a different abstract name for {GD, UTM, GC} in 25.2.4<br>
<br>
</span>I think your reading is correct although I would prefer 'geospatial<br>
coordinates' (since for some 'geographic' can mean the X3D 'geodetic'<br>
kind). The question is more about the output of the Interpolator.<br>
value_changed is supposed to give the output in scene coordinates<br>
whereas geovalue_changed in geoSystem coordinates.<br>
<span class=""><br>
><br>
> 3) 2008 enhanced geospatial proposal<br>
> x didn't see GeoPlanet equivalent mechanism to support multiple planets in<br>
> the same scene (if there are node-node interactions that the transform<br>
> stack itself doesn't separate/clarify, like relativeHeight)<br>
> x didn't see .relativeHeight equivalent<br>
> x didn't see GeoConverter equivalent<br>
> So I don't think there's a conflict/overlap with 2008 on the above.<br>
> Where there's overlap Doug vs 2008 geospatial proposals:<br>
> - specifying ellipsoid parameters parametrically<br>
> - specifying more mapping planes (I took a shortcut with 3TM, 2008 does it<br>
> parametrically)<br>
> <a href="https://www.iso.org/standard/54166.html" rel="noreferrer" target="_blank">https://www.iso.org/standard/<wbr>54166.html</a><br>
> - its from 2009, a year after web3d 2008 enhansed geospatial proposal<br>
> - (previous versions of 18026 submissions were 'withdrawn')<br>
> x it talks about SRM, not SRF, so the 2008 proposal has different<br>
> terminology<br>
> x costs 198 CHF. I don't have 198 CHF on me right now.<br>
<br>
</span><a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/ISO_IEC_18026_COVER.html" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>ISO_IEC_18026_COVER.html</a><br>
<br>
may be the current version (edition 2), for free. The PDF links work in Firefox.<br>
<br>
I think SRM and SRF are two different concepts. SRM is the general<br>
model, and SRF are the specific reference frames (coordinate systems).<br>
<span class=""><br>
> It has a bit of the feel of DIS, where its wrapping some giant external<br>
> standard and assuming you know/have spent a year studying/have access to<br>
> that standard, because it jumps into terminology defined in the external<br>
> standard -a lot of links into it- and leaves details to the standard<br>
> "... see 11.9.2 in ISO/IEC 18026 ..."<br>
> "... fully described in 8.5 of ISO/IEC 18026 ..."<br>
> x I don't understand why 2008 defines more mapping planes with specific<br>
> nodes like "GeoObliqueMercator". I suspect there are a zillion possible<br>
> mapping planes. I have a thick book on them, and found more when working on<br>
> projects in EU.<br>
<br>
</span>These are the most commonly used projections. The included ones<br>
probably do cover the majority of official projections globally.<br>
<span class=""><br>
> - if you do it in such a way that you can pass it all to proj4 or<br>
> equivalent back end, then you don't need all those specific nodes<br>
> - I think the geoSystem style of using an MFString is better that way.<br>
> Fewer specific node types, one general parameter list frees you up to<br>
> service a lot of possiblities / hand it all off to proj4.lib or equivalent<br>
<br>
</span>I agree that epsg codes, WKT and proj4 are just the defacto standard.<br>
To its credit, 18026 is an actual ISO standard but really is<br>
overwhelming. There are free java and cpp high quality implementations<br>
by SEDRIS. As Dick indicated one could map the epsg codes to the way<br>
projections are defined in 18026. Of course, proj4 does that already.<br>
<br>
The enhanced geospatial component references all of the following:<br>
<br>
RT (reference transformation) code (Int32) values are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_ANNEX_E.PDF" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_ANNEX_E.PDF</a><br>
<br>
(There are 342! )<br>
<br>
dss (designated spatial surface) codes are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_DSS_VOS.PDF#T_9_2" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_DSS_VOS.<wbr>PDF#T_9_2</a><br>
<br>
(There are 9)<br>
<br>
ORM (Object reference model) codes are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_ANNEX_E.PDF" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_ANNEX_E.PDF</a><br>
<br>
(There are 252, these include celestial objects).<br>
<br>
SRF (spatial reference frame) codes are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_SRF.PDF#T_8_30" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_SRF.PDF#T_<wbr>8_30</a><br>
and following<br>
<br>
(There are 14)<br>
<br>
SRFS (SRF sets) and member codes are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_SRF.PDF#T_8_48" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_SRF.PDF#T_<wbr>8_48</a><br>
and following<br>
<br>
(There are 7, each with members)<br>
<br>
SRFT (SRF template) codes are here:<br>
<br>
<a href="http://standards.sedris.org/18026_Ed2/ISO_IEC_18026_Ed2/text/ISOIEC_18026E_SRF.PDF#T_8_3" rel="noreferrer" target="_blank">http://standards.sedris.org/<wbr>18026_Ed2/ISO_IEC_18026_Ed2/<wbr>text/ISOIEC_18026E_SRF.PDF#T_<wbr>8_3</a><br>
<br>
(There are 26).<br>
<br>
In theory, all of those would need to be implemented. So the only<br>
realistic chance is to use the provided SEDRIS libraries. (I had made<br>
some progress converting them to javascript with what is now web<br>
assembly).<br>
<br>
-Andreas<br>
<span class=""><br>
><br>
><br>
> On Sun, May 13, 2018 at 6:39 PM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>><br>
> wrote:<br>
><br>
>> To be honest, I have not heard of the 3TM projection. Googling shows<br>
>> it is widely used in Canada but I am not sure that it is commonly used<br>
>> elsewhere.<br>
>><br>
>> The scale factors for the UTM/3TM projection is related to the width<br>
>> of the zones. They are designed such that there is true scale at two<br>
>> meridians symmetric to the central meridian. A scale factor of 1.0<br>
>> would yield true scale only at the central meridian. So it just<br>
>> depends where your city is relative to the two meridians with true<br>
>> scale, both for UTM and 3TM. The smaller width of 3 degrees per zone<br>
>> is really what makes distortions a little less severe with 3TM at the<br>
>> expense of having to deal with more zones. I suspect that this is a<br>
>> the cm to mm scale relative improvement. Most regions have their own<br>
>> preferred projection.<br>
>><br>
>> But 3TM and 10TM would be easy to add as you say once the zones are<br>
>> figured out. If it helps with adoption why not.<br>
>><br>
>> 25.2.2 states<br>
>><br>
>> 'Internally, an X3D browser will transform all geographic coordinates<br>
>> into earth-fixed geocentric coordinates (i.e., an (x,y,z) displacement<br>
>> from the center of the earth in units of length base units).'<br>
>><br>
>> This allows to mix geo-coordinates and predictable regular coordinates<br>
>> in a scene.<br>
>><br>
</span><span class="">>> My understanding is that the deprecation of GeoOrigin assumed that<br>
>> browsers would be able to use internally high precision (with doubles<br>
>> or better).<br>
>><br>
</span><span class="">>> The TCS based on the first geo-coordinate is a good idea but would<br>
>> need to be standardized.<br>
>><br>
>> GeoPositionInterpolator has both geovalue_changed which does not<br>
>> convert and value_changed which does convert to GC (but for you<br>
>> perhaps to LCS=TCS) as I understand it.<br>
>><br>
>> I agree that the browser internal coordinate conversions may just as<br>
>> well be exposed.<br>
>><br>
>> Walk mode currently just recognizes any mesh, surface or grid<br>
>> underneath and will use it to stay above, in x3dom (with GeoOrigin).<br>
>> Stepping off currently means falling in x3dom, I believe.<br>
>><br>
>> -Andreas<br>
>><br>
>> > Date: Sun, 13 May 2018 17:10:05 -0600<br>
>> > From: GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>><br>
>> > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
>> > Subject: Re: [x3d-public] GeoPlanets, was: Invalid geoSystem values in<br>
>> >         X3D Resources BasicGeospatial examples.<br>
>> > Message-ID:<br>
>> >         <CAM2ogRdsLO+<wbr>dNzBrHhuFt2Bwfd5qFw-<wbr>QL2LtEwaWRGa4BYi-TQ@mail.<br>
</span><span class="">>> <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>><br>
>> > Content-Type: text/plain; charset="utf-8"<br>
>> ><br>
</span><div><div class="h5">>> > Andreas,<br>
>> > Thanks for those links to those detailed Geospatial proposal. I hadn't<br>
>> see<br>
>> > that. I'll read it in more detail.<br>
>> ><br>
>> > 3TM is commonly used by cities around the world in their GIS department,<br>
>> > because the scale factor is close to 1 so when you take measurements it's<br>
>> > close to the surveyor's tape measure..<br>
>> ><br>
>> > And it uses the same transverse mercator math functions as UTM, so just a<br>
>> > scale factor and 2 offsets different - a very easy thing for browser<br>
>> > developers to add to their UTM support capture the city GIS crowd.<br>
>> ><br>
>> >> the underlying assumption is that in the scene regular (nongeo)<br>
>> >> coordinates are geocentric, eg. relative to the center of a single<br>
>> planet.<br>
>> ><br>
>> > Not quite or that's not how freewrl is working, not my understanding. In<br>
>> > the Precision section of Geospatial, it talks about GeoOrigin (deprecated<br>
>> > in v3.3) or something done automatically in the place of GeoOrigin.<br>
>> That's<br>
>> > called the Local Coordinate System. Not at the center of the earth. Its<br>
>> > somewhere nearby to the scenery you have on the surface of the earth, to<br>
>> > reduce coordinate precision required (from double to float) as the specs<br>
>> > describe.<br>
>> > In freewrl, in place of deprecated GeoOrigin, freewrl uses the TCS<br>
>> > -Topocentric Coordinate System, as described for GeoLocation- of the<br>
>> first<br>
>> > GeoNode it parses, or more precisely, the TCS of the first GeoNode in the<br>
>> > planet, as the arbitrary LCS origin.<br>
>> > Then non-geo nodes are in this LCS by default.<br>
>> ><br>
>> ><br>
>> >> I think regular coordinates within a GeoPlanet node would be geocentric<br>
>> > only<br>
>> >> to that planet.<br>
>> > They are LCS. So one job of GeoPlanet is to convert from LCS to GC /<br>
>> > geocentric - or more precisely push onto the transform stack a transform<br>
>> > that will do that - so the parent scenery sees the planet in geocentric<br>
>> > coords like you were thinking.<br>
>> ><br>
>> >> In a multiplanet scene it would be necessary to also<br>
>> >> specify the positions of the planets relative to each other.<br>
>> > Yes. Once each planet is wrapped in GeoPlanet then you can use normal<br>
>> > transforms to position the planets, and scripts to animate the planets.<br>
>> > The EarthRise_GP.x3d scene I mentioned does that - its got moon, sun, and<br>
>> > earth (although at shorter non-realistic distances).<br>
>> > I haven't done a formal release of a freewrl version that does all that,<br>
>> > but the develop version has been doing it all since March.<br>
>> ><br>
>> ><br>
>> >> GeoPositionInterpolator converts to GC<br>
>> > Really? Uh-oh. I missed that. I thought it was just working in double<br>
>> > precision coordinates, and left it up to you to decide GD, GC or XTM, but<br>
>> > without converting anything for you.<br>
>> > That's the main benefit I was targeting with the GeoConverter node<br>
>> > proposal. So if you do need conversion its available. And for browser<br>
>> > developers, its one of the easiest GeoNodes to add, because you already<br>
>> > have the conversion functions internally.<br>
>> ><br>
>> ><br>
>> >> relativeHeight: sounds interesting. Why use the highest point on the<br>
>> >> GEG and not the height at the actual location ?<br>
>> > It does/should use the GEG height at your location. But if you had<br>
>> > overlapping GEGS then takes highest one at your location.<br>
>> > That's handy if you have a low-resolution GEG covering for example the<br>
>> > whole planet, and want to put a high res GEG for a small local area of<br>
>> > interest. Rather than cut a hole in a GEG (awkward code), you can lower<br>
>> the<br>
>> > heights a bit, and your higher res GEG will take over.<br>
>> ><br>
>> >> What if the registered<br>
>> >> GEG is somewhere else than the GL ? Just fall back to<br>
>> >> Geoid,eg.sealevel ?<br>
>> ><br>
>> > Yes - fall back to relative-to-sealevel, for GL (or if you know you're<br>
>> not<br>
>> > going to be on a GEG, use absolute / leave .relativeHeight FALSE)<br>
>> > For GVP, a more common use case is starting out over a GEG and running<br>
>> off.<br>
>> > Lets say you start out on a small local GEG, with relativeHeight 100, and<br>
>> > you're in walk mode, and feeling the bumps in the terrain as you navigate<br>
>> > along. Then you hit the edge of the GEG and want to keep going. In<br>
>> freewrl,<br>
>> > with no GEG adjusting the height, you stay at the absolute (above<br>
>> sealevel)<br>
>> > height you were at when you hit the edge. If you turn and go back on at a<br>
>> > different place, the relative height you specified kicks back in, and<br>
>> > you're back at your 100m height walking on the GEG.<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
</div></div>>> > On Sun, May 13, 2018 at 1:50 PM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a><br>
<div><div class="h5">>> ><br>
>> > wrote:<br>
>> ><br>
>> >> Hi Doug,<br>
>> >><br>
>> >> here is my unfinished response to your earlier posting:<br>
>> >><br>
>> >> there may be planetary geoSystems or spatial reference frames proposed<br>
>> >> in the enhanced geospatial component proposal.<br>
>> >> <a href="http://www.igraphics.com/Standards/EnhancedGeospatialComponent_" rel="noreferrer" target="_blank">http://www.igraphics.com/<wbr>Standards/<wbr>EnhancedGeospatialComponent_</a><br>
>> >> 2007_10_30/Part01/components/<wbr>geodata.html<br>
>> >> <a href="http://www.sedris.org/wg8home/Documents/18026_FDIS/C030811e_" rel="noreferrer" target="_blank">http://www.sedris.org/wg8home/<wbr>Documents/18026_FDIS/C030811e_</a><br>
>> >> FILES/MAIN_C030811e/ISOIEC_<wbr>18026E_TOC.HTM<br>
>> >><br>
>> >> But a more streamlined proposal seems very useful.<br>
>> >><br>
>> >> I think geospatial nodes can only deal with scenes on a single planet<br>
>> >> since the underlying assumption is that in the scene regular (nongeo)<br>
>> >> coordinates are geocentric, eg. relative to the center of a single<br>
>> >> planet. Your proposal seems to address somewhat that question. I think<br>
>> >> regular coordinates within a GeoPlanet node would be geocentric only<br>
>> >> to that planet. In a multiplanet scene it would be necessary to also<br>
>> >> specify the positions of the planets relative to each other.<br>
>> >><br>
>> >> An expansion may be a solarcentric mode, where the center of a solar<br>
>> >> system is the origin. Each planet would have its center given relative<br>
>> >> to a central sun (ignoring precision issues for the moment). I think<br>
>> >> astronomy also uses galactic coordinates.<br>
>> >><br>
>> >> And here additional feedback:<br>
>> >><br>
>> >> 3TM and 10UTM seems to be only used in Canada ? 3TM seems to have<br>
>> >> meridians based on province ? If we allow additional projections, they<br>
>> >> should be truly global and well defined. I do not see it as a big<br>
>> >> burden to convert to GD or UTM. The other route to is allow all epsg<br>
>> >> codes which can be converted by a library such proj which means<br>
>> >> essentially all possible projections.<br>
>> >><br>
>> >> GeoPositionInterpolator converts to GC but there is no way to convert<br>
>> >> to UTM or GD which may be useful for reporting coordinates.<br>
>> >><br>
>> >> relativeHeight: sounds interesting. Why use the highest point on the<br>
>> >> GEG and not the height at the actual location ? What if the registered<br>
>> >> GEG is somewhere else than the GL ? Just fall back to<br>
>> >> Geoid,eg.sealevel ?<br>
>> >><br>
>> >> -Andreas<br>
>> >><br>
>> >> > Date: Sun, 13 May 2018 12:10:21 -0600<br>
>> >> > From: GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>><br>
>> >> > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
>> >> > Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources<br>
>> >> >         BasicGeospatial examples.<br>
>> >> > Message-ID:<br>
>> >> >         <<wbr>CAM2ogRfXeWAaqvS9WvLRrYUoGXMNH<wbr>b1NWyR7+aFDTos_-mp3zg@mail.<br>
>> >> <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>><br>
>> >> > Content-Type: text/plain; charset="utf-8"<br>
>> >> ><br>
>> >> > John, thanks for checking.<br>
>> >> > Hypothesis: Maybe I forgot to check the [x] public checkbox when<br>
>> making a<br>
>> >> > spec comment? I meant for it to be public, And I hope the<br>
>> recommendations<br>
>> >> > are adopted in some future version of the specs, and implemented by<br>
>> >> browser<br>
>> >> > developers.<br>
>> >> > I'll make it public here and do another submission.<br>
>> >> > -Doug<br>
>> >> > Here's what I submitted Mar 26, 2018<br>
>> >> ><br>
>> >> > ==============================<wbr>==============================<wbr>==<br>
>> >> ><br>
>> >> > GeoSpatial Component Comments Mar 2018<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > Acronyms:<br>
>> >> ><br>
>> >> > GL - GeoLocation<br>
>> >> ><br>
>> >> > GVP - GeoViewpoint<br>
>> >> ><br>
>> >> > GEG - GeoElevationGrid<br>
>> >> ><br>
>> >> > GPS - GeoProximitySensor<br>
>> >> ><br>
>> >> > GP - GeoPlanet<br>
>> >> ><br>
>> >> > XTM - UTM or 3TM<br>
>> >> ><br>
>> >> > 3TM - like UTM, except 3 degree zones, .9999 scale factor and no false<br>
>> >> > northing / false easting<br>
>> >> ><br>
>> >> > user coords - coords matching geosystem, authored in scene file,<br>
>> could be<br>
>> >> > GC, XTM, GD<br>
>> >> ><br>
>> >> > TCS/LGS - Topocentric Coordinate System aka Local Geodetic System, as<br>
>> >> > described in specs for GeoLocation:<br>
>> >> ><br>
>> >> > -- tangent to ellipsoid at a given geo location, -Z north, Y up<br>
>> >> ><br>
>> >> > LCS - Local Coordinate System - as described in specs for numerical<br>
>> >> > precision<br>
>> >> ><br>
>> >> > -- shared cartesian coordinate system used internally<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > A. Proposed nodetype: GeoPlanet<br>
>> >> ><br>
>> >> > Implicit in the web3d geospatial specs: all geoNodes are on the same<br>
>> >> > planet.: earth That should cover 99.99999% of uses. And even if you<br>
>> have<br>
>> >> 2<br>
>> >> > planets, the transform stack will keep them separate for most use<br>
>> >> cases.  The<br>
>> >> > exception being node-node interactions such as GVP-GEG,  GL-GEG, and<br>
>> >> > GPS-GEG as I'll explain later for the relativeHeight feature.<br>
>> >> ><br>
>> >> > x3d usage:<br>
>> >> ><br>
>> >> > <GeoPlanet planetId='#'><br>
>> >> ><br>
>> >> >  ... geonodes for planet...<br>
>> >> ><br>
>> >> > </GeoPlanet><br>
>> >> ><br>
>> >> > where<br>
>> >> ><br>
>> >> > planetId - an Int32 field that can be used to discriminate between<br>
>> >> planets,<br>
>> >> > could also be called planetName or planet<br>
>> >> ><br>
>> >> > example scenefile:<br>
>> >> ><br>
>> >> > <a href="http://dug9.users.sourceforge.net/web3d/tests/geo/World/" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/tests/geo/World/</a><br>
>> earthriseGP.x3d<br>
>> >> ><br>
>> >> > <a href="http://dug9.users.sourceforge.net/web3d/temp/freeWRL2018_" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/temp/freeWRL2018_</a><br>
>> GeoPlanet.mp4<br>
>> >> > feature details:<br>
>> >> ><br>
>> >> > 1. similar to GeoTransform (GT) it wraps geonodes, but instead of<br>
>> >> > converting to TCS/LGS it converts to GC<br>
>> >> > - allows orbital mechanics on multiple planets using planet centers<br>
>> and Z<br>
>> >> > as rotation axis<br>
>> >> ><br>
>> >> > - same job could in theory be done by modifying the specs for<br>
>> >> GeoTransform,<br>
>> >> > to allow converting to GC instead of TCS/LGS, and a field for<br>
>> planetId,<br>
>> >> but<br>
>> >> > adds a connundrum: 2 geoTransforms for the same planet could sport<br>
>> >> > different translation, rotation etc, which doesn't make sense.<br>
>> >> > 2. for node-node interactions such as GVP-GEG and GL-GEG helps keep<br>
>> the<br>
>> >> > planets separate<br>
>> >> ><br>
>> >> > - internally planetId is pushed and popped during scenegraph<br>
>> traversal,<br>
>> >> so<br>
>> >> > when visiting a the code can tell which planet it's working on<br>
>> >> ><br>
>> >> > a) for GVP-GEG:<br>
>> >> ><br>
>> >> > -- when visiting GVP to start the modelview matrix, store the<br>
>> planetId in<br>
>> >> > the GVP<br>
>> >> ><br>
>> >> > -- when visiting GEG, check the current planetId (applies to GEG)<br>
>> against<br>
>> >> > the GVP._planetId, use if same<br>
>> >> ><br>
>> >> > b) for GL-GEG:<br>
>> >> ><br>
>> >> > -- after loading scene/inline/externProto body, on first traveral add<br>
>> >> each<br>
>> >> > GEG to a per-planet list of GEGs<br>
>> >> ><br>
>> >> > -- when visiting a GL with relativeHeight TRUE, look through the<br>
>> current<br>
>> >> > planet's list of GEGs, and get the highest terrain height, if any GEGs<br>
>> >> > covering that location.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > GeoPlanet : X3DGroupingNode {<br>
>> >> >   SFInt32  []        planetId       0           [0,?)<br>
>> >> >   SFNode   [in,out] metadata       NULL        [X3DMetadataObject]<br>
>> >> >   MFNode   [in]     addChildren                [X3DChildNode]<br>
>> >> >   MFNode   [in]     removeChildren             [X3DChildNode]<br>
>> >> >   MFNode   [in,out] children       []          [X3DChildNode]<br>
>> >> >   SFVec3f  []       bboxCenter     0 0 0       (-?,?)<br>
>> >> >   SFVec3f  []       bboxSize       -1 -1 -1    [0,?) or ?1 ?1 ?1<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > B. Proposed nodetype: GeoConvert<br>
>> >> ><br>
>> >> > Web3d specs allow a different geoSystem on each geo node. And each as<br>
>> >> > fields in user/geoSystem coordinates that can be routed to/from. But<br>
>> no<br>
>> >> way<br>
>> >> > to convert between geoSystems.<br>
>> >> ><br>
>> >> > Proposed GeoConvert node<br>
>> >> ><br>
>> >> > - allows you to convert between GeoSystems via routing and 2<br>
>> GeoConvert<br>
>> >> > nodes<br>
>> >> > myGeoNode1 -> set_geoCoord (geoConvert1) gcCoord_changed -><br>
>> set_gcCoord<br>
>> >> > (geoConvert2) geoCoord_changed -> myGeoNode2<br>
>> >> > where geoConvert1.geoSystem == myGeoNode1.geoSystem<br>
>> >> > and geoConvert2.geoSystem == myGeoNode2.geoSystem<br>
>> >> > <a href="http://dug9.users.sourceforge.net/web3d/tests/geo/World/" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/tests/geo/World/</a><br>
>> >> World33geoConvert.x3d<br>
>> >> ><br>
>> >> ><br>
>> >> > GeoConvert : X3DNode {<br>
>> >> >   SFVec3d  [in]     set_geoCoords<br>
>> >> >   SFVec3d  [in]     set_gcCoords<br>
>> >> >   SFNode   [in,out] metadata       NULL        [X3DMetadataObject]<br>
>> >> >   MFString []       geoSystem      ["GD","WE"] [see 25.2.3]<br>
>> >> >   SFVec3d  [out]    geoCoords_changed<br>
>> >> >   SFVec3d  [out]    gcCoords_changed<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> > C. Proposed field for GVP, GL and GPS: .relativeHeight<br>
>> >> ><br>
>> >> > Sometimes you don't know the exact height of something above the<br>
>> >> ellipsoid,<br>
>> >> > but you know you want it at ground level, and you have a GEG in the<br>
>> scene<br>
>> >> > covering the area. It would be convenient to put 0 for the<br>
>> >> geoCoords/center<br>
>> >> > height, if they are GD or XTM user coords (not GC), and have the<br>
>> browser<br>
>> >> > adjust the height to terrain level.<br>
>> >> ><br>
>> >> > For GL and GPS if relativeHeight = TRUE, then on each frame when<br>
>> visiting<br>
>> >> > the node, check the list of GEGs registered for the current GeoPlanet,<br>
>> >> and<br>
>> >> > add the highest of those (if any) to the .geoCoords / .center height<br>
>> if<br>
>> >> in<br>
>> >> > GD or XTM, to convert from user to internal GC, and subtract if going<br>
>> >> from<br>
>> >> > GC back to user.<br>
>> >> ><br>
>> >> > For GVP, the behaviour is similar, but only for initial positioning,<br>
>> >> > because browser-supported navigation modes likely want to adjust the<br>
>> >> > relative height:<br>
>> >> ><br>
>> >> > - WALK + Collide:  maintain relative height to terrain, by<br>
>> >> climbing/falling<br>
>> >> > while navigating on GEG<br>
>> >> ><br>
>> >> > - FLY + Collide: maintain height relative to ellipsoid<br>
>> >> ><br>
>> >> > - FLY (no collide aka FREEFLY): allow height to be adjusted<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > Example scene (GVP and GL):<br>
>> >> ><br>
>> >> > <a href="http://dug9.users.sourceforge.net/web3d/temp/freeWRL2018_" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/temp/freeWRL2018_</a><br>
>> >> relativeHeights.mp4<br>
>> >> ><br>
>> >> > <a href="http://dug9.users.sourceforge.net/web3d/tests/geo/World/" rel="noreferrer" target="_blank">http://dug9.users.sourceforge.<wbr>net/web3d/tests/geo/World/</a><br>
>> >> World33GLrelativeHeight.x3d<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > Field descriptions:<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > GeoLocation  : X3DGroupingNode {<br>
>> >> > .. as per specs ..<br>
>> >> >   SFBool   []       relativeHeight FALSE<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> > GeoViewpoint : X3DViewpointNode {<br>
>> >> > .. as per specs ..<br>
>> >> >  SFBool    []       relativeHeight FALSE<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> > GeoProximitySensor  : X3DEnvironmentalSensorNode {<br>
>> >> > .. as per specs ..<br>
>> >> >   SFBool   []       relativeHeight FALSE<br>
>> >> > }<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > D. Proposed geoSystem additions<br>
>> >> ><br>
>> >> > <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/" rel="noreferrer" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.3/Part01/</a><br>
>> >> components/geodata.html#<wbr>Spatialreferenceframes<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > D1. A, IF, F, R<br>
>> >> ><br>
>> >> > An assumption of the specs: all geoNodes are for one planet: earth,<br>
>> and<br>
>> >> the<br>
>> >> > list of allowed ellipsoids are for earth.<br>
>> >> ><br>
>> >> > Online samples include a Mars scene, and it uses default earth<br>
>> ellipsoid:<br>
>> >> ><br>
>> >> > <a href="http://www.web3d.org/x3d/content/examples/Basic/#Geospatial" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/Basic/#<wbr>Geospatial</a><br>
>> >> ><br>
>> >> > Here are some additions to geoSystem to allow users to specify the<br>
>> >> > ellipsoid parameters:<br>
>> >> ><br>
>> >> > # - a number like a 6378137 or 298.257223563<br>
>> >> ><br>
>> >> > "A#" - semimajor axis<br>
>> >> ><br>
>> >> >  "IF#" - inverse flattening<br>
>> >> ><br>
>> >> > "F#" - flattening<br>
>> >> ><br>
>> >> > "R" - radius<br>
>> >> ><br>
>> >> > coherent combinations include:<br>
>> >> ><br>
>> >> > A and F<br>
>> >> ><br>
>> >> > A and IF<br>
>> >> ><br>
>> >> > R<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > D2. 3TM<br>
>> >> ><br>
>> >> > 3TM is like UTM, except with (built-in) central meridan scale factor<br>
>> >> .9999<br>
>> >> > (instead of .9997 for UTM) and no false easting or false northing (so<br>
>> >> > coordinates can be negative). Typically used for cities, and GIS<br>
>> packages<br>
>> >> > export 3TM often without mentioning the zone or central meridian. In<br>
>> that<br>
>> >> > case you can set Z0. Otherwise its generally 2x the UTM zone or 2x- 1.<br>
>> >> ><br>
>> >> > coherent combinations include<br>
>> >> ><br>
>> >> > 3TM<br>
>> >> ><br>
>> >> > 3TM and Z<br>
>> >> ><br>
>> >> > along with other UTM-compatible options except no FalseEasting or<br>
>> >> > FalseNorthing.<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > ==============================<wbr>==============================<wbr>====<br>
>> >> ><br>
>> >> > and April 9, 2018 addendum:<br>
>> >> ><br>
>> >> > ==============================<wbr>========<br>
>> >> ><br>
>> >> > (refering to a previous spec submission from the same commentor which<br>
>> >> > included new nodetype GeoPlanet)<br>
>> >> ><br>
>> >> > GeoPlanet - there's a preference among freewrl users that instead of<br>
>> >> > numerical planetId='#' it would be an SFString ie planet='earth',<br>
>> which<br>
>> >> > would be easier for scene authors to keep straight in their own minds.<br>
>> >> ><br>
>> >> > SFString planet "earth"<br>
>> >> ><br>
>> >> > ==============================<wbr>==========<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > On Sun, May 13, 2018 at 10:58 AM, John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> >> You may want to resubmit your 3TM and Planet changes to Mantis.  I<br>
>> >> >> searched for 3TM and Planet in Mantis (All Projects) and got nothing<br>
>> >> >> significant back.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> However, I was denied access to:<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> <a href="http://www.web3d.org/node/1694/submission/1671" rel="noreferrer" target="_blank">http://www.web3d.org/node/<wbr>1694/submission/1671</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Why?<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> and there?s:<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> <a href="http://www.web3d.org/member-only/mantis/view.php?id=1215" rel="noreferrer" target="_blank">http://www.web3d.org/member-<wbr>only/mantis/view.php?id=1215</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Not that I want to imagine writing schema for such a thing?that?s<br>
>> why I<br>
>> >> >> hope to get geoSystem into more reasonable shape in the Unified<br>
>> Object<br>
>> >> >> Model (we need volunteers, I think) before trying to do it in schema.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> John<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Sent from Mail <<a href="https://go.microsoft.com/fwlink/?LinkId=550986" rel="noreferrer" target="_blank">https://go.microsoft.com/<wbr>fwlink/?LinkId=550986</a>> for<br>
>> >> >> Windows 10<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> *From: *GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>><br>
>> >> >> *Sent: *Sunday, May 13, 2018 9:16 AM<br>
>> >> >> *To: *X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
>> >> >> *Subject: *Re: [x3d-public] Invalid geoSystem values in X3D Resources<br>
>> >> >> BasicGeospatial examples.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> I think N should be OK, just as you say a redundant default.. I<br>
>> proposed<br>
>> >> >> several new things in the geoSystem field, submitted to spec<br>
>> comments a<br>
>> >> few<br>
>> >> >> months ago, so I hope your processor works on the new things if ever<br>
>> >> >> adopted.<br>
>> >> >><br>
>> >> >> -Doug<br>
>> >> >><br>
>> >> >> R,A,B,F,IF - ways to drectly specifiy the shape of the ellipsoid so<br>
>> >> other<br>
>> >> >> planet shapes and sizes could be modeled<br>
>> >> >><br>
>> >> >> 3TM - similar to UTM (except 3degree zones, no false northing or<br>
>> >> easting,<br>
>> >> >> different central meridian scale factor .9999)<br>
>> >> >><br>
>> >> >> ...<br>
>> >> >><br>
>> >> >> I also proposed a Planet node - allows multiple planets in one scene<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Sun, May 13, 2018 at 6:14 AM, John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
>> >> wrote:<br>
>> >> >><br>
>> >> >> The object model is expressive enough to list conforming values, yet<br>
>> >> >> accept others, but as far as I know (I may be wrong here), it is not<br>
>> >> >> expressive enough to express supported geoSystem values.   This is a<br>
>> >> >> problem.   How do we resolve it, and should we, if we are accepting<br>
>> >> other<br>
>> >> >> values?   Is it resolved in X3DJSAIL?  Should I get rid of Roy's JSON<br>
>> >> >> subschema for geoSystem?<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> John<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Sun, May 13, 2018, 7:43 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
>> wrote:<br>
>> >> >><br>
>> >> >> I believe the purpose of schema is to support minimally acceptable<br>
>> >> files.<br>
>> >> >>  It should flag files which are questionable.   If a file can be<br>
>> brought<br>
>> >> >> into conformance easily, shouldn't it be?<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Yes, you should be able to ignore the results of the schema<br>
>> >> >> validation...at your own risk.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> What is the purpose of the X3D resources examples, but to show a good<br>
>> >> >> example practice?  Or are we testing tools to make sure certain<br>
>> values<br>
>> >> are<br>
>> >> >> acceptable?   If that's the case, then the schema should be updated<br>
>> for<br>
>> >> ALL<br>
>> >> >> versions.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> John<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Sun, May 13, 2018, 7:31 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
>> wrote:<br>
>> >> >><br>
>> >> >> Then the version of the document should be upgraded to 4.0 or above,<br>
>> and<br>
>> >> >> the corresponding schema updated.   I can upgrade the schema for all<br>
>> >> >> versions, since it is hard coded into the schema generator.   But<br>
>> >> really we<br>
>> >> >> need support from the object model if possible.   Right now, I have<br>
>> to<br>
>> >> >> explicitly allow it for all versions, since I use stdin/stdout<br>
>> instead<br>
>> >> of<br>
>> >> >> files.  Does the unified object model specify a version # in its<br>
>> >> contents?<br>
>> >> >> When the unified object model supports "N" in a usable fashion, then<br>
>> I<br>
>> >> can<br>
>> >> >> code something into the schema, or delete the requirement to check<br>
>> >> >> geoSystem.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Thanks, away from computer presently, or I would check.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> I don't see why Roy went to all the effort to create a schema, if we<br>
>> are<br>
>> >> >> going to ignore it?<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> This applies in many areas...if we merely have supported values, yet<br>
>> >> >> others must be accepted, why is there a standard?<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> I don't believe it's ambiguous in this case of X3D.   A missing "N"<br>
>> >> means<br>
>> >> >> Northern Hemisphere.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> John<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> On Sun, May 13, 2018, 12:46 AM Andreas Plesch <<br>
>> <a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >><br>
>> >> >> <a href="http://www.web3d.org/specifications/19775-1/V3.2/" rel="noreferrer" target="_blank">http://www.web3d.org/<wbr>specifications/19775-1/V3.2/</a><br>
>> >> >> Part01/components/geodata.<wbr>html#<wbr>Specifyingaspatialreference<br>
>> >> >> <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/" rel="noreferrer" target="_blank">http://www.web3d.org/<wbr>documents/specifications/<wbr>19775-1/V3.2/Part01/</a><br>
>> >> components/geodata.html#<wbr>Specifyingaspatialreference><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> lists the supported strings for the geoSystem MFString field.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> The prose choosing 'supported' over 'legal' or 'conforming' could be<br>
>> >> taken<br>
>> >> >> to mean that other than listed strings may be allowed to be<br>
>> supported as<br>
>> >> >> well by some browsers.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> However, previous discussions indicate that schemas are not<br>
>> sufficiently<br>
>> >> >> expressive to describe unknown but conforming string values.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> One resolution was to explicitly allow 'N' in upcoming X3D version,<br>
>> and<br>
>> >> >> perhaps silently allow it for 3.3.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Outside of X3D UTM zones often have the N hemisphere identifier to<br>
>> avoid<br>
>> >> >> ambiguity.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Andreas<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> Date: Sat, 12 May 2018 19:54:17 -0400<br>
>> >> >> From: John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>><br>
>> >> >> To: Don Brutzman <<a href="mailto:brutzman@nps.edu">brutzman@nps.edu</a>>,  X3D Graphics public mailing<br>
>> list<br>
>> >> >>         <<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a>><br>
>> >> >> Subject: [x3d-public] Invalid geoSystem values in X3D Resources Basic<br>
>> >> >>         Geospatial examples.<br>
>> >> >> Message-ID: <<a href="mailto:5af77ea8.1c69fb81.7da1f.13e3@mx.google.com">5af77ea8.1c69fb81.7da1f.13e3@<wbr>mx.google.com</a>><br>
>> >> >> Content-Type: text/plain; charset="utf-8"<br>
>> >> >><br>
>> >> >> Don, These files contain "N" in geoSystem, which I believe is not<br>
>> valid,<br>
>> >> >> and should be removed (default is Northern Hemisphere,  in the<br>
>> >> standard, I<br>
>> >> >> believe. "S" can be specified?not in this case).<br>
>> >> >><br>
>> >> >> Is there a tool which hasn?t been changed which is<br>
>> >> >><br>
</div></div><span class="">>> >> >> ______________________________<wbr>_________________<br>
>> >> >> x3d-public mailing list<br>
>> >> >> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> >> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>> >> >><br>
>> >> >><br>
>> >> >> ______________________________<wbr>_________________<br>
>> >> >> x3d-public mailing list<br>
>> >> >> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> >> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
</span><span class="">>> >> > -------------- next part --------------<br>
>> >> > An HTML attachment was scrubbed...<br>
>> >> > URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/</a><br>
>> >> attachments/20180513/8defb5db/<wbr>attachment.html><br>
>> >> ><br>
>> >> > ------------------------------<br>
>> >> ><br>
>> >> > Subject: Digest Footer<br>
>> >> ><br>
</span><span class="">>> >> > ______________________________<wbr>_________________<br>
>> >> > x3d-public mailing list<br>
>> >> > <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> >> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>> >> ><br>
>> >> ><br>
</span><span class="">>> >> > ------------------------------<br>
>> >> ><br>
>> >> > End of x3d-public Digest, Vol 110, Issue 31<br>
>> >> > ******************************<wbr>*************<br>
>> >><br>
>> >><br>
>> >><br>
</span><span class="">>> >> --<br>
>> >> Andreas Plesch<br>
>> >> Waltham, MA 02453<br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> x3d-public mailing list<br>
>> >> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> >> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>> >><br>
</span><span class="">>> > -------------- next part --------------<br>
>> > An HTML attachment was scrubbed...<br>
>> > URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/</a><br>
</span>>> attachments/20180513/75e39192/<wbr>attachment.html><br>
>> ><br>
>> > ------------------------------<br>
>> ><br>
>> > Subject: Digest Footer<br>
<span class="">>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > x3d-public mailing list<br>
>> > <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>> ><br>
>> ><br>
</span><span class="">>> > ------------------------------<br>
>> ><br>
>> > End of x3d-public Digest, Vol 110, Issue 35<br>
>> > ******************************<wbr>*************<br>
>><br>
>><br>
>><br>
</span><span class="">>> --<br>
>> Andreas Plesch<br>
>> Waltham, MA 02453<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> x3d-public mailing list<br>
>> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
>><br>
</span><span class="">> -------------- next part --------------<br>
> An HTML attachment was scrubbed...<br>
</span>> URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180514/63ab5bf0/attachment.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/<wbr>x3d-public_web3d.org/<wbr>attachments/20180514/63ab5bf0/<wbr>attachment.html</a>><br>
><br>
> ------------------------------<br>
><br>
> Subject: Digest Footer<br>
<span class="">><br>
> ______________________________<wbr>_________________<br>
> x3d-public mailing list<br>
> <a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
><br>
><br>
</span>> ------------------------------<br>
><br>
> End of x3d-public Digest, Vol 110, Issue 43<br>
> ******************************<wbr>*************<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
______________________________<wbr>_________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/<wbr>listinfo/x3d-public_web3d.org</a><br>
</div></div></blockquote></div><br></div>