dhis2-devs team mailing list archive

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

great if it works, as most users are on windows (chrome is only for
widows at the moment) but i tend to run linux. maybe opera?

It would be good to have some metrics and reccomendations in the
documentation in terms of which browser should be used. i think the
dataset for zambia health facilities is pretty typical, and is known
to be incomplete, so it will only tend to get bigger.



On Thu, Nov 12, 2009 at 6:29 PM, Jan Henrik Øverland
<janhenrik.overland@xxxxxxxxx> wrote:
> Google Chrome has by far the strongest Javascript engine and SVG renderer,
> you can really feel the difference.
>
> These things are improved and released every month, so I don't think it will
> be a problem in the long run.
>
> Btw, I am going to test the latest browsers right now.
>
>
> On Thu, Nov 12, 2009 at 6:23 PM, Jason Pickering
> <jason.p.pickering@xxxxxxxxx> wrote:
>>
>> Strange. This behaviour I observed was on a brand new laptop running
>> the latest version of Firefox on Linux.
>>
>> Mileage may vary.
>>
>>
>>
>> On Thu, Nov 12, 2009 at 5:51 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
>> > On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
>> >>
>> >> Not too promising:
>> >> "If you expect the number of your point to grow beyond ~100, you'll
>> >> definitely be better off using WMS (especially if your users are on
>> >> Internet
>> >> Explorer)"
>> >
>> > Actually, this 6 month old comment may be a bit outdated, seeing as the
>> > newest browsers handle Javascript a hell of a lot better than a year or
>> > two
>> > ago.
>> >
>> > I just tried your file with Opera 10 and Firefox 3.5 using
>> > http://openlayers.org/dev/examples/vector-formats.html, and it had no
>> > problem handling it at all.
>> > So in situations where you can tell people to use a modern browser (even
>> > IE6
>> > could in fact handle your 1511 features, just takes forever to load...
>> > and
>> > is very sluggish) we may be ok.
>> > I still think having an alternative with either static or dynamically
>> > generated SLDs is needed (but not in all situations).
>> > Knut
>> >
>> >
>> >
>> >>
>> >> http://openlayers.org/pipermail/users/2009-March/010997.html
>> >> On Wed, Nov 11, 2009 at 5:48 PM, Knut Staring <knutst@xxxxxxxxx> wrote:
>> >>>
>> >>> 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
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Knut Staring
>> >
>> >
>> >
>> > --
>> > Cheers,
>> > Knut Staring
>> >
>>
>> _______________________________________________
>> 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
>
>