Travel Mapping

Web Design Discussion => General Web Design Discussion => Topic started by: Jim on May 19, 2017, 01:49:50 pm

Title: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 01:49:50 pm
The highway browser on the tmtest site has a first attempt at linking to intersecting routes.  The links are in the "infowindow" that pops up when you click on a waypoint.  Any other route that includes a point with identical latitude and longitude as that waypoint will be listed.  I decided to put the links here rather than right in the list of waypoints because I didn't want to clutter up the lists, I don't want to mess around with the CSS that formats those tables, and it was a little easier to code this way.  The big problem at the moment is that the extra DB queries (one per waypoint) really slow things down.  For small routes, it's not too bad, but for long ones, the delay is unacceptably long.  And this is after I made some changes to the queries to make them about 4-5 times faster than my original attempt.  Unfortunately, my database expertise is pretty limited, and I don't know what else to try.  I'm guessing that I'll need to make some changes to the table structure itself to allow these queries to be more efficient, or to store the information about intersecting routes in some other way.
Title: Re: Intersecting routes on the HB
Post by: michih on May 19, 2017, 02:00:03 pm
I made a test:
http://tm.teresco.org/hb/index.php?units=km&u=terescoj&r=deu.a003 (loading time: ~1s)
http://tmtest.teresco.org/hb/index.php?units=km&u=terescoj&r=deu.a003 (loading time: ~90s)

