Problem with small arc: Positions are collinear in 2D.

[JoostdeK]

Hi,

I have a polygon with a very small arc in it (milimeters in epsg:28992). When reading this polygon from the database with Hibernate 5, Geolatte gives the error: Positions are collinear in 2D. I've made a test for it to reproduce it:

    @Test
    public void testIsCounterClockwise() {
        Position position1 = new C2D(new double[]{103063.722,438638.234});
        Position position2 = new C2D(new double[]{103063.723,438638.234});
        Position position3 = new C2D(new double[]{103063.723,438638.233});
        NumericalMethods.isCounterClockwise(position1,position2,position3);
    }

Now I'm really not smart enough to understand all the maths going on in these classes :). Sadly I can't change the polygon or the arc. I was wondering if there is anything I can do in the geolatte lib to read this feature from the database?

EDIT:

@Test
    public void testIsCounterClockwise2() {
        Position position1 = new C2D(new double[]{0.001,0.001});
        Position position2 = new C2D(new double[]{0.002,0.001});
        Position position3 = new C2D(new double[]{0.002,0.000});
        NumericalMethods.isCounterClockwise(position1,position2,position3);
    }

Which for me is the same dif in mm strangely enough works.

EDIT2: The large numbers of my coordinate system seem to be the problem. It seems if I just dumbly divide all the positions by a 1000, my first mentioned testcase no longer gives a collinear error. I wonder if this is a valid workaround?

example:

 private static double deltaDeterminant(Position p0, Position p1, Position p2) {
        double[] c0 = p0.toArray(null);
        double[] c1 = p1.toArray(null);
        double[] c2 = p2.toArray(null);
        return determinant(1, 1, 1, c0[0]/1000, c1[0]/1000, c2[0]/1000, c0[1]/1000, c1[1]/1000, c2[1]/1000);
    }

Kind regards,

Jim

[maesenka]

This is an example of a robustness problem. There is little we can do about this, I'm afraid.

The problem should go away when we implement support for curves and arcs. The problem occurs because we need to linearize arc segments to comply with the Simple Feature model.

What database are you using?

[maesenka]

I hope to have support for all the SQL/MM curve types in Postgis by end-of-year. That should also translate in better support for Oracle.

[maesenka]

Mabe there is something we can do. If the points are so close to colinear, we can simply treat them as linear.

Could you provide me the Polygon as an SDO_GEOMTRY, so I have a test case?

[JoostdeK]

EDIT: Made comments under the wrong user. My previous posts:

We are using Oracle Database 19c Enterprise Edition Release 19.0.0.0.0.

Linearization of arcs has always been a pain in our ass, even in Hibernate 4. For now we might have a way to work around it. We will search for patterns for which arcs give us problems (size ect) and ask the dataholders to change them and then restrict ,using the same rules, which types of arcs can be inserted.

Digging up the exact geometry of the above mentioned object can take a while. However, I have alot of other ones ready to go :). Can you work with these examples?

{2003,28992,null,{1,1005,3,1,2,1,15,2,2,19,2,1},{209499.475,578259.358,209503.708,578359.503,209505.325,578409.615,209505.144,578416.324,209504.933,578419.552,209505.118,578420.213,209505.693,578421.019,209500.401,578421.362,209500.401,578421.361,209500.402,578421.361,209500.832,578421.033,209501.057,578420.591,209501.063,578420.225,209499.607,578371.806,209497.623,578305.131,209495.574,578238.184,209495.409,578222.433,209495.062,578211.578,209498.02,578211.469,209499.475,578259.358}}

Or else maybe:

{2003,28992,null,{1,1005,11,1,2,1,7,2,2,11,2,1,13,2,2,17,2,2,21,2,1,29,2,2,33,2,2,37,2,1,41,2,2,45,2,2},{154259.254,379216.858,154257.848,379216.059,154257.951,379215.542,154259.501,379216.423,154259.997,379216.943,154260.125,379217.651,154251.434,379287.611,154250.261,379296.521,154248.768,379305.382,154247.256,379314.357,154246.068,379323.381,154245.84,379325.489,154245.541,379325.454,154245.349,379325.432,154245.571,379323.325,154246.762,379314.283,154248.276,379305.29,154249.766,379296.446,154250.937,379287.554,154259.628,379217.594,154259.628,379217.592,154259.628,379217.59,154259.629,379217.589,154259.55,379217.168,154259.254,379216.858}}

We have around 200 objects that give errors, so many more if you need them ;)

[maesenka]

Hi I implemented the solution so that (nearly) co-linear coordinates are treated as linear and will be used as-is. Could you maybe test this? It's in 1.9-snapshot

[JoostdeK]

Sorry was down with covid for a long time. Tested it and it works!

[maesenka]

I'll make a release then