Re: [GRASS-dev] [GRASS GIS] #1757: LD_SEARCH_FLAGS incorrect for NetBSD

[GRASS GIS]

#1757: LD_SEARCH_FLAGS incorrect for NetBSD
-+--
  Reporter:  brook   |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  critical|   Milestone:  7.0.0
 Component:  Default | Version:  svn-trunk
Resolution:  fixed   |Keywords:   
  Platform:  Other Unix  | Cpu:  Unspecified  
-+--
Changes (by mmetz):

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


Comment:

 Replying to [comment:8 mlennert]:
 > Is this still an open ticket ?

 The configure script has been updated accordingly. G7 compiles and runs
 fine for me on NetBSD 6. Closing 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] [GRASS GIS] #1358: WinGRASS 6.4.1: SQLite driver errors: `Unable to open database'

[GRASS GIS]

#1358: WinGRASS 6.4.1: SQLite driver errors: `Unable to open database'
-+--
 Reporter:  rvanderweide |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  minor|   Milestone:  6.4.4
Component:  Database | Version:  6.4.1 RCs
 Keywords:  wingrass, SQLite driver  |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--
Changes (by mmetz):

  * priority:  critical => minor


Comment:

 Replying to [comment:9 hamish]:
 > unless someone has a bright idea for a minimally invasive fix, bumping
 it down the road a little ...

 With GRASS default settings, i.e. the sqlite database in the default
 folder, this does not happen. Changing priority to minor, but the ticket
 could also be closed as invalid. Essentially, this is a sqlite bug with
 sqlite calling fsync() on the directory of the sqlite database even if the
 directory contains files not related to the sqlite database.

-- 
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] #72: PNG driver: boundary rendering is off by one pixel

[GRASS GIS]

#72: PNG driver: boundary rendering is off by one pixel
---+
 Reporter:  hamish |   Owner:  grass-dev@…  

 Type:  defect |  Status:  new  

 Priority:  critical   |   Milestone:  6.4.4

Component:  Default| Version:  svn-develbranch6 

 Keywords:  d.vect, rendering, PNG_DRIVER  |Platform:  Unspecified  

  Cpu:  Unspecified|  
---+

Comment(by mmetz):

 Replying to [comment:22 hamish]:
 > Hi,
 >
 > there is a similar off-by-one problem in the Cairo driver for 6.4 and
 6.5, very easy to reproduce:
 >
 {{{
 export GRASS_WIDTH=100
 export GRASS_HEIGHT=100
 d.mon start=cairo
 d.mon stop=cairo
 }}}
 >
 > you will see a single pixel black line along both the right and bottom
 edges of the resulting map.png file. (trouble if you wanted to use
 GRASS_TRANSPARENT=TRUE)

 This has been introduced by you with r12527. Reverting r12527 removes the
 single pixel black line along both the right and bottom edges. Do you
 remember by any chance the reason for r12527?

 Note that the line drawn by D_show_window() on the left and top edges is
 outside the current frame.

-- 
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] #1866: broken db driver communication in winGRASS 7

[GRASS GIS]

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:44 mmetz]:
 > Replying to [comment:42 neteler]:
 > > Right. So we need a test for that rather than failing with a slightly
 > > obscured error message. Or expand it to say:
 > >
 > > "Table <%s> not found in current mapset"
 >
 > Better:
 > "Table <%s> not found in database <%s> using driver <%s>"
 >
 > Done in r57260.

 Backported to 6.4 and 6.5 in r57264 and r57265.

 Tested with DBF and SQLite backends:

 {{{
 # DBF driver, user1 mapset
 GRASS 6.4.3svn (nc_spm_08):~/grass64 > db.describe bla
 Table  not found in database <$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/>
 using driver 

 GRASS 6.4.3svn (nc_spm_08):~/grass64 > db.describe myarea
 table:myarea
 description:
 insert:yes
 delete:yes
 ncols:5
 nrows:1

 --
 # SQLite driver, sqlite mapset
 GRASS 6.4.3svn (nc_spm_08):~/grass64 > db.tables -p
 testpoint

 GRASS 6.4.3svn (nc_spm_08):~/grass64 > db.describe bla
 Table  not found in database

 <$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite.db> using driver 
 GRASS 6.4.3svn (nc_spm_08):~/grass64 > db.describe testpoint
 table:testpoint
 description:
 insert:?
 delete:?
 ncols:4
 nrows:1

 column:cat
 description:
 type:INTEGER
 ...
 }}}

