[Script] WME Validator v2021.3.5 (+ PLACES BETA)

[BellHouse]

Further plans
Guys, let me know if you are interested in the following features:

1. User interface internationalization - i.e. translation of buttons, checkboxes, tips etc. on your language. Would it be useful or English is OK?

2. Separating translations from the main script. The main script will be slimmer and faster, while you will be able maintain translations on your own. I suggest to extract the following features:
a) UI translations (optional, see 1)
b) translation of check titles, problem descriptions, howtos and links localization
c) enabling/disabling checks for the country
d) managing exceptions and check parameters

Let me know what you guys think before I start to implement the functionality.
I would also like to hear if the script startup time in v0.6.2 is still an issue for you.

Yes, I think localizations would be helpful, as it would widen the user circle (not every editor is fluent in English). The translations can probably be handled by string lists, which could be fed to you by local persons or groups in each country. In particular, I like the idea of having localized links to wiki/howto references.

About 2c): I suggest to have a default enabled/disabled check list for each country, where each user can then individually edit his list. A reset-to-default functionality should allow fixing screwed-up configurations.

I don't quite understand what 2d) means.

[BellHouse]

Is there any chance that a check can be added to highlight a road with a blank elevation?

Blank elevations do not exist in the database, they are just sometimes displayed in WME by a long standing bug that's masked by the Junction Node Fixer Script (JNF). It happens after saves and the features are reloaded before the changes have fully propagated. Causing the features to reload (reload page, permalink, pan/zoom far enough, WME Toolbox key) clears it.

[BellHouse]

I would like to ask for some more discipline in keeping the posts in this thread related to WME Validator.

Every morning I open the forum, this thread has accumulated several pages of posts. That's a lot of stuff to read. But IMHO, around 90% of the discussed topics are not related to Validator. Example: the discussion about two way ramps in the US is absolutely valid and important, but I think it should be taken in a seperate thread in the US forum.

In this way, I think we can become more efficient in improving this excellent tool.

[BellHouse]

Validator's controls are located under the "Me" tab in WME. I suggest moving them to a dedicated Validator tab, like other extensions do:

[ img ]
In this way, there would be more space for the controls, and the number of menus within Validator could be reduced.

[BellHouse]

Is there an option to rerun/ update a report? Would be useful when trying to cleanup one particular area.

I guess if you create and save a permalink, you can always create reports starting from the exact same position, which is probably like re-running the report.

[BellHouse]

User BellHouse found the source of the problem related to Elevation Being Set to Null, it is caused by JNF (Junction Node Fixer). Just disable it and the problem is gone.

Except that it's not. It's a side effect of eventual consistency and has nothing to do with anything but WME's backend's current propagation delay at the time you save modification(s) to a segment(s).

Normally this is masked by JNF's issuing a second reload after a successful save, but sometimes you might get data served from a different server that isn't yet consistent.

Just to put this into another light: I did not mean to say that there is a bug in JNF leading to the null elevation data. I said JNF triggers this issue, and I might add it is not always doing so, and it might not only be JNF doing this. But - in my experience - JNF does have a high tendency of provoking this issue, for reasons way out my understanding.

But now the check for irregular elevation data has been switched off in Validator 0.9.3, so we can let this issue sleep again.

[BellHouse]

Is there a way to highlight segments which carry an alternate street name? I'm thinking of configuring something with the new RegExp feature, but I would not know which variable to use (something like ${alt_street}).

Check #34 only tests if the alternate street field has an empty name (only whitespace/s), so that cannot be tuned to do the job, I guess.

If it's not available, then this is a feature request.

[BellHouse]

Hi!

Is there a way to highlight segments which carry an alternate street name?

Sorry, alt. names are not available in the template at the moment. Since there might be few alt. street/city names, I'm not sure how to represent them in one string.

Any ideas?

I would create the two strings ${alt_street} and ${alt_city}, each of which are a collection of all alternative street or city names, delimited by a hash (#) character. So if for instance the two alternative street names are "Main St." and "Main", then the ${alt_street} would be "Main St.#Main". A segment with no alternative street name would then get an empty ${alt_street}.

[BellHouse]

WMECH does already highlight streets with alternate names. It doesn't, of course, do any checking of the names, but you didn't ask for that. Yet.

Yes? Hm, mine doesn't. Which setting is this?

[BellHouse]

1. No road continuation (for Primary Streets and up)
2. No right* turn (for any drivable road)
3. Geometry points are too close (for any drivable road)

1. and 3. seem ok for me.

I don't get the idea behind 2. You want to mark all right/left turns that are disabled (red arrow)? What's so special about a turn of around 90° angle?