| 11 Feb 2024 |
 das-g | In reply to @imincik:matrix.org
I am sorry for that. I see you are more after maintenance of OSM software. About OSM software: Yeah, but mostly because some of it was still missing in NixPkgs when I needed it, so I've packaged it if I was able to do so. I do use other geospatial software (such at QGIS), too. | 19:01:12 |
| das-g | In reply to @imincik:matrix.org
What we currently maintain is the list of most important geo software. Is the packages to which I'd like to add the team as a co-maintainer in scope for the geospatial team? I kinda assumed so, but probably not all of them are part of the "most important geo software". | 19:03:45 |
| das-g | In reply to @imincik:matrix.org
What we currently maintain is the list of most important geo software. * Is the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are part of the "most important geo software". | 19:04:15 |
| das-g | * Are the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are "most important geo software". | 19:12:17 |
 Ivan Mincik (imincik) | In reply to @das-g:matrix.org
Are the packages to which I'd like to add the team as a co-maintainer with https://github.com/NixOS/nixpkgs/pull/288107 in scope for the geospatial team? I kinda assumed so, but probably not all of them are "most important geo software". I would be happy to maintain all geo software, but I am not sure about protozero or ili2c. All OSM tools are OK. | 19:13:29 |
| das-g | protozero is a dependency of osmium and osm2pgsql | 19:14:40 |
| das-g | (and, at least until now, of nothing else in nixpkgs) | 19:15:05 |
| das-g | ili2c is a part of the Interlis ecosystem. While Interlis is a general data modelling language (and collection of data formats both for the model metadata and for the such-modelled data itself), it's focus is on modelling and transferring spatial data, which is also reflected by its slogan/tagline "The GeoLanguage". | 21:28:22 |
 nh2 | I'm at the GeoWeek 2024 currently (my startup benaco.com is exhibiting with a booth), and I just talked with Howard Butler, devleoper of PDAL :)
Greetings to the Nix geospatial community | 22:07:01 |
| Ivan Mincik (imincik) | In reply to @nh2:matrix.org
I'm at the GeoWeek 2024 currently (my startup benaco.com is exhibiting with a booth), and I just talked with Howard Butler, devleoper of PDAL :)
Greetings to the Nix geospatial community Nice to hear from you. Good luck with your exhibition! Greetings to hobu as well. | 22:12:20 |
| 15 Feb 2024 |
|  kenji joined the room. | 19:15:46 |
| 21 Feb 2024 |
 l0b0 | Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. | 01:18:03 |
| l0b0 | In the meantime I'd really appreciate a review of a prep PR which enables devs to run each of the GDAL tests separately. | 01:19:03 |
| l0b0 | * Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. Update: my attempt failed - nix-build -A gdal.passthru.tests.compress-lerc fails. I'd appreciate any tips. | 02:39:10 |
| l0b0 | * Got a tip from a colleague which might lead to a fix of the missing LERC compression in GDAL. Basically, -DGDAL_USE_INTERNAL_LIBS=OFF means we have to specify all the corresponding variables to include the libraries in other variables. Update: my attempt failed based on the build instructions failed - nix-build -A gdal.passthru.tests.compress-lerc says LERC compression is not available. I'd appreciate any tips. | 02:40:27 |
| Ivan Mincik (imincik) | I spent some time on fixing #238882 , but it looked to me as some kind of bug or problem on GDAL side. I was not able to find any problem in our packaging. l0b0 , have you seen it working (is for example Debian package or GDAL docker image working as expected ?) | 15:27:53 |
| l0b0 | In reply to @imincik:matrix.org
I spent some time on fixing #238882 , but it looked to me as some kind of bug or problem on GDAL side. I was not able to find any problem in our packaging. l0b0 , have you seen it working (is for example Debian package or GDAL docker image working as expected ?) I've only ever seen it work with the internal library, such as in this documentation. I guess most people (including distro maintainers) don't care too much about vendoring these libraries, but this video talks about why NixOS maintainers in particular should care. | 19:24:53 |
| Ivan Mincik (imincik) | What about opening issue in GDAL ? | 19:26:23 |
| Ivan Mincik (imincik) | So many issues in those few instructions in elevation README :) | 19:31:00 |
| Ivan Mincik (imincik) | Good reminder why I use Nix | 19:34:49 |
| Ivan Mincik (imincik) | Please review this trivial patch version update - https://github.com/NixOS/nixpkgs/pull/286713 . Thanks. | 21:04:05 |
| l0b0 | In reply to @imincik:matrix.org
What about opening issue in GDAL ? The first thing someone is going to ask is how to reproduce, and I think I'll need some help with that. There are a bajillion options, and I'm not very familiar with cmake, and even less familiar with GDAL. | 23:46:11 |
| l0b0 | In reply to @imincik:matrix.org
What about opening issue in GDAL ? * The first thing someone is going to ask is how to reproduce, and I think I'll need some help with that. There are a bajillion options, and I'm not very familiar with cmake, and even less familiar with GDAL. I'd be surprised if they'd be OK with running nix-build to test it, but I could start with that. | 23:46:58 |
| l0b0 | Looks like there's already a relevant issue. | 23:48:01 |
| l0b0 | * Looks like there's already a relevant issue. I'll try building libtiff with lerc to see if that fixes it… | 23:50:47 |
| 22 Feb 2024 |
| l0b0 | Is anyone familiar enough with libtiff to create some tests? I feel like if LERC support should be added to libtiff then it should be tested in the libtiff package, not in GDAL. | 00:05:25 |
| Ivan Mincik (imincik) | In reply to @vengmark2:matrix.org
Looks like there's already a relevant issue. I'll try building libtiff with lerc to see if that fixes it… Is it working with https://github.com/NixOS/nixpkgs/pull/290556 | 09:17:53 |
| Ivan Mincik (imincik) | In reply to @vengmark2:matrix.org
Looks like there's already a relevant issue. I'll try building libtiff with lerc to see if that fixes it… * Is it working with https://github.com/NixOS/nixpkgs/pull/290556 ? | 09:17:57 |
| l0b0 | Yep, that's how I verified the libtiff change. There's no libtiff test to verify that LERC support has been enabled yet. | 09:18:44 |
| l0b0 | You should be able to verify with
git checkout l0b0/libtiff-lerc-support
git cherry-pick l0b0/gdal-test-separation
git cherry-pick l0b0/gdal-lerc-support
nix-build --attr pkgs.gdal.passthru.tests
| 09:24:05 |
