Re: [GRASS-dev] strange NVIZ behavior

[Michael Barton]

Forgot to mention. As I moved and zoomed, the NVIZ scene became slower and 
slower. Eventually it crashed. With no vector overlaid, it is fast. I wonder if 
somehow vector lines are rendered as points now, with a lot of points for a 
long, irregular line like a stream or contour line. Trying to render hundreds 
or thousands of points is slowing it down??

Anyway, here is the error in case someone can make something of it.

"",
"",
"",
"",
"",
"",
"",
"",
"",
"=10)-[SGTSearchField:0x7dea33b0]>",
"",
"=218)]>"
)

Will attempt to recover by breaking constraint
=218)]>

Set the NSUserDefault 
NSConstraintBasedLayoutVisualizeMutuallyExclusiveConstraints to YES to have 
-[NSWindow visualizeConstraints:] automatically called when this happens.  
And/or, break on objc_exception_throw to catch this in the debugger.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Dec 2, 2014, at 5:43 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:



On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
One of my students recently install GRASS 7.0 svn for Windows. Today we tried 
to display a raster DEM in NVIZ, overlaid by a couple contour lines with values 
for walking distance from a site (from r.walk). The lines displayed but are 
floating above the surface at about the level of their contour values (3600 and 
7200), in spite of all my attempts to bring them down to earth.


I see, these are 3D lines. I will look at it, hopefully during the next week.
Related to this are a couple other NVIZ issues I’ve seen

1) making a line width greater than 1 creates a line made up of many many  
symbols at the size of the line width

I wonder if this happens only when the line is draped over a surface, then it's 
drawn as many lines. I don't think there is a simple way to set line caps in 
openGL, so I doubt I could fix it.
2) coloring a line only colors the first segment (cat=1) of a multisegment line.

does this happens  with recent grass? I thought I fixed something similar to 
what you describe sometime in summer, but it might be a different problem. If 
it happens with recent GRASS, could you send me the data (or show the problem 
on nc_spm)?

Anna

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I don’t use 
Windows regularly so I’m not up on what works and does not work.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 
480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 
480-727-0709 (CSDC)
www:  http://csdc.asu.edu, 
http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton


___
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] [GRASS GIS] #2502: wxdigit: "don't save" is not respected

[GRASS GIS]

#2502: wxdigit: "don't save"  is not respected
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  digitizer|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [ticket:2502 mlennert]:
 > I have the feeling that I've seen a message or report on this before,
 but can't find it:
 >
 > When I digitize a new map, then close the digitizer and click on 'No'
 when asked whether I want to save the map, the elements I digitized still
 get saved to the new map.

 The undo/redo logic was wrong and 'do not save = undo all' did not work
 properly. Fixed in r63341, please test.

-- 
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] #2503: wxdigit: wrong undo & redo

[GRASS GIS]

#2503: wxdigit: wrong undo & redo
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  digitizer|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mmetz):

 Replying to [comment:4 mlennert]:
 > Replying to [comment:3 mmetz]:
 > > Replying to [comment:2 mlennert]:
 > > >
 > > > There still is some confusion when one goes back one or two steps,
 then digitizes something else.
 > >
 > > The question is what should happen with the available redo steps if
 digitize something new after some undo steps. Eliminate the redo steps or
 insert the new changeset before the first redo step? This is handled by
 the wx digitizer, not the vector lib.
 >
 > I've tried three different programs (LibreOffice Writer, Inkscape and
 GIMP) and all discard these redo steps,i.e. when you do A, then B, then
 undo B, then do C, you cannot find B again.
 >
 > This seems to be the most intuitive behaviour to me.

 OK.
 >
 > >
 > > > When you then undo and redo again, the stack seems to be mixed
 between the different paths, sometimes leading to objects left on screen
 even when going all the way back to the last possible undo.
 > >
 > > It seems that a new changeset is appended after the last redo step if
 available, leading to a mix-up.
 > >
 >
 > Yes.

 Fixed in trunk r63341, please test.

-- 
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-SVN] r63227 - in grass/trunk/scripts: d.correlate d.out.file d.rast.leg d.redraw d.shadedmap d.to.rast d.vect.thematic d.what.rast d.what.vect

[Vaclav Petras]

On Tue, Dec 2, 2014 at 5:09 PM, Glynn Clements 
wrote:

> Markus Neteler wrote:
>
> > The issue is this:
> >
> > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region rast=lsat7_2002_30
> > GRASS 7.1.svn (nc_spm_08_grass7):~ > d.correlate
> map=lsat7_2002_30,lsat7_2002_40
> > ERROR: No graphics device selected. Use d.mon to select graphics device.
> > Traceback (most recent call last):
> > ...
> > grass.exceptions.CalledModuleError: Module run None ['d.text',
> > 'color=black', 'line=1', 'stdin=CORRELATION', 'size=4'] ended with
> > error
> > Process ended with non-zero return code 1. See errors in the (error)
> output.
>
> I can't reproduce the problem. And I'm not even sure how d.text can
> exit with a non-zero return code without printing any error message.


I can reproduce it. Are you sure you don't have MONITOR or
GRASS_RENDER_IMMEDIATE (or any other if it matters) set? I start GRASS
session (without any special shell environment) and I get it.

The error is the beginning, r.text is printed first (that's ERROR:... I
think), then the error from the main process is printed (Traceback).

I think the solution is try-except or calling the function(s) with with
secret `errors` parameter set to 'exit'. The later is usually not the ideal
solution but it might be appropriate for some calls in d.* scripts. The
issue is that with errors='exit' you cannot provide the user with failed
module name, so then the context of the error message might be unclear.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] strange NVIZ behavior

[Vaclav Petras]

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton 
wrote:

> 1) making a line width greater than 1 creates a line made up of many many
>  symbols at the size of the line width


Now, I actually prefer d.to.rast for this, although it might be sometimes
harder to prepare because it is hard to match extents. I'm not sure how
much it was tested on MS Windows or Mac OS.

http://grass.osgeo.org/grass70/manuals/d.to.rast.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by wenzeslaus):

 Replying to [comment:82 glynn]:
 > Replying to [comment:80 wenzeslaus]:
 > > I'm for explicit long descriptive option names but if it creates more
 issues then it solves (`3draster`) and if everybody would be using the
 shortened version all the time anyway (`rast`, ...), I prefer not to
 change them.
 >
 > Code should always use the full name. Abbreviations are intended for
 interactive use.

 This is what I mean. If we want better interactive use, let's improve it
 but not at expense of writing the code. (`3draster` is improvement for
 interactive use but it makes code worse by requiring `_3draster`.)

 As I said before, short options are mostly advantageous for unix-like
 command lines, so let's use what it used there, the Tab key auto-complete.
 This is definitively not an obsolete thing, for example Git is using it
 extensively, SVN supports it too.

 Another solution for abbreviating `raster` and `raster3d` which solves the
 problem at the level of abbreviating and does not make the code worse
 (although it might harm a little bit) is changing the ambiguity rules as
 [comment:75 Glynn suggested in comment 75]. My first impression from
 shortening actually was that it counts matching letters for each option
 and gives a best match. But this is not (unlike Tab key auto-complete)
 completely isolated from calling the modules from some code, so I'm afraid
 of two things. First, that it can become dangerous for people not using
 the long options in the code (e.g. for compatibility reasons). Second,
 that the option matching can become so costly that it would actually make
 module calls more expensive.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] strange NVIZ behavior

[Anna Petrášová]

On Tue, Dec 2, 2014 at 7:12 PM, Michael Barton 
wrote:

>  One of my students recently install GRASS 7.0 svn for Windows. Today we
> tried to display a raster DEM in NVIZ, overlaid by a couple contour lines
> with values for walking distance from a site (from r.walk). The lines
> displayed but are floating above the surface at about the level of their
> contour values (3600 and 7200), in spite of all my attempts to bring them
> down to earth.
>
>
I see, these are 3D lines. I will look at it, hopefully during the next
week.

>  Related to this are a couple other NVIZ issues I’ve seen
>
>  1) making a line width greater than 1 creates a line made up of many
> many  symbols at the size of the line width
>

I wonder if this happens only when the line is draped over a surface, then
it's drawn as many lines. I don't think there is a simple way to set line
caps in openGL, so I doubt I could fix it.

