Specific Idea | Blog: Problems in the land of 'live' data

Blog: Problems in the land of 'live' data

First, a little intro

Yuri (yuri.yup.la) is a satellite image saving web application I buit which is a great little tool if you just want to have a place that you can go back to and reference those cool images you found somewhere on google maps. But as with any service that relies on outside data, data that it can't control, this problem will inevitably crop up....

...you are going to find the proverbial rug pulled from underneath you...

Restrictions

Currently, (as far as I am aware) you can't use (due to licencing/legal restrictions) Google Maps service to save or download satelite images it produces. Let me get right to the punch-line: with live data, or data that gets updated by a third party, if you 'like' or want to frame that data in a particular context, you are going to find the proverbial rug pulled from underneath you, as the data becomes updated -- changes state.

...you aren't in control, so don't put any value in third party data.

From the moment you first embodied meaning into data and the 'now', when it is not any longer as it used to be -- the meaning it had for you, and on the open web this is also the rest of the world, is now lost. And what is the point of trying to 'fix' anything (any meaning) inside of an ever changing ephemeral place?

That may be a convoluted way of saying: you aren't in control, so don't put any value in third party data. Don't build a core business around it, don't bet your money on it.

Here are some specific parts of the exact licencing terms as of today Monday, April 25, 2011:

10.1.3 Restrictions against Data Export or Copying.

(a) No Unauthorized Copying, Modification, Creation of Derivative Works, or Display of the Content. You must not copy, translate, modify, or create a derivative work (including creating or contributing to a database) of, or publicly display any Content or any part thereof except as explicitly permitted under these Terms. For example, the following are prohibited: (i) creating server-side modification of map tiles; (ii) stitching multiple static map images together to display a map that is larger than permitted in the Maps APIs Documentation; (iii) creating mailing lists or telemarketing lists based on the Content; or (iv) exporting, writing, or saving the Content to a third party’s location-based platform or service.

(b) No Pre-Fetching, Caching, or Storage of Content. You must not pre-fetch, cache, or store any Content, except that you may store: (i) limited amounts of Content for the purpose of improving the performance of your Maps API Implementation if you do so temporarily, securely, and in a manner that does not permit use of the Content outside of the Service; and (ii) any content identifier or key that the Maps APIs Documentation specifically permits you to store. For example, you must not use the Content to create an independent database of “places.”

Taken from: http://code.google.com/apis/maps/terms.html

A fundamental problem

...save it for posterity...

In my case, or rather in the particular case of the Yuri.yup.la application, this problem has hit right to the core. First, let me explain why this is a problem for my application. The whole point of the application is to enable you, or me, or anyone to find that really interesting satelite picture lost in the sea of satelite images, frame it (take it out of it's context) and save it for posterity (in theory). This allows the building of a community around curated sattelite images. So what happens when these images get updated? What happens when the data for that particular geo-location changes?

...your, or my, precious framed image that we spent our valuable time combing the deserts and drivel of banal satelite images for, is now... something else.

Satelite images get updated, every so often google maps will update their images database for a particular location at a particular zoom level bracket and your, or my, precious framed image that we spent our valuable time combing the deserts and drivel of banal satelite images for, is now... something else.

...just make a nice friggin' image!

Take for example this particular image from the docks, on the shores of Japan. Recently having suffered a natural catastrophy, the cargo crates of this commercial dock lay strewn like a bag of colourful lego pieces was just spilled on a child's bedroom floor. When I first saw this area I found it fascinating, I spent time seeking the best way to frame the image in a rectangle, looking for aesthetic patterns, harmoy, reptetition; selecting intuitivley and precicely from the repertoire of design elements I've been ingrained with in art school, (just saying) for that particular arrangement that would convey the idea and, in simpler terms; just make a nice friggin' image!

Building on top of these API's is like building a house of cards on a rug firmly held in the grips of a bully.

But the data for this location has been updated, and the image changed. And now the careful framing, the meticulous time spent on it is all for nought.

Understandably, this is an active area and it get's more than the average share of satelites looking at it and gathering images and data. So it is prone to 'shifts' in data. Pun (too soon?) intended.

Let's imagine a scenario

Sometimes it's easier if we imagine some cases of data taken out of context. Imagine you live in a world where the data you create always changes, always shifts.

You send your grandparents a post card. It's a beautiful image of your new house pet. Your family just got a dog puppy. But while in transit, this data was updated, so now instead of a puppy, it's a cat. You call up your grandparents and they tell you what a cute cat you have. A totally contrived example, but you get the point. The post card or photograph isn't conveying the 'truth' or the data that you intended it to convey.
Do I really need to give you another outlandish example?

Outro

This is a problem not only for this particular application, but for all applications that rely on third party data. Data provided by Google, Microsoft, Yahoo, etc. (I am naming those because they operate in highly overlapping spaces on the web) are deceptively 'free' to be used but come with licence restrictions which, even with the wide availabiliy of API (application programming interfaces) that you and I can make use of to build our own application, we can't rely on this data. Building on top of these API's is like building a house of cards on a rug firmly held in the grips of a bully.