karimbahgat / pycrs Goto Github PK

Hello. I'm very excited about this project. It's what the World needs now. I'm just getting started but have hit an error pretty early. I'm trying to load this projection: http://spatialreference.org/ref/sr-org/6928/

I've tried a few different ways as prescribed by the documentation, but pretty consistently get this exception:

Traceback (most recent call last): File "/home/pat/.PyCharm2018.3/config/scratches/pycrs_test_1.py", line 58, in <module> """) File "/home/pat/sandbox/pycrs-test/venv/lib/python3.6/site-packages/pycrs/parse.py", line 92, in from_ogc_wkt return _from_wkt(string, "ogc", strict) File "/home/pat/sandbox/pycrs-test/venv/lib/python3.6/site-packages/pycrs/parse.py", line 406, in _from_wkt crs = _parse_top(header, content) File "/home/pat/sandbox/pycrs-test/venv/lib/python3.6/site-packages/pycrs/parse.py", line 294, in _parse_top raise Exception("The specified projection name %r could not be found" % projname) Exception: The specified projection name 'Mercator_Auxiliary_Sphere' could not be found

I've tried loading it from the a shapefile using pycrs.load.from_file and below I've included attempts using the ESRI WKT and OGC WKT directly:

crs = pycrs.parse.from_esri_wkt(""" PROJCS[ "WGS_1984_Web_Mercator_Auxiliary_Sphere", GEOGCS[ "GCS_WGS_1984", DATUM[ "D_WGS_1984", SPHEROID["WGS_1984",6378137.0,298.257223563] ], PRIMEM[ "Greenwich",0.0], UNIT["Degree",0.017453292519943295] ], PROJECTION[ "Mercator_Auxiliary_Sphere" ], PARAMETER["False_Easting",0.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",0.0], PARAMETER["Standard_Parallel_1",0.0], PARAMETER["Auxiliary_Sphere_Type",0.0], UNIT["Meter",1.0] ] """)

crs = pycrs.parse.from_ogc_wkt(""" PROJCS[ "WGS_1984_Web_Mercator_Auxiliary_Sphere", GEOGCS[ "GCS_WGS_1984", DATUM[ "D_WGS_1984", SPHEROID["WGS_1984",6378137.0,298.257223563] ], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Mercator_Auxiliary_Sphere"], PARAMETER["False_Easting",0.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",0.0], PARAMETER["Standard_Parallel_1",0.0], PARAMETER["Auxiliary_Sphere_Type",0.0], UNIT["Meter",1.0], AUTHORITY["ESRI","102100"] ] """)

It seems to not like GEOCS.PROJECTION ("Mercator_Auxiliary_Sphere"), but I'm not sure how to work around it. Please let me know if I can provide additional information.

Thank you again. This is great!

NotImplementedError: Unsupported projection: The specified projection name 'Gauss_Kruger' could not be found in the list of supported projections

Do we have a plan to implement Gauss_Kruger projection？

@djhoese wrote:

Another thought on functionality that could be added to these classes (if it doesn't exist somewhere else) would be a "sanitize" or "normalize" function so that I could take any user's PROJ.4 string and get a "consistent" PROJ.4 string back with defaults fill in.

Could that be accomplished simply by parsing the proj4 string, and then converting it back out to proj4? I.e. crs = pycrs.parse.from_proj4(...); sanitized = crs.to_proj4(). In some ways, the parsing function does do some sanity checks and adds in some defaults. If it's sufficient, maybe we could just add it as an example in the docs.

Or are there some issues this method would not cover, so that a sanitizing function would provide some extra value?

I'm getting TypeError: string argument without an encoding when I try to produce ESRI WKT on python 3.

import pycrs
from pycrs.parser import from_proj4

crs = from_proj4('+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ')
crs.to_esri_wkt()

---------------------------------------------------------------------------

TypeError                                 Traceback (most recent call last)

<ipython-input-3-cb542042cd0b> in <module>()
      3 
      4 crs = from_proj4('+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ')
----> 5 crs.to_esri_wkt()


C:\Users\Gregory\Anaconda2\envs\python3\lib\site-packages\pycrs\elements\containers.py in to_esri_wkt(self)
     21 
     22     def to_esri_wkt(self):
---> 23         return "%s" % self.toplevel.to_esri_wkt()
     24 
     25 ##+proj      Projection name (see `proj -l`)


C:\Users\Gregory\Anaconda2\envs\python3\lib\site-packages\pycrs\elements\containers.py in to_esri_wkt(self)
    156 
    157     def to_esri_wkt(self):
--> 158         return 'GEOGCS["%s", %s, %s, %s, AXIS["Lon", %s], AXIS["Lat", %s]]' % (self.name, self.datum.to_esri_wkt(), self.prime_mer.to_esri_wkt(), self.angunit.to_esri_wkt(), self.twin_ax[0].esri_wkt, self.twin_ax[1].esri_wkt )
    159 
    160 #PROJCS


C:\Users\Gregory\Anaconda2\envs\python3\lib\site-packages\pycrs\elements\parameters.py in to_esri_wkt(self)
    364 
    365     def to_esri_wkt(self):
--> 366         return 'UNIT["%s", %s]' %(self.unittype.to_esri_wkt(), self.metermultiplier.to_esri_wkt())
    367 
    368 ##+x_0       False easting


C:\Users\Gregory\Anaconda2\envs\python3\lib\site-packages\pycrs\elements\parameters.py in to_esri_wkt(self)
    323 
    324     def to_esri_wkt(self):
--> 325         return bytes(self.value.esri_wkt)
    326 
    327 # special...


TypeError: string argument without an encoding

Works fine in python 2, though.

import pycrs
from pycrs.parser import from_proj4

crs = from_proj4('+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs ')
crs.to_esri_wkt()

'GEOGCS["Unknown", DATUM["D_WGS_1984", SPHEROID["WGS_1984", 6378137, 298.257223563]], PRIMEM["Greenwich", 0], UNIT["Degree", 0.0174532925199], AXIS["Lon", EAST], AXIS["Lat", NORTH]]'

@djhoese wrote:

I also feel like the way I would have done this is put the crs-specific parsing logic in to a crs module along side the CRS classes that get returned. If the interface is clean enough you could even do a class method from_proj4 on the CRS class that parses a proj4 str/dict and returns the proper CRS class. That is how I would do it, doesn't mean the way it is done now is wrong or bad. Just being opinionated 😉 and laying out the options I see available.
...
After sleeping on it I think the from_proj classmethod is maybe a bad idea given the amount of logic that exists in the parsing code.

About where to place the parsing logic, I agree that putting the logic alongside each individual component would keep things nicely grouped together. It could be something to look at in the future, but for reasons of time and effort I think we'll stick to the current scheme for now, plus I think my reason for originally doing all the logic in one "global" function is that sometimes you need to know the values of other parameters in order to correctly parse a parameter.

It seems one could install pycrs on Pyodide and hence JupyterLite using micropip if it would have a source wheel package on PyPI. Maybe worth a thought?

Is there any maintenance activity for this package? I found some mistakes.

Thx!

As mentioned in

https://www.reddit.com/r/gis/comments/bdnir7/prj2epsgorgsearch_not_working_anymoreanyone_have/

It seems the prj2epsg/search will give 500 internal error, which makes utils.wkt_to_epgs() function doesn't work anymore, is it possible to change to another searching web as alternative (maybe epsg.io?) or provide an cached prj2epsg.json in the project file?

I'm converting an Albers projection from WKT to Proj4. My WKT is:
PROJCS["NAD_1983_Albers",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.2572221010042,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4269"]],PROJECTION["Albers_Conic_Equal_Area"],PARAMETER["standard_parallel_1",29.5],PARAMETER["standard_parallel_2",45.5],PARAMETER["latitude_of_center",23],PARAMETER["longitude_of_center",-96],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]]]

Then this line:
pycrs.parse.from_ogc_wkt(wkt).to_proj4()

Gives:
'+proj=aea +datum=NAD83 +ellps=GRS80 +a=6378137.0 +rf=298.2572221010042 +pm=0 +lat_1=29.5 +lat_2=45.5 +lonc=-96.0 +x_0=0.0 +y_0=0.0 +units=m +axis=enu +no_defs'

As far as I am aware, +lonc should be +lon_0

One of the basic ideas of PyCRS is to provide a taxonomy/ontology of the underlying components of a CRS, which is independent of particular CRS format specifications. Ironically, this is based on the WKT 1.0 format specification, simply because it seems to provide a fairly direct mapping to the underlying mathematical concepts and components.

It seems some of the WKT v1 components, which grew out of the initial ESRI prj file spec, is not ideal in all cases. A new WKT v2 is now defined as an ISO standard, and have made some changes to the ontology that deals with some of the older issues.

This is just a note regarding what the PyCRS API is currently based on, and to say that the next major version of PyCRS should probably be based on WKT v2 instead.

Hi,
I found a new issue,I have a location which is (lon, lat) (215018.25, 4824066.75), and the CRS is EPSG:32650. When I transform this location to epsg:4326 use this code:

lon, lat = 215018.25, 4824066.75
to_proj = pycrs.parse.from_ogc_wkt('GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]').to_proj4()
from_proj = pycrs.parse.from_epsg_code(32650).to_proj4()
t_lon, t_lat = pyproj.transform(pyproj.Proj(from_proj), pyproj.Proj(to_proj), lon, lat)
print(t_lon, t_lat)

I got this result: -6.5258322207676605 43.51516233549309.

Which the lat is right, but the lon is wrong(the correct lon is about 113°),I think the question is located in the CRS’s center of Longitude.

I found an extremely weird behavior with pycrs.parser where the conversion changes randomly with each Python interpreter.

This is the offending script:

import pycrs

# From https://epsg.io/2000
wkt_epsg_2000 = '''PROJCS["Anguilla 1957 / British West Indies Grid",
    GEOGCS["Anguilla 1957",
        DATUM["Anguilla_1957",
            SPHEROID["Clarke 1880 (RGS)",6378249.145,293.465,
                AUTHORITY["EPSG","7012"]],
            AUTHORITY["EPSG","6600"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4600"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-62],
    PARAMETER["scale_factor",0.9995],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    AUTHORITY["EPSG","2000"]]'''

print(pycrs.parser.from_esri_wkt(wkt_epsg_2000).to_proj4())

And this is what happens if I run it from the command line:

$ python wtf.py
+proj=utm +a=6378249.145 +f=293.465 +pm=0.0  +lat_0=0.0 +lon_0=-62.0 +x_0=400000.0 +y_0=0.0 +units=m +axis=enu +no_defs
$ python wtf.py
+proj=utm +a=6378249.145 +f=293.465 +pm=0.0  +lat_0=0.0 +lon_0=-62.0 +x_0=400000.0 +y_0=0.0 +units=m +axis=enu +no_defs
$ python wtf.py
+proj=tmerc +a=6378249.145 +f=293.465 +pm=0.0  +lat_0=0.0 +lon_0=-62.0 +x_0=400000.0 +y_0=0.0 +units=m +axis=enu +no_defs

Notice how the projection changes randomly. I cross checked with @slava-kerner in another machine and the same happens. The problem does not appear within a running Python process.

Hi I am not able to install pycrs due to the following error:

$ pip install pycrs
Collecting pycrs
  Using cached PyCRS-0.1.2.zip
    Complete output from command python setup.py egg_info:
    running egg_info
    creating pip-egg-info/PyCRS.egg-info
    writing pip-egg-info/PyCRS.egg-info/PKG-INFO
    writing top-level names to pip-egg-info/PyCRS.egg-info/top_level.txt
    writing dependency_links to pip-egg-info/PyCRS.egg-info/dependency_links.txt
    writing manifest file 'pip-egg-info/PyCRS.egg-info/SOURCES.txt'
    warning: manifest_maker: standard file '-c' not found

    error: package directory 'pycrs\elements' does not exist

Cheers

How can I parse a projection like this:

{"proj": "aea", "lat_1": 25, "lat_2": 47, "lat_0": 0, "lon_0": 105, "x_0": 0, "y_0": 0, "datum": "WGS84", "units": "m", "no_defs": true}

When using units that are not meters causes problems for pyproj with proj.4 representations.

I am using ESRI:102630 which uses US Survey Feet as its units which is 0.3048006096 m. (It is different from "International feet" or "Feet" which is 0.3048 m.)

In [19]: import pycrs

In [20]: official = pyproj.Proj('+proj=tmerc +lat_0=30 +lon_0=-87.5 +k=0.9999333
333333333 +x_0=600000.0000000001 +y_0=0 +ellps=GRS80 +datum=NAD83 +to_meter=0.30
48006096012192 +no_defs', preserve_units=True)

In [21]: alw_esri = pycrs.parser.from_esri_code(102630)

In [25]: alw_esri.to_proj4()
Out[25]: '+proj=tmerc +datum=NAD83 +ellps=GRS80 +a=6378137.0 +f=298.257222101 +p
m=0  +lon_0=-87.5 +x_0=600000.0000000001 +y_0=0 +k_0=0.9999333333333333 +lat_0=3
0 +units=m +to_meter=0.3048006096012192 +axis=enu +no_defs'

In [22]: converted = pyproj.Proj(alw_esri.to_proj4(), preserve_units=True)

# expected output
In [23]: official(-87.0, 34.75)
Out[23]: (2118695.32804112, 1728420.6727422967)

In [24]: converted(-87.0, 34.75)
Out[24]: (645779.6275461884, 526823.6746992014)  # give meter units

Note the return string foralw_esri.to_proj4() contains +units=m +to_meter=0.3048006096012192. It seems like there should not be a +unit and +to_meter in the same proj.4 code (see Proj.4's Wiki GenParms Units. I've also seen US survey feet represented as +units=us-ft in proj.4 projection codes.

I've worked on this problem a little, but I don't think I quite understand the code enough to make that design decision. The WKT representations seem to depend on the unit and conversion to meters factor being present.

It would be nice to see this project get CI integration with travis (linux and OSX) and appveyor (Windows) to prove that the tests pass now and when changes are made in the future.

I find it useful to use astropy's ci-helpers repository/utility: https://github.com/astropy/ci-helpers

I can provide some information if this is something you'd be interested in.

I typically deal with CRS information as PROJ.4 strings or dictionaries. It would be nice to have an example in the README (or in sphinx documentation?) of how I can create a CRS object from these. Then I could add it to my own objects in place of the PROJ.4 strings/dicts and maybe do things like isinstance(my_crs, CRS) for any special handling. Can I do from pycrs import CRS?

Would like to migrate docs and hosting to full sphinx + readthedocs style and hosting.
As I'm not very experienced with this would welcome any PRs moving in that direction. Once that is done can also change docstrings to be sphinx compatible (#27 ).

First I would like to say this lib helps me a lot. I am using it in conjunction with PyProj lib in several projects already.

Issue:
I have a ESRI WKT string, and in this particular case I know its corresponding EPSG code is 26916 because the ESRI WKT string represents NAD83 UTM Zone 16.

I was trying to re-project a point from above projection into EPSG:3857 using PyProj for a web mapping app, but the result looked incorrect. The following code shows the different results when PyProj objs are init'd by proj.4 string produced from PyCRS and EPSG code.

import pycrs
import pyproj

esri_prj_str_nad83_utm_zone16 = 'PROJCS["NAD_1983_UTM_Zone_16N",GEOGCS["GCS_North_American_1983",DATUM["D_NORTH_AMERICAN_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-87],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]'
fromcrs = pycrs.parser.from_esri_wkt(esri_prj_str_nad83_utm_zone16)
proj4_str = fromcrs.to_proj4()
prj_obj_from_proj4 = pyproj.Proj(proj4_str)

prj_obj_26916_from_epsg = pyproj.Proj("+init=EPSG:26916")
prj_obj_3857_from_epsg = pyproj.Proj("+init=EPSG:3857")

(-9748715.328601453, 3929480.5837150216)

print pyproj.transform(prj_obj_from_proj4, prj_obj_3857_from_epsg, 446495, 3681410)

(-9748750.584671738, 3931248.690782473)

print pyproj.transform(prj_obj_26916_from_epsg, prj_obj_3857_from_epsg, 446495, 3681410)

Thanks

Why can't our package parse 3857?
Use this code:

parse.from_epsg_code(3857)

This will return None

One more projection format we could support is the CF metadata standard, which appears to be used by NetCDF files and possibly elsewhere. Links below could be a good starting point, and actually provides some of the equivalent parameter names:

• https://cfconventions.org/wkt-proj-4.html
• http://cfconventions.org/cf-conventions/cf-conventions.html#grid-mappings-and-projections

https://github.com/conda-forge/staged-recipes

This would make it easier for people using conda (via the conda-forge channel) to install PyCRS.

The docstring style used in this project is something I don't think I've seen before. A lot of python packages use either numpy style or google style docstrings (https://sphinxcontrib-napoleon.readthedocs.io/en/latest/example_google.html) which sphinx can parse automatically using the napoleon extension which is provided with sphinx in recent versions. There is also basic restructuredtext/docutils docstrings but please no. These styles and the tools that parse them sometimes provide additional features beyond just standardizing docstrings between packages. Would eventually switching to one of these standards be something you'd be interested in in the future?

As pointed out in #39 and #40, parse.from_epsg_code() and related functions seem to use an outdated source of information from spatialreference.org, and should probably be updated to use epsg.io.

PRs welcome!

On Pypi, only the 0.1.3 version is available.

Could you consider to push 0.1.4 and 1.0.0 versions please ?

        # INIT CODES
        # eg, +init=EPSG:1234
        if "+init" in partdict:
    
            # first, get the default proj4 string of the +init code
            codetype, code = partdict["+init"].split(":")
            if codetype == "EPSG":
                initproj4 = utils.crscode_to_string("epsg", code, "proj4")
            elif codetype == "ESRI":
                initproj4 = utils.crscode_to_string("esri", code, "proj4")
    
            # make the default into param dict
>           initpartdict = dict([part.split("=") for part in initproj4.split()
                                 if len(part.split("=")) == 2 ])
E           UnboundLocalError: local variable 'initproj4' referenced before assignment

../../../.cache/pypoetry/virtualenvs/gis-app-py3.6/lib/python3.6/site-packages/pycrs/parse.py:460: UnboundLocalError

The input string is:

'+init=epsg:4326'

This fails because it's case sensitive and doesn't create initproj4. The string is output from rasterio.crs.to_proj4().

versions

Python 3.6.7
PyCRS==1.0.1
pyproj==2.2.1
rasterio==1.0.25

Looking through some of this package I noticed there aren't a lot of base classes or inheritance; like in the containers and datums modules. I'm not sure they would be useful, but at initial skimming of the code it may have made it easier to understand (map out in my mind). This is just my initial impression. I'm very impressed with everything that PyCRS is able to do and am excited to figure out how to incorporate it into my own code: https://satpy.readthedocs.io/en/latest/

Let me know if there is any way I can help. If you want to chat there is a link to join the satpy (pytroll community) slack here under "Getting in touch".

Currently, I created the CRS class as a sort of wrapper around either GeogCRS or ProjCRS (which have different attributes/layouts), so that the user can always know what to expect. These are then accessed via the "toplevel" attribute. But the CRS class has nothing specifically of value and in a way feels like a wasteful layer to always have to go through the "toplevel" attribute.

1. In deciding the API for the first stable version, is this wrapper a good thing, or would it be better not having the generic CRS class and instead directly receiving a GeogCRS or ProjCRS when parsing a crs format? This would mean they also had to use these directly when creating a crs from scratch.
2. How should users check if their crs is geographic or projected, just through instance checking, or also provide a "type" attribute to indicate the type?

Using Python 3.6, the function from_epsg_code is no longer usable. I'm guessing this also might apply to python 3.5 as well.

from_epsg_code(2193)

Traceback (most recent call last):

  File "<ipython-input-1598-a3ae4c743002>", line 1, in <module>
    from_epsg_code(2193)

  File "E:\programs\anaconda3_64bit\lib\site-packages\pycrs\parser.py", line 35, in from_epsg_code
    crs = from_proj4(proj4)

  File "E:\programs\anaconda3_64bit\lib\site-packages\pycrs\parser.py", line 430, in from_proj4
    partdict = dict([part.split("=") for part in string.split()

  File "E:\programs\anaconda3_64bit\lib\site-packages\pycrs\parser.py", line 431, in <listcomp>
    if len(part.split("=")) == 2 ])

TypeError: a bytes-like object is required, not 'str'

Thanks.

I'm getting an unexpected exception. It's easy to reproduce:

>>> import pycrs
>>> pycrs.__version__
'1.0.0'
>>> crs = pycrs.parse.from_epsg_code(2230)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\eykampC\AppData\Local\Programs\Python\Python37\lib\site-packages\pycrs\parse.py", line 35, in from_epsg_code
    crs = from_proj4(proj4)
  File "C:\Users\eykampC\AppData\Local\Programs\Python\Python37\lib\site-packages\pycrs\parse.py", line 687, in from_proj4
    unit.metermultiplier.value = partdict["+to_meter"]
AttributeError: 'Unknown' object has no attribute 'metermultiplier'
>>>

Hi. I'm excited to use PyCRS, but I've run into a glitch. When I use from_ogc_wkt() on the following wkt...

'PROJCS["NAD83 / UTM zone 17N",GEOGCS["NAD83 / UTM zone 17N",DATUM["NAD83",SPHEROID["GRS80",6378137.000,298.257222100,AUTHORITY["EPSG","0"]],AUTHORITY["EPSG","0"]],PRIMEM["Greenwich",0.0000000000000000,AUTHORITY["EPSG","8901"]],UNIT["Degree",0.01745329251994329547,AUTHORITY["EPSG","9102"]],AUTHORITY["EPSG","26917"]],UNIT["Meter",1.00000000000000000000,AUTHORITY["EPSG","9001"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0.0000000000000000],PARAMETER["central_meridian",-81.0000000000000000],PARAMETER["scale_factor",0.9996000000000000],PARAMETER["false_easting",500000.000],PARAMETER["false_northing",0.000],AXIS["Easting",EAST],AXIS["Northing",NORTH],AXIS["Height",UP],AUTHORITY["EPSG","26917"]]

...I get the following.

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\Nick.Forfinski-Sarko\AppData\Local\Continuum\anaconda3\envs\qaqc_checker\lib\site-packages\pycrs\parse.py", line 92, in from_ogc_wkt
    return _from_wkt(string, "ogc", strict)
  File "C:\Users\Nick.Forfinski-Sarko\AppData\Local\Continuum\anaconda3\envs\qaqc_checker\lib\site-packages\pycrs\parse.py", line 406, in _from_wkt
    crs = _parse_top(header, content)
  File "C:\Users\Nick.Forfinski-Sarko\AppData\Local\Continuum\anaconda3\envs\qaqc_checker\lib\site-packages\pycrs\parse.py", line 294, in _parse_top
    raise Exception("The specified projection name %r could not be found" % projname)
Exception: The specified projection name 'Meter' could not be found

I 'thought' this was an OCG string, but maybe not?

Thanks for sharing your module.

Nick

Can PyCRS pass this test?

import rasterio
import pycrs

def test_pycrs_parses_ogc_wkt():
    # data from https://spatialreference.org/ref/epsg/4326/
    epsg_4326_to_ogc_wkt = 'GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.01745329251994328,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]]'
    rasterio_ogc_wkt = rasterio.crs.CRS.from_string('EPSG:4326').to_wkt(morph_to_esri_dialect=False)
    epsg_4326_ogc_crs = pycrs.parse.from_ogc_wkt(epsg_4326_to_ogc_wkt)
    rasterio_ogc_crs = pycrs.parse.from_ogc_wkt(rasterio_ogc_wkt)
    assert rasterio_ogc_crs == epsg_4326_ogc_crs

The aim of this test is to check for the equality of some CRS regardless of what tools have serialized the CRS, assuming that it should be an OGC WKT serialization.

Hello, I was unable to get projection from EPSG code. I looked up the error and found that http://spatialreference.org has moved to https://spatialreference.org, so I already made a PR: #50. It's just a quick fix, since it would be great to migrate to epsg.io (I could work on that)

@djhoese wrote:

One feature that was brought up on that xarray/geoxarray issue was wanting to be able to take a CRS-like object and use the getitem method to use bracket access to projection parameters like my_crs['lon_0'] or something like that. Not sure if proj.4 parameter naming is the best thing, but yeah it was brought up and I think it could be a good idea. Not sure how to accomplish this with the current interfaces though given how everything is split up in to its own class.

So the requested feature here is perhaps about an easy way to access parameters. Right now how you would do it is by recursively accessing the correct nested sub-elements. E.g. metermultiplier = crs.toplevel.unit.unitmultiplier.value. In a way this would be the correct way to do it, as things would be logically grouped.

I could see the usefulness of also providing more convenient access in a way that kind of "searches" for the parameters for you based on the name, without the user needing to know about their nested structure. As you say, using the proj4 names may not be ideal here, but then again, all naming conventions come from one or another format spec, so it really just depends what you're used to I guess.

One way might be to implement a "get" and "set" method, where you could also supply which format you are using for your search and for the supplied and return values. That way, users more familiar with proj4 could use that, or those familiar with OGC WKT could use that, etc.

I got the following error message.

AttributeError: module 'pycrs' has no attribute 'parser'

Can you help?

Currently, the API reference html docs do not contain the readme. Look into adding the readme as a frontpage to the API reference.

Hello,

First of all I want to thank you Karim for this and all your "pure python" code related to GIS. I am making a python package and I don't want to have GDAL/OGR as a dependency =P

I am interested in getting the EPSG code from a know projection using a .prj file, is that functionality implemented? I couldn't find it. I managed to do it myself, but I wanted to know if you made an approach to it. This is my (simple) code in case anyone else is interested:

import requests
BASEURL = 'http://prj2epsg.org/search.json'
def get_epsg(wkt):
    """ Get EPSG code from WKT projection """
    params = dict(mode='wkt', terms=wkt)
    response = requests.get(BASEURL, params)
    return response.json()

Method from_unknown_text is not working.

I guess this is due to some refactoring.
The local variable string is not present in the method signature.

Steps to reproduce

from pycrs.parser import from_unknown_text
from_unknown_text('some_dummy_text')

Actual

NameError: global name 'string' is not defined

Expected

Exception: Could not detect which type of crs

It should be possible to define an ellipsoid with +a and +rf.
+f = 1 / +rf

`

import pycrs
pycrs.version
'0.1.3'
proj4 = '+proj=lcc +lat_1=25.0 +lat_2=60.0 +lon_0=-100.0 +lat_0=42.5 '
... '+a=6378137.0 +rf=298.257223563 +units=m +no_defs'

crs = pycrs.parser.from_unknown_text(proj4)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/pycrs/parser.py", line 746, in from_unknown_text
crs = from_proj4(text, strict)
File "/usr/local/lib/python2.7/dist-packages/pycrs/parser.py", line 493, in from_proj4
raise Exception("Could not find the required +ellps element, nor a manual specification of the +a or +f elements.")
Exception: Could not find the required +ellps element, nor a manual specification of the +a or +f elements.

`

Thank you

http://geotiff.maptools.org/proj_list/lambert_conic_conformal_2sp.html

An error related to this arose while trying to parse WKT, e.g.
http://spatialreference.org/ref/esri/102740/ogcwkt/

>>> esri_102740_ogc_wkt = 'PROJCS["NAD_1983_StatePlane_Texas_South_Central_FIPS_4204_Feet",GEOGCS["GCS_North_American_1983",DATUM["North_American_Datum_1983",SPHEROID["GRS_1980",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal_Conic_2SP"],PARAMETER["False_Easting",1968500],PARAMETER["False_Northing",13123333.33333333],PARAMETER["Central_Meridian",-99],PARAMETER["Standard_Parallel_1",28.38333333333333],PARAMETER["Standard_Parallel_2",30.28333333333334],PARAMETER["Latitude_Of_Origin",27.83333333333333],UNIT["Foot_US",0.30480060960121924],AUTHORITY["EPSG","102740"]]'

>>> pycrs.parse.from_ogc_wkt(esri_102740_ogc_wkt)
...
  File "/home/joe/miniconda3/envs/gis-dataprocessing/lib/python3.7/site-packages/pycrs/parse.py", line 303, in _parse_top
    raise NotImplementedError("Unsupported projection: The specified projection name %r could not be found in the list of supported projections" % projname)
NotImplementedError: Unsupported projection: The specified projection name 'Lambert_Conformal_Conic_2SP' could not be found in the list of supported projections

Why can't our package parse 3857?
Use this code:

parse.from_epsg_code(3857)

This will return None

Some libraries create proj4 representations as dicts instead of as a string. Probably useful to accept such a proj4 dict. This would be easy since internally we transform the string to dict anyway.

Should this be in a separate method loader.from_proj4_dict, or just allow loader.from_proj4() to accept either string or dict? @djhoese?