problem with x and y when reading dfs2 files from MikeShe with MIKE IO
tad9876 opened this issue · 8 comments
Describe the bug
When reading an dfs2 file dataset.geometry.origin is not the same as dataset.geometry.xy[0]. Actually dataset.geometry.xy[0] is exactly double of the origin.
dataset.geometry.xy
datase.geometry._xx
dataset.geometry._yy
is wrong
while;
dataset.geometry.dx
dataset.geometry.dy
dataset.geometry.nx
dataset.geometry.ny
datase.geometry._x0
dataset.geometry._y0
all seems right
Screenshots
System information:
- Python 3.10
- MIKE IO 1.2.2
Why is the projection: NON-UTM?
Can you include the geographical information as shown in MIKE Zero?
This is a file from the MIKE SHE installation examples:
While this is the output from MIKE SHE...
It is intensional that the x-coordinate vector starts in x0 + origin[0]. In most cases, x0 will be zero.
The problem is that the 2D x and y are wrong when reading with MikeIO (mikeio.read())
I attach a .dfs2 and a .dfs3 file. They are output files from the same MikeShe model run.
I also attach a small python script, which show that x_2D and x_3D are not the same (as they should be). x_3D is correct, x_2D is wrong. The same is the case for y.
I want to use the interp(x,y) function on the .dfs2 file, so it is really important that x and y is correct.
Tuse_aa_50m_cal_3DSZ.dfs3.txt
Tuse_aa_50m_cal_2DSZ.dfs2.txt
test_mikeIO.py.txt
[I'm a colleague of tad9876 also familiar with the issue]
So that means that we are defining the coordinate systems wrong in our setups? The mentioned issue occurs with result files from MIKE SHE; not with dfs2 files that we create ourselves from scrartch via mikeio or similar.
In the MIKE SHE setup (Model Domain and Grid), we usually just use "Local coordinates" as a map projection type (even though it most often is ETRS89 UTM32N we do not specify this there), and define a catchment origin X0 and Y0 (together with the rest, i.e. NX, NY, cell size).
Now what puzzles me:
- This produces output files with this value for X0 abnd Y0 both in the geographical Information and in the spatial axis origin (as shown 3 posts above)
- However, this works together (correctly) with input files that we create from scratch or templates, which also use "Local coordinates" as projections, but only have the origin offset in the geographical information (while the origin of the spatial axis is 0, 0)
I was not able to understand what is going on here from the manual - are you able to help?
Thanks a lot
Thanks, Jesper.
(I take that we did not misunderstand how to define our coordinate systems, but that there is some inconsistency in the definition of dfs files)
Looking forward to getting this solved.
closed by #544