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 <[email protected]> wrote: > 2009/4/24 Saptarshi Purkayastha <[email protected]>: >> 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 <[email protected]> wrote: >>> 2009/4/23 Saptarshi Purkayastha <[email protected]>: >>>> 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 <[email protected]> >>>>> >>>>> 2009/4/23 Lars Helge Øverland <[email protected]>: >>>>> > >>>>> >> >>>>> >> 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 : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
