[GRASS-user] Max length of sql_query in v.extract

Luigi_Ponti · January 27, 2010, 7:35pm

Hello,

Is there a length limit to a "where" sql statement fed to v.extract?

I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.

Thanks for any hints,

Luigi

neteler · January 27, 2010, 11:45pm

On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti <lponti@infinito.it> wrote:

Hello,

Is there a length limit to a "where" sql statement fed to v.extract?

I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.

Could you please try to analyse with
g.gisenv set=DEBUG=3
to identify when it gets lost? And perhaps provide an example
based on the Spearfish or North Carolina data sets?

best
Markus

Luigi_Ponti · January 28, 2010, 12:34pm

On 28/01/2010 00:45, Markus Neteler wrote:

On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti <lponti@infinito.it> wrote:


Hello,

Is there a length limit to a "where" sql statement fed to v.extract?

I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.

Could you please try to analyse with
g.gisenv set=DEBUG=3
to identify when it gets lost? And perhaps provide an example
based on the Spearfish or North Carolina data sets?

Version: WinGRASS-6.4.SVN-r40650-1 (installed in C:\GRASS-64-SVN i.e. no spaces in path; OS Windows 7)
Dataset: North Caroline dataset
Mapset: user1
vector: census_wake2000 (this actually resides in PERMANENT)

Working on the "Cmd >" input box of the wxGUI. I have chosen a case analogous to that where I encountered the error, i.e. a DBF Character field containing 105 different numeric codes (e.g. 050100) one per record:

(note that you can find full debug output in a text file available at the following link:
https://docs.google.com/leaf?id=0B0EpsfMZ-IZYOTJiYWVmNjUtNGYzMC00NDM5LWI1NDYtZTMyNzg3M2NjOThk&sort=name&layout=list&num=50

I thought 20,000+ lines was too much for the mailing list but please advice if had better taken a different course of action.)

### START GRASS CMD HISTORY ###

