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.
Author: Timmie
It's a great idea!
I added this to the OSGEO wiki at
OSGeo Python LibraryWill you advertise it on the mailing list of GRASS, QGIS, gvSIG, Mapfish, featureserver/tilecache?
Keep on!
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.
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.
The new Inscriptions of Roman Tripolitania (2009) website has a neat KML-based map. I like the subtle use of multiple hand-drawn map overlays and the nifty (Google standard, I now realize) icons. Great work, Hafed and Gabby.
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.
Author: David
Hybrid bike anyone?
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.
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).
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.
Via Volker Mische, I'm pleased to see that GeoCouch is using Shapely.
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]:
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.
Author: Benjamin Chartier
You're right, I misunderstood the border between SOAP and REST. Thank you for this clarification.
Benjamin
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...
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.
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!