First the confusion:
I ran across this today:EPSG Craziness
Fig 1 – EPSG official, official spherical mercator EPSG:3857
Looks like last Feb there was a change. The official spherical mercator is not EPSG:3785 but EPSG:3857 !?
EPSG:3857
<ProjectedCRS
xmlns=”http://www.opengis.net/gml”
xmlns:gml=”http://www.opengis.net/gml” gml:id=”ogp-crs-3857″>
<metaDataProperty>
<epsg:CommonMetaData xmlns:epsg=”urn:x-ogp:spec:schema-xsd:EPSG:0.1:dataset”>
<epsg:type>projected</epsg:type>
<epsg:alias code=”5966″ codeSpace=”urn:ogc:def:naming-system:EPSG::7301″
alias=”WGS 84 / Popular Visualisation Pseudo-Mercator” />
<epsg:informationSource>Microsoft.</epsg:informationSource>
<epsg:revisionDate>2009-02-09</epsg:revisionDate>
<epsg:changes>
<epsg:changeID xmlns:xlink=”http://www.w3.org/1999/xlink”
xlink:href=”urn:ogc:def:change-request:EPSG::2008.114″ />
</epsg:changes>
<epsg:show>true</epsg:show>
<epsg:isDeprecated>false</epsg:isDeprecated>
</epsg:CommonMetaData>
</metaDataProperty>
<identifier codeSpace=”OGP”>urn:ogc:def:crs:EPSG::3857</identifier>
<name>WGS 84 / Pseudo-Mercator</name>
<remarks>Uses spherical development of ellipsoidal coordinates. Relative to an ellipsoidal development errors
of up to 800 metres in position and 0.7 percent in scale may arise. It is not
a recognised geodetic system: see WGS 84 / World Mercator (CRS code 3395).</remarks>
<domainOfValidity xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:href=”urn:ogc:def:area:EPSG::3544″ />
<scope>Certain Web mapping and visualisation applications.</scope>
<conversion xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:href=”urn:ogc:def:coordinateOperation:EPSG::3856″ />
<baseGeodeticCRS xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:href=”urn:ogc:def:crs:EPSG::4326″ />
<cartesianCS xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:href=”urn:ogc:def:cs:EPSG::4499″ />
</ProjectedCRS>
IsDeprecated=True EPSG:3785
<ProjectedCRS
xmlns=”http://www.opengis.net/gml”
xmlns:gmd=”http://www.isotc211.org/2005/gmd”
xmlns:gco=”http://www.isotc211.org/2005/gco”
xmlns:epsg=”urn:x-ogp:spec:schema-xsd:EPSG:0.1:dataset”
xmlns:gml=”http://www.opengis.net/gml”
xmlns:xlink=”http://www.w3.org/1999/xlink”
xmlns:rim=”urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0″
gml:id=”epsg-crs-3785″>
<metaDataProperty>
<epsg:CommonMetaData>
<epsg:type>projected</epsg:type>
<epsg:alias alias=”Popular Vis CRS / Merc” code=”5516″
codeSpace=”urn:ogc:def:naming-system:EPSG::7302″ />
<epsg:informationSource>Microsoft.</epsg:informationSource>
<epsg:revisionDate>2008-03-14</epsg:revisionDate>
<epsg:changes>
<epsg:changeID xlink:href=”urn:ogc:def:change-request:EPSG::2008.114″ />
</epsg:changes>
<epsg:show>true</epsg:show>
<epsg:isDeprecated>true</epsg:isDeprecated>
</epsg:CommonMetaData>
</metaDataProperty>
<identifier codeSpace=”OGP”>urn:ogc:def:crs:EPSG::3785</identifier>
<name>Popular Visualisation CRS / Mercator</name>
<remarks>Uses spherical development. Relative to an ellipsoidal development errors of up
to 800 metres in position and 0.7% in scale may arise. Some applications call this WGS 84.
It is not a recognised geodetic system: see WGS 84 / World Mercator (CRS code 3395)</remarks>
<domainOfValidity xlink:href=”urn:ogc:def:area:EPSG::3544″ />
<scope>Certain Web mapping and visualisation applications.</scope>
<conversion xlink:href=”urn:ogc:def:coordinateOperation:EPSG::19847″ />
<baseGeodeticCRS xlink:href=”urn:ogc:def:crs:EPSG::4055″ />
<cartesianCS xlink:href=”urn:ogc:def:cs:EPSG::4499″ />
</ProjectedCRS>
Next the transparency
- Clarification on Silverlight MapControl PNG tansparency support
After some more investigation on the transparency problem I was running into, here is the gdalInfo for an example that does not work. It’s apparently png8 with color table which is more compact and valid, but the NoData Value=0 is ignored by Silverlight MapControl:
Driver: PNG/Portable Network Graphi
Files: PA_Hillshade.png
Size is 1259, 700
Coordinate System is `'
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 700.0)
Upper Right ( 1259.0, 0.0)
Lower Right ( 1259.0, 700.0)
Center ( 629.5, 350.0)
Band 1 Block=1259x1 Type=Byte, Colo
NoData Value=0
Color Table (RGB with 256 entries
0: 255,255,255,0
1: 184,184,184,255
2: 177,177,177,255
3: 175,175,175,255
.
.
Next run gdal_translate -of png -expand rgba PA_Hillshade.png PA_Hillshade4b.png to expand to png32:
Driver: PNG/Portable Network Graphics
Files: PA_Hillshade4b.png
PA_Hillshade4b.png.aux.xml
Size is 1259, 700
Coordinate System is `'
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 700.0)
Upper Right ( 1259.0, 0.0)
Lower Right ( 1259.0, 700.0)
Center ( 629.5, 350.0)
Band 1 Block=1259x1 Type=Byte, ColorInterp=Red
NoData Value=0
Band 2 Block=1259x1 Type=Byte, ColorInterp=Green
NoData Value=0
Band 3 Block=1259x1 Type=Byte, ColorInterp=Blue
NoData Value=0
Band 4 Block=1259x1 Type=Byte, ColorInterp=Alpha
NoData Value=0
Silverlight png transparency now works. Of course the png produced by a public WMS is out of my control.
If Silverlight doesn’t support a png8 transparency it looks like an on the fly translate is in order, which is another reason to use a proxy .ashx for a WMS GetMap request.