[postgis-devel] [PostGIS] #845: ST_Intersects() precision error - returns false instead of true
PostGIS
trac at osgeo.org
Thu Feb 24 04:46:02 PST 2011
#845: ST_Intersects() precision error - returns false instead of true
------------------------+---------------------------------------------------
Reporter: cdestigter | Owner: pramsey
Type: defect | Status: new
Priority: medium | Milestone: PostGIS 2.0.0
Component: postgis | Version: 1.5.X
Keywords: |
------------------------+---------------------------------------------------
Comment(by nicklas):
strk, you are right, pt_in_ring is counting crossings.
As I understand now we have different point in polygon code in 4 places
1) point_in_ring (winding number)
2) pt_in_ring (crossing number)
3) pt_in_ring_3d (winding number)
4) There is also some implementation for geography somewhere (crossing
number I think from a discussion some time ago)
The geography implementation have to be separate of course.
All the three others can be more or less merged.
I have not studied winding number enough to understand it. But at the
softsurfer link above that is what they recommend.
My reason for rewriting the iterations in 3d-version even if it is the
same thing happening as 2d-version is that it gets quite messy if I
project the polygon to, say x-z plane instead of x-y since x and y is hard
coded in the functions. If we can write the function so it just takes
coord1 and coord2 instead of x and y it can be used more widely.
How is that done in a robust way.
In other words, is this possible to do in some efficient robust way?
coord1=x;
pt.coord1;
instead of
pt.x;
a macro can do that?
Will it be to ugly (unefficient) or is it worth it to share more code?
/Nicklas
--
Ticket URL: <http://trac.osgeo.org/postgis/ticket/845#comment:11>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.
More information about the postgis-devel
mailing list