> 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 i
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 coordi
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 na
> 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 ab
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 modi
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 th
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
On Tue, Sep 6, 2011 at 8:31 PM, Patrick Sunter wrote:
> On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny
> 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 (ra
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 specified within a two dimensional space.
but that's not true as I just
On Mon, Sep 5, 2011 at 11:23 PM, Etienne Tourigny
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 such
> as THREDDS?
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,
Jean-Fra
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
> val
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
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
On 5 September 2011 15:46, Jan Hartmann 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
___
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 this SHAPE_ENCODING anywhere, What value should I use if I
want to wr
On 06-09-2011 17:48, Frank Warmerdam wrote:
On Tue, Sep 6, 2011 at 8:48 AM, Joaquim Luis 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_Ex
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 int
On Tue, Sep 6, 2011 at 8:48 AM, Joaquim Luis 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 OS
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
could
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
WKT
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
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 M
Selon Ole Nielsen :
> 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(
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, usi
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 Tue
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:
>
>
>1. Bounding boxes for raster data are computed differently (but better)
>in newer versions
Specific to Pixel
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
gdal-dev
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 numbe
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
Selon Jean-Claude Repetto :
> 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 suff
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 ti
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 sufficient, or there is
another problem.
I have noti
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:
>
> ---
34 matches
Mail list logo
