Skip to main content
Question

Reprojected geometry turn into spikes in multipatch output.

  • September 26, 2016
  • 6 replies
  • 17 views
G
Forum|alt.badge.img

Problem 1

  • Reading a sample of a city 3D-model multipatch EPSG:3008
  • Reprojector [EPSG:3008 -> EPSG:4326]
  • Inspector gives:

The output of the inspector is a bundle of spikes. Zooming in alot gives the picture above. Note the extents looks just fine (the buildings should be ~15 m in height)

  • Completing by writing to multipatch class gives the same result.

Problem 2

  • Creator [a box 100 x 100 meter]
  • 3D-rotator [10 degrees with custom axis from a box corner ]
  • Reprojector [EPSG:3008 -> EPSG:4326]

     

    • Inspector [ nice output! ]
  • Writing to multipatch

     

    • Inspect [bad output! Same kind of spikes as in Problem 1]

Research

  • ArcGIS "reproject" also gives the spikes, thats why I tried problem 2 to eliminate errors in the data.
  • GeometryValidator does not seem to help me (tried repairing the nonplanar-surfaces and duplicate consecutive points in 3D)
  • WARN |Reprojector: Vertex normals removed due to errors reprojecting from '_SWEREF-99-13-30_0' to 'EPSG:4326'. This appear in Problem 1 but not in problem 2.

So basically im aware there might be errors in my data, but atleast I would like to understand why I am failing on problem 2..

Thank you for any advice!

6 replies

zzupljanin
Contributor
Forum|alt.badge.img+4
  • zzupljaninContributor
  • Contributor
  • September 26, 2016

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.

G
Forum|alt.badge.img
  • giskis
  • Author
  • September 26, 2016
zzupljanin wrote:

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..

 

 

zzupljanin
Contributor
Forum|alt.badge.img+4
  • zzupljaninContributor
  • Contributor
  • September 26, 2016
giskis wrote:
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
G
Forum|alt.badge.img
  • giskis
  • Author
  • September 26, 2016
zzupljanin wrote:
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
mark2atsafe
Safer
Forum|alt.badge.img+44
  • mark2atsafeSafer
  • Safer
  • September 26, 2016

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.

G
Forum|alt.badge.img
  • giskis
  • Author
  • September 27, 2016
mark2atsafe wrote:

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..

 

 

Reply


Helpful Members This Week

Community Stats

31,180
Posts
118,181
Replies
38,791
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.