Geometry Boost List: [ggl] Snapping

Subject: [ggl] Snapping
From: Stephen Leary (sleary)
Date: 2009-12-02 05:19:49

On Tue, Dec 1, 2009 at 7:05 PM, Mateusz Loskot <mateusz_at_[hidden]> wrote:

> Stephen Leary wrote:
>
>  On Tue, Dec 1, 2009 at 9:34 AM, Barend Gehrels wrote:
>>
>>> 3) I don't understand this: "Line to Vertex (LV). It is rare to want
>>> to do this. But occasionally this is the right answer when a Vertex
>>> has a higher positional accuracy.", what do you mean by higher
>>> positional accuracy? You mean that the vertex is more precise, that
>>> you know that before, and therefore want to snap the line to that?
>>> So there probably must be a parameter (or more) to influence the
>>> behaviour of the algorithm?
>>>
>>
>>
>> Imagine i have people out capturing data. One captures a point where he
>> thinks it is on a map, the other captures the point using GPS. The capture
>> method will generally get stored with the data in a database and the
>> positional accuracy will be estimated. Some points are never allowed to move
>> so the algorithms have to be able to snap lines to points as well as points
>> to lines.
>>
>
> Let's say I'm developing UML drawing software, with SVG as data format
> and GGL for geometry. I want to have configurable snapping.
> What would be the positional accuracy?
>
>
There wouldnt be positional accuracy. You would simply make a choice on
which object would snap to which.  In UML you are unlikely to need to
correct the same kind of errors that GIS needs. You would probably not need
L-L snapping at all.

Let me be clear. The algorithm will not take a positional accuracy parameter
but it may be that you decide to do that kind of snap because a decision is
made in your own application.

> IOW, I'd suggest to increase the altitude of this analysis to more
> generic level, than the domain-specific about GIS. Or we are
> talking about extensions::gis::snap, then I'm fine & well
> with what Stephen is proposing.
>
>
For non-GIS needs V-V and L-V are sufficient for 99.999% of snapping.

>
>  The four algorithms are separate ways of snapping. More complex "high
>> level" uses of these algorithms may be created and implemented later. For
>> now I wanted to highlight some of the use cases so that we didnt produce an
>> over-simplistic way of snapping that couldnt be used for these cases.
>>
>
> OK, I'm clear now.
>
>
>
>  5) What will happen if two vertices are within the snap tolerance,
>>>    but a segment is even closer?
>>>
>>
>
> Barend, I imagine this decision belongs to end-user, application,
> which one is preferred.
>
>
>  6) what will happen if a point is close to a polygon (with holes),
>>> closer to one of the holes than to the boundary? Will it first
>>> detect the best-vertex-to-snap-to
>>>
>>
>> It should always snap to the nearest ring. A test will be made early on to
>> find the nearest ring and discard the others from the test.
>>
>
> I think there is a confusion here.
> Both, exterior ring and interior ring, according to OGC, define
> polygon boundaries.
> Given that, snapping works as "snap-to-boundary", thus it does not matter
> if point is snapped to vertex/segment of exterior ring or
> interior ring, in both cases it's snapped to polygon boundary
> and never crosses polygon interior.
>
> Correct me if I'm wrong.
>

Again its a usage thing. You may not want to snap a polygon to another
polygon's interior and exterior rings at the same time (or maybe you do).

Lots of things to think about anyway.

Stephen

>
>

> Best regards,
>
> Mateusz Loskot, http://mateusz.loskot.net
> _______________________________________________
> ggl mailing list
> ggl_at_[hidden]
> http://lists.osgeo.org/mailman/listinfo/ggl
>

-- 
Stephen Leary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20091202/50e7eecd/attachment.html