dhis2-devs team mailing list archive

[Calle Hedberg <calle.hedberg@xxxxxxxxx>]

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 <halvdanhg@xxxxxxxxx> 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.pickering@xxxxxxxxx>:
>
>>
>> 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.hedberg@xxxxxxxxx>
>> 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.hedberg@xxxxxxxxx>
>>> 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 <knutst@xxxxxxxxx> 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 <halvdanhg@xxxxxxxxx
>>>>> > 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.pickering@xxxxxxxxx>:
>>>>>>
>>>>>>> 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" <halvdanhg@xxxxxxxxx>
>>>>>>> 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 <halvdanhg@xxxxxxxxx>:
>>>>>>>>
>>>>>>>>> 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 <halvdanhg@xxxxxxxxx>:
>>>>>>>>>
>>>>>>>>>> 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.overland@xxxxxxxxx>:
>>>>>>>>>>
>>>>>>>>>>> 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.pickering@xxxxxxxxx> 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.pickering@xxxxxxxxx
>>>>>>>>>>>> tel:+46764147049
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>>> 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.hedberg@xxxxxxxxx
>>>>
>>>> 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.hedberg@xxxxxxxxx
>>>
>>> Skype: calle_hedberg
>>>
>>> *******************************************
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@xxxxxxxxx
>> tel:+46764147049
>>
>> _______________________________________________
>> 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
>>
>>
>


-- 

*******************************************

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.hedberg@xxxxxxxxx

Skype: calle_hedberg

*******************************************