try rebasing on top of latest master. It looks like the errors are only
those fixed per
https://github.com/OSGeo/gdal/commit/6703d3071de7155d320a39a580f27230428dcaca
--
http://www.spatialys.com
My software is free, but my time generally not.
___
Ok,
meanwhile this is taking on consideration I took care of ‘\n’, ‘\r’ and “\r\n”
to finish the value of a key correctly with a \0.
All errors have disappeared except one. Almost FINE!
I use now Valgrind (very useful indeed, thanks) but I cannot find something
useful that reveals the problem
My intuition is that reading/writing ini file should be quite
straightforward (unless I'm missing some subtelties of the format). In
port/cpl_conv.cpp, we have a CPLLoadConfigOptionsFromFile() function
that does that in a specific way for the purposes of parsing the GDAL
configuration file
Hi again,
MiraMon files have had INI files containing metadata information for ages.
To read and write sections and key/values from them, we use specific Windows
functions
(https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getprivateprofilestring).
When I started
Hi Even,
thanks for your effort on that.
I’ll spend some time analyzing that but I can imagine where the problem is.
For your information our .REL files are generated in ANSI codification and when
this kind of files are read I forgot to translate to UTF-8.
It’s very probable that this is the
Hi,
I've checkout'ed your branch locally and I can reproduce the error when
running the Python tests. Some of the CI checks give an interesting hint
about this being related to a UTF8 issue, and I wondered why
But running "ogrinfo
Hi,
I declare this motion passed with +1 from PSC members HowardB and me,
and +0 from KurtS
Even
Le 07/03/2024 à 20:07, Even Rouault via gdal-dev a écrit :
Hi,
The flow of comments calming down, I motion to adopt RFC 99: Geometry
coordinate precision
