Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alexandre Silva
    @Alexandre27
    @snowman2 Can confirm, I used the output from the machine where the task is being made currently to validate the new code and PROJ version is 4.9.3, whilst on mine I'm using the latest. Thank you very much for your help!
    Alan D. Snow
    @snowman2
    Not a problem. The PROJ devs should be able to bring some clarity on the state of the new version.
    David Hoese
    @djhoese
    @snowman2 are pyproj CRS objects hashable? Can I use them in a set or as a dict key?
    ah they are! I don't have pyproj 2.0+ installed on any environments right now so couldn't test. Found the __hash__ method
    Alan D. Snow
    @snowman2
    If you do, make sure that the length of the list isn't too big until 2.3 is released. Seepyproj4/pyproj#374
    *set/dict, not list.
    David Hoese
    @djhoese
    interesting, this is for geoxarray and comparing CRS objects in a single Dataset. Hopefully shouldn't be more than a couple.
    side question @snowman2: any knowledge on when a rasterio version compatible with PROJ 6.0+ will be released? I'm having a real hard time get a preferred conda environment with xarray, rasterio, gdal, and pyproj 2.0+ installed
    David Hoese
    @djhoese
    also, am I wrong, or do DataArray accessors get created every time you access them?
    David Hoese
    @djhoese
    Alan D. Snow
    @snowman2

    any knowledge on when a rasterio version compatible with PROJ 6.0+ will be released?

    Version 1.0.25 should be compatible. It is currently in-progress on the conda-forge feedstock.

    do DataArray accessors get created every time you access them?

    They should be retained for the life of the data array after it is first accessed (unless it is modified with another operation that drops/copies things) as far as I can tell.

    David Hoese
    @djhoese
    @snowman2 Have you seen any segmentation fault issues with pyproj 2.0+ on Linux with the newest conda-forge packages?
    Getting some only on Linux but Windows and OSX seem fine on travis
    issue right now is I'm not really getting a good indication of why/what is causing the seg fault
    or which package to blame
    Alan D. Snow
    @snowman2
    Just this one: pyproj4/pyproj#368
    I would recommend checking the version of PROJ and making sure it is 6.1+ and ensuring that a wheel wasn't installed by accident.
    David Hoese
    @djhoese
    @snowman2
        proj4-6.1.0                |       he751ad9_2         9.4 MB  conda-forge
        pyproj-2.2.1               |   py37hc44880f_0         252 KB  conda-forge
    David Hoese
    @djhoese
    I'm also seeing that on Windows I can't get proj4 6.0+ for some reason. Not sure what's holding that back. Maybe a failed rasterio build. Not sure.
    David Hoese
    @djhoese
    David Hoese
    @djhoese
    @snowman2 Have you ever had different experiences with proj from Linux to Windows on what it accepts? Pyresample had some old documentation that was doing the equivalent of Proj({'proj': 'eqc', 'lon_0': 0.0, 'lat_0': 0.0}) and it seems to error on Windows with RuntimeError: b'major axis or radius = 0 or not given' with pyproj 1.9.6 but with pyproj 2.3 it is fine. I would have assumed pyproj/proj to get more strict, not less strict. And I've never seen this error before. FYI this is PROJ 5.2.0 on Windows that fails.
    Alan D. Snow
    @snowman2
    Works fine for me on Linux:
    $ conda list proj
    # packages in environment at /home/snowal/miniconda3/envs/geocube:
    #
    # Name                    Version                   Build  Channel
    proj4                     5.2.0             he1b5a44_1003    conda-forge
    pyproj                    1.9.6           py36h516909a_1002    conda-forge
    (geocube) snowal@snowal-lx2:~$ python
    Python 3.6.7 | packaged by conda-forge | (default, Jul  2 2019, 02:18:42) 
    [GCC 7.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> from pyproj import Proj
    >>> pj = Proj({'proj': 'eqc', 'lon_0': 0.0, 'lat_0': 0.0})
    >>> pj
    pyproj.Proj('+units=m +proj=eqc +lon_0=0.0 +lat_0=0.0 ', preserve_units=True)
    >>> import pyproj
    >>> pyproj.__version__
    '1.9.6'
    David Hoese
    @djhoese
    hhmmm, I'll have to try on a Windows VM later
    @snowman2 Just because I'm a pain, ETA on pyproj 2.3.1?
    Alan D. Snow
    @snowman2
    Not sure. Hopefully by this weekend if no more issue pop up. Plan on a release candidate this evening.
    Alan D. Snow
    @snowman2
    @djhoese Mind testing out: pip install https://github.com/pyproj4/pyproj/archive/v2.3.1rc2.tar.gz?
    David Hoese
    @djhoese
    @snowman2 That seems to work!
    FYI, did you know you can do pip install git+https://github.com/pyproj4/pyproj.git?
    (no need to make a release)
    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.