Depends which scale you cache, down to around 1:100k or so isn't a big deal space-wise, below that you probably won't initially have much coverage outside of the US, even then you can start with clusters around points of interest. Even google doesn't have truly global high res coverage. You can always tile on demand or run metrics to determine areas of demand and prioritize accordingly. In my mind this aspect is really a generic content staging/delivery problem akin to federated staging like google/akamai/etc do. Not to dismiss it, but I do not see it as particularly unique to imagery.
I am a bit troubled by the focus on tiles, certainly that's probably the best way to technically disseminate large skins but will impact certain applications that want the actual imagery. I think its important to maintain a link to the source imagery - a simple polygon vector catalog would probably work. I admit I haven't read every message in these threads so I apologize if I missed it, but there's some separation between the actual sourcing and image cataloging and the primary means of dissemination (tiles). Building tiles isn't really that difficult - its mostly just resource-intensive (cpu and disk/io mostly). My suggestion is to focus on the management/maintenance side of it and then worry less about the actual tile generation. Because building tiles faster just means more disk space and cpu - but managing a large imagery catalog of disparately sourced imagery is quite challenging - I see this as the hard part. Most people have relatively few sources of imagery. I could go on but hopefully you get the idea, blackberry makes brevity! I'm interested on the HADR support side of it, as I am the GIS manager/architect for marforpac (executive agent for pacom hadr). Regards, - bri On 11/4/09, Schuyler Erle <[email protected]> wrote: > On Wed, 2009-11-04 at 15:06 -0800, Christopher Lippitt wrote: >> I created a wiki page here (http://www.openaerialmap.org/RELEIF_Nov09) >> to propose alternative "phase 1" approaches with Schuyler's as the the >> first. [snip] >> >> This approach will allow us to flush out and compare a few different >> architecture approaches directly, and then come out of the meeting >> with a clearer picture of how to start building the larger system and >> hopefully with a small code base to start from. > > Chris, thanks for your work in getting OAM started, and for taking the > time to outline these big-picture options on the wiki. I edited the page > slightly to reflect a few more specifics on these options. > > I want to suggest in the strongest possible terms that a fully > centralized solution, although simpler in some ways, and more comforting > to organizations with strong hierarchical authority, I think such an > approach is going to prove to be unworkable. > > First, no organization has yet volunteered to provide 100s of TB of > hosting, with full backups, and gigabits of bandwidth, both of which we > will eventually need if this takes off. Don has graciously put in for > funding for 10 TB of hosting, but if we tile the 15m NGA data he has > (been?) offered, we will use up all of that space instantly, between the > tiles and the source imagery. > > Second, a centralized data warehouse is a single point of failure. OAM > has already had problems with this in the most recent iteration. I will > repeat myself here by saying that I think that an unreliable OAM is > worse than no OAM at all, because it will only serve to discredit the > concept and discourage the community. > > Also, while each of the three options you describe have distinctive > merit, they all depend on a metadata catalog to make the whole thing > work. I would like to suggest that we discuss seriously making the > further development of the metadata service the first priority for > renewed technical work on OAM. I'm hoping to wrangle together folks who > are interested in this at Random Hacks of Kindness next week, and > perhaps we'll have something pulled together for discussion at Camp > Roberts the week after? > > SDE > > > _______________________________________________ > talk mailing list > [email protected] > http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org > -- Sent from my mobile device _______________________________________________ talk mailing list [email protected] http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org
