[x3d-public] candidate geoSystem correction to JSON schema (
Andreas Plesch
andreasplesch at gmail.com
Mon May 22 16:35:56 PDT 2017
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/
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> );
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170522/367c8664/attachment-0001.html>
More information about the x3d-public
mailing list