KML import problem and rounding problem

[neoraptor]

Hello,

I actually have 2 (small) issues with your software :
Issue 1 : KML import
I noticed that when I import a kml file with negative latitude, it is imported "mirrored". It looks like when importing, it does not process correctly the negative latitude.
Could you check your import routine?

Here is a sample :
* import a datalog from a track that has negative coordinates
* export it to kml (see image 1)
* reimport it to kml > track is mirrored (see image 2)

If we look to GMaps, the original data is correct (image 1).

Image 1 :


Image 2 :



I didn't check with negative longitude, but you also may have problems there.




Issue 2 : rounding problems
If I import long logs from DLog99, it seems there is some rounding problem (I imported 0.16kph > displayed 0.15092kph).
It doesn't appear with shorter logs.


I have the same problems with AEM Data software.
If you need any other informations, feel free to ask.
Thanks for the support

[RickS]

I have alerted our developers to this issue. I know that there is a 'Invert Sensor' option for this when logging but unsure how an imported file could be handled.

I'll post here when I get some more info.
BR
RickS

[RickS]

Development have found a bug in the KML Import code and a fix is in test. It will be rolled out in the next version. When you say 'import a datalog', is this a CSV import and not a download of an .STF file..?

You can change the number of displayed decimal places in the channel properties if it is not what you want it to be (right click the channel in the channel list, select "Channel Properties").

You can do this on multiple channels at once by selecting them all in the channel list.

Thanks for the heads-up.

RickS

[neoraptor]

Hi Ricks,
Thank you for the news !! That is great !

Concerning the import, it is the CSV import function from DLog99 (maybe not supported anymore).
As I only have the standard version, I can't see if the same error is present in the GDA import function.

[RickS]

I think this rounding issue stems fom the fact that STF files have historically used either 8 or 16 bit integers to represent values. Importing from CSV, we would need to convert the floating point values into full range integers (i.e. in the range 0 to 65536) and calculate scaling factors to normalize those values back to the original. This process of going to an integer and back again can cause rounding errors.

If you have a wide range of values then you are more likely to get scaling errors.

Starting at GDA Pro version 4.0.46, you can import floating point numbers and double precision floating point numbers - which are stored as such in the STF file. In many cases this would resolve that issue but, as we know, GDA Pro is licenced.
Alternatively the latest version of GDA Pro allows you to specify the integer range over which values are scaled to avoid unwanted fractional values.

As a test, if you would send a copy of the CSV file to tech (dot) support (at) gems.co.uk mail address, we could try an import on this latest version to see if the outcome is different.

The development guys had already started to find ways to improve the auto decimal places calculation at some point. They will revisit this soon.

BR
RickS