[gdal-dev] 64bit integers
pcreso at pcreso.com
pcreso at pcreso.com
Wed Nov 28 18:55:03 PST 2012
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) 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
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20121128/c2de7ba0/attachment.html>
More information about the gdal-dev
mailing list