[gdal-dev] OGR2OGR seem lost the field with primary key . ex
[OGR2OGR seem last ...]
aperi2007
aperi2007 at gmail.com
Sat Jan 21 05:32:08 EST 2012
Hi Even,
> I'm not sure why you see a difference of behaviour between the 2
>syntax.
> Perhaps it is due to the way the primary key has been defined. It
>might be that
> when given by layer name, OGR detects the primary key column, whereas >it
> doesn't when passed with -sql.
Yes,
but the issue is more complex.
In the first way (export all the schema) with this sintax:
ogr2ogr.exe --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS YES
-f "SQLite" prova.sqlite -progress PG:"dbname='test' active_schema=work
schemas=work host='local' port='5432' user='postgres'
password='postgres' " -overwrite -lco LAUNDER=yes -dsco SPATIALITE=yes
-lco SPATIAL_INDEX=yes -gt 65536
ogr2ogr probably is unable to understand what is the primary key, but
this don't explain why if the primary-key was defined on an alphanumeric
field, that field is correctly exported, and, instead, if the primary
key was defined on an integer field, that field is surely ignored and
don't exported.
If the issue was only "don't able to understand what is the PK" it
should lost the pk field also when it is defined on an alphanumeric field.
In the second way:
if I ask to export every single table each by each
using a sintax like this:
ogr2ogr.exe --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS YES
-f "SQLite" prova.sqlite -progress PG:"dbname='test' active_schema=work
schemas=work,public host='localhost' port='5432' user='postgres'
password='postgres' " -overwrite -lco GEOMETRY_NAME=geom -dsco
SPATIALITE=yes -lco SPATIAL_INDEX=yes -gt 65536 -sql "select * from
work.accesso"
All the filed are correctly exported indipendently if they are primary
key of integer type or primary key of alphanumeric type.
>Could you paste the schema of the >table ?
surely I can paste you a table schema however I tested it with many
table schema also this was tested with others Database .
It seem a systematic question.
I can give you this simple case test:
using this very simple script sql:
(the sintax is for the new postgis 2.0)
-------------------------------------------------
-------------------------------------------------
drop schema if exists testing cascade;
create schema testing;
create table testing.table1 (id integer primary key, field_2
varchar(10), field_3 integer, geometry geometry(Point,4326));
insert into testing.table1 (id, field_2, field_3,geometry)
values(1,'aaa',3, ST_GeomFromText('POINT(1 1)',4326));
create table testing.table2 (id varchar(10) primary key, field_2
varchar(10), field_3 integer, geometry geometry(Point,4326));
insert into testing.table2 (id, field_2, field_3,geometry)
values('1','aaa',3,ST_GeomFromText('POINT(1 1)',4326))
-------------------------------------------------
-------------------------------------------------
it will create a "testing" schema and populate it with two tables
(table1 and table2) and add to each a single record .
The first table has an integer pk, menawhile the second table has an
alphanumeric pk.
after this if I try lo export this schema in shapefile using:
ogr2ogr.exe -f "ESRI Shapefile" folder_name -progress PG:"dbname='test'
active_schema=testing schemas=testing host='localhost' port='5432'
user='user' password='pwd' " -overwrite
In a folder named "folder".
I can see the two shapefile where the table-1 shapefile has lost the
field "id" instead the table-2 shapefile has the id field (the table-2
has an alphanumeric id).
Regards,
Andrea.
Il 21/01/2012 10:13, Even Rouault ha scritto:
> Le dimanche 15 janvier 2012 15:20:32, aperi2007 a écrit :
>> > The integer primary column might be going into the sqlite datasource
>> >
>> >as
>> >
>> > the FID.
>>
>> Hi Chaitanya,
>>
>> unfortunatelly seem no.
>>
>> To have a more test I try to export from PG to shapefile.
>> I can confirm that the integer primary key field is lost in exportation.
>>
>> I notice also that this happened only if I ask to ogr2ogr to export to
>> shapefile a full schema.
>> Instead if I ask to ogr2ogr to export only one table using the -sql
>> "select * from table_test" , the primary key integer is correctly exported.
>
> I'm not sure why you see a difference of behaviour between the 2 syntax.
> Perhaps it is due to the way the primary key has been defined. It might be that
> when given by layer name, OGR detects the primary key column, whereas it
> doesn't when passed with -sql. Could you paste the schema of the table ?
>
> Otherwise, FID are special columns in OGR. If you want to preserve them with
> ogr2ogr, you need to add the -preserve_fid option in the ogr2ogr command line.
>
>>
>> Andrea.
>>
>> Il 14/01/2012 11:59, Chaitanya kumar CH ha scritto:
>>> Andrea,
>>>
>>> The integer primary column might be going into the sqlite datasource as
>>> the FID.
>>>
>>> On Sat, Jan 14, 2012 at 1:35 AM, aperi2007<aperi2007 at gmail.com
>>>
>>> <mailto:aperi2007 at gmail.com>> wrote:
>>> Hi,
>>>
>>> I notice that try-ing exporting from Postgres using ogr2ogr.exe
>>> It lost completely the primary key filed if that is a integer field.
>>> Instead it don't lost the same primary key field if it is a varchar
>>> type.
>>>
>>> Is a know bug this ?
>>>
>>> I'm use the gdal 1.9.
>>>
>>> I try exporting to a spatialite or to a shapefile.
>>> Both report the lost of the field PK.
>>>
>>> The sintax I'm using is this:
>>>
>>> ogr2ogr.exe --config PG_LIST_ALL_TABLES YES --config PG_SKIP_VIEWS
>>> YES -f "SQLite" prova.sqlite -progress PG:"dbname='test'
>>> active_schema=work schemas=work host='local' port='5432'
>>> user='postgres'
>>> password='postgres' " -overwrite -lco LAUNDER=yes -dsco
>>> SPATIALITE=yes -lco SPATIAL_INDEX=yes -gt 65536
>>>
>>> Thx,
>>>
>>> Andrea.
>>>
>>> _________________________________________________
>>> gdal-dev mailing list
>>> gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
>>> http://lists.osgeo.org/__mailman/listinfo/gdal-dev
>>> <http://lists.osgeo.org/mailman/listinfo/gdal-dev>
>>>
>>> --
>>> Best regards,
>>> Chaitanya kumar CH.
>>>
>>> +91-9494447584
>>> 17.2416N 80.1426E
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
More information about the gdal-dev
mailing list