[Qgis-developer] QGIS Crash - Serious problem in 2x

Tue Jun 24 08:37:42 PDT 2014

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

> Qgis-developer at .osgeo

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