Shapefile : A 10-digit value doesn't necessarily fit into a 32 bit integer...

[tsingdong]

I have the shapefile layer and it has a field named "tile_Id" and this field type is numeric(10,0), E.g. 2470190618 > 2^{31 ,how can i get the correct value using the ogr libary in the java language the current result is i get a negative value of this field value.}

[rouault]

This isn't specific to the java bindings. You can observe the same behaviour with C/C++ as well. Unfortunately we haven't come yet with a solution. There's a long series of bug related to that or very close issues : #2286, #933, #809, #1627, #1112.

However I'm not sure we identified that 10 was already a too big value to guarantee that the result fits in a 32 bit integer...

[warmerdam]

I believe the correct solution is to extend the OGR API to support 64 integer fields, and then update the shapefile driver accordingly. I am making this ticket the "official" ticket for the shapefile / 64bit integer field issue and passing off to Chaitanya to bring forward an RFC on the issue.

[szigeti]

Replying to warmerdam:

I believe the correct solution is to extend the OGR API to support 64 integer fields, and then update the shapefile driver accordingly. I am making this ticket the "official" ticket for the shapefile / 64bit integer field issue and passing off to Chaitanya to bring forward an RFC on the issue.

Dear developers,

well, I do not know, how many times have you already performed a 32bit -> 64bit upgrade, but as long as you are not experts, I would not recommend it for you. Just a few questions to consider:

• is the C/C++ environment suitable to define explicit type sizes? (No, some configure procedures are needed, but then)
• what if the architecture does not support any builtin 64bit type at all?
• how to support >20 digits (64+ bits)?
• what is the main purpose of these values? Only I/O or also some arithmetic? (I guess, mainly I/O)
• will real (float/double) numbers also face some similar problem? how to give a general solution on extending the numeric limits?

In ticket:1488#comment:5 I have already suggested to solve the problem by introducing a general type/class. If there is no arithmetic or only addition/subtraction about the numeric fields, structures based on char[] can be used easily. If you care about memory usage, you can even apply 1digit->4bit encoding.

It's, again, up to you. I volunteer my help.

[warmerdam]

I would note that we make extensive use of 64bit types in other aspects of GDAL/OGR and so it is not so challenging from that point of view. My main concerns relate to minimizing backward compatability problems api complexity. An RFC on the topic is under development at:

http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64

[anitagraser]

Is there any update to this issue yet?