[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by hamish):

 Replying to [comment:7 cmbarton]:
 > Yea. There is already code for this in the epsg select page.
 > I think this is the most reliable way to do the transforms.

 I concur Dr. Barton. If a pulldown menu were possible, that would be a lot
 easier than transcribing some custom "T21" code number.


 cheers,
 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by cmbarton):

 Yea. There is already code for this in the epsg select page. I think this
 is the most reliable way to do the transforms.

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by hamish):

 g.proj --help says:
 {{{
   datumtrans   Index number of datum transform parameters
 "0" for unspecified or "-1" to list and exit
 }}}

 so in this case valid options to pass g.proj for that are 0-6.

 {{{
  g.proj datumtrans=-1  proj4="+proj=lcc +datum=nad83"
 }}}

 [aside]
 North American Datum 1983 (nad83) is chronologically very close to 1984,
 so +towgs84=0,0,0 isn't too surprising (same for any datum post-satellite
 era), the others (2-6) are all NTv2 grid file transforms (is NAD83 a
 continental plate-bound datum?).



 I see the g.proj -t and -d flags, but not really sure if they help.

 here are the valid options I was describing for my neck of the woods:
 {{{
  g.proj proj4="+proj=nzmg +datum=nzgd49" datumtrans=-1
 }}}


 If I guess correctly you are looking at parsing the g.proj datumtr=-1
 output instead of the datumtransform.table file?


 thanks,
 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard  
  Platform:  Linux | Cpu:  x86-64   
---+
Comment (by cmbarton):

 Question. If I run g.proj with datumtrans=-1 for a UTM zone 3 NAD83, I get
 the following list below. The first 'transformation' is a default non-
 transform and in the datum.table. The remaining 5 transformations are in
 the datumtransform.table.

 If none of the transforms 2-6 are specified, will transform #1 (the
 default) be used?

 Michael

 ---
 1
 Used in whole nad83 region
 towgs84=0.000,0.000,0.000
 Default 3-Parameter Transformation (May not be optimum for older datums;
 use this only if no more appropriate options are available.)
 ---
 2
 Used in Florida
 nadgrids=FL
 Transforms 'Old NAD83' to 'HPGN NAD83'
 ---
 3
 Used in Maryland
 nadgrids=MD
 Transforms 'Old NAD83' to 'HPGN NAD83'
 ---
 4
 Used in Tennessee
 nadgrids=TN
 Transforms 'Old NAD83' to 'HPGN NAD83'
 ---
 5
 Used in Wisconsin
 nadgrids=WI
 Transforms 'Old NAD83' to 'HPGN NAD83'
 ---
 6
 Used in Washington - Oregon
 nadgrids=WO
 Transforms 'Old NAD83' to 'HPGN NAD83'
 GRASS 6.5.svn (Spearfish60_test):~ > c

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  critical  |   Milestone:  6.4.0
 Component:  wxGUI | Version:  svn-develbranch6 
Resolution:|Keywords:  location wizard  
  Platform:  Linux | Cpu:  x86-64   
---+
Changes (by hamish):

  * keywords:  => location wizard
  * priority:  major => critical

Comment:

 It is worse,

  * start wx loc wiz
  * some new name for the new loc'n
  * proj: nzmg
  * datum: nzgd49
  * transfrom parms: T53
  * Summary page: +dx,+dy,+dz are there (these are the "default" 3-param
 +towgs84 terms) *AND* the 7-term parms from T53. these are mutually
 exclusive.
  :-(

 (no way to cut & paste out of the wizard summary beyond screenshots,
 sorry)

 also:
  * no way to clear/unselect transform params after clicking the [< Back]
 button, even if transform parms choice is removed.

  * if you cancel the wizard, then again start the loc wiz, enter a new
 name but on the Choose Method page don't click on anything but [Next >]
 (leaving default Select Coord Sys selected), you go straight to the
 (mostly empty) Summary page. Doesn't happen the first time.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #784: wx location wizard: fails to set datum

2009-10-10 Thread GRASS GIS
#784: wx location wizard: fails to set datum
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by hamish):

 Replying to [comment:1 cmbarton]:
 > Any chance this could be a g.proj problem with southern hemisphere data?


 Nope; I tried making other non-UTM and UTM-north locations and see the
 same thing.

 The loc'n wizard shows the expanded terms for the selected datum in the
 Summary page PROJ.4 definition line (+a=, +rf=), but not the +datum= part.
 hmmph, there is more wrong there (duplication); continued in #785. These
 seem to be linked.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hamish):

 quick & dirty workaround idea: add a space to the end of the system string
 so it doesn't end with a \".

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by hamish):

 Replying to [comment:2 cmbarton]:
 > Correction, the options are read from the datumtransform.table
 > file, datums and their defaults are read from the datum.table file.
 >
 > There are only 2 transforms for nzgd49 and none for wgs84 in the
 > file.

 the 7-term and NTv2 transforms for nzgd49 are in the datumtransform.table
 file; the 3-term transform can be found in the datum.table file.

 The WGS84 3-term transform (+towgs84=0,0,0) is also in the datum.table
 file. The terms found in both those files must be combined for
 presentation to the user.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hamish):

 Replying to [comment:5 hellik]:
 > at the moment I've managed to understand the instructions
 > (http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4
 > /mswindows/README.html) to build a nsis-GRASS-Windows-
 > selfinstaller. maybe after some tests, a suitable installer will
 > be possible. but i have no idea about svn-diffs etc at windows.

 Colin has been really good about making releases, I'm not worried about
 that. The issue for me is that I'm borrowing a coworker's desk/PC to test
 GRASS on in free moments and can't use that for quick recompile+tests or
 mess with it too much.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hellik):

 Replying to [comment:3 hamish]:
 [...]
 > not until someone else releases another wingrass build; I'm not set up
 to do that.
 [...]

 at the moment I've managed to understand the instructions
 
(http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/mswindows/README.html)
 to build a nsis-GRASS-Windows-selfinstaller. maybe after some tests, a
 suitable installer will be possible. but i have no idea about svn-diffs
 etc at windows.

 best regards
 helli

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

[GRASS-dev] Re: [GRASS GIS] #784: wx location wizard: fails to set datum

2009-10-10 Thread GRASS GIS
#784: wx location wizard: fails to set datum
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by cmbarton):

 Any chance this could be a g.proj problem with southern hemisphere data?

 Michael

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

[GRASS-dev] [GRASS GIS] #786: Update to http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/mswindows/README.html

2009-10-10 Thread GRASS GIS
#786: Update to
http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/mswindows/README.html
-+--
 Reporter:  hellik   |   Owner:  grass-dev@lists.osgeo.org
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.0
Component:  Packaging| Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 Update:

 "4. Install NSIS (2.38)"

 actual version of NSIS is 2.45. (* Added support for Windows 7 installers)

 So the link should be changed from

 http://prdownloads.sourceforge.net/nsis/nsis-2.38-setup.exe

 to

 http://prdownloads.sourceforge.net/nsis/nsis-2.45-setup.exe

 best regards
 helli

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by cmbarton):

 Correction, the options are read from the datumtransform.table file,
 datums and their defaults are read from the datum.table file.

 There are only 2 transforms for nzgd49 and none for wgs84 in the file.

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

[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  wxGUI   | Version:  svn-develbranch6 
Resolution:  |Keywords:   
  Platform:  Linux   | Cpu:  x86-64   
-+--
Comment (by cmbarton):

 AFAIK, the options list is created from reading the datum.table file. Can
 you look in this file and see if it actually has the transforms that you
 need but seem to be missing?

 Thanks
 Michael

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

[GRASS-dev] Re: [GRASS GIS] #709: wxgui georectify: cannot see files to be displayed in grass65svn and grass7 and cannot create new group

2009-10-10 Thread GRASS GIS
#709: wxgui georectify: cannot see files to be displayed in grass65svn and 
grass7
and cannot create new group
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org   
  Type:  defect|  Status:  new 
  Priority:  major |   Milestone:  6.5.0   
 Component:  wxGUI | Version:  svn-develbranch6
Resolution:|Keywords:  georectify group display map
  Platform:  Linux | Cpu:  Unspecified 
---+
Comment (by cmbarton):

 Fixed in develbranch_6 (6.5). Please test. If OK, I'll backport to trunk
 (7).

 Michael

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

[GRASS-dev] Re: [GRASS GIS] #629: WinGRASS: spaces in pathnames

2009-10-10 Thread GRASS GIS
#629: WinGRASS: spaces in pathnames
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  Installation  | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, msys   
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hellik):

 Replying to [comment:29 hamish]:
 > extra quotes removed in r39456,7. try, try again

 grass64svn_relb self compiled in osgeo4w in WinVista: rev39464

 {{{
 g.gisenv --v
 GISDBASE='C:\gisdata\grassdata';
 LOCATION_NAME='nc_spm_08';
 MAPSET='user1';
 DEBUG='0';
 GRASS_GUI='wxpython';
 }}}

 {{{
 g.copy vect=hospit...@permanent,copyhospital
 Copy vector  to current mapset as 
 }}}

 seems to work :o)

 best regards
 helli

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

Re: [GRASS-dev] v.generalize tutorial

2009-10-10 Thread Martin Landa
Ciao,

2009/10/10 Paolo Cavallini :
>> it's already there my friend,
>>   http://grass.osgeo.org/wiki/V.generalize_tutorial
>
> Thanks. However, in the manpage the old link is mentioned:
> http://grass.itc.it/grass64/manuals/html64_user/v.generalize.html

fixed in r39470.

Martin

-- 
Martin Landa  * http://gama.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


[GRASS-dev] [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

2009-10-10 Thread GRASS GIS
#785: wx location wizard: doesn't show all datum transform opts
+---
 Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  6.4.0
Component:  wxGUI   | Version:  svn-develbranch6 
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---
 Hi,

 If I create a new location with the wx loc'n wizard (e.g. proj=nzmg) on
 the "Specify geodetic datum" page if I choose the nzgd49 datum I only see
 two options in the lower pane. There should be three: 3-term, 7-term, and
 NTv2 grid file. I assume the 3-term is the one that's missing but there
 isn't enough info there for the user to know for sure. (add +proj terms as
 a second\n description line or tooltip?)

 for wgs84 it is worse, you get the full list of transform params but no
 +towgs84=0,0,0 option.


 lib/gis/datum.table ignored?

 (also it would be nice if the search tools checked the Code column as well
 as the long description, and clicking on the magnifying glass icon
 executed the search)



 thanks,
 Hamish

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

[GRASS-dev] [GRASS GIS] #784: wx location wizard: fails to set datum

2009-10-10 Thread GRASS GIS
#784: wx location wizard: fails to set datum
+---
 Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  6.4.0
Component:  wxGUI   | Version:  svn-develbranch6 
 Keywords:  |Platform:  Linux
  Cpu:  x86-64  |  
+---
 Hi,

 if I make a new location using the wx location wizard (say utm zone 41
 south with WGS84 datum) the datum fails to be set.

 g.region -p says
 {{{
 datum:  ** unknown (default: WGS84) **
 }}}

 and g.proj -p only shows an ellps value.


 thanks,
 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hamish):

 Hamish:
 > > pps- should G_convert_dirseps_to_host() be done in the
 > > G_gisbase() and G_gisdbase() functions instead or making the
 > > modules do it?

 Replying to [comment:2 glynn]:
 > Eventually. But first you have to fix everything which expects
 > pathnames to use "/".

 ... but shouldn't everything to the left of the G_gisd?base() string be
 outside the realm of the libs and modules' expectations? All the /etc/
 action happens to things tacked onto the right of it.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by hamish):

 Replying to [comment:1 mmetz]:
 > Can you try this patch:

 not until someone else releases another wingrass build; I'm not set up to
 do that.

 > The idea is to replace the double quotes around the path to the
 > executable with single quotes in the hope that the windows
 > version of system() is now no longer able to strip the leading
 > and trailing quotes of the whole command because these are now
 > different.

 AFAIK MS-Win does not like single quotes. We already had to go through
 everything that used system() and switch to double quotes.

 I guess we have to live without quoting GISBASE for now, or fix it
 properly by constructing a **args list and then using G_spawn() or similar
 instead of system("g.module opt1=\"\" opt2=\"\" ... ").


 > PS: Any reason why r39150 didn't make it into trunk?

 The surviving && relevant bits have now made it into trunk.


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by glynn):

 Replying to [comment:1 mmetz]:

 > > ps- will the .ram and .seg modules fail in GRASS 7 where uppercase
 option names are disallowed? (eg LS= and S=)

 No, because:

 > They still work in GRASS 7, probably because they don't call
 G_parser(argc, argv)?

 Right.

 > Not sure if this is a good idea not to call G_parser(argc, argv).

 I'm not sure if it really matters, given that these modules aren't
 supposed to be run directly by the user. In terms of style and structure,
 there are a couple of hundred more serious issues before worrying about
 G_parser().

 > > pps- should G_convert_dirseps_to_host() be done in the G_gisbase() and
 G_gisdbase() functions instead or making the modules do it?

 Eventually. But first you have to fix everything which expects pathnames
 to use "/".

 The existing "quick fix" approach is to use "/" internally and convert to
 "\" at the last moment.

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

[GRASS-dev] Re: [GRASS GIS] #773: r.in.gdal unclean import of southern UTM zone

2009-10-10 Thread GRASS GIS
#773: r.in.gdal unclean import of southern UTM zone
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  Projections/Datums  | Version:  svn-develbranch6 
Resolution:  |Keywords:  r.in.gdal, utm   
  Platform:  Unspecified | Cpu:  Unspecified  
-+--
Comment (by hamish):

 the following patch fixes the order of questions, and sets the WIND files
 correctly (and so new maps' cellhd too):

 {{{
 Index: general/g.setproj/proj-parms.table
 ===
 --- general/g.setproj/proj-parms.table  (revision 39463)
 +++ general/g.setproj/proj-parms.table  (working copy)
 @@ -105,7 +105,7 @@
  UPS:Universal Polar Stereographic:SOUTH=ask,nodfl
  URM5:Urmaev
 V:ALPHA=ask,0.0;LAT0=ask,0.0;LON0=ask,20.0;NFACT=ask,1.0;QFACT=ask,1.0
  URMFPS:Urmaev Flat-Polar
 Sinusoidal:LAT0=ask,0.0;LON0=ask,20.0;NFACT=ask,1.0
 -UTM:Universal Transverse Mercator (UTM):SOUTH=ask,nodfl;ZONE=ask,nodfl
 +UTM:Universal Transverse Mercator (UTM):ZONE=ask,nodfl;SOUTH=ask,nodfl
  VANDG2:van der Grinten II:LAT0=ask,0.0;LON0=ask,20.0
  VANDG3:van der Grinten III:LAT0=ask,0.0;LON0=ask,20.0
  VANDG4:van der Grinten IV:LAT0=ask,0.0;LON0=ask,20.0
 }}}


 existing maps should be in existing mapsets/loc'ns so no bothered by this
 change.


 ok to commit for trunk & 6.5?


 Hamish

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

[GRASS-dev] Re: [GRASS GIS] #629: WinGRASS: spaces in pathnames

2009-10-10 Thread GRASS GIS
#629: WinGRASS: spaces in pathnames
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  Installation  | Version:  6.4.0 RCs
Resolution:|Keywords:  wingrass, msys   
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by glynn):

 Replying to [comment:28 hamish]:

 > ok, it looks like the extra \" may be to blame then. (if _spawnl()
 quotes the argument [as it should] then you get ""...\dbf.exe"")

 [http://msdn.microsoft.com/en-us/library/20y988d2(VS.80).aspx Microsoft's
 documentation] says that the caller needs to quote arguments:

 > Spaces embedded in strings may cause unexpected behavior; for example,
 passing _spawn the string "hi there" will result in the new process
 getting two arguments, "hi" and "there". If the intent was to have the new
 process open a file named "hi there", the process would fail. You can
 avoid this by quoting the string: "\"hi there\"".

 '''However:''' it says "arguments", which doesn't necessarily apply to the
 command name (and db_start_driver() invokes the driver with no arguments),
 although it will apply to argv![0] (it shouldn't matter if argv![0] has
 excess quotes, but if it doesn't have enough it will end up rolling over
 into argv![1]).

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

[GRASS-dev] Re: [GRASS GIS] #773: r.in.gdal unclean import of southern UTM zone

2009-10-10 Thread GRASS GIS
#773: r.in.gdal unclean import of southern UTM zone
-+--
  Reporter:  hamish  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect  |  Status:  new  
  Priority:  major   |   Milestone:  6.4.0
 Component:  Projections/Datums  | Version:  svn-develbranch6 
Resolution:  |Keywords:  r.in.gdal, utm   
  Platform:  Unspecified | Cpu:  Unspecified  
-+--
Comment (by hamish):

 Replying to [comment:1 pkelly]:
 > How long ago was the location created? g.setproj had a bugfix on
 > 7 October 2003 to create a negative zone number for southern
 > hemisphere UTM locations

 It was created a few days ago with "grass65 -text" and a new location
 name, then defined by following the prompts.

 > Are you saying that that doesn't work (i.e. the negative zone
 > doesn't go into the WINDOW file)

 negative zone number doesn't make it into WIND, DEFAULT_WIND, or
 PROJ_INFO.

 > because libgis doesn't handle negative zone numbers? If so that
 > would make this an incredibly long-running bug...

 I've used southern hemisphere UTMs for ages without problems. I guess the
 "new" thing here is r.in.gdal imported data actually gets it right?


 the PROJ_INFO file has
 {{{
 zone: (some positive number)
 south: defined
 }}}

 so to me putting a negative zone in PROJ_INFO is just confusing+redundant,
 and so that part seems ok.  (PROJ.4 uses +south to define a southern UTM
 btw)

 The WIND and cellhd files can not have a "south: defined" tag as south: is
 used for the bound, so it should get a negative zone number there.
 r.in.gdal is doing that for cellhd files (but eg r.mapcalc does not for
 new maps), and WIND files are not getting it.


 Part of the solution I think is to have G!__.window.zone report a negative
 int for southern UTMs. That would mean that anything which writes a new
 raster or WIND file should do that too.
 (should opencell.c be using G_zone() instead?)

 To avoid massive breakage from that we'd also have to improve the logic of
 G!__open_cell_old() to test the abs() of the zone number and the south-
 ness of the projection (but how?).

 Everything seems to run through the WIND file and not the PROJ_INFO file,
 so setting it in DEFAULT_WIND correctly seems to be the first step at
 fixing this properly.

 which brings us back to g.setproj/main.c which is currently asking the
 'South Hemisphere? [n]' question BEFORE the 'Enter Zone:' prompt, so when
 you enter the zone number it clobbers the cellhd.zone variable. The South
 question has to come after, somehow.


 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] libgrass_iostream build problem...

2009-10-10 Thread Glynn Clements

cgnicho...@alamedanet.net wrote:

> file=/home/cgn/tmp//STREAM_5Xwb5K:cannot read!: Bad address
> r.terraflow:
> /home/cgn/src/grass-6.4.0RC5/dist.i686-pc-linux-gnu/include/grass/iostream/ami_sort_impl.h:91:
> size_t makeRun_Block(AMI_STREAM*, T*, unsigned int, Compare*) [with T =
> keyvalue, Compare = keyCmpKeyvalueType]: Assertion `err ==
> AMI_ERROR_NO_ERROR || err == AMI_ERROR_END_OF_STREAM' failed.
> Aborted (core dumped)

Known bug (#775); see:

http://trac.osgeo.org/grass/ticket/775

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


[GRASS-dev] Re: [GRASS GIS] #775: r.terraflow: file=/home/mlennert/STREAM/STREAM_tQhXkQ:cannot read!: Bad address

2009-10-10 Thread GRASS GIS
#775: r.terraflow: file=/home/mlennert/STREAM/STREAM_tQhXkQ:cannot read!: Bad
address
---+
  Reporter:  mlennert  |   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  normal|   Milestone:  6.4.0
 Component:  Raster| Version:  svn-develbranch6 
Resolution:|Keywords:  terraflow bad address
  Platform:  Linux | Cpu:  Unspecified  
---+
Comment (by glynn):

 Replying to [comment:5 mlennert]:

 > > so the assert() shouldn't be triggering. But that may just be an
 artifact of optimisation. Can you reproduce this if libiostream and
 r.terraflow are built without optimisation?
 >
 > Now I get err = AMI_ERROR_IO_ERROR.

 Well, the immediate issue is that fread() is returning a short count but
 not setting the end-of-file indicator.

 The short count is to be expected: it's trying to read run_size = 13027967
 items although it only expects there to be last_run_size = 38343 items in
 the file (and has only allocated enough memory for that many).

 Given the "Bad address" from perror(), my suspicion is that fread() is
 complaining that &data[len] isn't valid (i.e. the buffer isn't large
 enough to hold the requested number of items), rather than simply trying
 to read them and seeing if it hits EOF before it segfaults.

 I suggest changing runFormation() to only try to read as many items as it
 has space for, i.e. replace the existing code with the commented-out
 version in:

 {{{
   //for (size_t i=0; i< nb_runs; i++) {
   while(!instream->eof()) {
 //crt_run_size = (i == nb_runs-1) ? last_run_size: run_size;

 //SDEBUG cout << "i=" << i << ":  runsize=" << crt_run_size << ", ";

 crt_run_size = makeRun_Block(instream, data, run_size, cmp);
 /* #ifdef BLOCKED_RUN */
 /* makeRun(instream, data, crt_run_size, cmp); */
 /* #else */
 /* makeRun_Block(instream, data, crt_run_size, cmp); */
 /* #endif */
 }}}

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

[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
  Reporter:  hamish|   Owner:  grass-dev@lists.osgeo.org
  Type:  defect|  Status:  new  
  Priority:  major |   Milestone:  6.4.0
 Component:  Raster| Version:  6.4.0 RCs
Resolution:|Keywords:  r.watershed, wingrass
  Platform:  MSWindows XP  | Cpu:  x86-32   
---+
Comment (by mmetz):

 Replying to [ticket:783 hamish]:
 >
 {{{
 D1/1: Running: "c:/GRASS-6-SVN/etc/r.watershed.ram"
 el="elevation@permanent" t=1 b
 a="elev10.basin" se="elev10.stream"
 }}}
 >
 Can you try this patch:

 {{{
 --- main.c  (revision 39464)
 +++ main.c  (working copy)
 @@ -233,12 +233,12 @@
  }

  /* Build command line */
 -sprintf(command, "\"%s/etc/", G_gisbase());
 +sprintf(command, "\'%s/etc/", G_gisbase());

  if (flag_seg->answer)
 -   strcat(command, "r.watershed.seg\"");
 +   strcat(command, "r.watershed.seg\'");
  else
 -   strcat(command, "r.watershed.ram\"");
 +   strcat(command, "r.watershed.ram\'");
 }}}

 The idea is to replace the double quotes around the path to the executable
 with single quotes in the hope that the windows version of system() is now
 no longer able to strip the leading and trailing quotes of the whole
 command because these are now different.
 >
 > ps- will the .ram and .seg modules fail in GRASS 7 where uppercase
 option names are disallowed? (eg LS= and S=)
 >
 They still work in GRASS 7, probably because they don't call
 G_parser(argc, argv)? Not sure if this is a good idea not to call
 G_parser(argc, argv).
 >
 > pps- should G_convert_dirseps_to_host() be done in the G_gisbase() and
 G_gisdbase() functions instead or making the modules do it?
 >
 In this case, the module should call G_convert_dirseps_to_host() because
 the module adds "/etc/" to G_gisbase().

 Markus M

 PS: Any reason why r39150 didn't make it into trunk?

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

Re: [GRASS-dev] v.generalize tutorial

2009-10-10 Thread Paolo Cavallini
Hamish ha scritto:
> Paolo wrote:
>> Would it be possible to move the very useful v.generalize tutorial:
>> http://users.ox.ac.uk/~orie1848/tutorial.html
>> to core documentation?
> 
> 
> it's already there my friend,
>   http://grass.osgeo.org/wiki/V.generalize_tutorial

Thanks. However, in the manpage the old link is mentioned:
http://grass.itc.it/grass64/manuals/html64_user/v.generalize.html
All the best.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev


Re: [GRASS-dev] v.generalize tutorial

2009-10-10 Thread Hamish
Paolo wrote:
> Would it be possible to move the very useful v.generalize tutorial:
> http://users.ox.ac.uk/~orie1848/tutorial.html
> to core documentation?


it's already there my friend,
  http://grass.osgeo.org/wiki/V.generalize_tutorial



Hamish




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


[GRASS-dev] [GRASS GIS] #783: r.watershed fails on wingrass

2009-10-10 Thread GRASS GIS
#783: r.watershed fails on wingrass
---+
 Reporter:  hamish |   Owner:  grass-dev@lists.osgeo.org
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.4.0
Component:  Raster | Version:  6.4.0 RCs
 Keywords:  r.watershed, wingrass  |Platform:  MSWindows XP 
  Cpu:  x86-32 |  
---+
 Hi,

 {{{
 GRASS 6.4.0svn (spearfish60) > r.watershed elevation=elevation.1
 0...@permanent threshold=1 basin=elev10.basin s
 tream=elev10.stream
 D1/1: Mode: All in RAM
 D1/1: Running: "c:/GRASS-6-SVN/etc/r.watershed.ram"
 el="elevation@permanent" t=1 b
 a="elev10.basin" se="elev10.stream"

 'c:/GRASS-6-SVN/etc/r.watershed.ram" el="elevation@permanent" t=1
 ba="elev10.basin
 " se="elev10.stream' is not recognized as an internal or external command,
 operable program or batch file.

 WARNING: Subprocess failed with exit code 1
 WARNING: category information for [elev10.basin] in [user1] missing or
  invalid
 WARNING: category information for [elev10.stream] in [user1] missing or
  invalid
 }}}


 r.watershed launches a .seg or .ram version of itself from $GISBASE/etc/.
 It builds up a char string with options then runs the string via system().

 note in the above error messsage the " from the 1st arg and " from the end
 of the last arg have been stripped off. It seems that the quoting is
 greedy and the entire string is being treated as a the executable name?


 Hamish

 ps- will the .ram and .seg modules fail in GRASS 7 where uppercase option
 names are disallowed? (eg LS= and S=)

 pps- should G_convert_dirseps_to_host() be done in the G_gisbase() and
 G_gisdbase() functions instead or making the modules do it?

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

[GRASS-dev] v.generalize tutorial

2009-10-10 Thread Paolo Cavallini
Hi all.
Would it be possible to move the very useful v.generalize tutorial:
http://users.ox.ac.uk/~orie1848/tutorial.html
to core documentation?
Thanks.
-- 
Paolo Cavallini: http://www.faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev