I'm not sure whether there's interest in this, but this is an FFI module, allowing anything which can do C-type FFI to access the encoding and decoding functions, via a .so/.dylib/.dll. There are docs, tests, and I've written a Python package which uses the bindings.

Other things: the docs are extensive, but the examples are in Rust, which is somewhat pointless. Compact examples using other languages (js?) would be great.

👋 Hi @tmcw, you are the only "user-owner" of the polyline crate on crates.io, so only you can edit that crate's owners on crates.io.

Following up on https://github.com/georust/meta/pull/21, I created a new polyline-publishers team for publishing to crates.io with you as maintainer.

Could you please update the crate owners? Specifically:

• [x] update polyline crate owners on crates.io:

cd polyline

# 💥 remove large publishing group
cargo owner --remove github:georust:core

# 🔐 add small publishing group
cargo owner --add github:georust:polyline-publishers

# you're currently the only user-owner of the crate. Consider adding another user-owner, 
# that way if for some reason you become inaccessible we have someone else who can edit the owners. 
# See https://github.com/rust-lang/crates.io/issues/2906
cargo owner --add <username>

# make sure everything looks good 👀 
cargo owner --list

If there's anyone else you'd like to be able to publish the crate, feel free to add them to your publishing team, or as a user-owner. Consider that user-owners, as opposed to owners-via-team, can themselves edit the crate's owners, which could be desirable, or not, depending.

In particular, it looks like @urschrei has been actively contributing to GH. Once you switch the publishing team, @urschrei (or anyone else) won't be able to publish until either they are added back to the publishing team or added as a user owner.

Let me know if you have any questions, or you can review https://github.com/georust/meta/pull/21.

Right now, encode_coordinates looks like:

pub fn encode_coordinates(coordinates: &[[f64; 2]], precision: u32) -> Result<String, String> {
    ...
}

We don't need the entire slice at once, we just need anything that can iterate over coordinates:

pub fn encode_coordinates<C>(coordinates: C, precision: u32) -> Result<String, String>
where
    C: Iterator<Item=[f64; 2]>
{
    ...
}

And maybe it makes sense to pull in the geo-types crate to reuse our common Coordinate construct:

pub fn encode_coordinates<C, T>(coordinates: C, precision: u32) -> Result<String, String>
where
    C: Iterator<Item=Coordinate<T>>
{
    ...
}

This is both more flexible and potentially more efficient, since slices require a single pointer dereference, and Vecs require two.

It also has the (potential) benefit of simplifying FFI interaction, since it's easier and more efficient to create slices than Vecs from pointers to data allocated outside Rust.

Addresses Clippy warnings concerning potentially lossy conversions, and replaces String with &str in decode_polyline, which makes for a more pleasant API.

This PR removes the last of the unwrap() calls (forgot to push that commit last time – sorry) and adds:

• A test for invalid string input
• Latitude and longitude bounds checking for the coordinate encoder, and a test.

encode_coordinates() and decode_polyline() now cope with the possibility that a u32 can't be encoded as a char, or that your .nth() operation could fail because index is longer than str (the latter is unlikely, but here we are).

This also means that your public functions now return Result types, which allows their consumers to be a bit more flexible.

This adds a test and fix for a rounding error condition, when two coordinates are very close to each other, so that the difference is below precision.

The current implementation would produce wrong characters, because the sign of the original subtraction would differ from the rounded subtraction.

This PR changes the comparison to just use the sign of the rounded subtraction, see polyline.js for comparison.

This PR switches the encode/decode API to use the Coordinate and LineString types from the geo-types crate and should fix #13.

As this is my first PR for such a switch it might not be idiomatic. So I'm looking for feedback. The benchmarks and tests now include a .clone() for the input, because the iterator now owns the provided coordinates, instead of references to f64 pairs. Is there a way around this? Is this ok?

This PR also contains #15 and #17.

Although polyline also uses LineStrings, these can be primitively represented without too much trouble. Should we thus adopt a similar strategy to the proj crate, enabling geo-types compatibility by default but allowing a more simple option for consumers who don't want or need the overhead?