-- 
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] #1662: Caching bug in 3D raster library with large data

[GRASS GIS]

#1662: Caching bug in 3D raster library with large data
-+--
 Reporter:  huhabla  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  7.0.0
Component:  Raster3D | Version:  svn-trunk
 Keywords:  3D raster, tiles, cache  |Platform:  Linux
  Cpu:  x86-32   |  
-+--

Comment(by mlennert):

 Could you provide the data ?

 Can anyone else confirm this ?

-- 
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] #523: wxGUI: querying a vector map in edit mode does nothing

[GRASS GIS]

#523: wxGUI: querying a vector map in edit mode does nothing
---+
  Reporter:  msieczka  |   Owner:  martinl 
  Type:  defect|  Status:  reopened
  Priority:  major |   Milestone:  6.4.0   
 Component:  Translations  | Version:  svn-develbranch6
Resolution:|Keywords:  
  Platform:  All   | Cpu:  All 
---+

Comment(by mlennert):

 This was for 6.4.0 where wxgui was still an infant. Much of the layer
 interrogation features has significantly changed since then.

 I cannot reproduce these issues on Debian GNU/Linux (in GRASS7 there is no
 interactive editing of attributes outside the digitiser, AFAIK).

 Can someone test on Windows ?

 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] #1260: Georectifier: RMS broken

[GRASS GIS]

#1260: Georectifier: RMS broken
---+
  Reporter:  q076256   |   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:|Keywords:  wingrass, gcp, georect   
  Platform:  MSWindows 2K  | Cpu:  x86-32   
---+

Comment(by mlennert):

 Replying to [ticket:1260 q076256]:
 >
 > '''Issue 1:'''[[BR]]
 > Rectifying raster maps in xy breaks when RMS is calculated. Raster map
 was imported and 6 RCP's defined. Whereas first rectification 1st order
 was set. Number of RCP's was increased up to 6. Now RMS selected - ok,
 then rectification set to 2nd order and RMS selected -> see following
 backtrace:[[BR]]
 >
 > 'ascii' codec can't decode byte 0xfc in position 44: ordinal
 > not in range(128)
 > Traceback (most recent call last):
 >   File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 > mingw32/etc/gui/wxpython/gui_modules/gcpmanager.py", line
 > 1292, in OnRMS
 >   File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 > mingw32/etc/gui/wxpython/gui_modules/gcpmanager.py", line
 > 1603, in RMSError
 >   File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 > mingw32/etc/gui/wxpython/gui_modules/gcmd.py", line 573, in
 > RunCommand
 >   File "c:/osgeo4w/usr/src/grass_trunk/dist.i686-pc-
 > mingw32/etc/gui/wxpython/gui_modules/gcmd.py", line 77, in
 > __init__
 > UnicodeDecodeError
 > :
 > 'ascii' codec can't decode byte 0xfc in position 44: ordinal
 > not in range(128)[[BR]]


 This is (was) an encoding error. From the pathnames, it seems that the OP
 works in a German environment. The po files for the gcp manager (notably
 the message about not enough GCPs) contains special characters in German.
 I just tried to reproduce in a French environment and the message shows up
 correctly. But that's in Debian GNU/Linux, not Windows.

 > '''Issue 2:'''[[BR]]
 > Now selection rectification 3d order immediately expands the GCP list
 with further 4 entries with 0 values, RMS selected shows message: not
 enough GCP's.
 > Now rectification 2d order selected and RMS run -> same as up here.

 I don't understand why here the message would work for 3rd order, but not
 for 2d order.


 > At this time the GCP #7 can not be defined, a click in the map with
 setGCP always set the points in GCP #10 no matter what GCP entry in the
 list is selected.[[BR]]

 I cannot reproduce this, at least no on Debian GNU/Linux.

 > Now added a 7th GCP and choosed rectification 2d order, RMS works fine.
 But if there are only 6 GCP activated the behavior is as in the 1st case
 up here. In this case there shall be a warning: not enough points,
 obviously for 2nd order 6 GCP are not enough![[BR]]

 There is a warning. Apparently it failed at the time because of encoding
 issues.


 > '''Issue 3:'''[[BR]]
 > Removing one or more GCPs from the list, saving GCPs and end and restart
 Georectifier do not work, see trace below:[[BR]]

 Again, I cannot reproduce this in Debian GNU/Linux. ISTR a similar issue a
 couple years, but that was solved. Cannot find trace of it, though.


 > '''Hint:''' Even more than one empty line at the end of one of the
 points files prevents Georectifier from starting up

 Cannot reproduce in Debian GNU/Linux.

 > '''Issue 4:'''[[BR]]
 > Removing a GCP form the the list does not clear the Backward error
 field.

 Cannot reproduce in Debian GNU/Linux.

 Could someone try to reproduce these issues in Windows ?

-- 
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] #2040: g.mapset does not create WIND file if new mapset is created in other location

[GRASS GIS]

#2040: g.mapset does not create WIND file if new mapset is created in other
location
-+--
 Reporter:  mlennert |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  mapset WIND  |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 In trunk:

 {{{
 GRASS 7.0.svn (nc_spm_08):/data/home/mlennert > g.mapset -c testmapset
 location=XY
 Your shell continues to use the history for the old mapset
 You can switch the history by commands:
 history -w; history -r /data/GRASS/DATA7/XY/testmapset/.bash_history;

 GRASS 7.0.svn (nc_spm_08):/data/home/mlennert > ls
 /data/GRASS/DATA7/XY/testmapset/
 GRASS 7.0.svn (nc_spm_08):/data/home/mlennert >
 }}}

 g.region -d fixes the issue, but g.mapset should create the WIND file
 automatically.

-- 
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] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI

[GRASS GIS]

#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
--+-
 Reporter:  huhabla   |   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  major |   Milestone:  7.0.0 
   
Component:  wxGUI | Version:  svn-trunk 
   
 Keywords:  display, Python, multiprocessing  |Platform:  All   
   
  Cpu:  All   |  
--+-

Comment(by huhabla):

 I have updated the display benchmark script to compare the PPM performance
 of PIL and g.pnmcomp. System: Ubuntu 12.04 LTS,  AMD Phenom(tm) II X6
 1090T Processor, 16GB RAM, 1TB Harddisk. Please make sure that you have
 the latest grass7 svn version to reproduce the benchmark results, since
 there was a bug in the pygrass Module run() function, that did not allow
 parallel process runs.

 {{{
 GRASS 7.0.svn (nc_spm_08_grass7):~/Downloads > python display_bench.py
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  228500
 south:  215000
 west:   63
 east:   645000
 nsres:  10
 ewres:  10
 rows:   1350
 cols:   1500
 cells:  2025000
 *** Serial runs
 Run SizeDriver  Bitmap  mmaprender  composite
 1   1024png png FALSE   0.859   0.135  PIL
 2   1024png bmp FALSE   0.447   0.044  PIL
 3   1024png bmp TRUE0.446   0.044  PIL
 4   1024png ppm FALSE   0.430   0.046  PIL
 5   1024png ppm FALSE   0.461   0.066  g.pnmcomp
 6   1024cairo   png FALSE   0.900   0.102  PIL
 7   1024cairo   bmp FALSE   0.535   0.055  PIL
 8   1024cairo   bmp TRUE0.527   0.045  PIL
 9   1024cairo   ppm FALSE   0.579   0.050  PIL
 10  1024cairo   ppm FALSE   0.579   0.051  g.pnmcomp
 11  4096png png FALSE   5.106   1.513  PIL
 12  4096png bmp FALSE   2.728   0.602  PIL
 13  4096png bmp TRUE2.724   0.596  PIL
 14  4096png ppm FALSE   2.402   0.604  PIL
 15  4096png ppm FALSE   2.129   0.306  g.pnmcomp
 16  4096cairo   png FALSE   4.011   1.236  PIL
 17  4096cairo   bmp FALSE   1.273   0.633  PIL
 18  4096cairo   bmp TRUE1.281   0.599  PIL
 19  4096cairo   ppm FALSE   2.510   0.606  PIL
 20  4096cairo   ppm FALSE   2.230   0.311  g.pnmcomp
 *** Parallel runs
 Run SizeDriver  Bitmap  mmaprender  composite
 1   1024png png FALSE   0.856   0.127  PIL
 2   1024png bmp FALSE   0.456   0.052  PIL
 3   1024png bmp TRUE0.457   0.044  PIL
 4   1024png ppm FALSE   0.442   0.048  PIL
 5   1024png ppm FALSE   0.447   0.059  g.pnmcomp
 6   1024cairo   png FALSE   0.902   0.100  PIL
 7   1024cairo   bmp FALSE   0.535   0.049  PIL
 8   1024cairo   bmp TRUE0.528   0.042  PIL
 9   1024cairo   ppm FALSE   0.586   0.046  PIL
 10  1024cairo   ppm FALSE   0.595   0.063  g.pnmcomp
 11  4096png png FALSE   4.481   1.535  PIL
 12  4096png bmp FALSE   2.331   0.608  PIL
 13  4096png bmp TRUE2.344   0.595  PIL
 14  4096png ppm FALSE   2.139   0.603  PIL
 15  4096png ppm FALSE   1.808   0.294  g.pnmcomp
 16  4096cairo   png FALSE   3.374   1.226  PIL
 17  4096cairo   bmp FALSE   1.269   0.619  PIL
 18  4096cairo   bmp TRUE1.283   0.586  PIL
 19  4096cairo   ppm FALSE   2.117   0.598  PIL
 20  4096cairo   ppm FALSE   1.790   0.486  g.pnmcomp
 }}}

