dhis2-devs team mailing list archive

[Rodolfo Melia <rmelia@xxxxxxxxxxxx>]

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