Tag Archives: rest

OpenPOIs Launches

Posted on by

I’ve struggled with writing the first blog post about OpenPOIs because there’s so much to say it’s hard to know where or how to begin. So after much procrastination, I’ll just start with the practical, tangible aspects and expand later on. OpenPOIs is an initiative of the Open Geospatial Consortium to build a global, comprehensive database of POIs — points of interest — which are basically all public places. The database is being seeded with existing open place databases such as Geonames and OpenStreetMap, and we plan to expand on what these great services already offer, by specializing in some key areas:

  1. OpenPOIs will index all web resources related to a POI as possible
  2. OpenPOIs will be the best source of correct place name spellings
  3. OpenPOIs will be multi-lingual
  4. OpenPOIs is open for third-party contributions and corrections

The system went public in alpha stage earlier this month with some US data. We are currently rebuilding the database with global coverage in preparation for a beta launch in a few weeks. It’s limited to a basic map and some read-only RESTful queries right now, with a full geographic search API coming soon.

Join the public announcement mailing list and read this blog to stay abreast of the advances coming soon.

Finally, for those of you interested in working with OpenPOIs, or building your own place name database or gazetteer, a “birds of a feather” interest group has formed with a mailing list here, and a monthly teleconference (join the list for access information).

OGC services and REST

Posted on by

Recently, the REST discussion flared up once again on the OGC’s Architecture Domain Working Group mailing list. Someone wanted to know if OGC had anything like a ranking of how “RESTful” each OGC web service was. The short answer is…of course, OGC doesn’t, and no one even knows how one would go about doing this objectively. I, however, took the risk of looking stupid and hazarded some ratings. Here is my post…

The fundamental problem with REST and GIS in my opinion, is that REST optimizes for data *access*, and OGC services are optimized for data *processing*. I consider GIS a type of OLAP system, and we as an industry will continue to resist REST because it would be counter-productive to expose data via atomic resources that all had their own URL (and metadata!?!) because everything we really want to do with the data would get harder.

That being said, here’s how I think OGC services fare…

If you look at the basic architectural constraints that REST espouses, OGC services do pretty well in general with their KVP interfaces (and don’t get too caught up in KVP vs. SOAP — Fielding’s original dissertation said there should be a place for FTP, WAIS, etc in the REST “church”).

However, when you get right down to the core concept behind REST — to identify and expose individual resources — our RESTfulness quickly breaks down. I’d say that WFS, SOS and WMTS do the best job.

WFS can be seen to expose each feature via a URL that doesn’t change (by doing a GetFeature request on the GML ID), and WFS-T gives you the create-update-delete functionality.

SOS does a similar thing with GetObservation and InsertObservation, but it could be more RESTful if GetObservationById was mandatory.

WMTS can be seen to expose each tile via a URL, but I don’t think it has create-update-delete functionality.

Of course, no service gets an “A” as we invent our own verbs instead of using HTTP GET, PUT, etc., but I’d give WFS and SOS and solid “B”, and WMTS a “B-/C+”.

I see WCS as failing utterly in RESTfulness, but it’s not the fault of WCS, but the inherent difficulty in creating a useful definition of resource when you’re modeling continuously varying phenomena. I don’t see it being very useful to call an entire coverage a resource. So I give REST a “D” in tackling the thorny case of imagery and environmental data sets.