Opened 3 years ago

Closed 3 years ago

#2546 closed defect (fixed)

GeoJSON with string coordinates parses incorrectly instead of throwing error

Reported by: crschmidt Owned by: pramsey
Priority: medium Milestone:
Component: postgis Version: 2.0.x
Keywords: Cc: Tim.Bunce@…


SELECT ST_AsText(ST_GeomFromGeoJSON('{"type":"Point","coordinates":[-48.23456,20.12345]}')) returns POINT(-48.23456 20.12345)

SELECT ST_AsText(ST_GeomFromGeoJSON('{"type":"Point","coordinates":["-48.23456","20.12345"]}')) returns POINT(-48 20)

Although the data in the second example is *wrong* -- coordinates shouldn't be enclosed in strings -- it seems an odd choice to truncate the values instead of just reporting an error back to the user. (I think parsing them as floats would also be reasonable, but I wouldn't say it's at all a requirement.)

This was brought up by timbunce in the GeoJSON channel; he had a login issue so I am reporting on his behalf.

POSTGIS="2.0.3 r11128" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.6" LIBJSON="UNKNOWN"

Adding on Tim's behalf as well (I personally disagree): "< timbunce_> Please add a note to the case that supporting coords in string form would make life a lot easier for people working in dynamically typed languages where the string/number distinction is subtle."

Change History (8)

comment:1 Changed 3 years ago by crschmidt

The CC line here is busted, if someone with ticket edit privileges could fix it, I'd appreciate it. (It looks like I can't.)

comment:2 Changed 3 years ago by robe

Cc: Tim.Bunce@… added; Tim.Bunce@… 6 March 2012" LIBXML="2.7.6" LIBJSON="UNKNOWN" removed

not sure how that happened. cc should be fixed now.

comment:3 Changed 3 years ago by robe

Cc: Tim.Bunce@… added; Tim.Bunce@… removed

comment:4 Changed 3 years ago by robe

Cc: Tim.Bunce@… added; Tim.Bunce@… removed

comment:5 Changed 3 years ago by kashif

If no one has fixed this I will fix it now. I think I will raise an exception if the coordinate array does not have numbers? That conforms to the geojson spec. Is that ok?


comment:7 Changed 3 years ago by timbunce

(I replied to the email notification but I'm not sure if that'll appear here automatically. If it does please accept my apologies for the duplication.)

I've created an alternative fix as a pull request:

It's simpler, faster, and avoids reusing the type of the first coord when processing the later coords. This isn't needed as json_object_get_double() automatically coerces types.

comment:8 Changed 3 years ago by pramsey

Resolution: fixed
Status: newclosed

Applied in 2.1 at r12303 and trunk at r12302, thanks!

Note: See TracTickets for help on using tickets.