Do you check all waypoints or the waypoints of the region only?
Title: Re: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 02:28:58 pm
Yes, very slow.  There's one DB query per non-hidden waypoint in the route being displayed.  Given the current structure of the DB, I don't know a way to avoid making that many queries.  Doesn't mean there isn't one.
Title: Re: Intersecting routes on the HB
Post by: compdude787 on May 19, 2017, 02:55:51 pm
Yeah, we might want to wait on implementing this until we can figure out how to make the loading time be faster. Otherwise people are going to get extremely frustrated at how slow it's going.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 04:15:06 pm
Fortunately, Google knows SQL tricks even if I don't.  Try it now.  It's fast!
Title: Re: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 04:24:45 pm
At this point, I'm interested in hearing mostly if I broke anything.  I'd like to push this functionality out as-is to start if existing functionality still appears to work.  If you prefer a different presentation of this information (such as in the waypoint table, more similar to how CHM's old HB did these), let me know.

Before reporting a case where an intersecting highway does not show up, please make sure it's not a data problem.  I know we still have NMPs out there, and this code looks for exact matches.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 04:43:53 pm
I see that my latest "fix" now makes it so the list in the table and the infowindow strings don't line up properly.  So clicking on an entry in the table brings up the wrong one.  Surely fixable, but I'm tied up the rest of the afternoon and much of the evening.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 19, 2017, 06:25:30 pm
Sorry to carry on a conversation with myself on this..  I had a minute to look for the error with the waypoint table and infowindows not lining up and I have made a fix.  Looks good now.  Please test away!
Title: Re: Intersecting routes on the HB
Post by: mapcat on May 19, 2017, 10:03:56 pm
No problems to report here. Working great!
Title: Re: Intersecting routes on the HB
Post by: yakra on May 20, 2017, 02:30:49 am
I decided to put the links here rather than right in the list of waypoints because I didn't want to clutter up the lists, I don't want to mess around with the CSS that formats those tables, and it was a little easier to code this way.
If you prefer a different presentation of this information (such as in the waypoint table, more similar to how CHM's old HB did these), let me know.
I prefer to have this info just as you've done it. I've actually wished it was listed in the InfoWindow since back in the CHM days.Thanks for doing this!
Title: Re: Intersecting routes on the HB
Post by: compdude787 on May 20, 2017, 02:35:35 am
Oh yeah, it's working great now! I'm glad you were easily able to improve the loading times.
Title: Re: Intersecting routes on the HB
Post by: michih on May 20, 2017, 03:37:58 am
Cool feature, thanks :) Loading time seems to be the same with or without this feature now.
I really like the idea of displaying Intersecting/Concurrent Routes in the info window and I'm even happy that it's NOT displayed in the table like yakra said

We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?

If I click on the intersecting route, the HB is loaded as usual. Is it possible to center the map with the last waypoint and zoom in with the same zoom level and with the same map style which was selected before? That means, I would see exactly the same map but just the highlighted route is changed. I could directly proceed browsing at the point I left the previous route.

I found a bug on tmtest which might be caused by this improvement or anything else but I think it's worth to be reported:
http://tm.teresco.org/hb/index.php?units=km&u=terescoj&r=deu.e50 (E50 shield is resized fine)
http://tmtest.teresco.org/hb/index.php?units=km&u=terescoj&r=deu.e50 (E50 shield is not resized correctly)
I've checked other shields and it seems to work fine but anything seems to be different on tmtest server... maybe just an outdated "template_eure.svg" file?

Edit: Shields are outdated on tmtest only. Maybe you could update it to avoid strange behavior and minimize annoying "bug" reports

More strange things:
1. Open http://tmtest.teresco.org/hb/?units=km&u=terescoj&r=bel.e17
2. Click on the last "BEL/FRA" wp, info window displays "waypoint 4" which is wrong
3. The next wp windows display 3 - 4 - 3 - 3 -3 - 2 -2 - 3 --> wrong
4. Click on the last "BEL/FRA" wp again.
5. Click on "BEL A14" --> Fine
6. Click on "FRA A22 (Tourcoing)" --> Fine
7. Click on "FRA E17" --> wp table is loaded correct but the route is not loaded on the map!


Just a note you might ignore right now but I'd like to say that some countries have intersecting routes which are not directly connected, especially countries with tolled motorways like France or Spain. There are often trumpet interchanges. The waypoints are off by more than just 0.000001°. I don't think that the intersecting feature could cover this use-case. For that reason, my Open Highway Browser for specific routes from the map (https://github.com/TravelMapping/Web/issues/95) feature is still as important as before.
Title: Re: Intersecting routes on the HB
Post by: mapcat on May 20, 2017, 07:58:01 am
We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?
I would prefer that we NOT include routes that are close but don't intersect.

Quote
2. Click on the last "BEL/FRA" wp, info window displays "waypoint 4" which is wrong
3. The next wp windows display 3 - 4 - 3 - 3 -3 - 2 -2 - 3 --> wrong
To me it looks like "waypoint X" means that X routes use that point.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 20, 2017, 08:54:58 am
We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?

I'd argue that those should not be included, since the concurrencies were intentionally broken.  If there's an intersection, then maybe those should be lined up and concurrencies should be broken with a shaping point instead.

If I click on the intersecting route, the HB is loaded as usual. Is it possible to center the map with the last waypoint and zoom in with the same zoom level and with the same map style which was selected before? That means, I would see exactly the same map but just the highlighted route is changed. I could directly proceed browsing at the point I left the previous route.

Sounds like a nice idea.  We should note it as a GitHub issue as a feature request for the future.

Edit: Shields are outdated on tmtest only. Maybe you could update it to avoid strange behavior and minimize annoying "bug" reports[/color]

I've updated them now, but don't do it regularly on tmtest since it makes the code update take about 10x longer than it does when I omit shields.

More strange things:
1. Open http://tmtest.teresco.org/hb/?units=km&u=terescoj&r=bel.e17
2. Click on the last "BEL/FRA" wp, info window displays "waypoint 4" which is wrong
3. The next wp windows display 3 - 4 - 3 - 3 -3 - 2 -2 - 3 --> wrong

Fixed this.  Lesson: be careful blindly using i as a loop index variable.  It might be already used for something else.

7. Click on "FRA E17" --> wp table is loaded correct but the route is not loaded on the map!

The problem here comes up because the City fields are in double quotes.  Any idea why?  That breaks my new JS code.

Just a note you might ignore right now but I'd like to say that some countries have intersecting routes which are not directly connected, especially countries with tolled motorways like France or Spain. There are often trumpet interchanges. The waypoints are off by more than just 0.000001°. I don't think that the intersecting feature could cover this use-case. For that reason, my Open Highway Browser for specific routes from the map (https://github.com/TravelMapping/Web/issues/95) feature is still as important as before.

For now, we'll stick with exactly intersecting only.  Related to this is an idea I've been kicking around for years now, mostly because of my academic use of the data, to have a non-clinchable "system" to indicate these kinds of things.  They'd become part of my graphs, but would not be displayed for TM.  But.. points connected in these cases could be exactly what you want here.

Thanks for all the testing and feedback.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 20, 2017, 09:05:17 am
7. Click on "FRA E17" --> wp table is loaded correct but the route is not loaded on the map!

The problem here comes up because the City fields are in double quotes.  Any idea why?  That breaks my new JS code.

Looking into this, it seems over 500 routes, all in Europe, have their city fields enclosed in double quotes.  Before I code a workaround in the intersecting routes code or remove those possibly extraneous quotes from the csv files, I want to make sure they're not there for some Good Reason that I'm not aware of.
Title: Re: Intersecting routes on the HB
Post by: michih on May 20, 2017, 10:31:18 am
We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?

I'd argue that those should not be included, since the concurrencies were intentionally broken.  If there's an intersection, then maybe those should be lined up and concurrencies should be broken with a shaping point instead.

Ok, it's fine with me.

If I click on the intersecting route, the HB is loaded as usual. Is it possible to center the map with the last waypoint and zoom in with the same zoom level and with the same map style which was selected before? That means, I would see exactly the same map but just the highlighted route is changed. I could directly proceed browsing at the point I left the previous route.

Sounds like a nice idea.  We should note it as a GitHub issue as a feature request for the future.

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

7. Click on "FRA E17" --> wp table is loaded correct but the route is not loaded on the map!

The problem here comes up because the City fields are in double quotes.  Any idea why?  That breaks my new JS code.

Looking into this, it seems over 500 routes, all in Europe, have their city fields enclosed in double quotes.  Before I code a workaround in the intersecting routes code or remove those possibly extraneous quotes from the csv files, I want to make sure they're not there for some Good Reason that I'm not aware of.

Si has already fixed it: https://github.com/TravelMapping/HighwayData/pull/1267

Please keep us on the loop if there are more routes. Maybe I have similar names... Dunno, maybe a data check should be added?
Title: Re: Intersecting routes on the HB
Post by: Jim on May 20, 2017, 07:55:04 pm
Si's csv file edits seem to have fixed the problem above.  Anything else anyone sees before I have this go live?
Title: Re: Intersecting routes on the HB
Post by: Jim on May 20, 2017, 08:53:49 pm
This is now installed on the production site.
Title: Re: Intersecting routes on the HB
Post by: yakra on May 21, 2017, 12:27:06 am
We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?

I'd argue that those should not be included, since the concurrencies were intentionally broken.  If there's an intersection, then maybe those should be lined up and concurrencies should be broken with a shaping point instead.
I would argue that these should be included. There's still an intersection, and one should still be able to move from one route to the other via intersecting roads, sliproads, etc.

My canonical example:
TX US183 @ TX21, TX21 @ US183/130, and TX130 @ 461. Movement between US183 & TX130 is made via Texas's typical sliproad-frontage road setup. US183 & TX21 show up as Intersecting/Concurrent Routes for one another, as they have identical coordinates.  TX130, with its mismatching coords, doesn't list & isn't listed for the other two routes. It clearly intersects TX21 here, and has access to US183 as well.

So, while calling US183 & TX130 Concurrent Routes here isn't strictly correct, listing them as Intersecting Routes is appropriate IMO.

Some other examples that immediately come to mind:
• RI I-95 @ 19 mismatches RI I-195 @ 1 and RI US6 @ I-195(1). I-95 clearly intersects both other routes.
• NS7 mismatches NS111(6B), to break a false multiplex toward NS111(6A). Both routes clearly intersect here.
• Fall River, Massachusetts:
  - US6 @ MA79/138 mismatches MA79 & MA138 @ US6_E. There's access here via the northbound exit slip, and Davol Street to the south.
  - MA79 @ *BriSt mismatches US6 & MA138 @ BriSt. MA138 south transfers from US6 on the frontage road to MA79 on the freeway mainline here.
• NY27 and BeltPkwy, with Texas-style sliproad-frontage road access.

I believe, in good faith, that everything I have marked off in nmpfps.log should be a perfectly legitimate intersection, like these examples. I'd be surprised if any of my intentional NMPs didn't include connections between any (if not all?) of the routes involved. However, I'm not going to take the time to do the research to prove/disprove this right now. :)

FWIW, sometimes I've corrected some intentional NMPs to be off by 0.000001 instead of some greater amount, the idea being that they'd someday be interpreted as intersections by an algorithm that would Do Such Things.
Title: Re: Intersecting routes on the HB
Post by: compdude787 on May 21, 2017, 12:35:26 am
This is now installed on the production site.

Unfortunately, the highway browser is not working at all now, no matter what route or user I have selected. The map just defaults to Siena College in near Albany, NY, and the selected route does not show up on the map at all. I don't know what you did when you put this up live, because it's working just fine on the tmtest website, but you gotta fix this. :)
Title: Re: Intersecting routes on the HB
Post by: yakra on May 21, 2017, 12:37:41 am
Unfortunately, the highway browser is not working at all now, no matter what route or user I have selected. The map just defaults to Siena College in near Albany, NY, and the selected route does not show up on the map at all. I don't know what you did when you put this up live, because it's working just fine on the tmtest website, but you gotta fix this. :)
I noticed this problem, and was about to post the same thing when the problems seemed to clear up. Try it again?
Title: Re: Intersecting routes on the HB
Post by: michih on May 21, 2017, 02:46:06 am
We sometimes move wps by exactly 0.000001° to break concurrencies but the route is still intersecting. Is it possible to include these routes?

I'd argue that those should not be included, since the concurrencies were intentionally broken.  If there's an intersection, then maybe those should be lined up and concurrencies should be broken with a shaping point instead.
I would argue that these should be included. There's still an intersection, and one should still be able to move from one route to the other via intersecting roads, sliproads, etc.

FWIW, sometimes I've corrected some intentional NMPs to be off by 0.000001 instead of some greater amount, the idea being that they'd someday be interpreted as intersections by an algorithm that would Do Such Things.

I absolutely agree with... both of you :) I'd prefer to include NMPs as intersecting routes because we are used to handled it this way for one year now but it would be fine with me - if there's no "simple" technical solution - to eliminate intentional NMPs and add shaping points instead. I think it should work for all use-cases. However, I don't start replacing NMPs by shaping points right now because I still hope to get a software solution :)

