2007 (old posts, page 11)

Atom feed RSS feed

WBW 33: Languedoc-Roussillon Values

body_html_template

Comments

Re: WBW 33: Languedoc-Roussillon Values

Author: Guillaume

Pic Saint-Loup is great. My favorite is Chateau de Lancyre : http://www.chateaudelancyre.com/vins/gdecuveerouge.htm Enjoy and feel Restful !

Re: WBW 33: Languedoc-Roussillon Values

Author: Marcus

Hey glad to hear it! (Ch de Lancyre was one of my more recent Languedoc tastings I uncorked from the region's awesome 2001 vintage.) Hope you all find a good bottle and contribute it.

Re: WBW 33: Languedoc-Roussillon Values

Author: Sean

Thanks for the recommendations. I'm also going to ask my wife to find something unique that we can't get here in Colorado, like a Mourvèdre varietal.

Re: WBW 33: Languedoc-Roussillon Values

Author: Sean

Well, no pure Mourvèdre came home with my wife, but she did bring back a couple bottles of good blog fodder. Also a Hortus Grand Cuvée Pic Saint-Loup and a Château Puech-Haut Tête de Bélier Rouge that are a bit outside the bargain price range.

WFS Simple

Raj Singh is working hard on WFS Simple, but I think it is still going to miss the "mass market" boat by a few steps.

Goodwill towards XSD is almost gone, for good reasons, and probably won't be coming back. XML Schemas will hinder adoption of WFS Simple.

We're only just beginning to see RPC-style services fall out of favor. Web architects and developers are more and more interested in RESTful APIs like the Atom Publishing Protocol than they are in SOAP lite. The OSM API, the OSGeo Tile Map Service, and MetaCarta's FeatureServer are only some of the first functional examples of the RESTful, web-friendly, geo services of the future. This is where we're headed. Eventually, WxS will be used almost solely for interoperation with legacy GIS applications.

By the way, I also still think the "mass market" term smacks too much of GIS elitism and exceptionalism. The geospatial industry and communities have a lot to learn from the Web and IT.

Comments

Re: WFS Simple

Author: Stefan

I agree with your thoughts about GIS elitism (or ignorance to mainstream IT?). But I don't see why WMS and WFS (simple) should be RPC-style? They are quite as RESTful as many examples you mention, aren't they? Regarding XML Schema: I've never been in favor of XML Schema but I don't think that it will go soon in face of so many existing tools and scholars. And if yes: What - better, non-XML(?) - alternative to take?

Re: WFS Simple

Author: Sean

No, Stefan, WMS and WFS Simple are not restful. There's more to it than just returning imagery or plain ole XML. From Fielding (6.5.2):
What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services.
Only very specialized clients and servers know what to make of WxS semantics, and this makes it much more challenging (for example) to use caching or proxying layers.

Dear Google Earth Team

Please consider giving your users the power to POST and PUT KML from Google Earth to arbitrary URLs other than http://bbs.keyhole.com. Anything you can do about this, Ed?

Comments

Re: Dear Google Earth Team

Author: Tom Churchill

Sean: It's a truism that the most likely way to convince another party to do something you'd like to have done is by making a convincing argument regarding what's in it for them, as opposed to you. While I can understand why you might want this feature, would Google? What would make them find this to be desirable? (IE: Would it generate more users for them?) They have invested millions of dollars in the development of the application and acquisition of imagery, and provide the resulting application/service for "free". (I'm sure advertising will figure more prominently in their future, and since your attention is valuable, and they can monetize it, the status quo is likely to change.) I'm confident that if you can make a compelling business case as to why this might be in their best interest, they would consider it... But bear in mind they are a for-profit company and are looking to create barriers to entry for other parties: whether that means negotiating exclusivity terms for Digital Globe imagery that prevent other parties from access, or giving bbs.keyhole.com an edge up over others, etc. Asking politely is nice, and you may get lucky, but don't be surprised if their interests may be different than yours...

Re: Dear Google Earth Team

Author: Ed Parsons

Hi Sean, What are the use cases you have in mind ? ed

Re: Dear Google Earth Team

Author: Sean

I'm making a digital, historical atlas of the Classical world. Google Earth is a fine viewer for our entities, and fairly restful to boot. There's no SOAP nonsense, no fancy WxS protocol: Google Earth follows network links using HTTP GET. Next, I'm going to enable classicists to upload new entities (stubs, at least) to our atlas (with HTTP POST or PUT), and also update locations in place (PUT). Currently, a user can create a KML document in GE, but to upload must detour, save to disk, and POST the document to my atlas URL using another application. This detour could be avoided if GE allowed us to POST or PUT KML directly to a web URL. Google Earth isn't always going to be just for reading from the Geo-Web, is it? The capacity for writing is going to become more and more important, and should be done as restfully as the reading is done. That means HTTP POST and PUT instead of SOAP or WFS-T.

Re: Dear Google Earth Team

Author: John J. Schweisinger

It would be interesting to see your historical atlas of the Classical world application. Are you compling and vieiwing historical maps? If you have all the data it would be best to make your own Image Server. Rather then make it dependant on Google. The worldwind application makes it simple to create your own Google Earth Application. However the error is too large for small scale GIS applications.

Re: Dear Google Earth Team

Author: Sean

John, we're beginning to upload named places from the Barrington Atlas to Pleiades. Our historian collaborators are concerned about modern imagery's potential to misinform about the ancient world, but the physiographic base is coming later.

Re: Dear Google Earth Team

Author: John J. Schweisinger

Sean, I added the data to Google Earth using the link to the KML file. Looks like an interesting project. Do you have the atlas maps georeferenced? You can make your own WMS site and add them to am Internet Mapping Server.

Resources, not Objects

Keyur, you must think in terms of resources, not object methods. Nouns, not verbs. In a restful architecture you don't cause your person to talk, you listen to the person's words:

GET /persons/1

or, if you want to be fancy:

GET /persons/1/words

Likewise, you don't cause them to walk a step, you update the person with a new location:

PUT /persons/1
{ ..., "location": [[-100.0, 40.0]] }

or:

PUT /persons/1/location
{ "location": [[-100.0, 40.0]] }

Matrix URIs? They're standard with Rails, but mainly to allow PUT operations to tunnel via POST from dumb clients like the browser:

POST /persons/1;edit
{ ..., "location": [[-100.0, 40.0]] }

Comments

Re: Resources, not Objects

Author: Christopher Schmidt

Ah, good, I knew something seem wrong, but I couldn't figure out what it was. Don't forget how to delete people! DELETE /persons/42

Re: Resources, not Objects

Author: Sean

Person 42, please report immediately to the disintegration chamber. Thank you.

But everything may not be model-able as a resource...

Author: Keyur

Sean - first of all, thanks for the feedback. I am with you in that one should always think resources first when designing a REST API. But there are cases where you can't model everything as a resource - and not all reasons are technical in nature. For ex. your users are used to a certain vocabulary and if you define new terms it's that much more to educate them and something which might actually go against the grain of your system. Basically, I too would like to model everything as a resource first. But in situations where I have to introduce a verb, I'll have to go with one of the 3 approaches(or others if there are any) that I listed.

Re: Resources, not Objects

Author: Sean

I agree that there may be cases that can't be modeled restfully, but your Persons example is not one of them. What are the limits of REST? Are GIS systems more or less naturally restful? More, in my assessment, and I'll point to ArcSDE, PostGIS, and WxS as evidence. Each reduce GIS tasks to CRUD operations and, like you said, these map readily to REST. Still, REST is no silver bullet, and it would be good to identify classes of systems that don't benefit from restful architecture.

GeoDRM or GeoCYA?

Raj, Paul, Tom: don't neglect to write soon about the process of approving the GeoDRM Reference Model, and how it's going to usher in a brand new era of data sharing. Congratulations! The masses will cheer you and throw flowers, I'm sure.

Related: yesterday, a reader pointed me to an article in Government Computer News about what I'll call GeoCYA, in which the OGC CTO walks a fine line between removing, and stoking, "the fear of litigation".

JSON Security

I'm surprised nobody noticed the potentially exploitable feature collections responses in my initial Hammock deployment. Best practice is to return JSON objects rather than arrays. Bob Ippolito explains all about it here.