I've been wondering about this myself. What exactly is the point of taking all of USGS/BLM's data and serving it up? I never have a problem finding tiled map services or WMS to use for data in the US. Besides, it'd make more sense to just pressure USGS to do this since they have it much of it served via WMS already anyway so it's really just a matter of them tiling it (the data management issues are already solved which is the lion's share of the work).<br>
<br>As for 15m data, it's not a big deal to get this. I have all of landsat at work it's only a couple terabytes or so. Even tiled to 1:100k or so it's not a big deal and there's not much point tiling it below that. Actually the big issue with large tiled datasets is the CPU time in generating the tiles - not the disk space to hold them. This is more of a 'startup' cost though as once you've tiled everything you only need to do maintenance on it. It therefore makes more sense to offload your big tile generation to EC2 or a similar utility model and just do your maintenance tiling in-house.<br>
<br><br>- bri<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 7:41 AM, Jeffrey Johnson <span dir="ltr"><<a href="mailto:ortelius@gmail.com">ortelius@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The way I see it, this iteration of OAM must start with a decent set<br>
of base data in the first 'node' or it will continue to NOT be taken<br>
seriously. A decent set of base data would probably include a landsat<br>
or spot mosaic and the entire set of NAIP imagery for the US ... which<br>
together once cached would quickly fill a 30TB disk appliance. As<br>
crschmidt once said, its not a problem of too little data, its a<br>
problem of too much. If we cant figure out how to simply process/serve<br>
the basic sets of free/open data out there, then we should just stop<br>
now and go back to using google and bing.<br>
<br>
Jeff<br>
<div><div></div><div class="h5"><br>
On Wed, Dec 9, 2009 at 9:25 AM, Schuyler Erle <<a href="mailto:schuyler@nocat.net">schuyler@nocat.net</a>> wrote:<br>
> On Tue, 2009-12-08 at 16:02 -1000, Brian Russo wrote:<br>
>> I think if people are too preoccupied with being on an official<br>
>> committee or having this title and that nothing will ever get done.<br>
><br>
> Okay, everyone, hold your horses, please. Of course, you're all right<br>
> about nothing of substance getting done yet, but, to my knowledge, no<br>
> one on this list has ever tried to build a collaborative project of this<br>
> scope before, and a little organizing ahead of time isn't going to hurt.<br>
> At some point soon, we're going to have to take collective decisions and<br>
> it's best for us to have some framework for doing that.<br>
><br>
> Now that we've got that out of the way, let's talk about what to do<br>
> next. We've got crschmidt's original code, and we've got the code that<br>
> the Livni brothers have started on. Where should we deploy it to start<br>
> hacking on and poking at? If no one else has a server, I've got one that<br>
> can host the catalog, but it doesn't have much disk space.<br>
><br>
> SDE<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> talk mailing list<br>
> <a href="mailto:talk@openaerialmap.org">talk@openaerialmap.org</a><br>
> <a href="http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org" target="_blank">http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org</a><br>
><br>
</blockquote></div><br>