Shapely 1.0.13 released

There's a testing bug fix in 1.0.13 and we've switched to prototyping libgeos_c functions in a way that lets Shapely function in py2exe apps. I've uploaded an sdist to http://pypi.python.org/pypi/Shapely/1.0.13. Windows installer yet to come.

Comments

Re: Shapely 1.0.13 released

Author: Brian Stankiewicz

Is there any ETA for releasing the Windows Installer? Simply installing (overwriting) the python code does not seem to fix the problem with py2exe (if it can could you describe how to do it please)?

Re: Shapely 1.0.13 released

Author: Sean

I can't recommend overwriting installed Python code, so you should hold off for a bit unless you're ready to wield the setup_windows.py script. Shapely's release process is a bit asynchronous, our Windows packaging expert is probably tied up with other stuff. He's had installers for previous releases within a few days.

Re: Shapely 1.0.13 released

Author: Brian Stankiewicz

Thanks for the update ... no, I have to admit that I am not "ready to wield the setup_windows.py script" ... or at least I can hold off for a couple of days. You're doing a great job. Thanks for all of the good work on this module!

Unofficial Python GIS SIG

There was a discussion on the GIS-Python list that made me think that there ought to be a discussion group that helps developers communicate across projects, share good ideas, and generally improve Python's GIS story, much like the Python Web-SIG list does for web software developers. Please help spread word of the Unofficial Python GIS SIG.

Comments

Re: Unofficial Python GIS SIG

Author: Timmie

It's a great idea!

I added this to the OSGEO wiki at

OSGeo Python Library

Will you advertise it on the mailing list of GRASS, QGIS, gvSIG, Mapfish, featureserver/tilecache?

Keep on!

Re: Unofficial Python GIS SIG

Author: Sean

I'm not a subscriber to those particular lists and am counting on others to spread the word. The MapFish developers are on board already.

Geography of dégustation: Saint-Christol

We're finally settled enough to resume our wine tourism. Pierre Boursot took me to visit Domaine de La Coste, an AOC Coteaux du Languedoc property near Saint-Christol on a Saturday evening. I've published a KML doc with a view that shows the domaine's larger North-facing slope. The wise say that Mourvèdre, in the Languedoc, should face the sea, and so it's planted on the opposite slope. To the West is planted Grenache. From the top of Luc and Elisabeth Moynier's Villafranchian limestone hill one has great views in all directions.

They make a number of great red wines from Grenache, Syrah, and Mourvèdre. I brought home some Cuvée Prestige (Mourvèdre, Grenache) and Cuvée Merlette ("forte dominance de Mourvèdre") for some midwinter roasts. Not shown on their website is a delicious vin blanc named Lou Camp de la Qualitat, a blend of Roussane and Viognier. Pierre tells me that such nice white wines are a rarity in a region that favors reds.

I'm a sucker for dessert wines, and so I knew I would be taking away some of the Muscat before I'd even tasted it. They also bottle an interesting aperitif from Mourvèdre juice called La Carthagène. It's like a vin santo, but pink-brown, more tannin and less caramel. I hear that there's a long tradition of idiosyncratic sweet wines in the Languedoc, definitely something I'm keen to explore.

The most curious part of the visit was when Luc Moynier offered us some wine fresh from the fermenter. The grapes had been picked 3 days before and subjected to carbonic maceration, a process in which whole grapes spontaneously ferment in an oxygen-free tank. It's more frothy fruit punch than wine at this early stage. Some of this character will remain in the finished wine, which winemakers used to enjoy right after the harvest (see Beaujolais nouveau). If I understood correctly, the Moyniers are experimenting with blending this into a new cuvée.

Eric Asimov recently wrote about wines of the Languedoc in The Languedoc Raises Its Game. It overlooks the Saint-Christol area in favor of more well-known and widely distributed wines from Minervois, Saint-Chinian, Faugères, and Pic St-Loup, but is well worth reading. Of the wines he reviews, I've tried the Domaine de l'Hortus, and it is indeed excellent. The vineyards and winery itself are also spectacularly well situated between rocky cliffs on the other side of the Pic Saint-Loup. That might have to be our next dégustation daytrip.

For spork's sake no

No, Vish (who asked for criticism), no:

I am also hoping that in the near future, ESRI’s SOAP and REST API have the exact same service contracts that are just exposed at different endpoints. Currently, the SOAP API seems to more feature-filled and the REST API seems to be playing catch up. Aren’t SOAP and REST just different ways of accessing the same exact GIS feature set in ArcGIS Server? Alright, I will end the rant right here. :)

REST and RPC are different styles of solutions for different types of problems. Wanting them to be exactly the same misses the point entirely. I'll make a (admittedly Anglo-European biased) dining analogy, because it's getting to be the time of day when I'm pondering dinner: a spork is no match for a spoon when it comes to delivering soup to your mouth, and is equally ill-suited for eating a salad. The difference between spoon and fork is due to good, divergent design, not design gone wrong.

Comments

Re: For spork's sake no

Author: David

Hybrid bike anyone?

Re: For spork's sake no

Author: Sean

Good one. Nothing wrong with a hybrid bike, but two of them? Which one do you take on a long and technical single-track ride? The blue one? The red one? It seems like ESRI users might be making design choices based on similarly wrong facets.

Re: For spork's sake no

Author: bob

I disagree on the analogy, using the car example (in this case a truck example), SOAP (IMHO) is Chevy 1500 pickup and REST is a Ford F150.

Both _can_ carry the same payload, it's just up to the developer to implement it that way. Where I work we pass the same data over all of our transport interfaces. That way the non-SOAP users (typically Unix/Java/Perl groups) can get the same data as the SOAP users (typically Windows/.Net users).

Re: For spork's sake no

Author: Sean

No. My analogy was weak, but yours is completely misbegotten, bob. You're missing the point of having different architectural styles. SOAP (and other RPC) abstract away the network. You trade scalability for productivity. RPC doesn't scale out, but you can apply your familiar object-oriented and MVC practices and tools. In the REST style you trade latency -- more requests, more following of links between loosely coupled components -- and maybe even productivity (fewer fancy tools) for scalability.

NASA SPG REST and SOAP

Thanks to Benjamin Chartier, I'm finally catching up with Allan Doyle's summary of the NASA SPG's recent session on web services. Benjamin and I disagree with the architecture sketched below [1]:

http://farm3.static.flickr.com/2552/3940198525_3a24633dab_d.jpg

I like it. I don't interpret the blue border between "SOAP" and "REST" literally as my firewall, but as a horizon of trade-offs involving scalability. Outside (aka "the web") is where you, in the words of Jim Webber, trade latency for scalability. Inside is where you trade scalability for nice tools and the ease of programming with distributed objects or XML wrappers around distributed objects.

Comments

Re: NASA SPG REST and SOAP

Author: Benjamin Chartier

You're right, I misunderstood the border between SOAP and REST. Thank you for this clarification.

Benjamin

Re: NASA SPG REST and SOAP

Author: Allan Doyle

Indeed, the boundary is not the firewall. The idea is that we have to accommodate systems like ECHO that have been under construction for a long time and represent a huge sunk cost, and that we don't simply want to wrap them, but let them continue on for as long as it makes sense. When you're building a real-world system, it's often better to have points of stability than to keep chasing the latest trend.

That being said, those kinds of systems then can form the basis for adding new interfaces in ways that make them more useful beyond the internal enterprise boundary.

I think a side effect of this is that the people working on the big systems are not pushed into a defensive mode where they feel they have to spend all their energy preserving their system. Instead, they can become partners who try out new ideas and follow the ones that show the most promise.

If anyone is interested in another NASA earth science web services meeting, let me know. There's one coming up in October where I could use a speaker or two...

Reintroducing the GIS and Python Software Laboratory

Comments on a recent post make me think it's time to reintroduce the GIS and Python Software Laboratory. It's a fairly pretentious name for what's little more than a wiki, an issue tracker, a couple of subversion repositories, and a few mailing lists, but a name that describes well what we're doing: experimenting with bringing GIS to the C Python platform, and bringing Python programming idioms and distribution mechanisms to GIS software. We're designing better APIs that feel natural to a Python programmer. We're designing interoperability around Python protocols. We're designing software that can deployed in the standard Python fashion, and also with new tools like virtualenv and pip. Software that's modular, letting users pay only for what they eat.

Using the same dining metaphor, the lab proposes to you the following a la carte menu:

  • Geojson: implementation of the GeoJSON 1.0 spec
  • OWSLib: making W*S suck less
  • Quadtree: quad-tree index for spatial data
  • Rtree: R*-tree indexes for spatial data
  • Shapely: easy access to the GEOS spatial primitives
  • WorldMill: easy access to vector data using OGR

Mix and match. Hack. Build your own stacks, or stack-busting apps. For projections see pyproj. Subscribing to a similar philosophy, it fits well with the GIS-Python packages.

Updates to the Shapely roadmap

Speaking of great Python packages for geoprocessing: the Shapely roadmap has updates. Version 1.0.13 will allow shapely to be imported in py2exe apps. The work on a framework for use of geometry engines other than GEOS that I'd been calling 1.1 is now raised to 2.0. Use of prepared geometries and the re-entrant geos_c API in GEOS 3.1 is planned for Shapely 1.2.0.

Redefining open source?

Is there more to open source than an OSI license? I enjoyed reading Ian Bicking's DjangoCon keynote. By chance, it's coincident with a big press release about (future) open source from TomTom, which adds interesting context to his some of his remarks. Open source watchers should read this: it's a great personal reflection on open source that doesn't push the usual hot buttons.