Cropping of starting and ending segments

[gregallensworth]

This one is a lower priority, since we have other data cleanup and UI stuff to work out. Don't move on it, unless we end up with surplus budget.

Consider a case where the ending point was North 14th Street, on the right-center of this image.

The entire segment is used, despite not ending at the desired location. This "extra" comprises about a mile.

In practice, the expectations here are not too high and this is likely acceptable. But as a possible phase 2 improvement:

• [x] Select the nearest point along the segment's linestring, and the relevant segment of the linestring.

• [x] Trim the remainder of the line (the beginning of the first segment, end of the last segment) based on the individual vertices becoming nearer/further....? TBD

• [x] Recalculate the new length of the starting and ending segments, since their reported length from the database is for the whole segment.

[danrademacher]

To be clear, only the clipping segment part is low priority, right? Finding a starting point is required. But our original plan of “find cue point nearest to the location user searched” is no longer valid, since we’re collapsing almost all cue points into the routing module's calculated values. So maybe we need a method of "find nearest segment" to user-supplied start and end?

Does this match your understanding, @clhenrick?

[gregallensworth]

• Yes, this fits into the "possible refinement, time permitting" category and is beyond the existing functionality.

• Current technique is that the closest segment to the selected start-latlong and destination-latlong, are used. This has been in place since the very first line of code was written in regards to routing.

[nilesbarnes]

This seems to have a relatively small impact on long searches but fairly significant impact on shorter searches.

[nilesbarnes]

@danrademacher I think if Greg could spend up to 4 hours of maintenance time to see if he can address this it would be helpful.

[gregallensworth]

Internal note: In the set of demos I have currently set up, some examples:

• The Pierson, FL to Kingsland, GA demo exemplifies this: the starting segment 1000682 CR 3 at Pierson, about 2/3 of its 13 mile span is south of the desired direction. Ideally only the northern 1/3 of that starting segment (3 - 4 miles) would be used.

• The Machias, ME to Calais, ME route, starting segment is 657262 Free Street and most of this should be omitted, with the start much closer to the intersection at Colonial Way.

• The Trenton to Bronx path, the ending segment at Bronx 659528 Pelham Greenway is 1.8 miles in length, only a small part of which is prior to the desired ending. The 3 extra sample points should be shaved off and this should be about 0.4 miles in length.

• The Machias, ME to Calais, ME route, the ending segment 781152 South St is 1.7 miles in length, and should be clipped to about half that. 6ish sample points, about 0.8 miles.

• The Providence, RI to Eastham, MA is a good example of an ending segment which would benefit from clipping.

[gregallensworth]

Give this one a look. It looks to be spot-on with what we need: start/end segments now clip to the on-trail start and end points, and distances are recalculated for directions reporting.

[danrademacher]

confirmed locally:

Was 169 miles.

Trenton to Bronx Path shaves off 4 miles:

And Providence to Eastham:

[nilesbarnes]

Looking good! @gregallensworth and @danrademacher Here is an example right at our HQ office (starting point) to downtown Durham. https://ecg-map.herokuapp.com/?loc=12,35.95948,-78.96371&route=35.92176,-78.93047,35.99598,-78.90156

[danrademacher]

And here's that with the fix in place:

[danrademacher]

Just deployed:

Try that link again, @nilesbarnes

[nilesbarnes]

Great! Thank you @danrademacher and @gregallensworth Much improved user experience.