Users

Popular Threads From Users:

SphericalMercator and SRS aliases epsg:900913, epsg:3857, epsg:3785, epsg:102113

GeoExt & OpenLayers, IE8 vs other Browsers

Geoserver WMS Layer Does Not Display

Control.SelectFeature

WMS and Mercator projection

List Statistics

Total Threads: 1594
Total Posts: 2743

Phrases Used to Find This Thread

Page 1 of 1

19-07-2010 11:14 AM

Users member admin is online now

User

19-07-2010 11:29 AM

Users member admin is online now

User

19-07-2010 12:09 PM

Users member admin is online now

User

19-07-2010 12:15 PM

Users member admin is online now

User

19-07-2010 01:51 PM

Users member admin is online now

User

19-07-2010 03:15 PM

Users member admin is online now

User

19-07-2010 04:37 PM

Users member admin is online now

User

19-07-2010 05:48 PM

Users member admin is online now

User

19-07-2010 10:17 PM

Users member admin is online now

User

#10

21-07-2010 06:42 AM

Users member admin is online now

User

#11

25-07-2010 01:02 AM

Users member admin is online now

User

#12

25-07-2010 09:17 PM

Users member admin is online now

User

#13

25-07-2010 11:02 PM

Users member admin is online now

User

Hello list,

OpenStreetMap and also some popular commercial mapservices (google,
bing, yahoo) are using the so called sphericalmercator projection.
OpenLayers has built-in support for this type of layer, inherited from
OpenLayers.Layer.SphericalMercator.

If you use a sphericalmercator layer as a baselayer, you may want to
combine this with other layers. By default, the openlayers
sphericalmercator baselayer uses SRS projection-code 'EPSG:900913' . So,
if you try to open an overlay, the overlay layer will be called with
parameter SRS=EPSG:900913.

EPSG Code 900913 happens to be a bogus code, based on the word 'google'.
Perhaps due to the resemblance of '900913' and 'google' or due to other
reasons, there are now several other codes in use for the same projection:
EPSG:3857
EPSG:3785 <= maybe because of a typo by someone somewhere?
EPSG:102113

Some map-services have stopped supporting SRS=EPSG:900913 and this
raises a problem for openlayers sphericalmercator users. Instead of
displaying a map, these mapservices will respond with something like 'no
support for EPSG:900913'.

The problem of overlaying sphericalmercator layers that do not support
epsg:900913 can be (partly) solved as follows:
Override the default srs code for sphericalmercator layers by explicitly
resetting the projection before adding the layer to a map:

var osmLayer = new OpenLayers.Layer.OSM("OpenStreetMap"); // osmlayer is
now sphericalmercator with default epsg:900913
osmLayer.projection = new OpenLayers.Projection ("EPSG:3857"); //
osmlayer is now sphericalmercator with epsg:3857
map.addLayers ([osmLayer]);

Overlay layers will now be requested with SRS=ESPG:3857

However, resetting the code for the baselayer projection, causes trouble
for the controls for MousePosition and MeasureControl: distances and
coordinates are no longer presented in the correct projection.

I solved this by adding the following lines of code to file
lib\OpenLayers\Layer\SphericalMercator.js
OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
OpenLayers.Layer.SphericalMercator.projectForward);
OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:102113",
OpenLayers.Layer.SphericalMercator.projectForward);
OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3785",
OpenLayers.Layer.SphericalMercator.projectForward);

OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
OpenLayers.Layer.SphericalMercator.projectInverse);
OpenLayers.Projection.addTransform("EPSG:102113", "EPSG:4326",
OpenLayers.Layer.SphericalMercator.projectInverse);
OpenLayers.Projection.addTransform("EPSG:3785", "EPSG:4326",
OpenLayers.Layer.SphericalMercator.projectInverse);

Questions:
- is this the way to support aliases for 900913 and support
MousePosition and MeasureControl at the same time?
- if yes, shouldn't the above lines be part of the standard OpenLayers
distribution?

Anne Blankert

_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hi Anne,

in trunk this has been addressed, see:

http://trac.openlayers.org/ticket/2665

Best regards,
Bart

> Hello list,
>
> OpenStreetMap and also some popular commercial mapservices (google,
> bing, yahoo) are using the so called sphericalmercator projection.
> OpenLayers has built-in support for this type of layer, inherited from
> OpenLayers.Layer.SphericalMercator.
>
> If you use a sphericalmercator layer as a baselayer, you may want to
> combine this with other layers. By default, the openlayers
> sphericalmercator baselayer uses SRS projection-code 'EPSG:900913' . So,
> if you try to open an overlay, the overlay layer will be called with
> parameter SRS=EPSG:900913.
>
> EPSG Code 900913 happens to be a bogus code, based on the word 'google'.
> Perhaps due to the resemblance of '900913' and 'google' or due to other
> reasons, there are now several other codes in use for the same projection:
> EPSG:3857
> EPSG:3785 <= maybe because of a typo by someone somewhere?
> EPSG:102113
>
> Some map-services have stopped supporting SRS=EPSG:900913 and this
> raises a problem for openlayers sphericalmercator users. Instead of
> displaying a map, these mapservices will respond with something like 'no
> support for EPSG:900913'.
>
> The problem of overlaying sphericalmercator layers that do not support
> epsg:900913 can be (partly) solved as follows:
> Override the default srs code for sphericalmercator layers by explicitly
> resetting the projection before adding the layer to a map:
>
> var osmLayer = new OpenLayers.Layer.OSM("OpenStreetMap"); // osmlayer is
> now sphericalmercator with default epsg:900913
> osmLayer.projection = new OpenLayers.Projection ("EPSG:3857"); //
> osmlayer is now sphericalmercator with epsg:3857
> map.addLayers ([osmLayer]);
>
> Overlay layers will now be requested with SRS=ESPG:3857
>
> However, resetting the code for the baselayer projection, causes trouble
> for the controls for MousePosition and MeasureControl: distances and
> coordinates are no longer presented in the correct projection.
>
> I solved this by adding the following lines of code to file
> lib\OpenLayers\Layer\SphericalMercator.js
> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
> OpenLayers.Layer.SphericalMercator.projectForward);
> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:102113",
> OpenLayers.Layer.SphericalMercator.projectForward);
> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3785",
> OpenLayers.Layer.SphericalMercator.projectForward);
>
> OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
> OpenLayers.Layer.SphericalMercator.projectInverse);
> OpenLayers.Projection.addTransform("EPSG:102113", "EPSG:4326",
> OpenLayers.Layer.SphericalMercator.projectInverse);
> OpenLayers.Projection.addTransform("EPSG:3785", "EPSG:4326",
> OpenLayers.Layer.SphericalMercator.projectInverse);
>
> Questions:
> - is this the way to support aliases for 900913 and support
> MousePosition and MeasureControl at the same time?
> - if yes, shouldn't the above lines be part of the standard OpenLayers
> distribution?
>
> Anne Blankert
>
>
> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hello Bart,

I am not sure if

http://trac.openlayers.org/ticket/2665

takes care of the side effect that Control.Measure and MousePosition are
no longer working properly after resetting the projection code?

Anne

On 7/19/2010 12:29 PM, Bart van den Eijnden (OSGIS) wrote:
> Hi Anne,
>
> in trunk this has been addressed, see:
>
> http://trac.openlayers.org/ticket/2665
>
> Best regards,
> Bart
>
>> Hello list,
>>
>> OpenStreetMap and also some popular commercial mapservices (google,
>> bing, yahoo) are using the so called sphericalmercator projection.
>> OpenLayers has built-in support for this type of layer, inherited from
>> OpenLayers.Layer.SphericalMercator.
>>
>> If you use a sphericalmercator layer as a baselayer, you may want to
>> combine this with other layers. By default, the openlayers
>> sphericalmercator baselayer uses SRS projection-code 'EPSG:900913' . So,
>> if you try to open an overlay, the overlay layer will be called with
>> parameter SRS=EPSG:900913.
>>
>> EPSG Code 900913 happens to be a bogus code, based on the word 'google'.
>> Perhaps due to the resemblance of '900913' and 'google' or due to other
>> reasons, there are now several other codes in use for the same projection:
>> EPSG:3857
>> EPSG:3785<= maybe because of a typo by someone somewhere?
>> EPSG:102113
>>
>> Some map-services have stopped supporting SRS=EPSG:900913 and this
>> raises a problem for openlayers sphericalmercator users. Instead of
>> displaying a map, these mapservices will respond with something like 'no
>> support for EPSG:900913'.
>>
>> The problem of overlaying sphericalmercator layers that do not support
>> epsg:900913 can be (partly) solved as follows:
>> Override the default srs code for sphericalmercator layers by explicitly
>> resetting the projection before adding the layer to a map:
>>
>> var osmLayer = new OpenLayers.Layer.OSM("OpenStreetMap"); // osmlayer is
>> now sphericalmercator with default epsg:900913
>> osmLayer.projection = new OpenLayers.Projection ("EPSG:3857"); //
>> osmlayer is now sphericalmercator with epsg:3857
>> map.addLayers ([osmLayer]);
>>
>> Overlay layers will now be requested with SRS=ESPG:3857
>>
>> However, resetting the code for the baselayer projection, causes trouble
>> for the controls for MousePosition and MeasureControl: distances and
>> coordinates are no longer presented in the correct projection.
>>
>> I solved this by adding the following lines of code to file
>> lib\OpenLayers\Layer\SphericalMercator.js
>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
>> OpenLayers.Layer.SphericalMercator.projectForward);
>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:102113",
>> OpenLayers.Layer.SphericalMercator.projectForward);
>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3785",
>> OpenLayers.Layer.SphericalMercator.projectForward);
>>
>> OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
>> OpenLayers.Layer.SphericalMercator.projectInverse);
>> OpenLayers.Projection.addTransform("EPSG:102113", "EPSG:4326",
>> OpenLayers.Layer.SphericalMercator.projectInverse);
>> OpenLayers.Projection.addTransform("EPSG:3785", "EPSG:4326",
>> OpenLayers.Layer.SphericalMercator.projectInverse);
>>
>> Questions:
>> - is this the way to support aliases for 900913 and support
>> MousePosition and MeasureControl at the same time?
>> - if yes, shouldn't the above lines be part of the standard OpenLayers
>> distribution?
>>
>> Anne Blankert
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hi Anne,

check the example (first couple of lines in comments):

http://trac.openlayers.org/browser/trunk/openlayers/examples/web-mercator.js?rev=10384

So that's up to the application to provide (at least for now). But I can
also see that's not really easy for end-users.

What do other people think about providing the EPSG aliases by default in
the OL library?

Best regards,
Bart

> Hello Bart,
>
> I am not sure if
>
> http://trac.openlayers.org/ticket/2665
>
> takes care of the side effect that Control.Measure and MousePosition are
> no longer working properly after resetting the projection code?
>
> Anne
>
> On 7/19/2010 12:29 PM, Bart van den Eijnden (OSGIS) wrote:
>> Hi Anne,
>>
>> in trunk this has been addressed, see:
>>
>> http://trac.openlayers.org/ticket/2665
>>
>> Best regards,
>> Bart
>>
>>> Hello list,
>>>
>>> OpenStreetMap and also some popular commercial mapservices (google,
>>> bing, yahoo) are using the so called sphericalmercator projection.
>>> OpenLayers has built-in support for this type of layer, inherited from
>>> OpenLayers.Layer.SphericalMercator.
>>>
>>> If you use a sphericalmercator layer as a baselayer, you may want to
>>> combine this with other layers. By default, the openlayers
>>> sphericalmercator baselayer uses SRS projection-code 'EPSG:900913' .
>>> So,
>>> if you try to open an overlay, the overlay layer will be called with
>>> parameter SRS=EPSG:900913.
>>>
>>> EPSG Code 900913 happens to be a bogus code, based on the word
>>> 'google'.
>>> Perhaps due to the resemblance of '900913' and 'google' or due to other
>>> reasons, there are now several other codes in use for the same
>>> projection:
>>> EPSG:3857
>>> EPSG:3785<= maybe because of a typo by someone somewhere?
>>> EPSG:102113
>>>
>>> Some map-services have stopped supporting SRS=EPSG:900913 and this
>>> raises a problem for openlayers sphericalmercator users. Instead of
>>> displaying a map, these mapservices will respond with something like
>>> 'no
>>> support for EPSG:900913'.
>>>
>>> The problem of overlaying sphericalmercator layers that do not support
>>> epsg:900913 can be (partly) solved as follows:
>>> Override the default srs code for sphericalmercator layers by
>>> explicitly
>>> resetting the projection before adding the layer to a map:
>>>
>>> var osmLayer = new OpenLayers.Layer.OSM("OpenStreetMap"); // osmlayer
>>> is
>>> now sphericalmercator with default epsg:900913
>>> osmLayer.projection = new OpenLayers.Projection ("EPSG:3857"); //
>>> osmlayer is now sphericalmercator with epsg:3857
>>> map.addLayers ([osmLayer]);
>>>
>>> Overlay layers will now be requested with SRS=ESPG:3857
>>>
>>> However, resetting the code for the baselayer projection, causes
>>> trouble
>>> for the controls for MousePosition and MeasureControl: distances and
>>> coordinates are no longer presented in the correct projection.
>>>
>>> I solved this by adding the following lines of code to file
>>> lib\OpenLayers\Layer\SphericalMercator.js
>>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
>>> OpenLayers.Layer.SphericalMercator.projectForward);
>>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:102113",
>>> OpenLayers.Layer.SphericalMercator.projectForward);
>>> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3785",
>>> OpenLayers.Layer.SphericalMercator.projectForward);
>>>
>>> OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
>>> OpenLayers.Layer.SphericalMercator.projectInverse);
>>> OpenLayers.Projection.addTransform("EPSG:102113", "EPSG:4326",
>>> OpenLayers.Layer.SphericalMercator.projectInverse);
>>> OpenLayers.Projection.addTransform("EPSG:3785", "EPSG:4326",
>>> OpenLayers.Layer.SphericalMercator.projectInverse);
>>>
>>> Questions:
>>> - is this the way to support aliases for 900913 and support
>>> MousePosition and MeasureControl at the same time?
>>> - if yes, shouldn't the above lines be part of the standard OpenLayers
>>> distribution?
>>>
>>> Anne Blankert
>>>
>>>
>>> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hello Bart,

My 2 cents:
In my opinion it is quite difficult for users to discover:
- OpenStreetMap, Google, Bing, Yahoo etc. use a projection called
'SphericalMercator'
- 'SphericalMercator' in OpenLayers uses code 'epsg:900913'
- there exist multiple aliases for 'epsg:900913' and some services
prefer alias epsg:3857 or epsg:102113 over epsg:900913
- how to override the default openlayers sphericalmercator epsg code
with an other epsg code
- discover that the override produces side effects in measurement and
mouseposition (and other functions, such as click-events...?)
- how to solve the side effects, by adding code:
OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
OpenLayers.Layer.SphericalMercator.projectForward);
OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
OpenLayers.Layer.SphericalMercator.projectInverse);

But instead of solving this in the library, this can also be part of the
documentation. Maybe that documentation already exists and I've
overlooked it?

Cheers,

Anne

On 7/19/2010 1:15 PM, Bart van den Eijnden (OSGIS) wrote:
> Hi Anne,
>
> check the example (first couple of lines in comments):
>
> http://trac.openlayers.org/browser/trunk/openlayers/examples/web-mercator.js?rev=10384
>
> So that's up to the application to provide (at least for now). But I can
> also see that's not really easy for end-users.
>
> What do other people think about providing the EPSG aliases by default in
> the OL library?

_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. On Jul 19, 2010, at 8:51 AM, ext Anne Blankert wrote:

>
> Hello Bart,
>
> My 2 cents:
> In my opinion it is quite difficult for users to discover:
> - OpenStreetMap, Google, Bing, Yahoo etc. use a projection called
> 'SphericalMercator'
> - 'SphericalMercator' in OpenLayers uses code 'epsg:900913'

I think this is reasonably well documented in

http://docs.openlayers.org/library/spherical_mercator.html

and if you search for:

http://docs.openlayers.org/search.html?q=google+projection