> 2) coloring a line only colors the first segment (cat=1) of a multisegment
> line.
>

does this happens  with recent grass? I thought I fixed something similar
to what you describe sometime in summer, but it might be a different
problem. If it happens with recent GRASS, could you send me the data (or
show the problem on nc_spm)?

Anna

>
>  I can do a ticket but perhaps these are already fixed in GRASS 7.1? I
> don’t use Windows regularly so I’m not up on what works and does not work.
>
>  Michael
> __
>  C. Michael Barton
>  Director, Center for Social Dynamics & Complexity
>  Professor of Anthropology, School of Human Evolution & Social Change
>  Head, Graduate Faculty in Complex Adaptive Systems Science
>  Arizona State University
>  Tempe, AZ  85287-2402
>  USA
>
>  voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>  fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
>  www:  http://csdc.asu.edu, http://shesc.asu.edu
>  http://www.public.asu.edu/~cmbarton
>
>
> ___
> 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

[GRASS-dev] strange NVIZ behavior

[Michael Barton]

One of my students recently install GRASS 7.0 svn for Windows. Today we tried 
to display a raster DEM in NVIZ, overlaid by a couple contour lines with values 
for walking distance from a site (from r.walk). The lines displayed but are 
floating above the surface at about the level of their contour values (3600 and 
7200), in spite of all my attempts to bring them down to earth.

Related to this are a couple other NVIZ issues I’ve seen

1) making a line width greater than 1 creates a line made up of many many  
symbols at the size of the line width
2) coloring a line only colors the first segment (cat=1) of a multisegment line.

I can do a ticket but perhaps these are already fixed in GRASS 7.1? I don’t use 
Windows regularly so I’m not up on what works and does not work.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

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

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Michael Barton]

I think there are quite a few modules that output vector files where the type 
might vary.


Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Dec 2, 2014, at 12:45 PM, Martin Landa  wrote:

> Hi,
> 
> 2014-12-02 5:31 GMT+01:00 Anna Petrášová :
>> Probably revert http://trac.osgeo.org/grass/changeset/59324? Or create
>> separate options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT?
> 
> there are probably not so many modules which would need
> G_OPT_V_TYPE_OUTPUT, right? Martin

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

Re: [GRASS-dev] [GRASS GIS] #1686: v.mkgrid should offer breaks option for vertical lines too

[GRASS GIS]

#1686: v.mkgrid should offer breaks option for vertical lines too
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  enhancement  |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Vector   | Version:  svn-releasebranch70  
 Keywords:  v.mkgrid |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by neteler):

 Replying to [comment:5 neteler]:
 > Note: this vertex densification should also be added to v.proj

 Thanks to Markus Metz that got implemented in v.proj in r63307 (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] [GRASS GIS] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:81 hcho]:

 > I don't think it's a good idea to have to type an underscore before
 certain option names in Python or possibly other languages and we could
 avoid such annoying/inconsistent situations by naming elements more
 carefully.

 There are two reasons why an option name cannot be used in Python. One is
 if it doesn't conform to the syntax for an identifier (e.g. starts with a
 digit). The other is if it is a reserved word (e.g. "from").

 Avoiding the first case is simple enough. A requirement that option names
 begin with a letter and consist solely of letters, digits and underscores
 will ensure conformance with the identifier syntax for any common
 language.

 The second one is more awkward, as different languages have different sets
 of reserved words. The only real constant is that many of them are quite
 common words which would frequently be an ideal choice for an option name.

 I'm not sure that we should reject such names simply because they can't be
 used as a variable/parameter/etc name in a specific language without a
 tweak such as adding an underscore (or changing case; now that option
 names are limited to lower-case, having grass.script.make_command() force
 each name to lower case would be feasible).

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by glynn):

 Replying to [comment:80 wenzeslaus]:

 > Perhaps we don't have to unabbreviate everything. It seems to me that
 there is no will to unabbreviate options for `g.region` or module names
 containing rast, vect or rast3d.

 FWIW, I would like to unabbreviate everything which could reasonably be
 unabbreviated (including raster and vector rather than rast and vect).
 Clearly, there are cases where this would be unreasonable (e.g. option
 names may contain acronyms which could expand to several words, some of
 which may be long compound words, or may themselves be acronyms).

 > I'm for explicit long descriptive option names but if it creates more
 issues then it solves (`3draster`) and if everybody would be using the
 shortened version all the time anyway (`rast`, ...), I prefer not to
 change them.

 Code should always use the full name. Abbreviations are intended for
 interactive use.

-- 
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-SVN] r63227 - in grass/trunk/scripts: d.correlate d.out.file d.rast.leg d.redraw d.shadedmap d.to.rast d.vect.thematic d.what.rast d.what.vect

[Glynn Clements]

Markus Neteler wrote:

> The issue is this:
> 
> GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region rast=lsat7_2002_30
> GRASS 7.1.svn (nc_spm_08_grass7):~ > d.correlate 
> map=lsat7_2002_30,lsat7_2002_40
> ERROR: No graphics device selected. Use d.mon to select graphics device.
> Traceback (most recent call last):
>   File 
> "/home/neteler/software/grass71/dist.x86_64-unknown-linux-gnu/scripts/d.correlate",
> line 104, in 
> main()
>   File 
> "/home/neteler/software/grass71/dist.x86_64-unknown-linux-gnu/scripts/d.correlate",
> line 46, in main
> grass.write_command('d.text', color = 'black', size = 4, line = 1,
> stdin = "CORRELATION")
>   File 
> "/home/neteler/software/grass71/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
> line 483, in write_command
> return handle_errors(returncode, returncode, args, kwargs)
>   File 
> "/home/neteler/software/grass71/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py",
> line 308, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None ['d.text',
> 'color=black', 'line=1', 'stdin=CORRELATION', 'size=4'] ended with
> error
> Process ended with non-zero return code 1. See errors in the (error) output.

I can't reproduce the problem. And I'm not even sure how d.text can
exit with a non-zero return code without printing any error message.

In any case, display commands don't need any "graphics device" to be
selected.

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

Re: [GRASS-dev] [GRASS GIS] #2256: No projection for web service layer

[GRASS GIS]

#2256: No projection for web service layer
--+-
  Reporter:  martinl  |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  7.0.0
 Component:  Default  | Version:  svn-trunk
Resolution:  fixed|Keywords:  wxGUI, web service   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by turek):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Backported in r63258, r63257 and r63254.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] check on GRASS revision number

[Markus Neteler]

Hi,

just for the record, by chance it happened to me today and how I
solved it easily:

GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
stream_rast=streams@user1 direction=direction@user1
elevation=elevation@PERMANENT accumulation=accum@user1
stream_vect=streams horton=horton
ERROR: Module built against version $Revision: 62395 $ but trying to use
   version $Revision: 63222 $. You need to rebuild GRASS GIS or
   untangle multiple installations.


# Now simply re-run g.extension:
GRASS 7.0.0svn (nc_spm_08_grass7):~ > g.extension r.stream.order
WARNING: Extension  already installed. Re-installing...
Fetching  from GRASS-Addons SVN repository (be patient)...
Compiling...
Installing...
Updating metadata file...
Installation of  successfully finished

# enjoy:
GRASS 7.0.0svn (nc_spm_08_grass7):~ > r.stream.order
stream_rast=streams@user1 direction=direction@user1
elevation=elevation@PERMANENT accumulation=accum@user1
stream_vect=streams horton=horton
All in RAM calculation...
Reading raster map ...
 100%
Reading raster map ...
 100%
Finding nodes...
Finding longest streams...
Calculating Strahler's stream order...
Calculating Hortons's stream order...
Calculating Shreve's stream magnitude, Scheidegger's consistent integer and
Drwal's streams hierarchy (old style)...
Calculating Hack's main streams and topological dimension...
Building topology for vector map ...
...
Writing outpout raster maps...

Hope this helps,
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Martin Landa]

Hi,

2014-12-02 5:31 GMT+01:00 Anna Petrášová :
> Probably revert http://trac.osgeo.org/grass/changeset/59324? Or create
> separate options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT?

there are probably not so many modules which would need
G_OPT_V_TYPE_OUTPUT, right? Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Martin Landa]

