David,
You are correct in your understanding. Here is the error I'm getting:
v.proj input=locations location=ohrfc mapset=tea dbase=/grass/data output=locations
Input Projection Parameters: +proj=latlong +a=6378137 +rf=298.257223563 +no_defs
Input Unit Factor: 1
Output Projection Parameters: +proj=lcc +lat_0=39.0000000000 +lat_1=60.0000000000 +lat_2=30.0000000000 +lon_0=-86.0000000000 +x_0=0.0000000000 +y_0=0.0000000000 +a=6378137 +rf=298.257223563 +no_defs +towgs84=0.000,0.000,0.000
Output Unit Factor: 1
Creating vector file...
DBMI-Postgres driver error:
Cannot select:
select * from locations where 0 = 1
ERROR: relation "locations" does not exist
GRASS_INFO_WARNING(15679,1): Cannot open select cursor: 'select * from locations where 0 = 1'
Looking at this more closely, I think the problem may stem from the issue I describe earlier, namely:
The further question about using v.in.db, the 'key' parameter in the
documentation claims this is a string, which makes since to me, but when
v.in.db is run, GRASS complains that an integer is needed. I'm guessing
the integer that's supplied is the column/field number (beginning with
'1'); if true, this seems to be inconsistent by what the 'x', 'y', and
'z' fields require — just a thought.
In order to get the Postgres table to import into my lat-long location, I put a "1" in the field for the "category column name (string required)"; when I put "lid" in the field, I got an error saying the type was not an integer. It seems GRASS is expecting a string for the field name that has integer as its type. My problem is that none of my fields meet this requirement for the key field, the only column that does, "lid", has type string. So, I think what is happening is that when I try to use v.proj, I get:
GRASS_INFO_WARNING(15679,1): Cannot open select cursor: 'select * from locations where 0 = 1'
Furthermore, when I use the query tool for the points in my lat-long location — while the x,y,z data is correct — all the other category data is the same — for record 1 in my Postgres table.
How do I get around the fact that my database table in Postgres does not have an integer field of unique values? A better question is why does GRASS require the key field to have type integer, when *really* the uniquely identifying field is the ID for a point (for instance).
Tom
David Finlayson wrote:
If I understand you correctly, you have a table in Postgres that
happens to contain x, y coordinates in addition to other attributes
but is not a PostGIS layer. You were able to convert the X,Y points
into a GRASS vector file (points) using v.in.db AND this new vector
file seems to work in the lat long Location.
Now when you try to project the new vector file into a LCC location it
fails. What is the error you are getting? That seems like it should
work.
As a test, have you tried exporting the postgres table as a csv file
(at least pointid, x and y) and then load the vector with v.in.ascii?
You will be able to link the ID, X,Y CSV file back to the original
postgres attribute table using the ID column. Does this simple vector
file project?
David
On 3/16/06, Thomas Adams <Thomas.Adams@noaa.gov> wrote:
David,
Maybe you don't understand. The Postgres table is for points and has the
lat-long location; using v.in.db one is required to identify the x,y
location. The additional attributes are read as well, of course. I can
successfully import the Postgres table into GRASS into my lat-long
location. If I then try to re-project the points into a LCC projection
(from the LCC location), the v.proj does not seem to work. Is this what
you previously understood I was tying to do or do now?
Who would know whether or not this can be done?
Thanks for you r responses…
Tom
David Finlayson wrote:
Ah, I understand now. I'm afraid I can't help you with this. I've only
used databases to hold attribute information not the topology also. I
haven't tried PostGIS yet.
David
On 3/15/06, Thomas Adams <Thomas.Adams@noaa.gov> wrote:
List:
I have a Lat-Long location into which I have successfully imported
points from Postgres (a further question about this further below). What
I want to do is to re-project the points into a Lambert Conic Conformal
location using v.proj. When I try to do this, it does not work — it
seems as though GRASS does not know how to do this. I have been able to
do this successfully with points imported using v.in.ascii. It seems I
am missing something, either conceptually or procedurally…
The further question about using v.in.db, the 'key' parameter in the
documentation claims this is a string, which makes since to me, but when
v.in.db is run, GRASS complains that an integer is needed. I'm guessing
the integer that's supplied is the column/field number (beginning with
'1'); if true, this seems to be inconsistent by what the 'x', 'y', and
'z' fields require — just a thought.
Tom
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams@noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033
--
David Finlayson
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams@noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033
--
David Finlayson
--
Thomas E Adams
National Weather Service
Ohio River Forecast Center
1901 South State Route 134
Wilmington, OH 45177
EMAIL: thomas.adams@noaa.gov
VOICE: 937-383-0528
FAX: 937-383-0033