You get that as one of the results. (Not as highly ranked as I would
like, I'll admit, but it is there.)

> - there exist multiple aliases for 'epsg:900913' and some services
> prefer alias epsg:3857 or epsg:102113 over epsg:900913
> - how to override the default openlayers sphericalmercator epsg code
> with an other epsg code

This being supported is something I'd question ;) Until very recently,
I'm pretty sure it was not at all possible to do this, so it's not really
a surprised that it isn't well documented, in my opinion.

> - discover that the override produces side effects in measurement and
> mouseposition (and other functions, such as click-events...?)
> - how to solve the side effects, by adding code:
> OpenLayers.Projection.addTransform("EPSG:4326", "EPSG:3857",
> OpenLayers.Layer.SphericalMercator.projectForward);
> OpenLayers.Projection.addTransform("EPSG:3857", "EPSG:4326",
> OpenLayers.Layer.SphericalMercator.projectInverse);
>
> But instead of solving this in the library, this can also be part of the
> documentation. Maybe that documentation already exists and I've
> overlooked it?

No documentation like this exists at this time that I'm aware of.

-- Chris

>
> Cheers,
>
> Anne
>
> On 7/19/2010 1:15 PM, Bart van den Eijnden (OSGIS) wrote:
>> Hi Anne,
>>
>> check the example (first couple of lines in comments):
>>
>> http://trac.openlayers.org/browser/trunk/openlayers/examples/web-mercator.js?rev=10384
>>
>> So that's up to the application to provide (at least for now). But I can
>> also see that's not really easy for end-users.
>>
>> What do other people think about providing the EPSG aliases by default in
>> the OL library?
>
>
> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Thanks for pointing to this fairly complete documentation. However,
the subject of why and how to use the epsg:900913 aliases and the
caveats is not yet included. I've added a section "SphericalMercator and
EPSG aliases" to http://trac.openlayers.org/wiki/SphericalMercator.

I don't think users can edit documentation such as

http://docs.openlayers.org/library/spherical_mercator.html

directly can they?

Anne
>> Hello Bart,
>>
>> My 2 cents:
>> In my opinion it is quite difficult for users to discover:
>> - OpenStreetMap, Google, Bing, Yahoo etc. use a projection called
>> 'SphericalMercator'
>> - 'SphericalMercator' in OpenLayers uses code 'epsg:900913'
> I think this is reasonably well documented in
>
> http://docs.openlayers.org/library/spherical_mercator.html
>
> and if you search for:
>
> http://docs.openlayers.org/search.html?q=google+projection
>
> You get that as one of the results. (Not as highly ranked as I would
> like, I'll admit, but it is there.)
>

_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hi Anne,

the best way for documentation fixes/additions is to create a patch (svn diff or unified diff) on the rst document (available in svn) and create a Trac ticket with the patch attached. TIA.

Best regards,
Bart

--
Looking for flexible support on OpenLayers or GeoExt? Please check out http://www.osgis.nl/support.html

Bart van den Eijnden
OSGIS

On Jul 19, 2010, at 5:37 PM, Anne Blankert wrote:

> Thanks for pointing to this fairly complete documentation. However,
> the subject of why and how to use the epsg:900913 aliases and the
> caveats is not yet included. I've added a section "SphericalMercator and
> EPSG aliases" to http://trac.openlayers.org/wiki/SphericalMercator.
>
> I don't think users can edit documentation such as
>
> http://docs.openlayers.org/library/spherical_mercator.html
>
> directly can they?
>
> Anne
>>> Hello Bart,
>>>
>>> My 2 cents:
>>> In my opinion it is quite difficult for users to discover:
>>> - OpenStreetMap, Google, Bing, Yahoo etc. use a projection called
>>> 'SphericalMercator'
>>> - 'SphericalMercator' in OpenLayers uses code 'epsg:900913'
>> I think this is reasonably well documented in
>>
>> http://docs.openlayers.org/library/spherical_mercator.html
>>
>> and if you search for:
>>
>> http://docs.openlayers.org/search.html?q=google+projection
>>
>> You get that as one of the results. (Not as highly ranked as I would
>> like, I'll admit, but it is there.)
>>
>
>
> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. .
> What do other people think about providing the EPSG aliases by default in
> the OL library?
>
good idea. AGS uses 102113 and I use an override to manage this
projection issue. eg

Ext.override(OpenLayers.Layer.WMS, {
getFullRequestString:function(newParams, altUrl) {
var projectionCode = this.map.getProjection();
if (this.url == null) isAGS ==0;
else var isAGS = this.url.search(/arcgis/);
if((projectionCode == 'EPSG:900913') && (isAGS >=0)) {
this.params.SRS = 'EPSG:102113';
} else {
this.params.SRS = (projectionCode == "none") ?
null : projectionCode;
}

return
OpenLayers.Layer.Grid.prototype.getFullRequestString.apply(
this,
arguments);
}
});

--
Phil Scadden, Senior Scientist GNS Science Ltd 764 Cumberland St,
Private Bag 1930, Dunedin, New Zealand Ph +64 3 4799663, fax +64 3 477 5232

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.

_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. On Jul 19, 2010, at 11:37 AM, ext Anne Blankert wrote:

>
> Thanks for pointing to this fairly complete documentation. However,
> the subject of why and how to use the epsg:900913 aliases and the
> caveats is not yet included. I've added a section "SphericalMercator and
> EPSG aliases" to http://trac.openlayers.org/wiki/SphericalMercator.
>
> I don't think users can edit documentation such as
>
> http://docs.openlayers.org/library/spherical_mercator.html
>
> directly can they?

Correct, this would have to be done via patches.

I have integrated your changes into the main documentation:

http://docs.openlayers.org/library/spherical_mercator.html#sphericalmercator-and-epsg-aliases

Thanks for the assist!

-- Chris

>
> Anne
>>> Hello Bart,
>>>
>>> My 2 cents:
>>> In my opinion it is quite difficult for users to discover:
>>> - OpenStreetMap, Google, Bing, Yahoo etc. use a projection called
>>> 'SphericalMercator'
>>> - 'SphericalMercator' in OpenLayers uses code 'epsg:900913'
>> I think this is reasonably well documented in
>>
>> http://docs.openlayers.org/library/spherical_mercator.html
>>
>> and if you search for:
>>
>> http://docs.openlayers.org/search.html?q=google+projection
>>
>> You get that as one of the results. (Not as highly ranked as I would
>> like, I'll admit, but it is there.)
>>
>
>
> _______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. I agree with Phil, their should be built-in support for spherical mercator
aliases after all. The (now) documented work-around does not work if you
need to overlay multiple layers from providers that each support a different
alias.

The idea that Phil published seems to be the best solution I've seen so far.
As long as this type of solution is not part of OpenLayers, this kind of
override can do the trick. The code that Phil provided depends on Ext and
the word 'arcgis' in the Url. I modified it slightly to remove the
dependencies and support a new layer option 'sphericalmercatoralias'.

// override OpenLayers.WMS.getFullRequestString class member function
OpenLayers.Layer.WMS.prototype.getFullRequestString = function(newParams,
altUrl) {
var projectionCode = this.map.getProjection();
if (this.options.sphericalmercatoralias)
{
if(projectionCode == 'EPSG:900913' || projectionCode == 'EPSG:102113' ||
projectionCode == 'EPSG:3857') {
this.params.SRS = this.options.sphericalmercatoralias;
} else {
this.params.SRS = (projectionCode == "none") ? null : projectionCode;
}
}
return OpenLayers.Layer.Grid.prototype.getFullRequestString.apply( this,
arguments);
}

After this override, you can set a new layeroption 'sphericalmercatoralias'
to tell OpenLayers to use that instead of the default as follows:

layer = new OpenLayers.Layer.WMS(title, url, {layers},
{sphericalmercatoralias: "EPSG:102113"});

Phil Scadden wrote:
>
> .
>> What do other people think about providing the EPSG aliases by default in
>> the OL library?
>>
> good idea. AGS uses 102113 and I use an override to manage this
> projection issue. eg
>
> Ext.override(OpenLayers.Layer.WMS, {
> getFullRequestString:function(newParams, altUrl) {
> var projectionCode = this.map.getProjection();
> if (this.url == null) isAGS ==0;
> else var isAGS = this.url.search(/arcgis/);
> if((projectionCode == 'EPSG:900913') && (isAGS >=0))
> {
> this.params.SRS = 'EPSG:102113';
> } else {
> this.params.SRS = (projectionCode == "none") ?
> null : projectionCode;
> }
>
> return
> OpenLayers.Layer.Grid.prototype.getFullRequestString.apply(
> this,
> arguments);
> }
> });
>
>

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/SphericalMercator-and-SRS-aliases-epsg-900913-epsg-3857-epsg-3785-epsg-102113-tp5311417p5334027.html
Sent from the OpenLayers Users mailing list archive at Nabble.com.
_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hi,

I wouldn't restrict it to sphericalmercatoralias. I use a similiar approach
to add WMS Server, which use a different EPSG code than my map, but describe
the same projection.

Why not use options.projection to request the WMS in this projection?

OpenLayers.Layer.WMS.prototype.getFullRequestString =
function(newParams,altUrl)
{
try{
var projectionCode = typeof this.options.projection == 'undefined' ?
this.map.getProjection() : this.options.projection;
}catch(err){
var projectionCode=this.map.getProjection();
}

var value = (projectionCode == "none") ? null : projectionCode
if (parseFloat(this.params.VERSION) >= 1.3) {
this.params.CRS = value;
} else {
this.params.SRS = value;
}

return OpenLayers.Layer.Grid.prototype.getFullRequestString.apply(this,
arguments);
},

Arnd

-----Urspr�ngliche Nachricht-----
Von: users- [mailto:users-] Im
Auftrag von Anne Blankert
Gesendet: Sonntag, 25. Juli 2010 13:54
An:
Betreff: Re: [OpenLayers-Users] SphericalMercator and SRS aliases
epsg:900913, epsg:3857, epsg:3785, epsg:102113

Hmm,

I didn't test my code properly, (layers without option sphericalmercator
stopped working). The following code should do better (Version >= 1.3 not
yet tested):

// override OpenLayers.WMS.getFullRequestString class member function
OpenLayers.Layer.WMS.prototype.getFullRequestString = function(newParams,
altUrl) {
var projectionCode = this.map.getProjection();
var value = (projectionCode == "none") ? null : projectionCode
if (this.options.sphericalmercatoralias)
{
if(value == 'EPSG:900913' || value == 'EPSG:102113' || value
==
'EPSG:3857') {
value = this.options.sphericalmercatoralias;
}
}
if (parseFloat(this.params.VERSION) >= 1.3) {
this.params.CRS = value;
} else {
this.params.SRS = value;
}

return
OpenLayers.Layer.Grid.prototype.getFullRequestString.apply(this,
arguments);
}

After this override, you can set a new layeroption 'sphericalmercatoralias'
to tell OpenLayers to use that instead of the default as follows:

layer = new OpenLayers.Layer.WMS(title, url, {layers: layernames},
{sphericalmercatoralias: "EPSG:102113"});

--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/SphericalMercator-and-SRS-aliases-eps
g-900913-epsg-3857-epsg-3785-epsg-102113-tp5311417p5334827.html
Sent from the OpenLayers Users mailing list archive at Nabble.com.
_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe. Hello Arnd,

An option named "sphericalmercatoralias" is indeed very specific to
sphericalmercator.
Maybe, an option named "projection" is not specific enough. Users could
think that such an option would somehow magically allow reprojecting the
overlay projection to the map projection. Things would get mixed up, when
sending bounding box coordinates using the wrong projection.
So maybe an option named "projectionalias" would be a better name than
"sphericalmercatoralias" or "projection"?
"projectionalias" stresses the fact that the projection itself should not be
different, just the code that is being used for the projection.

Anne

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/SphericalMercator-and-SRS-aliases-epsg-900913-epsg-3857-epsg-3785-epsg-102113-tp5311417p5336039.html
Sent from the OpenLayers Users mailing list archive at Nabble.com.
_______________________________________________
___________________________________________________

Posted on the Users mailing list. Go to http://openlayers.org/mailman/listinfo/users to subscribe.

#14

26-07-2010 07:12 AM

Users member admin is online now

User

#15

26-07-2010 01:13 PM

Users member admin is online now

User

#16

27-07-2010 08:05 AM

Users member admin is online now

User

#17

27-07-2010 01:25 PM

Users member admin is online now

User

#18

27-07-2010 01:29 PM

Users member admin is online now

User

#19

27-07-2010 02:00 PM

Users member admin is online now

User

Page 1 of 1

NewsArc Lists | Culture Pages | Computing Archive | Media-Pages

Link to this page on your blog or website by copying the HTML code below and pasting it into your site:

Next Thread »