Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Datacheck options for non-highway systems #604

Open
jteresco opened this issue Aug 14, 2023 · 5 comments
Open

Datacheck options for non-highway systems #604

jteresco opened this issue Aug 14, 2023 · 5 comments
Labels
datacheck railways TM expansion into railways

Comments

@jteresco
Copy link
Contributor

The relevant datachecks will be different for non-highway instances of TM. Naming conventions can be different, acceptable distances between visible points might be different, etc.

It might make sense to have a command-line parameter mechanism to enable/disable various datachecks. Then the site update script can select the right ones for whichever kind of data is being used in the update.

@jteresco jteresco added datacheck railways TM expansion into railways labels Aug 14, 2023
@michihdeu
Copy link
Contributor

michihdeu commented Aug 14, 2023

The threshold for NMPs should be smaller than for highways. I don't know the hwy value nor have a proposal for railways.
https://tmrail.teresco.org/logs/nmpbyregion/

@michihdeu
Copy link
Contributor

michihdeu commented Aug 14, 2023

180° SA (sharp angle) errors are usually intended when there is a DC (duplicate coords) error before and after, e.g.:

DIV_BlankA http://www.openstreetmap.org/?lat=53.565376&lon=9.818859
Blank http://www.openstreetmap.org/?lat=53.564483&lon=9.815297
DIV_BlankB http://www.openstreetmap.org/?lat=53.565376&lon=9.818859

I don't think that we can simply disable it via enabling/disabling but would need more logic in the data check.

@michihdeu
Copy link
Contributor

michihdeu commented Aug 18, 2023

We might generally disable the LONG_UNDERSCORE data check for railway systems: TravelMapping/Web#629 (comment)

@yakra
Copy link
Contributor

yakra commented Aug 22, 2023

In the OP, @jteresco wrote:

The relevant datachecks will be different for non-highway instances of TM. Naming conventions can be different, acceptable distances between visible points might be different, etc.

It might make sense to have a command-line parameter mechanism to enable/disable various datachecks. Then the site update script can select the right ones for whichever kind of data is being used in the update.

My first under-the-hood thought here is function pointers.
The majority of the datachecks (last I took inventory (and I believe nothing has changed since), 27/37) are performed during Route::read_wpt in order to get stuff done while waiting for disk access.
In particular, there's this one bit with a bunch of function calls in a row.
This could be separated out into several different datacheck "suite" functions, each containing only the function calls needed for Highway, Rail, Ski, Bike, whatever, data. (For example, those 3 USA-only datachecks at the beginning are only needed for Highway-flavored TM.)

The command-line mechanism can set a function pointer to the appropriate datacheck suite, and life goes on -- read_wpt gets cleaned up a bit, and we don't need to worry about cluttering up read_wpt, the individual datacheck functions, or a "suite" function that collects multiple function calls, with a bunch of conditionals and branching.

@michihdeu
Copy link
Contributor

HIDDEN_JUNCTION and VISIBLE_HIDDEN_COLOC are also quite common for railways. Omit?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
datacheck railways TM expansion into railways
Projects
None yet
Development

No branches or pull requests

3 participants