Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
filereference:fileformat [2014/03/28 23:07] – [Special EML items] enviadmin | filereference:fileformat [2021/10/18 19:12] – [Special EML items] enviadmin |
---|
| |
With version 4, ENVI-met has changed the format of **ALL** system files, databasefiles and input/ output files to the new EML format. | With version 4, ENVI-met has changed the format of **ALL** system files, databasefiles and input/ output files to the new EML format. |
There are several reasons for that: First, with V4 a huge amount of new features have been introduced in ENVI-met. In any case, this required a complete redesign of the data structure and the contents of all input and output files. Moreover, the old format lacks versioning information and was very unflexible concering the data sequenzes and the way the data was stored (fixed sign intervalls, all information in a fixed order). Hence, there was no way but to break with the old format and design a new one. | There are several reasons for that: First, with V4 a huge amount of new features have been introduced in ENVI-met. In any case, this required a complete redesign of the data structure and the contents of all input and output files. Moreover, the old format lacked versioning information and was very unflexible concering the data sequenzes and the way the data was stored (fixed sign intervalls, all information in a fixed order). Hence, there was no way but to break with the old format and design a new one. |
| |
For the large files such as your Area Input files and the different databases, import and conversion options are given, so you do not need to re-built the big files. For the smaller files (e.g. the files formerly known as Configuration Files .CF), you will need to re-compose them. That makes also sense as the new files also reflect the new model options in ENVI-met. | For the Area Input files, import and conversion options are given through the editor, so you do not need to re-built them. For the smaller files (e.g. the files formerly known as Configuration Files .CF), you will need to re-compose them. That makes also sense as the new files also reflect the new model options in ENVI-met. |
| |
| |
<code XML> | <code XML> |
<SOIL> | <SOIL> |
<ID> AK </ID> | <ID> 00MM00AK </ID> |
<Description> Asphalt (with Gravel </Description> | <Description> Asphalt (with Gravel </Description> |
<versiegelung> 1 </versiegelung> | <versiegelung> 1 </versiegelung> |
</code> | </code> |
| |
== Remark for ''color'' codes == | |
Color codes like in this example are always stored in RGB data. To understand the concept, the decimal value needs to be converted into a hexadecimal value. In hexadecimal, the colors are coded ''$RRGGBB'' where ''RR'', ''GG'' and ''BB'' are the intensities for the red, green and blue component of the color. Each intensity ranges from ''$00'' (not present) to ''$FF'' (full presence). For example ''$00FF00'' is a full red and in decimal this would be '#65280' like in the example above which gives no clue which color this might be. | |
| |
| |
No line-breaks are alowed within one row of data. | No line-breaks are alowed within one row of data. |
| |
| |
**Note:** | |
Valid only for PREVIEW applications: This item has been changed. Previous, the dimensions tags have been "columns" ans "rows" but due to missleading interpretation hve been changed. | |
A test was included in the reader routines allowing old file to be read, but only new format are written. | |
| |
=== ''spare-matrix-3D'' Tags === | === ''spare-matrix-3D'' Tags === |
| |
=== ''bitmap'' Tags === | === ''bitmap'' Tags === |
TODO: Store Format? (-> JPG Stream) | Including bitmaps is not foressen for the moment. |
| |
=== ''collections'' Tag === | === ''collections'' Tag === |
</code> | </code> |
| |
''Collections'' are Multi-Item tags stored as normal item tags. In the example above, the item ''<soilprofil>'' holds a series of 19 individual values (sub-items) which are stored in a comma-sepearated list. | ''Collections'' are Multi-Item tags stored as normal item tags. In the example above, the item ''<soilprofil>'' holds a series of 19 individual values (sub-items) which are stored in a comma-sepearated list (to keep it readable we used only 2 instead of 6 chars for the IDs). |
| |
These kind of tags only work with items that have explicit defined number of subitems to follow. They will only be interpeted correctly with programs understanding the meaning of such a comma-seperated list. In standard XML, this //collection// would have been splitted into 19 sub-items, one for each soil layer. Each of these sub-items would have its own opening and closing tag. For ENVI-met this was considered as an overkill. Therefor the Multi-Item tags have been introduced. | These kind of tags only work with items that have explicit defined number of subitems to follow. They will only be interpeted correctly with programs understanding the meaning of such a comma-seperated list. In standard XML, this //collection// would have been splitted into 19 sub-items, one for each soil layer. Each of these sub-items would have its own opening and closing tag. For ENVI-met this was considered as an overkill. Therefor the Multi-Item tags have been introduced. |
| |
| |
| === Color encoding === |
| Color codes like in the example above are always stored in plain RGB data. To understand the concept, the decimal value needs to be converted into a hexadecimal value. In hexadecimal, the colors are coded ''$RRGGBB'' where ''RR'', ''GG'' and ''BB'' are the intensities for the red, green and blue component of the color. Each intensity ranges from ''$00'' (not present) to ''$FF'' (full presence). For example ''$00FF00'' is a full red and in decimal this would be '#65280' like in the example above which gives no clue which color this might be. |
| |
| |
| |