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

Not able to convert geojson files when the schema is not inferrable #182

Open
clembou opened this issue Jun 7, 2024 · 2 comments
Open

Comments

@clembou
Copy link

clembou commented Jun 7, 2024

Hi,

I am experiencing this issue with gpq:

gpq: error: failed to create schema after reading 39 features

Based on #142 the answer is clear: there are no non null values in any of the features for one of the columns.
Indeed, if I edit the file and add just one everything works fine.

The problem is that unlike in the linked issue it is not possible for me to increase the amount of rows scanned because all the rows have nulls, and this is a case that is pretty common with the files I am dealing with.

While this strict behaviour is understandableby default, is is preventing me from adopting the tool. The ogr2ogr behaviour is maybe questionable (in my case the incriminating column is being added as a string instead of an int), it at least produces an output that is usable.

So perhaps an option to --drop-non-inferrable-columns, or --import-ambiguous-columns-as-strings would be a useful escape hatch for gpq users.
(pre-processing json is of course an option too but more invovled)

@tschaub
Copy link
Member

tschaub commented Jun 9, 2024

I agree that there should be a way to handle this. OGR will encode these “unknown” types as JSON strings.

In your case, I imagine you would want an optional integer type. The challenge is coming up with syntax for the command line args that is convenient and flexible. Referring to a secondary file with schema or other complex options might be nicer.

@clembou
Copy link
Author

clembou commented Jun 9, 2024

Being able to specify the schema would be nice for a perfect output yes. I think even just optionally treating unknown fields as strings or dropping non inferable columns altogether would be a nice improvement though (and acceptable for my personal use case)

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

No branches or pull requests

2 participants