The Google Cr-48 Netbook, Chrome OS and GIS

I’m rolling here with the Google Cr-48 Netbook and after a weekend with it I’ve come to some conclusions about how we work with GIS data today, how we’ll work with it in the future and what it means to try and use one of these cloud netbooks in 2010.  I won’t rehash what others have said about the hardware, it’s really bad in places (the trackpad on it could be the worst input device in 20 years), but it does give us a glimpse into where many of us will be in December 2011.

First off, moving between the Cr-48 and my iPad is pretty easy.  Both boot up almost instantly, don’t have hard drives, are connected to the Internet via WiFi and 3G and break the traditional concept of a file system with your OS.  Browser-wise, they are both derivatives of WebKit so they handle most of the latest JavaScript apps with ease.  There is some issues with lag on the Cr-48 vs the iPad on these web apps, but I have to assume when Google Chrome OS is release, it will be as snappy as Chrome is on my Mac or PC.

A quick spin to WeoGeo Market seems to show that the Chrome OS is just as compatible with as the the Chrome browser is with existing websites. (no duh, right?).  I was able to order a dataset, save it to the the Chrome download folder (or whatever this disk space is called in the Chrome OS) and forward it on to a friend.  While I can’t really work with shapefiles (yet) on the Chrome OS because you can only run web apps, you can still work with files and even upload them to websites to share.

As you'd expect, the WeoGeo cloud works perfectly on Chrome OS

My next stop was Esri’s ArcGIS.com and their web map app.  Works just as you’d expect (at least when you fight through the trackpad), but I was shocked when I tried to view some of their Flash API maps.  Chrome OS ground to a halt.  Adobe says they are “totally on this” (paraphrasing), but it is yet another reason to question why anyone would built apps with Flash anymore.  Hardware on these Chrome OS netbooks is going to be very weak, so much like we’ve seen on Android, Adobe better be really good at making their plugin run on these minimal configurations.

Stick to the Esri JavaScript client for now with Chrome OS Netbooks

So just to be safe, I dropped into Geocommons to see how their flash front-end works.  As with Esri’s Flash API, it gets there, but the Netbook practically just stops responding when working with it.  At least Geocommons has a workaround, you can append ?view=javascript to the end of any map url and get the JavaScript version which works great in Chrome OS.  You lose come functionality, but at least it works and works darn well.

The Geocommons Flash frontend works, but causes the Netbook to stutter. Google and Adobe need to fix this pronto.

Geocommons JavaScript front end works great, but isn't as feature complete as their Flash front end.

A quick check at the Esri Silverlight Showcase returns what you’d expect with Chrome OS.  It is a JavaScript and Flash world at Google and at least for now, Silverlight isn’t part of it.

Yea, you'd expect this. The problem is that Netflix doesn't work either. Bah!

Yea so don’t rush out and try and buy one of these Cr-48 Netbooks if Google wasn’t nice enough to send you one.  They are really not usable as an every day device today.  I’m sure as we get close to the release of these Google Chrome OS Netbooks next year, the OS will become more stable and usable.  That said, the writing is on the wall for traditional apps.  Niche use is all we’ll see of them moving forward.  Google, Apple, Microsoft and others are all committed to running consumer apps as hosted services and these Netbooks (plus all the iPads and Android tablets that are going to be sold next year).

Now don’t think for a minute that I’m talking about ArcView in the Cloud or any other wacky thing that someone might come up with while drinking some GeoKool-Aid.  No, I’m talking about eliminating the need for ArcView on 95% of all desks and using web apps for these people to work with the data.  Those that need the editing and analysis capabilities wouldn’t be on a netbook in the first place so they are really unaffected by these changes.  But I just can’t see how any organization can afford to pay for ArcView (or MapInfo, or whatever) licenses for users that are viewing data.  We’ve been talking about how those days are over for it seems like a decade, but I think the pieces are coming together in 2011 to finally put the fork in apps such as ArcView (real GIS pros need ArcInfo, sorry Esri), Microsoft Office and other “enterprise” apps.  Geo isn’t special enough to need hundreds or thousands of ArcView’s on desktops across the organization.  Time we started facing up to the fact.

Navigating Washington

Just the other day we were wondering over the RSP Architects coffee machine about if GeoCommons would ever have an API.  Rather than actually ask Sean if there was one in the works, it is of course easier to forget about the conversion and wait for Sean to blog about it himself.  What I assume is one of the first GeoCommons API (this example is running on Amazon’s EC2) applications out there, Navigating Washington which allows real time poll mapping in your browser or even a Blackberry or iPhone (no Windows Mobile device because no one uses those anymore).  I find the application very interesting and integration with mobile devices is a smart idea.  I’m anxious to see what Sean has planned with the API and how we can use it.

 

What cant maps do for you these days?

What can't maps do for you these days?

Sharing the File Geodatabase

There are really good reasons to use the File Geodatabase in the ESRI world over the shapefile and Personal Geodatabase, but it doesn’t mean it is easy to share.  Sean Gorman knows that the more file formats he supports, the more likely people (especially GIS pros) will be using GeoCommons.  I suppose the simple answer for Sean is to buy a license of FME Server and support everything and anything people upload.  The cost of that solution might not make business sense just yet for him so I suppose is the lack of ESRI Geodatabase support (or any other format) limiting you when you want to share data?  I like the idea of uploading a Geodatabase full of datasets at one time, but sharing a folder/file based dataset is difficult enough on a LAN, let along the internet.  Is converting to shapefiles too much to ask for people who want to share data on services such as GeoCommons?  

WeoGeo partnered with Safe Software to bring this kind of datasharing (among other features of FME Server) to the cloud web so there might be solutions that are cheaper than outright licensing FME Server to bring translate capability to Web 2.0 services.  If that can be coupled with Amazon Web Services pricing (pay for what you use rather than a traditional license) there could be something that many people take advantage of.

 

And of course you could export out any layer in GeoCommons Finder! to any of the 200+ FME supported formats.

And of course you could export out any layer in GeoCommons Finder! to any of the 200+ FME supported formats.

GeoCommons Maker! – the next day

Well kudos for FortiusOne for getting the word out on Maker! especially since the launch was delayed from the original PR blitz.  As with most GeoBloggers, I’ve had access to Maker! since last week and have really been impress with its output.  Sean has been teasing us for months it seems with the cartographic output of Maker! in his blog posts, so I was glad to finally get my  hands on Maker!. (side note, do you put a period after a product name that ends in a punctuation mark?)

Maker! is the map production portion of GeoCommons and Finder! is the search engine for geospatial data.  Together they allow users to create web maps that can be shared with the world.  So to get information in Maker!, you first upload your data to Finder! and then add it to your map.  The byproduct of this workflow is more data gets added to Finder! and in turn more data is available to the community at large.  Freely sharing data is one the core components of GeoCommons (compared to WeoGeo which is more of a marketplace).

Stefan Geens does a good job of showing how the map is created and how you set what we usually refer to the symbology of layers.  What I like about this approach is you can bring to light the data in ways that before Maker!, required custom programming to achieve good looking results (if even possible).  FortiusOne, according to Sean, worked with cartographic professionals to create the rich (I’m sorry) map production tools.  These tools are so good in fact that I’ve heard a couple GIS professionals lament that they’ll be out of a job soon (of course we all know that Maker! will only increase our workloads to produce data for public consumption).  What we have here are two really simple tools that allow anyone to upload geospatial content, combine that information with other datasets and then create a wonderful looking map that visually tells a story.

You can argue all day and night about what the GeoWeb is or isn’t, but I think we have an excellent example of what the GeoWeb should be right here.  Finder! has discoverable web services of data (with metadata to boot) and Maker! allows you to leverage those services together to create derivative value content to share with the world.  Moving forward, the data of GeoCommons should support more OGC services (beyond KML) for those who need that support and the maps created with Maker! should be more easily shared beyond just an web map.  But the groundwork is there for sharing data with the world.

Despite the lack of monkey maps, the GeoMonkey approves of Maker!

Despite the lack of monkey maps, the GeoMonkey approves of Maker!