Understood - thanks for the feedback. Lars
On Mon, May 19, 2014 at 10:18 PM, Rodolfo Melia <rme...@knowming.com> 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 | *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
