1

After reviewing this thread Adding field with geometry in WKT format in QGIS I started to wonder about the difference between the WKT notations: 'POINT(276547.16725324 5477265.87268898)' and 'Point (276547.16725324 5477265.87268898)' of the same vector geometry object. Is there any difference between them two?

The same applies also to 'LINESTRING()' and 'LineString ()', 'POLYGON(())' and 'Polygon (())'.

I have seen some related threads:

Until now IMHO it seems to be more a software issue, rather than a dispute between Semantics and Syntax.

Taras
  • 32,823
  • 4
  • 66
  • 137
  • 1
    Technically, "Point" isn't a proper keyword, but it would be foolish as a developer to do case-sensitive comparison. – Vince Nov 10 '21 at 12:47
  • 2
    @Vince I think the specs explicitly declare the geometry tags to be case insensitive, and I believe they actually mention PascalCase for readability. Anyhow, there is no difference; WKT get's serialized by geometry type specific pattern matches with a set of tokens; simply put, the <geometry_type> tag preceeds a list of tokens (e.g. list of rings | list of coordinate pairs) that are enclosed in (multiple levels of) parenthesis. Whitespaces are only considered as part of a pattern when between a set of coordinates. – geozelot Nov 10 '21 at 13:09
  • 1
    Well, there isn't just one WKT parser in all of creation, and plenty of room to debate whether Point (0 1) and POINT (0.0 1.0) and MULTIPOINT ((0 1)) are all equivalent. But this seems more appropriate in Reddit than GIS SE. – Vince Nov 10 '21 at 13:21

1 Answers1

2

The structure of WKT was originally defined in the standard OpenGIS® Implementation Standard for Geographic information - Simple feature access - Part 1: Common architecture https://portal.ogc.org/files/?artifact_id=13227. The current version of the standard is https://portal.ogc.org/files/?artifact_id=25355 and that is used as reference below.

EDIT

Excerpt from 7.2.1 BNF Introduction (bolding added):

The text representation of the instantiable Geometry Types implemented shall conform to this grammar. Well known text is case insensitive. Where human readability is important (as in the examples in this standard), an “upper camel-case” where each embedded word is capitalized, should be used

One can also try to interpret the BNF definition. In WKT geometry names point, linestring etc. are "names". "Name" is made of "letters", "letters" are made of "simple Latin Letters", which are made from a set of small case and upper case letters.

<name> ::= <letters>
<letters> ::= (<letter>)*
<letter> ::= <simple Latin letter>|<digit>|<special>
<simple Latin letter> ::= <simple Latin upper case letter>
|<simple Latin lower case letter>

<simple Latin lower case
letter> ::=
a|b|c|d|e|f|g|h|i|j|k|l|m
|n|o|p|q|r|s|t|u|v|w|x|y|z


<simple Latin upper case
letter> ::=
A|B|C|D|E|F|G|H|I|J|K|L|M
|N|O|P|Q|R|S|T|U|V|W|X|Y|Z

Thus Point and POINT are both OK, and nothing wrong with poinT either.

user30184
  • 65,331
  • 4
  • 65
  • 118
  • 1
    The <name> definition doesn't seem applicable to WKT, since while 'qweRtyAsdF' is a valid name, it isn't a valid geometry type. In 6.2.2 (p. 28) it states that <Point Tagged Text> := POINT <Point Text>, where <Point Text> := EMPTY | ( <Point> ), <Point> is <x> <y>, and <x> and <y> are " double precision literal" values. It doesn't state that "POINT" is (P|p)(O|o)(I|i)(N|n)(T|t), so there's room for trouble. But I wouldn't reject poinT either. – Vince Nov 10 '21 at 16:11
  • 1
    Any help with interpreting BNF is welcome, but I think that "point" within Point Text refers to 0-dimensional geometrin object and not to any character string. But this sentence in 7.2.1 is rather easy to interpret: The text representation of the instantiable Geometry Types implemented shall conform to this grammar. Well known text is case insensitive. Where human readability is important (as in the examples in this standard), an “upper camel-case” where each embedded word is capitalized, should be used – user30184 Nov 10 '21 at 20:01
  • 1
    The examples in the linked document are all UPPERCASE in that section (6.2.3); it would have been nice if the case insensitivity of WKT was mentioned in 6.2, where WKT was defined, and included in the examples, as well. – Vince Nov 11 '21 at 05:14
  • 1
    @vince, I wrote only a link to the original OGC-SF standard to my answer but I was reading the current version of the standard myself. I added now also this link https://portal.ogc.org/files/?artifact_id=25355. Table 6 in the current version has examples like MultiLineString ((10 10, 20 20), (15 15, 30 15)). – user30184 Nov 11 '21 at 09:44
  • 2
    Okay, so the original standard and examples were all uppercase and the current specification, copyrighted 10+ years after I wrote my first case-insensitive parser, is now explicitly case-insensitive. So the real difference between POINT and Point is when the export function that generated the WKT was written. – Vince Nov 11 '21 at 12:09