[x3d-public] candidate geoSystem correction to JSON schema (
Andreas Plesch
andreasplesch at gmail.com
Tue May 23 13:35:10 PDT 2017
On Tue, May 23, 2017 at 10:12 AM, Roy Walmsley <roy.walmsley at ntlworld.com>
wrote:
> Hi Andreas,
>
>
>
> Many thanks for your comments. And apologies for using incorrect
> terminology.
>
>
>
No need for any apologies.
> 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.
>
>
>
> 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).
>
>
>
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 (http://www.epsg.org/) which are widely used (but perhaps not quite
as rigorously defined). A third standards based approach is to use WKT
which is published as
http://docs.opengeospatial.org/is/12-063r5/12-063r5.html and ISO
recognized: https://www.iso.org/standard/63094.html . There are java and
javascript libraries which implement these large standards.
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 ?
Since a lot of work was invested in producing a spec. for an extended
geospatial component, I would also support its adoption.
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.
> 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.
>
I agree that this should be spelled out.
> Finally, I think the *geoSystem* 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 *geoSystem* field say “(see 25.2.3)”. And these
> additional options are in 25.2.4.
>
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.
Best,
Andreas
>
>
> *From:* Andreas Plesch [mailto:andreasplesch at gmail.com]
> *Sent:* 23 May 2017 00:36
> *To:* Roy Walmsley <roy.walmsley at ntlworld.com>
> *Cc:* X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject:* Re: candidate geoSystem correction to JSON schema (
>
>
>
> Some comments below
>
>
>
>
> Date: Mon, 22 May 2017 17:03:09 +0100
> From: "Roy Walmsley" <roy.walmsley at ntlworld.com>
> To: "'John Carlson'" <yottzumm at gmail.com>, "'Don Brutzman'"
> <brutzman at nps.edu>
> Cc: "'X3D Graphics public mailing list'" <x3d-public at web3d.org>
> Subject: Re: [x3d-public] candidate geoSystem correction to JSON
> schema
> Message-ID: <05d101d2d314$e8a3c7e0$b9eb57a0$@ntlworld.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
>
>
> 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
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/geodata.html#Specifyingaspatialreference). The first
> paragraph of this clause reads:
>
>
>
> ?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.?
>
>
>
> What does this tell us? And what doesn?t it tell us? Here goes:
>
> * geoSystem is an MFString field
> * It specifies the particular spatial reference frame
> * It says that three values are supported, namely ?GD?, ?UTM? and
> ?GC?
> * It says the optional arguments may appear in any order
> * It does not specifically state that any arguments are mandatory
>
>
>
> 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 http://www.web3d.org/documents
> /specifications/19775-1/V3.3/Part01/components/geodata.
> html#Spatialreferenceframes). 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:
>
>
>
> ?The code GDC shall be synonymous to GD and the code GCC shall be
> synonymous to GC.?
>
>
>
> We have to take account of the synonyms.
>
>
>
> One further point is from the last paragraph of 25.2.3, which reads:
>
>
>
> ?If no geoSystem field is specified, the default value is [ "GD", "WE" ].?
>
>
>
> 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:
>
>
>
> ?"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 <http://www.web3d.org/document
> s/specifications/19775-1/V3.3/Part01/components/geodata.
> html#t-earthellipsoids> . 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 <http://www.web3d.org/document
> s/specifications/19775-1/V3.3/Part01/components/geodata.html#t-earthgeoids>
> );
>
>
>
> 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.
>
>
>
> 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.?
>
> And this tell us:
>
> * There is an optional argument to specify one of the ellipsoids
> from Table 25.3.
> * An optional ?WGS84? can be specified if all elevations are to be
> relative to the WGS84 geoid.
>
>
>
> Here?s my JSON schema expanded to show this spatial reference frame type:
>
>
>
>
>
>
>
> Does it conform? Let?s see:
>
> * The array is constrained to contain from one to three strings
> * The first string in the array, which is required has two
> enumerations, namely ?GD? and ?GDC?, so the synonym is present.
> * The second string in the array, which is optional, is an
> enumeration for all 23 of the supported earth ellipsoids from table 25.3.
> * The third string in the array, which is also optional, can only
> take the value ?WGS84?
> * The array fails to allow for the optional arguments to appear in
> any order
>
>
>
> 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.
>
>
>
>
>
> The 23 listed are ellipsoids. Only one geoid is supported (WGS84).
>
>
>
>
>
> Now, this section consists of two subschemas, as follows:
>
>
>
>
>
>
>
>
> Now, let?s turn to the second supported spatial reference frame type. This
> is ?UTM?. The second bullet point of 25.2.3 reads:
>
>
>
> ?"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 <
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/geodata.html#t-earthellipsoids> . 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 <
> http://www.web3d.org/documents/specifications/19775-1/V3.3/
> Part01/components/geodata.html#t-earthgeoids> )); 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.?
>
>
>
> The salient points are:
>
> * 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.
>
>
>
> Not sure if this has to be the 2nd argument or can occur anywhere. In
> practice, it is probably always the 2nd.
>
>
>
>
>
> * An optional argument ?S? may be supplied to indicate southern
> hemisphere. Note that the use of an ?N? is not permitted.
>
>
>
> But in my opinion it should be permitted for symmetry reasons and UTM use
> expectations.
>
>
>
> * A further optional argument to specify one of the ellipsoids from
> Table 25.3.
> * An optional ?WGS84? can be specified if all elevations are to be
> relative to the WGS84 geoid.
>
>
>
> Here?s my JSON schema expanded to show this spatial reference frame type:
>
>
>
>
>
>
>
> Does it conform? Let?s see:
>
> * The array is constrained to contain from one to five strings. This
> fails because the second string is required.
> * The first string in the array can only take the value UTM.
> * The second string in the array, which is optional, can take any
> one of the 60 zone number values.
> * The third string in the array, which is optional, can only take
> the value ?S?.
> * The fourth string in the array, which is optional, is an
> enumeration for all 23 of the supported earth ellipsoids from table 25.3.
> * The fifth string in the array, which is also optional, can only
> take the value ?WGS84?
> * The array fails to allow for the optional arguments to appear in
> any order.
>
>
>
> 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.
>
> Ok
>
>
>
> Finally let?s consider the third case. The final bullet point from 25.2.3
> reads:
>
>
>
> ?"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" ].?
>
>
>
> This is straightforward, since no additional arguments are supported. The
> only consideration required is the synonym. Here is the expanded JSON
> schema for this:
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
>
> 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
> http://www.web3d.org/member-only/mantis/view.php?id=938). Candidate
> resolutions have been proposed, but none firmly decided upon. This means
> that those geospatial examples in the archive, such as Squaw LOD 029 (
> http://www.web3d.org/x3d/content/examples/Basic/Geospatial/
> SquawLOD029Index.html) 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.
>
>
>
> 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.
>
>
>
>
>
>
--
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170523/2c6ff9b5/attachment-0001.html>
More information about the x3d-public
mailing list