dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

Given that your json file is less than 600 k, it seems to me that it is the
number of objects in the DOM that are a problem rather than the file
size...which would not be the case with WMS of course, but then, less
immediate interaction

On Wed, Nov 11, 2009 at 5:38 PM, Knut Staring <knutst@xxxxxxxxx> wrote:

> On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering <
> jason.p.pickering@xxxxxxxxx> wrote:
>
>> In my spare time sitting in a long meeting, I have been taking  a look
>> at the GIS module in a bit more detail. I have a few comments.
>>
>> My source data file is here..
>>
>>
>> http://zamdhis.dynalias.org/geoserver/wfs?request=GetFeature&typename=who:HFC_GPS_ZAMBIA&outputformat=json&srsname=EPSG:4326
>>
>> This is the GeoJSON output of facilities in Zambia (those that are
>> available).
>>
>> Now, because we are using the DHIS 1.4 naming convention, where a
>> prefix of the province has been added to the name of the facility. The
>> basic problem here is that there are differences between the names of
>> the facilities in the DB and the names in the GeoJSON files. Luckily,
>> there is a common code that would allow the data to be matched, but I
>> can only match the JSON file on the name of the facility. Possible
>> solutions? Change the source file is an option. Allowing matching on
>> another field in the database would be a better option perhaps.
>>
>> Also, since there are some 1500 points or so in the file, the browser
>> "greys out" sometimes, which seems really to be a performance issue.
>> Obviously, we cannot simplify point files, which can speed up the
>> performance of polygon layers in the client. Thoughts?
>>
>
> You can actually simplify even points by including fewer decimals for each
> coordinate. That may be acceptable in some situations, but probably quite
> undesirable in others - and I think it underscores that we need to bring the
> OpenHealth-FP solution of generating SLDs to feed to Geoserver back in as a
> supplement for cases where GeoJSON are not suitable. It would be great to
> avoid that, but not sure if it is possible when we deal with serious amounts
> of data.
>
> Knut
>
>
>> Regards,
>> jason
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
> Cheers,
> Knut Staring
>



-- 
Cheers,
Knut Staring