#3352: Behavior of v.sort.points
---------------------+-------------------------
Reporter: spawley | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.4.0
Component: Addons | Version: unspecified
Keywords: | CPU: Unspecified
Platform: Linux |
---------------------+-------------------------
Hello devs,
I appear to be having some problems with the add on v.sort.points. Two
issues, potentially bugs:
(1) the module fails if the 'cat' column is not the first attribute in the
table (i.e. if points have been generated from a database table),
returning the error:
'Error in sqlite3_prepare(): duplicate column name: cat'
(2) even if 'cat' is the first column, sorting by an integer column does
not appear to be sorting point datasets in numeric order. Example from the
nc_spm location:
The order of the points based on opening the attribute table, and the
relationship between the 'ID' column and 'cat' appears to be the same as
the original dataset, where 'ID' was not in ascending order.
Either I'm doing something wrong or the add on requires some tweaks.
Otherwise his would be a very useful tool.
Replying to [ticket:3352 spawley]:
> Hello devs,
>
> I appear to be having some problems with the add on v.sort.points. Two
issues, potentially bugs:
>
> (1) the module fails if the 'cat' column is not the first attribute in
the table (i.e. if points have been generated from a database table),
returning the error:
>
> 'Error in sqlite3_prepare(): duplicate column name: cat'
Try r71147. This should hopefully fix that issue.
> (2) even if 'cat' is the first column, sorting by an integer column does
not appear to be sorting point datasets in numeric order. Example from the
nc_spm location:
>
> v.sort.points input=firestations@PERMANENT output=firestations_sorted
column=ID
>
> The order of the points based on opening the attribute table, and the
relationship between the 'ID' column and 'cat' appears to be the same as
the original dataset, where 'ID' was not in ascending order.
This is not a bug: cat values are conserved, i.e. the same points have the
same cat value in the input and the output. However, points are in a
different order in the file after v.sort.points. Category values of
objects do not define order.
Replying to [comment:2 mlennert]:
> Replying to [ticket:3352 spawley]:
>
> > (2) even if 'cat' is the first column, sorting by an integer column
does not appear to be sorting point datasets in numeric order. Example
from the nc_spm location:
> >
> > v.sort.points input=firestations@PERMANENT output=firestations_sorted
column=ID
> >
> > The order of the points based on opening the attribute table, and the
relationship between the 'ID' column and 'cat' appears to be the same as
the original dataset, where 'ID' was not in ascending order.
>
> This is not a bug: cat values are conserved, i.e. the same points have
the same cat value in the input and the output. However, points are in a
different order in the file after v.sort.points. Category values of
objects do not define order.
(2) even if ‘cat’ is the first column, sorting by an integer column
does not appear to be sorting point datasets in numeric order. Example
from the nc_spm location:
The order of the points based on opening the attribute table, and the
relationship between the ‘ID’ column and ‘cat’ appears to be the same as
the original dataset, where ‘ID’ was not in ascending order.
This is not a bug: cat values are conserved, i.e. the same points have
the same cat value in the input and the output. However, points are in a
different order in the file after v.sort.points. Category values of
objects do not define order.