What is it with this assumption that tiles are all that matters? Over at Camp Roberts a few months ago, when asked how benevolent data providers should hand over data, "tiles (in spherical mercator)" was the group consensus. I don't get it. It's trivial to turn a more unprocessed parent dataset into tiles, and while it's not totally impossible to think about reversing that, you lose a lot by removing the source data from the workflow.
In the context of this discussion, I realized there's an implicit consensus that the OAM Tile Servers deal exclusively with tiles. I see big advantages in storing and working with tiles via the distributed hash table that's being discussed, and for sharing/duplication amongst servers -- but I also see a big disadvantage in removing the source data entirely from the workflow. Not to get all paleo, but there are things people can do with imagery aside from put them in spherical mercator tiles. But equally important, I think, is this general mindset of only considering the final, most processed output, as what's important. As one simple example side-rant, this mindset is harmful to the very concept of open data. It legitimizes public agencies and others giving their datasets to large companies (you know who who I'm talking about) and reasonably concluding that because we all now get "free" get access to the tiles, they've done their civic duty. They haven't. Arguing tiles are all that we care about feeds this paradigm. 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. Thinking about different source datasets overlapping eachother, each with a different (and potentially valuable) story to tell is a more powerful vision of what OpenAerialMap can provide. What did source imagery ever do to anyone to make them want to kill it off? Take up too much space? Seriously? Tiles are neat-o (and important) for for all kinds of things OAM related, disaster-relief related, viewing-easily related. But they're not the only answer. Please, think of the data. -Josh On Tue, Nov 3, 2009 at 5:35 AM, Richard Fairhurst <[email protected]>wrote: > Christopher Schmidt wrote: > > Tiles are one way of thinking about it, but I think that everything else >> you say actually doesn't speak to 'tiles', but instead to 'data OpenLayers >> can read'. If a service can provide a WMS layer, why do you need tiles? >> You >> just need something that OpenLayers can read; preferably with no user >> knowledge other than 'I want that one!' >> >> Tiles are fine for developers, but for users, they don't care about tiles. >> They just want a map. (This is just my experience/opinion, anyway.) >> > > Tiles are great as the simplest thing possible. Potlatch, the OSM editor > which I write, just speaks 900913 tiles - basically because it then doesn't > have to worry about any projection other than spherical Mercator, and that's > a huge code saving. > > We're finding that whenever someone comes up with a cool small aerial > imagery set, there's always a helpful OSMer around (actually, it's usually > Andy Allan) who will reproject and slice into 900913 tiles. Similarly for > out-of-copyright UK maps. About the only thing Potlatch is missing by not > having WMS support is USGS topos. > > So yeah, I see the rationale behind "something that OpenLayers can read", > but "something that popular clients can read" is better phrasing; and > clients like Potlatch and Modest Maps are coalescing around tiles as the > lowest common denominator. > > (All this is detail, anyway. +1 for reviving OAM.) > > cheers > Richard > > > > _______________________________________________ > 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
