[gdal-dev] About installing EXPAT

Abel Pau a.pau at creaf.uab.cat
Mon Sep 25 05:13:15 PDT 2023 

Hi,
I’ve been like hours trying to make EXPAT work in my driver compilation and execution. Without success.
It’s for that reason I am asking for your help. Thanks in advance!

I’ve downloaded EXPAT from GitHub, then I’ve created a folder “build” and executed cmake .. and opened the result with Visual Studio 2019 (the same I’m using for the driver) and I’ve obtained libexpatd.dll and libexpatd.lib (from Debug). Also tried Release.

In Cmakefile.txt of the project I’ve configured this (below # Developer may want to specify some variable to find proper version.):
set(EXPAT_INCLUDE_DIR "D:/GitHub-repository/libexpat/expat/lib")
set(EXPAT_LIBRARY "D:/GitHub-repository/libexpat/expat/build/Debug/libexpatd.lib")
set(EXPAT_USE_STATIC_LIBS ON)
set(GDAL_USE_EXPAT ON)

This appears and:
Found EXPAT: D:/GitHub-repository/libexpat/expat/build/Debug/libexpatd.lib (found version "2.5.0")

Next error appears in copiling:
LINK : fatal error LNK1104: cannot open file 'D:\GitHub-repository\libexpat\expat\build\Debug.obj' [D:\GitHub-repositor
y\GDAL\build\GDAL.vcxproj]

But when I change the configuration to a dinamic dll.
set(EXPAT_LIBRARY "D:/GitHub-repository/libexpat/expat/build/Debug/libexpatd.dll")
set(EXPAT_USE_STATIC_LIBS OFF)

Found EXPAT: D:/GitHub-repository/libexpat/expat/build/Debug/libexpatd.dll (found version "2.5.0") appears on the lines

Then the compilation works fine but an error appears when I am executing from Debug:
This means something like that system cannot found the dll...

[cid:image001.png at 01D9EFBA.6D796C90]

Any idea what is happening?
Thanks!!



De: gdal-dev <gdal-dev-bounces at lists.osgeo.org> En nombre de Abel Pau via gdal-dev
Enviado el: divendres, 22 de setembre de 2023 13:22
Para: Javier Jimenez Shaw <j1 at jimenezshaw.com>
CC: gdal dev <gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

Hi Javier,
thanks for your answer and congrats for being part of the PSC!

I am using GDAL functions in the some parts of the driver in order to be as GDAL-friendly as possible (like open files, close, duplicate strings... etc) but I don’t need them if I use this code in MiraMon (We have our own functions). And it’s useful to have this variable to use them or another. In fact when I copy the code to GDAl project I can simply eliminate that and be happy but if I can use that some places, it’s easier for maintenance.

Thanks!!

De: Javier Jimenez Shaw <j1 at jimenezshaw.com<mailto:j1 at jimenezshaw.com>>
Enviado el: divendres, 22 de setembre de 2023 13:16
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>
CC: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>; gdal dev <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>>
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

I never used that env bastante before, but it seems to be what you describe. See that it is enabled also in the tests, as Even says in the pull 2666

I'm curious. Why do you 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, <gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>> wrote:
Hello again!

I need to know that some shared code is being compiled in GDAL project. I can see that GDAL_COMPILATION  (at Preprocessor definition i Visual Studio Project) is everywhere.

It's apropiate to use that variable to know if I am compiling in GDAL or not?
#ifdef GDAL_COMPILATION
I'm in GDAL
#else
I can ignore that code in gdal
#endif

I'm not using that in the code, only in some .h

Thanks!!!


-----Mensaje original-----
De: Abel Pau
Enviado el: dimarts, 5 de setembre de 2023 15:26
Para: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: RE: [gdal-dev] Creation of a new driver from scratch

Hi again,
after looking for that in the code, I think that versions depends on layer, so -lco is working fine (instead of -dsco, les used).
So, if there is no inconvenience, I'll use -lco Version=V20, etc...

Thanks again

-----Mensaje original-----
De: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>
Enviado el: dimarts, 5 de setembre de 2023 10:43
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>; Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: RE: [gdal-dev] Creation of a new driver from scratch

Sorry
there was a mistake. I meant: ogr2ogr src dst -dsco Version=V11 ...

-----Mensaje original-----
De: gdal-dev <gdal-dev-bounces at lists.osgeo.org<mailto:gdal-dev-bounces at lists.osgeo.org>> En nombre de Abel Pau Enviado el: dimarts, 5 de setembre de 2023 10:26
Para: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

Hi Everyone,

Even, after a meeting with the team, we have took in consideration your opinion and we have discard the option of writing V1.1 and change to V2.0 in the middle of writing.
We have a long tradition with V1.1 and we can't ignore that now but we are going to offer both possibilities: read both and write V1.1 and V2.0 according to user's choice (default 2.0).
If V1.1 is not enough for its limitations we are going to show a message:
"MiraMon format limitations." and "Try V2.0 option." and return OGRERR_FAILURE;

Can you confirm that is enough a -f parameter like?
        For version 1.1:   ogr2ogr src dst - dsco=V11
        For version 2.0:   ogr2ogr src dst - dsco=V20
        For last version (to make it simple for possible future versions):  ogr2ogr src dst - dsco=last_version

Thanks a lot for all your kind support.

-----Mensaje original-----
De: Even Rouault <even.rouault at spatialys.com<mailto:even.rouault at spatialys.com>> Enviado el: dimecres, 30 d’agost de 2023 22:57
Para: Abel Pau <a.pau at creaf.uab.cat<mailto:a.pau at creaf.uab.cat>>; gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Asunto: Re: [gdal-dev] Creation of a new driver from scratch

Abel,
>
> I am interested in proportionate 3 ways of proceeding when a used calls translation from one format to our format.
> way 1: force to write V1.1 and stop writing features if the limit is reached.
> way 2: force to write V2.0 (and stop writing features if the limit is reached (it will no happen in a near future, I think)).
> way 3: leave that the program decides if V1.1 is not enough and then it changes automatically to V2.0. It does it in the middle of the process, when FID or some used internal offset gets the limit.

Not knowing anything about the ecosystem of the miramon format, but ideally I would bend on the side of simplicity if possible, and I would just write V2.0 if V1.1 can be considered as a legacy format, that deserves perhaps only read-only support (at our times of terabytes+ storage capacity, the saving of 4 bytes per feature seems like a anachronic concern). But if you really want to use V1.1 when possible and V2.0 only when possible, and provided that you implement the writing of the final file only at dataset closing as it was my understanding, then you know already the max(FID) of features that have been passed to CreateFeature, so you could decide automatically the version needed. I would strongly discourage starting writing a V1.1 file and then switching to V2.0 in the middle of the writing. That sounds like a serious complication.

>
> So, my questions:
> 1.- Which ogr2ogr parameter is the best for doing that?
>       -f? specificating "MiraMon V1.1" or "MiraMonV2.0" or "MiraMon" (automatic way).

If you really need to implement the 2 formats, a dataset creation option in a single driver would probably be better.


>        Or there is another way I haven't seen (I've read all options
> in https://gdal.org/programs/ogr2ogr.html#ogr2ogr)
>
> 2.- When using -progress some points appear on screen informing the progress. At the end of the progress (or sometimes driver requires) there is a gap of time that driver is writing some pendant information.
-progress works by counting the number of features in the source layer, and computing the progress percentage at each call to CreateFeature()
> There is any way to inform the user what the process is doing?

Not really. You could possibly implement it using CPLDebug() statements if you want to monitor the progress in debug mode (the GeoPackage driver implemets something similar during spatial index writing, which can be a long operation), but there's nothing dedicated in the OGR API or ogr2ogr to monitor the progress of long operations occuring during dataset closing, as most drivers don't need that.

Even


--
http://www.spatialys.com
My software is free, but my time generally not.

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230925/f31c58f4/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 8766 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230925/f31c58f4/attachment-0001.png>

More information about the gdal-dev mailing list