dhis2-devs team mailing list archive

[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.

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.

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