W3C home > Mailing lists > Public > public-sdw-wg@w3.org > June 2015

RE: Best Practice for encoding spatial coverage

From: Svensson, Lars <L.Svensson@dnb.de>
Date: Wed, 24 Jun 2015 12:56:10 +0000
To: Clemens Portele <portele@interactive-instruments.de>
Cc: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, "Frans. Knibbe@Geodan. Nl" <frans.knibbe@geodan.nl>, "Mcgibbney, Lewis J (398M)" <Lewis.J.Mcgibbney@jpl.nasa.gov>, SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <24637769D123E644A105A0AF0E1F92EF010D0949FA@dnbf-ex1.AD.DDB.DE>
Clemens,

On Friday, June 19, 2015 6:02 PM, Clemens Portele wrote:

> the new WKT for CRS (ISO 19162 or http://docs.opengeospatial.org/is/12-

> 063r5/12-063r5.html) is a lot clearer on this than the Geometry WKT specs
> were. I expect that future revisions of the Geometry WKT will follow the same
> rules, too.
> 
> Case sensitivity: http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#18

> Whitespace in WKT: http://docs.opengeospatial.org/is/12-063r5/12-

> 063r5.html#138
> Whitespace in the BNF: http://docs.opengeospatial.org/is/12-063r5/12-

> 063r5.html#7

Thanks for the pointers. Yes the text is very much clearer than the old one. My point  is however, that I'd like to see those restrictions also in the BNF. My use case is that I want to create a WKT parser just by feeding the BNF into a compiler-compiler and then have the constructed parser de-compose a WKT string into its constituting parts. This means that *all* parts of the grammar need to be in the BNF, including handling of whitespace and upper/lower case. Otherwise I need either to pre- or post-process the WKT before/after it's handled by the parser by calling string.toLowerCase().trim() in order to figure out if "PoInT" is a valid geometry name.

Looking, for instance, at the syntax of "coordinate system" (§7.5.1) [1], it says

<axis> ::= <axis keyword> <left delimiter>  <axis nameAbbrev> <wkt separator> <axis direction> [ <wkt separator> <axis order> ] [ <wkt separator> <axis unit> ] [ { <wkt separator> <identifier> } ]…  <right delimiter> !! See 7.5.3, 7.5.4 and 7.5.5 for constraints   

The constraints should be part of the BNF.

Finally two nitpicks on the document:

1) In order to get the fragment IDs to work properly the page requires me to enable JavaScript. Why?
2) Minor typo in §6.5: s/ofquoted/of quoted/ [2]

[1] http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#37

[2] http://docs.opengeospatial.org/is/12-063r5/12-063r5.html#18


Best,

Lars
 
> > On 19 Jun 2015, at 17:45, Svensson, Lars <L.Svensson@dnb.de> wrote:
> >
> > Andrea,
> >
> > Sorry, but I can't resist a comment on WKT:
> >
> >> - it is case and "space" insensitive - i.e., all the following
> >> variants are valid: " point(0 0)" "PoinT ( 0  0)", " POINT(0  0 )  "
> >
> > The specification of WKT in SFA [1] says _in the text_ that " Well known text is
> case insensitive." (§ 7.2.1). The BNF does not reflect this though. E. g. for
> "point" it states
> >
> > <point tagged text> ::= point <point text>
> >
> > Further, the specification say nothing at all about whitespace when defining a
> point:
> >
> > <point text> ::= <empty set> | <left paren> <point> <right paren>
> > <point> ::= <x> <y>
> > <x> ::= <signed numeric literal>
> > <y> ::= <signed numeric literal>
> > <signed numeric literal> ::= {<sign>}<unsigned numeric literal>
> > <unsigned numeric literal> ::= <exact numeric literal>
> > 				|<approximate numeric literal>
> > <exact numeric literal> ::= <unsigned integer>
> > 				{<decimal point>{<unsigned integer>}}
> > 				|<decimal point><unsigned integer>
> > <approximate numeric literal> ::= <mantissa>E<exponent>
> > <mantissa> ::= <exact numeric literal>
> > <exponent> ::= <signed integer>
> > <signed integer> ::= {<sign>}<unsigned integer>
> > <unsigned integer> ::= (<digit>)*
> >
> > I stumbled over this when I tried to use the BNF to create a validator for
> WKT...
> >
> > [1] http://portal.opengeospatial.org/files/?artifact_id=25355

> >
> > Best,
> >
> > Lars

Received on Wednesday, 24 June 2015 12:56:40 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:17 UTC