Should the build succeed with the 2015 version of the MS compiler using
x86? I get
With x64 it gets a lot more errors.
It works fine with VS 2010 x86 - haven't tried x64.
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I'm getting:
GDAL:
GDALOpen(DB2ODBC:DB2:database=samp105;DSN=SAMP105A;tables=TEST.ZIPPOINT,
this=004995C0) succeeds as DB2ODBC.
GTiff: Reopen with strip chop enabled
GDAL: GDALOpen(..\gcore\data/cfloat64.tif, this=0485BEC8) succeeds as GTiff.
ODBC: SQLDisconnect()
GDAL:
GDALClose(DB2ODBC:DB2:
I am subclassing these classes to provide additional support for DB2.
It would simplify matters if some of the members of the parent classes
were protected rather than private.
The current CPLODBCStatement::Failed method is private but would be
useful as public.
There is also a peculiarity
Dear PSC,
I have read and agree to the committer guidelines as outlined in the
RFC3 [2].
I look forward to being a contributor to GDAL.
Regards,
David
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
__
In the gpkg code, the member names all appear to be prefixed with 'm_'.
Is this a new convention?
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
gdal-dev mailing list
gdal-dev@lists.osgeo.o
2015 13:18:52, David Adler a écrit :
For the first time I am trying to do development on an Ubuntu system.
Which Ubuntu version ?
After installing various tools, checking out the trunk source and
configuring, make appears to compile all the source ok but fails in
libtool with the followin
For the first time I am trying to do development on an Ubuntu system.
After installing various tools, checking out the trunk source and
configuring, make appears to compile all the source ok but fails in
libtool with the following messages:
make[1]: Entering directory `/home/davea/gdal'
/bin/
I noticed that ogr_db2_hack.py exists to test for some DB2 V7.2 problem
with WKB. I don't know what the problem was but we did make some fixes
to the DB2 WKB support and I'm wondering if this test is still necessary.
If the test is still necessary, was the problem reported to DB2 development?
Do I need to do something to move this forward?
Forwarded Message
Subject:Ticket to add IBM DB2 spatial support to GDAL/OGR
Date: Fri, 30 Oct 2015 17:22:11 -0400
From: David Adler
To: gdal-dev@lists.osgeo.org
I created the following ticket
https
Is there any reason why a common module couldn't be used to support both
raster and vector data for a particular database?
When the driver is opened the data type could be specified either as an
option or different names, such as "DB2V:" and "DB2R:"
Regards,
David
---
This email has been che
If a data source is created as a plugin and GDALRegisterAll invokes
GDALRegister_myDS, won't this cause an error at runtime if the DLL/so is
not found?
Does GDAL need to be rebuilt specifically to include support for a
particular plugin and then distributed separately?
Is there a repository
I created the following ticket
https://trac.osgeo.org/gdal/ticket/6191
which includes some information about the DB2 spatial driver we created
and also includes an 'svn diff' of all the code changes/additions.
This is based on the current GDAL 2.1 trunk as of 10/29/2015.
What is the next step?
The development and testing of this is complete as far as I am aware.
Should the "svn diff" just be zipped and attached to a post to this group?
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
I'm getting closer after installing the MS compiler for Python and
running "python setup.py build" successfully but still get a failure.
Does the usual GDAL Python user need to go through all this? I see lots
of information and tutorials about using the GDAL Python API but haven't
found much a
13, in
swig_import_
helper
import _gdal
ImportError: No module named _gdal*
On 10/26/2015 2:12 PM, Even Rouault wrote:
Le lundi 26 octobre 2015 18:48:47, David Adler a écrit :
I am close to finished with this driver which was delayed significantly
getting access to a DB2 for z/OS test enviro
I am close to finished with this driver which was delayed significantly
getting access to a DB2 for z/OS test environment to verify that it
works across IBM DB2 platforms.
What is the proper way to handle authorship in the source code? The DB2
driver is based on the MS SQL driver with signific
I have mostly completed the driver for DB2 Spatial using the ODBC
support and would appreciate pointers into the GDAL information for the
following:
1. Is there a test suite / framework for OGR drivers?
2. What is the mechanism for submitting a new driver?
3. What is the plan for the transition
17 matches
Mail list logo