Hi Hugo, Thanks for the feedback.
On 03/17/2016 08:26 AM, Hugo Mercier wrote: > Hi Denis, > > On 07/12/2015 15:30, Denis Rouzaud wrote: >> Hi all, >> >> If I understand correctly, Postgis does not handle NULL altitude in 3D >> geomtries. > That's what I understand as well. > >> Hence, when using ST_Force3D, it sets the altitude to 0, which I find a >> bit inconvenient (and dangerous). > Could you explain why ? > The name of ST_Force3D is pretty clear for me: you are forcing the > geometry to change its type from 2D to 3D. And yes, a 3D geometry is > defined by its altitude. So if you know a geometry should be 3D but do > not know its altitude, it's not yet a real 3D object :) Well forcing 3d is exactly the point, to be sure that everything you get is in 3d including 2d objects. I find this dangerous because you'll be mixing unknown altitudes with 0 altitudes, and hence won't be able to distinguish them apart. > >> 1. Is there any ongoing or potential development towards handling null >> altitude in geometries or this is not feasible? >> >> 2. Do you have any good workaround? Like using -9999 and creating your >> own ST_Force3D? > My opinion is that it should be handled on the side of the application. > If you really want to store not-fully-defined 3D objects with postgis, > then yes you can use a special value that your application knows how to > deal with. My preferred approach would be that Postgis handle null altitudes natively. If not possible, I think a native Postgis function ST_Force3D(geom, null_value) would help. Anyway, doing it myself is not a big deal, but I think I'm not the only one dealing with this issue. Cheers, Denis
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/postgis-users