feat(geo-traits): Provide basic structs implementing geo-traits' traits #1441

yutannihilation · 2025-10-25T09:34:43Z

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.

This pull request adds structs like Coord, Point, LineString, etc to geo-traits. These structs implement the corresponding trait (i.e. CoordTrait, PointTrait, LineStringTrait, etc) and the conversion from the objects implementing these traits so that we can use these structs to store the geometry data.

The code is mostly derived from the wkt crate. I don't know how to add attribution properly, sorry..., but I'm not sure if I can finish this anyway. The main purpose of this pull request is to sho what the implementation would be.

The main differences from wkt are:

Removed Display and conversion from text.
Added conversion from geo-traits (e.g. LineString::from_linestring(linestring: impl LineStringTrait<T = T>))
Added more constructors for Coord and Point
Added more From conversions for Coord and Point

kylebarron

Thanks for the PR! Some quick notes

kylebarron · 2025-10-27T22:09:10Z

geo-traits/src/structs/coord.rs

+        let y = coord.y();
+
+        match coord.dim() {
+            Dimensions::Xyzm | Dimensions::Unknown(_) => Self {


I don't know how people intend to use Dimensions::Unknown; I usually pass them into XY if 2 dimensions; into XYZ if 3 dimensions; into XYZM if 4 dimensions

Thanks, I'll follow the convention. How do you handle other irregular numbers? Should this function return Option<Self> to choose None for such cases?

I don't know... I find it really annoying that there is a Dimensions::Unknown at all, but then again I only work with xy/xyz/xym/xyzm data

geo-traits/src/structs/coord.rs

kylebarron · 2025-10-27T22:11:34Z

geo-traits/src/structs/geometry.rs

+    }
+
+    /// Create a new Geometry from an objects implementing [GeometryTrait]. The
+    /// result is `None` if the geometry is `Line`, `Rect`, or `Triangle`.


I think either we could convert Line to LineString, Rect to Polygon, Triangle to Polygon, or potentially it would make sense to also have those concepts here

kylebarron · 2025-10-27T22:12:38Z

geo-traits/src/structs/line_string.rs

+    ///
+    /// To handle empty input iterators, consider calling `unwrap_or` on the result and defaulting
+    /// to an [empty][Self::empty] geometry with specified dimension.
+    pub fn from_coords(coords: impl IntoIterator<Item = impl CoordTrait<T = T>>) -> Option<Self> {


This doesn't need to be impl IntoIterator; it can just be impl Iterator, right?

I think you are right. I couldn't make it due to some compiler error, but I'll try again...

Sorry, probably I too was confused, but probably you meant we want .iter() rather than .into_iter() so that we don't need to consume the object, right? If so, it's not about IntoIterator vs Iterator, and currently it should already be possible because &Coord<T> implements CoordTrait.

Yes, we don't need to consume the object. But taking in impl IntoIterator means that the input needs to be able to be consumed into an iterator. If we take in an impl Iterator instead, then the input doesn't need to be consumed

Sorry, I still don't understand your point. For example, if we have Vec<(f64, f64)>, I think we typically pass &[(f64, 64)] to impl IntoIterator argument because the slice implements IntoIterator. I think it's fine to have the slice consumed because we still hold the original Vec, no? Do you mean changing it to impl Iterator might save us from accidentally passing Vec itself...?

This might be because I'm not familiar with designing such interface. Do you have some good example of a signature that takes Iterator instead of IntoIterator?

kylebarron · 2025-10-27T22:13:02Z

geo-traits/src/structs/linestring.rs

+
+    /// Create a new LineString from an objects implementing [LineStringTrait].
+    pub fn from_linestring(linestring: &impl LineStringTrait<T = T>) -> Self {
+        Self::from_coords(linestring.coords()).unwrap()


I don't think this unwrap is ok, because empty linestrings are valid

Thanks for catching!

kylebarron · 2025-10-27T22:13:27Z

geo-traits/src/structs/multilinestring.rs

+            .line_strings()
+            .map(|l| LineString::from_linestring(&l))
+            .collect::<Vec<_>>();
+        let dim = line_strings[0].dimension();


ditto, we can't assume input objects are non-empty

yutannihilation

Thanks for reviewing! I'll address the comments.

geo-traits/src/structs/coord.rs

yutannihilation · 2025-10-28T13:22:13Z

geo-traits/src/structs/line_string.rs

+    ///
+    /// To handle empty input iterators, consider calling `unwrap_or` on the result and defaulting
+    /// to an [empty][Self::empty] geometry with specified dimension.
+    pub fn from_coords(coords: impl IntoIterator<Item = impl CoordTrait<T = T>>) -> Option<Self> {


I think you are right. I couldn't make it due to some compiler error, but I'll try again...

yutannihilation · 2025-10-28T13:22:49Z

geo-traits/src/structs/linestring.rs

+
+    /// Create a new LineString from an objects implementing [LineStringTrait].
+    pub fn from_linestring(linestring: &impl LineStringTrait<T = T>) -> Self {
+        Self::from_coords(linestring.coords()).unwrap()


Thanks for catching!

yutannihilation · 2025-10-28T13:27:25Z

geo-traits/src/structs/coord.rs

+        let y = coord.y();
+
+        match coord.dim() {
+            Dimensions::Xyzm | Dimensions::Unknown(_) => Self {


Thanks, I'll follow the convention. How do you handle other irregular numbers? Should this function return Option<Self> to choose None for such cases?

…ucts

kylebarron · 2025-11-22T02:33:19Z

I think the main question here is what the scope of geo-traits should be, and whether we should ship structs like this inside of geo-traits. As it is geo-traits only has an optional dependency on geo-types. This would create another optional feature that partially overlaps with geo-types.

Another possible worry is that if we add more structs to the geo-traits crate, then people might start writing APIs in terms of the structs thinking that those are part of the public consumption API of geo-traits, while this PR would be only intended to simplify life for the producers of geo-traits data.

Another option is to create and publish a separate crate with just these structs. That doesn't expand the maintenance burden of crates in the geo repo.

In my own work I don't find it that burdensome to use the wkt crate to manage these structs.

I'd like to hear from other maintainers too

yutannihilation added 21 commits October 25, 2025 15:39

Implement Coord

c4efa96

Geometry (instead of Wkt)

75ac6d7

Point

c28ecfe

Tweak

2c5f6c2

LineString

ddffc62

Polygon

36aae41

Multipoint

86353dd

Multilinestring

cf34df7

Linestring

ab0a9e0

Multipolygon

ba96b9a

GeometryCollection

7e1206c

Tweak

d72b832

Tweak documents

b2c3953

Add test

f8175b8

Add conversion

2953414

Add tests

9c1519e

Add tests

e277d90

Add more conversions

d2bb97d

Update polygon.rs

91ce9bb

Multipoint, MultiPolygon

1353dda

Add more tests

ab35e76

yutannihilation mentioned this pull request Oct 25, 2025

Provide multi dimensional geometry objects in geo-traits #1287

Open

yutannihilation added 3 commits October 25, 2025 21:36

Add default type

0bc3768

Change the signatures to &

5443507

Add default type

02c3c9b

yutannihilation mentioned this pull request Oct 25, 2025

Replace geo-types with geo-traits yutannihilation/ksj2gp#132

Merged

yutannihilation added 4 commits October 25, 2025 23:26

Remove unused imports

f429652

Add more constructors

6d955ce

Fix document links

03c6a73

Delete mistakenly commited .zed/settings.json

3d54e81

yutannihilation added 4 commits October 26, 2025 11:27

Rename

f025682

Add conversions

4456cbe

Delete settings.json

8a517a6

Skip Line, Triangle, Rect

ca8872c

kylebarron reviewed Oct 27, 2025

View reviewed changes

yutannihilation commented Oct 28, 2025

View reviewed changes

yutannihilation and others added 12 commits October 28, 2025 22:32

Handle Unknown Dimension

cc70dd8

Remove From conversion on (T,T,T) and (T,T,T,T)

c024459

Handle Rect, Triangle, Line

7a9cf73

Make from_geometry() return T not Option<T>

ed623e2

Handle empty linestring

3e75baf

Tweak

d2f9063

Rename

3036131

Rename and tweak for consistency

5d0e03a

Add more tests for empty cases

755b789

Remove unnecessary .clone() in tests

57a6fd8

Merge remote-tracking branch 'upstream/main' into feat/geo-traits-str…

60c9e91

…ucts

Handle Dimensions::Unknown somehow

7c1688f

feat(geo-traits): Provide basic structs implementing geo-traits' traits #1441

Are you sure you want to change the base?

feat(geo-traits): Provide basic structs implementing geo-traits' traits #1441

Uh oh!

Conversation

yutannihilation commented Oct 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kylebarron left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yutannihilation Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yutannihilation left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kylebarron commented Nov 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yutannihilation commented Oct 25, 2025 •

edited

Loading

yutannihilation Oct 28, 2025 •

edited

Loading

kylebarron commented Nov 22, 2025 •

edited

Loading