Talk:Web Mercator projection
This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
Reworking
[edit]This article needs a lot of work.
- “Web Mercator is a mathematically flawed version”: WP:POV violation, no source, no reasonable theory by which this could be meaningful.
- “It drops a term from the ellipsoidal Mercator equations…”: That’s not at all what it does. Down in Web Mercator#Formulas section, some partial derivatives for the ellipsoidal Mercator are given (instead of the actual formulas), and states that Google Maps drops the e term. It doesn’t “drop” it; it uses 0 for the projection. Meanwhile the derivatives are irrelevant, and what are alleged to be the formulas for the projection are not.
- “Web Mercator uses the formulæ for the spherical Mercator, but it uses the semi-major axis of the WGS 84 datum as the radius of the sphere. The difference between this sphere and the WGS 84 ellipsoid causes the resultant projection not to be precisely conformal.” This is flat-out wrong. The radius of the sphere has nothing to do with conformality. The only reason the projection is “not conformal” is because geodetic coordinates are treated as spherical coordinates. Meanwhile all whole-world projections do this because spherical coordinates are not available because there is no such thing as surveys based on spherical coordinates. People could convert geodetic coordinates to spherical coordinates for use in small-scale projections, but no one bothers to because the discrepancies are too tiny to matter at those scales.
- “Compared to the standard Mercator, Web Mercator is not conformal due to use of spherical coordinates”: Without more precise phrasing, this is wrong, too. What does “standard Mercator” here refer to? Ellipsoidal or spherical?
- The article claims, …spherical Mercator which uses a sphere with an average Earth radius, but that is wrong. Mercator is a projection, not a projection+datum. You can use any sphere you want with it.
I have made extensive corrections. Comments welcome. Thanks. Strebe (talk) 08:47, 15 February 2015 (UTC)
- Hi Strebe. Thanks for doing this! I don't really have a GIS or cartography background so I did the best I could to try to understand the topic better. I'm still confused about a few things:
- Are 3857 and 3785 the same thing or not?
- What does the "spherical development of ellipsoidal coordinates" bit actually mean? I added these quotes but I don't actually understand them. Any chance of another sentence or two explaining exactly what that means and why it matters? Stevage 05:51, 3 March 2015 (UTC)
- Sorry; I thought I answered this long ago but apparently I did not save my response properly. No, 3857 and 3785 differ as described. “Spherical development of ellipsoidal coordinates” means that the coordinates of locations on the earth assume an ellipsoidal model, since surveys are always against the ellipsoid. But if you project the earth as a sphere, then you introduce error due to the mismatch between the datum of the coordinates and the datum of the projection. If you want to use the sphere as your projection datum then you can convert the ellipsoidal coordinates to spherical coordinates. That’s pointless if the projection is small scale. If it’s large scale, though, then the discrepancy is noticeable. That’s a big reason why the Web Mercator receives so much flack. While historically it’s completely normal to use spherical projections for small scale maps even though the geographical data are given in geodetic (instead of spherical) coordinates, the Web Mercator retains this practice all the way down to large scale maps. That is an aberration. Technically the practice amounts to a different projection than standard Mercator usage. If you understood this explanation, and have ideas about how to convey it cleanly and concisely in the text, feel free. Strebe (talk) 22:50, 29 March 2015 (UTC)
35 km ground error?
[edit]- I have a concern with the last sentence in the first paragraph under "Properties" - which is - "This deviation becomes more pronounced further from the equator, and can reach as high as 35 km on the ground.[3]" I do not believe the sentence is a correct statement. And I do not believe it reflects what Alastair Aitchison presented in his article "The Google Maps / Bing Maps Spherical Mercator Projection" [1]. Alastair Aitchison presented (among many other things) the mistakes users make in creating the Web Mercator projection from the WGS84 ellipsoid. I believe the article clearly states that when the EPSG:3875 specification is appropriately implemented - then an accurate representation of the WGS84 ellipsoid can be presented in the Web Mercator projection (understanding no 2D projection is accurately defines a 3D realm in all ways).
- Example - A user with a smart phone on google maps (Web Mercator projection) who wants to meet a friend at the entrance to a bar in northern England - zooms into the location on the mapping APP, places the cursor on the sidewalk in front of the bar, and uses the map engine within the APP to convert the X&Y coordinates of the 2D projection into the WGS84 ellipsoid latitude and longitude (using the equations found in EPSG:3875). The user then emails the latitude and longitude to his friend - who happens to be using a Mercator projection mapping application (which I believe would have been created in accordance with EPSG:3395). The user inserts the latitude and longitude provided from the Web Mercator projection into the Mercator projection mapping device and the mapping engine of the device converts the latitude and longitude in accordance with the Mercator EPSG specifications which yields an X&Y location. The user zooms into Mercator projection and - the cursor is sitting on the sidewalk in front of the bar the friend desires to meet at. There is no 35 km deviation on the ground... It is important to recall Y values for the Web Mercator and Mercator projections for the bar location are not the same. The X values will be the same as both projections use the same mathematical conversion of the WGS84 longitude into values of X. The Y values will be slightly different as the projections use different equations for the conversion of the WGS84 latitude to values of Y. This is not an error. An uniformed user who attempts to combine the two projections on the same X&Y plane may end up having a 35 km "error" - but that error is the fault of the user. There are ample examples on the web demonstrating the Web Mercator projection yields the correct WGS84 latitude and longitude for a known location on the ground. One example is at the first external link I have provided below.
- The deviation discussed in the last sentence of the first paragraph of under the "Properties" section is actually referencing the stretching in the Y direction which occurs in both projections as one moves away from the equator. The Web Mercator stretches slightly more than the Mercator projection as the equation producing the value of Y in the Web Mercator projection uses the equatorial diameter (twice the semi major axis) of the WGS84 ellipsoid in the calculation of Y. The polar diameter is actually about 43KM shorter than the WGS84 equatorial diameter. The Mercator projection does not stretch as much in the Y direction as the Mercator equation for Y uses the shorter polar diameter of the WGS84 ellipsoid. Thus - if a user were to lay both projections on the same X&Y plane - the Web Mercator projection would have a greater value of Y (say at the entrance to the above bar in Northern England) than the Mercator projection. However, this is not an error. Both projections yield the correct WGS84 ellipsoidal latitude and longitude from the equations associated with each projection. There is not 32 km deviation on the ground. An example of two different conformal map projections of the continental United States is at the second external link I provide below. They are each centered at a given coordinate - but are offset in X Y due to the different equations used in the creation of the projections. These offsets are not errors - they are expected.
- I believe if the stretching in the Y direction is to be discussed under properties - perhaps the following would be possible -
- "Both the Mercator and Web Mercator projections stretch or distort scale in the Y direction as one moves away from the equator. The Web Mercator projection stretches slightly more in the Y direction than the Mercator projection (at any location not on the equator) due to the Web Mercator projection's use of the WGS84's ellipsoid equatorial diameter in the calculation of Y. The Mercator projection uses the actual (and slightly shorter) WGS84's ellipsoidal polar diameter in its calculation of Y - resulting in slightly less stretching of the projection in the Y direction for any location not on the equator. The difference in the value of Y's for each projection for the same location on the ground (not on the equator) is not unexpected given each projection uses a different equation for the conversion of the 3D latitude to a two dimensional value of Y. Novices working with map projections need to be continually reminded that mixing two different projections on the same two dimensional coordinate axis is most likely to result in location errors."[1]
- Hello Ebzimmerman. Thanks for moving the conversation here from my Talk page. Yes, the 35_km discrepancy spoken of happens by people mistaking the Web Mercator for the ellipsoidal equatorial Mercator. That’s all this is about, and so I think your proposed explanation is verbose and difficult to parse as an explanation. It is also incomplete; it makes it sound as if the discrepancy is due solely to the difference in polar diameter, but that is not the case. There is also a discrepancy from using different formulas. On my Talk page I proposed this:
However, the Web Mercator uses the spherical formulas at all scales whereas large-scale Mercator maps normally use the ellipsoidal form of the projection. The discrepancy is imperceptible at the global scale but causes maps of local areas to deviate slightly from true ellipsoidal Mercator maps at the same scale. This deviation becomes more pronounced further from the equator, and can reach as high as 35 km on the ground. This causes problems for people who mistake the Web Mercator for a true conformal WGS 84 Mercator projection.
- Please let me know if that satisfies your concerns. Strebe (talk) 07:27, 9 September 2016 (UTC)
- Hello Strebe We are not there yet. You mention "discrepency" in your above response. I do not recall mentioning any discrepency - as I do not believe one has been demonstracted.
- You consider my proposed change verbose. This is a complex subject... I have to say - at your suggestion - I read every word of the article you wrote regarding the positions on the different camps regarding Web Mercator. I thought it was well thought out, objective, and well written essay on the issues surrounding the topic. I ask you to perhaps take a second read of what I have provided you above. :)
- Regarding my verbocity - I suppose I was trying to deal with the language that was already there. Looking at that first paragaph under "Properties" on the current Web Mercator site again - I would take out the last two sentences...
- The proposed change to the first paragraph would be "Web Mercator is a slight variant of the Mercator projection that is used primarily in Web-based mapping programs. It uses the same formulas as the standard Mercator as used for small-scale maps. However, the Web Mercator uses the spherical formulas at all scales whereas large-scale Mercator maps normally use the ellipsoidal form of the projection." That would make it more concise.
- I do not believe anyone, anywhere has demonstrated there is/are location errors from using a properly prepared (EPSG:3875) Web Mercator projection. I believe the same is true from using a properly prepared Mercator projection. Both yield the same WGS84 ellipsoidal latitude and longitude for the center of any road intersection chosen from + or - 85 degrees of latitude (the approximate normal coverage of the projections) The only way you can come up with a 35 km ground difference from Web Mercator compared to Mercator is by either have an incorrectly produced Web Mercator projection or inappropriately combining the two projections together on the same X&Y plane. The deviation you speak of has to do with differences in the mathematical output of the two projections. Quite honestly - mathematically - I don't understand your position that there is a 35 km deviation on the ground. I ask for you to provide one example of how this can happen. Educate me. Respectfully. Ebzimmerman (talk) 12:18, 9 September 2016 (UTC)
- Hello again Ebzimmerman. I have to say I'm confused by your confusion. We already agree that "the problem", such as it exists, is that people mistakenly mix results from the two different projections. They do this because they do not realize that the Web Mercator is a distinct projection from the ellipsoidal Mercator. The confusion that causes people to do that is the whole reason that National Geospatial-Intelligence Agency has proscribed Web Mercator. Hence my proposed edit, rather clearly, I thought, explains where and why the problem arises: "This causes problems for people who mistake the Web Mercator for a true conformal WGS 84 Mercator projection." Nobody has claimed that there is some error in Web Mercator formulation such that you would get 35_km of error in ground-truth as long as you worked entirely within the Web Mercator framework. That is not at all what the text says, nor do I see how the text implies such.
- The "discrepancy" in the text refers to incongruent elements in the preceding sentence: While the Web Mercator's formulas are for the spherical form of the Mercator, geographical coordinates are required to be in the WGS 84 ellipsoidal datum. This discrepency... If the coordinates you feed into the Mercator were coordinates for a spherical datum, then there would be no discrepancy. If the coordinates you feed into the ellipsoidal Mercator were geodetic coordinates for an ellipsoid of the same parameters, then there would also be no discrepancy. However, Web Mercator uses geographic coordinates referenced to an earth-like ellipsoid (WGS 84, where eccentricity ≈ 0.082) while using the mathematics of a spherical model (where eccentricity = 0). At small scales (world maps, entire continents), mixing the models does not result in any discernible problem and is common practice. However, at large scales (i.e., quad topo maps, city maps, etc.) that practice is idiosyncratic and confusing to people who are accustomed to working in a coherent system where the projection mathematics are adapted to the survey datum. As a projection in the purest sense, and wholly within a Web Mercator ecosystem, no, there is no problem. It is just a projection like any other, and as long as you are aware that the datum parameters do not match those given to the projection formula, then of course nothing bad happens. Few people work in just Web Mercator, though, and few people grasp all these nuances. Hence, "the problem".
- If you object to the phrasing This discrepancy... then can I resolve the objection by substituting This idiosyncratic mixing of spherical mathematics with ellipsoidal coordinate data...? Strebe (talk) 16:42, 9 September 2016 (UTC)
- Hello Strebe First of all - want to say I appreciate you staying with me and attempting to clear this up for me. But - as you probably agree - this whole issue of Web Mercator is a clear as mud given the amount of misinformation which has been spread about...
- I suggest you not make any change to the current text at this time. Apparently - given the "clear as mud" status of Web Mercator, the International Association of Oil and Gas Producers (IOGP) is within days of publishing new guidance regarding the EPSG:3857 (I just found this out)... I'll tap my foot until it comes out and re-engage. Have a great weekend... Ebzimmerman (talk) 17:37, 9 September 2016 (UTC)
External links
[edit]Accuracy of Google Maps]
Three Different Map Projections of the United States]
Ebzimmerman (talk) 19:04, 8 September 2016 (UTC)
References
- ^ a b "The Google Maps / Bing Maps Spherical Mercator Projection". Alastair Aitchison. Retrieved 4 October 2014.
Formulas
[edit]One small question/comment under "Formulas": Shouldn't the expression for maximum φ be determined from "φ given y = 0" rather than the current "φ given y = π"? Pbogdude (talk) 19:50, 14 March 2015 (UTC)
- No. y = 0 is the equator, where φ = 0. Strebe (talk) 02:01, 15 March 2015 (UTC)
While y = 0 is the equator for Mercator, that's not the case for Web Mercator. As stated earlier in this section: 'the "world coordinates" are adjusted such that the upper left corner is (0, 0)'. In this case, y=0 corresponds to the upper left corner, where φ reaches its maximum value. The expression for φ_max (third equation in this section) follows from y = 0 in the previous equation. Pbogdude (talk) 01:47, 17 March 2015 (UTC)
- I see where the misunderstanding lies. The "φ given y = π" was intended to mean from the normal Mercator formulas, not the Web Mercator formulas, but that intent was not clear from the text. Since the Web Mercator formula can be used instead, I went ahead and made that change. Strebe (talk) 04:07, 17 March 2015 (UTC)
- There is confusion here as there are two different concepts of x and y coordinates being used without qualification. In a metric sense for EPSG:3857 y = 0 is the equator and North is +ve (as stated in the Advantages and Disadvantages section). In a tiled pyramid sense where one has x,y,zoom the y = 0 axis corresponds to the Northern-most boundary (with South +ve). Similarly x = 0 is -180 W in the tiled sense but x = 0 is the prime meridian for the zoom-agnostic projection.
- This article as it stands is self-contradictory. 2001:E68:540D:3F10:11C4:D75F:64DC:9202 (talk) 03:22, 18 January 2024 (UTC)
Why is not in radian in of the current article ? Kkddkkdd (talk) 15:09, 29 March 2015 (UTC)
- Because coordinates people use are given in degrees. Strebe (talk) 22:39, 29 March 2015 (UTC)
- It seems inconsistent with in the current article. Kkddkkdd (talk) 16:10, 30 March 2015 (UTC)
- Hence the ° symbol for it. Notice that the article talks about 85.051129°. The formula describes how to arrive at that. Meanwhile in general projection formulas are given using radians; otherwise the whole thing just becomes unwieldy. I agree: It’s not ideal, but I’m not sure how to improve it. Do you have suggestions? Strebe (talk) 04:23, 31 March 2015 (UTC)
- doesn't use a good technical notation. My suggestions are as follows:
- , with the additional description of "If the quantity is required not in radian but degree, multiply the right side by ". Kkddkkdd (talk) 14:21, 1 April 2015 (UTC)
- I would also vote for a two-step approach, the formula in radians like all the others, and one in degrees (being user space, so remains relevant). I was not aware of this discussion before and my change was reverted for this reason. Still, being consistent with units is a good thing for a technical page. Wesko (talk) 16:51, 18 January 2016 (UTC)
- I just eliminated the goofy notation. It’s probably not a good idea to presume the reader knows nothing about degrees versus radians. Does this work for everyone? Strebe (talk) 20:19, 18 January 2016 (UTC)
- doesn't use a good technical notation. My suggestions are as follows:
Citation needed
[edit]I think this claim "General lack of understanding that the Web Mercator differs from standard Mercator usage has caused considerable confusion and misuse." needs a citation. The next citation doesn't justify this statement. If one of the other references does, then please add it here as well - it's ok to use a reference many times. Stevage 23:03, 18 March 2015 (UTC)
- NGA issued the advisory notice because people were confused, using Web Mercator for situations where the governmental agencies required true Mercator maps. That’s why NGA issued the advisory. I have cited Battersby et al, who directly describe the situation as “confusion”. Strebe (talk) 23:44, 18 March 2015 (UTC)
- Ah, thank you. Stevage 23:12, 22 March 2015 (UTC)
"First Google Maps"
[edit]I'm pretty sure the very first public version of Google Maps actually used a plate carrée projection (maybe with some rescaling to get shapes approximately right at contiguous US latitudes), not a Mercator variant. At that point it only covered North America, and the shape distortion got pretty severe in northern Canada. They switched to the Web Mercator before long, though; I'm not sure exactly when. --50.177.151.55 (talk) 14:41, 18 April 2015 (UTC)
- You’d need some reference for that. Battersby et al (2014) don’t mention plate carrée as preceding Mercator in Google Maps. Also, I seriously doubt a service created by two Danish men in Australia would only show North America. Strebe (talk) 19:18, 18 April 2015 (UTC)
- A google employee says that The first launch of Maps actually did not use Mercator here. This source says plate carreé was used until July 22 2005 (apparently from personal knowledge, which has been added to the Google Maps page with no other source). Enaki (talk) 12:32, 29 August 2017 (UTC)
Multiple errors
[edit]@Vаdiм: The formulas you give are incorrect: You state latitude and longitude are in radians, but the formulas clearly require degrees in order to be anything like correct. But you also have a spurious term that is trigonometrically nonsensical. Furthermore, you attribute 900913 to EPSG, but that is false, as per: [1]. The site [epsg.io] lists EPSG:900913, but epsg.io is not an authorized or authoritative site for EPSG. Please discuss changes you want here so that we can ensure their accuracy and relevance. Strebe (talk) 17:53, 12 November 2018 (UTC)
- Lets start with the EPSG:900913:
- 1st, perhaps it wasn't clear in the text, but I did not attribute EPSG:900913 notation to the respective institution. It's rather the opposite: EPSG:900913, despite it wasn't recognized/endorsed by the EPSG themselves, was a popular notation for the so-called Web Mercator in various software project and publications. It's a hack: the developers simply appended it to a file with EPSG definitions they had already (hence the EPSG prefix). I can't confirm yet the last sentence with publications, but one can verify this with the software sources.
- EPSG:900913 as a designation for a projection is rather widespread even in academic publications and such. One can check it with the Google Scholar. In addition to the sources provided earlier, one can find in this listing, for example: "
Web Mercator was initially assigned an unofficial code “900913” (GOOGLE spelled with numbers). Later, EPSG introduced an official identifier: “EPSG:3857 -- WGS84 Web Mercator (Auxiliary Sphere).”
"
- On the other hand, the notation "OpenLayers:900913" does not have any sources cited behind it. Apparently this term is an invention of the article's editor. As per WP:VERIFY: "
Wikipedia does not publish original research. Its content is determined by previously published information rather than the beliefs or experiences of its editors. Even if you're sure something is true, it must be verifiable before you can add it.
"
- Formulas:
- Well spotted about radians, apologies for my copy/paste error. As for the formulas themselves they were taken from the Openlayers 2 sources, and the text had a relevant reference.
- Also one can check for more recent versions of the Openlayers for a their formulas.
- By the way, I can't find definition for the formulas currently placed in the article. If there is no any sources for them, then again as per WP:VERIFY they have to be removed from the article --Vаdiм (talk) 15:44, 13 November 2018 (UTC)
- I agree that nobody uses “OpenLayers:900913” even though OpenLayers is the real “authority” behind the nomenclature. The article should make clear that “EPSG:900913” is used sometimes, and how that came about, and the article should not mention “OpenLayers:900913” because that is not a recognized SRID.
- We can attribute the formulas to [2]. Right now we link to a Google page, but comparing the content of that page now to its state several years ago, it’s clear that the reference is out of data and no longer useful. I will replace that link with the one from OpenStreetMap.
- The OpenLayers formulation you give is a program, not a formula, thus requiring interpretation, which we should avoid. The mysterious tan(90+φ) term you had turns out to be transcribed improperly; the modification by π/360 belongs inside the tan calculation, not outside.
- Thanks for your efforts. Strebe (talk) 19:41, 13 November 2018 (UTC)
- I think it's all rather reasonable. It's fine with me if you update the article accordingly--Vаdiм (talk) 14:09, 14 November 2018 (UTC)
WKT incorrect
[edit]The Well-Known Text (WKT) is incorrect. The "Mercator_1SP" name in PROJECTION["Mercator_1SP"]
element is for ellipsoidal formulas. I'm not aware of an authoritative source for a Web Mercator projection name to put instead of "Mercator_1SP". Furthermore the EXTENSION
element does not exist in WKT; it is specific to some software based on the GDAL library. A possible fix would be to use WKT 2 instead of WKT 1 since WKT 2 encourages the use of an EPSG code for reducing the risk of confusion. Or alternatively we could just remove the "WKT definition" section for now.
Desruisseaux (talk) 11:27, 25 December 2018 (UTC)
- Perhaps WKT 2 is the right choice here. I suspect that is the dominant usage these days. Strebe (talk) 19:43, 28 December 2018 (UTC)
WKT 2 format is not yet widely used, but that may change in the coming year with the upcoming support from GDAL library. A WKT 2 for Web Mercator is provided by EPSG registry itself, which is the most authoritative source I'm aware of: http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857 Desruisseaux (talk) 17:10, 30 December 2018 (UTC)
Using spherical development for large-scale maps
[edit]User:Numerical advantage deleted, then reverted my reversion, of this text: This practice is uncontroversial for small-scale maps (such as of the entire world), but has little precedent in large-scale maps (such as of a city or province). This is in the context of the description of the Web Mercator's generally confusing usage of a spherical projection for large-scale maps.
Their original justification for this deletion was, Undid revision 915396859 by Strebe (talk) appears to be a work written by the user adding the reference, a clear conflict of interest. also not neutral, not due weight. I referred them to WP:SELFCITE, showing that their interpretation of conflict of interest is incorrect and asked for an explanation of the inobvious claims of non-neutrality and “not due weight”. The editor responded with, introduces non-neutral claim of controversy, does not illuminate a significant aspect of the topic, seems to have been added purely to promote the work being cited. If you think it must be stated, find another source that says this.
By this reasoning, no controversy could ever be mentioned in a Wikipedia article. The editor seems to confuse taking sides in a controversy with reporting the fact of a controversy. Or something. In any case, every major article discusses whatever controversies happen to be involved in the topic. The only Wikipedia guideline that I am aware of suggests that articles about contentious topics shouldn’t have a section specifically devoted to controversies and their rebuttals, but, rather, discussed in the text body wherever the controversial statements are made. Therefore the claim of non-neutral is false.
Furthermore, the text that the editor deleted did not claim a controversy; it stated that such-and-such practice has little precedent. In order for there to be a controversy, some party would have to be contesting the statement. There is no contest. Google does not dispute this; Microsoft does not dispute this; no literature disputes this. There simply is no controversy—and the text would not violate any policy even if there were.
The editor claims that the deleted text "does not illuminate a significant aspect of the topic". However, the editor themself is responsible for diluting the significance: In this edit, User:Numerical advantage changed a heading that existed from near the article's start, as provided by the article’s originator User:Stevage, “Spherical or ellipsoidal”? to “Geometry”. That heading’s purpose was to alert the reader about the confusing mix of spherical projection with ellipsoidal coordinates. Even with the dilution, the statement is important in providing the rest of the context: Not only does the projection violate normal usage of the Mercator, as amply ranted on by the National Geospatial Agency (cited in the article) and in the article by Battersby, Finn, Usery, and Yamamnoto (also cited); it also violates normal usage for any projection. This latter observation is well known among scholars even if not otherwise mentioned in the formal literature. Hence my explanation that the practice has little precedence informs the reader that mixing ellipsoidal and spherical paradigms, which is a key trait of the Web Mercator, is definitely not normal practice. How User:Numerical advantage will explain the insignificance of this will be interesting to see, but I rather doubt others will agree.
Then there is the incoherency of the arguments User:Numerical advantage makes. The claim that mentioning the (non)controversy is a point-of-view problem, and that the matter is insignficant, do not go away even if I cite some other source, as User:Numerical advantage demands. Therefore, those arguments are spurious and can be discarded. That leaves us with User:Numerical advantage hating my citation, for mysterious reasons, along with their unexplained belief that the citations’s purpose is to promote the article itself rather than to provide the pertinent information it had to be cited for.
I invite others to comment. Strebe (talk) 20:51, 28 September 2019 (UTC)
- I changed the section title because section headings should not be phrased as a question. I removed the addition of the source written by the person who added it for the following reasons:
- Firstly, one obviously has to treat with great caution a source added by the author of the source. It should be overwhelmingly clear to any other editor that the source provides something of significance, and is not merely someone using Wikipedia for spamming. That was not clear to me.
- Secondly, the source was not simply verifying something already in the article, but introducing a new claim, with a biased point of view. The text clearly indicates that the person who wrote it objects to the use of the projection. They state that "the text that the editor deleted did not claim a controversy." It obviously did: if you say that one use of the projection "...is uncontroversial, but...", then you're saying that the other use is controversial.
- Thirdly, the article cited is a primary source. Adding a citation to a primary source that you wrote yourself to convey your personal point of view is not an act beneficial to Wikipedia.
- As the projection is, according to the article, "used by virtually all major online map providers", it clearly is "normal practice". It clearly is not "controversial". Specific issues with the projection that have been discussed in secondary sources should of course be discussed; there is a section entitled "advantages and disadvantages". If the sentiment were expressed neutrally - something like "This practice was already common for small-scale maps (such as of the entire world), but had not previously been in large-scale maps (such as of a city or province)." - it may be worth retaining. I do not think the author of a source is a good judge of whether the source should be cited though. Numerical advantage (talk) 11:16, 29 September 2019 (UTC)
- User:Numerical advantage states that they changed a header from a question due to style guidelines. However, the change did not just remove the question; it changed the topic of the section from something specific to something far more general than the actual topic of the section. I will fix this.
- Firstly, one obviously has to treat with great caution a source added by the author of the source. It should be overwhelmingly clear to any other editor... Resorting to hyperbole in the bolded words, are we not? Furthermore Numerical advantage seems to have invented a Wikipedia policy that any editor has veto power over the consensus.
- The text clearly indicates that the person who wrote it objects to the use of the projection. Isn’t that rich, given that I seem to be the sole cartographic voice that defends Google’s use of the Web Mercator, as pointed out in the cited Battersby et al. In other words, Numerical advantage seems unable to conceive that someone might understand both strengths and weaknesses of a situation but instead attributes an unfavorable factual statement to bias. Perhaps that is how User:Numerical advantage works. It isn’t how everyone works.
- It should be overwhelmingly clear… that the source… is not merely someone using Wikipedia for spamming. That was not clear to me. Then how about you research my list of publications, versus how many times I cite them on Wikipedia, so that you can get some idea for how apathetic I am about “spamming Wikipedia” as a ratio of my total contributions to Wikipedia, hm? Why is it that you feel no duty to do any due diligence here while you sit around manufacturing insinuations?
- Thirdly, the article cited is a primary source. Adding a citation to a primary source that you wrote yourself to convey your personal point of view is not an act beneficial to Wikipedia. User:Numerical advantage again invents Wikipedia policy. There is neither an injunction against primary sources nor against WP:SELFCITE. Furthermore, the matter in dispute is not one of opinion; it is a matter of fact. Perhaps I have my fact wrong, but User:Numerical advantage hasn’t produce a whiff of any evidence about that; instead, User:Numerical advantage has nothing to offer but opinion about my motives. How about I offer an opinion on what are not acts beneficial to Wikipedia:
- •Stifling meaningful facts that have been vetted by four professionals in the field (the academic journal’s editor and three reviewers);
- •Providing no evidence that anyone but you yourself disagrees with the cited fact;
- •Inventing or misinterpreting Wikipedia policies to press a point;
- •Impugning other editors with speculations about their motives that cannot be supported by the available evidence;
- •Exercising WP:OWNERSHIP over content when every one of your roving list of objections has been refuted.
- Thirdly, the article cited is a primary source. Adding a citation to a primary source that you wrote yourself to convey your personal point of view is not an act beneficial to Wikipedia. User:Numerical advantage again invents Wikipedia policy. There is neither an injunction against primary sources nor against WP:SELFCITE. Furthermore, the matter in dispute is not one of opinion; it is a matter of fact. Perhaps I have my fact wrong, but User:Numerical advantage hasn’t produce a whiff of any evidence about that; instead, User:Numerical advantage has nothing to offer but opinion about my motives. How about I offer an opinion on what are not acts beneficial to Wikipedia:
- I am getting pretty tired of this obstructionism and waste of time. There is nothing controversial or unusual here. If other editors don’t weigh in, then this will be going into arbitration.
- Strebe (talk) 17:58, 29 September 2019 (UTC)
- Of course, it’s also not convenient to User:Numerical advantage’s narrative that Google abandoned Web Mercator in desktop browsers a year ago whenever rendering small-scale maps. Strebe (talk) 18:03, 29 September 2019 (UTC)
- I've made a total of six edits to the article. It's ludicrous to claim that I am "Exercising WP:OWNERSHIP". You have not given any coherent reasons for citing a source that you wrote yourself, and your desperation to include it convinces me that you lack the necessary impartial judgement. You haven't understood that the text you added was not neutral. If someone else wants to cite your work, and does so in a neutral way, I'm fine with that. The current text, and your attitude, are not acceptable. Numerical advantage (talk) 21:16, 5 October 2019 (UTC)
- @Numerical advantage:I’ve made a third-opinion request. Strebe (talk) 23:33, 5 October 2019 (UTC)
- @Numerical advantage:I’ve made a third-opinion request. Strebe (talk) 23:33, 5 October 2019 (UTC)
Response to third opinion request: |
Hello, I'm creffett and I'm your third opinion for today. Here's my thoughts on the matter:
|
- Thanks for your efforts, creffett. Concerning large scale projections in general: There isn’t anything else to cite because, until Web Mercator, the problem didn’t exist in any meaningful way and so there was nothing to comment on. You just didn’t use spherical projections at large scales. All of the national mapping systems use ellipsoidal developments, of course, and because the national mapping agencies have been the source of data and ground truth, cartographers generally used the regional standards for the maps they made. It would be harder not to. This is not to say that every ski lodge map or tourist map was made that way—such maps don’t even come with grids, generally—but for anything that purported to give you coordinate information, they naturally used official sources, and in the same projections. Therefore, there is no corpus of texts and papers out there warning you not to use spherical projections for large-scale maps. When it did happen, naturally the focus was on where it happened (Web Mercator), not where it did not happen.
- Use of the Web Mercator has been quite controversial among geodesists and cartographers, but not controversial in the sense of there being two sides that are debating. No professionals have really defended Web Mercator (except me, in a qualified way), and the online mapping services have not themselves defended the practice. (I could supply several references that express dismay over use of the Web Mercator, if needed, but in the end, nobody’s making an academic career out of bashing Web Mercator, so it’s not as if much gets formally published even if they stomp around fuming at conferences.) Hence, it would not be wrong for a reader to feel that the appearance of “uncontroversial” in the preceding sentence might imply “controversial” in the succeeding sentence. However, there is a better reason I used “uncontroversial” there: people might think that using ellipsoidal coordinates with a spherical development in small-scale maps is bad. The text is to reassure them that the practice is not controversial even though it’s a little “off”. Strebe (talk) 02:34, 10 October 2019 (UTC)
- I know that creffett has already chimed in here, but I thought I would add another opinion to the mix.
- I understand Numerical advantage's concern around WP:SELFCITE and agree that self-citation needs a higher level of scrutiny that other citations, however like creffett I am of the opinion that Strebe's self-citation does not appear to violate policy, particularly if we assume good faith. That said, consider this very weak support as I am not able to access the full source and from the abstract the relevancy appears to me to be borderline.
- Regarding the "controversy", while it may be true that it exists "among geodesists and cartographers", from Strebe's statement above it may not be verifiable to the standards of Wikipedia's policies at this time. As such, in interests of achieving consensus through compromise, I generally support something similar to Numerical advantage's suggested rewording:
"This practice was already common for small-scale maps (such as of the entire world), but had not previously been in large-scale maps (such as of a city or province)."
— User:Numerical advantage 11:16, 29 September 2019 (UTC) - Regarding the title of the sub-section currently named "Spherical and ellipsoidal mix", I cannot really see the value of this sub-section at all. It currently has very little content (but perhaps there is scope for more content in the future?) and it appears to duplicate content in the the second paragraph of the properties section: "While the Web Mercator's formulas are for the spherical form of the Mercator, geographical coordinates are required to be in the WGS 84 ellipsoidal datum." I recommend removal of this sub-section entirely and reworking the second paragraph of the properties section with an emphasis on clarity for non-expert readers.
- More broadly, stepping back to the overall context of the article and its improvement, I don't believe any discussion of controversy, advantages or disadvantages belongs under a section heading of "Properties". In my opinion, a section named properties should be a very non-controversial description of the basic properties of the map projection (both in plain English and mathematically) and what distinguishes it from other map projections. I do not believe a properties section should describe ways the map projection is used, its history, any discussion of the advantages and disadvantages it provides, or any criticisms or controversies related to it. I recommend redesignating the sub-section "Advantages and disadvantages" to as a new top level section renamed "Advantages, disadvantages and criticism" and relocating into it all discussion around use (for different scales, lack of acceptability by US Defence, etc.) and (well sourced) criticisms or controversies associated with its use. It may also be worth separating out another section titled "History and Uses" that could be used to cover the historical development/adoption of the projection and notable uses it has been put to. (For comparison, the Mercator projection article includes separates sections for "History", "Properties" and "Uses").
- 203.10.55.11 (talk) 03:47, 10 October 2019 (UTC)
- Thanks for the comments.
That said, consider this very weak support as I am not able to access the full source
I retained copyright. You can access the Author’s Manuscript (same content as published) here, p.5. As I read over the verbiage, I see that it could be taken as ambiguous: A lawyer might argue that “contrary to practice in any other context” applies to the Mercator usage rather than to the practice of ellipsoidal coordinates against a spherical development at large scale. The latter is the intent and would be recognized that way by a professional (because it is well known; e.g., nobody would dream of treating the State Plane system {UTM and Lambert conformal conic} this way), but a professional reading can’t be required. I think I will withdraw this proposal, with apologies.
- Thanks for the comments.
- I agree with the IP editor’s recommendations in “More broadly” for restructuring and about what goes where. I am a little more skeptical of providing no header at some level that calls attention to the problems so graphically denounced by NGA (and others). Somewhere along the line, somebody put in an explanation for why the projection has so many EPSG codes, the reason being that the projection was so offensive to the geodesy community and so heavily resisted by the EPSG registry, that EPSG only designated one many years later, well after organizations who needed an SRID for it created ones themselves in private registry space. Someone else deleted the explanation as unsourced—which it was—but this situation, too, is common knowledge among professionals. That leaves us with no explanation for an unprecedented and a very confused EPSG registry situation. Therefore to further dilute what is, actually, an important chunk of the projection's identity by eliminating a header talking about the geometry problem would be unfortunate, even if the content is still slim. I do not mind adding to it. Sourced, of course (and not self-cited! I have nothing further).
Regarding the "controversy", while it may be true that it exists "among geodesists and cartographers", from Strebe's statement above it may not be verifiable to the standards of Wikipedia's policies at this time.
While I agree with this, I think it points to an unfortunate hole in Wikipedia’s ability to deliver. In such situations (not speaking of this one specifically), we can see literature of the field in question that is predicated on some knowledge that is so common and obvious to those in the field that it is never actually stated. One can infer such knowledge; otherwise the literature would make no sense, but doing that falls afoul of WP:SYNTH. I have no solution to propose and I understand why the status quo must be, and yet I keep running into such situation—sometimes ones more important than this minor one. Vexing. Strebe (talk) 08:06, 10 October 2019 (UTC)
- To clarify, not being able to access the full source online for free is perfectly okay and I was not suggesting otherwise. It simply limited my ability to form a stronger opinion as to relevancy. 203.10.55.11 (talk) 21:29, 10 October 2019 (UTC)
False argument on calculation speed
[edit]The article states that the form for Web Mercator is simpler to calculate than spherical Mercator. However, it's not true. In fact, the calculation is the same. Even more, if the scaling is also needed, Web Mercator is actually slower than the proper ellipsoidal Mercator. See page 10 One may also refer to the NGA Standardization Document Implementation Practice: Web Mercator Map Projection for disadvantages and for some clarifications why Web Mercator is not welcome for surveying and for mapping. Yogurt (talk) 19:47, 16 June 2020 (UTC)
- @Yogurt: You have misunderstood the text. The speed advantage is, as stated, the spherical form (both regular and Web Mercator) over the ellipsoidal Mercator. Strebe (talk) 21:50, 16 June 2020 (UTC)
Forum posts as source
[edit]@Strebe: I tried tagging the mapthematics.com forum source [3] as "unreliable source" but it got reverted with reason "See Talk page". I couldn't find any reference to it on this talk page, if there was previous discussion on it, please point me to it. -- intgr [talk] 00:31, 17 June 2020 (UTC)
- I presumed the posting immediately above this one is what motivated you to tag the reference as questionable. Is that not the case? In any case, the forum posting was considered reliable enough to be used by Battersby et al, which is reference #4 in the References section. It’s fine to quote Battersby directly, but Battersby cites the forum posting. Strebe (talk) 02:21, 17 June 2020 (UTC)
- @Intgr:Actually, while the forum posting was the first to state it, by now there are many statements from reliable sources beyond Battersby et al concerning the (terribly obvious) fact of computational efficiency:
- https://books.google.com/books?id=dr6aDgAAQBAJ&pg=PA132&lpg=PA132&dq=Web+Mercator+computational+advantage&source=bl&ots=sutJD-1V7h&sig=ACfU3U1kzklfJNk1FFtequFbILLAtYjG-A&hl=en&sa=X&ved=2ahUKEwic5-GD54fqAhV2HzQIHftZCRYQ6AEwC3oECAkQAQ#v=onepage&q=Web%20Mercator%20computational%20advantage&f=false
- https://gis.utah.gov/nad83-and-webmercator-projections/
- https://www.researchgate.net/publication/321064657_Web_mercator_and_raster_tile_maps_two_cornerstones_of_online_map_service_providers
- Strebe (talk) 02:43, 17 June 2020 (UTC)
- @Strebe: Ahh nope, I didn't know of the above discussion. I merely happened to read the article and noticed there's a citation to a forum post, which does not pass WP:RS criteria. I don't doubt that it's true, just that the source is not considered good. If there are better sources now, I think it should be replaced. -- intgr [talk] 11:00, 18 June 2020 (UTC)
"Controversial"
[edit]User:Cinagroni deletes the cited explanation that using spherical development of a map projection with ellipsoidal datum is a controversial practice, and justifies this deletion and then reversion of the Undo with, used by billions of people every day without difficulty = not controversial. Perhaps you wish to say something different. It is also true that billions of people subscribe to superstitions, all of which are controversial, and that a large majority of Republican voters in the US believe that Biden's win in the presidential election was due to voter fraud, for which no evidence exists. That believe is also controversial. The given reason is spurious. Reverted again. Strebe (talk) 23:12, 1 January 2021 (UTC)