• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

r? @urschrei

This is a couple separate but related things...

The main new functionality is that you can call Geometry::from(wkt)

Along the way, I replaced the Try/Into impls with Try/From. We should prefer TryFrom where possible since it is sometimes nicer to use and also gives you the TryInto impl for free.

Correspondingly, I deprecated methods like try_into_geometry in favor of geometry.try_into which I think is more discoverable.

One thing I was curious about - I think conventionally conversions are done via move, so the caller is responsible for any cloning, but previously all our conversions were done via references and our impls were creating new points for everything. That seemed a little strange to me, so I implemented all the new ones with the move semantics that I'm used to. I did leave the existing functionality (but rephrased them as From) so as not to break the API.

A couple potentially controversial things I'll call out inline...

Attempt to close #33. I based this off of the conversion implementation in geojson and only used generic types for converting to geo_types objects

Initially I tried to update the From trait implementation, but I used Into instead because updating From gave me the following error:

type parameter `T` must be used as the type parameter for some local type

If I missed something that would make From work instead I can make that change. Let me know if I should change that or anything else here, thanks!

• [x] I agree to follow the project's code of conduct.
• [ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• [x] I ran cargo fmt

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• [x] I ran cargo fmt

Uses a SPDX license expression as recommended by Cargo.

This enables e.g. parsing via the CycloneDX Rust Cargo Plugin.

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• [x] I ran cargo fmt

Fixes #55 - adds an easier API to serialize a geo-type.

~~Depends on #86, so merge that first.~~ Merged!

~~partially conflicts with #88, because I'm relying on the ToWkt trait.~~ superseded!

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• [x] I ran cargo fmt

addresses #73 and #48.

This adds impls of From for every type and the Geometry enum in geo_types. It makes it unnecessary to bring to scope the ToWkt trait which gets deleted because it was not being used actually. Of course this is a breaking change.

Additionally I added some docs on the most relevant cases for this crate: parsing a wkt and getting a geometry and having a geometry and getting its WKT string. This is what actually motivates most of the PRs I've been doing, I just wanted to do that .-.

Some opinions

What if Wkt was instead a trait itself, implemented for every type in geo_types that provided a single method: wkt(&self) -> String?

being georust an environment for building geo applications it makes sense that things are integrated to work well within the environment, and maybe providing some LineString etc. traits which, if implemented on foreign types would give automatically a Wkt impl that allows to get its WKT string. And perhaps a WktGeometry enum with inner types refering to those in the geo_types crate just for the purposes of having something to parse a string into. Although it probably makes more sense to just have FromStr impls for the geo_types themselves...

Just an idea, I think it would simplify a lot how work with this crate happens.

This actually requires #86 for the docs to pass the tests

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

to address #83 and make it easier to go from Wkt to string representation. Includes test

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.

DRAFT: depends on https://github.com/georust/geo/pull/614 being released first.

Add TryFrom for converting directly to geo_types::Geometry enum members.

let ls: geo_types::LineString = geo_types::LineString::try_from(wkt).unwrap();

Previously it was:

let geom: geo_types::Geometry = geo_types::Geometry::from(wkt).unwrap();
let ls: geo_types::LineString = geo_types::LineString::try_from(geom).unwrap();

This introduced two new error cases, so I've also introduced thiserror which solves #49

FIXES https://github.com/georust/wkt/issues/49

I was trying to write a geo-type as WKT to file, and this is what I came up with:

    let points = include!("../src/algorithm/test_fixtures/louisiana.rs");
    let geo_linestring: geo::LineString<f32> = points.into();
    use wkt::ToWkt;
    let wkt: wkt::Wkt<_> = geo::Geometry::from(geo_linestring).to_wkt();
    let wkt_linestring = wkt.items.first().unwrap();
    let serialized = format!("{}", wkt_linestring);
    println!("{}", &serialized);

Is there already better way?

I was hoping for something like:

    let points = include!("../src/algorithm/test_fixtures/louisiana.rs");
    let geo_linestring: geo::LineString<f32> = points.into();
    use wkt::ToWkt;
    let wkt: wkt::Wkt<_> = geo::Geometry::from(geo_linestring).to_wkt();
-   let wkt_linestring = wkt.items.first().unwrap();
-   let serialized = format!("{}", wkt_linestring);
+   let serialized = wkt.to_string()
    println!("{}", &serialized);

Or like serde_jsons::to_writer

    let points = include!("../src/algorithm/test_fixtures/louisiana.rs");
    let geo_linestring: geo::LineString<f32> = points.into();
    use wkt::ToWkt;
    let wkt: wkt::Wkt<_> = geo::Geometry::from(geo_linestring).to_wkt();
-   let wkt_linestring = wkt.items.first().unwrap();
-   let serialized = format!("{}", wkt_linestring);
+   let file = File::create("/tmp/foo").unwrap();
+   let mut writer = BufWriter::new(file);
+   wkt::to_writer(&mut writer, wkt);
    println!("{}", &serialized);

Any thoughts?

• [x] I agree to follow the project's code of conduct.
• [x] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.
• [x] I ran cargo fmt

Fixes https://github.com/georust/wkt/issues/102

~~This is based on #101, which @rmanoka already approved (thanks!), but I'm going to wait just a bit longer to merge it in case someone else wanted to take a look at it.~~ update: #101 has been merged, and this is ready for review!

I'd like to get the next release out.

If possible, I'd like to include https://github.com/georust/wkt/pull/103 since it's the logical compliment to the already merged but unreleased https://github.com/georust/wkt/pull/101

Can someone take a look?

And anything else we should wait for?

I'm not sure if we should support this, but I wanted to at least gather some facts for documentation.

postgis supports it:

SELECT ST_AsText('TRIANGLE((0 0,0 1,1 1,0 0 ))');
          st_astext          
-----------------------------
 TRIANGLE((0 0,0 1,1 1,0 0))
(1 row)

JTS does not support it

reader.read("TRIANGLE((0 0,0 1,1 1,0 0 ))");
> org.locationtech.jts.io.ParseException: Unknown geometry type: TRIANGLE (line 1)

Nor does GEOS

     message: `ParseException: Unknown type: 'TRIANGLE'`

Currently geo-types uses the default implementation of wkt_string

fn wkt_string(&self) -> String {
    self
        .to_wkt() // <-- this allocates a Wkt struct
        .to_string()
}

Instead we could write an individual implementation for each geometry type that doesn't rely on first converting to a Wkt struct. e.g.

impl ToWkt for geo_types::Point {
    ...
    fn wkt_string(&self) -> String {
        format!("POINT({} {})", self.x, self.y)
    } 
}

There might be better and worse ways to do this WRT code re-use of the existing serialization methods on Wkt.

Once (if) the new geo-types with 3dM support is merged, I think wkt can migrate to use them directly, instead of having its own duplicate set of types. This should improve performance (no extra transformation), and simplify code - one set of types for everything.

// current WKT type
pub struct Coord<T: WktFloat> {
    pub x: T,
    pub y: T,
    pub z: Option<T>,
    pub m: Option<T>,
}

// corresponding geo type
pub struct Coordinate<T: CoordNum, Z: ZCoord, M: Measure> {
    pub x: T,
    pub y: T,
    pub z: Z,
    pub m: M,
}

The 3dM types require proper generics (either concrete float type or a NoValue empty struct). We could represent it with a new Wkt enum instead of the existing pub struct Wkt<T> { pub item: Geometry<T> }. NoValue might need to be updated to support all CoordNum requirements.

// Usage:
match Wkt::from_str("LINESTRING (10 -20, -0 -0.5)").unwrap() {
  Wkt(g) => ..., // 2D value
  WktM(g) => ..., // 2D+M value
  Wkt3D(g) => ..., // 3D value
  Wkt3DM(g) => ..., // 3D+M value
  WktEmpty(g) => ..., // Empty value, e.g. "POINT EMPTY"
}

// Note that all T, Z, and M types of the 3dM geo-types in WKT are used as the same `T` generic type, except for the empty type
pub enum Wkt {
    Wkt(Geometry<T>),
    WktM(GeometryM<T>),
    Wkt3D(Geometry3D<T>),
    Wkt3DM(Geometry3DM<T>),
    WktEmpty(Geometry<NoValue>),
}

This PR updates WKT to the pending https://github.com/georust/geo/pull/742

Note that merging this PR might make the main branch unpublishable because it requires patched crates

Constructs such as

let &geo_types::LineString(ref g_points) = g_line;
w_lines.push(g_points_to_w_linestring(g_points));

cannot be easily ported if we introduce 3D/M coordinates. This PR changes them to the direct tuple access. Eventually we may want to create dedicated tuple member accessors instead.

w_lines.push(g_points_to_w_linestring(&g_line.0));

• [x] I agree to follow the project's code of conduct. ~- [ ] I added an entry to CHANGES.md if knowledge of this change could be valuable to users.~