Metadata

[rogiersbart]

Currently we have some functionality for metadata in a separate *.prj projection file, possibly containing crs, origin coordinates, start time and grid rotation. Some of these parameters can be part of dataset 1 in the discretization file, with MODFLOW_OWHM. ModelMuse currently also includes the xy coordinates of the upper and lower, left and right corners, and the grid angle in the dataset 0 in the discretization file, and has been exporting usgs.model.reference files with the crs for quite some time now.

We need to figure out if we still want a separate metadata file (if so, I would opt for yaml, or the ModelMuse usgs.model.reference format), or if we want to include everything in the discretization file. The latter would require enabling processing of the ModelMuse comments in dataset 0, reading usgs.model.reference files if they exist, as well as the MODFLOW_OWHM dataset 1 options (and a rule for handling possible conflicts I guess), and a function to easily inject these details in discretization files that do not contain them.

[rogiersbart]

Example usgs.model.reference file contents:

xul  2.019602961259E+005 
yul  1.913295711065E+005 
rotation  3.200000000000E+001 
length_units meters
time_units days
start_date 12/30/1899
start_time 0:0:0
model MODFLOW-OWM
epsg 

Example of corresponding discretization file dataset 0:

# Discretization File created on 2019-06-18 by ModelMuse version 3.10.0.59.
# Upper left corner: (201960.296125871, 191329.571106547)
# Lower left corner: (205298.78749054, 185986.868100761)
# Upper right corner: (219684.50133554, 202404.883729021)
# Lower right corner: (223022.992700209, 197062.180723235)
# Grid angle (in degrees counterclockwise): 32

[cneyens]

I suggest including everything in the dis file. Keeping the metadata in a separate *.prj makes little sense since 1) it needs to be created everytime (i.e. it is not created by MODFLOW or by a GIS) and 2) in every use of it (e.g. plotting and converting) a dis object is required anyway. The prj information could be provided as arguments in the call to rmf_create_dis with sensible defaults:

rmf_create_dis(origin = c(0, 0), cornercoord = FALSE, llcoordinate= TRUE, crs = NULL, rotation = 0) 

where crs plays nicely with sf::st_crs(). Setting these arguments on an existing dis object would be as easy as creating list elements:

dis$rotation <- -12
dis$crs <- sf::st_crs(31370)

or we could have a function for that:

dis <- rmf_set_projection(dis = dis, rotation = -12, crs = sf::st_crs(31370))

which returns the dis object for easier piping.

Reading and writing would then also go through the discretization file. Reading/writing additional arguments from data set 1 (OWHM style) shouldn't be a problem since the discretization file is always in free-format. So this can be used for all models. The epsg code could also be added to data set 1.

The difficulty would then be in handling the ModelMuse format. I'm not that familiar with ModelMuse. Are these comments always written or are there cases when ModelMuse doesn't write this information? Does ModelMuse read this metadata directly from the comments in the dis file or does it also need the usgs.model.reference file? If everything is contained in the dis file, rmf_read/write_dis() can read/write this information in the header comments in addition to reading/writing it in data set 1. The issue is that we would then include the prj metadata twice, once in the comments and once in data set 1 and the crs should still be read/written from/to the usgs.model.reference file.

As a more general question, do you envision RMODFLOW to handle GUI specific files such as usgs.model.reference ?

[rogiersbart]

Have to look more deeply into the ModelMuse comments in dataset 0. But to answer your last question: No, except maybe ModelMuse (since it is also USGS and open source). But only reading then I would say, just to be able to get these details from USGS models that are available online and could be used as examples in the package for instance (meaning we can then easily insert these in the discretization file; see also #6).

For the function to inject the details in the file, I was thinking about one that does not read in and process the file. Just one that inserts the comments in the first few lines of the file on disk. But doing it in a pipe chain makes sense as well (maybe both can even be implemented through S3).

Note I have also been thinking about rotation center, a url, citation, and next to crs maybe also epsg as potential metadata. Some of these would probably be more appropriate as part of the name file, which can also have (max 300 character) comment lines ...