LACKS_GENERIC datacheck

[yakra]

LACKS_GENERIC is implemented in wptedit:
https://github.com/TravelMapping/Web/blob/51b9b3097e98fc804424e1b936dc0f10c5dbb5db/wptedit/wptfunctions.js#L1311

wpts[i].label.search(/^old\d/i) >= 0

...but not siteupdate.

Need to tighten things up to avoid too many FPs.

[yakra]

Re: Using grep to search highway data, waypoint labels, etc.

[yakra]

Replicating wptedit's datacheck and then adjusting to allow for a leading * produces 23 results.

• 6 are Old## flavored. Of these,

  • 5 are false positives because they refer to old exit numbers.
  • 1, on.on127 @ Old127, appears to be signed as exactly that in the field.

  Of the 17 remaining Old##Foo flavored entries...

• 15 are false positives with a generic highway type such as Rd or Hwy after the number, some as part of normal truncated road names such as Old3RRd.

• 2 entries remain that I would regard as true positives:
  mn.us014;*Old14Nic_E;;;LACKS_GENERIC;
mn.us014;*Old14Nic_W;;;LACKS_GENERIC;

This is all a pretty high FP rate for something that's so little of a problem.

Trying to avoid expected FPs while also avoiding false negatives gets thorny pretty fast.
Ignoring anything with letters after a number means ignoring cases of supposed "banners" or "abbrevs" like this example.
It would become, then, a matter of checking for legit generic types (Rd, St, Ave, Hwy, Blvd, Way, Ln, and the list goes on, and that's just in English-speaking North America (the only place I've seen this type of FP, but still)... and the list is bound to never be complete) optionally after a single letter, or ordinal number suffixes (which also might not be in English)...

Making this even a moderate level of foolproof would be an almost Herculean task, well out of scale with the size of the actual problem.
Even if we somehow got it "perfect", there'd still be a 3:1 false:true positive ratio.

Not sure if this datacheck is even worth implementing.

OTOH, as-is, 23 entries out of almost a million points is still pretty small in raw numbers. I could just add the FPs to datacheckfps.csv since I already have the info, and we could add any future FPs in the rare cases that they come up.

I'll just post on the forum about the true positives & hope they go away... ;)

[michihdeu]

I'd say, you've spent effort for it, so it is worth being implemented. 23 out of a million is not that much.

It would be a "black" error type on datacheck.php

[yakra]

It would be a "black" error type on datacheck.php

Agreed.