Yeah,
I had the same problem when I was working on my 3D City project (also writing to multipatch). Only I used older version of FME (assumed those bugs are solved in newer version, didn't ask any questions), and did some workround to get correct results.
For Problem 1 you could id every building (Counter), explode to vertices (Chopper), then reproject, then rebuild every building (by before mentioned ID) and write to multipatch. Only then there will be those nasty spikes from problem 2.
Workaround for spikes (Problem 2): >1% of buildings had those spikes (in my case). While creating multipatch I also wrote lowest and highest point of every building and wrote it as attributes (These are the real heights of buildings). Then I just created separate fmw (reader: multipatch) that also extracted lowest and highest point (those where possibly wrong heights of buildings) and just tested if real heights are as in heights of multipatch. If not then select problematic point of that building and put it on correct height.
Hope that was understendable.
But of course, a clarification why that occurs would be nice.
Yeah,
I had the same problem when I was working on my 3D City project (also writing to multipatch). Only I used older version of FME (assumed those bugs are solved in newer version, didn't ask any questions), and did some workround to get correct results.
For Problem 1 you could id every building (Counter), explode to vertices (Chopper), then reproject, then rebuild every building (by before mentioned ID) and write to multipatch. Only then there will be those nasty spikes from problem 2.
Workaround for spikes (Problem 2): >1% of buildings had those spikes (in my case). While creating multipatch I also wrote lowest and highest point of every building and wrote it as attributes (These are the real heights of buildings). Then I just created separate fmw (reader: multipatch) that also extracted lowest and highest point (those where possibly wrong heights of buildings) and just tested if real heights are as in heights of multipatch. If not then select problematic point of that building and put it on correct height.
Hope that was understendable.
But of course, a clarification why that occurs would be nice.
Interesting solution to problem 1. Thank you! For varous reasons Im still one FME 2016 beta. My geometries - after deaggregated/flattened/decomposed - are faces whom are not accepted by the chopper. I suspect coarsing them to polygons would make some of them corrupted (especially walls) which I would like to avoid..
Interesting solution to problem 1. Thank you! For varous reasons Im still one FME 2016 beta. My geometries - after deaggregated/flattened/decomposed - are faces whom are not accepted by the chopper. I suspect coarsing them to polygons would make some of them corrupted (especially walls) which I would like to avoid..
But it doeasn't have to. Because face is created from polygon (planar!!). So if we go by that you must get polygon (or elipse or donut). Of course, you never know, you can test it and see if input=output. good luck
But it doeasn't have to. Because face is created from polygon (planar!!). So if we go by that you must get polygon (or elipse or donut). Of course, you never know, you can test it and see if input=output. good luck
Thanks again, I did the coarsing an chopping now but unfortunately it didnt remove the spikeissue
I'm not expert in multipatch geometry, but... I do know that EPSG:4326
has units of decimal degrees. When I look at your screenshot it seems to
me that the X/Y coordinates put me in Helsingborg. But the Z values... I suspect they are meant to be in metres but I wonder if they are being interpreted as degrees?
I mean, the building is 0.000243176542395 wide by 0.000145461916524 deep, but 7.05 in height! No wonder they are long and thin and spiky!
I'd suggest, instead of using the Reprojector transformer, use the CSMapReprojector. This is the only reprojection transformer that will also help reproject Z values. Check out the parameters for vertical reprojection and see if they will help.
Vertical grids aren't installed by default with FME (because their file size is large and few people use them) but can be downloaded from a link on our downloads page.
I'm not expert in multipatch geometry, but... I do know that EPSG:4326
has units of decimal degrees. When I look at your screenshot it seems to
me that the X/Y coordinates put me in Helsingborg. But the Z values... I suspect they are meant to be in metres but I wonder if they are being interpreted as degrees?
I mean, the building is 0.000243176542395 wide by 0.000145461916524 deep, but 7.05 in height! No wonder they are long and thin and spiky!
I'd suggest, instead of using the Reprojector transformer, use the CSMapReprojector. This is the only reprojection transformer that will also help reproject Z values. Check out the parameters for vertical reprojection and see if they will help.
Vertical grids aren't installed by default with FME (because their file size is large and few people use them) but can be downloaded from a link on our downloads page.
Seems like they are interpreted as degrees indeed! Why would FME do that? I have never heard of a "heightitude". If I knew an approximate formula of "heightitude"-to-meters for my area I could use Z-scale in format settings. (A terrible ugly solution though)
No settings in CSmapReprojector/vertical seems to help. Im downloading the grids now so I get back if that helps.
Even after setting the feature class to vertical height system RH2000 (metric) the spikes remains both in inspector and ArcGIS..
