[postgis-tickets] [PostGIS] #3818: Triangle WKT importer checks the M dimension to determine if the triangle is closed. Other geometyr types don't

[PostGIS]

#3818: Triangle WKT importer checks the M dimension to determine if the triangle
is closed. Other geometyr types don't
---------------------+---------------------------
 Reporter:  rouault  |      Owner:  pramsey
     Type:  defect   |     Status:  new
 Priority:  medium   |  Milestone:  PostGIS 2.3.4
Component:  postgis  |    Version:  2.3.x
 Keywords:           |
---------------------+---------------------------
 select 'TRIANGLE M ((0 0 0, 5 10 0, 10 0 0, 0 0 1))'::geometry; -- fails
 whereas
 select 'POLYGON M ((0 0 0, 5 10 0, 10 0 0, 0 0 1))'::geometry; -- succeeds

 Full discussion extract from IRC:
 {{{
 [12:41] <EvenR> strk: I see that st_isclosed(st_geomfromtext('LINESTRING
 ZM(0 0 0 0,0 0 0 1)')) returns True. Do you know if it is on purpose that
 ST_IsClosed() ignores the M component. I think that makes sense.
 OGR_G_IsClosed() currently check all X,Y,Z,M which cause isses when
 importing some shapefiles where the M component of the last point is
 different than the first point (which is somehow logical)
 [12:47] <strk> I don't know if it's intentional. anything in docs about it
 ? and how about OGC standards ? (I tihnk IsClosed is defined there)
 [12:47] <strk> check also Z, is Z also ignored ?
 [12:47] <EvenR> Z is taken into account
 [12:47] <strk> I know for sure that for topology we want to ignore, maybe
 there's custom code there to avoid ST_IsClosed for specifically that
 [12:49] <strk> if (FLAGS_GET_Z(line->flags)) return
 ptarray_is_closed_3d(line->points);
 [12:49] <strk> return ptarray_is_closed_2d(line->points);
 [12:49] <strk> we also have ptarray_is_closed, checking *all* dimensions
 [12:50] <EvenR> https://postgis.net/docs/ST_IsClosed.html doesn't talk
 about the M componeent.     SQL/MM part 3 says that ST_IsClosed()   <==>
 ST_Boundary().ST_IsEmpty()
 [12:50] <sigq> Title: ST_IsClosed (at postgis.net)
 [12:50] <strk> but it seems to be ony used by the TIN parser
 [12:51] <strk> defined by boundary, ouch
 [12:51] <EvenR> yes I can't really make sense of that definition
 [12:51] <strk> I usually do the contrary: empty boundary is for closed
 lines
 [12:52] <strk> what's a line's boundary ?
 [12:52] <strk> the endpoints
 [12:52] <strk> a closed line has no endpoint
 [12:52] <strk> it does have them only for the purpose of defining it
 (structurally)
 [12:52] <strk> but not topologically
 [12:52] <EvenR> ok I see
 [12:52] <strk> M doesn't really fit in topology
 [12:52] <EvenR> doesn't really help with the M stuff. But the M dimension
 is a hack
 [12:53] <strk> it's really just for adding more info on the *structure*,
 not the topology
 [12:53] <strk> so I'd say it's ok to disreguard M for ST_IsClosed
 [12:53] <EvenR> ok thanks. I don't want to annoy you more on this.
 Probably that I'll align OGR_G_IsClosed() on PostGIS ST_IsClosed()
 behaviour (so ignoring M as well)
 [12:53] <strk> as it is a topological check (but then I guess
 documentation should be clear on this fact)
 [12:54] <strk> now I dunno if hte Triangle (not TIN, I was wrong) parser
 is intentionally checking M
 [12:54] <strk> but it sounds like an inconsistency
 }}}

 Perhaps the doc of ST_IsClosed() should mention the M dimension is ignored
 too

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3818>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.