dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

Understood - thanks for the feedback.

Lars


On Mon, May 19, 2014 at 10:18 PM, Rodolfo Melia <rmelia@xxxxxxxxxxxx> wrote:

> This sounds great ! I like the idea of separating the operators to use
> across Org Units or across Time.  It sounds like we will gain this feature
> just in time for Christmas...
>
> I noticed the new Org Unit count feature on the indicators- this will
> address many other needs, but not this one in particular, as I need to use
> the number of submitted forms - I will get this through a different data
> element, in which to store 1 or 0, so I can divide by the correct number of
> answers.
>
> Thanks again - looking forward for 2.17...
>
> *Rodolfo Meliá*
> *Principal  |  *rmelia@xxxxxxxxxxxx
> Skype: rod.melia  |  +44 777 576 4090  |  +1 708 872 7636
> www.knowming.com
>
>
> On Mon, May 19, 2014 at 8:09 PM, Lars Helge Øverland <larshelge@xxxxxxxxx>wrote:
>
>> Hi Rodolfo,
>>
>> now I understand what you mean. The solution I think would be to
>> introduce another aggregation operator: one for the time dimension, and
>> another for the org unit hierarchy dimension. Then you could set the org
>> unit hierarchy aggregation operator to avg to get your desired results.
>> This has actually been discussed before and would be a natural and good
>> feature, see blueprint from Jason here<https://blueprints.launchpad.net/dhis2/+spec/aggregation-operators>.
>> I have put it up for 2.17 for now.
>>
>> One feature that was introduced in 2.15 that might be useful is the "org
>> unit group count in indicator" function. First, you can create an org unit
>> group called "outlets", where you assign all your outlets. Then have a look
>> in indicator formula screen - you can put that group directly into the
>> formula, which will be substituted with the number of org units in that
>> group joined with the org unit hierarchy for which the aggregated value is
>> requested. You can use this as your denominator - simply take the total
>> value as numerator and divide it on the number of outlets.
>>
>> I assume your numbers are percentages? If so you you should keep the
>> aggregation operator on avg. It won't be perfect as you cannot weigh your
>> outlets but maybe close enough.
>>
>> regards,
>>
>> Lars
>>
>>
>>
>> On Mon, May 19, 2014 at 3:54 PM, Rodolfo Melia <rmelia@xxxxxxxxxxxx>wrote:
>>
>>> Hi Lars - your example for population is correct. It makes sense. Our
>>> case is scores calculated for quality assurance. On a given month we may
>>> get:
>>> *Region A*
>>> - Outlet 1: 90
>>> - Outlet 2: 100
>>> - Outlet 3: not conducted
>>> - Outlet 4: 80
>>>
>>> When looking in analytics at Region A, on the that month, we expect to
>>> get 90. We currently get 270, which is correct based on your explanation.
>>>
>>> We will try to create an indicator that divides between 3 (so we need to
>>> know conducted assessments). My worry is that the indicator will work of
>>> that month, but when looking across multiple months, not sure about what
>>> result will it return if we keep the aggregation = Avg.
>>>
>>> R
>>>
>>>
>>>
>>>
>>>
>>> *Rodolfo Meliá*
>>> *Principal  |  *rmelia@xxxxxxxxxxxx
>>> Skype: rod.melia  |  +44 777 576 4090  |  +1 708 872 7636
>>> www.knowming.com
>>>
>>>
>>> On Mon, May 19, 2014 at 2:36 PM, Lars Helge Øverland <
>>> larshelge@xxxxxxxxx> wrote:
>>>
>>>> Hi Rodolfo,
>>>>
>>>> I am not sure if I understand you correctly so I will just try to
>>>> explain how it works: With avg operator, you can get a valid
>>>> "disaggregated" data value for period "within" the data collection
>>>> frequency. So if you collect population with a yearly frequency for a data
>>>> element with the avg operator, then you can also ask for the monthly value
>>>> for a month in that year. In that case, the values will be the same - sort
>>>> of a "standing value" for that period. If you have a value of e.g. 1000
>>>> people for the year, then the value for the month will also be 1000. This
>>>> is just the nature of the data - if you have a population of 1000 for the
>>>> year, then we must assume that the population for a month is also 1000.
>>>>
>>>> We do not allow "average within a period" or disaggregations for data
>>>> element which naturally sums across time. As an example, if you collect
>>>> cases of some disease at a quarterly frequency, we don't allow retrieving
>>>> the value for a month within that quarter simply using the average. The
>>>> reason is that it would not be valid statistics - we have no evidence that
>>>> not all cases happened in the last month of the quarter, etc.
>>>>
>>>> regards,
>>>>
>>>> Lars
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, May 19, 2014 at 1:48 PM, Rodolfo Melia <rmelia@xxxxxxxxxxxx>wrote:
>>>>
>>>>> Hi Lars - thanks for the quick reply.
>>>>>
>>>>> I though AVG was valid within the same data-collection period as well
>>>>> as across time. If this is the case, how do you calculate an average within
>>>>> the same data collection period? AN indicator that divides the DE that has
>>>>> the answer between valid answers? Normally that will be completed forms,
>>>>> but such variable is not available as a denominator. We will have to use a
>>>>> different Data Element that count valid answers. Last, such indicator will
>>>>> make sense within the same period, but not across periods, as it will give
>>>>> you an incorrect value, I think.
>>>>>
>>>>> Are you sure that AVG only makes sense across-time? Wouldn't be better
>>>>> to also use the same logic within the same period? What's the rationale? If
>>>>> there anyone out not wanting AVG to be calculated on the same data
>>>>> collection period as across periods?
>>>>>
>>>>> R
>>>>>
>>>>> *Rodolfo Meliá*
>>>>> *Principal  |  *rmelia@xxxxxxxxxxxx
>>>>> Skype: rod.melia  |  +44 777 576 4090  |  +1 708 872 7636
>>>>> www.knowming.com
>>>>>
>>>>>
>>>>> On Mon, May 19, 2014 at 12:05 PM, Lars Helge Øverland <
>>>>> larshelge@xxxxxxxxx> wrote:
>>>>>
>>>>>> Hi James,
>>>>>>
>>>>>> the "aggregation operator" refers to the time dimension - data will
>>>>>> be averaged through time but still summed in the org unit hierarchy
>>>>>> dimension. We could make this clearer in the system I guess.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Lars
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 19, 2014 at 12:55 PM, James Chang <jamesbchang@xxxxxxxxx>wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On DHIS demo site, http://apps.dhis2.org/demo,
>>>>>>> 'Average' aggregation operator seem to do 'Sum' instead.
>>>>>>>
>>>>>>> I didn't do any data entry or ran Analytics, but only looking at the
>>>>>>> current data, 'Total Population' in 'Ngelehun CHC' and 'Njandama MCHP' seem
>>>>>>> to sum on 'Badjia' even though the 'Total Population' is set to 'Average'
>>>>>>> for Aggregation operator.
>>>>>>>
>>>>>>> See the attached images.
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>