<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 20, 2014 at 12:04 PM, Sören Gebbert <span dir="ltr"><<a href="mailto:soerengebbert@googlemail.com" target="_blank">soerengebbert@googlemail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-07-20 6:10 GMT+02:00 Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>>:<br>

<div><div class="h5">><br>
><br>
><br>
> On Sat, Jul 19, 2014 at 6:30 PM, Sören Gebbert<br>
> <<a href="mailto:soerengebbert@googlemail.com">soerengebbert@googlemail.com</a>> wrote:<br>
>><br>
>> Hi Anna,<br>
>><br>
>> 2014-07-19 19:04 GMT+02:00 Anna Petrášová <<a href="mailto:kratochanna@gmail.com">kratochanna@gmail.com</a>>:<br>
>> > Hi,<br>
>> ><br>
>> > I have a question about Rast3d_location2coord [1]. It is casting the<br>
>> > col,<br>
>> > row, depth values to integer like this:<br>
>> ><br>
>> > (int) col<br>
>> ><br>
>> > instead of using<br>
>> ><br>
>> > (int)floor(col)<br>
>> ><br>
>> > as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which<br>
>> > doesn't<br>
>> > seem correct to me. Any opinions?<br>
>><br>
>> I totally agree that there should be a function that returns the row,<br>
>> col and depth as double values, so the developer can decide how to<br>
>> handle these values. Otherwise there would be no convenient way to<br>
>> determine where coordinates are located in the voxel.<br>
>><br>
>> But i am not sure if the  integer casting is a bug, since the<br>
>> Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer<br>
>> casting as conversion method. There are algorithms in GRASS that use<br>
>> only integer casting and algorithms that make use of rounding with<br>
>> floor() before casting to integer.<br>
>><br>
>> The problem arise in case of negative column,row or depth values when<br>
>> casting to integer without rounding to an integer smaller than the<br>
>> double number. So the question is are there any chances to receive<br>
>> negative cols,rows and depths?<br>
>><br>
>> It does not seems do to me for col and row, since in case of negative<br>
>> coordinates will west and south always be smaller than east and north,<br>
>> resulting in always positive cols and rows. And the same should be<br>
>> true for depths, unless the top is smaller than bottom.<br>
><br>
><br>
> Yes, but you still can get negative col, for example when looking for the<br>
> neighboring voxels of a voxel on the edge of the 3D raster. Then, the<br>
> inconsistency causes problem.<br>
<br>
</div></div>Good point, i have updated the Rast3d_location2coord() function to use floor.<br></blockquote><div><br></div><div>Thanks, I hope it won't be too much overhead comparing to int.</div><div><br></div><div>Anna</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards<br>
Soeren<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks a lot for implementing Rast3d_location2coord_double.<br>
><br>
> Anna<br>
><br>
>><br>
>> Best regards<br>
>> Soeren<br>
>><br>
>> ><br>
>> > Thanks, Anna<br>
>> ><br>
>> > BTW, similar function Rast_northing_to_row from raster library returns<br>
>> > double.<br>
>> ><br>
>> ><br>
>> > [1] <a href="http://grass.osgeo.org/programming7/region_8c_source.html#l00291" target="_blank">http://grass.osgeo.org/programming7/region_8c_source.html#l00291</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > grass-dev mailing list<br>
>> > <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>> > <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
><br>
><br>
</div></div></blockquote></div><br></div></div>