@compdude787: I think HB works fine. I don't see any problem.
Title: Re: Intersecting routes on the HB
Post by: Jim on May 21, 2017, 08:40:17 am
Those who had intermittent problems might have some of the JS code cached.  Try a force reload.
Title: Re: Intersecting routes on the HB
Post by: compdude787 on May 21, 2017, 12:46:20 pm
Those who had intermittent problems might have some of the JS code cached.  Try a force reload.

Okay, thanks, that worked for me.
Title: Re: Intersecting routes on the HB
Post by: yakra on May 25, 2017, 11:57:42 pm
Might be better off if devel routes were omitted.
Whaddaya think?
Title: Re: Intersecting routes on the HB
Post by: michih on May 26, 2017, 09:46:14 am
Might be better off if devel routes were omitted.
Whaddaya think?

I don't think that they should generally be omitted because devel systems are shown in the HB system overview (http://tm.teresco.org/hb) per default. I think the only good solution is to implement a geneal mechanism as described here: https://github.com/TravelMapping/Web/issues/64. Just my 2c though...
Title: Re: Intersecting routes on the HB
Post by: Jim on May 26, 2017, 10:06:52 am
Yes, let me think if there's a not-too-painful way to implement the idea in https://github.com/TravelMapping/Web/issues/64 .
Title: Re: Intersecting routes on the HB
Post by: sipes23 on May 27, 2017, 11:25:01 pm
At first I thought this was kind of a dumb feature to add, so I said nothing figuring it would cause no harm.

