
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 4, 2013, at 5:37 AM, Uffe Kousgaard <<a href="mailto:uffe@routeware.dk">uffe@routeware.dk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">When DBF files has numeric fields with values > 2GB, processing fails and all values come out as -2147483648.<br><br>My current work-around is manually changing the fields from Numeric to Char (changing the header of the DBF), but it is really an ugly hack and spaces for padding are wrong (numeric fields are right-aligned, while char-fields are left-aligned internally).<br><br>It would be nice if at least int64 was used for integers in OGR, rather than int32. Large integers are typically used as identifiers in databases such as TomTom, OSM etc.<br><br>Has this been reported before?<br></blockquote><div><br></div>This is a well known feature<br><div><br></div><div>see</div><div><a href="http://www.clicketyclick.dk/databases/xbase/format/data_types.html">http://www.clicketyclick.dk/databases/xbase/format/data_types.html</a></div><div><br></div><div>solution </div><div>use something like spatialite instead of shape files </div></div><div><br></div></body></html>