matt on 08 Aug, 2018 02:39 AM
I don't seem to have any trouble snapping ot the line, at any zoom level.
If you zoom in far enough and start drawing, you can see that the highlighted yellow lines don't quite touch. This is a common problem and I have a bunch of code that tries to address it based on proximity; the delta is small enough that it should be snapping, regardless. But although unlikely, I wonder if it was changed in OSM since my last snapshot.
I'll take a look at this case specifically, since it should be bridging the gap at that distance regardless of whether the lines share a vertex. But it's going to be a little while before I have time to do so.
Huh. The behavior I described is quite repeatable for me, in either
Firefox or IE. (I just realized that my instructions may have been
ambiguous; the problem is in routing from the branch at the top right to
either the branch below or the branch left-and-north.)
My bet is that at the high zoom levels you haven't loaded enough of the
track data to "see" the route around the loop the long way, and that
once you've loaded that data you can route that way.
Yes, I see that the yellow lines don't touch. I also noticed the black
dot just northeast of the junction; I suspect that's the end of the
right fork. That is what led me over to OSM to try to fix it.
I totally understand that you are at the mercy of your data providers.
The only reason that I brought this up is that your behavior didn't seem
to match the OSM data. I didn't know that you used snapshots of OSM; I
assumed that it was live retrieval. My bet is that it's changed.
And of course this is low priority and there will be higher priority
things to work on.
So I wondered whether you had a general problem at three-way junctions.
Seemed unlikely, but always possible. I found something trivial but
interesting. Starting at
https://caltopo.com/map.html#ll=34.36083,-118.5621&z=20&b=mbt try routing from the north (top) branch to the east (right) branch.
Look at the path that results. Observe that the line from the north goes
down into the center of the black dot, then turns to the *west* to the
left edge of the black dot, then turns east out along the trail.
Looking at the OSM data, it appears that there's a node at the junction,
and another node (solely on the horizontal trail) just left of that. It
seems that (for whatever reason) you're routing through that node that's
just left of the actual junction.
matt on 08 Nov, 2018 03:12 AM
Finally managed to fix an auto-draw bug from where one line abuts another (ie the end of A touches the middle of B). Thought that was the issue here, but it turns out it was simply because the two lines' bounding boxes didn't quite overlap.
I see that the problem case that I pointed out is working OK now. So
was that an instance of the bug you describe, or was it a problem with
the OSM data that's fixed in a later snapshot?
I tried the second case I mentioned, the strange little tail at at the
Elder Loop junction. It's still there, but the tail is tiny and points
south rather than west. Obviously that's a non-issue for practical
purposes, but you might consider taking a look at it to make sure you
understand what's happening.
matt on 09 Nov, 2018 09:32 PM
When I went back I hadn't noticed that tucked away at the bottom of the email. Whether it does on OSM or not (looks like not), the snap-to taylor loop line does extend a hair south of elder loop. Not sure if that's due to the way things are processed in the app, or if it's coming out of the database that way.