Thanks for that...I tried all different formats and looked into your changes.
Could not retrieve my Z coordinate using wkb format because you created a
new geometry format called *wkbzm*.
Please update the doc (http://www.gdal.org/ogr/drv_mssqlspatial.html) and
don't forget to specify that wkbzm
On 29/11/2012 23:32, Nik Sands wrote:
> Thanks for the reply. Firstly, it did resolve my problem, so thanks very
> much for this information.
>
> However, I don't get that warning with gdalinfo .
You have to use the debug switch (look at the command I used in my
previous post).
___
Thanks for the reply. Firstly, it did resolve my problem, so thanks very much
for this information.
However, I don't get that warning with gdalinfo (see below). But I set the
environment variable in my code, and it did resolve the problem for me there
which is all that matters, I guess. :-)
Le jeudi 29 novembre 2012 23:23:44, Jeremy Palmer a écrit :
> so just to confirm 64bit integers can not be implemented before 2.X or
> 1.XX?
I think (hope) that 1.10 will be the last of the 1.X series. Implementing
64bit integer involves ABI changes, so qualifies for 2.0.
so just to confirm 64bit integers can not be implemented before 2.X or 1.XX?
- Original Message -
From: Even Rouault
To: Jeremy Palmer
Cc: "gdal-dev@lists.osgeo.org"
Sent: 30/11/2012 11:15 AM
Subject: Re: [gdal-dev] 64bit integers
Le jeudi 29 novembre 2012 23:10:08, Jeremy Palmer a
Le jeudi 29 novembre 2012 23:10:08, Jeremy Palmer a écrit :
> Thanks.
>
> Any idea if the 64bit proposal is going to happen any time soon?
(Not before GDAL 1.10 release, so as to keep GDAL 1.X ABI)
Perhaps are you volunteering ;-) ?
>
> If not, is there an option to implement functionality to
Thanks.
Any idea if the 64bit proposal is going to happen any time soon?
If not, is there an option to implement functionality to cast 64bit fields to
string in 1.9.X? This function could still be useful once 64bit integers are
implemented.
Cheers
Jeremy
- Original Message -
From: Ev
Le jeudi 29 novembre 2012 22:36:54, Jürgen E. Fischer a écrit :
> Hi Even,
>
> On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote:
> > With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING
> > configruation option to YES. This should generate a warning if the
> > conversion to in
Hi Even,
On Thu, 29. Nov 2012 at 20:53:57 +0100, Even Rouault wrote:
> With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNING configruation
> option to YES. This should generate a warning if the conversion to int
> overflows.
Um, that was meant to produce a warning when a non-numeric (
Le jeudi 29 novembre 2012 05:34:11, Jeremy Palmer a écrit :
> 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!
With latest trunk, you can set the OGR_SETFIELD_NUMERIC_WARNIN
Even- your guidance and correction was the solution that worked for me. Thank
you! _ joe
On Nov 29, 2012, at 11:00:47AM, Even Rouault
wrote:
> Le jeudi 29 novembre 2012 16:28:33, Joe Larson a écrit :
>> I have tried these three methods to add a filename column while scripting a
>> folder of sh
On Thu, Nov 29, 2012 at 3:54 PM, Chaitanya kumar CH
wrote:
> Joe,
>
> What was the full warning message about the normalized/laundered field name?
> Field name is modified when the name is longer than 10 characters or when a
> field with same name exists.
> Check the name of the newly created fiel
Le jeudi 29 novembre 2012 16:28:33, Joe Larson a écrit :
> I have tried these three methods to add a filename column while scripting a
> folder of shapefiles, with a Bash script - which results in `Warning 6:
> Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
> syntax erro
Chaitanya - I believe the normalized/laundered message is a non-issue at this
point. I only get that message when I repeatedly run my Bash script against the
folder of shapefiles - so it's changing the 'filename' column to 'filename_1'
when creating a new column.
I really like your idea of sqli
Joe,
What was the full warning message about the normalized/laundered field
name? Field name is modified when the name is longer than 10 characters or
when a field with same name exists.
Check the name of the newly created field.
As per the update command, I don't think the update command is impl
I have tried these three methods to add a filename column while scripting a
folder of shapefiles, with a Bash script - which results in `Warning 6:
Normalized/laundered field name` & `ERROR 1: SQL Expression Parsing Error:
syntax error` messages and NULL values in the created column :
#1
for f
On Thu, Nov 29, 2012 at 2:02 AM, mortac8 wrote:
> Newbie question here. I am trying to convert a DTED1 image to GeoTiff. The
> below command gives me a mosaic.tif image that is totally black.
>
> gdalwarp -ot Int16 n29.dt1 mosaic.tif
>
> Here is a link to my source image:
> https://www.dropbox.c
Le 28/11/2012 22:54, Nik Sands a écrit :
After applying the suggested patch, it no longer errors out in the same way,
however, I now get another error just a little further on in my code.
-
Failed to get geo-transform (error 3) for file: Cradle Mountain_ozf.map
18 matches
Mail list logo
