Re: [gdal-dev] C++ interface to lists of coordinate systems in data dir ?

[Lucena, Ivan]

Hi Alexandre,

Yes, that is an interesting idea. You can actually read the CSV files as OGR 
data source:

% ogrinfo gcs.csv -al | more
INFO: Open of `gcs.csv'
  using driver `CSV' successful.

Layer name: gcs
Geometry: None
Feature Count: 438
Layer SRS WKT:
(unknown)
COORD_REF_SYS_CODE: String (0.0)
COORD_REF_SYS_NAME: String (0.0)
DATUM_CODE: String (0.0)
DATUM_NAME: String (0.0)
GREENWICH_DATUM: String (0.0)
UOM_CODE: String (0.0)
ELLIPSOID_CODE: String (0.0)
PRIME_MERIDIAN_CODE: String (0.0)
SHOW_CRS: String (0.0)
DEPRECATED: String (0.0)
COORD_SYS_CODE: String (0.0)
COORD_OP_CODE: String (0.0)
COORD_OP_CODE_MULTI: String (0.0)
COORD_OP_METHOD_CODE: String (0.0)
DX: String (0.0)
DY: String (0.0)
DZ: String (0.0)
RX: String (0.0)
RY: String (0.0)
RZ: String (0.0)
DS: String (0.0)
OGRFeature(gcs):1
  COORD_REF_SYS_CODE (String) = 3819
  COORD_REF_SYS_NAME (String) = HD1909
  DATUM_CODE (String) = 1024
  DATUM_NAME (String) = Hungarian Datum 1909
  GREENWICH_DATUM (String) = 1024
  UOM_CODE (String) = 9122
  ELLIPSOID_CODE (String) = 7004
  PRIME_MERIDIAN_CODE (String) = 8901
  SHOW_CRS (String) = 1
  DEPRECATED (String) = 0
  COORD_SYS_CODE (String) = 6422
  COORD_OP_CODE (String) = 3817
  COORD_OP_CODE_MULTI (String) = 0
...

So Anders's application could browse those file using the GDAL/OGR C API and fill up his GUI. And 
that could be done in other wrappers too. Great.


Ivan

Alexandre Gacon wrote:
The OGR CSV support is a supported driver and I think it will work 
better than the built-in GDAL support (but perhaps it the same think).


Alexandre

On Tue, Sep 7, 2010 at 8:58 PM, Ivan Lucena > wrote:


 >  On Sep 7, 2010, at 8:59 AM, Anders Moe wrote:
 >
 >  >
 >  > Hi everyone
 >  >
 >  > Creating a C++ enduser app I was wondering if there is a
programmatic way to read the various datums/projections etc. files
in the gdal data directory ? I would like to present these in the
interface if the user is to perform conversion, etc.
 >
 >  Anders,
 >
 >  There's no interfaces as far as I know.  People usually consume
the files in the GDAL_DATA directory using their favorite text
manipulation methods

That is right, you can also the GDAL own CSV support:

http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_csv.cpp

Example of use are everywhere in the code, like here:


http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/idrisi/IdrisiDataset.cpp#L2301

I believe that CPL_CSV is not exposed on the GDAL API but it is
available for C  and C++ coders.

Regards,

Ivan

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org 
http://lists.osgeo.org/mailman/listinfo/gdal-dev




--
Alexandre Gacon


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGR: Get FID of last set feat in PG

[Even Rouault]

Tom,

yes you need to call  ReleaseResultSet after every ExecuteSQL, otherwise 
you'll have memory leaks

Ideally you should have been able to call GetFID() after CreateFeature(), but 
this is currently not implemented in the postgresql driver.

I have a patch to solve the issue, but it raises some potential backward 
compatibility issue, so I'd like hearing from other people before applying.

Patch and potential issues discussed here : 
http://trac.osgeo.org/gdal/ticket/3744

Best regards,

Even

