Oh! Thank you! I'm thinking maybe I'll generate a trigger in the
database to update the zvalue when the ELEVATION field is updated.
On 2021-08-13 2:04 p.m., Jan Heckman wrote:
Quite possibly in the Z-coordinate of your geometry column. You can
check in pgadmin or psql (or another program like o
Afternoon!
I recently upgraded to gdal 2.2.2 from 2.1 on linux and when I try to
use ogr2ogr to append/update an existing table in PostgreSQL/PostGIS the
command fails because it can't apply a transformation.
The command works fine in gdal 2.1.
The command I'm using is:
ogr2ogr -update -
I've also noticed for some intersections, especially where I want to
extract points that intersect polygons, it can be quicker to do a
ST_Within test - given that points will usually either be within or
outside of a polygon, or touching the boundary of a polygon.
On 2017-04-10 03:12 PM, Steph
(unsigned char*,
buf); stream->bufsize_ = bufsize - JAS_STREAM_MAXPUTBACK; } } else {
On 07/12/16 11:22 AM, Even Rouault wrote:
On mercredi 7 décembre 2016 11:19:11 CET Donovan Cameron wrote:
> On 07/12/16 10:41 AM, Even Rouault wrote:
> > You could as well replace the JAS_C
On 07/12/16 10:41 AM, Even Rouault wrote:
You could as well replace the JAS_CAST(uchar *, buf); by
JAS_CAST(unsigned char*, buf)
Thanks Even, that's helpful.
Whereabouts would I try to make this patch? Not sure what file to look
for to do this. Sorry!
--
Kind regards,
Donovan
__
Downgrading jasper to 1.900.5 results in a successful build.
On 07/12/16 10:22 AM, Donovan Cameron wrote:
Morning Everyone!
Jasper was update in Arch Linux today and trying to build gdal 2.1
from the git 2.1 release branch (r36743) the compile fails with a
jpeg2000 + jasper error:
make
Morning Everyone!
Jasper was update in Arch Linux today and trying to build gdal 2.1 from
the git 2.1 release branch (r36743) the compile fails with a jpeg2000 +
jasper error:
make -C jpeg2000 install-obj
make[2]: Entering directory
'/tmp/makepkg/gdal-filegdb/src/gdal-2.1/frmts/jpeg2000'
g++
Hey List!*
**
*I'm having trouble tracking down an answer to a question, from either
the archived mailing list or google, I have about ogr2ogr and loading
data to PostGIS.
*
*Basically, what's the difference between the -overwrite flag and the
layer creation option OVERWRITE for the PostgreSQL
That did the trick!
Thanks.
Is that a patch that would be applied upstream or should I apply it
locally instead?
Donovan
On 18/08/15 03:15 PM, Even Rouault wrote:
On Tuesday 18 August 2015 14:51:36 Donovan Cameron wrote:
I updated the ticket [1] too.
OS: Arch Linux 64-bit (Kernel
18 August 2015 11:47:07 Donovan Cameron wrote:
I made those changes but same error.
Tried once with,
#define _XOPEN_SOURCE
And a second time with,
#define _XOPEN_SOURCE 500
What is your config: OS + gcc ?
I can't reproduce with Ubuntu 14.04 with gcc 4.8
Could you intercept the gcc
I made those changes but same error.
Tried once with,
#define _XOPEN_SOURCE
And a second time with,
#define _XOPEN_SOURCE 500
Donovan
On 18/08/15 10:30 AM, Even Rouault wrote:
On Tuesday 18 August 2015 12:00:46 Vincent Schut wrote:
Hi,
this morning I wanted to refresh my gdal build, so
I've compiled libkml from the libkml/libkml git repo and really like
that minizip for example is an external dependency.
This makes it so that other applications that require minizip can be
compiled easily now.
Donovan
On 11/08/15 09:56 AM, Sebastiaan Couwenberg wrote:
On 11-08-15 18:37, Ku
Thanks a lot Martin,
build worked great, just had to patch the resultant Makefile because...
make DESTDIR="${pkgdir}" install
...would fail because the DESTDIR var wasn't recognized in the Makefile,
which I patched in.
But that's a limited use case and likely not applicable to anyone who
is
Afternoon everyone,
I'm having some problems getting the gdal-grass 1.11.2 plugin to compile
with grass 7.0.0 installed on Arch Linux 64bit.
I've compiled GDAL 1.11.2 --without-grass, then compiled grass 7.0.0
from the tar (even tried from the svn release 7_0 branch) archive.
Next tried to
ile to pull it in the build environment
> 2. Include the original tar.gz files on your spec file and move around
> files in correct places before the configure command
>
> I hope this helps.
>
> Best,
> Angelos
>
>
>
> On 01/25/2013 11:34 PM, Donovan Cameron w
My buildlog from "osc build openSUSE_12.2 x86_64 libgdal.spec --clean" if
it helps.
http://paste.opensuse.org/view/raw/e119c82d
On Fri, Jan 25, 2013 at 1:54 PM, Donovan Cameron wrote:
> I've tested compiling the 64bit gdal-1.9.2 from the tar.gz source file:
>
> ./co
using a conflict
so that that the .so for the FileGDB driver can't be found, even after
it's registered with ldconfig.
On Fri, Jan 25, 2013 at 11:05 AM, Donovan Cameron wrote:
> Thanks for the suggestion Jan.
>
> I tried to compile the 32-bit libgdal with the 32bit FileGDB_AP
ly the 32 bits version actually worked.
> I haven't tried to figure out why the 64 bits version didn't work, 32 bits
> was good enough for me.
> Hope this is an option for you as well,
> Jan
>
> On Fri, Jan 25, 2013 at 5:23 AM, Donovan Cameron
> wrote:
>>
>> L
Looks like over in the [qgis-user] list, someone is having similar problems:
https://groups.google.com/d/msg/qgis_user_remote/B2J9sOsSLbo/BIpAHZ84bhgJ
On Thu, Jan 24, 2013 at 9:05 PM, Donovan Cameron wrote:
> I can't seem to compile GDAL with FileGDB support on openSUSE.
> I'm c
I can't seem to compile GDAL with FileGDB support on openSUSE.
I'm compiling locally using the OBS tools (osc) and have checked-out
the libgdal package from the Application:Geo project.
Steps I've taken:
1) Download FileGDB_API_1_2-64.tar.gz
2) tar xzvf FileGDB_API_1_2-64.tar.gz -C /usr/lib64/
Have you reviewed the article from Tim Sutton: "A workflow for creating
beautiful relief shaded dems using GDAL"[1]?
It has some valuable pointers.
[1]
http://linfiniti.com/2010/12/a-workflow-for-creating-beautiful-relief-shaded-dems-using-gdal/
Donovan
On Tue, Feb 21, 2012 at 12:29 PM, Joa
I will definitely not recommend it then. Seems I got lucky in this case
scenario.
Thanks.
Donovan
On Fri, Feb 3, 2012 at 3:19 PM, Even Rouault
wrote:
> Le vendredi 03 février 2012 22:59:36, Donovan Cameron a écrit :
> > FYI
> >
> > Further testing with -overwrite g
appending and view the results in a GIS
viewer like QGIS.
Though the -where or -fid trick works as well
On Wed, Feb 1, 2012 at 2:38 PM, Even Rouault
wrote:
> Le mercredi 01 février 2012 22:22:42, Donovan Cameron a écrit :
> > Afternoon List.
> >
> > I am trying to generate an
Afternoon List!
I am trying to batch merge several GML files but get the following error:
*Cannot open existing output data source: output.gml*
I can read the file fine with "*ogrinfo output.hml output -so*" and
everything looks normal.
I am able to perform the operation successfully without err
Afternoon List.
I am trying to generate an empty feature (shp or gml) from a template that
retains both the attribute-table schema and map projection.
I can't get the *-overwrite *flag to work, it just copies the entire
feature (ie, makes a duplicate):
*ogr2ogr -overwrite -f "GML" geoname.gml /vs
25 matches
Mail list logo
