2007 (old posts, page 26)

Rocket City Baloney

Am I ever glad I took a pass (sorry, Tom) on coming down to Huntsville for this. I suppose this is the Bizarro version of Damian Conway's preach-to-the-choir FOSS4G keynote: telling the overdogs of the military-industrial complex (who, when you think about it, have a financial stake in global trouble) exactly what they want to hear.

OpenStreetMap Fort Collins

I didn't know that OSM covered the Fort. The city gives away street data, and that appears to be the primary source, but somebody has added the Spring Creek and Mason bike paths, the bike extension of Centre through the CSU campus, the bike path from the library to the Meridian/Plum intersection (along which I tow my kid to daycare), and the path around City Park Lake. One of these days, I'm going to get off my butt and help out with OSM.

Comments

Re: OpenStreetMap Fort Collins

Author: glenn

very cool... I'm in Fort Collins so its nice to see that effort expand! Glenn (gisuser.com)

PrimaGIS Sprint

Kai Lautaportti, Chris Calloway, Josh Livni, Sune Woeller, and Alessandro Amici are sprinting on PrimaGIS for Plone 3.0 in Naples today while Alex Mandel and I tele-sprint from California and Colorado. Goodbye old map interface, hello OpenLayers.

Comments

Re: PrimaGIS Sprint

Author: Joel

Go PrimaGIS!!

AtomPubbing Librarians

I was wondering about these "Sword" entries in my Hammock collection, and it seems they are associated with the UKOLN Simple Web-service Offering Repository Deposit (SWORD) project. The 1.0 version of the SWORD AtomPub profile was released today. Librarians, more and more, are getting the value of web-style services and resource-orientation.

Nobel Peace Prize

Congratulations to Al Gore and the UN IPCC. Bill Gray, my tropical meteorology professor (who has on the record compared Gore to Hitler), is certainly annoyed today, and heads will be exploding in the nuttier wings of the blogosphere (like this: pop!). It's hard not to reflect on where we might be today if the 2000 election hadn't been stolen.

Clearly it's a Good Idea

When people start coming out of the woodwork to take credit. Stats from a recent Directions article on GeoJSON:

Number of times an author of the GeoJSON draft is mentioned by name: 0

Number of posts to the working group mailing list or wiki by anyone from Safe Software, the company prominently linked in the article to GeoJSON: 0

Frankly, the thought of people storing data in the GeoJSON format on their filesystems, or emailing GeoJSON attachments to their customers, scares me. That's what GML is for. GeoJSON is just a way to encode simple geographic data structures on the wire between web clients and web servers.

Comments

Re: Clearly it's a Good Idea

Author: Steve Citron-Pousty

Amen Brotha'

Re: Clearly it's a Good Idea

Author: Michal Migurski

At least they aren't writing about GeoSOAP.

Standards Body?

Author: Andrew Turner

heh
Incredibly, the GeoJSON Request for Comments (RFC) has not even been approved or finalized by any official geospatial standards committee.
negative ghost-rider, the pattern is full

Re: Clearly it's a Good Idea

Author: Morten

I also found it funny that Netscape got the credit for AJAX, when it was Microsoft who introduced the XmlHttpRequest object that made all this possible.

Lost In Translation?

Author: Dale Lutz

