[GRASS-dev] [GRASS GIS] #3430: v.clean threshold in lat-long: metric or not?

GRASS GIS trac at osgeo.org
Fri Nov 10 11:14:28 PST 2017


#3430: v.clean threshold in lat-long: metric or not?
--------------------------+-------------------------
  Reporter:  neteler      |      Owner:  grass-dev@…
      Type:  defect       |     Status:  new
  Priority:  normal       |  Milestone:  7.2.3
 Component:  Vector       |    Version:  7.2.2
Resolution:               |   Keywords:  v.clean
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mlennert):

 Replying to [ticket:3430 neteler]:
 > From:
 > https://gis.stackexchange.com/questions/258089/v-clean-with-rmarea-and-
 lat-long-projection
 >
 > There is some confusion concerning this message:
 > main.c:
 > {{{
 >     /* TODO: threshold might be recalculated with optional geodesic
 support to meters */
 >     if (G_projection() == PROJECTION_LL)
 >         G_important_message(_("Note: In latitude-longitude coordinate
 system specify threshold in degree unit"));
 > }}}
 >
 > while the documentation reads:
 > {{{
 > grep meter v.clean.html
 > case, also the threshold parameter requires several values to be listed
 > Threshold must always be in square meters, also for latitude-longitude
 > locations or locations with units other than meters.
 > }}}
 >
 > Should the G_important_message() be removed from main.c?

 Looking through the code, I actually have the feeling that the
 documentation is wrong, at least for some of v.clean's functionalities.
 For example for snapping, I see the following in the
 [https://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/snap.c#L302
 code]:

 {{{
             dx = XPnts[pointb].x - XPnts[point].x;
             dy = XPnts[pointb].y - XPnts[point].y;
             dist2 = dx * dx + dy * dy;

             if (dist2 > thresh2) /* outside threshold */
                 continue;
 }}}

 So while area calculations might use meters (i.e. the rmarea function
 mentioned in the SE message), I'm not sure this is the case for snapping
 distances... I think this needs very careful review before deciding what
 to do.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3430#comment:1>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list