Re: [gdal-dev] Licensing Policy for drivers and applications

[Even Rouault]

Frank,

It looks mostly good to me.

A few remarks :

1) I had a strange feeling when I read that "In the absence of a user or 
application level policy, default to a policy of "PREFER_PROPRIETARY"". It 
sounds a bit paradoxical for an open source library... I guess that on Linux, 
it should be "PREFER_RECIPROCAL" and "PREFER_PROPRIETARY" on Windows. Just 
kidding...

2) We don't control the licence of third party libraries and their licencing 
terms can thus change over the time or have multiple licencing terms.

a) For example, currently the GDAL EPSILON driver relies on the epsilon 
library which is currently GPL. But Alessandro Furieri (Spatialite/Rasterlite 
author ) asked to the author of libepsilon if he would agree to relicence it 
under LGPL because what makes librasterlite GPL is the epsilon dependency. ( 
http://groups.google.com/group/spatialite-
users/browse_thread/thread/503faf18b78c3c6e/adbd5b7cef1cb5e8 ). This has been 
accepted but no newer release of libepsilon has been yet released. Admitedly 
licencing changes don't occur frequently so we can just indicate the ones of 
the latest released version of the third party library.

(Note: this doesn't affect the GDAL rasterlite driver that is an independant 
implementation that doesn't use librasterlite)

b) For MySQL, it depends on whether you use the open source version (GPL) or 
the commercial version.

3) Licences of the drivers :

* In the list of reciprocal drivers, you can add PDF (because of poppler being 
GPL) 
* I'm not sure for the GPSBabel driver. The driver doesn't technically link to 
GPSBabel (GPL) but communicate it with it through fork / exec / pipe. Does it 
make the driver to be bound to the GPL ?
* As far as ODBC, PGEO, MSSQLSPATIAL (and GEOMEDIA in trunk), it depends on 
the actual ODBC library... On unix, unixODBC is LGPL.
* The OGR SOSI driver should probably be marked as proprietary currently as it 
relies on linking with binary objects with unknown licencing terms, even if 
apparently the ultimate goal seems to open source them.
* I'm not sure for the ArcSDE Raster. I imagine this should be commercial ?
* I'm a bit confused by http://gdal.org/frmt_msg.html. Seems that it relies on 
third party stuff with both proprietary and GPL code.

4) A technical detail, but Python bindings automatically register the drivers 
when importing gdal or ogr modules, so it would not be possible to do a 
gdal.SetConfigOption('GDAL_LICENSE_POLICY', 'USE_ALL'), but 
os.environ['GDAL_LICENSE_POLICY'] = 'USE_ALL' should work

5) I was wondering if it wouldn't be nice to have a *build* option that could 
be equivalent to setting GDAL_LICENSE_POLICY = USE_ALL. That would only be 
usefull for power users that build their own GDAL for their own purposes and 
don't intend distributing it. Obviously neither Linux distributions nor 
OSGeo4W should use it, so that makes its use case scarce.

That's all for tonight !

Best regards,

Even

> Folks,
> 
> I have been thinking about how to adjust OSGeo4W in particular, and GDAL
> in general to make it easier to distribute software in a way that complies
> with the conflict between GPLed software and proprietary software.
> 
> In the case of OSGeo4W the main restrictions is that we should not be
> distributing GRASS in such a way that proprietary drivers like the MrSID
> driver can be used without the user having knowingly combined them by
> themselves.
> 
> To that end, I have prepared an RFC which attempts to address this at
> the GDAL driver registration level.  I'd appreciate feedback:
> 
>http://trac.osgeo.org/gdal/wiki/rfc34_license_policy
> 
> Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Marius Jigmond]

The link should work for another day or so (automatic server purge). I
can re-upload it if you don't get the chance to download it. Warning:
1.2GB.
https://www.twdb.state.tx.us/filetxfr/emaillinkdownload.aspx?id=&FileTransferID=289562464

-marius

-- 
Sent from Ubuntu



On Sat, 2011-01-29 at 22:25 +0100, Even Rouault wrote: 
> Le samedi 29 janvier 2011 22:17:45, Marius Jigmond a écrit :
> > Just realized that earlier I hit the wrong reply button (apologies).
> > 
> > The COPY_SRC_OVERVIEWS yielded a wild result. Here's what I did:
> > 1. gdaladdo -ro s70rgb321.tif 2 4 8 16 32 64 128 (note: input GTiff is 3
> > band with nodata=0 and no mask)
> > 2. gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90
> > -co PHOTOMETRIC=YCBCR -co COPY_SRC_OVERVIEWS=YES s70rgb321.tif test1.tif
> > 
> > The result: http://tinypic.com/r/110gig4/7
> > 
> > The top (~)quarter of the original image is replicated downwards up to
> > the original extent of the image. I would have expected the artifacts
> > but not this :). According to the http://www.gdal.org/frmt_gtiff.html
> > COPY_SRC_OVERVIEWS is applied as long as no general options are passed.
> 
> This is weird. Do you have a link so I can download s70rgb321.tif and test ?
> 
> > 
> > -marius
> > 
> > > Le samedi 29 janvier 2011 20:28:02, Marius Jigmond a écrit :
> > > > Thanks Even. I ran some more tests but that didn't quite work for me. I
> > > > still get those noisy pixels after gdal_translate (in QGIS I set value
> > > > 0 for transparency and those pixels stand out). However, I noticed the
> > > > following:
> > > > 
> > > > * nearblack -setmask shrinks the significant pixels area (expected?)
> > > > * the near black noise pixels seem to follow a stair step pattern
> > > > similar to the edge of the significant area but at a different scale
> > > > (larger steps, if what I just said makes sense) and extend past the
> > > > significant data areas in both masked and unmasked datasets.
> > > 
> > > Ah yes, nearblack has some default parameters that can account for this.
> > > See the -near and -nb parameters of http://gdal.org/nearblack.html
> > > 
> > > You can set them to 0 to have strict nearblack behaviour.
> > > 
> > > > I was aware of the fact that nodata values are band specific but I had
> > > > a little brain glitch from working with gdaladdo (which honors nodata
> > > > only as a triplet nodata). That's how I actually ran into the problem.
> > > > I am trying to compress a RGB GeoTIFF using JPEG and then generate
> > > > compressed overviews. We plan to serve some imagery through Geoserver
> > > > and would like to stick to open-source solutions. The compressed
> > > > datasets are significantly smaller and with overviews they are
> > > > extremely responsive, rendering very fast). OpenJPEG v2 looks great
> > > > but I haven't found support for it in Geoserver, yet.
> > > 
> > > To limit the issues with artifacts, I would compute the overviews on the
> > > uncompressed dataset and then translate the whole full resolution +
> > > overviews into a JPEG compressed TIFF with the new COPY_SRC_OVERVIEWS
> > > option of the GTiff driver.
> > > 
> > > I'm not sure that JPEG2000 would solve the issue. This would need to be
> > > checked if alpha channel is strictly preserved.
> > > 
> > > For the record, MapServer is able to use nodata mask band as transparency
> > > channel.
> > > 
> > > > -marius
> > > > 
> > > > On Sat, 2011-01-29 at 16:13 +0100, Even Rouault wrote:
> > > > > Le samedi 29 janvier 2011 15:47:43, Marius Jigmond a écrit :
> > > > > > Hi Everyone,
> > > > > > 
> > > > > > I am having some trouble figuring out why adding JPEG compression
> > > > > > to a RGB GeoTIFF results in Nodata pixel triplets becoming data
> > > > > > pixel triplets. Is this expected behavior due to the noisy nature
> > > > > > of JPEG compression or to the fact that these are border Nodata
> > > > > > triplets? I know certain algorithms process the boundary between
> > > > > > data and Nodata differently.
> > > > > 
> > > > > Marius,
> > > > > 
> > > > > Yes you did find the cause : the pixels maching nodata values will be
> > > > > JPEG compressed, so you have no guarantee that the 0 value is
> > > > > preserved through compression/decompression. I'd also note that the
> > > > > nodata concept in GDAL is a per-band value (so it should not be
> > > > > interpreted as a nodata "triplet")
> > > > > 
> > > > > A possibility to workaround this would be to create a "nodata mask
> > > > > band" (see http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask), but
> > > > > I'm pretty sure that QGIS ignores those mask bands.
> > > > > 
> > > > > Anyway, if you want to try and create one, you can :
> > > > > 
> > > > > 1) Use nearblack to create a nodata mask band based on (0,0,0)
> > > > > triplet nearblack -setmask -of GTiff -o out_with_mask.tif in.tif
> > > > > 
> > > > > (the -setmask option is new in GDAL 1.8.0)
> > > > > 
> > > > > 2) Then compress the dataset with
> > > > >

Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Even Rouault]

Le samedi 29 janvier 2011 22:17:45, Marius Jigmond a écrit :
> Just realized that earlier I hit the wrong reply button (apologies).
> 
> The COPY_SRC_OVERVIEWS yielded a wild result. Here's what I did:
> 1. gdaladdo -ro s70rgb321.tif 2 4 8 16 32 64 128 (note: input GTiff is 3
> band with nodata=0 and no mask)
> 2. gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90
> -co PHOTOMETRIC=YCBCR -co COPY_SRC_OVERVIEWS=YES s70rgb321.tif test1.tif
> 
> The result: http://tinypic.com/r/110gig4/7
> 
> The top (~)quarter of the original image is replicated downwards up to
> the original extent of the image. I would have expected the artifacts
> but not this :). According to the http://www.gdal.org/frmt_gtiff.html
> COPY_SRC_OVERVIEWS is applied as long as no general options are passed.

This is weird. Do you have a link so I can download s70rgb321.tif and test ?

> 
> -marius
> 
> > Le samedi 29 janvier 2011 20:28:02, Marius Jigmond a écrit :
> > > Thanks Even. I ran some more tests but that didn't quite work for me. I
> > > still get those noisy pixels after gdal_translate (in QGIS I set value
> > > 0 for transparency and those pixels stand out). However, I noticed the
> > > following:
> > > 
> > > * nearblack -setmask shrinks the significant pixels area (expected?)
> > > * the near black noise pixels seem to follow a stair step pattern
> > > similar to the edge of the significant area but at a different scale
> > > (larger steps, if what I just said makes sense) and extend past the
> > > significant data areas in both masked and unmasked datasets.
> > 
> > Ah yes, nearblack has some default parameters that can account for this.
> > See the -near and -nb parameters of http://gdal.org/nearblack.html
> > 
> > You can set them to 0 to have strict nearblack behaviour.
> > 
> > > I was aware of the fact that nodata values are band specific but I had
> > > a little brain glitch from working with gdaladdo (which honors nodata
> > > only as a triplet nodata). That's how I actually ran into the problem.
> > > I am trying to compress a RGB GeoTIFF using JPEG and then generate
> > > compressed overviews. We plan to serve some imagery through Geoserver
> > > and would like to stick to open-source solutions. The compressed
> > > datasets are significantly smaller and with overviews they are
> > > extremely responsive, rendering very fast). OpenJPEG v2 looks great
> > > but I haven't found support for it in Geoserver, yet.
> > 
> > To limit the issues with artifacts, I would compute the overviews on the
> > uncompressed dataset and then translate the whole full resolution +
> > overviews into a JPEG compressed TIFF with the new COPY_SRC_OVERVIEWS
> > option of the GTiff driver.
> > 
> > I'm not sure that JPEG2000 would solve the issue. This would need to be
> > checked if alpha channel is strictly preserved.
> > 
> > For the record, MapServer is able to use nodata mask band as transparency
> > channel.
> > 
> > > -marius
> > > 
> > > On Sat, 2011-01-29 at 16:13 +0100, Even Rouault wrote:
> > > > Le samedi 29 janvier 2011 15:47:43, Marius Jigmond a écrit :
> > > > > Hi Everyone,
> > > > > 
> > > > > I am having some trouble figuring out why adding JPEG compression
> > > > > to a RGB GeoTIFF results in Nodata pixel triplets becoming data
> > > > > pixel triplets. Is this expected behavior due to the noisy nature
> > > > > of JPEG compression or to the fact that these are border Nodata
> > > > > triplets? I know certain algorithms process the boundary between
> > > > > data and Nodata differently.
> > > > 
> > > > Marius,
> > > > 
> > > > Yes you did find the cause : the pixels maching nodata values will be
> > > > JPEG compressed, so you have no guarantee that the 0 value is
> > > > preserved through compression/decompression. I'd also note that the
> > > > nodata concept in GDAL is a per-band value (so it should not be
> > > > interpreted as a nodata "triplet")
> > > > 
> > > > A possibility to workaround this would be to create a "nodata mask
> > > > band" (see http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask), but
> > > > I'm pretty sure that QGIS ignores those mask bands.
> > > > 
> > > > Anyway, if you want to try and create one, you can :
> > > > 
> > > > 1) Use nearblack to create a nodata mask band based on (0,0,0)
> > > > triplet nearblack -setmask -of GTiff -o out_with_mask.tif in.tif
> > > > 
> > > > (the -setmask option is new in GDAL 1.8.0)
> > > > 
> > > > 2) Then compress the dataset with
> > > > gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90
> > > > -co PHOTOMETRIC=YCBCR out_with_mask.tif out_compressed.tif
> > > > 
> > > > Only the RGB channels will be JPEG compressed : the mask band will
> > > > use lossless compression so you won't have artifacts at the borders
> > > > between significant areas and nodata areas.
> > > > 
> > > > (You can add --config GDAL_TIFF_INTERNAL_MASK YES to make the nodata
> > > > mask internal to the GTiff file, instead of having a .tif.msk
> > > > ext

Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Marius Jigmond]

Just realized that earlier I hit the wrong reply button (apologies).

The COPY_SRC_OVERVIEWS yielded a wild result. Here's what I did:
1. gdaladdo -ro s70rgb321.tif 2 4 8 16 32 64 128 (note: input GTiff is 3
band with nodata=0 and no mask)
2. gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90
-co PHOTOMETRIC=YCBCR -co COPY_SRC_OVERVIEWS=YES s70rgb321.tif test1.tif

The result: http://tinypic.com/r/110gig4/7

The top (~)quarter of the original image is replicated downwards up to
the original extent of the image. I would have expected the artifacts
but not this :). According to the http://www.gdal.org/frmt_gtiff.html
COPY_SRC_OVERVIEWS is applied as long as no general options are passed.

-marius


-- 
Sent from Ubuntu



On Sat, 2011-01-29 at 21:04 +0100, Even Rouault wrote: 
> Le samedi 29 janvier 2011 20:28:02, Marius Jigmond a écrit :
> > Thanks Even. I ran some more tests but that didn't quite work for me. I
> > still get those noisy pixels after gdal_translate (in QGIS I set value 0
> > for transparency and those pixels stand out). However, I noticed the
> > following:
> > 
> > * nearblack -setmask shrinks the significant pixels area (expected?)
> > * the near black noise pixels seem to follow a stair step pattern
> > similar to the edge of the significant area but at a different scale
> > (larger steps, if what I just said makes sense) and extend past the
> > significant data areas in both masked and unmasked datasets.
> 
> Ah yes, nearblack has some default parameters that can account for this. See 
> the -near and -nb parameters of http://gdal.org/nearblack.html
> 
> You can set them to 0 to have strict nearblack behaviour.
> 
> > > 
> > I was aware of the fact that nodata values are band specific but I had a
> > little brain glitch from working with gdaladdo (which honors nodata only
> > as a triplet nodata). That's how I actually ran into the problem. I am
> > trying to compress a RGB GeoTIFF using JPEG and then generate compressed
> > overviews. We plan to serve some imagery through Geoserver and would
> > like to stick to open-source solutions. The compressed datasets are
> > significantly smaller and with overviews they are extremely responsive,
> > rendering very fast). OpenJPEG v2 looks great but I haven't found
> > support for it in Geoserver, yet.
> 
> To limit the issues with artifacts, I would compute the overviews on the 
> uncompressed dataset and then translate the whole full resolution + overviews 
> into a JPEG compressed TIFF with the new COPY_SRC_OVERVIEWS option of the 
> GTiff 
> driver.
> 
> I'm not sure that JPEG2000 would solve the issue. This would need to be 
> checked if alpha channel is strictly preserved.
> 
> For the record, MapServer is able to use nodata mask band as transparency 
> channel.
> 
> > 
> > -marius
> > 
> > On Sat, 2011-01-29 at 16:13 +0100, Even Rouault wrote:
> > > Le samedi 29 janvier 2011 15:47:43, Marius Jigmond a écrit :
> > > > Hi Everyone,
> > > > 
> > > > I am having some trouble figuring out why adding JPEG compression to a
> > > > RGB GeoTIFF results in Nodata pixel triplets becoming data pixel
> > > > triplets. Is this expected behavior due to the noisy nature of JPEG
> > > > compression or to the fact that these are border Nodata triplets? I
> > > > know certain algorithms process the boundary between data and Nodata
> > > > differently.
> > > 
> > > Marius,
> > > 
> > > Yes you did find the cause : the pixels maching nodata values will be
> > > JPEG compressed, so you have no guarantee that the 0 value is preserved
> > > through compression/decompression. I'd also note that the nodata concept
> > > in GDAL is a per-band value (so it should not be interpreted as a nodata
> > > "triplet")
> > > 
> > > A possibility to workaround this would be to create a "nodata mask band"
> > > (see http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask), but I'm
> > > pretty sure that QGIS ignores those mask bands.
> > > 
> > > Anyway, if you want to try and create one, you can :
> > > 
> > > 1) Use nearblack to create a nodata mask band based on (0,0,0) triplet
> > > nearblack -setmask -of GTiff -o out_with_mask.tif in.tif
> > > 
> > > (the -setmask option is new in GDAL 1.8.0)
> > > 
> > > 2) Then compress the dataset with
> > > gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90 -co
> > > PHOTOMETRIC=YCBCR out_with_mask.tif out_compressed.tif
> > > 
> > > Only the RGB channels will be JPEG compressed : the mask band will use
> > > lossless compression so you won't have artifacts at the borders between
> > > significant areas and nodata areas.
> > > 
> > > (You can add --config GDAL_TIFF_INTERNAL_MASK YES to make the nodata mask
> > > internal to the GTiff file, instead of having a .tif.msk external file,
> > > which will not make any difference for software using GDAL API but can
> > > be more convenient to have a sinle file)
> > > 
> > > FYI, you can later reconvert the dataset into an uncompressed RGBA
> > > dataset :
> > > 
>

