dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/4/24 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.

Ah.  Object serialization ... we've been here before :-)

This is way off my patch, but doesn't GeoServer also generate KML?
And OpenLayers can read both.  Any particular reason for going the
GeoJSON route?  It only becomes an issue if we want to integrate
geo-spatial metadata with "general" dxf data as part of an export.
Then KML would be much handier.

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

Hadn't really planned to spend any time on it!  Mind you if you wanted
to include kml polygons it would be pretty straight forward:

<dxf  version="99" xmlns:dx="www.hisp.info/dxf"
xmlns:kml="http://www.opengis.net/kml/2.2"; >

<dx:OrganisationUnit name="country1">
   <kml:Polygon>....</kml:Polygon>
   <dx:OrganisationUnit name="state1">
      <kml:Polygon>....</kml:Polygon>
   <dx:OrganisationUnit name="state2">
      <kml:Polygon>....</kml:Polygon>
</dx:OrganisationUnit>

Cheers
Bob

>
> 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
>
> _______________________________________________
> 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
>