How to commit a QGIS project to a git repository

[mcgratta]

We would like to start archiving case studies of wildland fire spread in our git repositories. The question is how to organize the folders. Take a look at this example. This folder has two sub-folders -- one contains the qgz file and other files needed to create the FDS input file(s). What is the minimum number of files one needs to open QGIS, run the qgis2fds script, and then run the FDS case. In particular, there seem to be many files in the QGIS/Layers. Are all these files necessary?

[emanuelegissi]

**I updated this comment with the screenshots** Very good question Kevin. I take this opportunity to share some evolutions Jonathan and I are discussing in the work towards qgis2fds 2.0. There are some decisions that need to be made before breaking backward compatibility, and to start off on the right foot with archiving case studies of wildland fire spread. *1) One only file for each vector layer* We have many files because we started using an old but very common format called *ESRI Shapefile*. Even if still much used, this format has several shortcomings ( https://en.wikipedia.org/wiki/Shapefile). (Sorry, but we keep learning by trial-and-error... ;-) Lately I have been thinking about moving the vector layers to a new open file format named *GeoPackage* (https://en.wikipedia.org/wiki/GeoPackage). It is an open, non-proprietary, platform-independent and standards-based data format for geographic information systems built as a set of conventions over a SQLite database. The migration is super easy, just swap the saving format to GeoPackage instead of ESRI Shapefile. All the information for the vector layer would then be contained in *an only gpkg file*. Do you agree?  *2) Domain extent as a vector layer* The domain extent is currently just a couple of coordinates and a CRS, as shown in the following screenshot.  But in general, when I use this feature, I create an *"Extent" vector layer* and then import its *extent coordinates* into the *"Domain extent" field*, using the *"Calculate from layer"* dropdown. I do this because I like to see on the map exactly the terrain that I am exporting, and a polygon is much better than coordinates at showing this. So we have been thinking of guiding the user towards this good practice, by replacing the *"Domain extent" coordinates* with a "*Domain extent layer"*. Instead of having two coordinates, qgis2fds would point to a vector "*Domain extent layer"*, a vector layer graphically representing the exported parcel, that in the majority of the current cases already exists. Do you agree? *3) Drop the Fire layer* The *"Fire layer"* was born as an experiment on how to modify on the fly the landuse raster layer, by overlapping the *"Ignited"* and *"Burned"* boundary conditions. In fact it has many more hidden features: you could easily overlap any other boundary condition on the landuse. But this feature has not been widely used by users, because it is probably overly complicated and hard to explain. Kevin and his student discovered a better way at doing this: the Serval plugin ( https://github.com/lutraconsulting/serval/blob/master/Serval/docs/user_manual.md ). Serval is a QGIS plugin for raster editing, providing convenient tools for modifying raster parts. I love this tool, much more flexible than what we have now. So, I would like to drop the qgis2fds *"Fire layer"* feature and point the user to the Serval plugin. In qgis2fds 2.0 we are going to work only with local layer data, so the ignited and burned zones are going to be included in the landuse local layer. As an added bonus, it is the same tool we are using for improving the continuity of rivers and roads boundary conditions to prevent fire from jumping them. Do you agree? *4) Drop the Wind file in favour of a new Free text file* Currently the "Wind file" specifies the data that is exported within the WIND namelist and its RAMP. This file is a comma-separated values file (*.csv) with an header row and three columns containing: - simulated time in seconds, - wind speed in m/s, - and wind direction in degrees. This has proven very useful, but I am wondering if we could make it more generic to accommodate other FDS namelists. So I suggest dropping the "Wind file" in favour of a new "Free text file". The new Free text file is just a reference to an external text file that is going to be inserted verbatim into the FDS case. The user could write any other namelist there and have it in the FDS case, an example: ``` ! Wind &WIND SPEED=1., RAMP_SPEED_T='ws', RAMP_DIRECTION_T='wd' / &RAMP ID='ws', T= 0, F= 10. / &RAMP ID='ws', T= 600, F= 10. / &RAMP ID='ws', T=1200, F= 20. / &RAMP ID='wd', T= 0, F=315. / &RAMP ID='wd', T= 600, F=270. / &RAMP ID='wd', T=1200, F=360. / ! Output quantities &SLCF AGL_SLICE=5. QUANTITY='LEVEL SET VALUE' / &SLCF AGL_SLICE=5. QUANTITY='TEMPERATURE' VECTOR=T / &SLCF PBX=0.00 QUANTITY='TEMPERATURE' VECTOR=T / &SLCF PBY=0.00 QUANTITY='TEMPERATURE' VECTOR=T / ``` Something similar is already used in BlenderFDS ( https://github.com/firetools/blenderfds/wiki/Quickstart#step-4c-the-text-editor), so many users are already accustomed to this feature. Do you agree? That's all for today, and it is a lot. I am available for further explanation and discussion.

[johodges]

You can see the organization I have been using in the verification cases here: https://github.com/firetools/qgis2fds/tree/dev/verification/tests

The structure is:

base directory

• project file.qgs - Stored as QGIS 3.28 lts firenze
• run_file.sh - bash script defining the run in the command line utility qgis_process for integration with automated testing
• _ref/ - what the expected output is
• data_layers/ - all files needed by the qgis project
  • vector layers stored as gpkg (typically, but a few are still shape files since that is what they were originally)
  • raster layers stored as tif
• output/ - directory for generated files

I am open to suggests on improvement.

[ericvmueller]

One question about point 3, @emanuelegissi...
I have only limited experience with Serval, but what about the case where the user runs a simulation at a finer resolution than the land use layer (e.g. <30m for LANDFIRE) and wants to specify an ignition which has detail at this finer resolution?

Having the input as a vector layer allows qgis2fds to interpolate the ignition boundaries to whatever resolution FDS will use. While, if I understand correctly, the proposed modification would mean that the user first needs to create a raster layer at this new resolution. Perhaps this use-case is not common or it is trivial with Serval, but it may be worth considering.

[mcgratta]

Let me first say that I do not want to make a suggestion that causes qgis2fds to get more complicated or difficult to use. Emanuelle and Jonathan, feel free to tell me that what I am suggesting will make things either worse or more complicated. I also do not want to have 10 different ways to do things because it is difficult to maintain 10 different bits of code. So take my questions and suggestions with a grain of salt.

1) One only file for each vector layer

Yes, I agree, assuming that this new format is better or more accepted or has a longer life expectancy. The fewer files we put in our repositories, the better.

2) Domain extent as a vector layer

Yes. When I first started using qgis2fds, I avoided creating vector layers because it was so much easier to just outline a rectangle with my cursor, which was an option in the pull-down menu. But now it seems that drawing some kind of shape or polygon is a necessity for defining the fire or other layers. So I am good with a vector layer for domain.

3) Drop the Fire layer

I think we should keep the fire layer. If we choose to define the domain extent as a vector layer, using the exact same procedure for the fire makes sense. It is good to use the same technique multiple times as that reinforces the ritual.

4) Drop the Wind file in favour of a new Free text file

I think we should keep the wind as it is now, at least for the moment. I think we should concentrate on the elevation, extent, landuse, and fire layers, making them as easy to create and easy to store locally.

[mcgratta]

Jonathan -- I was not even aware of the .qgs vs ..qgz output options. I think we need to discuss this all in more depth before I commit any more cases. It seems that the .qgs file is ascii text, which in general is better. My only desire is for these cases to be accessible to all users, not just linux. For verification purposes, linus is fine, but in general I'd like the case studies to be accessible to all OS's.

[johodges]

Regarding Ema's 4 points:

1 - Agree 1 file per layer (gpkg for vector, tif for raster)
2 - Agree with defining extent as a vector layer
3 - Prefer to keep the fire layer functionality. Fire perimeters are typically available as a vector format and it is easier for the user this way rather than having to manually edit the fuel map. It also makes it a bit easier to evaluate different initialization scenarios.
4 - No strong preference on free form text versus wind for now. If the plan is eventually to integrate with WPS, WRF, or some other source for weather this is going to look very different at that point anyway.

We can talk about storing out cases during the meeting Friday if needed.

[emanuelegissi]

@Eric Mueller
Good point! In fact you could resample the DEM to a finer resolution, but it is longer and complicated.

So far the consensus is:

1. One only file for each vector layer: Go!
Please @jonathan, can you check our cases for that? As you suggested, the verification cases could also serve as a template for the new wildfire spread cases repo.

2. Domain extent as a vector layer: Go!
I am taking care of that, modifying the parameters.

3. Drop the Fire layer: No go.
You are right, as Jonathan clearly stated, fire perimeters are typically available as a vector format.
I will try to expose the other already existing functionalities of the fire layer in the documentation.

4. Drop the Wind file in favour of a new Free text file: No go.
As Jonathan says, if the plan is eventually to integrate with WPS, WRF, or some other source for weather this is going to look very different at that point anyway.
In the meantime I keep experimenting with the free text file as a solution of total flexibility that could be added even if it does not replace the Wind file functionality.

[johodges]

1 - Done
2 - Leaving as assigned for Ema
3 - I started to reactivate this feature but it needs a bit more work since the sampling algorithm has changed.
4 - Done - Re-added the wind_filepath parameter
5 - Done - (t_begin, t_end) added these as params

[mcgratta]

While you are tinkering, would it be easy to add the simulation time (both T_BEGIN and T_END) to qgis2fds? If so, one could have a working FDS input file without having to edit anything, at least for a basic level set calculation.

[johodges]

Added on dev

[emanuelegissi]

Yes, very easy. Noted down. Just out of curiosity, why T_BEGIN?

[mcgratta]

When using the level set fire spread method, mode=2, the wind field is "frozen" when the fire starts. Thus, one sets T_BEGIN to a negative value to allow the wind field to establish itself, and then it is "frozen" at ignition time, which is often t=0.

[emanuelegissi]

Okay, thank you, I had forgotten that Il giorno mer 9 ago 2023 alle ore 16:23 Kevin McGrattan < ***@***.***> ha scritto:

…

When using the level set fire spread method, mode=2, the wind field is "frozen" when the fire starts. Thus, one sets T_BEGIN to a negative value to allow the wind field to establish itself, and then it is "frozen" at ignition time, which is often t=0. — Reply to this email directly, view it on GitHub <#65 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACXMVY4QB3AGWYHP46WPD53XUOMPZANCNFSM6AAAAAA3HEYCJA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- "When old people used to wish each other peace, we didn't understand the meaning of this word. Now we really understand." [Natalia Balasynovych, mayor of Vasilkiv, Ukraine 2022]

[rezafach]

follow along