Re: [GRASS-dev] i.latlong

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 17/07/2013 15:21, Markus Neteler ha scritto:
> On Wed, Jul 17, 2013 at 12:06 PM, Paolo Cavallini  
> wrote:

>> Just seen the very nice i.latlong (BTW: why not r.latlong?): any hope
>> of having it backported to grass6?
> 
> Done in r57191.
> 
> You can test it with:
> g.extension i.latlong
> 
> I agree that r.latlong would be more appropriate.
> If there are no objections, I would rename it in both G6 Addons and G7.

Thanks a lot. So it will be in the addons, not in main?
BTW: if I can have a list of the new or changed packages in the new release, I 
can
update qgis and sextante modules.
All the best.

- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlHnirQACgkQ/NedwLUzIr4eNACeI0LC+HD2HWzHRB/a61x7AezS
GUAAoKCmfsD3A8O3f0TQ/ixgAfG+eT+C
=MUNk
-END PGP SIGNATURE-
___
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:

> The point here is (as experienced on our local shared network
> grassdata/ recently):
> - GRASS allows users to enter their own mapset(s)
> - GRASS allows users to read all mapsets and write into the current (own) one
> - GRASS does not allow to modify the mapset of a different user

In 7.0, the last one can be suppressed by setting the environment
variable GRASS_SKIP_MAPSET_OWNER_CHECK to any non-empty string.

Of course, you still need write permission on the underlying files and
directories.

> So far so nice.
> 
> Assume that several users belong to the same group. If now the group
> write flag is enabled for mapsets, users can delete them even if they
> are not their own. This is fine since someone (admin) must have
> allowed for this.
> 
> Now back to GRASS: A user runs a session in his/her mapset with
> group-write enabled. This is against the GRASS internal policy where
> others cannot write into your own mapsets with GRASS commands.
> 
> Wish for improvement:
> When starting a session in a mapset with group/other-write enabled,
> issue a warning to inform the user about this in the startup script.
> This would follow the "least-surprise" paradigm.
> Feasible?

Yes. Just don't do anything too invasive.

Bear in mind that paying too much attention to filesystem permissions
has a similar problem to the ownership check, namely that most Unix
systems are capable of accessing non-Unix filesystems (e.g. FAT, NTFS,
CIFS). This is one reason why I added the ability to suppress the
check.

