Re: [gdal-dev] Problem Compiling with Oracle (--with-oci)
I have the expat 1.95 added via standed RHEL repo and using oracle instant client (11.2) without a problem with GDAL from SVN I use ./configure \ --with-libtiff=internal \ --with-geotiff=internal \ --with-jpeg=internal \ --with-libz=internal \ --with-png=internal \ --with-oci=/oracle/instantclient_11_1 \ --with-geos=/usr/local/bin/geos-config \ --with-curl \ --with-threads \ --with-expat=yes \ --with-libkml \ --with-python Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers Hanover, NH On 6/21/11 3:15 PM, Nikolaos Hatzopoulos nhat...@gmail.com wrote: vi configure :) --Nikos On Tue, Jun 21, 2011 at 12:02 PM, Chris Hodgson chodg...@refractions.net wrote: Ivan I appreciate your help here, but I think I've already tried everything you are suggesting. I dont' have an ORACLE_HOME set on the user doing this compiling, so if I don't specify --with-oci=... I don't get oracle support. I do have expat 1.95 installed (with -devel package as well) and it is automatically picked up by configure. I can build gdal successfully with no configure options, it builds with expat support among other defaults. If I specify --with-oci, I get the error about the funny libexpat path, if I add --with-expat=no, I get past that error, but get an error later when it can't find the XML_* symbols that the oracle library needs to be linked to. In neither of these cases to i get a working version of gdalinfo built. It seems to me that I need to link in expat for the oracle library, but I'm not sure if it is compatible with the 1.95 version the my system has installed and that GDAL requires if I specify --with-expat ... because there is an libexpat.so.0.5 in the oracle lib directory. Since I don't actually need GDAL's expat support, I'm fine with --with-expat=no ... but then I need to somehow tell libtool to ignore the funny expat path it is finding and use the expat in the oracle directory... perhaps the best way to do this is just to copy the libtool command that is failing in the build and tweak it manually to have the right path to the oracle expat instead of the funny path... however I won't be able to get to the next step of the build to see what other commands I need to run... is there a way to modify the makefile or tell configure about this? Thanks, Chris Ivan Lucena wrote: Hi Chris, I would not advise changing the configuration file. If you have a full installation of Oracle in your system you probably have a ORACLE_HOME environment variable, so if you run: $ ./configure ... checking for Oracle OCI headers in /oracle/path/... yes checking for Oracle OCI libraries in /oracle/path/lib... yes checking if Oracle OCI version is = 8.1.7 ... yes checking for Oracle version = 10.x to use -lnnz10 flag... yes checking if Oracle support is enabled... yes ... OCI support: yes GEORASTER support: yes ... If you don't have ORACLE_HOME you can pass the path using $ ./configure --with-oci=/oracle/path/... Now, you system is CentOS and I have never build GDAL on it but I would guess that it doesn't have Expat installed yet. My Linux does, so configure finds it: checking for XML_ParserCreate in -lexpat... yes checking for Expat XML Parser headers in /usr/include... found checking for Expat XML Parser... yes My suggestion is to isolate the problem by running ./configure, make and gdalinfo without Expat once and then make clean, ./configure, make and gdalinfo without OCI, ex: % ./configure --with-expat=NO % ./configure --with-OCI=NO Configure will setup your makefiles, then you run make based on those new settings. Good luck. Ivan ---Original Message--- From: Chris Hodgson chodg...@refractions.net To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem Compiling with Oracle (--with-oci) Sent: Jun 21 '11 12:38 What would need changed in the configure file? There is no reference there to the non-existent libexpat. I'm not familiar with spec files... but if I wanted to learn - what could I do there that I couldn't do in the configure/make process? The spec file still uses the package's build system right? It's not until the final linking with libtool that the problem happens, I just don't know what I need to tell libtool to get it to smarten up... Surely other people have compiled with support for oracle 11g? CentOS is just repackaged RHEL I don't know what I'm doing that is out of the ordinary here. Chris Nikolaos Hatzopoulos wrote: check the configure file it might need changes (vi configure) you can add the elgis repo add the devel package and start getting involved with the compile. this is a src rpm: http://elgis.argeo.org/repos/testing/5/elgis/SRPMS/gdal-1.8.0-2.el5.elgis.s rc.rpm
[gdal-dev] OGR2OGR PGeo reprojection with -sql
All, Using GDAL trunk, I can read and reproject a personal geodatabase using the internal projection as the source projection. However, when I use sql (as I need to add a new field to the output), the source projection can no longer be read. C:\tempogr2ogr -t_srs EPSG:4326 -f ESRI Shapefile temp1.shp CL_01_LDS_20101201_A.mdb CL_01_LDS_20101201_A_Contour_Smoothed Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' C:\tempogr2ogr -t_srs EPSG:4326 -f ESRI Shapefile temp1.shp CL_01_LDS_20101201_A.mdb -sql select * from CL_01_LDS_20101201_A_Contour_Smoothed Can't transform coordinates, source layer has no coordinate system. Use -s_srs to set one. Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR2OGR PGeo reprojection with -sql
Thanks Even, that worked perfectly. Mike On 4/11/11 1:29 PM, Even Rouault even.roua...@mines-paris.org wrote: Le lundi 11 avril 2011 18:47:16, Chaitanya kumar CH a écrit : Mike, Can you provide the version number and perhaps a sample dataset that shows this problem? No, need for it. This is the expected behaviour by looking at the code of the PGEO driver. It will be able to fetch the SRS only when working directly with layers, not with SQL requests. You could try specifying the -dialect OGRSQL option to ogr2ogr, in which case the SQL will be evaluated by OGR SQL engine and not by the ODBC engine. The OGRSQL engine should be able to retrieve the SRS from the layer. On Mon, Apr 11, 2011 at 9:51 PM, Smith, Michael D ERDC-CRREL-NH michael.sm...@usace.army.mil wrote: All, Using GDAL trunk, I can read and reproject a personal geodatabase using the internal projection as the source projection. However, when I use sql (as I need to add a new field to the output), the source projection can no longer be read. C:\tempogr2ogr -t_srs EPSG:4326 -f ESRI Shapefile temp1.shp CL_01_LDS_20101201_A.mdb CL_01_LDS_20101201_A_Contour_Smoothed Warning 6: Normalized/laundered field name: 'Shape_Length' to 'Shape_Leng' C:\tempogr2ogr -t_srs EPSG:4326 -f ESRI Shapefile temp1.shp CL_01_LDS_20101201_A.mdb -sql select * from CL_01_LDS_20101201_A_Contour_Smoothed Can't transform coordinates, source layer has no coordinate system. Use -s_srs to set one. Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers ___ 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] accessing zip files by URL
Joaquim, For .tar.gz, you can use /vsitar Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers Hanover, NH On 3/24/11 2:03 PM, Joaquim Luis jl...@ualg.pt wrote: Even, Chaitanya Thanks for hint. I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it hasn't any mention to the need of using vsicurl I was about to do the tests you did, so thank you also for that. The point here is not to read that file in particular. I just wanted to use one as example and one that is not a *.tar.gz that the docs say it won't work. Ok, I have enough information to make it possible to read some compressed files sitting somewhere in the web and have the data land directly in the internals of GMT. Thanks Joaquim Joaquim, The correct syntax would be : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 .dem.zip/W020N90.DEM or just : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90 .dem.zip because the zip file only contains one single file (W020N90.DEM) ... But the W020N90.DEM inside the zip file isn't directly recognized by GDAL (even if you download it and unzip the file). It's just a RAW file, that neads an header to tell the dimension, georeferencing, datatype etc, so the above won't directly work. You can for example create a VRT that refers to the raw file : VRTDataset rasterXSize=4800 rasterYSize=6000 GeoTransform-20, 8.3338e-03, 0, 90, 0, -8.3338e-03/GeoTransform VRTRasterBand dataType=Int16 band=1 subClass=VRTRawRasterBand NoDataValue-/NoDataValue SourceFilename relativetoVRT=0/vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM 30/w020n90/w020n90.dem.zip/SourceFilename ByteOrderMSB/ByteOrder /VRTRasterBand /VRTDataset I've deduced this VRT from the http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.hdr.zip file that sits next to the .dem.zip file. It's a shame that they didn't put the .hdr and the .dem file inside the same zip. It would have they been possible to open it directly... With the SRTM3 in HGT format, you can directly do : gdalinfo /vsizip/vsicurl/http://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Africa/N00E006.h gt.zip Best regards, Even Hi, How do we access to a compressed files by URL? We can do that, can't we? As an example I try this (on Windows) gdalinfo /vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.de m.zip ERROR 4: `/vsizip/C:\http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.d em.zip' does not exist in the file system, and is not recognised as a supported dataset name. and this gdalinfo /vsizip//http://dds.cr.usgs.gov/srtm/version2_1/SRTM30/w020n90/w020n90.dem. zip but the error message is similar. The idea is to fetch the data directly into GMT, but first I need to understand well how it works. Thanks Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Compiling GDAL --with-oci
Ivan, Oracle express edition does support SDO_GEOMETRY. Mike -- Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers Hanover, NH On 6/4/10 3:05 AM, Lucena, Ivan ivan.luc...@pmldnet.com wrote: Iván Sánchez Ortega wrote: El 04/06/2010 10:46, Mateusz Loskot escribió: open config.log and locate bits related to Oracle OCI configure:25057: checking for Oracle OCI headers in /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/ configure:25100: g++ -c -I/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/rdbms/public -I/usr/lib/ ./configure: line 25101: g++: command not found Dammit. One apt-get install g++later , everything works as expected :-) Hi Iván. Just a reminder. Oracle Express Edition does not support SDO_GEOMETRY or SDO_GEORASTER but only SDO_LOCATOR, so I don't think you are going to able to do much with GDAL. If you are planning to use Oracle only for evaluation or for your own software development projects you can download and use the full version without a purchase. Just download, install and start using it. But you cannot use in production mode, managing large databases. Regards, Ivan ___ 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
