Problem with visualization

[Spinoza]

Hi,

I'm experiencing problems in the visualization of my trips. When I select myself (Spinoza) and map of, say, Italy, the map actually shows Albany, NY and is stuck on "Loading data...". This is with both latest Chrome and Edge.

Is it just me or are others having the same problems?

[Jim]

Haven't heard of problems.  But make sure Javascript is enabled for travelmapping.net in your browser.

[yakra]

I assume only mapview.php is broken, and
https://travelmapping.net/user/region.php?units=miles&u=spinoza&rg=ITA
https://travelmapping.net/user/system.php?units=miles&u=spinoza&sys=itaa
work fine?

[Jim]

I've reproduced the bug and I'll see what I can figure out.  I'm guessing it's a case that my code did not anticipate within the data in ITA that does not occur in the places I used in my testing.

https://github.com/TravelMapping/Web/issues/527

[Jim]

Quick update: Mapview can be broken by VISIBLE_HIDDEN_COLOC errors that get marked as false positives and stay in the data.  I think the one that causes the failure here should be fixed in the data, but unless we can get rid of all VISIBLE_HIDDEN_COLOC errors (which I continue to support strongly), Mapview code will need to be modified to handle this.

[yakra]

unless we can get rid of all VISIBLE_HIDDEN_COLOC errors (which I continue to support strongly),

IMO, VISIBLE_HIDDEN_COLOC should stay -- although it no longer exists, there's the canonical example of Future I-22 ending at an unopened (and thus hidden) interchange on I-269.
The TX & NY examples, I added in order to enable Intersecting/Concurrent Routes for the routes with the visible point.
In these cases, concurrencies shouldn't be affected; the points should be visible on all routes comprising one incident edge, and hidden on all routes comprising another incident edge.
One option is to restrict cases where these are reported, by examining the visibility of the point on each concurrent route on each incident simple edge.
I'll have a look at the siteupdate code shortly, to refresh myself on when & how VISIBLE_HIDDEN_COLOC is flagged, and the surrounding context.

Mapview code will need to be modified to handle this.

I support this too, of course. Whether or not VISIBLE_HIDDEN_COLOC detection is ultimately changed, this would be the more robust solution if/when new VISIBLE_HIDDEN_COLOC errors are introduced.
Looks like Jim already has this in the works though.

[yakra]

One option is to restrict cases where these are reported, by examining the visibility of the point on each concurrent route on each incident simple edge.
I'll have a look at the siteupdate code shortly, to refresh myself on when & how VISIBLE_HIDDEN_COLOC is flagged, and the surrounding context.

I gave some thought to doing this, by moving VISIBLE_HIDDEN_COLOC detection into the edge-collapsing routine.
It would still flag cases like the north end of US377. While this specific example may be debatable in terms of 1PPI, IMO it still makes sense to allow marking VISIBLE_HIDDEN_COLOC errors as FP.

I no longer support making changes to VISIBLE_HIDDEN_COLOC detection, as this risks failing to flag cases that contributors would legitimately want to examine & potentially fix, and be more computationally intensive in the process.

[michih]

I checked all cases with VISIBLE_HIDDEN_COLOC errors (marked FP or not) and mapview only crashes with ITA and CHN-GD for all users!

[Jim]

I've put the workaround onto the production server, which I think means things will load, but could have labels from a concurrent route's waypoints instead of the primary route in popup windows in a few cases.