I got a bit wrapped up trying to get a side project finished up yesterday, so I’ll just skip to day three of ETech. The morning opening speakers were better that Day Two, although the session thus far have been a bit below Day Two’s. We kicked off the morning with an abbreviated talk by John McCarthy (father of LISP) on a new language he’s working for several years called Elephant. The elephant name coming from the fact it never forgets, and the broad concept of a semantic programming language that can create structured relationships from natural language. Unfortunately he ran out of time before he really got into the guts of it, but there were some fascinating concepts with how natural language can be leveraged in a structured way to do computation. Definitely something worth looking into more, and it reminded me a lot of our thoughts about a context driven architecture and natural language for data. Although we were looking to turn quantitative data into natural language versus turning natural language into data.

Following McCarthy’s talk there were some interesting bits on open source personal robots, then an informal launch on Yahoo’s Fire Eagle. Fire Eagle has taken some flack in the blogs for having minimal or “zero” functionality. I think this misses the point of what Fire Eagle is intended to do. My impression was that Fire Eagle is not meant to be a stand alone consumer application but a straight forward tool that does a simple thing very well. That simple thing being a platform for sharing your location online. The functionality folks are clamoring for is left to the users and developers and I think there are good number of fun possibilities here. For instance with GeoCommons we have big pile o’ data and would be very useful to personalize that data delivery to a users location, or have user have the ability to comment on that data from their location and have that comment geo-located. This creates a dependency on clever users, but form what I’ve heard floating around ETech there seem to be a good number of clever ideas floating around.

The last session of the day I attended was Mikel and Jesse’s presentation on “Disaster Tech”. I’d seen Mikel’s presentation at the State of the Map conference on open source disaster technology, and it was cool to see how the project has evolved. The whole topic is something close to us, especially getting up close doing disaster response after the London Bombings and Hurricane Katrina. The presentation has some great examples of Open Street Maps, Twitter and Google Maps being used in creative ways during disasters. Mikel gave a nice example of using the USGS GeoRSS earthquake feed, the EU lightweight tsunami propagation model and a feed to republish the resulting polygons as GeoRSS. With this approach they can churn out a polygon warning area in under a minute. A similar concept is seen at the United Nations – GDAC application.

All great stuff for ad hoc implementation that is cost effective and not over engineered. Lots of good discussion of how take the information produced by technology and effectively transmit it to non-technical or completely unconnected people. Also Jesse and Mikel had a nice bit at the end of the presentation on anti-patterns – i.e. what happens when you don’t have a champion for the technology to create repeatable and successful implementations. Specifically the case of the search for Steve Fosset where the crowd sourced help to find him actually slowed down the search and rescue teams having to deal with all the input. Resulting in the emergence of champions like InternetSAR that creates a structure that could be replicated and effective for search and rescue. Lots of good thought on an important topic

Popularity: 14% [?]

Yesterday we posted a blog about the international fiber cuts a few weeks ago. While I am interested in the geography of fiber and failures in general, we thought it would be a good opportunity to put Google MyMaps through its paces for creating a substantive data driven map. After 25 or so hours of collective labor I thought it would be useful to give the postmortem on our experience.

While there are many positive qualities to Google MyMaps the biggest complaint is that we spent 40 hours mucking about with it. The goal for the last blog post was to create a map that had 1) the fiber routes and landings for impacted carriers, 2) the location of the fiber failures, and 3) the countries that lost connectivity because of the failure. Seemed like a straight forward set of goals and I naively thought we could bang it out in a few hours. So, what ate up our time? Could we just be cartographically challenged?

1) Creating country boundaries – tracing all the countries with outlines so we could make polygons for the failed states was a big sink hole of time. The worst part was when we were not quite complete we hit the limit for the number of points a MyMap could support. Thus it was unfinished and did not make it to the blog post. If you are curious at what point MyMaps bonked here is the map:

View Larger Map