-- 
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] #232: raster and vector mismatch in monitors

[GRASS GIS]

#232: raster and vector mismatch in monitors
--+-
  Reporter:  hcho |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  reopened 
  Priority:  major|   Milestone:  6.4.4
 Component:  Default  | Version:  svn-releasebranch64  
Resolution:   |Keywords:  display, monitor 
  Platform:  Linux| Cpu:  x86-32   
--+-
Changes (by mlennert):

  * version:  svn-trunk => svn-releasebranch64
  * milestone:  7.0.0 => 6.4.4


Comment:

 Replying to [comment:3 hamish]:
 > The bug still exists, at least in GRASS 6. Play with "xmag".

 Ok, I can see it in GRASS 6 release, but not in 7. Can you reproduce it in
 7 ?

 I'm changing the milestone and version of this bug to better reflect where
 the issue is.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

[Glynn Clements]

Markus Neteler wrote:

> ERROR: MAPSET PERMANENT - permission denied

This error is generated by G__gisinit() if G__mapset_permissions()
returns 0 (mapset directory exists but not owned by the current user).

> How come that it tries to write in PERMANENT? This needs to be fixed for sure.

It isn't trying to write in PERMANENT. It's trying to execute the
command (to generate the HTML) with $GISBASE/demolocation/PERMANENT as
the current mapset. If the person running g.extension isn't the owner
of $GISBASE/demolocation/PERMANENT, that will fail.

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

Re: [GRASS-dev] [GRASS GIS] #1866: broken db driver communication in winGRASS 7

