> I haven't used tilecache for this, I know someone that did rent about $60k > worth of EC2 time to cache a bunch of tiles; I could find out more specifics > on this (it was months ago). I do realize it's not a 5 minute solution; but > this still makes more sense to me than trying to create the "rc5des > distributed.net" of imagery tiling.
I have processed roughly 30TB of tiles on EC2/EBS, and I certainly know the in's and out's of doing this ... its not trivial, but not that complicated either. I don't think there is any interest in creating a distributed tiling mechanism ala rc5des distributed.net ... what I am talking about is taking the freely available datasets that are out there (naip among them) and creating tiles from these (likely on EC2 or some other large chunk of infrastructure) and serving them up as a single TMS endpoint that people can drop into their web or mobile apps and expect that they will work and give them reasonably good (1m) imagery in the US. Doing a lazy cache against a WMS like seamless would break almost instantaneously, just ask NASA about that. > On Wed, Dec 9, 2009 at 9:48 AM, Jeffrey Johnson <[email protected]> wrote: >> >> > seamless has WMS services; they're not tiled. >> > >> > If you want them tiled get a bunch of hardware, stick tilecache on it >> > and >> > serve WMS-C tiles. >> >> Have you tried to do this on any reasonable scale? You would bring >> their hardware to its knees with a handful of tilecache_seed.py >> requests if you were not banned from making more requests very >> quickly. >> >> >OR continue to pressure USGS to do it. >> >> Could be that they will do it. > > I think it's worth a try. I don't deal with non-defense much; but NGA has > basically the same administrative structure as USGS (from what I can tell, > although USGS is more progressive); often it's just finding the right person > and establishing the requirements. From a technical standpoint they have > most of what they need to do it; it's more an aspect of them agreeing to the > business case/requirements. The people I have talked to about this at USGS are just totally resistant to serving tiles for use in generic web apps. They are not interested in having the govt pay the hardware and bandwidth bill for tiles used in my consumer web app ... its not their mission, and I happen to agree, they would probably screw it up anyway. >> > Right now I still don't see what's compelling about tiling NAIP. >> >> Its not NAIP per se, its about having a reasonable archive of imagery >> that can actually be used by people to plug into their web apps in a >> plug and play fashion similar to the way people use the Google Maps or >> Bing APIs. The original OAM service was great where it had coverage, >> but many people were simply not interested in using it when it did NOT >> have coverage where they wanted it ... even though such imagery >> existed for free out from various sources. >> >> The point is to have a service that people can actually just use to do >> useful things ... not a committee of a bunch of people talking about >> how to organize OTHER people to help them create a service that they >> can actually do useful things with. > > I agree, and this is where I'd like to see it go. Establishing a baseline of > 15m landsat is sound in that it works well for many purposes and paves the > way for your 1m/0.5m imagery. Because there really is a jump there. Getting > 10m imagery when you have 15m isn't much more useful. Having 2m instead of > 15m is significantly more useful. A baseline of 15M Landsat or SPOT and a baseline of 1M imagery (NAIP and other datasets) in the US is the baseline I am talking about. This baseline has to be available as tiles so that I can just grab the endpoint and drop it in my app without much fuss and expect that it works. Short of that, there is no compelling case for me to use OAM in my apps. > I don't think tilecache is a magic bullet (it might suck), but I like the > basic model of absorbing WMS and serving them out as tiles. It seems more > feasible than a lot of other proposals on here. Tilecache itself is not the magic bullet, but tiled map services are ... this great leap forward is what is driving the renaissance of mapping ... I have no interest in waiting for a WMS to render tiles and would not build a large scale app on such a service because it would be exceptionally frustrating for my users. This is what led to my previous large scale caching efforts. > Backtracking a bit, I agree the distributed concept is the right one; but I > think doing it with large trusted supernodes (more of a federated model) is > much more sensible than a truly distributed one. This is exactly what I am talking about ... lets make some effort toward getting some very large base/trusted supernodes up and running ASAP so that there actually a friggin map in OpenAerialMap again, and then spend the time to figure out how to deal with tons of little datasets ... or do them in parallel ... but please take the cart and put it back behind the horse. > Incidentally, does anyone have any contacts at NASA? They host a lot of > imagery albeit at smaller scales. NASA cannot even figure out how to keep their own services up and running reliably last time I checked, what makes you think they would want to help us? _______________________________________________ talk mailing list [email protected] http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org
