My thoughts after Where 2008...

In my view, the "Where 2.0" movement/phenomena is about the democratization of mapping - remix this, mash in that, geocode it and get it on a map. My Map. With My Stuff and My Friends. Social graphs and all that. For many things, "close" really is good enough, and since it's "your" data, validation is less of an issue ( did you "really" like that pub? ) . Usability and performance are huge driving factors because many of these sites rely on users "wanting" to participate. This is driving the rapid evolution in terms of user experience, and poorly designed or slow sites fade quickly.

Meanwhile back in "GIScience"-land, the hard-core old guard have railed against pushpins as too simple, in-accurate or just lame. Not sure why there is so much insecurity, but maybe it's just a little envy that a bunch of javascript hackers made maps "cool". Many GIS applications have a "captive" audience (i.e. staff who have to use the site to do their job), usability has been low on the list, and performance an after though. The emphasis was placed on trying to cram desktop type work-flows and interaction models into a browser. Needless to say this has its drawbacks.

Not to use the John Hanke and Jack Dangermond session as too much of a metaphor, but these two camps seem to be coming together, or at least recognizing they both bring something valuable to the table. Sure there is still lots of misunderstanding, but things are getting better. Many of the "mash up" people I've talked to are realizing that the next step is to add spatial analysis. Not buttons & dials type analysis for the sake of it, but leveraged in context of answering a question. Sure the social graph is cool, but there are all sorts of new and interesting ways to leverage that when used in conjunction with spatial analytics. It opens lots of new scenarios. There is a realization that the scientifically backed, validated data has serious value in addition to "my data" or crowd-sourced data.

Going the other way, the GIS crowd (sadly under-represented at Where) is coming around to the idea that even their "captive" user base appreciates (or demand) a good user experience - design & performance matter. A lot more than they thought. And maybe it does make sense to dial back some of the "science" options in order to optimize performance. Some times "close" is good enough, and the performance trade off to get to "really really really close" is not always worth it.

This is a good thing and the whole industry / community will be better for it. GIScience sites/services that embrace the usability and performance of the neogeography sites will flourish if for no other reason than their users "like" using them. And if you're a social site looking to stand out, adding a shot of analysis into the sauce may be the trick.

It's been fun and I'm leaving with a head full of interesting ideas.

If you are presenting...

A parting word for anyone presenting at Where (or anything else) - Please please please read Presentation Zen (the book & site) before you show up.  I (and others I talked with) had really expected that these presentations would be on the level of TED - sadly this was the exception, not the norm. There were some big name companies up on stage with horrid slide decks - some were literally painful to view. Sure you have a cool 3 minute video that's super slick, and you likely spend 500K on, but following that with a jumble of bullets on neon-green background with heinous clip art some what spoils the effect. If you have 15 minutes in front of a crowd of thought-leaders, maybe you should spend more than 15 minutes on your slides.

Since there many other people are blogging the details of Where, I'm just going to take notes about the ideas that resonate with me...

Make your maps permalink friendly: Everyblock.com has a Uri hierarchy (RESTy?) that makes sense, and allows deep-linking and deep-search.

Need to do more than points: deal with "areas" - neighborhoods, routes etc. Especially relevant for geo-locating events/stories, where push-pins over simplify. The situation.

Roll your own maps: make the map relevant for your users. Don't show what you don't need. Control the look & feel of the cartography and make it part of the site design.

Federated Geodata: (Sean Gorman) someone other than ESRI talking about breaking data out of the silos. Not much detail on the "how", or synchronizing updates, but maybe he'll post more details.

GOOG & ESRI: Enabling data sharing / deep indexing. Good demos of ArcGIS Server analysis fronted by a consumer UI experience - geoprocessing in Google Earth. The "real" application were a change of pace - not that "my friend recommends the calamari at this place" isn't useful, but real-time forest fire modeling / evacuation planning just has a little more "bite" to it. 

Overall, an interesting morning. The John Hanke and Jack Dangermond session certainly got people talking - and that's always a good thing.  Should be interesting to see how many groups open up their ArcGIS Server 9.3 systems to Google's indexing. Discovering data that's been walled off for so long could be really interesting.

More later...

So the session was hampered by some corrupted data on the USB sticks, and was more a loosely guided tour of the stack than anything else. I had PostGIS up and running, but could not get my data (loaded into ArcSDE on PostgreSQL using the PostGIS datatype) to load into GeoServer. Tried some other data, and same problem. Unclear what the issue is.

Many of the sample SLD's would not validate (hence could not be loaded), and I could never get the WMS group layers to work. I did get some data up in Google Earth, and open layers, but overall this session confirmed for me that the open source stack learning curve is steep from the get go. I need to get into OpenLayers as the demo's were pretty cool but until I can get the back end all working smoothly it's somewhat moot.

I think that the docs for this will be up somewhere. The software installers are below.

Downloads: http://files.opengeo.org/where2/stick/software

Grass roots re-mapping efforts, focused on Europe. Crowd-sourcing. Pretty nice cartography. See the maps here: http://www.openstreetmap.org/

Note the pubs shown on the map via the Pint glass on the map. Nice.

Has features not in other maps - foot paths (dashed red lines), Pubs etc.

Starting in the US based off Tiger data, and updated.

The Back-End Story

Simple data model. Nodes, Ways (lines, or polys if node1 = nodeN), Relations

Runs on MySQL. 30,000,000 records. All changes stored. No "geo" columns, just points. Use scaled integers instead of doubles, and some saucy indexes. "SDE like" tiled indexes.

Planet.osm - rendering format in Xml. ~4Gb. Released weekly. From there you usually load it into PostGres with a Geocolumn, and then push this out via Mapserver, or GeoServer, or subset as you need.

Site runs in Ruby on Rails. OpenLayers for the slippy map. Off-line and on-line editors. All stored in Subversion

API was RESTful from day 1. http://www.openstreetmap.org/api/0.5/node/45

Tags - What is it?

Every object has keys and values associated with it. Community process for selecting keys and values. Keys and Tags must be approved, or features will not be on the map. There are 100's of tags.

Current Rendering

Mapnik (apparently easier and simpler than MapServer) c-based tool that uses a huge Xml file for styling (looks like SLD?). Runs off the Postgres version of the OSM data. Tiles are created on request, and cached. There is a background tile cacher daemon. Tile cutter is on one box, cranking like 20 million tiles a day.

Osmarender - Xml --> Xslt --> SVG. Slow to convert. Rendering is done across a network of end-user PCs. 

Tiles match the Google scheme, which makes mashups easy.

Now moving onto mobile platforms

OSM is topological from the start, so it supports routing. Currently there are some simple routing options, but until the data density is higher, it's not too useful. High-performance routing is CPU intensive, and no plans to add that as a service.

Lots of other projects going on, so check it out over at openstreetmap.org.

Ok, hopes for a Bruce Lee javascript smack down were thwarted when Andrew started off with "this is Where 2.0 101".

Started out with a quick run over the common formats - GeoRSS, KML and Microformats.

Microformats - additional HTML markup that are conventions for geolocating content. geo & adr for lat/long and address.

High-speed review of REST with "spiffy diagram"

Must do some reading on Atom - maybe have lunch with local Atom fan-boy Sean Gilles

What is Mapstraction?

Javascript mapping API wrapper covering least common denominator functionality across 9 or so map platforms. Essentially a layer of indirection that will allow you to change the back-end (i.e. Google Maps to Poly9) without breaking your application.

It can do image overlays - which is nice because you can then push very dynamic data (i.e. data that can't be tiled) into the map.

Nice tile layer schema for roll-your-own tile services

GeoRSS and geojson direct consumption.

Support Filtering by a range of things - category, date etc.

It does not break terms of service - it still uses the underlying API's, so the tile providers are cool with using this.

Still allows you to go below Mapstraction to the underlying provider. So, you'd be able to write most of the site in Mapstraction, then jump down into some VE/GM specific stuff if you need to (obviously this limits how you can change between the back-ends)

OpenSearch: Expose the search interface for a website directly into a browser search. Details at opensearch.org. OpenSearch-Geo - extensions to support location strings. Supports location name, lat/lon + radius, bbox.

This is very cool - need to push this into some of our sites.

Mapstraction is BSD license so do what you like.