[gdal-dev] How to exclude a layer from a translation using ogr2ogr

Hi, I want to convert a Geopackage into MiraMonVector format. I use this command line: ogr2ogr "D:\mapes\2024\044 XP Topografia territorial\topografia-territorial-v1r0-3d-2022_menys_90_modelatge_terreny" "D:\mapes\2024\044 XP Topografia territorial\topografia-territorial-v1r0-3d-2022.gpkg" -f

Re: [gdal-dev] GDAL 3.9.0beta1 available for testing

Hi, I only want to advice that https://download.osgeo.org/gdal/3.9.0/gdal380beta1.zip is not found. Thanks. -Mensaje original- De: gdal-dev En nombre de Even Rouault via gdal-dev Enviado el: dilluns, 22 d’abril de 2024 14:13 Para: gdal-dev@lists.osgeo.org Asunto: [gdal-dev] GDAL

Re: [gdal-dev] Experience with slowness of free() on Windows with lots of allocations?

Hi Even, you’re right. We also know that. When programming the driver I took it in consideration. Our solution is not rely on windows to make a good job with memory and we try to reuse as memory as possible instead of use calloc/free freely. For instance, in the driver, for each feature I

Re: [gdal-dev] There's something strange about two tests that are very similar

ions/runs/8277097153/job/22646788426#step:6:2479>42: 2479<https://github.com/AbelPau/gdal/actions/runs/8277097153/job/22646788426#step:6:2480>42: /Users/runner/work/gdal/gdal/build/autotest/ogr/ogr_basic_test.py:454: AssertionError De: gdal-dev <mailto:gdal-dev-boun...@lists.os

Re: [gdal-dev] There's something strange about two tests that are very similar

ps://github.com/AbelPau/gdal/actions/runs/8277097153/job/22646788426#step:6:2479>42: 2479<https://github.com/AbelPau/gdal/actions/runs/8277097153/job/22646788426#step:6:2480>42: /Users/runner/work/gdal/gdal/build/autotest/ogr/ogr_basic_test.py:454: AssertionError De: gdal-dev En nombre d

Re: [gdal-dev] There's something strange about two tests that are very similar

Hi, I rebased yesterday, after your message, but same error appeared and some more. I rebased al 7.00 again and it seems that there are again some errors in linux builds. I assume it's because of lasts code updates. I'll wait until something stable to rebase again. Enviat des de l'Outlook per

Re: [gdal-dev] There's something strange about two tests that are very similar

fort to make it compile on all platforms and make all analysis tools we use happy not be greater than its benefits) Le 13/03/2024 à 15:00, Abel Pau via gdal-dev a écrit : Hi again, MiraMon files have had INI files containing metadata information for ages. To read and write sections and key/values from

Re: [gdal-dev] There's something strange about two tests that are very similar

al-dev En nombre de Abel Pau via gdal-dev Enviado el: dimecres, 13 de març de 2024 12:38 Para: Even Rouault ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] There's something strange about two tests that are very similar Hi Even, thanks for your effort on that. I’ll spend some time analyzing that

Re: [gdal-dev] There's something strange about two tests that are very similar

22577551385#step:16:17311> 17311<https://github.com/AbelPau/gdal/actions/runs/8254132320/job/22577551385#step:16:17312> See Also 17312<https://github.com/AbelPau/gdal/actions/runs/8254132320/job/22577551385#step:16:17313> 17313<https://github.com/AbelPau/gdal/actions/r

Re: [gdal-dev] There's something strange about two tests that are very similar

<https://github.com/AbelPau/gdal/actions/runs/8254132320/job/22577551385#step:16:17311> 17311<https://github.com/AbelPau/gdal/actions/runs/8254132320/job/22577551385#step:16:17312> See Also 17312<https://github.com/AbelPau/gdal/actions/runs/8254132320/job/22577551385#step:16:17

[gdal-dev] There's something strange about two tests that are very similar

Hi, I have in a single test python file with 3 tests inside: gdal/autotest/ogr/ogr_miramon_vector.py at master * AbelPau/gdal (github.com) In some actions the first and second are Ok but the third is not.

Re: [gdal-dev] Testing the driver

elated Bye VSIMkdirRecursive() · AbelPau/gdal@646b98b (github.com)<https://github.com/AbelPau/gdal/actions/runs/8172351502/job/22342474513> De: gdal-dev mailto:gdal-dev-boun...@lists.osgeo.org>> En nombre de Abel Pau via gdal-dev Enviado el: dimecres, 6 de març de 2024 13:52 Par

Re: [gdal-dev] Testing the driver

(github.com)<https://github.com/AbelPau/gdal/actions/runs/8172351502/job/22342474513> De: gdal-dev mailto:gdal-dev-boun...@lists.osgeo.org>> En nombre de Abel Pau via gdal-dev Enviado el: dimecres, 6 de març de 2024 13:52 Para: Even Rouault mailto:even.roua...@spatial

Re: [gdal-dev] New driver on doc index?

Oh, I assumed that it was an internal error and not findable on google, but you’re right that the process is standard. So, thanks for the answer! De: gdal-dev En nombre de Even Rouault via gdal-dev Enviado el: dilluns, 11 de març de 2024 12:50 Para: gdal-dev@lists.osgeo.org Asunto: Re:

[gdal-dev] New driver on doc index?

Hi, I'm obtaining this error: /__w/gdal/gdal/doc/source/drivers/vector/miramon.rst: WARNING: document isn't included in any toctree The file of the rst is miramon.rst but the name of the driver is MiraMonVector (to make it different from MiraMonRaster, in a future). So, this is a problem? or I

Re: [gdal-dev] Testing the driver

via gdal-dev Enviado el: dijous, 7 de març de 2024 23:42 Para: Even Rouault ; Andrew C Aitchison ; Daniel Evans CC: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) Asunto: Re: [gdal-dev] Testing the driver Hi, It’s in debug mode, yes, as you suggested. yes, it crashes in the same way

Re: [gdal-dev] Testing the driver

Hi, It’s in debug mode, yes, as you suggested. yes, it crashes in the same way. Same big number. It crashes because of the variable is not read from the file (this variable should be 1). But debugging in windows (where not crashes) this variable is set when opening the layer, and then I

Re: [gdal-dev] Testing the driver

Hi, I think that I found the way to debug and the trace makes me ask a question that can be interesting to everybody who uses python and it's not an expert, like me. In my test I do: ds = gdal.OpenEx("data/miramon/Polygons/SimplePolygons/SimplePolFile.pol") lyr = ds.GetLayer(0) assert lyr is

Re: [gdal-dev] Vagrant & VirtualBox

Even setting CPU to 6 it's extremly slow... Any recent experience on that from windows and vagrant + Virtual Box? Any other recomendation? De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dijous, 7 de març de 2024 16:30 Para: gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Vagrant

Re: [gdal-dev] Vagrant & VirtualBox

Perhaps with that? Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| # specify memory size in MiB vm_ram = ENV['VAGRANT_VM_RAM'] || 4096 vm_cpu = ENV['VAGRANT_VM_CPU'] || 2 vm_ram_bytes = vm_ram * 1024 * 1024 De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dijous, 7

Re: [gdal-dev] Vagrant & VirtualBox

I see now that if I shutdown the machine and execute "vagrant up" again + "vagrant ssh" it login automatically. On the other hand cmake -build. is extremly slow. The is anyway to configure more CPU or memory to the process? De: gdal-dev En nombre de Abel Pau via

[gdal-dev] Vagrant & VirtualBox

Hi, in my seekness to find a friendly environment to compile and debug some of my tests I am trying now to use vagrant and a virtualBox. Setting up a development environment - GDAL documentation Once I have both installed I run from

Re: [gdal-dev] Building on windows

Hi, I am a windows and VS2019 user anc C/C++ developer and I asked this question myself a long time ago. Finally the best way for me was: 1) Install vcpkg https://vcpkg.io/en/getting-started and install this on c:/dev/vcpkg. Follow their instructions. And then gdal instructions

Re: [gdal-dev] Testing the driver

python3 -m pytest autotest/ogr/ogr_miramon_vector.py PYTHONMALLOC=malloc valgrind python3 -m pytest autotest/ogr/ogr_miramon_vector.py Le 06/03/2024 à 16:02, Abel Pau via gdal-dev a écrit : Hi again, anyone have any advice for debuging into python code? I am using Pdb but it’s a little confusing. Any

Re: [gdal-dev] Testing the driver

com/AbelPau/gdal/actions/runs/8172351502/job/22342474513> De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dimecres, 6 de març de 2024 13:52 Para: Even Rouault ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Testing the driver Ok, I ‘ve changed that. Let’s see if it’s the p

Re: [gdal-dev] Testing the driver

"/usr/local/lib/python3.8/dist-packages/_pytest/runner.py", line 223 in call_and_report File "/usr/local/lib/python3.8/dist-packages/_pytest/runner.py", line 134 in runtestprotocol File "/usr/local/lib/python3.8/dist-packages/_pytest/runner.py", line 115 in pyt

Re: [gdal-dev] Testing the driver

e 05/03/2024 à 22:28, Abel Pau via gdal-dev a écrit : Hi again, after solving some issues I used WSL (Windows subsystem Linux) to create an environment where I am able to run tests. I run the cmake inside build folder in the environment. It’s slow but finally it finish. After cmake --build .

Re: [gdal-dev] Testing the driver

ote: you don't need the try / except in your test case unless you'd need to some particular cleanup, but that's not the case here. pytest handles test failures nicely Even Le 05/03/2024 à 22:28, Abel Pau via gdal-dev a écrit : Hi again, after solving some issues I used WSL (Windows subsystem Linu

Re: [gdal-dev] Testing the driver

. Does "pytest autotest/ogr/ogr_basic_test.py" work?* Note: you don't need the try / except in your test case unless you'd need to some particular cleanup, but that's not the case here. pytest handles test failures nicely Even Le 05/03/2024 à 22:28, Abel Pau via gdal-dev a écrit : Hi agai

Re: [gdal-dev] Segmentation fault (core dumped) occurs when running ogr2ogr command on container

Hi, I reduced the amount of memory requested. I could do that because I am developing the driver that failed. After my mail I discovered another error, so, perhaps, this was the real cause. 4Mb it’s so small, so I is not the cause... Perhaps you can add --config CPL_DEBUG ON at your command

Re: [gdal-dev] Testing the driver

pytest.fail(f"Test failed with exception: {e}") De: Even Rouault Enviado el: divendres, 9 de febrer de 2024 11:48 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Testing the driver Abel, Le 09/02/2024 à 10:55, Abel Pau via gdal-dev a écrit : Hi, I am at the l

Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

=0x7fffe400) at /gdal/apps/test_ogrsf.cpp:283 #13 0xbac1 in main (nArgc=2, papszArgv=0x55645050) at /gdal/apps/test_ogrsf.cpp:233 -Mensaje original----- De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dilluns, 4 de març de 2024 10:42 Para: Even Rouault ; gdal

Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

Pau via gdal-dev Enviado el: divendres, 1 de març de 2024 16:18 Para: Even Rouault ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions Yes, I hope it's only ONE single mistake because I have my code very protected against that kind of things... Before you

Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

Yes, I hope it's only ONE single mistake because I have my code very protected against that kind of things... Before you said that I am using LOG_STR(); from the test and I've filled it in all possible place it could be something. Remember I have windows and in Visual Studio it works fine... I

Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

st_ogrsf -all_drivers Even Le 01/03/2024 à 11:29, Abel Pau via gdal-dev a écrit : Hi, yesterday I updated my personal branch (soon I’ll do a pull request) but before as Even suggested I’m trying to make green al Actions. The only problem I have now is at some points on tests... But I am missing

Re: [gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

1:29, Abel Pau via gdal-dev a écrit : Hi, yesterday I updated my personal branch (soon I’ll do a pull request) but before as Even suggested I’m trying to make green al Actions. The only problem I have now is at some points on tests... But I am missing something because I there are things I don’t

[gdal-dev] Alpine, gcc 32-bit in Linux Build Actions

Hi, yesterday I updated my personal branch (soon I'll do a pull request) but before as Even suggested I'm trying to make green al Actions. The only problem I have now is at some points on tests... But I am missing something because I there are things I don't understand well. Can anyone give me

Re: [gdal-dev] Some problems after updating

! Thanks again! De: Even Rouault Enviado el: dimarts, 27 de febrer de 2024 20:48 Para: Abel Pau ; Uhrig, Stefan ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Some problems after updating Le 27/02/2024 à 20:44, Abel Pau via gdal-dev a écrit : Hi Stefan, thanks for the answer. In my case

Re: [gdal-dev] Some problems after updating

Hi Stefan, thanks for the answer. In my case the gdald.dll with the recent date from my last compilation is created directly to build\Debug and not to build\apps\Debug (the date it’s older, but not much older, it’s from this morning (??)). Are you sure that your sense of copy is FROM

Re: [gdal-dev] Some problems after updating

s.osgeo.org>> En nombre de Abel Pau via gdal-dev Enviado el: dimarts, 27 de febrer de 2024 10:29 Para: Javier Jimenez Shaw mailto:j...@jimenezshaw.com>> CC: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> Asunto: Re: [gdal-dev] Some problems after updating Ups, forget this co

Re: [gdal-dev] Some problems after updating

In one month ago gdal code the error persists. So I have to conclude that this error is related to my vcpkg update with, so I’m sad because it’s not something easy to solve. De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dimarts, 27 de febrer de 2024 10:29 Para: Javier Jimenez

Re: [gdal-dev] Some problems after updating

e change that "breaks" it. If you cannot replicate the correct behaviour with an older checkout... then the problem is not the source code. Cheers, Javier. On Tue, 27 Feb 2024 at 09:15, Abel Pau via gdal-dev mailto:gdal-dev@lists.osgeo.org>> wrote: Hi again, I built and compiled the Gd

Re: [gdal-dev] Some problems after updating

cate the correct behaviour with an older checkout... then the problem is not the source code. Cheers, Javier. On Tue, 27 Feb 2024 at 09:15, Abel Pau via gdal-dev mailto:gdal-dev@lists.osgeo.org>> wrote: Hi again, I built and compiled the Gdal version in GitHub (without my changes) and the error

Re: [gdal-dev] Some problems after updating

roj" -- FAILED. It could be related? De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dimarts, 27 de febrer de 2024 9:15 Para: gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Some problems after updating Hi again, I built and compiled the Gdal version in GitHub (without my chan

Re: [gdal-dev] Some problems after updating

Hi again, I built and compiled the Gdal version in GitHub (without my changes) and the error is NOT gone. Anyone has compiled very recently and is capable to call ogr2ogr with no problems? Thanks De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dilluns, 26 de febrer de 2024 18:17

Re: [gdal-dev] Some problems after updating

do a full rebuild Le 26/02/2024 à 17:48, Abel Pau via gdal-dev a écrit : It even now doesn’t work from Visual Studio itself. I don’t understand what have changed from yesterday to today (apart from updating vcpkg and gdal code itself). De: gdal-dev <mailto:gdal-dev-boun...@lists.osgeo.org&g

Re: [gdal-dev] Some problems after updating

It even now doesn’t work from Visual Studio itself. I don’t understand what have changed from yesterday to today (apart from updating vcpkg and gdal code itself). De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dilluns, 26 de febrer de 2024 17:42 Para: Even Rouault ; gdal-dev

Re: [gdal-dev] Some problems after updating

, Abel Pau via gdal-dev a écrit : Hi, usually (and always works) I call this two sentences from command line in Windows: cmake -B D:\GitHub-repository\GDAL\build -S . -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake cmake --build D:\GitHub-repository\GDAL\build

[gdal-dev] Some problems after updating

Hi, usually (and always works) I call this two sentences from command line in Windows: cmake -B D:\GitHub-repository\GDAL\build -S . -DCMAKE_TOOLCHAIN_FILE=C:/dev/vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake cmake --build D:\GitHub-repository\GDAL\build The first one generates all projects

Re: [gdal-dev] the /vsistdout mistery and the Update question

to do that! Have a nice weekend De: Even Rouault Enviado el: divendres, 23 de febrer de 2024 16:50 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] the /vsistdout mistery and the Update question Abel, Le 23/02/2024 à 10:34, Abel Pau via gdal-dev a écrit : Hi, after reading

[gdal-dev] the /vsistdout mistery and the Update question

Hi, after reading https://gdal.org/user/virtual_file_systems.html#vsistdout-standard-output-streaming I have to say I don't understand what it means. I which cases it's used? Some example to consider? In the driver I have to do something with that? I have, copied from other, if

Re: [gdal-dev] Some Tests fail in Actions tab of my branch

Oh, you meant that!! I’m gonna delete that file as it never existed :) De: Even Rouault Enviado el: dimecres, 21 de febrer de 2024 13:53 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Some Tests fail in Actions tab of my branch Le 21/02/2024 à 13:44, Abel Pau a écrit : I

Re: [gdal-dev] Some Tests fail in Actions tab of my branch

I think there’ll be no problem about changing to MIT the code we want to add to GDAL. I just copied it from other place like ogr\ogrsf_frmts\mem\ogrmemlayer.cpp Or this is specified somewhere else I don’t know? Thanks for the branch advise. I’ll started a long time ago. I am learning by the

Re: [gdal-dev] Some Tests fail in Actions tab of my branch

Ah ok!! Thanks Even. I’ll review that, then! I didn’t though in that way De: Even Rouault Enviado el: dimecres, 21 de febrer de 2024 12:34 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Some Tests fail in Actions tab of my branch Abel, Hi, lately I’ve been solving some issues

[gdal-dev] Some Tests fail in Actions tab of my branch

Hi, lately I've been solving some issues in my code to finally do a pull request of the MiraMon vector driver. There some things about test in the action I don't understand. I haven't commit any test yet. So I assume it's not my fault. Anyone knows why some of them are failing? At macos_build

Re: [gdal-dev] Building documentation on windows

via gdal-dev a écrit : Hi, I’m trying to build documentation (I am using windows) following the instructions at https://gdal.org/development/dev_documentation.html . Building the docs on Windows is unknown territory. If you really want to do that, you'll probably need to spin up some Linux

[gdal-dev] Building documentation on windows

Hi, I'm trying to build documentation (I am using windows) following the instructions at https://gdal.org/development/dev_documentation.html . When I do make html something is not working: (gdal) D:\GitHub-repository\GDAL\doc>make html mkdir -p build/xml && cd .. && ((cat Doxyfile | sed

Re: [gdal-dev] A qüestion about ICreateLayer() and it's parameter eType

ICreateLayer() and it's parameter eType Le 12/02/2024 à 11:05, Abel Pau via gdal-dev a écrit : Hi again, forget the question. I finally use the variable to inform that layers with measures will be processed without Measures. Otherwise you can just use the parameter type without its name (or by commenting

[gdal-dev] CPLCalloc() used for small memory allocations. And for big ones?

Hi, I am currently working on a driver and have been utilizing CPL_calloc(). However, when attempting to pass the Actions, I encounter errors such as: warning C4244: 'function': conversion from 'MM_INTERNAL_FID' to 'size_t', possible loss of data This issue can be addressed by casting

[gdal-dev] linting test in Code Checks always fails

Hi, I am trying to make my code good for all Actions in the project. Yesterday I was trying to format my code using clang. I looked at that: Commit hooks GDAL provides pre-commit hooks to run code linters before a commit is made. The hooks are cloned with the repository and can be installed

[gdal-dev] Delete untagged containers

Hi, when passing "actions" there is one that I think it's not depending on me: Delete untagged containers Anyone know if I have to do something special to pass this one? Thanks Abel Pau Garcia GIS developer [https://www.creaf.cat/sites/default/files/creaf-signature.png]

Re: [gdal-dev] A qüestion about ICreateLayer() and it's parameter eType

Hi again, forget the question. I finally use the variable to inform that layers with measures will be processed without Measures. Thanks again De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dilluns, 12 de febrer de 2024 10:05 Para: gdal-dev@lists.osgeo.org Asunto: [gdal-dev

[gdal-dev] A qüestion about ICreateLayer() and it's parameter eType

Hi, I am currently addressing all errors in Actions (in my fork), and I've encountered this one in 'slow_tests (slow_tests, ubuntu_22_04, build.sh, test.sh)': /home/runner/work/gdal/gdal/ogr/ogrsf_frmts/miramon/ogrmiramondatasource.cpp:133:44: error: unused parameter 'eType'

[gdal-dev] Testing the driver

Hi, I am at the lasts steps before pulling a request about the MiraMon driver. I need to write some documentation and formalize the tests. After that, I'll do the pull request to github. I am a little confused about the testing. I can use pytest or ctest, right? Which is the favourite? Are there

Re: [gdal-dev] Fields of type List to simple fields with N times the feature?

Hi Even, I finally offer several options. 1.-Export as string list or integer list, o r whatever list; 2.- Export only the fisrt, second,... or last member of the list (it can be usefull sometimes) 3.- export the JSON format you comment in this mail. Every user will be able to choose whatever he

Re: [gdal-dev] vector NODATA for Z values?

would actually be quite generic, and if we wanted to implement them, they would probably better be implemented as options of ogr2ogr (but should be done separately from your driver submission) Even Le 26/01/2024 à 10:59, Abel Pau via gdal-dev a écrit : Hi again, I understand... Perhaps an option

Re: [gdal-dev] vector NODATA for Z values?

XYZ(ST_GeomFromText('POINT (1 2)'),3)" point.json -Jukka Rahkonen- Lähettäjä: gdal-dev mailto:gdal-dev-boun...@lists.osgeo.org>> Puolesta Abel Pau via gdal-dev Lähetetty: torstai 25. tammikuuta 2024 19.07 Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> A

[gdal-dev] vector NODATA for Z values?

Hi, there is any value in GDAL for VECTORS that indicates that a concrete value of a Z is not known (z nodata value)? I couldn't find it anywhere. In MiraMon format we use one concrete number documented in our format pdf (-1.0E+300) an in the driver it's planned to translate it to the same

Re: [gdal-dev] help

vcpkg/vcpkg/scripts/buildsystems/vcpkg.cmake (from cmd in here: D:\GitHub-repository\GDAL) and I compile the project it with this one: cmake --build D:\GitHub-repository\GDAL\build I hope being helpful De: gdal-dev mailto:gdal-dev-boun...@lists.osgeo.org>> En nombre de Abel P

Re: [gdal-dev] help

it with this one: cmake --build D:\GitHub-repository\GDAL\build I hope being helpful De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: dijous, 25 de gener de 2024 15:58 Para: Marián Hadri CC: gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] help Hi,. I have in my windows environment

Re: [gdal-dev] help

Hi,. I have in my windows environment variables (not in any other place) this one: PROJ_LIB = C:\dev\vcpkg\vcpkg\buildtrees\proj\x64-windows-rel\data Attached I send what is in this folder. I think it could be the cause of the problem, but I'm not an expert. Luck and tell us if I solve anything

Re: [gdal-dev] Inquiry about Elevation Values in DXF Conversion using ogr2ogr

HI, I’ve checked that your file is correct but for some reason DXF does not get this capacity of variable elevation. Sorry for not being more helpful. Exporting with QGis also doesn’t work. Perhaps is a matter of the format itself. Have you tried with other files and did it worked sometime?

Re: [gdal-dev] Inquiry about Elevation Values in DXF Conversion using ogr2ogr

Hi, can you send us the file but not attached because it’s not allowed too much size in attachments. Have you converted to another format to see if it’s a matter of KML or it’s general? I’ll try to convert to MiraMon to test the elevations. Thanks De: gdal-dev En nombre de Shahrukh Mirza

[gdal-dev] Fields of type List to simple fields with N times the feature?

Hello, we have tried to generate some layers from MiraMon to SHP, KML, or GPKG, and we have noticed that they do not support "List" field cases. They give a warning like: "The output driver does not seem to natively support IntegerList type for field "XX". It could be interesting if a driver

Re: [gdal-dev] Where to fins my own files

uld change your GDAL_DATA env var now to point to d:\GitHub-repository\gdal\build\data Even De: gdal-dev <mailto:gdal-dev-boun...@lists.osgeo.org> En nombre de Abel Pau via gdal-dev Enviado el: dijous, 18 de gener de 2024 21:13 Para: Even Rouault <mailto:even.roua...@spatialys.com

Re: [gdal-dev] Where to fins my own files

En nombre de Abel Pau via gdal-dev Enviado el: dijous, 18 de gener de 2024 21:13 Para: Even Rouault ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Where to fins my own files Even, thanks a lot. I moved the file to {my GitHubDir}\GDAL\ogr\ogrsf_frmts\miramon\data\MM_m_idofic.csv I changed

Re: [gdal-dev] Where to fins my own files

Even, thanks a lot. I moved the file to {my GitHubDir}\GDAL\ogr\ogrsf_frmts\miramon\data\MM_m_idofic.csv I changed my CMakeLists.txt (see it below) as you indicated. And I deleted from gdal.cmake than now has only 5 files in there) I rebased, deleted my gdal\build directory created the project

Re: [gdal-dev] Where to fins my own files

OSGeo/gdal/pull/9087 . This improves relating data files to the driver that need them. This has no impact on the installed artifacts. Note that when working with a development build, GDAL_DATA should now point to ${top_build_dir}/data, and no longer to ${top_source_dir}/data. Even Le 06/01/2024 à 22:3

Re: [gdal-dev] Where to fins my own files

Hi Even, sure, as you need. We are used to the DBF format; our structure comprises one file for the geographic component, another for metadata, and a DBF for non-geographic attribute data. We have the capability to edit it using a dedicated editor. However, I acknowledge that it might be more

Re: [gdal-dev] Where to fins my own files

Yes, it’s just what I found now!! Thanks a lot Even! It works now!! De: Even Rouault Enviado el: diumenge, 7 de gener de 2024 22:06 Para: Abel Pau ; Sean Gillies CC: gdal dev Asunto: Re: [gdal-dev] Where to fins my own files Le 07/01/2024 à 21:59, Abel Pau a écrit : Thanks for your answers.

Re: [gdal-dev] Where to fins my own files

though it's probably possible with Cmake. Your driver's own directory won't necessarily exist on a system where you install GDAL. For datum files, have you checked whether they already exist in the PROJ project? On Sat, Jan 6, 2024, 2:32 PM Abel Pau via gdal-dev mailto:gdal-dev@lists.osgeo.o

[gdal-dev] Where to fins my own files

Hi, Happy New 2024 to everyone who celebrates it! I am programming a driver and in some point I need to read a file that contains some information (and it's better to keep this in a file than in c code) about the Horizontal Reference System. I have this file here:

Re: [gdal-dev] How to assign a new eType to a feature

20:58, Abel Pau via gdal-dev a écrit : HI, In the GetNewtRawFeature() I am processing all fields and a previusly OFTString type field has to be changed into OFTStringList type. After that, It’ll be probably a OFTString again. I try to do that: poFeature->GetDefnRef()->GetFieldDefn(n

[gdal-dev] How to assign a new eType to a feature

HI, In the GetNewtRawFeature() I am processing all fields and a previusly OFTString type field has to be changed into OFTStringList type. After that, It'll be probably a OFTString again. I try to do that: poFeature->GetDefnRef()->GetFieldDefn(nIField)->SetType(OFTStringList); And when the

Re: [gdal-dev] Why Open() inside QuietDelete()?

Thanks!! De: Even Rouault Enviado el: dijous, 14 de desembre de 2023 18:00 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Why Open() inside QuietDelete()? Le 14/12/2023 à 17:36, Abel Pau via gdal-dev a écrit : Hi, today I have a very inside-code question... I’m wondering why

[gdal-dev] Why Open() inside QuietDelete()?

Hi, today I have a very inside-code question... I'm wondering why when I want to translate from .SHP to MiraMonFile (.PNT) and the destinatination file already exists I seems that the call stack reveals a way that is weird for me and I would like to understand: Translate->Create->(then, as it

Re: [gdal-dev] Creating a diver: specify the options to create a layer

Thanks, I think it’s enough exporting one of the Z. It’s a not very used particularity of the format. De: Even Rouault Enviado el: dimarts, 12 de desembre de 2023 15:35 Para: Abel Pau ; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] Creating a diver: specify the options to create a layer You

Re: [gdal-dev] Creating a diver: specify the options to create a layer

Hi again, thanks for the interest, Even. You’ll rest of me when I finish the driver. I promise :) I didn’t explain it well. I try again. Now I am in the case I want to translate from MiraMon to other GDAL formats. For instance, points MiraMon format can have one or several Z values for each

[gdal-dev] Creating a diver: specify the options to create a layer

Hi, as you probably know I am creating a driver to read formats and translate them to MiraMon and to write any MiraMon file to any format supported in GDAL. One question appears to me today: I used -lco Version=V11 to specify in which version I want to WRITE a MiraMon file. It works fine and I

Re: [gdal-dev] Happy Birthday GDAL!

Happy birthday, people!!! De: gdal-dev En nombre de Javier Jimenez Shaw via gdal-dev Enviado el: divendres, 20 d’octubre de 2023 10:01 Para: gdal dev Asunto: [gdal-dev] Happy Birthday GDAL! GDAL got 25 years old on 2023-10-17 ! I found it in this post

Re: [gdal-dev] Number of fields when creating layer?

Hi Even, then I understand that CreateField() is the only thing that can create the fields and that call to this function stablish the number of fields for ALL EXISTING features at the moment of being called? Thanks for the explanations. I’ll thing if it’s easy to support that or it’s better

Re: [gdal-dev] Number of fields when creating layer?

, Abel Pau via gdal-dev a écrit : Hi everybody, do anyone know if a driver can know the number of fields (and it’s names, etc) of a layer BEFORE starting fetch features? So in the moment of create the layer. I mean, when a driver is creating the own layer it could probably be interested in creating

[gdal-dev] Number of fields when creating layer?

Hi everybody, do anyone know if a driver can know the number of fields (and it's names, etc) of a layer BEFORE starting fetch features? So in the moment of create the layer. I mean, when a driver is creating the own layer it could probably be interested in creating all fields before starting and

Re: [gdal-dev] About installing EXPAT

Stefan, I finally did it well and now it works Thanks a lot for your help!! De: Uhrig, Stefan Enviado el: divendres, 29 de setembre de 2023 17:36 Para: Abel Pau ; gdal dev Asunto: RE: [gdal-dev] About installing EXPAT Hi Abel, Hmm, I did not build with SWIG and Python. Your build log

Re: [gdal-dev] About installing EXPAT

Hi Stefan, thanks for your answer. I’ve installed vcpkg as you recommend. I followed the instructions of the web. After I installed packages you comment. It’s been needed to install phyton3 again cause some recent issues. (error: while looking for phyton:x64-windows: error: while loading phyton:

Re: [gdal-dev] Using ogr2ogr with limited memory

Hi Scott, As a programmer, I can see that when translating from one format to another, there is a minimal amount of memory to work with. The primary objective for a programmer is to be cautious about this and strive to stay within this limit. The easy solution would be to request as much

Re: [gdal-dev] About installing EXPAT

Hi again, well after using CONDA_PREFIX some errors appear about packages that are not included (I suppose). archive.dll libcrypto-3-x64.dll libssl-3-x64.dll liblz4.dll Are they familiar to you? De: Even Rouault Enviado el: dilluns, 25 de setembre de 2023 16:32 Para: Abel Pau ; gdal dev

Re: [gdal-dev] About installing EXPAT

Hi Even, I really appreciate your help. I prefer going by the easy way so once installed miniconda and applied all the described in download.htm. To have the EXPAT installed I do that: conda install expat And the, when I try the cmake .. some issues appear

[gdal-dev] About installing EXPAT

ebug: This means something like that system cannot found the dll... [cid:image001.png@01D9EFBA.6D796C90] Any idea what is happening? Thanks!! De: gdal-dev En nombre de Abel Pau via gdal-dev Enviado el: divendres, 22 de setembre de 2023 13:22 Para: Javier Jimenez Shaw CC: gdal dev Asunto: Re

Re: [gdal-dev] Creation of a new driver from scratch

need to do something different on GDAL compilation? (I assume it is in a exported header) On Thu, 21 Sept 2023, 15:56 Abel Pau via gdal-dev, mailto:gdal-dev@lists.osgeo.org>> wrote: Hello again! I need to know that some shared code is being compiled in GDAL project. I ca

  1   2   >