This way it is possible to derive the projected bool automatically, since it is set in the mk.MeshKernel instance (albeit indirectly via get_projection(). It would avoid the need to derive the projected bool from the mk.MeshKernel instance before converting the mesh2d to Ugrid2d and limits the amount of input arguments.
After implementation, it is still important to check if the passed crs and mk.MeshKernel are both geographic or both projected. But that is slighly better than the current situation, since we should actually check whether crs and mk.MeshKernel and projected are aligned.
The above also goes for mesh1d/Ugrid1d.
Alternatively
Alternatively, derive projected from crs. This would avoid the need to pass a different meshkernel instance. In that case it might be easiest to pick it up in https://github.com/Deltares/xugrid/issues/187
More info
Another consideration is consistency. We have back-forth conversions for meshkernel with meshkernel and from_meshkernel. These functions are available for UgridBase, Ugrid1d and Ugrid2d. meshkernel always creates a MeshKernel() instance, but from_meshkernel expects a mesh2d or mesh1d. So for consistency it would make sense to go for the first approach (and check the geographic property of the meshkernel instance against that of the passed crs).
This way it is possible to derive the
projectedbool automatically, since it is set in themk.MeshKernelinstance (albeit indirectly viaget_projection(). It would avoid the need to derive the projected bool from themk.MeshKernelinstance before converting themesh2dtoUgrid2dand limits the amount of input arguments.E.g. in dfm_tools we derive
projectedfrom themk.MeshKernelinstance before passing it tofrom_meshkernel: https://github.com/Deltares/dfm_tools/blob/9a527af6f0df6529aecf46d434315bb277158797/dfm_tools/xugrid_helpers.py#L550-L557 In https://github.com/Deltares/dfm_tools/pull/685 we moved to derivingcrsandprojectedfromudsinstead of frommk.MeshKernelAnd in hydromt_delft3dfm we pass
projectedandcrs, altoughprojectedis derived fromcrsbefore passing it tofrom_meshkernel: https://github.com/Deltares/hydromt_delft3dfm/blob/a97d2b491501e1fc78042e58292405e8bbcd2baa/hydromt_delft3dfm/mesh_utils.py#L259-L267After implementation, it is still important to check if the passed
crsandmk.MeshKernelare both geographic or both projected. But that is slighly better than the current situation, since we should actually check whethercrsandmk.MeshKernelandprojectedare aligned.The above also goes for mesh1d/Ugrid1d.
Alternatively Alternatively, derive
projectedfrom crs. This would avoid the need to pass a different meshkernel instance. In that case it might be easiest to pick it up in https://github.com/Deltares/xugrid/issues/187More info Another consideration is consistency. We have back-forth conversions for meshkernel with
meshkernelandfrom_meshkernel. These functions are available forUgridBase,Ugrid1dandUgrid2d.meshkernelalways creates aMeshKernel()instance, butfrom_meshkernelexpects amesh2dormesh1d. So for consistency it would make sense to go for the first approach (and check the geographic property of the meshkernel instance against that of the passed crs).