-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proj w/o geo #41
proj w/o geo #41
Conversation
39c4381
to
ae08ea1
Compare
src/geo_types.rs
Outdated
/// assert_approx_eq!(result.x, 1450880.29f64, 1.0e-2); | ||
/// assert_approx_eq!(result.y, 1141263.01f64, 1.0e-2); | ||
/// ``` | ||
impl<T: crate::proj::CoordinateType> crate::Point<T> for geo_types::Coordinate<T> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note - this PR would also let you do Proj stuff with Coords, not just points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it a bit more - we could take this even further and have a Projectable
trait or somesuch that just required implementing a Iter<Item=proj::Point<T>>
, then we could get easy projection of all the geo-type's. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not going to pursue the Iter scenario in this PR, but would like to do it in some followup work.
We could make the |
I'm in favour of this so long as we write clear documentation around it. In general, I find it tricky to present feature interaction in a clear and concise way, but we needn't let that stop us… |
d6cef04
to
c0f7f71
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -22,10 +22,7 @@ By default, this crate depends on a pre-built `libproj`, so PROJ v7.1.x must be | |||
|
|||
## Convert from [NAD 83 US Survey Feet](https://epsg.io/2230) to [NAD 83 Meters](https://epsg.io/26946) Using EPSG Codes | |||
```rust |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The README contains lots of snippets from the primary docs. Since it can be tedious and error prone to copy changes back and forth between them, I was hoping we could review just the primary docs, and once they're in good shape I can update the README before a final review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This lgtm, let's merge!
8e556ad
to
ee4d7db
Compare
I think this probably just needs a rebase now that we've switched to GH Actions? |
It more closely corresponds with how we're using the terminology in geo, and paves the way for interacting with "a bunch of coords" from geo-types e.g. if we're projecting a linestring, we'd operate on the linestrings coords, not it's points. Not a big deal, but since we're introducing a new thing (the trait), no reason to inherit the old name if another fits better.
These changes were all made in src/lib.rs Then I ran: cargo readme > README.md But unfortunately that doesn't capture feature-gated docs, so manually copied over the geo-types doc
ee4d7db
to
cf7994b
Compare
5849f35
to
3b66048
Compare
Ok! Rebased and addressed conflicts in the docs. Note that I'm (almost) wholesale copying the contents of README.md from the doc comments in src/lib.rs - the only divergence is the GH actions badge. |
bors try |
@@ -14,7 +14,7 @@ edition = "2018" | |||
|
|||
[dependencies] | |||
proj-sys = { version = "0.18.3", path = "proj-sys" } | |||
geo-types ="0.6.0" | |||
geo-types = { version = "0.6", optional = true } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I snuck this in - there wasn't a reason for us to peg the patch version of geo-types was there?
bors try I'm not sure why - but bors crashed... let's try again. |
tryAlready running a review |
bors r=urschrei |
bors cancel |
Build succeeded: |
🤦 booooorrrsss Oh well, I just wanted to fix a little typo in the README and squash the commits, but bors will do what bors wants. |
Oh, actually that was my bad. I should have said |
We have always known bots and people couldn't live in harmony. It's been a good run. (Thank you for doing this!) |
tryMerge conflict. |
wth bors |
I feel judged. |
It seems like the potential users of proj would include people who don't need/want to opt into the whole
geo
ecosystem.What would you think about having the proj interface be trait-based and having the geo-integration be a feature?
If this seems like a reasonable direction, before merging I'd like to update the docs to show:
geo
ecosystemimpl
your own point type if you're not using geo.(Float, Float)
implWDYT @urschrei?