Something new has cropped up in the mapping sites which I have just noticed - not a mapping error as such, but a formatting issue.
With the latest Google Maps API version, used by the SMP and many other sites, the standard map controls have very recently (in the past couple of hours!) suddenly been increased in size. This change has been introduced by Google without prior notice, in an effort to accommodate users of mapping sites who access those sites using mobile devices of various sorts featuring touch-screens. The larger standard controls are apparently easier to activate with the fingers, which is no bad thing in itself. However, the SMP was - rightly or wrongly - never designed to be used on small devices like mobile phones, so there is little sense in keeping such changes in the SMP.
This change has the unfortunate knock-on effect of breaking the conformity between the standard map controls and those created by developers, of which there are several in the SMP mapping pages. A solution to this issue is available to the SMP, but involves a combination of writing patches to developer code and extra styling rules. This solution is now in the process of being tested and should be implemented within the next few days.
Fortunately, with so many developers around the world using the Google Maps API, solutions can often be found for most problems encountered while using the API, and such is the case here. Somewhat surprising is the fact that the solution to this particular problem is supplied by Google themselves.
I blame this DevOps nonsense Rob. One time designs were prototyped, tested, beta tested and rolled out when the consequences were understood. Now people have a Scrum and any old code gets pushed out to the live servers for alpha testing by the users and tough if there are consequences because it’s latest buzz method of development.
Now raining in Fuerteventura, which is OK because I flying out in a few hours.
Well I don’t know anything about DevOps, but to be fair to the folks at Google, they do have a legitimate reason for pushing some kind of change to address problems people have been having with trying to use maps, and controls in the maps, based on their code.
Having said that, I find it disappointing that they have not even bothered to offer a simple solution to this problem to those who may not wish to use the new, big-scale styling in their sites. I’m not alone in this view.
Even in the solution styling code which Google provide, there’s no provision for dealing with different screen sizes, and hence different mobile platforms; something which I’ll be addressing in the code which will eventually be implemented in the SMP.
It’s business as usual at Google: they’re so big, they can easily afford to offend one half of the planet’s population: the other half will stay blithely ignorant of, and happy with, anything the Big G can throw at them.
So, I notice that many people are having problems with sotamaps today, in that the map does not appear to load at all.
Unfortunately, this is beyond my powers to fix: the SMP runs these days on a server run, and paid for, by the SOTA MT, and where I have no admin rights. In addition, the sotamaps.org web-address is nowadays registered in the name of MT IT group leader Andrew VK3ARR, and sotamaps <=> Google Maps connectivity is also managed by him, so enquiries concerning this issue should be directed to Andrew, or to the MT IT group.
Sorry for rattling your cage Rob with a PM when the problem is out of your hands. I didn’t know that. I’m sure Andrew or one of the MT IT guys will see this and look into it when they can.
Nothing to do with access levels. Everything to do with Google deciding that my account suddenly looks bogus for no real reason. I will have to go through a convoluted process to verify my identity with them. Not sure how long this will take. Might be easier just to drop Google support - it’s getting to be far too much trouble at this rate since their recent changes to API management.
Well, we DID have two(?) accounts, one temporary, one not, and it would seem that one of them had been considered no longer valid by Google - as far as my understanding of the matter is concerned.
I myself have an account with Google for my iotamaps.org site, and I’ve had no trouble with that - once Google had stopped playing silly beggars with accounts a couple of months ago, that is. Fingers crossed it stays that way…
And rewriting sotamaps code to use a different mapping engine would entail a LOT of work (which I am simply not prepared to do), and would mean we would lose a lot of functionality presently enjoyed by the SMP.
Well, for matters involving Google connectivity, Andrew is the man to contact, and this was a Google Maps connectivity issue. That is to say, all of the SMP mapping pages were affected, but the non-mapping pages were not affected.
For anything else in the SMP which involves coding problems (usually evidenced by one of the pages not working properly), then I’m (still) your contact point. If in any doubt, contact both of us, either by PM or here in this thread. Or rattle my cage, as you so eloquently put it.
I’m curious to know what information the iotamaps.org site provided which wasn’t already generally known - I mean, IOTA is a ham radio award scheme for islands, while SOTA is an award scheme for summits. If you don’t want to use this (sotamaps) thread to reply, you could PM me.
Rob,
By looking at the IOTA references on the map I realised that clusters of islands share a common reference, unlike SOTA where each summit has a unique reference. I had not known that before. Also, I looked at Brunei and found it has its own IOTA reference rather than sharing a common island reference with eastern Malaysian states Sabah and Sarawak, and the Indonesian state of Kalimantan. So the island of Borneo that contains all those various states including Brunei, has multiple IOTA references. All stuff I didn’t know, mainly because of not looking at IOTA. That’s all.
Andrew VK1DA/VK2UH
