Possible issue with GML import

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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@gmail.com
tel:+46764147049

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@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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

···

2015-03-24 14:05 GMT+01:00 Halvdan Grelland halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Fixed in latest 2.17 -> trunk.

···

2015-03-24 16:05 GMT+01:00 Halvdan Grelland halvdanhg@gmail.com:

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@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

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


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

On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.hedberg@gmail.com

Skype: calle_hedberg


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@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 knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.hedberg@gmail.com

Skype: calle_hedberg


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


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

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.hedberg@gmail.com

Skype: calle_hedberg


We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)

···

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Knut Staring

Dept. of Informatics, University of Oslo

Norway: +4791880522

Skype: knutstar

http://dhis2.org

Dropping support for GML really makes no sense and I am totally against it.

As there are potentially many clients of DHIS2 which will never generate a shape file. I just discussed last week a use case where an external system would need to integrate with DHIS2, and there would need to be an automatic way of importing the coordinates and/or polygon geometry. Since this external system would never generate a shape file (but could generate a standard format like GML), how would you propose to solve this use case by dropping GML support Callle?

GML is more standard than our own approach to storing something which is similar to GeoJSON as coordinates, and will thus, allow more integration opportunities.

From an open source point of view we should be using open standards based approaches, like GML and other standards recommended by OGC, instead of locking people into importing geometries with only a single proprietary format.

Nothing wrong at all with importing the shape files however, but the last time I tried that client Knut, it did not work for me (or at least the worklfow which I needed).

Regards,

Jason

···

On Fri, Mar 27, 2015 at 12:41 PM, Knut Staring knutst@gmail.com wrote:

We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)


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

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Jason P. Pickering
email: jason.p.pickering@gmail.com
tel:+46764147049

Yes I did. Fixes should be in revision 18306 of 2.18. Could you send me any relevant logs or even GML files? I’d like to have a look.

···

2015-03-27 12:41 GMT+01:00 Knut Staring knutst@gmail.com:

We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Someone pointed out that I misread your email Calle, which I did. Glad that we are all in agreement!

···

On Fri, Mar 27, 2015 at 12:41 PM, Knut Staring knutst@gmail.com wrote:

We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)


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.pickering@gmail.com
tel:+46764147049

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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

Jason

I though I made it clear that I do NOT want to drop GML support - just add shapefile support.

Regards

Calle

···

On 27 March 2015 at 13:51, Jason Pickering jason.p.pickering@gmail.com wrote:

Dropping support for GML really makes no sense and I am totally against it.

As there are potentially many clients of DHIS2 which will never generate a shape file. I just discussed last week a use case where an external system would need to integrate with DHIS2, and there would need to be an automatic way of importing the coordinates and/or polygon geometry. Since this external system would never generate a shape file (but could generate a standard format like GML), how would you propose to solve this use case by dropping GML support Callle?

GML is more standard than our own approach to storing something which is similar to GeoJSON as coordinates, and will thus, allow more integration opportunities.

From an open source point of view we should be using open standards based approaches, like GML and other standards recommended by OGC, instead of locking people into importing geometries with only a single proprietary format.

Nothing wrong at all with importing the shape files however, but the last time I tried that client Knut, it did not work for me (or at least the worklfow which I needed).

Regards,

Jason

On Fri, Mar 27, 2015 at 12:41 PM, Knut Staring knutst@gmail.com wrote:

We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)


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.pickering@gmail.com
tel:+46764147049

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.hedberg@gmail.com

Skype: calle_hedberg


Ooops - and I didn’t see your clarification

Yeah - good we are in agreement (Halvdan is sceptical, but that’s probably because he suspect he will have to do the actual work

Regards
Calle

···

On 27 March 2015 at 19:10, Calle Hedberg calle.hedberg@gmail.com wrote:

Jason

I though I made it clear that I do NOT want to drop GML support - just add shapefile support.

Regards

Calle

On 27 March 2015 at 13:51, Jason Pickering jason.p.pickering@gmail.com wrote:

Dropping support for GML really makes no sense and I am totally against it.

As there are potentially many clients of DHIS2 which will never generate a shape file. I just discussed last week a use case where an external system would need to integrate with DHIS2, and there would need to be an automatic way of importing the coordinates and/or polygon geometry. Since this external system would never generate a shape file (but could generate a standard format like GML), how would you propose to solve this use case by dropping GML support Callle?

GML is more standard than our own approach to storing something which is similar to GeoJSON as coordinates, and will thus, allow more integration opportunities.

From an open source point of view we should be using open standards based approaches, like GML and other standards recommended by OGC, instead of locking people into importing geometries with only a single proprietary format.

Nothing wrong at all with importing the shape files however, but the last time I tried that client Knut, it did not work for me (or at least the worklfow which I needed).

Regards,

Jason


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@gmail.com

Skype: calle_hedberg


On Fri, Mar 27, 2015 at 12:41 PM, Knut Staring knutst@gmail.com wrote:

We should definitely have both. Halvdan, did you backport the fix you made to 2.18? I just tried importing there but nothing happens on the client (haven´t yet asked for the server log)


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.pickering@gmail.com
tel:+46764147049

On Fri, Mar 27, 2015 at 12:39 PM, Calle Hedberg calle.hedberg@gmail.com wrote:

Hi

I would not DROP GML support, just ADD support for importing shapefiles.

Regards from Sarpsborg, Norway
Calle


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

On 25 March 2015 at 14:23, Halvdan Grelland halvdanhg@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.


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@gmail.com

Skype: calle_hedberg


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


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

On Wed, Mar 25, 2015 at 6:13 AM, Calle Hedberg calle.hedberg@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


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.pickering@gmail.com
tel:+46764147049

On 25 March 2015 at 12:11, Calle Hedberg calle.hedberg@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


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@gmail.com

Skype: calle_hedberg


On 24 March 2015 at 18:57, Knut Staring knutst@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


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.hedberg@gmail.com

Skype: calle_hedberg


On Tue, Mar 24, 2015 at 4:05 PM, Halvdan Grelland halvdanhg@gmail.com wrote:

Yeah as discussed just now we should support output from qgis and gdal at least. Currently working on that.


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

2015-03-24 16:03 GMT+01:00 Jason Pickering jason.p.pickering@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” halvdanhg@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 halvdanhg@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 halvdanhg@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.pickering@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:NameCrow Site</ogr:Name>

ogr:NAME_1Bird</ogr:NAME_1>

ogr:RegionAnimal</ogr:Region>

ogr:CountryDemoland</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@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.hedberg@gmail.com

Skype: calle_hedberg