Snap to OSM doesn't always cross junctions

Jordan Brown's Avatar

Jordan Brown

06 Aug, 2018 12:27 AM

Consider this map.,-118.56088&z=19&b=mbt
Add New Object > Add Line.
Confirm Snap To: OSM
Click above the junction at 34.3527, -118.5607.
Hover toward the junction; observe that it snaps properly.
First, observe that (depending on initial zoom, it seems) it won't snap on either the left or bottom side of the junction.
If you zoom out a bit, snapping starts working.
Now try to snap left of the junction. Observe that it takes the long way.
Try to snap below the junction. Observe that it again takes the long way.
It is as if the trail above the junction does not connect to the other two.

OK, so the OSM data isn't perfect. But I went over to OSM to fix it, and found that there's a single junction point, and if you move that junction point then all three trails move.

  1. Support Staff 1 Posted by matt on 08 Aug, 2018 02:39 AM

    matt's Avatar

    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.

  2. 2 Posted by Jordan Brown on 08 Aug, 2018 10:52 PM

    Jordan Brown's Avatar

    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.)

    If I start at (or refresh at),-118.56059&z=19&b=mbt
    then it won't route at all from the right branch to the left or lower
    branches.  If I zoom out two clicks to,-118.56113&z=17&b=mbt
    then it'll route, but it goes around the loop the wrong way.

    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,-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.

    Again, far from critical.

    Thanks for all you do.

  3. Support Staff 3 Posted by matt on 08 Nov, 2018 03:12 AM

    matt's Avatar

    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.

  4. matt closed this discussion on 08 Nov, 2018 10:15 PM.

  5. Jordan Brown re-opened this discussion on 09 Nov, 2018 03:50 PM

  6. 4 Posted by Jordan Brown on 09 Nov, 2018 03:50 PM

    Jordan Brown's Avatar


    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.

  7. Support Staff 5 Posted by matt on 09 Nov, 2018 09:32 PM

    matt's Avatar

    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.

  8. Jordan Brown closed this discussion on 20 Jan, 2019 10:42 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac