Re: [GRASS-dev] [GRASS GIS] #2290: Wrong file permissions for grassXY.py on Windows (was: Grass not starting)

[GRASS GIS]

#2290: Wrong file permissions for grassXY.py on Windows (was: Grass not 
starting)
--+-
 Reporter:  dnewcomb  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  critical  |   Milestone:  7.0.0
Component:  Installation  | Version:  svn-releasebranch70  
 Keywords:|Platform:  MSWindows 7  
  Cpu:  x86-64|  
--+-

Comment(by hellik):

 Replying to [comment:8 marisn]:
 > Replying to [comment:7 hellik]:
 > > I wouldn't say that this is a winGRASS '''bug''', it's a window
 operating system and a sytem right issue that can't be solved easily; as
 there are quite a lot of different right managements out there in the
 windows world. so I would class it rather an enhancement than a defect.
 >
 > It is. In *NIX world that equals shipping a package (RPM, deb) with
 missing go+R permissions. This is not a limitation of Windows. This is an
 error in Wingrass installer not setting correct permissions on files.
 Changed the summary to better reflect the scope of this issue.
 >
 > I am not familiar with NSIS and Wingrass, but as grass70.py file was
 affected, I would look on some of the magic touching that particular file,
 i.e.:
 > https://trac.osgeo.org/grass/browser/grass/trunk/mswindows/GRASS-
 Installer.nsi.tmpl#L884

 it could be that changing some content in the file by L884 etc. may change
 the permission rights on some windows systems.

 for setting permission rights:

 http://nsis.sourceforge.net/AccessControl_plug-in

-- 
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] #2372: GRASS 7 on windows starts with minimized CMD window

[GRASS GIS]

#2372: GRASS 7 on windows starts with minimized CMD window
-+--
 Reporter:  marisn   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Startup  | Version:  svn-releasebranch70  
 Keywords:  wingrass |Platform:  MSWindows 8  
  Cpu:  Unspecified  |  
-+--

Comment(by hellik):

 Replying to [comment:6 marisn]:
 [...]
 >  - still it displays why the simple proposal of Hellik in the 1st
 comment would be a good idea.

 nsis-script:  SW_SHOWMINIMIZED => SW_SHOWNORMAL (Ticket #2372);
 description fix
 r61277 trunk,  r61278 relbranch 7

-- 
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 7.1 trunk file man file error

[Sören Gebbert]

Hi,
i hopefully fixed this issue by adding keywords to the raster 3d
library test module in r61274.

Best regards
Soeren

2014-07-15 22:46 GMT+02:00 Michael Barton :
> Just now compiled GRASS 7.1 trunk and got an error in the man file
>
> make[2]:
> `/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/docs/man/man1/index.1'
> is up to date.
> VERSION_NUMBER=7.1.svn
> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/tools/g.html2man.py
> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/docs/html/keywords.html
> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/docs/man/man1/keywords.1
> /Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/docs/html/keywords.html:16:0:
> Error (IndexError('pop from empty list',)):
> SYNOPSIS  href="test.raster3d.lib.html">test.raster3d.lib
>
> make[2]: ***
> [/Users/cmbarton/Dropbox/GRASS_dropbox/source/grass7_dev/dist.x86_64-apple-darwin13.3.0/docs/man/man1/keywords.1]
> Error 1
> make[1]: *** [manpages] Error 2
> make: *** [default] Error 2
>
> 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] Rast3d_location2coord inconsistent behavior

[Anna Petrášová]

Hi,

I have a question about Rast3d_location2coord [1]. It is casting the col,
row, depth values to integer like this:

(int) col

instead of using

(int)floor(col)

as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn't
seem correct to me. Any opinions?

Thanks, Anna

BTW, similar function Rast_northing_to_row from raster library returns
double.


[1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Updates of wiki page for compiling on Ubuntu

[Vaclav Petras]

On Fri, Jun 6, 2014 at 3:49 PM, Vaclav Petras  wrote:

> There are probably also packages which are need for GUI but not specified
> in the list. I think it is namely python-matplotlib which is needed by
> scatter plot.


I'm still not sure which packages are missing. I've added python-gdal to
GDAL section.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1787: Profile Analysis Tool Problems

[GRASS GIS]

#1787: Profile Analysis Tool Problems
+---
 Reporter:  stu |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:  7.1.0
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  profile tool r.profile  |Platform:  All  
  Cpu:  x86-64  |  
+---

Comment(by annakrat):

 Replying to [comment:13 mlennert]:
 >
 > This immediately raises once again the question of whether such
 temporary workaround fixes are really a good idea, especially when we know
 that a fix is actually needed elsewhere. Now that this actually seems to
 work, the needed fix is in risk of oblivion.

 Well, I tried to fix it in r.profile, but I failed. I couldn't find a
 correct way to get the meter-whateverfeet conversion. The problem is that
 in the US they apparently use FootUS instead of feet, so the standard
 grass mechanism for handling units fails to recognize it as feet. (Survey
 foot = 0.3048006096, international foot = 0.3048). g.proj, on the other
 hand, gives correct conversion.

-- 
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 story movie

[Vaclav Petras]

Hi,

in case you don't know about this document:

The Future of GRASS?
http://www.tldp.org/HOWTO/GIS-GRASS/future.html

(found when searching for
http://grass.osgeo.org/grass70/source/REQUIREMENTS.html)


On Tue, Jul 15, 2014 at 2:31 PM, "Peter Löwe"  wrote:

> Hi Martin,
>
> the GRASS GIS Story has already been uploaded by someone to Youtube (
> https://www.youtube.com/watch?v=U3Hf0qI4JLc). Uploading it a second time
> won't do harm, but neither will solve some Youtube-related issues:
>
> Youtube does not allow for advanced search queries on the movies' content:
> The version already available on Youtube can _not_ be found by the search
> queries like "GRASS GIS William Shatner". Further, there is no proper way
> to _cite_ the movie in a publication. In my feeling the movie has already
> become a historical document for the OSGeo community. In the sense of
> information preservation it would be good to have a version which long time
> preserved, citable and fully searchable.
>
> In this vein, an upcoming presentation at FOSS4G 2014 in Portland
> (Scientific Track) will be of interest: "GRASS GIS, Star Trek and old Video
> Tape – a reference case on audiovisual preservation for the OSGeo
> communities" :-)
>
> Best,
> Peter
>
>
>
>
> >Hi,
> >
> >any obstacle to upload GRASS GIS Story movie [1] (takes to much time
> >to load and play) to youtube?
> >
> >Martin
> >
> >[1]
> http://grass.osgeo.org/HostedVideoAlbums/video/GRASS-History-The-GRASS-Story/15/
>
>
>
> 
> ___
> 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] #1972: v.in.ogr wrapper fails with UnicodeEncodeError

[GRASS GIS]

#1972: v.in.ogr wrapper fails with UnicodeEncodeError
--+-
  Reporter:  marisn   |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  closed   
  Priority:  major|   Milestone:  7.0.0
 Component:  wxGUI| Version:  svn-trunk
Resolution:  fixed|Keywords:   
  Platform:  Unspecified  | Cpu:  Unspecified  
--+-
Changes (by annakrat):

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


Comment:

 >
 > Needs a backport to 7.0 branch?

 Done in r61281. Closing the ticket.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Rast3d_location2coord inconsistent behavior

[Sören Gebbert]

Hi Anna,

2014-07-19 19:04 GMT+02:00 Anna Petrášová :
> Hi,
>
> I have a question about Rast3d_location2coord [1]. It is casting the col,
> row, depth values to integer like this:
>
> (int) col
>
> instead of using
>
> (int)floor(col)
>
> as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn't
> seem correct to me. Any opinions?

I totally agree that there should be a function that returns the row,
col and depth as double values, so the developer can decide how to
handle these values. Otherwise there would be no convenient way to
determine where coordinates are located in the voxel.

But i am not sure if the  integer casting is a bug, since the
Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
casting as conversion method. There are algorithms in GRASS that use
only integer casting and algorithms that make use of rounding with
floor() before casting to integer.

The problem arise in case of negative column,row or depth values when
casting to integer without rounding to an integer smaller than the
double number. So the question is are there any chances to receive
negative cols,rows and depths?

It does not seems do to me for col and row, since in case of negative
coordinates will west and south always be smaller than east and north,
resulting in always positive cols and rows. And the same should be
true for depths, unless the top is smaller than bottom.

Best regards
Soeren

>
> Thanks, Anna
>
> BTW, similar function Rast_northing_to_row from raster library returns
> double.
>
>
> [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
>
> ___
> 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] Rast3d_location2coord inconsistent behavior

[Sören Gebbert]

Hi Anna,
i have added the function Rast3d_location2coord_double() to the
raster3d library (r61282) that expects x, y and z as double values.

While doing this i discovered a really horrible bug in the coordinate
transformation for rows. The reason for this bug were wrong coordinate
tests in the raster3d library tests. Wrong indexing leaded me to wrong
northern coordinate to row conversion. This bug appeared in case that
coordinates are located exactly at the north/south border between two
voxels.

This is hopefully fixed now. It should be backported to grass7.0 as
well, after heavy testing.


Best regards
Soeren

2014-07-19 19:04 GMT+02:00 Anna Petrášová :
> Hi,
>
> I have a question about Rast3d_location2coord [1]. It is casting the col,
> row, depth values to integer like this:
>
> (int) col
>
> instead of using
>
> (int)floor(col)
>
> as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn't
> seem correct to me. Any opinions?
>
> Thanks, Anna
>
> BTW, similar function Rast_northing_to_row from raster library returns
> double.
>
>
> [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
>
> ___
> 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-SVN] r61282 - in grass/trunk: include/defs lib/raster3d lib/raster3d/test

[Vaclav Petras]

On Sat, Jul 19, 2014 at 8:02 PM,  wrote:

> Unfortunately changed the editor that i use the indention and converted
> all tabs into spaces at save time. Hence,
> the commit contains 95% tab to space conversion noise.
>

I would actually agree with the change. I think that the GRASS indentation
style is a bug since mixed tabs and spaces are enforced as a rule (not just
allowed). However, it was decided that it won't be fixed and that current
practice should be preserved. [1]

Fortunately, there is a script which can enforce the unusual indent style
[2]. And also `svn diff --ignore-space-change` for cases like this commit.

Anyway, I'm glad you discovered and fixed the bug. It is now painful for me
to see that tests did not showed the bug. That's maybe why in an ideal
world, tests are written by different person than the code (and without
access/looking to the source code).

Vaclav

[1] http://trac.osgeo.org/grass/ticket/1663
[2] http://trac.osgeo.org/grass/browser/grass/trunk/tools/grass_indent.sh
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Rast3d_location2coord inconsistent behavior

[Anna Petrášová]

On Sat, Jul 19, 2014 at 6:30 PM, Sören Gebbert  wrote:

> Hi Anna,
>
> 2014-07-19 19:04 GMT+02:00 Anna Petrášová :
> > Hi,
> >
> > I have a question about Rast3d_location2coord [1]. It is casting the col,
> > row, depth values to integer like this:
> >
> > (int) col
> >
> > instead of using
> >
> > (int)floor(col)
> >
> > as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which
> doesn't
> > seem correct to me. Any opinions?
>
> I totally agree that there should be a function that returns the row,
> col and depth as double values, so the developer can decide how to
> handle these values. Otherwise there would be no convenient way to
> determine where coordinates are located in the voxel.
>
> But i am not sure if the  integer casting is a bug, since the
> Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
> casting as conversion method. There are algorithms in GRASS that use
> only integer casting and algorithms that make use of rounding with
> floor() before casting to integer.
>
> The problem arise in case of negative column,row or depth values when
> casting to integer without rounding to an integer smaller than the
> double number. So the question is are there any chances to receive
> negative cols,rows and depths?
>
> It does not seems do to me for col and row, since in case of negative
> coordinates will west and south always be smaller than east and north,
> resulting in always positive cols and rows. And the same should be
> true for depths, unless the top is smaller than bottom.
>

Yes, but you still can get negative col, for example when looking for the
neighboring voxels of a voxel on the edge of the 3D raster. Then, the
inconsistency causes problem.

Thanks a lot for implementing Rast3d_location2coord_double.

Anna


> Best regards
> Soeren
>
> >
> > Thanks, Anna
> >
> > BTW, similar function Rast_northing_to_row from raster library returns
> > double.
> >
> >
> > [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
> >
> > ___
> > 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