[GRASS GIS]

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by mmetz):

 Replying to [comment:42 neteler]:
 > Replying to [comment:41 mlennert]:
 > > Replying to [comment:39 mlennert]:
 > > > Replying to [comment:38 neteler]:
 > > > > Replying to [comment:34 hamish]:
 > > > > > Replying to [comment:33 neteler]:
 > > > > > > I have tried with r56943 on Windows8, still failing:
 > > > > >  {{{
 > > > > > > GRASS 7.0.svn> db.describe overpasses
 > > > >
 > > > > ...
 > > > > > is the overpass vector map in the current mapset?
 >
 > No. I tried from the user1 mapset.
 >
 > > > > > You may be seeing the effect of the db.* modules only working
 for databases linked from maps in the current mapset

 This is not true. All db.* modules (should) have an option to define the
 database and driver, as for example db.describe, which can describe any
 table in any database, as long as the driver is supported.
 >
 > Right. So we need a test for that rather than failing with a slightly
 > obscured error message. Or expand it to say:
 >
 > "Table <%s> not found in current mapset"

 Better:
 "Table <%s> not found in database <%s> using driver <%s>"

 Done in r57260.

-- 
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] #1866: broken db driver communication in winGRASS 7

[GRASS GIS]

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-
Changes (by mlennert):

  * priority:  blocker => normal


Comment:

 Replying to [comment:42 neteler]::
 > > > > Replying to [comment:34 hamish]:

 > > > > > You may be seeing the effect of the db.* modules only working
 for databases linked from maps in the current mapset


 > Right. So we need a test for that rather than failing with a slightly
 > obscured error message. Or expand it to say:
 >
 > "Table <%s> not found in current mapset"

 The current test is this:

 {{{

 if (db_describe_table(driver, &table_name, &table) != DB_OK)
 G_fatal_error(_("Unable to describe table <%s>"),
 db_get_string(&table_name));
 }}}

 i.e. it justs checks whether it can describe the table and if not it
 fails. No attempt to no why it cannot describe the table (table does not
 exist in this mapset, bad spelling, etc). As the module does allow you to
 define the driver and database (meaning that you can actually describe a
 table in any database, not only tables in a database linked to a GRASS
 mapset), the issue is larger than just mapsets. I would suggest something
 like:


 {{{
 ERREUR :Unable to describe table . Check database connection
 information.
 }}}

 and adding a few lines to the manual.

 I'm attaching a relevant patch proposal.

 In any case, I'm downgrading this bug's priority.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G7: Definition problem in parser_standard_options.c

[Glynn Clements]

Markus Neteler wrote:

> Besides copying manually the G_asprintf() stuff into the module (no
> good), is there a better way of implementing it?

If the module changes ->options, it needs to change ->descriptions to
match. 

However, if it's only appending options, it can make use of the
existing descriptions, e.g.:

char *desc = method->descriptions;
G_asprintf((char **) &(method->descriptions),
   "%s;lanczos;%s", desc,
   _("Lanczos interpolation"));
G_free(desc);

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

Re: [GRASS-dev] [GRASS GIS] #1250: r.to.vect -v flag creates corrupt file

[GRASS GIS]

#1250: r.to.vect -v flag creates corrupt file
--+-
  Reporter:  cmbarton |   Owner:  grass-dev@…   
  Type:  defect   |  Status:  closed
  Priority:  major|   Milestone:  7.0.0 
 Component:  Raster   | Version:  svn-trunk 
Resolution:  worksforme   |Keywords:  r.to.vect, raster to vector conversion
  Platform:  Unspecified  | Cpu:  Unspecified   
--+-
Changes (by mlennert):

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


Comment:

 For me, working in the NC dataset

 g.region rast=streams_derived
 r.to.vect -v streams_derived out=streams_derived

 works perfectly.

 As this report is 3 years old, I'll close it for now. Reopen if needed.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

[Markus Neteler]

Hi,

when putting the PERMANENT permissions the GRASS way:
GRASS 7.0.svn (latlong):~ > ls -la /grassdata/latlong | grep PERMA
drwxr-xr-x 14 neteler  gis 4096 Mar 12 11:43 PERMANENT

in order to avoid that other group "gis" member be able to delete
PERMANENT through command line, a problem in g.extension appears:

GRASS 7.0.svn (latlong):~ > g.extension v.surf.mass
D1/1: grass.script.core.start_command(): g.version -rge
D1/1: grass.script.core.start_command(): g.message message=Fetching
 from GRASS-Addons SVN (be patient)...
Fetching  from GRASS-Addons SVN (be patient)...
D1/1: grass.script.core.start_command(): g.message message=Compiling...
Compiling...
ERROR: MAPSET PERMANENT - permission denied
make: *** [v.surf.mass.tmp.html] Error 1
D1/1: grass.script.core.start_command(): g.message -e
message=Compilation failed, sorry. Please check above error messages.
ERROR: Compilation failed, sorry. Please check above error messages.


GRASS 7.0.svn (latlong):~ > g.gisenv
MAPSET=matteo
GISDBASE=/grassdata
LOCATION_NAME=latlong
GUI=text
DEBUG=1

How come that it tries to write in PERMANENT? This needs to be fixed for sure.

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

Re: [GRASS-dev] [GRASS GIS] #523: wxGUI: querying a vector map in edit mode does nothing

[GRASS GIS]

#523: wxGUI: querying a vector map in edit mode does nothing
---+
  Reporter:  msieczka  |   Owner:  martinl 
  Type:  defect|  Status:  reopened
  Priority:  major |   Milestone:  6.4.0   
 Component:  Translations  | Version:  svn-develbranch6
Resolution:|Keywords:  
  Platform:  All   | Cpu:  All 
---+
Changes (by hamish):

  * status:  closed => reopened
  * resolution:  worksforme =>


Comment:

 Please confirm bugs as fixed before closing them.

 thanks, Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1260: Georectifier: RMS broken

[GRASS GIS]

#1260: Georectifier: RMS broken
---+
  Reporter:  q076256   |   Owner:  grass-dev@…  
  Type:  defect|  Status:  reopened 
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:|Keywords:  wingrass, gcp, georect   
  Platform:  MSWindows 2K  | Cpu:  x86-32   
---+
Changes (by hamish):

  * status:  closed => reopened
  * resolution:  worksforme =>


Comment:

 Please confirm bugs as fixed before closing them.


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #232: raster and vector mismatch in monitors

[GRASS GIS]

#232: raster and vector mismatch in monitors
--+-
  Reporter:  hcho |   Owner:  grass-dev@…  
  Type:  defect   |  Status:  reopened 
  Priority:  major|   Milestone:  7.0.0
 Component:  Default  | Version:  svn-trunk
Resolution:   |Keywords:  display, monitor 
  Platform:  Linux| Cpu:  x86-32   
--+-
Changes (by hamish):

  * status:  closed => reopened
  * resolution:  worksforme =>


Comment:

 The bug still exists, at least in GRASS 6. Play with "xmag".

 Also a similar issue is visible in symbols, but that's different, this one
 is to do with d.vect.


 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] [GRASS GIS] #523: wxGUI: querying a vector map in edit mode does nothing

[GRASS GIS]

#523: wxGUI: querying a vector map in edit mode does nothing
---+
  Reporter:  msieczka  |   Owner:  martinl 
  Type:  defect|  Status:  closed  
  Priority:  major |   Milestone:  6.4.0   
 Component:  Translations  | Version:  svn-develbranch6
Resolution:  worksforme|Keywords:  
  Platform:  All   | Cpu:  All 
---+
Changes (by mlennert):

  * status:  assigned => closed
  * resolution:  => worksforme


Comment:

 Replying to [comment:12 martinl]:
 > Asking the reporter, is this ticket still relevant to the recent version
 - 6.4.3svn?

 As there has been no response for 10 months, I'm closing this ticket.

 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] #1866: broken db driver communication in winGRASS 7

[GRASS GIS]

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by neteler):

 Replying to [comment:41 mlennert]:
 > Replying to [comment:39 mlennert]:
 > > Replying to [comment:38 neteler]:
 > > > Replying to [comment:34 hamish]:
 > > > > Replying to [comment:33 neteler]:
 > > > > > I have tried with r56943 on Windows8, still failing:
 > > > >  {{{
 > > > > > GRASS 7.0.svn> db.describe overpasses
 > > >
 > > > ...
 > > > > is the overpass vector map in the current mapset?

 No. I tried from the user1 mapset.

 > > > > You may be seeing the effect of the db.* modules only working for
 databases linked from maps in the current mapset

 Right. So we need a test for that rather than failing with a slightly
 obscured error message. Or expand it to say:

 "Table <%s> not found in current mapset"


 ...
 > > Does it really hang, or does it fail and give back the prompt after
 the error message ?

 No, it comes back to the command line just checked again with a current
 OSGeo4W-GRASS 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 GIS] #469: raster data needs binary mode on windows

[GRASS GIS]

#469: raster data needs binary mode on windows
-+--
 Reporter:  jef  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:  wingrass |Platform:  MSWindows XP 
  Cpu:  Unspecified  |  
-+--

Comment(by mlennert):

 Replying to [comment:19 neteler]:
 > Still relevant for GRASS 7?

 Glynn ? MarkusM ? I would think that this is not an issue in grass7 ?

-- 
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] #438: v.distance -a uses too much memory

[GRASS GIS]

#438: v.distance -a uses too much memory
--+-
 Reporter:  mlennert  |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  major |   Milestone:  7.0.0 
   
Component:  Vector| Version:  svn-trunk 
   
 Keywords:  v.distance memory allocation  |Platform:  Unspecified   
   
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:1 neteler]:
 > Is this still an issue with the current 7.SVN version?

 The code has changed.

 I just checked on a machine with 8GB of RAM and

 v.distance -a -p from=ssbel from_type=centroid to=ssbel to_type=centroid
 upload=dist col=dist > dist_ssbel

 where ssbel has a bit more than 2 centroids, still crashed after
 memory _and_ swap go up to their max levels.

 I'm aware that we're talking about 400,000,000 pairs of points, but I'm
 still hoping that there is a way to avoid such heavy memory usage.

 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] #232: raster and vector mismatch in monitors

[GRASS GIS]

#232: raster and vector mismatch in monitors
-+--
  Reporter:  hcho|   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  major   |   Milestone:  7.0.0
 Component:  Default | Version:  svn-trunk
Resolution:  worksforme  |Keywords:  display, monitor 
  Platform:  Linux   | Cpu:  x86-32   
-+--
Changes (by mlennert):

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


Comment:

 This is 5 years old and I cannot reproduce the problem with the wxgui, so
 closing.

-- 
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] #222: v.in gns broken in grass 7.0 trunk

[GRASS GIS]

#222: v.in gns broken in grass 7.0 trunk
--+-
 Reporter:  gisix |   Owner:  gisix
 Type:  defect|  Status:  assigned 
 Priority:  normal|   Milestone:  7.0.0
Component:  Vector| Version:  svn-trunk
 Keywords:  v.in.gns  |Platform:  Linux
  Cpu:  x86-32|  
--+-
Changes (by mlennert):

  * priority:  major => normal


Comment:

 No one has touched this report for 5 years and the code has not changed
 significantly.

 I just tried with 8 different gns country files and only 2 worked.

 As this is only a convenience script around v.in.ascii, I propose to
 deprecate this module and take it out of trunk and/or move it to addons.

 In any case, while waiting for opinions, I'm downgrading this to normal.

 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] #1866: broken db driver communication in winGRASS 7

[GRASS GIS]

#1866: broken db driver communication in winGRASS 7
--+-
 Reporter:  martinl   |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  blocker   |   Milestone:  7.0.0
Component:  Database  | Version:  unspecified  
 Keywords:  sqlite, wingrass  |Platform:  MSWindows 2K 
  Cpu:  Unspecified   |  
--+-

Comment(by mlennert):

 Replying to [comment:39 mlennert]:
 > Replying to [comment:38 neteler]:
 > > Replying to [comment:34 hamish]:
 > > > Replying to [comment:33 neteler]:
 > > > > I have tried with r56943 on Windows8, still failing:
 > > >  {{{
 > > > > GRASS 7.0.svn> db.describe overpasses
 > >
 > > ...
 > > > is the overpass vector map in the current mapset? You may be seeing
 the effect of the db.* modules only working for databases linked from maps
 in the current mapset, unless you explicitly set database= to the real
 path, not the default which may expand $MAPSET to the current mapset, not
 the other mapset's dir name.
 > >
 > > In fact it was in a different mapset (PERMANENT). But it should not
 hang
 > > (instead it should report that the table was not found in the current
 mapset).
 >
 > Does it really hang, or does it fail and give back the prompt after the
 error message ?

 ping

-- 
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] #1260: Georectifier: RMS broken

[GRASS GIS]

#1260: Georectifier: RMS broken
---+
  Reporter:  q076256   |   Owner:  grass-dev@…  
  Type:  defect|  Status:  closed   
  Priority:  blocker   |   Milestone:  7.0.0
 Component:  wxGUI | Version:  svn-trunk
Resolution:  worksforme|Keywords:  wingrass, gcp, georect   
  Platform:  MSWindows 2K  | Cpu:  x86-32   
---+
Changes (by mlennert):

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


Comment:

 As we haven't heard anything from the OP in years, and no one seems to
 have confirmed the bug, I'm closing it. Reopen if needed.

-- 
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] #2017: osgf compilation error

[GRASS GIS]

#2017: osgf compilation error
---+
 Reporter:  martinl|   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  blocker|   Milestone:  7.0.0
Component:  Compiling  | Version:  svn-trunk
 Keywords:  libc   |Platform:  Linux
  Cpu:  x86-64 |  
---+

Comment(by mlennert):

 Martin,

 Can you confirm this issue, or can we close the bug ?

 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] start grass with only initializing the environment

[Rainer M Krug]

Hamish  writes:

> Rainer wrote:
>
>>  I would therefore suggest an additional startup argument for grass,
>>  which only sets the environmental variables, including library paths,
>>  so that GRASS commands can be executed afterwards,
>
> just make your own batch file or function(){} for /etc/bash.bashrc?

Sure - that is how it works at the moment, but I ran into problems: the
problem were library paths, which were not set (on Mac OS X). 

Background: the idea is to use in spgrass6 to make it more robust to
different versions and platforms on which it is used.

>
>
>> and if the LOCATION_NAME and MAPSET are not provided, they will be
>> null and *have  to be set manualy afterwards*.
>
> that doesn't sound like a practice we should promote.
>
>
> what part of the start up are you trying to avoid? ('grass64 -text'
> works in 6 too, or 'g.gui text' to avoid the gui at startup)

Please see my other email, in which I explained why -text does not help
here.

>
> see also the usage for GRASS_BATCH_JOB, which basically does that in
> a non-interactive environment.

Exactly - what would be needed, is that GRASS does not exit, but rather
stays in the background and can be used via the spgrass6 command
execGRASS().

Cheers,

Rainer

>
>
> Hamish


-- 
Rainer M. Krug

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

Re: [GRASS-dev] start grass with only initializing the environment

[Rainer M Krug]

Markus Neteler  writes:

> On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug  wrote:
> ...
>> I would therefore suggest an additional startup argument for grass,
>> which only sets the environmental variables, including library paths,
>> so that GRASS commands can be executed afterwards, and if the
>> LOCATION_NAME and MAPSET are not provided, they will be null and *have
>> to be set manualy afterwards*.
>> This could e.g. have the name "-noui" indicating that no ui will be
>> started.
>
> I wonder what the difference to starting GRASS 7 with  -text is...
> Maybe that's already enough?

No - this doesn't work. 

The idea is to use this from R to set the environmental parameter when
using spgrass6. If I call grass -text from R (all in the terminal), the
grass session opens and I am in grass, but I can not do anything from R,
which I want to do. 

So it seems that the grass startup script recognises that it is not in a
shell, and then starts one? If this starting of the shell could be
suppressed, I would expect that starting grass with the -text option
should work. I would assume that this would be similar to setting
GRASS_BATCH_JOB, only that GRASS does not exit automatically.
Something like a GRASS_BATCH_MODE - or one could call it a GRASS_SERVER_MODE?

Cheers,

Rainer


>
> Markus


-- 
Rainer M. Krug

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

[GRASS-dev] G7: Definition problem in parser_standard_options.c

[Markus Neteler]

Hi,

I just discovered that local modifications of predefined
parser variables influence the help text/manual/etc:
Example:


http://grass.osgeo.org/grass70/manuals/r.resamp.interp.html
...
method=string
Sampling interpolation method
Options: nearest, linear, cubic, lanczos
Default: linear
nearest: Nearest-neighbor interpolation
linear: Linear interpolation
cubic: Cubic interpolation
...  <<-- missing: lanczos


because of
lib/gis/parser_standard_options.c

   case G_OPT_R_INTERP_TYPE:
Opt->key = "method";
Opt->type = TYPE_STRING;
Opt->required = NO;
Opt->description = _("Sampling interpolation method");
Opt->options = "nearest,linear,cubic";
G_asprintf((char **) &(Opt->descriptions),
   "nearest;%s;linear;%s;cubic;%s",
   _("Nearest-neighbor interpolation"),
   _("Linear interpolation"),
   _("Cubic interpolation"));
break;

Besides copying manually the G_asprintf() stuff into the module (no
good), is there a better way of implementing it?

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

Re: [GRASS-dev] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps

[Martin Landa]

Hi,

2013/7/24 Markus Metz :
>> I checked `v.unpack`. What exactly is not working? I haven't found any
>> problem related to db [1] and proj file [2].
>
> Sorry for the confusion, I received a vector packed with a pre-r57119
> v.pack which the current v.unpack could not unpack.

I will fix `v.unpack` also for this case. Thanks for testing. Martin
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev