Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation on using Turf for Simple Coordinate Systems #1750

Closed
ablakey opened this issue Aug 23, 2019 · 4 comments
Closed

Documentation on using Turf for Simple Coordinate Systems #1750

ablakey opened this issue Aug 23, 2019 · 4 comments
Labels

Comments

@ablakey
Copy link

ablakey commented Aug 23, 2019

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
Copy link
Member

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
Copy link
Collaborator

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

Note: be aware of #1602.

@ablakey
Copy link
Author

ablakey commented Aug 23, 2019

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.

@ablakey ablakey closed this as completed Aug 23, 2019
@morganherlocker
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants