> 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 will not use
> /usr/share/epsg/proj for this. This is normally done with the
> $(gdal_data)/gcs.csv or $(gdal_data)/pcs.csv files derived from the
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
