Problems with GeoJSON uploads

Support - Assistance technique
1

Hi Devs,

I am attempting to directly update the coordinates using the WebAPI, but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.

  1. Use MapShaper to simplify the coordinates.

  2. Export as GeoJSON.

  3. Use curl to PUT the coordinates to the correct end point, e.g. http://myserver/api/organisationUnits/abcd1234/coordinates

  4. Use curl to PUT the feature type (either “POLYGON” or “MULTI_POLYGON”) depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like this.

Sample polygon…

{

  • featureType: “POLYGON”,

  • coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],



Sample MultiPolygon:



{

  • featureType: “MULTI_POLYGON”,

  • coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]…

In the GIS client, when loading any of the MultiPolygon’s I get

Uncaught TypeError: Cannot read property ‘length’ of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

Regards,

Jason

···

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

2

Hi Jason

Do we actually support anything other than MultiPolygons and Points? For my GeoJson exporter, I default to MultiPolygon unless its a Point.

I have been able to successfully render all geojson using http://geojson.io

What is supported by GIS, I don’t know, Jan would have to explain that.

···

On Tue, Jan 5, 2016 at 7:16 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,

I am attempting to directly update the coordinates using the WebAPI, but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.

  1. Use MapShaper to simplify the coordinates.
  1. Export as GeoJSON.
  1. Use curl to PUT the coordinates to the correct end point, e.g. http://myserver/api/organisationUnits/abcd1234/coordinates
  1. Use curl to PUT the feature type (either “POLYGON” or “MULTI_POLYGON”) depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like this.

Sample polygon…

{
  • featureType: “POLYGON”,
  • coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],



Sample MultiPolygon:




{
  • featureType: “MULTI_POLYGON”,
  • coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]…

In the GIS client, when loading any of the MultiPolygon’s I get

Uncaught TypeError: Cannot read property ‘length’ of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

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

–
Morten

3

Hi Morten,

I am not sure what we support, but there are three feature types as far as I know: Points ,Polygons and MultiPolygons. If we only support MultiPolys, that would imply that all Polys would need to be converted prior to import into DHIS2, which is fine, but based on my mail previously, it seems that it must be exactly the opposite, namely converting Multi-Polys to Polys.

I was able to render a file with both MultiPolys as well as Polygons in this client without issues, which had been exported from a shape file to GeoJSON using ogr2ogr.

Jan, could you offer any insight into how to handle Polygons and Multi-polygons?

Regards,
Jason

···

On Fri, Jan 8, 2016 at 6:41 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Jason

Do we actually support anything other than MultiPolygons and Points? For my GeoJson exporter, I default to MultiPolygon unless its a Point.

I have been able to successfully render all geojson using http://geojson.io

What is supported by GIS, I don’t know, Jan would have to explain that.

–

–
Morten

On Tue, Jan 5, 2016 at 7:16 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,

I am attempting to directly update the coordinates using the WebAPI, but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.

  1. Use MapShaper to simplify the coordinates.
  1. Export as GeoJSON.
  1. Use curl to PUT the coordinates to the correct end point, e.g. http://myserver/api/organisationUnits/abcd1234/coordinates
  1. Use curl to PUT the feature type (either “POLYGON” or “MULTI_POLYGON”) depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like this.

Sample polygon…

{
  • featureType: “POLYGON”,
  • coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],



Sample MultiPolygon:




{
  • featureType: “MULTI_POLYGON”,
  • coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]…

In the GIS client, when loading any of the MultiPolygon’s I get

Uncaught TypeError: Cannot read property ‘length’ of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

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

4

Hi Jason, how did you get five levels of square brackets? Ps should have three, MPs should have four: http://geojson.org/geojson-spec.html#id4

At the moment the GML importer eats both Ps and MPs, but stores them all as MPs (four brackets) as far as I know. Makes it less complex on both ends.

I can see the problem though when someone who knows what he’s doing wants to PUT geojson directly (plumbers…) and his file is full of Ps. It’s still recommended to let the GML importer process it (validation / chops polygon coordinates to six decimals etc), but I just commited a fix to the GIS app (trunk and 2.21) that makes sure valid polygons (three brackets) are rendered, regardless of the feature type.

Hope that helps.

···

On Fri, Jan 8, 2016 at 8:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Morten,

I am not sure what we support, but there are three feature types as far as I know: Points ,Polygons and MultiPolygons. If we only support MultiPolys, that would imply that all Polys would need to be converted prior to import into DHIS2, which is fine, but based on my mail previously, it seems that it must be exactly the opposite, namely converting Multi-Polys to Polys.

I was able to render a file with both MultiPolys as well as Polygons in this client without issues, which had been exported from a shape file to GeoJSON using ogr2ogr.

Jan, could you offer any insight into how to handle Polygons and Multi-polygons?

Regards,
Jason

On Fri, Jan 8, 2016 at 6:41 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Jason

Do we actually support anything other than MultiPolygons and Points? For my GeoJson exporter, I default to MultiPolygon unless its a Point.

I have been able to successfully render all geojson using http://geojson.io

What is supported by GIS, I don’t know, Jan would have to explain that.

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

–
Morten

On Tue, Jan 5, 2016 at 7:16 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,

I am attempting to directly update the coordinates using the WebAPI, but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.

  1. Use MapShaper to simplify the coordinates.
  1. Export as GeoJSON.
  1. Use curl to PUT the coordinates to the correct end point, e.g. http://myserver/api/organisationUnits/abcd1234/coordinates
  1. Use curl to PUT the feature type (either “POLYGON” or “MULTI_POLYGON”) depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like this.

Sample polygon…

{
  • featureType: “POLYGON”,
  • coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],



Sample MultiPolygon:




{
  • featureType: “MULTI_POLYGON”,
  • coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]…

In the GIS client, when loading any of the MultiPolygon’s I get

Uncaught TypeError: Cannot read property ‘length’ of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

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

5

Hi Jan,
Let me describe the full work flow.

  1. Shape files were simplified and exported with MapShaper to GeoJSON.

  2. The shapefiles DBF were read and the JSON payload for all the orgunits was created (according to DHIS2 metadata requirements)

  3. The GeoJSON list was read, and joined with the rest of the metadata. The reason for the five brackets instead of four, was that when I had three brackets for Polygons, this did not work. The five brackets resulted from the fact that the GeoJSON list was itself a list. Thus, it had five brackets, instead of four. I was thinking that maybe the polygon’s needed to be contained by a list (thus the reason for four brackets instead of three).

  4. This was then uploaded as JSON to the DHIS2 metadata API.

GML was not used, as this system was being “booted” from scratch basically, and it was deemed easier to try and create all the metadata in one step.

So, I guess the fix which is needed is that Polygon segments should have three brackets, and MultiPolys should have four brackets, then I think we are good. I am not sure that we need to worry about whether Polys are actually stored as MPs or the other way around. So if I understand you correctly, if I upload a GeoJSON segment with three brackets (a poly) it will work, as will a multi-poly (four brackets)?

Regards,

Jason

···

On Fri, Jan 8, 2016 at 11:39 AM, Jan Henrik Øverland janhenrik.overland@gmail.com wrote:

Hi Jason, how did you get five levels of square brackets? Ps should have three, MPs should have four: http://geojson.org/geojson-spec.html#id4

At the moment the GML importer eats both Ps and MPs, but stores them all as MPs (four brackets) as far as I know. Makes it less complex on both ends.

I can see the problem though when someone who knows what he’s doing wants to PUT geojson directly (plumbers…) and his file is full of Ps. It’s still recommended to let the GML importer process it (validation / chops polygon coordinates to six decimals etc), but I just commited a fix to the GIS app (trunk and 2.21) that makes sure valid polygons (three brackets) are rendered, regardless of the feature type.

Hope that helps.

–

On Fri, Jan 8, 2016 at 8:10 AM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Morten,

I am not sure what we support, but there are three feature types as far as I know: Points ,Polygons and MultiPolygons. If we only support MultiPolys, that would imply that all Polys would need to be converted prior to import into DHIS2, which is fine, but based on my mail previously, it seems that it must be exactly the opposite, namely converting Multi-Polys to Polys.

I was able to render a file with both MultiPolys as well as Polygons in this client without issues, which had been exported from a shape file to GeoJSON using ogr2ogr.

Jan, could you offer any insight into how to handle Polygons and Multi-polygons?

Regards,
Jason

On Fri, Jan 8, 2016 at 6:41 AM, Morten Olav Hansen mortenoh@gmail.com wrote:

Hi Jason

Do we actually support anything other than MultiPolygons and Points? For my GeoJson exporter, I default to MultiPolygon unless its a Point.

I have been able to successfully render all geojson using http://geojson.io

What is supported by GIS, I don’t know, Jan would have to explain that.

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

–
Morten

On Tue, Jan 5, 2016 at 7:16 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Hi Devs,

I am attempting to directly update the coordinates using the WebAPI, but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.

  1. Use MapShaper to simplify the coordinates.
  1. Export as GeoJSON.
  1. Use curl to PUT the coordinates to the correct end point, e.g. http://myserver/api/organisationUnits/abcd1234/coordinates
  1. Use curl to PUT the feature type (either “POLYGON” or “MULTI_POLYGON”) depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like this.

Sample polygon…

{
  • featureType: “POLYGON”,
  • coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],



Sample MultiPolygon:




{
  • featureType: “MULTI_POLYGON”,
  • coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]…

In the GIS client, when loading any of the MultiPolygon’s I get

Uncaught TypeError: Cannot read property ‘length’ of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

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

6

Hi Jan,
Let me describe the full work flow.

