Directional mask "Direction field" drop-down doesn't recognise integer fields (Standalone GCD)

[fluviotect]

The drop-down box for "Direction field" doesn't populate in Standalone GCD 7.5.0.0

Field structure looks like:

'ID' and 'area_m' are native to the shp (originally created with shapely v1.7.1 in Python 3.9.5). Additional fields added in QGIS 3.20.

My guess is it's an encoding issue and/or something specific to building a shp outside of an ESRI environment.

I'll try and import/export through Arc and report back.

Cheers

[fluviotect]

Looking at things from the ESRI side (Arc 10.7.1):

A couple of interesting things to note:

• the 'ID' field is recognised as an integer in QGIS and a double in Arc
• the 'ord' field is a simple integer in QGIS and a Long in Arc
• the 'ord' and 'ID_int_sm' fields are recognised as different typres on ints in QGIS, but the same in Arc

I added new fields to the attribute table from within Arc:

• "ID_arcshrt" as a Short Integer
• "ID_arclong" as a Long Integer

for whatever reason, both appear as "long' in the field properties

However, when I go back to Standalone GCD.... voila:

I'm happy to hear thoughts on why this might be. And would be substantially happier if I could skip Arc altogether :-)

Cheers!

[fluviotect]

One last thing to add (for now)...

in a pure python env, 'ID' is an int64:

[fluviotect]

Now it's just getting weird....

As long as I was in Python, I figured I'd force a couple of different int types...

Which Arc still recognizes as 'doubles', e.g.

And a straight shot into Standalone GCD...

Recognises no fields at all. And stays that way even after exporting to a new shape from Arc.

[philipbaileynar]

I will leave this ticket open for when we have budget to investigate... but for now I will say the following:

1. ESRI's implementation of IBM DBF database table "standard" is actually very non-standard. They don't allow some data types that are permissable in the file (and can be generated with third party tools such as Shapely).
2. ESRI's implementation on integer and long integer has changed over time. I can't find the link but I have seen ArcGIS do strange things with long integer fields created in other software.

Thanks again for reporting this issue so thoroughly.

[fluviotect]

Cheers for the lead Philip. It's unfortunate a dbf can't just be a dbf.

Your post prompted me to find this:
https://support.esri.com/en/technical-article/000013192

While the ESRI article doesn't get into it, I'd think that if such a local registry change were made that was consistent with ESRI-flavoured dbfs, there should be a way to point shapely/geopandas to it during export.

The workaround I noted above is acceptable for now as I still have access to an Arc license. However, I'd be keen to see this addressed on the GCD side at some point (perhaps a matter of the making the control for the drop-down box inclusive of files with the broader IBM standard?).

Best Regards

[fluviotect]

For python-based solution without deviating through Arc, see following reply to a question I posed on StackExchange:

https://gis.stackexchange.com/a/404916/17482

I have confirmed that it works for my file.

[joewheaton]

Yes, thanks @fluviotect for providing such a great trail of how to deal with this. @philipbaileynar this re-enforces the decisions we've since made to go to geopackages and keep working outside ESRI. It would be fun someday to get GCD refactored for QGIS, but I don't see that as a funded priority for some time.