[postgis-users] Copy geometry from one table to another with insert statement fails]
Milo van der Linden
mlinden at zeelandnet.nl
Sat Jul 21 02:26:04 PDT 2007
Hello!
Kevin, you are growing to be my personal hero. I am getting a good
understanding here. I used to work with Spatialware from MapInfo a lot,
so I know the matter well. I had figured out that the geometry_columns
table would be something like mapinfo's mapcatalog.
I would love to write an article on the proces I now go to for the
official user documentation once I feel I controle the proces. The
article would be called something like:
"How to - copy spatial tables with options in postGIS"
Kevin Neufeld schreef:
> Ah, ok. Getting a clearer picture.
>
> It looks like your production table is currently empty which is why it
> returned nothing.
That is right!
>
> In response to your comment regarding the geometry_columns table...
>
> PostGIS is an add-on to PostgreSQL that simply adds a few new
> datatypes (ie. geometry, box3d), a few functions (ie. intersects(...),
> distance(...)) and a couple of tables (geometry_columns and
> spatial_ref_sys) to a database instance.
>
> In postgres, it's entirely possible to simply create a table with a
> geometry column by simply typing:
> CREATE TABLE public.tmp (id integer, the_geom geometry);
>
> However, creating a table this way would permit someone to insert
> geometries of varying types (ie. POINT, LINESTRING,...), of varying
> dimensions (2, 3 or 4D), and of varying projections (different SRIDs).
> What would be ideal is to add constraints to your table that would
> ensure that geometries are of the same type.
>
> One of the many functions added by PostGIS is addgeometrycolumn(...).
> Use this function whenever you want to add a geometry column to a
> table. So our previous example would be:
> CREATE TABLE public.tmp (id integer);
> SELECT addgeometrycolumn('public','tmp','the_geom',4326,'LINESTRING',2);
That is clear! Thank you, I will drop my hand made tables and recreate
them in this manner. It seems that OGR does it correct during import, so
the staging table can remain as is.
>
> This function simply adds a column called 'the_geom' of type
> 'geometry' to the public.tmp table, adds three constraints to the
> table (/enforce_dims_the_geom, enforce_geotype_the_geom, /and
> /enforce_srid_the_geom/), and inserts a row into the geometry_colums
> table.
> This ensures that the public.tmp table will only have geometries of
> type 'LINESTRING', are of 2 dimensions, and have an SRID of 4326.
Perfect!
>
> See (http://postgis.refractions.net/docs/ch06.html#id2997535)
>
> Whenever you drop a table, you must first use the
> dropgeometrycolumn(...) function that will automatically remove the
> necessary row from the geometry_columns table and drop the geometry
> column. Then you can drop the table.
That's clear and that was a function I was looking for. I will check if
it has been discussed to create a trigger for this, because I think that
would make life a bit easier.
>
> If you drop a table without calling dropgeometrycolumn first, you will
> have to manually delete the corresponding row in the geometry_columns
> table. Not a big deal, but a pain.
clear
>
> There is nothing special at all about the geometry_columns table. It's
> just a simple table that stores metadata about the tables with
> geometry columns in the database, and as you've already discovered,
> it's easy to get out of date. It's really only there to be OGC
> compliant. Some applications, like mapserver, use this table to
> quickly find all the registered geometry columns in a database ...
> although a complete list can be obtained by looking at the system tables.
I understand. On the things that follow below, I have to get back on
that next week. It seems the person who contracted me closes it's VPN
connection in the weekend, so I cannot access the machine I was working
on! Hahaha, that is a way to force people to take weekends off.
>
> Hope that makes things clearer.
>
>
> Anywho, back to your problem, it sounds like there is an SRID
> constraint on your production table that only allows geometries with a
> certain SRID to be inserted into the table.
>
> You mentioned that you were using pgAdmin, right? When you select your
> table in pgAdmin, what is the exact table definition?
> If you use postgres's command-line terminal, psql, you could simply
> issue the following command: "\d infra_line2".
>
> This will show you the table definition and all the constraints on the
> table.
>
> I suppose you could also view the table's constraints which this
> query: (I think i got this right)
> SELECT c.relname as table_name, conname as constraint_name,
> pg_catalog.pg_get_constraintdef(r.oid, true) as constraint_def
> FROM pg_catalog.pg_constraint r, pg_class c
> WHERE r.conrelid = c.oid
> AND r.contype = 'c'
> AND c.relname = 'infra_line2';
>
> What you need to do is wrap your geometries with a
> setsrid(wkb_geometry, XXXX) when you insert them into the infra_line2
> table, where XXXX is the /enforce_srid_the_geom/ constraint you have
> on that table.
>
> Clear as mud?
>
> Have a great weekend!
> -- Kevin
>
>
> Milo van der Linden wrote:
>> Thank you Kevin, One step closer to goal!
>>
>> I ran the 2 select statements you mentioned below and found out the
>> following;
>> - For infra_line2, it returns nothing!
>> - bm_staging returns the right value: 32767.
>>
>> I then tried the following;
>> UPDATE infra_line2 SET the_geom = SetSRID(the_geom, (SELECT srid FROM
>> geometry_columns WHERE f_table_name = 'infra_line2'));
>> SELECT distinct( getsrid( the_geom ) ) FROM infra_line2;
>> SELECT distinct( getsrid( wkb_geometry ) ) FROM bm_staging;
>>
>> But still infra_line2 returns nothing.
>>
>> I noticed something else; when I drop a table, the entry in the
>> geometry_columns tables remains. And opposite, when I create a table,
>> no entry is set in the geometry_columns.
>>
>> I am doing a project initiated by someone else, could it be that I
>> have to reinstall? Is there a way to check what version of postGIS is
>> the installed one?
>>
>> I also read on the OGR forum that when there is just a tiny mismatch
>> between the way EPSG:4326 is described in the conversion script and
>> the way it is implemented in postGIS, OGR creates a new SRID during
>> import, that's why my coordsys is in 32767. For this I am going to
>> use SetSRID(the_geom, 4326)
>>
>>
>> Help apreciated! Special thanks to you, Kevin.
>>
>>
>> Kevin Neufeld schreef:
>>> The error is being generated because the geometries you are
>>> inserting into your production table have a different SRID than the
>>> constraint you have on your table.
>>>
>>> You can either transform the geometries to the SRID of your table as
>>> you insert them, or you can simply set the SRID of your inserted
>>> geometries to be the same.
>>>
>>> For your insert query to work, these numbers should both be the same:
>>> SELECT distinct( getsrid( the_geom ) ) FROM public.infra_line2;
>>> SELECT distinct( getsrid( wkb_geometry ) ) FROM bm_staging;
>>>
>>> Cheers,
>>> -- Kevin
>>>
>>> Milo van der Linden wrote:
>>>> Hello Kevin, thank you for the response!
>>>>
>>>> Kevin Neufeld schreef:
>>>>>
>>>>> Milo van der Linden wrote:
>>>>>>
>>>>>> The original data is in shape files. With ogr2ogr I do a
>>>>>> conversion from the Dutch coordinate system to WGS84 and import
>>>>>> it in a temp_table in PostGIS.
>>>>> Did you know that PostGIS has a shape loader? You may find loading
>>>>> shape files easier with the shp2pgsql utility. Also, PostGIS can
>>>>> perform transformations on geometries ... you may not even need
>>>>> ogr. Just a thought.
>>>> I knew that, but I am very familiar with ogr and not with
>>>> shp2pgsql. Besides that, it is fired from a php script that is
>>>> currently well under control. Also, shp2pgsql is from the same
>>>> development team as ogr, they probably use the same code base.
>>>>>>
>>>>>> When I execute the statement in pgAdmin, I get an error message
>>>>>> from postGIS:
>>>>>>
>>>>>> ERROR: new row for relation "infra_line2" violates check
>>>>>> constraint "enforce_srid_the_geom"
>>>>>>
>>>>>> I tried to add USING SRID=32767 to the insert statement, but it
>>>>>> fails with another error message
>>>>> It sounds like the geometries in your temp table either doesn't
>>>>> have, or has a different SRID than your production table. Is the
>>>>> data in your staging table supposed to be the same projection as
>>>>> your production table? (ogr possibly didn't add an SRID to your
>>>>> imported geometries and they may be defaulting to -1). If this is
>>>>> the case, then you simply need to wrap your geometries with a
>>>>> setsrid function call, ie "SetSRID(the_geom, 32767)", assuming of
>>>>> course that 32767 is the SRID of your production table.
>>>> When I check my geometry meta table, the SRID for the staging table
>>>> is correct, even though it should be 4326 (wgs84), during the
>>>> import ogr decided to create a new srid that is a perfect copy of
>>>> the standard wgs84 SRID.
>>>>>
>>>>> INSERT INTO public.infra_line2
>>>>> (infraline_type,
>>>>> infraline_polution,
>>>>> infraline_comment,
>>>>> infraline_startdate,
>>>>> infraline_enddate,
>>>>> infraline_top,
>>>>> infraline_base,
>>>>> the_geom,
>>>>> idproject,
>>>>> idsh0,
>>>>> idshp)
>>>>> SELECT
>>>>> 'type' as infraline_type,
>>>>> CASE WHEN ver_inr='0' THEN FALSE WHEN ver_inr='1' THEN TRUE
>>>>> ELSE FALSE END as infraline_polution,
>>>>> opmerking as infraline_comment,
>>>>> d_start as infraline_startdate,
>>>>> d_stop as infraline_stopdate,
>>>>> hoogte_top as infraline_top,
>>>>> hoogte_bas as infraline_base,
>>>>> setsrid(wkb_geometry, 32767) as the_geom,
>>>>> 1 as idproject,
>>>>> 6 as indsh0,
>>>>> id as idshp
>>>>> FROM bm_staging;
>>>>>
>>>>> Hope this helps,
>>>> Thank you for giving it a try, but no, it doesn't. I need to know
>>>> why the error is generated. Perhaps some one from postGIS
>>>> development can tell me?
>>>>> -- Kevin
>>>>>
>>>>>
>>>>> --------
>>>>> Kevin Neufeld
>>>>> Refractions Research Inc.
>>>>> kneufeld at refractions.net
>>>>> (250) 383-3022
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> Milo van der Linden
>>>> mlinden at zeelandnet.nl <mailto:mlinden at zeelandnet.nl>
>>>> milovanderlinden at gmail.com <mailto:milovanderlinden at gmail.com>
>>>> milo at 3dsite.nl <mailto:milo at 3dsite.nl>
>>>> http://www.3dsite.nl
>>>>
>>>>
>>>>
>>>> De informatie in dit bericht reflecteerd mijn persoonlijke mening
>>>> en niet die van een bedrijf of instantie. Aan de informatie kunnen
>>>> geen rechten worden ontleend. Indien dit bericht onderdeel is van
>>>> een forum, mailing-list of community dan gelden automatisch de
>>>> bijbehorende voorwaarden.
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>>
>>>> Milo van der Linden
>>>> mlinden at zeelandnet.nl <mailto:mlinden at zeelandnet.nl>
>>>> milovanderlinden at gmail.com <mailto:milovanderlinden at gmail.com>
>>>> milo at 3dsite.nl <mailto:milo at 3dsite.nl>
>>>> http://www.3dsite.nl
>>>>
>>>>
>>>>
>>>> De informatie in dit bericht reflecteerd mijn persoonlijke mening
>>>> en niet die van een bedrijf of instantie. Aan de informatie kunnen
>>>> geen rechten worden ontleend. Indien dit bericht onderdeel is van
>>>> een forum, mailing-list of community dan gelden automatisch de
>>>> bijbehorende voorwaarden.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>>
>>
>>
>> --
>>
>>
>>
>>
>> Milo van der Linden
>> mlinden at zeelandnet.nl <mailto:mlinden at zeelandnet.nl>
>> milovanderlinden at gmail.com <mailto:milovanderlinden at gmail.com>
>> milo at 3dsite.nl <mailto:milo at 3dsite.nl>
>> http://www.3dsite.nl
>>
>>
>>
>> De informatie in dit bericht reflecteerd mijn persoonlijke mening en
>> niet die van een bedrijf of instantie. Aan de informatie kunnen geen
>> rechten worden ontleend. Indien dit bericht onderdeel is van een
>> forum, mailing-list of community dan gelden automatisch de
>> bijbehorende voorwaarden.
>>
--
Milo van der Linden
mlinden at zeelandnet.nl <mailto:mlinden at zeelandnet.nl>
milovanderlinden at gmail.com <mailto:milovanderlinden at gmail.com>
milo at 3dsite.nl <mailto:milo at 3dsite.nl>
http://www.3dsite.nl
De informatie in dit bericht reflecteerd mijn persoonlijke mening en
niet die van een bedrijf of instantie. Aan de informatie kunnen geen
rechten worden ontleend. Indien dit bericht onderdeel is van een forum,
mailing-list of community dan gelden automatisch de bijbehorende
voorwaarden.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20070721/771ccfdf/attachment.html>
More information about the postgis-users
mailing list