bilaldursun1 / nettopologysuite

Automatically exported from code.google.com/p/nettopologysuite
0 stars 0 forks source link

Intersection fails to find correct point when large coordiantes are used #94

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
Here is a test.  It fails like this.  Make the number a little smaller and it 
succeeds (ie change the last '5' to a '0' in the value below and it is ok.)

I was originally trying to create a line with coords of 10,double.MaxValue and 
10,double.MinValue, which also failed.

        [Test]
        public void IntersectionWithLineCreatedWithLargeCoordinates()
            {
            LineString ls = new LineString (new ICoordinate[]{new Coordinate(0,0),new Coordinate(50,50)});
            var value = 99999999999999982650000000000.0;            
            var geomtery = ls.Intersection (new LineSegment (new Coordinate (10, value), new Coordinate (10, -value)).ToGeometry (ls.Factory));
            Assert.That (geomtery.Coordinates[0].Equals2D (new Coordinate(10,10)));
            } 

What is the expected output? What do you see instead?
it returns a point at 0,0 rather then 10,10

What version of the product are you using? On what operating system?
A build from the tip, taken approximately 4 days ago

Original issue reported on code.google.com by the.hold...@gmail.com on 7 Oct 2011 at 2:31

GoogleCodeExporter commented 9 years ago
I've checked the behaviour of the current trunk against JTS 1.11.0 and both 
generate the same results. So this looks like a JTS bug than a NTS bug.
I can ask for some info in the JTS mailing list.
You can see the JTS and NTS TestCases in the trunk, from r735

Original comment by diegogu...@gmail.com on 7 Oct 2011 at 3:09

GoogleCodeExporter commented 9 years ago
Here the JTS team: 
http://sourceforge.net/mailarchive/message.php?msg_id=28197232
"This is a known issue.  It's not really a bug, it's a design limitation 
caused by the fact that JTS uses double-precision floating point to 
represent ordinate values.  This provides about 16 decimal digits of 
precision."
So, it isn't actually a bug.
Thanks in any case for reporting this.

Original comment by diegogu...@gmail.com on 7 Oct 2011 at 6:09