- What are the official ogr steps required to store a vector layer
(represented as e.g. a list of x, y values and associated feature
attributes (name, value))? In particular, is CreateField perhaps obsoleted
by something else?
Nothing obsoleted here. CreateField() and CreateFeature()
Hermann,
On 05/09/2011 16:03, Schmitz, Uwe wrote:
I wonder, if anyone else has experienced this or
similar behaviour. And how can I achieve that
ESRI- *and* gdal-Tools can identify the correct
reference system.
What I asked on this list some weeks ago:
--- snip ---
From
Hi,
thx to Jean-Claude and Even,
I definitively resolve my troubles. :)
gdalwarp is the right tool to merge.It don't break with no-one raster
and after I use gdaltranslate to produce a tiff4 raster.
To help any-one that has same need. I put the call I'm using.
The call take all the raster
Selon Jean-Claude Repetto jrepe...@free.fr:
Le 05/09/2011 19:24, Even Rouault a écrit :
If I add the libNCSEcwC.so library, it works:
I had updated configure.in and configure to include that new dependency. So
try
./configure again.
I had run ./configure, so your changes are not
Le 06/09/2011 14:12, Even Rouault a écrit :
I believe this should be fixed now by http://trac.osgeo.org/gdal/changeset/23067
.
The case that was dealt with before was when using ./configure
--with-ecw=/the/path/to/install/dir , but not ./configure --with-ecw[=yes]
which, I presume, is your use
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:
1. Bounding boxes for raster data are computed differently (but better)
in newer versions
2. While v1.6 of ogre would allow an single
On 11-09-02 04:42 PM, Even Rouault wrote:
Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny
---
+1
Daniel
--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000
___
gdal-dev mailing list
Selon Ole Nielsen ole.moller.niel...@gmail.com:
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:
1. Bounding boxes for raster data are computed differently (but better)
in newer
Thanks - I was hoping I could rely on the library to do the intelligent
truncation, but couldn't work it out.
Can I just clarify that the name to use with SetField would then be what is
provided by your last line?
layer_defn.GetFieldDefn(last_field_idx).GetNameRef()
Cheers and thanks
Ole
On
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many
cases.
However, I had a situation when trying to fetch the reference info. The
chunk of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than Matlab crashes at that line. However,
Selon Ole Nielsen ole.moller.niel...@gmail.com:
Thanks - I was hoping I could rely on the library to do the intelligent
truncation, but couldn't work it out.
Can I just clarify that the name to use with SetField would then be what is
provided by your last line?
On 11-09-06 08:10 AM, Joaquim Luis wrote:
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many cases.
However, I had a situation when trying to fetch the reference info. The chunk
of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than
On 11-09-06 12:54 AM, Schmitz, Uwe wrote:
On 05/09/2011 16:03, Schmitz, Uwe wrote:
My understanding of Frank's answer is that this is basically
not possible.
thanks for the link. It clarifies the problem but is
unsatisfactory. I must have missed this thread beforehand,
maybe due to the subject
OGR_G_* functions are intended to operate on OGRGeometry objects while
OSR* functions operate on OGRSpatialReferences. Your hSRS object is an
OGRSpatialReference and not suitable to pass to OGR_G_ExportToWkt().
You should use OSRExportToWkt() to translate an OGRSpatialReference
into it's
Hi Even,
you mentioned in your previous email that the GDALGridCreate() fcn has
only been mapped to Java bindings (I am assuming this is already the
case for the the latest stable (1.8.1) release)? If so, can you point me
to the interface file in which this is implemented? Doing a find/grep i
On Tue, Sep 6, 2011 at 8:48 AM, Joaquim Luis jl...@ualg.pt wrote:
OGR_G_* functions are intended to operate on OGRGeometry objects while
OSR* functions operate on OGRSpatialReferences. Your hSRS object is an
OGRSpatialReference and not suitable to pass to OGR_G_ExportToWkt().
You should use
Le mardi 06 septembre 2011 18:25:04, Matt Funk a écrit :
Hi Even,
you mentioned in your previous email that the GDALGridCreate() fcn has
only been mapped to Java bindings (I am assuming this is already the
case for the the latest stable (1.8.1) release)? If so, can you point me
to the
On 5 September 2011 15:46, Jan Hartmann j.l.h.hartm...@uva.nl wrote:
Is there a quick way to add back georeferencing information to a geotif file
that has been processed by Imagemagick?
There should be an applygeo utility distributed with the geotiff
library which can do this.
Andrew
On Fri, Sep 02, 2011 at 10:42:16PM +0200, Even Rouault wrote:
Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny
+1
--
Andrey V. Kiselev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Is there a quick way to add back georeferencing information to a geotif file
that has been processed by Imagemagick?
also see
http://code.google.com/p/maphew/source/browse/gis/gdal_extras/bin/gdalcopyproj.py
cheers,
matt wilkie
Geomatics Analyst
Le mardi 06 septembre 2011 19:42:18, Hilda Villegas a écrit :
Hi,
I'm trying to use the preliminary encoding support for shapefile/dbf as
you said in the Ticket #882, SHAPE_ENCODING configuration variable can
be used to override the interpretation, but I cannot find the valid
values for
Hi,
I have update the license of php5-gdal to the same as GDAL (I copied
the license block).
The project website is: http://projects.geonef.fr/projects/php5-gdal/wiki
If you want to add a link to
http://trac.osgeo.org/gdal/#GDALOGRInOtherLanguages, the project is
ready for it.
Regards,
On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny
etiennesky@gmail.com wrote:
Patrick,
A)
your suggestion does make sense, it is imperial that basic datum
information be saved as to adhere to CF-x standard. Are those CF
variables (radius, flattening etc) really sufficient for software
On Tue, Sep 6, 2011 at 8:31 PM, Patrick Sunter patdeve...@gmail.com wrote:
On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny
etiennesky@gmail.com wrote:
Patrick,
A)
your suggestion does make sense, it is imperial that basic datum
information be saved as to adhere to CF-x standard.
Yes this seems to work. However, I get a huge amounts of warnings of the
form
lyr.CreateField(fd)
Warning 6: Normalized/laundered field name: 'A slightly long name' to 'A
slightly'
0
They obviously tell what name has been derived, but I don't want this output
to clutter, and since that name is
Hi All,
Merging 2 files with a geographical CRS results in the output being shifted
a quarter-pixel to the east and south. The datum is WGS84 (altough not
explicitly named), I get the same result if I explicitly set it to WGS84.
SImilar data in modis sinusoidal projection gets merged fine with
On 11-09-06 06:05 PM, Etienne Tourigny wrote:
Hi All,
Merging 2 files with a geographical CRS results in the output being shifted a
quarter-pixel to the east and south. The datum is WGS84 (altough not
explicitly named), I get the same result if I explicitly set it to WGS84.
SImilar data in
Motion: Extend GDAL/OGR Commit Access to Etienne Tourigny
I declare this motion passed with support from PSC members AndreyK, DanielM,
EvenR, FrankW and TamasS and with non-PSC member Kyle Shannon.
Etienne, I'll let Frank deal with the practical details to enable you as a
committer.
Welcome
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 6: Normalized/laundered field name: 'A slightly long name' to 'A
slightly'
0
They obviously tell what name has been
Le mercredi 07 septembre 2011 01:48:09, Joaquim Luis a écrit :
Hi
The doc of OGR_G_GetCoordinateDimension states at
http://www.gdal.org/ogr/ogr__api_8h.html#8a5e78b0753339d1cdd282b0e151d28f
that
...
Returns:
in practice this always returns 2 indicating that coordinates
are
In case you feel like testing it, the functions needed are
OGRSpatialReference::importFromProj4() and exportToProj4(), the later
which is not documented.
Perhaps others can comment on the suitability of exporttoProj4() ???
It is documented but doxygen didn't like a macro that was
31 matches
Mail list logo
