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