is there any reason not to exit with a fatal error if the user tries to
run v.to.db option=azimuth from a lat/lon location? (the result is
useless)
an alternative is to use libproj to calculate forward and backward
azimuth geodesic angles, and send that to two DB columns. Until that is
done, I would have it G_fatal_error() at the end of v.to.db's
parse_command_line().
is there any reason not to exit with a fatal error if the user tries to
run v.to.db option=azimuth from a lat/lon location? (the result is
useless)
Also, in an ongoing effort to stop people shooting themselves in the foot,
I would suggest to add a warning to v.to.db option=perimeter that the
result is probably not what the user is after. At minimum I suggest a
paragraph in the man page explaining the fractal problem, which could
also be a good introduction to the op=fractal dimension and compact options,
but I don't think that is enough, as many don't bother to RTFM and broken
analysis reflects badly on GRASS as well as the end-user.
if there are objections to using G_warning() as well, please speak up.
On Tue, Apr 12, 2011 at 10:55 PM, Hamish <hamish_b@yahoo.com> wrote:
Hi,
is there any reason not to exit with a fatal error if the user tries to
run v.to.db option=azimuth from a lat/lon location? (the result is
useless)
an alternative is to use libproj to calculate forward and backward
azimuth geodesic angles, and send that to two DB columns. Until that is
done, I would have it G_fatal_error() at the end of v.to.db's
parse_command_line().
?,
Hamish
I think this is a wise decision, until code is in place to handle
lat/lon coordinates.
I agree with Hamish on this as well. Please add the suggested
warnings. Perhaps we can provide and link, and/or condensed summary of
the following wikipedia article:
On Tue, Apr 12, 2011 at 11:07 PM, Hamish <hamish_b@yahoo.com> wrote:
Hamish wrote:
is there any reason not to exit with a fatal error if the user tries to
run v.to.db option=azimuth from a lat/lon location? (the result is
useless)
Also, in an ongoing effort to stop people shooting themselves in the foot,
I would suggest to add a warning to v.to.db option=perimeter that the
result is probably not what the user is after. At minimum I suggest a
paragraph in the man page explaining the fractal problem, which could
also be a good introduction to the op=fractal dimension and compact options,
but I don't think that is enough, as many don't bother to RTFM and broken
analysis reflects badly on GRASS as well as the end-user.
if there are objections to using G_warning() as well, please speak up.