Skip to content
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

ENH: raise Python warnings instead of printing to stderr for GDAL Warning messages #242

Merged

Conversation

jorisvandenbossche
Copy link
Member

Follow-up on #236, xref #91 (comment)

Copy link
Member

@brendan-ward brendan-ward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jorisvandenbossche !

Can you please add a changelog entry, and also edit the docstring for kwargs of read_info,read, and read_dataframe to remove mention of logging invalid options to stderr?

@jorisvandenbossche
Copy link
Member Author

jorisvandenbossche commented Apr 4, 2023

I updated the tests a bit to avoid warnings being raised from running them. But how to exactly do this can certainly be discussed. For example, in some cases I could keep it simpler and just add some more @pytest.mark.filterwarnings, instead of trying to assert the exact warning being raised.

@@ -270,6 +271,7 @@ def test_write(tmpdir, naturalearth_lowres):

def test_write_gpkg(tmpdir, naturalearth_lowres):
meta, _, geometry, field_data = read(naturalearth_lowres)
meta.update({"geometry_type": "MultiPolygon"})
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem here is that reading the Shapefile will indicate the geometry type is "Polygon" (because shapefiles don't care about the distinction), but then using that meta to write to geopackage will raise a warning because geopackage is stricter

@@ -456,9 +458,11 @@ def assert_equal_result(result1, result2):
assert all([np.array_equal(f1, f2) for f1, f2 in zip(field_data1, field_data2)])


@pytest.mark.filterwarnings("ignore:File /vsimem:RuntimeWarning") # TODO
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When reading from bytes / file-like objects, we create a vsimem temporary in-memory file, but because we don't know the file type at that moment, we get a warning like "File /vsimem/5332805636f74498b74520a2c132082b has GPKG application_id, but non conformant file extension"
Ideally we would solve that (since the user cannot do anything about that warning, since this name is auto-generated), but not sure how. We don't know the type of file when it's a file-like object, and it's only GDAL that infers it based on the content of the file. Maybe we should open an issue about upstream in GDAL to relax this constraint for vsimem files.

Comment on lines +656 to +659
if dtype == "float32":
ctx = pytest.warns(RuntimeWarning, match="NaN of Infinity value found. Skipped")
else:
ctx = contextlib.nullcontext()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is bizarre, but for some reason GDAL only raise the warning if the dtype is float32, while the value is actually skipped for both float32 and float64

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like an issue to raise upstream?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, so the issue seems to be that it only warns once, not depending on float32 vs float64. I would expect it to warn once per file, and not once per session, though

https://github.com/OSGeo/gdal/blob/0626cc27486f7ff7ba80e24fe9464e933dbcda2d/ogr/ogrsf_frmts/geojson/ogrgeojsonwriter.cpp#L876-L883

Copy link
Member

@brendan-ward brendan-ward left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jorisvandenbossche !

I think your approach for the tests is good (testing for specific warnings instead of filtering). The issues that come from GDAL don't need to be resolved to merge this.

CHANGES.md Outdated Show resolved Hide resolved
Co-authored-by: Brendan Ward <bcward@astutespruce.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants