<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 17, 2012 at 4:16 PM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 17 December 2012 10:58, Mohammed Rashad <<a href="mailto:mohammedrashadkm@gmail.com">mohammedrashadkm@gmail.com</a>> wrote:<br>


> All,<br>
><br>
> What I am thinking of is a python version of r.in.poly which can create<br>
> area, line, circle from a list of (x,y) coordinates captured from wxGUI Map<br>
> display<br>
><br>
> r.in.poly reads from file or stdin. Using pyGRASS/ grass ctypes api we can<br>
> create objects in raster file.<br>
><br>
</div>But keep in mind that GUI should not call grass C libraries directly<br>
but should call modules if possible. Digitizer is now one of the<br>
exceptions. But we should avoid adding more exceptions, I think.<br></blockquote><div><br></div><div>graster.Rast_open_c_new() is allowed?</div><div><br></div><div>if not can you provide an example?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
(Calling library functions from GUI is often needed for better<br>
flexibility (or performance issues?) and, as you probably know, we are<br>
still reconsidering current approaches but still there is no final<br>
solution to this problem.)<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
> On Mon, Dec 17, 2012 at 2:30 PM, Pietro <<a href="mailto:peter.zamb@gmail.com">peter.zamb@gmail.com</a>> wrote:<br>
>><br>
>> Hi Hamish,<br>
>><br>
>> On Mon, Dec 17, 2012 at 4:36 AM, Hamish <<a href="mailto:hamish_b@yahoo.com">hamish_b@yahoo.com</a>> wrote:<br>
>> > for my 2c it's quite nice to have a dedicated raster digitizing<br>
>> > option, instead of needing an extra v.in.ascii -> v.to.rast<br>
>> > step in your workflow. That doesn't rule out a wrapper script<br>
>> > to hide the vector part of it, but a dedicated r.in.poly mode<br>
>> > would both be more efficient and perhaps less prone to loss in<br>
>> > fidelity.<br>
>><br>
>> I think that should be possible to use the geometry feature of the<br>
>> vector api of pygrass,<br>
>><br>
>> >>> from grass import pygrass<br>
>> >>> from pygrass.vector.geometry import Point, Line<br>
>> >>> pnt = Point(10, 100)<br>
>> >>> line = Line([(0, 0), (1, 1), (2, 0), (1, -1)])<br>
>> >>> line.c_points  # return the ctypes pointer to the line_points struct<br>
>> <grass.lib.ctypes_preamble.LP_struct_line_pnts object at 0x2aa1440><br>
>><br>
>> even if is not deeply tested...<br>
>><br>
>> get more example from here:<br>
>><br>
>><br>
>> <a href="http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features" target="_blank">http://www.ing.unitn.it/~zambelli/projects/pygrass/vector.html#vector-features</a><br>
>><br>
>><br>
>> Pietro<br>
><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
>    Rashad<br>
><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div><br>
</div>