W6/CC summits have reversed lat&long in the su

Old Reflector
1

Hi,

I was playing with creating a Google Maps mashup of all of the SOTA summits, but discovered something odd: it looks like that, in the summits.csv file downloaded from http://www.sotadata.org.uk/summitslist.csv, the latitude and longitude columns are swapped for all of the W6/CC summits. Other W6 summits seem fine; it’s just the W6/CC summits.

An example:

SummitCode,AssociationName,RegionName,SummitName,AltM,AltFt,GridRef1,GridRef2,Longitude,Latitude,Points,BonusPoints,ValidFrom,ValidTo,ActivationCount,ActivationDate,ActivationCall
…]
W6/CC-075,USA,Coastal Ranges,Mt. Livermore,238,781,37.8613157,-122.4319164,37.8613,-122.4319,1,0,01/07/2009,31/12/2099,0,
W6/CD-001,USA,Desert Ranges,White Mtn. Peak,4342,14246,37.6343734,-118.2556656,-118.2557,37.6344,10,3,01/07/2009,31/12/2099,1,08/08/2010,N6VDR,

The Longitude column is after the GridRef2 column, and the Latitude column is after the Longitude column (and before the Points column). For the W6/CD-001 row, things look right – but the W6/CC-075 row puts the latitude in the longitude column and the longitude in the latitude column. This is the case for all of the W6/CC summits.

What needs to be done to get this fixed?

Thanks & 73
-chris N2YYZ

2

In reply to N2YYZ:
Hi Chris, do you know there`s already a kmz file of all SOTA summits created & updated by Martyn M1MAJ. From the reflector message:-

Post by M1MAJ on 2nd July 2010 at 11:02
I have just done another update to my Google Earth visualisation. The KML file has now become too large for Yahoo, so I have repackaged it as a KMZ file which is much smaller. It should download into Google Earth in exactly the same way; if for any reason this doesn’t work you can rename it as summits.zip and extract the embedded summits.kml file using anything that handles zip archives.

As a consequence of the compression, I have been able to reinstate the copy on summitsbase. So the download URLs are now:

and

http://www.summitsbase.org.uk/tiki-download_file.php?fileId=204

This new version includes all of the summits currently in the database, and also incorporates over a thousand corrections of my own. (I will report the database errors to the MT in due course).

73 G1INK.

3

In reply to G1INK:
Yup, I’m familiar with the KMZ file.

The version I was working on runs entirely in your web browser, and doesn’t require Google Earth.

4

In reply to G1INK:

The MT is already aware of issues with the database, but it will be invaluable to have a crosscheck. Many of the errors will have to be corrected one at a time which will take a lot of time.

Cross-over of lat. and long. creeps up on us rather easily. The convention for a very long time (well over a century) is that lat. comes first (being directly measurable) followed by long. (which is inferred), but computer people and mathematicians say that the X axis comes before the Y axis, and as computer people make databases they have their way. The trouble is that lat. first is a learned reflex that has to be fought, so errors creep in. Well, that’s my interpretation, anyway! :slight_smile:

The MT are always glad to have errors pointed out so that in due course they can be corrected, but it is best to send them direct to the MT as members of the MT are more likely to read their common email server than the reflector (well, except for me, its my job!)

73

Brian G8ADD

5

In reply to G8ADD:
Brian: thanks. I’ve contacted the management team through the form on sota.org.uk.

73
-chris N2YYZ

6

In reply to N2YYZ:

the latitude and longitude
columns are swapped for all of the W6/CC summits.

This is one of the systematic errors which I routinely correct before I generate my KMZ file. I’m in communication with Andy about them and I’m sure they’ll get sorted when he has time (I know he’s very busy at the moment).

This one is actually rather easy to correct (a single SQL UPDATE statement will do it) but it obviously needs some care to get right. Some of the others will be a bit more fiddly.

7

In reply to M1MAJ:
Thanks for the reply.

The tool I was using to generate my Maps mashup (http://bit.ly/bse2aQ) has some support for importing KML files; I’ll try out some of the ‘fixed’ files once I have some more free time…

73
-chris N2YYZ

8

In reply to N2YYZ:

In cases such as these, it may be best to contact the Association Manager as recommended in all of the US Association Reference Manuals. In the case of the W6 association, these errors were discovered and noted to the MT a while ago. I am sure that the MT is both busy and competent, and patiently await correction. Repeatedly calling attention to the same problems could distract the MT from the tasks at hand.

Thanks for your concern. Stu

9

In reply to KI6J:
Stu,

Thanks. I wasn’t aware these errors had been previously noted to the MT.

-chris N2YYZ

10

In reply to N2YYZ:
Further investigation reveals that these W6/CC errors are in fact NOT on my hit list. I was conflating in my mind two different problems I’d observed: some W7 summits with feet and metres swapped (which is now fixed) and some SV summits with lat and long swapped.

One of the reasons I didn’t spot these is that Google Earth behaves bizarrely when given latitude values >90 or <-90. Rather than just appearing the wrong place, the pins seem to warp off somewhere invisible. I suppose this is understandable, but it’s annoying that there’s no diagnostic.

I’m sure they were right once… I presume some mass update broke them.

I’ll add another tweak shortly and re-release the KMZ file. I should also put a sanity check in the conversion script.

11

Yes, all was correct until the database crash last April. While you are at it, please correct the CC region seasonal bonus. The database is incorrectly adding a Summer season bonus. There is no seasonal bonus in the CC region.

Thanks Chris for the kick start. I guess I was waiting too patiently.

12

In reply to KI6J:
I’ve generated a new KMZ file with W6/CC corrected. Also I’ve fixed 3 HL summits with invalid longitude (looks like the decimal point was dropped on data entry). Downloadable from the usual places.

While you are at it, please correct the CC region seasonal bonus.

That’s not a field which is relevant for my purposes, so there’s no point in fixing it in my copy. That one really does need to be fed through official channels.