make a breaking change to swap to lon/lat order

[andrewharvey]

For consistency with GeoJSON, GL JS we should bump the major version number and swap to lon/lat order.

[agoddard]

The current order is to match the polyline spec I believe, but it's maddening because there's not much consistency between libraries/tools doing polyline encoding/decoding. I wonder if an argument to flip coordinates would help too, so that you can decode polylines encoded with tools that use lon/lat (or lat/lon if the default here becomes lon/lat)?

[jayenashar]

looking at https://github.com/mapbox/polyline#example , encode() is the only one i might change. i believe the polyline itself should match google's way, because i believe that is the most common way to use this library.

alternatively, you could add a parameter to each function like options: {order: 'xy' | 'latlong'} with the default being backwards-compatible.

[andrewharvey]

I should have been clearer, yes I'm only proposing to change the coordinates you pass encode and the coordinates you receive from decode, and not changing the resulting/supplied polyline encoding format. I think the argument/option to specify order is not needed. Most tools now use lon,lat order so if we follow that convention here it keeps things simpler.

Having an option and keeping the default for backwards compatibility is not worth it in my opinion.

[jayenashar]

"Most tools" really depends on the ecosystem you're in.

Another option would be to deprecate/remove the encode/decode functions, and make everyone use the unambiguous toGeoJSON and fromGeoJSON.

[andrewharvey]

"Most tools" really depends on the ecosystem you're in.

True. I'm mostly referring to Turf and GL JS here.