[Qgis-developer] FW: Diagram improvements

Fri Aug 10 02:30:43 PDT 2012

Hi Andreas

At the moment I plan to implement as follows:

Default: Scale area
              => The user can define: a value v for an attribute a that will generate a diagram of diameter d
                 A feature with v' = v/2 will generate a diagram with (d')^2 = (d)^2 / 2

Option: Scale diameter
              => where v' = v/2 will generate a diagram with d' = d/2

I think Marco was referring to my idea for the default version: to let the value v denote the area rather than the diameter. So d = sqrt(v/pi).

--
Matthias Kuhn

________________________________

	From: qgis-developer-bounces at lists.osgeo.org [mailto:qgis-developer-bounces at lists.osgeo.org] On Behalf Of Andreas Neumann
	Sent: Friday, August 10, 2012 11:08 AM
	To: Marco Hugentobler; qgis-developer at lists.osgeo.org
	Subject: Re: [Qgis-developer] FW: Diagram improvements

	Hm - I have to disagree here. The general opinion in thematic mapping is that you shpulf scale proportional to the area and not the diameter/radius. After all, if the attribute value of a feazure is 4 times larger than the att value of another feature the area of the circle/pie chart should be 4 times as large and not 16 or 8 times as large. In my opinion the area proportional behavior should be the default and the current behavior optional.

	Andreas
	-- 
	Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

	Marco Hugentobler <marco.hugentobler at sourcepole.ch> schrieb: 

		>I think the first approach would be better for existing
		>projects, as the reference diagram (specified in the layer
		>config dialog) would keep its original size.

		Yes, I'm also in favor of the first approach. It is more intuitive to 
		set the size of the diameter than the one of the area.

		Marco

		Am 10.08.2012 09:07, schrieb Kuhn Matthias, Vermessung:
		> Oops, clicked the wrong button. Here for the list:
		>
		>
		>> Hi Marco
		>>
		>> Good thoughts. A dimension more really justifies exponential scaling.
		>>
		>> For diagrams scaled by area, we should then use the specified
		>> diameter for the given attribute value and scale other
		>> diagrams according to this ratio.
		>> The other possibility would be to indicate indicate squared units.
		>&
		 gt;
		>> I think the first approach would be better for existing
		>> projects, as the reference diagram (specified in the layer
		>> config dialog) would keep its original size.
		>> Whereas the second approach would lead to immediate resize in
		>> existing projects but it would be more comprehensible for the
		>> user that he is scaling by area.
		>>
		>> --
		>> Matthias Kuhn
		>>   
		>>
		>>> -----Original Message-----
		>>> From: qgis-developer-bounces at lists.osgeo.org
		>>> [mailto:qgis-developer-bounces at lists.osgeo.org] On Behalf Of Marco
		>>> Hugentobler
		>>> Sent: Friday, August 10, 2012 8:04 AM
		>>> To: qgis-developer at lists.osgeo.org
		>>> Subject: Re: [Qgis-developer] Diagram improvements
		>>>
		>>> Hi Matthias
		>>>
		>>>> In my opinion
		  this
		is a bug in the current version and should be
		>>>> changed without option
		>>> It will be good to have an additional option to scale
		>> proportional to
		>>> the area. But I think you should leave the option to scale the
		>>> diameter.
		>>> This was done on purpose, because the diagram size you
		>> specify is the
		>>> radius, not the area (and this again is similar to the symbology
		>>> system, where point symbol size is also diameter, not area). Btw, I
		>>> have read that there might also be cases where you want to scale
		>>> diagram sizes proportional to the volume (e.g. to display
		>> content of
		>>> lakes, etc.).
		>>>
		>>>
		>>> Regards,
		>>> Marco
		>>>
		>>>
		>>>
		>>> Am 09.08.2012 14:48, schrieb Kuhn Matthias
		 ,
		Vermessung:
		>>>> Do you think circular diagrams (i.e. text and pie) need to
		>>> have an option to scale their radius instead of their area?
		>>>> In my opinion this is a bug in the current version and
		>>> should be changed without option as it overexagerates
		>> bigger values.
		>>> But maybe there is a reason to leave this choice to the user?
		>>>> --
		>>>> Matthias Kuhn
		>>>>    
		>>>>
		>>>>> -----Original Message-----
		>>>>> From: qgis-developer-bounces at lists.osgeo.org
		>>>>> [mailto:qgis-developer-bounces at lists.osgeo.org] On Behalf
		>>> Of Matthias
		>>>>> Kuhn
		>>>>> Sent: Tuesday, August 07, 2012 5:37 PM
		>>>>> To: Qgis Developer List
		>>>>> Subject: [Qgis-developer] Diagram improvem
		 ents
		>>>>>
		>>>>> Hi,
		>>>>>
		>>>>> I recently started an internship at Uster (a city in
		>>> Switzerland). My
		>>>>> job will mostly be to improve QGIS. I'm really looking
		>> forward to
		>>>>> this great opportunity.
		>>>>>
		>>>>> My first job is, to improve the diagrams. Any comments
		>> are highly
		>>>>> appreciated. (If you think something can be done better
		>>> differently,
		>>>>> if you think something is useless, if you are already working on
		>>>>> something or you know about somebody already working on
		>>> something, if
		>>>>> you wanna say thank you...)
		>>>>>
		>>>>> Here a short list of what I've got on my ToDo list.
		>>>>>
		>>>>> - Minimum size for diagrams (As an option, scale any
		>>> diagram smaller
		>>>>> than...): Done
		>>>>> - Text diagram: Center text better vertically (As an
		>> option): Done
		>>>>> - Charts are not placed on some polygons (e.g. banana
		>>> shaped polygons.
		>>>>> Should this be done with PAL library? Any help appreciated)
		>>>>> - Ordering: Draw smaller charts on top of bigger one instead of
		>>>>> hiding
		>>>>> (randomly?) colliding diagrams.
		>>>>> - Make diagrams area accurate! By now the radius instead
		>>> of area is
		>>>>> scaled.
		>>>>> - New diagram type: Bar chart
		>>>>> - New diagram option: Split diagrams. (Pie charts / Bar
		>>> charts e.g.
		>>>>> age
		>>>>> pyramid)
		>>>>>
		>>>>> If you're interested in the current state of work, have a
		>>> look at my
		>>>>> git repo [0] on master. Where it says done in the list above you
		>>>>> should be able to check it out.
		>>>>>
		>>>>> [0] https://github.com/matthias-kuhn/Quantum-GIS.git
		>>>>>
		>>>>> Regards,
		>>>>> I'm looking forward for comments
		>>>>>
		>>>>> Disclaimer: Sorry if you get this topic the second time.
		>> I thought
		>>>>> I'd written something about it yesterday, but couldn't
		>>> find it in my
		>>>>> history nor in the archives, so I'll repeat myself and
		>>> just believe,
		>>>>&g
		 t; that
		I missed the send button when I tried to click it.
		>>>>>
		>>>>>
________________________________

		>>>>> Qgis-developer mailing list
		>>>>> Qgis-developer at lists.osgeo.org
		>>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
		>>>>>
		>>>>
________________________________

		>>>> Qgis-developer mailing list
		>>>> Qgis-developer at lists.osgeo.org
		>>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
		>>>
		>>> --
		>>> Dr. Marco Hugentobler
		>>> Sourcepole -  Linux & Open Source Solutions Weberstrasse 5,
		>>> CH-8004 Zürich, Switzerland marco.hugentobler at sourcepole.ch
		>>> http://www.sourcepole.ch
		  <http://www.sourcepole.ch> 
		Technical Advisor QGIS Project Steering
		>>> Committee
		>>>
		>>>
________________________________

		>>> Qgis-developer mailing list
		>>> Qgis-developer at lists.osgeo.org
		>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
		>>>
		>
________________________________

		> Qgis-developer mailing list
		> Qgis-developer at lists.osgeo.org
		> http://lists.osgeo.org/mailman/listinfo/qgis-developer

		-- 
		Dr. Marco Hugentobler
		Sourcepole -  Linux & Open Source Solutions
		Weberstrasse 5, CH-8004 Zürich, Switzerland
		marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
		Technical Advisor QGIS Project Steering Committee

________________________________

		Qgis-developer mailing list
		Qgis-developer at lists.osgeo.org
		http://lists.osgeo.org/mailman/listinfo/qgis-developer