{5} Assigned, Active Tickets by Owner (Full Description) (118 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

Didge

Ticket Summary Component Milestone Type Created
Description
#1791 [KML] Buggy parsing of HTML tags in content of <description> element OGR_SF defect 09/04/07

This problem was reported on IRC: 

[20:37]  <darkblueB> >>the one that got stuck was embedded HTML
with self-closure <br/> inside <description>.. it was fixed
but th efix wasn't good in all cases, which is a bad sign
with something like a parser

alexamici@fastwebnet.it

Ticket Summary Component Milestone Type Created
Description
#499 AIX libtool - no .o files. default defect 02/20/04 
I am building on AIX 4 with libtool enabled, but it seems like make keeps
regenerating the same files over and over again.

For instance if I cd into gdal/port, and type make the build runs fine.
But only the .lo and .libs/*.lo files are created.  There is no .o file. 

If I type make again, all the same files are re-compiled. 

Should our dependency rules depend on .lo files instead of .o files when 
libtool is being used?   I see on Linux .o files are created as well, 
presumably because there is a difference between pic and non-pic code 
that does not exist on AIX. 

Any thoughts?

I don't know if I can easily provide access to the machine in question
#500 Cygwin / libtool build problem default defect 02/20/04 
I am getting some weird problems building on Cygwin that I assume is related
to libtool, though I could be wrong. 

Source: ftp://ftp.remotesensing.org/gdal/gdal-1.2.0a2.tar.gz

Platform:
CYGWIN_NT-5.1 play 1.3.20(0.73/3/2) 2003-02-08 12:10 i686 unknown unknown Cygwin

I will attach the log, but the following just before building the shared
library seems suspicious:

make[1]: Entering directory `/cygdrive/c/warmerda/cygdev/gdal-1.2.0a2'
GNUmakefile:43: warning: overriding commands for target `libgdal.la'
GNUmakefile:39: warning: ignoring old commands for target `libgdal.la'

The errors include lots of stuff like:

./frmts/o/.libs/sdtslib.o(.stab+0x159560): In function `Z24SDTSScanModuleReferen
cesP9DDFModulePKc':
/cygdrive/c/warmerda/cygdev/gdal-1.2.0a2/frmts/sdts/sdtslib.cpp:285: reloc refer
s to symbol `.text$_ZN12DDFFieldDefn16GetSubfieldCountEv' which is not being out
put

condit

Ticket Summary Component Milestone Type Created
Description
#1897 KML driver output appears broken OGR_SF defect 10/10/07

KML output from ogr2ogr does not open in GoogleEarth?

KML SoC driver, nor KML driver 1.4.2

remove the <Multipolygon> tag, file can be opened,

though the polys are filled rather than outlines

Note that the SoC KML driver internally uses a v2.0 spec that is no longer on the web

related ticket #1766

GoogleEarth? v4.2.0180.1134 (beta), 20Aug07, Mac OSX

#2298 improve the OGR KML creation options OGR_SF enhancement 03/27/08

Hello, when converting to a KML file from a vector resource via the virtual file format one can give a NameField? option which will be used to assigne names to the geoobjects on the KML file: ogr2ogr -f KML output.kml input.shp -dsco NameField?=RegionName?

Please add another option for placemark categories like ogr2ogr -f KML output.kml input.shp -dsco PlacemarkCategory?=kind_of_site

This option/keyword could serve the purpose to create a KML file and assign different Icons for the placemarks based upon unique identifiers in the database column "kind_of_site".

Example: A ecologist who wants to map sitings of three animal species could use the categoriy to show which bird appeard where (e.g. coocoo, eagle, crow) and display this information using different icons.

Please comment if you have a better idea who to get categorized items for KML based upon vector database information.

Thanks for looking at this.

dmorissette

Ticket Summary Component Milestone Type Created
Description
#308 Mapinfo : ogr symbol number problem OGR_SF defect 03/19/03

In the mapinfo driver, the numbering of symbol does not match the numbering specified in the documentation : ogr-sym-X+1 is returned instead ogr-sym-X.

For example, ogr-sym-3 is returned for the filedd-circle symbol instead of ogr-sym-2.

#842 OGR .IND files not used if read-only OGR_SF defect 04/29/05 
This is indirectly related to #839. 

I found that if the .IND file or the whole set of shapefiles for a given dataset
are read-only, then the .IND file is not used. Just making the .ind file
writeable is enough to have it used.

$ chmod -w shptest2.*
$ ogrinfo shptest2.shp -sql "SELECT * FROM shptest2 WHERE parcelid = 'D0134 
M00015'"
ERROR 4: Unable to open shptest2.shp or shptest2.SHP.
ERROR 3: Open() failed for shptest2.ind
ERROR 4: Failed to open index file shptest2.ind.
Had to open data source read-only.
...
... the query works but doesn't use the index (slow)
...

$ chmod +w shptest2.ind
$ ls -l shptest2.*
-r--r--r--    1 daniel   users    276714879 Apr 27 11:07 shptest2.dbf
-r--r--r--    1 daniel   users         227 Apr 27 11:09 shptest2.idm
-rw-rw-r--    1 daniel   users    17092608 Apr 29 11:06 shptest2.ind
-r--r--r--    1 daniel   users          38 Apr 27 11:05 shptest2.prj
-r--r--r--    1 daniel   users    307403144 Apr 27 11:07 shptest2.shp
-r--r--r--    1 daniel   users     2657620 Apr 27 11:07 shptest2.shx
$ ogrinfo shptest2.shp -sql "SELECT * FROM shptest2 WHERE parcelid = 'D0134 
M00015'"
ERROR 4: Unable to open shptest2.shp or shptest2.SHP.
Had to open data source read-only.
...
... this time the index is being used and returns fast
...

dnadeau

Ticket Summary Component Milestone Type Created
Description
#1568 gdalinfo on a netCDF file returns uninitiated coordinate information if variable/band not specified GDAL_Raster defect 04/09/07

This behaviour is described in #1506, and appears to work with any any NetCDF file, for example (using the "test-0001.nc" file from here): 

$ gdalinfo -nomd test-0001.nc 
Driver: netCDF/Network Common Data Format
Size is 512, 512
Coordinate System is `'
Subdatasets:
  SUBDATASET_1_NAME=NETCDF:"test-0001.nc":recharge
  SUBDATASET_1_DESC=[1x225x86] recharge (32-bit floating-point)
Corner Coordinates:
Upper Left  (    0.0,    0.0)
Lower Left  (    0.0,  512.0)
Upper Right (  512.0,    0.0)
Lower Right (  512.0,  512.0)
Center      (  256.0,  256.0)

The coordinate information 0.0, 256.0, etc. (power of 2) are uninitiated values for the raster band (or NetCDF variable), and are not representative for the file. It would seem appropriate for gdalinfo to report that the raster band has undefined coordinate information, rather than reporting ininitiated values.

Secondly, as there is only one variable/band in the netCDF file, gdalinfo should use that variable variable to define the coordinate information (I understand from #1506 that this is an unfinished defect in the NetCDF driver). The correct coordinate information is obtained by specifying the single band: 

$ gdalinfo -nomd NETCDF:"test-0001.nc":recharge
Driver: netCDF/Network Common Data Format
Size is 86, 225
Coordinate System is `'
Origin = (747650.000000000000000,5463750.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Corner Coordinates:
Upper Left  (  747650.000, 5463750.000) 
Lower Left  (  747650.000, 5441250.000) 
Upper Right (  756250.000, 5463750.000) 
Lower Right (  756250.000, 5441250.000) 
Center      (  751950.000, 5452500.000) 
Band 1 Block=86x1 Type=Float32, ColorInterp=Undefined
  NoData Value=-9999
#1607 GDAL/OPeNDAP version request. default 1.5.2 defect 05/02/07

Two patches for GDAL that we maintain locally now, three if we need to do the version hack:

  1. better support for georeferencing metadata
  2. wrt backslash support

Patches: https://db.aoos.org/wiki/index.php/AOOS_Systems_Software_Mapserver#libdap

Some discussion on the georeferencing metadata support which supplies

PROJ.4 type metadata for GDAL: https://db.aoos.org/wiki/index.php/AOOS_OPeNDAP#AOOS_OPeNDAP_Standards

dron

Ticket Summary Component Milestone Type Created
Description
#430 ASTER HDF Georeferencing Off by 1KM? GDAL_Raster defect 11/05/03

Andrey,

Steve Soule from Vexcel has pointed me to an ASTER HDF file which seems to have incorrect georeferencing. He raised the concern because the georeferencing didn't match a GeoTIFF file derived from the file by other software.

I confirmed this, and noticed that the lat/long corners of the image as reported in the metadata don't seem to match the lat/long corners reported after reprojection (in the gdalinfo report).

I will attach the gdalinfo report to this bug report. The file itself is pretty large so I am putting it putting it at the following url for download, assuming you need to do that.

http://pobox.com/~warmerdam/ASTER_DEM20020123085409.hdf

#833 tiff-3.7.2 libtiff.so doesn't work with ImageMagick 6.2.0/6.2.1 pgm to tiff convert default defect 04/19/05 
convert image.pgm image.tiff
display image.tiff
display: Not a TIFF file, bad magic number 49087 (0xbfbf). `image.tiff'.

When I replace with tiff-3.7.1 convert and display works fine.

Problem occurs on Solaris 8 and 9 - tiff-3.7.2 and tiff-3.7.1 built with gcc-3.4.3
#1221 Read JP2 with Jasper driver excrutiatingly slow GDAL_Raster defect 06/28/06 
Reading a JP2 with the JasPer driver is extremely slow.  Wrting JP2 with JasPer works fine.  A 5000x5000 
pixel color JP2 (lossless) takes over 5 minutes to tick over the progress meter.  As a comparison, reading 
the same JP2 with the MrSID JP2 driver takes 1.3 minutes for the full image.  Outsides of GDAL, with the 
jasper program (same jasper libraries that GDAL uses), it takes 30 sec to read the full image.

There is nothing in the console log to indicate a problem.  It passes the gdalautotests, but those are small 
files so the speed problem is not noticable.

GDAL 1.3.2
#1900 Get hdf band, inverse data set dimensions GDAL_Raster defect 10/11/07

Hi!

In the MODIS cloud product hdf files (MOD03, MYD03) some data sets are stored with the band dimension last instead of first. 

gdalinfo myfile.hdf (or gdal.Dataset.GetSubDatasets) yields:
[snip]
SUBDATASET_52_NAME=HDF4_EOS:EOS_SWATH:'myfile.hdf':mod06:Cloud_Mask_1km
SUBDATASET_52_DESC=[2040x1354x2] Cloud_Mask_1km mod06 (8-bit integer)
[snip]

So obviously there are two bands of size 2040x1354 in the subdataset. However, in order for gdal to recognize them as two bands the dimensions would have to be [2x2040x1354].

Accordingly, when I do gdalinfo HDF4_EOS:EOS_SWATH:'myfile.hdf':mod06:Cloud_Mask_1km I get information on 2040 different bands, each of size 1354x2

It would be useful to have a feature in gdal that allows explicit selection of the dimension that holds the band count or even let gdal decide on this.

A sample file is at: ftp://ladsweb.nascom.nasa.gov/allData/5/MYD06_L2/2006/220/MYD06_L2.A2006220.1315.005.2006222153137.hdf

Thanks and all best, Jan

PS: hdfview can read these files.

#2070 Remove OGRStyleVector OGR_SF 1.6.0 defect 12/07/07

As part of the discussions on RFC 18: OGR Style Support in C API for GDAL/OGR 1.5.0, Andrey mentioned that the OGRStyleVector class and related definitions were not used in OGR and should be removed in a future release (OGRStyleVector is only used in some of their apps but does not belong in OGR).

This ticket is to remind us to do this for 1.6.0.

#2251 Jasper driver fails with small jp2 image GDAL_Raster defect 02/29/08

Attempting to use the example jp2 images from the ecw sdk, ie testdata/Grayscale2.jp2 causes gdal to throw an error: 

$ ./gdal_translate.exe -of GTiff testdata/Greyscale2.jp2 gray.tiff
Input file size is 1500, 1500
0jpc_dec_decodepkts failed
error: cannot decode code stream
error: cannot get box
ERROR 1: IReadBlock failed at X offset 0, Y offset 0
ERROR 1: GetBlockRef failed at X block offset 0, Y block offset 0

This can be seen via gddal_translate and also band.readraster via code. The jasper library is the uuid modified version.

#2327 cubicspline resampling and other resamplers don't work for the entire image GDAL_Raster defect 04/16/08

If I resample a large image (14400x14400px) using cubicspline to be much smaller (1024x1024px), the cubic spline resampling seems to miss some 'strips' of the image. These 'strips' end up looking like nearest neighbor sampling is being used, and look similar to static in my raster set. The strips appear at regular intervals inside the image, and along the edges. This problem does not appear when using cubic interpolation.

These problem 'strips' become quite obvious when using a ZonePlate? test image (and ImageMagick?): http://www.worldserver.com/turk/opensource/#ZonePlate

I generated my test image using these commands: ./ZonePlate -w 14400 -h 14400 -s 1 -o z14400.gray convert -size 14400x14400 gray:z14400.gray PNG42:z14400.png

Here is the warp command: gdalwarp -r cubicspline -ts 1024 1024 z14400.tif z14400.cs.tif

Attached is the output I get. The input is simply concentric rings of varying frequency. The output should be mostly gray, but instead has strips of black & white running through it.

mloskot

Ticket Summary Component Milestone Type Created
Description
#1800 Prepare testing documentation Website task 09/05/07

Mateusz,

I would like you to prepare some documentation on how to run, interprete and extend the gdalautotest suite. Something sort of like:

http://mapserver.gis.umn.edu/development/Tests/regression_testing/

and suitable for developers or fairly savvy end users. The material should be prepared in the Trac wiki.

I would also like you to prepare a Trac wiki page describing the use of the GDAL buildbot instances. How to launch them, what they represent (ie. epithemius is MacOS X on bigendian PowerPC), and so forth.

#1172 GDAL OVF OCI does not work with SrcSQL OGR_SF 1.5.2 defect 05/01/06

When using SrcSQL for an Oracle (OCI) table all coordinates are reported as 0 (using ogrinfo). When using a SrcLayer? to a database view everything works fine.

ovf file used: 

<OGRVRTDataSource>
  <OGRVRTLayer name="calamiteitenoud">
<SrcDataSource>OCI:BVDE/BART@//rws-svl012i.int.storage.nwr.local:1521/TGEOS.rws.nl:VW_CALAMITEITEN_OUD</SrcDataSource>
<SrcSQL>SELECT * FROM CALAMITEITEN WHERE ACTUEEL = 0</SrcSQL>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>EPSG:28992</LayerSRS>
<GeometryField encoding="PointFromColumns" x="CALX" y="CALY"/>
</OGRVRTLayer>
</OGRVRTDataSource>

I will attach a database script to create the tables and data.

#1183 Oracle WKTEXT Translation OGR_SF 1.5.2 defect 05/11/06

The following WKTEXT value from Oracle is not handled properly in OGR bccause the PROJECTION[] name has a space in it. We need morph to/from oracle methods in ogrocidatasource.cpp to remap projection names and other identified oddities of Oracle format. 

PROJCS["GK Zone 4 (DHDN)", GEOGCS [ "", DATUM ["", SPHEROID ["Bessel 1841",
6377397.155, 299.1528128], 582.000000, 105.000000, 414.000000, -1.040000,
-0.350000, 3.080000, 8.300000 ], PRIMEM [ "Greenwich", 0.000000 ], UNIT
["Decimal Degree", 0.01745329251994330]], PROJECTION ["Transverse Mercator"],
PARAMETER ["Scale_Factor", 1.000000], PARAMETER ["Central_Meridian", 12.000000],
PARAMETER ["False_Easting", 4500000.000000], UNIT ["Meter", 1.000000000000]]
#1442 Feature.GetFieldAsInteger does not behave correctly on non existant field OGR_SF 1.6.0 defect 01/16/07

Using Feature.GetFieldAsInteger? on a inexistant field in the feature, answer is always 0. I guess it should report a ValueError? like Feature.GetField? (or even an AttributeError?).

Demonstration : 

did@geru-itae:~/Documents/ucl/alert/python$ python
Python 2.4.4 (#2, Jan 13 2007, 17:50:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ogr
>>> dataset = ogr.Open('alert/test/scenario1/polygones.shp')
>>> layer = dataset.GetLayer()
>>> feature = layer.GetNextFeature()
>>> print "Test with an existing field"
Test with an existing field
>>> feature.GetFieldIndex('cat')
0
>>> feature.GetFieldAsInteger(feature.GetFieldIndex('cat'))
1
>>> print "Test with a non existant field"
Test with a non existant field
>>> feature.GetFieldIndex('id')
-1
>>> feature.GetFieldAsInteger(feature.GetFieldIndex('id'))
0
>>> feature.GetField(feature.GetFieldIndex('id'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.4/site-packages/ogr.py", line 854, in GetField
    return _gdal.OGR_F_GetField( self._o, fld_index )
ValueError: Illegal field requested in GetField().
#1471 gdalwarp should keep georeferencing info default defect 02/01/07

Currently gdalwarp drops the projection info if it is not specifically assigned. I think it should either keep all projection info unless directed otherwise, or, have an option to retain it.

Eg. 

gdalwarp inimg.tif outimg.tif ---> keeps prj
gdalwarp -t_srs SAME inimg.tif outimg.tif ---> keeps prj
gdalwarp -t_srs NONE inimg.tif outimg.tif ---> drops prj
gdalwarp -t_srs [a proj4 string] inimg.tif outimg.tif ---> transforms to new prj
#1476 Improper handling of Postgis tables with multiple geometry columns OGR_SF 1.6.0 defect 02/04/07

OGR is not able to handle properly feature types with multiple geometries. In the specific case of a Postgis table with 4 geometry columns we do have the following output: 

ogrinfo -so PG:"host=localhost port=5432 user=myuser
 password=mystery dbname=tiger2005fe" major_roads

INFO: Open of `PG:host=localhost port=5432 user=myuser password=mystery dbname=tiger2005fe' using driver `PostgreSQL' successful.

Layer name: major_roads
Geometry: Unknown (any)
Feature Count: 105628
Extent: (-170.837387, -14.377902) - (144.914001, 66.922287)
Layer SRS WKT:
(unknown)
Geometry Column = gen_full
fid: Integer (0.0)
interstate: Integer (0.0)
othername: String (0.0)
state: String (0.0)
statehighway: Integer (0.0)
ushighway: Integer (0.0)

Layer name: major_roads
Geometry: Unknown (any)
Feature Count: 105628
Extent: (-170.837387, -14.377902) - (144.914001, 66.922287)
Layer SRS WKT:
(unknown)
Geometry Column = gen_full
fid: Integer (0.0)
interstate: Integer (0.0)
othername: String (0.0)
state: String (0.0)
statehighway: Integer (0.0)
ushighway: Integer (0.0)

Layer name: major_roads
Geometry: Unknown (any)
Feature Count: 105628
Extent: (-170.837387, -14.377902) - (144.914001, 66.922287)
Layer SRS WKT:
(unknown)
Geometry Column = gen_full
fid: Integer (0.0)
interstate: Integer (0.0)
othername: String (0.0)
state: String (0.0)
statehighway: Integer (0.0)
ushighway: Integer (0.0)

Layer name: major_roads
Geometry: Unknown (any)
Feature Count: 105628
Extent: (-170.837387, -14.377902) - (144.914001, 66.922287)
Layer SRS WKT:
(unknown)
Geometry Column = gen_full
fid: Integer (0.0)
interstate: Integer (0.0)
othername: String (0.0)
state: String (0.0)
statehighway: Integer (0.0)
ushighway: Integer (0.0)

whilst the table definition is: 

tiger2005fe=# \d major_roads
                             Table "public.major_roads"
    Column    |   Type   |                         Modifiers
--------------+----------+-----------------------------------------------------------
 state        | text     |
 gen_full     | geometry |
 gen_1        | geometry |
 gen_2        | geometry |
 gen_3        | geometry |
 interstate   | integer  |
 ushighway    | integer  |
 statehighway | integer  |
 othername    | text     |
 fid          | integer  | not null default nextval('major_roads_fid_seq'::regclass)
Indexes:
    "fid_pkey" PRIMARY KEY, btree (fid)
    "major_roads_spatial_ind" gist (gen_full)
    "major_roads_spatial_ind1" gist (gen_1)
    "major_roads_spatial_ind2" gist (gen_2)
    "major_roads_spatial_ind3" gist (gen_3)
#1484 NHD (ESRI) geodatabase reading problems OGR_SF 1.6.0 defect 02/08/07

The USGS NHD data is in ESRI geodatabase mdb format. Example cmd line: 

ogr2ogr -f PostgreSQL PG:"user=user dbname=NHD host=localhost password=pass port=5432" NHDH0104.mdb

The above cmd line creates a set of PostGIS tables, but some of the tables' wkb_geometry fields are empty - for example NHDARea, HYDRO_NET_Junctions. The NHD shape fields appear to have type 19 for polygons and type 9 for points which are unknown types, to me. The shape object signatures appear to match PolygonM, 25, and PointM, 21, but since the types do not match measure features the Mmin, Mmax, Marray may mean something different.

thanks

#1587 Error compiling gdal-grass against gdal 1.4.1 ConfigBuild defect 04/20/07

Using gdal 1.4.1 and gdal-grass 1.3.2

I ran into some minor troubles getting gdal-grass plugin (version 1.3.2) installed on gdal: 

./configure --with-gdal=/usr/local/bin/gdal-config
--with-grass=/usr/local/grass-6.3.cvs

g++ -Wall -fPIC  -DUSE_CPL
-DGRASS_GISBASE=\"/usr/local/grass-6.3.cvs\" -I/usr/local/include
-I/usr/local/grass-6.3.cvs/include   -c -o grass57dataset.o
grass57dataset.cpp
grass57dataset.cpp: In static member function 'static GDALDataset*
GRASSDataset::Open(GDALOpenInfo*)':
grass57dataset.cpp:828: error: invalid conversion from 'int (*)(char*,
int)' to 'int (*)(const char*, int)'
grass57dataset.cpp:828: error:   initializing argument 1 of 'int
G_set_error_routine(int (*)(const char*, int))'
make: *** [grass57dataset.o] Error 1

Mateusz writes: It seems prototype of function pointer has changed and first parameter has been redefined from non-const to const.

For the record, changing the following lines seems to fix it. 

# grass57dataset.cpp: 799
typedef int (*GrassErrorHandler)(const char *, int);

# ogrgrassdatasource:91
typedef int (*GrassErrorHandler)(const char *, int);

I can't confirm that the above changes work but at they compile at the very least ;-)

Mateusz writes: Yes, that will work, but probably it also will break backward compatibility, I suppose.

#1651 OCI Support for Oracle 9i OGR_SF 1.5.2 defect 05/29/07

Hi,

I try to build GDAL packages under debian sarge with OCI support for a oracle 9i database. Therefore I have header and lib provided as .deb packages. The header files a provided in two folders: /usr/lib/oracle/9.2.0/OraHome/rdbms/public and /usr/lib/oracle/9.2.0/OraHome/rdbms/demo

When I try to configure GDAL with following parameters:

--with-oci-include='/usr/lib/oracle/9.2.0/OraHome/rdbms/public \

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo' \

--with-oci-lib=/usr/lib/oracle/9.2.0/OraHome/lib

I get following error:

checking for Oracle OCI headers in /usr/lib/oracle/9.2.0/OraHome/rdbms/public /usr/lib/oracle/9.2.0/OraHome/rdbms/demo... not found checking if Oracle support is enabled... no

config.log: configure:22465: checking for Oracle OCI headers in /usr/lib/oracle/9.2.0/OraHome/rdbms/public /usr/lib/oracle/9.2.0/OraHome/rdbms/demo configure:22503: g++ -c -g -O2 -I/usr/lib/oracle/9.2.0/OraHome/rdbms/public /usr/lib/oracle/9.2.0/OraHome/rdbms/demo conftest.cc >&5 conftest.cc:68:17: oci.h: No such file or directory conftest.cc:81:4: #error Oracle oci.h header not found

When I switch the order of the two oci-include directories:

--with-oci-include='/usr/lib/oracle/9.2.0/OraHome/rdbms/demo \

/usr/lib/oracle/9.2.0/OraHome/rdbms/public' \

--with-oci-lib=/usr/lib/oracle/9.2.0/OraHome/lib

I get following error:

checking for Oracle OCI headers in /usr/lib/oracle/9.2.0/OraHome/rdbms/demo /usr/lib/oracle/9.2.0/OraHome/rdbms/public... not found checking if Oracle support is enabled... no

config.log configure:22465: checking for Oracle OCI headers in /usr/lib/oracle/9.2.0/OraHome/rdbms/demo /usr/lib/oracle/9.2.0/OraHome/rdbms/public configure:22503: g++ -c -g -O2 -I/usr/lib/oracle/9.2.0/OraHome/rdbms/demo /usr/lib/oracle/9.2.0/OraHome/rdbms/public conftest.cc >&5 In file included from conftest.cc:68: /usr/lib/oracle/9.2.0/OraHome/rdbms/demo/oci.h:2159:21: ociextp.h: No such file or directory In file included from /usr/lib/oracle/9.2.0/OraHome/rdbms/demo/oci.h:2164,

from conftest.cc:68:

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo/ociap.h:192:17: nzt.h: No such file or directory In file included from /usr/lib/oracle/9.2.0/OraHome/rdbms/demo/oci.h:2164,

from conftest.cc:68:

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo/ociap.h:6607: error: type specifier

omitted for parameter `nzttWallet'

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo/ociap.h:6607: error: parse error

before `*' token

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo/ociap.h:6611: error: type specifier

omitted for parameter `nzttWallet'

/usr/lib/oracle/9.2.0/OraHome/rdbms/demo/ociap.h:6611: error: parse error

before `*' token

... [snip]

It seems, that only the first path provided with the "--with-oci-include" parameter is checked. When I look into the config.log file, in the beginning it says:

less config.log: Invocation command line was $ ./configure --prefix=/usr --mandir=/share/man --with-threads --with-grass=no --with-geotiff=internal --with-xerces --with-netcdf --with-jasper --with-odbc=no --with-python --with-postgresql --with-oci-include=/usr/lib/oracle/9.2.0/OraHome/rdbms/demo /usr/lib/oracle/9.2.0/OraHome/rdbms/public --with-oci-lib=/usr/lib/oracle/9.2.0/OraHome/lib

Here the quotation marks are missing for the 2 "--with-oci-include" pathes. Maybe they are not added and used for configuration?

I hope someone has a clue for this.

thanks

Otto

PS: I checked with version 1.4.1 and svn checkout this morning.

#1802 Add HDF support to GDAL builders on the epimetheus Buildbot defect 09/05/07

As the short summary says, we need to test HDF support on PowerPC/Mac OS platform.

#1856 SQLite files incomplete OGR_SF defect 09/22/07

Some minimal KML files, coverted to SQLite, generate an incomplete SQLite file

ex. ogr2ogr -f SQLite t.sqlite Polygon.kml

ogrinfo will read the file as containing a polygon, but opening the file with SQLite3 will show "Incomplete SQL: SQLite format 3xxx", where xxx is the table defintion. This occurs for many minimal files converted to SQLite.

#1978 Customize cache size for Windows CE WinCE Port 1.5.2 defect 11/08/07

Recently reported problems with reading TIFF files on Windows CE have been solved and explanation of the solution was posted here Windows CE - GDALDatasetRasterIO error

jetelus@centrum.cz wrote:

Finally I solved it! I was hunting that lost memory and I discovered there is cache system implemented in GDAL :-) Problem is it's default size - 40 MB - too much for CE. I set it to 4 MB using GDALSetCacheMax() and all errors are gone - lol I suck I know :) but it would be nice to add some note to GDALDatasetRasterIO documentation - something like there is cache system which memory usage can be controlled. I can display even 5 MB JPEGs now on CE!

#2151 Small bug in libTIFF on Windows CE WinCE Port defect 01/12/08

in GDAL, frmts/gtiff/libtiff/tif_dirinfo.c - in the tagCompare routine, which tests inputs a and b for field_tag and field_type match. in the current form, it tests the a parameter (the ta tag) for a wildcard setting (TIFF_ANY), which would allow a simple field_tag match to return success.

but when tagCompare is called in this chain: TIFFFindField - bsearch - tagCompare, it is the b parameter which is specified with the wildcard field (in TIFFFindField); this wildcard is pointless, since only the a parameter is tested for the wildcard setting.

Other call sequences that lead to tagCompare may be different, but in the sequence through TIFFFindField, it is the b parameter which can hold the wildcard type specification, and not the a parameter. the change below fixes the wildcarding operation - other solutions could be to reverse the field parameter order in the call to tagCompare in bsearch (or in TIFFFindField's call to bsearch)

static int tagCompare(const void* a, const void* b) {

const TIFFField* ta = *(const TIFFField**) a; const TIFFField* tb = *(const TIFFField**) b; /* NB: be careful of return values for 16-bit platforms */ if (ta->field_tag != tb->field_tag)

return (int)ta->field_tag - (int)tb->field_tag;

else

// return (ta->field_type == TIFF_ANY) ? // 0 : ((int)tb->field_type - (int)ta->field_type);

return (tb->field_type == TIFF_ANY) ? // changed return 0 : ((int)tb->field_type - (int)ta->field_type);

}

