Scale and ScaleLine in Google approx double correct figure at some res'ns

[CharlesHarrison]

I first noticed this checking out my own work.

I have a test satellite alignment calculator page that draws in the correct azimuth on two maps side by side, a Google map and a UK Ordnance Survey map. In order to check the maps against each other, I have been following the lines out 5-10km or so and then comparing their distances to a landmark. By this means, I have been able to establish that the lines agree to the order of 1-1.5 10,000ths degree, easily good enough for purpose.

However, I had one puzzling anomalous result, approximately double that, and then I noticed the Google scale was just plain unrealistic. You can recreate this by going to ...

 http://www.macfh.co.uk/Test/SatelliteCalculator.html

... entering Latitude 58.15009, Longitude -5.24076, Sat 28.2E (the default) and Calculate UK Grid Variance. Then press Submit, and go out 10.3km to Loch a Mhadail.

Here's what you should see:

 http://www.macfh.co.uk/Test/GoogleScales.png

The loch is shaped roughly like an upside down fat T, and according to my OS hardcopy the distance across the base is 850m. The OS on-line map and scale make it about 860m (my hardcopy is 20 years old, so it could be that now, and I'll buy that), but the Google map and scale make it about 1.63km! Further, the two images of the loch are about the same size, yet the written Google scale reads 1:27K and the written OS one 1:14K!

[CharlesHarrison]

You can recreate this by going to ...
 http://www.macfh.co.uk/Test/SatelliteCalculator.html

That page has now changed purpose. Please use the live page to demo this bug:

 http://www.macfh.co.uk/JavaJive/AudioVisualTV/SatelliteTV/SatelliteCalculator.html

[crschmidt]

ScaleLine calculations are not geodesic. I'm going to try and fix this as an option for 2.8.

[CharlesHarrison]

Oh look, this is quite interesting - the scale rule (and therefore presumably also the text figure if only it were there) seems to indicate exactly double what it should in Google Maps as well ...

 http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&ie=UTF8&ll=58.080009,-5.131216&spn=0.021647,0.080595&t=h&z=14

Perhaps Google Maps themselves are creating the problem and passing it on to Open Layers?

[CharlesHarrison]

Also started a discussion about this in the Google Maps API group:

 http://groups.google.com/group/Google-Maps-API/browse_thread/thread/adcbe16c2f8e49ae

[CharlesHarrison]

Also now logged as a bug:

 http://code.google.com/p/gmaps-api-issues/issues/detail?id=1185&colspec=ID%20Type%20Status%20Introduced%20Fixed%20Summary%20Stars%20ApiType%20Internal&start=500

[CharlesHarrison]

Well, if you read the Google Maps API thread, now I can't seem to recreate this in Google. Very odd.

However, I've just checked, and it's still happening in OL, so it still needs attention over here.

[crschmidt]

Not going to deal with this in 2.8.

For the record, the reason for this is that all measurements are planar. A solution is to add a 'useGeodesic' option to the scale control, which -- if it can reproject back to lat/lon -- could then do simple math to multiply by sin() or whatever.

[CharlesHarrison]

Ah now that's got me thinking ... these two lines of JavaScript are from the Google Map init on my Satellite Calculator page:

	var scaleL	= new OpenLayers.Control.ScaleLine();
	var mouseP	= new OpenLayers.Control.MousePosition({displayProjection:EPSG4326, separator:"°E, ", suffix:"°N"});

Would it possible to cure the ScaleLine problem by similarly giving the ScaleLine control a suitable displayProjection?

[CharlesHarrison]

Replying to CharlesHarrison:

Would it possible to cure the ScaleLine problem by similarly giving the ScaleLine control a suitable displayProjection?

No, doesn't seem to help :-(

[crschmidt]

Again, this is a known lack of functionality. If you want this functionality, you will need to change the OpenLayers code. The code you want is not written yet.

[pwr]

a simple workaround is to use Google's scaleline instead of OL's:

layer.mapObject.addControl(new GScaleControl());

[theoddbot]

patch to make scaleline behaviour similar to google maps

[AxelBoldt]

Maybe a possible approach to the scale issue is this: display the scale only for zoom levels and latitudes where it isn't misleading, i.e. where all true (geodesic) distances across the map are within say 10% of the distances determined with the displayed scale. We can't visually estimate distances much better than that anyway. I believe maps in atlases handle it this way.

[jan]

Not only the scale is wrong, but also the resolution. I want to create a map of all the trees in a park, but all the trees are too small because the resolution is wrong. This is a very annoying bug!

[CharlesHarrison]

I've not has a chance to test the attachment, but I've discovered some other things about the scaleline control that it would be good to fix:

1) Where the top text = 1000m, make it read 1km to stop it wrapping. If further it would be possible to prevent 100km and above wrapping, say by using smaller print, that would be even better, but I would guess use of such large area maps would be quite rare anyway, and the need for a scale on them even rarer. However the wrapping 1000m is a significant eyesore, and easy to fix.

2) Make the scale lines be black with a white border so that they show up better against a wider variety of backgrounds, like the Google ones.

[ahocevar]

The above patch adds a geodesic option to the ScaleLine control, which has the same effect as the geodesic option for the Measure control: it switches to geodesic measurement mode, resulting in much better accuracy for maps in Spherical Mercator projection.

The patch comes with an acceptance test which shows the expected behavior.

Tests still pass in FF3.6. Please review.

[bartvde]

Looks good Andreas, please commit.

[ahocevar]

(In [10110]) Give the ScaleLine control a geodesic option. Setting this to true will provide an accurate scale bar in Spherical Mercator maps. r=bartvde (closes #1890)

[CharlesHarrison]

Replying to ahocevar:

(In [10110]) Give the ScaleLine control a geodesic option. Setting this to true will provide an accurate scale bar in Spherical Mercator maps. r=bartvde (closes #1890)

The bug report originally detailed both the Scale and the Scaleline as being incorrect, but only the Scaleline has been fixed.

Also, shouldn't the geodesic option either be on by default (in the following example, the UK Ordnance Survey projection has this option set unnecessarily, but regardless of the setting the Scaleline is unaltered, suggesting that it would be safe to set it by default), or shouldn't it be set on automatically if the projection warrants it? Leaving it unset is a user bug just waiting to happen. When wouldn't you want this option set?

See new demo:

 http://www.macfh.co.uk/Test/GoogleOLScales.html

[ahocevar]

See http://openlayers.org/pipermail/users/2010-April/017532.html for a proposal to modify OpenLayers.INCHES_PER_UNIT based on the latitude.

[CharlesHarrison]

Replying to ahocevar:

See http://openlayers.org/pipermail/users/2010-April/017532.html for a proposal to modify OpenLayers.INCHES_PER_UNIT based on the latitude.

Is it only me that thinks this suggestion the dumbest thing I've heard in quite a while? OL.INCHES_PER_UNIT is a fundamental unit of the system as a whole, and changing it for the benefit of one broken component merely breaks everything else. It's taking an error in one part of the system and applying it everywhere! It's the tail wagging the dog.

It also breaks encapsulation and is fundamentally unsound. See the following discussion concerning how to set about mending the already broken encapsulation of OL. The problems described there are exactly what results when people with no real understanding of OOP apply ill-considered botches of this nature.

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

For example, what about distances NS as opposed to WE? Wouldn't they need to change by different amounts? What if layers in different projections are superimposed over each other? The one in a 'true' projection will no longer be able to calculate distances properly, just as currently the one in the 'oddball' projection can't!

[ahocevar]

@CharlesHarrison: easy man. I just posted the list archive link for reference, because it may lead to ideas for an appropriate fix. Using a system constant for something that is used in a map instance is of course stupid -- but providing a unit reference per se is not so stupid.

On a side note, displaying a scale or scale line on a projected map that shows the whole world is a stupid thing in the first place, but people are used to it. Projections either reliably keep areas or angles, but never distances.

In general, at least in the open source world, helping make a better software at least by providing ideas is better than just complaining.

[ahocevar]

@CharlesHarrison: to me the hint with the INCHES_PER_UNIT led to the idea of a map based, geodesic unit reference, which was very valuable in creating a patch that also made it easy to introduce a geodesic option to the Scale control.

[ahocevar]

@CharlesHarrison: there is more work needed on the above patch - it needs unit tests, an example, and probably better documentation. Feel free to chime in and make it ready for review.

[ahocevar]

Note: the above patch also adds a behavior change to the ScaleLine control: it now does the geodesic measurement in W-E instead of N-S direction. To make this work at the poles in non-polar projections, I convert a zero result of the measurement to a very small number, otherwise we would get NaN scales at the poles.

[bartvde]

Andreas, the patch seems to be incomplete, i.e. misses the Map.js part? Also, the Measure Control would need to be adapted as well.

[ahocevar]

this time with missing Map.js patch

[ahocevar]

Bart, the above patch comes with the Map.js changes. But why would the Measure Control need to be adapted? It has a geodesic option already.

[bartvde]

I thought the Measure control could use the stuff from Map.js, but maybe I am wrong :-)

[CharlesHarrison]

Replying to by ahocevar (and others):

@CharlesHarrison: easy man. I just posted the list archive link for reference, because it may lead to ideas for an appropriate fix. Using a system constant for something that is used in a map instance is of course stupid

If the original suggestion was stupid, doesn't that make posting a link to it no less stupid? Why then are you surprised at my very natural reaction?

but providing a unit reference per se is not so stupid.

It depends at what level it is applied. At the map instance level, which is what my reply assumed, it is as stupid as I pointed out, but at the layer instance level, perhaps not, though I still think there'd be an issue between NS and EW.

On a side note, displaying a scale or scale line on a projected map that shows the whole world is a stupid thing in the first place, but people are used to it. Projections either reliably keep areas or angles, but never distances.

True, but most maps use the scale and scaleline for short distances over small areas. I was always taught that a map without a scale and a graph without axis labels were both meaningless.

In general, at least in the open source world, helping make a better software at least by providing ideas is better than just complaining.

See above.

@CharlesHarrison: there is more work needed on the above patch - it needs unit tests, an example, and probably better documentation. Feel free to chime in and make it ready for review.

I have no facilities on my PC to test anything that is not at least in trunk, nor do I wish to acquire such facilities. I wish to put in my dwindling remaining time on this earth on my work, not someone else's.

However, the demo I linked uses trunk, so once a patch gets that far, it can be tested with the demo.

I thought the Measure control could use the stuff from Map.js, but maybe I am wrong

Shouldn't controls have a system of finding out what they need to do from the baselayer they're representing, instead of relying on the map programmer to remember to set the geodesic option, and to change it appropriately when and if the baselayer changes?

[bartvde]

@CharlesHarrison please keep in mind that fixing bugs, helping people or adding features in OpenLayers is sometimes a non-paid job, that a programmer does in its spare time. Please have a bit of respect for this! Thanks in advance. I really miss this respect in some of your postings.

OpenLayers is not a proprietary product where you have paid a support fee and hence have some rights when finding issues, and even in those proprietary cases there are many situations where you won't find any good help at all, other than this might be fixed in the next version if you're lucky.

[CharlesHarrison]

Replying to bartvde:

@CharlesHarrison please keep in mind that fixing bugs, helping people or adding features in OpenLayers is sometimes a non-paid job, that a programmer does in its spare time. Please have a bit of respect for this!

Such comments really have no place in a bug report, but as you seem to want to go down this road ...

Just because something is not-for-profit doesn't mean it is or even should be beyond criticism. If an individual or organisation is not prepared to listen to criticism, then (s)he or it will never improve. There is a certain unrealistic 'preciousness' of too many people in general, and some in Open Source software in particular, who are surprised and upset when others find fault with their work, when really it's a predictable sequence of events which they should expect, to which they should adjust, and from which they should learn to benefit.

Whether the people who created it choose to consider OL as such or not, the vast majority of outsiders will regard it as a service; in effect, it became such the moment it was first published. As such, although like most users I am prepared for some give and take in unpaid Open Source software development, ultimately I expect it to work, and when it doesn't, I expect it to be fixed, not to be told or invited to fix it myself.

In an exact analogy, I have created a fairly sizeable website which has never earned me a penny. It's taken many man hours, well years really, of my life. Nevertheless, I expect that my visitors will expect it to work, and if through some misfortune, or mistake on my part, something doesn't, I certainly don't have unrealistic expectations that they will be prepared to spend significant amounts of their time benefiting my site by trying to find out why something doesn't work.

Thanks in advance. I really miss this respect in some of your postings.

I note that I haven't made any disrespectful remarks about any individual.

OpenLayers is not a proprietary product where you have paid a support fee and hence have some rights when finding issues, and even in those proprietary cases there are many situations where you won't find any good help at all, other than this might be fixed in the next version if you're lucky.

See above.

[crschmidt]

CharlesHarrison:

There is a difference between criticism, and disrespect. Many of your posts cross the line.

"Is it only me that thinks this suggestion the dumbest thing I've heard in quite a while?" "The problems described there are exactly what results when people with no real understanding of OOP apply ill-considered botches of this nature."

Both of these comments in this ticket are disrespectful ways of stating your opinion. Describing suggestions as "dumbest thing I've heard" and ad-hominem attacks on developers of a project are both directly disrespectful. In addition to causing developers to, generally speaking, simply be unable to respond in any useful way to your posts, these types of comments are disrespectful to the project. I would feel the same way if the developers were paid full time, or even if there were no longer any developers: these types of comments and attacks are simply not welcome in a public forum.

If you'd like to insult the OpenLayers developers, please feel free to do so elsewhere. The project bug tracker is not an appropriate place to do so. In general, the type of argument you seem to feel is valid criticism would not be welcome in any public forum I seek to maintain.

Criticism of OpenLayers is good; many of the developers criticize aspects of the project regularly. But there is a difference between criticism and disrespect, towards either developers or the project as a whole. The latter -- despite your personal feelings -- is evident in at least some of your posts, if not many. The general flavor of your comments has always tended to "The only kind of person who would develop this solution has no idea what they are doing". While I understand that feeling, that type of response is not welcome here; there are a number of people working to do their best, and criticism of the results is welcome -- criticism of the people is not.

"Ultimately I expect it to work, and when it doesn't, I expect it to be fixed, not to be told or invited to fix it myself."

If this is the case, then your expectations are misplaced. You can expect it to *do* whatever you like -- but when it doesn't, there is no person, inside or outside the project, who can be expected to change that situation. If you'd like it to work, you are welcome to make it work; if you are not interested in such, then you will simply need to deal with the fact that it doesn't work.

This is not to say that I expect you to make it work. I don't. Instead, I expect that you will understand it doesn't work, and that's that. Filing bugs is a great way to contribute, but not necessary. Applying fixes and testing them is welcome if you are interested in doing so, but not necessary. However, at no point in the process should you let an expectation that something should work cross the line into believing that it is the responsibility of some person -- or even the project -- to *make* it work.

Your desires are fine, but your expectations are wrong. It works or it doesn't work; you can fix it or not fix it; but no matter what you do, your tone -- and specifically attacking developers, or their work, in the way that you are or have been, is inappropriate.

Best Regards, Christopher Schmidt OpenLayers Developer

[CharlesHarrison]

Replying to crschmidt:

CharlesHarrison: There is a difference between criticism, and disrespect. Many of your posts cross the line. "Is it only me that thinks this suggestion the dumbest thing I've heard in quite a while?"

Apparently the person I was replying to at least half agrees with me:
ahocevar: "Using a system constant for something that is used in a map instance is of course stupid"

"The problems described there are exactly what results when people with no real understanding of OOP apply ill-considered botches of this nature."

This names no individual, and is not an unreasonable summary of the problems of broken encapsulation described in that thread, and how they almost certainly came about. It is simply calling a spade a spade.

As for the rest, we've disagreed in the past about the nature of Open Source development and the differing expectations of those who create as opposed to those that merely use. I merely repeat that I think you'll find that in the wider world, my views are closer to the majority's than your own.

However, I see no point in hammering it out all over again. If it would help, I would be quite happy for all remarks that people rightly or wrongly find contentious to be removed from the bug thread, and hereby give my permission for my posts to be edited or removed appropriately, as long as substance useful to the bug is not lost, and as long as others' replies are given equal treatment.

If people really must continue the discussion, although I'm really not very interested, it would be more appropriate to do so through pm. I can be contacted via here:

 http://www.macfh.co.uk/JavaJive/Contact.html

Now I suggest we return to the bug.

[ahocevar]

Replying to CharlesHarrison:

Now I suggest we return to the bug.

Fine. attachment:openlayers-1890-reopened.2.patch fixes remaining issues with the ScaleLine, and adds a geodesic option to Scale. The geodesic option for both is set to false by default, because otherwise we would introduce an behavioral change which would break our promise of API stability throughout a major release.

The patch has no unit tests and no examples yet. I have no time right now to add these, but I might change my mind if a rainy weekend and a donation to my paypal account coincide. People with the desire for this patch to go into trunk without having to make their coding hands dirty may contact me per pm to get my paypal account details. I reserve the right to either by myself a couple of beers with the donated money, or pass the donation to a charity of my choice.

[CharlesHarrison]

Replying to ahocevar:

attachment:openlayers-1890-reopened.2.patch fixes remaining issues with the ScaleLine, and adds a geodesic option to Scale.

Thanks for your work on this. Although it may not be the impression you have gained, I do appreciate your efforts.

The geodesic option for both is set to false by default, because otherwise we would introduce an behavioral change which would break our promise of API stability throughout a major release.

Yes, I can see that this is important. Perhaps the behaviour of such controls ought to reviewed with a view to optimisation and standardisation for the next major release.

The patch has no unit tests and no examples yet. I have no time right now to add these, but I might change my mind if a rainy weekend and a donation to my paypal account coincide. People with the desire for this patch to go into trunk without having to make their coding hands dirty may contact me per pm to get my paypal account details. I reserve the right to either by myself a couple of beers with the donated money, or pass the donation to a charity of my choice.

As I've been too ill to work for some years now, I'm afraid no donation will forthcoming from this direction, but good luck with that anyway :-)

[ahocevar]

Closing this ticket, because the remaining issue is covered by #2600.