My two cents, just add/leave the possibility to add a scale bar in m, km, Nm, whatever unit. Let the user decide if it's right or wrong. A simple and effective solution is to provide a message stating that scale bars in other units than degrees are not accurate or something along that line, mainly just as a reminder for people that may forget the data is unprojected when in composer
Bernhard Ströbl wrote > Hi Matthias, > > Am 24.06.2014 16:46, schrieb Matthias Kuhn: >> On 24.06.2014 16:10, Bernhard Ströbl wrote: >>> >>> Hi Matthias, >>> >>> In your mail I attached two files (not for the list). One is North >>> America in a Lambert Conformal Conic projection, the other one in >>> WGS84. Both show a grid with 10 degrees distance between parallels and >>> meridians. >>> >>> Am 24.06.2014 14:02, schrieb Matthias Kuhn: >>>> Hi Bernhard, >>>> >>>> On 24.06.2014 11:06, Bernhard Ströbl wrote: >>>>> Hi Matthias, >>>>> >>>>> probably this is academical... >>>>> >>>>> Am 24.06.2014 10:42, schrieb Matthias Kuhn: >>>>>> Hi Bernhard, >>>>>> >>>>>> I wouldn't say no sense at all. It strongly depends on the >>> context, but >>>>>> if you have for example a lesson for geography students and are >>>>>> introducing CRS/projections and their properties one could want to >>> add a >>>>>> scale bar in degrees. >>>>> >>>>> But would that scalebar show the degrees for lon or lat? >>>> >>>> Maybe I am wrong, but I assume that there is no difference. One unit >>>> (degree) will represent the same amount of pixels/points horizontal and >>>> vertical. >>> >>> Well, you are wrong because one degree in lat is always ~110km whereas >>> one degree in lon is ~110 km at the equator and e.g. in Zurich ~75km >>> (for calculation see [1]). So how many pixels are 1 degree? Depends on >>> the projection; in WGS84 it is the same amount no matter if for lon or >>> lat, in Lambert it is not. >> >> For Lambert neither one nor the other makes sense. The only appropriate >> solution here would be some kind of "Lambert unit" whatever that may be. >> But for the WGS84 map you sent the original statement above holds true: >> the same amount of pixels matches the same amount of degrees everywhere >> on the map (In terms of lat/lon, not in terms of degrees on the sphere >> though). While a scalebar in km as provided is subject to distortion for >> the exact reason you noted. > > Agreed. But a scale bar is used to measure distances (and IMHO distances > are in miles, km,..., not in degrees) If a scale bar makes sense depends > on the projection and the area covered (as I stated some mails ago: "The > fact that a map is suitable to measure and compare distances is not > decided by the map units but by the used projection and the covered > area."). If it does not make sense one should not put a scale bar on the > map. > >> >>> >>>> >>>>> If the first (lon) for which latitude? >>>> It doesn't matter in degrees. But it really matters when trying to >>> put a >>>> scalebar in meters. >>> >>> It does also matter in degrees, depending on the projection. same in >>> meters: 1 cm on the map represents always a certain distance in >>> reality (though this distance varies troughout the map depending on >>> the projection and the area covered). If you look at the Lambert map, >>> you realize that the distance between two parallels (10 degrees!) >>> increases towards the pole, although in reality it is always (10*110km >>> =) 1100 km. In the WGS84 map the distance between the parallels is >>> constant but so is the distance between the meridians, but this is >>> false as the distance gets less towards the pole in reality. So a >>> scalebar (in m) being accurate in the middle of the map becomes less >>> accurate towards the edges. Hence my question on which base the >>> scalebar is calculated. >> >> The question absolutely makes sense but I don't know the answer :) > > Could you check? or whom would we have to ask? > >> >>> >>>>> Either of the two: how do you want to tell people that this scalebar >>>>> is only true for North-South (lat) or East-West (lon) measurements and >>>>> must not be used in any other direction? IMHO a scale bar is to enable >>>>> readers to use their ruler to measure a distance on the map in _any_ >>>>> direction. >>>>> >>>>>> I agree that it's not very common and most people >>>>>> are probably unused, but if you explicitly state the fact that the >>> map >>>>>> is in degrees you might even avoid confusion and prevent people from >>>>>> trying to compare distances. >>>>> >>>>> But adding a scale bar encourages users to compare distances! The fact >>>>> that a map is suitable to measure and compare distances is not decided >>>>> by the map units but by the used projection and the covered area. If >>>>> your map is in degrees just enable the graticules and (if useful) add >>>>> a scalebar in m/km/miles (does that work with degrees? I have not >>>>> tried. If not this would be a feature request.) >>>>> >>>> Doesn't really make sense to me. Graticules are just another reference >>>> for distances (in degrees in this case) and an alternative or addition >>>> to scale bars. What problem exactly would the combination of a grid in >>>> degrees and a scalebar in meters solve? >>> >>> a scale bar makes distances measurable while a graticule helps >>> localizing a point. In certain cases (projections) the graticule could >>> be used for measuring, though. >> You are right here. It's not a replacement but a bit of a different >> thing (because graticules are not necessarily required to be straight). >> So for the ship navigation example before, graticules in degrees for >> localization (non-straight) combined with a meaningful scalebar (given a >> suitable projection) make absolutely sense. My main point was, that a >> graticule doesn't compensate for a scalebar on an unsuitable projection. > > OK, total agreement, all is related to the projection, so the maker of > the map has to use care to choose a suitable one. > >>> >>>> >>>>> BTW: for which point of a map is the scale bar currently created >>>>> (thinking of non-distance-true projections and large areas e.g. >>>>> continents)? >>>> No idea. >>>> But if there should be proper support for scalebars in meters on >>>> degree-based maps, then it has to be configurable. And also the two >>>> different scalebars (horizontal vs. vertical) that you mentioned. Then >>>> it could be that there is a small enough area that this can be >>>> considered accurate enough to be useful. And there should be >>> warnings to >>>> inform the mapper that he might be misleading readers and should >>>> consider to reproject. >>> >>> I cannot imagine any use case for measuring distances in degrees. If >>> you look at either of my maps you see that the south of Greenland is >>> apporximately 40 degrees north of Cuba and that Canada covers almost >>> 90 degrees in east-west direction. But why should someone measure this >>> in degrees and not in km or miles? Would you measure the distance >>> between your place and your favourite bar in degrees? >> >> That's not the right question to ask. Instead it should be: "Why would >> someone want to measure distances on an unsuitable projection, with a >> ruler that he has no idea if it has any meaning for the location he >> tries to measure?". > > Again, its up to the maker of the map to provide a scalebar if it is > meaningful and none otherwise, same with the graticule. > >> The result is the same as when a friend measures the distance to his >> favorite bar, find out that it's 2.8 miles and then telling me that it's >> 2.8 km. I'd rather know that it's 2.8 "units" and therefore be aware of >> the requirement to be careful with the interpretation of the result. >> Or even better: have somebody warn my friend that he might be using the >> wrong tool for the job he tries to accomplish :) > > or even better: go with him to the bar to show you the way :-) > > Bernhard > > > __________ Information from ESET Mail Security, version of virus signature > database 9993 (20140624) __________ > > The message was checked by ESET Mail Security. > http://www.eset.com > > > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer -- View this message in context: http://osgeo-org.1560.x6.nabble.com/QGIS-Crash-Serious-problem-in-2x-tp5147434p5147622.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
