r.digit is not available in grass 7. Is it removed or is there any problem with my build?
–
Regards,
Rashad
On Sun, Dec 16, 2012 at 5:31 AM, Mohammed Rashad
<mohammedrashadkm@gmail.com> wrote:
r.digit is not available in grass 7. Is it removed
Yes:
r.digit needed an interactive xmon window, which is only available if using X11.
Interestingly there is still the deactivated old code in
grass70/raster/r.digit/
Markus
Hi Markus,
Is there anyone working on it?
Seems like it needs to be something similar to wx Digitizer but for raster.
Am I correct?
···
On Sun, Dec 16, 2012 at 4:04 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Dec 16, 2012 at 5:31 AM, Mohammed Rashad
<mohammedrashadkm@gmail.com> wrote:r.digit is not available in grass 7. Is it removed
Yes:
r.digit needed an interactive xmon window, which is only available if using X11.Interestingly there is still the deactivated old code in
grass70/raster/r.digit/Markus
–
Regards,
Rashad
On Sun, Dec 16, 2012 at 11:52 AM, Mohammed Rashad
<mohammedrashadkm@gmail.com> wrote:
Hi Markus,
Is there anyone working on it?
Not that I aware of.
Seems like it needs to be something similar to wx Digitizer but for raster.
Am I correct?
Do we really need it (v.digit, v.to.rast are there)?
If yes, in case it may be based on the digitizer in i.class (idea).
Markus
On Sun, Dec 16, 2012 at 5:37 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Sun, Dec 16, 2012 at 11:52 AM, Mohammed Rashad
<mohammedrashadkm@gmail.com> wrote:
> Hi Markus,
>
> Is there anyone working on it?Not that I aware of.
> Seems like it needs to be something similar to wx Digitizer but for
raster.
> Am I correct?Do we really need it (v.digit, v.to.rast are there)?
You are saying there is no need for r.digit module. because v.digit +
v.to.rast may produce same output. Right?
If the module is needed i can start working on it.
If yes, in case it may be based on the digitizer in i.class (idea).
I didnt get this.
Markus
--
Regards,
Rashad
2012/12/16 Mohammed Rashad <mohammedrashadkm@gmail.com>:
If yes, in case it may be based on the digitizer in i.class (idea).
http://grasswiki.osgeo.org/wiki/WxIClass
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/iclass
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
I am still confused. my problem 
so clear me up. wxIClass has a digitizer and r.digit is useless?
Does r.digit needs to be ported or not?
If yes, anyone have any suggestions for it
···
On Sun, Dec 16, 2012 at 7:04 PM, Martin Landa <landa.martin@gmail.com> wrote:
2012/12/16 Mohammed Rashad <mohammedrashadkm@gmail.com>:
If yes, in case it may be based on the digitizer in i.class (idea).
http://grasswiki.osgeo.org/wiki/WxIClass
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/iclassMartin
–
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
–
Regards,
Rashad
On 16 December 2012 15:34, Mohammed Rashad <mohammedrashadkm@gmail.com> wrote:
I am still confused. my problem
so clear me up. wxIClass has a digitizer and r.digit is useless?
wxIClass uses wxDigitizer (not sure how we call this component). It is
the same digitizer which is used in Map Display Digitizer mode.
If I need a raster map, I can now use Map Display Digitizer and than
v.to.rast (e.g., till now this was the only way to obtain MASK
specified by hand).
wxIClass is different. It internally creates vector map and then it
creates on the fly something like a raster map. But this something is
not a real raster map. It is only a set of values obtained from raster
map which has the shape of the old vector areas. This functionality is
similar to v.to.rast and probably there is some duplication. (IMHO,
this should be generalized, merged with v.to.rast and become part of
the library, but that's another story.) Nevertheless, my point is that
wxIClass is not the tool for digitizing raster. It provides the same
functionality as Map Display Digitizer mode and moreover, it is not
able to export raster map now.
Does r.digit needs to be ported or not?
Combination digitize vector + convert to raster is not able to allow
user to decide which particular cell should or should not be
digitized. So, the raster digitizer is needed for this. But I don't
know if this is a frequent case. I don't know r.digit but it was the
same as digitizer + v.to.rast according to module description.
Can d.rast.edit help us with the problem above?
Vaclav
If yes, anyone have any suggestions for it
On Sun, Dec 16, 2012 at 7:04 PM, Martin Landa <landa.martin@gmail.com>
wrote:2012/12/16 Mohammed Rashad <mohammedrashadkm@gmail.com>:
>> If yes, in case it may be based on the digitizer in i.class (idea).http://grasswiki.osgeo.org/wiki/WxIClass
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/iclassMartin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa--
Regards,
Rashad_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Mohammed:
> Does r.digit needs to be ported or not?
Vaclav:
Combination digitize vector + convert to raster is not able
to allow user to decide which particular cell should or should
not be digitized. So, the raster digitizer is needed for this.
But I don't know if this is a frequent case. I don't know
r.digit but it was the same as digitizer + v.to.rast according
to module description.
Hi guys,
G6's r.digit is a front end to the r.in.poly module, which takes
an input not dissimilar to the v.in.ascii standard grass format.
An old idea was to just reuse the wx digitizer tool but instead
of writing to grass vector ascii format + v.in.ascii change
things a little and save to r.in.poly ascii format instead.
Since then the wx digitizer got way more advanced, I'm not sure
if it is possible any more to just have an extra Save As.. in
the file menu/toolbar. (I hope it is)
for my 2c it's quite nice to have a dedicated raster digitizing
option, instead of needing an extra v.in.ascii -> v.to.rast
step in your workflow. That doesn't rule out a wrapper script
to hide the vector part of it, but a dedicated r.in.poly mode
would both be more efficient and perhaps less prone to loss in
fidelity.
thanks,
Hamish
On Mon, Dec 17, 2012 at 9:06 AM, Hamish <hamish_b@yahoo.com> wrote:
Mohammed:
> > Does r.digit needs to be ported or not?Vaclav:
> Combination digitize vector + convert to raster is not able
> to allow user to decide which particular cell should or should
> not be digitized. So, the raster digitizer is needed for this.
> But I don't know if this is a frequent case. I don't know
> r.digit but it was the same as digitizer + v.to.rast according
> to module description.Hi guys,
G6's r.digit is a front end to the r.in.poly module, which takes
an input not dissimilar to the v.in.ascii standard grass format.
An old idea was to just reuse the wx digitizer tool but instead
of writing to grass vector ascii format + v.in.ascii change
things a little and save to r.in.poly ascii format instead.
Since then the wx digitizer got way more advanced, I'm not sure
if it is possible any more to just have an extra Save As.. in
the file menu/toolbar. (I hope it is)for my 2c it's quite nice to have a dedicated raster digitizing
option, instead of needing an extra v.in.ascii -> v.to.rast
step in your workflow. That doesn't rule out a wrapper script
to hide the vector part of it, but a dedicated r.in.poly mode
would both be more efficient and perhaps less prone to loss in
fidelity.
By dedicated raster digitizer you mean using r.in.poly or using C code +
cyptes wrapper for wxGui, the same way as wxDigitizer?
Btw, r.in.poly implementation is very easy!!. But I dont know about its
efficiency
thanks,
Hamish
--
Regards,
Rashad
Hi Hamish,
On Mon, Dec 17, 2012 at 4:36 AM, Hamish <hamish_b@yahoo.com> wrote:
for my 2c it's quite nice to have a dedicated raster digitizing
option, instead of needing an extra v.in.ascii -> v.to.rast
step in your workflow. That doesn't rule out a wrapper script
to hide the vector part of it, but a dedicated r.in.poly mode
would both be more efficient and perhaps less prone to loss in
fidelity.
I think that should be possible to use the geometry feature of the
vector api of pygrass,
from grass import pygrass
from pygrass.vector.geometry import Point, Line
pnt = Point(10, 100)
line = Line([(0, 0), (1, 1), (2, 0), (1, -1)])
line.c_points # return the ctypes pointer to the line_points struct
<grass.lib.ctypes_preamble.LP_struct_line_pnts object at 0x2aa1440>
even if is not deeply tested...
get more example from here:
http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features
Pietro
All,
What I am thinking of is a python version of r.in.poly which can create area, line, circle from a list of (x,y) coordinates captured from wxGUI Map display
r.in.poly reads from file or stdin. Using pyGRASS/ grass ctypes api we can create objects in raster file.
···
On Mon, Dec 17, 2012 at 2:30 PM, Pietro <peter.zamb@gmail.com> wrote:
Hi Hamish,
On Mon, Dec 17, 2012 at 4:36 AM, Hamish <hamish_b@yahoo.com> wrote:
for my 2c it’s quite nice to have a dedicated raster digitizing
option, instead of needing an extra v.in.ascii → v.to.rast
step in your workflow. That doesn’t rule out a wrapper script
to hide the vector part of it, but a dedicated r.in.poly mode
would both be more efficient and perhaps less prone to loss in
fidelity.I think that should be possible to use the geometry feature of the
vector api of pygrass,from grass import pygrass
from pygrass.vector.geometry import Point, Line
pnt = Point(10, 100)
line = Line([(0, 0), (1, 1), (2, 0), (1, -1)])
line.c_points # return the ctypes pointer to the line_points struct
<grass.lib.ctypes_preamble.LP_struct_line_pnts object at 0x2aa1440>even if is not deeply tested…
get more example from here:
http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features
Pietro
–
Regards,
Rashad
On 17 December 2012 10:58, Mohammed Rashad <mohammedrashadkm@gmail.com> wrote:
All,
What I am thinking of is a python version of r.in.poly which can create
area, line, circle from a list of (x,y) coordinates captured from wxGUI Map
displayr.in.poly reads from file or stdin. Using pyGRASS/ grass ctypes api we can
create objects in raster file.
But keep in mind that GUI should not call grass C libraries directly
but should call modules if possible. Digitizer is now one of the
exceptions. But we should avoid adding more exceptions, I think.
(Calling library functions from GUI is often needed for better
flexibility (or performance issues?) and, as you probably know, we are
still reconsidering current approaches but still there is no final
solution to this problem.)
On Mon, Dec 17, 2012 at 2:30 PM, Pietro <peter.zamb@gmail.com> wrote:
Hi Hamish,
On Mon, Dec 17, 2012 at 4:36 AM, Hamish <hamish_b@yahoo.com> wrote:
> for my 2c it's quite nice to have a dedicated raster digitizing
> option, instead of needing an extra v.in.ascii -> v.to.rast
> step in your workflow. That doesn't rule out a wrapper script
> to hide the vector part of it, but a dedicated r.in.poly mode
> would both be more efficient and perhaps less prone to loss in
> fidelity.I think that should be possible to use the geometry feature of the
vector api of pygrass,>>> from grass import pygrass
>>> from pygrass.vector.geometry import Point, Line
>>> pnt = Point(10, 100)
>>> line = Line([(0, 0), (1, 1), (2, 0), (1, -1)])
>>> line.c_points # return the ctypes pointer to the line_points struct
<grass.lib.ctypes_preamble.LP_struct_line_pnts object at 0x2aa1440>even if is not deeply tested...
get more example from here:
http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features
Pietro
--
Regards,
Rashad
HI,
On Mon, Dec 17, 2012 at 11:46 AM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 17 December 2012 10:58, Mohammed Rashad <mohammedrashadkm@gmail.com> wrote:
All,
What I am thinking of is a python version of r.in.poly which can create
area, line, circle from a list of (x,y) coordinates captured from wxGUI Map
displayr.in.poly reads from file or stdin. Using pyGRASS/ grass ctypes api we can
create objects in raster file.But keep in mind that GUI should not call grass C libraries directly
but should call modules if possible. Digitizer is now one of the
exceptions. But we should avoid adding more exceptions, I think.
ok, pygrass Module object, it suppose to work with stdin, but is not
ready yet... I hope to finish this part at the beginning of the new
year, and should work in this way:
from pygrass.modules import raster as r
area = """A
... 591316.80 4926455.50
... 591410.25 4926482.40
... 591434.60 4926393.60
... 591341.20 4926368.70
... = 42 stadium"""
r.in_poly(input='-', output='rtest', stdin_=area)
But you have to wait...
Pietro
On Mon, Dec 17, 2012 at 4:16 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On 17 December 2012 10:58, Mohammed Rashad <mohammedrashadkm@gmail.com>
wrote:
> All,
>
> What I am thinking of is a python version of r.in.poly which can create
> area, line, circle from a list of (x,y) coordinates captured from wxGUI
Map
> display
>
> r.in.poly reads from file or stdin. Using pyGRASS/ grass ctypes api we
can
> create objects in raster file.
>
But keep in mind that GUI should not call grass C libraries directly
but should call modules if possible. Digitizer is now one of the
exceptions. But we should avoid adding more exceptions, I think.
graster.Rast_open_c_new() is allowed?
if not can you provide an example?
(Calling library functions from GUI is often needed for better
flexibility (or performance issues?) and, as you probably know, we are
still reconsidering current approaches but still there is no final
solution to this problem.)
>
>
>
> On Mon, Dec 17, 2012 at 2:30 PM, Pietro <peter.zamb@gmail.com> wrote:
>>
>> Hi Hamish,
>>
>> On Mon, Dec 17, 2012 at 4:36 AM, Hamish <hamish_b@yahoo.com> wrote:
>> > for my 2c it's quite nice to have a dedicated raster digitizing
>> > option, instead of needing an extra v.in.ascii -> v.to.rast
>> > step in your workflow. That doesn't rule out a wrapper script
>> > to hide the vector part of it, but a dedicated r.in.poly mode
>> > would both be more efficient and perhaps less prone to loss in
>> > fidelity.
>>
>> I think that should be possible to use the geometry feature of the
>> vector api of pygrass,
>>
>> >>> from grass import pygrass
>> >>> from pygrass.vector.geometry import Point, Line
>> >>> pnt = Point(10, 100)
>> >>> line = Line([(0, 0), (1, 1), (2, 0), (1, -1)])
>> >>> line.c_points # return the ctypes pointer to the line_points struct
>> <grass.lib.ctypes_preamble.LP_struct_line_pnts object at 0x2aa1440>
>>
>> even if is not deeply tested...
>>
>> get more example from here:
>>
>>
>>
http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features
>>
>>
>> Pietro
>
>
>
>
> --
> Regards,
> Rashad
>
--
Regards,
Rashad