Ok, you got me, I foolishly skimmed that bit of your proposal, and even more foolishly assumed you weren't already one step ahead of my pre-coffee rants. At very quick second glance, I guess I was not thinking that "version" meant "distinct data source".
I'll look in more detail at the proposed API, and comment in more detail once I've had a chance to do that. But as long as we can be able to, for a given bbox, get a list of potential data-sources, and then be able to request a set of tiles from only that datasource, I'll be psyched. And my second quick-glance it looks like that will be quite feasible - awesome! I think my raw-image over just-tiles argument is much less important than this (for OAM, if not the overall open data concept), and not likely worth making any initial OAM efforts more difficult in order to solve it. Thanks a lot for putting so much good thought/effort into this. -Josh On Tue, Nov 3, 2009 at 9:18 AM, Paul Ramsey <[email protected]>wrote: > On Tue, Nov 3, 2009 at 9:05 AM, Josh Livni <[email protected]> > wrote: > > > With that side rant over, I also think that this mindset implies that one > > global layer to rule them all is the best way to go: After all, we only > > care about processed tiles, so lets just make sure every tile is the > "best" > > available for the area in question, and we're done. I don't see it that > > way. > > Nor I. My proposal probably doesn't surface this enough (you'd have to > read down into the DHT hash key proposal) but I am assuming > > (a) we will have multiple "layers" > (b) for each layer there will be one "canonical view", the "best" > view, with a fixed known address for each tile > (c) for each layer there will be one "canonical metadata address", an > address to get a metadata block about that tile > (d) inside that metadata block, will be information about all the > *other* information in that tile beyond the current canonical view > (e) so, for example, when new imagery supersedes old imagery, the old > imagery doesn't go away, it continues to exist in a non-canonical > address for that tile, and is findable through the standard metadata > address for that tile > (f) so, the data update process is one where a new tile is first > written into a unique address, where it will persist "forever" and > also written into the canonical address, where it will reside until it > too is superseded > > This view is still tile centric and doesn't make any allowance for > storing the raw imagery, though probably we could find a place in the > addressing scheme to chop the original unprojected imagery into > storable chunks and dump them into the DHT too, just not as objects > useful for mapping. > > P. >
_______________________________________________ talk mailing list [email protected] http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org
