Details Ticket 745


Comment | Reply | Take | Open


Serial Number 745
Subject v.reclass.pg man page bears little resemblence to v.reclass.pg code!
Area wish
Queue grass
Requestors russo@swcp.com
Owner none
Status resolved
Last User Contact Mon May 28 17:06:16 2001 (7 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Sat Dec 22 09:33:21 2001 (7 yr ago)
Created Fri May 25 19:20:04 2001 (7 yr ago)

Transaction History Ticket 745


Fri, May 25 2001 19:20:04    Request created by guest  
Subject: v.reclass.pg man page bears little resemblence to v.reclass.pg code!
Platform: FreeBSD
Xwindows version: Xfree 3.3.6
Xwindows manager: fvwm2
TclTk version: tcl/tk 8.3
grass downloaded at: Baylor site
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, grass5.0beta11
c compiler name: gcc

v.reclass.pg's man page claims that the "-s sql=inputfile" version it takes a
file of sql select statements and creates a new classification where category
1 is assigned to the results of the first select statement, category 2 is the
results of the second, etc.

A cursory examination of the source code reveals that it does nothing of the
sort.  

All it does is pull in the first 1024 characters of the input file and pass it
to postgres.  It then expects the query to return 2-tuples of the form (fid,category),
and generates an input file for v.reclass with lines of the  form 
  fid = category

So something like:

select distinct roads.fid,rd01ardf.entity_label from roads,rd01ardf where roads.obj_code=rd01ardf.ob
j_code
order by rd01ardf.entity_label,roads.fid;
 
would produce something that v.reclass.pg would expect.  The database on which
this particular query is based is the one that would be produced by v.in.sdts
on a  USGS SDTS file of transportation data, and *should* assign each line a
category based on road type (e.g. trail, primary divided road, etc.).  Unfortunately,
USGS entity_labels for roads are things like 1700201, 1700211, etc., and the
input file for v.reclass  produced by v.reclass.pg ends up looking like:
  650 = 1700201
 1025 = 1700201
 1275 = 1700201
...

It would be *nice* if v.reclass.pg worked as the manpage claimed.  Or if the
man page documented how it really worked.  

Furthermore, the man page for v.reclass.pg seems to have retained vestiges of
its former informix version --- the "retrieve" statement won't work in postgres.
This issue may also relate to some issues I see in the queue (v.reclass.pg saying
something about out of range from PQgetvalue?) --- the select statement must
return TWO fields, an FID and a category, but this isn't explicitly stated in
the man page.  Returning just an FID will lead to an invalid tuple when the code
tries to call PQgetvalue on the second field, hence the error message.
Mon, May 28 2001 17:06:16    Mail sent by mneteler  
Hi,

thanks for the hints - I have adjusted the parameters list so far in CVS (will
appear online tomorrow). You are right that the man pages of all PostgreSQL
tools are in bad condition. Due to lack of time we need a volunteer to
update them. May I kindly invite you to help us?

Eventually contact me personally,

 Markus Neteler
 neteler@geog.uni-hannover.de
Sat, Dec 22 2001 09:33:21    Status changed to resolved by ashevlakov  
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request