dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx>
>> 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@xxxxxxxxx> 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>) , 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@xxxxxxxxx
>>>> tel:+46764147049
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dhis2-devs
>>>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>>
>>>
>>
>>
>> --
>> Jason P. Pickering
>> email: jason.p.pickering@xxxxxxxxx
>> tel:+46764147049
>>
>
>


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