#2221 OGR SQL limits table name and column name character set OGR_SF 1.5.2 defect 02/12/08

The OGR SQL implementation limits table names and column names to letters, digits and .+-_*.

For example, with mysql with the table "Départs" wich as a column 'NomDépart' the command :

ogrinfo MySQL:test,host=localhost -sql "select NomDépart from départs"

works fine. With an equivalent shape (départs.shp), i can do :

ogrinfo départs départs

this works for the filename, but i can't do :

ogrinfo départs.shp -sql "select NomDépart from Départs" INFO: Open of `départs.shp'

using driver `ESRI Shapefile' successful.

ERROR 1: SQL: Missing comma after column NomD in SELECT statement.

#2370 undefined reference to xercesc_2_8:: ConfigBuild 1.5.2 defect 05/14/08

'make' fails when compiling either 1.5.1 or svn-trunk with multiple errors. On the same system version 1.4.4 and 1.5.0 compiles fine. 

libgdal.so: undefined reference to `xercesc_2_8::XMLFormatter::operator<<(unsigned short)'
libgdal.so: undefined reference to `xercesc_2_8::XMLString::catString(unsigned short*, unsigned short const*)'
libgdal.so: undefined reference to 'xercesc_2_8::SAXParseException::SAXParseException(xercesc_2_8::SAXParseException const&)'
libgdal.so: undefined reference to `xercesc_2_8::XMLString::copyString(unsigned short*, unsigned short const*)'
libgdal.so: undefined reference to `xercesc_2_8::XMemory::operator new(unsigned int)'
libgdal.so: undefined reference to `xercesc_2_8::XMLUni::fgXercesScannerName'

It goes on with a bunch of similar errors for several more lines. I can update with the full list if necessary.

My configure options:

./configure --with-ogr --with-oci=/usr/lib/oracle/xe/app/oracle/product/10.2.0/client --with-oci-include=/usr/lib/oracle/xe/app/oracle/product/10.2.0/client/rdbms/public --with-xerces --with-xerces-lib=/opt/xerces/lib --with-xerces-inc=/opt/xerces/include --with-mrsid=/opt/geoexpress/ --with-jp2mrsid=yes --with-threads

Thanks,

Robert

#1693 Please add HFA (Erdas Imagine) driver to WinCE project file WinCE Port 1.5.2 enhancement 07/04/07

hi,

i just tested the hfa driver on windows mobile 5 and it worked without any porting effort.

Just add the hfa* files to the wince project files and add the new FRMT_hfa define
to the preprocessor defines.

Best regards,
Wolfgang

#1540 Minor memory leaks in gmlreader.cpp OGR_SF 1.5.2 defect 03/30/07

I have fixed some minor memory leaks in gmlreader.cpp. The xerces runtime was not being cleaned up properly on exit so I have added a call to XMLPlatformUtils::Terminate(); in the GMLReader class destructor. Also some strings in GMLReader::SetupParser? were not being freed, so I have enclosed them in std::auto_ptr(s). The relevant files modded against the 1.4.0 release are attached. These leaks are trivial but can bite someone making protracted use of the library without reloading.

#1248 Please add transaction support to ogr2ogr for the postgres driver default enhancement 07/20/06 
I found out recently that ogr2ogr does not support transactions when inserting into postgres. I believe this is essential when doing large batch imports, such as importing TIGER. It helps avoid duplicate rows from being inserted and should make bulk data loads faster. I imagine a command line argument could be added to the ogr2ogr command line that would then perform all inserts and even DDL in a transaction which would get rolled back on error or abort, and commit on successful exit.

Thanks,

Daniel Ceregatti (AKA Primer on freenode)

pvachon

Ticket Summary Component Milestone Type Created
Description
#2223 CEOS driver doesn't recognize beam mode in RADARSAT-1 ScanSAR imagery GDAL_Raster defect 02/13/08

The beam mode for RADARSAT-1 ScanSAR products is found in the trailer file. Currently, the CEOS driver (ceos2/sar_ceosdataset.cpp) does not look in the trailer for this value. So, the CEOS_BEAM_TYPE metadata field is not added to the product's metadata.

rouault

Ticket Summary Component Milestone Type Created
Description
#1884 Format - SRTM HGT GDAL_Raster defect 10/03/07

According to the NASA documentation:

3.0 Data Formats The names of individual data tiles refer to the longitude and latitude of the lower-left (southwest) corner of the tile (this follows the DTED convention as opposed to the GTOPO30 standard). For example, the coordinates of the lower-left corner of tile N40W118 are 40 degrees north latitude and 118 degrees west longitude. To be more exact, these coordinates refer to the geometric center of the lower left sample, which in the case of SRTM3 data will be about 90 meters in extent.

Though in the loader it is expected that the coordinate definition lies on the corner of the sample, not on it's center and tries to fix it accordingly. That is wrong - the following would comply with the NASA definition:

GDALDataset* SRTMHGTDataset::Open(GDALOpenInfo* poOpenInfo)

poDS->adfGeoTransform[0] = southWestLon; poDS->adfGeoTransform[1] = 1.0 / (numPixels-1); poDS->adfGeoTransform[2] = 0.0000000000; poDS->adfGeoTransform[3] = southWestLat + 1; poDS->adfGeoTransform[4] = 0.0000000000; poDS->adfGeoTransform[5] = -1.0 / (numPixels-1);

Furthermore:

SRTM1 data are sampled at one arc-second of latitude and longitude and each file contains 3601 lines and 3601 samples. The rows at the north and south edges as well as the columns at he east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell.

Though in the loader is is expected to cover 1.0 degree on the [0,1200]/[0,3600] or [0,1201)/[0,3601) interval. That is wrong, it is slightly more (the overlap). 1.0 degree is then on the [0,1199]/[0,3599] or [0,1200)/[0,3600) interval - the following would correct that also:

poDS->adfGeoTransform[0] = southWestLon; poDS->adfGeoTransform[1] = 1.0 / (numPixels-2); poDS->adfGeoTransform[2] = 0.0000000000; poDS->adfGeoTransform[3] = southWestLat + 1; poDS->adfGeoTransform[4] = 0.0000000000; poDS->adfGeoTransform[5] = -1.0 / (numPixels-2);

I detected the error by trying to connect independent SRTM-tiles in a 3D-software, they weren't adjacent. I implemented the fix, and now the data fits absolutely correct.

Ciao

Niels

#2364 NITF JPEG-compressed with data mask subheader (IC=M3) multi-blocks fails default 1.6.0 defect 05/10/08

Reading the following image currently fails : http://www.gwg.nga.mil/ntb/baseline/software/testfile/Nitfv2_1/ns3301j.nsf

Currently M3 or C3 mono-block are supported, C3 multi-blocks too, but not M3 multi-block.

tamas

Ticket Summary Component Milestone Type Created
Description
#1986 GCPsToGeoTransform in the CSharp binding CSharpBindings 1.5.2 defect 11/12/07

I'm trying to use the GCPsToGeoTransform function in the 1.4.3 C# Wrapper.

It seem to me that the second argument should be an array of GCP. 

public static SWIGTYPEpFALSEISERR GCPsToGeoTransform(int nGCPs, GCP pGCPs, double[] argout, int bApproxOK);

Thanks

warmerdam

Ticket Summary Component Milestone Type Created
Description
#481 ogr2ogr: SHAPE-> MapInfo conversion - proj info get's lost OGR_SF defect 02/02/04 
Frank,

by chance I found a problem with projection definitions
when creating MapInfo format from SHAPE. The projection info
seems to get lost.

Here a test:

#Original file with no projection:
ogrinfo -summary ctr10000.shp ctr10000
Had to open data source read-only.
INFO: Open of `ctr10000.shp'
using driver `ESRI Shapefile' successful.

Layer name: ctr10000
Geometry: Polygon
Feature Count: 586
Extent: (1623653.000000, 4960499.000000) - (1824909.000000, 5178586.000000)
Layer SRS WKT:
(unknown)
A_CODICE: Integer (6.0)
B_NOME: String (40.0)
AGG: Integer (4.0)
DITTA: String (40.0)
DXF: String (16.0)
RVE: String (16.0)
SHP: String (16.0)
ASC: String (16.0)
VECTOR_TYP: String (16.0)

#######
# This map I wanted to fix by applying the related EPSG code. Output
#desired in MapInfo format. Using ogr2ogr to apply Monte Mario Italy 2:
ogr2ogr -a_srs '+init=epsg:26592' -f "MapInfo File" ctr10000 ctr10000.shp

#verification:
ogrinfo -summary ctr10000/ctr10000.tab ctr10000
Had to open data source read-only.
INFO: Open of `ctr10000/ctr10000.tab'
using driver `MapInfo File' successful.

Layer name: ctr10000
Geometry: Polygon
Feature Count: 586
Extent: (1623653.010000, 4960498.995000) - (1824909.000000, 5178586.005000)
Layer SRS WKT:
PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563],
            TOWGS84[0,0,0,-0,-0,-0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",15],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",2520000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1.0]]
A_CODICE: Integer (0.0)
B_NOME: String (40.0)
AGG: Integer (0.0)
DITTA: String (40.0)
DXF: String (16.0)
RVE: String (16.0)
SHP: String (16.0)
ASC: String (16.0)
VECTOR_TYP: String (16.0)

# --> It didn't pick up the EPSG definition.

#######
# Same test with SHAPE output:

ogr2ogr -a_srs '+init=epsg:26592'  ctr10000 ctr10000.shp

#verification:
ogrinfo -summary ctr10000/ctr10000.shp ctr10000
INFO: Open of `ctr10000/ctr10000.shp'
using driver `ESRI Shapefile' successful.

Layer name: ctr10000
Geometry: Polygon
Feature Count: 586
Extent: (1623653.000000, 4960499.000000) - (1824909.000000, 5178586.000000)
Layer SRS WKT:
PROJCS["Monte Mario (Rome) / Italy zone 2",
    GEOGCS["Monte Mario (Rome)",
        DATUM["Monte_Mario_Rome",
            SPHEROID["International 1924",6378388,297,
                AUTHORITY["EPSG","7022"]],
            AUTHORITY["EPSG","6806"]],
        PRIMEM["Rome",12.45233333333333,
            AUTHORITY["EPSG","8906"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AUTHORITY["EPSG","4806"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",15],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",2520000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","26592"]]
A_CODICE: Integer (6.0)
B_NOME: String (40.0)
AGG: Integer (4.0)
DITTA: String (40.0)
DXF: String (16.0)
RVE: String (16.0)
SHP: String (16.0)
ASC: String (16.0)
VECTOR_TYP: String (16.0)

# --> This looks ok.

########
#third test: convert fixed SHAPE to MapInfo:
cd ctr10000

#conversion of projected SHAPE to MapInfo:
ogr2ogr -f "MapInfo File" ctr10000 ctr10000.shp

ogrinfo -summary ctr10000/ctr10000.tab ctr10000
Had to open data source read-only.
INFO: Open of `ctr10000/ctr10000.tab'
using driver `MapInfo File' successful.

Layer name: ctr10000
Geometry: Polygon
Feature Count: 586
Extent: (1623653.010000, 4960498.995000) - (1824909.000000, 5178586.005000)
Layer SRS WKT:
PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563],
            TOWGS84[0,0,0,-0,-0,-0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",15],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",2520000],
    PARAMETER["false_northing",0],
    UNIT["Meter",1.0]]
A_CODICE: Integer (0.0)
B_NOME: String (40.0)
AGG: Integer (0.0)
DITTA: String (40.0)
DXF: String (16.0)
RVE: String (16.0)
SHP: String (16.0)
ASC: String (16.0)
VECTOR_TYP: String (16.0)

# --> damaged projection

Probably I am missing something.

Best regards

 Markus Neteler
#249 [OGR-GML] GML driver doesn't recognize GML files with 0 features default defect 12/18/02

The OGR/GML driver doesn't recognize files that contain 0 features. Everything goes well until GMLReader::PrescanForSchema?() gets called, it returns false since it doesn't find any feature class.

I guess this makes sense for datasets in general, but when we use the GML driver in the context of a WFS, receiving 0 features is a valid case.

It would be nice if OGR accepted to open GML file, and present it as a file with a single layer with 0 features in it.

What is an OGR driver expected to do if a file is empty? If nothing can be done at the OGR level for this then I guess I'll have to preparse the GML file before .

I try to open it with OGR, which is a bit of a waste of resources.

Any ideas, suggestions?

#498 GDAL 1.2.0a - Build problem w/ libtiff on AIX 4.3.3 default defect 02/20/04

Starting a new build og GDAL 1.2.0a on AIX 4.3.3 w/ GCC 3.3.2

I ran into the following error with the internal libtiff: 

make[3]: Entering directory `/home/src/gdal-1.2.0a/frmts/gtiff/libgeotiff'
/bin/sh ../../../libtool --mode=compile gcc -c -I../../../port -I../libtiff
-Wall  -O2     xtiff.c -o ../../o/xtiff.o
 gcc -c -I../../../port -I../libtiff -Wall -O2 xtiff.c  -DPIC -o
