Opened 10 years ago

Closed 5 years ago

Last modified 4 years ago

#3615 closed defect (fixed)

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

Reported by: tsingdong Owned by: chaitanya
Priority: normal Milestone: 2.0.0
Component: OGR_SF Version: 1.7.2
Severity: normal Keywords:
Cc: Kosta

Description

I have the shapefile layer and it has a field named "tile_Id" and this field type is numeric(10,0), E.g. 2470190618 > 231 ,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.

Change History (8)

comment:1 Changed 10 years ago by Even Rouault

Milestone: 1.7.2
Summary: Get the correct unsigned int valueShapefile : A 10-digit value doesn't necessarily fit into a 32 bit integer...

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...

comment:2 Changed 9 years ago by warmerdam

Owner: changed from warmerdam to chaitanya

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.

comment:3 Changed 9 years ago by Kosta

Cc: Kosta added

comment:4 in reply to:  2 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by 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

comment:6 Changed 7 years ago by anitagraser

Is there any update to this issue yet?

comment:7 Changed 5 years ago by Even Rouault

Milestone: 2.0
Resolution: fixed
Status: newclosed

comment:8 Changed 4 years ago by Even Rouault

Milestone: 2.02.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.