Props to ArcMap

/images/tvulgare-sm.png

I just finished making a map of Tanacetum vulgare (Common Tansey) incidence for a visiting ecologist. I learned to do this kind of task with ArcView 3 back in the previous century, but left the data processing and analysis business before my employer upgraded. This means I never really tried out ArcMap until now. I must say that it's perfectly adequate for this kind of task, allowing me to add a new attribute to features and hack away at the attribute table using search and replace. A scriptable interface to the symbolization would be nice, but the provided tools are not too bad. Everything I remembered about good ole ArcView 3.2 seemed to transfer right over to use of ArcMap 9.1. The whole thing, not including the time to find and download decent data (North American Framework from GeoGratis) took about 20 minutes. There's no greater message to this story, I just feel that I owe the blogosphere a report of a good experience I've had with proprietary GIS software.

SDI in a Box

There's an accurate, well-written article on geospatial open source by Christopher J. Andrews in Directions Magazine. In the last paragraph, Andrews writes.

With the liberal licensing on some geospatial OSS, I hope an industrious company will develop a 'map server in a box' appliance. Such an appliance, coupled with a basic methodology to package up an organization's available data, would greatly accelerate the adoption of geospatial OSS and further decrease the TCO for geospatial open source.

People having been talking about mapservers or spatial data infrastructures in a box for a while. It's bound to happen any day now, but almost certainly without the box, instead using "elastic" arrays of virtual machines.

Comments

Re: SDI in a Box

Author: Allan

Three relevant papers from FOSS4G: GDIdevl - running a GDI Lin-on-Win Geospatial Virtual Appliance - MapSnack How to fit 5 Kilos of Software into a 1.3 Kilo Box See what you missed? And that's not all!

How to Explain Metadata

No, no, no. As as cook and programmer, I must object. The only analogy that works is ingredients == data. In this case metadata is the well known extra information on the packaging: serving size, nutritional guidance, organic or not, country of origin, year of production, appellation, etc.

Comments

Re: How to Explain Metadata

Author: Jason Birch

Hmm. You must have created a /. effect on that site... A recipe is metadata, documenting the data sources and methods which were used to derive the product :) Jason

Re: How to Explain Metadata

Author: Sean

You're right, Jason. One man's data ...

Re: How to Explain Metadata

Author: Jason Birch

...is another man's gnocchi?

Java Freed

Java is free. Open source GIS folks should read and think about Bray's -- and he's not a Free Software zealot -- common sense arguments for the GPL.

Comments

Re: Java Freed

Author: Steven Citron-Pousty

Hey Sean: glad to see that you will now be using Java - I mean now that it is GPL'ed what complaint could be left ;)

primagis.buildout

Kai and I attended Chris McDonough's talk on buildouts -- in general, not specifically about zc.buildout -- at the Plone Conference. I left motivated to start thinking about buildouts. Kai left motivated to do something about common environments for developing PrimaGIS. His solution is primagis.buildout: a script for making complete, isolated PrimaGIS sandboxes. So far, it's only tested on OS X, Debian, and Ubuntu, but already has several new users up and running. For windows, I imagine we could use more binaries, and try to tap into Howard Butler's build kit for PCL-GDAL and PCL-MapServer.

Tests for Goodness' Sake

Dear PyWPS and TileCache,

You know what would impress more than a 1.0 tag? Tests. If it's worth building, it's worth testing. Testing Python is easy, even fun. Ask me how.

Best regards,

The Test Nut

Update: TileCache's HACKING file does serve as a doctest file.

Comments

Re: Tests for Goodness' Sake

Author: Christopher Schmidt

cd tilecache-1.0 python >>> import doctest >>> doctest.testfile("HACKING") UserWarning() (0,20) >>> TileCache has tests, they're just not obvious. I don't think they need to be (although I believe Schuyler disagrees): So long as I consider it my personal responsibility to maintain the TileCache code, it's my responsibility to make sure it does what it says on the tin, which means the tests are important to me, and not to you. I'd love to hear why you feel otherwise.

Re: Tests for Goodness' Sake

Author: Sean

I simply didn't find your tests. You've got a well-earned reputation for making cool software, but I think you'll find that adding obvious tests will get you even more attention and contributions from savvy users.

Re: Tests for Goodness' Sake

Author: Christopher Schmidt

But you still haven't answered the question: "Why do you need my tests?" OpenLayers has public tests: 905+ of them. They're runnable on the web (http://openlayers.org/dev/tests/run-tests.html), they're using an Open Source testing framework, and they're required for inclusion of new features into the codebase. OpenLayers is an Open Development project. TileCache is an *open source* project, but not an Open Development one. Given a good patch, it would likely be integrated, but (unless I'm sorely mistaken as to the niche this fills), it will never be an Open Development project. There is no public SVN repository. There are no non-MC committers. I can't imagine there ever being a reason for there to be: it's 500 lines of code. There's very little reason to bother committing a patch back, because there's so little to patch that wouldn't mean adding a layer of complexity or four. Tests for open development projects are absolutely essential. Tests for Open Source projects which are not open development don't neccesarily help anyone. If I'm going to check your patch, then it's my responsibility to make sure it doesn't break things, not yours. If I want you to make sure it works, then I've got to think about switching models to be something other than Open Source closed Development. Can you point to some change you might think about making where tests are helpful in TileCache?

Re: Tests for Goodness' Sake

Author: Sean

Why do *I* need your tests? Tests are a sign (to me) that the code could be worth my time to evaluate. That's all. OpenLayers' tests were a very positive sign.

Re: Tests for Goodness' Sake

Author: Schuyler Erle

Christopher, speaking as your collaborator and admirer, I'll reiterate why I insisted we come up with some kind of unit tests for TileCache: They're useful to *me*. If I break something, I want to know about it. ;-)

Web Mapping and Accessibility

Web mappers: what are you doing about accessibility?

Me? I'm using Plone for a solid start. Pleiades is using OpenLayers and Google Earth to visually display georeferenced content; neither of these are fully accessible. It's a hard problem, for sure. One of our technical observers is a CompSci specialist in accessible UIs. He sees the problem as rich and chewy, which means it won't be solved any time soon. Last time we met he had some interesting ideas, and I hope to be able to write about realizations of them next year. Pleiades' feed-based, "viewer"-independent, architecture should help.

Python Cartographic Library 0.11

/images/amp11.jpg

This release has been a long time coming, and I appreciate the patience I've been shown. At least the wait was less than 18 months. Here are the source release downloads: PCL-0.11.0.tar.gz [MD5, SHA1].

PCL 0.11 includes contributions from Kai Lautaportti, Michael Kerrin, Con Hennessy, Howard Butler, Ludwig Brinckman, Josh Livni, Sally Kleinfeldt, Aleksi Korvenranta, and Chris Calloway.

Comments

Re: Python Cartographic Library 0.11

Author: James Fee

Hey don't kill the messenger.

Re: Python Cartographic Library 0.11

Author: Sean

Sorry, James. I've changed the link to the original entry.