Giter Site home page Giter Site logo

Metadata about rmodflow HOT 3 OPEN

rogiersbart avatar rogiersbart commented on July 22, 2024
Metadata

from rmodflow.

Comments (3)

rogiersbart avatar rogiersbart commented on July 22, 2024

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

from rmodflow.

cneyens avatar cneyens commented on July 22, 2024

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 ?

from rmodflow.

rogiersbart avatar rogiersbart commented on July 22, 2024

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 ...

from rmodflow.

Related Issues (18)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.