[gdal-dev] Licensing Policy for drivers and applications

[Frank Warmerdam]

Folks,

I have been thinking about how to adjust OSGeo4W in particular, and GDAL
in general to make it easier to distribute software in a way that complies
with the conflict between GPLed software and proprietary software.

In the case of OSGeo4W the main restrictions is that we should not be
distributing GRASS in such a way that proprietary drivers like the MrSID
driver can be used without the user having knowingly combined them by
themselves.

To that end, I have prepared an RFC which attempts to address this at
the GDAL driver registration level.  I'd appreciate feedback:

  http://trac.osgeo.org/gdal/wiki/rfc34_license_policy

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

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Even Rouault]

Le samedi 29 janvier 2011 20:28:02, Marius Jigmond a écrit :
> Thanks Even. I ran some more tests but that didn't quite work for me. I
> still get those noisy pixels after gdal_translate (in QGIS I set value 0
> for transparency and those pixels stand out). However, I noticed the
> following:
> 
> * nearblack -setmask shrinks the significant pixels area (expected?)
> * the near black noise pixels seem to follow a stair step pattern
> similar to the edge of the significant area but at a different scale
> (larger steps, if what I just said makes sense) and extend past the
> significant data areas in both masked and unmasked datasets.

Ah yes, nearblack has some default parameters that can account for this. See 
the -near and -nb parameters of http://gdal.org/nearblack.html

You can set them to 0 to have strict nearblack behaviour.

> > 
> I was aware of the fact that nodata values are band specific but I had a
> little brain glitch from working with gdaladdo (which honors nodata only
> as a triplet nodata). That's how I actually ran into the problem. I am
> trying to compress a RGB GeoTIFF using JPEG and then generate compressed
> overviews. We plan to serve some imagery through Geoserver and would
> like to stick to open-source solutions. The compressed datasets are
> significantly smaller and with overviews they are extremely responsive,
> rendering very fast). OpenJPEG v2 looks great but I haven't found
> support for it in Geoserver, yet.

To limit the issues with artifacts, I would compute the overviews on the 
uncompressed dataset and then translate the whole full resolution + overviews 
into a JPEG compressed TIFF with the new COPY_SRC_OVERVIEWS option of the GTiff 
driver.

I'm not sure that JPEG2000 would solve the issue. This would need to be 
checked if alpha channel is strictly preserved.

For the record, MapServer is able to use nodata mask band as transparency 
channel.

> 
> -marius
> 
> On Sat, 2011-01-29 at 16:13 +0100, Even Rouault wrote:
> > Le samedi 29 janvier 2011 15:47:43, Marius Jigmond a écrit :
> > > Hi Everyone,
> > > 
> > > I am having some trouble figuring out why adding JPEG compression to a
> > > RGB GeoTIFF results in Nodata pixel triplets becoming data pixel
> > > triplets. Is this expected behavior due to the noisy nature of JPEG
> > > compression or to the fact that these are border Nodata triplets? I
> > > know certain algorithms process the boundary between data and Nodata
> > > differently.
> > 
> > Marius,
> > 
> > Yes you did find the cause : the pixels maching nodata values will be
> > JPEG compressed, so you have no guarantee that the 0 value is preserved
> > through compression/decompression. I'd also note that the nodata concept
> > in GDAL is a per-band value (so it should not be interpreted as a nodata
> > "triplet")
> > 
> > A possibility to workaround this would be to create a "nodata mask band"
> > (see http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask), but I'm
> > pretty sure that QGIS ignores those mask bands.
> > 
> > Anyway, if you want to try and create one, you can :
> > 
> > 1) Use nearblack to create a nodata mask band based on (0,0,0) triplet
> > nearblack -setmask -of GTiff -o out_with_mask.tif in.tif
> > 
> > (the -setmask option is new in GDAL 1.8.0)
> > 
> > 2) Then compress the dataset with
> > gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90 -co
> > PHOTOMETRIC=YCBCR out_with_mask.tif out_compressed.tif
> > 
> > Only the RGB channels will be JPEG compressed : the mask band will use
> > lossless compression so you won't have artifacts at the borders between
> > significant areas and nodata areas.
> > 
> > (You can add --config GDAL_TIFF_INTERNAL_MASK YES to make the nodata mask
> > internal to the GTiff file, instead of having a .tif.msk external file,
> > which will not make any difference for software using GDAL API but can
> > be more convenient to have a sinle file)
> > 
> > FYI, you can later reconvert the dataset into an uncompressed RGBA
> > dataset :
> > 
> > gdal_translate out_compressed.tif out_rgba.tif -b 1 -b 2 -b 3 -b mask
> > 
> > Best regards,
> > 
> > Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Tamas Szekeres]

Ari,

I would be eager to know the exact use case you have. Did you have some
errors provided by the linker in this case?
It would indeed be a problem how the various compilers decorate their export
functions in a different way. It looks like the __declspec(dllexport) option
(this is what is used in GDAL) provides different names with MSVC and MinGW
by default. If we want to compile the dlls in a portable way we should
probably get back to an alternative method like .def file or "#pragma
comment( linker, "/export:FuncName" )" when exporting the functions.

The article you are referring to describes another way of providing a
portable version that is:
1. Compile the dll as it is now (the functions exported
with__declspec(dllexport))
2. Extract the export functions in a .def file by using pexports
3. Replace the function names with their undecorated names in the .def file
4. Recompile the dll with this new export definition file.

I'm keen to give it a try if I get some further info about how to test this
on the other side.


Best regards,

Tamas




2011/1/29 Ari Jolma 

> Did anybody else try to use the now standard Visual Studio built GDAL DLL
> (which was much discussed some time ago here and is now available from
> Tamas' site) in a MinGW environment?
>
> I spent some time a week or two ago on the issue, but I had a hard time,
> which AFAIK is because the DLL mixes two function export methods and thus
> using the standard tools seems difficult if not impossible (I already
> downloaded the sources for latest GNU dlltool and considered hacking it...)
>
> The best page about the issue I found so far is this:
> http://wyw.dcweb.cn/stdcall.htm
>
> Anybody have any ideas? Is my observation about the two export methods
> correct and why is that?
>
> Ari
>
>
> On 01/29/2011 04:59 AM, Frank Warmerdam wrote:
>
>> Folks,
>>
>> I have had good success with the GDAL 1.8 upgrade and I have now thrown
>> the switch migrating it into the production version of OSGeo4W.
>>
>> I have upgraded "gdal", "gdal-python", "gdal-mrsid" and "gdal-autotest".
>> I have yet to upgrade the ecw, and sde related drivers, and I have not
>> upgraded the java bindings.  I will try to work on them tomorrow.
>>
>> The gdal15dll package was created for backward compatability and should
>> be automatically pulled in.  It seems to be working fine for OpenEV.
>>
>> I would encourage folks building packages to update, and rebuild them
>> using the current GDAL.  The GDAL include files in C:\OSGeo4W\include
>> and libraries in C:\OSGeo4w\lib should now be for 1.8.
>>
>> Note that the new GDAL package is built using Visual Studio 2008
>> Express instead of 2003.  If you are using the C++ API this may cause
>> issues but if you use the C API it should be invisible.
>>
>> Let me know of problems.
>>
>> Best regards,
>>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed . . .

[Neil Best]

Thank you, Even.  I think that did it.  Instead of passing around raster()
objects I need to pass the file names and re-instantiate the objects on the
workers within the foreach closure.  Are you on Stackoverflow?  If not,
please consider signing up.  I think it's a great concept and I would like
to give you credit for this solution. 
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Error-1-TIFFFetchDirectory-Sanity-check-on-directory-count-failed-tp5972745p5973171.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to geotiff

[Joaquim Luis]

Anna,

I wonder how ENVI does the warping and if there isn't any hidden trick 
that must be applied. I did the warping in Mirone where I can choose to 
do a gdalwarp or warping using a totally independent code (from Matlab) 
and the results are equal and ... wrong.


Joaquim



hi all,
excuse me for not giving up. i undertook some additional tests, and i 
got the same problems i described below. But i can't believe that 
nobody is working with gdal and modis level 1b data. At least this 
format is listet as supported at http://www.gdal.org/frmt_hdf4.html.
So my question: does anybody in this list work with modis level 1b? If 
yes, is the georeference of the resulting image ok or does somebody 
knows an workaround?
maybe the answer is, that it is not possible to warp modis level 1b 
data with gdal because the modis geolocation (mod3xxx) file is missing?

i appreciate any help.
cheers
anna


*Von:* "Chaitanya kumar CH" 
*Gesendet:* 19.01.2011 10:13:49
*An:* "anna auge" 
*Betreff:* Re: [gdal-dev] Modis L1B SWATH: georef problem hdf to
geotiff

Anna,

Check a couple of GCPs to rule out bad data. If they are OK, file
a ticket at http://trac.osgeo.org/gdal/newticket

On Wed, Jan 19, 2011 at 1:23 PM, anna auge mailto:annaa...@web.de>> wrote:

So it is a problem with gdalwarp and the GCPs ín the GeoTiff.
Do you have any hints how to go on with this problem?
Cheers, Anna



*Von:* "Nikolaos Hatzopoulos" mailto:nhat...@gmail.com>>
*Gesendet:* 19.01.2011 01:33:43
*An:* "anna auge" mailto:annaa...@web.de>>
*Betreff:* Re: [gdal-dev] Modis L1B SWATH: georef problem
hdf to geotiff


You are right, I notice that there isn't any difference
from the
band_1.tiff and band_1_warp.tiff

--Nikos Hatzopoulos

On Mon, Jan 17, 2011 at 8:15 AM, anna auge
mailto:annaa...@web.de>> wrote:

Hi all,

I am trying to convert modis level 1B data (type
SWATH) to geotiff following these steps.

1) Examining the HDF
gdalinfo
d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf
gdalinfo

HDF4_EOS:EOS_SWATH:"d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
2) Extracting the 1. band of the subdataset
MODIS_SWATH_Type_L1B:EV_1KM_RefSB
gdal_translate -of GTiff -b 1

HDF4_EOS:EOS_SWATH:"d:\modis\1b\MOD021KM.A2011008.0850.005.2011008195744.hdf":MODIS_SWATH_Type_L1B:EV_1KM_RefSB
d:\modis\1b\band_1.tiff
4) Warping the image to WGS84
gdalwarp -t_srs EPSG:4326 d:\modis\1b\band_1.tiff
d:\modis\1b\band_1_warp.tiff

The example dataset, which i am using, can be
downloaded here

ftp://ladsftp.nascom.nasa.gov/allData/5/MOD021KM/2011/008//MOD021KM.A2011008.0850.005.2011008195744.hdf

And now to my problem: I get always an certain shift

