Re: [postgis-users] Best Practices for Configuring Large Data Sets
Brent Fraser wrote: Is your PLSS data lines (yikes!) or areas (hopefully)? And the shapefiles have the same attributes (or can be made that way prior to loading into PostGIS)? Are the mining claims represented by points or areas? If they are areas, I guess you could use the centroid in the query. They are areas (polygons). The shapefiles are theoretically the same, but as with most large govt-built databases there are wee variations that'll whack you if you don't check. So I follow Reagan's advice, "Trust, but verify." and will fix the problems I've found already and make each state table identical in structure. One suggestion I've received that sounds pretty good is to pre-index the centroids as well as the polygons. But it sounds like indexing is a very key part of the process. Disk space and RAM is (relatively) cheap these days while time seems to be getting more expensive. -- Bill Thoen GISnet - www.gisnet.com 1401 Walnut St., Suite C Boulder, CO 80302 303-786-9961 tel 303-443-4856 fax ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
samclemmens wrote: I dropped the db and recreated it...and this time it worked. I get the following, which, I'm assuming, means I'm good to go...? testdb1=# SELECT postgis_full_version(); postgis_full_version --- POSTGIS="1.5.0SVN" GEOS="3.2.0-CAPI-1.6.0" PROJ="Rel. 4.6.1, 21 August 2008" LIBXML="2.7.6" USE_STATS (1 row) Yep; that looks good to me :) ATB, 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] PostGIS: make check works, but I can't manually create a spatial database
I dropped the db and recreated it...and this time it worked. I get the following, which, I'm assuming, means I'm good to go...? testdb1=# SELECT postgis_full_version(); postgis_full_version --- POSTGIS="1.5.0SVN" GEOS="3.2.0-CAPI-1.6.0" PROJ="Rel. 4.6.1, 21 August 2008" LIBXML="2.7.6" USE_STATS (1 row) Mark Cave-Ayland-3 wrote: > > samclemmens wrote: > >> I ran make install after make check, and received the output below. >> There >> was no confirmation that it installed properly or not. I tried creating >> another spatial database using the same commands, but to no avail. >> ---Same >> issue. > > The "make install" output looks good. Are you sure you get *exactly* the > same error as before when installing into a fresh database? The part of > the log we need to see when installed into a fresh database are the set > of lines just before and just after the first ERROR appears. Please drop > the database and try again posting the relevant output. > > The only other thing I can think of is that someone has installed > another version of PostGIS into the template1 database so that it gets > automatically added to any new database. > > > 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 > > -- View this message in context: http://old.nabble.com/PostGIS%3A-make-check-works%2C-but-I-can%27t-manually-create-a-spatial-%09database-tp28691440p28708732.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
samclemmens wrote: I ran make install after make check, and received the output below. There was no confirmation that it installed properly or not. I tried creating another spatial database using the same commands, but to no avail. ---Same issue. The "make install" output looks good. Are you sure you get *exactly* the same error as before when installing into a fresh database? The part of the log we need to see when installed into a fresh database are the set of lines just before and just after the first ERROR appears. Please drop the database and try again posting the relevant output. The only other thing I can think of is that someone has installed another version of PostGIS into the template1 database so that it gets automatically added to any new database. 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] Best Practices for Configuring Large Data Sets
Hi Bill, I have not done much like you describe, but am working with Postgis tables with around 155,000,000 polygons in them, & have got very reasonable performance out of it. General comments, some probably obvious, but here anyway... I'm running a quad core AMD 965 with 16Gb memory & my db in a raid 0 partition (software raid under Linux) across fastish 1Tb WD black hard drives. You are moving lots of data for a query on such datasets so fast disk, spatial queries are also fpu/cpu intensive. Get a balanced system, but disk I/O will generally be the bottleneck. A fast cpu will still be idling waiting for data as the most likely bottleneck. Use a 64 bit O/S to allow full use of as much memory as you can. With DDR3 now providing fast & affordable 4Gb modules, at least 16Gb is good. Use latest versions of Postgres/Postgis. They have improved indexing & prepared queries which are around 10x faster than previous ones for many spatial queries. Use tablespaces. Put indexes & data on separate physical disks (or arrays). Heads jumping around of drives is the slowest part of the equation. Use aspatial columns/indices where possible & pre-populate. eg: for all records (section, city, county, etc) have an indexed column for state. Select section where state='ID' will be much faster than where ST_contains(state.geom, section.geom) If you often have queries like "W of Mississippi" then add an indexed boolean column as a flag for this & pre-populate, again "select ... where [not] w_mis and ..." is much quicker than "select ... where and ..." Table partitioning might help, but configure the server to use them effectively. Maybe the section table partitioned by state, but configure the server to use table partitions effectively. (there is documentation on this, but other ways can be more effective) If you do a lot of section-in-state queries, then having a clustered index on section.state should help. Use functional & conditional indexes (see this post for details: http://postgis.refractions.net/pipermail/postgis-users/2006-February/011198.html) Yes, using pre configured bounding boxes will help, any way to quickly reduce the result set to be further processed can make big differences. Don't trust the query planner. While it usually does a pretty good job, with complex spatial queries it can get confused. "explain" is your friend, even if it does talk in some arcane jargon at times. If a query is taking longer than you expected, it can often be tweaked to give faster results. Store ALL your data in a single projection/coord system. You don't want any unnecessary transforms. Use 2D geometries. I don't know what the overhead in a few bytes extra per coord, but why suffer it if you don't need to. HTH, Brent Wood --- On Sat, 5/29/10, Bill Thoen wrote: > From: Bill Thoen > Subject: [postgis-users] Best Practices for Configuring Large Data Sets > To: postgis-users@postgis.refractions.net > Date: Saturday, May 29, 2010, 2:49 AM > I've got a database of Public Land > Survey System (PLSS) data for most of the > contiguous United States, and I need to make it accessible > to spatial queries using PostgreSQL and PostGIS. My basic > question is how to physically configure it so that queries > over any area are as efficient as possible. > > Right now it is all stored in Shapefiles, physically > separated by state and within each state it's divided into > three layers: township boundaries, section boundaries and > quarter-section boundaries. To give you some idea of the > scale of the entities, townships are square-ish polygons 6 > miles on a side and contain 36 sections. Sections are approx > 1 sq mi in size. The files take up some space too (for > example, the data for Colorado is 862Mb and Wyoming is > 763Mb.) > > I need to use these data to perform queries on other > national data sets to provide results for requests like: > "Produce a count of all active mining claims west of the > Mississippi (west of longitude 96W is good enough) by PLSS > section that intersect any of the Inventoried Roadless Areas > (IRAs)." > > I think I know how to do queries like this, but it would be > nice to not have to do them for each state. OTOH, if I > combine the data so that it doesn't break at the state > borders, every query is going to involve whopper-sized > tables and the system might be too slow. I've thought about > writing the queries starting out by filtering on an "Area of > Interest" rectangle first, taking advantage of spatial > indexing, but I have no feel yet for whether that will > quickly enough reduce the load so that the queries don't > take months to execute. > > So if you have experience with this sort of thing, could I > get your advice on how to balance files sizes to optimize > performance and convenience? Also if you know of any > "red flag" conditions that I should watch out for where > things become unstable or performance goes to pot (like MS > Access' 2Gb limit. You
Re: [postgis-users] Best Practices for Configuring Large Data Sets
Bill, Is your PLSS data lines (yikes!) or areas (hopefully)? And the shapefiles have the same attributes (or can be made that way prior to loading into PostGIS)? Are the mining claims represented by points or areas? If they are areas, I guess you could use the centroid in the query. I expect the query to fast enough as long as there is a spatial index on the PLSS table, but perhaps some more experienced PostGIS people could comment on that... Best Regards, Brent Fraser Bill Thoen wrote: I've got a database of Public Land Survey System (PLSS) data for most of the contiguous United States, and I need to make it accessible to spatial queries using PostgreSQL and PostGIS. My basic question is how to physically configure it so that queries over any area are as efficient as possible. Right now it is all stored in Shapefiles, physically separated by state and within each state it's divided into three layers: township boundaries, section boundaries and quarter-section boundaries. To give you some idea of the scale of the entities, townships are square-ish polygons 6 miles on a side and contain 36 sections. Sections are approx 1 sq mi in size. The files take up some space too (for example, the data for Colorado is 862Mb and Wyoming is 763Mb.) I need to use these data to perform queries on other national data sets to provide results for requests like: "Produce a count of all active mining claims west of the Mississippi (west of longitude 96W is good enough) by PLSS section that intersect any of the Inventoried Roadless Areas (IRAs)." I think I know how to do queries like this, but it would be nice to not have to do them for each state. OTOH, if I combine the data so that it doesn't break at the state borders, every query is going to involve whopper-sized tables and the system might be too slow. I've thought about writing the queries starting out by filtering on an "Area of Interest" rectangle first, taking advantage of spatial indexing, but I have no feel yet for whether that will quickly enough reduce the load so that the queries don't take months to execute. So if you have experience with this sort of thing, could I get your advice on how to balance files sizes to optimize performance and convenience? Also if you know of any "red flag" conditions that I should watch out for where things become unstable or performance goes to pot (like MS Access' 2Gb limit. You DON'T want to get near that!) I'd appreciate knowing about them before stepping into them. TIA, - Bill Thoen ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
I ran make install after make check, and received the output below. There was no confirmation that it installed properly or not. I tried creating another spatial database using the same commands, but to no avail. ---Same issue. [r...@ip-10-224-82-127 postgis-1.5.0SVN]# make install make -C liblwgeom make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/liblwgeom' : -Plwg_parse_yy -i -f -o'lex.yy.c' wktparse.lex make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/liblwgeom' make -C postgis make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old commands f or target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old commands for target `uninstall' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/postgis' make -C loader make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/loader' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/loader' make -C utils make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/utils' chmod +x postgis_restore.pl create_undef.pl postgis_proc_upgrade.pl profile_inte rsects.pl test_estimation.pl test_joinestimation.pl make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/utils' PostGIS was built successfully. Ready to install. make -C postgis install make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/postgis' Makefile.pgxs:17: warning: overriding commands for target `install' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:92: warning: ignoring old commands f or target `install' Makefile.pgxs:63: warning: overriding commands for target `installdirs' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:140: warning: ignoring old commands for target `installdirs' Makefile.pgxs:82: warning: overriding commands for target `uninstall' /usr/lib64/pgsql/pgxs/src/makefiles/pgxs.mk:164: warning: ignoring old commands for target `uninstall' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/mkinstalldirs '/usr/lib 64/pgsql' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 755 p ostgis-1.5.so '/usr/lib64/pgsql/postgis-1.5.so' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 ./ ../spatial_ref_sys.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 po stgis.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 un install_postgis.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 po stgis_upgrade_15_minor.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 po stgis_upgrade_14_to_15.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 644 po stgis_upgrade_13_to_15.sql '/usr/share/pgsql/contrib/postgis-1.5' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c -m 755 p ostgis-1.5.so '/usr/lib64/pgsql/postgis-1.5.so' make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/postgis' make -C loader install make[1]: Entering directory `/opt/sources/postgis/postgis-1.5.0SVN/loader' /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c pgsql2shp /usr/bin /bin/sh /usr/lib64/pgsql/pgxs/src/makefiles/../../config/install-sh -c shp2pgsql /usr/bin make[1]: Leaving directory `/opt/sources/postgis/postgis-1.5.0SVN/loader' Mark Cave-Ayland-3 wrote: > > samclemmens wrote: > >> Unfortunately, I get the following: >> >> postgres=# SELECT postgis_full_version(); >> ERROR: function postg
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
samclemmens wrote: Unfortunately, I get the following: postgres=# SELECT postgis_full_version(); ERROR: function postgis_full_version() does not exist LINE 1: SELECT postgis_full_version(); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. Okay so something has gone wrong somewhere. Firstly, after "make check", did you run "make install"? Secondly, what happens if you load the postgis.sql file into a brand new database? ATB, 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] PostGIS: make check works, but I can't manually create a spatial database
Unfortunately, I get the following: postgres=# SELECT postgis_full_version(); ERROR: function postgis_full_version() does not exist LINE 1: SELECT postgis_full_version(); ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. Mark Cave-Ayland-3 wrote: > > samclemmens wrote: > >> Sorry; I inadvertently posted my previous response twice... The line >> is: >> >> psql:postgis/postgis.sql:80: ERROR: type "spheroid" already exists >> >> So, does this mean that my spatial database was successfully created the >> first time around despite the "notices" that the spatial functions (e.g., >> st_max_distance) do not exist? > > Older versions of 1.5 tried to remove some legacy functions from the > database as part of the installation which is why some people would see > error messages at the end of the installation. > > Since all the SQL functions are now in a transaction, then if you can > call any PostGIS function then the installation has completed correctly. > Does "SELECT postgis_full_version()" work for you? If so, you should be > fine. > > > 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 > > -- View this message in context: http://old.nabble.com/PostGIS%3A-make-check-works%2C-but-I-can%27t-manually-create-a-spatial-%09database-tp28691440p28708126.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
samclemmens wrote: Sorry; I inadvertently posted my previous response twice... The line is: psql:postgis/postgis.sql:80: ERROR: type "spheroid" already exists So, does this mean that my spatial database was successfully created the first time around despite the "notices" that the spatial functions (e.g., st_max_distance) do not exist? Older versions of 1.5 tried to remove some legacy functions from the database as part of the installation which is why some people would see error messages at the end of the installation. Since all the SQL functions are now in a transaction, then if you can call any PostGIS function then the installation has completed correctly. Does "SELECT postgis_full_version()" work for you? If so, you should be fine. 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
[postgis-users] Best Practices for Configuring Large Data Sets
I've got a database of Public Land Survey System (PLSS) data for most of the contiguous United States, and I need to make it accessible to spatial queries using PostgreSQL and PostGIS. My basic question is how to physically configure it so that queries over any area are as efficient as possible. Right now it is all stored in Shapefiles, physically separated by state and within each state it's divided into three layers: township boundaries, section boundaries and quarter-section boundaries. To give you some idea of the scale of the entities, townships are square-ish polygons 6 miles on a side and contain 36 sections. Sections are approx 1 sq mi in size. The files take up some space too (for example, the data for Colorado is 862Mb and Wyoming is 763Mb.) I need to use these data to perform queries on other national data sets to provide results for requests like: "Produce a count of all active mining claims west of the Mississippi (west of longitude 96W is good enough) by PLSS section that intersect any of the Inventoried Roadless Areas (IRAs)." I think I know how to do queries like this, but it would be nice to not have to do them for each state. OTOH, if I combine the data so that it doesn't break at the state borders, every query is going to involve whopper-sized tables and the system might be too slow. I've thought about writing the queries starting out by filtering on an "Area of Interest" rectangle first, taking advantage of spatial indexing, but I have no feel yet for whether that will quickly enough reduce the load so that the queries don't take months to execute. So if you have experience with this sort of thing, could I get your advice on how to balance files sizes to optimize performance and convenience? Also if you know of any "red flag" conditions that I should watch out for where things become unstable or performance goes to pot (like MS Access' 2Gb limit. You DON'T want to get near that!) I'd appreciate knowing about them before stepping into them. TIA, - Bill Thoen -- - Bill Thoen GISnet - www.gisnet.com 303-786-9961 ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
Sorry; I inadvertently posted my previous response twice... The line is: psql:postgis/postgis.sql:80: ERROR: type "spheroid" already exists So, does this mean that my spatial database was successfully created the first time around despite the "notices" that the spatial functions (e.g., st_max_distance) do not exist? Kevin Neufeld wrote: > > These are not the ERRORs messages Devrim was referring to. These are > merely NOTICEs that are typical for a PostGIS installation. Before all > the "ERROR: transaction was aborted" log entries you reported, there > should be a line that indicates what caused the transaction to roll back. > > -- Kevin > > On 5/27/2010 2:14 AM, Peter Cotroneo wrote: >> >> Hi Devrim, >> >> Thanks for your reply. Here’s what I get immediately after trying to >> create a spatial database: >> >> >> [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres createdb >> testdb >> >> [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres createlang >> plpgsql testdb >> >> [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres psql -d >> testdb -f postgis/postgis.sql >> >> BEGIN >> >> psql:postgis/postgis.sql:57: NOTICE: type "spheroid" is not yet defined >> >> DETAIL: Creating a shell type definition. >> >> CREATE FUNCTION >> >> psql:postgis/postgis.sql:63: NOTICE: argument type spheroid is only a >> shell >> >> CREATE FUNCTION >> >> psql:postgis/postgis.sql:68: NOTICE: return type spheroid is only a shell >> >> CREATE FUNCTION >> >> psql:postgis/postgis.sql:73: NOTICE: argument type spheroid is only a >> shell >> >> CREATE FUNCTION >> >> CREATE TYPE >> >> psql:postgis/postgis.sql:90: NOTICE: type "geometry" is not yet defined >> >> DETAIL: Creating a shell type definition. >> >> As I mentioned yesterday, make check works just fine (i.e., it creates >> the spatial database postgis_reg). >> >> Cheers, >> >> Petrus >> >> >> ___ >> 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 > > -- View this message in context: http://old.nabble.com/PostGIS%3A-make-check-works%2C-but-I-can%27t-manually-create-a-spatial-%09database-tp28691440p28707299.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS: make check works, but I can't manually create a spatial database
Here’s what I get immediately after trying to create a spatial database: [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres createdb testdb [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres createlang plpgsql testdb [r...@ip-10-224-82-127 postgis-1.5.0SVN]# sudo -u postgres psql -d testdb -f postgis/postgis.sql BEGIN psql:postgis/postgis.sql:57: NOTICE: type "spheroid" is not yet defined DETAIL: Creating a shell type definition. CREATE FUNCTION psql:postgis/postgis.sql:63: NOTICE: argument type spheroid is only a shell CREATE FUNCTION psql:postgis/postgis.sql:68: NOTICE: return type spheroid is only a shell CREATE FUNCTION psql:postgis/postgis.sql:73: NOTICE: argument type spheroid is only a shell CREATE FUNCTION CREATE TYPE psql:postgis/postgis.sql:90: NOTICE: type "geometry" is not yet defined DETAIL: Creating a shell type definition. ...and so on... Devrim GÜNDÜZ wrote: > > On Wed, 2010-05-26 at 12:16 +0100, Peter Cotroneo wrote: >> >> When I try to create a spatial database (e.g., psql -d geodb -f >> postgis.sql), however, it doesn't work. I get numerous errors that >> look as follows: >> >> psql:postgis.sql:7739: ERROR: current transaction is aborted, >> commands ignored until end of transaction block > > There should be something different before this. Could you please paste > it? > > BTW, did you load plpgsql before running postgis.sql script? > -- > Devrim GÜNDÜZ > PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer > PostgreSQL RPM Repository: http://yum.pgrpms.org > Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr > http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz > > > ___ > postgis-users mailing list > postgis-users@postgis.refractions.net > http://postgis.refractions.net/mailman/listinfo/postgis-users > > -- View this message in context: http://old.nabble.com/PostGIS%3A-make-check-works%2C-but-I-can%27t-manually-create-a-spatial-%09database-tp28679308p28707160.html Sent from the PostGIS - User mailing list archive at Nabble.com. ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
