> Randy,
>
> I think you already received other replies, but I think the problem is
> that an earlier step select gtkgl as a library but without actually
> checking properly if it was available and now the GDAL test fails because
> it also tries to include previous dependencies like gtkgl.
>
> S
Le mardi 17 novembre 2009 à 14:48 +0100, Even Rouault a écrit :
> Selon Guillaume Sueur :
>
> Guillaume,
>
> I agree that understanding what is the OGR responsibility and what is proj.4
> responsability is not always obvious ;-)
>
> When you use "EPSG:" or "+init=EPSG:x" as a SRS definit
Selon Guillaume Sueur :
Guillaume,
I agree that understanding what is the OGR responsibility and what is proj.4
responsability is not always obvious ;-)
When you use "EPSG:" or "+init=EPSG:x" as a SRS definition, OGR will try
to resolve the EPSG code from its own CSV data files, and thus
I know it's the official one, but since it has been introduced in proj
4.7 (the server is running 4.5) and OpenLayers still defines it as
900913, no chance to get it work with 3857 !
Le mardi 17 novembre 2009 à 11:33 +0100, Jean-Claude REPETTO a écrit :
> Guillaume Sueur a écrit :
> > I have ad
Guillaume Sueur a écrit :
I have added to that file the famous 900913 definition
When I try to create a SpatialReference with 900913 code, I run into a
SRSException: Unsupported SRS
Any hint would be appreciated !
Hi Guillaume,
Have you tried EPSG:3857, which is the official EPSG number fo
Hi,
Don't want to bother you guys, but I'm running into an unsupported SRS
problem I haven't been able to solve on my own for the past hours...
I'm running geodjango on a legacy server, which is said to be running
Fedora 9, with standard packages for this distro :
gdal-1.5.3-1.fc9.i386
proj-4.5.0
