Thu

May 4
2006

Nat Torkington

Nat Torkington

Where 2.0: Standards

As the number of mapping platforms increases, standards start to be more important. If upcoming wants to offer access to its database for people to include in their own mashups or applications, what data format or web services API standards should they adhere to? Upcoming has chosen to use GeoRSS, a light-weight standard rapidly gaining traction. But there are others ...

GeoRSS arose out of this need to share lists of points. Google Earth had a similar need several years ago, and created KML (Keyhole Markup Language) for its particular needs. KML is like GeoRSS, but with camera angles, styles, overlays, and many other presentation features built in. There is, naturally, a small religious element to any discussion of whether a feature markup language should have styles included or whether they should be separate (a-la CSS).

GeoRSS and KML are data interchange file formats. The Open Geospatial Consortium standards defines the GML format, which KML bears some resemblance to. GML is notorious for being a superset of features of the products whose companies worked together to define the format. This means that it's complex and quite scary--KML is more accessible, and GeoRSS even more so.

The OGC also defines several web services: WFS (Web Feature Service) and WMS (Web Mapping Service) are the two big ones. WMS describes the basic map (either as tiles or as lines) and WFS describes the features on that map. NASA Worldwind gets its imagery through WMS, and they're adding WFS support. It's the only one of the major Internet mapping paltforms (Google Earth, Google Maps, Yahoo! Maps, Virtual Earth, I'm looking at you) built on top of the OGC standards. There are hacks to get Google Earth to display WMS data, and if you buy the full Keyhole product then you get WMS display. I've also seen a smattering of Google Maps mashups with OGC standards.

Why are WMS and WFS important? Because all the traditional GIS applications support them, as do storage systems and analysis tools. When you graduate from a hack to really building location intelligence into your application, you'll want to start using some of these sophisticated tools. For example, you might want to start using PostGIS, the geospatial extensions to the popular PostgreSQL open source database so you can easily search by location. Or you might want to use the GRASS open source GIS for entry and analysis. Or, of course, you might buy commercial systems from ESRI, MapInfo, or others.

So open standards are important because they let you move from mashups to infrastructure. That's why we've scheduled talks on GeoRSS, the OGC activities, ESRI, and GRASS. NASA Worldwind will be there, Google are scheduled to speak and I know they want to talk about Google Earth, Yahoo! and Microsoft will be speaking around new features in their mapping platforms, and AutoDesk will be speaking about their standards-compliant MapGuide Open Source.


tags:   | comments: 4   | Sphere It
submit:

 
Previous  |  Next

0 TrackBacks

TrackBack URL for this entry: http://blogs.oreilly.com/cgi-bin/mt/mt-t.cgi/4639

Comments: 4

  Marshall Kirkpatrick [05.04.06 10:27 AM]

Whatever Upcoming has done so far, it doesn't seem like there's been much uptake of the service's API. Maybe I'm wrong, but I went looking awhile ago and couldn't find many at all.

  Fantom Planet [05.05.06 03:59 AM]

I was discussing with someone the other day about standards, geospatial standards in particular. And I was trying to wrap my brain around how long it would take to develop an open standard and for a number of robust tools to be developed to handle those standards. There's not too much out there besides WMS and WFS tools. Some of the free tools, could use some improvement, and the commercial tools need to change course to accept/output open standards.

So, yes, GeoRSS is emerging to be the best thing since sliced bread. Everyone's hope is to get the non-geogeeks involved in marking their territory and telling their stories with out having to go through ESRI school. But how soon will there be tools to handle the information from GeoRSS feeds?

Look how long it has took to develop decent, not good, feed aggregators. How soon can World Wind, Google Earth, and all of the other "slippy map" providers build tools that will read, and create, GeoRSS?

I really hope to interact with Raj and Mikel at Where 2.0 about this.

  Harvey Appelbe [05.05.06 05:56 AM]

I attended Direction's recent Location Intelligence conference. There was a session on interoperability where the facilitator asked vendors 'when will your product plug and play with your competitors'.

It became very clear to the audience there were two camps:
1. Traditional GIS vendors: "life is very complex, you can't just rush into interoperability, we don't really want them to be able to unplug us"...so you have OGC WMS/WFS.
2. Y!, Google & MSFT; "we want to organise the world's information, some if that is spatial, you hold it, we want it"...so you have GeoRSS.

The take home message for the audience was: if you're a mapping agency try use OGC WMS/WFS, if you're the rest of the developer community us GeoRSS.

If the adoption of location is dependent upon commidisation (e.g. mash-ups), it would be valuable to revisit vendor attitudes during Where2.0.

Aside: I'm being a little unfair, the guys behind FME highlighted OGC's SF-GML as the new standard for the masses.

  Carl Reed [05.05.06 09:14 AM]

Nat -

Great note! I have only one clarification - GeoRSS is not a file interchange format. From the GeoRSS web site: GeoRSS describes a number of ways to encode location into RSS feeds. As RSS becomes more and more prevalent as a way to publish and share information, it becomes increasingly important that location is described in an interoperable manner so that applications can request, aggregate, share and map geographically tagged feeds.

I should also point out the GeoRSS is very well grounded in existing standards work. The geomtry is based on the ISO/OGC feature geometry model. And there are two flavors of GeoRSS: Simple and GML. The GML flavor is based on a very restricted subset (or profile) of GML 3.1.1 but is highly extensible.

As to implementations of GeoRSS, there are a number out their already with many more in the works.

Thanks again

Post A Comment:

 (please be patient, comments may take awhile to post)






Type the characters you see in the picture above.