On Wed, Sep 7, 2011 at 12:16 PM, Even Rouault
wrote:
> Le mercredi 07 septembre 2011 02:36:35, Ole Nielsen a écrit :
> > Yes this seems to work. However, I get a huge amounts of warnings of the
> > form
> >
> > >>> lyr.CreateField(fd)
> >
> > Warning
ut
to clutter, and since that name is already available through your procedure
they really should be suppressed. Can that be done?
Many thanks
Ole
On Tue, Sep 6, 2011 at 10:10 PM, Even Rouault
wrote:
> Selon Ole Nielsen :
>
> > Thanks - I was hoping I could rely on the library to do the
e
On Tue, Sep 6, 2011 at 9:26 PM, Even Rouault
wrote:
> Selon Ole Nielsen :
>
> > Hi Even
> >
> > Thanks again for all your help - all tests now pass using either gdal 1.6
> or
> > 1.8. Just to summarise, there were three issues as I see them:
> >
> >
>
;s at least what I did.
For those interested, the updated class dealing with vector data for our
risk modelling application is available on github at
https://github.com/AIFDR/riab/blob/develop/impact/storage/vector.py
Thanks again for a great piece of software
Ole Nielsen
On Tue, Sep 6, 2011 at 1:
one deal with this truncation? Your example (which does not
use CreateField) would suggest names can be longer than 10 characters.
- Where can i find some documentation of the OGR Python bindings?
I am sorry that my questions are so fundamental, but I am still new to this
library.
Chee
ent (char*) followed by a float (double) which I
thought would be matched by the third last header above. It works fine on
version 1.6 but not version 1.8.
Can anyone tell me what has changed, what it means and how to work around it
- please?
Many thanks
Ole
On Thu, Sep 1, 2011 at 7:33 PM, Even R
decimal places. Do you think that is
significant?
Anyway, I'll update our unit tests to take this into account.
Cheers and thanks
Ole
On Sat, Sep 3, 2011 at 5:30 PM, Even Rouault
wrote:
> Le samedi 03 septembre 2011 12:23:55, Ole Nielsen a écrit :
> > Dear all!
> >
> >
(102d14'13.20"E, 2d11'56.40"S)
Center ( 100.7985000, -1.0995000) (100d47'54.60"E, 1d 5'58.20"S)
It'd be great if someone can
1. Reproduce this using the test file (download usin
:
> Ole, why don't you uninstall libgdal1-1.6.0 and the grass one and run
> ldconfig to make sure everything is using 1.8?
>
> Ariel.
>
> On Thu, Sep 1, 2011 at 9:23 PM, Ole Nielsen
> wrote:
> > Many thanks for the reply, but I need the Python bindings as we are usi
function
'Feature_SetField'.
I am sure it is something simple that changed in more recent versions - such
as an extra required argument perhaps - and I'd be grateful if someone who
knows the codebase could tell me what this error means and what I must do to
make the call succeed.
python)?
Cheers and thanks
Ole
On Thu, Sep 1, 2011 at 7:33 PM, Even Rouault
wrote:
> Selon Ole Nielsen :
>
> > Sorry for the addition, but regarding the issue with SetField, I just had
> > the same error with the inputs
> > SetField('STRUCT_DAMAGE_fraction', 0.346
on Ubuntu 11.04
this error keeps happening in our code. I don't know how to find out what
version of org we are using.
Please let me know how to work around this or if there is a patch you can
apply.
Cheers and thanks
Ole
-- Forwarded message ------
From: Ole Nielsen
Date: Thu,
6.html
but they seem to be more concerned with defining typemaps in the C
libraries. What I need to know is how to modify my
Python code so that this runs again on all relevant gdal versions.
Can anyone help, please?
Many thanks
Ole Nielsen
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
L(argv[i+1], "0"))
with a test for whether argv]i+1] is not empty and can be converted to a
numeric value.
This would be a duck-typing approach and more robust in my humble opinion.
Best regards
Ole Nielsen
-Original Message-
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-de
...70...80...90...100 - done.
Has anyone else seen this problem?
Cheers
Ole
Dr Ole Nielsen
Numerical Modeller
Australia-Indonesia Facility for Disaster Reduction
Mobile: +62 811 820 4637 | Phone: +62 21 398 30088 x1007 | Fax: +62 21 398 30068
[cid:image001.jpg@01CB8D6E.EB561F80
on binding (ReadAsArray) - or both.
Could you perhaps post the updated script that produced the double precision
values correctly?
Thanks
Ole Nielsen
-
Ole Nielsen
Australia - Indonesia Facility for Disaster Reduction
--
View this message in context:
http://osgeo-org.1803224.n2.nabbl
:50.814723686393002
Error (ASC): 0.00282112858
Error (TIF): 0.00282112858
Grateful for your help
Cheers
Ole
Dr Ole Nielsen
Numerical Modeller
Australia-Indonesia Facility for Disaster Reduction
Mobile: +62 811 820 4637 | Phone: +62 21 398 30088 x1007 | Fax: +62 21 398 30068
50.00
100.00
We then convert to kml using ogr2ogr
Thanks again
Ole
Dr Ole Nielsen
Numerical Modeller
Australia-Indonesia Facility for Disaster Reduction
Mobile: +62 811 820 4637 | Phone: +62 21 398 30088 x1007 | Fax: +62 21 398 30068
[cid:image001.jpg@01CB1DEA.70229B20]
From
only information
available in the shapefiles generated by gdal_contour, but that does not
generally reflect the order of the contour lines either.
How is it possible to determine which contour line corresponds to a particular
level?
Best regards
Ole
Dr Ole Nielsen
Numerical Modeller
Australia
(64
bit).
By the way, trying to contour directly from the NetCDF puts all the contours at
the south pole. I suspect this is another manifestation of the origins being
ignored.
Can anyone help please?
Cheers and thanks
Ole Nielsen
--
View this message in context:
http://osgeo-org.1803224.
20 matches
Mail list logo
