Comments (7)
I think here a line is a segment, composed of 2 coordinates.
from geo.
Is the distinction here that a Line
is a series of Coordinate
s instead of a series of Point
s?
from geo.
(Aside: if you've written up the current direction of georust somewhere, I'd love a link!)
I don't have anything in writing really. I haven't done a great job at establishing a direction for rust-geo, other than saying it's a place for geospatial types and algorithms. I don't do much geospatial work anymore, and have been pretty busy with some other Rust projects, so if anyone has good ideas for the direction of this crate, let me know.
I had heard that it might be the plan to represent geo::types as traits; in which case this could either be its own trait or an implementation of LineString.
Traits would be cool, and I have a pull request open experimenting with them, but with the direction I was heading, it would have made the ergonomics significantly worse than they currently are, and I wasn't a fan of that. That's not to say traits aren't the way forward, they just might require more thinking.
Does it make sense to have a separate type for a Line, like https://github.com/paulmach/go.geo/blob/master/line.go (in that it is treated as a LineString for GeoJSON/WKT)?
I'm not really sure about this. For now, I've been very loosely following version 1.1.0 of the Simple Features spec
which has a data model that looks like:
the latest version of the spec (v 1.2.1) has a data model that looks like:
In that model, you'll see a Line type, which presumably corresponds to the type you're talking about. Maybe it makes sense to start modeling after v1.2.1? Does it make sense to follow a spec? Does it make sense to add all these new types? These are questions I don't know.
Sorry, that's not much of an answer, would appreciate any feedback here
from geo.
Disclosure: I'm also pretty new to GIS programming at this point, so take these opinions with some grains of salt.
Modelling the library according to the Simple Features specification seems like the best approach to take, because most GIS Databases support most (or some) of the specification.
I would definitely like to implement (or see implemented) an updated to the v1.2+ version of the spec (incorporating Z/M coordinates, open/closed, etc).
Following that plan, it doesn't make sense, at least initially, to include the Line/LinearRing/Triangle types because the specification describes them as non-instantiable; but also:
that the SFA-CA implementation standard assumes that a system handles these two types by means of added functionality that is not defined by the SFA-SQL
I'm thinking the final outcome might be:
- Remove
Coordinate
type (should just bePoint
) - Have traits for
Curve
,Surface
,MultiSurface
, andMultiCurve
- Have "core" types for
Point
,LineString
,Polygon
,MultiPoint
,MultiPolygon
, andMultiLineString
- Have some extension with types (possibly in one of the other crates, or in a submodule) for
Line
,LinearRing
since these types have distinct types in Spatial Schema (https://www.iso.org/standard/26012.html)
Still not sure whether Geometry
should be a type (enum like you have now) or trait --- but this should probably just be based on the library's ergonomic needs.
from geo.
Some thoughts:
I'm in favour of compliance with a spec, but with an emphasis on "core" types, as above.
Some other things I'd like to see:
- Distance methods for the core types (I'm working on a Rotating Calipers implementation which will solve this if I can make it work)
- Union / Intersection / Etc as in #80 and #81. Vatti is probably a good fit here, and there are existing high-quality implementations in e.g. C++
- Buffering. I haven't really looked into how to do this.
With the addition of the above, I feel like the library would cover most people's day-to-day needs (I haven't done much linear referencing or transformation, so I assume it's somewhat niche – this is obviously wrong)
- FFI!
I'm also time-constrained, and will be until at least July (working on this project is a form of distraction for me), but I'm also conscious that we've made a lot of progress in the last 9 months or so, and I'd like to see this continue / expand. We could do a lot more in terms of finding new contributors, and the current quality of the code base and the reviews (@frewsxcv and @TeXitoi are fantastic) makes this a hugely valuable learning experience.
from geo.
A PR was opened last week with an implementation for Line
: #118
from geo.
This was completed in #118
from geo.
Related Issues (20)
- Allow returning the source of edges from BoolOp.
- MultiPoint::len
- Panic in BooleanOps::union for Polygon<f32> HOT 6
- VecSet may cause panics HOT 7
- Proposal: Common abstraction layer for collection types (via `Deref` and `DerefMut`) HOT 2
- Add delauney triangulation algorithm to root `geo` crate docs index
- Thoughts on algorithms for trait-based geometries
- concave_hull returns nonsense results for simple polygons HOT 1
- Panic in RegionAssembly reproducibly HOT 4
- Clarify that current cross-track distance uses spherical (Haversine) earth model, add Ellipsoidal (Vincenty) version HOT 2
- Missing `contains` implementations
- `is_valid` for all geometry types. HOT 3
- Problems building with Rust 1.75.0 HOT 1
- Add is_equal_topo method to IntersectionMatrix to determine topological equality
- How to calculate intersection area of two rotated rectangles? HOT 2
- Missing PointZ implementations HOT 1
- Latest ahash dep and Rust 1.70.0 are incompatible HOT 4
- 3D (3-dimensional) data types HOT 2
- Rhumb destinations do not wrap angles after the first pole intersection HOT 8
- GeodesicDestination produces cyclcically incosistent results HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geo.