Uncorrect summit position

The great thing about standards are there are so many to choose from. You’re both right. Probably best the argument stops here :slight_smile:

No, they are not. One was established and the other introduced to yield confusing data and no advantage.
73,
Rod

Remarks like this from a member of the MT to drop a discussion when it’s being conducted in a civil manner between two SOTA participants (one of whom is actually the moderator of this very forum), is one of the reasons why I intend to cease having anything more to do with SOTA, and that at the earliest convenient opportunity.

…and with such a disparaging remark, belittling one or the other system, I find myself in the position of agreeing wholeheartedly with Andrew. Let this discussion move back on topic.

Sorry you feel that way Rob, but my position is not from a point of view of censorship but a point of view of this sort of debate is like vim vs emacs, or Icom vs Yaesu. You’re both right, the argument will continue as civilly as possible and nothing will be resolved in either direction.

Oh, and I have moderator privs too, so if I did feel like being a dictator, I could shut the thread, but you know that’s not my style - I’m the reasonable one on the MT :wink:

Whether anything is resolved or not, the discussion raises some interesting - some might say important - issues which any person viewing this thread may find illuminating.

As far as I’m personally concerned, I couldn’t care less which system is better, which is used (by whom), and so on. I simply find the discussion fruitful in that it may lead somebody to enquire further into the topic.

If anything, I’d side with @G8ADD Brian in saying that I’m personally more comfortable with “latitude” / “longitude” simply because it “sounds” or “feels” more “natural”. But I’m far too objective a person to let my own feelings obtrude into such a discussion :smirk: :alien: :older_man: :speaking_head: :nerd:

…and thank heaven for small mercies…

I’m sorry that you feel like that, Rob. From my point of view we were holding an enjoyable civilised and stimulating discussion exploring the pro’s and con’s of two co-existing co-ordinate systems that have some impact on SOTA but which most participants would not meet up with in the pursuit of points. Don’t go, we’d miss you!

Carry-on Rob. You’re doing a great job and SOTA would not be the same with your work. Criticism is good when it is constructive and conducive to promote progress. We all know it is not always the case. I have learnt to ignore such comments and carry on with the people willing to have a proper discussion.

I think there is saying along the lines of: “If you’re not p*****g somebody off then you’re not doing something worthy”.

2 Likes

I’d be interested in knowing where this notion that Google changed the convention comes from.

Google Maps URLs put latitude first, e.g:

https://www.google.co.uk/maps/place/Ben+Nevis/@56.7965633,-5.0074344,17z/data=!4m13!1m7!3m6!1s0x0:0x0!2zNTbCsDQ3JzQ4LjciTiA1wrAwMCcyMC43Ilc!3b1!8m2!3d56.7968571!4d-5.0057392!3m4!1s0x488932978af1e5f3:0x6e948b77ffad9a71!8m2!3d56.7968569!4d-5.0035503

and when displaying coordinates on screen they put latitude first.

Likewise Google Earth displays latitude first:

Maybe there are other contexts in which Google reverse them but it clearly isn’t universal. I haven’t noticed any.

Putting aside for a moment the observation that the error which started this thread was not a transposition error, I don’t think the long history of such mistakes in the SOTA ecosystem has anything to do with Google. Rather I think it stems from some very early design decisions.

Those who were around in the early days of SOTA will recall that the first database did not have lat/long coordinates at all. There was a single column “Gridref” which held a national grid reference, using either the British National Grid or the Irish Grid. There were no summits outside the British Isles, so that worked fine. It was clear that the positions were provided “for identification purposes”, and very little thought had been put into how that data might be used systematically for other purposes such as automated mapping or loading into GPS devices.

Then overseas associations came along. I believe it was assumed that other countries would use their own national grids, but it seems that most other countries either don’t have one or find it less deeply embedded in popular culture. Whatever the reason, it was apparent that most other places wanted to specify lat/long. It would have been entirely possible for both to have been encoded in a single string, but for some reason unknown to me the database was extended to two columns, Gridref1 and Gridref2. This would have been very sensible if somebody had specified which was which and how the values were to be encoded, but this was either not done or ignored. As far as I can make out each association just uploaded whatever it had to hand.

