BUG: copying features and attributes quality?

sjf

Hi,

Is this a BUG?

I have a large LAS file with points. I select and copy a set of points based on GPStime code (12345678.123456).

I paste this set in a new GM instance: all is well.

BUT now the GPS time is limited to 12345678.123 - How do I make sure that all data is copied? Am I doing something wrong or do I have to set something to the correct quality level? Or is this a BUG or limitation?

Cheers

Stefan

BMG_Amanda

Howdy Stephan,

This seems to be an oddly intermittent bug. I've added this to the queue as item #GM-12972.

For more timely responses and updates on the ticket please feel free to email the tech team at geohelp@bluemarblegeo.com

sjf

yes seems intermittent because sometimes is only .123 of sometimes it is none!

maybe there is a relation with a windwos copy and paste setting?

cheers

Stefan

sjf

I did some tests but it remains strange: large sets seem to copy OK others do not copy well.

There might also be a relation if you select via select digitiser tool or select via area select tool

Maybe you could see if you could ad: copy alt C for copying full precision?

I really need this!

Do I have to open a new instance of GM for pasting or can I paste in the same instance?

Stefan

BMG_Amanda

Hi Stefan,

You can paste in the same instance of GM, you can even paste the data back into its original layer.

I couldn't see a predictable pattern between selection tools, we'll have to wait and see what the Dev team thinks.

sjf

Ok I will wait! Yes unpredicatibity is a challenge.

sjf

Hi there,

Any update on this BUG yet?

For me this is a critical BUG and I would like to receive at least a workaround to save a subset of a LIDAR LAS file without loosing the GPS timestamp markers. This attribute is the unique point indicator and I need all 7 digits behind the comma.

Maybe saving as points from a (querry) selected subset?

(I have a lidar set of about 7 to 14 million points and need to extract the individual scans (about 850 points per scan - 5000 per second over 5 - 15 second experiments) this will be scripted.

But the data integrity of the GPS timestamp is vital. If there is any alternative to keep this unchanged I would be happy.

(paste in an empty layer with set accuracy maybe?)

bmg_mike

I'm looking at this now. The GPS timestamp is copied as a full double precision value and nothing is lost. This is just an issue with the formatting precision displayed when the double precision value is converted to text.

How this works is that the smallest time delta between points is calculated when a point cloud is loaded. That is used to determine the precision to use when displaying the time stamp. So when you copy a sub-set of the point cloud to a new layer, if those points are sparse, that minimum time delta might end up being much larger than it was in the original data, so the times end up displayed with a smaller precision.

I'll see what I can do to make this precision be maintained when a subset is used, or at least use a minimum of 3 decimal places.

Thanks,

Mike

Global Mapper Guru

geohelp@bluemarblegeo.com

bmg_mike

I have updated this logic so that no matter what at least 4 digits of precision will be shown. In cases where the time offsets are not consistent (i.e. a cut-and-paste of a subset), additional precision will be used.

There will be a new daily build tomorrow at https://www.bluemarblegeo.com/products/global-mapper-daily-builds.php with this fix for v23.0.x.

Thanks,

Mike

Global Mapper Guru

geohelp@bluemarblegeo.com

sjf

thanks!!

It's been a long time, and still enjoy your fast response as always!

Will update tomorrow.

cheers

Stefan

bmg_mike

I also made it so that the Configuration dialog option on General -> Measure / Units to 'Display Extra Precision' will add 3 decimal digits to the reported GPS Time, so you can now force more digits if you want. This change will be in the daily build as well.

Thanks,

Mike

Global Mapper Guru

geohelp@bluemarblegeo.com

sjf

great! You're the best. Thanks

Stefan

sjf

it is fixed now! Thanks!

sjf

yes: and it is fixed also because some other issues played up.

thanks Stefan