Mesh Data Abstraction Library

Related tags

Miscellaneous gis mesh
Overview

Linux Tests MemCheck Tests Coverage Tests OSX Tests WIN Tests

Code Style Coverage Status Docs Build Anaconda-Server Badge

MDAL

Mesh Data Abstraction Library

MDAL is OSGeo Community Project

MDAL OSGeo

Mailing List

To discuss development and usage, please use [email protected]

Supported Formats

You can use MDAL to load the following file formats:

  • 2DM: Mesh representation of various various hydrodynamic modelling packages (e.g. BASEMENT, TUFLOW)
  • XMS TIN: Mesh TIN representation in ASCII format
  • NetCDF: Generic format for scientific data. Examples can be found here
  • GRIB: Format commonly used in meteorology. Examples can be found here
  • XMDF*: Outputs of various hydrodynamic modelling packages (e.g. TUFLOW, HYDRO_AS-2D)
  • XDMF*: As an example, hydraulic outputs from BASEMENT 3.x modelling package
  • DAT: Outputs of various hydrodynamic modelling packages (e.g. BASEMENT, HYDRO_AS-2D, TUFLOW)
  • 3Di*: 3Di modelling package format based on CF Conventions
  • UGRID*: Unstructured Grid format based on CF Conventions
  • FLO-2D: Outputs of the FLO-2D modelling package
  • Selafin/Serafin: Outputs of the TELEMAC 2D hydrodynamic modelling package
  • HEC-RAS: Outputs of the HEC-RAS modelling package
  • SWW: Outputs of the ANUGA modelling package
  • Esri TIN: Format for storing elevation data as a triangulated irregular network
  • SAGA FLOW**: Rasters in the SAGA flow direction format
  • ADCIRC***: ADCIRC hydrodynamic model results
  • PLY: Stanford Polygon Format also useful for mesh created from point clouds by PDAL
  • DFSU*:DHI Flexible File Format (External Driver)
  • DFS2*:DHI Grid Series File (External Driver)

* Data lazy loaded

** Formats can be preprocessed using QGIS Crayfish Mesh processing algorithm to one of supported formats

*** Results should pre pre-processed to become UGRID compliant

Format Mesh Frame Support Mesh Lazy Loaded 1D Data Support 2D Data Support 3D Data Support Data Lazy Loaded
2DM READ-WRITE N/A N/A N/A N/A N/A
XMS TIN READ-ONLY N/A N/A N/A N/A N/A
Esri TIN READ-ONLY N/A N/A N/A N/A N/A
GDAL-NetCDF READ-ONLY NO NO READ-ONLY N/A NO
GDAL-GRIB READ-ONLY NO NO READ-ONLY N/A NO
XMDF N/A N/A NO READ-ONLY READ-ONLY YES
XDMF N/A N/A NO READ-ONLY NO YES
DAT N/A N/A READ-ONLY READ-WRITE N/A NO
3Di READ-ONLY NO READ-ONLY READ-ONLY NO NO
UGRID READ-WRITE NO READ-ONLY READ-ONLY NO NO
FLO-2D READ-ONLY NO READ-ONLY READ-WRITE NO NO
Selafin READ-ONLY NO NO READ-ONLY NO NO
SWW READ-ONLY NO NO READ-ONLY NO NO
PLY READ-WRITE N/A READ-WRITE READ-WRITE READ-WRITE N/A
DFSU READ-ONLY N/A NO READ-ONLY READ-ONLY YES
DFS2 READ-ONLY N/A NO READ-ONLY N/A YES

Standalone Installation

MDAL can be installed as a stand-alone package (i.e. outside of QGIS) using conda.

The package can installed by running :

conda install -c conda-forge mdal

This package provides the MDAL ABI through the mdal shared object( i.e. mdal.dll, libmdal.dylib or libmdal.so) and the mdalinfo CLI.

A friendly note about versions. The conda package is usually targetted at the latest version of GDAL on conda-forge. This is usually a later version than used by QGIS. Therefore, there may be some subtle differences in behaviour when loading e.g. GRIB files.

Versioning and integration in QGIS

QGIS contains internal copy of MDAL library in following versions:

