Opened 17 years ago

Closed 9 years ago

#1805 closed defect (wontfix)

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

Reported by: Ari Jolma Owned by: warmerdam
Priority: normal Milestone:
Component: OGR_SF Version: unspecified
Severity: normal Keywords:


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.

Change History (8)

comment:1 by Ari Jolma, 17 years ago

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 :)

comment:2 by warmerdam, 17 years ago


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.

comment:3 by Ari Jolma, 17 years ago

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.

comment:4 by warmerdam, 17 years ago

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.

comment:5 by Ari Jolma, 17 years ago

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.

comment:6 by Jukka Rahkonen, 10 years ago

I checked that current standard version 1.2.1 (06-103r4) "OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture" does really have <decimal point> ::= <period> | <comma>

comment:7 by Jukka Rahkonen, 9 years ago

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.

comment:8 by Even Rouault, 9 years ago

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.