I was wrong. It was awesome. I saw it tonight and used it.
Title: Re: Intersecting routes on the HB
Post by: yakra on July 09, 2017, 12:18:28 pm
Just found a bug due to case sensitivity:
Load http://tm.teresco.org/hb/?units=miles&r=ar.us064busalm and click on the east endpoint. Only AR US64 (http://tm.teresco.org/hb/?r=ar.us064) will be shown, as expected.
Load http://tm.teresco.org/hb/?units=miles&r=ar.us064bUsalm and click on the east endpoint. Both AR US64 (http://tm.teresco.org/hb/?r=ar.us064) and AR US64 Bus(Alma, AR) (http://tm.teresco.org/hb/?r=ar.us064busalm) itself are shown.
Title: Intentional NMPs & Intersecting Routes
Post by: yakra on September 16, 2018, 03:25:12 pm
I haven't created a GitHub issue for this, as I don't know whether it'd better belong in DataProcessing or Web.

Consider the following:
tx.us183 @ TX21
tx.tx021 @ US183/130
tx.tx130 @ 461
The first two points have the same coords. TX130 (on the main lanes) has its coords offset to break a false-positive multiplex with US183 (on the frontage roads). Thus US183 & TX21 both list one another as Intersecting/Concurrent Routes. TX130 lists nothing.
I propose listing routes with intentional NMPs (IE, off by 0.000001) as Intersecting Routes, as it should still be possible to get from one route to the other. I can't conceive of any example where this would not be the case. (Does anyone know of any?)
Title: Re: Intentional NMPs & Intersecting Routes
Post by: si404 on September 16, 2018, 04:06:45 pm
I can't conceive of any example where this would not be the case. (Does anyone know of any?)
Rather a lot - check, for example, Bologna and the RA1 (http://travelmapping.net/hb/index.php?units=miles&u=si404&r=ita.ra001), which are free local carriageways outside the A14. Or the B30 (http://travelmapping.net/hb/index.php?units=miles&u=si404&r=espct.b030), ditto with the AP7 (and more junctions on the AP7). There's others, but I frankly can't be bothered to list them all, having shown that there's a good score or more examples where it is the case*.

In my regions, its when the FPs (which I need to mark) are not off by the .0000001 where there's an actual connection (eg a short link road). As such, I strongly oppose this proposal.

The TX example could have off-by-.00000001 shaping point(s) either side to break the concurrency, with the TX130 intersection the same co-ords as the other two roads.

*if it's still up, have a look at Bologna on CHM. Looks terrible!
Title: Re: Intentional NMPs & Intersecting Routes
Post by: yakra on September 17, 2018, 12:10:34 am
The TX example could have off-by-.00000001 shaping point(s) either side to break the concurrency, with the TX130 intersection the same co-ords as the other two roads.
True. I have no choice but to agree with this. (http://forum.travelmapping.net/index.php?topic=2689.msg11364#msg11364) This alone makes my proposal unnecessary.

I still want to argue with the rest of your post, but will refrain from doing so at the moment. :)
Title: Re: Intentional NMPs & Intersecting Routes
Post by: yakra on September 19, 2018, 03:38:17 pm
Consider US87 & US287 in Amarillo TX as a reason against my proposal.
Title: Re: Intersecting routes on the HB
Post by: yakra on October 23, 2018, 10:17:12 pm
Topics merged.

I would prefer that we NOT include routes that are close but don't intersect.
If there's an intersection, then maybe those should be lined up and concurrencies should be broken with a shaping point instead.
The TX example could have off-by-.00000001 shaping point(s) either side to break the concurrency, with the TX130 intersection the same co-ords as the other two roads.

I'm on board with this line of thinking now.
It can be done now, the way the site's already set up.
I've backed off from the "include points off by 0.000001°" proposal michih & I suggested earlier, now that I can conceive of a situation where it'd be a Bad Thing:
Consider US87 & US287 in Amarillo TX as a reason against my proposal.
To dive deeper into this...
Suppose that between TXLp279 and I-40BL/60 there were a point at 3rd Avenue. The two routes don't directly intersect here (It's a bit of a different animal from the main/frontage/sliproad in the TX130/US183 example above); instead they're indirectly connected by very short connecting road.

