Re: [gdal-dev] python scripts - create layer problem
Hi Even, 2014-07-11 11:33 GMT+02:00 Even Rouault even.roua...@mines-paris.org: If you see the CREATE TABLE in the debug log, and it is not created, then it is really weird. Perhaps check the potential surrounding BEGIN/COMMIT/ROLLBACK just in case. Might it not be an issue with your PostgreSQL instance ? I tried your suggestions and then I checked again my scripts. The problem was not in GDAL, but in my scripts. Sorry for the noise and thanks for your help! Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] OCI driver: Date field creation improvement
Hi list, Can someone could review and commit my patch ? http://trac.osgeo.org/gdal/ticket/5600 Thanks Nicolas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] OGR: memory leak in OCI driver
Hi list,
We tested the suggestion of Ivan and it's better.
Fortunately, my problem to create ticket was solved
The ticket is http://trac.osgeo.org/gdal/ticket/5599 with a patch file.
Best regards
Nicolas
De : Ivan Lucena [mailto:lucena_i...@hotmail.com]
Envoyé : mardi 6 mai 2014 17:48
À : SIMON Nicolas; gdal-dev@lists.osgeo.org
Cc : SANDRI Christophe; NGUYEN Thi Xuan Truc
Objet : RE: [gdal-dev] OGR: memory leak in OCI driver
Hi Nicolas,
I received that report a month ago:
we have found the OGROCISession is never released, causing a large memory leak
whenever a connection is closed.
As workaround, we added in OGROCISession::~OGROCISession()
if( hEnv )
OCIHandleFree((dvoid *) hEnv, (ub4) OCI_HTYPE_ENV);
But they also mention some other memory leaks without an specific location on
the code.
Can you try to see if that fix the problem?
Thanks,
Ivan
From: nicolas.si...@spw.wallonie.bemailto:nicolas.si...@spw.wallonie.be
To: gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org
Date: Tue, 6 May 2014 15:32:09 +
CC:
christophe.san...@spw.wallonie.bemailto:christophe.san...@spw.wallonie.be;
xuan.ngu...@spw.wallonie.bemailto:xuan.ngu...@spw.wallonie.be
Subject: [gdal-dev] OGR: memory leak in OCI driver
Dear developers,
I suspect that there is a memory leak in OCI driver for OGR
My simplified test case is :
...
// point A
OGRRegisterAll();
// point B
pDS = OGRSFDriverRegistrar::Open(OCI:USER/PWD@INSTANCE:TABLE, true);
if(pDS)
{
OGRDataSource::DestroyDataSource(pDS);
pDS = NULL;
}
else
{
fprintf(fOut,Erreur Open\n);
}
// point C
OGRCleanupAll();
// point D
It appears that I lose memory between points B and C, and between point A and D
B = A + 4 MB
C = A + 20 MB ( 16 MB lost)
D = A +19 MB ( 3 more MB lost)
Test was done with GDAL 1.9 under windows (with Oracle 11g)
Can some one have an idea to find and fix this ?
Thank you
By the way, I received « TICKET_CREATE privileges are required to perform this
operation » when I tried to make a ticket (UID nicsim)
Nicolas
___ gdal-dev mailing list
gdal-dev@lists.osgeo.orgmailto:gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] styles .ofs and OGR_STBL_GetNextStyle()
Nik,
This is a good idea. The doc you specified needs a correction. The
version string and style field lines are supposed to be commented out
with a #.
The OGRStyleTable class has methods to save and load style tables.
They assume neither empty lines nor comments.
There is one method to Print that saves the styletable into a file in
the .ofs format. We can implement a method that loads a styletable
from such file. Do you have any other suggestions?
I suggest you create a ticket on this at http://trac.osgeo.org/gdal/#BugTracking
On Wed, Jul 30, 2014 at 10:17 AM, Nik Sands nix...@nixanz.com wrote:
Hi Devs,
I'm just planning to convert my own 'in-house' drawing styles management to
using the styles management built into OGR. The documentation at
http://www.gdal.org/ogr_feature_style.html suggests that styles can be in a
'.ofs' file to be automatically associated with a data source of the same
name as the .ofs file.
But how about if the .ofs file is a stand-alone file passed directly to
OGR_STBL_LoadStyleTable()? Eg, OGR_STBL_LoadStyleTable(table,
/path/to/styles.ofs)
In this case the first two calls to 'OGR_STBL_GetNextStyle(table)' will
return the 'styles':
OFS-Version : 1.0
2014-07-30 14:38:36.392 Maps n Trax[47458:60b] StyleField : style
Which are of course not styles at all, but part of the .ofs specification.
From this, I assume that files passed into OGR_STBL_LoadStyleTable() should
in fact NOT be .ofs files, but merely plain text files with raw style strings
only (and no .ofs specifications).
Is this correct?
Would there be any advantage on getting OGR_STBL_LoadStyleTable() to ignore
the first line or two if it is an .ofs file and those two lines match the
spec?
Cheers,
Nik.
OFS-Version: 1.0
StyleField: style
DefaultStyle: SYMBOL(c:#00,id:ogr-sym-3,s:5pt); PEN(c:#00,w:2pt);
BRUSH(fc:#80808080); LABEL(c:#00,s:14pt,t:{title})
locality: LABEL(c:#00,s:24pt,t:{title})
town: SYMBOL(c:#80,id:ogr-sym-3,s:10pt);
LABEL(c:#80,s:24pt,t:{title})
city: SYMBOL(c:#80,id:ogr-sym-3,s:15pt);
LABEL(c:#80,s:24pt,t:{title})
region: PEN(c:#00,w:2pt); BRUSH(fc:#80808080);
LABEL(c:#00,s:28pt,t:{title})
country: PEN(c:#00,w:2pt); BRUSH(fc:#80808080);
LABEL(c:#00,s:32pt,t:{title})
vegetation_low: BRUSH(fc:#A0F0A0); LABEL(c:#004000,s:18pt,t:{title})
vegetation_medium: BRUSH(fc:#80C080); LABEL(c:#004000,s:18pt,t:{title})
vegetation_high: BRUSH(fc:#008000); LABEL(c:#004000,s:18pt,t:{title})
water: SYMBOL(c:#80,id:ogr-sym-3,s:2pt); PEN(c:#80,w:2pt,p:18pt
8pt); BRUSH(fc:#8080C0); LABEL(c:#80,s:18pt,t:{title})
contour: PEN(c:#808080,w:1pt); LABEL(c:#808080,s:12pt,t:{elevation})
road_unsealed: PEN(c:#A08080,w:2pt,p:10pt 6pt);
LABEL(c:#00,s:18pt,t:{title})
road_minor: PEN(c:#A08080,w:2pt); LABEL(c:#00,s:18pt,t:{title})
road_medium: PEN(c:#A0,w:4pt); LABEL(c:#00,s:18pt,t:{title})
road_major: PEN(c:#A0,w:6pt); LABEL(c:#00,s:18pt,t:{title})
route: PEN(c:#00,w:2pt,p:2pt 4pt); LABEL(c:#00,s:18pt,t:{title})
track: PEN(c:#00,w:2pt,p:10pt 6pt); LABEL(c:#00,s:18pt,t:{title})
rail: PEN(c:#00,w:4pt,p:2pt 5pt); LABEL(c:#00,s:18pt,t:{title})
cable: PEN(c:#00,w:2pt,p:1pt 6pt); LABEL(c:#00,s:18pt,t:{title})
ferry: PEN(c:#80,w:2pt,p:18pt 8pt); LABEL(c:#80,s:18pt,t:{title})
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Best regards,
Chaitanya kumar CH.
+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GSoC weekly report 11. GDAL Networking
Hello everyone. As at this week I've implemented a support of network's business logic (my blog post: http://gsoc2014gnm.blogspot.ru/2014/08/week-11-networks-business-logic.html) I'm very close to finish implementing GNM according to my plan. All that I need to complete in order to finish my project: 1) Several: methods of functionality, small 'todo-s' and application commands; 2) Python tests which I unfortunately always had no time to complete; 3) Documentation, which I've started to write - I've already written some pages of tutorial and architecture description. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
