Corey Farwell
Corey Farwell
> are not discoverable (you need to read the docs or the implementation instead of relying on auto-complete)
And no plans to deprecate the public fields in the structs, if users want to create them that way.
From the GeoJSON spec: ``` o A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise....
> > Does that sound right? 🤔 > > Yep, that's my understanding! Good idea on the winding-order crate if it gives us a compilation speedup… So considering we'll need...
This should either return a better error, or we should gracefully handle cases where the user passes in something that isn't a feature collection
a couple relevant issues in the popular json libraries: - [`serde-rs/json#526`](https://github.com/serde-rs/json/pull/526) - [`maciejhirsz/json-rust#143`](https://github.com/maciejhirsz/json-rust/issues/143)
Potentially 25% faster
> Is there any reason to continue supporting vec other than avoiding breaking the old API? > For new code, the coord based approach seems strictly better, right? > >...
> And in the future, after some dust has settled and we feel good about this design, we can change the default from `Vec` to something else like `(f64, f64)`....
Potentially relevant mapnik issue: https://github.com/mapnik/mapnik/issues/4313