OpenEV

Hi,

I don't know anything about GMT, but if you have one of Frank's openev 
builds (the openev_fw releases), you might be able to use the ogr2ogr 
command line executable to change shapefiles saved through OpenEV's 
File/Save Vector Layer menu entry into another format.  The ogr2ogr 
utility in Frank's linux openev_fw 1.7.1 build indicates that it can 
output TIGER, S57, MapInfo, DGN, GML, and PostgreSQL formats. 

If you're willing to try python scripting, you could use the functions 
in openev's gview.py to open up the shapes and print their nodes out to 
an ascii text file.  If you save something like the following to 
script.py and run python script.py shapefile.shp out.txt, it should 
print out lines with the shape index, ring #, node #, and  x/y/z 
coordinates of the node to a text file out.txt.

import gview
import sys
 
if __name__ == '__main__':
 
    fshp = sys.argv[1]
    fout = sys.argv[2]
       
    sdata=gview.GvShapes(shapefilename=fshp)
    wlines=[]
    for shp_indx in range(len(sdata)):
        if sdata[shp_indx] is None:
            continue
 
        for ring in range(sdata[shp_indx].get_rings()):
            for node in range(sdata[shp_indx].get_nodes(ring)):
                pnt = sdata[shp_indx].get_node(node,ring)
                nline='%d,%d,%d,%f,%f,%f\n' % 
(shp_indx,ring,node,pnt[0],pnt[1],pnt[2])
                wlines.append(nline)
    fh=open(fout,'w')
    fh.writelines(wlines)

I hope this helps.
             
Gillian

Vincent Godard wrote:

>Hi,
>
>I'm a new openev user and I'd like to export some vector layers generated with 
>openev in ascii format or any format that can be used with GMT (which don't 
>seem to recognize shapefiles). Is there a simple way to do that (I am not too 
>familiar with python scripting..)?
>
>Thanks in advance,
>
>Vincent.
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Openev-discuss mailing list
>Openev-discuss@...
>https://lists.sourceforge.net/lists/listinfo/openev-discuss
>  
>

Gillian Walter wrote:

>
>
> if __name__ == '__main__':
>
>    fshp = sys.argv[1]
>    fout = sys.argv[2]
>          sdata=gview.GvShapes(shapefilename=fshp)

The formatting got messed up in the mail.  sdata should be in line with 
fshp/fout.

Mario Beauchamp wrote:
> Hi all,
> 
> I added this to my GViewApp class:
> 
> def new_project( self ):
>     layers = self.layerdlg.list_layers()
>     view = self.layerdlg.get_active_view()
>     for layer in layers:
>         view.remove_layer(layer)

Mario,

There is already a "clear_project" method in gvviewapp.py.  It destroys all views:

     def clear_project( self ):
         self.view_manager.close_all_views()
         pass

It is used in the project loading code.  So I think a more appropriate implementation
of a new_project() method would likely be to do a clear_project() and then new_view().
This would give you a clean slate for a new project.  Your approach seems to only clear all
layers off the current view and could live a variety of non-default state on the app
including other views and view/projection settings on the current view.

Myself, I am not convinced a new_project() method is necessary.

> This is simply a quick way to clear all layers in a view and start a new project. Do I need to do
> something else? Is that the best way to do it? Seems to work, anyway...
> 
> Also (duh!), the line "self.add_to_rfl(filename)" was right there in save_project_with_name_cb() a
> few lines below so adding the line to load_project() solved a problem I mentioned before. I should
> have looked at the code <;

Added the add_to_rfl() when loading existing projects.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi Frank,

On Mon, 23 Aug 2004 11:24:41 -0400, Frank Warmerdam <warmerdam@...> wrote:

>There is already a "clear_project" method in gvviewapp.py.  It destroys all views:
>
>     def clear_project( self ):
>         self.view_manager.close_all_views()
>         pass

I had noticed. But somehow, I wrongly thought that "close_all_views()" would cause problems.

>It is used in the project loading code.  So I think a more appropriate implementation
>of a new_project() method would likely be to do a clear_project() and then new_view().

Of course! That does it exactly! Duh! :)

>Myself, I am not convinced a new_project() method is necessary.

So how would you start a new project then?

>Added the add_to_rfl() when loading existing projects.

Cool :)

Thanks for the tip!
--
Mario B.

Hi,

Here's one easy (quick and dirty) way to reproject on
the fly:

1-Hook to the layer's signal "setup"
    gtk_signal_connect_object(GTK_OBJECT(layer),
"setup",
                     
GTK_SIGNAL_FUNC(gv_my_layer_setup),
                      GTK_OBJECT(layer));

2-In gv_my_layer_setup, and for all shapes do:

   // exemple with line
   GvLineShape  *line   = (GvLineShape *) shape;
   int    npt   = line->num_nodes;
   pt3 *data = line->xyz_nodes;
   pt3 *pt     = data;

   // deg to rad
   for (i=0; i<npt; ++i, ++data)
        data->x *= DEG_TO_RAD,
        data->y *= DEG_TO_RAD;

    // rad to proj
    pj_transform(pjsrc, pjdst, npt, 3, &pt->x, &pt->y,
&pt->z);



That it!

Well that's the general idea. What happend is that
the coordinates are reprojected 'in place' right after
they
where pulled by OGR. It act like a filter more or
less.
OpenEV doesn't seem to notice as far as I can tell.
Note that OpenEV must be configure'd with 
--with-double-geocoord for this to work.

The RightWay(tm) would probably be to do the
reprojection
at the GDAL/OGR level since PROJ live over there.

I just wanted to add that to the openev projection
debate 
(though its not clear if its for or against.)


Cheers,

Sylvain.






--- Julien Demaria <dem@...> wrote:

> Andrey,
> 
> I've seen in the TODO list that you plan (long term)
> to implement vector 
> layer reprojection, and also that you work on
> changing projection on the 
> fly (preliminary support).
> 
> What are exactly your plans about these points ?
> Will OpenEV automatically reproject vector layers
> into the view projection ?
> And about rasters, do you plan to implement support
> of rasters with 
> different projections in the same view ?
> Will rasters be reprojected on the fly ?
> 
> 
> Thanks in advance,
> 
> Julien
> 
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest
> price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R
> for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping
> and Free Gift.
>
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Openev-discuss mailing list
> Openev-discuss@...
>
https://lists.sourceforge.net/lists/listinfo/openev-discuss
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

s duclos wrote:
> Hi,
> 
> Here's one easy (quick and dirty) way to reproject on
> the fly:
> 
> 1-Hook to the layer's signal "setup"
>     gtk_signal_connect_object(GTK_OBJECT(layer),
> "setup",
>                      
> GTK_SIGNAL_FUNC(gv_my_layer_setup),
>                       GTK_OBJECT(layer));
> 
> 2-In gv_my_layer_setup, and for all shapes do:
> 
>    // exemple with line
>    GvLineShape  *line   = (GvLineShape *) shape;
>    int    npt   = line->num_nodes;
>    pt3 *data = line->xyz_nodes;
>    pt3 *pt     = data;
> 
>    // deg to rad
>    for (i=0; i<npt; ++i, ++data)
>         data->x *= DEG_TO_RAD,
>         data->y *= DEG_TO_RAD;
> 
>     // rad to proj
>     pj_transform(pjsrc, pjdst, npt, 3, &pt->x, &pt->y,
> &pt->z);
> 
> 
> 
> That it!
> 
> Well that's the general idea. What happend is that
> the coordinates are reprojected 'in place' right after
> they
> where pulled by OGR. It act like a filter more or
> less.
> OpenEV doesn't seem to notice as far as I can tell.
> Note that OpenEV must be configure'd with 
> --with-double-geocoord for this to work.
> 
> The RightWay(tm) would probably be to do the
> reprojection
> at the GDAL/OGR level since PROJ live over there.
> 
> I just wanted to add that to the openev projection
> debate 
> (though its not clear if its for or against.)

Sylvain,

I would note that gv_reproject_points() (in gvutils.c) is the preferred
entry point for reprojecting data.  It uses the OGRCoordinateTransformation
which in turn uses PROJ.4 of course.  It also avoids the DEG_TO_RAD
step.

int gv_reproject_points( const char *source_srs,
                          const char *destination_srs,
                          int count, double *x, double *y, double *z )

I am not sure how a general solution should be done. The original
conception was that the GvShapesLayer would maintain a copy of the
vector data in the GvShapes but reprojected into the GvShapesLayer
coordinate system for faster display.  This seems awfully expensive in
memory to me, and very hard to keep synchronized.

My suggestion for an approach would just be to modify the GvShapesLayer
rendering code to include the ability to apply an on-the-fly reprojection
during rendering if needed.  This would be kind of slow for alot of
vectors but most of the time no reprojection is needed anyways.

It would also require quite a bit of fiddling in the complex GvShapesLayer
rendering functions to include the reprojection support.

Finally, we need to keep track of coordinate systems on the GvShapes objects.
The GvShapesLayer would need to compare the projection on the view to the
one on the GvShapes to see if conversion was needed.

It is also desirable at some point to have a dialog for setting the
coordinate system on a view window.  Currently it inherits its coordinate
system from the first raster layer loaded.

--

All this said, Sylvain's approach is indeed workable as a partial hack to
get reprojected vector display working for specific needs.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

Hi Frank,


--- Frank Warmerdam <warmerdam@...> wrote:

> s duclos wrote:
[...]

> Sylvain,
> 
> I would note that gv_reproject_points() (in
> gvutils.c) is the preferred
> entry point for reprojecting data.  It uses the
> OGRCoordinateTransformation
> which in turn uses PROJ.4 of course.  It also avoids
> the DEG_TO_RAD
> step.
> 
> int gv_reproject_points( const char *source_srs,
>                           const char
> *destination_srs,
>                           int count, double *x,
> double *y, double *z )
> 
> I am not sure how a general solution should be done.
> The original
> conception was that the GvShapesLayer would maintain
> a copy of the
> vector data in the GvShapes but reprojected into the
> GvShapesLayer
> coordinate system for faster display.  This seems
> awfully expensive in
> memory to me, and very hard to keep synchronized.
>

I'm not sure either! but I have been coding different
way
to see what would be the "best".

What I have now is some sort of oneway 'pipe' that
goes from the HD to the CRT because the opposite
is expensive  (for OpenGL a least.) So it look like
this:

OGR->PROJ->tess->glDisplayList->glDrawArray

Once its in DrawArray/DisplayList its "gone" and live
only on the graphic hardware. So the memory above
(in GV) could be freed.

The trick is in orgenazing the display lists. 
Its a 'science' all by it self  (see OSG
-openscenegraph.sf.net)
when doing real-time rendering.

For GV it would mean handling the index to the
displaylist.
In fact OpenEV act like a scenegraph but hold all the
data
(unless every thing is in a displaylist.)

A scenegraph is a tree data structure and has 3 steps
(tree traversal):
1- APP: update a scene (add/del object from the tree)
2- CULL: discard object not in view
3- DRAW: GPU redering

3 is the most expensive (95% of the work)
1&2 are done by the CPU

Any way I'm mentioning this because with today
graphic hardware we can look into 'serious fun'  and
ppl have been optimising for that for some time now.
This in turn could affect the way we look at the stuff
at
the upper level (ie in GV.) 

To check for that I have done S52 3D rendering using
OpenEV + OSG (via libS52) to get 'allmost' real-time 
rendering on my old machine :) 

Again the idea is to look into what other are doing
with their big iron to get some hint. 

Not trying to turn openev into RT mode :)


Cheers,

Sylvain.




		
_______________________________
Do you Yahoo!?
Win 1 of 4,000 free domain names from Yahoo! Enter now.
http://promotions.yahoo.com/goldrush

Hi,

On the subject of vectors and reprojection, I have a few somewhat 
tangential comments/questions (I'm only starting to really look into 
openev/gdal's projection-related code, so some of these may be a bit 
ignorant):

1) Currently shapefile .prj files are ignored by openev.  Does anyone 
know of a reason why they shouldn't be read if present and the 
projection set on the GvShapes object using the GvData set_projection 
function when a shapefile is opened in openev?

2) One comment that a number of users have made to me is that it would 
be nice to have vectors that are loaded on top of a georeferenced raster 
get reprojected to the pixel/line coordinates of the raster when the 
georeferencing toggle is pressed so that the vectors still show up in 
pixel/line mode (or vice versa if the vectors were drawn on a raster 
that was in pixel/line mode).  I haven't put anything to address this 
into the openev core because I wasn't sure if it was a general enough 
sort of problem, and there are a number of considerations (how to match 
the vector file to a raster- especially if more than one is open in a 
given view, how to indicate whether the vectors were drawn in 
georeferenced or pixel/line coordinates, how to make sure the editing 
tools still work, etc.).  It could perhaps be solved if prj files were 
read and could contain a raster filename for the pixel/line case, but 
would be quite a bit of work to implement and test properly.  Has anyone 
else run into situations where this capability would be considered useful?

3) OpenEV uses internal shapefile code, but ogr for all other vector 
files (unless it's changed since last time I looked).  I don't know 
whether or not there would be any advantage to using ogr's shapefile 
code instead of openev's if present.  Does ogr automatically read .ofs 
(ogr feature style) files associated with a shapefile?

4) Frank, when you mention "complex GvShapesLayer rendering functions 
that would need fiddling with" for reprojection, which ones are you 
thinking of?  I guess the editing tools would have to be modified, for a 
start.

Gillian

Frank Warmerdam wrote:

>
> Sylvain,
>
> I would note that gv_reproject_points() (in gvutils.c) is the preferred
> entry point for reprojecting data.  It uses the 
> OGRCoordinateTransformation
> which in turn uses PROJ.4 of course.  It also avoids the DEG_TO_RAD
> step.
>
> int gv_reproject_points( const char *source_srs,
>                          const char *destination_srs,
>                          int count, double *x, double *y, double *z )
>
> I am not sure how a general solution should be done. The original
> conception was that the GvShapesLayer would maintain a copy of the
> vector data in the GvShapes but reprojected into the GvShapesLayer
> coordinate system for faster display.  This seems awfully expensive in
> memory to me, and very hard to keep synchronized.
>
> My suggestion for an approach would just be to modify the GvShapesLayer
> rendering code to include the ability to apply an on-the-fly reprojection
> during rendering if needed.  This would be kind of slow for alot of
> vectors but most of the time no reprojection is needed anyways.
>
> It would also require quite a bit of fiddling in the complex 
> GvShapesLayer
> rendering functions to include the reprojection support.
>
> Finally, we need to keep track of coordinate systems on the GvShapes 
> objects.
> The GvShapesLayer would need to compare the projection on the view to the
> one on the GvShapes to see if conversion was needed.
>
> It is also desirable at some point to have a dialog for setting the
> coordinate system on a view window.  Currently it inherits its coordinate
> system from the first raster layer loaded.
>
> -- 
>
> All this said, Sylvain's approach is indeed workable as a partial hack to
> get reprojected vector display working for specific needs.
>
> Best regards,

Hi Gillian,

On Fri, 20 Aug 2004 09:53:52 -0400, Gillian Walter <gillian.walter@...> wrote:

>>When I export an image that has been enhanced using another algorithm than linear (log, root, etc),
>>the exported image is always linear enhanced. Is that the expected result?
>>
>Yes, this is expected.  "Scale to View" just means that the layer's 
>scale min and scale max are used.  The export tool does its rescaling 
>using the VRT's ScaleOffset and ScaleRatio features.  There aren't any 
>that I'm aware of for log, root, complex luts, etc.

That's unfortunate... so the only solution is screen capture then. Which is a pain in the butt with
images larger than the screen :)

BTW, can someone explain how scale min and scale max translate to ScaleOffset and ScaleRatio? I must
admit I don't see the relation at all...

Thanks!
--
Mario B.

Hi,

>BTW, can someone explain how scale min and scale max translate to ScaleOffset and ScaleRatio? I must
>admit I don't see the relation at all...
>  
>
This is my understanding of it:

srcmin,srcmax- range of values to use from input dataset
dstmin, dstmax- range of values in output dataset (0, 255 for byte 
output- this is what scale to view uses)

ratio = (dstmax-dstmin)/(srcmax-srcmin) = number to scale input values by
offset = dstmin-(srcmin*ratio) = amount to add to scaled values

output _value = (ratio*input_value) + offset

Input values above srcmax are set to dstmax in output; input values 
below srcmin are set to dstmin.

Gillian


>Thanks!
>--
>Mario B.
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
>_______________________________________________
>Openev-discuss mailing list
>Openev-discuss@...
>https://lists.sourceforge.net/lists/listinfo/openev-discuss
>  
>

Salut Mario,

It just occur to me (first coffe.) But this sound like
a job for:

gdk_gl_pixmap_new - create an off screen rendering
area

See the man for glXCreateGLXPixmap:
 - create an off-screen GLX rendering area

Or off-line rendering I think its called at the OS
(Linux) level
(it's used to draw stuff on computer with no screen.)


Just a thought.

Sylvain.


--- Mario Beauchamp <starged@...> wrote:

> Hi all,
> 
> Quoting myself:
> 
> >I had never used the print-to-file option until
> now.
> >Tried it today and got a blank image so I am not
> sure what went wrong...
> 
> Scratch that. Nothing's wrong. Besides me, I mean :)
> 
> However, it does not solve my problem since it only
> prints the view and not the whole image.
> 
> Ah, well...
> --
> Mario B.
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest
> price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R
> for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping
> and Free Gift.
>
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Openev-discuss mailing list
> Openev-discuss@...
>
https://lists.sourceforge.net/lists/listinfo/openev-discuss
> 



		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

Hi,

Frank Warmerdam wrote:

>
>> - Alpha channel is ignored when exporting an image.
>
>
> Your referring to the "File->Export" mechanism, right?  Not the 
> print-to-file
> style exporting?  Do you mean that the alpha channel isn't even 
> written out
> to the new file or just that it isn't marked properly as being an 
> alpha channel?
> I don't know too much about the export capability so perhaps Andrey 
> will look
> into this if you can be more specific about the issue.

I assume he means the scale-to-view function ignores the alpha channel?  
I'll fix this.  I never use the alpha channel myself, and forgot about 
it when implementing the scaled export.

Gillian

Mario Beauchamp wrote:

>- Alpha channel is ignored when exporting an image.
>  
>
I've updated the export tool in cvs so that the alpha channel shouldn't 
be ignored in view scaling anymore.  Note that the fourth channel will 
only be recognized as an  alpha channel by formats that can store this 
sort of info (eg. GTiff, VRT); others will see it as an ordinary fourth 
channel.  I also removed DTED from the generated list of output formats, 
since the creation of a valid dted file is beyond the scope of the 
export tool (it would create a file, but the dted spec places stringent 
requirements on file sizes/resolutions that can't be met by the export 
tool, so the file wasn't truely dted). 


Gillian

Hi Frank and all,

Well, you folks have been busy this morning! :)

I will clarify some points here..

On Fri, 20 Aug 2004 10:39:40 -0400, Frank Warmerdam <warmerdam@...> wrote:

>> - After a lot of interactions, the layers dialog gets "screwed up" and I get numerous:
>
>Have noticed this myself on occasion but I am not really too sure how to dig into it.
>It also doesn't seem to happen very frequently or repeatedly for me, though I may just
>not have tried hard enough to isolate the issue.

Clicking repeatedly on the visibility icon will eventually cause the problem.

>> - Opening a new view freezes the existing one.
>
>Always?  Just under some circumstances?  This sounds like it is mostly like
>an interaction with a particular underlying OpenGL driver, relating to managing
>more than one OpenGL state.

Since this one is difficult to describe, I was hoping that somebody else had noticed that...

Typically, it goes like this: open a new View, and go back to View1. The now uncovered portion of
View1 is not redrawn. Go back to View2 and then View1 again and now it looks ok. Zoom-in on View1
and the scrollbars change size but image stays the same. Go back to View2 and then View1 and now
it's ok. And it goes on like this. Closing View2 doesn't solve the problem and we have to shutdown
OpenEV.

Hope this clarifies the problem.

As for the cause of this and others, my bet is the GTK win32 port which I read somewhere is not very
well done.

>> - Dialog sometimes have weird dimensions.
>
>Can you be more specific?

For example, the progress dialog can be 3-4 times higher than wide. Same with other dialogs.
However, this behavior is unpredictable and not easy to reproduce. Wouldn't be surprised if this was
another of GTK's annoyances.

>> - Opening and closing an image that is not georeferenced causes all subsequent images to open
>> flipped/inverted.
>
>This should be fixable.   I see what I can figure out this morning.

Saw you did. Thanks!

>> - Alpha channel is ignored when exporting an image.
>
>Your referring to the "File->Export" mechanism, right?  Not the print-to-file
>style exporting?

Yes. I had never used the print-to-file option until now. Tried it today and got a blank image so I
am not sure what went wrong...

>Do you mean that the alpha channel isn't even written out to the new file

Exactly. Even when exporting from a tiff file already having an Alpha channel.

>> - The tracker tool coordinates preference cannot be changed for a project.
>
>There is a general issue with regard to preferences and whether they should be
>saved in projects or not.

So what does this line in a project file mean?

<Translation x="-336160.46875" y="-5934558.0"/>

>> - The ROI tool is unreliable and should "snap" to the pixel resolution.
>
>Do you mean specifically when used with the export tool?

Yes. And when I use it for my fusion tool.

>The ROI tool does have a mode that restricts it within the outer boundary of a raster and I can
>see that it would be nice to further be able to restrict it to a pixel boundary

Yes since it's illogical to cut a pixel in half, for example :)
To do my fusions, I need the images to match perfectly and to ensure that, I have to zoom-in deep to
set the ROI correctly on pixel boundaries (actually, just slightly inside the ul corner and slightly
outside the lr corner).

>> - Root and square enhancements have been left out from the possible choices (had to add them)
>
>Do you mean that the icons aren't available on the icon bar?

Yes. Fortunately, the XML config makes it easy to add them. We only have to add the callback
functions in gvviewwindow. 

>They were deliberately omitted to avoid clogging up the icon bar with too many
>enhancement options when they are rarely alot better than those that are available.

I tend to disagree on that one: for example, I have no use for Equalization but I discovered that
root enhancement is the one I really need... 

>We really need some sort of popup list of actions we can apply to a raster layer.

That would be a good idea.

>> - Exporting many layers into a single image (ie, mosaics, alpha channel blending)
>
>Currently the only mechanism to accomplish this is the print-to-file
>approach.  Otherwise it would be quite complex and in many ways out of
>the scope of OpenEV.

Couldn't we adapt the code from gdal_merge.py to do this?

>> - Add an option to use Averaging when exporting at 1:2, 1:4, 1:8
>
>Hmm, interesting option.  It would be fairly complicated to implement
>though I think since I believe the export tool currently depends on
>GDAL to do the downsampling and GDAL doesn't have a really easy way
>of accomplishing this.

I made a temporary fix to serializeBand in vrtutils.py like this:

[...]
if opt_dict['DstRect'][2] != opt_dict['SrcRect'][2]:
    ssbase=[gdal.CXT_Element,'AveragedSource']
else:
    ssbase=[gdal.CXT_Element,'SimpleSource']
[...]

However, this causes problems in other uses of vrtutils...
But I think using VRTAveragedSource is a simple way to accomplish that.

And what about the GDAL warper functions? Is there a reason why they don't have Python wrappers?

>Thanks for the great feedback.  Hopefully we can act on a few of these at least.

And thanks to you all for taking the time to read and respond!
--
Mario B.

Hi Gillian,

On Fri, 20 Aug 2004 10:50:23 -0400, Gillian Walter <gillian.walter@...> wrote:

>>- Opening a new view freezes the existing one.
>>
>I've never seen this- is it possible there's some video issue?

See a more detailed description in my previous post.

>>- Dialog sometimes have weird dimensions.
>>
>Which dialogs?

Anyone of them. As I said, this is unpredictable.

>>- Opening and closing an image that is not georeferenced causes all subsequent images to open
>>flipped/inverted.
>>
>It's not a fix, but you can flip an image in the vertical direction 
>using Ctrl-F2 (Ctrl-F1 for horizontal).

Thanks for that tip! I'll have to use that until the next OpenEV_FW release (I don't compile OpenEV
anymore, too many problems)

>>- Add an option to use Averaging when exporting at 1:2, 1:4, 1:8
>>
>The export tool follows the VRT's convention of using existing 
>overviews, or else decimating.  If you have an image with averaged 
>overviews, it will use them.

See my suggestion about using VRTAveragedSource.

(Later)

>I assume he means the scale-to-view function ignores the alpha channel?  

I meant that the alpha channel was not written at all to the file.

>I've updated the export tool in cvs so that the alpha channel shouldn't 
>be ignored in view scaling anymore.

It wasn't exactly the problem but I assume this update will correct it. I'll test it further and
will report on it.

Thanks!
--
Mario B.