CGAL users discussion list

[chrism <>]

I have a set of points in UTM and lat/long coordinates that represent the
vertices of a triangle mesh located on the surface of the earth. I need to
calculate a unit normal to this triangle, and so use the CGAL::unit_normal
function.

With UTM coordinates this works as expected.

With lat/long/elevation the wrong answer is produced:

(-119.452959304302,54.727712609640498,888) 
(-119.27352872835201,54.731184848162897,820) 
(-119.369047730614,55.029360094556502,678) 

If I scale the x,y by 100 000, it then works correctly:

(-11945295.9304302,5472771.26096405,888)
(-11927352.8728352,5473118.4848162895,820)
(-11936904.7730614,5502936.0094556501,678)

Strangely: without this scaling, paraview is unable to render the mesh
properly (same issue?). 

If I plot these point sets in Wolfram Alpha, the problem is apparent: the
non-scaled produces a plane that is vertical instead of horizontal. 

works
https://www.wolframalpha.com/input/?i=plane+through+(-11945295.9304302,5472771.26096405,888)+(-11927352.8728352,5473118.4848162895,820)+(-11936904.7730614,5502936.0094556501,678)
broken
https://www.wolframalpha.com/input/?i=plane+through+(-119.452959304302,54.727712609640498,888)+(-119.27352872835201,54.731184848162897,820)+(-119.369047730614,55.029360094556502,678)

I am using an Exact_predicates_inexact_constructions_kernel. 

I have tried with the exact constructions, but it doesn't seem to allow me
to use it alongside the inexact?When I call the unit_normal function, I get 

/usr/include/CGAL/Kernel/function_objects.h:1879:17: error: no match for
‘operator/’ (operand types are
‘CGAL::CommonKernelFunctors::Construct_unit_normal_3<CGAL::Simple_cartesian&lt;CGAL::Gmpq>
>::Vector_3 {aka CGAL::Vector_3<CGAL::Simple_cartesian&lt;CGAL::Gmpq> >}’
and ‘CGAL::Null_functor::result_type {aka CGAL::Null_tag}’)
       res = res / CGAL::sqrt(res.squared_length());

Any ideas what is causing the unit normal to be so incorrect? I'm guessing a
numeric issue, but I'm not really sure where? Is there a way around this?
It's a one off computation so can take the hit of exact constructions if
that a) solves it and b) is used along side the inexact. 



--
View this message in context: 
http://cgal-discuss.949826.n4.nabble.com/Wrong-unit-normal-with-CGAL-unit-normal-tp4662261.html
Sent from the cgal-discuss mailing list archive at Nabble.com.