Martin, all; Here is the wkt for the enclosing polygon:
53327 | SRID=1;POLYGON((1224673.7804 499721.97084,1224664.2479 499721.56584,1224639.311 499709.63254,1224658.0919 499675.28084,1224664.2479 499721.56584,1224673.1624 499747.57644,1224676.7094 499739.52814,1224676.916 499740.76654,1224692.459 499812.83074,1224668.6628 499811.81964,1224658.0339 499811.36804,1224630.597 499769.81704,1224627.078 499734.63704,1224622.024 499724.36664,1224616.0171 499712.16004,1224595.8521 499691.28704,1224573.8378 499685.40964,1224561.8108 499682.19864,1224555.2798 499681.92114,1224553.7247 499680.03974,1224549.0699 499678.79694,1224549.2472 499674.62264,1224550.0095 499656.68104,1224534.9948 499656.04304,1224527.759 499655.73564,1224525.1614 499651.95204,1224525.556 499642.66424,1224526.0666 499630.64754,1224527.1273 499605.67644,1224502.1236 499604.61414,1224503.1844 499579.64304,1224478.1807 499578.58064,1224479.2415 499553.60954,1224466.8676 499553.08384,1224458.2316 499552.71694,1224454.6943 499541.79814,1224454.9879 499534.88804,1224450.0691 499527.35404,1224431.6821 499499.19104,1224417.7948 499486.96474,1224416.8351 499484.88504,1224410.5131 499470.72264,1224410.1876 499470.02924,1224409.5706 499468.87504,1224408.8795 499467.76364,1224408.658 499467.43914,1224405.783 499463.31414,1224405.2422 499462.57484,1224404.4119 499461.56314,1224404.1681 499461.29034,1224397.5431 499454.00904,1224397.4215 499453.87654,1224386.8436 499442.45874,1224379.5284 499434.45384,1224369.2823 499422.31714,1224369.0369 499422.03184,1224368.1423 499421.07654,1224367.1869 499420.18194,1224366.6558 499419.73214,1224355.8777 499410.92434,1224341.2698 499396.04914,1224341.1422 499395.92044,1224329.9105 499384.68884,1224324.2636 499378.59734,1224302.9088 499332.37814,1224392.4667 499355.14934,1224393.122 499355.91874,1224487.2901 499450.78514,1224496.2156 499459.77684,1224493.9911 499462.52154,1224506.465 499484.35254,1224564.6899 499528.85044,1224605.2731 499587.61344,1224614.2741 499599.88254,1224625.0241 499614.53564,1224653.1386 499652.85784,1224658.315 499659.91354,1224667.3321 499683.31754,1224673.7804 499721.97084)) point 0 is the se corner of the bow tie. point 1 is the "knot" of the bow-tie, and you will see it reappear as point 4. the triangle made up of points 1, 2, 3, 4 is the one I mentioned previously that goes in the wrong direction. I must confess to a slight simplification in my previous e-mails; the bow tie is not quite perfectly formed; it's southeast corner has been trimmed off so that the eastern "triangle" is actually a quadrilateral. Sorry :D Martin Davis wrote: > Chris, > > Can you post the WKT for the problematic feature? (Ascii art is > nifty, but not really a substitute for a 1600x1200 pixel display... 8^) > > Chris Hermansen wrote: >> Hi Nicolas, all; >> >> Nicolas, I understand your comment. But after looking at the data some >> more in OpenJump, that appears to not be my problem. >> >> If I load the PostGIS theme into OpenJump and run the QA on it, I see >> that it is the polygon that contains the bow-tie shaped figure that is >> the problem. >> >> I can represent this schematically as: >> >> +-----------------+ >> | | >> | |><| >> | | >> +-----------------+ >> >> (again, I hope this works out visually. I have done the figure in >> fixed-width text). >> >> OpenJump's QA tool shows that there is an error in the enclosing polygon >> at the "bow-tie point", and that the enclosing polygon is a bad feature. >> >> The triangle polygons themselves are not shown as bad features. There >> are points shown at all corners of the triangles, ie there is no real >> "bow-tie" type self intersection. >> >> The enclosing polygon contains all the edges shown in the above figure, >> including those of the triangles. Each triangle is a separate polygon. >> >> I've traced the order of the edges of the enclosing polygon and it >> appears that it is the ordering of these edges that is creating the >> crossing / bow-tie in the enclosing polygon. That is, the enclosing >> polygon's points define the edges as follows: >> >> pt 0: se corner of east triangle >> pt 1: bow-tie point >> pt 2: nw corner of west triangle >> pt 3: sw corner of west triangle >> pt 4: bow-tie point >> pt 5: ne corner of east triangle >> ... and off to the remainder of the enclosing polygon points >> >> So it appears to me that the edges of the western triangle are actually >> traversed in the wrong order in the enclosing polygon. As well, clearly >> there is a self-intersection in the enclosing polygon. >> >> I conclude from this that the order of traversal of the western triangle >> edges could be reversed and preserve the clockwise traversal of the >> enclosing polygon's edges. However I think the fact that the bow-tie >> point is traversed twice in the same polygon is a real problem that must >> be repaired (manually in this case, I guess). >> >> Does anyone have any comments on this? Thanks in advance! >> >> Nicolas Ribot wrote: >> >>>> Good people; >>>> >>>> I have this odd problem that I hope others may clarify for me. >>>> >>>> I have a big ArcInfo polygon coverage produced by a sequence of >>>> spatial >>>> unions. One of the component polygon coverages was brutalized >>>> somewhere >>>> along the way and it has some polygons with triangular and bow-tie >>>> inclusions. >>>> >>>> Nevertheless, the coverage is clean and sober as far as ArcInfo is >>>> concerned. >>>> >>>> If you all can picture in your minds a bow-tie polygon |><| where the >>>> rightmost | of the bowtie is actually the edge of an enclosing >>>> polygon, kind >>>> of like: >>>> >>>> | >>>> |><| >>>> | >>>> >>>> (I sure hope that works out visually...) >>>> >>>> OK, when I use ogr2ogr to import this coverage into postgis 1.3.1 / >>>> geos-3.0.0rc4, I see the following: >>>> >>>> >>>> >>>> the containing polygon fails at st_isValid() >>>> the st_area() of the containing polygon appears to include the area >>>> of the >>>> bow-tie polygon, ie it is larger than the area copied over from the >>>> ArcInfo >>>> coverage by about the same amount as the area of the bow-tie >>>> polygon When I >>>> look at this little mess with OpenJump, sure enough the QA routines >>>> find the >>>> bow-tie and complain. >>>> >>>> The long and the short of this is that PostGIS returns slightly >>>> more area >>>> than ArcInfo does for the same big ugly polygon coverage, because >>>> of the >>>> apparent loss of these bow ties. >>>> >>>> What I'm not sure about is what exactly is wrong here. Is the >>>> bow-tie >>>> shape itself illegal? Or is it the fact that both sides of the >>>> bow-tie >>>> belong to the same polygon? Or something else I'm missing? >>>> >>>> Thanks for any light anyone can shed on this. >>>> >>>> >>>> >>> Hi, >>> I will only give a partial answer: >>> yes, a bowtie polygon is invalid for PostGIS (as stated in the OGC >>> SFSQL documentation, polygon's boundary cannot cross itself). >>> If you want to represent this with valid polygons, you will need 2 >>> triangles touching at one point. >>> >>> HTH >>> nicolas >>> _______________________________________________ >>> postgis-users mailing list >>> postgis-users@postgis.refractions.net >>> http://postgis.refractions.net/mailman/listinfo/postgis-users >>> >> >> >> > -- Regards, Chris Hermansen · mailto:[EMAIL PROTECTED] tel:+1.604.714.2878 · fax:+1.604.733.0631 Timberline Natural Resource Group · http://www.timberline.ca 401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5 C'est ma façon de parler. _______________________________________________ postgis-users mailing list postgis-users@postgis.refractions.net http://postgis.refractions.net/mailman/listinfo/postgis-users
