[x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.

[John Carlson]

You may want to resubmit your 3TM and Planet changes to Mantis.  I searched for 3TM and Planet in Mantis (All Projects) and got nothing  significant back.

However, I was denied access to:

http://www.web3d.org/node/1694/submission/1671

Why?

and there’s:

http://www.web3d.org/member-only/mantis/view.php?id=1215

Not that I want to imagine writing schema for such a thing…that’s why I hope to get geoSystem into more reasonable shape in the Unified Object Model (we need volunteers, I think) before trying to do it in schema.

John

Sent from Mail for Windows 10

From: GPU Group
Sent: Sunday, May 13, 2018 9:16 AM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.

I think N should be OK, just as you say a redundant default.. I proposed several new things in the geoSystem field, submitted to spec comments a few months ago, so I hope your processor works on the new things if ever adopted.
-Doug
R,A,B,F,IF - ways to drectly specifiy the shape of the ellipsoid so other planet shapes and sizes could be modeled
3TM - similar to UTM (except 3degree zones, no false northing or easting, different central meridian scale factor .9999)
...
I also proposed a Planet node - allows multiple planets in one scene

On Sun, May 13, 2018 at 6:14 AM, John Carlson <yottzumm at gmail.com> wrote:
The object model is expressive enough to list conforming values, yet accept others, but as far as I know (I may be wrong here), it is not expressive enough to express supported geoSystem values.   This is a problem.   How do we resolve it, and should we, if we are accepting other values?   Is it resolved in X3DJSAIL?  Should I get rid of Roy's JSON subschema for geoSystem?

John

On Sun, May 13, 2018, 7:43 AM John Carlson <yottzumm at gmail.com> wrote:
I believe the purpose of schema is to support minimally acceptable files.   It should flag files which are questionable.   If a file can be brought into conformance easily, shouldn't it be?

Yes, you should be able to ignore the results of the schema validation...at your own risk.

What is the purpose of the X3D resources examples, but to show a good example practice?  Or are we testing tools to make sure certain values are acceptable?   If that's the case, then the schema should be updated for ALL versions.

John

On Sun, May 13, 2018, 7:31 AM John Carlson <yottzumm at gmail.com> wrote:
Then the version of the document should be upgraded to 4.0 or above, and the corresponding schema updated.   I can upgrade the schema for all versions, since it is hard coded into the schema generator.   But really we need support from the object model if possible.   Right now, I have to explicitly allow it for all versions, since I use stdin/stdout instead of files.  Does the unified object model specify a version # in its contents?  When the unified object model supports "N" in a usable fashion, then I can code something into the schema, or delete the requirement to check geoSystem.

Thanks, away from computer presently, or I would check.

I don't see why Roy went to all the effort to create a schema, if we are going to ignore it?

This applies in many areas...if we merely have supported values, yet others must be accepted, why is there a standard?

I don't believe it's ambiguous in this case of X3D.   A missing "N" means Northern Hemisphere.

John

On Sun, May 13, 2018, 12:46 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
http://www.web3d.org/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference

lists the supported strings for the geoSystem MFString field.

The prose choosing 'supported' over 'legal' or 'conforming' could be taken to mean that other than listed strings may be allowed to be supported as well by some browsers.

However, previous discussions indicate that schemas are not sufficiently expressive to describe unknown but conforming string values.

One resolution was to explicitly allow 'N' in upcoming X3D version, and perhaps silently allow it for 3.3.

Outside of X3D UTM zones often have the N hemisphere identifier to avoid ambiguity.

Andreas




Date: Sat, 12 May 2018 19:54:17 -0400
From: John Carlson <yottzumm at gmail.com>
To: Don Brutzman <brutzman at nps.edu>,  X3D Graphics public mailing list
        <x3d-public at web3d.org>
Subject: [x3d-public] Invalid geoSystem values in X3D Resources Basic
        Geospatial examples.
Message-ID: <5af77ea8.1c69fb81.7da1f.13e3 at mx.google.com>
Content-Type: text/plain; charset="utf-8"

Don, These files contain "N" in geoSystem, which I believe is not valid, and should be removed (default is Northern Hemisphere,  in the standard, I believe. "S" can be specified?not in this case).

Is there a tool which hasn?t been changed which is 
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180513/acc39945/attachment-0001.html>