<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 23, 2017 at 10:12 AM, Roy Walmsley <span dir="ltr"><<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-7959435653452568458m_7340738173320381570WordSection1"><p class="MsoNormal"><span>Hi Andreas,<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>Many thanks for your comments. And apologies for using incorrect terminology.<u></u><u></u></span></p><p class="MsoNormal"><br></p></div></div></blockquote><div><br></div><div>No need for any apologies.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-7959435653452568458m_7340738173320381570WordSection1"><p class="MsoNormal"></p><p class="MsoNormal"><span>I hadn’t realised that there were the two additional options, i.e. “latitude_first” and “longitude_first” for the “GD” spatial reference frame, and also “northing_first” and “easting_first” for the “UTM” spatial reference frame. I have not incorporated these into the JSON schema… sighs… These would severely complicate it, and so a redesign is probably required.<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>While we are on the subject of options, are there any others that a) are currently used and I have missed or b) you would like to see included in future versions of X3D? I am well aware of the “N” discussions, and agree that it ought to be permitted (Mantis 938).<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> </span></p></div></div></blockquote><div><br></div><div>Along the lines of Dicks comment's, I would like to see support of more projections. While the standards on which the extended geospatial component is based are very rigorous, they are unfortunately not very widely used or even known. Another approach would be to define SRF's in terms of epsg codes (<a href="http://www.epsg.org/">http://www.epsg.org/</a>) which are widely used (but perhaps not quite as rigorously defined). A third standards based approach is to use WKT which is published as <a href="http://docs.opengeospatial.org/is/12-063r5/12-063r5.html">http://docs.opengeospatial.org/is/12-063r5/12-063r5.html</a> and ISO recognized: <a href="https://www.iso.org/standard/63094.html">https://www.iso.org/standard/63094.html</a> . There are java and javascript libraries which implement these large standards.</div><div><br></div><div>Perhaps a revision of the geoSystem could be as simple as saying the geoSystem MFString could be composed of  'WKT', and a valid WKT string ? Or/and 'EPSG' and a epsg code ?</div><div><br></div><div>Since a lot of work was invested in producing a spec. for an extended geospatial component, I would also support its adoption.</div><div><br></div><div>If these changes are too deep and if asked what would be single most projection to support, I would suggest to support direct use of web maps (in tiles) by allowing the 'web mercator' 'projection' (let's say transformation). It is well defined and easy to implement.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-7959435653452568458m_7340738173320381570WordSection1"><p class="MsoNormal"><span><u></u></span></p><p class="MsoNormal"><span>The standard does not permit required arguments to be in any order. Therefore, although it is not clearly specified, the zone number for the “UTM” spatial reference frame should always be the second entry in the list.</span></p></div></div></blockquote><div><br></div><div>I agree that this should be spelled out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-7959435653452568458m_7340738173320381570WordSection1"><p class="MsoNormal"><span>Finally, I think the <i>geoSystem</i> field needs to be more clearly specified, so that all the options are collected together in one place. The current standard is misleading, since in the node signatures, the range of permitted values for the <i>geoSystem</i> field say “(see 25.2.3)”. And these additional options are in 25.2.4.</span></p></div></div></blockquote><div><br></div><div>Yeah, I remember well that it was quite a challenge to digest the geoSystem sections. The chapter definitely would benefit from a reorganization and editing. I will be glad to to help out.</div><div><br></div><div>Best,</div><div><br></div><div>Andreas</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_-7959435653452568458m_7340738173320381570WordSection1"><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Andreas Plesch [mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.co<wbr>m</a>] <br><b>Sent:</b> 23 May 2017 00:36<br><b>To:</b> Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>><br><b>Cc:</b> X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br><b>Subject:</b> Re: candidate geoSystem correction to JSON schema (<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Some comments below<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><br>Date: Mon, 22 May 2017 17:03:09 +0100<br>From: "Roy Walmsley" <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>><br>To: "'John Carlson'" <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>>, "'Don Brutzman'"<br>        <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>Cc: "'X3D Graphics public mailing list'" <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>Subject: Re: [x3d-public] candidate geoSystem correction to JSON<br>        schema<br>Message-ID: <05d101d2d314$e8a3c7e0$b9eb57a<wbr>0$@<a href="http://ntlworld.com" target="_blank">ntlworld.com</a>><br>Content-Type: text/plain; charset="utf-8"<br><br>Hi,<br><br><br><br>Let us look at the geoSystem field in detail. The relevant clause is ISO/IEC 19775-1 25.2.3 Specifying a spatial reference frame (see <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#Specifyingaspatialreference" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#Specifyingaspatialreferen<wbr>ce</a>). The first paragraph of this clause reads:<br><br><br><br>?All the X3D nodes that allow inclusion of geographic coordinates support a field called geoSystem. This field is used to specify the particular spatial reference frame that will be used for the geospatial coordinates in that node. This is an MFString field that can include a number of arguments to fully designate the spatial reference frame. Each argument appears in a separate string within the MFString array. Argument matching is case sensitive. Optional arguments may appear in any order. The following values are supported.?<br><br><br><br>What does this tell us? And what doesn?t it tell us? Here goes:<br><br>*       geoSystem is an MFString field<br>*       It specifies the particular spatial reference frame<br>*       It says that three values are supported, namely ?GD?, ?UTM? and ?GC?<br>*       It says the optional arguments may appear in any order<br>*       It does not specifically state that any arguments are mandatory<br><br><br><br>The subsequent three bullet points list the supported values. We?ll look at each of them in turn, in a moment. First, we should refer to clause 25.2.2 Spatial reference frames (see <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#Spatialreferenceframes" target="_blank">http://www.web3d.org/documents<wbr>/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#Spatialreferenceframes</a>). Table 25.2 lists the same three supported spatial reference frames. However, the first sentence of the text in the paragraph immediately following Table 25.2 reads as follows:<br><br><br><br>?The code GDC shall be synonymous to GD and the code GCC shall be synonymous to GC.?<br><br><br><br>We have to take account of the synonyms.<br><br><br><br>One further point is from the last paragraph of 25.2.3, which reads:<br><br><br><br>?If no geoSystem field is specified, the default value is [ "GD", "WE" ].?<br><br><br><br>So, I started the JSON schema definition for this field with the presumed requirement that the first string value is required, and must be one of the supported values, or synonyms. Since, as we shall see, that the three spatial reference frame types have rather different additional arguments, I decided to take the ?oneOf? approach, dealing with each type separately. Let?s take the first type, ?GD?, which has the synonym  ?GDC?. The first bullet point in 25.2.3 reads:<br><br><br><br>?"GD" - Geodetic spatial reference frame (latitude/longitude). An optional argument may be used to specify the ellipsoid using one of the ellipsoid codes that are defined in Table 25.3 <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#t-earthellipsoids" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#t-earthellipsoids</a>> . If no ellipsoid is specified, then "WE" is assumed (i.e., the WGS84 ellipsoid). An optional "WGS84" string can be specified if you wish all elevations to relative to the WGS84 geoid (i.e., mean sea level) (see Table 25.4 <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#t-earthgeoids" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#t-earthgeoids</a>> );<u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">This can be quite confusing since the WGS84 ellipsoid is not the same as the WGS84 geoid. The geoid has a pear like shape and is not an ellipsoid.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">otherwise, all elevations will be relative to the ellipsoid. An example spatial reference frame definition of this format is [ "GD", "WD" ], for a geodetic spatial reference frame based upon the WGS72 ellipsoid with all elevations being relative to that ellipsoid.?<br><br>And this tell us:<br><br>*       There is an optional argument to specify one of the ellipsoids from Table 25.3.<br>*       An optional ?WGS84? can be specified if all elevations are to be relative to the WGS84 geoid.<br><br><br><br>Here?s my JSON schema expanded to show this spatial reference frame type:<br><br><br><br><br><br><br><br>Does it conform? Let?s see:<br><br>*       The array is constrained to contain from one to three strings<br>*       The first string in the array, which is required has two enumerations, namely ?GD? and ?GDC?, so the synonym is present.<br>*       The second string in the array, which is optional, is an enumeration for all 23 of the supported earth ellipsoids from table 25.3.<br>*       The third string in the array, which is also optional, can only take the value ?WGS84?<br>*       The array fails to allow for the optional arguments to appear in any order<br><br><br><br>No, it does not conform. However, this can be rectifies fairly easily, by adding an additional subschema, whereby the optional ?WGS84? is the second string, and the list of 23 supported earth geoids. <u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The 23 listed are ellipsoids. Only one geoid is supported (WGS84).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Now, this section consists of two subschemas, as follows:<u></u><u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><br><br><br><br><br><br><br>Now, let?s turn to the second supported spatial reference frame type. This is ?UTM?. The second bullet point of 25.2.3 reads:<br><br><br><br>?"UTM" - Universal Transverse Mercator. One further required argument must be supplied for UTM in order to specify the zone number (1..60). This is given in the form "Z<n>", where <n> is the zone number. An optional argument of "S" may be supplied in order to specify that the coordinates are in the southern hemisphere (otherwise, northern hemisphere will be assumed). A further optional argument may be used to specify the ellipsoid using one of the ellipsoid codes that are defined in Table 25.3 <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#t-earthellipsoids" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#t-earthellipsoids</a>> . If no ellipsoid is specified, then "WE" is assumed (i.e., the WGS84 ellipsoid). An optional "WGS84" string can be specified if you wish all elevations to relative to the WGS84 geoid (i.e., mean sea level (see Table 25.4 <<a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/geodata.html#t-earthgeoids" target="_blank">http://www.web3d.org/document<wbr>s/specifications/19775-1/V3.3/<wbr>Part01/components/geodata.<wbr>html#t-earthgeoids</a>> )); otherwise, all elevations will be relative to the ellipsoid. An example spatial reference frame definition of this format is [ "UTM", "Z10", "S", "GD" ], for a southern hemisphere UTM spatial reference frame in zone 10 with all elevations being with respect to mean sea level.?<br><br><br><br>The salient points are:<br><br>*       The second string is a required argument, and must be a zone number of the form ?z<N>?, where the ?<n>? is the zone number, from one to sixty, inclusive.<u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Not sure if this has to be the 2nd argument or can occur anywhere. In practice, it is probably always the 2nd. <u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">*       An optional argument ?S? may be supplied to indicate southern hemisphere. Note that the use of an ?N? is not permitted.<u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">But in my opinion it should be permitted for symmetry reasons and UTM use expectations.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">*       A further optional argument to specify one of the ellipsoids from Table 25.3.<br>*       An optional ?WGS84? can be specified if all elevations are to be relative to the WGS84 geoid.<br><br><br><br>Here?s my JSON schema expanded to show this spatial reference frame type:<br><br><br><br><br><br><br><br>Does it conform? Let?s see:<br><br>*       The array is constrained to contain from one to five strings. This fails because the second string is required.<br>*       The first string in the array can only take the value UTM.<br>*       The second string in the array, which is optional, can take any one of the 60 zone number values.<br>*       The third string in the array, which is optional, can only take the value ?S?.<br>*       The fourth string in the array, which is optional, is an enumeration for all 23 of the supported earth ellipsoids from table 25.3.<br>*       The fifth string in the array, which is also optional, can only take the value ?WGS84?<br>*       The array fails to allow for the optional arguments to appear in any order.<br><br><br><br>So this fails on two counts. The first failure, not making the zone number required, is easy to fix. The array constraints should be changed to contain from two to five strings. The second failure, the appearance of the optional arguments in any order, could be fixed in a similar manner to the first case above, introducing additional subschemas. For this instance, as many as nine might be required. This would take careful consideration of all possible combinations, bearing in mind that any, or even all, of the three optional arguments could be absent. I will try to solve this problem at a later date.<u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal">Ok<u></u><u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><br><br>Finally let?s consider the third case. The final bullet point from 25.2.3 reads:<br><br><br><br>?"GC" - Earth-fixed Geocentric with respect to the WGS84 ellipsoid. No additional arguments are supported. An example spatial reference frame definition of this format is [ "GC" ].?<br><br><br><br>This is straightforward, since no additional arguments are supported. The only consideration required is the synonym. Here is the expanded JSON schema for this:<br><br><br><br><br><br>Now we see that only one string is permitted in the array, and it has the two possible values ?GC? and ?GCC? as required. This conforms to the requirements.<u></u><u></u></p></blockquote></div></div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">There are also the 'longitude_first' type of arguments which I use frequently. Their specification is hidden in the GD and UTM sections. They can appear anywhere making for even more permutations probably requiring some procedural checking with logic.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Since 'latitude_first' and 'northing_first' are the defaults they are rarely specified, and can in fact be ignored by a parser. This is analogous to the hemisphere specifier except that only 'S' is legal (although 'N' is the defacto default).<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It turns out it is actually not hard to write a parser for GeoSystem values when the parser can just look for known values and ignore everything else. It may be difficult to write a strict validator although the rules seem pretty watertight.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal" style="margin-bottom:12pt"><br>Before closing this discussion I should point out that the lack of support for an optional ?N? value for the UTM reference frame has been raised before. This is covered in Mantis issue 938 (see <a href="http://www.web3d.org/member-only/mantis/view.php?id=938" target="_blank">http://www.web3d.org/member-on<wbr>ly/mantis/view.php?id=938</a>). Candidate resolutions have been proposed, but none firmly decided upon. This means that those geospatial examples in the archive, such as Squaw LOD 029 (<a href="http://www.web3d.org/x3d/content/examples/Basic/Geospatial/SquawLOD029Index.html" target="_blank">http://www.web3d.org/x3d/cont<wbr>ent/examples/Basic/Geospatial/<wbr>SquawLOD029Index.html</a>) do not conform to V3.3. In fact, this particular example is against V3.0 of the standard. However, the wording is technically identical, therefore this does not conform to V3.0 either.<br><br><br><br>Since neither the DTD nor the XML schema have sufficient expressive power to validate the individual string values, these errors have probably not been picked up before. I don?t know what level of checking is built into the current version of the schematron. I did run this particular example on the X3D validator, and it passed all tests. The development of the JSON schema, with this very strong validation capability, has now exposed these issues.<u></u><u></u></p></blockquote><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><u></u> <u></u></p></blockquote><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal"><u></u> <u></u></p></blockquote></div></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_-7959435653452568458gmail_signature">Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453</div>
</div></div>