Andy Allan kirjoitti: > On Thu, Nov 18, 2010 at 5:58 PM, Mâ¡rtin Koppenhoefer > <[email protected]> wrote: >> First I must admit that I don't know much about projections, reference >> systems and geodetic datums. >> >> I have recently experimented with homemade hillshading and contours, >> and I found out by trying that my hillshade was fitting the contours >> if I assumed it was in EPSG 3785 (I created the hillshading from SRTM >> with Grass GIS and reprojected to an EPSG 900913 setting while the >> contours were created with mapnik and srtm2osm). >> By reading the EPSG documentation sheets it seems that 3785 and 3857 >> are not the same (the first uses a sphere, while the latter uses an >> ellipsoid with inverse flattening of 298.257223563). EPSG says that >> the ellipsoid-version is valid (and registered as 3857) while the >> sphere is not. This results visually in quite some change on the map >> if you mix it up. >> >> Therefor I thought that Mapnik's 900913 was equal to EPSG's >> "non-valid" 3785 version with the sphere. (EPSG states: "Sphere with >> radius equal to the semi-major axxis of the GRS80 and WGS84 >> ellipsoids. Used only for Web approximate mapping and visualisation. >> Not recognised by geodetic authorities" --- on which I found some >> comments ("EPSG is arrogant") in the web btw. who said it was >> perfectly working with the sphere as well, even if not scientifically >> correct). >> >> Now I found some docs in the OSM-Wiki that state we were using EPSG >> 3857. >> >> My own tests indicate "we" are using the (not registered) "3785" >> (sphere). >> >> Also this setting in mapnik/inc/entities.xml.inc indicates this: >> <!ENTITY srs900913 "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 >> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null +no_defs >> +over"> >> >> in generate_image.py I found this (seems that someone changed from >> sphere to ellipsoid): >> Â Â # prj = mapnik.Projection("+proj=merc +a=6378137 +b=6378137 >> +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null >> +no_defs +over") >> Â Â prj = mapnik.Projection("+proj=merc +a=6378137 +rf=298.257223563 >> +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgri...@null >> +no_defs +over") >> >> can someone please tell me which datum is used by the mapnik and t...@h >> tile servers? > > I'm totally confused by your email, so bear with me. > > As far as I'm aware, 900913, 3785 and 3857 are all identical, and > don't have the difference that you are describing above. From > spatialreference.org > > http://www.spatialreference.org/ref/epsg/3785/ > http://www.spatialreference.org/ref/epsg/3785/proj4/ > > http://spatialreference.org/ref/sr-org/6864/ (EPSG:3857) > http://spatialreference.org/ref/sr-org/6864/proj4/ > > From the proj4 project: > http://trac.osgeo.org/proj/browser/trunk/proj/nad/epsg > > Moreover, you refer to changes made to the generate_image.py file, but > I don't see such a change: > http://trac.openstreetmap.org/browser/applications/rendering/mapnik/generate_image.py#L38 > > However, the following two entries at EPSG are conflicting with all > the above, and do in fact appear to be different: > http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3785&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3785 > http://www.epsg-registry.org/report.htm?type=selection&entity=urn:ogc:def:crs:EPSG::3857&reportDetail=short&style=urn:uuid:report-style:default-with-code&style_name=OGP%20Default%20With%20Code&title=EPSG:3857 > > > Ho hum. Maybe take it up with the proj project? Anyway, we use > Spherical Mercator ie. the one without the +rf=298.25... so I'd find a > different copy of generate_image.py >
Hi, I asked this from gdal-dev list and this is what Frank Warmerdam wrote: < Jukka, < In EPSG:3785 web mercator was expressed as a normal Mercator 1SP < projection on a spherical GCS. However, this lost the fact that < the lat/long coordinates you produced when unprojecting the mercator < coordiantes were supposed to be treated as WGS84, not lat/long on the < sphere. < So that was deprecated and EPSG:3857 (it freaks me out that they are < the same digits just rearranged!) was introduced. This is based on < WGS84, but they define a custom projection method "Popular Visualization < Psuedo Mercator" which seems to have the spherical earth model for the < projection algorithm "baked in", but is otherwise based on a normal < WGS84 GCS. This makes it easy for applications to understand that the < unprojected coordinates are to be treated as WGS84. < For what it's worth, GDAL has custom logic to treat them as equivalent. Unfortunately I do not really understand the answer, but I suppose that if gdal is recognising EPSG:3857 then it treats it right. -Jukka Rahkonen- _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
