Add coordMap function to complement coordEach

[cyrilchapon]

Explaination

Hey :)

Yesterday, searching for a tool to loop and map over coordinates, I did not succeed to find one.

The idea was basically simple : loop over all coordinates, and map each of them with a new item (new position, i.e); but the key part is leaving the whole geojson object untouched

I can think of 3 example use-cases, including mines :

• Reproject a whole GeoJSON object
• Remove z ([lng, lat, z]) from coordinates in a whole, dirty, GeoJSON object
• Round coordinates to 6 decimal places into a whole GeoJSON object
• (do the 3 previous operations in a single motion, to improve performance)

I found coordsEach (which just loop), coordsReduce (which would suffice to recompose a new geojson, with indexes and stuff, but would not be very readable), and perliedman/reproject (which is too linked with reprojection stuff, and provide a too-rough cloning strategy IMHO). FYI I opened an issue there to propose extraction of "mapping coordinates logic" in another repo.

I ended up implementing it myself, but I think it could be a great addition to @Turfjs 😄

Here is it : traverse-geojson

I used some gjtk tools, and the implementation is very basic. I'd like to use @Turfjs formalism and helpers (invariants, etc.), but I'm not really used to it.

---

API

coordsMap(input, transformer) => returns output (same shape as input)

Params

• input : GeoJSON (FeatureCollection<Any>|Geometry<Any>|Coordinates<Any>|Position|GeometryCollection)
• transfomer : function(position) => returns transformedPosition
  • position : [lng, lat[, ...rest]]
  • transformedPosition : any, ideally a position
• output : GeoJSON<Any>, exact input deep clone, with only coordinates mapped through transformer

---

Questions :

Is that a good idea ?

Could it be integrated into turf ?

What about also featuresMap, which would basically do the same stuff, but with features ?

[stebogit]

Hey @cyrilchapon, thanks for the suggestion.
I am personally a supporter of the idea of completing the already available "Array like" functions we have in Turf, i.e. adding .coordMap and/or .featureMap methods. 👍
There is an open discussion about a similar topic.

Feel free to send a PR and we'll see if we can reach the quorum to merge it to master. 🤞

Note: we (namely @rowanwins) are currently working on a quite significant renovation of the entire repo, so it might take a while before we take in account new modules/functions.

[cyrilchapon]

Well, it may be a good start to do it in the formalism you want to introduce inside v7, and maybe PR directly there ?

I need help on it though. Maybe another contributor than yourself can help me accomplish this ?

[rowanwins]

Hey @cyrilchapon

So I'm just trying to understand why the existing coordEach isn't suitable? So for example we use coordEach in our truncate module here. We have an option on truncate called mutate which specifies whether you mutate the input or not.

[tmcw]

Untested, but this would be the general direction of implementing each suggestion. And, yes, this mutates the data, but... just clone the data ahead of time, which is just the same as what a function would do internally.

Reproject a whole GeoJSON object

coordEach(object, coord => {
  const p = reproject(coord);
  coord.length = 0;
  coord.push(...p);
});

Remove z ([lng, lat, z]) from coordinates in a whole, dirty, GeoJSON object

coordEach(object, coord => coord.pop());

// safer if only some have a z
coordEach(object, coord => {
  const [x, y] = coord;
  coord.length = 0;
  coord.push(x, y);
});

Round coordinates to 6 decimal places into a whole GeoJSON object

coordEach(object, coord => {
  for (let i = 0; i < coord.length; i++) coord[i] = parseFloat(coord[i].toFixed(6));
});

[cyrilchapon]

Hey @rowanwins and @tmcw, basically because those algorithms are mutative and not really readable.

It's 2018, ES6 is here, and non-mutative mutations are well known now, and purity should not be seen like a compromise to performance.. So basically "const input = options.mutate ? geojson : deepClone(geojson)" then performing a rough mutating algorithm doesn't seem very ok to me.

The question was not about "is that possible with the current state of art", the question was "would it be a great addition to the lib ?"

If you want you can check my implementation inside aforementioned repo, you'll understand

[rowanwins]

Hey @cyrilchapon

the question was "would it be a great addition to the lib ?"

I think we're just trying to understand why it would be a great addition. To be honest I'm struggling to see a little bit why it is. We've got an existing module that can be used to pretty much do the same thing, admittedly using a slightly different approach. I've taken a look through your repo and it does make sense, I'm not arguing that. The main downside I see of your proposal is that it adds more surface to the turf codebase to test and maintain when we can already achieve much the same result.

It's 2018, ES6 is here

Currently TurfJS doesn't use ES6 features, we don't use babel in transpiling any code. That's not to say it wont happen, we are for instance currently implementing ES6 modules.

I don't think we're trying to be difficult so sorry if it feels like that.

[cyrilchapon]

Hey @rowanwins, sorry for being a bit difficult to, bad night 😜

We've got an existing module that can be used to pretty much do the same thing, admittedly using a slightly different approach

The main downside I see of your proposal is that it adds more surface to the turf codebase to test and maintain when we can already achieve much the same result.

Well, what I understood about turf.js, and I've been using this for like 2 years, importing like 60% of it's modules; the point seems to be abstraction, centralisation and simplification of complex geographic stuff (usually already available in various modules accross the web)

Think of it, we have coordsEach, okay we can loop. Why did someone develop coordsReduce on the first place ? After all, the same thing can be accomplished with coordsEach... but (except maybe arguing that coordsReduce is used in other turf modules), the concept of reducing is something one Javascript developer typically use way less than the concept of mapping

If coordsReduce was a good addition, I think we can argue that coordsMap would not only be a consistent choice to follow that logic (I.E kinda reimplementing "array functions" deeply in geojson objects); but could also be more useful.

Currently TurfJS doesn't use ES6 features, we don't use babel in transpiling any code. That's not to say it wont happen, we are for instance currently implementing ES6 modules.

This is another topic indeed, and I could argue in ES6 (even ES2017) stuff but maybe somewhere else than in that issue. There are 2 discussions here :

• The feature on its own
• The syntax of implementation

The point is "the syntax when using it" is part of "the feature", and not "the syntax of implementation" if you follow me. I, being a little bit narrow minded, am not found of :

• Making a choice between "Roughly deep cloning" or "mutating" an object when I need a map
• Having this in my codebase :

coordEach(object, coord => {
  for (let i = 0; i < coord.length; i++) coord[i] = parseFloat(coord[i].toFixed(6));
})

---

By example

Arguing that the API, and readability and syntax of usage is part of the feature, see

Reproject a whole GeoJSON object

const reprojected = coordsMap(
  geojson,
  coords => reproject(coords)
)

Remove z ([lng, lat, z]) from coordinates in a whole, dirty, GeoJSON object

const reprojected = coordsMap(geojson, coords => coords.slice(0, -1))

// safer if only some have a z
const reprojected = coordsMap(geojson, coords => coords.slice(0, 1))

Round coordinates to 6 decimal places into a whole GeoJSON object

const reprojected = coordsMap(
  geojson,
  coords => coords.map(
    coord => coord.toFixed(6)
  )
)

[tmcw]

I'm the original author of turf-meta, so, I'll at least explain that part:

turf-meta wasn't initially designed as a convenience module, or a simple abstraction. turf had a lot of modules that claimed to take 'geojson' as input, but in reality they only accepted one type of geojson (like a featurecollection), or weren't able to handle certain atypical forms (like null geometries). turf-meta was designed and written to be a near-zero overhead module that ensured that people could write turf modules as robust by default, instead of slowly discovering the various other forms of geojson that don't immediately come to mind.

This original intent is why, for example, I've typically opposed efforts to improve the ergonomics of turf-meta, unless they can clearly be accomplished without any performance penalty. A performance problem in turf-meta would ripple out to the rest of turf, making lots of other functions slower. Which would be true of any effort at immutability: mapping an array into another array requires more memory and is slower than iterating and mutating an existing array, and there's no way JavaScript will be able to change that, ES9 or beyond.

---

Anyway, not to get all opinionated about this stuff: something like coordMap would be fine if a majority of folks want it and someone's interested in maintaining it. But it probably shouldn't be part of turf-meta, because its intent and behavior would be different, and probably shouldn't be named coordMap, because it's more like transformCoords or something - given the signatures of coordEach and coordReduce, you'd expect it to return coords, not a geojson object.