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

Change History (3)

comment:1 by pramsey, 7 years ago

In 15833:

Allow triangles unclosed in M to be parsed in WKT (References #3818)

comment:2 by pramsey, 7 years ago

In 15834:

Allow triangles unclosed in M to be WKT parsed (References #3818)

comment:3 by pramsey, 7 years ago

Resolution: fixed
Status: newclosed

In 15835:

Triangles un-closed in M should be WKT parseable (Closes #3818)

Note: See TracTickets for help on using tickets.