From j1 at jimenezshaw.com  Wed Nov  5 08:58:14 2025
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Wed, 5 Nov 2025 17:58:14 +0100
Subject: [PROJ] inspecting embedded proj.db
Message-ID: <CADRrdKt8Yz4yVTXHjLqF6GHBSs=BqyABDAOSQb_7C5JzM_yo5A@mail.gmail.com>

Hi

I am considering to embed proj.db in libproj.so.
Sometimes I want to look at proj.db later to see why some transformation is
not doing what I expect. (I modify the db)

Is there a way to "extract" proj.db from the library?

I use a normal "DB Browser for SQLite" in my ubuntu to inspect it.

It is not critical. I see that proj.db is in the data folder after
compilation, so I can recompile and watch it. It is more curiosity.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251105/543bee3e/attachment-0001.htm>

From even.rouault at spatialys.com  Wed Nov  5 09:18:04 2025
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 5 Nov 2025 18:18:04 +0100
Subject: [PROJ] inspecting embedded proj.db
In-Reply-To: <CADRrdKt8Yz4yVTXHjLqF6GHBSs=BqyABDAOSQb_7C5JzM_yo5A@mail.gmail.com>
References: <CADRrdKt8Yz4yVTXHjLqF6GHBSs=BqyABDAOSQb_7C5JzM_yo5A@mail.gmail.com>
Message-ID: <39502244-291f-42d3-bef5-d35e6f90808e@spatialys.com>

Hi Javier,

