Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failure with OrientedEnvelope #10

Open
Tracked by #244
pnorman opened this issue Sep 13, 2015 · 3 comments
Open
Tracked by #244

Test failure with OrientedEnvelope #10

pnorman opened this issue Sep 13, 2015 · 3 comments

Comments

@pnorman
Copy link
Contributor

pnorman commented Sep 13, 2015

not ok 30 - ST_AsText(OrientedEnvelope(ST_GeomFromText('LINESTRING(0 0, 10 10, 8 12)')))
    expected: 'POLYGON((8 12,10 10,0 0,-2 2,8 12))'
    actual: 'POLYGON((2.30769230769231 -1.53846153846154,1.77635683940025e-15 -8.88178419700125e-16,8 12,10.3076923076923 10.4615384615385,2.30769230769231 -1.53846153846154))'

PostGIS full version is POSTGIS="2.1.7 r13414" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 1.11.2, released 2015/02/10" LIBXML="2.9.2" LIBJSON="UNKNOWN" RASTER, PostgreSQL is 9.4.4 server and client

@ajashton
Copy link
Contributor

Thanks, will try to replicate.

@pnorman
Copy link
Contributor Author

pnorman commented Nov 21, 2015

I stepped through the function on my new server, and an old server running 2.0 r9605 from SVN, where the test passed.

Stepping through manually, I get the same answer on both - the answer I get on my new server. But, looking closely at all the steps, I can see what's going on. Both return values have the same ST_Area, showing that there is not a unique solution. Thinking about it, it's obvious that this is the case: consider a regular polygon with N sides, there will be N solutions, unless some are equal. e.g. an equilateral triangle has three OrientedEnvelopes, and a circle will have infinitely many OrientedEnvelopes.

This linestring happens to trigger that case. When I step through by hand, I get slightly different rounding behavior, so it picks a different solution. The problem is the comparison area_cur < area_min, which depends on the floating point behavior of

  • ST_Area
  • ST_Envelope
  • ST_Rotate
  • ST_Azimuth
  • pi()
  • Any underlying system calls

As to why does it trigger that case? I believe any right-angled triangle will, but haven't gone through a geometric proof. Any isosceles certainly will. This case happens to be a 1-5-sqrt(26) right-angled triangle.

We should probably change the test so that we test a shape with a unique solution.

There's also another issue - should we guarantee a particular solution when there are multiple valid ones?

@pnorman
Copy link
Contributor Author

pnorman commented Dec 28, 2015

ping @ajashton

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants