Opened 7 years ago
Closed 7 years ago
#3818 closed defect (fixed)
Triangle WKT importer checks the M dimension to determine if the triangle is closed. Other geometyr types don't
Reported by: | rouault | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.3.4 |
Component: | postgis | Version: | 2.3.x |
Keywords: | Cc: |
Description
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
Note:
See TracTickets
for help on using tickets.
In 15833: