> Giovanni,
>
> I'm afraid I don't really follow your point. Are you wanting to
> be able to do something like -t_srs GFOSSIT:3033 ?
No Frank, that would be a hell! :)
I was just thinking about the relation that can be assumed between the
epsg strings produced by gdal and the epsg codes from the
On Tue, May 22, 2012 at 3:31 PM, G. Allegri wrote:
> One proposals come from the GFOSS.it community is to consider a couple
> of new fields to characterize the epsg code: an authority code, and
> maybe an internal id for each CRS.
> Having "official" EPSG codes following the EPSG Registry would ke
Frank,
I think the opposite. Maybe it's useful for users (even if I think
it's dangerous and should be avoided) to suggest an approximate
transformation, but for services the tranformation should be chosen
carefully and shouldn't assume a default one when a correct default
isn't available.
One pro
On Tue, May 22, 2012 at 2:25 PM, G. Allegri wrote:
> Thanks Frank for the clear explanation. I've missed your blog post.
> I think that the rational behind the sorting logic is the best that
> can be done if a choice must be made. The point is IF that choice
> should be made, and you give lot of r
Thanks Frank for the clear explanation. I've missed your blog post.
I think that the rational behind the sorting logic is the best that
can be done if a choice must be made. The point is IF that choice
should be made, and you give lot of reasons for it, and I suppose lot
of users agree with having
On behalf of the GDAL/OGR development team, I am pleased to
announce the release of the GDAL/OGR 1.9.1 bug fix release. This
release contains many bug fixes since the December 1.9.0 release.
The source is available at:
http://download.osgeo.org/gdal/gdal191.zip
http://download.osgeo.org/gdal
On Tue, May 22, 2012 at 1:47 PM, G. Allegri wrote:
>> Your issue with EPSG:3003 is of a different kind, and related to another
>> change where the new logic now peaks up the EPSG preferred transformation
>> whereas it didn't before
>
> Hi Even,
> I have some difficults to follow the overall flow
> Your issue with EPSG:3003 is of a different kind, and related to another
> change where the new logic now peaks up the EPSG preferred transformation
> whereas it didn't before
Hi Even,
I have some difficults to follow the overall flow controlling the
peaking of the preferred transformation. Wh
On Thu, May 17, 2012 at 1:36 PM, Frank Warmerdam wrote:
> Motion: The GDAL/OGR 1.9.1RC2 release candidate is hearby
> declared the final GDAL/OGR 1.9.1 release.
Folks,
I declare this motion passed with support from Frank, Daniel, Even and Tamas.
I'll rename the RC to final and update the news pa
Did this motion pass? I notice that the 1.9.1 news page does not exist
on trac.osgeo.org/gdal/
-jeff
--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
h
Le mardi 22 mai 2012 21:01:26, Margherita Di Leo a écrit :
> Hi folks,
>
> looks like this bug ticket [1] finds its roots into the gdal code. From a
> discussion [2] in the gfoss.it [3] ML (the italian OSGeo local chapter)
> emerged that gdal 1.8.0 introduced a further option named
> OVERRIDE_PROJ
Hi folks,
looks like this bug ticket [1] finds its roots into the gdal code. From a
discussion [2] in the gfoss.it [3] ML (the italian OSGeo local chapter)
emerged that gdal 1.8.0 introduced a further option named
OVERRIDE_PROJ_DATUM_WITH_TOWGS84, allowing to replace the +datum definition
with a c
Frank,
> My brief thoughts are:
>
> * My objectives for GDAL/OGR 2.0 primarily revolve around
> restructuring OGR to be close alignment with the GDAL API. That means
> moving to a unified driver model, and GDAL style creation option and
> capabilities mechanisms. I want to end up with a G
13 matches
Mail list logo
