Re: [postgis-users] Problem after reprojecting: Extent: BOX(inf inf, inf inf)
The coordinates you get from extent do not look like WGS84 (lat/lon) which is
EPSG code 4326. Are they UTC zone 33N (which covers Austria?). If the
original projection is incorrect this would explain the inf results from
ST_TRANSFORM.
Phil
>
>From: Jan Peters
>To: PostGIS Users Discussion
>Sent: Monday, 7 November 2011, 17:47
>Subject: [postgis-users] Problem after reprojecting: Extent: BOX(inf inf, inf
>inf)
>
>Sorry for posting in a reply last time:
>
>Dear all,
>I am a bit stuck: I just encountered that some of my PostGIS datasets were
>defined as EPSG:31259 in the geometry_colums table, but the geometry data was
>actually EPSG:4326. Now I wanted to project this data from 4326 to 31259 via:
>
>CREATE TABLE table_31259 AS
>SELECT
>table_4326.id,
>ST_Transform(the_geom,31259) AS the_geom
>FROM table_4326;
>
>which had already been working for other tables, but the newest tables seem to
>resist correct projection because when I run
>
>select ST_extent(table_4326.the_geom)
>FROM table_4326;
>
>I get:
>
>st_extent:
>BOX(4130129.75 -3197344.75,4439015 -2797768.25) /*which is correct*/
>
>after projecting the data to EPSG:31259 I get:
>
>st_extent:
>BOX(inf inf,inf inf) /*which means there is obviously something wrong*/
>
>Do I miss something here? I also tried to update the SRID in table_4326 like:
>
>SELECT updategeometrysrid('table_4326', 'the_geom', 4326);
>and then:
>SELECT setsrid(the_geom, 4326) from table_4326;
>
>and after that projecting the data to EPSG:31259 again, so there must be
>something going fundamentally wrong I fear.
>
>Thanks for any replies
>Jan
>
>--
>NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
>Jetzt informieren: http://www.gmx.net/de/go/freephone
>___
>postgis-users mailing list
>postgis-users@postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Tuning PostgreSQL for a very large database
Rene, There is no single answer to this as it depends on your usage, type of data, etc. You can get some pointers here http://postgis.refractions.net/docs/ch06.html#id2636014 Also a search on the mailing list will give you some information on what to change, some messages are a bit old but they contain valuable information. Hope that helps -- Juan Marín Otero GIS Consultant ---Visita mi blog en- http://guachintoneando.blogspot.com --- On Sun, Nov 6, 2011 at 1:16 PM, René Fournier wrote: > Just wondering what I can do to squeeze out more performance of my > database application? Here's my configuration: > > > - Mac mini server > > - Core i7 quad-core at 2GHz > > - 16GB memory > - Dedicated fast SSD (two SSDs in the server) > - Mac OS X 10.7.2 (*not* using OS X Server) > > - PostgreSQL 9.05 > - PostGIS 1.5.3 > - Tiger Geocoder 2010 database (from build scripts from > http://svn.osgeo.org/postgis/trunk/extras/tiger_geocoder/tiger_2010/) > - Database size: ~90GB > > I should say, this box does more than PostgreSQL > geocoding/reverse-geocoding, so reasonably only half of the memory should > be allotted to PostgreSQL. > > Coming from MySQL, I would normally play with the my.cnf, using > my-huge.cnf as a start. But I'm new to PostgreSQL and PostGIS (w/ a big > database), so I was wondering if anyone had suggestions on tuning > parameters (also, which files, etc.) Thanks! > > …Rene > > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > > ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Tuning PostgreSQL for a very large database
Rene, You're best asking the PostgreSQL Performance (pgsql-performance) mailing list. http://www.postgresql.org/community/lists/ If you have any spatial-specific questions (a query is running slower than expected), then definitely post here. -bborie On 11/06/2011 10:16 AM, René Fournier wrote: Just wondering what I can do to squeeze out more performance of my database application? Here's my configuration: - Mac mini server - Core i7 quad-core at 2GHz - 16GB memory - Dedicated fast SSD (two SSDs in the server) - Mac OS X 10.7.2 (*not* using OS X Server) - PostgreSQL 9.05 - PostGIS 1.5.3 - Tiger Geocoder 2010 database (from build scripts from http://svn.osgeo.org/postgis/trunk/extras/tiger_geocoder/tiger_2010/) - Database size: ~90GB I should say, this box does more than PostgreSQL geocoding/reverse-geocoding, so reasonably only half of the memory should be allotted to PostgreSQL. Coming from MySQL, I would normally play with the my.cnf, using my-huge.cnf as a start. But I'm new to PostgreSQL and PostGIS (w/ a big database), so I was wondering if anyone had suggestions on tuning parameters (also, which files, etc.) Thanks! …Rene ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users -- Bborie Park Programmer Center for Vectorborne Diseases UC Davis 530-752-8380 bkp...@ucdavis.edu ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Problem after reprojecting: Extent: BOX(inf inf, inf inf)
Sorry for posting in a reply last time:
Dear all,
I am a bit stuck: I just encountered that some of my PostGIS datasets were
defined as EPSG:31259 in the geometry_colums table, but the geometry data was
actually EPSG:4326. Now I wanted to project this data from 4326 to 31259 via:
CREATE TABLE table_31259 AS
SELECT
table_4326.id,
ST_Transform(the_geom,31259) AS the_geom
FROM table_4326;
which had already been working for other tables, but the newest tables seem to
resist correct projection because when I run
select ST_extent(table_4326.the_geom)
FROM table_4326;
I get:
st_extent:
BOX(4130129.75 -3197344.75,4439015 -2797768.25) /*which is correct*/
after projecting the data to EPSG:31259 I get:
st_extent:
BOX(inf inf,inf inf) /*which means there is obviously something wrong*/
Do I miss something here? I also tried to update the SRID in table_4326 like:
SELECT updategeometrysrid('table_4326', 'the_geom', 4326);
and then:
SELECT setsrid(the_geom, 4326) from table_4326;
and after that projecting the data to EPSG:31259 again, so there must be
something going fundamentally wrong I fear.
Thanks for any replies
Jan
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Problem after reprojecting: Extent: BOX(inf inf, inf inf)
Dear all,
I am a bit stuck: I just encountered that some of my PostGIS datasets were
defined as EPSG:31259 in the geometry_colums table, but the geometry data was
actually EPSG:4326. Now I wanted to project this data from 4326 to 31259 via:
CREATE TABLE table_31259 AS
SELECT
table_4326.id,
ST_Transform(the_geom,31259) AS the_geom
FROM table_4326;
which had already been working for other tables, but the newest tables seem to
resist correct projection because when I run
select ST_extent(table_4326.the_geom)
FROM table_4326;
I get:
st_extent:
BOX(4130129.75 -3197344.75,4439015 -2797768.25) /*which is correct*/
after projecting the data to EPSG:31259 I get:
st_extent:
BOX(inf inf,inf inf) /*which means there is obviously something wrong*/
Do I miss something here? I also tried to update the SRID in table_4326 like:
SELECT updategeometrysrid('table_4326', 'the_geom', 4326);
and then:
SELECT setsrid(the_geom, 4326) from table_4326;
and after that projecting the data to EPSG:31259 again, so there must be
something going fundamentally wrong I fear.
Thanks for any replies
Jan
--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostgreSQL table history tracking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2011 12:40 PM, Sandro Santilli wrote: > Ivan, maybe tracking history of a PostGIS topology would be an interesting > use case for you. It'd require tracking multiple tables at once, so that > "restore" operations are also performed on all tables at the same time. Hi Sandro, I think it is possible to add support for topology entities. I did just quick look on your good topology work at the time when You announced it. > I guess such use case would benefit for ad-hoc routines to support that, > should they be in your code ? > Or is there any postgis-specific code in yours ? Currently, all functions are created to support any data types (geometry or non-geometry). There is no postgis-specific code, because it is not needed now. Maybe some quick code review from experienced hacker like You would be very valuable for this project. I would incorporate Your comments. Anyway, thanks for Your response. - -- Ivan Mincik, Gista s.r.o. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk64FgEACgkQVqso/9cUsCw0SQCfYNsCvrN46QFwOiqLo6kTomsh 7wUAn2mGg64YcwV0NpQMylBE+EEJsgfq =sZRW -END PGP SIGNATURE- ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Error Loading HDF4 Format with raster2pgsql.py Script.
Apparently the gdal Python binding is not able to determine the pixeltype of the raster... Does gdalinfo can? > -Original Message- > From: postgis-users-boun...@postgis.refractions.net [mailto:postgis-users- > boun...@postgis.refractions.net] On Behalf Of elliott > Sent: Monday, November 07, 2011 10:45 AM > To: PostGIS Users Discussion > Subject: [postgis-users] Error Loading HDF4 Format with raster2pgsql.py > Script. > > Hi, > > I have tried to load an HDF4 formatted MODIS temperature file with the > raster2pgsql.py script and getting the following error. I have built GDAL > with the > HDF4 format and it seems to recognize the file but the loader is having the > following problem: > > /usr/local/pgsql/bin/raster2pgsql.py -r > MOD11A2.A2011289.h27v05.005.2011298111759.hdf -F -t modisLandTemp -s > 4326 -I > /usr/local/pgsql/data/modislt.sql Traceback (most recent call last): >File "/usr/local/pgsql/bin/raster2pgsql.py", line 1040, in > main() >File "/usr/local/pgsql/bin/raster2pgsql.py", line 1003, in main > gt = wkblify_raster(opts, filename.replace( '\\', '/') , i, gt) >File "/usr/local/pgsql/bin/raster2pgsql.py", line 945, in wkblify_raster > summary = wkblify_raster_level(options, ds, options.overview_level, > band_range, infile, i) >File "/usr/local/pgsql/bin/raster2pgsql.py", line 861, in > wkblify_raster_level > pixel_size, block_size, extent) >File "/usr/local/pgsql/bin/raster2pgsql.py", line 385, in > make_sql_addrastercolumn > assert len(pixeltypes) > 0, "No pixel types given" > AssertionError: No pixel types given > > Thanks for your help! > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Error Loading HDF4 Format with raster2pgsql.py Script.
Hi, I have tried to load an HDF4 formatted MODIS temperature file with the raster2pgsql.py script and getting the following error. I have built GDAL with the HDF4 format and it seems to recognize the file but the loader is having the following problem: /usr/local/pgsql/bin/raster2pgsql.py -r MOD11A2.A2011289.h27v05.005.2011298111759.hdf -F -t modisLandTemp -s 4326 -I > /usr/local/pgsql/data/modislt.sql Traceback (most recent call last): File "/usr/local/pgsql/bin/raster2pgsql.py", line 1040, in main() File "/usr/local/pgsql/bin/raster2pgsql.py", line 1003, in main gt = wkblify_raster(opts, filename.replace( '\\', '/') , i, gt) File "/usr/local/pgsql/bin/raster2pgsql.py", line 945, in wkblify_raster summary = wkblify_raster_level(options, ds, options.overview_level, band_range, infile, i) File "/usr/local/pgsql/bin/raster2pgsql.py", line 861, in wkblify_raster_level pixel_size, block_size, extent) File "/usr/local/pgsql/bin/raster2pgsql.py", line 385, in make_sql_addrastercolumn assert len(pixeltypes) > 0, "No pixel types given" AssertionError: No pixel types given Thanks for your help! ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ERROR: Operation on two geometries with different SRIDs
>> Now, trying to import it with: >> >>shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco> morocco.sql >>psql -U my_database< morocco.sql > > Hi Stefan, > > The SRID argument to shp2pgsql should just be a plain numeric field, and not > have the EPSG prefix in front of it, e.g.: > > shp2pgsql -s 26191 -I -D morocco.shp morocco> morocco.sql > > This should generate you a file with the SRID 26191 which should load without > any further issues. That did the trick! Great. Thanks a lot!! ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ERROR: Operation on two geometries with different SRIDs
On 07/11/11 14:07, Stefan Schwarzer wrote: Now, trying to import it with: shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco> morocco.sql psql -U my_database< morocco.sql Hi Stefan, The SRID argument to shp2pgsql should just be a plain numeric field, and not have the EPSG prefix in front of it, e.g.: shp2pgsql -s 26191 -I -D morocco.shp morocco> morocco.sql This should generate you a file with the SRID 26191 which should load without any further issues. HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] ERROR: Operation on two geometries with different SRIDs
On 7 November 2011 15:07, Stefan Schwarzer wrote: > Hi there, > > I am somewhat fighting with the projection of my file. > > I have a file for Morocco, which, after ArcMap, has the following projection: > > Projected Coordinate System: zone1 > Projection: Lambert_Conformal_Conic > False_Easting: 50. > False_Northing: 30. > Central_Meridian: -5.4000 > Standard_Parallel_1: 34.8660 > Standard_Parallel_2: 31.7250 > Scale_Factor: 1. > Latitude_Of_Origin: 33.3000 > Linear Unit: Meter > Geographic Coordinate System: GCS_Merchich_Degree > Datum: D_Merchich > > After looking around, it seems to be the EPSG 26191 > (http://spatialreference.org/ref/epsg/26191/). > > Now, trying to import it with: > > shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco > morocco.sql > psql -U my_database < morocco.sql > > > I can see in the SQL file that the SRID is set to -1. If I change this to > 26191, and try to import it then, it gives me an error message: > > ERROR: new row for relation "morocco" violates check constraint > "enforce_srid_the_geom" > Hi, Can you explicitly drop the table before re-running the SQL ? > > So, I changed the SRID in the geometry_columns manually. > > But when trying to map the layer, I receive the error messsage: > > ERROR: Operation on two geometries with different SRIDs > > It is not enough to update the geometry_columns. You also have to update internal geometries SRID: update mytable set geom = set_srid(geom). (looking at the manual, I also see: updateGeometrySrid, that manages all operations (metadata, constraints and data, did not know this one :) ) > My Mapserver.map file show only SQLs with 26191, for projection of main > document, as well as SQLs such as: > > DATA 'the_geom FROM morocco USING UNIQUE gid USING srid=26191' > > > Extent and units of the mapserver file have been changed to the proper > extent/units. > > So, I am confused about where the problem comes from. It would be great if > someone could give me a hint where the error lies. > > Thanks a lot! > Nicolas ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] ERROR: Operation on two geometries with different SRIDs
Hi there, I am somewhat fighting with the projection of my file. I have a file for Morocco, which, after ArcMap, has the following projection: Projected Coordinate System: zone1 Projection: Lambert_Conformal_Conic False_Easting: 50. False_Northing: 30. Central_Meridian:-5.4000 Standard_Parallel_1: 34.8660 Standard_Parallel_2: 31.7250 Scale_Factor:1. Latitude_Of_Origin: 33.3000 Linear Unit: Meter Geographic Coordinate System:GCS_Merchich_Degree Datum: D_Merchich After looking around, it seems to be the EPSG 26191 (http://spatialreference.org/ref/epsg/26191/). Now, trying to import it with: shp2pgsql -s EPSG:26191 -I -D morocco.shp morocco > morocco.sql psql -U my_database < morocco.sql I can see in the SQL file that the SRID is set to -1. If I change this to 26191, and try to import it then, it gives me an error message: ERROR: new row for relation "morocco" violates check constraint "enforce_srid_the_geom" So, I changed the SRID in the geometry_columns manually. But when trying to map the layer, I receive the error messsage: ERROR: Operation on two geometries with different SRIDs My Mapserver.map file show only SQLs with 26191, for projection of main document, as well as SQLs such as: DATA 'the_geom FROM morocco USING UNIQUE gid USING srid=26191' Extent and units of the mapserver file have been changed to the proper extent/units. So, I am confused about where the problem comes from. It would be great if someone could give me a hint where the error lies. Thanks a lot! ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
