search

Turfjs / turf

A modular geospatial engine written in JavaScript and TypeScript
https://turfjs.org/
MIT License
9.35k stars 941 forks source link

Documentation on using Turf for Simple Coordinate Systems #1750

Closed ablakey closed 5 years ago

ablakey commented 5 years ago

I'm trying to use Turf with a lot of GeoJSON data that lives in a 2D planar world with no curvature (and no projection). All map units are in metres, not degrees or whatnot.

Is there any documentation that describes how you go about doing this? I ask because I just tried it out of the box and get some really wonky results when using tools like buffer.

My guess is that I just have to close my eyes and pretend everything is metres, even though the documentation is claiming the defaults to all be in degrees. I'm just hoping that there's nothing clever going on given the assumption that units are degrees (ie. wrap-around, projections, etc.)

If I can get some clarification on this, I would be happy to write a section and PR it for documentation.

Edit: looks like a point at [0, 0] and a point at [100, 0] are 99.88 degrees away. So nothing seems to agree.

morganherlocker commented 5 years ago

I would recommend writing a transform to WGS84 lon/lat coordinates, since all algorithms used in Turf assume this format, per the GeoJSON specification. If you're looking for a library to handle this, I would check out proj4js, which is capable of loading 2 CRS definitions, a coordinate, and performing the conversion.

stebogit commented 5 years ago

@ablakey turf-projection could be useful as well, not sure though if it would be enough for you.

Note: be aware of https://github.com/Turfjs/turf/issues/1602.

ablakey commented 5 years ago

Thank you both for your responses. It sounds like I need to assume turf is expecting WGS84 and so I'll get a lot of wrong measurements and generated data if I don't first project into that. Really weird thing to do given my data is representing a non-georeferencable Cartesian space (robots assuming the world is flat because they drive around indoors).

I'll see what JSTS offers as well, and explore the CPU/mental complexity cost of transforming the data before usage.

morganherlocker commented 5 years ago

@ablakey Hearing a bit more about your usecase, I would lastly suggest giving JSTS a look. It is used by Turf for certain geometry operations involving topology. Whereas Turf is designed specially around geography, JSTS is a more pure geometry focused library, and may be more flexible for the robotics usecase. This especially comes into play when dealing with measurements, which are geodesic and assume a spheroid in the majority of cases in Turf. This is not ideal when dealing with a space the size of a room, due to performance overhead and potential accuracy mismatches.