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.

Improve this question
3
  • 1
    Technically, "Point" isn't a proper keyword, but it would be foolish as a developer to do case-sensitive comparison.
    – Vince
    Commented Nov 10, 2021 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
    Commented Nov 10, 2021 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
    Commented Nov 10, 2021 at 13:21

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 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
    Commented Nov 10, 2021 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
    Commented Nov 10, 2021 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
    Commented Nov 11, 2021 at 5: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 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
    Commented Nov 11, 2021 at 9: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
    Commented Nov 11, 2021 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.