Opened 10 years ago

Closed 10 years ago

#2613 closed defect (fixed)

st_curvetoline not accurate

Reported by: hassony Owned by: pramsey
Priority: high Milestone: PostGIS 2.0.5
Component: postgis Version: 2.0.x
Keywords: Cc:

Description

I'm using the st_curvetoline function on a CIRCULARSTRING which is a closed shape ('ellipse') - the start and end points are the same. However, performing the st_curvetoline on this geometry results in a slightly different start & end points which seems due to precision, which causes the st_isclosed to return false.

The curved shape: CURVEPOLYGON(CIRCULARSTRING(-192.63 96.09,-236.72 -84.3,-262.33 -256.89,-267.71 -409.94,-252.5 -533,-217.73 -617.69,-165.78 -658.24,-100.19 -651.89, -25.42 -599.06,53.44 -503.37,130.99 -371.32,201.97 -211.92,261.53 -36.04,305.62 144.35,331.23 316.94,336.61 469.99,321.4 593.05,286.64 677.74,234.69 718.29,169.09 711.94,94.32 659.11,15.47 563.42,-62.09 431.37,-133.07 271.98,-192.63 96.09))

The st_curvetoline result:

POLYGON((-192.63 96.0899999999997,-217.49094913285 3.68 269634278732,-237.787740682362 -89.8331676257292,-253.471477899904 -184.232303998227,-262.33 -256.89,-266.542588544681 -299.745998177307,-268.6472586 8043 -342.757076350724,-268.638940072543 -385.819617065606,-266.517652761274 -428.829878889538,-262.28850711356 -471.684246334532,-255.961691511694 - 514.279479475813,-252.5 -533,-251.658894336039 -540.497237553746,-250.450929810044 -547.944173257723,-248.879016514363 -555.322866791548,-246.9469413 25809 -562.615542236198,-244.659358782741 -569.804630897767,-242.021779871873 -576.872813631977,-239.040558751827 -583.803062567522,-235.722877445405

-590.578682127699,-232.076728537468 -597.183349251514,-228.110895920101 -603.601152717363,-223.834933631445 -609.816631474565,-219.259142839184 -615

.814811890383,-214.394547024127 -621.581243822815,-209.252865423682 -627.102035432256,-203.846484799182 -632.363886648156,-198.188429595094 -637.3541 21210052,-192.292330561993 -642.060717205791,-186.172391918886 -646.47233603337,-179.843357134009 -650.578349716621,-173.320473406515 -654.3688665089 38,-166.619454934641 -657.834754723356,-165.78 -658.24,-158.27220787791 -658.95577504603,-150.738337803383 -659.302298010905,-143.196539529318 -659.2 78734090452,-135.664981908341 -658.885140052217,-128.161809122446 -658.122464098715,-120.705096972076 -656.992543583119,-113.312809329932 -655.498100 582921,-106.002754864432 -653.642735342207,-98.7925441370669 -651.430917598351,-91.6995471770205 -648.867975814032,-84.7408516352421 -645.96008434049 5,-77.9332216188017 -642.714248543001,-71.2930573046867 -639.138287924287,-64.8363554303397 -635.240817286701,-58.5786707561163 -631.031225978388,-52 .5350785925049 -626.519655273526,-46.7201384823841 -621.716973941109,-41.1478591258075 -616.634752061133,-35.8316646318194 -611.285233151256,-30.7843 621785992 -605.681304671096,-26.0181111598484 -599.836466975206,-25.42 -599.06,3.44582357033562 -567.161224310148,30.711678255014 -533.884493262475,5 6.3118782218929 -499.30997341677,80.1847503469395 -463.520957819713,102.272782790188 -426.603665344624,122.522763546799 -388.64703298265,130.99 -371. 32,171.67174396928 -284.717936588532,208.055123152742 -196.224030591009,240.052486803127 -106.05147157813,261.53 -36.04,286.39094913285 56.3673036572 126,306.687740682362 149.883167625729,322.371477899904 244.282303998228,331.23 316.94,335.442588544681 359.795998177307,337.54725868043 402.807076350 724,337.538940072543 445.869617065606,335.417652761274 488.879878889538,331.18850711356 531.734246334532,324.861691511694 574.329479475813,321.4 593. 05,320.560236709669 600.54576004541,319.353685438253 607.991285887927,317.783252873448 615.368640603647,315.852722324855 622.660051498878,313.5667446 0966 629.847952926123,310.930826848408 636.915028601256,307.951319197864 643.844253319975,304.635399552933 650.618933973003,300.991056254479 657.2227 49761254,297.027068844715 663.639791514071,292.752986916516 669.854600015802,288.179107107612 675.852203248415,283.316448295087 681.618152460394,278. 176725049939 687.13855697505,272.772319415653 692.400117654377,267.11625107877 697.390158937841,261.222146003329 702.096659378912,255.104203604718 70 6.508280605789,248.777162542044 710.614394636523,242.256265211411 714.405109482761,235.55722102565 717.87129298041,234.69 718.29,227.181974792479 719 .006101264455,219.647855906502 719.352938617851,212.105793694379 719.329676498623,204.573957644584 718.936370947256,197.070492609871 718.173969471271 ,189.613475094737 717.044308762603,182.220869707532 715.550110272845,174.910485882149 713.694973657036,167.699934973538 711.483368101773,160.60658783 0409 708.920621558554,153.647532947331 706.01290790827,146.83953529706 702.767232087792,140.198995942245 699.191413214458,133.741912523835 695.294065 749139,127.483840721359 691.084578743246,121.439856777931 686.573093219684,115.62452118026 681.770477742239,110.051843581166 676.688302232254,104.735 249049093 671.33881009568,99.6875457259478 665.734888727635,94.9208939711623 659.890038465538,94.3200000000002 659.11,65.4365040332256 627.1840887415 01,38.1543297185289 593.879387667767,12.5392022034703 559.276130720833,-11.3471694261464 523.457680177571,-33.4472408088659 486.510325822666,-53.7077 709369901 448.523077068964,-62.0899999999999 431.37,-102.757449576671 344.807495558579,-139.128492652405 256.353802273192,-171.115508198707 166.22201 2838594,-192.63 96.09))

The versions I'm using: PostgreSQL 8.2.15 (Greenplum Database 4.2.5.1 build 1) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Apr 25 2013 13:18:30

POSTGIS="2.0.3 r11128" GEOS="3.3.8-CAPI-1.7.8" PROJ="Rel. 4.8.0, 6 March 2012" LIBXML="2.7.8"

Change History (2)

comment:1 by pramsey, 10 years ago

I'm not seeing the same effect here (osx 10.9, clang, pgsql 9.2).

with curve as ( 
  select st_curvetoline(
  'CURVEPOLYGON(CIRCULARSTRING(-192.63 96.09,-236.72 -84.3,-262.33 -256.89,-267.71 -409.94,-252.5 -533,-217.73 -617.69,-165.78 -658.24,-100.19 -651.89, -25.42 -599.06,53.44 -503.37,130.99 -371.32,201.97 -211.92,261.53 -36.04,305.62 144.35,331.23 316.94,336.61 469.99,321.4 593.05,286.64 677.74,234.69 718.29,169.09 711.94,94.32 659.11,15.47 563.42,-62.09 431.37,-133.07 271.98,-192.63 96.09))'
  ) as curve ), 
startend as ( 
  select 
    st_y(st_startpoint(st_exteriorring(curve))) as s, 
    st_y(st_endpoint(st_exteriorring(curve))) as e 
  from curve )  
select s = e from startend;

And in reviewing the code, line 234 in lwsegmentize.c actually adds the first coordinate of the original line without alteration to the segmentized version. So I cannot even see programmatically how coordinate drift could be introduced. Any further examples? Smaller ones?

comment:2 by pramsey, 10 years ago

Resolution: fixed
Status: newclosed

Take it back. I downgraded to 2.0.3 and can replicate your problem. Fortunately the solution for you is to just upgrade to 2.0.4, it's fixed there (which is why it was working for me).

Note: See TracTickets for help on using tickets.