Geometry Boost List: [ggl] Snapping

Subject: [ggl] Snapping
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-12-01 13:12:41

Hi Stephen,

>
> Yes. What i mean is while the algorithm doesnt need to know about the 
> size of your data a snapping tolerance should be chosen sensibly. 
> Usually around 10 times the geometric tolerance. I found that alot 
> more than this caused whole objects to snap and lose their basic shape 
> and alot smaller than this caused problems with
OK, sorry if I missed it, but what do you mean exactly by "geometric 
tolerance"? This? 
http://www.roymech.co.uk/Useful_Tables/Drawing/draw_geom.html

>  
> 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 see.

>
>     4) What will happen if a vertex is not projected on the line
>     segment? Within all drawings, it is on the line segment, but what
>     if it is just a little above?
>
>
>  I dont follow this one... could you draw it?
It is probably handled by your answers.

The point will move to the closest segment-vertex, or the segment-vertex 
will move to the point. Even if that point is not 'projected' (that is 
probably not that important).

>
> 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 see. I think that is important. Using Boost.Geometry (GGL), all 
methods handle all geometries. So within a polygon you first find the 
closest ring. Within a multi-polygon, you first find the closest 
polygon, and then the closest ring.

>
> The summary is that snapping is complicated and that different 
> people/users will want to snap things differently. The four basic 
> snapping methods should be kept separate from an algorithm point of 
> view so that different ways of snapping can be decided for specific 
> implementations. I would like to have some easy to use snapping 
> methods but also leave the ability to cusomise exacly how things snap 
> too.
>
> I know this is not an easy subject because my brain hurt the first 
> time I saw all this.
>
Yes, it is not so easy; you have much experience with it and there is 
interest in it. So I would say, go ahead, it is very interesting for 
both parties, for you (I think) to discover Boost.Geometry and its 
design, for Boost.Geometry to have additional functionality.

There was not yet a "projected point" strategy, but I created it this 
year for another project, and will check this in. It is probably very 
useful for you. It is a strategy, meaning dependant on coordinate 
systems. It is currently only for Cartesian, but as soon as we have it 
for Spherical, your algorithm will probably work for that as well (it 
might make sense in case of digitizing countries or continents).

I've sent you SVN account including write access. Can you put it in e.g. 
extensions/gis/edit (you can create it) or extensions/gis/snap?

Regards, Barend

-------------- next part --------------
Skipped content of type multipart/related