-
Notifications
You must be signed in to change notification settings - Fork 33
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
wip: proj transform #22
base: main
Are you sure you want to change the base?
Conversation
af3b0be
to
c903ce3
Compare
fn xy(&mut self, x: f64, y: f64, idx: usize) -> Result<()> { | ||
let (x, y) = self.proj.convert((x, y)).unwrap(); | ||
self.output.xy(x, y, idx) | ||
} |
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 is the crux - we transform the points before passing them in to the "next" processor in the pipeline.
We only "need" these two methods coordinate
/ xy
, but we have to explicitly delegate our other impls to the "output" processor, otherwise we'd inherit the "no-op" implementations for the GeomProcessor trait. (which is really painful)
Effectively, I'm going for some kind of interceptor pattern here.
As well as being very verbose, it also seems like it'd be easy to break if we added a new method to GeomProcessor/FeatureProcessor/PropertyProcessor and failed to update these long list of delegations below.
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.
Sorry, I'm currently short on time and leaving for Easter holidays soon. My only input would be that maybe a delegation pattern like https://github.com/flatgeobuf/flatgeobuf/blob/845111d2ba6765c8f43379877eb1f3440b78d4b6/src/rust/src/file_writer.rs#L302 could work here as well.
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.
maybe a delegation pattern
If I understand correctly, that's exactly what I'm doing - I did use the delegate
crate macro to make it a little more concise, but it seems like a lot of boilerplate.
I'm searching for, but have so far failed to find, a better way to do this.
I'm currently experimenting with a new event based API, which should support chaining of processors. Other advantages of an event stream would be serializing and buffering. |
Excited to see what you come up with! |
This is a demo of an API I'd like to be able to use with geozero to do more kinds of processing with the library.
Currently, it seems like processing is usually limited to "input -> output", which works great for converting formats and for some kinds of processing:
But often I want to do some kind of pipeline of operations. One such example here:
I personally think the user facing API is pretty good - but implementing it has some problems that I'll highlight below.