Turf: Latlng vs LngLat

[peterqliu]

This is a much broader discussion (and one probably too late to have), but have we thought about standardizing latitude/longitude order, at least with respect to how Turf plays with Mapbox.js? I have this in my code (both pairs point to the same geographic point, but are reverse of each other), and always keep second-guessing myself whether I have the order right.

Then again, I'm a noob to GIS and measuring the Earth, in general.

[tmcw]

turf uses GeoJSON and GeoJSON does lon, lat, so turf does too. Shapefiles, GPX, KML, GeoJSON, Shapely, all also do lon, lat.

We can add a note about this to turf docs (basically "this is geojson").

[peterqliu]

@tmcw ah, and what precedent did mapbox.js follow?

[tmcw]

Leaflet's, since it wraps Leaflet. Leaflet followed the precedent of Google Maps.

The split is more or less "GIS, data formats, developer tools = lon, lat" and "end-user-ish-things = lat, lon". Turf falls into the former bin.

[morganherlocker]

We can add a note about this to turf docs (basically "this is geojson").

The "Data" section on the Getting Started page explains this currently http://turfjs.org/examples.html

[tmcw]

Welp, then :+1: done.

[wafisher]

I just spent two hours debugging something because I didn't realize this. I think this should really be highlighted somewhere — reversing lat/long is a very subtle bug that won't throw an error anywhere but will produce wrong results. I'm using Leaflet with this, of course, and that takes LatLng. This is called out just _barely_ in the Data section in the README. Happy to submit a PR to call this out.

[tmcw]

Sure, happy to accept a PR to make this clearer.

[DenisCarriere]

I've had a few moments like this as well, I eventually added a simple validateLngLat function every time a LngLat was passed. This might be a handy function with minimal impact/processing time.

Would this type of function go into @turf/helpers? When the user creates a GeoJSON geometry.

I also agree that Turf should stay with the GeoJSON syntax as LngLat.

point([80, 120]) => throw error
point([120, 80]) => valid

/**
 * Validates {@link LngLat} coordinates.
 *
 * @param {LngLat} lnglat Longitude (Meridians) & Latitude (Parallels) in decimal degrees
 * @throws {Error} Will throw an error if LngLat is not valid.
 * @returns {LngLat} LngLat coordinates
 * @example
 * validateLngLat([-115, 44])
 * //= [ -115, 44 ]
 * validateLngLat([-225, 44])
 * //= Error: LngLat [lng] must be within -180 to 180 degrees
 */
export function validateLngLat(lnglat: LngLat): LngLat {
  const [lng, lat] = lnglat
  if (lat < -90 || lat > 90) {
    const message = 'LngLat [lat] must be within -90 to 90 degrees'
    throw new Error(message)
  } else if (lng < -180 || lng > 180) {
    const message = 'LngLat [lng] must be within -180 to 180 degrees'
    throw new Error(message)
  }
  return [lng, lat]
}

[morganherlocker]

I've had a few moments like this as well, I eventually added a simple validateLngLat function every time a LngLat was passed. This might be a handy function with minimal impact/processing time.

I'm 👎 on this one. The GeoJSON spec is required reading for Turf. Validation helpers add extra overhead that 1) add no benefit if GeoJSON follows the spec, 2) adds extra overhead at runtime when data should already be cleaned/tested (it adds up), and 3) will inconsistently return errors, which causes a false sense of security. Tools like geojson.io make it straightforward to see if data looks the way it should, and most times I have seen people run into issues like this, visualizing the data is a 2 second solution to the problem. \2cents

[tmcw]

Yep, I'm in favor of adding documentation if people believe it will help, but, like @morganherlocker, validating longitude would introduce instability, performance issues, and limitations where there were none before.

Longitude values outside of the normal range are valid in GeoJSON and often used to represent 180th-crossing geometries: we should not ban them.

[wafisher]

Yeah agreed no on validation. Will create a PR to make the long/lat thing more clear, though in the README.

[DenisCarriere]

Make sense, It was simply a suggestions. Lots of quick feedback 👍

[wafisher]

See #516.