<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 19, 2014 at 6:30 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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>
<div class="">> Hi,<br>
><br>
> I have a question about Rast3d_location2coord [1]. It is casting the 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 doesn't<br>
> seem correct to me. Any opinions?<br>
<br>
</div>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></blockquote><div><br></div><div>Yes, but you still can get negative col, for example when looking for the neighboring voxels of a voxel on the edge of the 3D raster. Then, the inconsistency causes problem.</div>

<div><br></div><div>Thanks a lot for implementing Rast3d_location2coord_double.</div><div><br></div><div>Anna</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
Best regards<br>
Soeren<br>
<div class=""><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>
</div>> _______________________________________________<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>
</blockquote></div><br></div></div>