Re: [postgis-users] install postgis 2 linux
On 09/22/2012 03:42 PM, Icadedt wrote: i would like to install postgis 2 in linux centos 6 my source folder is /usr/local/postgis-2.0.1 when i execute ./configure , the return message is : checking for geos-config... no configure: error: could not find geos-config within the current path. You may need to try re-running configure with a --with-geosconfig parameter. my geos-config file is in /usr/local/geos-3.3.3/tools, so i execute ./configure --with-geosconfig=/usr/local/geos-3.3.5/tools/geos-config but i have this error message: Using user-specified geos-config file: /usr/local/geos-3.3.3/tools/geos-config checking GEOS version... 3.3.3 checking geos_c.h usability... no checking geos_c.h presence... no checking for geos_c.h... no configure: error: could not find geos_c.h - you may need to specify the directory of a geos-config file using --with-geosconfig Please help me , thanks in advance Do you have two versions of GEOS on your system? It looks like you may have installed 3.3.3 and then also 3.3.5; perhaps this is confusing to the configure script. I do this by compiling each of the libraries in /usr/local/src/library-name, so first I download the latest source, unpack them in /usr/local/src, and build from there, like this: cd /usr/local/src tar xzf ~/proj-4.8.0.tar.gz cd proj-4.8.0 ./configure make make install /sbin/ldconfig With the default configure, it may help to have a file named /etc/ld.so.conf.d/local.conf containing the one line /usr/local/lib then cd /usr/local/src tar xjf ~/geos-3.3.5.tar.bz2 cd geos-3.3.5 ./configure make make install /sbin/ldconfig and cd /usr/local/src tar xzf ~/gdal-1.9.1.tar.gz cd gdal-1.9.1 ./configure make make install /sbin/ldconfig then install PostGIS the same way. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email:pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Question on datum names
Thanks, Frank! I conclude there is little to lose in using ESRI's names for projection, datum, and spheroid, so that my .prj files will work without modification in ArcGIS. I'm puzzled that these texts, evidently a controlled vocabulary lacking formal standardization, play such a strong role, but if it makes things work and doesn't break much, it's clearly a better approach. Peter On 05/29/2012 05:56 PM, Frank Warmerdam wrote: > Peter, > > I agree that it is somewhat perverse to use the .prj extension if you > aren't going to match ArcGIS PE strings. Either call it something > else (like .pgwkt for instance) or transform it. The GDAL/OGR > packages' OGRSpatialReference class includes a morphToESRI() method > that will convert OGC/PostGIS/OGR Well Known Text to ESRI PE String > format reasonably well. > > On Tue, May 29, 2012 at 2:45 PM, Peter N. Schweitzer > wrote: >> On the web site from which I distribute spatial data, I provide shapefiles >> with projection information as a .prj file. I've drawn the contents of >> these prj files from the srtext field of the spatial_ref_sys table. >> >> A user has pointed out to me that this is inconvenient for people running >> ArcGIS because ArcGIS expects to see different values as the name of the >> coordinate system and the datum. I have not seen a standard that specifies >> these names. Is there one? > > Well, the defacto standard is whatever ArcGIS does. They do publish > various information on this but it isn't a "standard" in the normal sense of > that world. Note that OGC's Well Known Text format was an adaption of > ESRI PE Strings - hence the similar but not the same nature. > > Best regards, > Frank > >> It looks like I could change my .prj files to fit ArcGIS without much >> trouble. >> But would this change break other applications? Are there GIS applications >> other than ArcGIS that rely strongly on these names? How do others support >> portability of projection information in downloadable data using the >> shapefile >> format? >> >> Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Question on datum names
On the web site from which I distribute spatial data, I provide shapefiles with projection information as a .prj file. I've drawn the contents of these prj files from the srtext field of the spatial_ref_sys table. A user has pointed out to me that this is inconvenient for people running ArcGIS because ArcGIS expects to see different values as the name of the coordinate system and the datum. I have not seen a standard that specifies these names. Is there one? It looks like I could change my .prj files to fit ArcGIS without much trouble. But would this change break other applications? Are there GIS applications other than ArcGIS that rely strongly on these names? How do others support portability of projection information in downloadable data using the shapefile format? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] How to Store Metadata?
On 06/24/2011 09:02 AM, Brett Antonides wrote: Could someone please tell me or send me a link describing how to best store ISO 19115/19139 metadata with my spatial data in PostGIS? Ultimately, the data will be stored in PostGIS, published via GeoServer, and cataloged in GeoNetwork. I know I can just load the metadata into GeoNetwork, but I'd rather store it in the database so it doesn't get lost if data is migrated to another server. I'm hoping someone has already cracked this nut. I tried searching for the answer, but Google failed me (or I failed Google). Either way I'd appreciate any help you can provide. PostgreSQL has an XML type; you could store the metadata in an inventory table, like Stephen Woodbridge suggests, but with the column containing the metadata as type "XML". Then if you wish you can query that information using the xpath() function. I have not used that specific function in my work; instead I simply retrieve the XML type and transform it using an XSLT within PHP. But I'm sure there are lots of different ways to handle this. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] A way to split polygons?
Just wanted to report to the list that I seem to have successfully applied the tiling idea to these geologic map units, by creating a separate table containing only those polygons where ST_NPoints(the_geom) > 1, a table containing tiles that are 1/7th of a degree square, and a third table containing the intersection of the complex polygons with the tiles. By marking, in the original polygon table, those polygons for which I have tiled versions, I am now able to generate KML that is simple enough for Google Earth to display. I'm happy about this because this is a problem that has been following me for several years now--every once in a while I would receive email from a user inquiring about polygons that weren't displaying properly in Google Earth. A proper understanding and application of PostGIS's ST_Intersects and ST_Intersection functions, coupled with some bookkeeping, has made this solution possible. So for any who are interested, the end result is the collection of KML files linked from http://tin.er.usgs.gov/geology/state/kml/ or from individual pages describing the state geologic map compilation, from http://tin.er.usgs.gov/geology/state/ There remains to be explored the worthwhile suggestion of generating lower-resolution versions of these data for use with KML regions, to speed the display within Google Earth. For now, however, these data seem (to me) to render readily enough. Thanks to those from this list who offered suggestions towards solving this problem. Peter On 03/03/2011 03:44 PM, Peter N. Schweitzer wrote: At http://tin.er.usgs.gov/geology/state/ and pages below it, I provide geologic map units for US states in KML for use within Google Earth. These are stored in PostgreSQL (9.0.2) with PostGIS (1.5.2). My problem is that many of the larger geologic units are represented as polygons that have a large number of vertices, often with many interior rings. Google Earth doesn't want to display polygons that have 100,000 vertices (I think the actual limit is lower, but I don't know what it is.) So my geologic maps have large irregular holes in them when viewed in Google Earth. Is there a way, using PostGIS functions, to split these polygons so that the resulting polygons have fewer vertices and thus would appear as expected in Google Earth? It seems to me one possibility would be to intersect these large polygons with Box2D's whose vertical dimensions were, say, one or two degrees. But I don't yet see how to carry this operation out. Can anyone offer suggestions as to how this might be done? Here are some of the characteristics of the data. The principal table containing the polygons is named geol_poly; the field unit_link is a relational key to other, more interesting data, and the_geom comes through shp2pgsql. select unit_link,ST_NPoints(the_geom) npt,ST_NumGeometries(the_geom) ng, ST_NumInteriorRings(the_geom) ni from geol_poly order by npt desc; unit_link | npt | ng | ni -+++-- FLwater;0 | 451759 | 1 | 8945 PAPAa;6 | 319192 | 1 | 1235 PAPAcg;6 | 216653 | 1 | 925 ALwater;0 | 205251 | 1 | 108 OHPAc;0 | 201310 | 1 | 842 OHPAm;0 | 200763 | 1 | 895 OHPAap;0 | 196422 | 1 | 1207 MNOl;0 | 188753 | 1 | 107 MNCu;0 | 165061 | 1 | 86 TNObh;6 | 152421 | 1 | 825 PAPAp;6 | 144889 | 1 | 324 MOOjc;0 | 144721 | 1 | 144 MOMk;0 | 128731 | 1 | 290 WVPAk;0 | 128402 | 1 | 934 TXKed;0 | 124666 | 1 | 720 TNMfp;10 | 122021 | 1 | 117 OHMlc;0 | 116993 | 1 | 731 TNMfp;10 | 113034 | 1 | 406 MOOr;0 | 109195 | 1 | 136 PAPAm;6 | 105906 | 1 | 395 PAPAcc;6 | 105798 | 1 | 447 WVPAm;0 | 99944 | 1 | 474 CAQ;0 | 97086 | 1 | 455 WVPAc;0 | 94277 | 1 | 455 MNOm;0 | 93054 | 1 | 53 PAPPAw;0 | 89974 | 1 | 218 TNOca;6 | 89292 | 1 | 564 WVPAa;0 | 89182 | 1 | 504 MOOr;0 | 87103 | 1 | 171 MOOg;0 | 85660 | 1 | 277 Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] A way to split polygons?
Arnold, Thanks very much, I think this is something that I can try out. Seems like the resulting table could co-exist with the original, and when I need tiled polygons, I can use the tiled version. These data are expected to change only rarely, so that may suffice. I do appreciate your willingness to spell it out for me in detail. Sometimes it helps me to see these techniques as others might do them. Peter On 03/03/2011 07:03 PM, Arnold Helmut Engelmann wrote: If you want to go the tiling route and want to try that: Create a layer of tiles (boxes) at the size you want. Then run the following query: CREATE TABLE tiled_geo_units as SELECT ST_Intersection(a.geometry, b.geometry) AS geometry, a.*, b.* FROM geo_units as a, tiles as b WHERE ST_Intersects(a.geometry, b.geometry) Where "geo_units" is the table with your geological units, and "tiles" is the table of boxes you created. This will intersect both layers and split the polygons at the tile boundaries. You can also add to the WHERE clause if you want to filter out just the "large" polygons, otherwise this will tile all your polygons. For this ST_NPoints will probably useful. -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] A way to split polygons?
On 03/03/2011 04:00 PM, pcr...@pcreso.com wrote: It sounds like you are wanting to tile your polygons. Not really ideal, as each polygon is rendered via tiles, so you need to render them without borders to hide the tiles, then often plot the border as well, which still has all the vertices. Lots more work. Hmmm. But in my KML, I'm not drawing the boundaries, so perhaps that disadvantage doesn't cause trouble in this situation? You might look at simplifying your polygons to reduce the number of vertices in each. If you manage your data topologically, this process will work better at retaining shared boundaries. Mike Toews has suggested ST_Simplify or ST_SimplifyPreserveTopology, but I'm unsure of what value to use for the tolerance. The CRS is geographic, not projected. If you can use Google to provide vector zoom layers, then as you zoom in you can get less & less simplified versions... just like pyramid'ed rasters. Zoomed out you can't see so don't provide the unnecessary detail. Use Google? I don't understand--is there some service they provide which might be used for data like these? Or are you referring to a way to describe the data in KML that I'm not familiar with? Either is plausible--I'm not being snarky here! I'm just writing KML with a PHP script that queries the PostgreSQL db, and have used these technologies in only simple ways so far. So when I say "Google" I mean only that the people who use these data typically open them with Google Earth, at least, those who experience this problem report it so. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] A way to split polygons?
At http://tin.er.usgs.gov/geology/state/ and pages below it, I provide geologic map units for US states in KML for use within Google Earth. These are stored in PostgreSQL (9.0.2) with PostGIS (1.5.2). My problem is that many of the larger geologic units are represented as polygons that have a large number of vertices, often with many interior rings. Google Earth doesn't want to display polygons that have 100,000 vertices (I think the actual limit is lower, but I don't know what it is.) So my geologic maps have large irregular holes in them when viewed in Google Earth. Is there a way, using PostGIS functions, to split these polygons so that the resulting polygons have fewer vertices and thus would appear as expected in Google Earth? It seems to me one possibility would be to intersect these large polygons with Box2D's whose vertical dimensions were, say, one or two degrees. But I don't yet see how to carry this operation out. Can anyone offer suggestions as to how this might be done? Here are some of the characteristics of the data. The principal table containing the polygons is named geol_poly; the field unit_link is a relational key to other, more interesting data, and the_geom comes through shp2pgsql. select unit_link,ST_NPoints(the_geom) npt,ST_NumGeometries(the_geom) ng, ST_NumInteriorRings(the_geom) ni from geol_poly order by npt desc; unit_link| npt | ng | ni -+++-- FLwater;0 | 451759 | 1 | 8945 PAPAa;6 | 319192 | 1 | 1235 PAPAcg;6| 216653 | 1 | 925 ALwater;0 | 205251 | 1 | 108 OHPAc;0 | 201310 | 1 | 842 OHPAm;0 | 200763 | 1 | 895 OHPAap;0| 196422 | 1 | 1207 MNOl;0 | 188753 | 1 | 107 MNCu;0 | 165061 | 1 | 86 TNObh;6 | 152421 | 1 | 825 PAPAp;6 | 144889 | 1 | 324 MOOjc;0 | 144721 | 1 | 144 MOMk;0 | 128731 | 1 | 290 WVPAk;0 | 128402 | 1 | 934 TXKed;0 | 124666 | 1 | 720 TNMfp;10| 122021 | 1 | 117 OHMlc;0 | 116993 | 1 | 731 TNMfp;10| 113034 | 1 | 406 MOOr;0 | 109195 | 1 | 136 PAPAm;6 | 105906 | 1 | 395 PAPAcc;6| 105798 | 1 | 447 WVPAm;0 | 99944 | 1 | 474 CAQ;0 | 97086 | 1 | 455 WVPAc;0 | 94277 | 1 | 455 MNOm;0 | 93054 | 1 | 53 PAPPAw;0| 89974 | 1 | 218 TNOca;6 | 89292 | 1 | 564 WVPAa;0 | 89182 | 1 | 504 MOOr;0 | 87103 | 1 | 171 MOOg;0 | 85660 | 1 | 277 Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Polygon from point query
On 12/28/2010 02:49 PM, Poynter, David wrote:
This is probably an easy one, but being a PostGIS newb I've been spinning my
wheels and haven't the google fu to locate an answer, so here goes...
I have a table of counties from the state (county) and I'm creating a point to
insert in another table and I would like to find the county the point falls in.
I think I should be able to do it in one query rather than looping thru county
by county, but I can't seem to put it together.
SELECT county_nam FROM county WHERE ?
I've been looking at ST_Within() and think the answer lies with it somehow,
thanks for any clues...
I do this in PHP, and am using a query like this:
select fips from county
where the_geom && PointFromText('POINT($longitude $latitude)',4269)
and ST_within(PointFromText('POINT($longitude $latitude)',4269),the_geom)
Since this is a string in PHP, the X coordinate will go where I've
written $longitude and the Y coordinate will go where I've written
$latitude.
The county table in this case is the countyp020 shapefile drawn from
the US National Atlas at nationalatlas.gov. In my case what I want is
the FIPS code of the county.
You can actually try this out online using syntax like this:
http://tin.er.usgs.gov/atlas/point-xml.php?latitude=39&longitude=-77
That service will run your point against a variety of other base polygon
layers, as you can see.
Peter
--
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov
<http://geology.usgs.gov/peter/>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Trouble after upgrade to 1.4.0
Paragon Corporation wrote: There was another missing cast. CREATE CAST (box3d_extent AS geometry) WITH FUNCTION st_geometry(box3d_extent) AS IMPLICIT; Leo, That did the trick. Thanks! Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] Trouble after upgrade to 1.4.0
Paragon Corporation wrote: No,but it looks like you are just being bitten by the missing autocast in the upgrade script which I think we have fixed in 1.4.1 See my comment here http://trac.osgeo.org/postgis/ticket/223 So short answer -- your problems should be solved if you run the below CREATE CAST (box3d_extent AS box3d) WITH FUNCTION st_box3d_extent(box3d_extent) AS IMPLICIT; There is another problem I ran into I describe which hopefully I'm the only one in the world affected by this other change. Regina, Thanks for the pointer. I could execute that create cast function but that didn't eliminate the error. Following a comment in the ticket, I now write select ST_Box2d(ST_Transform(ST_SetSRID(ST_Extent(the_geom)::box3d,4267),3395)) from and this works without error. Is this what you would expect? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Trouble after upgrade to 1.4.0
I just upgraded from 8.3.7/1.3.5 to 8.4.1/1.4.0 I now get an error when running the following query: select ST_Box2d(ST_Transform(ST_SetSRID(ST_Extent(the_geom),4267),3395)) from ingeol_poly ERROR: function st_setsrid(box3d_extent, integer) does not exist LINE 1: select ST_Box2d(ST_Transform(ST_SetSRID(ST_Extent(the_geom),... ^ HINT: No function matches the given name and argument types. You might need to add explicit type casts. But I can do a number of ST_ functions, and mapserver seems to work with postgis/postgresql. So I assume I'm using the wrong combination of magic words to get the information I want from the database. What I'm trying to do is get the extent, in mercator, of all of the polygons in a layer "ingeol_poly" whose native coordinate system is geographic NAD27. Corrections of my misunderstanding would be very helpful! Here's the postgis_full_version(): sgmc=# select postgis_full_version(); POSTGIS="1.4.0" GEOS="3.1.1-CAPI-1.6.0" PROJ="Rel. 4.7.1, 23 September 2009" USE_STATS Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Mark Cave-Ayland wrote:
Peter N. Schweitzer wrote:
(cut)
Peter
I recently had this problem with packages downloaded from the opensuse
repository. Once I hand built and installed proj with this "@null"
patch the problem went away.
Folks,
I have not followed this discussion closely, but I am pretty sure adding
@null at the end of the list just allows pj_transform() to "succeed"
if it does not find a transform file. That is, you are just masking
the fact that no datum shift file is found, and the final results will
be off by the amount of the datum shift - often a matter of hundreds of
meters for NAD27/NAD83 shifts.
Are you sure this is what you want?
In some applications it wouldn't matter (ie. weather scale work), but at
others it will completely invalidate your work spatially speaking.
Frank,
I think I may have encountered this when converting data that are
generally
old (mostly based on pre-1980 maps) to NAD83. I assume that those points
located in North America would have used NAD27 (although mostly these are
not high precision locations); for points located in other parts of the
world, I have no datum information at all. To make the PostGIS ingest
happy, I typically tell shp2pgsql that the CRS of the shapefile is NAD27
geographic in this case.
Most PostGIS functions operating on two geometries (ST_Intersects, for
example) require the geometries to have the same SRID. That's why I
think I need to specify and keep track of the SRID for every table.
So my hypothesis--please help me understand how wrong this is--is that
the
@null has the effect of keeping proj going when I project a point that is
not in the areas covered by the nad27-to-nad83 conversion tables. I have
to admit, as you probably suspect already, that I really don't know this
stuff very well. And since the data are not highly accurate in any case,
the difference won't matter much in any analysis of the converted data.
But this is what I'm thinking. Your counsel would be welcome!
Peter
Note that with PostGIS 1.4 you can change this behaviour yourself by
simply altering the spatial_ref_sys table entries directly if you
require. This is probably a better solution than altering the PROJ.4
behaviour for everything on your machine. See the 1.4 manual for more
details:
http://postgis.refractions.net/documentation/manual-1.4/ST_Transform.html.
I also agree with Frank that this is something that you want to be very
careful with.
It looks to me like it does what I want. Taking two points, one inside
and the other outside North America, I have
psql> select ST_AsEWKT(ST_Transform(PointFromText('POINT(-77.55
39.09)',4267),4269));
st_asewkt
-
SRID=4269;POINT(-77.5497126443548 39.0901066943327)
(1 row)
psql> select ST_AsEWKT(ST_Transform(PointFromText('POINT(77.55
39.09)',4267),4269));
st_asewkt
-
SRID=4269;POINT(77.55 39.090009235)
(1 row)
If I recall correctly, before I added @null, if I executed the second query,
I would get an error.
I have to say that datum transformations are almost as confusing and frustrating
as character encoding problems!
Peter
--
Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192)
(703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov
<http://geology.usgs.gov/peter/>
___
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Frank Warmerdam wrote: Don wrote: Peter N. Schweitzer wrote: I was able to trace the problem to a file in the proj source code. in proj-4.6.1/src/pj_datums.c 87,88c87,88 < "NAD27", "nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat", < "clrk66", --- "NAD27","nadgri...@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat,@null", "clrk66", I don't recall when I added the ",@null" to the nadgrids= line, but I think it was in response to someone else's urging. And adding it to the current source causes proj to correctly locate the conversion files. I don't know whether this is a bug in proj or a peculiarity of the systems where I've deployed it. Thanks again for your help! Peter I recently had this problem with packages downloaded from the opensuse repository. Once I hand built and installed proj with this "@null" patch the problem went away. Folks, I have not followed this discussion closely, but I am pretty sure adding @null at the end of the list just allows pj_transform() to "succeed" if it does not find a transform file. That is, you are just masking the fact that no datum shift file is found, and the final results will be off by the amount of the datum shift - often a matter of hundreds of meters for NAD27/NAD83 shifts. Are you sure this is what you want? In some applications it wouldn't matter (ie. weather scale work), but at others it will completely invalidate your work spatially speaking. Frank, I think I may have encountered this when converting data that are generally old (mostly based on pre-1980 maps) to NAD83. I assume that those points located in North America would have used NAD27 (although mostly these are not high precision locations); for points located in other parts of the world, I have no datum information at all. To make the PostGIS ingest happy, I typically tell shp2pgsql that the CRS of the shapefile is NAD27 geographic in this case. Most PostGIS functions operating on two geometries (ST_Intersects, for example) require the geometries to have the same SRID. That's why I think I need to specify and keep track of the SRID for every table. So my hypothesis--please help me understand how wrong this is--is that the @null has the effect of keeping proj going when I project a point that is not in the areas covered by the nad27-to-nad83 conversion tables. I have to admit, as you probably suspect already, that I really don't know this stuff very well. And since the data are not highly accurate in any case, the difference won't matter much in any analysis of the converted data. But this is what I'm thinking. Your counsel would be welcome! Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostgreSQL 8.3.8 and 8.4.1 out
Mark Cave-Ayland wrote: As of PostGIS 1.4, you can now upgrade both PostgreSQL and PostGIS to the latest X.Y.A to X.Y.B without running any upgrade scripts. So you can simply recompile and re-install PostgreSQL, restart the server and everything should just work as before, with the benefit that you have any additional bug fixes included. Just to clarify the point-- If I have versions earlier than PostGIS 1.4 and PostgreSQL 8.4, I need to run one of the upgrade scripts, right? (I am running 1.3.5/8.3.7) Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] PostGIS-PostgreSQL
Chris Hermansen wrote: I should have mentioned that it's not considered good practice to have more than one geometry column per table, and hence more than one geometry object per row. This makes sense if you think of rows as representational instances of real world objects. Hmmm. I'm storing two geometry columns, because in one I have the geographic (unprojected) coordinates, and in the other the coordinates in some projection. This is to support several different map interfaces some of which are projected, others not. Since the points don't change frequently, I can generate the projected coords once and then simply use them rather than recalculate them on every web hit. It's denormalized, but seems sensible to me. Would you disagree with this method? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] postgis libraries not found
tla...@gwdg.de wrote: Fehler = Error: could not load library: »/usr/lib/pgsql/liblwgeom.so«: libgeos_c.so.1: cannot open shared object file: File or directory not found. However, /usr/lib/pgsql/liblwgeom.so exists and libgeos_c.so.1 is in /usr/local/lib. Postgis configure script has found the paths for geos and proj. Torsten, My first guess is that you need to run ldconfig so that the system will know where to find libgeos_c.so. You probably know to do createlang plpgsql before loading lwpostgis.sql, but if you had skipped that step, that could cause trouble too. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] Does Slony-I work with PostGIS data?
I read in its documentation that Slony-I does not support replication of large objects. Would that exclude the geometry columns used by PostGIS, and therefore make Slony-I an inappropriate choice for replicating spatial databases held in PostgreSQL/PostGIS clusters? Or do others use Slony-I successfully to replicate these databases? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Frank Warmerdam wrote: Adding @null to the end essentially means that if all else fails, just apply a null transformation and don't complain if the null file isn't found. Frank, Thanks, I figured it was an escape hatch of sorts. What worried me was that the error message appeared, implying that the error condition occurred, which could mean that my computed coordinates were wrong. I still don't understand why it said there was an error, and worried that taking away its ability to complain only covered up a real problem. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Dylan Beaudette wrote: Looks close to the output from proj4 above. Thoughts? Dylan, Thanks for showing me how to check the calculations. I get identical results using my copies of cs2cs and postgis, on both systems. I conclude from this that the effect of adding @null to the definition of NAD27 in pj_datums.c is that it somehow eliminates the error message but doesn't render the results incorrect. I don't pretend to understand why this is so, but I'm happy to proceed with this configuration. Thanks again for your help! Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: pschweit...@usgs.gov <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Dylan Beaudette wrote: Strange. I have never modified that code before, and regularly get the correct output... I will post back with a similar example that causes PostGIS to throw the '-38' error. Dylan, Another correspondent indicated to me that when he applied this change, he got different, better results even though he wasn't seeing this specific error message (perhaps because he wasn't at the psql prompt when the transform operation occurred). We're both running Linux. How do you know what the correct output is? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: [EMAIL PROTECTED] <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Richard Greenwood wrote: On Mon, Dec 8, 2008 at 12:19 PM, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote: Richard Greenwood wrote: On Thu, Dec 4, 2008 at 1:19 PM, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote: Hello, I have two PostgreSQL installations. One uses 8.3.3 with PostGIS 1.3.3, GEOS 3.0.1, and PROJ 4.6.1 (with proj-datumgrid-1.4). With it I am able to run a command like update county set nad27_geom=ST_Transform(the_geom,4267); My newer installation uses 8.3.5 with PostGIS 1.3.4, GEOS 3.0.3, and PROJ 4.6.1. With this system I get the error message WARNING: transform: -38 (failed to load NAD27-83 correction file) ERROR: transform: couldn't project point: -38 (failed to load NAD27-83 correction file) I know that proj-datumgrid-1.4.zip must be unzipped in the nad/ directory of proj-4.6.1 PRIOR to running configure. I have done this. I have also recompiled and reinstalled proj, GEOS, and PostGIS in that order, running ldconfig at the end of each step. The directory /usr/local/share/proj on each of these systems is identical. I've tried recreating the database cluster, starting and stopping the database instance, rebooting the machine, dropping and rebuilding the spatial database, all to no avail. So I'm looking for some setting that I may have missed, some environment variable, or some trick to tell libproj.so.0.5.5 where its transform files should go. Both systems run Slackware 12.1. I'm at wit's end. Any clues? Pete PROJ_LIB is an environment variable that points to the directory containing grid shift files and EPSG parameter files. The grid shift files are binary and platform specific. Is it possible that you are using Windows grid shift files on a Linux system? You could also rule out issues related to the different versions of Postgres and PostGIS on you two systems by testing at the command line with the cs2cs utility which is a part of Proj. Rich, Thanks for your counsel. The example using cs2cs from its documentation worked the same on both systems, executed from the command line. I believe the grid shift files are slightly different, even though I thought I had installed the same versions. As a test, I copied the /usr/local/share/proj directory from the older system (the one that does the datum shift without complaint) to the newer one, and the ST_Transform completes without error. So I believe that is the source of the problem. But there is only one link on http://trac.osgeo.org/proj/ for the datum shift file package. If the package is OS-specific I would expect to see more than one. So I am puzzled and worried that next time I may face the same problem again. Peter The files in http://svn.osgeo.org/metacrs/proj/trunk/proj/nad/ are ASCII. In the nad directory, you need to do: ./configure make install to create the binary grid shift files that proj actually uses. (Proj doesn't read the ASCII files). And I'm not sure that the config-make-install of the proj program does the nad directory. Rich Many thanks to Rich and Dylan for helpful replies. I was able to trace the problem to a file in the proj source code. in proj-4.6.1/src/pj_datums.c 87,88c87,88 < "NAD27","[EMAIL PROTECTED],@alaska,@ntv2_0.gsb,@ntv1_can.dat", < "clrk66", --- "NAD27","[EMAIL PROTECTED],@alaska,@ntv2_0.gsb,@ntv1_can.dat,@null", "clrk66", I don't recall when I added the ",@null" to the nadgrids= line, but I think it was in response to someone else's urging. And adding it to the current source causes proj to correctly locate the conversion files. I don't know whether this is a bug in proj or a peculiarity of the systems where I've deployed it. Thanks again for your help! Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: [EMAIL PROTECTED] <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
Re: [postgis-users] NAD conversion problem
Richard Greenwood wrote: On Thu, Dec 4, 2008 at 1:19 PM, Peter N. Schweitzer <[EMAIL PROTECTED]> wrote: Hello, I have two PostgreSQL installations. One uses 8.3.3 with PostGIS 1.3.3, GEOS 3.0.1, and PROJ 4.6.1 (with proj-datumgrid-1.4). With it I am able to run a command like update county set nad27_geom=ST_Transform(the_geom,4267); My newer installation uses 8.3.5 with PostGIS 1.3.4, GEOS 3.0.3, and PROJ 4.6.1. With this system I get the error message WARNING: transform: -38 (failed to load NAD27-83 correction file) ERROR: transform: couldn't project point: -38 (failed to load NAD27-83 correction file) I know that proj-datumgrid-1.4.zip must be unzipped in the nad/ directory of proj-4.6.1 PRIOR to running configure. I have done this. I have also recompiled and reinstalled proj, GEOS, and PostGIS in that order, running ldconfig at the end of each step. The directory /usr/local/share/proj on each of these systems is identical. I've tried recreating the database cluster, starting and stopping the database instance, rebooting the machine, dropping and rebuilding the spatial database, all to no avail. So I'm looking for some setting that I may have missed, some environment variable, or some trick to tell libproj.so.0.5.5 where its transform files should go. Both systems run Slackware 12.1. I'm at wit's end. Any clues? Pete PROJ_LIB is an environment variable that points to the directory containing grid shift files and EPSG parameter files. The grid shift files are binary and platform specific. Is it possible that you are using Windows grid shift files on a Linux system? You could also rule out issues related to the different versions of Postgres and PostGIS on you two systems by testing at the command line with the cs2cs utility which is a part of Proj. Rich, Thanks for your counsel. The example using cs2cs from its documentation worked the same on both systems, executed from the command line. I believe the grid shift files are slightly different, even though I thought I had installed the same versions. As a test, I copied the /usr/local/share/proj directory from the older system (the one that does the datum shift without complaint) to the newer one, and the ST_Transform completes without error. So I believe that is the source of the problem. But there is only one link on http://trac.osgeo.org/proj/ for the datum shift file package. If the package is OS-specific I would expect to see more than one. So I am puzzled and worried that next time I may face the same problem again. Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: [EMAIL PROTECTED] <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
[postgis-users] NAD conversion problem
Hello, I have two PostgreSQL installations. One uses 8.3.3 with PostGIS 1.3.3, GEOS 3.0.1, and PROJ 4.6.1 (with proj-datumgrid-1.4). With it I am able to run a command like update county set nad27_geom=ST_Transform(the_geom,4267); My newer installation uses 8.3.5 with PostGIS 1.3.4, GEOS 3.0.3, and PROJ 4.6.1. With this system I get the error message WARNING: transform: -38 (failed to load NAD27-83 correction file) ERROR: transform: couldn't project point: -38 (failed to load NAD27-83 correction file) I know that proj-datumgrid-1.4.zip must be unzipped in the nad/ directory of proj-4.6.1 PRIOR to running configure. I have done this. I have also recompiled and reinstalled proj, GEOS, and PostGIS in that order, running ldconfig at the end of each step. The directory /usr/local/share/proj on each of these systems is identical. I've tried recreating the database cluster, starting and stopping the database instance, rebooting the machine, dropping and rebuilding the spatial database, all to no avail. So I'm looking for some setting that I may have missed, some environment variable, or some trick to tell libproj.so.0.5.5 where its transform files should go. Both systems run Slackware 12.1. I'm at wit's end. Any clues? Peter -- Peter N. Schweitzer (MS 954, U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 FAX: (703) 648-6252 email: [EMAIL PROTECTED] <http://geology.usgs.gov/peter/> ___ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
