dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Fri, Sep 11, 2009 at 1:12 PM, Jason Pickering <
jason.p.pickering@xxxxxxxxx> wrote:

>
> 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? ;-)
>

Yes, please. And add a link to the blueprint in the new wikipage below (I
can give you edit rights if you dont have them):
http://www.openhealthconsortium.org/wiki/doku.php?id=HealthMapper


>
>
> Regards,
> Jason
>
>
>


-- 
Cheers,
Knut Staring