$ objdump -t lib/libproj.so | grep proj_db_data
0000000000682660 l???? O .rodata??? 000000000093b000 proj_db_data
$ dd if=lib/libproj.so of=my_proj.db bs=1 skip=$((16#0000000000682660)) 
count=$((16#000000000093b000))
$ sqlite3 my_proj.db "pragma integrity_check"
ok

Even

Le 05/11/2025 ? 17:58, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> I am considering to embed proj.db in libproj.so.
> Sometimes I want to look at proj.db later to see why some 
> transformation is not doing what I expect. (I modify the db)
>
> Is there a way to "extract" proj.db from the library?
>
> I use a normal "DB Browser for SQLite" in my ubuntu to inspect it.
>
> It is not critical. I see that proj.db is in the data folder after 
> compilation, so I can recompile and watch it. It is more curiosity.
>
> Thanks.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

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


From karney at alum.mit.edu  Fri Nov  7 14:02:51 2025
From: karney at alum.mit.edu (Charles Karney)
Date: Fri, 7 Nov 2025 22:02:51 +0000
Subject: [PROJ] Jacobi's solution for geodesics on a triaxial ellipsoid
Message-ID: <CH3PR12MB85090D15F6BD9AF160A74F18E1C3A@CH3PR12MB8509.namprd12.prod.outlook.com>

I've completed the paper documenting the solution of geodesic problems
for triaxial ellipsoids in GeographicLib.  It's

  C. F. F. Karney,
  Jacobi's solution for geodesics on a triaxial ellipsoid (2025)
  https://arxiv.org/abs/2511.01621<https://arxiv.org/abs/2511.01621">arxiv:2511.01621>

--

Charles Karney <karney at alum.mit.edu>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251107/2899a221/attachment.htm>

From karney at alum.mit.edu  Sat Nov  8 04:57:36 2025
From: karney at alum.mit.edu (Charles Karney)
Date: Sat, 8 Nov 2025 12:57:36 +0000
Subject: [PROJ] Jacobi's solution for geodesics on a triaxial ellipsoid
In-Reply-To: <CH3PR12MB85090D15F6BD9AF160A74F18E1C3A@CH3PR12MB8509.namprd12.prod.outlook.com>
References: <CH3PR12MB85090D15F6BD9AF160A74F18E1C3A@CH3PR12MB8509.namprd12.prod.outlook.com>
Message-ID: <CH3PR12MB8509F059C245FFFBA48CD8A2E1C0A@CH3PR12MB8509.namprd12.prod.outlook.com>

Somehow, the link to arXiv got mangled (depending on your email reader).  Here it is again

https://arxiv.org/abs/2511.01621

-----Original Message-----
From: Charles Karney <karney at alum.mit.edu>
Date: Friday, November 7, 2025 at 17:03
To: proj <proj at lists.osgeo.org>
Subject: Jacobi's solution for geodesics on a triaxial ellipsoid

I've completed the paper documenting the solution of geodesic problems
for triaxial ellipsoids in GeographicLib. It's


C. F. F. Karney,
Jacobi's solution for geodesics on a triaxial ellipsoid (2025)
https://arxiv.org/abs/2511.01621


--
Charles Karney <karney at alum.mit.edu<mailto:karney at alum.mit.edu>>





--

Charles Karney <karney at alum.mit.edu>

702 Prospect Ave, Princeton, NJ 08540-4037



Tel: +1 609 497 4662


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251108/91a8a087/attachment.htm>

From j1 at jimenezshaw.com  Mon Nov 10 15:58:50 2025
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Tue, 11 Nov 2025 00:58:50 +0100
Subject: [PROJ] proj.db in a cross compilation
Message-ID: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>

Hi

I am trying to compile PROJ in emscripten (inside an ubuntu docker image).
How do I produce proj.db?
Any recommended compile options or steps?

I thought there were some workflows cross-compiling (that was the reason to
have the "hash" of the sql code, to not run the check when cross
compiling), but I do not find any example in the github actions.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251111/5c58dcfc/attachment-0001.htm>

From even.rouault at spatialys.com  Mon Nov 10 16:13:34 2025
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 11 Nov 2025 01:13:34 +0100
Subject: [PROJ] proj.db in a cross compilation
In-Reply-To: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>
References: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>
Message-ID: <0499c868-cfd4-40cd-b50c-5ed55a7a603e@spatialys.com>

Hi Javier,

the "key" is to have a sqlite3 executable for the host architecture 
(that you can point to with the EXE_SQLITE3 CMake variable), and the 
libsqlite3 library for the target one.

For example the GDAL CI has an Android setup at 
https://github.com/OSGeo/gdal/blob/master/.github/workflows/android_cmake/start.sh#L45 
(note that is likely not the most canonical way of setting up an Android 
cross compilation, but at least it works...)

Even

Le 11/11/2025 ? 00:58, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> I am trying to compile PROJ in emscripten (inside an ubuntu docker image).
> How do I produce proj.db?
> Any recommended compile options or steps?
>
> I thought there were some workflows cross-compiling (that was the 
> reason to have the "hash" of the sql code, to not run the check when 
> cross compiling), but I do not find any example in the github actions.
>
> Thanks.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

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


From wwcohen at gmail.com  Mon Nov 10 16:14:34 2025
From: wwcohen at gmail.com (Will Cohen)
Date: Mon, 10 Nov 2025 19:14:34 -0500
Subject: [PROJ] proj.db in a cross compilation
In-Reply-To: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>
References: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>
Message-ID: <CAB26zV07F9GBToc9=tZOtMkzdG7ENfXLMMRu6vk6TzFNrRJHUA@mail.gmail.com>

The emscripten build for clj-proj definitely was spitting out proj.db
before it was being embedded!

Happy to talk more off-thread if helpful, or we can diagnose here.

On Mon, Nov 10, 2025 at 6:59?PM Javier Jimenez Shaw via PROJ <
proj at lists.osgeo.org> wrote:

> Hi
>
> I am trying to compile PROJ in emscripten (inside an ubuntu docker image).
> How do I produce proj.db?
> Any recommended compile options or steps?
>
> I thought there were some workflows cross-compiling (that was the reason
> to have the "hash" of the sql code, to not run the check when cross
> compiling), but I do not find any example in the github actions.
>
> Thanks.
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251110/a7680047/attachment.htm>

From wwcohen at gmail.com  Mon Nov 10 16:15:42 2025
From: wwcohen at gmail.com (Will Cohen)
Date: Mon, 10 Nov 2025 19:15:42 -0500
Subject: [PROJ] proj.db in a cross compilation
In-Reply-To: <0499c868-cfd4-40cd-b50c-5ed55a7a603e@spatialys.com>
References: <CADRrdKv1fmTVBjf2aRNQP2qHNc1zE8NAC4y_eORMjyeZ9ed=ow@mail.gmail.com>
 <0499c868-cfd4-40cd-b50c-5ed55a7a603e@spatialys.com>
Message-ID: <CAB26zV0sWr=vteJFzjfoWtBkcqJJxuedyDhzXaib6yfBc-Mqfw@mail.gmail.com>

Ah that?s right ? it precompiled SQLite with emscripten first too, and fed
that to the configuration before rerunning with emcmake.

On Mon, Nov 10, 2025 at 7:13?PM Even Rouault via PROJ <proj at lists.osgeo.org>
wrote:

> Hi Javier,
>
> the "key" is to have a sqlite3 executable for the host architecture
> (that you can point to with the EXE_SQLITE3 CMake variable), and the
> libsqlite3 library for the target one.
>
> For example the GDAL CI has an Android setup at
>
> https://github.com/OSGeo/gdal/blob/master/.github/workflows/android_cmake/start.sh#L45
> (note that is likely not the most canonical way of setting up an Android
> cross compilation, but at least it works...)
>
> Even
>
> Le 11/11/2025 ? 00:58, Javier Jimenez Shaw via PROJ a ?crit :
> > Hi
> >
> > I am trying to compile PROJ in emscripten (inside an ubuntu docker
> image).
> > How do I produce proj.db?
> > Any recommended compile options or steps?
> >
> > I thought there were some workflows cross-compiling (that was the
> > reason to have the "hash" of the sql code, to not run the check when
> > cross compiling), but I do not find any example in the github actions.
> >
> > Thanks.
> >
> > _______________________________________________
> > PROJ mailing list
> > PROJ at lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/proj
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251110/2c7a7ca9/attachment.htm>

From j1 at jimenezshaw.com  Thu Nov 13 08:26:32 2025
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Thu, 13 Nov 2025 17:26:32 +0100
Subject: [PROJ] bound + compound + derived vertical
Message-ID: <CADRrdKvw5AfWy3+GnWnUs_EZn9WRVtR_3vcshEZrxp_gtzBzcw@mail.gmail.com>

Hi

I want to create a WKT2 to define a CRS with some specific conditions.
For context, it is a horizontal (translation, rotation and scale) and
vertical (offset and slope) transformation over a Gau?-Krugger over MGI,
but MGI is defined by the Helmert transformation, and not by the grid file.

To ensure that the Helmert transformation is done, I am creating a BOUNDCRS
with those parameters.
Inside the SOURCECRS I made a Compound with a derived projected and a
derived vertical.
That would allow me to include a proj pipeline with the horizontal
correction, and use the derived vertical (using the Ellipsoid datum) to
apply a vertical offset and slope.

Not a small WKT2, but doable. I just have to copy the parameters I have in
a json in the proper places, and it should work. But no, the vertical
offset and slope is not applied.

Do you know why?

Ok, I thought that I can add the vertical component inside the
derivingconversion of the baseprojcrs. If I add "+step +proj=affine
+zoff=0.55429" it works fine. But I need to add an slope, something like
"+step +proj=vertoffset +lat_0=48 +lon_0=12 +dh=0.55429 +slope_lat=1.234
+slope_lon=0.234"
But no. vertoffset works over a geodetic system, and the deriving
conversion output is a cartersian projected system.

In other examples have seen that the vertoffset pipeline is applied before
the projection. How can I do it? Any idea why is it failing and how can I
work it around?

I can supply some WKT2s with my trials. They are big.

Thank you
Javier

PS If you reached here, I have a present for you: in vscode or vscodium,
you can format a WKT with "ini" format. The brackets are colored, and it
makes easier to detect mistakes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251113/60a3d3f4/attachment.htm>

From even.rouault at spatialys.com  Thu Nov 13 09:56:28 2025
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 13 Nov 2025 18:56:28 +0100
Subject: [PROJ] bound + compound + derived vertical
In-Reply-To: <CADRrdKvw5AfWy3+GnWnUs_EZn9WRVtR_3vcshEZrxp_gtzBzcw@mail.gmail.com>
References: <CADRrdKvw5AfWy3+GnWnUs_EZn9WRVtR_3vcshEZrxp_gtzBzcw@mail.gmail.com>
Message-ID: <9fffa355-f9ca-4214-b83d-913267bf2354@spatialys.com>

Hi Javier,

Do you try to transform from that coumpound of bound to? MGI 3D ? If 
so,that's probably a limitation in the current implementation of 
CoordinateOperationFactory::Private::createOperationsCompoundToGeog(). 
Around line 6026 of coordinateoperationfactory.cpp, there's a case that 
deal with a similar beast but only if transforming to "another CRS whose 
datum is not the same as the horizontal datum of the source".? That 
might be "just" a matter of tweaking that code to remove that 
restriction. Or something else :-)

Even

Le 13/11/2025 ? 17:26, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> I want to create a WKT2 to define a CRS with some specific conditions.
> For context, it is a horizontal (translation, rotation and scale) and 
> vertical (offset and slope) transformation over a Gau?-Krugger over 
> MGI, but MGI is defined by the Helmert transformation, and not by the 
> grid file.
>
> To ensure that the Helmert transformation is done, I am creating a 
> BOUNDCRS with those parameters.
> Inside the SOURCECRS I made a Compound with a derived projected and a 
> derived vertical.
> That would allow me to include a proj pipeline with the horizontal 
> correction, and use the derived vertical (using the Ellipsoid datum) 
> to apply a vertical offset and slope.
>
> Not a small WKT2, but doable. I just have to copy the parameters I 
> have in a json in the proper places, and it should work. But no, the 
> vertical offset and slope is not applied.
>
> Do you know why?
>
> Ok, I thought that I can add the vertical component inside the 
> derivingconversion of the baseprojcrs. If I add "+step +proj=affine 
> +zoff=0.55429" it works fine. But I need to add an slope, something like
> "+step +proj=vertoffset +lat_0=48 +lon_0=12 +dh=0.55429 
> +slope_lat=1.234 +slope_lon=0.234"
> But no. vertoffset works over a geodetic system, and the deriving 
> conversion output is a cartersian projected system.
>
> In other examples have seen that the vertoffset pipeline is applied 
> before the projection. How can I do it??Any idea why is it failing and 
> how can I work it around?
>
> I can supply some WKT2s with my trials. They are big.
>
> Thank you
> Javier
>
> PS If you reached here, I have a present for you: in vscode 
> or?vscodium, you can format a WKT with "ini" format. The brackets are 
> colored, and it makes easier to detect mistakes.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

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


From j1 at jimenezshaw.com  Mon Nov 24 07:14:22 2025
From: j1 at jimenezshaw.com (Javier Jimenez Shaw)
Date: Mon, 24 Nov 2025 16:14:22 +0100
Subject: [PROJ] using pipeline without proj.db
Message-ID: <CADRrdKu0BsGToXnQxPhspuWDsZAR5rVL3YMd8OzOfjAgV9DhYA@mail.gmail.com>

Hi

I am trying to use PROJ in a minimalistic deploy... without proj.db
I only need to do transformations based on a proj-pipeline.

Just something like "+proj=pipeline +step +proj=axisswap +order=2,1 +step
+proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=utm +zone=32
+ellps=WGS84"

I am calling "proj_create(ctx, str)", and I get an error message "Cannot
find proj.db"

First question: Do I need proj.db for that purpose? I would say that not.
The transformation is already defined in the pipeline, I don't need
anything from EPSG. But now I'm not sure.

Second question: if it is not needed, is that a bug or am I doing something
wrong?


Looking at the code of proj_create, I see at the begining:

    // Only connect to proj.db if needed
    if (strstr(text, "proj=") == nullptr || strstr(text, "init=") !=
nullptr) {
        getDBcontextNoException(ctx, __FUNCTION__);
    }

That I assume is not executing getDBcontextNoException. The comment seems
promising for my purpose, but it is failing somewhere. There is a similar
check in the C++ code.

Thanks.
Javier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20251124/d4a11a86/attachment-0001.htm>

From even.rouault at spatialys.com  Mon Nov 24 08:29:14 2025
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 24 Nov 2025 17:29:14 +0100
Subject: [PROJ] using pipeline without proj.db
In-Reply-To: <CADRrdKu0BsGToXnQxPhspuWDsZAR5rVL3YMd8OzOfjAgV9DhYA@mail.gmail.com>
References: <CADRrdKu0BsGToXnQxPhspuWDsZAR5rVL3YMd8OzOfjAgV9DhYA@mail.gmail.com>
Message-ID: <75f9fa36-6dea-46db-b43c-5ac6c52ef710@spatialys.com>

Javier,

I've fixed that in https://github.com/OSGeo/PROJ/pull/4617 . I was a bit 
nervous about that change since it is in the tricky area where we bind 
together the C++ ISO-19111 world and the good-old-C PROJ code, but to my 
surprise, it didn't break any existing test. The dbcontext here could be 
used to substitute EPSG official grid names by PROJ ones, but from what 
I can see, that substitution has already been done before in code 
triggered by proj_create_crs_to_crs() that obviously needed the 
database. So the use cases where we would need to do that again rom 
pj_obj_create() are hopefully null...

Even

Le 24/11/2025 ? 16:14, Javier Jimenez Shaw via PROJ a ?crit?:
> Hi
>
> I am trying to use PROJ in a minimalistic deploy... without proj.db
> I only need to do transformations based on a proj-pipeline.
>
> Just something like "+proj=pipeline +step +proj=axisswap +order=2,1 
> +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=utm 
> +zone=32 +ellps=WGS84"
>
> I am calling "proj_create(ctx, str)", and I get an error message 
> "Cannot find proj.db"
>
> First question: Do I need proj.db for that purpose? I would say that 
> not. The transformation is already defined in the pipeline, I don't 
> need anything from EPSG. But now I'm not sure.
>
> Second question: if it is not needed, is that a bug or am I doing 
> something wrong?
>
>
> Looking at the code of proj_create, I see at the begining:
>
> ? ? // Only connect to proj.db if needed
> ? ? if (strstr(text, "proj=") == nullptr || strstr(text, "init=") != 
> nullptr) {
> ? ? ? ? getDBcontextNoException(ctx, __FUNCTION__);
> ? ? }
>
> That I assume is not executing?getDBcontextNoException. The comment 
> seems promising for my purpose, but it is failing somewhere. There is 
> a similar check in the C++ code.
>
> Thanks.
> Javier.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj

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


From kristian at evers.dev  Tue Nov 25 02:07:47 2025
From: kristian at evers.dev (Kristian Evers)
Date: Tue, 25 Nov 2025 10:07:47 +0000
Subject: [PROJ] PROJ 9.7.1RC1 & PROJ-data 1.24RC1
Message-ID: <28664A88-DF59-43FB-AEED-DC0064943A5E@evers.dev>

Everyone,

It?s once again time for a round of releases of the PROJ and PROJ-data packages. I?ve prepared
release candidates for both, which can be downloaded from

https://download.osgeo.org/proj/proj-9.7.1RC1.tar.gz
https://download.osgeo.org/proj/proj-9.7.1RC1.zip 

https://download.osgeo.org/proj/proj-data-1.24RC1.tar.gz
https://download.osgeo.org/proj/proj-data-1.24RC1.zip

The PROJ-data release adds a grids for the

*  Czech S-JTSK / Krovak East North to S-JTSK/05 / Modified Krovak East North transformation
* Norwegian vertical transformation from NN54 to NN2000 height
* French RGM23 to IGN 2023 Mayotte height transformation

Details for the PROJ release can be found below. 

Please report any issues you may find with the release candidates, either here
on the mailing list or in issues on GitHub.

/Kristian

????????????????????????

# PROJ Release Notes

## 9.7.1

### Updates

* Enable transformations_czechia.sql (#4578)

* Update to EPSG v12.029 (#4586)

### Bug Fixes

* `createOperations()`: fix compound to compound when vertical CRS definition is equivalent but not strictly identical (#4579)

* `createOperations()`: fix compound to compound when horizontal CRS of ? (#4582)

* `projinfo`: make it honour `-k crs` (#4592)

* `proj_clone()`: fix insufficient propagation of `FORCE_OVER=YES` (#4595)

* `BoundCRS::identify`: fix creation of an invalid BoundCRS (that can cause later crashes) for CRS based on 'NTF (Paris)' (#4601)

* WKT/PROJJSON datum ensemble import: allow no members (#4615)