Too many complex enum types, sometimes unnecessarily about vtkio HOT 2 OPEN

Thank you for submitting the issue @awoimbee! You bring up an important point!
To start, for context, Vtk is a barebones model/type for representing all possible representations of a vtk file (XML or Legacy).
We could for instance represent different vtk files (e.g. pvtp, vtp, vtu, pvtu, vtk (legacy)) with different types, but this would make it difficult for users to use the same code to access the same data from different formats. This is roughly why the "API" seems complex.

I'll try to address each of your questions given the context above:

why do I have to check that my Attribute is a DataArray ? I'm working on a VTP file (that only supports DataArray).

because in the legacy format it can also be a Field

I don't understand the pieces vector of DataSet, aren't VTP files always single element ?

In general VTK files in XML format (e.g. VTP) can be distributed into multiple pieces, and loaded on-demand. This is why pieces is a Vec.

Do you have any plans to simplify the API ?

If you mean simplify the Vtk data structure, then definitely no because this will remove some of the functionality. However I am open to adding a simpler access API on top of Vtk to make it easier to use...

Are you open to PRs ?

I am definitely open to PRs adding more ergonomic APIs on top of this model.
I think your proposed API can easily be implemented on top of the vtkio and the Vtk type, but I am happy to accept PRs directly to vtkio as well.

Are there reasons to make the API so complex ?

Think of it this way. The "API" on top of Vtk is minimal, this is deliberate because different use cases may require different access patterns, and so adding an actual API would be somewhat opinionated. With that said, of course, especially with Vtk, there are the most common use cases, and I am happy to support those directly with an API in vtkio under a feature flag.

PS:
I also don't use vtkio directly when working on projects. I have another crate called meshx that uses vtkio along with other file formats to load and save mesh data with attributes.

from vtkio.

I've never heard of pyvista until now, so thanks for bringing it up.
I glanced at it and noticed that pyvista is actually a wrapper for Vtk. Vtk actually has its own python api but it is possible that it may not be very user friendly (i don't know since I haven't really used it much).

Maybe it's not obvious from the docs, but vtkio has no dependency on the original vtk C++ library, it implements the serializer and deserializer for vtk files directly in Rust, and it tries to be as complete as possible (AFAIR we support most features except for direct binary (not base64) embedding inside XML files, which is a limitation of the quick-xml library we use).
So that is to say that vtkio is meant to be a low level library. I think building a more comprehensive toolset like pyvista on top of it would be of great value for the scientific community using Rust. Although, like I said above, I am also happy to accept PRs for a more ergonomic API directly in vtkio. Something similar to what you proposed with "as_polydata" and "as_map" seems reasonable to me, although I would prefer "into_" prefixes for more expensive conversions that are not just views into the underlying data.

from vtkio.