I was thinking of opening with a Richard Nixon quote, but realized that may not be the best way to get my point across... After reading Sean's comments, I very carefully reread the Directions article to see if somehow we at Safe Software were painted as claiming credit for GeoJSON (we didn't write or initiate the article, we were just interviewed). Let me be perfectly clear (okay, there's my Nixon quote), Safe is never interested in taking credit for a format, we're interested in supporting formats, sometimes brand new formats, sometimes formats on the bleeding edge. All we've done, and all we were quoted as claiming in the article, is implement support for the current draft of GeoJSON in the beta version of FME so that folks can download and play if they are so inclined. To see what some of the possibilities are, check out GeoJason Birch's blog. (Aside: we don't see folks really using GeoJSON in a file, but rather in web architectures. That's why our reader can read from a URL and output to any FME format, and our writer will most likely be primarily used as part of an FME Server GeoJSON web service -- FME is about alot more than files.) As for participation in the community, perhaps we could have piped up a bit on a few issues, but honestly I've liked what I've seen. Let your X by X, and your Y by Y, for example. (If someone had proposed that the coordinate order was going to be governed by an EPSG code, I am quite sure we'd have expressed an opinion. But we didn't need to.) I did talk with Chris at FOSS4G about a few things, but admittedly that's not much. If we see something we think would make implementation horrible, we'll get more involved, but frankly the whole point of GeoJSON has been to make implementation straight forward and easy, so I doubt that anything's coming that would make our skin crawl. In any case, we certainly aren't interested in taking away or having any part of the glory associated with the creation of GeoJSON, all we want to do is be sure we support it, much as the GeoServer folks do/have done. If our actions are in anyway offensive or otherwise disrespectful to the GeoJSON community, I apologize deeply and welcome advice on how we can support your (in-my-personal-opinion-excellent) efforts without offending anyone. Until then, we'll do our best to stay well inside the woodwork, quietly keeping up as well as we can with any ongoing spec changes...

Re: Clearly it's a Good Idea

Author: Sean

No, Dale you're not directly taking undue credit, but the author of that infomercial is putting the terms GeoJSON and Safe Software so adjacent that the reader can't help but form an association between them. It's a classic advertising method, like in a TV commercial where world peace breaks out while everyone is holding a can of soda pop. Does the soda really create world peace? No, but that's the implication. I don't claim to represent the GeoJSON working group, many of whom are big Safe fans, and I do think it's great to have vendors involved. Like Cadcorp's Martin Daly, who started the group, and gets no mention at all in the article. At any rate, it's too early (IMO) to start advertising GeoJSON support. I think that goes for GeoServer as much as for any proprietary product.

Better Python Practices for the GeoWeb

It pains me to see novices taught poor Python programming practices, and so I can't resist making a few corrections to this post. Processing and marking up data into KML is a simple task that can be used to teach better practices. Here are 3 easy ones:

  • abstract access to file-like resources with urllib;
  • iterators and generators;
  • XML templating with Genshi;

Here is a script that reads in a FIRMS text file and writes out a KML document named fires.kml:

import urllib2

from genshi.template import TemplateLoader

def collect_latest_fires():
    f = urllib2.urlopen('file:N_America.A2007275.txt')
    for line in f:
        fields = line.split(',')
        lat = fields[0]
        long = fields[1]
        confidence = fields[8]
        coords = '%s, %s' % (long, lat)
        yield {
            'name': 'Wildland Fire at %s' % coords,
            'description': 'Confidence: %s' % confidence,
            'coordinates': coords
            }

loader = TemplateLoader(['.'])
template = loader.load('template.kml')
stream = template.generate(collection=collect_latest_fires())

f = open('fires.kml', 'w')
f.write(stream.render())

The input data file is hard coded in the collect_latest_fires function, but it's trivial to calculate the name of the latest data (A well-managed site would probably call it current.txt). You can get the input data via FTP or HTTP by using the proper URI scheme:

>>> f = urllib2.urlopen('ftp://ftp.example.org/current.txt')

By virtue of the yield statement, collect_latest_fires is a generator, an iterator that keeps track of its own state and computes values on demand. Iterators are a key element in Python programming. Note that Python file-like objects are themselves iterators. If you needed an actual list of fires, you could create it from the generator like so:

>>> collection = list(collect_latest_fires())

This generator function is the bulk of the script. The remainder simply loads a Genshi template, generates an output markup stream using an iterator over the latest collection of fires, and then renders and writes the stream.

Here is the KML template:

<?xml version="1.0" encoding="utf-8"?>
<kml
  xmlns="http://earth.google.com/kml/2.1"
  xmlns:py="http://genshi.edgewall.org/"
  >
  <Folder>
    <Style id="fireIcon">
      <IconStyle>
        <Icon>
          <href>http://maps.google.com/mapfiles/kml/pal3/icon38.png</href>
        </Icon>
      </IconStyle>
    </Style>
    <Placemark py:for="item in collection">
      <name py:content="item['name']">NAME</name>
      <styleUrl>#fireIcon</styleUrl>
      <description py:content="item['description']">
        DESCRIPTION
      </description>
      <Point>
        <coordinates py:content="item['coordinates']">
          LONG,LAT
        </coordinates>
      </Point>
    </Placemark>
  </Folder>
</kml>

Use well-engineered templating systems and/or serializers to create KML. Do not concatenate hand-coded strings of angle brackets. Templates like the one above can be run through your favorite XML tools to insure that they are well-formed. You can't do that with your Python code. A good templating system also handles the encoding for you.

Finally, since the FIRMS source data is changing only once a day, you should be running the script above no more than once a day. Don't use it as a CGI. Transform the source data to KML and write it to a file under your web server. Configure your web server to provide the application/vnd.google-earth.kml+xml content type for the KML and also set the HTTP Expires header to the modification time of the file plus 24 hours. That's a recipe that scales.

Comments

Re: Better Python Practices for the GeoWeb

Author: Kristian

Bookmarked. Now I'm just waiting for part two, "TurboGears and Shapely vs. GeoDjango" ;)

Re: Better Python Practices for the GeoWeb

Author: Sean

TurboGears and Django overflow with good practices, so no need for that sequel.

Open Source and Sustainability

Open source software has a big role to play in sustainable development. In the closing session of last month's FOSS4G conference, the committee that will be hosting next year's conference in Capetown (congratulations!) reminded us that the South African government is committed to open source software. Getting locked into buying proprietary seed is not the way to sustainable agriculture, and getting locked into buying boxed proprietary software is not the way to sustainable digital enterprises. Where is the sustainability media on the subject of open source?

Comments

Re: Open Source and Sustainability

Author: Guillaume Sueur

not sure that sending most of the attendees on a more than 10 hours flight is the best one can do for sustainable development. Bring your seeds, and plant a tree !

Re: Open Source and Sustainability

Author: Yves Moisan

"sustainable digital enterprises" : I like it. I have been looking for an equivalent of "développement informatique durable" for a while. Guillaume : I see your point, but where would be a location that would minimize the global footprint of attendees, given we can consider this is the only important variable (which of course it isn't) ? And don't forget : folks from down under will want to have their take one day too ;-) Cheers, Yves

Re: Open Source and Sustainability

Author: Sean

I'm with you there, Guillaume, but even if many of the 2007 attendees stayed home for environmental concerns, it's important to have the next event be near to developing countries. The 2003 MapServer Users Meeting triggered growth of the open source GIS community in North America, and FOSS4G 2008 should do the same for Africa.

Open Source Web Processing Versus ArcGIS Server

James Fee looks at Christopher Schmidt's WPSServer and writes:

Now this of course won't replace the complex analysis that ArcGIS Desktop or even ArcGIS Server can accomplish, but why not use such lightweight tools for lightweight needs?

A RESTful web geo-processor that provides a DSL for describing complex processes and analyses (my preference would be for Javascript ala CouchDB, and I'm hoping to find funding to develop such a thing and make Mush a more powerful tool for the digital humanities) and lets users create new processing resources from these scripts could certainly begin to replace ArcGIS Server. I'm a regular user of open source software that generates Python workflow code from UML, and I can imagine something like ArchGenXML coming to the aid of people who like to draw their processes graphically.

Using New Technologies to Explore Cultural Heritage

I thoroughly enjoyed the privilege of attending the NEH/CNR conference on "Using New Technologies to Explore Cultural Heritage", but was a bit crushed to learn that I missed meeting Dan Cohen. His book, "Digital History", has been a very important reference for Pleiades and I am a big fan of his blog. Cohen has written a detailed review of the conference.