They have more in common with the Min and Max Extents in the Feature Information window than down below where the geometry coordinates are. Should I expect the indices to align with the existing coordinates? Do aggregates change how the CoordinateExtactor works? It is really mystifying. Any insight is appreciated.
Solved
CoordinateExtractor Questions: I am using the coordinate extractor on a large amount of 3D wireframe wall shape aggregates. When I look at the indices, not only are they not in the same order as the FME geometry, but they are completely differen
+8- Contributor
- 46 replies
Best answer by virtualcitymatt
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
So when reading from Revit there are two options to choose as to where the geometries should be relative to.
I think the issue here is that the Geometry you see in the Feature Information window is not the real geometry - the extracted coordinate and bounds reflect the real geometry.
Storing geometry with a transformation matrix can be faster than applying the transformation to the coordinates. For example, when in Revit and you model something, if you copy and paste a group of objects instead of calculating all the coordinates, Revit might be choosing instead to just track the movements you make of the objects.
If you want to apply the transformation matricies to the data (get rid of them) you can reproject the data and then reproject it back.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+63- Celebrity
- 1625 replies
Say you have a line that is an aggregate feature of three lines (red, green and blue).
These lines are all topologically valid (each line that touches shares the same vertex). Notice how the blue line is drawn in a different direction to the red and the green.
Now the order that these lines are in the aggregate feature is blue, green red. Because of that, when you look at the order of the vertices, the very first vertice is the start of the blue line (where it touches read), the vertices then extend along the blue line till the end of it. The next vertice is the start of the green line (where it touches red), the vertices then extend along the green line till the end of it. We now move to the last part of the aggregate which is the red line. The next vertice is the start of the red line (where it touches the blue line) the vertices then continue along till the end of the red line (where it touches the green line)
+8- Contributor
- 46 replies
Say you have a line that is an aggregate feature of three lines (red, green and blue).
These lines are all topologically valid (each line that touches shares the same vertex). Notice how the blue line is drawn in a different direction to the red and the green.
Now the order that these lines are in the aggregate feature is blue, green red. Because of that, when you look at the order of the vertices, the very first vertice is the start of the blue line (where it touches read), the vertices then extend along the blue line till the end of it. The next vertice is the start of the green line (where it touches red), the vertices then extend along the green line till the end of it. We now move to the last part of the aggregate which is the red line. The next vertice is the start of the red line (where it touches the blue line) the vertices then continue along till the end of the red line (where it touches the green line)
Hi @[hkingsbury], that makes sense.
What doesn't make sense is that the extracted coordinates of these features show values that are completely different than the actual geometry coordinates. Also, the min and max extents are more in the range of the extracted coordinates rather than the geometry.
My workspace up to this point is only attribute filters and an exposer, nothing that transforms. I have attached a spreadsheet comparing the extracted vs FME Geometry coordinates, and also a text file of the entire Feature Information as it occurs.
I noticed this behavior when trying to do a clipper with door and wall geometries, the doors were floating at the top of the walls. I had grouped everything by floor level. Weird, no?
Here are some screens shots of the Workspace and Visual Preview:
The red circles are where I got the Feature info and the output for visual preview, respectively.
The selected wall is the feature in the attachments, only flattened and extruded using the bounds as a base. _zmax -_zmin = Extrusion distance.
+8- Contributor
- 46 replies
Hi @[hkingsbury], that makes sense.
What doesn't make sense is that the extracted coordinates of these features show values that are completely different than the actual geometry coordinates. Also, the min and max extents are more in the range of the extracted coordinates rather than the geometry.
My workspace up to this point is only attribute filters and an exposer, nothing that transforms. I have attached a spreadsheet comparing the extracted vs FME Geometry coordinates, and also a text file of the entire Feature Information as it occurs.
I noticed this behavior when trying to do a clipper with door and wall geometries, the doors were floating at the top of the walls. I had grouped everything by floor level. Weird, no?
Here are some screens shots of the Workspace and Visual Preview:
The red circles are where I got the Feature info and the output for visual preview, respectively.
The selected wall is the feature in the attachments, only flattened and extruded using the bounds as a base. _zmax -_zmin = Extrusion distance.
Can't put two attachments in the same posting, I guess...
+63- Celebrity
- 1625 replies
I'm not quite following, are you able to share the data/workbench? Can you run it locally with feature caching and save it as a template (with feature cache saved) and share it here?
Also ccing in @dmitribagh and @virtualcitymatt as they're much more clued up with BIM/Solids than I am
+8- Contributor
- 46 replies
I'm not quite following, are you able to share the data/workbench? Can you run it locally with feature caching and save it as a template (with feature cache saved) and share it here?
Also ccing in @dmitribagh and @virtualcitymatt as they're much more clued up with BIM/Solids than I am
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
+47- Celebrity
- 2000 replies
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
Here in your screen shot you can see that a transformation matrix is getting applied to the geometry. When you extract the coordinates (or get the bounds) FME will apply the transformation matrix to each coordinate giving it it's 'real' location. In this case the transformation matrix shifts the whole block down by 20 meters. This is why the bounds is 0 but the coordinates of the geometry is 20.
+8- Contributor
- 46 replies
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
Hi @virtualcitymatt,
I see what you mean. Good catch. Now the question is: Why is my geometry being transformed? It looks like the Revit Reader is doing this.
What use is the extents properties and extracted coordinates if they don’t align with the “real” geometry? Is this some kind of coordinate system “correction “? I just want accurate data from the model.
I’ve found 4 legit bugs in the last month. Is this #5??
+47- Celebrity
- 2000 replies
- Best Answer
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
So when reading from Revit there are two options to choose as to where the geometries should be relative to.
I think the issue here is that the Geometry you see in the Feature Information window is not the real geometry - the extracted coordinate and bounds reflect the real geometry.
Storing geometry with a transformation matrix can be faster than applying the transformation to the coordinates. For example, when in Revit and you model something, if you copy and paste a group of objects instead of calculating all the coordinates, Revit might be choosing instead to just track the movements you make of the objects.
If you want to apply the transformation matricies to the data (get rid of them) you can reproject the data and then reproject it back.
+8- Contributor
- 46 replies
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
Hi @virtualcitymatt ,
I checked a few other models that are part of the project and Z is at 0.00, which is what the extracted coordinates are! My hunch is that the models use the georeferenced coordinate system instead of project. I will verify with the model I am reading into FME which will take around a 1/2 to 1 hour to load, so I will thank you now and circle back to confirm.
Best,
Loren
+8- Contributor
- 46 replies
I can't share the data as is because it is sensitive and the file is huge. I'll find a way to send a pared-down version. What I am trying to understand is why the extracted coordinates are completely different than the FME geometry coordinates that it is supposed to extract. It seems like the coordinate extractor is looking at the wrong data. Sorry it's hard to explain. I was hoping the files I sent would show that difference.
Here is another screenshot taken from the Revit Reader. Maybe it's a Revit Reader issue? Notice the min/max extents have nothing to do with the geometry coordinates. It seems to have ignored the floor height:
After loading the model into FME, it seems that not everything was transformed and is random. I was able to reproject by daisy-chaining two Reprojectors to two different coordinate systems, then through a coordinate system remover, which seemed to work.
This model could not be opened in Revit, so it makes sense things were all jacked up. This was a good lesson in recognizing strange behavior in a Revit file!