Re: [GRASS-dev] [GRASS GIS] #2131: Terrible performance from v.what.rast due to per-iteration db_execute

[GRASS GIS]

#2131: Terrible performance from v.what.rast due to per-iteration db_execute
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.4
Component:  Database | Version:  svn-develbranch6 
 Keywords:  v.what.rast, db_execute  |Platform:  Linux
  Cpu:  x86-64   |  
-+--

Comment(by hamish):

 Replying to [ticket:2131 hamish]:
 > I'm running v.what.rast for 175k query points in 6.x. It's taking a
 horribly long time.
 > With debug at level 1 it shows that it gets done with the query
 processing and
 > on to the "Updating db table" stage in less than 1 second. Over an *hour
 > later* I'm still waiting for the dbf process, which is running at 99%
 cpu! This
 > is a fast workstation too.
 ...
 > in trunk it takes about 6 seconds to complete the 100k random
 > points, I'm not seeing anything obvious in the module changelog,
 > so I guess something in the libraries got fixed? any hints?

 actually trunk is pretty bad too. v.db.addtable takes a couple of minutes
 to read the categories (the first half is reasonably quick, but then it
 slows down more and more), and then v.what.rast after running for 13
 minutes is only 9% done. (with the new print instead of update DB flag it
 takes only 0.347s to complete)


 any ideas?

 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Nikos Alexandris]

Vaclav Petras wrote:

> However, I must say the same I said before. If you need some 
advanced bash
> functionality such as `if` and `for` or even functions it is better 
to
> use/learn Python instead.

Check the just posted "i.fusion.hpf" script, you'll love the amount 
of "if"s :D.  Just kidding of course. For sure Python can handle such 
situations much more flexible.

Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)

[Nikos Alexandris]

Dear GRASS GIS users,

together with Nikos Ves, we share the "i.fusion.hpf" idea/proof of concept.  At 
the moment, 
we have a custom shell script named `i.fusion.hpf` (an attempt for a proper 
GRASS add-on), 
which implements the High Pass Filter Additive (HPFA) Fusion Technique for 
Pan-Sharpening 
[*]. Nikos V started already porting to Python.  How can we proceed in sharing 
it?

We require some help in testing. Specifically, comparing the results between 
the steps 
implemented in GRASS GIS and the respective "HPF Resolution Merge" in ERDAS. It 
seems that 
GRASS' outputs are slightly more smooth. I will upload some screenshots in the 
Wiki. Perhaps 
I have done something wrong in the order of applying the algorithm's steps (in 
the shell 
script)!?

Note, however, that the script misses the (optional, as explained in the 
related publication) 
histogram matching step. In ERDAS' implementation, it seems that histo-matching 
is 
performed by default. Though, it might be possible to extract the "model" and 
subtract this 
final optional step so as to get 1:1 comparable outputs.


Background

HPFA seems to outperform the well known Pan-Sharpening techniques (incl. 
Brovey, IHS, 
PCA).  The algorithm comprises the following steps:

1. Computing ratio of low (Multi-Spectral) to high (Panchromatic) resolutions
2. High Pass Filtering the Panchromatic Image
3. Resampling MSX image to the higher resolution
4. Adding weighted High-Pass-Filetred image to the upsampled MSX image
5. Optionally, matching histogram of Pansharpened image to the one of the 
original MSX 
image


A few more words on the script

+ Stunning!, Crisp and colorful images (- currently after applying color 
rebalancing manually)
+ Extremely easy to use, i.e.: "i.fusion.hpf pan=Pan_DNs 
msx=Band1[,Band2,Band3,...]"
+ Grasping and testing the various parameters that define the High-Pass 
filter's kernel size and 
center value is also a matter of short time.
+ It will work with any kind of imagery (after minor modifications)
+ However, it can be easily adapted for GRASS 7 / converted to Python

- The attached script, badly coded by a non-programer, is in Bash for G64.
- Currently works only for integers (with minor tweaking it can work with 
r.mfilter.fp to crunch 
Floating Points as well)
- Lacks of the histogram matching operation
- Something I don't understand about g.tempfile -- how to use it?


Two questions

? Can someone confirm that the part of the existing "i.pansharpen" code that 
performs 
histogram matching (code lines 348 - 431), do so as "linearly stretching an 
image to match 
another image's Mean and StdDev"?

? Would it be desired to get the HPFA algorithm integrated in i.pansharpen?


For the records, the replication of the HPFA fusion technique in GRASS-GIS, as 
well as the 
"filter creation" bash one-liner, were Nikos Ve's ideas. I followed-up with a 
bash proof of 
concept.

Nikos
---

[*] Optimizing the High-Pass Filter Addition Technique for Image Fusion (2008) 
by Ute G. 
Gangkofner, Pushkar S. Pradhan, and Derrold W. Holcomb


i.fusion.hpf.tar.gz
Description: application/compressed-tar
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Linearly stretch an image to match another image's Mean and StdDev

[Nikos Alexandris]

Nikos Alexandris wrote:

> Part of an image processing algorithm is "linearly 
stretching an image to
> match another image's Mean and StdDev". How can we 
replicate this in GRASS?
> Already implemented as part of...

"i.pansharpen", code lines 348 - 431 maybe?

Thanks, Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Vaclav Petras]

On Wed, Nov 13, 2013 at 7:47 PM, Nikos Alexandris
wrote:

>  Nikos wrote:
>
>
>
> > >> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ;
>
> > >> done
>
>
>
> Hamish wrote:
>
>  > Curly brackets do nothing to protect the contents of a variable. Using
> them
>
> > tricks new bash coders into thinking they are protected when they are
> not.
>
> > To avoid propagating the damaging myth, only use them when you actually
> need
>
> > them (eg to protect the variable name from following characters, not its
>
> > contents).
>
>
>
> Maybe this should be added in /grass_addons/SUBMITTING_SCRIPTS ?
>
>
Hamish and Nikos, SUBMITTING is a great idea. That's the best place. And
once #2103 will be solved it will be ideal. The document can be much longer
then now, I believe.

I'm just not sure if this is for addons or trunk but just but it anywhere
for #2103 they might be merged.

https://trac.osgeo.org/grass/ticket/2103

And about Bash versus Python, I agree, I feel it the same, but at the end,
I always ends with Python. By the way, there is actually one thing which is
sometimes used and that is generation of bash code/script in Python and
then running it using bash command. Bit strange but powerful.

Vaclav

>
>
> Nikos
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] lib fn to set all of a raster row to NULL?

[Hamish]

Hamish wrote:

> is there a lib function somewhere like Rast_get_row() which populates
> a row buffer, but instead of reading from a file just (re)sets all
> values in the row array to NULL?
> 
> something like:
>   Rast_fill_row_with_nulls(void *buf, RASTER_MAP_TYPE data_type)
> 
> It's easy enough to write small for() loop to do it, but seems like the
> sort of thing a lib fn might help with, so might already exist somewhere.
> 
> ?

nevermind, found it:

Rast_set_null_value(row_ptr, window.cols, map_type);


Hamish

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Nikos Alexandris]

Nikos wrote:

> >> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ; 
> >> done

Hamish wrote:
 
> Curly brackets do nothing to protect the contents of a variable. Using them
> tricks new bash coders into thinking they are protected when they are not.
> To avoid propagating the damaging myth, only use them when you actually need
> them (eg to protect the variable name from following characters, not its
> contents).

Maybe this should be added in /grass_addons/SUBMITTING_SCRIPTS ?

Nikos

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2133: g.parser does call the form.py with full path

[GRASS GIS]

#2133: g.parser does call the form.py with full path
+---
 Reporter:  wenzeslaus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Parser  | Version:  svn-trunk
 Keywords:  parser  |Platform:  All  
  Cpu:  All |  
+---

Comment(by hamish):

 ps- typically scripts using g.parser need to be somewhere in the system
 PATH since they run in two passes, and the second time it has forgotten
 the original path (if it ever knew it, it could have been called as
 "./script"). For compiled addon modules they don't need to be in the PATH
 since the module is run in the same process as the parser.

 try adding the directory you script is in to the PATH.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2133: g.parser does call the form.py with full path

[GRASS GIS]

#2133: g.parser does call the form.py with full path
+---
 Reporter:  wenzeslaus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Parser  | Version:  svn-trunk
 Keywords:  parser  |Platform:  All  
  Cpu:  All |  
+---
Changes (by hamish):

  * component:  wxGUI => Parser


Comment:

 Replying to [ticket:2133 wenzeslaus]:
 > *This is the second Trac component I'm suggesting in past few
 > weeks but what about Parser/G_parser/GRASS Parser/g.parser
 > component*.

 done.


 regards,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] lib fn to set all of a raster row to NULL?

[Hamish]

Hi,

is there a lib function somewhere like Rast_get_row() which populates
a row buffer, but instead of reading from a file just (re)sets all
values in the row array to NULL?

something like:
  Rast_fill_row_with_nulls(void *buf, RASTER_MAP_TYPE data_type)

It's easy enough to write small for() loop to do it, but seems like the
sort of thing a lib fn might help with, so might already exist somewhere.


?

note this is for working with the cell array values, not
writing an all-null row on the disk.



thanks,
Hamish

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2133: g.parser does call the form.py with full path

[GRASS GIS]

#2133: g.parser does call the form.py with full path
+---
 Reporter:  wenzeslaus  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  parser  |Platform:  All  
  Cpu:  All |  
+---
 When I run `gui/wxpython/gui_core/forms.py` directly with full path:

 {{{
 python gui_core/forms.py ../../temporal/t.list/t.list.py
 }}}

 I get the module form/dialog (task frame) for the command and following
 debug output (`g.gisenv set=WX_DEBUG=1`):

 {{{
 GUI D1/1: forms.py called using command: ../../temporal/t.list/t.list.py
 GUI D1/1: forms.py opening form for: ['t.list.py']
 }}}

 However, when I run the module itself (here with `--ui` because of other
 parameters):

 {{{
 ../../temporal/t.list/t.list.py --ui
 }}}

 I don't get the GUI for module, I get an error dialog with message:

 {{{
 Unable to fetch interface description for command 't.list.py'.

 Details: [Errno 2] No such file or directory

 Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.
 }}}

 and the reason is actually clear from the debug output:

 {{{
 GUI D1/1: forms.py called using command: t.list.py type="strds"
 temporaltype="absolute,relative" order="id" columns="id"
 GUI D1/1: forms.py opening form for: ['unknown']
 }}}

 The parser mechanism does not pass the full path to file, so it is not
 found by the `task.py` mechanism. The task.py should probably end with
 some other error then setting the name to `unknown` but that's another
 story.

 The function responsible for running GUI is `module_gui_wx` in
 `lib/gis/parser.c`. It is passing result of `G_recreate_command()` as a
 first parameter and this works pretty well. The problem is that it returns
 only base name of the command returned by `G_program_name()` which uses
 global variable set by `G_set_program_name` function which stripes the
 name to using `G_basename` function.

 I cannot go further because `G_recreate_command` does not have any useful
 documentations (the only line of doc is related to non-interactivity which
 is really outdated). I hope that some others knows what is the concept of
 this and so what is the right solution.

 This functionality is important for testing non-core modules
 (addons/extensions) and more importantly it is crucial for running user
 scripts or scripts distributed in other way then GRASS Addons repository.

 Note that you need at least r58212 (GRASS 7) to test this because I added
 the debug messages in r58212. By the way, I've fixed the two tests there
 and extended usage suggestions when you run it without parameters.

 *This is the second Trac component I'm suggesting in past few weeks but
 what about Parser/G_parser/GRASS Parser/g.parser component*.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.stats area question

[Eric Goddard]

Hi all,

Quick question regarding the units of area output from r.stats. the -a
flag specifies the output area to be printed in square meters. The
manual, however, says:

Area statistics are given in units of square meters and/or cell counts.

and:

If a single map layer is specified on the command line, a list of
areas in square meters (assuming the map's coordinate system is in
meters) for each category in the raster map layer will be printed...

My coordinate system is in U.S. Feet (I know, I know...we're still in
the dark ages). The numbers do appear to be meters, but I just wanted
to confirm that the output isn't in feet because of the "assuming the
map's coordinate system is in meters" part.

Thanks,
Eric
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Hamish]

Glynn:
>>Example:
>>
>>        $ hello='hi     there'
>>        $ echo $hello
>>        hi there
>>        $ echo "$hello"
>>        hi     there


here's another example:
FOO="a b"
BAR="c d"
mkdir ${FOO}
mkdir "$BAR"
ls -l
drwxr-xr-x  a/
drwxr-xr-x  b/
drwxr-xr-x  c d/


Vaclav:
> I remember that we had this conversation recently.

I tend to repost that lesson every time I see curly brackets, in a quixotic 
attempt to stamp them out. :)


> What about putting some (ba)sh(ell) primer into the manual?

My concern with that is where does it end? Do we add a UNIX primer too? I think 
it's a very good idea to put links in the wiki to existing tutorials though, 
but no need for us to rewrite what's already been written many times. Some tips 
are already in the SUBMITTING_SCRIPTS files. Often the best advice is to just 
use the existing GRASS scripts as a template. (be it python or bourne scripting)

> However, I must say the same I said before. If you need some
> advanced bash functionality such as `if` and `for` or even
> functions it is better to use/learn Python instead.

I humbly disagree, but probably only on what would be
considered 'advanced functionality'. I'd put the bar more at
the subtle quoting for dynamic variable names needing `eval`
and nested multi-level $(``) executions, or needing to write
some complicated awk or regex statement. i.e. once it gets to
the point where it isn't human readable anymore.. but I guess
the discussion is highly academic since we're not proposing to
change anything from what we do now.



For manipulating huge amounts of ascii data there's not
much in the world that can beat the UNIX powertools piped
together in a shell script. Also it's hard to beat the
simplicity of cutting and pasting the last five lines
you entered onto the command line into a text editor
and saving the file with a ".sh" extension.  i.e. a gentle
introduction to programming for command line users. (this
is why I really like having the command line self-assemble at the bottom of the 
module GUIs)

Both python and shell scripting are fine tools, each with their
own niche; I would hope we could identify the best tool for the
job based on the niche, and not devolve into me trying to use
shell scripting for everything because I know it well, and
others trying to use python for everything because they know it
well. And rather both use the most appropriate tool for the job
on a needs basis, and get better in both. :)


2c,
Hamish

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2105: Missing guidelines for testing

[GRASS GIS]

#2105: Missing guidelines for testing
+---
 Reporter:  wenzeslaus  |   Owner:  
grass-dev@…  
 Type:  task|  Status:  new 
 
 Priority:  normal  |   Milestone:  7.0.0   
 
Component:  Tests   | Version:  
svn-trunk
 Keywords:  testing, tests, PyUnit, doctest, testsuite  |Platform:  All 
 
  Cpu:  Unspecified |  
+---

Comment(by wenzeslaus):

 Some software projects require to have a test for each closed ticked,
 fixed bug or commit. I'm wondering how to do it for platform dependent or
 system configuration specific issues such as r58200 discussed at
 [http://lists.osgeo.org/pipermail/grass-dev/2013-November/066277.html
 GRASS-dev]. Maybe in the same way as GUI part of the GUI can be tested,
 i.e. document with steps what to do (how to reproduce).

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Vaclav Petras]

On Wed, Nov 13, 2013 at 10:50 AM, Glynn Clements
wrote:

