Here is ISAW's Associate Director for Digital Programs (my boss), Tom Elliot, on collaboration between Pleiades and DARMC [Ramping up Pleiades 2]:

Meanwhile, we've been in dialog with Michael McCormick, Guoping Huang and Kelly Gibson at Harvard. They're the driving force behind the Digital Atlas of Roman and Medieval Civilization, with whom we're collaborating under the new grant. Our aim is to collate and share the datasets assembled by both projects and to cross-link our web applications. This will bring more accurate coordinates for many features into Pleiades, as well as a number of new features that will expand our time horizon into the middle ages. You'll get a choice of display and map interaction modes and, eventually, the ability to move back and forth between both resources. We'll keep you posted as the timeline for this portion of the work is refined.

GeoScript now has something like descartes [plotting geometries]:

The plotting functionality makes use of the JFreeChart library, a popular open source Java framework for creating diagrams and charts. Another example of one of the benefits of the marriage of Java and Python that is Jython.

It reminds me of the run of such posts I went on this past spring. JFreeChart might be great, but Java platform developers shouldn't underestimate what matplotlib brings to the C Python platform: loads of tools for earth science visualization and excellent integration with tried and true numerical libraries. That said, I'll freely admit to some JTS envy.

BTW, Shapely 1.2.1 is now accepted to Debian unstable.

You can say that again.

The pont de Saint-Étienne d'Issensac has been remade a few times since the 14th century, but it doesn't look like they widened it much. We spent the afternoon in its shadow on the beautiful Hérault river.

I've combined my interests in the brand new RFC 5870 and representing rough locations in KML at http://ruffgeo.appspot.com/. Comments are very welcome, except about the name of the app.

Update (2010-06-18): Fixed a content disposition issue with Firefox. Apologies.

After some reading of Bittner and Stell [1], I've decided that my most recent approach to representing fuzzy locations was too sloppy: spatial objects and the regions in which they are located were conflated. By leveraging the container-like nature of kml:MultiGeometry, I've come up with a new one in which my spatial objects (like an ancient city's footprint) are always represented as KML Features and the regions they occupy are always represented as KML Geometries. So far, it seems like it will let us represent vague objects (like "Narbonensis", the Roman province which covered the Mediterranean coast of what is now France and had no absolute boundaries) as well as crisp objects (like "Lattara", or your mobile device's GPS location) which are located imprecisely in our information systems.

In this approach, a MultiGeometry would represent the rough location of a spatial object and collect statements about relations to other regions which would also be represented as MultiGeometries, one per relationship predicate. Predicates would be represented as text nodes of relation elements from a future namespace. The predicates themselves would come from 9IM or RCC models. In the example below, I show collections of relations that form a 3-piece concentric partition of space (like an "egg-yolk" [2]).

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2"
  xmlns:x="http://example.com/x">
<Document>
  <Placemark>
    <name>Spatial object located at an indeterminate region</name>

    <MultiGeometry>
      <!-- representation of indeterminate region -->

      <MultiGeometry>
        <!-- core/yolk -->
        <x:relation>Contains/hasProperPart</x:partition>
        <Polygon>...</Polygon>
      </MultiGeometry>

      <MultiGeometry>
        <!-- wide-boundary/white -->
        <x:relation>Within/properPartOf</x:relation>
        <Polygon>...</Polygon>
      </MultiGeometry>

      <MultiGeometry>
        <!-- exterior -->
        <x:relation>Disjoint</x:relation>
      </MultiGeometry>

    </MultiGeometry>

  </Placemark>
</Document>
</kml>

Test drive this if you like: http://sgillies.net/files/rough.kml.

Can you identify the spatial object having this footprint?

Update (2010-06-18): Welcome James Fee blog readers. I've updated the picture. Code to produce it is at http://bitbucket.org/sgillies/plot-pac-n/src. I've made use of a handy shapefile wrapper for OGR and modified it to provide JSON objects.

There have been a few recent calls for humanities researchers and informaticians to write more about their models of temporal and geographic data. The one I'm working on (Pleiades, a gazetteer and more) is preparing to evolve, so this is a good time to write about its current state and future directions.

That a place is more than its longitude and latitude coordinates has long been recognized. It's not just that a single point insufficiently describes a place known as "Lattara", but also that no ensemble of 2D or 3D geometric objects – points, lines, or polygons – sufficiently describes that place. Place is also determined by history, by language, by populations, by human experience. Yi-fu Tuan [1] writes:

Experience constructs place at different scales. The fireplace and the home are both places. Neighborhood, town, and city are places: a distinctive region is a place, and so is a nation.

Pleiades is primarily concerned with two characteristics of ancient world places: locations and names. We consider these distinct entities. The cardinality and navigability of the relationships are not much different than those in the CIDOC CRM [2]. In our case we have accompanying assertions and evidence that only make sense within the context of a place, so we have a composition relationship.

Among other attributes, Locations and Names have attested time periods (shown) with confidence measures and evidence (not shown). Temporal modeling isn't something we're going to get into here; in brief, Pleiades has an open vocabulary of time periods that can grow to suit users. The initial time periods (inherited from the Barrington Atlas) are quite coarse, but suffice for study or visualization of change between major eras. One can think of Names and Locations as broad events instead of snapshots in time and thereby partly escape the conceptual box of time-ordered footprints identified by Mostern and Johnson [3]. Politics or the movement of people sweep away old names and bring new ones. Settlements grow and fade, coastlines shift. Pleiades can document what is known about these episodes.

In the CRM, names and coordinates are generalizations of "E44 Place Appellation". We don't model this in the same way, although some of the intended consequences manifest themselves in the way we implement composition: one can readily find "place 42" by following the links embedded in the representations at (for example) /places/42/name(foo) or /places/42/location(bar) and in that sense, they do label the place.

The CRM, by the way, is as open-minded (or more) about place as Tuan: the deck of the H. M. S. Victory is considered a place and the lower right corner of a painting depicting Admiral Nelson's death is considered a place. We wouldn't prevent a user from submitting the bottom step of the Scalae Gemoniae as a place, I suppose, but Pleiades isn't aimed at this scale.

There's a lot we can do with the simple model shown above. We can identify unlocated places mentioned in ancient texts but never conclusively surveyed by archaeologists. We can identify the sites of excavated ancient places that yield no clue to their names. We can identify fictional places. We can collect arguments and evidence. We can share identifiers across the web. Yet, there are a few interesting ways to look at places that we can't support.

We don't allow aggregation of places to create hierarchies or places that are known only by sum of their parts. See for example Smith's [4] chapter on Gallia Cisalpina (emphasis mine):

The Boii occupied the country along the south side of the Po to the foot of the Apennines, and the northern slopes of these mountains. Their limits can only be approximated to by mentioning the towns within their territory. Bononia, originally called Felsina, when it was an Etruscan city, was one of them, and Mutina and Parma were two others. Placentia, near the junction of the Trebia and the Po, may have been within their limits; if it was not, we must place it in the country of the Ananes.

We've special-cased fuzzy locations such as "within the Barrington Atlas map 15 grid cell B2" but don't otherwise have a way for users to express fuzzy or relative locations like those in the same chapter (emphasis mine):

A new band according to Livy's authorities soon crossed the Alps by the same pass, the Cenomani (Liv. 5.35) under Elitovius, and occupied the places where in Livy's time Brixia (Brescia) and Verona were: the Libui were the previous occupiers of these parts. Livy may not have perceived that he has already mentioned (5.34) the Aulerci as Gallic invaders of Italy, and that the Cenomani were a division of the Aulerci. [CENOMANI] Cato found a tradition somewhere (Plin. Nat. 3.19) that the Cenomani once dwelt near Massilia (Marseille) in the country of the Volcae, which, if the tradition is true, may have been during their migration from their original country between the Loire and the Seine. The Cenomani (Livy) were followed by the Salluvii, who settled near “an ancient people, Laevi, Ligures,” as some texts have it, “who dwelt about the river Ticinus.” But here Livy has not observed, though he knew the fact, that the Salluvii or Salyes were Ligurians, and dwelt between the Lower Rhone and the Alps. In this passage (5.35) perhaps he may mean the Salassi.

The Barrington Atlas map-by-map directories include entries for ancient road networks such as this stretch of the Via Postumia in Map 39:

Augusta Taurinorum → Forum Vibii → *Forum Germanici → Pedo(na)

but we're not yet able to store these in a form that allows network analysis.

Changes to the model that would allow us to cover the new use cases are sketched out below.

The Feature interface in the diagram allows a clearer diagram. In practice it will be provided by Place entities. The "connected to" relationship would let us form graphs and do simple analysis of trade networks even in the absence of surveyed roadways. The "has part" relationship would let us generate rough spatial extents for aggregate places without falsely asserting any exact boundaries to them. An set of "relates to" relationships will let us put fuzzily or relatively located places "on the map".

I'm simultaneously writing about the effort to design representations of these entities for the web here and here. In the near future, I'd like to explain more about the evidentiary entities in light of Sebastian Heath's research.

By coincidence, as I'm writing this and citing Ruth Mostern (disclosure: Prof. Mostern was on the original Pleiades steering committee), I got word of the publication of version 1.1 of the Digital Gazetteer of the Song Dynasty (CC by-nc-sa) she has produced with Elijah Meeks. Their entity model is shown at http://songgis.ucmercedlibrary.info/?page_id=94.

FOSS4G workshop W-06 looks like a bonanza:

Python is becoming a solid development platform for the web and the geospatial domain. One of the advantages of Python for developing GIS applications is the number of high-quality tools it counts in the geospatial domain. Examples include Shapely, Mapnik, GeoDjango, TileCache, Python bindings for OGR/GDAL. This workshop presents a number of Python tools, libraries and frameworks, and shows how to use them together to create solid and efficient web-mapping applications. More specifically, the workshop covers the Shapely and GeoJSON libraries from the GIS Python Lab. It shows how to use these libraries together with SQLAlchemy and its GIS extension, GeoAlchemy, to create HTTP web services in an application developed with the Pylons web development framework. The workshop then teaches how to use MapFish to make the development of GIS web services easier. Finally the workshop demonstrates how to secure tile accesses by pluging TileCache in a MapFish application and making use of repoze.who and repoze.what for the security layer.

I've got more (previously) half-baked thoughts on handling the fuzziness or relativity of places and their locations in KML. There are two sides to this issue: 1) a interface based on visual metaphors and hypertext through which a user can navigate fuzzy waters, and 2) an encoding of the fuzziness so that a machine can make sense of it when user-modified KML is uploaded.

One possible user interface is driven by HTML anchors and links to other KML entities within Feature descriptions [reference]: http://sgillies.net/files/relative2.kml.

In this KML there is a representation of a place (labeled "Lattara") with a location that is known only from a gazetteer (in the back of my atlas) to be within the earthly footprint of the Barrington Atlas map 15 grid cell B2. The location of ancient Lattara is actually well known (and the museum dedicated to it in Lattes is a must-visit), but let's imagine it is not, and until I reconcile Pleiades with a big batch of updates coming soon from a partner institution, many of our places are in this state: known only to be within a lat/long rectangle. A nice feature of our model is we can identify places by URI without knowing their locations or coordinates precisely. The spatial data is added as we get it. You'll recognize that this is absolutely not the GIS way of doing things.

The simple place browsing user interface that surfaces in Google Earth from relative2.kml isn't terrible: click on the "Lattara" folder in the left pane and we get a free floating popup with a link to a location.

Click that link and we traverse to the location, which has more links to its spatial context.

Click on the "footprint" context link and we get an anchored popup.

By representing the fuzzy location as a KML Folder containing a NetworkLink, my intention is better expressed in Google Maps than previously [map]. Every item of interest shows up in the pane on the left. Unfortunately, there are still no free floating popups for the "Lattara" and "within context" items. It's quite possible that I'm missing something, but it looks like Google Earth and Maps behave differently. A close look at the DOM of a Maps page post-load shows that there's no snippet div to be shown in a popup for item that's not a placemark.

I think what I need is way to represent the "within" relationship (or others) as a placemark – and this is where the issue (2) of machine readability comes up – without asserting that its position in the map marks the actual location of a place. Maybe KARML's balloons aren't as far off the mark as I thought. A problem with them (for me) is there's no way to create them from Google Earth. Not much of a KML editing tool, Google Earth doesn't even let a user create "extended data", but it's ubiquitous. I am very much trying to avoid having to write a one-off visual editor for fuzzy and relative locations. I've got enough on my plate already and would like to find a fairly generic and declarative solution: location relativity expressed in markup, not written into a database using a specialized API or specialized GUI.

What to do? RDFa in Feature descriptions ala

<description><![CDATA[
This feature is somewhere within the
<a
  rel="where:within"
  href="http://sgillies.net/files/bagrid15.kml#batlas-15-b2-footprint;balloon">
footprint</a>
of
<a href="http://sgillies.net/files/bagrid15.kml#batlas-15-b2;balloon">
BA Grid 15 B2</a>.
]]></description>

is a possibility. Of course, you can't count on users to type RDFa and HTML properly (to change rel="where:within" to rel="where:outside" for example), so this opens a very large can of worms.

I'm going to continue to think aloud about this for a while. Good ideas and good-natured heckling are welcome.

GeoJSON is a browser-era alternative to the good old WKT format. It's not that {"type": "LineString", "coordinates": [[0.0, 0.0], [1.0, 0.0]]} is easier to parse than or technically superior to LINESTRING (0.0 0.0, 1.0 0.0), but that we can now represent geometric objects using a more general and widely used format: uniform use of JSON instead of WKT for geometry and some other format for non-geometric data.

On Seth G's geographika blog there's a fine demo of fetching GeoJSON from a web service and plotting it with matplotlib and descartes. Descartes deals in GeoJSON-like Python objects and so he could in fact keep the data in that form from start to finish.

This morning I found an email pointing out ArcPy's support for data interchange using the same kind of GeoJSON-like Python objects: AsShape().

import arcpy
gjPolygon = {
    "type": "Polygon",
    "coordinates":
        [[[10.0, 0.0], [20.0, 0.0], [20.0, 10.0], [10.0, 10.0], [10.0, 0.0]]]
    }
polygon = arcpy.AsShape(gjPolygon)

Is GeoJSON (as a dict) a new lingua franca for Python GIS? Will wider use mean that we'll finally have to do something about the GeoJSON specification's defficiencies at the date line and poles?