William,
> ---Original Message---
> From: William Kyngesburye
> To: Ivan Lucena
> Cc: gdal-dev
> Subject: Re: [gdal-dev] can't import osgeo or gdal in python
> Sent: Sep 20 '10 21:53
>
> On Sep 20, 2010, at 9:37 PM, Ivan Lucena wrote:
>
> > I got some good news!
> >
> > It
On Sep 20, 2010, at 9:37 PM, Ivan Lucena wrote:
> I got some good news!
>
> It is working pretty good. See:
>
> Last login: Mon Sep 20 19:08:28 on ttys002
> turtlebowl:~ ilucena$ python
> Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
> [GCC 4.2.1 (Apple Inc. build 5646)] on darwin
> Type "he
I got some good news!
It is working pretty good. See:
Last login: Mon Sep 20 19:08:28 on ttys002
turtlebowl:~ ilucena$ python
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
Well, I am following other lead.
I am trying to uninstall the python.org 2.7 and use only the 2.6 from Apple
that is actually working well with GDAL.
I did some search and found that tip on python bug report issue7107 on how to
uninstall python from OS X:
http://bugs.python.org/issue7107
Rega
On Sep 17, 2010, at 11:30 AM, Jeff Hamann wrote:
> ImportError:
> dlopen(/Library/Python/2.6/site-packages/GDAL-1.7.2-py2.6-macosx-10.6-universal.egg/osgeo/_gdal.so,
> 2): Symbol not found: _CPLDefaultErrorHandler
> Referenced from:
> /Library/Python/2.6/site-packages/GDAL-1.7.2-py2.6-macosx-
For both of you, it now sounds like the _gdal.so might not be linking libgdal
at all.
What does this return:
otool -L
/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osgeo/_gdal.so
On Sep 20, 2010, at 6:54 PM, Ivan Lucena wrote:
> Hi guys,
>
> Sorry to interrupt
Hi guys,
Sorry to interrupt but I was having the exact same error as Jeff and I was
following the discussion quite close.
But I found a solution. I can get it to work as long as if I use python2.6:
turtlebowl:~ ilucena$ python2.6
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (App
Tamas,
I altered the table and that did indeed fix up my ogrinfo results. I'm still
not getting anything from Mapserver, but I am preparing a basic mapfile that
should make testing easier.
David Lowther
Coordinate Solutions, Inc.
_
From: Tamas Szekeres [mailto:szeker...@gma
David,
The driver assumes that the first field is the fid and the second is the
geometry column in the table. This doesn't appear to be a problem until the
table has been created by the same driver.
However in your case the field ordering doesn't follow this pattern. For a
workaround you may modif
LAYER
NAME "SQL SPATIAL"
CONNECTIONTYPE OGR
CONNECTION
"MSSQL:server=coordinatesolutions.com\sqlexpress2008;database=xxx;uid=xxx;pw
d=xxx;tables=MetesAndBoundsHeader"
DATA "MetesAndBoundsHeader"
TYPE POLYGON
P
CREATE TABLE [dbo].[MetesAndBoundsHeader](
[PKey] [int] IDENTITY(1,1) NOT NULL,
[SpatialDataKey] [int] NULL,
[StartX] [decimal](18, 4) NULL,
[StartY] [decimal](18, 4) NULL,
[Feature] [geometry] NULL,
CONSTRAINT [PK_MetesAndBoundsDescription] PRIMARY KEY CLUSTERE
2010/9/20 David Lowther
>
>
> It seems almost as if there is an index off in the field information.
>
>
>
David,
That's strange indeed. What is the database type of this field in the table?
Could you provide your test data to reproduce this?
> I am also not seeing any features when I render
On Sep 20, 2010, at 12:33 PM, Christopher Barker wrote:
> Jeff Hamann wrote:
>> Chris, Thanks for responding to my post.
>
> re-including the gdal list -- I suspect you didn't mean to reply only to me.
>
>> I'm not using the pre-built frameworks as I'm trying to construct a stack
>> that can b
Hi Paolo,
Glad you liked it. If you can recall additional difficulties that you think
others would appreciate knowing, please feel free to add them to the page.
Best,
Jason
-Original Message-
From: Paolo Corti [mailto:pco...@gmail.com]
Sent: Monday, September 20, 2010 12:56 PM
To: Jaso
Hi Even and Chris,
Thanks for the review and edits. Feel free to edit as needed to reflect the
facts as seen by yourself and the GDAL team.
I replaced the reference to "C++" with "C" for numpy. Hopefully it reflects
reality now. I work mostly at the Python level these days and sometimes gloss
Even Rouault wrote:
The part where I'm not sure if about the Numpy ABI problems. I wasn't very
aware of problems related to it. From what I've seen in the code, it looks
like that the python bindings only use the C API/ABI of Numpy.
yup -- there is no C++ in numpy.
> IMHO. However, I haven't
Jason,
thanks for the effort ! I didn't find any obvious errors and it will likely be
very valuable to newcomers !
I just made a few changes in the way of expressing things. I guess some of the
unpleasant effects you can observe are more likely side effects of the
implementation and not really
Hi all,
is there a way to read VMAP data with the SWIG libs?
My request looks like: Ogr.Open("gltp:/vrf/C:/vmap/EURNASIA/LIB_xxx",
0);
Resulting datasource is null. Any hints?
Console command with ogr2ogr.exe works fine, also access to other
ressources under C#.
_
If you install all the required dll-s and gdal support files along with your
executable, you might not require to install fwtools as a prerequisite.
Best regards,
Tamas
2010/9/20 mail2vajram
>
> i have used the gdal libraries through fwtools in my .NET application, and
> now i am giong to pr
Jeff Hamann wrote:
Chris,
Thanks for responding to my post.
re-including the gdal list -- I suspect you didn't mean to reply only to me.
I'm not using the pre-built frameworks as I'm trying to construct a
stack that can be "easily" built, installed, and replicated on Linux,
FreeBSD (my fav
On Mon, Sep 20, 2010 at 6:29 PM, Jason Roberts wrote:
> Even,
>
> Thank you very much for your comments. Based on them, I started a new "Python
> Gotchas" page here http://trac.osgeo.org/gdal/wiki/PythonGotchas, referenced
> from http://trac.osgeo.org/gdal/wiki/GdalOgrInPython. Please review it
Even,
Thank you very much for your comments. Based on them, I started a new "Python
Gotchas" page here http://trac.osgeo.org/gdal/wiki/PythonGotchas, referenced
from http://trac.osgeo.org/gdal/wiki/GdalOgrInPython. Please review it to make
sure I got everything right.
Best regards,
Jason
---
On 20/09/2010 10:37, Matin80 wrote:
hm, do you think it's possible to create a batch, which looks at all the .bin
files in the directory and automatically creates a VRT for all of them (the
header is always the same)?
You could try this (in bash or similar):
$ for f in *.bin ; do gdal_translat
On 09/20/2010 12:57 PM, Lucena, Ivan wrote:
Hi Vicent,
Sorry if I called you Chris.
You didn't. Chris and I just both happen to have coded our own gdal_calc
script. They are different, each might have its pro's and con's. Sorry
if I created some confusion... I just thought it might be interes
Hi Vicent,
Sorry if I called you Chris.
I think that the gdal_calc.py implementation looks pretty good and I would vote to include it as
official GDAL command line tool. I could upload it to /swig/python/scripts/ if eveybody agrees.
Regards,
Ivan
Vincent Schut wrote:
Just fyi: I've been us
hm, do you think it's possible to create a batch, which looks at all the .bin
files in the directory and automatically creates a VRT for all of them (the
header is always the same)?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/access-multiple-files-with-VRT-tp5545929p5
Just fyi: I've been using my own brewn version of a band-math like
command line gdal python script for some years now (have sent it to the
gdal list once, like a year ago or something), you might be interested
to take a look at the source and compare approaches. I've attached the
script with t
27 matches
Mail list logo
