SMP range page update #3

There are a couple of new updates and additions to the SMP range page, driven mainly by user requests.

Road Route

It is now possible in the range page to define waypoints along a road route to force the Google Maps Directions service (which the SMP uses internally for routes-finding) to find a route between A and B, and which (hopefully!) will also pass through your waypoints. Typically, one would use this to try to avoid major highways and to try to find a route which might take a more scenic - albeit longer and “costlier” - route than the default quick-and-cheap main highway which Google Maps route would otherwise find.

The inclusion of this option was triggered by the following topic and question from David AE9Q:

I have to say that, though I tried for a long while over many days to get the directions service to come up with a route which followed the Blue Ridge Parkway along it’s entire length, even using waypoints, it became clear to me that the service is just not up to the job. Firstly, the route is loooong at over 400 miles in length; secondly, it is a narrow, winding tertiary route, and lastly that Google allows the user to pick only eight (8) points along the way (unless I, as developer, pay some $10k per year to permit the user a royal 23 waypoints!): far too few to permit the user to “tie down” the route over such a distance.

Nonetheless, the waypoints option can definitely be of use to those seeking to better define a shorter route along which summits should be found.

Another new feature in the range page road-route option is the ability to drag the line in the map representing the route to make it follow a new road or set of roads: after dragging the route, one can re-map the summits around the new route.

Again, when trying this with the Blue Ridge Parkway, the Google Maps Directions service refused to let the route follow the Parkway along most of its’ length, preferring nearby main or secondary highways to the Parkway: you can drag the route to the Parkway, but upon letting go of the dragged route, it just snaps back to the highways again. Somebody should contact Google and ask them why this is not possible…


This is a new feature, allowing the mapping of summits within a polygon which is defined by the user. The inclusion of this new feature was prompted by a PM which I received last week from an OM who wanted to be able to upload a set of points defining an area within which the 2017 solar eclipse on August 21 could be seen in totality in the US, and also within which SOTA summits could be found. This in order that SOTA summiteers could place themselves on summits in advance of the eclipse, and to make contacts during the eclipse.

So, a user can now choose “Polygon” as a range type, and can define a polygon on the map in one of two ways:

  • by clicking in the map at points which define the corners (vertices) of the polygon;
  • by entering a set of latitude/longitude coordinate pairs as points to define the corners (vertices) of the polygon.

A maximum of fifty (50) points may be defined using one or the other data-entry method. The vertices of the resulting polygon can at any time be dragged to a new position and, by clicking the “Map” button, the summits within the new polygon can be re-mapped

Once a polygon has been so defined, clicking the “Map” button will (again, hopefully!) show any SOTA summits which may be found within the confines of the polygon. Here’s a snapshot of a polygon defining the boundaries of totality during the August 2017 eclipse:

And, for those with a particular interest in the eclipse, here is an example set of points to be entered in the range page polygon-text entry field to define the area of eclipse totality:

45.32125, -125.09033
45.03471, -119.16870
44.59047, -114.49951
44.10337, -110.79712
43.31718, -106.27075
41.92680, -100.30518
40.68064, -96.05347
39.29180, -92.03247
37.70121, -88.02246
35.89795, -84.01245
33.93425, -80.03450
32.85190, -78.00293
31.63468, -78.00293
32.70411, -80.01343
34.70324, -84.01794
36.52067, -88.00323
38.15184, -92.00500
39.56971, -96.00128
40.79094, -100.00031
42.03297, -105.01556
42.99661, -110.01160
43.69965, -115.00488
44.17235, -120.00641
44.43378, -125.00519

OK, that’s definitely enough for now. Enjoy!



Looks good.

Can I report a minor issue? If I use the layers menu and turn off everything except summit markers then the display is as expected. If I change the magnification (using the mouse scroll wheel) or reposition the map then the region border and shaded area comes back. Enabling and disabling the region borders item removes the shading until the next zoom or move.

Firefox 50.1.0 on Linux Mint 17.3 Rosa (XFCE)

Aahhh - I haven’t yet checked the interoperability of these disparate elements - I’ll look into it.


Are you actually using the range page when you see/hide these areas?

Rob – I really appreciate all the functionality of the mapping pages. I’m just getting back into SOTA, and I’m using the mapping page a lot. I’m amazed at what the volunteer effort has produced; it’s impressive by any measure. de K7ZOO

1 Like

No, just a simple view of Southern Scotland Rob.

The different region views such as nearby regions are really useful when you are looking at somewhere new to visit. But I was figuring out the best order to tackle a few GM/SS summits and didn’t need it. I haven’t noticed anything else misbehaving with region views.

Well… this particular topic presents a report on recent developments in the SMP range page, so I was assuming the problems you had been experienced were the results of my having made the alterations to that page as mentioned above. Which was perplexing, since I couldn’t reproduce such errors in that page.

Can I now assume that this was not the case, and that the problems you report are to be found in another of the SMP pages? The main page, perhaps?

Details, please: you help me, then hopefully I can help you.



Thanks for the flowers - you’re welcome!


Rob thanks for the Polygon feature could it be used to define new summits that may have been missed by the mapping team. [Wayne and Me]
We have just a few such"possible" summits to prove one way or other in vk5 .
Ian vk5cz …

I don’t whether it’s a new issue or not Rob. I went to play with the range changes and the range polygon feature is a fine addition. I was able to define an irregular polygon around a set of roads in area I’ll be in a few weeks and it turned up loads of possibilities. It’s much easier than selecting regions by hand etc. or even multi region selections. It was after that I noticed the regions problem back on the main screen. You’ll know whether that is something that may have been introduced with these changes or not.

