Skip to content

Work-in-progress: Add support for projection using PROJ library >6.1#1331

Merged
lonvia merged 1 commit intoosm2pgsql-dev:masterfrom
joto:proj6-support
Nov 26, 2020
Merged

Work-in-progress: Add support for projection using PROJ library >6.1#1331
lonvia merged 1 commit intoosm2pgsql-dev:masterfrom
joto:proj6-support

Conversation

@joto
Copy link
Copy Markdown
Collaborator

@joto joto commented Nov 20, 2020

This is a stab at adding projection support using the PROJ library from
6.1 onwards. There might be an issue with multithreading, but the old
code most likely already had that issue. This needs to be checked.

The CMake config will prefer using the old API, simply because I don't
know how to check for the new API without it trying to use the new API
with version 5-6.0 which don't have everything we need. The code will
only work from 6.1 onwards.

@joto joto marked this pull request as draft November 20, 2020 15:09
@joto
Copy link
Copy Markdown
Collaborator Author

joto commented Nov 20, 2020

See #922

@joto joto force-pushed the proj6-support branch 5 times, most recently from 13e98e0 to 4faefbf Compare November 25, 2020 15:37
@joto joto marked this pull request as ready for review November 25, 2020 15:37
This commit is adding projection support using the PROJ library from
6.1 onwards.

The CMake config will prefer using the old API, simply because I don't
know how to check for the new API without it trying to use the new API
with version 5-6.0 which don't have everything we need. The code will
only work from 6.1 onwards.

There is a new CMake cache variable USE_PROJ_LIB which can be set to:
* "4": Use version 4 API. Fail CMake if it is not available.
* "6": Use version 6 API. Fail CMake if it is not available.
* "off": Disable PROJ support (resulting binary will only have WGS84
  (4326) and Web Mercator (3857) support)
* "auto": Use version 4 API if available, otherwise try version 6 API
  or fall back to no PROJ support.

Note that we have an issue with multithreading using the PROJ library,
because we use it potentially from multiple threads. The information I
can find about this seems to indicate that this is only a problem for
error reporting, because of the error handling using a global errno-type
variable. So we can't detect failed transformations reliably. But we
don't care about those anyway in the code we have, so I believe this is
probably not a huge problem. This affects the old and the new code, so
this isn't something new. The API version 6 allows to do the
multithreading correctly using a "context" which this commit does use.
But the context is still shared between threads, because we are starting
the threads after the reprojections have been initialized. So all of
this is technically not correct, but we'll probably get away with it for
the time being. We need larger refactorings in the geometry code anyway
which we want to tackle soon and hopefully can resolve this correctly
then.

See osm2pgsql-dev#922
@lonvia lonvia merged commit 354f9ad into osm2pgsql-dev:master Nov 26, 2020
@joto joto deleted the proj6-support branch November 27, 2020 07:46
@jmckenna
Copy link
Copy Markdown

thank-you @joto for this

@jmckenna jmckenna mentioned this pull request Nov 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants