Data check error "LABEL_SELFREF" not detected

[michihdeu]

I had some cases where LABEL_SELFREF where not detected in FRA-IDF and FRA-GES.
I guess it's in combination to the usage of banners for the French D routes.

• Plain D906 was not detected.
• Plain D112 was not detected.
• Plain D120 was not detected.
• D60 was not detected in D60/D108_W and D60/D108_E.
• But D33 in D8/D33 was detected!?

[yakra]

• Plain D906 was not detected.
• Plain D112 was not detected.
• Plain D120 was not detected.

DataProcessing/siteupdate/python-teresco/siteupdate.py

Line 3676 in 8c633d2

if '/' in w.label and r.route[-1].isdigit():

These labels don't contain a /, so we skip over that section of code.

DataProcessing/siteupdate/python-teresco/siteupdate.py

Lines 3689 to 3690 in 8c633d2

	# now the remaining checks
	if selfref_found or r.route+r.banner == w.label or re.fullmatch(r.route+r.banner+'[_/].*',w.label):

selfref_found is unchanged, still False. Thus the banner is required to match, and these non-banner "banners" of -54 & -78 are not found in the labels, so nothing else happens.

---

• D60 was not detected in D60/D108_W and D60/D108_E.

This label contains a /, so we do enter into the first big if block, but all the checks therein only scan the label starting after the /, so selfref_found remains False and we proceed as before.

---

• But D33 in D8/D33 was detected!?

Here, D33 is after the slash.

DataProcessing/siteupdate/python-teresco/siteupdate.py

Lines 3682 to 3683 in 8c633d2

	if w.label[w.label.index('/')+1:] == r.route:
	selfref_found = True

And badabing!

---

Implementing a "fix" for this would require ignoring a route's banner field, which would mean breaking every case where a bannered route's point's label contains its unbannered parent.
...to which I emphatically say Nope! :)

...unless we added in some kind of FRA-specific workaround?

select distinct banner from routes where region like 'FRA%';
select distinct banner from routes where systemName like 'fra%';

It looks like the only banners used in FRA are department numbers.
This makes me bristle a bit though; it just seems like a kluge...

[michihdeu]

Another issue: TravelMapping/HighwayData@bf30f26#diff-bc7f7e44dde3d183158d81d437001af7a109fa5fcf8cdbe995310fd95e066f3a

[michihdeu]

Plain M62 not detected: TravelMapping/HighwayData@f755054#diff-0a8d538a6f603f2449e76519bad9b0f327cf216581de3e4c75ed820b21c74ca9

[yakra]

...unless we added in some kind of FRA-specific workaround?
...
This makes me bristle a bit though; it just seems like a kluge...

A bit more palatable: Ignore Banners beginning with -.
Right now, these are only used for French department numbers.
Would just have to ensure that any future uses of -XX banners are a similar "non-banner" usage.

---

Marked FP now:
frahdf.d093962cam;D901/D939;;;LABEL_SELFREF;

• Currently flagged because after-slash checks still ignore banners.
• Phase 1 gets rid of it: same route + same "banner"