After a little while it was total chaos. G* and EI stuck with their national grids, and other associations used lat/long, but with a wide variety of formatting conventions. Not only the order varied, but also D.dddddd vs D M.mm vs D M S, use of NSEW vs (variant) sign conventions etc. Plus there were a fair number of typos.

The existing data columns were beyond redemption. But I wanted to do systematic processing. So I campaigned for two new columns to be introduced for latitude and logitude, and that they be declared to be WGS84 coordinates in decimal degrees with the standard GPS sign convention. As they were named columns, the notion of order did not arise. I can’t rememeber exactly how the conversion was done. I know that I provided approximate conversions of all of the British and Irish grid references, which is why to this day many of them are still a bit “off” - you will find that they are on a six figure grid reference alignment. (Others have subsequently been adjusted by the association manager). I might have helped with some of the other conversions; but somehow it got done.

I do not claim that this was a masterful insight and I’m sure it would have happened sooner or later regardless, but it is worth remembering that the pressure to have a consistent coordinate reference system came from the grass roots and was not an MT initiative. I recall having to push quite hard to make it happen as not everybody saw the need for it at the time.

It can be seen from the public export of the summits list that the legacy Gridref1 and Gridref2 still exist and remain populated, though I hope they are now largely disused.

What is not visible to me, of course, is the process which causes the database to be populated. I hear that spreadsheets are involved, which isn’t really a good sign. It is clear that in the early days the coordinates were merely for identification and not regarded as data that had to be validated. Some of the errors that still creep in suggest that to some degree this must still be true. Many errors that have reached the database would have been spotted by a simple check that -90<=lat<=90 and -180<long<=180. This picks up transposition errors on half of the planet, and scale errors caused by wrong decimal separators and the like.

Confusion about the order of latitude and longitude is likely to cause a whole association or region to be wrong. It’s quickly spotted and easily corrected. Errors in odd summits are more an indication of sloppy data processing techniques - e.g. manually transcribing figures rather than writing a script to convert what you have to what you need. I don’t think Google can be blamed for that.

Martyn M1MAJ

I don’t think that anybody will be surprised to learn that SOTA has evolved over the last fifteen years! It would be much more surprising if it hadn’t.

With regard to Google, when I raised objections in MT discussions to longitude going before latitude, I was told that it was to be compatible with Google Earth (I have just gone back and checked that this is what I was told) so I blamed Google, perhaps unjustly or so it seems!

I would hope that it’s fairly clear from the efforts I’ve been pushing and publicising in the IT Group update emails that we take improvement of these systems seriously and will be developing systems to do so. I have a number of ideas about removing the human-in-the-loop-causing-human-error element while retaining a final approval check of summits that come in, and have been successively refining these over time - the JA, ZL, FK, VO and several Latin American associations have directly benefited for initial (and ongoing) updates, as have a few updates to older European associations in recent times.

We just haven’t spoken much about those yet, as they are by no means complete, integrated or even as refined as I’d like them. The ultimate goal would be to move to a continuous integration model where summits are approved and automatically pushed live. We’re nowhere near that, but Simon and the summits team do a fantastic job already. The number of errors introduced versus the number of summits added in the last year is tiny compared to what they were in the early days, as you describe.

What I do hate is that some people assume the MT are comfortable with where SOTA is at and therefore are kicking back doing little work[1]. We know there are issues with both the data model and some of the systems that are in place. There’s a bunch of things that are done now that seem on the surface to be just a little insane, but exist because they are far better than what was there before, assuming there even was anything before.

We are looking at what we need to do with addressing those. The data model is probably the last thing we’ll touch; a man with your obvious knowledge in this area, Martin, will appreciate that, in the paraphrased words of Boromir, one does not simply modify a 14 year old data model :smiley: See other threads on IT Group Priorities for more information on what we are going to tackle this year instead.

Cheers,
Andrew

[1] As a personal example. it’s 25 past 11 at night, I’ve just worked a full day at work, done two late night conference calls, also for work, written a bunch of Providers for the upcoming Single Sign On system to handle some aspects of the SOTA infrastructure, checked about 100 new summits (of 500) for an upcoming partial update for the ZS association, thrown together this response and am now considering whether I tackle some infrastructure updates for Simon for two other associations that are also coming up for release, or follow my wife’s orders and go to sleep. It doesn’t feel like I’m kicking back doing nothing right now :smiley: