Hi,
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,
Denis
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
