[gdal-dev] Re: error compiling gdal with ArcSDE support
Hi list, Good news, I've fixed this issue by removing the libsde.so file from the ArcSDE libraries. But now I have another issue, this is the error I get: /home/sde/bin/sde100/sdeexe100//lib/libsde.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.c:(.text+0x0): multiple definition of `jpeg_CreateCompress' /home/tux/bin/gdal/gdal-1.8.1/frmts/o/.libs/jcapimin.o:/home/tux/bin/gdal/gdal-1.8.1/frmts/jpeg/libjpeg/jcapimin.c:31: first defined here Have any of you encountered this issue before? I'm already compiling with the --with-jpeg=internal option, but this didn't help. It looks like the libsde.a file contains these methods already, and want to join the jpeg-creation-game... Btw, this is not the only method that causes errors, but the other errors are similar. Thanks in advance, Wouter -- Wouter http://blog.giswhat.be On 15 September 2011 16:08, Wouter Schaubroeck wouter.schaubro...@gmail.com wrote: Hi list, I'm trying to compile gdal from source with added ArcSDE support, but it doesn't compile. I get this error: libsde.so: undefined reference to `pthread_atfork' My configure command looks like this: ./configure --with-sde=/home/sde/bin/sde100/sdeexe100/ --with-sde-version=100 --prefix=/home/tux/bin/gdal/app/ I'm compile on a fully patched and up to date OpenSuSE: Linux ospgsql 2.6.37.6-0.7-default #1 SMP 2011-07-21 02:17:24 +0200 x86_64 x86_64 x86_64 GNU/Linux Do any of you guys know what the problem is? I've already tried the following: - disabling the multi threads: --with-threads=no - specifically included the libpthread.so.0 in the LD_LIBRARY_PATH Thanks in advance, Wouter -- Wouter http://blog.giswhat.be ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Re: error compiling gdal with ArcSDE support
On Sep 21, 2011, at 7:30 AM, Wouter Schaubroeck wrote: Hi list, Good news, I've fixed this issue by removing the libsde.so file from the ArcSDE libraries. But now I have another issue, this is the error I get: /home/sde/bin/sde100/sdeexe100//lib/libsde.a(jcapimin.o): In function `jpeg_CreateCompress': jcapimin.c:(.text+0x0): multiple definition of `jpeg_CreateCompress' /home/tux/bin/gdal/gdal-1.8.1/frmts/o/.libs/jcapimin.o:/home/tux/bin/gdal/gdal-1.8.1/frmts/jpeg/libjpeg/jcapimin.c:31: first defined here Have any of you encountered this issue before? I'm already compiling with the --with-jpeg=internal option, but this didn't help. It looks like the libsde.a file contains these methods already, and want to join the jpeg-creation-game... Btw, this is not the only method that causes errors, but the other errors are similar. You'll have to link to an external jpeg library and then make sure that SDE SDK is first in the link line so its internal JPEG library symbols get used first. It is unfortunate that SDE is embedding JPEG (they used to embed an ancient and crackable zlib too) Do any of you guys know what the problem is? I've already tried the following: - disabling the multi threads: --with-threads=no - specifically included the libpthread.so.0 in the LD_LIBRARY_PATH libsde.so wants pthread, so you'll probably have to have --with-threads=yes Additionally, you might try adding -pthread to the GDALMake.opt line that adds -lpthread. Sometimes compilers treat this special. I don't know that removing libsde.so fixed the issue. This file has symbols that are definitely needed for things to run. Good luck, Howard ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] 2D KML to 3D KML
Hi all, I've got some 2D KML generated by gdal_polygonize I'd like to turn into 3D KML. Do you have any ogr2ogr techniques to do this? A snip of my 2D KML: -- Placemark name1/name StyleLineStylecolorffff/color/LineStylePolyStylefill0/fill/PolyStyle/Style ExtendedDataSchemaData schemaUrl=#out SimpleData name=Name1/SimpleData /SchemaData/ExtendedData PolygonouterBoundaryIsLinearRingcoordinates106.2125,-6.0 106.2125,-6.01 106.225,-6.01 106.225,-6.02 106.2375,-6.02 106.2375,-6.03 106.25,-6.03 106.25,-6.0 106.2125,-6.0/coordinates/LinearRing/outerBoundaryIs/Polygon /Placemark -- And the desired 3D KML: Placemark name1/name StyleLineStylecolorffff/color/LineStylePolyStylefill1/fillcolorffff/color/PolyStyle/Style ExtendedDataSchemaData schemaUrl=#out SimpleData name=Name1/SimpleData /SchemaData/ExtendedData Polygon outerBoundaryIsLinearRingcoordinates106.2125,-6.0,101 106.2125,-6.01,101 106.225,-6.01,101 106.225,-6.02,101 106.2375,-6.02,101 106.2375,-6.03,101 106.25,-6.03,101 106.25,-6.0,101 106.2125,-6.0,101 /coordinates/LinearRing/outerBoundaryIs/Polygon /Placemark -- I've added a z to the coordinates (100 plus the name value, to boost it above the terrain), plus a little bit of PolyStyle info to set the fill color. The long term solution may be to enhance gdal_polygonize to output 3D vectors, but right now I'm just experimenting with visualizing KML in Google Earth -- Best Regards, Brent Fraser ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OGR SQL implicit conversions
Hi Devs,
We have some problems due to the recent changes in the SQL expression parser
which is related to the change in the implicit type conversion behaviour.
Formerly we could safely use the following statement:
select * from mytable where ogr_fid in ('1100','1101','1102')
If the data type of ogr_fid is an integer or float then the expression
evaluator has converted the string constants to numeric values implicitly.
As of 1.8 the parser reports an error due to the incompatible types in the
expression.
I've added a ticket #4259 http://trac.osgeo.org/gdal/ticket/4259 related
to this problem including a patch to handle these string to numeric
conversions.
However I'm a bit uncertain whether some other conversions should also be
supported or not. Having a larger number of conversion rules we might
probably think about rewriting the current approach by using a more generic
implementation.
Any ideas?
Best regards,
Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Problems with OGROpen, OCI Driver (OGROCITableLayer::ReadTableDefinition) and Oracle Views in GDAL 1.8.1
All,
I've run into some very serious problems (for me) with changes made to
the OCI driver for 1.8.1. Specifically lines the following lines
(270-274).
oDimCmd.Append( SELECT a. );
oDimCmd.Append( pszGeomName );
oDimCmd.Append( .GET_DIMS() DIM FROM );
oDimCmd.Append( pszTableName );
oDimCmd.Append( a WHERE ROWNUM = 1 );
Our schema has many large tables and several views which use these
tables. The views are referenced in all_sdo_geom_metadata. When the
query select a.geometry.get_dims() dim from the_view a where rownum
= 1 is run it results in FULL Table accesses. This has result in
running sorted queries on very large tables and I managed to blow out
the temp table space on our oracle instance just calling OGROpen. To say
the least our DBA's are not happy with me.
I'm considering changing :
oDimCmd.Append( SELECT a. );
oDimCmd.Append( pszGeomName );
oDimCmd.Append( .GET_DIMS() DIM FROM );
oDimCmd.Append( pszTableName );
oDimCmd.Append( a WHERE ROWNUM = 1 );
to:
oDimCmd.Append( SELECT COUNT(t.SDO_DIMNAME) DIM FROM
ALL_SDO_GEOM_METADATA A, TABLE(A.DIMINFO) T WHERE a.TABLE_HAME=' );
oDimCmd.Append( pszTableName );
oDimCmd.Append( ' );
The following code was not in 1.7.2.
ogrocitablelayer.cpp Lines 259-316
/*
*/
/* Identify Geometry dimension
*/
/*
*/
if( pszGeomName != NULL strlen(pszGeomName) 0 )
{
OGROCIStringBuf oDimCmd;
OGROCIStatement oDimStatement( poSession );
char **papszResult;
int iDim = -1;
oDimCmd.Append( SELECT a. );
oDimCmd.Append( pszGeomName );
oDimCmd.Append( .GET_DIMS() DIM FROM );
oDimCmd.Append( pszTableName );
oDimCmd.Append( a WHERE ROWNUM = 1 );
oDimStatement.Execute( oDimCmd.GetString() );
papszResult = oDimStatement.SimpleFetchRow();
if( CSLCount(papszResult) 1 )
{
OGROCIStringBuf oDimCmd2;
OGROCIStatement oDimStatement2( poSession );
char **papszResult2;
oDimCmd2.Appendf( 1024,
select m.sdo_index_dims\n
from all_sdo_index_metadata m, all_sdo_index_info
i\n
where i.index_name = m.sdo_index_name\n
and i.sdo_index_owner = m.sdo_index_owner\n
and i.table_name = upper('%s'),
pszTableName );
oDimStatement2.Execute( oDimCmd2.GetString() );
papszResult2 = oDimStatement2.SimpleFetchRow();
if( CSLCount( papszResult2 ) 0 )
{
iDim = atoi( papszResult2[0] );
}
}
else
{
iDim = atoi( papszResult[0] );
}
if( iDim 0 )
{
SetDimension( iDim );
}
else
{
CPLDebug( OCI, get dim based of existing data or index
failed. );
}
}
This electronic communication and any attachments may contain confidential and
proprietary
information of DigitalGlobe, Inc. If you are not the intended recipient, or an
agent or employee
responsible for delivering this communication to the intended recipient, or if
you have received
this communication in error, please do not print, copy, retransmit, disseminate
or
otherwise use the information. Please indicate to the sender that you have
received this
communication in error, and delete the copy you received. DigitalGlobe reserves
the
right to monitor any electronic communication sent or received by its
employees, agents
or representatives.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Problems with OGROpen, OCI Driver (OGROCITableLayer::ReadTableDefinition) and Oracle Views in GDAL 1.8.1
Ethan,
That code has changed a little bit since last time I saw it on
http://trac.osgeo.org/gdal/ticket/3025 but I can take a look on that for
you and commit with your suggestion if that works well.
Regards,
Ivan
---Original Message---
From: Ethan Alpert
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Problems with OGROpen, OCI Driver
(OGROCITableLayer::ReadTableDefinition) and Oracle Views in GDAL 1.8.1
Sent: Sep 21 '11 13:48
All,
Ive run into some very serious problems (for me) with changes made to the
OCI driver for 1.8.1. Specifically lines the following lines (270-274).
oDimCmd.Append( SELECT a. );
oDimCmd.Append( pszGeomName );
oDimCmd.Append( .GET_DIMS() DIM FROM );
oDimCmd.Append( pszTableName );
oDimCmd.Append( a WHERE ROWNUM = 1 );
Our schema has many large tables and several views which use these tables.
The views are referenced in all_sdo_geom_metadata. When the query select
a.geometry.get_dims() dim from a where rownum = 1 is run it results in
FULL Table accesses. This has result in running sorted queries on very
large tables and I managed to blow out the temp table space on our oracle
instance just calling OGROpen. To say the least our DBAs are not happy
with me.
Im considering changing :
oDimCmd.Append( SELECT a. );
oDimCmd.Append( pszGeomName );
oDimCmd.Append( .GET_DIMS() DIM FROM );
oDimCmd.Append( pszTableName );
oDimCmd.Append( a WHERE ROWNUM = 1 );
to:
oDimCmd.Append( SELECT COUNT(t.SDO_DIMNAME) DIM FROM
ALL_SDO_GEOM_METADATA A, TABLE(A.DIMINFO) T WHERE a.TABLE_HAME= );
oDimCmd.Append( pszTableName );
oDimCmd.Append( );
The following code was not in 1.7.2.
ogrocitablelayer.cpp Lines 259-316
/*
*/
/* Identify Geometry dimension
*/
/*
*/
if( pszGeomName != NULL strlen(pszGeomName) 0 )
{
OGROCIStringBuf oDimCmd;
OGROCIStatement oDimStatement( poSession );
char **papszResult;
int iDim = -1;
ODIMCMD.APPEND( QUOT;SELECT A.QUOT; );
ODIMCMD.APPEND( PSZGEOMNAME );
ODIMCMD.APPEND( QUOT;.GET_DIMS() DIM FROM QUOT; );
ODIMCMD.APPEND( PSZTABLENAME );
ODIMCMD.APPEND( QUOT; A WHERE ROWNUM = 1QUOT; );
oDimStatement.Execute( oDimCmd.GetString() );
papszResult = oDimStatement.SimpleFetchRow();
if( CSLCount(papszResult) 1 )
{
OGROCIStringBuf oDimCmd2;
OGROCIStatement oDimStatement2( poSession );
char **papszResult2;
oDimCmd2.Appendf( 1024,
select m.sdo_index_dims\n
from all_sdo_index_metadata m, all_sdo_index_info i\n
where i.index_name = m.sdo_index_name\n
and i.sdo_index_owner = m.sdo_index_owner\n
and i.table_name = upper('%s'),
pszTableName );
oDimStatement2.Execute( oDimCmd2.GetString() );
papszResult2 = oDimStatement2.SimpleFetchRow();
if( CSLCount( papszResult2 ) 0 )
{
iDim = atoi( papszResult2[0] );
}
}
else
{
iDim = atoi( papszResult[0] );
}
if( iDim 0 )
{
SetDimension( iDim );
}
else
{
CPLDebug( OCI, get dim based of existing data or index
failed. );
}
}
This electronic communication and any attachments may contain confidential
and proprietary information of DigitalGlobe, Inc. If you are not the
intended recipient, or an agent or employee responsible for delivering
this communication to the intended recipient, or if you have received
this communication in error, please do not print, copy, retransmit,
disseminate or otherwise use the information. Please indicate to the
sender that you have received this communication in error, and delete the
copy you received. DigitalGlobe reserves the right to monitor any
electronic communication sent or received by its employees, agents or
representatives.
___
gdal-dev mailing list
[LINK: compose.php?to=gdal-dev@lists.osgeo.org] gdal-dev@lists.osgeo.org
[LINK: http://lists.osgeo.org/mailman/listinfo/gdal-dev]
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] libjpeg-turbo for gdal?
Hi Folks, I had seen libjpeg-turbo , http://www.libjpeg-turbo.org/Main/HomePage, in the announcement for Fedora 14 bu had forgotten about it until Franks' FOSS4G talk last week. Has anyone tried using it in GDAL? Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats.___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libjpeg-turbo for gdal?
On 21/09/11 21:46, doug_newc...@fws.gov wrote: I had seen libjpeg-turbo , Has anyone tried using it in GDAL? http://www.gdal.org/frmt_jpeg.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] Set color table in NITF
I am revisiting this because I discovered some of my code that I thought was
correct is not actually setting a colortable in my NITF.
dataBand = sicdDS-GetRasterBand(1);
GDALColorTable colorTable(GPI_RGB);
int index;
for (int red = 0 ; red 256; red += 51)
{
for (int green = 0 ; green 256 ; green += 51)
{
for (int blue = 0 ; blue 256 ; blue += 51)
{
GDALColorEntry gce;
gce.c1 = red;
gce.c2 = green;
gce.c3 = blue;
colorTable.SetColorEntry(index, gce);
index++;
}
}
}
while (index 256)
{
GDALColorEntry gce;
gce.c1 = 255;
gce.c2 = 255;
gce.c3 = 255;
colorTable.SetColorEntry(index, gce);
index++;
}
dataBand-SetColorTable(colorTable)
The above does NOT set the colortable of the image as expected, and when I do a
gdalinfo on the image, the lookup table values look like defaults (256 colors,
1..256 sequentially)
Can you see somethign wrong with the code above as to why it is not setting it?
Further down in that code I use dataBand to do some RasterIO operations that
seem to be taking, but its just not letting me modify the lookup table.
Thanks
From: Even Rouault [even.roua...@mines-paris.org]
Sent: Monday, August 29, 2011 6:29 PM
To: gdal-dev@lists.osgeo.org
Cc: Cole, Derek
Subject: Re: [gdal-dev] Set color table in NITF
Le mardi 30 août 2011 00:14:12, Cole, Derek a écrit :
Hello,
I am trying to create a NITF that uses a color lookup table.
I found the option to add an RGB/LUT to the image, which didnt complain,
however, when I had my LUT data to the image, it all seems to be kind of
black and white.
I know when I was displaying the images in my viewer (which I wrote in Qt),
I had a function to create a 256 element color table, that changed some of
the values. How would I modify the color table in the NITF?
Use SetColorTable() on the raster band object.
Python example :
from osgeo import gdal
ds = gdal.GetDriverByName('NITF').Create('test.ntf', 1, 1, options =
['IREP=RGB/LUT', 'LUT_SIZE=3'])
ct = gdal.ColorTable()
ct.SetColorEntry( 0, (0,0,0) )
ct.SetColorEntry( 1, (10,10,10) )
ct.SetColorEntry( 2, (20, 20, 20))
ds.GetRasterBand(1).SetColorTable(ct)
ds = None
$ gdalinfo test.ntf
Driver: NITF/National Imagery Transmission Format
Files: test.ntf
Size is 1, 1
[...]
Band 1 Block=1x1 Type=Byte, ColorInterp=Palette
NoData Value=3
Color Table (RGB with 4 entries)
0: 0,0,0,255
1: 10,10,10,255
2: 20,20,20,255
3: 0,0,0,0
Thanks
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] libjpeg-turbo for gdal?
I am curios to see the supercharged version :) --Nikos On Wed, Sep 21, 2011 at 3:08 PM, Mateusz Loskot mate...@loskot.net wrote: On 21/09/11 21:46, doug_newc...@fws.gov wrote: I had seen libjpeg-turbo , Has anyone tried using it in GDAL? http://www.gdal.org/frmt_jpeg.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ 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] libjpeg-turbo for gdal?
Thanks! Sorry for the noise. Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior. Life is too short for undocumented, proprietary data formats. -gdal-dev-boun...@lists.osgeo.org wrote: - To: doug_newc...@fws.gov From: Mateusz Loskot mate...@loskot.net Sent by: gdal-dev-boun...@lists.osgeo.org Date: 09/21/2011 06:08PM cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] libjpeg-turbo for gdal? On 21/09/11 21:46, doug_newc...@fws.gov wrote: I had seen libjpeg-turbo , Has anyone tried using it in GDAL? http://www.gdal.org/frmt_jpeg.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org ___ 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
