Ticket #2546 (closed defect: fixed)

Opened 13 months ago

Last modified 10 months ago

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@…

Description

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

Changed 13 months 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.)

Changed 13 months 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.

Changed 13 months ago by robe

  • cc Tim.Bunce@… added; Tim.Bunce@… removed

Changed 13 months ago by robe

  • cc Tim.Bunce@… added; Tim.Bunce@… removed

Changed 13 months 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?

thanks!

Changed 13 months 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:  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.

Changed 10 months ago by pramsey

  • status changed from new to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.