I’m trying to convince someone to count all the points so we have a numeric threshold but I think I need to offer more beer to get the bribe to work. The limit I’ve seen for number of points a My Map can support is 150, but it looks as if we exceeded that for drawing polygons.

2) Dealing with multiple layers – since there were three distinct layers to our MyMap we thought it would be useful to separate them out so the map would be easier to understand. The issue is that you can’t embed a Google MyMap with multiple distinct layers, they have to created as one continuous set. This was almost a deal breaker since we had broken up the work between three people (Bill Emily and myself). Fortunately we found a work around where we saved each of our maps/layers as kml then imported all three onto a new map (except Emily’s countries since it was the limit busting bonking layer).

3) Little bit of cartographic love – while push pins and drawing tools are great for posting pictures of my summer vacation some basic cartographic tools would have made life far easier. Dealing with the lack of a legend is challenging for conveying the story the map is telling. In MyMaps you get a list of every point on the map running down the right pain and with the embed you get nothing.

The conclusion at the end of it is MyMaps is a phenomenal drawing tool for maps – simple and intuitive. On the other hand if you want to create a data intensive map be prepared to run up against some technological limits, but more importantly be prepared to invest a good chunk of time. A large number of these limitations (need for enhancement) have been suggested in the MyMaps Google Group and it will be interesting to see if any are picked up in future releases.

* When I searched for other blog posts that have talked about the pros and cons for MyMaps I came up with zilch – making cross linking pretty tough. Interestingly the only comparison I found was for mapping service, but no one has compared the newer map creation tools. Maybe a topic for next time.

Popularity: 14% [?]

In a previous blog, “Fantasy Football Fun: A Look at the Offense Side”, Matia posted an intriguing comment: “It would be interesting to see if certain states are more likely to produce offense positions or defensive linemen — you could control for state population and see if California and Florida really can stand up next to some big stereotypical football states like Texas and Oklahoma.”

In an attempt to explore that issue, the hometowns of all defensive and offensive players on teams that were in the playoffs this season were scraped off of player profiles on espn.com, the numbers aggregated and geocoded to the state level and the information mapped in terms of both proportions and per capita equivalents.

Looks like, at least for the players whose hometowns were mapped, that Florida, California and Texas stand out as big NFL football player producers; however, the picture does indeed change quite dramatically when you control for population.

Proportion of Players by Hometown State

Defense

Offense

Per Capita Players by Hometown State

Defense

Offense

Other information that was compiled on the attributes of players by hometown states include: average years pro, average weight and average age of players. The full datasets for both offense positions or defensive linemen are available at geocommons.com for mapping.

Popularity: 15% [?]

Wanted to take this opportunity to let folks know that Chris Marentis has joined up with FortiusOne (check the new website) as our President and Chief Operations Officer. Chris was most recently CEO at Clearspring Technologies – the leading provider of cross-platform widget services. We are very excited and flattered that Chris has decided to come on board and he will be a great accelerator for the launch of the next generation GeoCommons. He has already had a huge impact helping us run things in a more smooth and targeted manner. We really look forward to the many good things he’ll have in store for the company as he helps us drive the next generation of GeoCommons.

We’ve gotten some great feedback on the GeoCommons beta and learned some valuable lessons on what works and what does not in fusing the GeoWeb and GIS. On the GeoWeb side we’ve been working hard on building the right work flow and user experience to make GIS data useful and exciting for non-technical users. On the GIS side of things we’ve putting lots of effort into providing tools to make GeoCommons an acceptable part of the GIS workflow – ranging from metadata to OGC standards support. Then using web services to bridge the two together with some semantic fun to intelligently serve and syndicate the best content, data and analysis.

For the current GeoCommons we’ll be in steady state mode till the next generation is ready to push out. In the mean time please keep all the great feedback and suggestions coming. We are working hard to make them a reality in the next release.

Popularity: 7% [?]