GeoJSON with string coordinates parses incorrectly instead of throwing error

[crschmidt]

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."

[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.)

[robe]

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

[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?

thanks!

[kashif]

​https://github.com/kashif/postgis/commit/3ad2be5d948f673b50288c38605bd1164b101019

has the fix for you to kindly review. You can get the diff from:

​https://github.com/kashif/postgis/commit/3ad2be5d948f673b50288c38605bd1164b101019.diff

thanks!

[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: ​https://github.com/postgis/postgis/pull/15

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.

[pramsey]

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