Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:49
    kbevers review_requested #1934
  • 08:43
    kbevers demilestoned #1310
  • 08:43
    kbevers demilestoned #1738
  • 08:42
    kbevers demilestoned #1850
  • 07:12
    sebastic opened #1934
  • 06:48
    sebastic edited #1933
  • 05:12
    sebastic opened #1933
  • 05:12
    sebastic labeled #1933
  • Feb 17 20:22

    kbevers on master

    Remove man3 Makefile from confi… (compare)

  • Feb 17 20:22

    kbevers on 7.0

    Remove man3 Makefile from confi… (compare)

  • Feb 17 20:15

    kbevers on master

    Update CMake setup with new pro… (compare)

  • Feb 17 20:14

    kbevers on 7.0

    Update CMake setup with new pro… (compare)

  • Feb 17 20:04

    kbevers on 7.0

    (compare)

  • Feb 17 20:04
    kbevers closed #1258
  • Feb 17 20:04

    kbevers on master

    Remove man3 files Closes #1258 Make sure that projsync man fil… Update ABI version numbers for … and 2 more (compare)

  • Feb 17 18:53
    cooljeanius starred OSGeo/PROJ
  • Feb 17 15:09
    avancinirodrigo commented #1932
  • Feb 17 15:08
    avancinirodrigo commented #1932
  • Feb 17 15:07
    avancinirodrigo commented #1932
Ryan
@mccarthyryanc
@kbevers , I think that will work, I forgot affine transforms had a shear component! Thank you. I'm going to play around with that, and respond to the GIS StackExchange post once I get something working.
Ryan
@mccarthyryanc

I added an answer to the SE post that uses an affine transform in a pipeline definition and applies it using pyproj.Transformer, but not quite a custom CRS. @kbevers I'm trying your suggestion to combine transverse mercator and affine in a single WKT definition, for something like this:

PROJCRS["unknown",
    BASEGEOGCRS["NAD83(2011)",
        ...],
    CONVERSION["unknown",
        METHOD["PROJ affine"],
        PARAMETER["xoff",640686.187527129,
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]],
        PARAMETER["yoff",3735329.60112556,
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]],
        PARAMETER["s11",0.00124580862112505,
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]],
        ...],
    CONVERSION["UTM zone 13N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        ...],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]]

Results don't look right with this. Do I have the syntax correct for combining multiple conversion methods? Or am I completely off?

B R S Recht
@brsr
If I have a follow-on to a closed issue, should I add a comment to that issue, or should I make a new issue? The issue is OSGeo/PROJ#1666 and the follow-on is that if the chamb projection expects the control points to be in clockwise order, it should a) be documented somewhere, and/or b) raise an error or warning if the points are in the wrong order. @rouault
B R S Recht
@brsr
I guess a third option is c) rearrange the points and raise a warning, but you get the idea
Even Rouault
@rouault
@brsr I've reopened the issue. Feel free to add comments in it
B R S Recht
@brsr
thanks
Bernard Walker
@GuidedByCthulhu

Sorry to bother, just a minor question. I'm building 6.3.0 using MSVC/cmake, and I've run into a minor snag. I can successfully build, producing proj.lib, and all the executables. However, I would like to also build the proj.dll. The process I am following does not produce this.

I assume it's a minor step that I'm just not aware of.

I'll caveat this with: I'm not a C++ developer (so I really don't know CMake and its options). I am just updating the GDAL and PROJ within our application. I do apologize if this is too trivial to be posted here.

I've seen a post which mentioned adding "set(BUILD_SHARED_LIBS ON)" to my CMakeLists.txt, but that didn't appear to work.
Bernard Walker
@GuidedByCthulhu

This is how I am executing cmake (we link to a version of SQLite we build ourselves):

cmake -DCMAKE_GENERATOR_PLATFORM=x64 -DSQLITE3_INCLUDE_DIR=....\ThirdParty\sqlite\include -DSQLITE3_LIBRARY=....\ThirdParty\sqlite\Release\lib\sqlite3.lib -DEXE_SQLITE3=....\ThirdParty\sqlite\Release\bin\sqlite3.exe -DCMAKE_INSTALL_PREFIX=Release ..

Bernard Walker
@GuidedByCthulhu

An update: I noticed the the lib_proj.cmake was controlling if the dll was built. I flipped the Win32 section to "BUILD_LIBPROJ_SHARED_DEFAULT ON", but I also noticed that BUILD_LIBPROJ_SHARED_DEFAULT wasn't being used by the following if statement to set PROJ_LIBRARY_TYPE.

Forcing it to set PROJ_LIBRARY_TYPE SHARED does build a proj_6_3.dll; though everything else fails as it then doesn't build the .lib.

Howard Butler
@hobu

adding "set(BUILD_SHARED_LIBS ON)" to my CMakeLists.txt, but that didn't appear to work.

Can you please file a ticket on this? It should just work out of the box

Bernard Walker
@GuidedByCthulhu
@hobu Sure. Raise the issue on github, or elsewhere?
Howard Butler
@hobu
github https://github.com/OSGeo/PROJ/ Mention that PROJ doesn't follow the CMake conventions of BUILD_SHARED_LIBS and that hobu said to file a ticket on it. Fill it out with your findings from here
Bernard Walker
@GuidedByCthulhu
Will do, thank you
Howard Butler
@hobu
Nice bug report, thanks!
Bernard Walker
@GuidedByCthulhu
@hobu No problem, and thank you for helping out.
David Hoese
@djhoese
Hi everyone, I'm looking in to how the PROJ proj.db is created and used and I was wondering if the other.extra file (and other files in https://github.com/OSGeo/PROJ/tree/master/data) is being ingested at all. I don't seem to be able to access the definitions from other.extra and I don't see them in the database. Is this file maybe just there for backwards compatibility but not actually used?
Kristian Evers
@kbevers
@djhoese it is used, but it has nothing to do with the database. It is an old init-file, probably only kept for backwards compatibility. As you can see here it is installed in $PROJ_LIB alongside proj.db https://github.com/OSGeo/PROJ/blob/6507e962e04f074ea17478670f04ff6732bfc87d/data/Makefile.am#L3
David Hoese
@djhoese
@kbevers Ok, thanks. So it is there but the information in it (and the other text files most likely) aren't use by PROJ any more (from what I could tell, but could be very wrong)?
Howard Butler
@hobu
@djhoese that is correct AFAIK
David Hoese
@djhoese
The reason I ask is that I'm trying to hack a fake EPSG code in to mapserver/GDAL/rasterio through the proj.db just to do some testing until I can figure out a better longer term solution for serving non-EPSG data in mapserver.
Kristian Evers
@kbevers
@djhoese I was just made the aware of AuthorityFactory_proj_based_transformation test in test/unit/test_factory.cpp - it could be what you are looking for
David Hoese
@djhoese
@kbevers Thanks. I did a test using pycharm to open the database and copy a row from the other_transformation table, change the number, name, and description. I'm using the pyproj python library to make a CRS object by doing CRS('EPSG:930916') (a number I picked) and it doesn't seem to be reading the other_transformation table. It does seem to be accessing the compound_crs table and the projected_crs table which makes sense. Not sure if other_transformation is supposed to be accessible or if this is something missing from pyproj (doubt it since I think they are just using PROJ's functions). CC @snowman2
David Hoese
@djhoese
ah ok, so the other_transformation table is just transformations, not the CRS definitions explicitly (I think)
Kristian Evers
@kbevers
@djhoese exactly. But I believe you could introduce your own CRS by adding a transformation (that you make up) between your custom CRS and an existing widely used CRS. PROJ should be able to figure out how to chain them together in most cases.
David Hoese
@djhoese
@kbevers But I would have to add the custom CRS to one of the *_crs tables, right?
Otherwise, EPSG:XXXX used by mapserver wouldn't find my definition
pdenessen
@pdenessen
Hi guys, I am trying to update Proj manually as the ubunto distro is currently 4.9.3 and for QMapShack I need 5 or later. The installation instruction says I need the latest "Proj-Datumgrid" but when I look in the list then I see that the lastest is "proj-6.3.0" is this the latest which I should use?
Kristian Evers
@kbevers
@djhoese possibly, I am not familiar with that part of the code, so I think you are left with a bit of trial and error for now. You could raise this question on the mailing list, you should be able to get better and more thorough answers there
@pdenessen you need both the latest PROJ (6.3.0) and proj-datumgrid (1.8) packages.
pdenessen
@pdenessen
@kbevers Thanks Kristian. Altough I am bit stuck now on how to install this on Linux Mint (19.3) The documentation on the proj website for the installation is not very clear for me and I think I also run in a number of legacy issues with dependencies on older versions of libproj-dev (4.9.3-2) and proj-data(4.9.3-2). Can you give some guidance here?
Kristian Evers
@kbevers
@pdenessen not based on that level of detail. What is unclear about the installation instructions?
pdenessen
@pdenessen
@kbevers Hi, Managed to download and unzip proj-6.3.0 and proj-datumgrid-1.8.zip. Then I cd into the extracted folder proj-6.3.0 and used ./configure
pdenessen
@pdenessen
then I copied the datumgrid files into proj-6.3.0/data and ran make and thereafter sudo make install. So far so good. "Make check" passed succesfully. Altough the installation of QMapShack fails during compilation indicating I need Proj5.0.0 or higher. When I use "proj --version" I get the error message "proj: error while loading shared libraries: libproj.so.15: cannot open shared object file: No such file or directory"
pdenessen
@pdenessen
@kbevers Hi Kristian, I found an older version libproj on my computer. I removed these and a couple of others and now it seems to work. Next step is to get QMS installed.
Nikos Alexandris
@NikosAlexandris
Dears, has anyone worked with MSG/SEVIRI products? It appears that there is no straightforward way (like a one or two-liner gdalwarp command for example) to project products like land-surface-temperature into "common" coordinate systems.
Nikos Alexandris
@NikosAlexandris

Dears, has anyone worked with MSG/SEVIRI products? It appears that there is no straightforward way (like a one or two-liner gdalwarp command for example) to project products like land-surface-temperature into "common" coordinate systems.

Here and there, there are some references on GDAL and MSG/SEVIRI products. I got it working finally (posted an example in gdal-dev along with an error). Apologies for th noise here.

David Hoese
@djhoese
@NikosAlexandris Sorry I didn't see this sooner, I was going to suggest also looking at the Satpy Python package (I'm a maintainer) which might help you work with some SEVIRI data
Nikos Alexandris
@NikosAlexandris
@djhoese Thank you David. I've been skimming through Quickstart with MSG SEVIRI. Looks neat!
sjfergus
@sjfergus
Hi all. I am attempting to execute cs2cs via CLI on windows (running proj 6.3.0), providing the source CRS as a WKT string within the command (converting to WGS 84) - I'm having no luck. According to the online documentation, the CLI commands can take properly formatted WKT strings as CRS definitions. I am able to get the conversion to work providing the PROJ string equivalent definition, but with WKT being the preferred method, I am hoping to get this working. I've tried placing the WKT string inside none, 1, 2 and 3 double-quotes with no success. I'm using an EPSG.io sourced WKT and PROJ string, so I'm highly confident the CRS definitions are properly constructed. Any guidance is greatly appreciated.
FinnAr
@FinnAr
I'm a newbie to proj. I would like to use the library in my Windows application to transform coordinates between different coordinate systems. I managed to build the library (but gave up on cmake) and link it to my application. Then I tried to use the example code shown at the proj.org website under Quick Start to create a transformation.
However, I realize that I run into problems as the library I built apparently doesn't have any coordinate system definitions. It doesn't know any EPSG projections etc.
Can anyone point me to documentation on how to add such data to the library? Also, if the proj.db is where such data is to be found, I realize that I don't have a clue about how to create or put relevant data into the proj.db file.
Grateful to reaceive any and all help or pointers.
Kristian Evers
@kbevers

I'm using an EPSG.io sourced WKT and PROJ string, so I'm highly confident the CRS definitions are properly constructed. Any guidance is greatly appreciated.

There's no quarantee that what epsg.io does is compatible with modern PROJ. In fact, I am quite certain they have an older PROJ version (< 6.0.0) in the back end of their site

@FinnAr you shouldn't add the EPSG data by yourself. proj.db is supposed to be build and populated as part of the build procedure. I reckon your problems is a faulty build but I can't say more than that with the amount of detail you have given here. I don't understand how you can build PROJ without CMake on Windows... That would be your problem
FinnAr
@FinnAr
@kbevers Well, it's not that difficult to create a native project to compile the source files in Visual Studio. Maybe it's better to use cmake. However, I'm not familiar with cmake, and I can't figure out what is supposed to happen when I run cmake on the project. In any case, I get a couple of fatal errors, such as "CMake Error at CMakeLists.txt:31 (install): install FILES given no DESTINATION!" I call cmake with these parameters:cmake -Wno-dev -G"Visual Studio 16 2019" -Bbuild . - just to see if I can make it complete. I'd be grateful for help on what to put in the command line... I have a learning curve to climb. :)
Kristian Evers
@kbevers
@FinnAr you can have a look at https://github.com/OSGeo/PROJ/blob/master/docs/source/install.rst It is made for the upcomming 7.0.0 release but most still applies to 6.x versions. You can skip the parts about libcurl and libtiff.
Nikos Alexandris
@NikosAlexandris

Dears, has anyone worked with MSG/SEVIRI products? It appears that there is no straightforward way (like a one or two-liner gdalwarp command for example) to project products like land-surface-temperature into "common" coordinate systems.

Here and there, there are some references on GDAL and MSG/SEVIRI products. I got it working finally (posted an example in gdal-dev along with an error). Apologies for th noise here.

Just in case: https://gitlab.com/thermopolis/public/-/blob/master/code/msg/project_lsasaf_to_wgs84.sh

FinnAr
@FinnAr
@kbevers, I think I'll retire from this thread to avoid wasting peoples time. I'll just note that the OSGeo installation tool, when trying to install the binary version of Proj, crashes after having suggested installing some run-time libraries Proj is dependent on, and my accepting to install those libraries.
Brandon McAllister
@bmcallis_gitlab

I'm getting an error trying to install proj63 via yum. It requires sqlite33 which isn't found.

$ docker run --rm -it centos:7 sh
sh-4.2# yum -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm epel-release && yum -y install proj63
...
--> Processing Dependency: sqlite33 for package: proj63-6.3.0-1.rhel7.x86_64
--> Finished Dependency Resolution
Error: Package: proj63-6.3.0-1.rhel7.x86_64 (pgdg10)
           Requires: sqlite33

Any help would be appreciated.

Brandon McAllister
@bmcallis_gitlab
The issue with sqlite33 not being available has been fixed. https://redmine.postgresql.org/issues/5156
Luke Haub
@luke.haub_gitlab
Hi guys. Is anyone able to explain to me how to perform coordinate system transforms with a Z component from the base geographic datum transform in Proj 6.3? I'm trying to upgrade our use of Proj4 to Proj 6.3 and it's really confusing the hell out of me. I started with just testing EPSG:20254 to EPSG:32754 but ended up figuring out that they're 2D Projected coordinate systems. So I switched to using custom WKT strings based on those two but with a 3D cartesian coordinate system where the 3rd axis is "ellipsoidal height" but it still avoids any Z change. Stepping through in a debugger shows that there's a push/pop step in the pipeline that's resetting the Z value. It's calculating it, it's just throwing it away. How to I get it to actually use a 3D instead of 2D geographic transform for the base geographic coordinate system of my two projected coordinate systems?