dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

The new GIS solution for DHIS 2 is not using KML, but GeoJSON.
Conversion between these formats and PostGIS or Mysql/H2 spatial
tables is possible, but for now we will mainly be using JSON files
generated by GeoServer.

KML is an interesting format, and there is also a lot of possibilities
for using Google's maps. But I don't think you should spend time on
including polygon geometries in the DXF yet. Point coordinates could
perhaps be included, that's cheap.

But the InSTEDD toolset definitely has a lot to offer.

k

On 4/24/09, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> 2009/4/24 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
>> A timestamp diff instead of file-based diff. Getting a new export out
>> and then doing a file diff with last export is a huge overhead.
>
> OK.  So Lars' suggestion of using lastUpdated flag solves this problem?
>
>> As for gis import export, i suggested we add something 2 the
>> blueprint. Either in dxf or java object serialization. Both have some
>> merits/demerits wrt our prob. Oracle had that gis type in the db for
>> something. Those arguments are valid in our context.
>
> OK.  Add something to the blueprint and lets look at it.  I notice the
> mesh4x project which Knut has been getting charmed with is using KML.
> As is OpenLayers.  Probably would make sense to use that.  Either way
> we need to look first at what GIS data we would be
> importing/exporting.
>
> Talking of spatial extensions to databases I was mildly shocked to see
> that h2 has an interesting extension
> http://geosysin.iict.ch/irstv-trac/wiki/H2spatial/Download .
>
> Cheers
> Bob
>
>> On 4/24/09, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
>>> 2009/4/23 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
>>>> Since this discussion moved from roadmap to import-export and then
>>>> interchange formats... lemme add something to chew for on
>>>> import-export.
>>>>
>>>> Why aren't we using a diff-based import-export?? Suppose I already have
>>>> an
>>>> exported file and the new export file only should contain the new
>>>> values,
>>>> we
>>>> can generate only the changed values in the export process. Definitely
>>>> reduces time/ file size for places where import-export will be used
>>>> monthly/weekly.
>>>
>>> Thinking out loud:  the problem with a diff is that you need to have
>>> something to diff against.  So the program would have to be able to
>>> read the exported file you already have in order to un-select these
>>> values from the set in order to export.  On the other hand it would be
>>> quite trivial (and maybe in the end quicker) to have a dxf-diff
>>> process which can generate the difference between two exported files.
>>> Still its an interesting thought ...
>>>
>>>> Has anyone thought of object serialization?? Where we could serialize
>>>> objects and move it to new places... A radical and stupid way, but may
>>>> be
>>>> useful for GIS import-export, where the dxf format may fall short on
>>>> representing sharable geographic information. Disease surveillance on
>>>> the
>>>> CBHS may be one candidate...
>>>
>>> Can of worms here - the respective merits of native serializing
>>> (presumably) vs serializing to XML.  Personally I would always go for
>>> the latter.
>>>
>>> I am not up to speed on exactly what shareable geographic information
>>> we might want to share, but it makes sense to use an open geographical
>>> markup language to do it (like GML) rather than trying to reinvent the
>>> wheel in dxf.  Spurious example:
>>>
>>> <dxf xmlns:dx="www.hisp.info/dxf"
>>> xmlns:gml="http://www.opengis.net/gml/3.2
>>>>
>>>
>>> <dx:DataValue DateElement=... Value="32" >
>>>    <dx:Location>
>>>       <gml:Point>
>>>        <gml:coordinates>100,200</gml:coordinates>
>>>     </gml:Point>
>>>    </dx:Location>
>>> </dx:DataValue>
>>>
>>> Thats not a good example.  Real life might be more interesting ... but
>>> there is no good reason why we couldn't quite easily get geographic
>>> information into dxf.  The beauty of namespaces.
>>>
>>> Cheers
>>> Bob
>>>
>>>>
>>>> ---
>>>> Regards,
>>>> Saptarshi PURKAYASTHA
>>>> Director R & D, HISP India
>>>> Health Information Systems Programme
>>>>
>>>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>>>> You Live by CHOICE, Not by CHANCE
>>>>
>>>>
>>>> 2009/4/24 Bob Jolliffe <bobjolliffe@xxxxxxxxx>
>>>>>
>>>>> 2009/4/23 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>>>>> >
>>>>> >>
>>>>> >> 6 complicates the current import strategy where objects get
>>>>> >> imported
>>>>> >> "on
>>>>> >> the fly" without temporary storage, maybe we can put this on hold.
>>>>> >
>>>>> > Actually this holds for 5 as well...
>>>>> >
>>>>>
>>>>> I'll have to look at this more closely - though I know you will have a
>>>>> better idea of what is going on.  In principle it shouldn't really
>>>>> matter.  All that's happening in 5 is that we import a <Period> object
>>>>> (on the fly, in its entirety or what have you).  Then we just use the
>>>>> inherited periodID attribute as we import all the contained
>>>>> dataValues.  I am not seeing how this would be fundamentally
>>>>> different.  Could be I'm just tired and in need of a beer ...
>>>>>
>>>>> Cheers
>>>>> Bob
>>>>
>>>>
>>>
>>
>> --
>> Sent from my mobile device
>>
>> ---
>> Regards,
>> Saptarshi PURKAYASTHA
>> Director R & D, HISP India
>> Health Information Systems Programme
>>
>> My Tech Blog:  http://sunnytalkstech.blogspot.com
>> You Live by CHOICE, Not by CHANCE
>>
>


-- 
Cheers,
Knut Staring