Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    David Hoese
    @djhoese
    can even add @branch-or-tag
    Alan D. Snow
    @snowman2
    Yes, I have done that before. Using the commit ref is usually the most efficient. There are many who package and deploy pyproj. The pre-release should allow them to build pyproj and report on any errors before the main release.
    David Hoese
    @djhoese
    :+1:
    David Hoese
    @djhoese
    @snowman2 I finally got a Windows VM up for the issue mentioned above. I definitely get the same error on Windows.
    will have to search through PROJ source for where it is coming from
    David Hoese
    @djhoese
    @snowman2 what's the current library holding up PROJ6 support on conda-forge for Windows? GDAL (2.4?) is built for Windows with PROJ6 isn't it?
    Alan D. Snow
    @snowman2
    I thought it was. Are you seeing something different?
    David Hoese
    @djhoese
    Cartopy seems to make it incompatible
    Alan D. Snow
    @snowman2
    Ah, I guess cartopy was built with PROJ 6.1.0 and the pin for most is 6.1.1 maybe? The windows build for 6.1.1 failed for cartopy I think.
    David Hoese
    @djhoese
    @snowman2 That looks right. I filed a cartopy-feedstock bug report. Thanks.
    Alan D. Snow
    @snowman2
    Thanks for filing the report. Hopefully we'll get the stack noci
    *working
    Wim De Clercq
    @Wim-De-Clercq

    Hey all, I'm working on upgrading pyproj from 1.9.4 to a more recent version. But I can't get past a change in output from pyproj.transform if I go to 2.2.1 and higher.

    import pyproj
    result = pyproj.transform(pyproj.Proj(init='EPSG:4326'),
                              pyproj.Proj(init='EPSG:31370'),
                              -50, -50)
    print(result)
    # 2.2.1: (-16648000.756625965, -13287157.707139067)
    # 1.9.4: (-16647936.738681808, -13287195.77167615)

    The outputs are in the comments, and the difference is really too big to ignore.
    What exactly is going wrong here?

    Joris Van den Bossche
    @jorisvandenbossche
    Can you try to remove the 'init' (on 2.2.1) ?
    so use pyproj.Proj('EPSG:4326') instead
    I also have been struggling with this (also with EPSG:31370 ;)), but thought for me the difference was smaller (not in the meters order)
    Wim De Clercq
    @Wim-De-Clercq
    That gives me the same output.
    I do have smaller differences with more realistic data rather than -50, -50
    149372.267141, 175495.954088 vs 149372.214872, 175495.952055.
    But still..
    Joris Van den Bossche
    @jorisvandenbossche
    Yes, I just wanted to say: if I try with values that are within the area of use, I get only the small difference I noticed before.
    In [27]: import pyproj 
        ...: result = pyproj.transform(pyproj.Proj(init='EPSG:4326'), 
        ...:                           pyproj.Proj(init='EPSG:31370'), 
        ...:                           4, 50) 
        ...: print(result)                                                                                                                                                                                             
    (123563.57130448119, 76585.07875370234)
    vs
    In [14]: import pyproj 
        ...: result = pyproj.transform(pyproj.Proj(init='EPSG:4326'), 
        ...:                           pyproj.Proj(init='EPSG:31370'), 
        ...:                           4, 50) 
        ...: print(result)                                                                                                                                                                                             
    (123563.56657479196, 76585.07854289468)
    Joris Van den Bossche
    @jorisvandenbossche
    So the small difference you see here (around 1 mm) is due to a different way to interpret the CRS. If you change (in pyproj 2) the EPSG code with the full proj4 string as found on eg epsg.io:
    In [17]: import pyproj 
        ...: result = pyproj.transform(pyproj.Proj('EPSG:4326'), 
        ...:                           pyproj.Proj('+proj=lcc +lat_1=51.16666723333333 +lat_2=49.8333339 +lat_0=90 +lon_0=4.367486666666666 +x_0=150000.013 +y_0=5400088.438 +ellps=intl +towgs84=-106.869,52.2978,-103
        ...: .724,0.3366,-0.457,1.8422,-1.2747 +units=m +no_defs'), 
        ...:                           4, 50, always_xy=True) 
        ...: print(result)                                                                                                                                                                                             
    (123563.5712753858, 76585.07851246372)
    this gives yet another result, but is closer to the result of pyproj 1.9.6. The difference here has to do with the +towgs84 which is not considered part of the EPSG:31370 definition
    But on your original example, why the difference is so big for unrealistic (outside of the area of use) coordinates, I am not sure
    Wim De Clercq
    @Wim-De-Clercq
    Ah yes, so it's not the transform, but the parsing of the Proj that makes the big difference.
            # 1.9.4:
            #  EPSG : (-16647936.738681808, -13287195.77167615)
            #  proj4: (-16647936.738681808, -13287195.77167615)
            # 2.2.1:
            #  EPSG : (-16648000.756625965, -13287157.707139067)
            #  proj4: (-16647936.738681737, -13287195.771676153)
    Joe McGlinchy
    @joemcglinchy
    hello! I have an installation question, as I can't seem to get Proj to update by updating pyproj. I've tried updating pyproj and proj4 via conda but Proj is still locked at 4.9.3, does anyone know how to get Proj updated to use some of the coordinate systems that depend on Proj version 5.2 in pyproj?
    David Hoese
    @djhoese
    @joemcglinchy Are you using the conda-forge channel at all or only the defaults?
    and do you have strict channel priority set?
    The newest versions of pyproj will be on conda-forge, but it also depends on what versions of other libraries you are using. Some libraries may not be built for the newest versions of PROJ. There are also some limitations about the versions of libraries available on Windows (like GDAL 3.x)
    Joe McGlinchy
    @joemcglinchy
    @djhoese i specified conda-forge on the install command. I don't think I have channel priority set
    David Hoese
    @djhoese

    do you have other PROJ related libraries installed @joemcglinchy? Like rasterio? cartopy? gdal?

    I think it is recommended that you set conda-forge as the channel for the entire environment (I always set it globally) and it is usually best to look in setting a channel_priority to "strict". Otherwise you end up with some packages from the defaults channel and some from conda-forge and they may conflict. What do you get when you do conda install -c conda-forge "pyproj>=2"? Note that pyproj 2.0+ depends on PROJ 6 so this is higher than the PROJ 5.2 that you want, but it's also the newest version so it'd be a good idea to upgrade now if you can.

    Joe McGlinchy
    @joemcglinchy
    @djhoese i do have other libraries installed. There was a conflict wiht my rasterio version (0.36). I tried installing a fresh environment w/ python 3.7, then installing geopandas (which successfully installed gdal and proj 5.2), but now have issues with installing rasterio. That is a whole other can of worms, though.
    David Hoese
    @djhoese
    @joemcglinchy There are much newer versions of rasterio (a 1.0+ release). Is there a reason you have to use that old of a version?
    Or maybe it is a limitation on geopandas?
    Joe McGlinchy
    @joemcglinchy
    yeah for some reason the dependencies on windows get all messed up. If i install current rasterio it upgrades gdal and then gdal is no longer able to be imported
    David Hoese
    @djhoese
    @joemcglinchy A lot of this can be fixed if you force strict channel priority. You may not need it configured globally, but you should at least use it when first creating the environment with all of your main dependencies. What is happening is that conda is looking at packages from conda-forge and defaults and mixing them together, however for C libraries or C-heavy libraries like GDAL, PROJ, rasterio, and pyproj, things can easily get messed up. You can tell this by looking at where the packages are coming from when you do your install/update commands. You'll likely see results from conda-forge and defaults. There are only a few libraries that should actually be coming from defaults; most of them are pretty low-level
    David Hoese
    @djhoese

    @snowman2 Sanity check: PROJ/pyproj have no way of guessing the datum from a PROJ string unless it is explicitly set.

    I realized today that newer versions are automatically converting a/b to ellps if it matches a definition (ex.+ellps=GRS80), but wondering if there is a way to define PROJ parameters to have it do the same for the datum. I'd assume there aren't PROJ parameters to define a datum completely

    David Hoese
    @djhoese
    @snowman2 one more: Ever experienced a bug in rasterio/GDAL where it drops some of the projection parameters? I have a WKT rasterio CRS object that has the Latitude of natural origin and Longitude of natural origin for a laea projection, but after saving to a geotiff with rasterio it has those parameters set to 0
    will work on an example tomorrow probably
    Alan D. Snow
    @snowman2

    PROJ/pyproj have no way of guessing the datum from a PROJ string unless it is explicitly set.

    I believe PROJ has assumed defaults. GRS80 is a common one IIRC. In the docs I see it quite a bit example aea.

    Alan D. Snow
    @snowman2

    @snowman2 one more: Ever experienced a bug in rasterio/GDAL where it drops some of the projection parameters? I have a WKT rasterio CRS object that has the Latitude of natural origin and Longitude of natural origin for a laea projection, but after saving to a geotiff with rasterio it has those parameters set to 0

    Huh, I haven't seen that. But, definitely something to be concerned about.

    Alan D. Snow
    @snowman2

    PROJ/pyproj have no way of guessing the datum from a PROJ string unless it is explicitly set.

    I believe PROJ has assumed defaults. GRS80 is a common one IIRC. In the docs I see it quite a bit example aea.

    Looks like that was ellps not datum. Not sure about the internals on how PROJ matches the datum.

    Juho Häme
    @JuhoHame_twitter
    Hi, I'm looking to change the datum transformation for a CRS. Can I do this by poking around in proj.db?
    Alan D. Snow
    @snowman2
    That answer is out of date. The EPSG file does not exist in newer versions.
    I would recommend looking into either PROJ pyproj4/pyproj#389
    Or, looking into modifying the SQL used to create the PROJ.db in the PROJ code. Or, looking into a custom proj pipeline.
    Juho Häme
    @JuhoHame_twitter
    umm, pyproj 2.4 seems to be using that /usr/share/proj/epsg file?
    Juho Häme
    @JuhoHame_twitter
    (at least it fixed my issue, added alternative datum transformation for 3844)
    Alan D. Snow
    @snowman2
    It still works, you are correct, but it is mostly because the old functionality hasn't been removed. I have seen inconsistencies with it and wouldn't recommend using it.