Period type OnChange -Does it exist?

Using the 2.0.5 release branch with Postgres, importing data from 1.4
which has an "OnChange" period type. The import seems to choke on
this.

Does this periodtype exist in 2.0?

Regards,
Jason

···

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

This is a tricky one. We don’t support any behavior related to on-change period type in DHIS 2 so we decided to remove it from the system. But DHIS 1.4 has it and uses that period type during import. A workaround is to insert a row “OnChange” in the periodtype table before doing import from 1.4

Lars

···

On Fri, Nov 5, 2010 at 1:04 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Using the 2.0.5 release branch with Postgres, importing data from 1.4

which has an “OnChange” period type. The import seems to choke on

this.

Does this periodtype exist in 2.0?

Regards,

Jason

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190


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

Tricky indeed. This is a workaround for the import, but what happens
to all the data values when we try and use them?

···

2010/11/18 Lars Helge Øverland <larshelge@gmail.com>:

This is a tricky one. We don't support any behavior related to on-change
period type in DHIS 2 so we decided to remove it from the system. But DHIS
1.4 has it and uses that period type during import. A workaround is to
insert a row "OnChange" in the periodtype table before doing import from 1.4
Lars

On Fri, Nov 5, 2010 at 1:04 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:

Using the 2.0.5 release branch with Postgres, importing data from 1.4
which has an "OnChange" period type. The import seems to choke on
this.

Does this periodtype exist in 2.0?

Regards,
Jason

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

The aggregation routines are using start- and end-dates for the periods associated with the datavalues only, so the output tools should handle it just fine.

Lars

···

2010/11/18 Jason Pickering jason.p.pickering@gmail.com

Tricky indeed. This is a workaround for the import, but what happens

to all the data values when we try and use them?

2010/11/18 Lars Helge Øverland larshelge@gmail.com:

This is a tricky one. We don’t support any behavior related to on-change

period type in DHIS 2 so we decided to remove it from the system. But DHIS

1.4 has it and uses that period type during import. A workaround is to

insert a row “OnChange” in the periodtype table before doing import from 1.4

Lars

On Fri, Nov 5, 2010 at 1:04 PM, Jason Pickering > > > jason.p.pickering@gmail.com wrote:

Using the 2.0.5 release branch with Postgres, importing data from 1.4

which has an “OnChange” period type. The import seems to choke on

this.

Does this periodtype exist in 2.0?

Regards,

Jason

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190


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

Jason P. Pickering

email: jason.p.pickering@gmail.com

tel:+260968395190

Can someone define what exactly is an onChange period type? Its a
term I have heard referred to a lot but I must confess I don't know if
I properly understand what it means. Do we simply mean an arbitrary
period of time (without frequency) ie. it has start and end date only,
but no inherent frequency characteristic? So start date would equal
the end date of the previous OnChange period for the same series of
datavalues. Or is it an instant ie. an observation captured at a
moment in time with no inherent interval implied? So
startdate=enddate?

One case I recall hearing onChange periods being discussed was regard
staffing data in the context of data import from iHRIS. The number of
doctors might change infrequently so we might capture number of
doctors only when there is a change, rather than capturing the same
numbers each month. Either way it raises an interesting problem. I
think we define the aggregation "operator" (sum, average etc) per data
element. But it seems to me, looking at this particular example, that
you would actually want to aggregate differently depending on which
axis (time and space) that you were aggregating along. So for example
if I have datavalues for "number of doctors" which I collect on a
monthly report, it makes sense to sum across the spatial axis and
average across the time axis

               clinicA clinicB DistrictTotal
Jan 5 7 12
Feb 5 6 11
Mar 5 5 10

Quarter 5 6 11

Maybe there are other such cases where the aggregation operator would
differ across different axes. So there are maybe two ways to
rationalise this: one is to not capture the data monthly, but rather
"onChange". This does have an implication for things like monthly
data collection instruments, because I suspect frequently there will
be a requirement to capture such data routinely. The other is for the
dataelement to capture the change rather than the cumulative count -
like we would do with "new malaria cases" for example. In this case
we'd capture "new doctors". In that case we could sum across both
axes and get a sensible result, but one which would only be useful
with a sort of opening balance for the dataelement. So it is not so
much the period type which is onChange but the dataValue type. The
datavalue either reflects what has happened within that period or what
the cumulative status is at the end of that period.

This is maybe confusing two related issues, but the other approach
which comes to mind is to have two aggregation operators for the data
element - the time aggregation operator and the space aggregation
operator. This might lead a simple way out of the contradictions and
complications above. For many, perhaps most, these would both be
"sum". But for others, like the above, we would "sum" over space and
"average" over time. I am sure there might be other examples where
the reverse is true.

I am also sure these are all well known and well solved problems, so
apologies if I am being ignorant.

Cheers
Bob

Philosophical aside: Frederick Engels in Anti-Durhring, defines time
as that quantity required in order for things to change. I always
like that definition :slight_smile:

···

2010/11/18 Lars Helge Øverland <larshelge@gmail.com>:

The aggregation routines are using start- and end-dates for the periods
associated with the datavalues only, so the output tools should handle it
just fine.
Lars

2010/11/18 Jason Pickering <jason.p.pickering@gmail.com>

Tricky indeed. This is a workaround for the import, but what happens
to all the data values when we try and use them?

2010/11/18 Lars Helge Øverland <larshelge@gmail.com>:
> This is a tricky one. We don't support any behavior related to on-change
> period type in DHIS 2 so we decided to remove it from the system. But
> DHIS
> 1.4 has it and uses that period type during import. A workaround is to
> insert a row "OnChange" in the periodtype table before doing import from
> 1.4
> Lars
>
> On Fri, Nov 5, 2010 at 1:04 PM, Jason Pickering >> > <jason.p.pickering@gmail.com> wrote:
>>
>> Using the 2.0.5 release branch with Postgres, importing data from 1.4
>> which has an "OnChange" period type. The import seems to choke on
>> this.
>>
>> Does this periodtype exist in 2.0?
>>
>> Regards,
>> Jason
>>
>>
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@gmail.com
>> tel:+260968395190
>>
>> _______________________________________________
>> Mailing list: DHIS 2 developers in Launchpad
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe : DHIS 2 developers in Launchpad
>> More help : ListHelp - Launchpad Help
>
>

--
Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+260968395190

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

Quick comment: Currently the aggregation operator property applies to the time axis only, space axis is always sum.

···

2010/11/18 Bob Jolliffe bobjolliffe@gmail.com

Can someone define what exactly is an onChange period type? Its a

term I have heard referred to a lot but I must confess I don’t know if

I properly understand what it means. Do we simply mean an arbitrary

period of time (without frequency) ie. it has start and end date only,

but no inherent frequency characteristic? So start date would equal

the end date of the previous OnChange period for the same series of

datavalues. Or is it an instant ie. an observation captured at a

moment in time with no inherent interval implied? So

startdate=enddate?

One case I recall hearing onChange periods being discussed was regard

staffing data in the context of data import from iHRIS. The number of

doctors might change infrequently so we might capture number of

doctors only when there is a change, rather than capturing the same

numbers each month. Either way it raises an interesting problem. I

think we define the aggregation “operator” (sum, average etc) per data

element. But it seems to me, looking at this particular example, that

you would actually want to aggregate differently depending on which

axis (time and space) that you were aggregating along. So for example

if I have datavalues for “number of doctors” which I collect on a

monthly report, it makes sense to sum across the spatial axis and

average across the time axis

           clinicA     clinicB   DistrictTotal

Jan 5 7 12

Feb 5 6 11

Mar 5 5 10

Quarter 5 6 11

Maybe there are other such cases where the aggregation operator would

differ across different axes. So there are maybe two ways to

rationalise this: one is to not capture the data monthly, but rather

“onChange”. This does have an implication for things like monthly

data collection instruments, because I suspect frequently there will

be a requirement to capture such data routinely. The other is for the

dataelement to capture the change rather than the cumulative count -

like we would do with “new malaria cases” for example. In this case

we’d capture “new doctors”. In that case we could sum across both

axes and get a sensible result, but one which would only be useful

with a sort of opening balance for the dataelement. So it is not so

much the period type which is onChange but the dataValue type. The

datavalue either reflects what has happened within that period or what

the cumulative status is at the end of that period.

This is maybe confusing two related issues, but the other approach

which comes to mind is to have two aggregation operators for the data

element - the time aggregation operator and the space aggregation

operator. This might lead a simple way out of the contradictions and

complications above. For many, perhaps most, these would both be

“sum”. But for others, like the above, we would “sum” over space and

“average” over time. I am sure there might be other examples where

the reverse is true.

I am also sure these are all well known and well solved problems, so

apologies if I am being ignorant.

Cheers

Bob

Philosophical aside: Frederick Engels in Anti-Durhring, defines time

as that quantity required in order for things to change. I always

like that definition :slight_smile:

Hi,

Search for onchange in this page:

http://208.76.222.114/confluence/display/DHIS1/DHIS+1.4

···

Ola Hodne Titlestad (Mr)
HISP
Department of Informatics
University of Oslo

Mobile: +47 48069736
Home address: Vetlandsvn. 95B, 0685 Oslo, Norway. Googlemaps link

2010/11/18 Lars Helge Øverland larshelge@gmail.com

2010/11/18 Bob Jolliffe bobjolliffe@gmail.com

Can someone define what exactly is an onChange period type? Its a

term I have heard referred to a lot but I must confess I don’t know if

I properly understand what it means. Do we simply mean an arbitrary

period of time (without frequency) ie. it has start and end date only,

but no inherent frequency characteristic? So start date would equal

the end date of the previous OnChange period for the same series of

datavalues. Or is it an instant ie. an observation captured at a

moment in time with no inherent interval implied? So

startdate=enddate?

One case I recall hearing onChange periods being discussed was regard

staffing data in the context of data import from iHRIS. The number of

doctors might change infrequently so we might capture number of

doctors only when there is a change, rather than capturing the same

numbers each month. Either way it raises an interesting problem. I

think we define the aggregation “operator” (sum, average etc) per data

element. But it seems to me, looking at this particular example, that

you would actually want to aggregate differently depending on which

axis (time and space) that you were aggregating along. So for example

if I have datavalues for “number of doctors” which I collect on a

monthly report, it makes sense to sum across the spatial axis and

average across the time axis

           clinicA     clinicB   DistrictTotal

Jan 5 7 12

Feb 5 6 11

Mar 5 5 10

Quarter 5 6 11

Maybe there are other such cases where the aggregation operator would

differ across different axes. So there are maybe two ways to

rationalise this: one is to not capture the data monthly, but rather

“onChange”. This does have an implication for things like monthly

data collection instruments, because I suspect frequently there will

be a requirement to capture such data routinely. The other is for the

dataelement to capture the change rather than the cumulative count -

like we would do with “new malaria cases” for example. In this case

we’d capture “new doctors”. In that case we could sum across both

axes and get a sensible result, but one which would only be useful

with a sort of opening balance for the dataelement. So it is not so

much the period type which is onChange but the dataValue type. The

datavalue either reflects what has happened within that period or what

the cumulative status is at the end of that period.

This is maybe confusing two related issues, but the other approach

which comes to mind is to have two aggregation operators for the data

element - the time aggregation operator and the space aggregation

operator. This might lead a simple way out of the contradictions and

complications above. For many, perhaps most, these would both be

“sum”. But for others, like the above, we would “sum” over space and

“average” over time. I am sure there might be other examples where

the reverse is true.

I am also sure these are all well known and well solved problems, so

apologies if I am being ignorant.

Cheers

Bob

Philosophical aside: Frederick Engels in Anti-Durhring, defines time

as that quantity required in order for things to change. I always

like that definition :slight_smile:

Quick comment: Currently the aggregation operator property applies to the time axis only, space axis is always sum.


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