headers
Sandro Santilli | 1 Mar 2012 18:48
Gravatar

Re: ST_Snap

On Wed, Feb 29, 2012 at 08:14:15AM -0800, Martin Davis wrote:
> Snap-rounding is a well-defined technique for eliminating robustness
> problems when overlaying arrangements of line segments.  The
> original paper is by John Hobby; another good paper is this one by
> Goodrich et al:
> 
> http://www.ics.uci.edu/~goodrich/pubs/snap.pdf
>
> Google gives lots of references to various papers. As always, there
> is a big gap between the papers and a practical implementation!

Great, thanks for the link!
My approach for the incremental topology creation is 
a first-come best-served one. Hot pixels are nodes by definition,
every node of an existing topology is an hot-pixel there.

But it's not easy to determine the grid size, which that paper
is based upon, right ? How close should a segment be to a node
in order to snap there ? In other words, how big is the hot pixel ?

It'd surely be useful to let the user specify such grid (tolerance?)
when invoking GEOS functions.

It's also interesting to note that the floating point number grid 
is of variable size, with cells growing in size while moving away 
from origin.

--strk;

  ,------o-.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Davis | 2 Mar 2012 02:08

Re: ST_Snap


On 3/1/2012 9:48 AM, Sandro Santilli wrote:
> On Wed, Feb 29, 2012 at 08:14:15AM -0800, Martin Davis wrote:
>> Snap-rounding is a well-defined technique for eliminating robustness
>> problems when overlaying arrangements of line segments.  The
>> original paper is by John Hobby; another good paper is this one by
>> Goodrich et al:
>>
>> http://www.ics.uci.edu/~goodrich/pubs/snap.pdf
>>
>> Google gives lots of references to various papers. As always, there
>> is a big gap between the papers and a practical implementation!
> Great, thanks for the link!
> My approach for the incremental topology creation is
> a first-come best-served one. Hot pixels are nodes by definition,
> every node of an existing topology is an hot-pixel there.
>
> But it's not easy to determine the grid size, which that paper
> is based upon, right ? How close should a segment be to a node
> in order to snap there ? In other words, how big is the hot pixel ?
Data-dependent.  I think you need to let the user choose.  You should be 
able to get away with 10 digits of precision.
>
> It'd surely be useful to let the user specify such grid (tolerance?)
> when invoking GEOS functions.
>
> It's also interesting to note that the floating point number grid
> is of variable size, with cells growing in size while moving away
> from origin.
Snap-rounding assumes a fixed-point coordinate system.  It's not going
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sandro Santilli | 2 Mar 2012 09:46
Gravatar

Re: ST_Snap

On Thu, Mar 01, 2012 at 05:08:26PM -0800, Martin Davis wrote:
> On 3/1/2012 9:48 AM, Sandro Santilli wrote:

> >But it's not easy to determine the grid size, which that paper
> >is based upon, right ? How close should a segment be to a node
> >in order to snap there ? In other words, how big is the hot pixel ?
>
> Data-dependent.  I think you need to let the user choose. 

I agree, it needs to be decided once and globally.

I've been thinking about the "expanding grid" idea and realized
you just _can't_ rely on it because if you have to compute a grid
based on ordinate values you can only do it _locally_ so you'd need
to recompute it for every intersection point (and scaling to the
origin to improve robustness would also change those "local" numbers
making it even harder to tell).

The alternative of computing "min_grid_size" based on each operation
is also broken because an operation performed on a long edge (insert
a long edge into the existing topology) will have to use a large grid
(the size of the biggest cell within the new edge extent) while a point
you may have added before would have used a smaller grid size so you'd
end up with different tolerances which would create hard or impossible
to manage situations (multiple candidate hotpixels to snap to).

> You should be able to get away with 10 digits of precision.

Yep, that's about the value my convoluted "find out min tolerance"
gives you. Could be 10 digits very much on the left of the decimal
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Davis | 2 Mar 2012 16:20

Re: ST_Snap


On 3/2/2012 12:46 AM, Sandro Santilli wrote:
>
> Snap-rounding assumes a fixed-point coordinate system.  It's not
> going to be able to handle datasets with huge variation in scale.
> If instructed by user about the cell size it wouldn't need to assume
> anything, right ? That'd probably be the aim.
>
cell size = fixed-precision coordinate system, right?

