[OAM-talk] OpenAerialMap questions

[Matthew Perry]

On Dec 8, 2007 12:04 PM, Christopher Schmidt <crschmidt at crschmidt.net> wrote:
> I agree with half of this: delivery in alternative projections is a
> requisite. *Storage* in alternative projections is not a requisite. I
> think that http://openaerialmap.org/map/mercator.html is relatively
> effective, and it doens't involved storing anything differently.
>

Very nice. This is a good solution: store the data in epsg:4326 and
let mapserver deliver the mercator (or UTM, or stateplane, etc)
version.

Have you tried using different resampling techniques? I think a lot of
the noise in the reprojected image can be taken care of by using:

PROCESSING "RESAMPLE=AVERAGE"


> The processing of the data can be largely automated, and packaged up
> with FWTools, so if they have a Linux or Windows machine, they have the
> toolset that they need to process their imagery all wrapped up in a box.
> Given that, the next step is sufficient instructions that they can build
> what they need using only that.

I'm currently working on the NAIP imagery (or rather my CPU is). I
wrote a quick script to take the NAIP .sid images and create a tiled
set of latlong geotiffs. It's available at
http://perrygeo.googlecode.com/svn/trunk/gis-bin/imageryOAM.py

> 35GB of data is fine, if you can't host it elsewhere:

Great. I'll probably just do a small subset of santa barbara county,
CA as a test case (just the channel islands) and try to find a more
permanent home for the rest.

>  I'm still
> personally working on trying to figure out how we can store this stuff
> compressed, so I haven't concentrated on the 'making it easy to store
> your data and share it' instructions that are going to be neccesary.

Hopefully the process can be encapsulated into a single gdal script.
The instructions would be pretty short in that case.

1) Use the script to pre-process your data
2a) upload to OAM
  or
2b) create a mapserver mapfile to serve the data as WMS


> > In the past, I've built a web map front end with a little "download"
> > button which would construct a WCS call based on the current bbox
> > extent. Pretty simple and it did the trick.. zoom in, hit download,
> > get a full-res, geo-referenced dataset of that area.
>
> And what did users do with this?
>

In the example I described above, the dataset was a DEM which was used
to perform hydrologic modeling (determining flow paths, basin
delineation, etc). For OAM imagery, the user could do some
classifications, feature extraction, fusing, blending,
color-correcting ... all the normal things one would be doing with
remotely sensed data in a package like OSSIM for example.


> Encoding JP2 with the free encoders is painful, as far as I can tell.

I'll second that.

> > Well you can't have WCS access to data that is cascaded through WMS.
> > The whole point of WCS is that it allows access to the actual raw
> > data. So WCS would only make sense on the first link in the chain (ie
> > the host server of the data in question).
>
> I don't think that's true. WCS provides 'raw data', but it can provide
> 'raw data' in any format you ask for, regardless of the format of the
> data. Assuming the source data is JPG encoded (some is, some isn't, at
> the moment), then there's nothing lost from loading up the WCS from JPG
> tiles from a WMS, other than perhaps a slight increase in the number of
> compression artifacts you see. Right?

Perhaps. The host WMS server can do whatever it likes with the data
(PROCESSING directives, putting the data in a lossy format, etc) so
the WMS-ified image may not bear any resemblance to the original data
(in terms of pixel values).  WMS servers also place a limit on the
image size so a cascaded WMS *might* not be able to provide the data
needed for a larger WCS request... I'll have to test that out.

Basically, I'd just like to put out the idea of a bbox-based image
download service that would provide the user with a georeferenced
dataset that was a close as possible to the source data.  There are
details to consider but - one step at a time.

-- 
Matthew T. Perry
http://www.perrygeo.net