dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

> No 2 is exactly what it was like a couple of months ago. We decided to read
>> local GeoJSON files instead, because we wanted to leave out Geoserver to get
>> rid of those ~50 mb. It is also a lot easier for nontechnicals to receive a
>> GeoJSON file and make use of it compared to getting a set of shapefiles and
>> not being familiar with Geoserver.
>>
>>
Sure, I understand this, and I think it is a good choice. For bigger
installations however, I think having the option to use a WFS to get the
GeoJSON dynamically, is a must.
Typically, if you are managing say a layer of health facilities, you would
use a GeoDatabase or shape file for this purpose. It would be come
cumbersome to manage both a shapefile as well as a GeoJSON file and keep
them up in sync with each other. It would be preferable to manage the
geographical data in one place, and then let a WFS server like Geoserver
worry about the translation between whatever format the geodatabase is in
(PostGIS, ArcSDE, Personal Geodatabase, shapefile, etc) and what the output
format is. DHIS GIS needs GeoJSON, but you might also want to be able to
export to KML. Anyway, I think it is clear. It would be a nice to have at
some point in time, but not crucial right nw.

> Is it possible to dynamically produce a list of shapefiles currenty
>> available in your Geoserver installation? Like the new combo box lists the
>> available files in DHIS2_HOME/geojson ?
>>
>
> Yes - this is an important feature. Actually the GeoExt based GeoExplorer
> that Johan L. has been working on has a very nice layer selector:
> http://geoext.opengeo.org/geoexplorer/preview/
>
> GeoExplorer uses a GetCapabilities request to generate the list of possible
layers.

http://apps.who.int/tools/geoserver/ows?service=WFS&request=GetCapabilitieswill
return an XML file of possible layers, as well as possible output
formats (JSON for instance). Once the layer has been selected,
http://mygeoserverlocation/geoserver/wfs?request=GetFeature&typename=mylayer&outputformat=json<http://localhost:8080/geoserver/wfs?request=GetFeature&typename=topp:states&maxfeatures=1&outputformat=json>
will return the layer as JSON.

Obviously, extending the ability of the client to consume remote WMS layers
would be good as well. We (meaning WHO) have been talking to groups like IRI
on the exposure of rainfall anomaly and other risk maps for the purposes of
calculating malaria risk. They are working on exposing their data via WMS
(see
http://iri.columbia.edu/climate/forecast/net_asmt/2009/aug2009/SON09_Afr_pcp.htmlfor
an example although this is not yet a WMS layers). Being able to
include
maps from remote servers, such as IRI, NASA, FAO, etc would be allow a lot
of flexibility in terms of the types of maps that could be produced.
OpenLayers can handle all of this with no issues, so it is probably just a
matter of extending the code a bit.

Shall I write it up as a blueprint? ;-)


Regards,
Jason