Improve scale calculation for maps in geographic coordinates

I have implemented a msInchersPerUnit(int unit, double center_lat) that adjusts 
the inches per unit value for DD according to the center latitude parameter that 
is provided (using a cos() call as described above).  For all other unit types 
this center_lat has no effect.

This is committed to CVS, and all places in the code that used to refer to 
'extern inchesPerUnit[]' have been modified to call msInchesPerUnit() with a 
center_lat of 0 instead.

Before I can mark this fixed, I need to review all places where 
msInchesPerUnit() is used, and if applicable then pass a valid valud for 
center_lat.

I'm starting to wonder whether doing this was a good idea or not.  What worries 
me is that as you pan north on a map in lat/lon then some layers may turn on or 
off since the scale value will change internally.  This behavior may not be what 
users want to see happening.

What do you think Steve, should we remove that change and stick with a fixed 
value for the number of inches per degree?

I have disabled this feature for now using an #ifdef 
ENABLE_VARIABLE_INCHES_PER_DEGREE since there are potential side-effects of this 
that I had not initially thought about, such as the pan issue that I mentioned 
in comment #2 above.  I'll have to revisit this when I have time... in the 
meantime, comments, or votes for/against this feature are welcome. 

Daniel, the fact that you call msInchesPerUnit with a 0 latitude, even in 
cases when the latitude is known (such as from setExtent in maptemplate.h) 
causes some layers to turn on or off as you move north or south. I personally 
think using the real (well, a value close to it) scale, based on the center 
latitude would solve this, especially when using external sources that 
calculate their own scale from your extents. Those will use a different value 
since they will adjust for different latitudes. IMHO using the actual latitude 
should be the way to go with this.

I don't like the variable inches/degree option for exactly the reason Daniel 
outlines in comment #3. My opinion is that allowing users to set their own 
fixed value appropriate for the region they are working is a reasonable 
solution. That will at least get them decent scalebars for large scale maps.

Steve

In reply to comment #4 from Jerry, I would think that it's the contrary: if you
pass the correct latitude value to msInchesPerUnit() then the scale value will
change as you pan north or south and you will get the effect that you described.
However, in the current situation (always passing 0) then the scale never
changes as you pan north/south and there is no problem with layers going on/off
unexpectedly. (Or did I miss something?)

In comment #5, Steve proposed that we let users set their own fixed latitude
value appropriate for the area they're working on... this would have the benefit
of giving more accurate scale bars for projects dealing with relatively small
study areas (city or state level), without the side-effect of having a scale
that changes as you pan north/south.

How do you think this should be implemented Steve? Should we add a new keyword,
or perhaps a processing directive? Either way, the value could be either a
latitude value or the keyword "AUTO", with the default being a fixed value of 0
(current bahavior). If one uses AUTO, then MapServer would always use the center
of the current map->extent as the latitude when available, which would lead to
the layers turning on and off behavior that Jerry described, but some users may
still want that.

We are requesting layers from thrid parties that do adjust for latitude, 
that's why I am having the prblem with some of them not being displayed 
depending on the map's location. As for a fix - it's a compile time option, to 
turn it on you need to explicitly define ENABLE_VARIABLE_INCHES_PER_DEGREE. If 
users don't want this adjustment they don't need to do anything, even if we 
fix this. However users that do want this functionality are currently being 
disappointed since defining that directive does actually have the effect it 
promises. That to me is a bug we should fix. In the end it will be up to the 
user to turn it on, we shoudl just make sure that it works if they do.

I don't think the compile-time directive is enough, it was just there as a
temporary measure and we should get rid of it. The problem with the compile
directive is that in this case, it does not just enable an option, it
significantly changes the behavior of the software. We've got too many
compile-time directives anyway that we are trying to get rid of.

So I'm back to my question of whether we should use a PROCESSING directive or a
new mapfile keyword. The PROCESSING directive may be simpler to implement but
may be slow to test at runtime, so perhaps the mapfile parameter would be best,
we'd have to see.

I think this needs to be a run-time, not a compile-time change. One option 
would be to extend the UNITS parameter to optionally take a conversion factor 
as a second argument being a conversion factor:

  UNITS DD xxx

That works ok for interfaces with a hand-rolled mapfile. The folks in MapScript-
land would have to access a second parameter behind the scenes if they were 
building a mapfile from scratch. So I guess a new parameter would be the way to 
go, although I hate adding one for such a specialized purpose.

Would there then be a function to turn a central latitude into a the correct 
number of inches/unit?

Steve