<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 2014/12/14 15:20, Rouzaud Denis
      wrote:<br>
    </div>
    <blockquote
      cite="mid:B06F52D2-A643-4BDA-8F3B-51EEEB6DF80B@gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div class=""><br class="">
      </div>
      <div class="">From my point of view, the settings of snapping are
        far too advanced for 95% of the usage. Let’s not make them even
        more complicated, just for a very specific use case.</div>
    </blockquote>
    <br>
    Hi Denis,<br>
    I have to disagree with you, as someone who does a fair amount of
    digitising.<br>
    <br>
    To support Ramon, I too work with many map layers in many different
    projections, so we mustn't lose facilities that we (even by
    accident) have.<br>
    <br>
    Some points:<br>
    <ul>
      <li>Being able to set a global tolerance in linear units, and have
        QGIS convert that to the relevant layer CRS would be VERY
        useful.<br>
        ie: I want a 10m snapping tolerance even if I am on a LatLong
        map layer.<br>
      </li>
      <li>QGIS only allows Snap Modes "To Vertex", "To Segment" or "To
        Vertex and Segment"<br>
        What if both a Line-end and a Vertex on that same line is within
        tolerance?<br>
        We really need to differentiate between Point (the Start &
        End Vertex of a Line or Polygon), Vertex and Segment AND be able
        to set the Snapping order between those three components of a
        graphical entity.</li>
      <li>The snapping order between layers is currently set to the
        order of the maps in your Layer Tree. Depending on the features
        you are digitising, this is not optimal as one often needs to
        have a layer snapping order different from the viewing order.</li>
      <li>It would be useful to set the layer snapping order in the
        Snapping Options table, and have the <u>option</u> (and not
        enforced by the developer) to prioritise the current map being
        edited.<br>
      </li>
      <li>If I remember correctly, snapping returns a position from the
        first layer it finds anything in, and IIRC if there are multiple
        snaps on that layer, the closest is returned? What if there are
        still unsearched layers that might have something within
        tolerance?</li>
    </ul>
    <p>The above is just a couple of walls I have hit when trying to
      digitise large volume jobs with multiple feature types and map
      layers. <br>
    </p>
    <br>
    My 2c<br>
    <br>
    Regards,<br>
    Zoltan<br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 

===========================================
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
GIS and Photogrammetric Services

P.O. Box 7, Muizenberg 7950, South Africa.

Mobile: +27-83-6004028
Fax:    +27-86-6115323     <a class="moz-txt-link-abbreviated" href="http://www.geograph.co.za">www.geograph.co.za</a>
===========================================</pre>
  </body>
</html>