1) Shape files were simplified and exported with MapShaper to GeoJSON.
2) The shapefiles DBF were read and the JSON payload for all the orgunits
was created (according to DHIS2 metadata requirements)
3) The GeoJSON list was read, and joined with the rest of the metadata.
The reason for the five brackets instead of four, was that when I had three
brackets for Polygons, this did not work. The five brackets resulted from
the fact that the GeoJSON list was itself a list. Thus, it had five
brackets, instead of four. I was thinking that maybe the polygon's needed
to be contained by a list (thus the reason for four brackets instead of
three).
4) This was then uploaded as JSON to the DHIS2 metadata API.

GML was not used, as this system was being "booted" from scratch
basically, and it was deemed easier to try and create all the metadata in
one step.

So, I guess the fix which is needed is that Polygon segments should have
three brackets, and MultiPolys should have four brackets, then I think we
are good. I am not sure that we need to worry about whether Polys are
actually stored as MPs or the other way around. So if I understand you
correctly, if I upload a GeoJSON segment with three brackets (a poly) it
will work, as will a multi-poly (four brackets)?

Correct

···

On Fri, Jan 8, 2016 at 1:21 PM, Jason Pickering <jason.p.pickering@gmail.com > wrote:

Regards,
Jason

On Fri, Jan 8, 2016 at 11:39 AM, Jan Henrik Øverland < > janhenrik.overland@gmail.com> wrote:

Hi Jason, how did you get five levels of square brackets? Ps should have
three, MPs should have four: Obsolete

At the moment the GML importer eats both Ps and MPs, but stores them all
as MPs (four brackets) as far as I know. Makes it less complex on both ends.

I can see the problem though when someone who knows what he's doing wants
to PUT geojson directly (plumbers...) and his file is full of Ps. It's
still recommended to let the GML importer process it (validation / chops
polygon coordinates to six decimals etc), but I just commited a fix to the
GIS app (trunk and 2.21) that makes sure valid polygons (three brackets)
are rendered, regardless of the feature type.

Hope that helps.

On Fri, Jan 8, 2016 at 8:10 AM, Jason Pickering < >> jason.p.pickering@gmail.com> wrote:

Hi Morten,

I am not sure what we support, but there are three feature types as far
as I know: Points ,Polygons and MultiPolygons. If we only support
MultiPolys, that would imply that all Polys would need to be converted
prior to import into DHIS2, which is fine, but based on my mail previously,
it seems that it must be exactly the opposite, namely converting
Multi-Polys to Polys.

I was able to render a file with both MultiPolys as well as Polygons in
this client without issues, which had been exported from a shape file to
GeoJSON using ogr2ogr.

Jan, could you offer any insight into how to handle Polygons and
Multi-polygons?

Regards,
Jason

On Fri, Jan 8, 2016 at 6:41 AM, Morten Olav Hansen <mortenoh@gmail.com> >>> wrote:

Hi Jason

Do we actually support anything other than MultiPolygons and Points?
For my GeoJson exporter, I default to MultiPolygon unless its a Point.

I have been able to successfully render all geojson using
http://geojson.io

What is supported by GIS, I don't know, Jan would have to explain that.

--
Morten

On Tue, Jan 5, 2016 at 7:16 PM, Jason Pickering < >>>> jason.p.pickering@gmail.com> wrote:

Hi Devs,
I am attempting to directly update the coordinates using the WebAPI,
but am running into issues with the formatting (I think) of JSON fragments.

The worflow is as follows.
1) Use MapShaper to simplify the coordinates.
2) Export as GeoJSON.
3) Use curl to PUT the coordinates to the correct end point, e.g.
http://myserver/api/organisationUnits/abcd1234/coordinates
4) Use curl to PUT the feature type (either "POLYGON" or
"MULTI_POLYGON") depending on what is reported by the GeoJSON.

That part seems to work fine and I get something which looks like
this.

Sample polygon..

{

   - featureType: "POLYGON",
   - coordinates: "[[[[125.8054,-8.7452],[125.8038,-8.7455],[125.8031,-8.7455],[125.8031,-8.7471],[125.8028,-8.748],[125.8021,-8.7488],[125.8013,-8.7492],[125.8004,-8.7494],

Sample MultiPolygon:

{

   - featureType: "MULTI_POLYGON",
   - coordinates: "[[[[[127.3286,-8.448],[127.3281,-8.4479],[127.3272,-8.4476],[127.3271,-8.4473],[127.3267,-8.447],[127.3254,-8.4473],[127.3251,-8.4471],[127.3249,-8.4466],[127.3246,-8.4465]...

In the GIS client, when loading any of the MultiPolygon's I get
Uncaught TypeError: Cannot read property 'length' of null with util.map.getTransformedFeatureArray.

If I mangle the GeoJSON such that is has four square brackets (instead of five as above) things works OK. If I change the number of square brackets of normal polygons to three (as in the spec example here <http://geojson.org/geojson-spec.html&gt;\) , I get the same error.

Is there a particular reason for this? It would seem to be desirable to allow the upload of GeoJSON directly from a GIS system, without having to mangle it before.

Regards,
Jason

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

_______________________________________________
Mailing list: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

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

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