<div>What is it with this assumption that tiles are all that matters?</div><div><br></div><div>Over at Camp Roberts a few months ago, when asked how benevolent data providers should hand over data, &quot;tiles (in spherical mercator)&quot; was the group consensus.  I don&#39;t get it.  It&#39;s trivial to turn a more unprocessed parent dataset into tiles, and while it&#39;s not totally impossible to think about reversing that, you lose a lot by removing the source data from the workflow.</div>
<div><br></div><div>In the context of this discussion, I realized there&#39;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&#39;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.  </div>
<div><br></div><div>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&#39;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&#39;m talking about) and reasonably concluding that because we all now get &quot;free&quot; get access to the tiles, they&#39;ve done their civic duty.  They haven&#39;t.  Arguing tiles are all that we care about feeds this paradigm.</div>
<div><br></div><div>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 &quot;best&quot; available for the area in question, and we&#39;re done.  I don&#39;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? </div>
<div><br></div><div>Tiles are neat-o (and important) for for all kinds of things OAM related, disaster-relief related, viewing-easily related.  But they&#39;re not the only answer.  Please, think of the data.</div><div><br>
</div><div> -Josh</div>
<br><br><div class="gmail_quote">On Tue, Nov 3, 2009 at 5:35 AM, Richard Fairhurst <span dir="ltr">&lt;<a href="mailto:richard@systemed.net">richard@systemed.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Christopher Schmidt wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tiles are one way of thinking about it, but I think that everything else<br>
you say actually doesn&#39;t speak to &#39;tiles&#39;, but instead to &#39;data OpenLayers<br>
can read&#39;. If a service can provide a WMS layer, why do you need tiles? You<br>
just need something that OpenLayers can read; preferably with no  user knowledge other than &#39;I want that one!&#39;<br>
<br>
Tiles are fine for developers, but for users, they don&#39;t care about tiles.<br>
They just want a map. (This is just my experience/opinion, anyway.)<br>
</blockquote>
<br></div>
Tiles are great as the simplest thing possible. Potlatch, the OSM editor which I write, just speaks 900913 tiles - basically because it then doesn&#39;t have to worry about any projection other than spherical Mercator, and that&#39;s a huge code saving.<br>

<br>
We&#39;re finding that whenever someone comes up with a cool small aerial imagery set, there&#39;s always a helpful OSMer around (actually, it&#39;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.<br>

<br>
So yeah, I see the rationale behind &quot;something that OpenLayers can read&quot;, but &quot;something that popular clients can read&quot; is better phrasing; and clients like Potlatch and Modest Maps are coalescing around tiles as the lowest common denominator.<br>

<br>
(All this is detail, anyway. +1 for reviving OAM.)<br>
<br>
cheers<br><font color="#888888">
Richard</font><div><div></div><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openaerialmap.org" target="_blank">talk@openaerialmap.org</a><br>
<a href="http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org" target="_blank">http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org</a><br>
</div></div></blockquote></div><br>