ST_Equals checks the x, y (not the z)

[tudorbarascu]

Just FYI, all the following return True, so maybe we shouldn't do ST_Equals(ST_Force2d.. in the data model and lose speed.

SELECT ST_Equals(ST_GeomFromText('POINT(100 100)'), ST_GeomFromText('POINT(100 100 1)'));
SELECT ST_Equals(ST_GeomFromText('POINT(100 100 0)'), ST_GeomFromText('POINT(100 100 1)'));
SELECT ST_Equals(ST_GeomFromText('LINESTRING(100 100 1, 200 200 2)'),  ST_GeomFromText('LINESTRING(100 100 3, 200 200 4)'));

Also interesting: https://postgis.net/docs/ST_Equals.html

[tudorbarascu]

Just thinking out loud, I think going 3d with the geometries was a mistake (guess mainly of the complexity which led to incompleted work in functions/triggers resulting in the data model letting errors like duplicate node to slip.. updates in altitude not propagated to Z or viceversa etc.).

[haubourg]

Hi, well, I tend to agree.. Le lun. 19 avr. 2021 à 09:35, Tudor Barascu ***@***.***> a écrit :

…

Just thinking out loud, I think going 3d with the geometries was a mistake (guess mainly of the complexity which led to incompleted work in functions/triggers resulting in the data model letting errors like duplicate node to slip.. updates in altitude not propagated to Z or viceversa etc.). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#331 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMN5HOAYBTSUXXDF2X2WATTJPMLRANCNFSM422SFZ5Q> .

[ponceta]

IMHO we should adress this as a postgis issue because

'POINT(100 100 0)' != 'POINT(100 100 1)'));

[lbartoletti]

ST_Equals is not referenced as supporting 3D : https://postgis.net/docs/manual-dev/PostGIS_Special_Functions_Index.html#PostGIS_3D_Functions.

BTW, I'm pretty sure this function use GEOS and GEOS doesn't support well Z/M.

But I agree that it should be more explicit in the documentation. If we can't push this in GEOS, can we propose this improvement in PostGIS?

[tudorbarascu]

From my point of view... we shouldn't have nodes in the same xy location (although the z differ). So for my use case ST_Equals fits the purpose.

My workaround for vertical pipes is to move the other nodes a cm in a random direction as it doesn't impact hydraullically.

The main issue is that in the current data model we're doing ST_Force2d and so on without any gains.

[ponceta]

If you feel st_force2d is used in vain and cost processing time (in the st_equal context), feel free to propose a removal proposition for this.

Removing useless complexity is always a +1 on my side.

[cymed]

What if you have 2 90° bends on top of each other? There are cases where 3D is needed