[Gdal-dev] modis sinusoidal tiles: bug in gdal?

[Vincent Schut]

Norman Vine wrote:
>>>
>>> Vincent,
>>>
>>> vrt_merge.py isn't part of GDAL - could you provide a pointer to the
>>> version you are using?
>>>       
>> 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:
>> http://www.vso.cape.com/~nhv/files/gdal/gdal_vrtmerge.py, 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.
>>     
>
>
> AFAIK this is now part of the gdal distribution
>
> http://trac.osgeo.org/gdal/browser/trunk/gdal/pymod/samples/gdal_vrtmerge.py
>
> 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
>   
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?
Anyway, both versions choke on my sub-nanometer scale difference, so
there might be some improvement possible.
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 :)
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?

VS.
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20071107/2fca361c/attachment.html