Use turf-buffer without units and projections

[grahamcracker1234]

The options.units of the buffer function can accept "none", allowing a buffer to use the raw geometry without projecting and unprojecting. This is useful when dealing in an exclusive pixel-space which does not necessarily need a projection. It modifies turf-buffer and turf-helpers.

• New functionality
• Have read and followed the steps for preparing a pull request.

[twelch]

I'm glad you were able to make buffer work for you, and much appreciate the time put into the PR. My initial feeling is that unitless is outside the scope of the turf project, which uses GeoJSON at its core, which has a single idea of what coordinates are.

https://datatracker.ietf.org/doc/html/rfc7946#section-4

The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
of decimal degrees.

If another core contributor wanted to advocate for adding this I'm open to hearing it.

[grahamcracker1234]

Thank you for your feedback @twelch.

While I agree, as per the specification, there is a single conception of what GeoJSON coordinates are, it does not always align with how they may be used, particularly in georeferencing tasks where conversion between an item's original pixel-space and its georeferenced world-space coordinates are common. Using features in world-space, while allowing for modification of those features in the original pixel space through transformations like buffer, intersection, union, difference, etc., is a legitimate use case and, in my opinion, completely within the scope of the turf project.

In my experience using this library so far, buffer is one of the only transformations that break when using this temporary pixel-space paradigm; other transformations, particularly the binary polygon operations, work out of the box regardless of whether the GeoJSON coordinates meet the intended specification. In fact, polygon-clipping, which turf uses for its binary polygon operations, specifically states it ignores the specification in some respects:

https://github.com/mfogel/polygon-clipping?tab=readme-ov-file#input

For non-empty results, output will always be a MultiPolygon containing one or more non-overlapping, non-edge-sharing Polygons. The GeoJSON spec is followed, with the following notes/modifications:

• outer rings will be wound counter-clockwise, and inner rings clockwise.
• inner rings will not extend outside their outer ring.
• rings will not overlap, nor share an edge with each other.
• rings will be self-closing.
• rings will not contain repeated points.
• rings will not contain superfluous points (intermediate points along a straight line).
• rings will not be self-touching nor self-crossing.
• rings may touch each other, but may not cross each other.

Given that the specification is often ignored or modified, even if just slightly—usually to match the expectation of how people actually use GeoJSON—I think this use case is acceptable. Turf is a great tool, and even if this ignores the specification, I still truly believe it is well within the scope of the project and should be reconsidered.

Thank you hearing me out, and I would love to hear what other core contributors think.

[twelch]

Thank you. Yes, the use case is absolutely acceptable. I break the rules all the time 😄 The specific question that comes to mind for me is does someone have the interest and time to make sure it works properly and maintain it going forward as a "supported" feature.

[smallsaucepan]

Thanks for proposing this PR @grahamcracker1234. There's a question mark for me over whether this is functionality for Turf.

To make sure I understand "pixel space" first, is that another way of saying unattached to any physical measurement unit or scale, and the coordinate space is flat and uniform? Is there a use case you can describe that might help?

[grahamcracker1234]

@smallsaucepan Yes, by "pixel space," I am referring to a flat and uniform coordinate space unattached to any physical measurement unit or scale. One use case appears when dealing with georeferenced images, with maps being a primary example. These images can have features such as points, lines, and polygons, all of which are positioned locally in this "pixel space."

Ultimately, these features are georeferenced as a result of the image itself being georeferenced, but doing geospatial transformations directly in the flat, uniform coordinate space is often easier to reason about, simpler to maintain, and more intuitive to work with. Allowing for this geospatial task by temporarily working in this "pixel space" streamlines a use case that others dealing with building similar products will appreciate.