2011 (old posts, page 4)

Ancient Toponym of the Week: Error Ins.

I saw Error? Ins. yesterday in the slideshow that runs in the new Pleiades homepage and immediately thought "there's an Atlas bug." Tom Elliott, managing editor of Pleiades, checked his copy of the Itineraria Provinciarum et Maritimum (also known as the Antonine Itinerary) and found:

item inter cartaginem spartariam et cesaream mauretanie: insula erroris et tauria, inter se habent stadia LXXV.

Translation: "between Spartarian(?) Cartagina and Caesarea Mauretania: the island of Error and Tauria, between which there are 75 stadia."

The Barrington Atlas (and Pleiades) annotated this toponym with a question mark to indicate some uncertainty in association between this name and the small island now known as Île Plane.

Tom also reminded me that the Antonine Itinerary is covered in Chapter 14 of The History of Cartography, Volume 1 – available as a free PDF from the University of Chicago Press: http://www.press.uchicago.edu/books/HOC/HOC_V1/Volume1.html.

Comments

Itinerary

Author: Tom Elliott

Unfortunately I'm not aware of any open-access edition of the itinerary. The standard print edition is Otto Cuntz (ed.), Itineraria Romana, vol. I, Stuttgart: Teubner, 1929. My 1990s reprint copy (ISBN 3-519-04273-8) cost something like 96 euros via ABE Books.

Tom

Getting the GeoJSON band back together

The authors of the 1.0 specification have agreed to address the deficiencies and ambiguities of the GeoJSON format and revise the specification document. Consensus is that we will avoid going overboard; this will be a 1.1 not a 2.0. The primary components of the process are:

  • Consensus
  • Good faith
  • Transparency
  • GitHub

All authors signed off on every part of 1.0 and consensus among the authors will decide everything for 1.1. We probably can't tackle every worthy idea that is floated, but we'll do our best. Discussion, debate, and consensus forming will take place on a public (and archived) mailing list and wiki and the process of revision will be managed using Git and GitHub. Please see https://github.com/GeoJSONWG/geojson-spec and join us in keeping the format fit for future use.

Notes on deploying a Pyramid app to Heroku

My first try at deploying a Pyramid app to Heroku's new Python platform took all of 20 minutes, 15 of which were spent figuring out that I needed to pin my application to PasteScript 1.7.3 to use cpwsgi_server and that putting a Python executable in the Procfile's web line seemed to be the key to getting Heroku to understand this was a Python (and not Ruby on Rails) app. I'm sure the Heroku example using Flask can get you up and running in less than 5 minutes. Heroku is probably not news to many of you, but I'm blown away at how easy the Heroku team has made this. Impressive.

My application itself is nothing much. Try out the Greek to modern Latin transliteration scheme used by the Classical Atlas Project and Pleiades at http://fierce-sky-2201.herokuapp.com/ if you like. There's a link to the source of my Pyramid app in the form's page.

Fiona

I while ago I created a project named WorldMill to learn about writing Python extension modules with Cython and experiment with designing a slicker OGR API. Interest in the project is rising again and after some discussion I've persuaded users that we should change the name because the *Mill project name space is getting a little crowded. The new project: Fiona. Fiona is OGR's neater (or nicer/nimble/no-nonsense) API – elegant on the outside, unstoppable OGR(e) power on the inside.

What I'd like out of Fiona: a clear alternative to the complex layers and cursors and fussy geometry objects of OGR and ArcPy; Python generators serving as sources and sinks of GeoJSON-like objects; and above all, no reference counting duty dumped on users, no need to explicitly "del" anything. I think an API like this would be productive and make new types of Python data processing programs possible. For example, one might use the enhanced generator protocol of PEP 342 to create pipelines of coroutines that receive and send GeoJSON-like objects, bringing into being something like a WSGI for Python spatial data processing. See https://gist.github.com/1232852 for the pipelinedemo module code wherein the pipeline components below are declared. The demo tasks simply increment the value of a particular feature property (adding the property if it doesn't already exist) and send the feature down the pipe. The demo writer appends received features to a list and serializes them to JSON in a file.

>>> from pipelinedemo import pipeline, task1, task2, writer
>>> features = [{'id': "1"}, {'id': "2"}, {'id': "3"}]
>>> pipeline(
...     features,
...     task1(
...         task2(
...              writer(open("pipeline-demo.json", "w")))
...         )
...     )
>>> print open("pipeline-demo.json").read()
{
  "features": [
    {
      "id": "1",
      "properties": {
        "count": 2
      }
    },
    {
      "id": "2",
      "properties": {
        "count": 2
      }
    },
    {
      "id": "3",
      "properties": {
        "count": 2
      }
    }
  ]
}

Fiona already provides feature source generators that leverage the OGR format drivers. Work on the feature sinks at the other end of the processing pipeline is clearly the next step. Follow or fork; your ideas and pull requests are welcome.

By the way, A Curious Course on Coroutines and Concurrency has a very readable introduction to this "push" style of pipeline for Python along with excellent advice in general on using enhanced generators.

State of the Map Saturday

I'm attending the State of the Map next Saturday, not to present but to catch up with some Python folks, meet some nodes of my social networks, and hear about the state of the art in collecting, modeling, and using geographic data. The OpenStreetMap project has been and continues to be a source of inspiration and social and technical guidance for Pleiades. I hope I'll see you there.

I won't be at FOSS4G this year. My wife is off to an international weed science symposium and I'm solo dad all next week. I wanted to come down Wednesday to organize an informal Python session; inability to get any babysitting help before or after school is going to prevent me from doing so. I will miss a lot of people who won't be at SoTM, but $350 for a brief visit during school hours is more than I can justify.

Trail Ridge

My youngest finally got her first taste of camping in Rocky Mountain National Park last weekend, and also her first ramble on the tundra (or rather a trail through protected tundra) up on top of Trail Ridge. The Rock Cut parking lot on Trail Ridge Road (US-34) is at 12,110 feet, or just less than 3700 meters above sea level.

http://farm7.static.flickr.com/6184/6073550484_2a1f670cc0_z_d.jpg

Coming down from the viewpoint, her big sister spotted this vast Moose-shaped snowfield:

http://farm7.static.flickr.com/6186/6073550490_d88553f377_z_d.jpg

There's a hint of the Moose in Bing's imagery, but not in Google's.

Closing down the Lab

If you're a suscriber to the GIS-Python projects mailing list, you've seen the discussion about migrating projects to other hosting services. If you're not a subscriber your first notice might have been seeing this at the Trac site:

http://sgillies.net/images/closing-lab.jpg

OWSLib is going to Sourceforge, the zgeo.* projects are being superceded by the collective.geo suite at CoActivate, and most everything else has been moved to GitHub.

When Kai and I started the GIS-Python effort in 2005, running our own development site looked like the best option. Today, it's nowhere near the best option and feels increasingly like a hinderance. I'm looking forward to spending less time on operations and more time on coding. I hope you'll stick with the projects through the move and beyond.