Reality is a bit murkier, though...
The only points on this section are where other routes in the HB connect.
In a One-Point-Per-Interchange sense, TXLp395 (same for TXLp279) needs to connect to US87, and to US287. Thus US87 and US287 must connect. I can live with this, I suppose. As we Yankees say, you can get theyah from heyah. I can just break the multiplexes with shaping points.

So yeah, while there are no such points currently in these files, I can see wanting to separate points by 0.000001°, and not list another route as intersecting.

However, I don't start replacing NMPs by shaping points right now because I still hope to get a software solution :)
No longer seeing a software solution on-site as feasible, I've started lining up NMPs and adding shaping points. >:-D

If the two edges, PointA <-> PointB and PointA <-> +x5haper <-> PointB differ visibly from one another in Mapview or the HDX, I can see that as being distracting/ugly; I prefer the clean look of overlaying one polyline over the other with as little deviation as possible.
CUZ I'M A HUGE NERD, I wrote a program (https://github.com/yakra/tmtools/tree/master/autoshape) that, given a list of WPT segments, will find the coordinates between existing adjacent points that, at the usual 6 decimal places' precision, deviate the least possible amount from the line directly connecting those points on a Mercator map, and then add a new shaping point to the file.
The Intersecting Routes feature works, Mapview overlays look as they do with the current "off-by-0.000001°" method, and the only difference the average site user should see is that concurrencies aren't inappropriately detected and added to their stats.
You can see the resulting shaping points here (for now). (https://github.com/TravelMapping/HighwayData/compare/master...yakra:nmp)
Thoughts? Comments?