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.

Rtree 0.1.0

Good news for Python geo-programmers: Howard Butler has kicked out the jams, unstuck my Python/C++ R-Tree experiment, and allowed me to release Rtree 0.1.0. This package is based on Marios Hadjieleftheriou's spatialindex, and now allows you to persist a tree on disk. The one known bug is that it's a no go on 64-bit architectures. This will be addressed in the 0.2.0 release by using spatialindex 1.1.1.

In other news, I moved Rtree and Quadtree from Pleiades to the GIS-Python repository. Thanks to svndumpfilter, it was almost too easy.

Hammock

Here's the code for the toy not-a-WFS I wrote about yesterday [browse]:

$ svn co http://icon.stoa.org/svn/pleiades/hammock/trunk hammock

Requires GeoJSON:

$ svn co http://svn.gispython.org/gispy/GeoJSON/trunk GeoJSON
$ chdir GeoJSON
$ python setup.py install

in addition to simplejson (needed by GeoJSON), elementtree, selector, and wsgiref (use setuptool's easy install script, or build from Cheeseshop tarballs).

Comments

Re: Hammock

Author: Christopher Schmidt

Also, GeoJSON has a simplejson dependency, looks like.

Re: Hammock

Author: Sean

Oh, yeah. Thanks, Christopher, correction made.