Michael Kirk

Maybe a dupe of https://github.com/netvl/xml-rs/issues/155

So it seems that this is a known issue - xml_rs explodes when encountering a BOM. The author prefers that, since the BOM exists "outside of the xml", this should...

Oh man, the plot thickens. Maybe we shouldn't just get rid of `HaversineIntermediate`, because there are sibling traits: `GeodesicIntermediate` and `RhumbIntermediate`. I don't have a solution yet and have run...

I spent a while trying to understand our existing "measurement" traits - see the new table in the issue description. It exposes a bit of overlap, some inconsistencies, and some...

Next up, I want to collapse these into some kind of conceptual "metric space" trait: (WIP) I don't know that it will actually be implementable as such, but if nothing...

I've rescoped this issue a bit and fleshed out some of the details. I hope to have the first PR improving (I think!) the situation by the end of today.

> Don't forget EuclideanLength et al. It's in there! We don't currently have implementations for all the algorithms for Euclidean, but I'd like to add them in a followup. >...

I'm going to re-open this as a tracking issue since there are several other things I'd like to accomplish under this umbrella. I'll update the description soon.

Here's my rough and dirty impl ```rust use geo::{ algorithm::{HaversineDistance, HaversineIntermediate}, geometry::{Coord, LineString, Point}, }; pub struct HaversineSegmenter { geometry: LineString, next_index: usize, } impl HaversineSegmenter { pub fn new(geometry:...

Probably I could do it with a borrowed LineString rather than owned, and store only the single temporary intermediate point from the last iteration.