dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Wed, May 19, 2010 at 6:18 PM, Jason Pickering
<jason.p.pickering@xxxxxxxxx> wrote:

> I have understood from the beginning of the DHIS2 GIS client, that it
> was based on simplicity and speed. I think it has been a great
> success, and achieved much more than I really thought possible in such
> a short time. I do not think we should complicate things too much and
> lose sight of the original intentions of the DHIS2 GIS client.
>
> However, I would like to see that DHIS2 can either 1) serve as a
> repository of GIS data, in which case it needs to be able to support
> things like GML or projection definitions to serve to external clients
> that may need this OR 2) consume data in standard formats from another
> repository. Both would be great of course, but we do not want to
> rewrite Geoserver.

Indeed. We may at some point wish to package Geoserver, but that would
add both to the size on disk and in RAM, so should be optional. And I
don't think we need it yet.

>I think there is a blueprint out there that would
> allow (when implemented) DHIS to consume data from a WFS, and then
> transform this data into its own internal representation (In this
> case, GeoJSON).  It is also theoretically possible to use the
> Geoserver, with an attribute or view, to present to Geoserver, which
> could handle the heavy WFS/WMS lifting if required.
>
> I guess I am sort of favoring implementing some sort of GML support,
> as this would pretty much easily allow other clients to take a DXF
> file and transform it into something that they could use directly.

This is a very good point - we want DHIS 2 to be a national repository
of facilities and data, and this certainly also includes their
placement (i.e. lat/lon), but probably also administrative boundaries.
And we want it to be easy to distribute and share this, i.e. it should
be in DXF. Using GML for this makes a lot of sense, and adding  XSLT
could give us the popular KML as an option:
http://members.home.nl/cybarber/geomatters/GML2KML.xslt

>If
> the internal representation of the data is needed in GeoJSON for
> performance and simplicity reasons, I think this might be OK for now.
> However, I think what is represented in the DXF (or SDMX-HD) file,
> which may be used by either DHIS2 systems or other systems, then
> representing the point/polygon in GML would be a more standards based
> approach. One possible way would be to store the data in native GML
> format, and then transform it into GeoJSON (sort of like a data mart)
> for presentation to the mapping client.

I don't think we want to do this transformation on the fly. It is an
empirical question whether it would be as fast to serve GML to
OpenLayers as it is currently to serve GeoJSON. I guess it would be
possible to store both representations in different fields, but that
seems fraught with difficulty as well. My hunch is to keep the GeoJSON
representation in the db and generate GML for export, and likewise be
able to absorb GML import - I could be mistaken. Of course, if we
don't worry about the administrative boundaries things become a hell
of a lot simpler - but I think we have to.

k

>  Just some ideas...
>
> Regards,
> Jason
>
>
> 2010/5/19 Bob Jolliffe <bobjolliffe@xxxxxxxxx>:
>> Just took a very quick look at the schema for gmlSimpleFeaturesProfile
>> (attached).
>>
>> It is a limited subset of gml which allows (amongst others) the
>> following simple constructs
>>
>> <!--<Polygon xmlns="http://www.opengis.net/gml";
>>    <interior>
>>        <LinearRing>
>>            <posList>
>>                10 10
>>                20 20
>>                25 32
>>                12 45
>>                22 45
>>            </posList>
>>        </LinearRing>
>>    </interior>
>>    </Polygon>-->
>>
>> <!--<Point xmlns="http://www.opengis.net/gml";>
>>    <pos>10 10</pos>
>> </Point>-->
>>
>> We'll see what Knut provides back and see whether these are
>> sufficient, but these do seem to to map against what we have.  There
>> are of course additional optional attributes and elements but if we
>> don't model them we don't need to produce them.  Not sure if I go for
>> all the inner ring stuff but then again what I know about GIS I could
>> write on the back of a cigarette box.  Others will know better.
>>
>> Regards
>> Bob
>>
>> 2010/5/19 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>>>
>>> Thanks for valuable input. Using GML in one way or the other was part of the
>>> plan as it seems the most versatile format among those produced by
>>> Geoserver.
>>> Before deciding I really need to see some more examples of Shapefiles. The
>>> ones for SL are a bit weird as Geoserver produces invalid XML when exporting
>>> the facility layer to GML (one reason is that the name column is called
>>> "name of fa" and that is attempted translated into an xml element).
>>> Does anyone have a couple of "standard" shapefiles? I guess the WHO ones are
>>> the closet we get to that. Knut, could you provide some more examples of
>>> that (without me having to sign and fax a bunch of forms like last time:-) ?
>>> Lars
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dhis2-devs
>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
>
> --
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+260968395190
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Cheers,
Knut Staring