[mapserver-dev] Regarding to the scale calculation in MapServer

Fri Mar 7 05:32:07 PST 2014

Hi,

Even at out latitudes (60-70 degrees N) the ground scale with EPSG:4326 and EPSG:3857 are notably different in South-North and West-East directions. I have been thinking sometimes that a vector-like scalebars could be nice for such situation. Typewriter graphics below hopefully helps to catch what I mean.

^
| S-N scalebar
|
|------------------------>
W-E scalebar

-Jukka Rahkonen-

Paul Spencer wrote:

I agree with Thomas that the existing calculation of scaledenom should not be changed for the reasons he mentioned and also because there are a vast number of existing mapfiles out there that rely on the current scale calculations for rendering.

I do think it is a good idea, however, to fix the scalebar if it is wrong.

I also think it might be worth adding something to return the ground scale, perhaps msGroundScale()? which would return the scale denominator for the current ground scale at the center of the map as drawn.  This would probably be used by the scalebar and exposed via mapscript.  I don't see it being a useful keyword in a mapfile.

Cheers

Paul
--
Paul Spencer
Sent with Airmail

From: Thomas Bonfort thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>
Reply: Thomas Bonfort thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>
Date: March 7, 2014 at 4:44:28 AM
To: Tamas Szekeres szekerest at gmail.com<mailto:szekerest at gmail.com>
Cc: mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org> mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
Subject:  Re: [mapserver-dev] Regarding to the scale calculation in MapServer

On 07/03/2014 10:33, Tamas Szekeres wrote:
> Thomas,
>
> It is indeed a problem that the scale may vary across a given view, but
> with the current approach in most cases the reported scale is not falling
> between the minimum and the maximum, which seems to be incorrect.
I don't understand that part (minimum, maximum), can you be more precise?

> It would
> me more reasonable to use something like what Paul is mentioning with the great
> circle distance calculation.
If this is going to be used for the scalebar computation, I'm fine with
that. For the scaledenom calculation given a map request, the calculated
scale for a (Wi,Hi) pixels image of extent size (We,He) should remain
strictly identical for a given Wi,Hi,We,He,units , whatever the actual
longitude/latitude values where used to compute We and He, for the
reasons I explained in my previous email.

--
thomas

>
> Best regards,
>
> Tamas
>
>
>
> 2014-03-07 10:19 GMT+01:00 Thomas Bonfort <thomas.bonfort at gmail.com<mailto:thomas.bonfort at gmail.com>>:
>
>> Tamas,
>> Adding to what Paul said about the need to maintain a list of
>> projections with their respective deformations (which can be dependant
>> of longitude also, not only latitude), introducing extent based scale
>> calculation also implies that your map rendering may change drastically
>> (by switching from one scale-delimited layer to the next) by just having
>> the user do a 1-pixel pan in the vertical direction. This would also be
>> incompatible with any tiling software as the content of a given tile
>> will depend on many external factors (the size of a metatile being one)
>> and will therefore not be consistent with a neighboring tile.
>>
>> If you went that way, how would you account for the fact that the scale
>> at the top of an image is different from the scale at the bottom of it?
>>
>> Maybe you can work-around your specific need by having a scale
>> computation function given a projection, size and extent, and then using
>> that programmatically to select which layers/styles you need.
>> But in terms of the scaledenom usage in mapserver, it should stay as it
>> is now (and ENABLE_VARIABLE_INCHES_PER_DEGREE left disabled by default).
>>
>> Best regards,
>> thomas
>>
>> On 06/03/2014 16:49, Tamas Szekeres wrote:
>>> Hi Devs,
>>>
>>> As far as I know certain projections require to modify the scale
>> regarding
>>> to the latitude of the given view. For latlong and AFAIK for the web
>>> mercator (ie EPSG:3857, EPSG:900913) we might require to use
>> cos(latitude)
>>> as the correction factor.
>>>
>>> With the current mapserver code, I don't see how this requirement is
>> taken
>>> into account. For the units=MS_DD, I can see the following code fragment
>> in
>>> the code in msInchesPerUnits (though this is not compiled in by default)
>>>
>>> #ifdef ENABLE_VARIABLE_INCHES_PER_DEGREE
>>> if (center_lat != 0.0) {
>>> double cos_lat;
>>> cos_lat = cos(MS_PI*center_lat/180.0);
>>> lat_adj = sqrt(1+cos_lat*cos_lat)/sqrt(2.0);
>>> }
>>> #endif
>>>
>>>
>>> Shouldn't the correction be applied for the web mercator
>> (units=MS_METERS)
>>> and probably for futher CRS-s as well?
>>>
>>> Should we anyway have ENABLE_VARIABLE_INCHES_PER_DEGREE defined by
>> default?
>>>
>>> Best regards,
>>>
>>> Tamas
>>>
>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org<mailto:mapserver-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/mapserver-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140307/cdf9a1d8/attachment-0001.html>