g.gisenv set=DEBUG=3 (Thu Jan 28 12:12:34 2010) Command finished (0 sec) (Thu Jan 28 12:12:43 2010) v.extract input=census_wake2000 output=census_extract_all_trt2000 where=(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402')
D3/3: Mapset = PERMANENT
D1/3: Vect_open_old(): name = census_wake2000 mapset=
PERMANENT update = 0
D1/3: Vect_set_thresh(): thresh = 0.000000

[...]

D3/3: db_select_int()
D3/3: SQL: SELECT cat FROM census_wake2000 WHERE (TRT2000=
'050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000=
'050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000=
'050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000=
'051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000=
'051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000=
'051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000=
'052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000=
'052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000=
'052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000=
'052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000=
'052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000=
'052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000=
'052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000=
'052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000=
'052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000=
'052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000=
'053101')or(TRT
DBMI-DBF driver error:
SQL parser error: syntax error, unexpected $end processing
''
in statement:
SELECT cat FROM census_wake2000 WHERE (TRT2000='050100')or(T
RT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(T
RT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(T
RT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(T
RT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(T
RT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(T
RT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(T
RT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(T
RT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(T
RT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(T
RT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(T
RT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(T
RT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(T
RT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(T
RT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(T
RT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(T
RT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(T
RT
Error in db_open_select_cursor()
ERROR: Unable select records from table <census_wake2000>
(Thu Jan 28 12:12:45 2010) Command finished (1 sec)

### END GRASS CMD HISTORY ###

But if I do the same with only the first 10 TRT2000 codes, everything seem to work fine:

### START GRASS CMD HISTORY ###

v.extract input=census_wake2000 output=census_extract_all_trt2000 where=(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')
D3/3: Mapset = PERMANENT
D1/3: Vect_open_old(): name = census_wake2000 mapset=
PERMANENT update = 0

[...]

mapset= user1
D1/3: get coor info: C:\cygwin\home\andy/nc_spm_08/user1/vec
tor/census_extract_all_trt2000/coor
D2/3: ftell = 6941
D1/3: Info->size = 6941, Info->mtime = 1264679138
D1/3: dig__write_head()
D1/3: write coor size (6941) to head
D2/3: coor body offset 14
D1/3: Vect_get_thresh(): thresh = 0.000000
D1/3: Vect_write_dblinks(): map =
census_extract_all_trt2000, mapset = user1
D1/3: dbln file: C:\cygwin\home\andy/nc_spm_08/user1/vector/
census_extract_all_trt2000/dbln
D1/3: 1 census_extract_all_trt2000 cat
$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/ dbf
D1/3: Dblinks written
(Thu Jan 28 12:45:51 2010) Command finished (13 sec)

### END GRASS CMD HISTORY ###

And the resulting vector displays ok -- the v.info output is the following:

v.info census_extract_all_trt2000 | Layer: | Mapset: user1 | Location: nc_spm_08 | Database: C:\cygwin\home\andy | Titolo: | Scala della mappa: 1:1 | Formato della mappa: native | Name of creator: helena | Organization: NC OneMap | Dati di origine: |--------------------------- | Type of Map: vector (level: 2) | | Numero di punti: 0 | Numero di linee: 0 | Numero di confini: 41 | Numero di centroidi: 10 | | Map is 3D: No | Number of dblinks: 1 | | Proiezione: | N: 228616.93548384 | E: 645055.16891034 | | Digitization threshold: 0 | Comments: | +--------------------------- (Thu Jan 28 13:12:03 +----------------------------------------------------------------------------+
census_extract_all_trt2000 |
|
|
|
Wake County census tracts 2000 (polygon map) |
|
|
|
|
Tue Nov 7 19:54:38 2006 |
-------------------------------------------------|
|
|
Numero di aree: 10 |
Numero di isolee: 1 |
Numero di facce: 0 |
|
|
|
|
|
Lambert Conformal Conic |
S: 222650.82550162 |
W: 637287.55397511 |
|
|
|
|
-------------------------------------------------+
2010) Command finished (0 sec)

Kind regards,
Luigi

best
Markus

neteler · January 28, 2010, 1:57pm

On Thu, Jan 28, 2010 at 1:34 PM, Luigi Ponti <lponti@infinito.it> wrote:

On 28/01/2010 00:45, Markus Neteler wrote:

On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti <lponti@infinito.it> wrote:

Hello,

Is there a length limit to a "where" sql statement fed to v.extract?

I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.

Could you please try to analyse with
g.gisenv set=DEBUG=3
to identify when it gets lost? And perhaps provide an example
based on the Spearfish or North Carolina data sets?

Version: WinGRASS-6.4.SVN-r40650-1 (installed in C:\GRASS-64-SVN i.e. no
spaces in path; OS Windows 7)
Dataset: North Caroline dataset
Mapset: user1
vector: census_wake2000 (this actually resides in PERMANENT)

Working on the "Cmd >" input box of the wxGUI. I have chosen a case
analogous to that where I encountered the error, i.e. a DBF Character field
containing 105 different numeric codes (e.g. 050100) one per record:

(note that you can find full debug output in a text file available at the
following link:
https://docs.google.com/leaf?id=0B0EpsfMZ-IZYOTJiYWVmNjUtNGYzMC00NDM5LWI1NDYtZTMyNzg3M2NjOThk&sort=name&layout=list&num=50

I thought 20,000+ lines was too much for the mailing list but please advice
if had better taken a different course of action.)

### START GRASS CMD HISTORY ###

g.gisenv set=DEBUG=3
(Thu Jan 28 12:12:34 2010) Command finished (0 sec)
(Thu Jan 28 12:12:43 2010)
v.extract input=census_wake2000 output=census_extract_all_trt2000
where=

[... very long WHERE suppressed...]

(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402')

D3/3: Mapset = PERMANENT
D1/3: Vect_open_old(): name = census_wake2000 mapset=
PERMANENT update = 0
D1/3: Vect_set_thresh(): thresh = 0.000000

[...]

D3/3: db_select_int()
D3/3: SQL: SELECT cat FROM census_wake2000 WHERE (TRT2000=

... first part of very long statement...

'052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000=
'052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000=
'052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000=
'052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000=
'052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000=
'053101')or(TRT
DBMI-DBF driver error:
SQL parser error: syntax error, unexpected $end processing

This looks suspicious:
lib/dbmi/dbmi_client/select.c

int db_select_int(dbDriver * driver, const char *tab, const char *col,
                  const char *where, int **pval)
{
    int type, more, alloc, count;
    int *val;
    char buf[1024];
...
    /* allocate */
    alloc = 1000;
    val = (int *)G_malloc(alloc * sizeof(int));

    if (where == NULL || strlen(where) == 0)
        G_snprintf(buf, 1023, "SELECT %s FROM %s", col, tab);
    else
        G_snprintf(buf, 1023, "SELECT %s FROM %s WHERE %s", col, tab, where);

G_debug(3, " SQL: %s", buf);

db_init_string(&stmt);
db_append_string(&stmt, buf);

I guess that we need to change to dynamic string length allocation here?
The cut string is pretty close to the 1023 chars length.

Markus

Luigi_Ponti · January 28, 2010, 2:27pm

Hi all,

Not sure why this happens, but some of the manual pages of my WinGRASS-6.4.SVN-r40650-1 installation are in English e.g.

v.build.all - Rebuilds topology on all vector maps in the current mapset.

while other are in another (not sure which) language e.g.

v.buffer - Vytvoøí buffer okolo prvkù zadaného typu (plochy musí obsahovat centroid)

Is this a known issue?

Kind regards,

Luigi

Luigi_Ponti · January 28, 2010, 2:39pm

Thanks for your answer, Markus.

On 28/01/2010 14:57, Markus Neteler wrote:

On Thu, Jan 28, 2010 at 1:34 PM, Luigi Ponti <lponti@infinito.it> wrote:


On 28/01/2010 00:45, Markus Neteler wrote:


On Wed, Jan 27, 2010 at 8:35 PM, Luigi Ponti <lponti@infinito.it> wrote:

Hello,

Is there a length limit to a "where" sql statement fed to v.extract?

I am getting an
...
Error in db_open_select_cursor()
...
in the middle of a very long query.

[...]

        v.extract input=census_wake2000 output=census_extract_all_trt2000
where=

[... very long WHERE suppressed...]

(TRT2000='050100')or(TRT2000='050300')or(TRT2000='050400')or(TRT2000='050500')or(TRT2000='050600')or(TRT2000='050700')or(TRT2000='050800')or(TRT2000='050900')or(TRT2000='051000')or(TRT2000='051100')or(TRT2000='051200')or(TRT2000='051400')or(TRT2000='051501')or(TRT2000='051502')or(TRT2000='051600')or(TRT2000='051700')or(TRT2000='051800')or(TRT2000='051900')or(TRT2000='052001')or(TRT2000='052002')or(TRT2000='052101')or(TRT2000='052102')or(TRT2000='052201')or(TRT2000='052202')or(TRT2000='052301')or(TRT2000='052302')or(TRT2000='052401')or(TRT2000='052402')or(TRT2000='052404')or(TRT2000='052405')or(TRT2000='052501')or(TRT2000='052503')or(TRT2000='052504')or(TRT2000='052601')or(TRT2000='052602')or(TRT2000='052603')or(TRT2000='052701')or(TRT2000='052703')or(TRT2000='052704')or(TRT2000='052705')or(TRT2000='052801')or(TRT2000='052802')or(TRT2000='052803')or(TRT2000='052804')or(TRT2000='052805')or(TRT2000='052900')or(TRT2000='053001')or(TRT2000='053002')or(TRT2000='053101')or(TRT2000='053103')or(TRT2000='053104')or(TRT2000='053200')or(TRT2000='053402')or(TRT2000='053403')or(TRT2000='053404')or(TRT2000='053405')or(TRT2000='053406')or(TRT2000='053407')or(TRT2000='053501')or(TRT2000='053505')or(TRT2000='053506')or(TRT2000='053507')or(TRT2000='053508')or(TRT2000='053509')or(TRT2000='053510')or(TRT2000='053512')or(TRT2000='053513')or(TRT2000='053514')or(TRT2000='053515')or(TRT2000='053600')or(TRT2000='053703')or(TRT2000='053706')or(TRT2000='053707')or(TRT2000='053709')or(TRT2000='053710')or(TRT2000='053711')or(TRT2000='053712')or(TRT2000='053713')or(TRT2000='053714')or(TRT2000='053715')or(TRT2000='053716')or(TRT2000='053801')or(TRT2000='053802')or(TRT2000='053900')or(TRT2000='054001')or(TRT2000='054003')or(TRT2000='054004')or(TRT2000='054006')or(TRT2000='054007')or(TRT2000='054008')or(TRT2000='054009')or(TRT2000='054010')or(TRT2000='054102')or(TRT2000='054104')or(TRT2000='054105')or(TRT2000='054106')or(TRT2000='054107')or(TRT2000='054108')or(TRT2000='054109')or(TRT2000='054201')or(TRT2000='054202')or(TRT2000='054301')or(TRT2000='054302')or(TRT2000='054401')or(TRT2000='054402')

Yes, that's very long. Would there be a better way of achieving this in GRASS e.g. via *.db.* commands or is v.extract a wrapper for them, and hence they would fail anyway?
Kind regards,
Luigi

[...]

I guess that we need to change to dynamic string length allocation here?
The cut string is pretty close to the 1023 chars length.

Markus

neteler · January 28, 2010, 2:51pm

Martin: please read on:

On Thu, Jan 28, 2010 at 3:27 PM, Luigi Ponti <lponti@infinito.it> wrote:

Hi all,

Not sure why this happens, but some of the manual pages of my
WinGRASS-6.4.SVN-r40650-1 installation are in English e.g.

v.build.all - Rebuilds topology on all vector maps in the current mapset.

while other are in another (not sure which) language e.g.

v.buffer - Vytvoøí buffer okolo prvkù zadaného typu (plochy musí obsahovat
centroid)

Is this a known issue?

It is a bugfeature: some want it some not. Ideally both English and the
current locale would be used for creating the manual, see enhancement
request: https://trac.osgeo.org/grass/ticket/846

Apparently winGRASS-daily was/is build in CZ locale and NLS active.
Before compilation, the locale settings should be set to English by
defining LANG and LC_MESSAGES variables. IMHO easy to fix
on Martin's server.

Markus

Glynn_Clements1 · January 28, 2010, 6:43pm

Markus Neteler wrote:

    if (where == NULL || strlen(where) == 0)
        G_snprintf(buf, 1023, "SELECT %s FROM %s", col, tab);
    else
        G_snprintf(buf, 1023, "SELECT %s FROM %s WHERE %s", col, tab, where);

    G_debug(3, " SQL: %s", buf);

    db_init_string(&stmt);
    db_append_string(&stmt, buf);

I guess that we need to change to dynamic string length allocation here?
The cut string is pretty close to the 1023 chars length.

AFAICT, the raison d'être for the dbString type was precisely to avoid
this sort of issue. I suggest:

  db_init_string(&stmt);
  db_append_string(&stmt, "SELECT ");
  db_append_string(&stmt, col);
  db_append_string(&stmt, " FROM ");
  db_append_string(&stmt, tab);
  if (where && *where) {
      db_append_string(&stmt, " WHERE ");
      db_append_string(&stmt, where);
  }

Beyond that, maybe we need db_sprintf_string()?

BTW, as we appear to be taking the availability of snprintf() for
granted, maybe it's time to re-write G_asprintf() (the current
fallback implementation where vasprintf() isn't available writes to a
temporary file then reads it back in, which isn't exactly efficient).

--
Glynn Clements <glynn@gclements.plus.com>

Luigi_Ponti · February 10, 2010, 10:45am

Martin: please read on:

Hi all,

Not sure why this happens, but some of the manual pages of my
WinGRASS-6.4.SVN-r40650-1 installation are in English e.g.

v.build.all - Rebuilds topology on all vector maps in the current mapset.

while other are in another (not sure which) language e.g.

v.buffer - Vytvoĝí buffer okolo prvkù zadaného typu (plochy musí obsahovat
centroid)

Is this a known issue?


It is a bugfeature: some want it some not. Ideally both English and the
current locale would be used for creating the manual, see enhancement
request: [https://trac.osgeo.org/grass/ticket/846](https://trac.osgeo.org/grass/ticket/846)

Apparently winGRASS-daily was/is build in CZ locale and NLS active.
Before compilation, the locale settings should be set to English by
defining LANG and LC_MESSAGES variables. IMHO easy to fix
on Martin's server.

Hello,
Just wanted to mention the partly-Czech manual is still there on the daily standalone installer (WinGRASS-6.4.SVN-r40876): many (not all) of the man pages have the first part (Flags, Parameters) in Czech, while starting from the Description section the rest of the page is in English.
Kind regards,
Luigi

P.S. It was really a major improvement to have daily builds packaged for windows – THANKS!

martinl · February 11, 2010, 9:52am

Hi,

2010/1/28 Markus Neteler <neteler@osgeo.org>:

[...]

Apparently winGRASS-daily was/is build in CZ locale and NLS active.
Before compilation, the locale settings should be set to English by
defining LANG and LC_MESSAGES variables. IMHO easy to fix
on Martin's server.

finally I have some time to look at this problem. Defining LANG and
LC_MESSAGES in package.sh doesn't seems to help. Any hint from Windows
users?

Thanks, Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

neteler · February 18, 2010, 9:46am

On Thu, Feb 11, 2010 at 10:52 AM, Martin Landa <landa.martin@gmail.com> wrote:

2010/1/28 Markus Neteler <neteler@osgeo.org>:

[...]

Apparently winGRASS-daily was/is build in CZ locale and NLS active.
Before compilation, the locale settings should be set to English by
defining LANG and LC_MESSAGES variables. IMHO easy to fix
on Martin's server.

finally I have some time to look at this problem. Defining LANG and
LC_MESSAGES in package.sh doesn't seems to help. Any hint from Windows
users?

Two random ideas:
- add the definitions also in the cronjob script
- check if English language is possible on the machine (maybe the
en_US locale isn't there?)

Markus

Glynn_Clements1 · February 18, 2010, 10:26am

Markus Neteler wrote:

>> Apparently winGRASS-daily was/is build in CZ locale and NLS active.
>> Before compilation, the locale settings should be set to English by
>> defining LANG and LC_MESSAGES variables. IMHO easy to fix
>> on Martin's server.
>
> finally I have some time to look at this problem. Defining LANG and
> LC_MESSAGES in package.sh doesn't seems to help. Any hint from Windows
> users?

Two random ideas:
- add the definitions also in the cronjob script
- check if English language is possible on the machine (maybe the
en_US locale isn't there?)

The default locale is "C", which behaves the same as if no locale is
set (i.e. no call to setlocale()).

LC_ALL takes precedence over the individual LC_* variables and LANG,
so you may need to use:

export LC_ALL=C

--
Glynn Clements <glynn@gclements.plus.com>

martinl · February 19, 2010, 3:33pm

Hi,

2010/2/18 Glynn Clements <glynn@gclements.plus.com>:

[...]

The default locale is "C", which behaves the same as if no locale is
set (i.e. no call to setlocale()).

LC_ALL takes precedence over the individual LC_* variables and LANG,
so you may need to use:
   export LC\_ALL=C

I have already tried to put `LC_ALL=C` to package.sh and recompile
GRASS, but it didn't seem to help (module --interface-description
still returns localized text).

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

Luigi_Ponti · February 19, 2010, 5:29pm

Thanks Martin. Just to detail further my report, in case it is useful (sorry if redundant):

Installed last available WinGRASS-6.4.SVN-r41105-1-Setup.exe of 19 February.

If I do for example:

r.colors --interface-description

what is get is:

<?xml version="1.0" encoding="CP1252"?> Creates/modifies the color table associated with a raster map layer. raster, color table Nome della mappa raster in input name Required [...]

You can see there is English description plus some Italian text depending on how far the translator got. It is the same text I get in the g.parser GUI when invoking r.colors without arguments. I think this is fine since I have an Italian locale. However, the HTML manual page of r.colors is a partial Czech translation.

Kind regards,

Luigi