<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
<br>
<div class="moz-cite-prefix">On 14.12.2014 15:12, Zoltan Szecsei
wrote:<br>
</div>
<blockquote cite="mid:548D9ACF.9010105@geograph.co.za" type="cite">
<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">
<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>
</ul>
</blockquote>
well, the case you mention is not feasible today in QGIS and will be
handled by my proposal of having the "map units" and dropping "layer
units".<br>
<blockquote cite="mid:548D9ACF.9010105@geograph.co.za" type="cite">
<ul>
<li> <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>
</blockquote>
I agree with these points but they are not related to the question
of the units for the snapping.<br>
<br>
We do a lot of digitizing too, and what I've noticed:<br>
* 95% of the time, the precision is given in pixels because that's
the most natural to work with (no scale dependency).<br>
* for the rest, working in the project unit is ideal.<br>
<br>
What is the chance of working with a layer with a projection on a
project in geographic coordinates and do digitizing?<br>
<br>
Maybe, there will be a very specific use-case for layer units. <br>
<br>
But, for me the aim of QGIS is to stay the most intuitive possible
and not to be weighed down under tons of configuration
possibilities.<br>
<br>
Also, I do believe it will make the code more complex (Martin?).<br>
<br>
That's my main two reasons for not keeping the "layer units".<br>
<br>
Best regards,<br>
<br>
Denis<br>
<br>
</body>
</html>