@Terence_Scott
It’s OK. This is not the forum to educate people on GIS - and the GIS knowledge among DHIS2 users are generally low - but for those interested, note the following:
-
DHIS2 only supports SRID / EPSG 4326 - which is equivalent to the geographical graticule (earth model) that often are referred to as WGS-84 (World Geodetic System of 1984).
2.
Geographical longitudes goes either East from the 0 meridian (in school you might have heard of it as the “Greenwich Meridian”) to +180 deg in the Pacific, or West from the 0 deg meridian to -180 deg in the Pacific. Geographical latitude from 0 degrees (equator) to +90 degrees North (the true North Pole) and from 0 deg (equator) to -90 degrees (true South Pole) in the southern hemisphere.
DHIS2, like nearly all GIS systems, is also only accepting coordinates in the DECIMAL DEGREES format - not e.g. Decimal degrees, minutes, and seconds that many learned about in school (navigation is heavily influenced by it’s marine origins and mariners used deg-min-seconds, but that’s another story). So all coordinates you capture or import into DHIS2 must be from -180.000000 to +180.000000 for longitudes and from -90.000000 to +90.000000 degrees for latitudes (six decimals are equivalent to approximately 50cm accuracy, which is more than sufficient for health applications)
If you find that you have coordinates like 170543 or something like that, it means those coordinates are coming from a PROJECTED map - and you must PROJECT such coordinates back to geographical coordinates before using/importing them into DHIS2.
-
What this means e.g. for Africa is that west of approximately Togo, you will have a negative longitude (west of 0 deg) and a positive latitude (north of the Equator). From Togo and eastwards, all longitudes are positive - BUT latitudes will be positive north of the equator and negative south of the Equator. Asian countries are all having positive longitudes and (north of the equator) positive latitudes. This basic understanding is what I often find lacking among users, especially data capturers - so if they capture coordinates manually you get a lot of East/west values longitude values mixed up due to the minus sign, and a lot of north/south values mixed up too.
-
Some countries use local variants of WGS-84 to increase accuracy within their borders - like South Africa is using an official datum called Hartebeeshoek - but the differential between those and WGS-84 are usually less than 1-2 metres and thus irrelevant for health purposes.
-
For DHIS2 version up to 2.29, standard coordinates were generally stored in two fields called “longitude” and “latitude”. The first step in the shift to using PostGIS geometry happened when the “COORDINATE” data type was introduced. The second step from 2.30 was to replace all those long/lat fields in various key tables with a “geometry” field. In 2.30, only the three tables “organisationunit”, “map”, and “programinstance” still have the lat/long fields) - in 2.31.1 it’s only the first two left, while “programinstance”, “programstageinstance”, and “trackedentityinstance” tables now have a “geometry” field.
-
During this transition it is not a surprise that bugs are creeping in or mistakes made - for instance I picked up in Nov-18 that the the maps and GIS apps did not display coordinate data elements of data type “COORDINATE”, the apps only displayed e.g. events using the default coordinates. That bug was fixed, and they had to back-port it several versions, indicating that nobody had picked it during the last 1-2 years - which again reflects the fact that the GIS functionality in DHIS2, just like GIS functionalities in every other health information system I’ve looked at over the last 20-25 years, are under-utilised. Which again reflect the fact that most health managers and health personnel are not familiar with the analysis and interpretation of spatial data and maps. That again reflect the fact that many many Low and Middle income countries historically have restricted access to maps and spatial data…
-
Finally, also note that the DHIS2 user interface for geographical data is poor/inconsistent:
- While the global standard for storing and displaying coordinates is longitude-latitude, and DHIS2 stores them like that, it often DISPLAY them as latitude-longitude.
- While the words latitude and longitude are displayed for coordinate fields when those fields are empty, the words disappear after values are entered, so when a user reviews or edits coordinates it’s easy to mix them up.
- There are no features to limiting coordinates to a specific range.
- There are no features for e.g. limiting point coordinates to fall within a specific area, like within a country
- You cannot use geometry fields in program rules
and so on. It all boils down to a lot of garbage coordinates being captured or imported, causing problems which in turn reduces the useability and thus usage.
Nuff’ said - that was today’s sermon from the spatial pulpit 
Regards
Calle
