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 | *rme...@knowming.com 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 <larshe...@gmail.com>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 <rme...@knowming.com>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 | *rme...@knowming.com >> 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 <larshe...@gmail.com >> > 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 <rme...@knowming.com>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 | *rme...@knowming.com >>>> 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 < >>>> larshe...@gmail.com> 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 >>>>> <jamesbch...@gmail.com>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@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : dhis2-devs@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>> >> >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
