Avoid geojson types as internal representation

[michaelkirk]

Every time there is a new release of geojson, the types of this crate must be updated.

This isn't a huge problem - you can just keep bumping the geojson crate (82b2373375d8de4a50a26316550e7f380d4bd3a2, 639826348738ad646efc873b881d7b4f68f8fa3d, 520f39d4074b52b94b5a2f5a41cdd324ab3d0ca0) as you have, but really I don't know that there's a good reason to use the types from the geojson crate as your interchange format.

The downsides are, as mentioned above, that it triggers a downstream update cycle, but also those data structures aren't very efficient ways of representing your data types.

Would you consider a PR which leverages internal types detached from the geojson crate for contours?

If you'd like, it could retain an impl Serialize that serializes to geojson or (my preference) add a to_geojson method that explicitly converts your internal types to geojson types for those people who actually want to serialize geojson.

[mthh]

Thanks for your feedback.

Every time there is a new release of geojson, the types of this crate must be updated.

Indeed.

Would you consider a PR which leverages internal types detached from the geojson crate for contours?

Sure !

If you'd like, it could retain an impl Serialize that serializes to geojson or (my preference) add a to_geojson method that explicitly converts your internal types to geojson types for those people who actually want to serialize geojson.

A to_geojson method sounds good.