Re: [Openev-discuss] Feedback on "Porting" an application to OpenEV

[Gillian W. <gil...@at...>]

Hi,

The PAA project sounds interesting.  I'm not sure what type of thoughts 
you are looking for, but I've inserted some comments below:

>
> * Change OpenEV menus and toolbars to fulfill needs of PAA 
> application.  This would mean adding new items (and underlying code) 
> and removal of items that are not needed. 

If you want to do really fundamental changes, you might want to consider 
using the components of OpenEV (gview.py) to construct your own 
application rather than using the standard reference application 
(gviewapp.py/gvviewwindow.py).  This would give you maximum flexibility, 
and it isn't too hard to put the components together in a new 
application.  The developer tutorials explain a bit about openev's 
components and how it works:

http://openev.sourceforge.net/app/developer_info/DEVCOURSE.html

>
>
> * Add the concept of multiple sensor layers (corresponding to data 
> sources or historical acquisition periods, so users could see the 
> images available for each layer).  This seems to be equivalent to 
> having several default vector layers, with a special menu item to turn 
> them on/off.
>
> * Add area and distance measurement
>
> * Enhance drawing capabilities (needs arrows and probably some other 
> items)

OpenEV doesn't directly expose all of its vector display capabilities.  
You might want to have a look at Paul Spencer's mil_symbols.py tool 
(openev/tools) to get an idea of what can be done with vector display.

>
>
> We hope to do a pilot project for that basic work with some (very 
> talented) colleagues in India actually doing the code development.  
> Current thinking is that it is about a 3-month effort for one person.  
> If that goes well we hope for additional funding for a full port and 
> enhancements, with capabilities such as:
>
> * Web-enabled access to image and vector data (so users can access 
> image collections and vector overlays available anywhere on the 
> Internet).  And, eventually, we would like to have a full web-based 
> version (using WMS or whatever).
>
> * 3-D and perspective views (so users can better understand the 
> topography they see in the image, without instruction on image 
> interpretation; probably with SRTM data).  It looks like OpenEV 
> already supports the basics but I have not experimented with it.

It supports draping over a grid, but doesn't do triangulated meshing or 
anything like that.

>
> * Mosaicked images (so two or more images that divide an AOI could be 
> combined and saved as a new image)

You might also want to have a look at the GDAL facilities, which include 
some support for warping (gdalwarp) and mosaicking (gdal_merge.py), 
among many other things:

http://www.remotesensing.org/gdal/
http://www.remotesensing.org/gdal/gdal_utilities.html

GDAL also has tools for dealing with vectors and projection:

http://www.remotesensing.org:16080/gdal/ogr/
http://www.remotesensing.org:16080/gdal/ogr/ogr_utilities.html

I'd also recommend learning about the VRT format:

http://www.gdal.org/gdal_vrttut.html

Some of the tools in GDAL have not been exposed in OpenEV yet, but 
potentially could be.


- Gillian