Le Wednesday 10 June 2009 23:49:41 Nicholas Efremov-Kendall, vous avez écrit :
> Hi Even,
>
> quick question. If it did specify the projection, where would it put it in
> the GML file, somewhere up top I assume?
No, as an attribue of the geometry of each GML feature. Like:
-6.754960
Hey all,
Im having a bit of an issue using the python gdal api's. I keep getting an
error in python saying that it is unable to find libgdal.so.1. I am not having
any issues using the various gdal binaries however (gdalinfo works). i looked
at PYPI and changed the gdal-config location set
From the error message, it looks like you would need to specify the z
coordinate. tr.TransformPoint(pt[0], pt[1], 0)
But both old gen and new gen python bindings have z coordinate as an optional
argument. I have tested that it works with current trunk.
--> Looks like your OpenEV uses an unoffi
Nicholas,
this is a actually a good point. I've just improved ogr2ogr (svn trunk r17229)
so that it sets the spatial coordinate system on each individual geometry
when -a_srs is specified, in addition to the destination layer. This way
the 'srsName' attribute will be written for each output GML
hi list,
I've been getting the following error from osr.py:
File "C:\iapro\OpenEV\python\lib\site-packages\osgeo\osr.py", line 618, in
TransformPoint
return _osr.CoordinateTransformation_TransformPoint(*args)
NotImplementedError: Wrong number of arguments for overloaded function
'CoordinateTra
I have an NITF image in UTM projection, but its RPC appears to be
intended for LatLon. I tried to perform orthorectification on this image
using orthoigen from OSSIM, but the result was weird (panchromatic and
multispectral become non-overlapping). I plan to reproject this image
to LatLon hopi
Hi all,
I apologize for the somewhat beginner's question but here goes: I'm trying
to convert a shp file to GML. The shp file doesn't have a projection defined
for it, and I use the -a_srs" "EPSG:" -fileout -filein format. When I
convert them this way, the gml doesn't contain a bounding box or
Now, I want to use a new enhancement which is not compile by defaut. So I
have downloaded trunk sources, compiled the files and so I have a local user
library (which is so in /usr/local/lib directory).
I'm using unstable trunk library ! Yes, I 'm using new enhancement ! I shall
discover new bu
Personnaly, being the author of that change, this one is precisely the type of
change that I'm really reluctant to backport. Much too large and risky for a
stable branch, on top of previous changes over the the whole NITF driver
since 1.6, etc... I see support for 64-bit offsets in NITF more as
On Wed, Jun 10, 2009 at 12:29 PM, Even Rouault wrote:
>
> 1.7 release date hasn't been decided yet. There is no precise criterion to
> determine when it happens : it depends mainly on when RFC or major work
> planned by developers have been implemented. But if you look at the release
> date of pr
Matt,
1.7 release date hasn't been decided yet. There is no precise criterion to
determine when it happens : it depends mainly on when RFC or major work
planned by developers have been implemented. But if you look at the release
date of previous "major" versions (1.6.0 ~ 04-Dec-2008, 1.5.0 ~ 20
What's the current thinking on when 1.7 might be released? I'm interested
in a bugfix that has been added to the trunk, and am curious whether I
should spend the time to back port it to my version of 1.6.x or wait for 1.7
to be released. I'm not looking for an exact date, but a rough timeline: a
12 matches
Mail list logo
