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?
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.
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@gmail.com wrote:
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.
“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)”
On Wed, Nov 11, 2009 at 5:48 PM, Knut Staring knutst@gmail.com 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@gmail.com wrote:
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.
We need to get a blueprint written for the use of WMS layers where the
SLD is generated/used by DHIS.
GetFeatureInfo capabilities requests should allow similar behaviour of
the click and get feature info behaviour we have now (hover is also
possible).
Lets tackle this on Friday as well.
···
On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring <knutst@gmail.com> 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)"
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@gmail.com> wrote:
On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering >>> <jason.p.pickering@gmail.com> 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.
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
OK. I think it is a very basic start, but much of the code should
already be there in the functional prototype, and should be able to be
simplified significantly as we are not dealing with OLAP but rather
static table. There were a number of deficiencies in the prototype,
which I have documented in different emails from the past. I will try
and dig these out and provide more detail on what the desired spec
should be.
···
On Wed, Nov 11, 2009 at 9:31 PM, Knut Staring <knutst@gmail.com> wrote:
On Wed, Nov 11, 2009 at 6:18 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:
yeah, this is going to be a problem for sure.
We need to get a blueprint written for the use of WMS layers where the
SLD is generated/used by DHIS.
GetFeatureInfo capabilities requests should allow similar behaviour of
the click and get feature info behaviour we have now (hover is also
possible).
Lets tackle this on Friday as well.
On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring <knutst@gmail.com> 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)"
>
> http://openlayers.org/pipermail/users/2009-March/010997.html
> On Wed, Nov 11, 2009 at 5:48 PM, Knut Staring <knutst@gmail.com> 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@gmail.com> wrote:
>>>
>>> On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering >> >>> <jason.p.pickering@gmail.com> 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@lists.launchpad.net
>>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>>> More help : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Knut Staring
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>
>
>
> --
> Cheers,
> Knut Staring
>
“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.
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
···
On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring knutst@gmail.com wrote:
On Wed, Nov 11, 2009 at 5:48 PM, Knut Staring knutst@gmail.com 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@gmail.com wrote:
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.
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@gmail.com> wrote:
On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring <knutst@gmail.com> 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
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@gmail.com> wrote:
On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering >>>> <jason.p.pickering@gmail.com> 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.
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
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@gmail.com> 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@gmail.com> 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@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring <knutst@gmail.com> 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@gmail.com> 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@gmail.com> >> >>> wrote:
>>>>
>>>> On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering >> >>>> <jason.p.pickering@gmail.com> 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@lists.launchpad.net
>>>>> 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
>