<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><font color="#009900">Hi Denis/All,<br>
</font><br>
On 2014/12/15 08:41, Denis Rouzaud wrote:<br>
</div>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<blockquote cite="mid:548D9ACF.9010105@geograph.co.za" type="cite">
<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>
<font color="#009900">ie: I want a 10m snapping tolerance
even if I am on a LatLong map layer.</font><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>
<font color="#009900">So I would have to (outside of QGIS) manually
calculate the degrees (at my current latitude) I would have to
insert into the Snapping options, for whatever linear snapping
tolerance I want to set?</font><br>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite">
<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>
<font color="#009900">I agree with these points but they are not
related to the question of the units for the snapping.<br>
</font></blockquote>
<font color="#009900">Agreed - but whilst the developer/maintainer
is busy in that part of QGIS, wouldn't it be nice to know what
amendment requests might be coming up or doable at the same time?
So the above list is not a formal request (QEP?) but rather a
'headsup' on what else might be worth considering.</font><br>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"> <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>
</blockquote>
Valid for manual digitising, but not for scripted testing if
"minimum distance" rules have been adhered to by your digitising
staff.<br>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"> * for
the rest, working in the project unit is ideal.<br>
</blockquote>
Except if projects CRS is in LATLONG.<br>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"> <br>
<font color="#009900">What is the chance of working with a layer
with a projection on a project in geographic coordinates and do
digitizing?<br>
</font></blockquote>
<font color="#009900">Thank you for asking :-)<br>
South Africa is covered by 1920 'mapsheets' that are printed at
1:50K, but captured at closer to 1:10K details levels.<br>
I have digitised/revised 1114 of these mapsheets. That's more than
half of South Africa.<br>
When working at a national level, the question here is<i> "What is
the chance of working with a layer with a projection on a
project that is NOT in geographic coordinates, and do
digitizing?"</i></font>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"> <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>
</blockquote>
<font color="#009900">Intuitive use comes from sensible defaults,
and not from removing wider options that a handful of people
(handful in relation to the user base) deem not necessary.<br>
</font>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"><font
color="#009900"> </font><br>
Also, I do believe it will make the code more complex (Martin?).<br>
</blockquote>
<font color="#009900">A programmer writes a piece of code FAAAR less
often than that that piece of code gets used by the user, so the
focus must always be on user friendliness (sensible defaults) and
the user's ability to make that function work the way he needs it.</font><br>
<br>
<font color="#009900">So, I am NOT meaning to be argumentative, but
the work I have carried out over the years, does fit into the
usage case that you are a proponent of removing, so I am
highlighting the need for that case.<br>
<br>
Kind regards,<br>
Zoltan</font><br>
<blockquote cite="mid:548E827E.4090105@gmail.com" type="cite"> <br>
That's my main two reasons for not keeping the "layer units".<br>
<br>
Best regards,<br>
<br>
Denis<br>
<br>
</blockquote>
<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>