Hi,
I have a question about Rast3d_location2coord [1]. It is casting the col, row, depth values to integer like this:
(int) col
instead of using
(int)floor(col)
as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn’t seem correct to me. Any opinions?
Thanks, Anna
BTW, similar function Rast_northing_to_row from raster library returns double.
[1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
Hi Anna,
2014-07-19 19:04 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
Hi,
I have a question about Rast3d_location2coord [1]. It is casting the col,
row, depth values to integer like this:(int) col
instead of using
(int)floor(col)
as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn't
seem correct to me. Any opinions?
I totally agree that there should be a function that returns the row,
col and depth as double values, so the developer can decide how to
handle these values. Otherwise there would be no convenient way to
determine where coordinates are located in the voxel.
But i am not sure if the integer casting is a bug, since the
Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
casting as conversion method. There are algorithms in GRASS that use
only integer casting and algorithms that make use of rounding with
floor() before casting to integer.
The problem arise in case of negative column,row or depth values when
casting to integer without rounding to an integer smaller than the
double number. So the question is are there any chances to receive
negative cols,rows and depths?
It does not seems do to me for col and row, since in case of negative
coordinates will west and south always be smaller than east and north,
resulting in always positive cols and rows. And the same should be
true for depths, unless the top is smaller than bottom.
Best regards
Soeren
Thanks, Anna
BTW, similar function Rast_northing_to_row from raster library returns
double.[1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Anna,
i have added the function Rast3d_location2coord_double() to the
raster3d library (r61282) that expects x, y and z as double values.
While doing this i discovered a really horrible bug in the coordinate
transformation for rows. The reason for this bug were wrong coordinate
tests in the raster3d library tests. Wrong indexing leaded me to wrong
northern coordinate to row conversion. This bug appeared in case that
coordinates are located exactly at the north/south border between two
voxels.
This is hopefully fixed now. It should be backported to grass7.0 as
well, after heavy testing.
Best regards
Soeren
2014-07-19 19:04 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
Hi,
I have a question about Rast3d_location2coord [1]. It is casting the col,
row, depth values to integer like this:(int) col
instead of using
(int)floor(col)
as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which doesn't
seem correct to me. Any opinions?Thanks, Anna
BTW, similar function Rast_northing_to_row from raster library returns
double.[1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sat, Jul 19, 2014 at 6:30 PM, Sören Gebbert <soerengebbert@googlemail.com
wrote:
Hi Anna,
2014-07-19 19:04 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
> Hi,
>
> I have a question about Rast3d_location2coord [1]. It is casting the col,
> row, depth values to integer like this:
>
> (int) col
>
> instead of using
>
> (int)floor(col)
>
> as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which
doesn't
> seem correct to me. Any opinions?I totally agree that there should be a function that returns the row,
col and depth as double values, so the developer can decide how to
handle these values. Otherwise there would be no convenient way to
determine where coordinates are located in the voxel.But i am not sure if the integer casting is a bug, since the
Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
casting as conversion method. There are algorithms in GRASS that use
only integer casting and algorithms that make use of rounding with
floor() before casting to integer.The problem arise in case of negative column,row or depth values when
casting to integer without rounding to an integer smaller than the
double number. So the question is are there any chances to receive
negative cols,rows and depths?It does not seems do to me for col and row, since in case of negative
coordinates will west and south always be smaller than east and north,
resulting in always positive cols and rows. And the same should be
true for depths, unless the top is smaller than bottom.
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.
Thanks a lot for implementing Rast3d_location2coord_double.
Anna
Best regards
Soeren>
> Thanks, Anna
>
> BTW, similar function Rast_northing_to_row from raster library returns
> double.
>
>
> [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
2014-07-20 6:10 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
On Sat, Jul 19, 2014 at 6:30 PM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:Hi Anna,
2014-07-19 19:04 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
> Hi,
>
> I have a question about Rast3d_location2coord [1]. It is casting the
> col,
> row, depth values to integer like this:
>
> (int) col
>
> instead of using
>
> (int)floor(col)
>
> as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which
> doesn't
> seem correct to me. Any opinions?I totally agree that there should be a function that returns the row,
col and depth as double values, so the developer can decide how to
handle these values. Otherwise there would be no convenient way to
determine where coordinates are located in the voxel.But i am not sure if the integer casting is a bug, since the
Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
casting as conversion method. There are algorithms in GRASS that use
only integer casting and algorithms that make use of rounding with
floor() before casting to integer.The problem arise in case of negative column,row or depth values when
casting to integer without rounding to an integer smaller than the
double number. So the question is are there any chances to receive
negative cols,rows and depths?It does not seems do to me for col and row, since in case of negative
coordinates will west and south always be smaller than east and north,
resulting in always positive cols and rows. And the same should be
true for depths, unless the top is smaller than bottom.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.
Good point, i have updated the Rast3d_location2coord() function to use floor.
Best regards
Soeren
Thanks a lot for implementing Rast3d_location2coord_double.
Anna
Best regards
Soeren>
> Thanks, Anna
>
> BTW, similar function Rast_northing_to_row from raster library returns
> double.
>
>
> [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sun, Jul 20, 2014 at 12:04 PM, Sören Gebbert <
soerengebbert@googlemail.com> wrote:
2014-07-20 6:10 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
>
>
>
> On Sat, Jul 19, 2014 at 6:30 PM, Sören Gebbert
> <soerengebbert@googlemail.com> wrote:
>>
>> Hi Anna,
>>
>> 2014-07-19 19:04 GMT+02:00 Anna Petrášová <kratochanna@gmail.com>:
>> > Hi,
>> >
>> > I have a question about Rast3d_location2coord [1]. It is casting the
>> > col,
>> > row, depth values to integer like this:
>> >
>> > (int) col
>> >
>> > instead of using
>> >
>> > (int)floor(col)
>> >
>> > as a result, col = 0.1 => col = 0 and col = -0.1 => col = 0, which
>> > doesn't
>> > seem correct to me. Any opinions?
>>
>> I totally agree that there should be a function that returns the row,
>> col and depth as double values, so the developer can decide how to
>> handle these values. Otherwise there would be no convenient way to
>> determine where coordinates are located in the voxel.
>>
>> But i am not sure if the integer casting is a bug, since the
>> Rast_easting_to_col() /Rast_northing_to_row() docs suggest integer
>> casting as conversion method. There are algorithms in GRASS that use
>> only integer casting and algorithms that make use of rounding with
>> floor() before casting to integer.
>>
>> The problem arise in case of negative column,row or depth values when
>> casting to integer without rounding to an integer smaller than the
>> double number. So the question is are there any chances to receive
>> negative cols,rows and depths?
>>
>> It does not seems do to me for col and row, since in case of negative
>> coordinates will west and south always be smaller than east and north,
>> resulting in always positive cols and rows. And the same should be
>> true for depths, unless the top is smaller than bottom.
>
>
> 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.Good point, i have updated the Rast3d_location2coord() function to use
floor.
Thanks, I hope it won't be too much overhead comparing to int.
Anna
Best regards
Soeren> Thanks a lot for implementing Rast3d_location2coord_double.
>
> Anna
>
>>
>> Best regards
>> Soeren
>>
>> >
>> > Thanks, Anna
>> >
>> > BTW, similar function Rast_northing_to_row from raster library returns
>> > double.
>> >
>> >
>> > [1] http://grass.osgeo.org/programming7/region_8c_source.html#l00291
>> >
>> > _______________________________________________
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>