[Script] WME HN NavPoints

WME HN NavPoints

Version: 2023.09.29.01

Greasyfork: https://greasyfork.org/en/scripts/390565-wme-hn-navpoints

Description: This script adds WME layers showing lines between all House Numbers and their Navigation Points, as well as the numbers themselves, even when not in the HN mode. The visibility can be disabled when zoomed out (lower #) further than a specified setting in WME HN NavPoints settings. The default is 5, the minimum is 4. Visibility of the layers can be controlled in the layer menu and with keyboard shortcuts.

Developers: dBsooner through WazeDev (Originally developed by MajkiiTelini)

Feature list:

  • Two layers within WME: HN NavPoints (lines) and HN NavPoints Numbers.
  • House Number mouseover tooltip, for zoom levels 6-10, with edit button for easy HN mode access.
  • Setting to disable when zoomed out wider than specified zoom level (minimum 4, default 5).
  • Ability to use keyboard shortcuts to toggle each layer independently.
  • Settings, including keyboard shortcuts, synchronize between browsers with the help of WazeWrap.
  • Spinner in top left corner of WME map pane to indicate when script is actively processing.
  • Mouseover tooltip for house numbers to show full address as well as edit button to enter house number edit mode. Tooltip can be disabled in settings.

Changelog:

2023.09.29.01 CHANGE: WME beta release v2.188 compatibility. 2023.08.02.01: CHANGE: WME release v2.180-7-geb388e8d3 compatibility. 2023.07.20.01: CHANGE: Latest WME update compatibility. CHANGE: No longer removing HN or lines when first clicking a drag handle or HN input box. 2023.06.15.01: BUGFIX: Keyboard shortcuts not surviving reload. 2023.05.23.01: CHANGE: Reverted to 100% vanilla JavaScript, removing reliance on jQuery. CHANGE: Switch to WazeWrap for script update checking. CHANGE: (2023.05.23.01) WME v2.162-3 changes compliance. 2023.05.11.01: CHANGE: Reverted to 100% vanilla JavaScript, removing reliance on jQuery. CHANGE: Switch to WazeWrap for script update checking. 2023.04.19.01: NEW: Check for updated version on load. NEW: Moved settings to new HN NavPoints tab. CHANGE: WME production now includes function from WME beta. 2022.08.26.01: BUGFIX: Minor bugfixes. 2022.08.02.01: BUGFIX: Minor bugfixes. 2021.09.14.01: NEW: Auto-select input box when adding a new HN. BUGFIX: HN and lines not clearing on first click. BUGFIX: HN and lines not added back if no changes made after deselection. 2021.08.30.01: CHANGE: Change forum post URL. 2021.08.26.02: CHANGE: Update zoom levels to new WME numbers. 2021.07.28.01: NEW: Fix WME bug by forcing WME to clean its HN object array when exiting house numbers mode, thus preventing WME from growing the array astonishingly large, wasting resources. NEW: Multiple new functions to aide in the bugfixes named below. CHANGE: Allow HNs to be drawn concurrently with other map features. (MUCH faster) CHANGE: WazeWrap.Requires.Icon class used now instead of injecting my own OpenLayers.Icon class. CHANGE: Less data stored within HNs and Lines objects. CHANGE: Now using the new WME font for HNs. BUGFIX: Clicking the reload / refresh icon in WME would not clear HNs or Lines in some instances. BUGFIX: HNs and Lines were either removed, not removed or were multiplied (multiple numbers and lines for same HN) in certain situations. BUGFIX: Selecting a house number input field would not remove the HN or Line in certain situations. 2020.07.27.02: NEW: Setting to disable house number mouseover tooltip. NEW: With the mouseover tooltip disabled, script reverts to previous style of numbers to increase performance. NEW: Setting to disable keeping the house numbers layer on top of other layers. CHANGE: WME map object references. CHANGE: Changes to allow for better ability to select features behind house numbers: house numbers smaller, nav point line layer zindex. BUGFIX: Incorrect display, omitting of data in a right-to-left text locale. BUGFIX: Memory management by removing lines and numbers no longer in the map extent. 2020.07.08.01: CHANGE: WME compaitibility update. 2020.06.16.01: NEW: HN number mouseover tooltip (zooms 6-10). Edit button for easy HN mode access. CHANGE: Lots of under-the-hood stuff to increase performance. CHANGE: Latest WME update compatibility. BUGFIX: Reloads not properly refreshing HN and lines. 2019.12.06.01: CHANGE: WME v2.43-40-gf367bffa4 compatibility. 2019.10.18.01: NEW: Initial WazeDev version release. NEW: Updated to utilize WazeWrap features. NEW: Settings saved to WazeWrap for easy access from other browsers. NEW: Disable when zoom level < # setting created. Set in WME Settings. (Minimum: 4) NEW: Spinner in top left corner of WME when HN NavPoints are loading. CHANGE: Lots of under the hood stuff to enhance experience. BUGFIX: Keyboard shortcuts to toggle layers now remembered.

Color code (lines and number outlines):
Forced & unedited => red
Forced & edited => orange
Unforced & unedited => yellow
Unforced & edited => white

Screenshots:


1 Like

That’s a handy script! Thank you.

Sean

This provides basically what I was hoping to get when I posted this script request a little over a year ago!

THANK YOU!!!

Haha, didn’t know about this discussion.

The (my) idea has come from house numbers problems in our local community.

Upon further use, it actually doesn’t go to the level that I had hoped.

Was looking for a way, without overloading the server with queries, to be able to visualize that HNs exist and where they’re attached, without having to open the HN view first, and for more or less all HNs that would be visible in the edit window.

This script appears to scrape up the HN data each time the HN view is opened, and then keeps them visible until the screen is refreshed. While not nearly the time saver I had hoped it would be, it is still a step in the right direction, at least. Thanks!

You can do that in Toolbox. There’s an option to highlight streets with house numbers (shaded blue). You won’t see the actual house numbers - you still have to go into HN view first - but you’ll quickly be able to see which streets do have house numbers set.

Yes, I have TB, thanks. Unfortunately, it isn’t able to show you how many HNs are on that segment (false positive when there is only one HN but there should be six, etc.) or give any visual indication that any present HNs are positioned properly (ie. sometimes they are all attached at one end of the segment or something).

This script solves those problems, but still does it after the fact, after HN edit view opened.

I know there are issues with server calls if you want all this HN info up front, it is discussed on the other thread.

I probably don’t understand you, my script does not need open HN edit view to show lines for all house numbers in all segments, which are visible on the screen. (So lines to some house numbers could not be seen, because their segment is ouf of the screen.)

There is no other way how to do it. I did many optimizations to minimize server overload.

That might have been your intention, but I just installed and can confirm it does not work that way on the NA server, which would make sense since you are only querying for ROW HNs.

Oops, you are right. I completely forgot about the nonROW servers, although i know this issue from LMAO script…

It should be fixed now, please download version 0.5.1

Updated script, and yes, it works! THANK YOU!

Here is the first place I used it to reveal a notable HN mess. A bunch of HNs for 47th Circle were incorrectly imported as attached to 47th Ave. At some point the HNs missing from 47th Circle were noticed and added, but without this script there would have been no obvious way to notice all these extra and incorrect HNs still attached to 47th Ave.

HUGE thank you for this script!

I’ve found several like that, but I found one that makes me want a new feature, jump to address point. I followed one for nearly 100 miles before I gave up on finding it.

That’s weird for me. Script should not be able to do this, because it displays lines only for HNs, that are visible on screen.

“jump to address point” is not in planning now :wink:

Verrrrrry grateful for this script. It’s super useful to see when the HNs are incorrectly snapping on segments. I tend to find some forced HNs when I see the clump of HNs at a location.

Is there a way you could allow highlighting of forced HNs? There are forced HNs out there, even when they aren’t clumped together. I’d love the ability to be able to see those forced HNs and work them.

LOL. Sorry, but that did make me literally laugh out loud. :slight_smile:

That could happen if there is more than one matching HN for the road name, but perhaps in a different county (assuming USA/NA addressing). If two roads have the same name and have no primary city set but are in the same state, you’ll get the “already exists” error.

For example, say some small unincorporated community with no primary city has a “101 Main Street”, and another unrelated unincorporated community far away but in the same state also has a “101 Main Street” with no primary city. I’ve run into this a few times.

Alt city naming with USPS cities solves the problem for searching purposes when someone wants one of them specifically, especially since it will give the closer search result first (which is probably almost always the desired result), but at the end of the day, both “101 Main St” addresses with no primary city in the same state are correct even though WME doesn’t want you to do it

In order to get this to work so both addresses are searchable with alt cities, I will change the segment name, add the troublesome HN, then change the segment name back. Next time you open HNs on that segment, the “hack-forced” HN appears with a red border instead of green, but is still correct. As long as you leave it alone you are OK, but if you bump it you won’t be able to save your changes. There are a lot of these double HNs that have existed ever since the initial HN imports, and were not created by an editor.

I’m guessing your long distance HN is from something like this.

Another color of dashed line would be enough?

Yeah, a red dashed line would be appropriate. This would make those forced HNs really pop out.

Another color for “un-nudged” HNs (ones that have never been edited by any user) would be nice, too, as long we are asking for features. :slight_smile:

OK!

Forced & unedited => red

Forced & edited => orange

Unforced & unedited => yellow

Unforced & edited => white