<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">I do think it is a good idea, however, to fix the scalebar if it is wrong.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Cheers</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Paul</div> <div id="bloop_sign_1394197591591793152" class="bloop_sign"><span style="font-family:helvetica,arial;font-size:13px"></span>-- <br>Paul Spencer<br><span>Sent with Airmail</span></div> <div style="color:black"><br>From: <span style="color:black">Thomas Bonfort</span> <a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a><br>Reply: <span style="color:black">Thomas Bonfort</span> <a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a><br>Date: <span style="color:black">March 7, 2014 at 4:44:28 AM</span><br>To: <span style="color:black">Tamas Szekeres</span> <a href="mailto:szekerest@gmail.com">szekerest@gmail.com</a><br>Cc: <span style="color:black">mapserver-dev@lists.osgeo.org</span> <a href="mailto:mapserver-dev@lists.osgeo.org">mapserver-dev@lists.osgeo.org</a><br>Subject: <span style="color:black"> Re: [mapserver-dev] Regarding to the scale calculation in MapServer <br></span></div><br> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>

<br>

<br>On 07/03/2014 10:33, Tamas Szekeres wrote:

<br>> Thomas,

<br>>  

<br>> It is indeed a problem that the scale may vary across a given view, but

<br>> 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?

<br>

<br>> It would

<br>> me more reasonable to use something like what Paul is mentioning with the great

> circle distance calculation.

<br>If this is going to be used for the scalebar computation, I'm fine with

<br>that. For the scaledenom calculation given a map request, the calculated

<br>scale for a (Wi,Hi) pixels image of extent size (We,He) should remain

<br>strictly identical for a given Wi,Hi,We,He,units , whatever the actual

<br>longitude/latitude values where used to compute We and He, for the

reasons I explained in my previous email.

<br>

<br>--

<br>thomas

<br>

<br>>  

<br>> Best regards,

<br>>  

<br>> Tamas

<br>>  

<br>>  

<br>>  

<br>> 2014-03-07 10:19 GMT+01:00 Thomas Bonfort <thomas.bonfort@gmail.com>:

<br>>  

<br>>> Tamas,

<br>>> Adding to what Paul said about the need to maintain a list of

<br>>> projections with their respective deformations (which can be dependant

<br>>> of longitude also, not only latitude), introducing extent based scale

<br>>> calculation also implies that your map rendering may change drastically

<br>>> (by switching from one scale-delimited layer to the next) by just having

<br>>> the user do a 1-pixel pan in the vertical direction. This would also be

<br>>> incompatible with any tiling software as the content of a given tile

<br>>> will depend on many external factors (the size of a metatile being one)

>> and will therefore not be consistent with a neighboring tile.

<br>>>

<br>>> 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?

<br>>>

<br>>> Maybe you can work-around your specific need by having a scale

<br>>> computation function given a projection, size and extent, and then using

>> that programmatically to select which layers/styles you need.

<br>>> 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).

<br>>>

<br>>> Best regards,

<br>>> thomas

<br>>>

<br>>> On 06/03/2014 16:49, Tamas Szekeres wrote:

<br>>>> Hi Devs,

<br>>>>

<br>>>> As far as I know certain projections require to modify the scale

<br>>> regarding

<br>>>> to the latitude of the given view. For latlong and AFAIK for the web

<br>>>> mercator (ie EPSG:3857, EPSG:900913) we might require to use

<br>>> cos(latitude)

>>> as the correction factor.

<br>>>>

<br>>>> With the current mapserver code, I don't see how this requirement is

<br>>> taken

<br>>>> into account. For the units=MS_DD, I can see the following code fragment

<br>>> in

<br>>>> the code in msInchesPerUnits (though this is not compiled in by default)

<br>>>>

<br>>>> #ifdef ENABLE_VARIABLE_INCHES_PER_DEGREE

<br>>>>       if (center_lat != 0.0) {

<br>>>>         double cos_lat;

<br>>>>         cos_lat = cos(MS_PI*center_lat/180.0);

<br>>>>         lat_adj = sqrt(1+cos_lat*cos_lat)/sqrt(2.0);

<br>>>>       }

<br>>>> #endif

<br>>>>

<br>>>>

<br>>>> Shouldn't the correction be applied for the web mercator

<br>>> (units=MS_METERS)

>>> and probably for futher CRS-s as well?

<br>>>>

<br>>>> Should we anyway have ENABLE_VARIABLE_INCHES_PER_DEGREE defined by

<br>>> default?

<br>>>>

<br>>>> Best regards,

<br>>>>

<br>>>> Tamas

<br>>>>

<br>>>>

<br>>>>

<br>>>> _______________________________________________

<br>>>> mapserver-dev mailing list

<br>>>> mapserver-dev@lists.osgeo.org

<br>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

<br>>>>

<br>>> _______________________________________________

<br>>> mapserver-dev mailing list

<br>>> mapserver-dev@lists.osgeo.org

<br>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

<br>>>

<br>>  

<br>_______________________________________________

<br>mapserver-dev mailing list

<br>mapserver-dev@lists.osgeo.org

<br>http://lists.osgeo.org/mailman/listinfo/mapserver-dev

<br></div></div></span></blockquote></body></html>