I think using Postgis would be the easiest way. I am not aware of how
ogr2ogr can do simplification but perhaps.
Right, and of course in general we want to continue to use PostGIS as the master repository, and not shapefiles, also for Geoserver more generally apart from GeoJSON.
You can also use ogr2ogr for injection of shape files into Postgres,
instead of shp2pgsql.
Likewise, you can extract Postgis data out of Postgis with ogr2ogr.
With a carefully constructed SQL query, you might be able to do
Thanks, that’s a great way to do it, Johan was just suggesting something similar. We could also add a WHERE clause in the SQL to filter for one country.
I would like to have your input on the whole picture on packaging OpenHealthMapper with core GIS and health data. Here is a suggested scenario:
Keep the world admin layers in PostGIS with LVLIDs and add point layers for Health Facilities and Villages (also with LVLIDs), as well as regular geometry tables for rivers and roads.
Use the above procedure to extract GeoJSON for a country for all the polygon admin layers, rivers and roads.
Write a script to populate OHM source and organisationunit tables (and perhaps also orgunitgroup/orgunitgroupmembers)
Import all SAM data to the same master OHM database.
Import all core health indicators from IMR (using SDMX)
Enhance the Metadata export to be able to pick just one branch of the OU hierarchy (typically a country)
Export the metadata and include the DXF and the GeoJSON files with the OHM installer for a country.
Sounds like a plan. Better be sure to get your contract extended
indefinitely.
No seriously, it sounds all reasonable, but the Indicator registry
part is still a bit fuzzy. Is there a plan for integration?
Of course the devil is in the details. I know for instance that the
geodata that WHO has for Zambia is out of date. I would suspect that
this is the case for many places. This is not necessarily a reason not
to pursue this approach, but we need to anticipate it, and prepare for
the fact that the data may be out of date, needs to be recoded, or
potentially, upgraded before ever deploying to DHIS2.
But technically, it seems like a pretty reasonable pathway, regardless
of where the data is coming from.
Regards,
JPP
···
On Tue, Dec 15, 2009 at 4:00 PM, Knut Staring <knutst@gmail.com> wrote:
On Tue, Dec 15, 2009 at 2:32 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:
Hi Knut,
I think using Postgis would be the easiest way. I am not aware of how
ogr2ogr can do simplification but perhaps.
Right, and of course in general we want to continue to use PostGIS as the
master repository, and not shapefiles, also for Geoserver more generally
apart from GeoJSON.
You can also use ogr2ogr for injection of shape files into Postgres,
instead of shp2pgsql.
Likewise, you can extract Postgis data out of Postgis with ogr2ogr.
With a carefully constructed SQL query, you might be able to do
everything in a single command similar to this [FWTools] ogr2ogr shp --> kml conversion failing on some complicated polygons
Thanks, that's a great way to do it, Johan was just suggesting something
similar. We could also add a WHERE clause in the SQL to filter for one
country.
I would like to have your input on the whole picture on packaging
OpenHealthMapper with core GIS and health data. Here is a suggested
scenario:
1) Keep the world admin layers in PostGIS with LVLIDs and add point layers
for Health Facilities and Villages (also with LVLIDs), as well as regular
geometry tables for rivers and roads.
2) Use the above procedure to extract GeoJSON for a country for all the
polygon admin layers, rivers and roads.
3) Write a script to populate OHM source and organisationunit tables (and
perhaps also orgunitgroup/orgunitgroupmembers)
4) Import all SAM data to the same master OHM database.
5) Import all core health indicators from IMR (using SDMX)
6) Enhance the Metadata export to be able to pick just one branch of the OU
hierarchy (typically a country)
7) Export the metadata and include the DXF and the GeoJSON files with the
OHM installer for a country.
Comments welcome,
Knut
Thanks for the comments. It is a huge task to update all the geodata that we have and I guess we can reasonably think we will not be able to achieve it in one day.
We should have a plan for integration as you suggest. As in any GIS system, the geodata is more important than the software and it is really key to have core layers up to date. We should look at the following layers first and decide from where the data is coming from:
- Admin boundaries: data source(SALB, GAUL, GADM, HealthMapper)
- Health Facilities: data source (SAM, OpenStreetMap, MoH)
- Villages: data source (Geonames)
- Roads: data source (OpenStreetMap)
- Rivers: data source (DCW?)
Let us know and we can draft a plan. Then we can start to prepare some datasets for priority countries. Do you know if there a list of countries we should start with?
regards,
Johan L.
···
-----Original Message-----
From: dhis2-devs-bounces+lemarchandjo=who.int@lists.launchpad.net [mailto:dhis2-devs-bounces+lemarchandjo=who.int@lists.launchpad.net] On Behalf Of Jason Pickering
Sent: 15 December 2009 19:31
To: Knut Staring
Cc: DHIS 2 developers
Subject: Re: [Dhis2-devs] Managing basic data and geometries
Sounds like a plan. Better be sure to get your contract extended
indefinitely.
No seriously, it sounds all reasonable, but the Indicator registry
part is still a bit fuzzy. Is there a plan for integration?
Of course the devil is in the details. I know for instance that the
geodata that WHO has for Zambia is out of date. I would suspect that
this is the case for many places. This is not necessarily a reason not
to pursue this approach, but we need to anticipate it, and prepare for
the fact that the data may be out of date, needs to be recoded, or
potentially, upgraded before ever deploying to DHIS2.
But technically, it seems like a pretty reasonable pathway, regardless
of where the data is coming from.
Regards,
JPP
On Tue, Dec 15, 2009 at 4:00 PM, Knut Staring <knutst@gmail.com> wrote:
On Tue, Dec 15, 2009 at 2:32 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:
Hi Knut,
I think using Postgis would be the easiest way. I am not aware of how
ogr2ogr can do simplification but perhaps.
Right, and of course in general we want to continue to use PostGIS as the
master repository, and not shapefiles, also for Geoserver more generally
apart from GeoJSON.
You can also use ogr2ogr for injection of shape files into Postgres,
instead of shp2pgsql.
Likewise, you can extract Postgis data out of Postgis with ogr2ogr.
With a carefully constructed SQL query, you might be able to do
everything in a single command similar to this [FWTools] ogr2ogr shp --> kml conversion failing on some complicated polygons
Thanks, that's a great way to do it, Johan was just suggesting something
similar. We could also add a WHERE clause in the SQL to filter for one
country.
I would like to have your input on the whole picture on packaging
OpenHealthMapper with core GIS and health data. Here is a suggested
scenario:
1) Keep the world admin layers in PostGIS with LVLIDs and add point layers
for Health Facilities and Villages (also with LVLIDs), as well as regular
geometry tables for rivers and roads.
2) Use the above procedure to extract GeoJSON for a country for all the
polygon admin layers, rivers and roads.
3) Write a script to populate OHM source and organisationunit tables (and
perhaps also orgunitgroup/orgunitgroupmembers)
4) Import all SAM data to the same master OHM database.
5) Import all core health indicators from IMR (using SDMX)
6) Enhance the Metadata export to be able to pick just one branch of the OU
hierarchy (typically a country)
7) Export the metadata and include the DXF and the GeoJSON files with the
OHM installer for a country.
Comments welcome,
Knut
