<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Norman Vine wrote:
<blockquote cite="mid:20071106123419.7A35F28018@mrelay1.cape.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
<pre wrap="">Vincent,
vrt_merge.py isn't part of GDAL - could you provide a pointer to the
version you are using?
</pre>
</blockquote>
<pre wrap="">I know that. It is however a very valuable tool for me :-)
I think I picked it up from the ml somewhere sometime long ago... Not
easy to provide a pointer. Might have been this one:
<a class="moz-txt-link-freetext" href="http://www.vso.cape.com/~nhv/files/gdal/gdal_vrtmerge.py">http://www.vso.cape.com/~nhv/files/gdal/gdal_vrtmerge.py</a>, but I'm not
sure. And I've adapted it to correct for an index error in the
colortable support somewhere, if I remember correctly. And for
ngbindings instead of ogbindings. I can send you a copy if you'd like.
</pre>
</blockquote>
<pre wrap=""><!---->
AFAIK this is now part of the gdal distribution
<a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/browser/trunk/gdal/pymod/samples/gdal_vrtmerge.py">http://trac.osgeo.org/gdal/browser/trunk/gdal/pymod/samples/gdal_vrtmerge.py</a>
I can't remember when I fixed the 'precision' to match the GDAL 'C'
expectations
So I would try the version above might get lucky :-)
Cheers
Norman
</pre>
</blockquote>
This version (from gdal svn) seems slightly older than the version I
found somewhere, and which I have changed a bit since then. The newer
version contains a line in the changelog that sais "Be more careful in
rounding for computing xsize/ysize." by you (Norman), but I see no
other difference when diffing with the version from gdal's
pymod/samples except for my own edits. Maybe you forgot to actually
implement it?<br>
Anyway, both versions choke on my sub-nanometer scale difference, so
there might be some improvement possible.<br>
Currently, my version of the script is adapted to use ngpython
(osgeo.gdal), has a bug fixed (I think) regarding colortable support,
and has nodata propagation from source to destination vrt bands. I
could try to implement some precision-diminishing code for coordinates
and pixel sizes. Would gdal be interested in an update of this script?
I'd like to have someone (preferable the creator?) review my changes,
especially the colortable thing, to make sure I didn't accidentally
break something. I only tested it on very specific datasets :)<br>
What would be the prefered way to handle the precision issue? Simply
round to let's say 8 or 10 digits after the dot, and compare likewise?
Would that be enough precision for all use cases, like degree based
crs's too?<br>
<br>
VS.<br>
<blockquote cite="mid:20071106123419.7A35F28018@mrelay1.cape.com"
type="cite">
<pre wrap="">
_______________________________________________
Gdal-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gdal-dev@lists.maptools.org">Gdal-dev@lists.maptools.org</a>
<a class="moz-txt-link-freetext" href="http://lists.maptools.org/mailman/listinfo/gdal-dev">http://lists.maptools.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
</body>
</html>