false negatives for DISCONNECTED_ROUTE #610
Comments
|
#7239 may or may not have changed some of the symptoms. Check before & after. |
This happens.
I was semi-expecting this to happen, but adding some debug text shows it doesn't. Nope: Not quite: auto flag = [&]()
{ Datacheck::add(r, r->con_beg()->label, "", "",
"DISCONNECTED_ROUTE", q->con_end()->root_at_label());
Datacheck::add(q, q->con_end()->label, "", "",
"DISCONNECTED_ROUTE", r->con_beg()->root_at_label());
cr.disconnected = 1;
q->set_disconnected();
r->set_disconnected();
};
r->con_mismatch();
if ( q->points.size > 1 && r->points.size > 1 && !r->con_beg()->same_coords(q->con_end()) )
if ( q->con_beg()->same_coords(r->con_beg()) )
if ( q->is_disconnected() )
q->set_reversed();
else flag();
else if ( q->con_end()->same_coords(r->con_end()) )
r->set_reversed();
else if ( q->con_beg()->same_coords(r->con_end()) )
{ if ( q->is_disconnected() )
q->set_reversed();
else flag();
r->set_reversed();
}
else flag();
Maybe?
More?
ToDo: Finish looking at India.
|
|
5 new chopped routes in 3 connected routes
|
|
debug text//r->con_mismatch();
std::cout << "DEBUG: "; // This only works single-threaded
std::cout << (( q->points.size > 1 && r->points.size > 1 && !r->points.begin()->same_coords(q->con_end()) ) ? '@' : '!');
std::cout << (( q->con_beg()->same_coords(r->points.begin()) ) ? 'Q' : '_');
std::cout << (( q->con_end()->same_coords(&r->points.back()) ) ? 'R' : '_');
std::cout << (( q->con_beg()->same_coords(&r->points.back()) ) ? "B " : "_ ");
std::cout << q->root << '\t' << r->root << std::endl;
//if ( q->points.size > 1...Top 2: Disconnected in the truest sense: gap in the ConnectedRoute, sans chopped Route Top 2: Full beltways in 2 regions. Not errors. |
|
play-by-playBold: W/E split alignments causing errors
|
When either Q xor R can be reversedThings get... interesting. What are Q and R?Q and R refer to a pair of two adjacent chopped routes in a What happens?When Q xor R can be reversed so their endpoints line up, the code I've been testing thus far just... picks one. When?When both routes' Does it matter?In the Nagpur example, this happens because E & W split alignments are erroneously included in the same ConnectedRoute, like trying to include I-35E & I-35W along with the rest of I-35. The matching coords could happen in real life, in a two-region beltway. Two of these exist, though this doesn't come into play as both have consistent point ordering in both chopped routes. Consistent with the Route-in-ConnectedRoute order too, so both pass the connectivity check with nothing needing to be reversed at all. But what if...?
Could a legitimate ConnectedRoute be affected by the wrong chopped Route being selected for reversal? Note that problems only arise if the loop is at the beginning of the route. West-to-east in the picture. Answering the "Do we reverse Q or R?" question means finding out which direction R needs to go to link up to the next chopped route (if there is one), yielding code looking something like: if ( q->points.size > 1 && r->points.size > 1 && !r->points.begin()->same_coords(q->con_end()) )
if ( q->con_end()->same_coords(&r->points.back()) ) // R can be reversed
if ( q->con_beg()->same_coords(r->points.begin()) // Can Q be reversed instead?
&& ( q == cr.roots[0] || q->is_disconnected() ) // Is Q not locked into one direction?
&& i+1 < cr.roots.size() // Is there another chopped route after R?
&& ( r->points.back().same_coords(cr.roots[i+1]->points.begin()) // And does its beginning
|| r->points.back().same_coords(&cr.roots[i+1]->points.back()) )) // or end link to R as-is?
q->set_reversed();
else r->set_reversed();
else if ( q->con_beg()->same_coords(&r->points.back()) ) // Q & R can both be reversed together
if ( q == cr.roots[0] || q->is_disconnected() ) // as long as Q's direction is unknown
{ q->set_reversed();
r->set_reversed();
}
else flag();
else if ( q->con_beg()->same_coords(r->points.begin()) // Only Q can be reversed
&& ( q == cr.roots[0] || q->is_disconnected() )) // as long as its direction is unknown
q->set_reversed();
else flag();Meh. Thankfully, this extra check will happen very rarely. *Working from an old HighwayData revision from Oct 30. Newer revisions will have more connections to check and fewer (zero?) Q-xor-R cases, as indnh_con.csv got cleaned up bit. Anyway.
O HAY! All this reminds me! |
|
A solution for this is ready. Holding off until #615 is merged. |
rebase 49288bc itself a rebase of c627aec
https://forum.travelmapping.net/index.php?topic=3512.msg33027#msg33027
First thoughts:
The text was updated successfully, but these errors were encountered: