Field: enable standalone use

[MuellerSeb]

Minor update to the Field class to enable standalone usage:

• enable standalone use with given dim
• add points method to generate field on a point list (transposed unstructured pos tuple as used in many other packages (e.g. PyVista))
• add latlon property
• better doc ref to __call__

This was a low hanging fruit. Now Field can be used to display and export arbitrary n-d point data.

[LSchueler]

I think first of all the __call__ method and maybe also the Field class itself needs more documentation. It is not clear at all what is being "generated" and what the "field values" are.

Now we have Field.structured, Field.unstructured, Field.mesh, and Field.points. Wouldn't it be really nice to enhance the mesh_type keyword to be able to actually use all these possibilities with only one single method call?

[MuellerSeb]

I think first of all the __call__ method and maybe also the Field class itself needs more documentation. It is not clear at all what is being "generated" and what the "field values" are.

Maybe just a "Set field with position tuple and values" in the doc header?

Now we have Field.structured, Field.unstructured, Field.mesh, and Field.points. Wouldn't it be really nice to enhance the mesh_type keyword to be able to actually use all these possibilities with only one single method call?

This would be an issue for GSTools v2. For now we have to keep these methods. Especially the Field.mesh has a lot of settings where we would need to refactor all derived classes to pass **kwargs needed for mesh handling. By defining these partial calls to __call__ as present, we are really flexible since we only rely on the pos and mesh_type arguments in the __call__ signature (present and needed(!) in all child classes) for all these "shortcut" methods. The "mesh_type" itself is only a leftover from the first implementations of GSTools IMO and I think the "(un)structured" options are enough here (See: #61).

Also the planned xarray interface (see #140) should also be just a new method Field.xarray that uses __call__ internally IMO. Actually I really like this approach to add new interfaces that may need special keywords to control their generation settings (see mesh) but internally then uses the simple __call__ method to generate the desired field. This also makes maintenance more easy, since we never need to adopt __call__ or the mesh_type property and all child classes smoothly inherit these functionalities.

Here we are again discussing the scope of this class 😄

[LSchueler]

Maybe just a "Set field with position tuple and values" in the doc header?

Yeah, together with an example of what that is good for is enough I guess. Something like "This gives you access to e.g. the plotting routines or the normalization functionality."

[LSchueler]

Here we go again ;-)
The extra args for the mesh method is a good point. But Python is known, loved, and hated for its duck-typing. And now you suggest to create a separate field-generation method for all kinds of different input types? Function overloading would be really handy in this case, but I guess Python lacks that feature for a reason.
structured, unstructured, and points (or whatever the best keyword would be) all have the same arguments.
For me the ideal solution would still be to use the different input types to create a Field class and then do the field generation with only one method call. But I already tried to implement that and didn't finish, because I don't have enough time for all the refactoring. :'(

Anyways, I think the points or point tuples or point list should be added to the mesh_type argument.

[MuellerSeb]

Here we go again ;-)
The extra args for the mesh method is a good point. But Python is known, loved, and hated for its duck-typing. And now you suggest to create a separate field-generation method for all kinds of different input types? Function overloading would be really handy in this case, but I guess Python lacks that feature for a reason.
structured, unstructured, and points (or whatever the best keyword would be) all have the same arguments.
For me the ideal solution would still be to use the different input types to create a Field class and then do the field generation with only one method call. But I already tried to implement that and didn't finish, because I don't have enough time for all the refactoring. :'(

Anyways, I think the points or point tuples or point list should be added to the mesh_type argument.

Then I would vote for kicking points out again, since all it does is transposing the pos tuple. When adding a new mesh_type possibility, we would also need to refactor all downstream routines (exporting, plotting, converting). We added structured and unstructured only for convenience back in the days.

[LSchueler]

We actually added the structured and unstructured methods for convenience, not the mesh_type keywords. However, we shouldn't use history as arguments for the future development ;-)

I have to agree that it would take a lot of careful considerations, if we introduce a new mesh_type keyword. Although I still do prefer it that way. But if we now introduce a method points and later maybe remove it or add mesh_type keywords, that could get pretty confusing. Maybe we should indeed drop the points method for the moment.

[MuellerSeb]

Ok, then I am fine with dropping points again. ;-) I think passing a points.T for pos is also fine.

[MuellerSeb]

@LSchueler removed the points method and added an example. LGTM!

[LSchueler]

I think it's good to have the example.
And I think we're nearly there ;-)

[LSchueler]

We finally made it! 👍

[MuellerSeb]

We finally made it! +1

Yeah! Will merge when CI is successful. 🎉