URL parameters to store/share route beginning and ending points

[danrademacher]

So the link button works

That would store start and end. Does that create an issue/conflict with hash used for map zoom and center?

[clhenrick]

@danrademacher shouldn't; query params and hash in the URL are treated separately.

We'll probably have something like startLat, startLon, endLat, endLon in the query params. If startLat & startLon are present & validated, but not endLat & endLong, we'll set the start location automatically, and if both start and end lat lon are present & validated we'll set start and end then do the route calculation.

[clhenrick]

The application will successfully load a route if given start and end query params in the URL in the form of:

?start=42.3605679999338&start=-71.0532319996051&end=42.2589364375731&end=-71.800156867074

Where the first start represents the starting latitude, the second start represents the starting longitude, the first end represents the ending latitude, the second end represents the ending longitude.

This convention is subject to change, right now I am going with this method because it's easy to test.

Next to do is to have the app set the start and end location upon successfully searching a route.

[clhenrick]

Ended up switching over to using query string params to simplify things. Now the map zoom and center are stored under loc and the route start and end are stored under route, each having comma separate variables.

For example:

?loc=10,35.78161,-78.79257&route=35.89466,-78.95350,35.77823,-78.63822

will load the app with a start and end location, then the app will find the route between the two locations.

Without route the query params for loc will set the map zoom and center:

?loc=12,35.84189,-78.83926

which can be used for state pages in the main Greenway site.

However, we may want a separate page in the app that can be linked to that is more "embed friendly", e.g. doesn't have the app's UI and navbar so that when the map is embeded elsewhere it doesn't try to function as both a trip planner and state page overview.

Let me know what you think about this last part @danrademacher and @nilesbarnes.

[danrademacher]

Pulled out the standalone state page to #53 as an Enhancement since it wasn't part of original proposal/scope. But we have a good plan if it proves feasible.

[clhenrick]

Enabled copying of URL to clipboard. Currently an "alert" message will display to the user to let them know they've successfully copied the app URL to their clipboard or if their browser doesn't allow for copying in such a manner (very few browsers will prevent this). Ideally we'd create a custom UI for this message such as a modal. We can revisit this if there's time for an enhancement.