Plotting map for activation?

Online Resources
41

The code largely predates SSO integration, but it is all a bit vague. I haven’t looked into it sufficiently to suggest a solution. I do know that SMP maintains a location table which is populated from various sources unknown

1 Like
42

Well, I don’t think I will search the web for that one :slight_smile:
73,
Rod

1 Like
43

Top Google hit looks like something Viki would browse - but hide her cards first.

1 Like
44

Somebody buy something from there so they can pay their model and she can buy herself a square meal. There’s more meat on a butcher’s pencil than on that female model.

1 Like
45

The same problem is happening again. I have discovered that not only the S2S QSOs are not being displayed on the map, but the S2S QSOs are not even listed in the log at the left side of the screen:
This is my actual log:

imagen
imagen1150×237 91.1 KB

And this is what I have now on the SMP Activation map page:
imagen

You can see that the S2S QSOs with HB9AGO/P, CT7/K9PM/P and HB9AFH/P are missing.

It looks like it’s a temporary problem and it’s happening when the No year-chart data message is displayed.

73,

Guru

1 Like
46

Hi Rod

Oddly for our QSO yesterday the map now shows you in IO82pa
Go figure …

Rick

1 Like
47

Try it again.
73,
Rod

1 Like
48

I have been having a play with Adventure Radio Log Analyzer 3.2. My typical workflow for logging is as follows:

  1. I use Fast Log Entry to transpose my paper log. This generates a SOTA CSV import file and an ADIF file. It can also upload to eqsl and lotw directly, and I tend to use these three facilities.

  2. In order to get semi-accurate mapping I need to ensure that their is either a SOTA reference for /P stations S2S or for other /P or /M stations a Maidenhead Locator. I try and ask for these when I can, otherwise a general location like a town is enough to look one up. These can be added to the Fast Log Entry source file as a hash-string such as #IO84ni. Better accuracy would be achieved if a contest reference could be used directly: SOTA, WOTA, HEMA, COTA, LOTA etc. The SOTA Mapping software knows about SOTA references, but not others.

  3. For mapping I have two options at the moment: SOTA Mapping or Adventure Radio Log Analyzer 3.2.

  4. I run my own custom post-processor on the ADIF file generated by Fast Log Entry. This is a java program that looks for keywords in the comment section of the ADIF file. For example, if the comment string contains: <OP: John, QTH: Leominster> the post-processor picks these up and sets the op name in the ADIF file and the QTH in the ADIF file accordingly. I can also specify <GRID: IO84NI> but this does the same thing as entering it direct in a line.

  5. I upload my ADIF activation file to qrz.com.

  6. I then export my total ADIF log file and cut out the activation entries. The upload process fills in some fields which are useful for mapping.

  7. Yes, this is a protracted process!

My observations of the two systems based on the following sample Fast Log Entry extract of my G/LD-003 activation yesterday:

image

I’ll be looking at mapping for the following entries:

Geoff GM4WHA/M has a grid locator specified of #IO84ix, this is the ADIF record:

<app_qrzlog_logid:9>645735829
<app_qrzlog_status:1>N
<band:2>2M
<band_rx:2>2M
<call:8>GM4WHA/M
<cont:2>EU
<country:8>Scotland
<cqz:2>14
<dxcc:3>279
<freq:6>145.55
<freq_rx:6>145.55
<gridsquare:6>IO84ix
<ituz:2>27
<lat:11>S000 00.000
<lon:11>W000 00.000
<mode:2>FM
<my_city:10>Windermere
<my_country:7>England
<my_cq_zone:2>14
<my_gridsquare:6>IO84lm
<my_itu_zone:2>27
<my_lat:11>N054 22.259
<my_lon:11>W002 54.595
<my_name:12>Mark Wickens
<operator:5>M0NOM
<qrzcom_qso_upload_date:8>20210619
<qrzcom_qso_upload_status:1>Y
<qsl_rcvd:1>N
<qsl_sent:1>N
<qso_date:8>20210619
<qso_date_off:8>20210619
<rst_rcvd:2>52
<rst_sent:2>59
<station_callsign:7>M0NOM/P
<time_off:4>0854
<time_on:4>0854
<eor>

Note that the <gridsquare:6>IO84ix is specified, but there is no corresponding entry in <lat:11> or <lon:11> - this is not ideal, and highlights a limitation when rendering via SOTA mapping.

SOTA Activator G1RKV/P on G/LD-024:

<app_qrzlog_logid:9>645735824
<app_qrzlog_status:1>N
<band:2>2M
<band_rx:2>2M
<call:7>G1RVK/P
<comment:14>SOTA: G/LD-024
<cont:2>EU
<country:7>England
<cqz:2>14
<dxcc:3>223
<freq:6>145.55
<freq_rx:6>145.55
<ituz:2>27
<lat:11>S000 00.000
<lon:11>W000 00.000
<mode:2>FM
<my_city:10>Windermere
<my_country:7>England
<my_cq_zone:2>14
<my_gridsquare:6>IO84lm
<my_itu_zone:2>27
<my_lat:11>N054 22.259
<my_lon:11>W002 54.595
<my_name:12>Mark Wickens
<operator:5>M0NOM
<qrzcom_qso_upload_date:8>20210619
<qrzcom_qso_upload_status:1>Y
<qsl_rcvd:1>N
<qsl_sent:1>N
<qso_date:8>20210619
<qso_date_off:8>20210619
<rst_rcvd:2>59
<rst_sent:2>59
<station_callsign:7>M0NOM/P
<time_off:4>0850
<time_on:4>0850
<eor>

SOTA Mapping

SOTA Mapping does an excellent job of locating SOTA activators, but doesn’t pick up the maidenhead locators for other /P or /M operators.

Here is an example, we have GM4WHA/M in the sample, this is how SOTA Mapping deals with that:

image
image1136×736 313 KB

So where has locator IO85hr come from? Remember that I have used the SOTA CSV export functionality of Fast Log Entry to upload the file to the SOTA database, so there will be no reference to my overriden /M gridsquare IO84ix. I don’t know how SOTA Mapping derives IO85hr from GM4WHA/M.

For SOTA activators clearly the SOTA Mapping is spot on. Here is the mapping for G1RKV/P on G/LD-024:

image
image958×728 180 KB

And for my summit location on G/LD-003:

image
image1047×747 264 KB

Adventure Radio Log Analyzer 3.2

Here is the mapping for G1RKV/P on G/LD-024:

image
image801×734 250 KB

So, definitely not putting G1RKV/P on G/LD-024 as can be seen.

Further, because my Maidenhead locator is being used for my location, rather than the summit reference G/LD-003 I’m off the summit for this mapping too:

image
image1108×820 331 KB

Conclusions

It looks like there are issues with both systems. I think the only way to tackle this, whilst still using mapping, is to do the following:

  1. Update my post-processor to recognize various contest logging references, off hand we have SOTA, WOTA, HEMA and WWFF as a minimum, possibly also COTA (Castles on the Air) and LOTA (Lighthouses on the Air).

  2. or upload the log file to a Logging Application that knows about contest references.

  3. The contest reference should be translated into a Latitude and Longitude value in the ADIF file.

  4. Use Adventure Radio Log Analyzer 3.2 to plot the results. I think with Latitude and Longitude specified it would do a good job.

Another advantage of Adventure Radio Log Analyser is that it has the facility to provide interactive maps. You have to upload your log file onto a server that can serve the file via a http: reference.

So for example for the Helvellyn activation G/LD-003 I have uploaded the ADIF to my wickensonline server:

http://qsomap.adventureradio.de/mapsanalysis.php?adi=https://wickensonline.co.uk/static/adif/2021-06-19-Helvellyn-G_LD-003.adi&m=3&stn=on&xmylocator=IO84lm&m=5

Work in progress…

2 Likes
49

It can probably be made aware if you PM me through a list of where the references are, with no SLAs on when it gets implemented :slight_smile:

1 Like
50

Qrz.com.

There’s also the possibility of FLE exporting the overridden grid as a QRA entry in the comments, like you would do for a microwave award entry (I think the format is %QRA%IO81AA%)

1 Like
51

So, I found the relevant details - it’s basically just pulling from QRZ but at some point Rob’s commented out the cronjob. It appears I’ve run it manually about 2 years back, but I can’t remember why: it’s as likely to be that I was fixing a similar issue as I just accidentally cut/paste the wrong link from the crontab. I’ve re-run it manually again, and it updated 101 records.

Now, I no doubt need to factor in the next stage which is SSO integration to pull from user profiles.

1 Like
52

Yap, Log Analyzer puts stations in the centre of their six-digit grid locator.

Ahoi
Pom

1 Like