Michael Kirk

> The ser. support is awesome! It should address https://github.com/georust/geojson/issues/176 too, right? Unfortunately, it's probably not much of a performance improvement at this point. In fact, it might be worse...

> Could we get a short doc string here so it's visible in the docs? I've done this in https://github.com/georust/geojson/pull/199/commits/493463eb9bea7856ae4f04656cdfa06c228956bb And then I realized that the short doc string was...

> should we call out this functionality early on in the "main" docs? Done in https://github.com/georust/geojson/pull/199/commits/413b959add564933ef7e1ee76da1a1ed3836834b

I pushed up some examples/* as documentation and to facilitate memory profiling. I've gotten a couple approvals and only pushed up some non-controversial(I think) followups, so I'll plan to merge...

bors r=urschrei,rmanoka

Just peeping on your WIP. 👀 Is there any reason to continue supporting vec other than avoiding breaking the old API? For new code, the coord based approach seems strictly...

> Yes, but if you're implementing the GeozeroDatasource trait directly on Arrow structs, you won't be able to do that from a third party crate. If you're creating your own...

I get the instinctual reaction that "crashing our client's app is bad", but I personally don't think that all errors should be translated to run-time errors. In particular, I think...

The existing API's serializing a FeatureCollection directly is still expensive `serde_json::to_string(FeatureCollection)`, but there are now alternatives like `FeatureWriter` and `FeatureReader` which should work for many use cases, while consuming much...

Fixed by https://github.com/seanmonstar/reqwest/pull/1372 ?