DHIS 2: District system versus National repository/Health Observatory - and GIS

In the recent discussions on regarding geodata, Bob and Jason have
again brought up a number of good points with regard to standards and
interoperability.

Because of limited resources, it is imperative that we as much as
possible maintain a unified application, and for instance integrate
all the work from India and Vietnam as much as suitable into the core.

However, at the same time we need to be mindful of the relatively
different roles that DHIS2 as an application can serve. I do very much
like how the name emphasizes the use of information for action at
local levels. At the same time, DHIS2 is increasingly suited as a
platform for a national health observatory and central repository of
data for internal reporting and public dissemination (for this, we do
still need a way to "publish" certain views of the data without having
to log in - and probably a workflow for authorization of public data).

One type of data which we would like to serve as a repository for is
geodata, in particular the location of health facilities. Jason is
quite right that these need to be available in standard formats such
as GML (and KML) for easy use and maintenance in clients different
from DHIS2. Also, polygon data such as administrative boundaries will
almost always come from external sources, and be edited with dedicated
GIS software - and for the repository function, we need to preserve
the full precision of these data (which often result in quite large
amounts of data).

On the other hand, there is a need for quick and responsive mapping -
which we already have today. For this, the GeoJSON format has proven
very suitable, which we should build on. For this to be usable, it's
important to radically simplify the files (typically 90% reduction in
vertices) and reducing precision in from e.g. 8 decimals to 3. This
is different - and for a national repository, I really think a full
PostGIS representation of the GeoData with Geoserver on top which can
output all kinds of formats in any projection as a webservice is
needed. But this need is hardly present in most districts.

So we probably need to consider outlining different configurations for
different roles of the platform - in the implementation document.

Knut