On Thu, Mar 17, 2011 at 05:18:25PM -0500, Mark Korver wrote: > I've been checking out the progress with the Imagery Index. It's > lookin good. So have been thinking about "Access Tools" abit now that > Chris has the index working. > > Assuming the data is Processed image data. > I have some area of interest, so I use a bbox and some other filters > to get back a list of urls, having those urls I download the data to > my application. > Once I have the data local, the tool auto-builds index and mapfile ( > MapServer ) allowing me to see it as a wms. > Once I can view it as a wms ( assuming overviews are in the tifs here > ) I can check it and run code to TMS it. > Once I have the TMS ( like on S3 ) I can delete the source tifs. > > I would imagine all of this working off of some app that you just > started from a public EC2 instance that would start you off with OL > showing you the result of your query to the Imagery Index ( Chris > already showed this to us ), then allow you to run the process kind've > like TileMill. > > This shouldn't be so hard to do with one application instance, the > trick would be to do it with 100 to speed things up. > > Is this the kind've thing people have in mind for Access Tools?
Yep, that's exactly one sort of access tool. Of course, another is the simple demo that I built -- using the API + OpenLayers to display outlines of the layers, for example. Another potential access tool is one that allows you to download a set of data, and deploy it on a machine -- perhaps in response to a humanitarian disaster, for example -- and ship that machine off to some other location and use all the data. Basically, 'access tools' is code for "Anything people want to do with OAM" -- and our goal is to make that as easy as possible. So, for example, one of the things I wnat to do that I didn't think of was make a seperate overview of "This is the imagery this server is hosting", built from the index... but I can't stash additional data about layers in the index (like a WMS URL for a layer). So that requires extending the imagery index -- I'm thinking with tags on layers for storage of additional key/value data that can be consumed by layers. You can imagine building other types of tools: Evaluation of cloud cover, landcover changes using dated images and diffing them, etc. These are all a bit more advanced: I think that the thing you described is exactly the kind of thing we're hoping people will be able to do relatively easily, and is a solid first target for access tools. Regards, -- Christopher Schmidt Web Developer _______________________________________________ talk mailing list t...@host134.hostmonster.com http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org
