2006 (old posts, page 10)

AJAX Mapping Shakeout

Speaking of shakeout and convergence: I don't see any reason why Mapbuilder and OpenLayers, the two leading open source AJAX map libraries, need merge. Choice is good, and these projects offer distinctly different approaches. Mapbuilder is closely tied to GeoServer, highly structured, and disciplined. It's a natural fit for Java projects. OpenLayers, on the other hand, is simpler, XSLT-free, and more attractive to Python, Ruby, and PHP (if you must) users.

Python Web Framework Shakeout

Python mapscript users have always been overwhelmed when they go shopping in the web frameworks aisle. It's long, and tall, and filled with mildly branded boxes. There's more options than one shop can possibly evaluate, and until the last year or so, none of them made much effort to jockey for the prime eye-level shelf. It's confusing. And the last thing your typical web GIS project needs is more confusion and more choices. You've already had to choose processors (Intel or Athlon), storage (IDE/ATA or SCSI), operating system (Windows, Fedora, Debian, Ubuntu, or ...), RAID configuration, raster tiling schemes, shapefiles or PostGIS, and so on. I really can't blame anyone at this point for taking the route clearly marked "PHP".

Google Regionator

I was speculating wildly the other night that Google's regionator package has to have been written by Frank Warmerdam. The distracting capitalized method names are either a dead giveaway or a brilliant red herring. Regionator seems like a useful tool, but I'm less than excited about a couple aspects of it. There are tests -- good -- but they don't use unittest or doctest. Bad. Why invent yet another testing framework? Then there is the KML serialization:

kml = []
kml.append('<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n')
kml.append('<kml xmlns=\"http://earth.google.com/kml/2.1\">\n')
return "".join(kml)

Yo, Google, don't be a bozo. Use ElementTree (or lxml) infosets instead of managing all those tags and angle brackets yourself. You'll be glad you did, and you'll help to set a good example for hundreds of new Python programmers.

Sol Katz Award, Ideals of Open Source

Nominations are open for the Sol Katz Award, which honors

... individuals who have demonstrated leadership in the GFOSS community. Recipients of the award will have contributed significantly through their activities to advance open source ideals in the geospatial realm.

I'm curious to see the nominees. The MapServer Foundation cabal members should consider disqualifying themselves. The NDA signed with Autodesk last year was a poisonous thing, and far from the ideals of open source community. It troubles me to say this because one of them is otherwise the clear choice for the award. The FOSS4G Pete Rose, you might say.

GeoDRM and Access Control

It's come to my attention that work is under way to separate access control of geospatial web services from digital rights management. A wise thing to do, and not only because GeoDRM is a non-starter. The access control problem has already been solved by the pioneers of internet commerce. If you don't believe me, go read the Apache httpd authorization and authentication docs. Anybody have an access use case that can't be solved by an Apache proxy, mod_rewrite fu, and tweaking of row/column privileges in your data store? It would have to be quite the corner case.


Re: GeoDRM and Access Control

Author: Andrew Hallam

Totally agree on separating access control from DRM. I've seen a few projects that wanted to control access to WMS and WFS services, but gave up when they realised that it would break interoperability. My suggestion to the OGC would be to look at standardising on TLS/SSL and HTTP authentication. Combine that with common business practice of licence agreements/contracts and most of the issues would be solved. Although, there may be some issues to work through. If that doesn't cover all the bases then DRM could be considered (shiver), but let's take care of the common cases first using established technologies.

Re: GeoDRM and Access Control

Author: Sean

Andrew, the document you linked to is brilliant!

GeoDRM: Worst. Idea. Ever.

I lurk on the Mapbuilder email list and am growing uneasy at the project's flirtation with GeoDRM. In the wake of Sony's anti-customer technology meltdown the string "DRM" makes reasonable people shudder, but GeoDRM proponents soldier obliviously on. Five months after its release, I finally made the time to read the GeoDRM final report jointly produced by the FGDC, GeoData Alliance, and OGC. My conclusion is that it won't happen for at least four reasons. GeoDRM, as proposed, is:

  • Overly complex
  • Backwards-looking
  • Poorly researched
  • Unnecessary


Re: GeoDRM: Worst. Idea. Ever.

Author: Bryan

I'm not sure that the geodrm strand is going the right way either. But I do think there is good reason for access control for GIS resources exposed using OWS ... not least because some requests generate significant server side processing which one might (ok, does) need to control when one expects significant hits ... and also because some data can be restricted in distribution for other than financial reasons (often folk are willing to share, but not til they've got the low hung fruit within their distributed team, and I think that's fair enough). So, if one removes the DRM badness, and just thinks about constraining usage to what is manageable and fair, then it's not all bad ... For me, I think the way to do is simple, the outline concept is at http://home.badc.rl.ac.uk/lawrence/blog/2006/08/15/on_access_control

Re: GeoDRM: Worst. Idea. Ever.

Author: James Fee

What, no Comic Book Guy graphic?

Re: GeoDRM: Worst. Idea. Ever.

Author: Sean

Sorry, James, DRM sends my sense of humor packing. Bryan, you've inspired me to write a bit more on the subject. Access control is a good thing, and there are a lot of good options for geo purposes. People should think twice before inventing new ones.

Yahoo's Python Developer Center

Yesterday I wrote a Python module that uses the REST-ful Yahoo geocoding API. Coincidentally, Simon Willison announces today Yahoo's Python Developer Center with a few very similar recipes. It's another example of the ease of Python: there's usually one obviously right way to solve small problems. Check out the site for good examples of using the Yahoo APIs, but remember to skip over minidom and go straight to ElementTree. It's going to be in the standard library come 2.5, so why not get used to it now?

W*S Client Library for Python

A few years ago, J.F. Doyon and I collaborated on a Python package for programming with WMS and WFS called PyOGCLib. It found use in Thuban and a few other Python programs. I was never a happy PyXML user and so when I started up the Python Cartographic Library, took the opportunity to start over using ElementTree. My partner this time was Julien Anguenot of Nuxeo, and the driving force was the CPSGeo product for CPS. Last weekend I spent some time factoring our code out into a new project: OWSLib.

"OWS" is short for OGC(TM) Web Service. OWSLib is used by PrimaGIS to inspect WMS and WFS. It has a simple but effective capabilities document parser, and code for making web map context documents that probably has little use for anyone outside CPS at this time. WMC and SLD parsers are an obvious next step. There is a GML parser for PCL in progress which might also be of interest to OWSLib users.

OWSLib doesn't require the Python Cartographic Library. It depends only on ElementTree or lxml. Your choice. There's no official release yet, but I expect to have one in October in time for the Seattle Plone Sprint.


Re: W*S Client Library for Python

Author: Allan Doyle

Thanks for the pointer to ElementTree... I've been playing with it and it's a great package. ElementBuilder (http://www.tothink.com/python/ElementBuilder/) turns out to be a nice little "convenience" module that adds easy Element building.

Re: W*S Client Library for Python

Author: Allan Doyle

I just hacked together a Mapfile builder with ElementTree and ElementBuilder - http://think.random-stuff.org/FrontPage/archive/2006/07/mapfile-builder