[GRASSLIST:5941] basic projection problem

I am trying to project some tiger line data (which I have been told it projectionless)
from lat long in it's current location into a new location with is UTM zone 10. I created the
new UTM location but when I tried to use v.proj from the new location to pull the old lat long map into a new location, I got the following error:

cannot initialize pj
cause: elliptical usage required

HELP!

Schuyler Fishman
Schuylerfish@earthlink.net
www.mindlikesky.com

Which version of GRASS? Did you try the latest CVS (I fixed some bugs
yesterday)? Can you provide the output of g.projinfo for your two
locations?

Paul

On Tue, 1 Apr 2003, Schuyler Fishman wrote:

I am trying to project some tiger line data (which I have been told it
projectionless)
from lat long in it's current location into a new location with is UTM
zone 10. I created the
new UTM location but when I tried to use v.proj from the new location
to pull the old lat long map into a new location, I got the following
error:

cannot initialize pj
cause: elliptical usage required

HELP!

Schuyler Fishman
Schuylerfish@earthlink.net
www.mindlikesky.com

I am having some trouble importing scanned maps with
r.in.tiff.

The trouble occurs with GRASS 5pre3 for X on
WindowsXP/Cygwin but not with GRASS 5.0.0 on Linux. In the
5pre3 installation, I get the following error message:

WARNING: G_set_window(): Illegal latitude for North
ERROR: couldn't set cellhd.

Is this a Windows problem or a pre3 problem? What do you
recommend?

On the latter setup, r.in.tiff reads in the image and then I
can use i.group, i.target, i.points, i.rectify. One problem
I do have is that the scanned image is distorted in the
upper left panel of the i.points interface. I would welcome
suggestions on this problem as well.

Thank you and best regards,

Michael

Michael Ash, Assistant Professor
  of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash

On Wed, Apr 02, 2003 at 10:46:35AM -0500, Michael Ash wrote:

I am having some trouble importing scanned maps with
r.in.tiff.

The trouble occurs with GRASS 5pre3 for X on
WindowsXP/Cygwin but not with GRASS 5.0.0 on Linux. In the
5pre3 installation, I get the following error message:

WARNING: G_set_window(): Illegal latitude for North
ERROR: couldn't set cellhd.

Is this a Windows problem or a pre3 problem? What do you
recommend?

A later version of r.in.tiff checks for the projection... An
unreferenced TIFF will have a "region" of 0..width by 0..-height pixels
and a cell size of 1. But, 90 pixels isn't very many...

Solution: (1) Import unreferenced images into an XY location.
(2) Newer r.in.tiff will set the projection to XY for the image if it
doesn't have a TFW (I think, maybe this was not a good idea since most
of the projection info is per LOCATION not data set).

(1) is probably the preferred solution.

--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

Michael Ash wrote:
> I am having some trouble importing scanned maps with
> r.in.tiff [in GRASS 5pre3 for Cygwin/X]

Eric G. Miller wrote:

A later version of r.in.tiff checks for the projection... An
unreferenced TIFF will have a "region" of 0..width by 0..-height pixels
and a cell size of 1. But, 90 pixels isn't very many...

Solution: (1) Import unreferenced images into an XY location.
(2) Newer r.in.tiff will set the projection to XY for the image if it
doesn't have a TFW (I think, maybe this was not a good idea since most
of the projection info is per LOCATION not data set).

(1) is probably the preferred solution.

Thank you very much for the guidance. (1) worked.

I created a new location with XY coordinates and dimensions
that correspond roughly to those of the TIFF file. I ran
r.in.tiff and then g.region and now I have a working raster
map of the scanned map.

(One curiosity: r.in.tiff generated a segmentation fault
until I ran it with the -v (verbose) option, and then it ran
fine.)

BTW, note to new users about what I am up to:

Goal: I want to add some maps scanned from paper to an
existing location/mapset.

I will follow Eric's advice to scan the unreferenced images
into an XY location. I will then use:

i.group to make the map(s) into a single group

i.target to specify the target location/mapset to which the
  newly scanned maps apply (this is how I connect the scanned map in a vanilla XY location
  to an existing location/mapset with lat/long or other coordinates)

i.points to specify points in the scanned map that correspond to known points in the target location/mapset This procedure can be done by coordinates or by point-n-click.

i.rectify to create the new raster map in the desired location/mapset with coordinates that correspond to those specified in i.points.

Best regards,

Michael Ash, Assistant Professor
  of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash

On Wed, Apr 02, 2003 at 06:35:33PM -0500, Michael Ash wrote:

(One curiosity: r.in.tiff generated a segmentation fault
until I ran it with the -v (verbose) option, and then it ran
fine.)

That ain't right. But ... pre3 is somewhat dated. There used to
be a problem with "stack memory size" that could cause r.in.tiff
to segfault immediately at startup, but the -v option shouldn't change
that...

BTW, your procedure sounds about right to me...

--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

I have both postgresql and GRASS working on my linux box.
I can use psql to create, query, delete, etc. postgresql databases.
But so far I cannot get GRASS to talk to postgresql.

I tried the following according to the first-steps tutorial
http://freegis.org/cgi-bin/viewcvs.cgi/~checkout~/grass/src.garden/grass.postgresql/tutorial/index.html

GRASS:~ > g.select.pg -l
g.select.pg: error while loading shared libraries: libpq.so: cannot load shared object file: No such file or directory

I then tried without success:
export POSTGRES_LIB=/usr/local/pgsql/lib

I will be grateful for guidance.

Here is some info about GRASS and postgresql on my system:
GRASS:~ > g.version
GRASS 5.0.0 (August 2002)

GRASS:~ > locate libpq.so
/usr/local/pgsql/lib/libpq.so.3
/usr/local/pgsql/lib/libpq.so.3.0
/usr/local/pgsql/lib/libpq.so

GRASS:~ > ps -ax | grep postmaster
18820 pts/2 S 0:00 /usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/d

Best regards,

Michael Ash

Michael Ash, Assistant Professor
  of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash

Michael Ash wrote:

GRASS:~ > g.select.pg -l
g.select.pg: error while loading shared libraries: libpq.so: cannot load shared object file: No such file or directory

GRASS:~ > locate libpq.so
/usr/local/pgsql/lib/libpq.so.3
/usr/local/pgsql/lib/libpq.so.3.0
/usr/local/pgsql/lib/libpq.so

If you put shared libraries in a non-standard location (i.e. anywhere
other than /lib and /usr/lib), you have to tell the loader. E.g.:

  LD_LIBRARY_PATH=/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or, if LD_LIBRAY_PATH is already defined:

  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or add /usr/local/pgsql/lib to /etc/ld.so.conf then run "ldconfig".

The ld.so(8) man page might have useful information (or it might just
be hopelessly out of date; any references to a.out are ancient
history).

--
Glynn Clements <glynn.clements@virgin.net>

I have now successfully made GRASS and postgresql
communicate. The resolution of the shared library problem
was easy thanks to Glynn Clements and is outlined at the end
of this message.

I have two further questions about postgresql and GRASS:

1) How do I connect attribute data in a postgresql database
table with the map geometry if they do not come from the
same .shp,.shx,.dbf trio? That is, suppose that I have
created a vector map from raw data and I want to create an
associated postgresql table. How do I define a key column
in the table that is associated with shapes in the vector
map? Do I have to register the map or otherwise connect a
file in dig_cats with the postgresql table? Do I have to
give the key column a special name?

To give a simple example, suppose I have created a map of
four neighborhood and would like to highlight the distressed
neighborhoods?

=Vector Map=
Neighborhood
     1
     2
     3
     4

=Table=
Neighborhood Distressed
     1 1
     2 0
     3 0
     4 1

2) I have downloaded some shapefile trios (.shp,.shx,.dbf)
from the U.S. Census (for example rg99_d00.shp,.shx,.dbf)

http://www.census.gov/geo/www/cob/bdy_files.html

I have attempted to import a dbf file using pg.in.dbf

The GRASS-postgresql commands import the file. The columns
are named properly, but the data in the columns are not
properly divided. The values for most of the variables end
up in the first column. (When I examine the dbf file in
Excel, the columns are properly divided.)

