Rocky Mountain Rail Authority Study

Anybody who has ever spent 3 or 4 hours on a winter (or summer holiday) evening creeping home, bumper-to-bumper, on I-70 has had one of these two thoughts roll through their weary, road-raging brain: "If I only had a monster truck I would crush all of you and be home in time to watch Sean Hannity!", or "Train, duh!"

In the news today is an announcement that the Rocky Mountain Rail Authority -- a coalition of Colorado counties, cities, transportation authorities, and the Colorado Department of Transportation -- will study the feasibility of high-speed rail links between Front Range and mountain communities. Cheyenne to Trinidad is maybe overreaching, but Fort Collins to Colorado Springs and Denver International Airport to Vail would be mighty fine.

http://farm4.static.flickr.com/3182/2758287891_5a1ab26554_d.jpg

It's about damn time. I don't care if the study has to use the most paleo-proprietary software one can find, let's get this on. I do, however, reserve the right to complain bitterly about any godawful ArcGIS Server-based transit user web applications.

Comments

Re: Rocky Mountain Rail Authority Study

Author: Paul Ramsey

Breaking news, feasibility to be studied, more at 11!

Another sorry chapter in the North American real odyssey.

Here in Victoria, we're busily allowing a perfectly good rail corridor up the island fall into complete disrepair. It's so bad the tracks have potholes! God forbid government should subsidize a transportation network. The highway system is required, but the rail system is optional. Bah!

Re: Rocky Mountain Rail Authority Study

Author: Sean

Yes, I know: I'm setting myself up for disappointment. The geography is favorable here (flat and linear), but money and politics will decide. High speed rail is way too much like Communism for people outside the liberal ghettos of Fort Collins, Boulder, and Denver. I suspect a high speed "ski" train in the I-70 corridor will be found most feasible.

Re: Rocky Mountain Rail Authority Study

Author: James Fee

Hey if they can't even get high speed rail between LA and Las Vegas, those in other areas (we here in Arizona are looking at Phoenix to Tucson high speed rail) don't have a prayer.

"Web GIS" versus "GeoWeb"

Adena Schutzberg:

Web mapping was not mentioned; Web GIS was, quite a bit. GeoWeb? Not that I recall.

I like the proposition of "Web GIS": applying geographic information system technology and geographic information science to the universal information space -- the mature space of documents and the emerging space of data -- that we call "the Web". GIS for the Web is something that you can actually design and implement (ESRI and I part ways where the rubber meets the road). "Web GIS" is marketing, yes, but at least it's supported by solid concepts.

The "GeoWeb" proposition repels me. Asserting an existence of a "GeoWeb" distinct from the Web seems like self-imposed ghettoization. Maybe it's a matter of taste, but I'd find discussion of MusicWebs, VideoWebs, and BookWebs equally unproductive.

Comments

Re: "Web GIS" versus "GeoWeb"

Author: James Fee

I think you've gotten very down in the weeds here worried about Web GIS vs GeoWeb. Curious though Sean, who is saying the GeoWeb is separate from the web (or the series of tubes)?

Re: "Web GIS" versus "GeoWeb"

Author: Sean

I wrote "distinct", not "separate". I'm looking for the distinction being made with the term "GeoWeb". What's going on that isn't simply "Web"?

Re: "Web GIS" versus "GeoWeb"

Author: James Fee

Fair enough, I'm not sure the consensus is that are distinct either. Or are you just having trouble with the marketing of the term as opposed to the use of Web GIS?

Re: "Web GIS" versus "GeoWeb"

Author: Matt Giger

Usually I don't care what marketing term a company is using, but GeoWeb is being used to categorize an entire field of computer science as a novelty. 'Web' should not be even referenced since within the next few years the lines between online and offline GIS will be mostly invisible.

Re: "Web GIS" versus "GeoWeb"

Author: Andrew Turner

WebGIS and GeoWeb are obviously different things as you pointed out. WebGIS are the tools and technology (Slippy Maps, API's, hosting) versus the interlinked, especially geospatially linked documents. By Geospatially linked I mean features that use externally referenced geometries, for example WOEID's or Geonames, that then imply correlation based on location. While there isn't "MusicWeb", there is SocialWeb. It's not NounWeb, but 'Adjective'Web. This is similar to GeoRSS (and agree that it's confusing) where it 's not a separate interface, but instead the necessary push for extensions that just add geographic data to broader information.

Re: "Web GIS" versus "GeoWeb"

Author: Sean

Yes, Andrew, we've been working together on geographical link relations in the context of Atom and I think that's getting close to something we could call a "GeoWeb", but that's not at all what most people (and all business people) mean when they refer to the "GeoWeb" (I know because there are just a handful of us in the link discussions).

Geojson 1.0

We're done: http://pypi.python.org/pypi/geojson/1.0. Matt Russell from Sanoodi did most of the coding while I was editing the spec, and Eric Lemoine from Camptocamp helped us crush bugs.

Geojson provides geometry, feature, and collection classes, and supports pickle-style dump and load of objects that provide the lab's Python geo interface. Here's an example of a round-trip through the GeoJSON format:

>>> import geojson
>>> p = geojson.Point([0.0, 0.0])
>>> p
Point(coordinates=[0.0, 0.0])
>>> data = geojson.dumps(p)
>>> data
'{"type": "Point", "coordinates": [0.0, 0.0]}'
>>> q = geojson.loads(data, object_hook=geojson.GeoJSON.to_instance)
>>> q
Point(coordinates=[0.0, 0.0])

The geometry classes interoperate with Shapely via the geo interface:

>>> from shapely.geometry import asShape
>>> x = asShape(p)
>>> x.wkt
'POINT (0.0000000000000000 0.0000000000000000)'

For more details, please see the project page at http://trac.gispython.org/lab/wiki/GeoJSON. Share and enjoy.

High Country News and Plone

I've read the print manifestation of High Country News for years and am delighted to find out today that the new http://hcn.org site is based on Plone. Congratulations Jon and ONE/Northwest.

Comments

Re: High Country News and Plone

Author: Jon Stahl

Heh... Glad you're a fan, because I think they want to talk to me about mapping for their "2.0" release. :-)

Re: High Country News and Plone

Author: Sean

Indeed, geography is one of the major themes of HCN. I think some georeferenced Atom feeds and map representations of them would complement the articles well.

Weak references

I've been living off of them for years, but have finally found a use for Python's weak references in my own code.

In Shapely, coordinate sequences, rings of polygons, and members of multi-part geometries provide proxy access to a GEOS geometry structure "owned" by the parent polygon or multi-part geometry. Through their lives they must carry references to the parent like this:

>>> point.coords.__p__ == point
True

so that an anonymous parent object isn't swept up by the Python garbage collector before a hobuism like:

>>> len(polygon.exterior.centroid.coords)
1

executes completely. The implementation is a bit tricky, but a Shapely user doesn't need to think about it: it just works.

Some sub-geometries are expensive enough to create that I've decided to cache them in the parent. Since the "child" already holds a reference to the parent, making a reference to the child from the parent creates a potentially problematic reference cycle. The example below shows cyclic references that prevent Python's automatic garbage collection from freeing objects. The garbage attribute of the gc object below contains references to objects that aren't freed.

>>> import gc
>>>
>>> class ReferencingThing:
...     ref = None
...
>>> gc.enable()
>>> gc.set_debug(gc.DEBUG_SAVEALL)
>>>
>>> for i in range(2):
...     a = ReferencingThing()
...     b = ReferencingThing()
...     a.ref = b
...     b.ref = a
...
>>> gc.collect()
4
>>> gc.garbage
[{'ref': <__main__.ReferencingThing instance at 0xb7dbec4c>},
 <__main__.ReferencingThing instance at 0xb7dbeb8c>,
 {'ref': <__main__.ReferencingThing instance at 0xb7dbeb8c>},
 <__main__.ReferencingThing instance at 0xb7dbec4c>
 ]

A Shapely user demonstrated to me such a bug that was causing geometries to pile up in his application. A weak reference, which is not enough to keep an object alive, does not so block Python's automatic garbage collection. Here is the non-leaking weakly-referencing version of the code above:

>>> import gc
>>> import weakref
>>>
>>> class WeaklyReferencingThing:
...     _ref = None
...     def reference(self, ob):
...         self._ref = weakref.ref(ob)
...     def dereference(self):
...         return self._ref()
...
>>> gc.enable()
>>> gc.set_debug(gc.DEBUG_SAVEALL)
>>>
>>> for i in range(2):
...     p = WeaklyReferencingThing()
...     q = WeaklyReferencingThing()
...     p.reference(q)
...     q.reference(p)
...
>>> gc.collect()
0
>>> gc.garbage
[]

I've also come across a pattern for weak attributes that provides a nicer syntax.

Linking open geographic data

Before I read Bjørn Sandvik's post about semantic geospatial services, I didn't know there was an effort to build bridges from WS-* to the Semantic Web. More significantly, his post is a useful introduction to semantic web issues to GIS users who are more familiar with the concept of services than the concept of Web resources. The metadata in OGC service capability documents (abstract, keywords, etc) are inadequate for the purpose of machine reasoning, and application of RDF and OWL could certainly make it more clear what a service is about.

There is a different effort already underway to semantically link open datasets called "Linked Data" [wikipedia, http://linkeddata.org] or "Linking Open Data" [W3C]. This service-free, or at least, service-agnostic, approach is the one I find more compelling for Pleiades and Concordia. The diagram below (from Richard Cyganiak) shows how geographic data courtesy of GeoNames is right at the heart of the Linked data project.

http://richard.cyganiak.de/2007/10/lod/lod-datasets_2008-03-31.png

This graph of data has grown by leaps and bounds since we pitched Concordia. We didn't initially propose to join the Linked Data project, but I'd really like to see Ancient World datasets link themselves together in this way.

Blog hauling

body_html_template

Comments

Re: Blog hauling

Author: James Fee

import cartography is no more?

Re: Blog hauling

Author: Sean

Not doing much cartography these days, I felt it necessary to change the name. I thought "Two minutes' W*S hate" would be ironically amusing, but there's so more to my blog than that -- such as pictures of birds and vegetables.