wkt macro to create geo-types

[michaelkirk]

• 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.

---

Inspired by #1061. I don't think it necessarily replaces #1061, but it might obviate it. It's arguable we might want both (or maybe neither 😢)... how do people feel?

I've applied the new macro to a sampling of tests to give people an idea of where it's nice / less nice.

[michaelkirk]

Here's an example of where it's less nice. Unlike the serde_json::json! macro, you can't embed expressions. The wkt! macro only accepts literals.

[culebron]

I like this, I think this is better that what I wrote. A lot more options.

[urschrei]

This is great!

[michaelkirk]

(Replying to @culebron #1061 (comment) here since I think it's about the changes in this PR)

I like the wkt! macro syntax. The only problem seems to be the confusion with wkt crate. Maybe a different name can work better?

I thought of a name like geom! (geom!(LINESTRING (10.0 20.0,30.0 40.0)) but it will also be confusing of whether it returns the exact type or a general enum wrapper for geometry objects.

re: enum vs inner type

I initially thought it should return a Geometry enum rather than the variants, and implemented it that way, but then when I tried to actually use it in our existing test cases, I found I was almost always immediately unwrapping it to its inner type. So I became convinced it should return the inner type (Point, LineString, etc.) rather than a Geometry. You can always Geometry::from(inner) in the less common case of actually wanting the Geometry enum.

re: naming

I think it's important to have 'wkt' in the name since it's a macro that takes WKT.
One goal is to allow easy copy/paste of test fixtures from other tools. Another goal is to be concise, so a short name is preferred as long as it's clear enough.

I'm not too concerned with the naming collision of geo_types::wkt! vs the wkt crate or even the proposed and similar wkt::wkt macro.

But, I'd also be OK with something like geo_wkt! { POINT(0 1) } if there's a quorum of support for it.

[michaelkirk]

With the nostd build, we need to give a fully qualified path to the vec macro. That's the primary change in this commit.

But also I noticed these into_vec calls. I don't think we were gaining anything by building an array and then boxing it into a Vec vs. building the vec! directly, so I've changed it.

[urschrei]

I'd like to merge this. Anyone else want to chime in? Speak now (or any time before tomorrow morning)

[urschrei]

now what