-- 
Glynn Clements 
___
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 glynn):

 Replying to [comment:2 huhabla]:

 > I have the hope to speed up the composition by avoiding disc I/O.

 If one process writes a file and another immediately reads it, it doesn't
 necessarily involve "disc" I/O.

 The OS caches disc blocks in RAM. write() completes as soon as the data
 has been copied to the cache (the kernel will copy it to disc on its own
 schedule), read() reads the data from the cache (and only requires disc
 access for data which isn't already in the cache).

 The kernel will use all "free" memory for the disc cache. So unless memory
 pressure is high, the files written by the display driver will remain in
 the cache for quite a while.

 > As far as i understand mmap(), it is file backed and reads/writes the
 data from the file on demand into the shared memory? An exception is
 anonymous mapping, but is this also supported on windows? How can we
 access the anonymous mmap() from wxPython?

 Anonymous mmap() isn't relevant here. mmap() is file backed, but this
 doesn't affect the time required to read and write the file unless memory
 pressure is so high that the size of the file exceeds the amount of free
 memory. In the event that sufficient free memory is available, neither
 writing nor reading will block waiting for disc I/O.

 > > Once you have d.* commands generating BMP files, it shouldn't be
 necessary to add any binary blobs to wxGUI. Compositing should be
 perfectly viable within Python using either numpy, PIL or wxPython (having
 wxPython perform the compositing during rendering may be able to take
 advantage of video hardware).
 >
 > What do you mean with binary blobs? Binary large objects?

 Machine code.

 IOW, it shouldn't be necessary to move g.pnmcomp into a library (DLL/DSO)
 which is accessed from the wxGUI process. The replacement can just be
 written in Python, using existing Python modules (numpy, PIL or wxPython)
 to get reasonable performance.

 > Does wxPython take advantage of the video hardware?

 wxWidgets is a cross-platform wrapper around existing toolkits: Windows
 GDI, GTK/GDK, etc. The underlying toolkit will use the video hardware, but
 wxWidgets may insist upon inserting itself between the data and the
 hardware.

 > IMHO we can also implement a OpenCL version of the PNM image
 composition.

 This won't help much unless you can persuade wxWidgets/wxPython to use the
 composed image directly. If it insists upon pulling the data from video
 memory so that it can pass it to a function which just pushes it straight
 back again, it would probably be quicker to perform the compositing on the
 CPU.

 > It is still puzzling me how to create a shared memory buffer using
 multiprocessing.sharedctypes.Array and use this in the C-function calls.

 I'm not sufficiently familiar with the multiprocessing module to answer
 this question. However, if it turns out to be desirable (and I don't
 actually think it will), it wouldn't be that hard to modify the PNG/cairo
 drivers to write into a SysV-IPC shared memory segment (shmat() etc).

 But I don't think that will offer any advantages over mmap()d files, and
 it's certainly at a disadvantage compared to GPU rendering into shared
 video memory.

 > Should we wait for hardware that have no distinction between video and
 main memory?

 X11 will always make a distinction between server memory and client
 memory, as those may be on different physical systems.

 > Using pycairo.BitmapFromImageSurface() seems to be a good approach?

 It may be the best that you're going to get. GDK can can create a
 GdkPixmap from an XID (gdk_pixmap_foreign_new), and this functionality is
 exposed by PyGTK. But the higher level libraries all seem to insist upon
 creating the pixmap themselves from data which is in client memory. Or at
 least, if the functionality is available, it doesn't seem to be
 documented.

 > I don't think that calling the d.vect and d.rast functionality as
 library functions is insane. :)

 Eliminating the process boundary for no reason other than to avoid having
 to figure out inter-process communication is not sane.

 > Using library function will allow to use the same image buffers across
 rendering and composition that can be passed to the wxGUI parent process
 using the multipro

Re: [GRASS-dev] [GRASS GIS] #2032: r.mapcalc does not always respect MASK

[Glynn Clements]

Paulo van Breugel wrote:

> The reason I think such a reminder might be helpful is that modules like
> r.neighbors always require an existing map as input and therefore the MASK
> will normally be respected.

"Respected" in the sense that the input will be masked. But
r.neighbors computes the aggregate over the non-null neighbours, so it
will typically write non-null values to some of the cells which are
masked (more specifically, the masked regions will tend to shrink by
the neighbourhood radius).

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Michael Barton]

I just created a ticket for this: http://trac.osgeo.org/grass/ticket/2034

Michael
__
C. Michael Barton 
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
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 Jul 14, 2013, at 2:05 AM, Markus Neteler  wrote:

