Next steps for mashups

Just read Schuyler's thoughts on Web Map API's over at Mapping Hacks and he ends with a query about the next stage of the game for web mapping. I'm pretty sure I know where he's going, which I'm planning on exploring fully here (been planning for awhile, but I'm still not giving up, I promise), but I had a few thoughts at this nice LI Conference hosted by Directions.

The main thought is really quite simple, on how we take an intermediary step to the full on Geospatial Web dreams. It's this:

Yahoo!, Microsoft and Google need to build in GeoRSS output in to their mashup APIs.

At this LI conference, the vendor guys were actually getting quite good talking about GeoRSS, and how they can read it in. Which is sort of interesting to me. But what gets really interesting is when they can output GeoRSS by default. This turns any mashup in to Drive By Data and the essence of Tim O'Rielly's Architecture of Participation (mine's a bit more on top of that) – that users will create things of value simply by doing what they're doing already.

It makes it so I can build a mashup that is just a synthesis of three other mashups, from Yahoo! and Microsoft, since by using their API a hacker would have (perhaps) unknowingly made a GeoRSS feed of the points he was plotting. Right now that's impossible unless the mashuper explicitly make their data available. Many just put it up in a simple xml format already, but by building GeoRSS explicitly in to the mapping engine, it will always happen. Once this gets started, you can start to see what GeoSpatial Search would look like, and these search engine companies can apply what they know best to maps. Not just finding local information, but allowing us to search and sort layers of data that users from all the world are putting up on mashups. Yahoo! is making some traffic feeds and whatnot available as GeoRSS, but they're not yet making it so anyone who makes a mashup has a feed that someone else can attach to, in the way that flickr or does.

Once this happens, will see the start of real mashups, not just attaching data from one db to a silo of information, but allowing mashups to interact, to overlay housingmaps with a crime map with a pollution map with a starbucks location map, to see how housing prices are affected by such things. You start to enable citizens to discover interesting trends spatially, instead of just sitting back and letting a programmer/masher decide how things should be overlaid. The GeoSpatial Web becomes richer, lowering the bar so that it's not just javascript programmers who can display data how they want, but so that it's really anyone.

And once we make the first step with GeoRSS, then we can start to get WMS and WFS, to combine with the rest of the Geospatial Web, so that we're not in divergent walled gardens, but instead all speak the same language and start to build something much bigger. But even if they just start with GeoRSS then I can just make a datastore in GeoServer that can translate from GeoRSS to the richer display options of WMS and deeper query language possible with WFS.

8 thoughts on “Next steps for mashups

  1. You are absolutely, right. I think many software developers, particularly those that develop user-facing software such as Google Maps, etc. tend to think of their software as client software. This is limiting because it locks them into thinking in terms of consuming data, not of producing data. If every time someone developed a bit of client software, they thought about how they could fulfil the role of being a server, then your idea of serving GeoRSS would have come naturally.

    Thinking always of how to “be a server” is a good exercise and helps you to develop a mindset of giving something back. If all you do is consume data and help people put the data onto/into your stuff, then you should not be surprised if you find few good data producers. If, on the other hand, you also produce data, then you’re helping enrich the world.

  2. Great ideas. I’ve been advocating this as well — the APIs could offer another view producing GeoRSS, accessible to any-one or -bot by adding an argument to the URL of the mashup; or maybe by a flag in the user-agent. Problem is the aggregators would need to execute javascript to produce the GeoRSS. Or the APIs would need to offer a hosted service doing the translation.

    I experimented with this idea in the Google Maps Hacks book,%20section&xmlid=0596101619/googlemapshks-CHP-5-SECT-9&k=20&g=&srchText=%28rss%2C%29+AND+%28ISBN+LIKE+0%2D596%2D10161%2D9%2C+0%2D596%2D10161%2D9%29&code=&h=0&m=&l=1,%201&j=list&catid=&s=1,%201&b=1,%201&f=1,%201&t=1,%201&c=1,%201&u=1&r=&o=1&n=1&d=1&p=1&a=0&page=0

    It’s a bookmarklet which extracts GeoRSS from some gmaps mashups

  3. We have incorporated reading and displaying GeoRSS into our client product, and the next experiment is to have our Catalog generate and catalog GeoRSS. My thought is that it is a simple way to deliver results of standing queries for geospatial services and data. The GeoRSS would hold the footprints of the data set that users could see on a map display.

    I really haven’t thought of GeoRSS as a datastore, but that’s a good idea as well and easily implementable from a read-only standpoint. Do you think that a transactional GeoRSS is a good idea? I’m trying to see a use case for it beyond simply using GeoRSS as datastore format.

  4. My thoughts behind promoting GeoRSS as a datastore are basically that it makes geo easier to understand. The GeoRSS GML profile is still GML, but any one can understand it. I think a transactional GeoRSS datastore will make more and more sense, but the thing to be worked out firt is what a transactional RSS store would look like. Google and Microsoft both seem to have ideas, so we’ll have to wait and see how it works out. But since GeoRSS is sort of the web oriented Geo XML format, we should follow what’s being done on the web, as opposed to the normal OGC route of inventing it themselves, then attempting to reconcile the difference. Of course we can allow people to update their GeoRSS output by using WFS-T and GML in the meantime, but I see no reason to start bending WFS-T to GeoRSS specifically.

    So the ‘use case’ is simply that if RSS is moving towards a read/write direction, we want GeoRSS to be right at the forefront, and perhaps it ends up as the more accessible WFS-T.

  5. Pingback: GeoRSS blog » Blog Archive » GeoRSS and Mashups
  6. I agree about OGC constantly reinventing the wheel; I guess every Sisyphus has to have very own rock.

    Either through sheer genius or a fortuituous act of ommission, OGC has so far not defined a client interface. This is wonderful because it does not inhibit an implementation from adding new formats to a W*S. So outputformat=KML and outputformat=GeoRSS are already a reality; and outputformat=ppt and outputformat=podcast are obvious choices for implementers.

  7. Pingback: Mapping Hacks » Blog Archive » there will, if necessary, be a grass-roots remapping.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s