Tilt!
Placebase's Pushpin API provides a format they call "GeoJSON", which should be good except that it has the wrong coordinate order. Easting and northing are swapped and the data is therefore tilted over, which is bad. See for example
http://rest.beta.pushpin.com/states/CA/counties/alameda.js
The sooner this gets fixed, the better for all of us. Anybody got a line to Placebase?
Update (2008-05-24): The Pushpin response is fixed. I'm excited to see GeoJSON catching on like this.
Comments
Re: Tilt!
Author: jaron
hey Sean- thanks for bringing this up- and thanks to Tim@UM for letting us know .. We're going to get it right and re-release, we'll post again when it's correct. We should have looked at the draft spec more carefully... apologies, we'll get it right...Re: Tilt!
Author: Sean
Excellent! Thanks, Jaron.Re: Tilt!
Author: Matt Priour
I think there is still confusion over the proper coordinate order when you actually specify a crs of EPSG:4326 (ie WGS84, Decimal Degrees with Lat Lon order). I got this snippet from the latest trunk version of Feature Server when I pointed it to a shapefile with a specified (not implied) CRS of EPSG:4326.{"features": [{"geometry": {"type": "Point", "coordinates": [[29.975341, -90.226626]]}, "id": 0, "properties": {...}},...]}You will notice the Y, X coordinate order which seems like it is against spec, but since I specified a CRS which uses that Y,X coordinate order, it could be right. I was personally +1 for the optional Coordinate Order element proposal for the GeoJSON spec, but I was clearly in the minority.Re: Tilt!
Author: Christopher Schmidt
Matt: I don't know what version of FeatureServer you're using, but that is definitely wrong. Can you share your shapefile? To me, it looks like it's buggy data; I've never seen OGR give Y,X ordering, which it looks like you're getting, so I'd like to understand how to know when it's happening and fix it.Re: Tilt!
Author: Matt Priour
@Christopher I looked at my files and you are right. It is the shapefile itself that is wrong. It was created using OGR2OGR with a csv text file and a VRT file. The VRT file incorrectly identified the x & y columns: So of course, the GeoJSON coordinates are sent in the wrong order. If I had tried to use a BBOX on this dataset, I would have certainly gotten incorrect results.Re: Tilt!
Author: Christopher Schmidt
Garbage In, Garbage Out. Bad data begets bad data.Re: Tilt!
Author: iwei
We've fixed the GeoJSON formatting by reversing the coordinates (applies to our KML version too). Sorry for the inconvenience and thanks for the catch!