This feature has been changed from the 'r' key to 'c' to correspond with the menu that pops up and offers a "connected" option.

Sorry about that -- Javascript error I didn't catch. The patch is uploading right now and should be live in a few minutes. Just refresh your browser. Thanks for the head up.

That trips me up too sometimes. The underlying map relies on OpenLayers interface and the OpenSteetMap. They are both open source and free to use. OpenLayers would support other maps if one can be found that is stable and well supported. I haven't found one.

I'm thinking about how to make this work on touch screens. Any ideas?

Is it still useful to have the alt/option-click method, or does this replace it completely?

Another iteration of the path feature was uploaded today:
• The "r" key clears all labels; tapping "r" any time has the same effect.
• No new labels appear as long as the "r" key is held down.
• Shorter hops are not displayed, to reduce clutter.
• The search for connected paths has been expanded.

Another followup to this — if you hold down the "r" (for recursive) key and select a footprint, it will expand to all the connected paths. To reduce clutter station callsigns are omitted.

You may need to refresh your browser to pick up the change.

The update has been uploaded. The map will self-correct over time or clicking on footprints with incorrect paths will load the corrected data. Thanks for helping to troubleshoot this.

The Es filtering needs more work. Right now it is triggered when there are at least three intersecting paths of 1750+ km from 6 distinct stations. Once that is met, any path of 500+ km in the vicinity is accepted. Something in there needs to be tightened up.

I think I found the problem. I'll do some testing and upload it soon if everything looks normal again. I thought I saw an optimization opportunity, but that just broke things in a mirror image way. I've documented that area better!

Hmm, I'm seeing that this morning too. It must have to do with with a recent update. I'll work on it. The update has to do with restoring e-skip detection and display. It is mostly working except for eliminating false positives. Something about that change must be causing what you see.

Do most people know the corn grown the corn belt is not edible directly? It mostly goes into ethanol, cattle feed, and such. The same for soybeans: biodiesel, oils, etc. The terms here in MN are "field corn" which is everywhere and "sweet corn" which is edible but I haven't any of that this season.

It seems OK to me. Could it be a local problem?

On small screens, the prediction will fill the view and on larger devices it will appear as an inset at the bottom left.

On large screen the prediction will change as the target destination is moved to a new location. The inset will move to get out of the way of the target as needed.

hf.dxview.org

There is a new button on all devices to reveals a propagation prediction between two points on the HF map.

To show the prediction, first select an initial location. Next select a distant point of interest. Finally, at the top of the window, select "show prediction …".

hf.dxview.org
#hamradio

Notifications can be delivered via a browser

developer.mozilla.org/en-US/docs/W...

Toward the bottom of that page is a table of which browsers support the various features. I expect this will work better and better going forward.

Anyway, this is a starting point for adding notifications some day.

The HF map is most useful when your location is selected because it personalized the map for your QTH.

The draggable target for selecting your station's location has been slimmed down (same on mobile and desktops) and the corresponding text input moved to the top of the screen.

Panning or zooming the map under the selector now correctly updates the targeted location.

Good idea. What type of notification do you prefer? The Google Cloud doesn't allow email directly. Browser-based notifications might be possible but have no experience with that yet.