[OAM-talk] Nov. RELEIF Meeting Goals

[Brian Russo]

On Thu, Nov 5, 2009 at 4:41 AM, Schuyler Erle <schuyler at nocat.net> wrote:

> On Wed, 2009-11-04 at 22:44 -1000, Brian Russo wrote:
> >
> > 2.  The actual tiling & dissemination/content delivery portion. This
> > is much more automated, and while initially could be something as
> > simple as a few servers rsynching or whatever, eventually would be an
> > "automagical" self-balancing/managing/etc content delivery platform.
> > Realistically a lot of the tech for this part is probably already
> > written. I know we have a lot of tiling stuff out there right now, and
> > I'm sure there is some open source content federation work (though I
> > haven't looked).
>
> I'm 100% in agreement that the catalog ought to come first. But is
> anyone here familiar with open source content federation software that
> actually works? A quick bit of Google searching reveals only Coral CDN,
> which definitely won't work for our purposes.
>

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.


>
> >  This is where your big bandwidth and platters come into play, and is
> > of course crucial to the whole process - but I do not see it as being
> > especially "geospatial" in the sense that this is a rather generic
> > (aka license-plate making) step of the process.
>
> Actually, Paul pointed out (and I agree), that taking advantage of
> geo-locality might actually provide significant optimization to the
> distribution network. So it's not necessarily that simple.
>

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.


>
> > ... just focusing on the tiling/dissemination piece is pretty moot
> > until you get a good set of data partners and a framework of business
> > processes/rules for managing the workflow of data. I don't mean to say
> > that we need some massive unwieldy bureacracy or anything of that
> > sort.
>
> I agree that long-term management will require some kind of process to
> be elaborated. I strongly suggest that, if we're serious, this mailing
> list should nominate and constitute a Project Steering Committee to
> outline such a process (preferably one as simple as possible) and
> empower trusted individuals to do the work.
>

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.


>
> (by PSC I mean something like
> http://trac.openlayers.org/wiki/SteeringCommittee)
>
> > This is all fine, but if you're not just dealing with a few standard
> > products, I think you really want a plan to deal with all that imagery
> > and how you'll stitch it together, handle quality vs timeliness, etc..
> > Otherwise it will just be a big cluster of unusable imagery (IMO).
>
> Please amplify on these points? Thanks!
>

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".

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.

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.

- bri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openaerialmap.org/pipermail/talk_openaerialmap.org/attachments/20091105/43bf21e8/attachment-0001.html>