Le mercredi 08 septembre 2010 17:36:30, Tom van der Putte a écrit :
>  In reply to my own question, I've created something that works:
>  Layer tempLayer = ds2.ExecuteSQL("SELECT
> currval(pg_get_serial_sequence('wells', 'well_id')) as seqval;", null,
> null);
>  Feature seqFeat = tempLayer.GetNextFeature(); //always only 1 row in
> the resultset, so no *while*
>  tempFID = seqFeat.GetFieldAsInteger("seqval");
>  ds2.ReleaseResultSet(tempLayer);
>  Is it necessary to call ReleaseResultSet after every ExecuteSQL? Or
> only after the last one?
>  Cheers,
>  Tom
>  On Wed 08/09/10 16:03 , Tom van der Putte t...@vdputte.nl sent:
>   Hi All,
>  I'm adding several new features to a PostGIS table using OGR (in
> C#). After each CreateFeature I'd like to somehow get the FID of the
> created feature. Is there any possible way to do this? If not elegant,
> any hack is also welcome :D
>  Cheers,
>  Tom
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

RE: [gdal-dev] OGR OVF has no identified FID column

[David Lowther]

Brent, 

Finally got back to this today. I upgraded my GDAL to version 1.7.1. The
only thing I notice that is different is that I get:

OGR: OGRGeometryFactory::createFromWkb() - got corrupt data.

That gave me a hint. I added a WKT column to the MS SQL Server table and
calculated it to the STAsText of the Feature column. Then I modified the ovf
file to look for WKT in the WKT column. Still no FID, but the point data ogr
sees is what I expect:

Layer name: PointData
Geometry: Unknown (any)
OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
Feature Count: 1
OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
Layer SRS WKT:
(unknown)
PKey: Integer (10.0)
Feature: Binary (0.0)
WKT: String (0.0)
OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
OGRFeature(PointData):3
  PKey (Integer) = 3
  Feature (Binary) = BC08010C59405940
  WKT (String) = POINT (100 100)
  POINT (100 100)


Thanks again for your help.

David Lowther
 
Coordinate Solutions, Inc.
 

-Original Message-
From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
Sent: Friday, August 20, 2010 10:16 AM
To: David Lowther
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] OGR OVF has no identified FID column

David,

   GDAL:   POINT (0.0 2.0021871)
   SQL Server: POINT (150 150)

   That IS strange!  There could be a problem with GDAL's or SQL Server's 
encoding/decoding of WKB, or it could be related to data type (geometry? 
geography?) or the lack of a Spatial Reference System?

Best Regards,
Brent Fraser

David Lowther wrote:
> D:\Utility\ms4w\tools\gdal-ogr>ogrinfo test.ovf  PointData --debug on
> ERROR 4: Update access not supported for VRT datasources.
> OGR_ODBC: EstablishSession(DSN:"CLO", userid:"un", password:"pw")
> ODBC: SQLConnect(CLO)
> OGR_ODBC: Table PointData has no identified FID column.
> OGR: OGROpen(ODBC:un/p...@clo,PointData/00FB9BB0) succeeded as ODBC.
> OGR: OGROpen(test.ovf/010870B8) succeeded as VRT.
> Had to open data source read-only.
> INFO: Open of `test.ovf'
>   using driver `VRT' successful.
> OGR: GetLayerCount() = 1
> 
> 
> Layer name: PointData
> Geometry: Unknown (any)
> OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
> Feature Count: 1
> OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
> Extent: (0.00, 2.00) - (0.00, 2.00)
> Layer SRS WKT:
> (unknown)
> PKey: Integer (10.0)
> Feature: Binary (0.0)
> OGR_ODBC: ExecuteSQL(SELECT * FROM PointData)
> OGRFeature(PointData):1
>   PKey (Integer) = 1
>   Feature (Binary) = 010C00C0624000C06240
>   POINT (0.0 2.0021871)
> 
> VRT: 2 features read on layer 'PointData'.
> OGR_ODBC: 3 features read on layer 'PointData'.
> ODBC: SQLDisconnect()
> 
> 
> 
> 
> And, why do you think it is saying 0.0 2.00... for the point when the
> SQL query says?
> 
> 1 0x010C00C0624000C06240  POINT (150 150)
> 
> 
> 
> David Lowther
>  
> Coordinate Solutions, Inc.
>  
> 
> -Original Message-
> From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
> Sent: Thursday, August 19, 2010 5:21 PM
> To: David Lowther
> Cc: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] OGR OVF has no identified FID column
> 
> I think it's faster since it doesn't have to enumerate all the
tables,views,
> etc.
> 
> so how do you get for attributes names when you do a
> 
> ogrinfo test.ovf  PointData --debug on
> 
> Brent
> 
> David Lowther wrote:
>> Still doesn't see the FID but is way faster! 
>>
>> 
>>  
>>   ODBC:un/p...@clo,PointData
>>   
>>   PKey
>>  
>> 
>>
>> ogrinfo test.ovf --debug on
>>
>> ERROR 4: Update access not supported for VRT datasources.
>> OGR_ODBC: EstablishSession(DSN:"CLO", userid:"un", password:"pw")
>> ODBC: SQLConnect(CLO)
>> OGR_ODBC: Table PointData has no identified FID column.
>> OGR: OGROpen(ODBC:un/p...@clo,PointData/02799B88) succeeded as ODBC.
>> OGR: OGROpen(test.ovf/010270B8) succeeded as VRT.
>> Had to open data source read-only.
>> INFO: Open of `test.ovf'
>>   using driver `VRT' successful.
>> OGR: GetLayerCount() = 1
>>
>> 1: PointData
>> ODBC: SQLDisconnect()
>>
>>
>>
>> Does the datatype of the FID column matter? I have it as an int, does it
>> need to be guid?
>>
>> David Lowther
>>  
>> Coordinate Solutions, Inc.
>>  
>>
>> -Original Message-
>> From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
>> Sent: Thursday, August 19, 2010 3:49 PM
>> To: David Lowther
>> Cc: gdal-dev@lists.osgeo.org
>> Subject: Re: [gdal-dev] OGR OVF has no identified FID column
>>
>> Yeah I saw that after I sent the message.  Take out the  , it's
>> really 
>> only useful if want to do "special" things, and it can kill spatial
> indexing
>> on 
>> ODBC datasources.  Does this work any better:
>>
>> 
>>  
>>   ODBC:un/p...@clo,PointData
>>   
>>   PKey
>>  
>> 
>>
>>
>> Brent
>>
>> David Lowther wrote:
>>> Brent,
>>>
>>> Thanks for the reply. On initial read I thought you had found my issue -
>>> that I was

Re: [gdal-dev] C++ interface to lists of coordinate systems in data dir ?

[Alexandre Gacon]

The OGR CSV support is a supported driver and I think it will work better
than the built-in GDAL support (but perhaps it the same think).

Alexandre

On Tue, Sep 7, 2010 at 8:58 PM, Ivan Lucena  wrote:

> >  On Sep 7, 2010, at 8:59 AM, Anders Moe wrote:
> >
> >  >
> >  > Hi everyone
> >  >
> >  > Creating a C++ enduser app I was wondering if there is a programmatic
> way to read the various datums/projections etc. files in the gdal data
> directory ? I would like to present these in the interface if the user is to
> perform conversion, etc.
> >
> >  Anders,
> >
> >  There's no interfaces as far as I know.  People usually consume the
> files in the GDAL_DATA directory using their favorite text manipulation
> methods
>
> That is right, you can also the GDAL own CSV support:
>
> http://trac.osgeo.org/gdal/browser/trunk/gdal/port/cpl_csv.cpp
>
> Example of use are everywhere in the code, like here:
>
>
> http://trac.osgeo.org/gdal/browser/trunk/gdal/frmts/idrisi/IdrisiDataset.cpp#L2301
>
> I believe that CPL_CSV is not exposed on the GDAL API but it is available
> for C  and C++ coders.
>
> Regards,
>
> Ivan
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Alexandre Gacon
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Re: cut a .dem file

[Joaquim Luis]

On 08-09-2010 16:38, Carmelo Terrasi wrote:

Yes, you're right, if I need a portion I have to use that utility.
Thank you so much Hermann,
regards,
Carmelo


Not so simple.
The problem will be that your bmp image is not referenced but the DEM 
is, so you'll need to find the correspondence between the (row,column) 
coordinates of the bmp image and the (x,y) coords of the model. That 
means referencing the image (bmp) to the grid (dem).


Joaquim




2010/9/8 Hermann Peifer mailto:pei...@gmx.eu>>

On 08/09/2010 15:26, Carmelo Terrasi wrote:

Hello everybody,

does anybody know how to cut a smaller dem file from another
one???
I have my original file /terrain.dem /but my /image.bmp/ is
smaller so I
would cut a portion just to create another suitable dem file
for my
/image.bmp/
Is it possible to do it or am I off-board?


Look at the -srcwin and -projwin options at
http://gdal.org/gdal_translate.html

Hermann



___
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] Re: cut a .dem file

[Carmelo Terrasi]

Yes, you're right, if I need a portion I have to use that utility.
Thank you so much Hermann,
regards,
Carmelo

2010/9/8 Hermann Peifer 

> On 08/09/2010 15:26, Carmelo Terrasi wrote:
>
>> Hello everybody,
>>
>> does anybody know how to cut a smaller dem file from another one???
>> I have my original file /terrain.dem /but my /image.bmp/ is smaller so I
>> would cut a portion just to create another suitable dem file for my
>> /image.bmp/
>> Is it possible to do it or am I off-board?
>>
>>
> Look at the -srcwin and -projwin options at
> http://gdal.org/gdal_translate.html
>
> Hermann
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGR: Get FID of last set feat in PG

[Tom van der Putte]

 In reply to my own question, I've created something that works:
 Layer tempLayer = ds2.ExecuteSQL("SELECT
currval(pg_get_serial_sequence('wells', 'well_id')) as seqval;", null,
null);
 Feature seqFeat = tempLayer.GetNextFeature(); //always only 1 row in
the resultset, so no *while*
 tempFID = seqFeat.GetFieldAsInteger("seqval");
 ds2.ReleaseResultSet(tempLayer);
 Is it necessary to call ReleaseResultSet after every ExecuteSQL? Or
only after the last one?
 Cheers,
 Tom
 On Wed 08/09/10 16:03 , Tom van der Putte t...@vdputte.nl sent:
  Hi All,
 I'm adding several new features to a PostGIS table using OGR (in
C#). After each CreateFeature I'd like to somehow get the FID of the
created feature. Is there any possible way to do this? If not elegant,
any hack is also welcome :D
 Cheers,
 Tom
  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] OGR: Get FID of last set feat in PG

[Tom van der Putte]

Hi
All,
 I'm adding several new features to a PostGIS table using OGR (in
C#). After each CreateFeature I'd like to somehow get the FID of the
created feature. Is there any possible way to do this? If not elegant,
any hack is also welcome :D
 Cheers,
 Tom
  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re: cut a .dem file

[Hermann Peifer]

On 08/09/2010 15:26, Carmelo Terrasi wrote:

Hello everybody,

does anybody know how to cut a smaller dem file from another one???
I have my original file /terrain.dem /but my /image.bmp/ is smaller so I
would cut a portion just to create another suitable dem file for my
/image.bmp/
Is it possible to do it or am I off-board?



Look at the -srcwin and -projwin options at 
http://gdal.org/gdal_translate.html


Hermann
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] cut a .dem file

[Carmelo Terrasi]

Hello everybody,

does anybody know how to cut a smaller dem file from another one???
I have my original file *terrain.dem *but my *image.bmp* is smaller so I
would cut a portion just to create another suitable dem file for my *
image.bmp*
Is it possible to do it or am I off-board?

Thanks in advance,
Regards,
Carmelo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev