On Fri, Jun 27, 2014 at 10:35 AM, Luca Delucchi <[email protected]> wrote:
> On 27 June 2014 15:46, Anna Petrášová <[email protected]> wrote: > > > > > > > > On Fri, Jun 27, 2014 at 3:03 AM, Luca Delucchi <[email protected]> > wrote: > >> > >> On 26 June 2014 19:59, Markus Neteler <[email protected]> wrote: > >> > >> > > >> > nice work, Luca (and thanks to Anna for code cleanup). > >> > > >> > >> Sorry Anna, but I don't understand because you remove all the 3D code, > >> I would like to implement it later (sometime I'm careless but not this > >> time :-P ) > >> Thanks for the improvement of coordinates field. > > > > > > Sorry for that. I also fixed some other minor things in that commit. Do > you > > plan to support vector data as well? > > > > I would like, first I need a vector temporal dataset to test :-) > > > What I am not sure about is the usage of pygrass here. The problem is if > we > > would like to integrate it more in GUI. Currently when you click on the > > g.gui.tplot in menu, a standard generated dialog opens and when you fill > the > > params and press ok, the actual plotting gui shows up, which is > cumbersome. > > yes I have your same feeling, I should create a function like for > animation tool? > (other tools have the same behavior of g.gui.tplot for example > g.gui.timeline) > > > The menu entry could bring directly the tplot, however then there is a > > possibility of crashing entire GUI when something goes wrong (because of > > using ctypes in pygrass). So one option is to call some t.* module but > there > > is no t.rast.what only t.vect.strds.observe which requires vector map. > > I could use r.what instead pygrass but I would like to escape to call > external modules > > > Another option is to wrap the pygrass code and call it as a subprocess. I > > don't have time to look at it more now, but we should be aware of this. > > > > Just to know, we don't have the same problem using ctypes in the gui? > In several modules we are using it.... > yes we have, digitizer and nviz, I just want to avoid another one when it would be relatively simple (comparing to those 2) make it safe. r.what could be a simple solution, although it would be probably slower than pygrass (not sure if significantly, maybe not). > > Anna > > -- > ciao > Luca > > http://gis.cri.fmach.it/delucchi/ > www.lucadelu.org >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
