Skip to content

Conversation

@styrowolf
Copy link
Contributor

@styrowolf styrowolf commented Sep 1, 2025

  • I agree to follow the project's code of conduct.
  • I added an entry to the project's change log file if knowledge of this change could be valuable to users.
    • Usually called CHANGES.md or CHANGELOG.md
    • Prefix changelog entries for breaking changes with "BREAKING: "

This is an implementation of feature writing for MVTs, as discussed in #263. This PR builds upon @nyurik's previous WIP reimplementation #181. It passes all of the mvt_writer tests. I am not sure if I understood the API exactly correctly but this seems to be a pretty good starting point, as individual feature/geom can be converted to a MVT feature with the ToMvt trait as well as MvtWriter can process multiple feature and output them to a layer.

Here is an example of feature writing and layer output with MvtWriter (from GeoJSON to MVT tiles PR, maplibre/martin#2098)

Let me know how we can move forward with this PR.

@styrowolf
Copy link
Contributor Author

@urschrei the checks fail on something unrelated to the PR. when I run cargo clippy --workspace --all-features --bins --examples --tests --benches -- -D warnings on my machine, it passes. do I need to do anything?

@michaelkirk
Copy link
Member

It's kind of annoying when new clippy lints break builds, but I guess it's a forcing function to improve (usually they're improvements anyway 😆) the codebase.

If you want to speed things along, you can fix the clippy lints in a separate PR.

@kylebarron
Copy link
Member

kylebarron commented Sep 3, 2025

I made #265 to fix latest clippy

@styrowolf
Copy link
Contributor Author

Could someone review this PR when possible, so that we can move forward? Appreciate the help.

tags_builder: TagsBuilder,
}

impl Default for MvtWriter {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make sense to implement Default here? The arguments to new (extent: u32, left: f64, bottom: f64, right: f64, top: f64) don't to me seem to have a natural default.

Copy link
Contributor Author

@styrowolf styrowolf Sep 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default call creates an "unscaled" MvtWriter, where the geometry is assumed to be in tile coordinates and accepted as is. The new call has arguments to scale geometries. Maybe we could rename this or clarify that the Default is an unscaled writer.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still think this would be clearer to not be implemented as Default. Default should be painfully obvious what it does, and I don't think this meets that bar.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just adding new_unscaled as a new constructor isn't enough in my opinion because the Default impl is still public

@styrowolf
Copy link
Contributor Author

Current questions

Thank you for your time and your reviews.

Copy link
Member

@frewsxcv frewsxcv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have any other blocking comments here, but it'd be great to get sign off from @michaelkirk and @kylebarron as well

@kylebarron
Copy link
Member

I think there should at least be an option to do so. It's probably the most straightforward way of encoding Binary properties, right?

  • Are the changes in MvtWriter and its implementation of Default ready to go? Is there any concerns I've not addressed or something that should be changed?

I think it would be clearer if it were a separate constructor with an associated docstring. To me, Default should be painfully obvious what will happen, and it's not in this case.

  • Any docs, examples, explanations to add?

I think having a runnable and doctested example would be ideal here. It can be small

@styrowolf
Copy link
Contributor Author

I just added base64 encoding for ColumnValue and MvtWriter docstrings. Feel free to take a look. I'll add the runnable, doctested example when I find the time. Thanks

@styrowolf
Copy link
Contributor Author

I've added the doc-tested example as well. Ready for (hopefully!) final review.

Copy link
Member

@nyurik nyurik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are we removing integration tests here? Are they fundamentally wrong now? Also, made a few minor comments. Thank you for working on this!

@styrowolf
Copy link
Contributor Author

I added the integration tests back in. Should be good to go.

@styrowolf
Copy link
Contributor Author

There seems to be only one blocker for this PR (link to comment):

Just adding new_unscaled as a new constructor isn't enough in my opinion because the Default impl is still public

What can I do to remove this blocker?

/// The resulting writer expects all geometries to be provided in tile coordinate space,
/// matching the specified `extent`.
pub fn new_unscaled(extent: u32) -> MvtWriter {
assert_ne!(extent, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should panic here. Either we should allow this function to return a Result, or we should make the parameter NonZeroU32

@kylebarron
Copy link
Member

Just adding new_unscaled as a new constructor isn't enough in my opinion because the Default impl is still public

What can I do to remove this blocker?

My opinion there would be that we should remove the Default impl because it's not obvious what it does. And have only new and new_unscaled constructors.

@styrowolf
Copy link
Contributor Author

styrowolf commented Sep 10, 2025

I removed the default impl and changed constructors so that they return Results. I also updated the changelog with the breaking changes.

@nyurik
Copy link
Member

nyurik commented Sep 10, 2025

looks good, thanks!

@nyurik nyurik added this pull request to the merge queue Sep 10, 2025
Merged via the queue into georust:main with commit 11525cf Sep 10, 2025
1 check passed
@styrowolf styrowolf deleted the mvt-reimpl branch September 10, 2025 20:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants