juliadata / dbftables.jl Goto Github PK

Would there be any interest if I removed the DataFrames dependency and switched to subscribing to the Tables.jl interface instead? This would be breaking of course.

This would work more nicely with where I want to go with Shapefile.jl as well.

I have a DBF file where the field name in the header ends with a ' \0', but the remaining bytes are not filled with '\0', so replacing the `\0' with a space and then trimming the string does not help.

Simply only selecting the string up to the '\0' saves the day.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Ref: https://discourse.julialang.org/t/package-compatibility-caps/15301

I have a DBF file where, when trying to load it, the data section is always off by one.
I compared the position in the IO stream after reading the header and the header length, and they were also off by one.

So I wanted to add additional skip statements to reach the position header.hsize, but that led to the test script failing (there, the header length is actually exceeded by one, i.e. after reading the header (length 26), the position is at 27).

When loading the test.dbffiles created during the runtest.jl script in Excel, I also noticed that they were incorrectly interpreted (off by one). It seems to me that the final 0xD character is written in Base.write(io::IO, h::Header), but is maybe not considered when calculating the length of the header in write(io::IO, tbl)?

Can we refactor this code so that the type is inferred correctly when no missing values are present?

Returning always a Union{T,Missing} is too rigid.

I tried to add this package, but I get the error message

"resolve is unable to satisfy package requirements. The problem was detected when trying to find a feasible version for package DataFrames. However, this only means that package DataFrames is involved in an unsatisfiable or difficult dependency relation, and the root of the problem may be elsewhere."

I think this might be because your package depends on a now-out-of-date version of DataFrames. Could you possibly update the package to work with the current release of DataFrames (0.11.6). If that isn't why I'm getting this error message, can you please help me out. Thanks.

As suggested by @quinnj, it would be good to tag a 1.0 release for DBFTables.
The package is pretty stable, so after giving it one more good look, the next release can be 1.0.

From the dbase spec

I | Long | 4 bytes.        Leftmost bit used to indicate sign, 0 negative.

A zero sign bit means negative numbers. E.g. not a regular julia/C Int32 at all:

julia> bitstring(Int32(-1))
"11111111111111111111111111111111"

To enable full shapefile writing support in JuliaGeo/Shapefile.jl#77

dbase files specify the string encoding, and occasionally it's not ascii. We should probably read that and use something like:
https://github.com/JuliaStrings/StringEncodings.jl

To convert to UTF8.

See:
JuliaGeo/Shapefile.jl#63