Follow-up on the original question:

Michael Ash wrote:
> GRASS:~ > g.select.pg -l
> g.select.pg: error while loading shared libraries: libpq.so: cannot load shared object file: No such file or directory

Glynn Clements gave the following advice, which solved the problem:

If you put shared libraries in a non-standard location (i.e. anywhere
other than /lib and /usr/lib), you have to tell the loader. E.g.:

  LD_LIBRARY_PATH=/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or, if LD_LIBRAY_PATH is already defined:

  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or add /usr/local/pgsql/lib to /etc/ld.so.conf then run "ldconfig".

Best regards,

Michael Ash, Assistant Professor
  of Economics and Public Policy
Department of Economics and CPPA
University of Massachusetts
Amherst, MA 01003
Tel 413-545-6329 Fax 413-545-2921
Email mash@econs.umass.edu
http://people.umass.edu/maash

I have been running GRASS 5.0.0 with postgresql successfully
on Linux, but I just upgraded to 5.0.2 by downloading the
binary from http://grass.ibiblio.org. Unfortunately, the
GRASS/postgresql connection stopped working after the
upgrade. (When I revert to 5.0.0, GRASS/postgresql works
again.) The problem appears to be shared libraries.

GRASS:~ > g.select.pg -l
g.select.pg: error while loading shared libraries: libpq.so.2: cannot load shared object file: No such file or directory

GRASS:~ > locate libpq.so.2
GRASS:~ >

Unlike the previous time (see the effective advice of Glynn
Clements below), when my problem was that I had not informed
the loader of the nonstandard location of the library, I do
not seem to have libpq.so.2 on my system. Is it necessary
to have libpq.so.2? Can libpq.so.3, which I do have (again,
see below), substitute?

I would be grateful for advice.

Best regards,

Michael Ash

Michael Ash wrote:

> GRASS:~ > g.select.pg -l
> g.select.pg: error while loading shared libraries: libpq.so: cannot load shared object file: No such file or directory

> GRASS:~ > locate libpq.so
> /usr/local/pgsql/lib/libpq.so.3
> /usr/local/pgsql/lib/libpq.so.3.0
> /usr/local/pgsql/lib/libpq.so

If you put shared libraries in a non-standard location (i.e. anywhere
other than /lib and /usr/lib), you have to tell the loader. E.g.:

  LD_LIBRARY_PATH=/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or, if LD_LIBRAY_PATH is already defined:

  LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/pgsql/lib
  export LD_LIBRARY_PATH

Or add /usr/local/pgsql/lib to /etc/ld.so.conf then run "ldconfig".

The ld.so(8) man page might have useful information (or it might just
be hopelessly out of date; any references to a.out are ancient
history).

--
Glynn Clements <glynn.clements@virgin.net>

Michael Ash wrote:

I have been running GRASS 5.0.0 with postgresql successfully
on Linux, but I just upgraded to 5.0.2 by downloading the
binary from http://grass.ibiblio.org. Unfortunately, the
GRASS/postgresql connection stopped working after the
upgrade. (When I revert to 5.0.0, GRASS/postgresql works
again.) The problem appears to be shared libraries.

GRASS:~ > g.select.pg -l
g.select.pg: error while loading shared libraries: libpq.so.2: cannot load shared object file: No such file or directory

GRASS:~ > locate libpq.so.2
GRASS:~ >

Unlike the previous time (see the effective advice of Glynn
Clements below), when my problem was that I had not informed
the loader of the nonstandard location of the library, I do
not seem to have libpq.so.2 on my system. Is it necessary
to have libpq.so.2? Can libpq.so.3, which I do have (again,
see below), substitute?

Maybe, maybe not. If a shared library's major version number is
changed, it is normally because the library isn't compatible with the
previous version.

Check whether your Linux distribution offers a "compatibility" package
for the PostgreSQL libraries (i.e. older versions of the libraries).
If not, then you would need to compile GRASS from source code to
obtain binaries which are compatible with your PostgreSQL libraries.

--
Glynn Clements <glynn.clements@virgin.net>