../../o/.libs/xtiff.o
In file included from ../libtiff/tiffio.h:33,
                 from xtiffio.h:11,
                 from xtiff.c:17:
../libtiff/tiff.h:75: warning: redefinition of `int8'
/usr/include/sys/inttypes.h:622: warning: `int8' previously declared here
../libtiff/tiff.h:80: warning: redefinition of `int16'
/usr/include/sys/inttypes.h:623: warning: `int16' previously declared here
../libtiff/tiff.h:86: error: conflicting types for `int32'
/usr/include/sys/inttypes.h:624: error: previous declaration of `int32'
make[3]: *** [../../o/xtiff.o] Error 1
make[3]: Leaving directory `/home/src/gdal-1.2.0a/frmts/gtiff/libgeotiff'
make[2]: *** [lib-geotiff] Error 2
make[2]: Leaving directory `/home/src/gdal-1.2.0a/frmts/gtiff'
make[1]: *** [gtiff-install-obj] Error 2
make[1]: Leaving directory `/home/src/gdal-1.2.0a/frmts'
make: *** [frmts-target] Error 2
#528 ESRI Shapefile long int attribute not handled properly OGR_SF defect 03/22/04 
I have a ESRI Shape file with long integers in a particular column in the
attribute file (dbf).  These are all converted to -2^31.  I can confirm this by
using ogr2ogr and converting the file to GML.  Opening the dbf file in MS Excel
shows the correct values, such as 10020001022000.
#529 OGCDatumName2EPSGDatumCode() shouldn't use libgeotiff GDAL_Raster defect 03/23/04 
Currently OGCDatumName2EPSGDatumCode() in gdal/frmts/gtiff/gt_wkt_srs.cpp
will use the libgeotiff versions of stuff like CSVReadParseLine() but it
shouldn't since it is using the gdal gdal_datum.csv.  This file might not
be found with the libgeotiff version of stuff.  Also, if libgeotiff is using
"incode" tables, no records can be read with the stub CSVReadParseLine() 
then available. 

Instead, this function should be moved into gdal/ogr/ogr_from_epsg.cpp (or
somewhere similar) and avoid including any libgeotiff related include files.
#558 WISH: PostgreSQL-Driver from OGR does not support views (yet) default defect 04/21/04

Dear developers,

It would be a nice feature also to use views with the PostgreSQL-Driver from OGR as it was recently implemented in the OCI-Driver (Bug #394) Thank you for this great peace of software.

Cheers

Stephan Holl

#575 Compile error on IRIX default defect 05/20/04 
In directory frmts/fit:

CC   -I../../port -I../../gcore -I../../ogr   -c -o fitdataset.o fitdataset.cpp
"gstEndian.h", line 50: error(3114): identifier "namespace" is undefined
  namespace gstEndian {
  ^

"gstEndian.h", line 50: error(3158): expected a ";"
  namespace gstEndian {
                      ^

"../../gcore/gdal_priv.h", line 179: warning(3109): parsing restarts here
          after previous syntax error
  class GDALMajorObject;
                       ^

"fitdataset.cpp", line 119: error(3114): identifier "using" is undefined
  using namespace gstEndian;
  ^

"fitdataset.cpp", line 119: error(3158): expected a ";"
  using namespace gstEndian;
                  ^
                  ^

"fitdataset.cpp", line 337: warning(3666): variable "p" was set but never used
      char *p;
            ^

4 errors detected in the compilation of "fitdataset.cpp".
make: *** [fitdataset.o] Error 1
#584 Imported Erdas (from a NITF colored dataset) can't be opened with 'ViewFinder' GDAL_Raster defect 06/03/04 
Using 'gdalcvs-20040603' gdal_translate.exe to create an erdas imagine file 
from a nitf file (http://dl.maptools.org/gdal/data/nitf/cadrg/001zc013.on1)), 
the generated file (test.img) can not be opened correctly using 'ERDAS 
ViewFinder'. 

Noureddine Farah
Ottawa, Canada
#615 infinite recursive call when GetNextFeature from a empty mitab file with a filter. OGR_SF defect 09/22/04 
I have a empty MapInfo TAB file, there is no feature in it.
When I use SetSpatialFilter set a filter for it, GetNextFeature output many
error message like this:

ERROR 3: InitBlockFromData(): Invalid Block Type: got 0 expected 2
ERROR 1: ReadBytes(): Attempt to read past end of data block.
ERROR 1: ReadBytes(): Attempt to read past end of data block.
ERROR 1: ReadBytes(): Attempt to read past end of data block.
...

There is an error in file ogr/ogrsf_frmts/mitab/mitab_mapfile.cpp, this is patch:

Index: ogr/ogrsf_frmts/mitab/mitab_mapfile.cpp
===================================================================
RCS file: /cvs/maptools/cvsroot/gdal/ogr/ogrsf_frmts/mitab/mitab_mapfile.cpp,v
retrieving revision 1.18
diff -u -r1.18 mitab_mapfile.cpp
--- ogr/ogrsf_frmts/mitab/mitab_mapfile.cpp     7 Jul 2004 20:54:55 -0000       1.18
+++ ogr/ogrsf_frmts/mitab/mitab_mapfile.cpp     22 Sep 2004 03:52:26 -0000
@@ -560,7 +560,7 @@
         CPLAssert( m_poSpIndex == NULL && m_poSpIndexLeaf == NULL );
 
         if( PushBlock( m_poHeader->m_nFirstIndexBlock ) == NULL )
-            return -1;
+            return FALSE;
 
         if( m_poSpIndex == NULL )
         {



This patch can avoid infinite recursion, but still an error message remained.
#652 configure.in does not detect the absence of libgif when libungif is present default defect 11/03/04 
configure.in does not detect the absence of libgif, although it detects the
presence of libungif.

Patch will be supplied soon.
#657 query on oraclespatial using OGR/OCI OGR_SF defect 11/04/04 
I'm working with mapserver, and I need to get query results on oraclespatial layers.
Using OGR connectiontype, and the oraclespatial tablename for Data, I'm not able
to get good results to a query.
The data returned doesn't correspond to what is expected. And no shape is
highlighted.

Following are some sql statements and a mapfile to reproduce the bug.

---------Mapserver version ---------
MapServer version 4.2.5 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUTPUT=SWF
SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT
SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT INPUT=EPPL7 INPUT=POSTGIS
INPUT=ORACLESPATIAL INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE

---------SQL statement--------------
DROP table mytable;

CREATE TABLE MYTABLE (
  GID VARCHAR(20),
  geometry MDSYS.SDO_GEOMETRY);

insert into MYTABLE (GID,GEOMETRY) values (
  '1',
  mdsys.sdo_geometry(
    '2003',
    null,
    null,
    mdsys.sdo_elem_info_array(1,1003,1),
    mdsys.sdo_ordinate_array(1,1, 1,4, 4,4, 4,1, 1,1))
);

insert into MYTABLE (GID,GEOMETRY) values (
  '2',
  mdsys.sdo_geometry(
    '2003',
    null,
    null,
    mdsys.sdo_elem_info_array(1,1003,1),
    mdsys.sdo_ordinate_array(6,1, 6,4, 9,4, 9,1, 6,1))
);

insert into MYTABLE (GID,GEOMETRY) values (
  '3',
  mdsys.sdo_geometry(
    '2003',
    null,
    null,
    mdsys.sdo_elem_info_array(1,1003,1),
    mdsys.sdo_ordinate_array(1,6, 1,9, 9,9, 9,6, 1,6))
);

delete from user_sdo_geom_metadata where table_name like 'MYTABLE';

insert into user_sdo_geom_metadata (table_name,column_name,diminfo,srid)
values ('MYTABLE','GEOMETRY',
mdsys.SDO_DIM_ARRAY(mdsys.SDO_DIM_ELEMENT('X', 0, 10, 0.1),
mdsys.SDO_DIM_ELEMENT('Y', 0, 10, 0.1)),
NULL);

drop index q_mytable;

create index Q_MYTABLE on MYTABLE(GEOMETRY) indextype is MDSYS.spatial_index;


---------mapfile---------------
NAME DEMO
STATUS ON
SIZE 500 300
EXTENT 0 0 10 10
IMAGECOLOR 255 255 255

WEB
  IMAGEPATH "/var/www/cartoserver_DGI_flash/www-data/images/"
  IMAGEURL "cartogfx/"
END

LAYER
  NAME squares
  TYPE POLYGON
  STATUS ON
#  CONNECTIONTYPE oraclespatial
#  CONNECTION "pierre/xbe9a51h@192.168.226.149:1521/orcl"
  CONNECTION "OCI:pierre/xbe9a51h@192.168.226.149:1521/orcl"
  CONNECTIONTYPE OGR
#  DATA "select * from mytable"
  DATA "mytable"
  TEMPLATE "ttt"
  CLASS
   SIZE 10
   COLOR 255 255 255
   OUTLINECOLOR 200 200 200
  END
END

END
#659 Oracle Loading DIM=2 with 3D geometries. OGR_SF defect 11/04/04 
1
2
3
4
5
6
7
8
9
10
11
12



red@seitzr > ogr2ogr.exe -f OCI OCI:userid/passwd@englink_staging -nln usbr_dams
-lco OVERWRITE=YES -lco DIM=2 -lco SRID=8307 damsgeo.shp
ERROR 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: internal error [ROWID:AAAPjuAAeAABNKiAAA] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13364: Layer Dimensionality does not match geometry dimensions
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
 in CREATE INDEX "USBR_DAMS_IDX" ON USBR_DAMS("ORA_GEOMETRY") INDEXTYPE IS
MDSYS.SPATIAL_INDEX

The problem seems to be that the layer type is forced to 2D by the DIM=2, but 
3D geometries are still produced.
#684 OGR SFS Specification and style of point features problem OGR_SF defect 11/24/04 
I have found the bug in MapInfo driver for OGR.

There is follow MIF file:

--top of MIF file
Version 300
Charset "WindowsCyrillic"
Delimiter ","
CoordSys Earth Projection 1, 0
Columns 2
  ID Integer
  Code Char(8)
Data

Point 36.145654 54.531409
    Symbol (45,0,10,"MapInfo Weather",0,0)
--end of MIF file

So, I have follow style string (by calling OGRFeature::getStyleString()):

SYMBOL(a:0,c:#000000,s:10pt,id:"mapinfo-sym-45.ogr-sym-8").

There is no information about font name in that style string. And there is no 
ability to get the information, so that information is lost!

 I have developed a patch (for OGR 1.2.3), which helps to get that
 information. But it's implemented only for MapInfo files. (MIF/MID and
TAB).
 And I tested it only for MapInfo files. But I think, that it does not have
 effect for other formats (bad effect, of course :)  ).
 I suggest, it is nesessary to change OGR Simple Feature Style Specification
 by adding new parameter in Symbol Tool parameter set. Parameter
 'font name' ("f").

Patch is attached.
#721 Shapefile has repeated fields, ogr2ogr bails on defining the second in postgis OGR_SF defect 12/19/04 
This file sucks and I don't expect ogr2ogr to handle buggy data, but it would 
be nice if it could handle this inconsistency rather than letting PostGIS halt 
the process.  Could ogr2ogr handle checking for problematic field names (i.e. 
duplicates) rather than leaving it up to PostGIS to complain? 
It'd be even greater if it could rename repeated attributes before getting 
that far.  Perhaps there is already an lco that I'm not aware of? 
 
> ogr2ogr -f "PostgreSQL" "PG:dbname=project1" pres_nov28.shp 
ERROR 1: ALTER TABLE "pres_nov28" ADD COLUMN "state_fips" CHAR(12) 
ERROR:  column "state_fips" of relation "pres_nov28" already exists 
 
ERROR 1: ALTER TABLE "pres_nov28" ADD COLUMN "cnty_fips" CHAR(13) 
ERROR:  column "cnty_fips" of relation "pres_nov28" already exists 
 
ERROR 1: INSERT command for new feature failed. 
ERROR:  new row for relation "pres_nov28" violates check constraint "$2" 
 
ERROR 1: Terminating translation prematurely after failed 
translation of layer pres_nov28
#772 HDF - Georeferencing for ASTER HDF_EOS products GDAL_Raster defect 02/15/05 
Some aster HDF EOS products lack any georef