Activity for Justus Spitzmüller
-
Justus Spitzmüller posted a comment on discussion User Forum
Hello, It is not clear to me from the table which tools are involved. Please always reference them with library name and ID e.g. ta_morphometry 14. The corresponding output then with the identifier e.g. HU which can be taken from the description in the properties window. I can't find the ones you assigned in the table in any of the tools. As a pure guess, however, I would say that the (height) results are in the same unit as the input data set. If the DEM has stored the heights in meters, the result...
-
Greetings, I also assume that many of SAGA's previous applications would run significantly faster on a GPU. However, running an application on a GPU usually means completely re-implementing this application. The two papers you mentioned used CUDA and OpenGL respectively for this. This is not viable for us in this form. The favored solution would be to use the offloading functions of the multiprocessing library OpenMP, which we already use for multi threading on the CPU. OpenAAC also looks promising...
-
I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges Okay good to know. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines). No this is not the popper way. We will not extent or extrapolate the contour line. You will have to use tiling. This is the only proper way to handle this in my opinion. Also, overlap will not help on the outer edges of gridded data, because there will be no overlap there....
-
I see that GDAL simply extends lines/polygons horizontally or vertically to the grid edges Okay good to know. But I believe that the proper way is to extrapolate or extend contours as in the another attached image (blue lines). No this is not the popper way. We will not extent or extrapolate the contour line. You will have to use tiling. This is the only proper way to handle this in my opinion. Also, overlap will not help on the outer edges of gridded data, because there will be no overlap there....
-
This solution is kinda hacky so please take it with a grain of salt. You could copy the column at the meridian and then manipulate the metadata. For example if you have a .sg-grd file extension you cloud open it in a text editor an offset the POSITION_YMIN Value so it wraps around the dateline.
-
I'am sure this will be answered properly in the next days. I see no need for a feature request.
-
10 steps instead of 2 (generate polygons for fill and generate contour lines) with the proposed filter implemented. I think this is irrational. It's a pity, but it looks like you think the suggested filter is useless. I don't think the filter is useless. As i said in this thread I understand the problem, but I can't say how much effort it would take to adapt the tool as suggested Note: I am not the author of the tool. And while my employer welcomes my participation in the open source project and...
-
I suppose that in both options there will be a problem with attributes. Can you explain this further? What problems are you seeing? In second option with polygons to lines conversion all unwanted outer lines of polygons will remain, which will need to be removed. Unfortunately, all of this is complicated by extent issue. Therefore, select a sufficient overlap. The extent problem mentioned is also "only" half a cell. If every tile with sufficient overlap has contour lines as polygons and these are...
-
Thanks for the illustration. The pattern (I believe) I see is that the empty cells have all four points at the nodes. Leaving no Point within the cell. Since your 5x5 shape follows a regular(ish) distribution, but it is not orthogonal and thus the suggestion Shapes to Grid leads to strong artefacts. I would suggest either interpolate or do the grid creation outside of SAGA. (But keep in mind, rectangular grids are a key design element from SAGA)
-
Okay then, I would suggest not to mix the two vector forms when generating the contour lines. For example, you could only generate lines and then filter them as suggested by Volker . And then use Polygon-Line Intersection to split the extent of the grid for the filling. Or you work only with polygons, filter them with my suggested solution and then transfer them with Convert Polygons to Lines into the lines. If you want the Filling to have less contours between the levels, you can also make two passes...
-
Okay then, I would suggest not to mix the two vector forms when generating the contour lines. For example, you could only generate lines and then filter them as suggested by Volker . And then use Polygon-Line Intersection to split the extent of the grid for the filling. Or you work only with polygons, filter them with my suggested solution and then transfer them with Convert Polygons to Lines into the lines. If you want the Filling to have less contours between the levels, you can also make two passes...
-
Okay then, I would suggest not to mix the two vector forms when generating the contour lines. For example, you could only generate lines and then filter them as suggested by Volker . And then use Polygon-Line Intersection to split the extent of the grid for the filling. Or you work only with polygons, filter them with my suggested solution and then transfer them with Convert Polygons to Lines into the lines. If you want the Filling to have less contours between the levels, you can also make two passes...
-
I understand the problem, but I can't say how much effort it would take to adapt the tool as suggested. In my investigations I always choose data sets that are much larger than my area of interest / map because many algorithms behave differently at the edges. I then crop the resulting data sets, such as contour lines, accordingly to my AOI/map. Would this be possible for your investigations?
-
So when it comes to removing small polygons, I would also suggest post-processing with the tool "Polygon Generalization" from the "Polygons" library. There you can set the "Area threshold" and too small ones are then merged with the neighbors.
-
Isn't there a step missing from the procedure? I assume we are talking about the "Basic Terrain Analysis" tool from the "Compound Analysis" library? The input for the tool is a grid. Your described procedure says: shape file load in SAGAgui 9.02 > terrain analysis What is the process from the shape file to the grid dataset? From your previous post I know that you are not interested in creating the dataset from .txt with SAGA and taking an interpolation into account. It seems you have now made the...
-
Isn't there a step missing from the procedure? I assume we are talking about the "Basic Terrain Analysis" tool from the "Compound Analysis" library? The input for the tool is a grid. The described procedure says: shape file load in SAGAgui 9.02 > terrain analysis What is the process from the shape file to the grid dataset? From your previous post I know that you are not interested in creating the dataset from .txt with SAGA and taking an interpolation into account. It seems you have now made the...
-
Export of multiple derivations
-
This is the Bug-Tracker. This is for reporting errors in the software. Please use the Forum to ask questions or for help. Also have a look at our guidelines imho your description above is not sufficient. Closing
-
And now you should be able to set the 'Elevation' and 'Channel Network' raster in the 'Overland Flow Distance to channel network'. It is a common design pattern for grid tools in saga to work within the same grid system.
-
Are the Raster files in the same grid system? If not use the Resampling tool to transfer one to the other system.
-
If computation time is a problem, it may be better to perform this task in the database via SQL using db_pgsql 6. Maybe PostGIS offers a tool for this?
-
You have to create the shapes first with db_pgsql 20 from the database then process it and then export it again with db_pgsql 21.
-
You have to create the shapes first with db_psql 20 from the database then process it and then export it again with db_psql 21.
-
Is the checkbox "Show Object Properties window" available under the "Window-Button"?
-
Is the checkbox "Show Object Properties window" available under "Window"?
-
Description of Cloud and Shadow Detection
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
We currently do not offer a binary for MacOS. However, it is possible to compile the current versions yourself following these instructions. If and how this version can be integrated into QGIS on MacOS I can't say. In case of doubt you have to run the desired tools in the SAGA GUI and then load the results back into QGIS if you wish to continue using QGIS.
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Missing libhdf5_hl when linking vigra plugin
-
No progress for about two months after narrow down the problem and request for more information. Closed for now.
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Build with Clipper2 failed
-
Hi, thank you for tracing the bug down to the changes in gcc13. With commit bd3fb2 and e39336 the missing cstdint inclusion and expected c++ standard version is fixed. This should now work in the future and i am closing this bug :) Regards, Justus
-
PDAL-enabled build fails due to forced c++11
-
it seems to me that the raised C++ standard (to 14) solved the initial issue Glad to hear that the problem is solved so far. As for now the PDAL module builds without problem with c++14, even though other requirements are listed. We definitely need to keep an eye on this and should raise the the standard in the near future. Vigras incompatibility with the c++ standard greater >14 seems to be a big problem for a lot of distributions since vigra is in its "archive" state, every package maintainer has...
-
Great to hear :) Thanks for your work and that saga is now easily usable under fedora! Two final steps: Do you want to add Fedora in the Binary Packages Wiki Page? And could you reevaluate the status of ticket 302 and 303? Kind Regards J Spitzmüller
-
Merge remote-tracking branch 'upstream/master'
-
Hi, in the Wiki we mention MSVC 2017 because this is what most of the team use at this time. I compile it with MSVC 2019 (note: i use wxWidgets as precompiled binary). I think the recommendation for the older version comes because it is the one the libs4saga were built/tested with. I don't think there should be any particular problems with using newer versions and if you find problems we are happy to update our cmake build system for newer versions. but i'm facing some doubts. Do you have specific...
-
Merge remote-tracking branch 'upstream/master'
-
Python cpp interface
-
Saga python Hello World
-
Work on fmask
-
Added fmask tool barebone
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Build with Clipper2 failed
-
PDAL-enabled build fails due to forced c++11
-
Missing libhdf5_hl when linking vigra plugin
-
I could not reproduce the compile error in the past, unfortunately. Because of another ticket, I noticed that Vigra is sometimes patched manually by the maintainers. Which distribution was it here (SUSE?) and which Vigra package was used here?
-
isinf c++ compilation failure : wksp_map_layer.cpp - OS X Lion ; 7.3.0 -> 7.8.2
-
Since the creation of this Ticket the MacOS Build made a lot of progress.
-
pointer freed error GUI and/or CMD ; OSX Lion
-
Since the creation of this Ticket the MacOS Build made a lot of progress.
-
SAGA 7.3.0 - Snow Leopard - MAKE fails now
-
Since the creation of this Ticket the MacOS Build made a lot of progress.
-
CMake compilation error in Arch Linux
-
Problem Create Grid Collection - Saga 8.1.0
-
No further information given, not reproducible, old version. Closing this.
-
Missing license files
-
Hello Today we released Saga 9.0.0 now with a Readme containing the necessary/missing information. Thank you for your help! I'am closing this.
-
Hi Yes we are aware of this and we have already raised the C++ standard to 14 for SAGA 8.5.1. Turns out the fix was not merged until today. Vigra is in version 1.11.1 since 2017 and only got updates to elevate the python bindings or boost. From the Arch-Repo it seems to exist a Patch based on this PR for the c++17 compatibility. On my machine the Vigra-Tools compiles fine with C++17 and so i can not verify this patch work, but the RPM does not apply this one.
-
Removed c++ 11 requirement for cmake
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Hi With "autotools style" i meant the existences of the exact files with the exact names like AUTHORS. Sorry for the misunderstanding. I agree on clarification in the source tarball to differentiate between the API and GUI/CMD licensing and association with the project website and sourceforge repository. At this point, it is certainly appropriate to re-evaluate this entire area and once again check the requirements of other distributions. Do I understand the Fedora Guidelines correctly so far that...
-
Hi The error is difficult to diagnose from a distance. The warning warning: elaborated-type-specifier for a scoped enum must not use the 'class' keyword can be provoked if gcc does not know the underlying datatype of the enum in this case uint32_t. Then I can reproduce the error on my machine if i change uint32_t to say abc i got the same warning with the same following warnings and errors like in your attachment. But it is not clear to me why gcc does not know this type since it is absolute basic......
-
Hi Yes we are aware of this and we have already raised the C++ standard to 14 for SAGA 8.5.1. For the Archlinux AUR package for example I applied a similar patch to the one you provided. Is it possible to use version 8.5.1 for the Fedora build or patch before build/packaging? A compiler that supports C++17 is now required to build PDAL or include PDAL headers in your code Thanks for the information that in the future also C++ 14 will likely not be sufficient.
-
Hi Yes we are aware of this and we have already raised the C++ standard to 14 for SAGA 8.5.1. For the Archlinux AUR package for example I applied a similar patch to the one you provided. Is it possible to use version 8.51 for the Fedora build or patch before build/packaging? A compiler that supports C++17 is now required to build PDAL or include PDAL headers in your code Thanks for the information that in the future also C++ 14 will likely not be sufficient.
-
Hi These files were removed during the migration from autotools to cmake and were in my opinion the autotools style. The GPL and LGPL are currently in the src folder. If this is not sufficient this can of course be corrected. Glad to hear that SAGA is coming to more distributions.
-
These files were removed during the migration from autotools to cmake and were in my opinion the autotools style. The GPL and LGPL are currently in the src folder. If this is not sufficient this can of course be corrected. Glad to hear that SAGA is coming to more distributions.
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Do you have a working Patch for the cmake configuration? It is hard to diagnose this error on your machine from distance.
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
Merge remote-tracking branch 'upstream/master'
-
cmake platform independent c++ 14 min requirement
-
Hello, Glad you want to contribute a tool! How far has your work progressed? Does your source code work with the SAGA API and is the tool a CSG_Tool class? Then the process is very simple. You would only have to choose a suitable tool library and extend the tool library interface. I would suggest libsim_air_flow as a first tip?!? The dev_exercises tool library is a simple and beginner friendly library that helped me a lot at the beginning. https://sourceforge.net/p/saga-gis/code/ci/master/tree/saga-gis/src/tools/develop/dev_exercises/...
-
Removed c++ 11 requirement for cmake
-
Removed c++ 11 requirement for cmake
-
Commit mid work
-
Change Geocoding bing to json
-
Switching dataformat to json
-
Bytes in curl possible utf8 bug on linux
-
Geocoding fixes
-
Fixes on geocoding
-
Changes
-
Compiling SAGA on Linux
1 >