[Qgis-developer] Snapping tolerance

Denis Rouzaud denis.rouzaud at gmail.com
Sun Dec 14 22:41:02 PST 2014


On 14.12.2014 15:12, Zoltan Szecsei wrote:
> On 2014/12/14 15:20, Rouzaud Denis wrote:
>> 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.
> Hi Denis,
> I have to disagree with you, as someone who does a fair amount of 
> digitising.
> 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.
> Some points:
>   * Being able to set a global tolerance in linear units, and have
>     QGIS convert that to the relevant layer CRS would be VERY useful.
>     ie: I want a 10m snapping tolerance even if I am on a LatLong map
>     layer.
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".
>  *
>   * QGIS only allows Snap Modes "To Vertex", "To Segment" or "To
>     Vertex and Segment"
>     What if both a Line-end and a Vertex on that same line is within
>     tolerance?
>     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.
>   * 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.
>   * It would be useful to set the layer snapping order in the Snapping
>     Options table, and have the _option_ (and not enforced by the
>     developer) to prioritise the current map being edited.
>   * 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?
I agree with these points but they are not related to the question of 
the units for the snapping.

We do a lot of digitizing too, and what I've noticed:
* 95% of the time, the precision is given in pixels because that's the 
most natural to work with (no scale dependency).
* for the rest, working in the project unit is ideal.

What is the chance of working with a layer with a projection on a 
project in geographic coordinates and do digitizing?

Maybe, there will be a very specific use-case for layer units.

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.

Also, I do believe it will make the code more complex (Martin?).

That's my main two reasons for not keeping the "layer units".

Best regards,


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20141215/6a2c8ece/attachment.html>

More information about the Qgis-developer mailing list