[postgis-users] Help loading box (polygon) data, value of GiST on squares and 180 meridian question
Wood Brent
pcreso at pcreso.com
Wed Apr 14 22:37:32 PDT 2004
I thought I'd followed the instructions, but I'm prob missing summat simple.
I have a script to create a table, add geometry & write SQL to populate.
#commands to make new table
psql -d $DB -q -c "create table chat_cell (
cell_id int,
depth decimal(5,1),
substrate smallint
);"
psql -d $DB -q -c "SELECT AddGeometryColumn('public', 'chat_cell', 'the_geom',
4326, 'POLYGON', 2);"
This seems fine. I then write the file with the command to insert a record, the
line as written is:
insert into chat_cell (cell_id,depth,substrate,the_geom) values
(1,0,0,GeometryFromText('POLYGON(173.0000 -45.4834, 173.0000 -45.4668, 173.0166
-45.4668, 173.0166 -45.4834)',4326));
This returns the error message when run:
psql -d env2003 -f cells.sql
psql:cells.sql:1: ERROR: couldnt parse object in GEOMETRY
I assume my insert command has an error in the geometry formatting???
The object should be a small box, with 4 corners. I'm assuming I don't need to
finish with the first point to close the polygon, and I get the same error when
I add the first point at the end.
Followup questions, for when (not if :-) I get the data loaded.
As the table only contains square boxes (about 50,000 when done), is there any
benefit to creating a GiST index on it? The index will be the bounding box for
each cell, which is the same as the cell, but it may have other advantages I'm
not aware of to improve performance, like the tree itself being faster than a
table scan.
Also, I'm using SRID 4326 as a generic WGS84 lat/long projection. Is this going
to be happy with longitudes in the range of 0-360 instead of -180 to +180? (or
should I ask this in a proj area instead?) Will -170 equate to 190?
Thanks,
Brent Wood
More information about the postgis-users
mailing list