Skip to main content
Solved

Converting component 'x' from type 'Real64' to 'Int32' - should I care?

  • November 20, 2019
  • 3 replies
  • 136 views
maphew
Forum|alt.badge.img

I'm reading and writing LAS files. There are warnings in the log files about X,Y,Z and being converted from Real64 to int32. How do I tell (with confidence) if this is important? Are the numbers being changed in a way that meaningfully changes the result?

LAS writer: Converting component 'x' from type 'Real64' to 'Int32'.  If this conversion is undesired, consider changing the type explicitly
LAS writer: Converting component 'y' from type 'Real64' to 'Int32'.  If this conversion is undesired, consider changing the type explicitly
LAS writer: Converting component 'z' from type 'Real64' to 'Int32'.  If this conversion is undesired, consider changing the type explicitly

https://knowledge.safe.com/questions/47749/combine-tilling-and-compress-las-files-without-con.html has a recipe for counter-acting the conversion, but it's not clear to me if that is needed. That discussion links to another page that says only int32 supported in the output format. If that's the case then why go through the extra work? 

I guess the question behind the question is: why is FME using Real64 at all if it's not supported?

ArcMap considers the points identical.

ArcMap before and after overlay of a LAS point. View scale 1:0.13. Distance from center to exterior of symbol is 0.006 meters. No measurable difference in point position.

 

0684Q00000ArCDTQA3.png

Best answer by dmitribagh

hi @maphew,

I don't think you should worry about this conversion. The coordinates are stored as int32 in LAS, but there is also scaling in the header, so you'll get the numbers you need at the end despite the conversion. We just warn that this conversion is happening.

FME itself supports real64 and there are other formats that support this data type. We don't want to limit FME to int32 only just because LAS was designed this way.

I hope this helps.

Dmitri

 

 

 

View original
Did this help you find an answer to your question?

3 replies

dmitribagh
Safer
Forum|alt.badge.img+15
  • dmitribaghSafer
  • Safer
  • Best Answer
  • November 26, 2019

hi @maphew,

I don't think you should worry about this conversion. The coordinates are stored as int32 in LAS, but there is also scaling in the header, so you'll get the numbers you need at the end despite the conversion. We just warn that this conversion is happening.

FME itself supports real64 and there are other formats that support this data type. We don't want to limit FME to int32 only just because LAS was designed this way.

I hope this helps.

Dmitri

 

 

 

maphew
Forum|alt.badge.img
  • maphew
  • Author
  • November 26, 2019
dmitribagh wrote:

hi @maphew,

I don't think you should worry about this conversion. The coordinates are stored as int32 in LAS, but there is also scaling in the header, so you'll get the numbers you need at the end despite the conversion. We just warn that this conversion is happening.

FME itself supports real64 and there are other formats that support this data type. We don't want to limit FME to int32 only just because LAS was designed this way.

I hope this helps.

Dmitri

 

 

 

Thanks Dimitri.

An info message class would be better than warning in this instance. I spent a few hours trying to figure out what I should do about the warning. (A KB document explaining would have helped too.)

jackzhang
  • jackzhang
  • April 20, 2021

Thank Dimitri for the answer. I agree with Maphew it would be better to have the message class change from warning to info.

Reply


Most helpful members this week

Community Stats

30,851
Posts
116,965
Replies
38,682
Members
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.