> On Sun, Jul 14, 2013 at 1:32 AM, Michael Barton  
> wrote:
>> It's really a bite that I cannot a working Mac version of GRASS 7 without
>> some post-compilation hacking. While I can create a useable Mac binary with
>> some effort, it could be a problem for others who wish to do so.
>> 
>> Glynn suggests that this is a ctypes issue and Anna thinks it may be
>> something that has consequences for numerous modules (I'm inclined to
>> agree). But so far, we're stuck.
> 
> Michael,
> 
> please send the ticket number for this... (don't find it)
> 
> Markus

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

[GRASS-dev] [GRASS GIS] #2034: GUI crashes on launch for newly compiled binary for Mac OS X

[GRASS GIS]

#2034: GUI crashes on launch for newly compiled binary for Mac OS X
---+
 Reporter:  cmbarton   |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  critical   |   Milestone:  7.0.0
Component:  wxGUI  | Version:  svn-trunk
 Keywords: |Platform:  MacOSX   
  Cpu:  OSX/Intel  |  
---+
 Beginning several months ago, with the introduction of the new toolbox,
 GRASS 7 GUI crashes on launch--after selecting a working location/mapset
 and after the splash screen. the immediate cause of the crash is that
 ..xml/menudata.xml is empty.

 The reason that menudata.xml is empty is that make xml/menudata.xml fails
 during compilation. It fails with a bogus error of "No module named
 wxversion".

 Here is the error:

 {{{

 make /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/etc/gui/wxpython/xml/module_items.xml
 Generating interface description for all modules...
 GISRC=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/demolocation/.grassrc70
 GISBASE=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.4.0
 PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:$PATH"
 PYTHONPATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/etc/python:/Users/Shared/grass_dev/grass7_dev/dist.x86_64
 -apple-darwin12.4.0/etc/python:$PYTHONPATH"
 DYLD_LIBRARY_PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:" LC_ALL=C python tools/build_modules_xml.py >
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/etc/gui/wxpython/xml/module_items.xml
 make xml/menudata.xml
 GISRC=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/demolocation/.grassrc70
 GISBASE=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.4.0
 PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:$PATH"
 PYTHONPATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/etc/python:/Users/Shared/grass_dev/grass7_dev/dist.x86_64
 -apple-darwin12.4.0/etc/python:$PYTHONPATH"
 DYLD_LIBRARY_PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:" LC_ALL=C python core/toolboxes.py > xml/menudata.xml
 ERROR: wxGUI requires wxPython. No module named wxversion
 make[4]: *** [xml/menudata.xml] Error 1
 make[3]: [default] Error 2 (ignored)

 }}}

 A little background:

 1. I am compiling on OS X 10.8 (Mt. Lion) with some special hacks so that
 the binary works with OS X 10.6 (Snow Leopard). All Mac binaries are
 compiled with wxPython bundled in the binary so that there is no conflict
 between the version use for compiling and the version on a user's
 computer. This has worked fine for over a year.

 2. Beginning in the fall of 2012, I started getting errors during
 compilation from a series of new modules that share some new gui classes,
 including mapswipe, cartographic composer, etc. BUT, these modules work
 fine in spite of the compiler errors. I mention these because the cause of
 these errors may be related to the problem in this report.

 The crash reported here seems to be associated with the new toolbox
 module. Glynn thinks that it may be a ctypes problem. He notes:

 "It seems to start going wrong with lib/python/ctypes, specifically:

 {{{
 GISRC=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/demolocation/.grassrc70
 GISBASE=/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.4.0
 PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:$PATH"
 PYTHONPATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/etc/python:/Users/Shared/grass_dev/grass7_dev/dist.x86_64
 -apple-darwin12.4.0/etc/python:$PYTHONPATH"
 DYLD_LIBRARY_PATH="/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/bin:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/lib:" LC_ALL=C ./ctypesgen.py --cpp "gcc -E
 -I/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-
 darwin12.4.0/include -I/Users/Shared/grass_dev/grass7_dev/dist.x86_64
 -apple-darwin12.4.0/include -D__GLIBC_HAVE_LONG_LONG" -lgrass_gis.7.0.svn
 /Users/Shared/grass_dev/gr

Re: [GRASS-dev] [GRASS GIS] #1739: Language switch on wxGUI doesn't affect all strings

[GRASS GIS]

#1739: Language switch on wxGUI doesn't affect all strings
-+--
 Reporter:  MilenaN  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Python   | Version:  unspecified  
 Keywords:   |Platform:  All  
  Cpu:  x86-32   |  
-+--
Changes (by MilenaN):

  * milestone:  6.4.3 => 6.4.4


Comment:

 I found more examples where translated strings are ignored:

 1. Map Display buttons flags

 2. Dropdown list "Element list:" at Preferences -> Settings -> Appearance
 tab

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Happy birthday!!!!

[Margherita Di Leo]

30 YEARS OF GRASS GIS!!!

https://fbcdn-sphotos-d-a.akamaihd.net/hphotos-ak-ash3/892738_10201550826760526_2040218298_o.jpg

cheers!
madi

-- 
Best regards,

Dr. Margherita DI LEO
Scientific / technical project officer

European Commission - DG JRC
Institute for Environment and Sustainability (IES)
Via Fermi, 2749
I-21027 Ispra (VA) - Italy - TP 261

Tel. +39 0332 78 3600
margherita.di-...@jrc.ec.europa.eu

Disclaimer: The views expressed are purely those of the writer and may not
in any circumstance be regarded as stating an official position of the
European Commission.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.latlong

[Markus Neteler]

On Wed, Jul 17, 2013 at 12:06 PM, Paolo Cavallini  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all.
> Just seen the very nice i.latlong (BTW: why not r.latlong?): any hope
> of having it backported to grass6?

Done in r57191.

You can test it with:
g.extension i.latlong

I agree that r.latlong would be more appropriate.
If there are no objections, I would rename it in both G6 Addons and G7.

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

Re: [GRASS-dev] A Tri(ple)-View Map Swipe

[Nikos Alexandris]

Nikos A:

> > would a tri-view Map Swipe be feasible?  Thinking of comparing pre-, post-
> > and changes maps for example.

Anna K:

> Sorry, not so feasible. I was also thinking about this but it is not much
> supported by wxPython. It is not impossible but it would be needed to
> completely rewrite it using some newer approach.

Thanks for the feedback.

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

Re: [GRASS-dev] A Tri(ple)-View Map Swipe

[Anna Petrášová]

Hi,


On Wed, Jul 17, 2013 at 12:37 PM, Nikos Alexandris
wrote:

> Dear Anna,
>
> would a tri-view Map Swipe be feasible?  Thinking of comparing pre-, post-
> and
> changes maps for example.
>

Sorry, not so feasible. I was also thinking about this but it is not much
supported by wxPython. It is not impossible but it would be needed to
completely rewrite it using some newer approach.

Anna


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

[GRASS-dev] A Tri(ple)-View Map Swipe

[Nikos Alexandris]

Dear Anna,

would a tri-view Map Swipe be feasible?  Thinking of comparing pre-, post- and 
changes maps for example.

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

[GRASS-dev] i.latlong

[Paolo Cavallini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all.
Just seen the very nice i.latlong (BTW: why not r.latlong?): any hope
of having it backported to grass6?
Thanks a lot.
- -- 
Paolo Cavallini - Faunalia
www.faunalia.eu
Full contact details at www.faunalia.eu/pc
Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlHmbL0ACgkQ/NedwLUzIr5cawCeMnmcysj7GHV1FsS4aTjDV96Y
LhEAn3o3xp/tlC1OCwgTodsvCanRDnrO
=HZCQ
-END PGP SIGNATURE-
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.segment: invalid region id 0

[Nikos Alexandris]

Below kept only timings and number of created segments (from previously posted 
tests as well as a few new ones), just as a reference.

All tests above threshold=0.95 fail to deliver. The extreme instruction 
threshold=0.95 derives 70 segments.  Above this, I think that everything would 
be merged in one segment, a result for which i.segment is not required anyway.

How this is related with the error message... ?

In any case, if wanted, I will try during the weekend to replicate a Huge 
region, as the one Moritz tested with a "rational" threshold (close to zero).

Thank you for this wonderful module!
Nikos


Nikos Alexandris wrote:
 
> # ###
> # A series of tests using default RAM
> 
> # threshold 0.1

> Segmentation converged after 11 iterations.
> Writing out segment IDs
> i.segment complete. Number of segments created: 25407
> 
> real8m9.122s
> user8m5.582s
> sys 0m0.296s

> # threshold 0.3

> Segmentation converged after 11 iterations.
> Writing out segment IDs
> i.segment complete. Number of segments created: 11684
> 
> real12m20.273s
> user12m19.466s
> sys 0m0.256s
> 
> # threshold 0.5
 
> Segmentation converged after 12 iterations.
> Writing out segment IDs
> i.segment complete. Number of segments created: 5495
> 
> real17m35.330s
> user17m34.302s
> sys 0m0.264s
> 
> # threshold 0.7

> Segmentation converged after 12 iterations.
> Writing out segment IDs
> i.segment complete. Number of segments created: 4911
> 
> real18m15.143s
> user18m11.188s
> sys 0m0.300s
> 
> # threshold 0.9
 
> Segmentation converged after 13 iterations.
> Writing out segment IDs
> i.segment complete. Number of segments created: 1276
> 
> real30m30.619s
> user30m29.010s
> sys 0m0.272s

# threshold 0.95
time i.segment group=pan out=pan_segmented_threshold_0.95_memory_3 
threshold=0.95 memory=3
..
Segmentation converged after 13 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 70

real45m48.901s
user45m45.064s
sys 0m0.512s

# threshold 0.955 (I guess identical to 0.95)
time i.segment group=pan out=pan_segmented_threshold_0.955_memory_3 
threshold=0.955 memory=3
..
Segmentation converged after 13 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 70

real45m59.356s
user45m55.280s
sys 0m0.584s

# threshold 0.96
time i.segment group=pan out=pan_segmented_threshold_0.96_memory_3 
threshold=0.96 memory=3
..
Pass 13:
ERROR: Invalid region id 0

real48m0.629s
user47m56.724s
sys 0m0.472s

# threshold 0.97
time i.segment group=pan out=pan_segmented_threshold_0.97_memory_3 
threshold=0.97 memory=3
..
Pass 11:
  40%   Pass 12:
Pass 13:
ERROR: Invalid region id 0

real47m58.069s
user47m53.976s
sys 0m0.628s

# threshold 0.99
time i.segment group=pan out=pan_segmented_threshold_0.99_memory_3 
threshold=0.99 memory=3

..
Pass 13:
ERROR: Invalid region id 0

real37m24.352s
user37m14.000s
sys 0m0.784s

time i.segment group=pan out=pan_segmented_threshold_0.99_memory_300 
threshold=0.99

..
Pass 13:
ERROR: Invalid region id 0

real41m42.828s
user41m39.932s
sys 0m0.680s
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.kcv - new version

[Markus Neteler]

Hi Jan,

very interesting!
as Helmut suggests, it would be best to upload the *diff* to trac at
http://trac.osgeo.org/grass/

Please make it a diff against
http://svn.osgeo.org/grass/grass/branches/releasebranch_6_4/

so that only the differences are stored.

thanks
Markus

On Tue, Jul 16, 2013 at 12:54 PM, Jan Růžička  wrote:
> Dear developers,
>
> in connection with attempts to rewrite some GRASS module with OpenMP we have
> rewrote the v.kcv module. The new version is much faster that the previous
> (no OpenMP is now needed - there is only one loop now with direct writing to
> the resulting layer). We believe that the new version of the module do the
> same work as original. We are not familiar with GRASS GIS development so the
> code is included in the attachment of this message. Hope that it could be
> useful.
>
> Kind regards
>
> Jan Ruzicka and Jan Vandrol
>
> ___
> 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] mapset permissions: only owner should have write permissions

[Markus Neteler]

On Tue, Jul 16, 2013 at 8:44 PM, Glynn Clements
 wrote:
> Markus Metz wrote:
...
>> With grass data on a network drive with multi-user access, I would
>> regard e.g. the contents of the PERMANENT mapset as
>> particularly-sensitive information.
>
> Plenty of sites will treat PERMANENT as public data, to be shared by
> all users.

Shared yes.
Destroyed no.

The point here is (as experienced on our local shared network
grassdata/ recently):
- GRASS allows users to enter their own mapset(s)
- GRASS allows users to read all mapsets and write into the current (own) one
- GRASS does not allow to modify the mapset of a different user

So far so nice.

Assume that several users belong to the same group. If now the group
write flag is enabled for mapsets, users can delete them even if they
are not their own. This is fine since someone (admin) must have
allowed for this.

Now back to GRASS: A user runs a session in his/her mapset with
group-write enabled. This is against the GRASS internal policy where
others cannot write into your own mapsets with GRASS commands.

Wish for improvement:
When starting a session in a mapset with group/other-write enabled,
issue a warning to inform the user about this in the startup script.
This would follow the "least-surprise" paradigm.
Feasible?

Markus
___
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):

 Replying to [comment:1 glynn]:
 > Replying to [ticket:2033 huhabla]:
 >
 > > My question would be if this is also possible with d.rast, d.vect and
 other display modules? Hence, moving the code from these modules into the
 display library and calling these functions from dedicated wxGUI sub-
 processes to speed up the rendering?
 >
 > Possible? Probably. Sane? No.
 >
 > Moving the guts of d.rast/d.vect/etc around won't make it run any
 faster. If the issue is with the communication of the raster data, there
 are faster methods than reading and writing PNM files.

 I have the hope to speed up the composition by avoiding disc I/O.

 > Both the PNG and cairo drivers support reading and writing 32-bpp BMP
 files where the raster data is correctly aligned for memory mapping.
 Setting GRASS_PNGFILE to a filename with a .bmp suffix selects this
 format, and setting GRASS_PNG_MAPPED=TRUE causes the drivers to mmap() the
 file rather than using read() and write().

 As far as i understand mmap(), it is file backed and reads/writes the data
 from the file on demand into the shared memory? An exception is anonymous
 mapping, but is this also supported on windows? How can we access the
 anonymous mmap() from wxPython?

 > Once you have d.* commands generating BMP files, it shouldn't be
 necessary to add any binary blobs to wxGUI. Compositing should be
 perfectly viable within Python using either numpy, PIL or wxPython (having
 wxPython perform the compositing during rendering may be able to take
 advantage of video hardware).

 What do you mean with binary blobs? Binary large objects? Well as i can
 see from the wx description, there is no way around blobs since even numpy
 arrays must be converted into a bytearray or similar to create a wx image.
 Does wxPython take advantage of the video hardware? IMHO we can also
 implement a OpenCL version of the PNM image composition. In this case it
 would be a large advantage to have the images created by d.rast and d.vect
 in a shared memory area as well to avoid disk I/O.

 > Additionally, on X11 (and provided that the cairo library supports it),
 the cairo driver supports rendering directly into an X pixmap which is
 retained in the server (typically in video memory) after the d.* program
 terminates. This has the added advantage that rendering will be performed
 using the video hardware.
 >
 > Setting GRASS_PNGFILE to a filename ending in ".xid" selects this
 option; the XID of the pixmap will be written to that file as a
 hexadecimal value. The g.cairocomp module can composite these pixmaps
 without the image data ever leaving video memory ("g.cairocomp -d ..." can
 be used to delete the pixmaps from the server).
 >
 > The only missing piece of the puzzle is a way to get wxPython to use an
 existing pixmap (ideally without pulling it into client memory then
 pushing it back out to the server). The cleanest approach would be via
 pycairo and wx.lib.wxcairo, which would also allow g.cairocomp to be
 eliminated, but that's yet another dependency.

 It is still puzzling me how to create a shared memory buffer using
 multiprocessing.sharedctypes.Array and use this in the C-function calls.
 In the current approach i have to use a queue object to transfer the image
 data from the child process to its parent and therefor the transformation
 of the image buffer into a Python bytearray. How to access video memory is
 another point. Are pipes or similar techniques available for this kind of
 operation? Should we wait for hardware that have no distinction between
 video and main memory? Using pycairo.BitmapFromImageSurface() seems to be
 a good approach?

 However, we should focus on approaches that work on Linux/Unix/Mac and
 Windows. Using X11 specific features is not meaningful in my humble
 opinion. Besides of that the cairo driver is not work with the windows
 grass installer yet (missing dependencies, with the exception of Markus
 Metz local installation).

 I don't think that calling the d.vect and d.rast functionality as library
 functions is insane. :)
 Using library function will allow to use the same image buffers across
 rendering and composition that can be passed to the wxGUI parent process
 using the multiprocessing queue. This will 

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

[Markus Metz]

On Tue, Jul 16, 2013 at 10:38 PM, Hamish  wrote:
> Markus Metz wrote:
>
>>  In this case, would it be ok to enforce umask to 0022 in the start up
>> script?
>
> two rules to thumb:
>
> we shouldn't restrict others to the limits of our own imagination.
>  (if someone wants to set their umask to allow 777 for whatever reason
>   or need, why not let them?)
>
> it's not broken == don't fix it
>
>
> ... my suggestion is just leave the thing alone. why make work for people?

Just to clarify, I no longer want to enforce permissions inside GRASS,
but will instead enforce permissions on system level, outside GRASS.
Maybe our shared network GRASS data are a special case.

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