2014-12-02 17:56 GMT+01:00 Michael Barton :
> For r.to.vect, there are no input vector features. The only input is a raster.
>
> It is the output that produces vector features.

sorry, I mistake the modules, fixed in r63332. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Indeed, these files are 99% cloned:
  * r.random.cells/gasdev.c
  * r.random.surface/gasdev.c

 and
  * r.random.cells/random.c
  * r.random.surface/random.c

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Michael Barton]

For r.to.vect, there are no input vector features. The only input is a raster.

It is the output that produces vector features.

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Dec 2, 2014, at 6:48 AM, Martin Landa  wrote:

> Hi,
> 
> 2014-11-29 18:20 GMT+01:00 Michael Barton :
>> I just ran into this last night.
>> 
>> The description for the "type" argument for r.to.vect calls it "Input
>> feature type", but actually it should be "Output feature type".
> 
> why do you think so? The option is used to filter out input vector
> features. Martin
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.eu/mentors/landa

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

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Michael Barton]

__
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University
Tempe, AZ  85287-2402
USA

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
www:  http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On Dec 2, 2014, at 6:29 AM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:



On Tue, Dec 2, 2014 at 12:01 AM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:


On Dec 1, 2014, at 9:31 PM, Anna Petrášová 
mailto:kratocha...@gmail.com>> wrote:



On Mon, Dec 1, 2014 at 6:21 PM, Michael Barton 
mailto:michael.bar...@asu.edu>> wrote:
In r.to.vect, this argument ONLY refers to the output vector feature. There are 
not any different feature types for the 2D raster maps that are input to this 
module. I assume that while the nature of the raster map affects the vector 
feature type to some extent, this argument can force it to output a particular 
feature type when there is the potential for multiple feature type output.

I suppose simply “feature type” is OK. But it is the output vector map that is 
being referred to in any case and “input” feature type is misleading IMHO.

Probably revert http://trac.osgeo.org/grass/changeset/59324? Or create separate 
options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT?

But the input is always a raster. So there is no reason for an option 
G_OPT_V_TYPE_INPUT

The output is always a vector, which CAN have different feature types, so there 
is a reason for G_OPT_V_TYPE_OUTPUT.

I was talking about introducing new standard options G_OPT_V_TYPE_INPUT, 
G_OPT_V_TYPE_OUTPUT which would differ only in description (Input feature 
type/Output feature type). r.to.vect would then use G_OPT_V_TYPE_OUTPUT, 
v.to.rast would use  G_OPT_V_TYPE_INPUT. Or we just stay with G_OPT_V_TYPE and 
redefine description.

Yes. This makes sense.

Michael



Michael


Anna


Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 
480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 
(CSDC)
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu















On Dec 1, 2014, at 4:13 PM, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:

> On Sat, Nov 29, 2014 at 6:20 PM, Michael Barton 
> mailto:michael.bar...@asu.edu>> wrote:
>> I just ran into this last night.
>>
>> The description for the “type” argument for r.to.vect calls it “Input
>> feature type”, but actually it should be “Output feature type”.
>
> I'm not sure. The raster input defines also the output to some extent.
> In G6 it was simply called "Feature type", perhaps we should restore
> that description?
>
> Markus

___
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] [GRASS GIS] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by cmbarton):

 I tested this with trunk. While I can do the mechanics of submitting this
 later this week for 7.0 and trunk, I'm a little hesitant since I'm not
 familiar with C and don't know if this should be applied to other
 r.random.x modules or not.

 Michael

-- 
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] #2409: last call for options keys consolidation

[GRASS GIS]

#2409: last call for options keys consolidation
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  task  |  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Default   | Version:  unspecified  
 Keywords:  standardized options  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-

Comment(by hcho):

 Replying to [comment:80 wenzeslaus]:
 > Replying to [comment:79 glynn]:
 > > Replying to [comment:77 annakrat]:
 > > > Replying to [comment:76 cmbarton]:
 > > > > Could it cause a problem somewhere down the line to have this term
 beginning with a number--e.g. If it is used to name a temp file or
 something?
 > > >
 > > > As I already said, it causes problems for Python because keyword
 parameter can't start with number. This is solvable by adding underscore
 and some special handling of this case, which is partially there already.
 It violates pep8.
 > >
 > > PEP8 is a style guide. There is no inherent reason why an argument
 name cannot start with an underscore. And we're not even talking about
 explicit arguments; such arguments will only ever be obtained via the
 **kwargs mechanism.
 >
 > The problem may come once you want to use parameter as an variable or
 member variable. In later case underscore would means private which is
 technique not limited to Python. I'm also afraid that this can hit us or
 somebody else in some other language or system. Almost nothing allows
 numbers at the beginning of identifiers. I also think that for 3D raster
 it is much more probable that you hit this issue. For example, how should
 I name variable in my script which holds 3D raster map name or its
 maximum? `_3draster_name`? `_3draster_max`? I can of course name my
 variables whatever I want but wouldn't we stick to `rast3d` or `raster3d`
 in the GRASS source code anyway?
 >
 > >
 > > In fact, I think that this is why I chose to use a leading underscore
 rather than a trailing underscore.
 > >
 > > Still, I'd rather avoid having option names start with a digit. But
 unless we relax the ambiguity check, it wouldn't outweigh my preference to
 avoid using an option name which has a very common option name (rast or
 raster) as a prefix.
 >
 > I'm glad you are saying that. I think it is really important to state
 the priorities and motivations. If we just want backwards compatibility,
 then some special check in the parser can handle old short option names.
 And if we value the most backwards compatibility and short options, we
 probably should not not shorten at all in these special cases (type
 names).
 >
 > Perhaps it is useful to ask why we want short options. It is for manual
 typing? Well then we perhaps should use techniques used elsewhere. And we
 are actually partially doing it. There is IDE-like auto-complete in GUI,
 Python dir completed is implemented for PyGRASS module interface and of
 course Linux command line auto-completes module names. So why not to take
 it further and auto-complete also parameters and perhaps other things by
 implementing auto-complete for shell?
 >
 > Classic unix-like command line is anyway the only place where short
 options really matter if you consider the things above and also that you
 should not use shortened option names in scripts because it is not
 readable (that's why we are unabbreviating them, right?).
 >
 > Perhaps we don't have to unabbreviate everything. It seems to me that
 there is no will to unabbreviate options for `g.region` or module names
 containing rast, vect or rast3d. I'm for explicit long descriptive option
 names but if it creates more issues then it solves (`3draster`) and if
 everybody would be using the shortened version all the time anyway
 (`rast`, ...), I prefer not to change them.
 >

 I strongly agree with you. Personally, I'm fine with the old type names.
 If shortening rast3d= is an issue because of conflicts with rast=, we
 could change it to volume= or voxel= (and vo.* module names). I don't
 think it's a good idea to have to type an underscore before certain option
 names in Python or possibly other languages and we could avoid such
 annoying/inconsistent situations by naming elements more carefully.

 > If we want short options for whatever reason, let's standardize them,
 rather than standardize the long options and provide ways how to avoid the
 standard.

 +1

-- 
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] #2496: r.random.surface error from RAN C library

[GRASS GIS]

#2496: r.random.surface error from RAN C library
--+-
 Reporter:  cmbarton  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Raster| Version:  svn-trunk
 Keywords:  r.random.surface  |Platform:  MacOSX   
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Will you submit the patch?

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Martin Landa]

Hi,

2014-11-29 18:20 GMT+01:00 Michael Barton :
> I just ran into this last night.
>
> The description for the "type" argument for r.to.vect calls it "Input
> feature type", but actually it should be "Output feature type".

why do you think so? The option is used to filter out input vector
features. Martin

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.eu/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] small interface inconsistency in r.to.vect in GRASS 7

[Anna Petrášová]

On Tue, Dec 2, 2014 at 12:01 AM, Michael Barton 
wrote:

>
>
>  On Dec 1, 2014, at 9:31 PM, Anna Petrášová  wrote:
>
>
>
>  On Mon, Dec 1, 2014 at 6:21 PM, Michael Barton 
> wrote:
>
>> In r.to.vect, this argument ONLY refers to the output vector feature.
>> There are not any different feature types for the 2D raster maps that are
>> input to this module. I assume that while the nature of the raster map
>> affects the vector feature type to some extent, this argument can force it
>> to output a particular feature type when there is the potential for
>> multiple feature type output.
>>
>> I suppose simply “feature type” is OK. But it is the output vector map
>> that is being referred to in any case and “input” feature type is
>> misleading IMHO.
>>
>
>  Probably revert http://trac.osgeo.org/grass/changeset/59324? Or create
> separate options G_OPT_V_TYPE_INPUT, G_OPT_V_TYPE_OUTPUT?
>
>
>  But the input is always a raster. So there is no reason for an option
> G_OPT_V_TYPE_INPUT
>
>  The output is always a vector, which CAN have different feature types,
> so there is a reason for G_OPT_V_TYPE_OUTPUT.
>

I was talking about introducing new standard options G_OPT_V_TYPE_INPUT,
G_OPT_V_TYPE_OUTPUT which would differ only in description (Input feature
type/Output feature type). r.to.vect would then use G_OPT_V_TYPE_OUTPUT,
v.to.rast would use  G_OPT_V_TYPE_INPUT. Or we just stay with G_OPT_V_TYPE
and redefine description.

>
>  Michael
>
>
>  Anna
>
>
>> Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>>
>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  On Dec 1, 2014, at 4:13 PM, Markus Neteler  wrote:
>>
>> > On Sat, Nov 29, 2014 at 6:20 PM, Michael Barton 
>> wrote:
>> >> I just ran into this last night.
>> >>
>> >> The description for the “type” argument for r.to.vect calls it “Input
>> >> feature type”, but actually it should be “Output feature type”.
>> >
>> > I'm not sure. The raster input defines also the output to some extent.
>> > In G6 it was simply called "Feature type", perhaps we should restore
>> > that description?
>> >
>> > Markus
>>
>> ___
>> 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] [GRASS GIS] #2503: wxdigit: wrong undo & redo

[GRASS GIS]

#2503: wxdigit: wrong undo & redo
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  wxGUI| Version:  svn-trunk
 Keywords:  digitizer|Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:3 mmetz]:
 > Replying to [comment:2 mlennert]:
 > > Replying to [comment:1 mmetz]:
 > > > Replying to [ticket:2503 mlennert]:
 > > > > The undo and redo buttons in the digitizer (accessed via the Map
 Display) seem to work well for simple features, but as soon as I use tools
 like split line or similar, the results of undo and redo become somewhat
 arbitrary (at least to the innocent user).
 > > >
 > > > Please try r63265 (trunk) or r63266 (relbr70).
 > >
 > > Much better, thanks !
 > >
 > > There still is some confusion when one goes back one or two steps,
 then digitizes something else.
 >
 > The question is what should happen with the available redo steps if
 digitize something new after some undo steps. Eliminate the redo steps or
 insert the new changeset before the first redo step? This is handled by
 the wx digitizer, not the vector lib.

 I've tried three different programs (LibreOffice Writer, Inkscape and
 GIMP) and all discard these redo steps,i.e. when you do A, then B, then
 undo B, then do C, you cannot find B again.

 This seems to be the most intuitive behaviour to me.

 >
 > > When you then undo and redo again, the stack seems to be mixed between
 the different paths, sometimes leading to objects left on screen even when
 going all the way back to the last possible undo.
 >
 > It seems that a new changeset is appended after the last redo step if
 available, leading to a mix-up.
 >

 Yes.

 Moritz

-- 
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] #2505: v.build.polylines options aren't working

[GRASS GIS]

#2505: v.build.polylines options aren't working
---+
 Reporter:  hellik |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  7.0.0
Component:  Vector | Version:  svn-releasebranch70  
 Keywords:  v.build.polylines  |Platform:  All  
  Cpu:  Unspecified|  
---+

Comment(by mmetz):

 Replying to [ticket:2505 hellik]:

 `cats=no` was indeed not working, fixed in r63321,2 (trunk, relbr70).

 `v.build.polylines` is indeed copying all attribute tables as is from
 input to output, but the categories are processed according to the cats
 option. This means that the attribute table(s) can contain spurious
 entries that do not match any output feature. Other (not all) modules also
 copy attribute tables from input to output as is, without filtering.
 Usually, this does not harm and is not even noticeable.

-- 
Ticket URL: 
GRASS GIS 

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