<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>The same applies to a rectangle - 5 points stored instead of 4 - so where do we draw the line? <br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>How many vertices must a polygon have before we follow the spec & explicitly close it?</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>I agree that the closing vertex is redundant, & can be replaced by a bit in the header - but by doing so we lose the
ability to test for is it REALLY closed, rather than just saying it is closed, perhaps less important for triangles, but a capability I'm reluctant to lose.</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>And as a general principle, I think dealing with polygons differently, depending on the number of vertices, is a road to be avoided. Any change should be considered at the standard level, and implemented in the application if the standard is changed. I would not like to see arbitrary changes from the standard just because :-)<br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color:
transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span>Brent Wood<br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: times new roman,new york,times,serif; background-color: transparent; font-style: normal;"><span> <br></span></div><div><br></div> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"> <div dir="ltr"> <hr size="1"> <font face="Arial" size="2"> <b><span style="font-weight:bold;">From:</span></b> Olivier Courtin <olivier.courtin@oslandia.com><br> <b><span style="font-weight: bold;">To:</span></b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org>; Mateusz Loskot <mateusz@loskot.net> <br> <b><span
style="font-weight: bold;">Sent:</span></b> Monday, December 2, 2013 10:50 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [postgis-devel] OGC TIN of triangles or polygons?<br> </font> </div> <div class="y_msg_container"><br><br>On Nov 28, 2013, at 12:55 PM, Mateusz Loskot wrote:<br><br>Hi Mateusz,<br><br>> """<br>> A Triangle is a polygon with 3 distinct, non-collinear vertices<br>> """<br>> <br>> If a triangle must have exactly 3 points and all points must be distinct,<br>> as I interpret what the space says above, why PostGIS generates 4 points?<br>> <br>> Attempt to parse WKT with 3-point triangles, as OGC specifies:<br>> <br>> TIN (((0 0, 0 1, 1 0)), ((0 1, 1 1, 1 0)))<br>> <br>> generates:<br>> <br>> ERROR: triangle must have exactly 4 points<br>> <br>> Is that right?<br><br><br><br>Triangle is a surface in OGC SFS 1.2 model.<br>And so closing coordinates are required. (cf
6.1.11.1 in SFS 1.2 common part)<br><br>So it's imply (as i understand it) 3 coordinates points and 1 more to close it (so 4)<br><br><br><br>One other discussion could be, is it really smart to store the closing point for a TRIANGLE ?<br>(and not to just use a is_closed flag, in geometry header for instance)<br>As it could lead to save significant storage space.<br><br><br>> Is it my misunderstanding or from an implementer point,<br>> OGC SFS 1.2.1 is inconsistent in regard to specification of TIN,<br>> triangle and polygon and use of those types in the WKT/WKB formats.<br>> And, the buggy WKBTIN format in the OGC SFS 1.2.1 should be corrected this way:<br>> <br>> WKBTIN {<br>> byte byteOrder;<br>> static uint32 wkbType = 17;<br>> uint32 numTriangles;<br>> WKBTriangle triangles[numTriangles]<br>> }<br><br><br>I agree, <br>and, as you seen, it was implemented in PostGIS in this way.<br><br>On the other side, never spend
time/energy to interact with OGC WG to clean it up/clarify it.<br>Worth to check it in coming OGC SFS standard.<br><br><br>O.<br>_______________________________________________<br>postgis-devel mailing list<br><a ymailto="mailto:postgis-devel@lists.osgeo.org" href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-devel</a><br><br><br></div> </div> </div> </div></body></html>