QGIS MDAL Features
3.0.2 N/A 2D meshes
3.2.3 0.0.3
3.4.14 0.0.10
3.6.3 0.3.2 Many new formats supported
3.8.3 0.3.3
3.10.0 0.3.3
3.10.1 0.4.0 Save datasets for some formats
3.10.2 0.4.1
3.10.3 0.4.2
3.12.0 0.5.1 3D layered meshes
3.14.0 0.6.1 1D meshes
3.16.0 0.7.1 Mesh creation, PLY format
3.18.0 0.8.0 Dynamic drivers, DFSU format
3.20.0 0.8.1
3.22.0 0.9.x DFS2, DFSU 3D, PLY write
3.24.0 1.0.x TBD

versions X.Y.9Z are development versions or alpha/beta releases (e.g. 0.4.90, 0.4.91, ...)

Backporting

We maintain the version of MDAL used in current QGIS LTR version. For any CRITICAL bugfixes (e.g. crashes, coredumps, regressions, data corruption) we want to backport the code to MDAL LTR version. To do this, label your pull request with label "backport release-XXX". Once pull request is merged, mdal-bot will automatically create a pull request to specified branch. Note that the pull request must be squashed to 1 commit for automatic backport.

Development

Coding standards & Contribution

MDAL is an open-source project and all contributions to either documentation, format support, testing or code are more than appreciated. Any change to the code must go through Pull Request, followed by review by one of the MDAL core developers.

To be able to accept a pull request, please verify that:

  • code follows QGIS coding style
  • code is properly unit-tested with a set of small test files under tests/data/ (code coverage > 90%)
  • code is reasonably documented and easy to read
  • code compiles without any compilation warnings
  • no dead-code (e.g. unused functions) or commented out code
  • all new code or new dependencies (e.g. libraries) have GPLv2 compatible license
  • all tests pass
  • the code if properly formated (run ./scripts/check_all.bash)

Please respect our Contributor Covenant Code of Conduct

Build

Windows

For 64-bit version:

  • Install Microsoft Visual Studio 16 2019
  • Install OSGeo4W (64bit) to C:\OSGeo4W64
  • Run "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\Tools\VsDevCmd.bat -arch=x86" to initialize Visual Studio environment (or open VS terminal). For community version, run similar command "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat -arch=x86"
  • Create build directory mkdir build;cd build
  • Run (to get a Release build)
cmake -G "Visual Studio 16 2019" -DCMAKE_BUILD_TYPE=Rel  ^
    -DENABLE_TESTS=ON ^
    -DNETCDF_PREFIX="C:\OSGeo4W64" ^
    -DHDF5_ROOT="C:\OSGeo4W64" ^
    -DGDAL_DIR="C:\OSGeo4W64" ^
    -DGDAL_LIBRARY="C:\OSGeo4W64\lib\gdal_i.lib" ^
    -DGDAL_INCLUDE_DIR="C:\OSGeo4W64\include" ^
    -DLIBXML2_LIBRARIES="C:\OSGeo4W64\lib\libxml2.lib ^
    -DLIBXML2_INCLUDE_DIR="C:\OSGeo4W64\include\libxml2" ^
    -D EXTERNAL_DRIVER_DHI_DFS=OFF ^
    ..
  • Build the executables cmake --build . --config Release
  • Adjust the PATH (or copy the mdal.dll to folder test\Release) with command set PATH="C:\OSGeo4W64\bin; \build\tool\Release\; \build\mdal\Release;%PATH%"
  • Run the tests ctest -VV -C Release --exclude-regex mdal_dynamic**

Linux

install dependencies for drivers

sudo apt-get install libgdal-dev libhdf5-dev libnetcdf-dev libxml2-dev

and use cmake to generate build system

mkdir build;cd build
cmake -DCMAKE_BUILD_TYPE=Rel -DENABLE_TESTS=ON ..
make

MacOS

First you need to install qgis-deps dependencies,

To build, create build system with cmake and make sure you use dependencies from qgis-deps and not system ones

mkdir build;cd build
cmake -DCMAKE_PREFIX_PATH=/opt/QGIS/qgis-deps-0.5.3/stage -DCMAKE_BUILD_TYPE=Debug -GNinja -DENABLE_TESTS=ON ../
ninja

External Drivers

see DFSU

Tests

run ctest command in build directory ctest -VV

Code syntax

format code:

cd scripts
./check_all.bash

or use git pre-commit hook

cd MDAL
ln -s ./scripts/mdal_astyle.bash .git/hooks/pre-commit

Windows

On Windows, the code can be formatted using the following :

cd MDAL
powershell -ExecutionPolicy BYPASS scripts\check_all.ps1
Comments
  • Problem opening mesh layer in QGIS as user

    Problem opening mesh layer in QGIS as user

    Trying to open a mesh layer as user fails in QGIS with the following error: unnamed But when you run QGIS as admin, the same layer can be loaded. Note, this happened for a 2dm file.

    bug blocked upstream 
    opened by saberraz 19
  • Openning ugrid file causes core dump

    Openning ugrid file causes core dump

    If I try to open this file: https://github.com/lutraconsulting/MDAL/blob/master/tests/data/ugrid/D-Flow1.2/bw_11_zonder_riviergrid_met_1dwtg_clm.nc

    It causes core dump. To reproduce it, you can try and add it twice (while the first one is open).

    bug 
    opened by saberraz 17
  • [SELAFIN] unable read Fudaa-prepro selafin export

    [SELAFIN] unable read Fudaa-prepro selafin export

    Fudaa-prepro is used for pre and post processing of TELEMAC2D model.

    I have an "invalid string position" when importing a mesh exported from fudaa (see attached file). Qgis 3.14.1

    export_fudaa.zip

    bug formats 2D 
    opened by nicogodet 15
  • MDAL crashes with MARS data (GRIB)

    MDAL crashes with MARS data (GRIB)

    https://apps.ecmwf.int/datasets/data/interim-full-daily/levtype=sfc/

    crashes on

    void MDAL::DriverGdal::addDataToOutput( GDALRasterBandH raster_band, std::shared_ptr<MemoryDataset> tos, bool is_vector, bool is_x )
    {
      assert( raster_band );
    

    where raster_band is null pointer;

    bug 
    opened by PeterPetrik 13
  • BASEMENT output .dat error

    BASEMENT output .dat error

    I've been working with BASEMENT and up to now the visualization on Crayfish was fine. With QGIS update to v3.4 and the MDAL tool I'm struggling in visualizing BASEMENT outputs in qgis. When trying to add both ascii.dat or *.sol files as extra dataset to the 2dm mesh, the message "Could not read mesh dataset." appears. Actually, by reading these output files, the *.sol files are written in the *.dat syntax, but I am unable to upload them on MDAL as extra dataset.

    bug formats unable to replicate 
    opened by JoaoBarreiro 12
  • Support 2DM's E6T element (triangle with 6 nodes)

    Support 2DM's E6T element (triangle with 6 nodes)

    I tried to create the simplest possible example for test purposes - see http://forum.aquaveo.com/topic/3426-working-example-of-a-2dm-mesh-file-with-e6t-elements-six-node-quadratic-triangles/

    Unfortunately, I haven't received any responses from the SMS forum.

    In QGIS, the file seems to read fine, but doesn't render: image

    Crayfish exports the nodes, but produces an empty (nodata) raster and empty polygon for the face (expression used to create the "wkt" virtual field - geom_to_wkt( $geometry) ) : image

    QGIS version info:
    
    
    QGIS version
    3.10.2-A Coruña
    QGIS code revision
    d4cd3cfe5a
    Compiled against Qt
    5.11.2
    Running against Qt
    5.11.2
    Compiled against GDAL/OGR
    3.0.3
    Running against GDAL/OGR
    3.0.3
    Compiled against GEOS
    3.8.0-CAPI-1.13.1
    Running against GEOS
    3.8.0-CAPI-1.13.1 
    Compiled against SQLite
    3.29.0
    Running against SQLite
    3.29.0
    PostgreSQL Client Version
    11.5
    SpatiaLite Version
    4.3.0
    QWT Version
    6.1.3
    QScintilla2 Version
    2.10.8
    Compiled against PROJ
    6.3.0
    Running against PROJ
    Rel. 6.3.0, January 1st, 2020
    OS Version
    Windows 10 (10.0)
    Active python plugins
    changeDataSource; 
    crayfish; 
    gmsh; 
    latlontools; 
    Mergin; 
    mmqgis; 
    profiletool; 
    QMetaTiles; 
    quick_map_services; 
    shapetools; 
    splitmultipart; 
    SVG2ColoR; 
    timemanager; 
    valuetool; 
    VectorMCDA; 
    VoGisProfilTool; 
    db_manager; 
    MetaSearch; 
    processing
    
    
    enhancement good first issue formats feedback 2D 
    opened by Brent-Edwards 11
  • [hydro-as-2d] driver support for the xmdf result files

    [hydro-as-2d] driver support for the xmdf result files

    Hi! We're using mdal/crayfish quite often, especially to show and analyse results of the 2d hydraulic model hydro-as-2d / hydro-ft-2d. ...and it would be great, if we can show and analyse the result from .h5 files in QGIS :)

    Is a driver for the xmdf (.h5) format planned to get into mdal? maybe its just an extension to the already existing xmdf driver. hydro-as stores a relatively simple xmdf format with one group per dataset. Each group stores 4 tables (Mins, Maxs, Times, Values) I'm not into cpp, but I wrote a simple function in python using the h5py lib (see attached) to read/write the data. May this could help a little bit to get the driver for reading these files into mdal :)

    hydras_h5_io.py.zip

    test files testdata_hydro_as.zip

    it would be great to see the hydro-as xmdf support in the future!! cheers

    enhancement formats 2D 
    opened by dimdle 10
  • Write enabled and Binary enabled PLY driver

    Write enabled and Binary enabled PLY driver

    This PR is the first part of an update to the PLY driver to make to READ/WRITE and to include binary as well as ASCII format files. Currently, although it does both formats it has only been tested on ASCII formats. There will be an update when the binary formats are tested and working (which will be dependent on the metadata PR submitted separately). Submitting now to start the review.

    NOTES:

    1 This driver has been built on top of an existing library for PLY. This code is fully MIT licenced (include explicit language allowing the code to be merged) and I have included the copyright notice both in the MDAL LICENCE.TXT and in its own licence file. I believe this meets all legal requirements. Note that the libplyxx code has been extensively customised to the needs of MDAL, has been changed to use MDAL error logging and has been updated to include all PLY data types and lists in all positions.

    2 I have build the PLY library code into the MDAL shared object to avoid problems with creating new dependencies. This may be seen as not usual - but the amount of code involved is no more than would be required to write a PLY driver from scratch and it does not bring in any unusual or new dependencies itself (except as in the next point) - so this seems reasonable to me.

    3 This code DOES make extensive use of std::unordered_map and therefore has a dependency on C++ 14. This does not seem unreasonable in 2021.

    4 The use of libplyxx approach means that the actual mdal_ply code is such simplified down to just wrangling the MDAL into and out of the libplyxx data formats.

    opened by runette 9
  • Bad read of 0 values in SELAFIN file

    Bad read of 0 values in SELAFIN file

    Hi I noticed sometimes there is hole in the map when I display some Telemac results. After analysis, I discover that the hole are generated where the values on node are 0. When inspect the values, there is no_data indicate.. This could have sense for water depth as sometimes we don't want to map 0 values but this is more problematic for the bottom or the free surface when working on coasts as 0 is a real value... Hope this could be solved in a future version

    bug 
    opened by ccoulet 9
  • Support for ADCIRC file [UGRID]

    Support for ADCIRC file [UGRID]

    Hello, I am trying to load ADCIRC hydrodynamic model results in QGIS using "Add Mesh Layer" but it's not working.

    After some small tweaks to make the files more UGRID (unstructured grid) compatible I was able to load them using EDAL and ncWMS as show in the image below, so I am quite sure the files are OK.

    The files used in the test are here: ugrids.zip

    Thank you.

    adcirc_ugrid1 adcirc_ugrid2

    enhancement formats 
    opened by marceloandrioni 9
  • When importing ECMWF / Copernicus NetCDF files MDAL seems not to be applying scaling factors and offsets.

    When importing ECMWF / Copernicus NetCDF files MDAL seems not to be applying scaling factors and offsets.

    Hi,

    I've just been helping a colleague use R to download and work with some reanalysis datasets from ECMWF and Copernicus. I thought I'd also try using the MDAL import option to load them into QGIS 3.6 on Windows. I was able to successfully load in new MDAL layers within which there were 10 metre wind groups. The displayed magitudes and vector arrows showed the expected sort of patterns. However, when I checkd the ranges of values the magnitudes were up in the 1000s of metres per second :-(

    In case something was wrong with the files I'd downloaded, I switched to the example ECMWF_ERA-40_subset.nc files mentioned in this blog post: https://www.lutraconsulting.co.uk/blog/2018/10/18/mdal/. Again the 10m windspeeds ranged way up into the 10,000s of metres per second. I tested the same file in UniData's IDV and it generated displays indicating much more reasonable ranges of a few 10s of metres per second.

    I did a bit of digging and it looks like the values that the MDAL layer is showing are probably just the raw short integers from the NetCDF files. Any associated scaling factors and offsets necessary to convert those back into the original floating point values currently don't seem to be getting picked up from the NetCDF flies and applied to the integer numbers.

    This extract from running the ncdump utility on the ECMWF_ERA-40_subset.nc file shows the scale_factors and offsets for the two variables used to store the 10m u and v wind components:

        short p10u(time, latitude, longitude) ;
                p10u:scale_factor = 0.0007584155104299 ;
                p10u:add_offset = -0.440509086897149 ;
                p10u:_FillValue = -32767s ;
                p10u:missing_value = -32767s ;
                p10u:units = "m s**-1" ;
                p10u:long_name = "10 metre U wind component" ;
        short p10v(time, latitude, longitude) ;
                p10v:scale_factor = 0.000664359461014752 ;
                p10v:add_offset = -0.745888358484452 ;
                p10v:_FillValue = -32767s ;
                p10v:missing_value = -32767s ;
                p10v:units = "m s**-1" ;
                p10v:long_name = "10 metre V wind component" ;
    

    Hopefullly either I've just missed something or this will just be quite a quick fix. Happy to supply more info if needed as having MDAL in QGIS is potentially very useful for a few of us in my Unit.

    cheers

    Clint

    bug 
    opened by ClintBlight 9
  • Remove GDAL dependency

    Remove GDAL dependency

    We should read the GRIB/NetCDF formats natively, GDAL is not a dependency for a low-level library as MDAL.

    related #416 related #391 related #273 related #237 duplicate #165 related #106 related #103

    enhancement 
    opened by PeterPetrik 0
  • MDAL doesn't load binary datasets if mesh number of nodes differs from maximum node ID

    MDAL doesn't load binary datasets if mesh number of nodes differs from maximum node ID

    For both, binary and ascii dataset files the index (position/line) of the values correspond to the node numbers in the mesh. In most cases nodes are numbered from 1 to maximumId. But this is not mandatory. There may be reasons to remove some nodes from a mesh without renumbering, having the ability to use existing datasets. If I use ascii format this is no problem in most cases, because the validation of the dataset is made by comparision of the value behind the ND-card and the maximum ID of mesh nodes (see mdal_ascii_dat.cpp, MDAL::DriverAsciiDat::loadNewFormat/loadOldFormat):

        if ( cardType == "ND" && items.size() >= 2 )
        {
          size_t fileNodeCount = toSizeT( items[1] );
          size_t meshIdCount = maximumId( mesh ) + 1;
          if ( meshIdCount != fileNodeCount )
          {
            MDAL::Log::error( MDAL_Status::Err_IncompatibleMesh, name(), "Loading old format failed" );
            return;
          }
        }
    

    In binary format (mdal_binary_dat.cpp, MDAL::DriverBinaryDat::load) this doesn't work, because the comparision is made between the number of values in the dataset (numdata) and the number of nodes in the mesh (vertexCount).

          case CT_NUMDATA:
            // Num data
            if ( read( in, reinterpret_cast< char * >( &numdata ), 4 ) ) return exit_with_error( MDAL_Status::Err_UnknownFormat, "unable to read num data" );
            if ( numdata != static_cast< int >( vertexCount ) ) return exit_with_error( MDAL_Status::Err_IncompatibleMesh, "invalid num data" );
            break;
    

    I think both dataset formats should use the same criteria and for more flexibilty it should be the first one (the maximum node id of the mesh). This would solve the problem of gaps in node numbering. But there may be cases where the node with the maximum ID should be removed from the mesh. In this case loading of datasets would not work, because the criteria is meshIdCount != fileNodeCount and would cause an error. So the only really mandatory check should be: meshIdCount > fileNodeCount where no values can be found in the datasets file for ID greater than fileNodeCount.

    A second barrier in file formats can be the number of elements, if stored in datasets files (NC card / CT_NUMCELLS ). Flexibility would rise if this would be ignored completely for vertex based datasets.

    I'm aware that the implemented behavior is intended to avoid users from combining mismatching data. I think, the user would recognize this immediately, viewing the results and the benefit of these checks would be less than the higher flexibility and the ability to create clipped TIN-Meshes (e.g. for watersurface elevation).

    bug 
    opened by wilhelmje 3
  • Tests failing after build with GDAL 3.5.0

    Tests failing after build with GDAL 3.5.0

    The NetCDF tests are failing after MDAL is built using GDAL 3.5.0 in Conda-Forge.

    The results can be seen here https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=515809&view=logs&j=656edd35-690f-5c53-9ba3-09c10d0bea97&t=e5c8ab1d-8ff9-5cae-b332-e15ae582ed2d&l=2279

    bug 
    opened by runette 8
  • GRIB Driver breaks when built on GDAL 3.4

    GRIB Driver breaks when built on GDAL 3.4

    WHen MDAL is built on GDAL 3.4 - the GRIB tests fail with the following message

    11: C:\Users\runes\Documents\GitHub\MDAL\tests\test_gdal_grib.cpp(214): error: Expected equality of these values: 11: -0.818756103515625 11: value 11: Which is: -0.535552978515625 This is consistent across all platforms that I have tried.

    I believe that this might be related to https://github.com/OSGeo/gdal/issues/4524 since - if you run gdalinfo on the test GRIB file you get different results for different versions of GDAL - note the origin and corner coordinates. I do not know enough about the GRIB driver to know what effect this change would have.

    IN 3.3.3 you get Warning: Inside GRIB2Inventory, Message # 3 ERROR: Couldn't find 'GRIB' or 'TDLP' Driver: GRIB/GRIdded Binary (.grb, .grb2) Files: wind_only_u_component.grib Size is 480, 241 Coordinate System is: GEOGCRS["Coordinate System imported from GRIB file", DATUM["unnamed", ELLIPSOID["Sphere",6367470,0, LENGTHUNIT["metre",1, ID["EPSG",9001]]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]], CS[ellipsoidal,2], AXIS["latitude",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]], AXIS["longitude",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]]] Data axis to CRS axis mapping: 2,1 Origin = (-0.375000000000000,90.375000000000000) Pixel Size = (0.750000000000000,-0.750000000000000) Corner Coordinates: Upper Left ( -0.3750000, 90.3750000) ( 0d22'30.00"W, 90d22'30.00"N) Lower Left ( -0.3750000, -90.3750000) ( 0d22'30.00"W, 90d22'30.00"S) Upper Right ( 359.625, 90.375) (359d37'30.00"E, 90d22'30.00"N) Lower Right ( 359.625, -90.375) (359d37'30.00"E, 90d22'30.00"S) Center ( 179.6250000, 0.0000000) (179d37'30.00"E, 0d 0' 0.01"N) Band 1 Block=480x1 Type=Float64, ColorInterp=Undefined Description = 0[-] SFC (Ground or water surface) Metadata: GRIB_COMMENT=10 metre u wind component [m/s] GRIB_ELEMENT=10U GRIB_FORECAST_SECONDS=43200 sec GRIB_REF_TIME= 1538352000 sec UTC GRIB_SHORT_NAME=0-SFC GRIB_UNIT=[m/s] GRIB_VALID_TIME= 1538395200 sec UTC Band 2 Block=480x1 Type=Float64, ColorInterp=Undefined Description = 0[-] SFC (Ground or water surface) Metadata: GRIB_COMMENT=10 metre u wind component [m/s] GRIB_ELEMENT=10U GRIB_FORECAST_SECONDS=43200 sec GRIB_REF_TIME= 1538395200 sec UTC GRIB_SHORT_NAME=0-SFC GRIB_UNIT=[m/s] GRIB_VALID_TIME= 1538438400 sec UTC In 3.4 you get Warning: Inside GRIB2Inventory, Message # 3 ERROR: Couldn't find 'GRIB' or 'TDLP' Driver: GRIB/GRIdded Binary (.grb, .grb2) Files: wind_only_u_component.grib Size is 480, 241 Coordinate System is: GEOGCRS["Coordinate System imported from GRIB file", DATUM["unnamed", ELLIPSOID["Sphere",6367470,0, LENGTHUNIT["metre",1, ID["EPSG",9001]]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]], CS[ellipsoidal,2], AXIS["latitude",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]], AXIS["longitude",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433, ID["EPSG",9122]]]] Data axis to CRS axis mapping: 2,1 Origin = (-180.375000000000000,90.375000000000000) Pixel Size = (0.750000000000000,-0.750000000000000) Corner Coordinates: Upper Left (-180.3750000, 90.3750000) (180d22'30.00"W, 90d22'30.00"N) Lower Left (-180.3750000, -90.3750000) (180d22'30.00"W, 90d22'30.00"S) Upper Right ( 179.6250000, 90.3750000) (179d37'30.00"E, 90d22'30.00"N) Lower Right ( 179.6250000, -90.3750000) (179d37'30.00"E, 90d22'30.00"S) Center ( -0.3750000, 0.0000000) ( 0d22'30.00"W, 0d 0' 0.01"N) Band 1 Block=480x1 Type=Float64, ColorInterp=Undefined Description = 0[-] SFC (Ground or water surface) Metadata: GRIB_COMMENT=10 metre u wind component [m/s] GRIB_ELEMENT=10U GRIB_FORECAST_SECONDS=43200 GRIB_REF_TIME=1538352000 GRIB_SHORT_NAME=0-SFC GRIB_UNIT=[m/s] GRIB_VALID_TIME=1538395200 Band 2 Block=480x1 Type=Float64, ColorInterp=Undefined Description = 0[-] SFC (Ground or water surface) Metadata: GRIB_COMMENT=10 metre u wind component [m/s] GRIB_ELEMENT=10U GRIB_FORECAST_SECONDS=43200 GRIB_REF_TIME=1538395200 GRIB_SHORT_NAME=0-SFC GRIB_UNIT=[m/s] GRIB_VALID_TIME=1538438400

    bug 
    opened by runette 13
Releases(0.9.90)
Owner
lutraconsulting
lutraconsulting
Yet another abstraction layer - a general purpose C++ library.

Yet Another Abstraction Layer What yaal is a cross platform, general purpose C++ library. This library provides unified, high level, C++ interfaces an

Marcin Konarski 14 Jul 27, 2022
Portable, Noto-powered font-rendering abstraction based on FreeType and Raqm

Mechascribe Mechascribe is still under construction and nothing is functional yet. Mechascribe is a text rendering abstraction trying to support as mu

null 4 Jan 27, 2022
Language that provides an abstraction to a PART of GTK difficulty

Welcome to GPP_COMPILER Language that provides an abstraction to a PART of GTK difficulty . To get projet on your computer, clone it using the followi

null 9 Jan 28, 2022
a minimal C++, SDL2, OpenGL abstraction for general game and application development

hept the hept abstraction is a minimal lightweight layer above C++ and SDL dependencies: - SDL2 - C++17 or above - GLM example use: #include "hept.h"

ENDESGA 15 Sep 18, 2022
A format converter for surface mesh intergrated with muli tools.

MeshConverter A format converter for surface mesh intergrated with small tools for fast surface mesh modification in CFD application scenarios. Build

yhf 4 Jul 22, 2022
Procedural tree mesh generator (and editor)

ProcTree This is a liberally licensed procedural tree generator in c++, along with an editor HappyTree. (youtube video) The procedural generation itse

Jari Komppa 182 Sep 6, 2022
This is a tool for software engineers to view,record and analyse data(sensor data and module data) In the process of software development.

![Contributors][Huang Jianyu] Statement 由于工具源码在网上公开,除使用部分开源项目代码外,其余代码均来自我个人,工具本身不包含公司的知识产权,所有与公司有关的内容均从软件包中移除,软件发布遵循Apache协议,任何人均可下载进行修改使用,如使用过程中出现任何问

HuangJianyu 34 May 5, 2022
Samir Teymurov 1 Oct 6, 2021
Treexy is a library that implements a compact hierarchical data structure that can store and manipulate volumetric data, discretized on a three-dimensional grid

Treexy is a library that implements a compact hierarchical data structure that can store and manipulate volumetric data, discretized on a three-dimens

Davide Faconti 307 Sep 20, 2022
Serial Data Monitor is a multiplatform (Windows, Linux, Mac, ...) tool to interactively receive/edit/monitor data and send commands to an embedded system via the serial bus

See wiki for full documentation Serial Data Monitor Description Serial Data Monitor is a multiplatform (Windows, Linux, Mac, ...) tool to interactivel

monnoliv 4 Oct 29, 2021
This repository uses a ROS node to subscribe to camera (hikvision) and lidar (livox) data. After the node merges the data, it publishes the colored point cloud and displays it in rviz.

fusion-lidar-camera-ROS 一、介绍 本仓库是一个ROS工作空间,其中ws_fusion_camera/src有一个工具包color_pc ws_fusion_camera │ README.md │ └───src │ └───package: c

hongyu wang 18 Sep 28, 2022
"SaferCPlusPlus" is essentially a collection of safe data types intended to facilitate memory and data race safe C++ programming

A collection of safe data types that are compatible with, and can substitute for, common unsafe native c++ types.

null 318 Sep 21, 2022
An easy to build CO2 Monitor/Meter with Android and iOS App for real time visualization and charting of air data, data logger, a variety of communication options (BLE, WIFI, MQTT, ESP-Now) and many supported sensors.

CO2-Gadget An easy to build CO2 Monitor/Meter with cell phone App for real time visualization and charting of air data, datalogger, a variety of commu

Mariete 22 Aug 5, 2022
Mod - MASTERS of DATA, a course about videogames data processing and optimization

MASTERS of DATA Welcome to MASTERS of DATA. A course oriented to Technical Designers, Technical Artists and any game developer that wants to understan

Ray 32 Oct 1, 2022
Example code for collecting weather data from an ESP32 and then uploading this data to InfluxDB in order to create a dashboard using Grafana.

InfluxGrafanaTutorial Example code for collecting weather data from an ESP32 and then uploading this data to InfluxDB in order to create a dashboard u

Michael Klements 5 May 12, 2022
Source code for the data dependency part of Jan Kossmann's PhD thesis "Unsupervised Database Optimization: Efficient Index Selection & Data Dependency-driven Query Optimization"

Unsupervised Database Optimization: Data Dependency-Driven Query Optimization Source code for the experiments presented in Chapter 8 of Jan Kossmann's

Jan Koßmann 4 Apr 24, 2022
The PNT Integrity Library provides users a method to verify the integrity of the received GPS data and ranging signals, thereby improving resiliency against potential GPS signal loss.

PNT Integrity Library The PNT Integrity Library provides users a method to verify the integrity of the received GPS data and ranging signals, thereby

Cybersecurity and Infrastructure Security Agency 39 Jul 31, 2022
tiny_csg is a C++ library that generates meshes from brush-based level data and supports incremental updates (real-time CSG).

tiny_csg is a C++ library that generates meshes from brush-based level data and supports incremental updates (real-time CSG). It is intended to be used as a backend in 3d level editors and/or generators.

Luka Aleksić 31 Sep 25, 2022