Re: [gdal-dev] Cannot compile 1.10 for iOS due to missing crt_extern
Selon Nik Sands nix...@nixanz.com: PS. I've got a work around for now... I edited the file ogr/ogrsf_frmts/vfk/vfkdatablock.cpp and commented out the lines that referenced clock(), and the debug line which appears to be all that was using it. It then built OK. :-) I'm sure you guys can come up with a proper solution, but this did the job for me for now. :-) Nick, can you open a ticket in GDAL Trac about those 2 issues ? Thanks, Even Cheers, Nik. On 13/08/2013, at 10:16 AM, Nik Sands nix...@nixanz.com wrote: Hi Even, Your suggestion has helped a little, but I still can't compile for iOS (device). I'm getting the following at the end of the build output... libtool: compile: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/gcore -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/alg -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr/ogrsf_frmts -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/frmts -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -c commonutils.cpp -o commonutils.o /bin/sh /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libtool --mode=link /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk gdalinfo.lo commonutils.lo /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libgdal.la -o gdalinfo libtool: link: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk gdalinfo.o commonutils.o -o gdalinfo /Users/nsands/Documents/Nik/Development/gdal-1.10.0/.libs/libgdal.a -lsqlite3 -lz -lpthread -ldl -liconv -lxml2 Undefined symbols for architecture armv7: _clock$UNIX2003, referenced from: IVFKDataBlock::LoadGeometry() in libgdal.a(vfkdatablock.o) ld: symbol(s) not found for architecture armv7 collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make: *** [apps-target] Error 2 How can I get this resolved? Cheers, Nik. On 12/08/2013, at 4:12 PM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 12 août 2013 02:17:33, Nik Sands a écrit : Hi list members, I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS simulator, however I cannot compile GDAL 1.10 for the actual iOS (devices). It appears that this is because crt_extern is not included in iOS. The code that trips up the build is in 'cpl_spawn.cpp' and appears to be: #ifdef __APPLE__ #include crt_externs.h The last few lines of the build output are below. Is there some way that I can get GDAL 1.10 built for iOS? I really need one of the changes that was included in this version. Thanks in advance for any advice that you may be able to provide. Nick, Maybe you can try the patch at https://github.com/joyent/libuv/pull/321#issuecomment-4155600 that has very similar code that the one in GDAL and report if it works for you so it can get integrated ? Even Cheers, Nik. libtool: compile: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o cpl_spawn.o cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or directory cpl_spawn.cpp: In function 'CPLSpawnedProcess* CPLSpawnAsync(int (*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int, char**)': cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in this scope make[1]: *** [cpl_spawn.lo] Error 1 make: *** [port-target] Error 2 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html ___ 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
[gdal-dev] problem in where clause
hello Do you have any idea why this expression is wrong ? 'PG: dbname=tr2 host=localhost user=orkun password=22 port=5432 schema=public table=slp4_geo AS r, sformasyon22 AS g where=( ST_Intersects(r.rast, ST_SetSRID(g.geom,4326) ) ) AND (g.yas LIKE \'%KUVATERNER%\') mode=2' regards -- Ahmet Temiz Jeoloji Müh. Afet ve Acil Durum Yönetimi Başkanlığı Planlama ve Zarar Azaltma Dairesi Başkanlığı Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux
Selon Jeremy Palmer jpal...@linz.govt.nz: Wow Even - just amazing as always. Have you confirmed that you can no open a FileGDB in QGIS? No, I didn't. I've tested with the OGR API that it solved the issue with the following access pattern : ds1 = ogr.Open(datasetname) ds2 = ogr.Open(datasetname) ds2 = None ds1 = None I still get the freeze when using GDAL trunk, but maybe that now a QGIS problem. Just to be sure that you are using the version with the fix, if you break with gdb when it hangs, does it display FGdbDriver::Release() in the stack trace ? -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 11:29 a.m. To: gdal-dev@lists.osgeo.org Cc: Jeremy Palmer; 'qgis-develo...@lists.osgeo.org' Subject: Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Le lundi 12 août 2013 22:12:11, Jeremy Palmer a écrit : Further to this I see that when you open a FIleGDB in QGIS 3 OGROpen calls made to the same database before any OGR_DS_Destroy calls are made. These open calls occur during the layer selection dialog, the OGR provider construction, and the initialisation of the QgsOgrFeatureIterator. I'm guessing the fix for this should really be done at the Esri library level, but because we have no control over this maybe something can be done in the OGR library to reuse FileGDBAPI Geodatabase handles? Jeremy, I do think this is exactly the issue of http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit-Lin ux- when-same-File-Geodatabase-opened-twice At least I reproduced it on my own PC. I've implemented a workaround in GDAL trunk for that issue that implements ref-counting of the FileGDBAPI Geodabase handle at OGR side : http://trac.osgeo.org/gdal/changeset/26307. Even Cheers, Jeremy -Original Message- From: Jeremy Palmer Sent: Sunday, 11 August 2013 9:08 a.m. To: qgis-develo...@lists.osgeo.org Subject: QGIS hanging when opening a FileGDB on 64 bit Linux Hi QGIS devs! Since the latest round of code changes (maybe over the last 2 months) I can no longer open Esri FileGDB in QGIS. I can read the database and QGIS prompts me from the FileGDB layers to add to the map, but when I select the layer from this dialog QGIS just hangs. I did some debugging and it seems to hang on the OGR_DS_Destroy call within QgsOgrFeatureIterator::close(). Does anyone else have this problem? I'm running FileGDB SDK 1.3 and Ubuntu 12.04 64bit with QGIS master. I've tested this with the OSGeo4W win32 qgis-dev package and I don't get the problem. Could this be related to this issue: http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit -Lin ux-when-same-File-Geodatabase-opened-twice ?? Cheers, Jeremy This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux
Nope I get a crash when opening now via OGRSFDriverRegistrar::Open. back trace is here: https://gist.github.com/palmerj/6219582 called from here in QGIS: https://github.com/qgis/Quantum-GIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L305 From: Even Rouault [even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 7:23 p.m. To: Jeremy Palmer Cc: 'Even Rouault'; 'gdal-dev@lists.osgeo.org'; 'qgis-develo...@lists.osgeo.org' Subject: RE: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Selon Jeremy Palmer jpal...@linz.govt.nz: Wow Even - just amazing as always. Have you confirmed that you can no open a FileGDB in QGIS? No, I didn't. I've tested with the OGR API that it solved the issue with the following access pattern : ds1 = ogr.Open(datasetname) ds2 = ogr.Open(datasetname) ds2 = None ds1 = None I still get the freeze when using GDAL trunk, but maybe that now a QGIS problem. Just to be sure that you are using the version with the fix, if you break with gdb when it hangs, does it display FGdbDriver::Release() in the stack trace ? -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 11:29 a.m. To: gdal-dev@lists.osgeo.org Cc: Jeremy Palmer; 'qgis-develo...@lists.osgeo.org' Subject: Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Le lundi 12 août 2013 22:12:11, Jeremy Palmer a écrit : Further to this I see that when you open a FIleGDB in QGIS 3 OGROpen calls made to the same database before any OGR_DS_Destroy calls are made. These open calls occur during the layer selection dialog, the OGR provider construction, and the initialisation of the QgsOgrFeatureIterator. I'm guessing the fix for this should really be done at the Esri library level, but because we have no control over this maybe something can be done in the OGR library to reuse FileGDBAPI Geodatabase handles? Jeremy, I do think this is exactly the issue of http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit-Lin ux- when-same-File-Geodatabase-opened-twice At least I reproduced it on my own PC. I've implemented a workaround in GDAL trunk for that issue that implements ref-counting of the FileGDBAPI Geodabase handle at OGR side : http://trac.osgeo.org/gdal/changeset/26307. Even Cheers, Jeremy -Original Message- From: Jeremy Palmer Sent: Sunday, 11 August 2013 9:08 a.m. To: qgis-develo...@lists.osgeo.org Subject: QGIS hanging when opening a FileGDB on 64 bit Linux Hi QGIS devs! Since the latest round of code changes (maybe over the last 2 months) I can no longer open Esri FileGDB in QGIS. I can read the database and QGIS prompts me from the FileGDB layers to add to the map, but when I select the layer from this dialog QGIS just hangs. I did some debugging and it seems to hang on the OGR_DS_Destroy call within QgsOgrFeatureIterator::close(). Does anyone else have this problem? I'm running FileGDB SDK 1.3 and Ubuntu 12.04 64bit with QGIS master. I've tested this with the OSGeo4W win32 qgis-dev package and I don't get the problem. Could this be related to this issue: http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit -Lin ux-when-same-File-Geodatabase-opened-twice ?? Cheers, Jeremy This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no
[gdal-dev] OGRStyleLabel/OGRStyleTool units
I am trying to interpret font sizes coming from OGR feature style strings. I would expect a font size in ground units to be scale-dependent inasmuch as a label would get smaller when you zoom out and bigger when you zoom in. I would expect a font size in pts, mm, inches, pixels, etc. to be scale-independent and to be drawn with that size at the current display scale. The problem I have encountered is that the style tools do not seem to offer a way to get at the input units (OGRStyleValue::eUnit) of a given parameter. The classes only seem to offer a way to convert the values from their unexposed input units to some given output units. Is there a way to get at that information? If not, would it make sense to add a GetInputUnit(Param) method on the OGRStyleTool classes? OGRSTUnitId GetInputUnit(OGRSTLabelParam eParam, GBool bValueIsNull); I have also considered trying to use SetInternalInputUnitFromParam to work around the problem at my level, but I cannot seem to get at the original parameter string as GetParmStr gives back a unit-converted string. Thanks, Andre Any views or opinions expressed in this email are solely those of the author and do not necessarily represent those of the company. No binding contract will result from this email until such time as a written document is signed on behalf of the company. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] create mask file only
Is there any way to create a mask file from an rgba without creating anything else, just the .msk file? Thanks, Duarte Duarte Carreira Diretor | Dep. Informa??o Geogr?fica e Cartografia www.edia.pthttp://www.edia.pt www.alqueva.com.pthttp://www.alqueva.com.pt Tel. +351 284315100 [http://www.edia.pt/edia/images/edia_logo2.gif]http://www.edia.pt ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux
Hi Even. I found the problem. I needed to do a make clean before rebuilding gdal. Now everything is working and QGIS can load FIleGDBs! Any chance to get this change back-ported to 1.10 so QGIS 2.0 will work with FIleGDBs? Thanks again for your help. Cheers Jeremy From: Jeremy Palmer Sent: Tuesday, 13 August 2013 9:50 p.m. To: Even Rouault Cc: 'gdal-dev@lists.osgeo.org'; 'qgis-develo...@lists.osgeo.org' Subject: RE: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Nope I get a crash when opening now via OGRSFDriverRegistrar::Open. back trace is here: https://gist.github.com/palmerj/6219582 called from here in QGIS: https://github.com/qgis/Quantum-GIS/blob/master/src/providers/ogr/qgsogrprovider.cpp#L305 From: Even Rouault [even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 7:23 p.m. To: Jeremy Palmer Cc: 'Even Rouault'; 'gdal-dev@lists.osgeo.org'; 'qgis-develo...@lists.osgeo.org' Subject: RE: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Selon Jeremy Palmer jpal...@linz.govt.nz: Wow Even - just amazing as always. Have you confirmed that you can no open a FileGDB in QGIS? No, I didn't. I've tested with the OGR API that it solved the issue with the following access pattern : ds1 = ogr.Open(datasetname) ds2 = ogr.Open(datasetname) ds2 = None ds1 = None I still get the freeze when using GDAL trunk, but maybe that now a QGIS problem. Just to be sure that you are using the version with the fix, if you break with gdb when it hangs, does it display FGdbDriver::Release() in the stack trace ? -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 11:29 a.m. To: gdal-dev@lists.osgeo.org Cc: Jeremy Palmer; 'qgis-develo...@lists.osgeo.org' Subject: Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Le lundi 12 août 2013 22:12:11, Jeremy Palmer a écrit : Further to this I see that when you open a FIleGDB in QGIS 3 OGROpen calls made to the same database before any OGR_DS_Destroy calls are made. These open calls occur during the layer selection dialog, the OGR provider construction, and the initialisation of the QgsOgrFeatureIterator. I'm guessing the fix for this should really be done at the Esri library level, but because we have no control over this maybe something can be done in the OGR library to reuse FileGDBAPI Geodatabase handles? Jeremy, I do think this is exactly the issue of http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit-Lin ux- when-same-File-Geodatabase-opened-twice At least I reproduced it on my own PC. I've implemented a workaround in GDAL trunk for that issue that implements ref-counting of the FileGDBAPI Geodabase handle at OGR side : http://trac.osgeo.org/gdal/changeset/26307. Even Cheers, Jeremy -Original Message- From: Jeremy Palmer Sent: Sunday, 11 August 2013 9:08 a.m. To: qgis-develo...@lists.osgeo.org Subject: QGIS hanging when opening a FileGDB on 64 bit Linux Hi QGIS devs! Since the latest round of code changes (maybe over the last 2 months) I can no longer open Esri FileGDB in QGIS. I can read the database and QGIS prompts me from the FileGDB layers to add to the map, but when I select the layer from this dialog QGIS just hangs. I did some debugging and it seems to hang on the OGR_DS_Destroy call within QgsOgrFeatureIterator::close(). Does anyone else have this problem? I'm running FileGDB SDK 1.3 and Ubuntu 12.04 64bit with QGIS master. I've tested this with the OSGeo4W win32 qgis-dev package and I don't get the problem. Could this be related to this issue: http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit -Lin ux-when-same-File-Geodatabase-opened-twice ?? Cheers, Jeremy This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy
Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux
Le mardi 13 août 2013 21:10:40, Jeremy Palmer a écrit : Hi Even. I found the problem. I needed to do a make clean before rebuilding gdal. Now everything is working and QGIS can load FIleGDBs! Any chance to get this change back-ported to 1.10 so QGIS 2.0 will work with FIleGDBs? I've just done that (although the changeset is a bit more substantial/risky than the usual fixes done in stable branch). Thanks again for your help. Cheers Jeremy From: Jeremy Palmer Sent: Tuesday, 13 August 2013 9:50 p.m. To: Even Rouault Cc: 'gdal-dev@lists.osgeo.org'; 'qgis-develo...@lists.osgeo.org' Subject: RE: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Nope I get a crash when opening now via OGRSFDriverRegistrar::Open. back trace is here: https://gist.github.com/palmerj/6219582 called from here in QGIS: https://github.com/qgis/Quantum-GIS/blob/master/src/providers/ogr/qgsogrpr ovider.cpp#L305 From: Even Rouault [even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 7:23 p.m. To: Jeremy Palmer Cc: 'Even Rouault'; 'gdal-dev@lists.osgeo.org'; 'qgis-develo...@lists.osgeo.org' Subject: RE: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Selon Jeremy Palmer jpal...@linz.govt.nz: Wow Even - just amazing as always. Have you confirmed that you can no open a FileGDB in QGIS? No, I didn't. I've tested with the OGR API that it solved the issue with the following access pattern : ds1 = ogr.Open(datasetname) ds2 = ogr.Open(datasetname) ds2 = None ds1 = None I still get the freeze when using GDAL trunk, but maybe that now a QGIS problem. Just to be sure that you are using the version with the fix, if you break with gdb when it hangs, does it display FGdbDriver::Release() in the stack trace ? -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Tuesday, 13 August 2013 11:29 a.m. To: gdal-dev@lists.osgeo.org Cc: Jeremy Palmer; 'qgis-develo...@lists.osgeo.org' Subject: Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux Le lundi 12 août 2013 22:12:11, Jeremy Palmer a écrit : Further to this I see that when you open a FIleGDB in QGIS 3 OGROpen calls made to the same database before any OGR_DS_Destroy calls are made. These open calls occur during the layer selection dialog, the OGR provider construction, and the initialisation of the QgsOgrFeatureIterator. I'm guessing the fix for this should really be done at the Esri library level, but because we have no control over this maybe something can be done in the OGR library to reuse FileGDBAPI Geodatabase handles? Jeremy, I do think this is exactly the issue of http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit-Li n ux- when-same-File-Geodatabase-opened-twice At least I reproduced it on my own PC. I've implemented a workaround in GDAL trunk for that issue that implements ref-counting of the FileGDBAPI Geodabase handle at OGR side : http://trac.osgeo.org/gdal/changeset/26307. Even Cheers, Jeremy -Original Message- From: Jeremy Palmer Sent: Sunday, 11 August 2013 9:08 a.m. To: qgis-develo...@lists.osgeo.org Subject: QGIS hanging when opening a FileGDB on 64 bit Linux Hi QGIS devs! Since the latest round of code changes (maybe over the last 2 months) I can no longer open Esri FileGDB in QGIS. I can read the database and QGIS prompts me from the FileGDB layers to add to the map, but when I select the layer from this dialog QGIS just hangs. I did some debugging and it seems to hang on the OGR_DS_Destroy call within QgsOgrFeatureIterator::close(). Does anyone else have this problem? I'm running FileGDB SDK 1.3 and Ubuntu 12.04 64bit with QGIS master. I've tested this with the OSGeo4W win32 qgis-dev package and I don't get the problem. Could this be related to this issue: http://forums.arcgis.com/threads/76527-CloseDatabase-hanging-on-64-bit -Lin ux-when-same-File-Geodatabase-opened-twice ?? Cheers, Jeremy This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html
Re: [gdal-dev] QGIS hanging when opening a FileGDB on 64 bit Linux
Any chance to get this change back-ported to 1.10 so QGIS 2.0 will work with FIleGDBs? I've just done that (although the changeset is a bit more substantial/risky than the usual fixes done in stable branch). Thanks! I see the QGIS dev team is looking to release 2.0 about the 7th of Sept. Is there a chance to release a GDAL/OGR 1.10 point release to coincide with this? I'm particularly interested in the OSGeo4W QGIS 2.0 package then being linked against the newer 1.10.X binary release. This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or i...@linz.govt.nz) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL 1.10.1 release schedule ? [Was Re: QGIS hanging when opening a FileGDB on 64 bit Linux]
Le mardi 13 août 2013 22:04:38, Jeremy Palmer a écrit : I see the QGIS dev team is looking to release 2.0 about the 7th of Sept. Is there a chance to release a GDAL/OGR 1.10 point release to coincide with this? I'm particularly interested in the OSGeo4W QGIS 2.0 package then being linked against the newer 1.10.X binary release. I believe that the gdal dll name does not change in point releases, so I don't think there's a strong technical reason to sync' the releases for the QGIS 2.0 binary to benefit from a GDAL 1.10.1 binary when if it is available, if QGIS is built against GDAL 1.10.0. That said, we could/should do a GDAL 1.10.X point release at some time, so that could be a teaser. Personnaly, I'm off the first week of september, so the release process should start soon... GDAL devs, We have already 45 tickets fixed in 1.10 branch : http://trac.osgeo.org/gdal/query?status=closedgroup=resolutionmilestone=1.10.1 Do you have some other things you'd like to push in the 1.10 branch for 1.10.1 ? Perhaps we could cut a 1.10.1beta1 next week ? GDAL users, if you have fixes they'd like to see in 1.10.1, then it would be time to speak up, but preferably with a ticket with an attached patch ;-) Even -- Geospatial professional services http://even.rouault.free.fr/services.html ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Accessing OnEarth TiledWMS fails with This server no longer provides full WMS services!
Until a few days ago I used the GDAL WMS driver described in http://www.gdal.org/frmt_wms.html to access the Global SRTM Elevation data (actual elevation in meters) distributed by the JPL OnEarth server. I used the stock XML configuration file http://www.gdal.org/frmt_twms_srtm.xml but currently some of the services of OnEarth are being phased out and I started getting the following error: ERROR 1: GDALWMS: The server returned exception: This server no longer provides full WMS services! OnEarth should still be serving TiledWMS data according to: http://onearth.jpl.nasa.gov/tiled.html and http://onearth.jpl.nasa.gov/wms.cgi?request=GetCapabilities but the old configuration file doesn't work anymore. It would be nice if anybody familiar with the driver could have a look at the problem and update the published configuration file, otherwise it needs to be removed from the GDAL website as it is not usable at the moment. Thanks, Alessandro -- CTO at B-Open Solutions - http://www.bopen.eu/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Cannot compile 1.10 for iOS due to missing crt_extern
No problem. I've now logged these issues in GDAL Trac as two separate tickets (not sure if they should be in one ticket or two?): Ticket #5197 Ticket #5198 On 13/08/2013, at 4:06 PM, Even Rouault even.roua...@mines-paris.org wrote: Selon Nik Sands nix...@nixanz.com: PS. I've got a work around for now... I edited the file ogr/ogrsf_frmts/vfk/vfkdatablock.cpp and commented out the lines that referenced clock(), and the debug line which appears to be all that was using it. It then built OK. :-) I'm sure you guys can come up with a proper solution, but this did the job for me for now. :-) Nick, can you open a ticket in GDAL Trac about those 2 issues ? Thanks, Even Cheers, Nik. On 13/08/2013, at 10:16 AM, Nik Sands nix...@nixanz.com wrote: Hi Even, Your suggestion has helped a little, but I still can't compile for iOS (device). I'm getting the following at the end of the build output... libtool: compile: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/gcore -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/alg -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/ogr/ogrsf_frmts -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/frmts -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -c commonutils.cpp -o commonutils.o /bin/sh /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libtool --mode=link /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk gdalinfo.lo commonutils.lo /Users/nsands/Documents/Nik/Development/gdal-1.10.0/libgdal.la -o gdalinfo libtool: link: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/g++ -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk gdalinfo.o commonutils.o -o gdalinfo /Users/nsands/Documents/Nik/Development/gdal-1.10.0/.libs/libgdal.a -lsqlite3 -lz -lpthread -ldl -liconv -lxml2 Undefined symbols for architecture armv7: _clock$UNIX2003, referenced from: IVFKDataBlock::LoadGeometry() in libgdal.a(vfkdatablock.o) ld: symbol(s) not found for architecture armv7 collect2: ld returned 1 exit status make[1]: *** [gdalinfo] Error 1 make: *** [apps-target] Error 2 How can I get this resolved? Cheers, Nik. On 12/08/2013, at 4:12 PM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 12 août 2013 02:17:33, Nik Sands a écrit : Hi list members, I was able to build GDAL 1.9 for iOS, and I can build 1.10 for the iOS simulator, however I cannot compile GDAL 1.10 for the actual iOS (devices). It appears that this is because crt_extern is not included in iOS. The code that trips up the build is in 'cpl_spawn.cpp' and appears to be: #ifdef __APPLE__ #include crt_externs.h The last few lines of the build output are below. Is there some way that I can get GDAL 1.10 built for iOS? I really need one of the changes that was included in this version. Thanks in advance for any advice that you may be able to provide. Nick, Maybe you can try the patch at https://github.com/joyent/libuv/pull/321#issuecomment-4155600 that has very similar code that the one in GDAL and report if it works for you so it can get integrated ? Even Cheers, Nik. libtool: compile: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/usr/bin/g++ -arch armv7 -pipe -Os -gdwarf-2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Dev eloper/SDKs/iPhoneOS6.1.sdk -mno-thumb -mthumb-interwork -Wall -DOGR_ENABLED -I/Users/nsands/Documents/Nik/Development/gdal-1.10.0/port -DHAVE_LIBZ -I/usr/include/libxml2 -DHAVE_LIBXML2 -c cpl_spawn.cpp -o cpl_spawn.o cpl_spawn.cpp:465:25: error: crt_externs.h: No such file or directory cpl_spawn.cpp: In function 'CPLSpawnedProcess* CPLSpawnAsync(int (*)(CPL_FILE_HANDLE, CPL_FILE_HANDLE), const char* const*, int, int, int, char**)': cpl_spawn.cpp:727: error: '_NSGetEnviron' was not declared in this scope make[1]: *** [cpl_spawn.lo] Error 1 make: *** [port-target] Error 2 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Geospatial professional services http://even.rouault.free.fr/services.html
Re: [gdal-dev] Motion: Commit Access for Kurt Schwehr
On Fri, Aug 9, 2013 at 2:41 PM, Frank Warmerdam warmer...@pobox.com wrote: Motion: Commit Access to GDAL for Kurt Schwehr I declare this motion passed with support from Daniel, Tamas, Even, Howard and I. Welcome abort Kurt! I have svn enabled userid goatbar for the GDAL svn group. Please add yourself to the gdal/COMMITERS file. Kurt has been contributing some patches around maritime formats, and other aspects of GDAL. He is also taking over my GDAL related responsibilities at Google, and I feel it would be helpful for him to have commit access to upstream various kinds of fixes smoothly. I've personally worked with him on GDAL issues for several months now. Kurt, could you confirm to the list that you have read and will try to comply with: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with: +1 Frank 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 Software Developer -- ---+-- 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: Commit Access for Kurt Schwehr
Thanks! -kurt On Aug 13, 2013, at 6:59 PM, Frank Warmerdam warmer...@pobox.com wrote: On Fri, Aug 9, 2013 at 2:41 PM, Frank Warmerdam warmer...@pobox.com wrote: Motion: Commit Access to GDAL for Kurt Schwehr I declare this motion passed with support from Daniel, Tamas, Even, Howard and I. Welcome abort Kurt! I have svn enabled userid goatbar for the GDAL svn group. Please add yourself to the gdal/COMMITERS file. Kurt has been contributing some patches around maritime formats, and other aspects of GDAL. He is also taking over my GDAL related responsibilities at Google, and I feel it would be helpful for him to have commit access to upstream various kinds of fixes smoothly. I've personally worked with him on GDAL issues for several months now. Kurt, could you confirm to the list that you have read and will try to comply with: http://trac.osgeo.org/gdal/wiki/rfc3_commiters I'll start voting with: +1 Frank 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 Software Developer -- ---+-- 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 Software Developer ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
