Timeline for How to Fix Inconsistent Data Conversions in SFCGAL Expressions
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 2, 2018 at 11:21 | comment | added | John Powell | Ignore me. I have checked ST_SnapToGrid and it works on PolygonZ, but not on Polyhedral Surfaces or TINs. So, you would have to dump all the sides, snap them, and reassemble. There must be a better way. | |
| May 2, 2018 at 9:08 | comment | added | John Powell | There is one other possible approach to your problem with is ST_SnapToGrid. In Geos, there is a similar error about self-intersections and the like that is caused by arbitrary and spurious precision (16 decimal places, kind of thing) and can be solved using this function. I haven't investigated too far with the 3D functionality yet, but it is conceivable it might help. I have seen errors like yours when doing intersections of cylinders, and extruded buildings for line of sight purposes. Please let me know if you solve this problem. | |
| May 2, 2018 at 6:30 | comment | added | John Powell | Yes, I am working on similar problems, and have also found some of the issues you describe. It might be worth posting to Postgis or sfcgal list, as there aren't many people on here with 3d Postgis experience yet. | |
| May 2, 2018 at 3:45 | comment | added | craigL | Thanks for this, it's a plausible explanation that the problem is in the ordering of sides. The difficulty though is that the cube is only a simple example to try to get it working. The larger objective is to conduct the spatial algebra on point clouds converted to meshes, so the geometries are potentially highly complex and don't have simple geometrical shapes. | |
| May 1, 2018 at 12:01 | history | edited | John Powell | CC BY-SA 3.0 |
added 110 characters in body
|
| May 1, 2018 at 10:22 | history | answered | John Powell | CC BY-SA 3.0 |