The WKT reader in OGR does not recognize comma as a decimal point

[Ari Jolma]

As this simple test shows:

use Geo::GDAL;
$g = Geo::OGR::Geometry->new(undef, "POINT(1,3 2,4)");

OGR reports the WKT as corrupt data because of comma used as a decimal point.

WKT is defined in OGC simple features document, where decimal point is defined as:

<decimal point> ::= <period> | <comma>

I guess the ReadPoints in ogrutils.cpp should be changed to accept commas as decimal points.

[Ari Jolma]

Hmm, the comma seems to be allowed only in the candidate implementation specification (06-103r3). The OpenGIS specification (05-126) does not specify what a "double precision literal" is.

Anyway this might be noted somewhere as it may bite people in countries where comma is the official decimal point (as me :)

[warmerdam]

Ari,

Any idea how commas for decimal points would work in LINESTRING() where comma is used to separate tuples? I do have code that will support parsing numeric values with either commas or periods for the decimal point, but I don't see how we can support this widely in WKT parsing.

[Ari Jolma]

In the candidate specification, as I read the BNF of WKT, the number of coordinates that makes a point is always known (point is 2, point z is 3 etc.).

Maybe write a scanner with flex for WKT? Anyway, I don't think this is very urgent, but worth looking at when the candidate specification gets adopted more.

[warmerdam]

POINT Z? I am getting the impression you are looking at the new simple features specification - is that the case? Certainly OGR does not yet claim to support it and we will still have the "issue" of having to work gracefully with old WKT extensions such as the traditional form for 3D geometries.

[Ari Jolma]

Yes, see above in my first comment. The (now deprecated) specification is not very exact, but the new (candidate) is and it specifies point z, point m and point zm for example besides commas as decimal points.

[Jukka Rahkonen]

I checked that current standard version 1.2.1 (06-103r4) "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture" ​http://portal.opengeospatial.org/files/?artifact_id=25355 does really have <decimal point> ::= <period> | <comma>

[Jukka Rahkonen]

Would somebody to consider it bad to close this one as wontfix? It seems to be sure that according to the standard version 1.2.1 both period and comma should be accepted. However:

• During all these years there has been very few complaints about missing support for decimal commas
• I checked that JTS does not accept commas either and I have not seen complaints about this behaviour.
• I have a strong feeling that starting to support commas, even a right thing according to the standard, would make much more damage than anything good.

[Even Rouault]

As said by Frank, can't see how we could accept comma as decimal separtor in LINESTRING, POLYGON, etc... as it would be confused with the tuple separator