-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python OGR CreateGeometryFromGML does not handle unit for radius in CURVEPOLYGON/CIRCULARSTRING geometry #4807
Comments
This is odd -- QGIS uses OGR to read GML files, so you should see the same results outside of QGIS (in other words, QGIS doesn't have any specif handling of the uom attribute). Do you have a sample GML file you were using to test that I can investigate? |
@nyalldawson : thanks for you answer. Here is a GML file I'm using, in the attached zip file |
Does that GML tell what is the CRS of CenterPoint? Just wondering that if GDAL thinks that the coordinates are in same units than uom the results would make sense. I believe that intention is that CenterPoint is in EPSG:4326, right? |
Yes. The CRS is in EPSG:4326. |
I apologize that I do not master GML but could you try to edit the GML and tell the srsName of Pos here:
But probably it is OK because this appears earlier: Corresponding unit test in the autotest suite is here: I believe that your test is indeed not good but my guess that srsName could be told for Pos was wrong. Or perhaps it could work as well, GML tend to have many ways for everything. But try to give the srsName directly for CircleByCenterPoint. |
I have also try to set srsName, but setting the srsName doesn't change anything in my case, and then a warning is displayed:
ERROR 1: PROJ: proj_create: no database context specified |
Did you do |
No, I don't import osr, because I don't use it.
Same result if I import osr.
|
Works for me
|
How do you do to have a CIRCULARSTRING as input and the have a LINESTRING as output ? |
I do not know, I am just another GDAL user. Probably that is an intentional thing. Something about how arcs are handled is documented in https://gdal.org/drivers/vector/gml.html. For further questions you should use gdal-dev mailing list. I somehow believe that the reason for creating a linear geometry in this case with ogr.CreateGeometryFromGML(gml) is in the combination of having the center point in EPSG:4326 and radius in linear units like nautical miles. Because 2000 nm corresponds to different number of degrees in north-south and west-east directions the result, when looked as EPSG:4326 coordinates, does not really look like a circle (I believe that the image below should be rotated because my geometry viewer is not aware of lat-long coordinate order but tilt your head and look at the shape). |
This one is related #3118. That fix was targeted into GDAL 3.2.1 so your GDAL 3.3.3 should support also nautical miles. |
Yes, you are right. If srsName is set and using GDAL 3.3.3, it works. Thanks for your help. |
|
It works if the srsName is set directly on the CircleByCenterPoint element (returns a POLYGON). It also works if the srsName is defined on some parent GML elements, but not on all. However, if the srsName is only defined on the root element (Surface), it doesn't work (returns a CURVEPOLYGON). Is there any workaround? When processing large files, modifying the XML to insert the correct srsName for child elements is inconvenient. PS: It is strange that when I replace nmi_i with m, km, or nm, it doesn't work (regardless of the presence of srsName) — it returns a CURVEPOLYGON. According to the comments above and #3118, it should work.
GDAL 3.11.0 (build from master branch) |
Expected behavior and actual behavior.
Python OGR CreateGeometryFromGML does not handle unit for radius in CURVEPOLYGON/CIRCULARSTRING geometry
Steps to reproduce the problem.
CIRCULARSTRING (-1951 2,2049 2,-1951 2)
CIRCULARSTRING (-1951 2,2049 2,-1951 2)
CIRCULARSTRING (-1951 2,2049 2,-1951 2)
Whatever the unit, the geometry is always the same.
Notice : if I try to display my GML file with QGIS, the uom of the radius element is handled by QGIS;
Operating system
CentOS 8, Windows 10
GDAL version and provenance
3.0.2 and 3.3.3 : CentOS 8 from http://download.osgeo.org/gdal/
3.0.2 and 3.3.3 : Windows10 from https://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal
Python version : 3.7
The text was updated successfully, but these errors were encountered: