[GRASSLIST:213] Re: Question about re-projecting points imported from Postgres

[Thomas Adams]

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 at 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 at 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 at 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 at 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 at noaa.gov

VOICE:	937-383-0528
FAX:	937-383-0033