[gdal-dev] 64bit integers

[Jeremy Palmer]

Hi Brent,

It's in PostgreSQL. We could convert the field to a string data type, but that's not the point. OGR is currently corrupting data without telling the user!

Cheers
Jeremy

________________________________
From: pcreso at pcreso.com [mailto:pcreso at pcreso.com]
Sent: Thursday, 29 November 2012 3:55 p.m.
To: gdal-dev at lists.osgeo.org; Jeremy Palmer
Subject: Re: [gdal-dev] 64bit integers

Hi Jeremy,

Outside of a GDAL solution, what format is the underlying data stored in?

I have resolved issues like this with Postgis data stores by doing the int64 to string conversion in the query generating the data for the service, or via views on the source tables.

Not the most elegant approach, but one of the reasons a good spatial database is a useful foundation for these sorts of systems.

Brent Wood.


--- On Thu, 11/29/12, Jeremy Palmer <JPalmer at linz.govt.nz> wrote:

From: Jeremy Palmer <JPalmer at linz.govt.nz>
Subject: [gdal-dev] 64bit integers
To: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
Date: Thursday, November 29, 2012, 10:26 AM

I have a WFS layer with a 64bit integer field (sufi):

http://wfs.data.linz.govt.nz/83de09e2215a4d0c914dbfe28bb71557/v/x1208/wfs?service=WFS

When using ogr this 64bit integer field gets truncated to 32bit without any warning. E.g

ogrinfo -al 'wfs:http://wfs.data.linz.govt.nz/83de09e2215a4d0c914dbfe28bb71557/v/x1208/wfs?service=WFS&MAXFEATURES=1'

OGRFeature(v:x1208):1384201
  gml_id (String) = x1208.1384201
  id (Integer) = 1384201
  sufi (Integer) = -1519442684
  name (String) = Copy of Daffodil Bay Road
  locality (String) = Sandy Point
  created (String) = 2012-09-04T01:04:02Z
  modified (String) = 2012-09-04T01:04:02Z
  text (String) = (null)
  unofficial_flag (String) = O
  editor (String) = jbedford
  version (Integer) = 1
  edit_action (String) = N
  status (String) = H

This of course then flows through to all drivers such as sqlite, postgresql, mysql, mssql etc.

Should ogr not cast these 64bit integers to an ogr string so data is not lost? At least until http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64 is implemented?

Thanks,
Jeremy


This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or info at linz.govt.nz</mc/compose?to=info at linz.govt.nz>) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.
_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org</mc/compose?to=gdal-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121129/2c36c270/attachment.html>