Software and Camping Gear

Tom Kralidis asked the following question about OWS common metadata parsing, but it could be asked about almost any aspect of web GIS:

But then I thought why not just implement this in MapServer, and have the functionality exposed via mapscript?

Why write new web GIS software? Why not add to MapServer? I'm going to explain by analogy: it's like picking camping gear.

Call me soft, but I like filtered water, hot meals and drinks, shelter from the rain, and a warm bed when I go camping. For the sake of argument, let's call these the basic requirements for alpine camping equipment:

  • water filtration and storage;

  • heat source for cooking food;

  • shelter from rain and snow;

  • warm bedding;

  • means of transporting the above.

There are 2 distinctly different philosophical approaches to meeting these requirements. The first involves acquiring:

  • a hand-pumped sub-micron water filter, and several liter bottles;

  • a compact single-burner kerosene stove, with pot, kettle, cup, and spoon;

  • a weatherproof, folding tent with light, collapsable graphite framework;

  • a sleeping bag and stuff-sack;

  • a backpack.

The REI approach, if you will (disclosure: I am an REI member). The second approach is to get a recreational vehicle with everything (including the kitchen sink) built in. See where I'm going with this analogy? The RV is certainly convenient, but gives you no flexibility. The configuration of its components is fixed. None of them can be removed and used away from the vehicle. The REI approach, on the other hand, provides maximum flexibility. Want to camp kilometers from a road? Pack your gear in the backpack and walk. Water sources are far from your campsite? Take your filter and bottles to the source and carry treated water back. Maybe you're just "carpet camping" at a friend's ski cabin? Bring only your sleeping bag.

My projects require similarly modular, agile software tools. There are places that MapServer can't readily go, and that's why I'm working on OWSLib, Quadtree, Rtree, GeoJSON, and Shapely.


Re: Software and Camping Gear

Author: Tom Kralidis

In some instances, it's alot easier to build code on top of existing, approved packages so as not to introduce anything 'new' into the mix. For example, it would be easier to build GeoJSON support in OGR, so then one can utilize them from within an already-built-and-deployed GDAL/OGR scenario. P.S. I'm a sucker for analogies -- they are really helpful!

Re: Software and Camping Gear

Author: hobu

Tom, I recently committed GeoJSON output and input of geometries to the next-gen Python bindings in OGR. It has allowed me to do things like this (a service that can reproject GeoJSON from URLs): Howard

Re: Software and Camping Gear

Author: Sean

How about this: build reprojection of GeoJSON data on the web into ogr2ogr? ;)

Re: Software and Camping Gear

Author: hobu

ogr2ogr wouldn't be very webby, would it? As a side note, I will not be implementing any specification that is described on a wiki page in a rigid, statically-typed language like C++. When the dust settles on the spec, we can look at making it part of OGR proper. Howard

Re: Software and Camping Gear

Author: Tom Kralidis

hobu: to clarify, OGR proper has GeoJSON support, right? So I can get to them via Python or Perl, etc.? As for reprojection, I'm a big fan of the ogr/wcts in the GDAL dist, and use it alot. Great web service!!

Re: Software and Camping Gear

Author: hobu

Don't know that there is such a thing as 'proper' GeoJSON support because there isn't a hard spec yet.... Anyway, OGR has Geometry-only GeoJSON i/o in the Python next-gen bindings in subversion. So, no, it isn't in OGR proper as a real driver, just a couple of Python methods in the Python bindings. When the spec settles down, maybe I'll make the effort to write a C++ driver for GeoJSON. It's likely to be messy because OGR doesn't really have a concept of a free-standing Feature, however, and GeoJSON almost exclusively does.