>
> Hamish wrote:
>
> > Nikos wrote:
> > >> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ;
> done
> >
> > Curly brackets do nothing to protect the contents of a variable. Using
> them
> > tricks new bash coders into thinking they are protected when they are
> not.
> > To avoid propagating the damaging myth, only use them when you actually
> need
> > them (eg to protect the variable name from following characters, not its
> contents).
>
> In case it wasn't clear: putting the variable name in braces prevents
> subsequent alphanumeric characters from being interpreted as part of
> the variable name; e.g.
>
> echo ${hello}_world
>
> will substitute the value of the variable "hello", whereas
>
> echo $hello_world
>
> will substitute the value of the variable "hello_world".
>
> But if you want to prevent the substituted value from being re-parsed,
> double quotes must be used, e.g.:
>
> echo "$hello"
>
> Example:
>
> $ hello='hi there'
> $ echo $hello
> hi there
> $ echo "$hello"
> hi there
>
> I remember that we had this conversation recently. What about putting some
(ba)sh(ell) primer into the manual?

However, I must say the same I said before. If you need some advanced bash
functionality such as `if` and `for` or even functions it is better to
use/learn Python instead.

--
> Glynn Clements 
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] modifying the dblink it require to re-build the topology

[Moritz Lennert]

On 12/11/13 23:24, Pietro Zambelli wrote:

On Tuesday 12 Nov 2013 20:37:24 you wrote:



On the other hand, the tables are already there, we need only to
link the geometry features to the existing table.


No, if we have a new map it should use a different attribute table
than the old map.


I don't agree I prefer to avoid to have several copy of the same thing
on my hard-disk, but I can understand your logic. :-)


It's not about redundancy, but about the fact that when you have two 
maps (the old and the new) linked to the same table you will have 
conflicts to resolve. Normally GRASS erases the table linked to a map 
when that map is erased. So, if you link the new map to the old table 
and then erase the old map, you might lose all your attribute data...


Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2132: Create a system for building and running GRASS modules written in Python

[GRASS GIS]

#2132: Create a system for building and running GRASS modules written in Python
---+
 Reporter:  wenzeslaus |   Owner:  
grass-dev@…  
 Type:  defect |  Status:  new  

 Priority:  normal |   Milestone:  7.0.0

Component:  Python | Version:  
svn-trunk
 Keywords:  makefiles, addons, path, python, packages  |Platform:  All  

  Cpu:  All|  
---+

Comment(by wenzeslaus):

 In r58208, I used `get_lib_path` function to find the `r.modis`
 library/package. This actually fixes `r.modis.import` for me on Ubuntu.
 The `r.modis.download` started successfully before and starts also after
 the change.

 However, the Makefile is still a issue at least for addons. How the
 directories are set and what the `get_lib_path` function tries has unclear
 system. There is a module group name `r.modis` (name of directory in
 source code) and than there is a library (which is supposed to be a Python
 package?) name `libmodis`. However, `libmodis` is renamed to `r.modis`
 when installed and libraries (or whatever) from one module group are
 grouped to the same directory named by module group. So, the result is
 `r.modis/r.modis` directory in `GRASS_ADDON_BASE` (e.g.,
 `/home/john/.grass7/addons/r.modis/r.modis`).

 Grouping the libraries makes sense to avoid potential conflicts. For few
 libraries it is not necessary but I can imagine a groups of modules in
 addons which includes some 3rd party library into the distribution. Then
 grouping is advantage. The renaming seems strange to me. Is there some
 reason for it?

 I'm not sure where the other than Python files related to the module or
 module group should go. This is the case of ''resources'' such as XMLs or
 images. I'm not sure if there is some mechanism for it now.

 The terminology started to be a real issue here, I'm not sure how to speak
 about things. Addon, extension, package, library, GRASS module, Python
 module, module group, module package...

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Glynn Clements]

Hamish wrote:

> Nikos wrote:
> >> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ;  done
> 
> Curly brackets do nothing to protect the contents of a variable. Using them
> tricks new bash coders into thinking they are protected when they are not.
> To avoid propagating the damaging myth, only use them when you actually need
> them (eg to protect the variable name from following characters, not its 
> contents).

In case it wasn't clear: putting the variable name in braces prevents
subsequent alphanumeric characters from being interpreted as part of
the variable name; e.g.

echo ${hello}_world

will substitute the value of the variable "hello", whereas

echo $hello_world

will substitute the value of the variable "hello_world".

But if you want to prevent the substituted value from being re-parsed,
double quotes must be used, e.g.:

echo "$hello"

Example:

$ hello='hi there'
$ echo $hello
hi there
$ echo "$hello"
hi there

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r58200 (attempt to fix failure when user name contains non-ascii characters)

[Glynn Clements]

Martin Landa wrote:

> > What problem is it trying to fix?
> 
> it fixes issue on Windows when user name contains non-ascii charecters
> (which is quite common on this platform).
> 
> > And how does it do that (if it does actually work)?
> 
> I have created on my Windows machine such user and this patch was
> necessary otherwise GRASS start script simply fails.

How/why does it fail? And how does this change fix that?

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2125: r.in.xyz not importing data when line is 800 characters long (was: r.in.xyz not importing data with 5 decimal digits)

[GRASS GIS]

#2125: r.in.xyz not importing data when line is 800 characters long
--+-
 Reporter:  moreno|   Owner:  hamish  
 Type:  defect|  Status:  assigned
 Priority:  major |   Milestone:  6.4.4   
Component:  Raster| Version:  6.4.3   
 Keywords:  r.in.xyz  |Platform:  All 
  Cpu:  x86-64|  
--+-

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Nikos Alexandris]

Nikos wrote:

> >> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ; 
> >> done

Hamish wrote:

> Curly brackets do nothing to protect the contents of a variable. Using them
> tricks new bash coders into thinking they are protected when they are not.
> To avoid propagating the damaging myth, only use them when you actually need
> them (eg to protect the variable name from following characters, not its
> contents).

Thank you Hamish.

Vaclav:

> > Is GIS_OPT_MSX also in GRASS 7 (trunk)?
 
> That's just going to be the contents of a msx= command line option defined
> in the script header's #% definition.

That's right.

Nikos
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a multi-"${GIS_OPT_X}" input in a shell for loop

[Hamish]

Nikos wrote:
>> for Image in `echo $GIS_OPT_MSX | tr "," "\ "` ; do echo ${Image}  ;  done

Curly brackets do nothing to protect the contents of a variable. Using them
tricks new bash coders into thinking they are protected when they are not.
To avoid propagating the damaging myth, only use them when you actually need
them (eg to protect the variable name from following characters, not its 
contents).

Vaclav:
> Is GIS_OPT_MSX also in GRASS 7 (trunk)?

That's just going to be the contents of a msx= command line option defined in 
the
script header's #% definition.


regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2125: r.in.xyz not importing data with 5 decimal digits

[GRASS GIS]

#2125: r.in.xyz not importing data with 5 decimal digits
--+-
 Reporter:  moreno|   Owner:  hamish  
 Type:  defect|  Status:  assigned
 Priority:  major |   Milestone:  6.4.4   
Component:  Raster| Version:  6.4.3   
 Keywords:  r.in.xyz  |Platform:  All 
  Cpu:  x86-64|  
--+-
Changes (by hamish):

 * cc: grass-dev@… (added)
  * owner:  grass-dev@… => hamish
  * status:  new => assigned


Comment:

 Hi,

 I have increased the buffer size to 1024 chars in the development branches
 r58203,4. It doesn't really fix the heart of the problem but fixes it for
 you and makes it less likely to occur in the future (maybe we should keep
 going to 4096 chars). Please test with tomorrow's nightly build of
 WinGrass 6.5.


 When the line is longer than the specified input buffer I'm not sure if it
 really matters if G_getl2() flushes the rest of the line or not. Either
 way the data-read has gone wrong and you'll want a G_fatal_error(), so the
 question becomes at what point to throw that error, and what the error
 should say. _("Line is too long for input buffer") might be a good
 candidate for what it should say.


 thanks,
 Hamish

 ps- consider to use fs=tab instead of fs='\t'.

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev