[gdal-dev] gdal android
I am using android-ndk-r4-crystax. gdal is building proprerly but I am getting error when linking gdal with my application here is my error log /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/gdal/lib/libgdal.a: could not read symbols: File in wrong format collect2: ld returned 1 exit status -- Thanks Regards Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: gdal android
here is my new error log cpl_strtod.cpp: In function 'void CPLReplacePointByLocalePoint(char*, char)': cpl_strtod.cpp:200: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:201: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:204: error: 'struct lconv' has no member named 'decimal_point' make[1]: *** [cpl_strtod.lo] Error 1 make[1]: Leaving directory `/home/rashadkm/gdal-1.8.0/port' make: *** [port-target] Error 2 Which gdal version to use for Android On Thu, Feb 17, 2011 at 4:10 PM, Mohammed Rashad mohammedrasha...@gmail.com wrote: I am using android-ndk-r4-crystax. gdal is building proprerly but I am getting error when linking gdal with my application here is my error log /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/android-ndk-r4-crystax/build/prebuilt/linux-x86/arm-eabi-4.4.0/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/bin/ld: /home/rashadkm/android/gdal/lib/libgdal.a(ogrregisterall.o): Relocations in generic ELF (EM: 3) /home/rashadkm/android/gdal/lib/libgdal.a: could not read symbols: File in wrong format collect2: ld returned 1 exit status -- Thanks Regards Rashad -- Thanks Regards Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal install error version 1.5.0
Install error; console log bin/sh /home/rashadkm/gdal-1.5.0/libtool --mode=compile --tag=CXX arm-linux-androideabi-g++ -g -O2 -Wall -I/home/rashadkm/gdal-1.5.0/port -I/home/rashadkm/gdal-1.5.0/gcore -I/home/rashadkm/gdal-1.5.0/alg -I/home/rashadkm/gdal-1.5.0/ogr -I/home/rashadkm/gdal-1.5.0/ogr/ogrsf_frmts -c -o ../o/ilwisdataset.o ilwisdataset.cpp libtool: compile: arm-linux-androideabi-g++ -g -O2 -Wall -I/home/rashadkm/gdal-1.5.0/port -I/home/rashadkm/gdal-1.5.0/gcore -I/home/rashadkm/gdal-1.5.0/alg -I/home/rashadkm/gdal-1.5.0/ogr -I/home/rashadkm/gdal-1.5.0/ogr/ogrsf_frmts -c ilwisdataset.cpp -fPIC -DPIC -o ../o/.libs/ilwisdataset.o In file included from /home/rashadkm/gdal-1.5.0/gcore/gdal_priv.h:54, from /home/rashadkm/gdal-1.5.0/gcore/gdal_pam.h:33, from ilwisdataset.h:34, from ilwisdataset.cpp:30: /home/rashadkm/gdal-1.5.0/port/cpl_string.h:173: note: the mangling of 'va_list' has changed in GCC 4.4 ilwisdataset.cpp: In function 'CPLErr GetStoreType(std::string, ilwisStoreType)': ilwisdataset.cpp:409: error: no matching function for call to 'transform(__gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , unresolved overloaded function type)' ilwisdataset.cpp: In member function 'void ILWISDataset::CollectTransformCoef(std::string)': ilwisdataset.cpp:485: error: no matching function for call to 'transform(__gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , unresolved overloaded function type)' ilwisdataset.cpp: In static member function 'static GDALDataset* ILWISDataset::Open(GDALOpenInfo*)': ilwisdataset.cpp:791: error: no matching function for call to 'transform(__gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , unresolved overloaded function type)' ilwisdataset.cpp: In member function 'CPLErr ILWISRasterBand::GetILWISInfo(std::string)': ilwisdataset.cpp:1321: error: no matching function for call to 'transform(__gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , unresolved overloaded function type)' ilwisdataset.cpp:1373: error: no matching function for call to 'transform(__gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , __gnu_cxx::__normal_iteratorchar*, std::basic_stringchar, std::char_traitschar, std::allocatorchar , unresolved overloaded function type)' make[2]: *** [../o/ilwisdataset.o] Error 1 make[2]: Leaving directory `/home/rashadkm/gdal-1.5.0/frmts/ilwis' make[1]: *** [ilwis-install-obj] Error 2 make[1]: Leaving directory `/home/rashadkm/gdal-1.5.0/frmts' make: *** [frmts-target] Error 2 -- Thanks Regards Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal install error version 1.5.0
On 11-02-17 08:41 AM, Mohammed Rashad wrote: Install error; console log bin/sh /home/rashadkm/gdal-1.5.0/libtool ... -- Thanks Regards Rashad Rashad, GDAL 1.5.0 is quite old, and not even the newest of that stable branch. Try GDAL 1.8.0. If the problem persists I'm sure we would be glad to look into it. If you really need a GDAL 1.5.x version then at least use the newest 1.5.x release (1.5.4?). 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] Re: gdal android
On 11-02-17 06:00 AM, Mohammed Rashad wrote: here is my new error log cpl_strtod.cpp: In function 'void CPLReplacePointByLocalePoint(char*, char)': cpl_strtod.cpp:200: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:201: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:204: error: 'struct lconv' has no member named 'decimal_point' make[1]: *** [cpl_strtod.lo] Error 1 make[1]: Leaving directory `/home/rashadkm/gdal-1.8.0/port' make: *** [port-target] Error 2 Which gdal version to use for Android Rashad, My copy of cpl_strtod.cpp (trunk) has an ifdef in that function for the __ANDROID__ case. Do you? If yes, I wonder why it isn't getting activated. Perhaps you should review the fairly new android notes at: http://trac.osgeo.org/gdal/wiki/BuildingForAndroid 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] GCP list projection
Hello, I wonder if it makes any sense if GCP list at a dataset is different from the dataset's SRS. I've played a little with these in Python, but neither gdal.Transformer, nor warping via VRT doesn't produce the results expected. I mean, presumably if GCP's SRS is different from the dataset's SRS, then they are to be transformed internally into the dataset SRS, but this doesn't seem to happen Regards V ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Gdal2tiles in Gdal18 and creating KMZ files
Thanks Brian, I have reviewed OSGeo4W\bin\gdal2tiles.py and specifically line 1597 containing the href tag to the png file: Icon href%(ty)d.%(tileformat)s/href /Icon I was curious if someone had any idea on how to modify this href tag to include the relative path as Brian suggests below. I see that the appropriate path is already included in the name tag if the .kml is changed to .png. Any ideas on the best approach would be appreciated. Also, is this relative path something that should be added to the general release to support kmz compression? Thanks, Roland On Wed, Feb 16, 2011 at 5:35 PM, brian r...@winkey.org wrote: Roland the problem is in /12/1211/2558.kml line 26 href2558.png/href this should be a relative path from the root of the zipfile not from 2558.kml Brian On Wed, 2011-02-16 at 15:14 -0500, Roland Duhaime wrote: I am following the instructions for creating one KMZ file that are posted here: http://trac.osgeo.org/gdal/wiki/UserDocs/Gdal2Tiles I am using gdal2tiles under the gdal package 1.8. I have having success creating superoverlays and the related folder structure. I am able to read the created doc.kml in Google Earth. However, when I attempt to zip up the folder structure using 7zip and rename the file to test.kmz, the file doesn't read properly in Google Earth (GE). GE zooms into the correct location but all I see is a red x. Compressing the superoverlay structure seems to break the link between the doc.kml file and the png files. As an example, I have created a tiny (21 KB) example and placed it here: http://www.edc.uri.edu/Personal/roland/test.kmz I am curious if someone had some insight. All the Best, Roland ___ 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] GCP list projection
On 11-02-17 10:08 AM, Vadim Shlyakhov wrote: Hello, I wonder if it makes any sense if GCP list at a dataset is different from the dataset's SRS. I've played a little with these in Python, but neither gdal.Transformer, nor warping via VRT doesn't produce the results expected. I mean, presumably if GCP's SRS is different from the dataset's SRS, then they are to be transformed internally into the dataset SRS, but this doesn't seem to happen Vadim, Normally I would expected a dataset with GCPs to have a GCP SRS, and no dataset level projection or geotransform. When given such a datsaet, gdalwarp will attempt to produce an output dataset in the *GCP SRS*. If the source dataset has both a GCP SRS and a dataset level SRS I am not absolutely positive what gdalwarp does, but I feel it *ought* to be producing an output file in the GCP SRS if it is using the GCPs. I am not sure why you expect the GCPs to be reprojected. Note, if the output file is in a different SRS than the GCPs, I think the GCPs would still be used to compute a polynomial in the SRS of the GCPs for getting from source file pixel/line to source georeferenced coordinates. Then reprojection would be applied as an extra step. In theory it could make sense to have a dataset with a dataset level SRS and geotransform, and also GCPs with a different SRS. In some cases the GCPs are in a particular SRS (say lat/long) just because it is a convenient coordinate system to collect the GCPs, not because it is representative of the geometry of the image. 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] Re: gdal android
Le jeudi 17 février 2011 15:58:17, Frank Warmerdam a écrit : On 11-02-17 06:00 AM, Mohammed Rashad wrote: here is my new error log cpl_strtod.cpp: In function 'void CPLReplacePointByLocalePoint(char*, char)': cpl_strtod.cpp:200: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:201: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:204: error: 'struct lconv' has no member named 'decimal_point' make[1]: *** [cpl_strtod.lo] Error 1 make[1]: Leaving directory `/home/rashadkm/gdal-1.8.0/port' make: *** [port-target] Error 2 Which gdal version to use for Android Rashad, My copy of cpl_strtod.cpp (trunk) has an ifdef in that function for the __ANDROID__ case. Do you? If yes, I wonder why it isn't getting activated. Perhaps you should review the fairly new android notes at: http://trac.osgeo.org/gdal/wiki/BuildingForAndroid Best regards, I see that the path is /home/rashadkm/gdal-1.8.0/port so I deduce this is a GDAL 1.8.0 build. But the adjustment for Android has been introduced in trunk (1.9.0dev) very recently. See http://trac.osgeo.org/gdal/ticket/3952 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal vs wgrib2 output for grb2 files
Hi Bill,
i was wondering if there had been any more progress on the issue w.r.t
to the discreptancy between wgrib2 and the gdal driver file?
I found the thread which you initiated at:
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-GDAL-Navigation-of-a-Grib2-file-td5740761.html
If you don't mind, can you tell me where that whole thing ended up or
whether it went any further than listed?
Which output did you trust?
Any advice is appreciated...
thanks
matt
On 1/20/2011 3:24 PM, Cassanova, Bill wrote:
Hi Matt,
Can you be a little more explicit about what you are asking? Generally
speaking GRIB2 files do not contain explicit lat-lon information.
GRIB2's contain a projection and within that projection the bounding box
including the number of points along each axis is contained.
As an experiment run gdalinfo on your grib2 file and you will see output
similar to the below:
gdalinfo foo.grib2
Driver: GRIB/GRIdded Binary (.grb)
Files: foo.grib2
Size is 720, 361
Coordinate System is:
GEOGCS[Coordinate System imported from GRIB file,
DATUM[unknown,
SPHEROID[Sphere,6371229,0]],
PRIMEM[Greenwich,0],
UNIT[degree,0.0174532925199433]]
Origin = (0.000,270.000)
Pixel Size = (0.500,-0.500)
Corner Coordinates:
Upper Left ( 0.000, 270.000) ( 0d 0'0.01E,270d 0'0.00N)
Lower Left ( 0.000, 89.500) ( 0d 0'0.01E, 89d30'0.00N)
Upper Right ( 360.000, 270.000) (360d 0'0.00E,270d 0'0.00N)
Lower Right ( 360.000, 89.500) (360d 0'0.00E, 89d30'0.00N)
Center ( 180.000, 179.750) (180d 0'0.00E,179d45'0.00N)
Band 1 Block=720x1 Type=Float64, ColorInterp=Undefined
Description = 0[-] SFC=Ground or water surface
Metadata:
GRIB_UNIT=[K]
GRIB_COMMENT=Temperature [K]
GRIB_ELEMENT=TMP
GRIB_SHORT_NAME=0-SFC
GRIB_REF_TIME= 1295481600 sec UTC
GRIB_VALID_TIME= 1296151200 sec UTC
GRIB_FORECAST_SECONDS=669600 sec
GRIB_PDS_PDTN=0
GRIB_PDS_TEMPLATE_NUMBERS=0 0 2 0 96 0 0 0 1 0 0 0 186 1 0 0 0 0 0 255 0
0 0 0 0
If you are trying to read the values contained in Upper Left, Lower Left, etc?
If this is the case you need to get the geo_transform using code similar to
the C-code below:
GDALAllRegister();
GDALDatasetH my_data_set;
int my_x_size, my_y_size;
int my_raster_bands;
GDALRasterBandH my_raster_band;
double my_geo_transform[6];
std::string my_projection_ref;
my_data_set = NULL;
my_raster_band = NULL;
my_x_size = my_y_size = my_raster_bands = 0;
ACE_LOG_MSG-log(LM_INFO, %D %n Opening %s \n, input_grib2_file.c_str());
my_data_set = GDALOpen(input_grib2_file.c_str(), GA_ReadOnly);
if (NULL == my_data_set)
{
ACE_LOG_MSG-log(LM_INFO, %D %n NULL GDALDatasetH pointer for file %s,
file invalid, quitting\n, input_grib2_file.c_str());
return (1);
}
GDALGetGeoTransform(my_data_set, my_geo_transform);
my_x_size = GDALGetRasterXSize(my_data_set);
my_y_size = GDALGetRasterYSize(my_data_set);
my_raster_bands = GDALGetRasterCount(my_data_set);
ACE_LOG_MSG-log(LM_INFO,
%D %n Data Set: x_size = %d y_size = %d raster_bands =
%d origin = %f, %f, pixel_size=%f, %f\n,
my_x_size, my_y_size, my_raster_bands,
my_geo_transform[0],
my_geo_transform[3], my_geo_transform[1],
my_geo_transform[5]);
From this information you can calculate the lat-lon of each point within the
file.
To answer your other question about wgrib2 -spreadwgrib2 calculates the
lat-lon coordinates on the fly and does not store these explicitly in the
file...Unless they are put there as a wgrib2 data segment which most people
don't do.
Hope this helps,
Bill
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Matt Funk
Sent: Thursday, January 20, 2011 4:38 PM
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] question about reading grib2 file
Hi,
i am somewhat new to gdal and the grib format.
I need to read in a grib2 file which contains latitude longitude and
elevation.
So i do:
ds = gdal.Open(filename)
and
print ds.GetRasterCount(): %s % ds.GetRasterCount()
gives: 1
I can proceed to read in this band, but all the data that i get is the
elevation.
Not sure if this is an incredibly stupid question, but how do i access
the latitude/longitude data?
I know that there is latitude/longitude since when outputting things to
a csv file via the wgrib2 utility i get lat/lon and elevation?
thanks for any advice
matt
___
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
Re: [gdal-dev] Re: gdal android
I installed gdal-1.5.0 on android with some patches. there is a problem in tiff format, gml,geojson,kml all other formats worked without any patch will send you those patches if needed On Fri, Feb 18, 2011 at 12:03 AM, Even Rouault even.roua...@mines-paris.org wrote: Le jeudi 17 février 2011 15:58:17, Frank Warmerdam a écrit : On 11-02-17 06:00 AM, Mohammed Rashad wrote: here is my new error log cpl_strtod.cpp: In function 'void CPLReplacePointByLocalePoint(char*, char)': cpl_strtod.cpp:200: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:201: error: 'struct lconv' has no member named 'decimal_point' cpl_strtod.cpp:204: error: 'struct lconv' has no member named 'decimal_point' make[1]: *** [cpl_strtod.lo] Error 1 make[1]: Leaving directory `/home/rashadkm/gdal-1.8.0/port' make: *** [port-target] Error 2 Which gdal version to use for Android Rashad, My copy of cpl_strtod.cpp (trunk) has an ifdef in that function for the __ANDROID__ case. Do you? If yes, I wonder why it isn't getting activated. Perhaps you should review the fairly new android notes at: http://trac.osgeo.org/gdal/wiki/BuildingForAndroid Best regards, I see that the path is /home/rashadkm/gdal-1.8.0/port so I deduce this is a GDAL 1.8.0 build. But the adjustment for Android has been introduced in trunk (1.9.0dev) very recently. See http://trac.osgeo.org/gdal/ticket/3952 -- Thanks Regards Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MrSID mask band support
On Tue, Feb 15, 2011 at 1:19 PM, Even Rouault even.roua...@mines-paris.org wrote: Barring that, since the MrSID driver reimplements the overview-related virtual functions to bypass the default overview manager, would there be any harm in initializing the overview manager when a MrSIDDataset object is created? Yes I think this should be harmless. But I'm not too sure of what will happen if you try to get the overviews of the mask, or the mask of the overviews ... The basics of the patch were easy enough (23 lines): I initialize the overview manager near the end of MrSIDDataset::Open(), and implemented MrSIDDataset::IBuildOverviews() to simply print a warning, as Frank suggested. As to your last comment about masks of the overviews and overviews of the masks, Even, the behavior as it stands after this patch is that 1) the masks of the overviews are coming back as GMF_ALL_VALID, and 2) overviews of the masks are non-existent. I believe this is consistent with the current behavior of, e.g., adding a per-dataset mask to a GeoTIFF file that already has overviews. If that's sufficient, I'll create a ticket and submit the patch as-is -- otherwise, I'm open to suggestions. -b -- Brian Claywell bcclayw...@gmail.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] MrSID mask band support
Le jeudi 17 février 2011 22:23:43, Brian Claywell a écrit : On Tue, Feb 15, 2011 at 1:19 PM, Even Rouault even.roua...@mines-paris.org wrote: Barring that, since the MrSID driver reimplements the overview-related virtual functions to bypass the default overview manager, would there be any harm in initializing the overview manager when a MrSIDDataset object is created? Yes I think this should be harmless. But I'm not too sure of what will happen if you try to get the overviews of the mask, or the mask of the overviews ... The basics of the patch were easy enough (23 lines): I initialize the overview manager near the end of MrSIDDataset::Open(), and implemented MrSIDDataset::IBuildOverviews() to simply print a warning, as Frank suggested. As to your last comment about masks of the overviews and overviews of the masks, Even, the behavior as it stands after this patch is that 1) the masks of the overviews are coming back as GMF_ALL_VALID, and 2) overviews of the masks are non-existent. I believe this is consistent with the current behavior of, e.g., adding a per-dataset mask to a GeoTIFF file that already has overviews. If that's sufficient, I'll create a ticket and submit the patch as-is -- otherwise, I'm open to suggestions. I think it must be OK as it is. Actually GDALDefaultOverviews::IBuildOverviews() will build overviews of the mask if the mask already exists, but yes, creating a mask after building the overviews will not lead to automatic building of the overviews of the mask. Those are really very specialized cases that could be improved later. Actually, you can run IBuildOverviews() on the .msk file and the overviews of the mask should be usable. -b ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] How to reproject a geotiff using osgeo gdal python bindings
Hello, I am trying to project a raster in lambert conformal conic projection to geographic dd wgs84. The cell resolution changes between the two, so I don't know what the final grid size is in the geographic raster. Does anyone have any complete examples of opening a geotiff in lambert, and writing the complete dataset out to geographic? Thanks Bill ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Potential dangerous use of CPLSetErrorHandler()
Hi Roger,
not sure if you are the appropriate recipient for this email, but as your name
appeared on http://cran.r-project.org/web/packages/rgdal/index.html I try my
chance ;-).
(CC'ing gdal-dev too since other users of GDAL might be interested by the
issue related with CPLSetErrorHandler() in other contexts)
I had a discussion with Bob on the GDAL IRC that you can follow here :
http://logs.qgis.org/gdal/%23gdal.2011-02-16.log and
http://logs.qgis.org/gdal/%23gdal.2011-02-17.log
Here's my analysis (based on https://r-forge.r-
project.org/scm/viewvc.php/trunk/src/gdal-bindings.cpp?view=markuproot=rgdal
) of what leads to the crash he noticed (of course I can be wrong since my
knowledge of R is null, so this is mostly based on guess) :
1) QGIS loads a plugin that loads RGDAL
2) When RGDAL is initialized, it installs a global error handler
__errorHandler with CPLSetErrorHandler()
3) Some functions of QGIS unrelated to RGDAL causes a CPLError() to be emitted
by GDAL/OGR
4) The global RGDAL error handler is triggered, causes the error() method to
be called which apparently causes a longjmp() to the R interpreter
5) At that point QGIS crashes as the longjmp() is inappropriate because R
isn't ready for being run at that point
So my suggestion would be not to use a global error handler set when RGDAL is
initialized, but rather for each binding of the GDAL API, install a local
error handler with CPLPushErrorHandler(__errorHandler) and uninstall it before
returning to R with CPLPopErrorHandler()
For example :
SEXP
RGDAL_GetDescription(SEXP sxpObj) {
void *pGDALObj = getGDALObjPtr(sxpObj);
CPLPushErrorHandler(__errorHandler);
const char *desc = ((GDALMajorObject *)pGDALObj)-GetDescription();
CPLPopErrorHandler();
return(mkString_safe(desc));
}
This is going to be quite painfull since you have to do this for each GDAL
method you bind, and be careful to correctly pair CPLPushErrorHandler() /
CPLPopErrorHandler() (the later being the easiest to forget in unsuual code
paths, such as error code paths).
Best regards,
Even
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Potential dangerous use of CPLSetErrorHandler()
Le vendredi 18 février 2011 01:02:30, Even Rouault a écrit :
So my suggestion would be not to use a global error handler set when RGDAL
is initialized, but rather for each binding of the GDAL API, install a
local error handler with CPLPushErrorHandler(__errorHandler) and uninstall
it before returning to R with CPLPopErrorHandler()
For example :
SEXP
RGDAL_GetDescription(SEXP sxpObj) {
void *pGDALObj = getGDALObjPtr(sxpObj);
CPLPushErrorHandler(__errorHandler);
const char *desc = ((GDALMajorObject *)pGDALObj)-GetDescription();
CPLPopErrorHandler();
return(mkString_safe(desc));
}
Actually, I'm just thinking that when an error actually triggers, the
CPLPopErrorHandler() will not be called due to the longjmp() done in the error
handler... So you probably needs to call CPLPopErrorHandler() in the error
handler before it to call error() (a quick review of port/cpl_error.cpp leads
me to think this is OK to do so, but this needs certainly some testing)
Or other possibility, it might be dangerous that the error handler interrupts
the GDAL code flow with the longjmp(). It could cause memory leaks or leaves
GDAL in an unstable state (unreleased locks, or whatever). What would be safer
would be that the error handler just stores the error code and/or message, and
just looks at it after the return from the GDAL code.
Something like this :
static CPLErr saved_eErrClass = CE_None;
static saved_err_no = 0;
static char saved_error_msg[2048];
static void
__errorHandler(CPLErr eErrClass, int err_no, const char *msg) {
saved_eErrClass = eErrClass;
saved_err_no = err_no;
/* a mutex could be usefull here to avoid a race condition if 2 threads
trigger the error handler at the same time */
strncpy(saved_error_msg, msg, sizeof(saved_error_msg));
saved_error_msg[sizeof(saved_error_msg)-1] = 0;
}
void installErrorHandler()
{
CPLPushErrorHandler(__errorHandler);
saved_err_no = 0;
}
void uninstallErrorHandlerAndTriggerRError()
{
CPLPopErrorHandler();
if (saved_err_no == CE_Warning) {
warning(\n\tNon-fatal GDAL Error %d: %s\n, saved_err_no,
saved_error_msg);
} else if (saved_err_no == CE_Failure) {
error(\n\tGDAL Error %d: %s\n, saved_err_no, saved_error_msg);
}
}
SEXP
RGDAL_GetDescription(SEXP sxpObj) {
void *pGDALObj = getGDALObjPtr(sxpObj);
installErrorHandler();
const char *desc = ((GDALMajorObject *)pGDALObj)-GetDescription();
uninstallErrorHandlerAndTriggerRError();
return(mkString_safe(desc));
}
Or you could also take the approach of
gdal/swig/include/python/python_exceptions.i where the installed error handler
just forwards CE_Fatal, CE_Warning and CE_Debug to the previous error handler
(or the default one if there's none). After the GDAL call, it just looks at
CPLGetLastErrorType() and if it is CE_Failure, it triggers a Python exception
with the error messages fetched with CPLGetLastErrorMsg().
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Segmentation fault using gdal_translate in 1.8.0
Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting Segmentation fault errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. Derrick Wong Software Engineer | Spatial Information Services Stack (SISS) Project | CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.aumailto:derrick.w...@csiro.au | www.csiro.auhttp://www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia PLEASE NOTE The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. Please consider the environment before printing this email. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
Derrick, Can you file a ticket and attach a sample data set? Do you have any other details? A gdalinfo of the netcdf file and another of one of the variables would be great. Thanks. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 19:54, derrick.w...@csiro.au wrote: Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting “Segmentation fault” errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. *Derrick Wong** * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* ___ 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] Segmentation fault using gdal_translate in 1.8.0
Hi Kyle, Thanks for the reply. Gdalinfo on 1.8.0 gives me the same Segmentation fault error. Attached is the dump using 1.7.3 I have included a sample file and you can download it here: ftp://ftp.csiro.au/DerrickWong/sample/sample.nc Derrick Wong Software Engineer | Spatial Information Services Stack (SISS) Project | CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.aumailto:derrick.w...@csiro.au | www.csiro.auhttp://www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia PLEASE NOTE The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. Please consider the environment before printing this email. From: Kyle Shannon [mailto:ksshan...@gmail.com] Sent: Friday, 18 February 2011 11:32 AM To: Wong, Derrick (CESRE, Kensington) Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0 Derrick, Can you file a ticket and attach a sample data set? Do you have any other details? A gdalinfo of the netcdf file and another of one of the variables would be great. Thanks. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.usmailto:kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 19:54, derrick.w...@csiro.au wrote: Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting Segmentation fault errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. Derrick Wong Software Engineer | Spatial Information Services Stack (SISS) Project | CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.aumailto:derrick.w...@csiro.au | www.csiro.auhttp://www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia PLEASE NOTE The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. Please consider the environment before printing this email. ___ gdal-dev mailing list gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev Driver: netCDF/Network Common Data Format Files: ga_fixed2_1e75_911d_7726.nc Size is 179, 180 Coordinate System is `' Origin = (147.124923499972280,-39.96963051372) Pixel Size = (0.0083323,-0.0083330) Metadata: NC_GLOBAL#cdm_data_type=Grid NC_GLOBAL#Conventions=CF-1.0, COARDS, Unidata Dataset Discovery v1.0 NC_GLOBAL#Easternmost_Easting=148.612 NC_GLOBAL#geospatial_lat_max=-39.9738 NC_GLOBAL#geospatial_lat_min=-41.4654 NC_GLOBAL#geospatial_lon_max=148.612 NC_GLOBAL#geospatial_lon_min=147.129 NC_GLOBAL#history=2011-02-01 http://apacsrv6/thredds/dodsC/ga/onshore_only_Bouguer_geodetic_fixed2 .nc 2011-02-01 http://apacsrv6.arrc.csiro.au/erddap/griddap/ga_fixed2.nc?onshore_only_Bouguer_geodetic[( -41.4654040144):(-39.97379701376)][(147.1290897228):(148.6123637108)].draw=surface .vars=longitude|latitude|onshore_only_Bouguer_geodetic.colorBar=|.land=under NC_GLOBAL#infoUrl=http://apacsrv6/thredds/dodsC/ga/onshore_only_Bouguer_geodetic_fixed2.nc.html NC_GLOBAL#institution=APACSRV6 NC_GLOBAL#license=The data may be used and redistributed for free but is not intended for legal use, since it may contain inaccuracies. Neither the data Contributor, ERD, NOAA, nor the United States Government, nor any of their employees or contractors, makes any warranty, express or implied, including warranties of merchantability and fitness for a particular purpose, or assumes any legal liability for the accuracy, completeness, or usefulness, of this information. NC_GLOBAL#Metadata_Conventions=CF-1.0, COARDS, Unidata Dataset Discovery v1.0 NC_GLOBAL#Northernmost_Northing=-39.9738 NC_GLOBAL#Source_Software=ESRI ArcGIS NC_GLOBAL#sourceUrl=http://apacsrv6/thredds/dodsC/ga/onshore_only_Bouguer_geodetic_fixed2.nc NC_GLOBAL#Southernmost_Northing=-41.4654
Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0
Thanks Derrick, I will look at this in the morning. I will file a ticket if need be. Thanks for the report, sorry about the inconvenience. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 21:27, derrick.w...@csiro.au wrote: Hi Kyle, Thanks for the reply. Gdalinfo on 1.8.0 gives me the same “Segmentation fault” error. Attached is the dump using 1.7.3 I have included a sample file and you can download it here: ftp://ftp.csiro.au/DerrickWong/sample/sample.nc *Derrick Wong** * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* *From:* Kyle Shannon [mailto:ksshan...@gmail.com] *Sent:* Friday, 18 February 2011 11:32 AM *To:* Wong, Derrick (CESRE, Kensington) *Cc:* gdal-dev@lists.osgeo.org *Subject:* Re: [gdal-dev] Segmentation fault using gdal_translate in 1.8.0 Derrick, Can you file a ticket and attach a sample data set? Do you have any other details? A gdalinfo of the netcdf file and another of one of the variables would be great. Thanks. kss # Kyle Shannon Physical Science Technician RMRS Fire Sciences Lab Fire, Fuels Smoke - RWU 4405 5775 Highway 10 W. Missoula, MT 59808 (406)829-6954 kshan...@fs.fed.us # On Thu, Feb 17, 2011 at 19:54, derrick.w...@csiro.au wrote: Hi all, I have updated to use GDAL 1.8 and I am having problems using gdal_translate to convert netCDF files to Geotiff or ERS. I am getting “Segmentation fault” errors only occurring in 1.8.0. I was using 1.7.3 previously. Could someone kindly advise? Thank you for your time. *Derrick Wong * Software Engineer *|* Spatial Information Services Stack (SISS) Project *| *CSIRO Phone: +61 8 6436 8945 derrick.w...@csiro.au *|* www.csiro.au Address: Spatial Information Services Stack (SISS), 26 Dick Perry Avenue, Kensington WA 6151, Australia *PLEASE NOTE** *The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. *Please consider the environment before printing this email.* ___ 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] Gdal2tiles in Gdal18 and creating KMZ files
Roland, not really an answer to your question, but note that - with a recent gdal - you can also create kmz by using the kmlsuperoverlay output format, e.g.: gdal_translate -of kmlsuperoverlay infile out.kmz your infile need be a rgb or rgba format (if you want to maintain transparency, add '-co format=png' to the gdal_translate command, otherwise jpeg's will be created for the tiles). Regards, Vincent. On 02/17/2011 06:28 PM, Roland Duhaime wrote: Thanks Brian, I have reviewed OSGeo4W\bin\gdal2tiles.py and specifically line 1597 containing the href tag to the png file: Icon href%(ty)d.%(tileformat)s/href /Icon I was curious if someone had any idea on how to modify this href tag to include the relative path as Brian suggests below. I see that the appropriate path is already included in the name tag if the .kml is changed to .png. Any ideas on the best approach would be appreciated. Also, is this relative path something that should be added to the general release to support kmz compression? Thanks, Roland On Wed, Feb 16, 2011 at 5:35 PM, brian r...@winkey.org mailto:r...@winkey.org wrote: Roland the problem is in /12/1211/2558.kml line 26 href2558.png/href this should be a relative path from the root of the zipfile not from 2558.kml Brian On Wed, 2011-02-16 at 15:14 -0500, Roland Duhaime wrote: I am following the instructions for creating one KMZ file that are posted here: http://trac.osgeo.org/gdal/wiki/UserDocs/Gdal2Tiles I am using gdal2tiles under the gdal package 1.8. I have having success creating superoverlays and the related folder structure. I am able to read the created doc.kml in Google Earth. However, when I attempt to zip up the folder structure using 7zip and rename the file to test.kmz, the file doesn't read properly in Google Earth (GE). GE zooms into the correct location but all I see is a red x. Compressing the superoverlay structure seems to break the link between the doc.kml file and the png files. As an example, I have created a tiny (21 KB) example and placed it here: http://www.edc.uri.edu/Personal/roland/test.kmz I am curious if someone had some insight. All the Best, Roland ___ gdal-dev mailing list gdal-dev@lists.osgeo.org mailto: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 mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
