[OAM-talk] Nov. RELEIF Meeting Goals

[Christopher Lippitt]

I wanted to touch on Brian's last point:

It seems to me that allowing ingestion of imagery from a disparate range of
sources is one of the primary benefits of OAM. Also, the ability to view a
range of different datasets based on criteria like the latest, the highest
resolution, spectral bands, etc, is key to allowing the system to
simulaniously be an image map and an image catalog. It is my beleif that "if
we build it, they will come", meaning that many municipalities and other
image data holders will begin to use OAM as a free way to host and
distribute their imagery.

This makes the database and its catalog a critical component of the system.
It also presents a range of issues about how to mosaic/stitch such imagery,
how to control for quality, etc. I think that the mosaic and stitch problem
and the accuracy problem can be left aside for now, since there are a range
of companies working on the stitching topic and academics working on the
accuracy problem,  it seems to me that these hard problem that can wait. The
catalog problem however is the core of the system, and subsequently seems
like it should be priority for hashing out.

Chris

On Thu, Nov 5, 2009 at 6: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.
>
> >  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.
>
> > ... 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.
>
> (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!
>
> SDE
>
>
> _______________________________________________
> talk mailing list
> talk at openaerialmap.org
> http://openaerialmap.org/mailman/listinfo/talk_openaerialmap.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openaerialmap.org/pipermail/talk_openaerialmap.org/attachments/20091105/8e43b936/attachment.html>