(http://www.flickr.com/photos/54033867@N00/5363471425/in/photostream/),
which is avoided if i am using the "Georeference
MODIS" option in ENVI

(http://www.flickr.com/photos/54033867@N00/5364083966/in/photostream/).
I also tried a few workarounds, f.g.
http://thread.gmane.org/gmane.comp.gis.gdal.devel/10482,
but nothing worked properly.
As far as I understand gdal supports Modis L1B SWATH,
so what I am doing wrong? Any help is appreciated.

Regards Anna

P.S. I am using FWTools 2.4.7 on Windows


WEB.DE  DSL Doppel-Flat ab 19,99
€/mtl.! Jetzt mit
gratis Handy-Flat!
*http://produkte.web.de/go/DSL_Doppel_Flatrate/2*


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/gdal-dev



NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: *http://produkte.web.de/go/webdefreephone*


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/gdal-dev




-- 
Best regards,

Chaitanya kumar CH.
/tʃaɪθənjə/ /kʊmɑr/
+91-9494447584
17.2416N 80.1426E



Empfehlen Sie WEB.DE DSL Ihren Freunden und Bekannten 

Re: [gdal-dev] reproject

[Frank Warmerdam]

On 11-01-29 04:55 AM, Mohammed Rashad wrote:

is there any function in ogr to export the projection string to proj4.

there is a function called importFromProj4 but nothing like export from proj4.
i have the wkt of projection read from .prj file
I need to convert it to proj4 string.



Rashad,

The method is OGRSpatialReference::exportToProj4().  There are corresponding
C, C#, python, java, etc entry points.

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

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Jürgen E . Fischer]

Hi Frank,

On Fri, 28. Jan 2011 at 21:59:57 -0500, Frank Warmerdam wrote:
> I would encourage folks building packages to update, and rebuild them
> using the current GDAL.  The GDAL include files in C:\OSGeo4W\include
> and libraries in C:\OSGeo4w\lib should now be for 1.8.

Ok, the QGIS nightly build it now using GDAL 1.8.  And the automatic
"promotion" is back in place.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-20
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Frank Warmerdam]

On 11-01-29 09:52 AM, Ari Jolma wrote:

Did anybody else try to use the now standard Visual Studio built GDAL DLL
(which was much discussed some time ago here and is now available from Tamas'
site) in a MinGW environment?

I spent some time a week or two ago on the issue, but I had a hard time, which
AFAIK is because the DLL mixes two function export methods and thus using the
standard tools seems difficult if not impossible (I already downloaded the
sources for latest GNU dlltool and considered hacking it...)

The best page about the issue I found so far is this:
http://wyw.dcweb.cn/stdcall.htm

Anybody have any ideas? Is my observation about the two export methods correct
and why is that?


Ari,

It is true that some GDAL/OGR entry points are using cdecl, and some
are using stdcall.  Some were converted to stdcall several years ago
to facilitate calls into the DLL from VB6 and Delphi Pascal which
apparently could not easily call cdecl functions.

I believe these entry points can be used from gcc but you need to be sure
the stdcall decorations are properly applied when the include files are
processed.  There is some stuff about this in cpl_port.h, and I think you
can predefine CPL_STDCALL for alternate environments.

I think I did note this as one item we would likely want to discard
from the ABI in GDAL 2.0.

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

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Jürgen E . Fischer]

Hi Ari,

On Sat, 29. Jan 2011 at 16:52:46 +0200, Ari Jolma wrote:
> Did anybody else try to use the now standard Visual Studio built GDAL  
> DLL (which was much discussed some time ago here and is now available  
> from Tamas' site) in a MinGW environment?

The OSGeo4W GRASS package (and AFAIK also the standalone WinGRASS package) is
built with MinGW using the libraries for OSGeo4W (ie. with GDAL, GEOS and
PROJ.4 build with MSVC).   AFAIK that seems to work fine - although I must
admit to what extent GDAL/OGR is used in GRASS.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-20
Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden   http://www.norbit.de

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Even Rouault]

Le samedi 29 janvier 2011 15:47:43, Marius Jigmond a écrit :
> Hi Everyone,
> 
> I am having some trouble figuring out why adding JPEG compression to a
> RGB GeoTIFF results in Nodata pixel triplets becoming data pixel
> triplets. Is this expected behavior due to the noisy nature of JPEG
> compression or to the fact that these are border Nodata triplets? I know
> certain algorithms process the boundary between data and Nodata
> differently.

Marius,

Yes you did find the cause : the pixels maching nodata values will be JPEG 
compressed, so you have no guarantee that the 0 value is preserved through 
compression/decompression. I'd also note that the nodata concept in GDAL is a 
per-band value (so it should not be interpreted as a nodata "triplet")

A possibility to workaround this would be to create a "nodata mask band" (see 
http://trac.osgeo.org/gdal/wiki/rfc15_nodatabitmask), but I'm pretty sure that 
QGIS ignores those mask bands.

Anyway, if you want to try and create one, you can :

1) Use nearblack to create a nodata mask band based on (0,0,0) triplet
nearblack -setmask -of GTiff -o out_with_mask.tif in.tif

(the -setmask option is new in GDAL 1.8.0)

2) Then compress the dataset with
gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90 -co 
PHOTOMETRIC=YCBCR out_with_mask.tif out_compressed.tif

Only the RGB channels will be JPEG compressed : the mask band will use 
lossless compression so you won't have artifacts at the borders between 
significant areas and nodata areas.

(You can add --config GDAL_TIFF_INTERNAL_MASK YES to make the nodata mask 
internal to the GTiff file, instead of having a .tif.msk external file, which 
will not make any difference for software using GDAL API but can be more 
convenient to have a sinle file)

FYI, you can later reconvert the dataset into an uncompressed RGBA dataset :

gdal_translate out_compressed.tif out_rgba.tif -b 1 -b 2 -b 3 -b mask

Best regards,

Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Re: GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed . . .

[Even Rouault]

