1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293
|
.. _gotchas:
Gotchas/FAQ
===========
This is a page for some suggestions, gotchas, and FAQs.
Also see:
- :ref:`examples`
- :ref:`PROJ FAQ <faq>`
What are the best formats to store the CRS information?
--------------------------------------------------------
In general, `Well-Known Text (WKT) <https://en.wikipedia.org/wiki/Well-known_text_representation_of_coordinate_reference_systems>`__
or `Spatial Reference ID
(SRID) <https://en.wikipedia.org/wiki/Spatial_reference_system>`__, such as EPSG
codes, are the preferred formats to describe a CRS.
.. note:: WKT2 is preferred over WKT1.
PROJ strings can be lossy for storing CRS information.
If you can avoid it, it is best to not use them.
Additionally, PROJ strings will likely not be supported
in future major version of PROJ for storing CRS information.
More info: https://proj.org/faq.html#what-is-the-best-format-for-describing-coordinate-reference-systems
Axis order changes in PROJ 6+
-----------------------------
- https://proj.org/faq.html#why-is-the-axis-ordering-in-proj-not-consistent
- See warning at the top of :ref:`transformer`
- Examples of how to handle it: :ref:`examples`
- :ref:`min_confidence`
`+init=<auth>:<auth_code>` should be replaced with `<auth>:<auth_code>`
-----------------------------------------------------------------------
The `+init=<auth>:<auth_code>` syntax is deprecated and will be removed
in future versions of PROJ. Also, if you use the `+init` syntax,
you may have problems initializing projections when the other syntax works.
.. code-block:: python
>>> from pyproj import CRS
>>> CRS("ESRI:54009")
<Projected CRS: ESRI:54009>
Name: World_Mollweide
Axis Info [cartesian]:
- E[east]: Easting (metre)
- N[north]: Northing (metre)
Area of Use:
- name: World
- bounds: (-180.0, -90.0, 180.0, 90.0)
Coordinate Operation:
- name: World_Mollweide
- method: Mollweide
Datum: World Geodetic System 1984
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich
>>> CRS("+init=ESRI:54009")
...
pyproj.exceptions.CRSError: Invalid projection: +init=ESRI:54009 +type=crs: (Internal Proj Error: proj_create: cannot expand +init=ESRI:54009 +type=crs)
Proj (Not a generic latitude/longitude to projection converter)
---------------------------------------------------------------
:class:`pyproj.Proj` is limited to converting between geographic and
projection coordinates within one datum. If you have coordinates in latitude
and longitude, and you want to convert it to your projection, it is recommended
to use the :class:`pyproj.transformer.Transformer` as it takes into account datum
shifts.
You likely want to start from `EPSG:4326` (WGS84) for coordinates as
latitude and longitude.
.. code-block:: python
>>> from pyproj import CRS
>>> crs_4326 = CRS("WGS84")
>>> crs_4326
<Geographic 2D CRS: EPSG:4326>
Name: WGS 84
Axis Info [ellipsoidal]:
- Lat[north]: Geodetic latitude (degree)
- Lon[east]: Geodetic longitude (degree)
Area of Use:
- name: World
- bounds: (-180.0, -90.0, 180.0, 90.0)
Datum: World Geodetic System 1984
- Ellipsoid: WGS 84
- Prime Meridian: Greenwich
Then, use the :class:`pyproj.transformer.Transformer` to transform from latitude
and longitude to your projection as you might have a projection with a different
datum.
.. code-block:: python
>>> crs_proj = CRS("EPSG:28992")
>>> crs_proj
<Projected CRS: EPSG:28992>
Name: Amersfoort / RD New
Axis Info [cartesian]:
- X[east]: Easting (metre)
- Y[north]: Northing (metre)
Area of Use:
- name: Netherlands - onshore.
- bounds: (3.2, 50.75, 7.22, 53.7)
Coordinate Operation:
- name: RD New
- method: Oblique Stereographic
Datum: Amersfoort
- Ellipsoid: Bessel 1841
- Prime Meridian: Greenwich
>>> crs_proj.datum == crs_4326.datum
False
>>> from pyproj import Transformer
>>> transformer = Transformer.from_crs(crs_4326, crs_proj)
>>> transformer.transform(52.067567, 5.068913)
(133175.3690698233, 453300.86739169655)
If you use :class:`pyproj.Proj`, it will use the geodetic CRS with
from the projected CRS with the same datum to do the transformation,
which may not be what you want.
.. code-block:: python
>>> from pyproj import Proj
>>> Proj('epsg:28992')(5.068913, 52.067567)
(133148.22970574044, 453192.24450392975)
>>> transg = Transformer.from_crs(crs_proj.geodetic_crs, crs_proj)
>>> transg.transform(52.067567, 5.068913)
(133148.22970574044, 453192.24450392975)
.. _min_confidence:
Why does the EPSG code return when using `EPSG:xxxx` and not with `+init=EPSG:xxxx`?
------------------------------------------------------------------------------------
From: https://gis.stackexchange.com/a/326919/144357
The reason that the EPSG code does not appear with the CRS initialized with
the `init=` syntax is that the CRS are different.
.. code-block:: python
>>> from pyproj import CRS
>>> crs_deprecated = CRS(init="epsg:4544")
>>> crs = CRS("EPSG:4544")
>>> crs == crs_deprecated
False
Upon further inspection of the `Axis Info` section, you can see that the difference
is in the **axis order**.
.. code-block:: python
>>> crs_deprecated
<Projected CRS: +init=epsg:4544 +type=crs>
Name: CGCS2000 / 3-degree Gauss-Kruger CM 105E
Axis Info [cartesian]:
- E[east]: Easting (metre)
- N[north]: Northing (metre)
Area of Use:
- name: China - 103.5°E to 106.5°E
- bounds: (103.5, 22.5, 106.5, 42.21)
Coordinate Operation:
- name: Gauss-Kruger CM 105E
- method: Transverse Mercator
Datum: China 2000
- Ellipsoid: CGCS2000
- Prime Meridian: Greenwich
>>> crs
<Projected CRS: EPSG:4544>
Name: CGCS2000 / 3-degree Gauss-Kruger CM 105E
Axis Info [cartesian]:
- X[north]: Northing (metre)
- Y[east]: Easting (metre)
Area of Use:
- name: China - 103.5°E to 106.5°E
- bounds: (103.5, 22.5, 106.5, 42.21)
Coordinate Operation:
- name: Gauss-Kruger CM 105E
- method: Transverse Mercator
Datum: China 2000
- Ellipsoid: CGCS2000
- Prime Meridian: Greenwich
The reason the `min_confidence` parameter in
:meth:`pyproj.crs.CRS.to_epsg` and :meth:`pyproj.crs.CRS.to_authority`
exists is because you can initialize a CRS in several different methods and
some of them do not always correspond to an EPSG or authortiy code, but it
can be close enough.
For example, if you have a WKT/PROJ string and you use it to create the CRS instance,
in most cases you want to be sure that the EPSG code given by to_epsg will give you a
CRS instance similar to the one created by the WKT/PROJ string.
However, if an EPSG code does not exist that matches you WKT/PROJ string with
a `min_confidence` you don't want to get that EPSG code back as it will make
you think that the WKT/PROJ string and the EPSG code are one and the same when
they are not.
However, if you are only wanting to get the EPSG code that is closest
to the PROJ/WKT string, then you can reduce your min_confidence to a
threshold you are comfortable with.
Here is an example of that:
.. code-block:: python
>>> crs_deprecated = CRS("+init=epsg:4326")
>>> crs_deprecated.to_epsg(100)
>>> crs_deprecated.to_epsg(70)
>>> crs_deprecated.to_epsg(20)
4326
>>> crs_latlon = CRS("+proj=latlon")
>>> crs_latlon.to_epsg(100)
>>> crs_latlon.to_epsg(70)
4326
>>> crs_epsg = CRS.from_epsg(4326)
>>> crs_epsg.to_epsg(100)
4326
>>> crs_wkt = CRS(crs_epsg.to_wkt())
>>> crs_wkt.to_epsg(100)
4326
>>> crs_wkt == crs_epsg
True
>>> crs_epsg == crs_latlon
False
>>> crs_epsg == crs_deprecated
False
Internal PROJ Error ... SQLite error on SELECT
----------------------------------------------
The PROJ database is based on the EPSG database. With each release,
there is a good chance that there are database updates. If you have multiple
versions of PROJ installed on your systems and the search path for
the data directory becomes mixed up, you may see an error message like:
`SQLite error on SELECT`. This is likely due to a version of PROJ
attempting to use an incompatible database.
Debugging tips:
- To get data directory being used: :func:`pyproj.datadir.get_data_dir`
- The order for searching for the data directory can be found in
the docstrings of :func:`pyproj.datadir.get_data_dir`
- To change the data directory: :func:`pyproj.datadir.set_data_dir`
.. _upgrade_transformer:
Upgrading to pyproj 2 from pyproj 1
-----------------------------------
We recommended using the :class:`pyproj.transformer.Transformer` and
:class:`pyproj.crs.CRS` in place of the :class:`pyproj.Proj` and
:meth:`pyproj.transformer.transform`.
Also see:
- :ref:`examples`
- :ref:`optimize_transformations`
.. warning:: :meth:`pyproj.transformer.transform` and :meth:`pyproj.transformer.itransform`
are deprecated.
pyproj 1 style:
>>> from functools import partial
>>> from pyproj import Proj, transform
>>> proj_4326 = Proj(init="epsg:4326")
>>> proj_3857 = Proj(init="epsg:3857")
>>> transformer = partial(transform, proj_4326, proj_3857)
>>> transformer(12, 12)
pyproj 2 style:
>>> from pyproj import Transformer
>>> transformer = Transformer.from_crs("EPSG:4326", "EPSG:3857")
>>> transformer.transform(12, 12)
|