Hi I would not DROP GML support, just ADD support for importing shapefiles.
Regards from Sarpsborg, Norway Calle On 25 March 2015 at 14:23, Halvdan Grelland <halvda...@gmail.com> wrote: > I'm not really seeing any reason to drop GML support altogether, but the > prospect of letting users directly import shapefiles is an interesting one > for sure. I'd be very interested to have a look, Knut. > > As I'm sure you all know handling (and not to mention creating) GML is > fairly complex and I'm not really convinced moving the complexity from > established GIS suites like GDAL and QGIS and into DHIS2 itself is a clever > move. In fact I'm sure it would open up a whole new world of hurt. > > Jason is also right in assuming that accepting different coordinate > systems/projections would not be an easy fix but requires a major rewrite > which is, quite frankly, not worth the effort. The middle ground solution > to this would of course be to consume different projections and reproject > them into the desired format before storage but we're then introducing the > complexity I'm advicing against. > > > 2015-03-25 11:27 GMT+01:00 Jason Pickering <jason.p.picker...@gmail.com>: > >> >> Hi Knut, >> >> As for the app, I did not try it and agree with Calle that it is much >> easier for people to import a shape file directly. However, we do not >> always (but usually do) have a shapefile to import, so I would not be in >> favor of removing GML support at all. >> >> I seem to recall from a while back that it was not possible to update >> coordinates with the app. >> >> See below from our private correspondence on this a while back Knut >> (June 2014) >> >> >actually in a way it does work to update the existing OU, but the >> problem is, we need the shapfiles and matching dbf files. And some details >> of that dbf file need to match the existing OU details in the >db, which in >> case may be different. So I am looking though the solution that will help >> map the OU units with the existing OU units. I will soon post you on this. >> >> So, not sure that was sorted out and if the workflow of supporting update >> to coordinates is supported? >> >> @Calle, as for the WGS84 , agree that it would be "nice", but it would be >> a rather big change I suspect. At the moment, the coordinates are stored in >> the database without any reference to any geographical coordinate system >> whatsoever. So allowing anything other than EPSG:4326 would require that >> information to be stored some place and possibly reprojected into a single >> coordinate system prior to feeding it to the GIS. Would be nice to have, >> but not really sure how big of a change it would be, but does not feel like >> it would be trivial. >> >> Regards, >> Jason >> >> >> >> On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg <calle.hedb...@gmail.com> >> wrote: >> >>> Hi >>> >>> Another change that would be advantageous would also be to drop the >>> requirement that the datum have to be WGS-84 standard - some countries are >>> using other datum standards and might prefer to have all their data in that >>> datum. >>> >>> Note though, that this is less important in practice than the ability to >>> import shapefiles directly. >>> >>> Regards >>> Calle >>> >>> On 25 March 2015 at 12:11, Calle Hedberg <calle.hedb...@gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> HISP-SA would strongly support dropping the GML step - or at least to >>>> short-cut it with an option to import shapefiles directly. GML adds nothing >>>> to the mix, it just makes the process more cumbersome and "techie". >>>> >>>> Regards >>>> Calle >>>> >>>> On 24 March 2015 at 18:57, Knut Staring <knu...@gmail.com> wrote: >>>> >>>>> Hi Jason (and Halvdan), >>>>> >>>>> Not directly related, but since GML is coming up again, it could >>>>> perhaps be good to revisit Sushil's app, which is meant to bypass GML and >>>>> import shapefiles directly. >>>>> >>>>> If you (and others on the list) have some time, it would be good to >>>>> get more feedback on it. >>>>> >>>>> Knut >>>>> >>>>> On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland <halvda...@gmail.com >>>>> > wrote: >>>>> >>>>>> Yeah as discussed just now we should support output from qgis and >>>>>> gdal at least. Currently working on that. >>>>>> >>>>>> 2015-03-24 16:03 GMT+01:00 Jason Pickering < >>>>>> jason.p.picker...@gmail.com>: >>>>>> >>>>>>> I just exported this from QGIS. Would seem strange if we could not >>>>>>> support this,as it was just an export from a shape file. >>>>>>> >>>>>>> Regards >>>>>>> Jason >>>>>>> On Mar 24, 2015 9:30 AM, "Halvdan Grelland" <halvda...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Actually, small error in my example: pos elements should have lat >>>>>>>> and long separated by whitespace: >>>>>>>> >>>>>>>> <gml:pos>-45.046450667490049 30.904516454945856</gml:pos >>>>>>>> >>>>>>>> 2015-03-24 14:05 GMT+01:00 Halvdan Grelland <halvda...@gmail.com>: >>>>>>>> >>>>>>>>> By the way, here is the relevant quote from the GML Point Profile: >>>>>>>>> >>>>>>>>> "A Point is defined by a single coordinate tuple, with the >>>>>>>>> coordinate values being specified by the gml:pos property. Data >>>>>>>>> instances >>>>>>>>> compliant with this profile shall use only the gml:pos property." >>>>>>>>> >>>>>>>>> 2015-03-24 13:57 GMT+01:00 Halvdan Grelland <halvda...@gmail.com>: >>>>>>>>> >>>>>>>>>> The gml:Point element only supports gml:pos coordinate tuples (a >>>>>>>>>> single one, of course). The gml:coordinates element is expected to >>>>>>>>>> have >>>>>>>>>> multiple points, which is why it is parsed in that particular way. >>>>>>>>>> >>>>>>>>>> The only real bug on our part here is that we for some reason >>>>>>>>>> allow gml:Point to contain a gml:coordinates element with a single >>>>>>>>>> contained coordinate, thus being incorrectly output as seen in Jasons >>>>>>>>>> example. I realize we might have allowed this for a while, though, >>>>>>>>>> as the >>>>>>>>>> logics of this has remained unchanged by the recent GML importer >>>>>>>>>> rewrite. >>>>>>>>>> >>>>>>>>>> My suggestion is that we follow the standard GML point profile >>>>>>>>>> and remove support for gml:coordinates within gml:Point entirely. >>>>>>>>>> Jason, >>>>>>>>>> could you try with the following XML, please: >>>>>>>>>> >>>>>>>>>> <gml:featureMember> >>>>>>>>>> <ogr:OpenDemolandHealthFacilities >>>>>>>>>> fid="OpenDemolandHealthFacilities.4"> >>>>>>>>>> <ogr:geometryProperty><gml:Point >>>>>>>>>> srsName="EPSG:4326"><gml:pos>-45.046450667490049,30.904516454945856</gml:pos></gml:Point></ogr:geometryProperty> >>>>>>>>>> <ogr:Name>Crow Site</ogr:Name> >>>>>>>>>> <ogr:NAME_1>Bird</ogr:NAME_1> >>>>>>>>>> <ogr:Region>Animal</ogr:Region> >>>>>>>>>> <ogr:Country>Demoland</ogr:Country> >>>>>>>>>> </ogr:OpenDemolandHealthFacilities> >>>>>>>>>> </gml:featureMember> >>>>>>>>>> >>>>>>>>>> Of course, If you feel otherwise let me know. >>>>>>>>>> >>>>>>>>>> Halvdan >>>>>>>>>> >>>>>>>>>> 2015-03-24 13:09 GMT+01:00 Jan Henrik Ă˜verland < >>>>>>>>>> janhenrik.overl...@gmail.com>: >>>>>>>>>> >>>>>>>>>>> Halvdan, quick fix. Points should never have more than one set >>>>>>>>>>> of brackets. >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 24, 2015 at 12:01 PM, Jason Pickering < >>>>>>>>>>> jason.p.picker...@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi there. >>>>>>>>>>>> >>>>>>>>>>>> I am using the GML importer to import coordinates. >>>>>>>>>>>> >>>>>>>>>>>> Here is a snippet of the GML I am importing >>>>>>>>>>>> >>>>>>>>>>>> <gml:featureMember> >>>>>>>>>>>> <ogr:OpenDemolandHealthFacilities >>>>>>>>>>>> fid="OpenDemolandHealthFacilities.4"> >>>>>>>>>>>> <ogr:geometryProperty><gml:Point >>>>>>>>>>>> srsName="EPSG:4326"><gml:coordinates>-45.046450667490049,30.904516454945856</gml:coordinates></gml:Point></ogr:geometryProperty> >>>>>>>>>>>> <ogr:Name>Crow Site</ogr:Name> >>>>>>>>>>>> <ogr:NAME_1>Bird</ogr:NAME_1> >>>>>>>>>>>> <ogr:Region>Animal</ogr:Region> >>>>>>>>>>>> <ogr:Country>Demoland</ogr:Country> >>>>>>>>>>>> </ogr:OpenDemolandHealthFacilities> >>>>>>>>>>>> </gml:featureMember> >>>>>>>>>>>> >>>>>>>>>>>> This seems to import fine, but on the database side, I see this >>>>>>>>>>>> >>>>>>>>>>>> Crow Site | [[-45.0465,30.9045]] >>>>>>>>>>>> >>>>>>>>>>>> Note, the double square brackets. The GIS says there are no >>>>>>>>>>>> valid coordinates. >>>>>>>>>>>> >>>>>>>>>>>> When I replace these double brackets with single ones >>>>>>>>>>>> >>>>>>>>>>>> Crow Site | [-45.0465,30.9045] >>>>>>>>>>>> >>>>>>>>>>>> Things work OK. This is a 2.19 snapshot version, unsure of the >>>>>>>>>>>> revision. >>>>>>>>>>>> >>>>>>>>>>>> Is this an issue possibly with rev 18488? >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Jason >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Jason P. Pickering >>>>>>>>>>>> email: jason.p.picker...@gmail.com >>>>>>>>>>>> tel:+46764147049 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>>>>>>>>> Post to : dhis2-devs@lists.launchpad.net >>>>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>>> Post to : dhis2-devs@lists.launchpad.net >>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Knut Staring >>>>> Dept. of Informatics, University of Oslo >>>>> Norway: +4791880522 >>>>> Skype: knutstar >>>>> http://dhis2.org >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~dhis2-devs >>>>> Post to : dhis2-devs@lists.launchpad.net >>>>> Unsubscribe : https://launchpad.net/~dhis2-devs >>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> ******************************************* >>>> >>>> Calle Hedberg >>>> >>>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA >>>> >>>> Tel/fax (home): +27-21-685-6472 >>>> >>>> Cell: +27-82-853-5352 >>>> >>>> Iridium SatPhone: +8816-315-19274 >>>> >>>> Email: calle.hedb...@gmail.com >>>> >>>> Skype: calle_hedberg >>>> >>>> ******************************************* >>>> >>>> >>> >>> >>> -- >>> >>> ******************************************* >>> >>> Calle Hedberg >>> >>> 46D Alma Road, 7700 Rosebank, SOUTH AFRICA >>> >>> Tel/fax (home): +27-21-685-6472 >>> >>> Cell: +27-82-853-5352 >>> >>> Iridium SatPhone: +8816-315-19274 >>> >>> Email: calle.hedb...@gmail.com >>> >>> Skype: calle_hedberg >>> >>> ******************************************* >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >>> >> >> >> -- >> Jason P. Pickering >> email: jason.p.picker...@gmail.com >> tel:+46764147049 >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~dhis2-devs >> Post to : dhis2-devs@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~dhis2-devs >> More help : https://help.launchpad.net/ListHelp >> >> > -- ******************************************* Calle Hedberg 46D Alma Road, 7700 Rosebank, SOUTH AFRICA Tel/fax (home): +27-21-685-6472 Cell: +27-82-853-5352 Iridium SatPhone: +8816-315-19274 Email: calle.hedb...@gmail.com Skype: calle_hedberg *******************************************
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp