<br><br><div class="gmail_quote">On Thu, Nov 5, 2009 at 4:41 AM, Schuyler Erle <span dir="ltr"><<a href="mailto:schuyler@nocat.net">schuyler@nocat.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, 2009-11-04 at 22:44 -1000, Brian Russo wrote:<br>
><br>
> 2. The actual tiling & dissemination/content delivery portion. This<br>
> is much more automated, and while initially could be something as<br>
> simple as a few servers rsynching or whatever, eventually would be an<br>
> "automagical" self-balancing/managing/etc content delivery platform.<br>
> Realistically a lot of the tech for this part is probably already<br>
> written. I know we have a lot of tiling stuff out there right now, and<br>
> I'm sure there is some open source content federation work (though I<br>
> haven't looked).<br>
<br>
</div>I'm 100% in agreement that the catalog ought to come first. But is<br>
anyone here familiar with open source content federation software that<br>
actually works? A quick bit of Google searching reveals only Coral CDN,<br>
which definitely won't work for our purposes.<br></blockquote><div><br>I may have glossed over it a bit too much, at the end of the day it remains in my mind a fairly generic problem, and if we need to write software so be it, but I don't think it's something that's a particularly novel problem. Quick search reveals a few others.. Cacheboy CDN, Globule, etc all look like dead projects. At the least in my mind it remains a logically separate task.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> This is where your big bandwidth and platters come into play, and is<br>
> of course crucial to the whole process - but I do not see it as being<br>
> especially "geospatial" in the sense that this is a rather generic<br>
> (aka license-plate making) step of the process.<br>
<br>
</div>Actually, Paul pointed out (and I agree), that taking advantage of<br>
geo-locality might actually provide significant optimization to the<br>
distribution network. So it's not necessarily that simple.<br></blockquote><div><br>That's possible, I'm not sure I really agree. I was thinking about it on the way home and it really depends on the usage case for the data. If the usage case is something like finding directions, then definitely there'll be a geolocation component, but for many other uses there will not be (I think) an appreciable correlation. For example research, agency disaster response, casual browsing, vacation/trip planning, etc.. Definitely worth looking into - in the end it really depends what proportion of usage will have a geolocality aspect and I think if it's rather small then it may not be worthwhile to implement - but I don't know either way.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> ... just focusing on the tiling/dissemination piece is pretty moot<br>
<div class="im">> until you get a good set of data partners and a framework of business<br>
> processes/rules for managing the workflow of data. I don't mean to say<br>
> that we need some massive unwieldy bureacracy or anything of that<br>
> sort.<br>
<br>
</div>I agree that long-term management will require some kind of process to<br>
be elaborated. I strongly suggest that, if we're serious, this mailing<br>
list should nominate and constitute a Project Steering Committee to<br>
outline such a process (preferably one as simple as possible) and<br>
empower trusted individuals to do the work.<br></blockquote><div><br>I agree it should be simple as possible, I don't mean at all that this should be complex; I believe it should be lightweight, flexible, and effective. I think most of us can agree that one thing about these types of projects is you cannot anticipate every usage case that folds out; so you just try your darndest to build it right but in a flexible enough way that someone can come along and make it do what they want - but at the same time not so heavy that it never takes off the ground.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
(by PSC I mean something like<br>
<a href="http://trac.openlayers.org/wiki/SteeringCommittee" target="_blank">http://trac.openlayers.org/wiki/SteeringCommittee</a>)<br>
<div class="im"><br>
> This is all fine, but if you're not just dealing with a few standard<br>
> products, I think you really want a plan to deal with all that imagery<br>
> and how you'll stitch it together, handle quality vs timeliness, etc..<br>
> Otherwise it will just be a big cluster of unusable imagery (IMO).<br>
<br>
</div>Please amplify on these points? Thanks!<br></blockquote><div><br>We're going to have different currency of data versus quality of data; you need ways to determine what the main 'skin' gets. How much more important is it that something be good quality (resolution, cloud cover, etc) versus being recent? Is a 30% cloud cover shot that's 6 months old worse than a 10% cloud cover shot that's 12 months old? The answer of course is "it depends".<br>
<br>As someone else touched on, if we get a newer re-shoot of imagery that's in the middle of say.. an urban corridor.. how do we integrate that into the larger county dataset? That currency will be important for some applications, but if the area hasn't really changed much it might just make the imagery mosaic uglier. Simply overlay? Turn it on at a different scale dependency? What do you when you have multiple data sources of similar resolution/quality/currency but perhaps differ say.. being natural colour versus CIR? Both are good for different applications. Perhaps not the most striking sorts of questions that will fall out, but I did just wakeup.<br>
<br>Some of these sorts of questions turn out to be very simple, but they still have to be answered somehow and with some consistency that people know what they're getting. Google imagery for example is great, but I never know what their criteria for currency vs quality are - not a big deal if you're dealing with turn-by-turn directions in a relatively established urban core; but important if you're trying to establish whether a bridge still exists so you can drive across it in some remote area.<br>
<br>- bri
</div></div><br>