Transformer.transform exception with empty inputs

[jleinonen]

Calling Transformer.transform with empty inputs results in a ProjError.

Code Sample

import numpy as np
from pyproj import Transformer

transformer = Transformer.from_crs("epsg:4326", "epsg:3857") # error occurs no matter what these are
transformer.transform(np.array([]), np.array([])) # raises a ProjError
transformer.transform([], []) # same as above

Problem description

The Transformer.transform function raises an error with a nondescriptive error message if the inputs are empty lists or arrays:

---------------------------------------------------------------------------
ProjError                                 Traceback (most recent call last)
<ipython-input-6-c1db9b18466b> in <module>
----> 1 transformer.transform([], [])

<path>/lib/python3.8/site-packages/pyproj/transformer.py in transform(self, xx, yy, zz, tt, radians, errcheck, direction)
    428             intime = None
    429         # call pj_transform.  inx,iny,inz buffers modified in place.
--> 430         self._transformer._transform(
    431             inx,
    432             iny,

pyproj/_transformer.pyx in pyproj._transformer._Transformer._transform()

ProjError: x, y, z, and time must be same size

Expected Output

In my view, calling Transformer.transform with empty inputs should result in empty outputs without errors. This is standard NumPy behavior.

If the devs have some reason that this should raise an error, then at least the exception should have a descriptive error message.

Environment Information

pyproj info:
    pyproj: 2.6.1.post1
      PROJ: 7.1.1
  data dir: <path>/share/proj

System:
    python: 3.8.6 | packaged by conda-forge | (default, Oct  7 2020, 19:08:05)  [GCC 7.5.0]
executable: <path>/bin/python
   machine: Linux-3.10.0-1062.12.1.el7.x86_64-x86_64-with-glibc2.10

Python deps:
       pip: 20.2.4
setuptools: 49.6.0.post20201009
    Cython: None

Installation method

Installed from conda.

Conda environment information (if you installed with conda):

Environment (conda list):

$ conda list proj
# packages in environment at <path>:
#
# Name                    Version                   Build  Channel
proj                      7.1.1                h966b41f_3    conda-forge
pyproj                    2.6.1.post1      py38h56787f0_3    conda-forge

Details about conda and system ( conda info ):

$ conda info
     active environment : <redacted>
    active env location : <redacted>
            shell level : 2
       user config file : <redacted>
 populated config files : <redacted>
                         <redacted>
          conda version : 4.9.2
    conda-build version : not installed
         python version : 3.8.3.final.0
       virtual packages : __glibc=2.17=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : <redacted>  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache :<redacted>
                         <redacted>
       envs directories : <redacted>
                          <redacted>
               platform : linux-64
             user-agent : conda/4.9.2 requests/2.24.0 CPython/3.8.3 Linux/3.10.0-1062.12.1.el7.x86_64 rhel/7.7 glibc/2.17
                UID:GID : 25897:30631
             netrc file : None
           offline mode : False

[snowman2]

@jleinonen, sounds like a reasonable change to me. Do you have any interest to submit a PR with the change?

[jleinonen]

Hmm, I suppose I could add something to this specific function, but I would guess that similar behavior exists in other functions in PyPROJ. At least the deprecated function pyproj.transform seems to behave the same way, and I'm not sure if these share the same underlying code. So a proper fix may be better done by someone who better knows the internals of PyPROJ.

[snowman2]

Thanks for the report 👍

[jleinonen]

Thanks for the fix!