So main mapping page, select an assoc and region. By default you get the summit markers for the selected region, the region border (and shading) for the selected region, the region tooltip and the nearby regions shaded. From the layers icon dropdown, turn off region borders, region borders tooltips and nearby group borders. They all turn off and you see the map and the summit makers. Drag the map with the mouse and the region border and shading returns. Or you can alter the zoom and it returns. The layers icon dropdown is still open, so click region borders to turn it on (tick appears) and again to turn it off. The region border and shading disappears. As soon as you zoom or move, the region borders and shading comes back. It doesn’t matter whether the layers icon is open or closed.

As I said, I haven’t seen it before so maybe it was like this before these changes.

A good use of the polygon option in the range page, and one which I had not considered. Of course, when one is coding, the emphasis is on getting something to work - how it’s actually used is mostly down to the user.[quote=“MM0FMF, post:10, topic:14534”]
As soon as you zoom or move, the region borders and shading comes back. It doesn’t matter whether the layers icon is open or closed.

Yes, I thought I’d fixed all that a while ago, but as you say there was still a bug crawling around in the walls. Zapped it now, and in the process also discovered that the event-handler governing the visibility of the regions layer(s) boxes had been firing FIVE times at each zoom, pan, etc., so fixed that too.

So, it should be OK now,

This feature will only find those SOTA-registered summits which can fit inside a polygon on the map - it can’t identify any other summits. Of course, the local AM and associates could use it to identify hilly/mountainous areas within a polygon (state/county/park border?), but it would be up to them to properly research and identify any new summits for possible inclusion into the SOTA scheme.

So, no: it can’t perform the necessary research and identification work for you.


It’s a great addition. When you select multiple assocs/regions to look at somewhere new, you can end up with lots and lots of summits. That’s not an issue on this PC ( 4x i7 cores 8GB mem) or my home PC (8x i7 cores 8GB) but on my little travel PC (4x Atom 2GB mem) having lots of summits really slows down the display. That’s what you expect, a lower performance machine runs slower with lots of data to handle. With the polygon region, you can define a region that spans multiple assocs/regions but does not include all of them. The result is fewer summits and a much faster display on the travel PC.

It is. It is also noticeably faster when the various layers are selected as well.

Still using a 10-year old PC here (Win10) which has so little memory it’s a joke (or an 8-year old laptop with similar issues) - saving my pennies for a much better machine, but it’ll probably be summer/autumn this year before I can afford that.

To cap it all, the narrow-band internet access (600kB/sec download when I’m lucky) here just adds to the fun. NOT. Could be worse, though, mustn’t complain…

Another update to the range page in the SMP.

It is now possible to define a road route - around which SOTA summits should be found - in one of two ways:

  • Use Google Directions Service” - this is the original road-route option which allows the user to define a route by entering start- and end-points, plus optional waypoints, and the program will attempt to find one or more routes using the Google Directions Service internally. This option will already be familiar to some of you.

  • Define road route by choosing points from map - this second, new, method to define a road route uses the mouse to mark multiple points in the map, thereby creating a “route” on the map, along which SOTA summits may then be found. The point-markers can at any time be dragged to a new place; controls are provided for editing or deleting the markers or route. The route so defined does not actually need to follow a road or roads - it could follow any feature on the map: a border between two countries, for instance. Your route might also follow a series of roads which the Google Directions Service will not, or cannot, offer as suggestions for a road route - the picturesque Blue Ridge Parkway in the US being a perfect example.

Hopefully, this new option may prove to be of use to somebody out there…



Hi Rob

This will be very useful!

I will “publicize” this tool in the Portuguese SOTA Channels (site and FB) because its a great tool

Thank you!

Vy 73

Rob, looks like this bug or a derivative of this bug has returned.

  1. Select main mapping page
  2. select an association (ea8)
  3. Select region, ea8/la
  4. Select layers dropdown, turn off region borders, region borders tooltips, nearby group borders and close dropdown.

Onlthe summit markers are shown overlaying the map.

5 Select new region, say ea8/go. The page updates, the summit markers overlay the map but the region border is also drawn. If you click layers dropdown the region borders checkbox is definitely not selected.

You can get rid of the region border by selecting it in the dropdown and then deselecting it. When you deselect it then it is erased from the map.

Yes, I’ve recently (half-) noticed this as a side-issue while working to get the updated version of the SMP ready, and wondered what might have broken what I had fixed earlier. But I hadn’t given it any real notice, or looked into it in any detail - it does need fixing, so I’ll get round to it tomorrow. At the moment I’m laid up with a bad back.

1 Like

OK, sorry for the delay - I’ve now refactored the “Layers” map control, and did away with the main page settings dialog area which also played some part in controlling the various regions layers.

So, the “Layers” map control now governs all aspects of regions layers presentation, and also sets and reads cookies depending on user interaction with the control. This probably looks like just a small cosmetic change, but in the background a lot has changed. It’s been a bit tricky to coordinate the complex interactions between various parts of the code, so I may have missed one or two snippets - I’m sure the users will let me know what is missing.

Before the change:

and after the change:

I’ve also cleaned up the way each of the map controls with dropdowns (i.e. the “Position”, “Grids”, “Icons” and “Layers” controls) interact with each other - if any one of the dropdowns is activated, any other visible dropdown will disappear.

UPDATE: user-settings for summit icon type and display of summit code labels (in the “Icons” map control) also now stored to cookies.

HTH, Rob


A thousand apologies Rob. I tested this as soon as you posted a fix was in place but forgot to say so. It fixed the issue I was seeing but I didn’t thrash it to see if there were any other issues. However, the reported problem is fixed and things work just peachy when I switch between regions.