[Qgis-developer] Snapping tolerance

[Zoltan Szecsei]

Hi Denis/All,

On 2014/12/15 08:41, Denis Rouzaud wrote:
>
>>   * 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".
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?
>>
>>  *
>>
>>
>>   * 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.
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.
>
> 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).
Valid for manual digitising, but not for scripted testing if "minimum 
distance" rules have been adhered to by your digitising staff.
> * for the rest, working in the project unit is ideal.
Except if projects CRS is in LATLONG.
>
> What is the chance of working with a layer with a projection on a 
> project in geographic coordinates and do digitizing?
Thank you for asking :-)
South Africa is covered by 1920 'mapsheets' that are printed at 1:50K, 
but captured at closer to 1:10K details levels.
I have digitised/revised 1114 of these mapsheets. That's more than half 
of South Africa.
When working at a national level, the question here is/"What is the 
chance of working with a layer with a projection on a project that is 
NOT 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.
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.
>
> Also, I do believe it will make the code more complex (Martin?).
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.

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.

Kind regards,
Zoltan
>
> That's my main two reasons for not keeping the "layer units".
>
> Best regards,
>
> Denis
>


-- 

===========================================
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     www.geograph.co.za
===========================================

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