hcarter333 / rm-rbn-history

Mapping reverse beacon spots and QSOs of the Rockmite 20 at KD0FNR
0 stars 0 forks source link

Add Feature to dump .csv files as kml #13

Open hcarter333 opened 1 year ago

hcarter333 commented 1 year ago

Add featuer so maps can be overlaid on Google Earth by loadin in the KML file. Use the formatting examples at http://dagik.org/kml_intro/E/line.html as a guide

hcarter333 commented 1 year ago

First prototype up and running image

hcarter333 commented 1 year ago

The first prototype of the script has been included in qso_spot_kml.py

which is called from qso_kml.py

hcarter333 commented 1 year ago

There appears to be a bug in Google Earth??? The spot linestrings (blue lines, from the RBN network in this case) are origined at two different points in Africa:

earth_error

Here's the detailed view of the two origins: image

This does not happen with the same kml file in Google's MyMaps(project specific map): image

My initial hypothesis is that this might be related to QSO coordinates containing a different number of decimal points of precision compared to the spotting coordinates:

QSO:

-106.578838,32.382328,-111.714101266416,40.2823153730325,2023/01/30 16:21,0,14058.3,KJ7BES

RBN spot:

-106.556812, 32.373049,-94.6250,38.6458,2023/01/30 09:41:00,5,14058.3,AC0C-1
hcarter333 commented 1 year ago

I separated the QSOs into their own file only_qsos.csv

and the spots into their own file: only_spots.csv

The spots were still incorrectly anchored in Africa: image

Meanwhile, MyMaps was still fine: image

hcarter333 commented 1 year ago

The next hypothesis by the unschooling gang here was that the power level being 0 in the case of QSOs might be causing the issue. The power levels don't carry through to the kml files, but because they are used in the color selection for the kml linestrings, they could in fact be the issue. The spot linstrings were modified to have a power of 0: only_spots_all_zeros.csv

The result was the same in both Google Earth (still broken) and MyMaps(still working) with the exception that the spot lines were now green. image

hcarter333 commented 1 year ago

The unschooling gang's next hypothesis, (I now had THREE extra sets of eyes on the problem), was that there the sepcific coordinates of the QSOs might work while the coordinates of the spots for some reason did not. To test this we placed a single spot in a file and modified its coordinats to match those of a qso: only_one_spots_all_zeros.csv

only_one_qsos.csv

We were down to a single incorrect mapping, but it was still incorrect. (We also noticed there was an equitorial line that did not correspond to any of the linestrings, but can be seen in some of the other results above. image

MyMaps still worked correctly.

hcarter333 commented 1 year ago

At this point we noticed that the QSOs had no spaces after their coordinate commas:

-106.578838,32.382328,-90.3550100117382,41.4721178800016,2023/01/30 10:43,0,14058.3,NN9K

but the spot linestrings did:

-106.578838, 32.382328,-90.3550100117382,41.4721178800016,2023/01/30 09:15:00,0,14058.3,VE6JY

(Notice the space after the comma following the first coordinate(-106.578838)

We removed the space. At that point, Google Earth mapped the linestring correctly: image

A quick review of the two kml files (generated from .csv files with and without the space) reveals that the space was propagated through and is the only difference: image

hcarter333 commented 1 year ago

The end results once the leading spaces had been removed: image

This shows the paths through the passes and notches to various other stations: image

We can also see really illustrative things like this image