Re: [gdal-dev] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.comwrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/ 3) export LD_LIBRARY_PATH=/usr/lib64/FileGDB_API/lib cd /usr/lib64/FileGDB_API/samples make cd bin ./Querying #Works, so the API is fine. 4) su - $ vi /etc/ld.so.conf.d/fgdb.conf #Added a single entry: /usr/lib64/FileGDB_API/lib $ ldconfig #A grep of this with the -v flag shows it registered fine 5) #Some openSUSE specific stuff, b/c I'm building locally via the OBS $ zypper in osc cd /home/saultdon/Development/obs osc co Application:Geo libgdal cd Application:Geo/libgdal vi libgdal.spec #added --with-fgdb=/usr/lib64/FileGDB_API in %configure section #I also did a test build without that configure param. first and it compiled fine with working RPMs osc build openSUSE_12.2 x86_64 libgdal.spec --clean Resulting Error: [ 209s] checking for libFileGDBAPI.so in in /usr/lib64/FileGDB_API/lib... configure: error: not found. [ 209s] error: Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) [ 209s] RPM build errors: [ 209s] Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) The buildroot was: /var/tmp/build-root libFileGDBAPI.so file exists, ldconfig registered it, and the API test worked fine, the env. var. LD_LIBRARY_PATH is also set, but I don't even think that's necessary. I only had to set that to get the API test to work. I'm not sure where this is going wrong. If anyone has any input or needs more information, let me know. Thanks! Donovan ___ 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] elevetions from ASTER GDEM V2
If the spatial resulution is fine for your problem, then as Tyler suggested, you can use gdallocationinfo [1] to get the pixel value at Long,Lat location. If you think you need to downscale your data to your needs, you can first built a vrt (virtual dataset) with gdal's gdalbuildvrt [2] and -tr option. What I don't know is, which method vrts are using to obtain raster values when the source rasters are in another resolution than the vrt [1] http://www.gdal.org/gdallocationinfo.html [2] http://www.gdal.org/gdalbuildvrt.html On Thu, Jan 24, 2013 at 10:15 PM, Tyler Mitchell tyler.mitch...@actian.comwrote: On 2013-01-24, at 11:43 AM, Elias Kotsifis wrote: I want to calculate the elevation of any point on earth, giving lat, Long (for example like google elevation Api, or the earth tools: http://www.earthtools.org/webservices.htm # cheigit) based the ASTER GDEM MODEL V2. I went to download data from there, and gives me geotiff files. Overall for the entire planet is 22,702 granule with 400GB size Then what should I do? Hi Elias, Have you tried the gdallocationinfo command? You can pass it a lat/lon and raster and it will report back what you're after I believe. Hope it helps, Tyler ___ 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] Warping with GCPs at high latitudes
On 24. jan. 2013 20:43, Even Rouault wrote: Did you try to do your suggestion at hand to actually check that your idea leads to the expected result ? This is basically a matter of running : 1) gdaltransform -s_srs EPSG:4326 -t_srs +proj=stere +lat_0=90 +lon_0=0 on the coordinates of the GCPs of the source image 2) gdal_translate -a_srs +proj=stere +lat_0=90 +lon_0=0 [-gcp x y X Y]* src.tif src_reprojected_gcp.tif where x y come from the source image and X Y are the reprojected coordinates 3) gdalwarp src_reprojected_gcp.tif out.tif I tried it now with Python API, and it works perfectly, all the way to the pole. Thus the conclusion should be that GCPs can have any spatial reference system, but preferably one with no singularity within or near the destination area. I used code like this: # Make tranformer from GCP SRS to destination SRS dstSRS = osr.SpatialReference() dstSRS.ImportFromProj4(srsString) srcSRS = osr.SpatialReference() srcGCPProjection = srcDataset.GetGCPProjection() srcSRS.ImportFromWkt(srcGCPProjection) transformer = osr.CoordinateTransformation(srcSRS, dstSRS) # Reproject all GCPs srcGCPs = self.vrt.dataset.GetGCPs() dstGCPs = [] for srcGCP in srcGCPs: (x, y, z) = transformer.TransformPoint(srcGCP.GCPX, srcGCP.GCPY, srcGCP.GCPZ) dstGCP = gdal.GCP(x, y, z, srcGCP.GCPPixel, srcGCP.GCPLine, srcGCP.Info, srcGCP.Id) dstGCPs.append(dstGCP) # Update dataset self.vrt.dataset.SetGCPs(dstGCPs, dstSRS.ExportToWkt()) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] ogr2ogr - ESRI Shapefile: how to set SHPT?
my idea is to convert a MULTIPOINT shapefile to a POINT shapefile, but how to set SHPT=POINT? I would have a try with ogr2ogr -explodecollections -explodecollections did the conversion from MULTIPOINT to POINT shapefile. thanks! - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/ogr2ogr-ESRI-Shapefile-how-to-set-SHPT-tp5029635p5029892.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] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
Thanks for the suggestion Jan. I tried to compile the 32-bit libgdal with the 32bit FileGDB_API but still throws the same error... Is it possible that the osc tool is looking inside it's build environment at /tmp or /usr/tmp instead of my local user files at /usr/lib64? I might take this problem to the package maintainer for libgdal on openSUSE 12.2 to see if they have attempted to compile with FileGDB support. On Fri, Jan 25, 2013 at 1:19 AM, Jan Heckman jan.heck...@gmail.com wrote: Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.com wrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/ 3) export LD_LIBRARY_PATH=/usr/lib64/FileGDB_API/lib cd /usr/lib64/FileGDB_API/samples make cd bin ./Querying #Works, so the API is fine. 4) su - $ vi /etc/ld.so.conf.d/fgdb.conf #Added a single entry: /usr/lib64/FileGDB_API/lib $ ldconfig #A grep of this with the -v flag shows it registered fine 5) #Some openSUSE specific stuff, b/c I'm building locally via the OBS $ zypper in osc cd /home/saultdon/Development/obs osc co Application:Geo libgdal cd Application:Geo/libgdal vi libgdal.spec #added --with-fgdb=/usr/lib64/FileGDB_API in %configure section #I also did a test build without that configure param. first and it compiled fine with working RPMs osc build openSUSE_12.2 x86_64 libgdal.spec --clean Resulting Error: [ 209s] checking for libFileGDBAPI.so in in /usr/lib64/FileGDB_API/lib... configure: error: not found. [ 209s] error: Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) [ 209s] RPM build errors: [ 209s] Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) The buildroot was: /var/tmp/build-root libFileGDBAPI.so file exists, ldconfig registered it, and the API test worked fine, the env. var. LD_LIBRARY_PATH is also set, but I don't even think that's necessary. I only had to set that to get the API test to work. I'm not sure where this is going wrong. If anyone has any input or needs more information, let me know. Thanks! Donovan ___ 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] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
I've tested compiling the 64bit gdal-1.9.2 from the tar.gz source file: ./configure --with-fgdb=/usr/lib64/FileGDB_API And it completes successfully where I can see the FileGDB driver read/write format in the output of ogrinfo --formats. There must be something in this SPEC file that is causing a conflict so that that the .so for the FileGDB driver can't be found, even after it's registered with ldconfig. On Fri, Jan 25, 2013 at 11:05 AM, Donovan Cameron sault@gmail.com wrote: Thanks for the suggestion Jan. I tried to compile the 32-bit libgdal with the 32bit FileGDB_API but still throws the same error... Is it possible that the osc tool is looking inside it's build environment at /tmp or /usr/tmp instead of my local user files at /usr/lib64? I might take this problem to the package maintainer for libgdal on openSUSE 12.2 to see if they have attempted to compile with FileGDB support. On Fri, Jan 25, 2013 at 1:19 AM, Jan Heckman jan.heck...@gmail.com wrote: Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.com wrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/ 3) export LD_LIBRARY_PATH=/usr/lib64/FileGDB_API/lib cd /usr/lib64/FileGDB_API/samples make cd bin ./Querying #Works, so the API is fine. 4) su - $ vi /etc/ld.so.conf.d/fgdb.conf #Added a single entry: /usr/lib64/FileGDB_API/lib $ ldconfig #A grep of this with the -v flag shows it registered fine 5) #Some openSUSE specific stuff, b/c I'm building locally via the OBS $ zypper in osc cd /home/saultdon/Development/obs osc co Application:Geo libgdal cd Application:Geo/libgdal vi libgdal.spec #added --with-fgdb=/usr/lib64/FileGDB_API in %configure section #I also did a test build without that configure param. first and it compiled fine with working RPMs osc build openSUSE_12.2 x86_64 libgdal.spec --clean Resulting Error: [ 209s] checking for libFileGDBAPI.so in in /usr/lib64/FileGDB_API/lib... configure: error: not found. [ 209s] error: Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) [ 209s] RPM build errors: [ 209s] Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) The buildroot was: /var/tmp/build-root libFileGDBAPI.so file exists, ldconfig registered it, and the API test worked fine, the env. var. LD_LIBRARY_PATH is also set, but I don't even think that's necessary. I only had to set that to get the API test to work. I'm not sure where this is going wrong. If anyone has any input or needs more information, let me know. Thanks! Donovan ___ 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] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
My buildlog from osc build openSUSE_12.2 x86_64 libgdal.spec --clean if it helps. http://paste.opensuse.org/view/raw/e119c82d On Fri, Jan 25, 2013 at 1:54 PM, Donovan Cameron sault@gmail.comwrote: I've tested compiling the 64bit gdal-1.9.2 from the tar.gz source file: ./configure --with-fgdb=/usr/lib64/FileGDB_API And it completes successfully where I can see the FileGDB driver read/write format in the output of ogrinfo --formats. There must be something in this SPEC file that is causing a conflict so that that the .so for the FileGDB driver can't be found, even after it's registered with ldconfig. On Fri, Jan 25, 2013 at 11:05 AM, Donovan Cameron sault@gmail.com wrote: Thanks for the suggestion Jan. I tried to compile the 32-bit libgdal with the 32bit FileGDB_API but still throws the same error... Is it possible that the osc tool is looking inside it's build environment at /tmp or /usr/tmp instead of my local user files at /usr/lib64? I might take this problem to the package maintainer for libgdal on openSUSE 12.2 to see if they have attempted to compile with FileGDB support. On Fri, Jan 25, 2013 at 1:19 AM, Jan Heckman jan.heck...@gmail.com wrote: Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.com wrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/ 3) export LD_LIBRARY_PATH=/usr/lib64/FileGDB_API/lib cd /usr/lib64/FileGDB_API/samples make cd bin ./Querying #Works, so the API is fine. 4) su - $ vi /etc/ld.so.conf.d/fgdb.conf #Added a single entry: /usr/lib64/FileGDB_API/lib $ ldconfig #A grep of this with the -v flag shows it registered fine 5) #Some openSUSE specific stuff, b/c I'm building locally via the OBS $ zypper in osc cd /home/saultdon/Development/obs osc co Application:Geo libgdal cd Application:Geo/libgdal vi libgdal.spec #added --with-fgdb=/usr/lib64/FileGDB_API in %configure section #I also did a test build without that configure param. first and it compiled fine with working RPMs osc build openSUSE_12.2 x86_64 libgdal.spec --clean Resulting Error: [ 209s] checking for libFileGDBAPI.so in in /usr/lib64/FileGDB_API/lib... configure: error: not found. [ 209s] error: Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) [ 209s] RPM build errors: [ 209s] Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) The buildroot was: /var/tmp/build-root libFileGDBAPI.so file exists, ldconfig registered it, and the API test worked fine, the env. var. LD_LIBRARY_PATH is also set, but I don't even think that's necessary. I only had to set that to get the API test to work. I'm not sure where this is going wrong. If anyone has any input or needs more information, let me know. Thanks! Donovan ___ 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] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
Hi Donovan, This approach will not work. OpenBuildService (OBS) is a system to automate builds and create packages, and we are using it to http://openbuildservice.org/ openSUSE Build Service is a deployment of OBS that we are using to produce openSUSE distribution https://build.opensuse.org/ The root of your problem: OBS builds packages in an isolated environment (chroot or kvm virtual machines where network is not accessible). In order to satisfy dependencies, those have to be already packaged and get pre-installed on the chroot environment (or vm) as specified by the Requires: and BuildRequires: sections of the spec file. This is made in order to CONFIRM that everything that is needed to build the new rpm package is already included in the distribution and that the source code is available for it. On the openSUSE Build Service (including Application:Geo repository) it is FORBIDDEN to upload binaries, only source code is permitted. This is done to confirm that our distribution can be built completely from source code. OBS is Open Source and if you want to build non open source stuff you can deploy it on your own server, no problem there. The specifics of your problem: It is correct to use ./configure --with-fgdb=/usr/lib64/FIleGDB_API but the problem is that these files have to be installed inside the chroot environment. You have 2 options: 1. Create an RPM for the GDB_API and make a BuildRequires statement in the spec file to pull it in the build environment 2. Include the original tar.gz files on your spec file and move around files in correct places before the configure command I hope this helps. Best, Angelos On 01/25/2013 11:34 PM, Donovan Cameron wrote: My buildlog from osc build openSUSE_12.2 x86_64 libgdal.spec --clean if it helps. http://paste.opensuse.org/view/raw/e119c82d On Fri, Jan 25, 2013 at 1:54 PM, Donovan Cameron sault@gmail.comwrote: I've tested compiling the 64bit gdal-1.9.2 from the tar.gz source file: ./configure --with-fgdb=/usr/lib64/FileGDB_API And it completes successfully where I can see the FileGDB driver read/write format in the output of ogrinfo --formats. There must be something in this SPEC file that is causing a conflict so that that the .so for the FileGDB driver can't be found, even after it's registered with ldconfig. On Fri, Jan 25, 2013 at 11:05 AM, Donovan Cameron sault@gmail.com wrote: Thanks for the suggestion Jan. I tried to compile the 32-bit libgdal with the 32bit FileGDB_API but still throws the same error... Is it possible that the osc tool is looking inside it's build environment at /tmp or /usr/tmp instead of my local user files at /usr/lib64? I might take this problem to the package maintainer for libgdal on openSUSE 12.2 to see if they have attempted to compile with FileGDB support. On Fri, Jan 25, 2013 at 1:19 AM, Jan Heckman jan.heck...@gmail.com wrote: Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.com wrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/ 3) export LD_LIBRARY_PATH=/usr/lib64/FileGDB_API/lib cd /usr/lib64/FileGDB_API/samples make cd bin ./Querying #Works, so the API is fine. 4) su - $ vi /etc/ld.so.conf.d/fgdb.conf #Added a single entry: /usr/lib64/FileGDB_API/lib $ ldconfig #A grep of this with the -v flag shows it registered fine 5) #Some openSUSE specific stuff, b/c I'm building locally via the OBS $ zypper in osc cd /home/saultdon/Development/obs osc co Application:Geo libgdal cd Application:Geo/libgdal vi libgdal.spec #added --with-fgdb=/usr/lib64/FileGDB_API in %configure section #I also did a test build without that configure param. first and it compiled fine with working RPMs osc build openSUSE_12.2 x86_64 libgdal.spec --clean Resulting Error: [ 209s] checking for libFileGDBAPI.so in in /usr/lib64/FileGDB_API/lib... configure: error: not found. [ 209s] error: Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) [ 209s] RPM build errors: [ 209s] Bad exit status from /var/tmp/rpm-tmp.7SOa8g (%build) The buildroot was: /var/tmp/build-root libFileGDBAPI.so file exists, ldconfig registered it, and the API test worked fine, the env. var. LD_LIBRARY_PATH is also set, but I don't even think
Re: [gdal-dev] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
When I check-out the libgdal package and I run the osc build command, isn't this building locally and not trying to *upload *any binaries? I thought this chroot was in my local machine and only making changes there? I was trying to keep this all a local build by following the instructions at: https://en.opensuse.org/openSUSE:Build_Service_Tutorial maybe I misunderstood what local really means. Should I not be using osc to build this and instead use the rpmbuild commands directly? I'll explore those two options you've suggested, I was trying to do option 2, but kept running into permission issues when the source tarball for the API was being extracted to the chroot environment at /usr/lib64 with permission denied. I'll read more on this stuff, thanks again. I think I just need to read more on how to handle user permissions in the spec file, so I'll take some time to read some more docs on bundling RPMs from spec files. On Fri, Jan 25, 2013 at 3:57 PM, Angelos Tzotsos gcpp.kal...@gmail.comwrote: Hi Donovan, This approach will not work. OpenBuildService (OBS) is a system to automate builds and create packages, and we are using it to http://openbuildservice.org/ openSUSE Build Service is a deployment of OBS that we are using to produce openSUSE distribution https://build.opensuse.org/ The root of your problem: OBS builds packages in an isolated environment (chroot or kvm virtual machines where network is not accessible). In order to satisfy dependencies, those have to be already packaged and get pre-installed on the chroot environment (or vm) as specified by the Requires: and BuildRequires: sections of the spec file. This is made in order to CONFIRM that everything that is needed to build the new rpm package is already included in the distribution and that the source code is available for it. On the openSUSE Build Service (including Application:Geo repository) it is FORBIDDEN to upload binaries, only source code is permitted. This is done to confirm that our distribution can be built completely from source code. OBS is Open Source and if you want to build non open source stuff you can deploy it on your own server, no problem there. The specifics of your problem: It is correct to use ./configure --with-fgdb=/usr/lib64/FIleGDB_API but the problem is that these files have to be installed inside the chroot environment. You have 2 options: 1. Create an RPM for the GDB_API and make a BuildRequires statement in the spec file to pull it in the build environment 2. Include the original tar.gz files on your spec file and move around files in correct places before the configure command I hope this helps. Best, Angelos On 01/25/2013 11:34 PM, Donovan Cameron wrote: My buildlog from osc build openSUSE_12.2 x86_64 libgdal.spec --clean if it helps. http://paste.opensuse.org/view/raw/e119c82d On Fri, Jan 25, 2013 at 1:54 PM, Donovan Cameron sault@gmail.com sault@gmail.comwrote: I've tested compiling the 64bit gdal-1.9.2 from the tar.gz source file: ./configure --with-fgdb=/usr/lib64/FileGDB_API And it completes successfully where I can see the FileGDB driver read/write format in the output of ogrinfo --formats. There must be something in this SPEC file that is causing a conflict so that that the .so for the FileGDB driver can't be found, even after it's registered with ldconfig. On Fri, Jan 25, 2013 at 11:05 AM, Donovan Cameron sault@gmail.com sault@gmail.com wrote: Thanks for the suggestion Jan. I tried to compile the 32-bit libgdal with the 32bit FileGDB_API but still throws the same error... Is it possible that the osc tool is looking inside it's build environment at /tmp or /usr/tmp instead of my local user files at /usr/lib64? I might take this problem to the package maintainer for libgdal on openSUSE 12.2 to see if they have attempted to compile with FileGDB support. On Fri, Jan 25, 2013 at 1:19 AM, Jan Heckman jan.heck...@gmail.com jan.heck...@gmail.com wrote: Hi, On windows, using visual studio (2008 and 2012), I could compile both 32 bits and 64 bits, but only the 32 bits version actually worked. I haven't tried to figure out why the 64 bits version didn't work, 32 bits was good enough for me. Hope this is an option for you as well, Jan On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron sault@gmail.com sault@gmail.com wrote: Looks like over in the [qgis-user] list, someone is having similar problems: https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron sault@gmail.com sault@gmail.com wrote: I can't seem to compile GDAL with FileGDB support on openSUSE. I'm compiling locally using the OBS tools (osc) and have checked-out the libgdal package from the Application:Geo project. Steps I've taken: 1) Download FileGDB_API_1_2-64.tar.gz 2) tar xzvf FileGDB_API_1_2-64.tar.gz -C
Re: [gdal-dev] libFileGDBAPI.so not found with compiling gdal 1.9.2 on openSUSE 12.2 x64.
Hi Donovan, comments inline: On 01/26/2013 01:34 AM, Donovan Cameron wrote: When I check-out the libgdal package and I run the osc build command, isn't this building locally and not trying to *upload *any binaries? I thought this chroot was in my local machine and only making changes there? Yes this chroot is local when you use osc build command. Be careful not to push your changes though. Those local rpms can be saved and used, no problem. I was trying to keep this all a local build by following the instructions at: https://en.opensuse.org/openSUSE:Build_Service_Tutorial maybe I misunderstood what local really means. Should I not be using osc to build this and instead use the rpmbuild commands directly? As long as you don't push proprietary binaries to OBS it is ok to build locally. I'll explore those two options you've suggested, I was trying to do option 2, but kept running into permission issues when the source tarball for the API was being extracted to the chroot environment at /usr/lib64 with permission denied. I would suggest to create a spec file that installs that API, build locally and then require that rpm for your local gdal build. I'll read more on this stuff, thanks again. You are welcome :) I think I just need to read more on how to handle user permissions in the spec file, so I'll take some time to read some more docs on bundling RPMs from spec files. Cheers, Angelos -- Angelos Tzotsos Remote Sensing Laboratory National Technical University of Athens http://users.ntua.gr/tzotsos ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
