karimbahgat / pycrs Goto Github PK
View Code? Open in Web Editor NEWProjection creation, and conversion to misc formats
License: MIT License
Projection creation, and conversion to misc formats
License: MIT License
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]]'
ipdb> epsg_code['url']
'http://prj2epsg.org/epsg/2278.json'
ipdb> pycrs.load.from_url(epsg_code['url'])
*** pycrs.parse.FormatError: Could not auto-detect the type of crs format, make sure it is one of the supported formats
@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")
print pyproj.transform(prj_obj_from_proj4, prj_obj_3857_from_epsg, 446495, 3681410)
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://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?
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()
.
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.
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.
from pycrs.parser import from_unknown_text
from_unknown_text('some_dummy_text')
NameError: global name 'string' is not defined
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.