Paul and Schuyler, Thanks for jumping in and getting the conversation back into the public domain. Both the technical and organizational aspects of this project are significant. Keeping both these conversations in the same thread could be counter productive. Please (please please), organize your ideas in the wiki. I know wiki's aren't a great place to have discussion, so after you make changes please start a "new" email thread where the changes can be discussed independent of other issues.
The email list is a great place for people to announce their great intentions and state their ideas, but please do some work first, help organize the wiki, add your thoughts there then announce them here on this list. http://www.openaerialmap.org/OAM_2009 http://www.openaerialmap.org/Architecture http://www.openaerialmap.org/Management etc, etc.. Thanks, Charlie. On Mon, Nov 2, 2009 at 11:13 AM, Schuyler Erle <[email protected]> wrote: > On Mon, 2009-11-02 at 11:03 -0800, Paul Ramsey wrote: > > For some reason I got on a research jag about this topic last month > > (maybe to avoid my FOSS4G prep?). Anyhow, I sketched out some ideas on > > the storage/provision side here: > > > > http://etherpad.com/I3dgOoyQKV > > > > Feel free to annotate / edit that if you like. > > > > [snip] > > Thanks, Paul. I think these are great ideas for getting an OAM network > to scale robustly. However, I debate your consideration that OAM has > foundered thus far on the storage problem; I believe that building the > community is more significant and that the technical solutions will > follow. Witness the fits and starts in the growth of OSM for example. > > I see two hitches with your technical proposal. Number one is that > traversing a distributed hash table introduces significant latency. We'd > have to test the hell out of a DHT solution to ensure performance. > > The other hitch is that some people care about verifying a tile's > provenance. I think that this implies a set of core servers that do the > actual proxying to the source WMS servers, and then crypto-sign the > images themselves (by adding the metadata and signature to an image > metadata field or simply appending the metadata/signature combo to the > end of the image, which works with JPEG at least). > > Perhaps, once signed, the tiles can then go into the cloud at some level > of redundancy, whether the leaf servers are networked via DHT, or just > heartbeat-ping the DNS servers and keep independent local caches. > > I think that improving the likelihood of cache hits on client requests > by using DNS to take advantage of geographic locality is a really great > idea, and I hope to see this implemented in whatever topology gets > worked out. > > 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
