Why does a buffered point result in a oval?

[djdmbrwsk]

I know there is probably some geographical/mathematical reason, but why does a buffered point result in a oval polygon? Thanks!

[djdmbrwsk]

Oh duh. So if your Point has coordinates: [0, 0] you get a perfect circle. The reason i'm getting an oval is because I'm in the Northern hemisphere. Great library, thanks for all your hard work!

[morganherlocker]

Thanks! You guessed it though, the issue is that web maps typically use projections that distort shapes the closer they get to the poles. Let me know if you run into any other issues or have any feature requests; feedback is always very helpful.

[djdmbrwsk]

Well I thought I understood this, but I guess not.

When I create a polygon at [0, 0] using turf by buffering it, it is perfectly circular. That makes sense because when projecting a spherical map to a flat surface there is less distortion at the equator. If I create the same polygon at a Boston lon/lat the result is an oval (even if it's just a 5 mile buffer). Because of map projection scaling shouldn't I really only see distortion on very large polygons? And when I do, assuming they're circular, shouldn't they look like an upside-down egg?

[morganherlocker]

I will need to explore this some more, but I think that the issue comes from using 4326 lat,lon data and projecting it over to 3857 (what most web maps use under the hood). One thing to try would be transforming your data over before buffering using something like proj4js. It is my understanding that the distortion in 3857 is actually pretty significant, and that you would see this sort of thing even at 5 miles.

[djdmbrwsk]

This has opened up a can of worms for me. I've been doing a bunch of reading and these different projection standards are quite confusing. But from what I've gathered so far though 4326 is like the standard, and as such most web map APIs take 4326 as input and translate it to whatever they need to display it (mainly 3857). Does that sound right?

If that's the case I wouldn't think I would have to do anything, but there is definitely something funky going on here.

[atdrago]

@morganherlocker I admittedly don't know as much about this stuff as you do, however I was looking at JTS (the parent of JSTS), and it seems like it is built for a 2d, linear plane. From the JTS site:

JTS provides a complete, consistent, robust implementation of fundamental algorithms for processing linear geometry on the 2-dimensional Cartesian plane

I created a little test that takes in @djdmbrwsk's GeoJson file and buffers the reference point (instead of using the feature collection he provided), and then computes the distance to each vertex of the buffered polygon. The points created should seemingly be 3 or close to it, however they fluctuate between 3 -> 2.2 -> 3 -> 2.2 -> 3, which is the oval shape he is talking about.

[atdrago]

I believe I have the buffering of a Point working now, using LatLon.prototype.destinationPoint from this blog to move in a circular direction around the point at a given distance, at a fixed number of points along the circumference of the circle to create a circular shaped polygon:

https://gist.github.com/atdrago/08a42bac9f887243b8d5

I'll try to get Polygon buffering working tomorrow using similar concepts.

[morganherlocker]

This is terrific, and that post is very helpful. Polygon buffers get pretty tricky when you get into complex polygons, but full geodesic buffers would be a huge win. I think you are definitely on the right track.

[djdmbrwsk]

@atdrago Thanks a ton for running some tests to help get to the bottom of this!

@morganherlocker Before we get too deep, you are looking for turf to be a truly geodesic library correct?

[morganherlocker]

@djdmbrwsk Yes. We may want to support planar for some reason in the future, but I think geodesic makes the most sense, and is definitely what people are expecting. Turf is specifically for geospatial data, not geometric data.

[djdmbrwsk]

I saw there was a bunch of organizational/clean up activity today, nice! We should probably mark this issue as a bug...it's a pretty nasty one. I know @atdrago has point buffering working geodesically and he's working on polygons, but I don't know how far he has gotten.