Talk:Well-known text representation of geometry

Misleading Link

Linestring has a link to the Wikipedia article on Line Segment. This would confuse some people. A Linestring is a compact notation of multiple consecutive line segments, not a line segment. — Preceding unsigned comment added by ChrisLit (talk • contribs) 23:23, 19 March 2020 (UTC)

Updated to more appropriate Polygonal chain link (as was done elsewhere in article). +mt 00:17, 20 March 2020 (UTC)

Broken Link

The link in References for "Well-Known Text (WKT) Format, MySQL documentation" https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-format.html no longer leads to the format document. Perhaps it should be http://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html#gis-wkt-format — Preceding unsigned comment added by 2601:9:640:5C:553B:B62C:6C1:9AB6 (talk) 16:00, 23 September 2014 (UTC)

MULTIPOINT example is incorrect

There have been numerous attempts to fix the incorrect MULTIPOINT:

MULTIPOINT (10 40, 40 30, 20 20, 30 10)

All attempts have been reverted! Why?

It is not valid according the OGC specs:

1) OGC 05-126 Version: 1.1.0

<MultiPoint Tagged Text> := MULTIPOINT <Multipoint Text>
<Multipoint Text> := EMPTY | ( <Point Text > {, <Point Text > }* )
<Point Text> := EMPTY | ( <Point> )
<Point> := <x> <y>

2) OGC 06-103 Version: 1.2.[0-1]

<multipoint tagged text> ::= multipoint <multipoint text>
<multipoint text> ::= <empty set>
        | <left paren> <point text> {<comma> <point text>}* <right paren>
<point text> ::= <empty set> | <left paren> <point> <right paren>
<point> ::= <x> <y>

Related discussion on PostGIS mailing list: WKT form(s) of MULTIPOINT

--Mloskot (talk) 16:00, 4 December 2013 (UTC)

Both forms are presented in the example, but there should be a footnote to identify which one is described in the standards (OpenGIS, then OGC, then SQL/MM). The other form (without excessive parenthesis) is very common among various software, so I wouldn't suggest it is "incorrect". +mt 19:31, 5 December 2013 (UTC)

Well-Known Text (WKT) is a name of format forged by OGC, not some general term for parenthesis-wrapped tagged lists of coordinates. The fact that some software handle degenerate form of format is no reason to display it in the article devoted to OGC Well-Known Text. Any non-standard implementation-specific variant should be simple removed or moved to dedicated section clearly labelled as non-standard behaviours. The history why degenerate form is supported, like in PostGIS, is quite funny and due to bug in examples of the early version of specification document. So, the degenerate MULTIPOINT form as presented is incorrect, there should be no doubt. --Mloskot (talk) 14:31, 9 December 2013 (UTC)

TIN example is incorrect

According to OGC SFS 1.2+, the current example

TIN (((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)))

should read, either

TIN Z (((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)))

or

TIN (((0 0, 0 0, 0 1, 0 0)), ((0 0, 0 1, 1 1, 0 0)))

APIs that provide support - Esri Geometry API for Java

For "APIs that provide support", the Esri Geometry API for Java supports WKT for import and export. Disclosure: collaborator. -- Randall Whitman 198.102.62.250 (talk) 17:10, 23 September 2015 (UTC)

Done. +mt 19:27, 23 September 2015 (UTC)

POLYHEDRALSURFACE Patches?

The PolyhedralSurface example contains the word PATCHES that I am not seeing when looking at some of the WKT syntax diagrams I have found online. Is "PATCHES" part of the standard or is that a mistake? 204.115.183.4 (talk) 21:42, 13 May 2018 (UTC)

ISO 13249-3 http://jtc1sc32.org/doc/N2501-2550/32N2538-text-for-ballot-5CD2-13249-3.pdf

<polyhedralsurface text> ::= <empty set> | <left paren> PATCHES <polygonpatches text> <right paren>

Split into two articles?

I'm considering splitting this article into two parts: (1) Well-known text/binary representation of geometry (described by Simple feature access), and (2) Well-known text representation of coordinate reference systems. (I'm not sure what the article titles should be yet; suggestions welcome). These are distinct topics, each with their own varying software support. Presently, most of the content in this article concerns the representation of geometry. The representation of coordinate reference systems is incomplete, as it primarily describes what is now called WKT1, and is lacking content on the more recent WTK2 forms. Thoughts? +mt 20:31, 9 January 2019 (UTC)

OK, here's a preliminary plan. Move this article to Well-known text representation of geometry, and split the CRS-related content to Well-known text representation of coordinate reference systems. There are many external links to Well-known text (e.g. [1] [2]), so either keep this as a redirect to the geometry article (preferred), or create a two-entry disambiguation article to help the external reader. Any thoughts? +mt 22:01, 15 January 2019 (UTC)

Moves and splitting most content is done. Redirects for well-known text point to the representation of geometry article. Software support in this article may need to be revised/sourced. +mt 03:53, 28 January 2019 (UTC)

Simple Feature Access elements not expressed in WKT

This edit reverted my corrections to the feature list. I have re-reverted it. The listed features that I reverted do not occur in the WKT portion of the specification. In fact, many of them are listed in Section 8.2.3 as not in use even as OGC geometric elements (let alone WKT): To keep these codes in synchrony and to reserve sections for future use, we define a list here for all geometric object types in this standard or planned for future releases. The shaded codes in the table below are for future use and do not reflect types used here. A few of them are in use but not incorporated into WKT. Please examine the WKT portion of the specification, starting 7.2.1. Strebe (talk) 04:07, 4 February 2019 (UTC)