Or am I not understanding your "cell size"?
Permalink | Reply | 1 comment |
headers
Sandro Santilli | 5 Mar 2012 09:59
Gravatar

Re: ST_Snap

On Fri, Mar 02, 2012 at 07:20:55AM -0800, Martin Davis wrote:
> 
> 
> On 3/2/2012 12:46 AM, Sandro Santilli wrote:
> >
> >Snap-rounding assumes a fixed-point coordinate system.  It's not
> >going to be able to handle datasets with huge variation in scale.
> >If instructed by user about the cell size it wouldn't need to assume
> >anything, right ? That'd probably be the aim.
> >
> cell size = fixed-precision coordinate system, right?
> 
> Or am I not understanding your "cell size"?

Yes, by "cell-size" I mean a fixed-precision coordinate system.

--strk; 

  ,------o-. 
  |   __/  |    Delivering high quality PostGIS 2.0 !
  |  / 2.0 |    http://strk.keybit.net - http://vizzuality.com
  `-o------'
Permalink | Reply | 0 comments |
headers
GEOS | 5 Mar 2012 17:18
Favicon

[GEOS] #515: mingw64 make check returns #IND

#515: mingw64 make check returns #IND
------------------------+---------------------------------------------------
 Reporter:  robe        |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  trivial     |   Milestone:  3.3.3                     
Component:  Default     |     Version:  3.3.2                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------
 On my mingw64 chain.  Make check tests pass except for 1

 {{{
 ---> group: capi::GEOSisValidDetail, test: test<3>
      problem: assertion failed
      failed assertion: "Values are not equal: expected 'POINT (NAN -5)'
 actual '
 POINT (-1.#IND -5)'"
 }}}


 strk says its a harmless failure and just anotehr presentation of NAN.

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/515>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
(Continue reading)

Permalink | Reply | 6 comments |
headers
GEOS | 5 Mar 2012 17:26
Favicon

Re: [GEOS] #515: mingw64 make check returns #IND

#515: mingw64 make check returns #IND
------------------------+---------------------------------------------------
 Reporter:  robe        |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  trivial     |   Milestone:  3.3.3                     
Component:  Default     |     Version:  3.3.2                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by strk):

 Did mingw32 give you the same failure ?

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/515#comment:1>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Permalink | Reply | 0 comments |
headers
GEOS | 5 Mar 2012 17:28
Favicon

Re: [GEOS] #515: mingw64 make check returns #IND

#515: mingw64 make check returns #IND
------------------------+---------------------------------------------------
 Reporter:  robe        |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  trivial     |   Milestone:  3.3.3                     
Component:  Default     |     Version:  3.3.2                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by robe):

 mingw32 which one do you mean (the 3.4.5 ? ).  I forget because that one
 gives like 5 or 6 errors so I didn't pay much attention to it. That we
 have a separate ticket for I think on GEOS with all the noted errors.

 I'm planning to switch my 32-build to the mingw 64 chain BTW.

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/515#comment:2>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Permalink | Reply | 0 comments |
headers
GEOS | 5 Mar 2012 17:37
Favicon

Re: [GEOS] #515: mingw64 make check returns #IND

#515: mingw64 make check returns #IND
------------------------+---------------------------------------------------
 Reporter:  robe        |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  trivial     |   Milestone:  3.3.3                     
Component:  Default     |     Version:  3.3.2                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by strk):

 Im asking because a fix to this would be expecting the different answer
 based on the system, with some _MINGW_ macro or something. But I dont know
 which macro would do...

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/515#comment:3>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Permalink | Reply | 0 comments |
headers
GEOS | 5 Mar 2012 17:39
Favicon

Re: [GEOS] #515: mingw64 make check returns #IND

#515: mingw64 make check returns #IND
------------------------+---------------------------------------------------
 Reporter:  robe        |       Owner:  geos-devel <at> …              
     Type:  defect      |      Status:  new                       
 Priority:  trivial     |   Milestone:  3.3.3                     
Component:  Default     |     Version:  3.3.2                     
 Severity:  Unassigned  |    Keywords:                            
------------------------+---------------------------------------------------

Comment(by strk):

 Could you try the attached mingw.nan.patch file ?

--

-- 
Ticket URL: <http://trac.osgeo.org/geos/ticket/515#comment:4>
GEOS <http://geos.refractions.net/>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite (JTS).

_______________________________________________
geos-devel mailing list
geos-devel <at> lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
Permalink | Reply | 0 comments |

Gmane