2008 (old posts, page 12)

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:
<GeometryField encoding="PointFromColumns" x="bg_lat" y="bg_long">
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!

Shapely 1.0.5

Shapely 1.0.5 now includes a flexible polygonizer documented in section 2.5.1 of the updated manual, and makes it harder to create a particular class of broken geometries.

Dark Matter of the "GeoWeb"

Hanke wasn't referring just to ESRI silos, but also to the data stuck behind WMS and GetFeatureInfo(), WFS and GetFeature().

Comments

Re: Dark Matter of the "GeoWeb"

Author: James Fee

It just looks better to have Jack up on stage with him than a freetard.

Shapely Debs

I'm a big fan of the Debian GIS Project and pleased to see that Shapely is getting some of its attention. Meanwhile, I'm still building GEOS 3.0 from source (with Kai's hexagonit.recipe.cmmi) because Hardy is still at GEOS 2.2.3.

Line Simplification

I just want to point out how well Schuyler Erle's implementation of Douglas-Peucker line simplification plays with Shapely.

>>> from shapely.geometry import Point
>>> point = Point(0.0, 0.0)
>>> outline = point.buffer(2.0, quadsegs=32).boundary
>>> coords = list(outline.coords)
>>> from dp import simplify_points
>>> simple_coords = simplify_points(coords, 0.25)
>>> from shapely.geometry import LineString
>>> simple_outline = LineString(simple_coords)
>>> outline.length
12.565109003731115
>>> simple_outline.length
12.245869835682875

The simplify_points function requires a sequence of coordinate tuples. The coords property of a Shapely geometry is an iterator over coordinate tuples, but you can make a sequence from the iterator by using Python's built in list function.

>>> from numpy import asarray
>>> from matplotlib import pylab
>>> a = asarray(outline)
>>> fig = pylab.figure(1, figsize=(5,5), dpi=72)
>>> pylab.show()
>>> pylab.plot(a[:,0], a[:,1])
[<matplotlib.lines.Line2D instance at 0x8ae7d8c>]
>>> b = asarray(simple_outline)
>>> pylab.plot(b[:,0], b[:,1])
[<matplotlib.lines.Line2D instance at 0x90bc86c>]

The original:

http://sgillies.net/images/outline.png

And simplified:

http://sgillies.net/images/simple-outline.png

The Programming Historian

The Programming Historian looks great to me. It covers HTML parsing (with Beautiful Soup), regular expressions, Unicode, and link traversing, with more to come.

Via the author, Bill Turkel.

Comments

Re: The Programming Historian

Author: William J. Turkel

Sean, thanks for the plug. Feedback and requests are welcome. We hope to include some geo- stuff at some point in the future, probably starting with a simple bibliographic map mashup. But who knows? We may get to automatically extracting toponyms from texts. Bill

Shapely 1.0.4

One bug fix and a simple GEOS geometry cache to improve performance when wrapping coordinate data stored outside of Shapely. http://pypi.python.org/pypi/Shapely/1.0.4.

In comments on a post about Javascript geometries, Paul Ramsey and Martin Davis wondered about a pure Python version of JTS. It might be an interesting project, and maybe you could coax reasonable performance out of it with psyco or Cython, but it wouldn't perform as well as something based on C (for C Python) or Java (for Jython) or C# (for IronPython). Consider Ian Bicking's HTML parsing benchmarks: lxml, based on libxml2, is far faster than anything else. The need to calculate spatial operations in C rather than Python is greater yet.

If Google would provide some basic spatial indexing (for App Engine), you could try to go the rest of the distance with the help of an external web geoprocessing service. You might not need a PyTS after all.

Comments

Re: Shapely 1.0.4

Author: Martin Davis

Sean, you must have been reading my mind. I was going to email you and ask if you thought there was any need for a pure Python port of JTS. I guess I'm not surprised to hear that a PyTS wouldn't have the performance of JTS or GEOS. On the other hand, there are lots of times where what is needed is functionality, and performance is a secondary concern. Perhaps the input data is small or well-bounded, or there aren't tight requirements on response time. (Human-facing spatial apps often fit this profile). So I'm not convinced that there wouldn't be an audience for PyTS. Any interest in exploring what it would take and how it might happen?

Re: Shapely 1.0.4

Author: Sean

Send me that email, Martin.

Keytree

Keytree (also known as pleiades.keytree in our repository) is a simple package of ElementTree helpers for parsing KML. I needed it, didn't see anything else like it out there, and put in a little extra work to make it more generally useful. If you're already using ElementTree and are curious, give it a try. It plays well with Shapely, of course:

>>> from xml.etree import ElementTree
>>> tree = ElementTree.parse(open('archaic.kml', 'rb'))
>>> kmlns = tree.getroot().tag.split('}')[0][1:]
>>> placemarks = tree.findall('*/{%s}Placemark' % kmlns)
>>> p0 = placemarks[0]
>>> import keytree
>>> f = keytree.feature(p0)
>>> from shapely.geometry import asShape
>>> shape = asShape(f.geometry)
>>> shape.wkt
'POINT (21.9725000000000001 32.8962999999999965)'

Keytree parses out points, line strings, and polygons, but not yet geometry collections. I'll make a real release of it after I get a chance to work on compatibility with lxml.

Comments

Re: Keytree

Author: Matt Priour

>>> from xml.etree import ElementTree >>> tree = ElementTree.parse(open('archaic.kml', 'rb')) >>> kmlns = tree.getroot().tag.split('}')[0][1:] >>> placemarks = tree.findall('*/{%s}Placemark' % kmlns) >>> p0 = placemarks[0]
Is it possible to have keytree just automatically do the kmlns & placemarks operations you have done here? It seems that is keytree is for KML then it should automatically know those 2 things and they could be implemented as helper/convience(sic) functions rather than always having to manually do that everytime you want to start working with KML feature extraction/import.

Re: Keytree

Author: Sean

Indeed. If KML docs were constrained to a Document/Folder/Placemark structure, I would use the WorldMill model. But KML is more loosely structured than that -- you can have folders of folders, and placemarks and folders as siblings -- and for now I'm leaving the how of getting Placemark elements up to the user (me, for all I know).