I regularly scan James Fee's great Spatially Adjusted blog for news from the ESRI side of the blogosphere. One of his favorite ideas is that ArcWeb services are equally good for web mashups as Google Maps. Besides being untrue -- SOAP is an impediment to mashups -- it's wrong-headed.

Yes, one can use the ArcWeb SOAP API to push point data to the service to be rendered onto a map and display the resulting map image in a web page, but this is not what we're talking about when we say mashup. A web map mashup, in the chicagocrime.org sense, combines data (locations, images, etc) and maps in your browser. The browser is where the mashing occurs, increasingly with the use of tools like Greasemonkey, not a GIS server.

Furthermore, a mashup begins as an unsanctioned operation or workaround for some web service that has no useful API. ArcWeb services, on the other hand, are strictly defined in order to appeal not to mashers and hackers, but to the Enterprise (managers, I mean, not the USS Enterprise). Calling the normal use of this business-suited SOAP API a "mashup" seems a bit phony, an attempt to co-opt buzz and cool.

Before the OSG conference i chatted with Cameron Shorter about using mapbuilder with ZCO. I didn't have a chance to dig into it before the conference, and once there was too busy presenting to meet the mapbuilder folks. Too many presentations was a big mistake on my part, and I really should have spent more time watching and listening and getting clued in to mapbuilder earlier. It's a rich and fairly mature AJAX library, and consumes a wide range of OGC web services. Unlike its more glamorous counterpart, ka-map, mapbuilder doesn't depend on a non-standard tile server, and runs practically right out of the box.

In very little time I was able to traverse the mapbuilder-lib source distribution and load it into Zope as a tree of folders, DTML methods, and images. After instantiating mapbuilder configuration and models as more DTML methods, and creating a page template to mount the widgets, I had my first Zope and mapbuilder demo.

The first three layers come from NASA's OnEarth, and the fourth is from a WMS service implemented using ZCO on sgillies.net. Not bad performance from the ZCO WMS, though it's certainly not under the same load as OnEarth.

I'm dedicating this release to Joe A. (DTD3315) at Dell Enterprise eSupport. Last week, after a few days of sporadic power blinks, my Dell 1800FP monitor went dead. This sent me back to my iBook for a few days. Once I figured out how to start the warranty replacement process -- forget the phone menu and go straight to email -- it all went smoothly, and a refurbished monitor landed on my doorstep in 2 days. Thanks, Joe A!

Able to use my windows box again, first thing I've done is make dumb binary and binary installer releases for PCL: PCL-0.9-win32.zip.

If you are primarily interested in PrimaGIS on win32, I recommend that you use the dumb binary (zip file) rather than the installer (exe). It can be a pain in the neck to get the installer to locate your Plone's python program, and I think it's easier to extract the zip file to some location on your filesystem (C:\PCL-0.9, say), and then edit the system PYTHONPATH environment variable to include C:\PCL-0.9\python23\Lib\site-packages. After you do this, make sure to remove any previously installed cartography package from your Plone python's site-packages.

The Geospatial industry and community responded to last year's Indonesian tsunami with an outpouring of ... flashy web maps. Let's ease up on the maps this time, and focus on the material aid and relief desperately needed by the people injured and displaced by Hurricane Katrina.

Includes SVG, GML, and connection pool bug fixes, and a patch that finally enables imageObj.getBytes() for the C# mapscript module.

http://cvs.gis.umn.edu/dist/mapserver-4.6.1.tar.gz

This morning Kai and I released PCL 0.9, ZCO 0.6, and PrimaGIS 0.4. The PrimaGIS announcement with change log and download links is at

http://www.primagis.fi/blog/primagis_0_4_0

and the ZCO and PCL announcement to the mailing list is at

http://lists.community.tummy.com/pipermail/primagis/2005-August/000089.html

The PrimaGIS demo, public face of our projects, has been updated to the current version. There are four different data backends exploited by this demo

• Filesystem (world borders shapefile)

• WMS (Landsat mosaic layer)

• WFS (MapServer users layer via my Cheapo WFS)

• Plone (Capitals and AOI layers)

The filesystem backend has been changed almost entirely for these releases. To help users make the transition, I've written a new document that walks through the process of configuring a filesystem backend for use with PCL/ZCO/PrimaGIS. Kai is making it very easy for PrimaGIS users; an installer creates the demo data stores automatically.

I'd like to thank the entire crew for their contributions!

Through Planet Python I just saw that ESRI is hiring a Python programmer to, among other things

improve the Python language as required by ESRI and its thousands of users

As opposed to the mere dozens of existing Python users? ;)

I'm really curious about what improvements are required. Hopefully this would mean improvements to the standard library rather than big changes to the core language, though as Python is used as a scripting language for geo-processing chains they may be looking at coroutines, continuations, and closure.

At any rate, here's hoping that they hire somebody who really understands Python and open source. Like Hobu :)

One more screenshot: editing a layer [fullsize]. An overview image is rendered to give users feedback on layer attributes set through the edit form. The extents of the overview image default to the bounding box of the datastore, and can be customized by setting a bbox property on the layer or its container.

In this case, we're making a Layer of a WMS request to the NASA OnEarth service. This request is for the global_mosaic layer with its default style. This could be changed through the form to other layer/style combinations such as "global_mosaic/visual".

So, what's the new ZCO release like on the inside? Here's a screenshot [fullsize] of one of our best new features: the symbolizer edit view. The color chooser offers web safe colors, but users are free to type any of the millions of colors into the form fields.

Frank Warmerdam's Geospatial Data Abstraction Library, GDAL, is a big part of the foundation of our open source GIS software stack, and the 1.3.0 release is now available for download.

This release corrects some GML parsing and spatial reference issues that I found in version 1.2.6. I'm only using a subset of GDAL's formats; there are improvements across the board. Hobu and Kevin Ruland have revised the GDAL and OGR scripting framework to make it possible to produce Java and C# bindings using SWIG. Perhaps even PHP, if SWIG support for that language improves.

Unfortunately for me, Python was the first scripting language for GDAL and its interface has a distinctly un-Pythonic feel. New language users have nothing but blue skies and can work with SWIG to make APIs with the right feel. Java users, for example, really want methods with a getFoo form rather than GetFoo for sake of consistency and clarity. This can be accomplished using SWIG's %rename directive:

%rename(getLayer) DataSource::GetLayer;

Perhaps it seems like a lot of work to some, but I guarantee that some Java user will make the time to do this. Hell, I would if I could, but there are too many legacy Python scripts out there to allow any such changes for the Python bindings. While I'm at it, I might as well wish for a pony ;)

I haven't looked at SWIG's online docs since the 1.3.23 release: when did they get so purty?