[GRASS5] [bug #745] (grass) v.reclass.pg man page bears little resemblence to v.reclass.pg code!

[Request Tracker]

this bug's URL: http://intevation.de/rt/webrt?serial_num=745
-------------------------------------------------------------------------

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.obj_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.


-------------------------------------------- Managed by Request Tracker