I don't think we should rush to get anything on-line. We can run the code locally for testing and development, or even on a small machine with a very small sample data set.
Let's organize potential hosting resources in the wiki. As Jeff mentioned we have the DIY, AWS and NPS options on the table now. We also have OAM members at a number of different universities. I imagine with the right proposal in hand we could secure plenty of resources from our various institutions. I am willing to lead the effort at Arizona State University. I'm sure we can get something back up at San Diego State University. However, we need to be clear in what we ask for. I can setup a server and several TB of storage at ASU, but would be thrown in a closest and forgotten about in 6 months. However, if we ask for the right resources I think ASU would offer long term support this project with both hardware and manpower, which is far more valuable than a server in a closet. Would anyone like to volunteer to lead the wiki effort to organize resources and development? - Charlie. On Wed, Dec 9, 2009 at 9:41 AM, Jeffrey Johnson <[email protected]> wrote: > We have at least 3 options for disk for the first big 'node' (possibly more?). > > 1) Buy/Build a machine with a decent amount of disk to get this thing > off the ground. Once built, it would require somewhere to host it, but > that could be less of a problem than putting the machine together at > first. By 'decent' ... I mean at least 10TB probably as much as 20 or > 30 just to get the ball rolling here, otherwise we quickly > (immediately) run into resource issues. This kind of machine (30TB > disk) can be built for roughly $7.5-10k. It seems to me that this kind > of $ could be raised if we had an appropriate plan. > > 2) Use amazon for the time being and move things around later. I have > experience working with the key people at AWS, and I'm guessing I > could arrange for some amount of resources for us to work with if idea > was proposed correctly. I'm willing to work on this option if it seems > like the logical thing to do. > > 3) NPS Has offered hardware for us to work with. My suspicion is > getting over all the hurdles in order to actually use the hardware > will be more difficult than either of the other two options, although > over the long term, this could certainly be a large node in the > system. I just dont want 'waiting' on it to become available to become > a blocker. > > Others? > > The way I see it, this iteration of OAM must start with a decent set > of base data in the first 'node' or it will continue to NOT be taken > seriously. A decent set of base data would probably include a landsat > or spot mosaic and the entire set of NAIP imagery for the US ... which > together once cached would quickly fill a 30TB disk appliance. As > crschmidt once said, its not a problem of too little data, its a > problem of too much. If we cant figure out how to simply process/serve > the basic sets of free/open data out there, then we should just stop > now and go back to using google and bing. > > Jeff > > On Wed, Dec 9, 2009 at 9:25 AM, Schuyler Erle <[email protected]> wrote: >> On Tue, 2009-12-08 at 16:02 -1000, Brian Russo wrote: >>> I think if people are too preoccupied with being on an official >>> committee or having this title and that nothing will ever get done. >> >> Okay, everyone, hold your horses, please. Of course, you're all right >> about nothing of substance getting done yet, but, to my knowledge, no >> one on this list has ever tried to build a collaborative project of this >> scope before, and a little organizing ahead of time isn't going to hurt. >> At some point soon, we're going to have to take collective decisions and >> it's best for us to have some framework for doing that. >> >> Now that we've got that out of the way, let's talk about what to do >> next. We've got crschmidt's original code, and we've got the code that >> the Livni brothers have started on. Where should we deploy it to start >> hacking on and poking at? If no one else has a server, I've got one that >> can host the catalog, but it doesn't have much disk space. >> >> SDE >> >> >> _______________________________________________ >> talk mailing list >> [email protected] >> http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org >> > > _______________________________________________ > talk mailing list > [email protected] > http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org > _______________________________________________ talk mailing list [email protected] http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org
