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 "PR
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
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 a
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_
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
dist
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:
>
>
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 i
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
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 f
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,
Th
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 bu
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, wh
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 als
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
> compress
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 framewo
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-tp59727
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 tw
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
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://
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
Ther
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
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 <
mohammed
22 matches
Mail list logo