Le samedi 29 janvier 2011 15:53:30, Neil Best a écrit :
> Thanks, Even.  That makes sense.  If I understand your suggestion I can
> create a trivial VRT pointing to the input data for each worker, correct?

Yes, that's one possibility. But more simply, provided it is possible through 
rgdal framework, you could just open the same tiff file from each worker thread.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed . . .

[Neil Best]

Thanks, Even.  That makes sense.  If I understand your suggestion I can
create a trivial VRT pointing to the input data for each worker, correct?
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Error-1-TIFFFetchDirectory-Sanity-check-on-directory-count-failed-tp5972745p5972790.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Ari Jolma]

Did anybody else try to use the now standard Visual Studio built GDAL 
DLL (which was much discussed some time ago here and is now available 
from Tamas' site) in a MinGW environment?


I spent some time a week or two ago on the issue, but I had a hard time, 
which AFAIK is because the DLL mixes two function export methods and 
thus using the standard tools seems difficult if not impossible (I 
already downloaded the sources for latest GNU dlltool and considered 
hacking it...)


The best page about the issue I found so far is this: 
http://wyw.dcweb.cn/stdcall.htm


Anybody have any ideas? Is my observation about the two export methods 
correct and why is that?


Ari

On 01/29/2011 04:59 AM, Frank Warmerdam wrote:

Folks,

I have had good success with the GDAL 1.8 upgrade and I have now thrown
the switch migrating it into the production version of OSGeo4W.

I have upgraded "gdal", "gdal-python", "gdal-mrsid" and "gdal-autotest".
I have yet to upgrade the ecw, and sde related drivers, and I have not
upgraded the java bindings.  I will try to work on them tomorrow.

The gdal15dll package was created for backward compatability and should
be automatically pulled in.  It seems to be working fine for OpenEV.

I would encourage folks building packages to update, and rebuild them
using the current GDAL.  The GDAL include files in C:\OSGeo4W\include
and libraries in C:\OSGeo4w\lib should now be for 1.8.

Note that the new GDAL package is built using Visual Studio 2008
Express instead of 2003.  If you are using the C++ API this may cause
issues but if you use the C API it should be invisible.

Let me know of problems.

Best regards,


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] JPEG compressed GeoTIFF ignores Nodata

[Marius Jigmond]

Hi Everyone,

I am having some trouble figuring out why adding JPEG compression to a
RGB GeoTIFF results in Nodata pixel triplets becoming data pixel
triplets. Is this expected behavior due to the noisy nature of JPEG
compression or to the fact that these are border Nodata triplets? I know
certain algorithms process the boundary between data and Nodata
differently.

I'm running GDAL 1.8.0 with internal libtiff. The command I issued was:
gdal_translate -co COMPRESS=JPEG -co TILED=YES -co JPEG_QUALITY=90 -co
PHOTOMETRIC=YCBCR s70rgb321.tif test.tif

In QGIS using the identify feature on the same triplets results in:
s70rgb321.tif:
Band 1: null(nodata)
Band 2: null(nodata)
Band 3: null(nodata)
test.tif:
Band 1: 1
Band 2: 1
Band 3: 3


gdalinfo s70rgb321.tif yields:
Driver: GTiff/GeoTIFF
Files: s70rgb321.tif
   s70rgb321.tif.ovr
Size is 32261, 30632
Coordinate System is:
PROJCS["Pulkovo_1942_58_Stereo70",
GEOGCS["GCS_Pulkovo 1942(58)",
DATUM["Pulkovo_1942_58",
SPHEROID["Krassowsky_1940",6378245,298.3,
AUTHORITY["EPSG","7024"]],
AUTHORITY["EPSG","6179"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Oblique_Stereographic"],
PARAMETER["latitude_of_origin",46],
PARAMETER["central_meridian",25],
PARAMETER["scale_factor",0.99975],
PARAMETER["false_easting",50],
PARAMETER["false_northing",50],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (27432.591760581413837,941642.761553813470528)
Pixel Size = (28.512429802339831,-28.512429802339831)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (   27432.592,  941642.762) ( 18d26'17.19"E, 49d47'26.40"N)
Lower Left  (   27432.592,   68250.012) ( 19d18' 9.44"E, 41d58' 4.57"N)
Upper Right (  947272.090,  941642.762) ( 31d12'45.10"E, 49d48'33.95"N)
Lower Right (  947272.090,   68250.012) ( 30d23'36.76"E, 41d58'59.57"N)
Center  (  487352.341,  504946.387) ( 24d50'11.61"E, 46d 2'39.82"N)
Band 1 Block=32261x1 Type=Byte, ColorInterp=Red
  NoData Value=0
  Overviews: 16131x15316, 8066x7658, 4033x3829, 2017x1915, 1009x958,
505x479, 253x240
  Metadata:
LAYER_TYPE=athematic
Band 2 Block=32261x1 Type=Byte, ColorInterp=Green
  NoData Value=0
  Overviews: 16131x15316, 8066x7658, 4033x3829, 2017x1915, 1009x958,
505x479, 253x240
  Metadata:
LAYER_TYPE=athematic
Band 3 Block=32261x1 Type=Byte, ColorInterp=Blue
  NoData Value=0
  Overviews: 16131x15316, 8066x7658, 4033x3829, 2017x1915, 1009x958,
505x479, 253x240
  Metadata:
LAYER_TYPE=athematic

gdalinfo test.tif yields:
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 32261, 30632
Coordinate System is:
PROJCS["Pulkovo_1942_58_Stereo70",
GEOGCS["GCS_Pulkovo 1942(58)",
DATUM["Pulkovo_1942_58",
SPHEROID["Krassowsky 1940",6378245,298.29998,
AUTHORITY["EPSG","7024"]],
AUTHORITY["EPSG","6179"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Oblique_Stereographic"],
PARAMETER["latitude_of_origin",46],
PARAMETER["central_meridian",25],
PARAMETER["scale_factor",0.99975],
PARAMETER["false_easting",50],
PARAMETER["false_northing",50],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
Origin = (27432.591760581413837,941642.761553813470528)
Pixel Size = (28.512429802339831,-28.512429802339831)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  SOURCE_COLOR_SPACE=YCbCr
  COMPRESSION=YCbCr JPEG
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (   27432.592,  941642.762) ( 18d26'17.19"E, 49d47'26.40"N)
Lower Left  (   27432.592,   68250.012) ( 19d18' 9.44"E, 41d58' 4.57"N)
Upper Right (  947272.090,  941642.762) ( 31d12'45.10"E, 49d48'33.95"N)
Lower Right (  947272.090,   68250.012) ( 30d23'36.76"E, 41d58'59.57"N)
Center  (  487352.341,  504946.387) ( 24d50'11.61"E, 46d 2'39.82"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Red
  NoData Value=0
  Metadata:
LAYER_TYPE=athematic
Band 2 Block=256x256 Type=Byte, ColorInterp=Green
  NoData Value=0
  Metadata:
LAYER_TYPE=athematic
Band 3 Block=256x256 Type=Byte, ColorInterp=Blue
  NoData Value=0
  Metadata:
LAYER_TYPE=athematic

Thanks for any insights you might have.

-marius

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed . . .

[Even Rouault]

Le samedi 29 janvier 2011 15:16:01, Neil Best a écrit :
> How should I interpret this error?
> 
> GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed,
> this is probably not a valid IFD offset
> 
> I saw this in an R session.  I descibe the context on Stackoverflow:
> 
> http://stackoverflow.com/questions/4831882/mysterious-error-from-foreach
> 
> There I describe that I am wrapping a function from library(raster), which
> uses rgdal, with a foreach construct and parallelizing using
> multicore/doMC. I suspect that this and other errors have something to do
> with file I/O but I'm not sure how to interpret them or track them down. 
> Thanks for any suggestions.

Neil,

First, does the opening of the TIFF file with a utility such gdalinfo works 
without emitting this warning ? If it works, then your code is the likely 
culprit, otherwise the TIFF file is corrupted.

I don't know how you use the multi threading, but this could certainly be the 
responsible for the error : you cannot use the same GDAL dataset object from 
multiple threads, even if you just use it for reading. If you want to do 
parallelized I/O, you need to open as many dataset objects as you have threads 
(you can open several datasets pointing to the same file). See 
http://www.gdal.org/classGDALDataset.html#6764788806a1785c97036d1dba064497

Best regards,

Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed . . .

[Neil Best]

How should I interpret this error?

GDAL Error 1: TIFFFetchDirectory:Sanity check on directory count failed,
this is probably not a valid IFD offset

I saw this in an R session.  I descibe the context on Stackoverflow:

http://stackoverflow.com/questions/4831882/mysterious-error-from-foreach

There I describe that I am wrapping a function from library(raster), which
uses rgdal, with a foreach construct and parallelizing using multicore/doMC. 
I suspect that this and other errors have something to do with file I/O but
I'm not sure how to interpret them or track them down.  Thanks for any
suggestions.
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/GDAL-Error-1-TIFFFetchDirectory-Sanity-check-on-directory-count-failed-tp5972745p5972745.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 1.8 - Switch Thrown

[Tamas Szekeres]

Frank,

I would suggest to include the C# bindings too. I don't think it would be
reasonable to provide the bindings from a separate compilation and not
compiling that along with the GDAL core components.

Best regards,

Tamas



2011/1/29 Frank Warmerdam 

> Folks,
>
> I have had good success with the GDAL 1.8 upgrade and I have now thrown
> the switch migrating it into the production version of OSGeo4W.
>
> I have upgraded "gdal", "gdal-python", "gdal-mrsid" and "gdal-autotest".
> I have yet to upgrade the ecw, and sde related drivers, and I have not
> upgraded the java bindings.  I will try to work on them tomorrow.
>
> The gdal15dll package was created for backward compatability and should
> be automatically pulled in.  It seems to be working fine for OpenEV.
>
> I would encourage folks building packages to update, and rebuild them
> using the current GDAL.  The GDAL include files in C:\OSGeo4W\include
> and libraries in C:\OSGeo4w\lib should now be for 1.8.
>
> Note that the new GDAL package is built using Visual Studio 2008
> Express instead of 2003.  If you are using the C++ API this may cause
> issues but if you use the C API it should be invisible.
>
> Let me know of problems.
>
> Best regards,
> --
>
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmer...@pobox.com
> light and sound - activate the windows | 
> http://pobox.com/~warmerdam
> and watch the world go round - Rush| Geospatial Programmer for Rent
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] reproject

[Mohammed Rashad]

is there any function in ogr to export the projection string to proj4.

there is a function called importFromProj4 but nothing like export from
proj4. i have the wkt of projection read from .prj file
I need to convert it to proj4 string.

On Sat, Jan 29, 2011 at 10:58 AM, Mohammed Rashad <
mohammedrasha...@gmail.com> wrote:

> sorry
>
>
> On Sat, Jan 29, 2011 at 1:35 AM, Chaitanya kumar CH  gmail.com> wrote:
>
>> Rashad,
>>
>> Please look for solutions online before asking on the list. Read the
>> projections tutorial in the website. http://www.gdal.org/ogr/
>>
>> On Sat, Jan 29, 2011 at 12:14 AM, Mohammed Rashad <
>> mohammedrasha...@gmail.com> wrote:
>>
>>> How to reproject a shapefile to geographic coordinates by code? using OGR
>>>
>>> --
>>> Rashad
>>>
>>> ___
>>> gdal-dev mailing list
>>> gdal-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>
>>
>>
>>
>> --
>> Best regards,
>> Chaitanya kumar CH.
>> /tʃaɪθənjə/ /kʊmɑr/
>> +91-9494447584
>> 17.2416N 80.1426E
>>
>
>
>
> --
> Rashad
>



-- 
Rashad
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev