Hello,
thanks again for the Facets plugin.
I am using the csv and shp files exports for making calculations. I noticed the following:
- the $Surface field is the same in .csv and .shp, with same min/mean/max/sum
- the properties related to the bounding rectangle, $Horiz_ext; $Vert_ext; and $Surf_ext,are not the same in .csv and .shp, and vary depending on the normal orientation chosen for the export of the .shp (I tried with a specified orientation and the mean orientation)
I would have thought the properties of the bounding rectangle are calculated in Cloudcompare prior to the export. Are the value exported in the .csv the "good" ones, measured in 3D regardless of the point of view?
Also, it would be great to export the perimeter of each facet (length of the border of the planes) as well as the $Surface. I can calculate it in qGIS, but it would depend on the point of view of the export, and would loose the 3D component of the data.
Thanks,
Cecile
FYI: geological application is the calculation of the P21 parameter, the (sum of the length of fracture borders / area of outcrop), which is important for generating fracture models. I am trying to use the output of Facet directly for calculating this parameter. The alternatives I thought of involve a few fudge factors that I would rather avoid.
qFacets: Error in the export of the geometry of the bounding rectangle?
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
A bit late, but I just saw this post:
http://www.danielgm.net/cc/forum/viewto ... 1400#p6451 with exports of shape files in 2D geometry rather than 3D. Sorry if it is in fact the same question. I am still confused by the difference in values of the fields in the .shp though.
I'm testing your latest post on exports to .obj and see if it does the trick for me.
Cecile
http://www.danielgm.net/cc/forum/viewto ... 1400#p6451 with exports of shape files in 2D geometry rather than 3D. Sorry if it is in fact the same question. I am still confused by the difference in values of the fields in the .shp though.
I'm testing your latest post on exports to .obj and see if it does the trick for me.
Cecile
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
Hi Cecile,
Most of the values are computed on the fly, at the time of export. But indeed, while the CSV file considers the facets in 3D, the SHP export tool considers them in 2D (this is why it asks about the projection normal). However if you use the 'native orientation', I believe all (or most?) of the parameters should be equivalent.
At the time we developed the plugin (with Thomas Dewez), it seemed that most GIS tools where mostly considering 2D entities. We should add an option to export the polygons in 3D. I'll add this (and the perimeter) to the TODO list.
Most of the values are computed on the fly, at the time of export. But indeed, while the CSV file considers the facets in 3D, the SHP export tool considers them in 2D (this is why it asks about the projection normal). However if you use the 'native orientation', I believe all (or most?) of the parameters should be equivalent.
At the time we developed the plugin (with Thomas Dewez), it seemed that most GIS tools where mostly considering 2D entities. We should add an option to export the polygons in 3D. I'll add this (and the perimeter) to the TODO list.
Daniel, CloudCompare admin
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
Hi Daniel,
thanks for this helpful and rapid answer. Indeed, the "native orientation" keeps all the parameters equivalent. However, it is not super useful to visualise the parameters in GIS when the outcrop is vertical, which is why I use other projection directions.
just to clarify, is it correct that:
- the Surf_ext is the "surface of the bounding rectangle in the facet plane", measured in 3D for the .csv, but on the 2D projected facet plane in the .shp file
- Horiz_ext and Vert_Ext are the lengths in vertical and horizontal directions (and not the long and short axis length) of the bounding rectangle, also calculated in the 3D facet plane for the .csv, and on the 2D projected facet plane in the .shp
- "Surface" is the area of the individual facet measured in 3D and is not projected
I ended up getting the perimeter of the polygons in qGIS using shp files exported in the most "front" view possible and limit 3D effects (my outcrop is basically vertical). Good enough until having the option to export the perimeter field measured in 3D :)
Thanks
Cecile
thanks for this helpful and rapid answer. Indeed, the "native orientation" keeps all the parameters equivalent. However, it is not super useful to visualise the parameters in GIS when the outcrop is vertical, which is why I use other projection directions.
just to clarify, is it correct that:
- the Surf_ext is the "surface of the bounding rectangle in the facet plane", measured in 3D for the .csv, but on the 2D projected facet plane in the .shp file
- Horiz_ext and Vert_Ext are the lengths in vertical and horizontal directions (and not the long and short axis length) of the bounding rectangle, also calculated in the 3D facet plane for the .csv, and on the 2D projected facet plane in the .shp
- "Surface" is the area of the individual facet measured in 3D and is not projected
I ended up getting the perimeter of the polygons in qGIS using shp files exported in the most "front" view possible and limit 3D effects (my outcrop is basically vertical). Good enough until having the option to export the perimeter field measured in 3D :)
Thanks
Cecile
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
Indeed:
- horiz_ext and vert_ext are computed on the '2D' facet (projected along the specified normal - which is the facet normal itself when exporting to CSV or using the 'native' option). It's basically the dimensions of the (2D) bounding box of the facet.
- surf_ext = horiz_ext * vert_ext
- surf is indeed the facet (polygon) surface
Daniel, CloudCompare admin
-
- Posts: 1
- Joined: Sat Aug 19, 2023 2:06 am
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
Hello,
thanks again for the Facets plugin.
I am using csv and shp file export for calculation. I noticed the following:
I was thinking that the properties of the bounding rectangle are calculated in Cloudcompare before exporting. Is the value exported in .csv a "good" value, measured in 3D regardless of the point of view?
Also it would be nice to export the perimeter of each face (lengths of the contours of the planes) as well as $Surface. I can calculate it in qGIS, but it will depend on the export point of view and will lose the 3D component of the data.
Thank,
thanks again for the Facets plugin.
I am using csv and shp file export for calculation. I noticed the following:
I was thinking that the properties of the bounding rectangle are calculated in Cloudcompare before exporting. Is the value exported in .csv a "good" value, measured in 3D regardless of the point of view?
Also it would be nice to export the perimeter of each face (lengths of the contours of the planes) as well as $Surface. I can calculate it in qGIS, but it will depend on the export point of view and will lose the 3D component of the data.
Thank,
Re: qFacets: Error in the export of the geometry of the bounding rectangle?
Yes, these parameters should be computed in 3D (in the facet plane).
And yes, I guess it's possible to add these metrics (even though the perimeter might not be very accurate, as it will highly depend on the noisiness of the contour extraction). I'll add it to the TODO list.
And yes, I guess it's possible to add these metrics (even though the perimeter might not be very accurate, as it will highly depend on the noisiness of the contour extraction). I'll add it to the TODO list.
Daniel, CloudCompare admin