Assigning organizational units...some observations

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?

Regards,
jason

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

···

On Wed, Nov 11, 2009 at 5:21 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

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

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

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

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: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

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.

Started one here (with wiki page). Please expand.

https://blueprints.launchpad.net/dhis2/+spec/gis-sld-generator-wms

k

···

On Wed, Nov 11, 2009 at 6:18 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

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


Cheers,
Knut Staring

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.

Started one here (with wiki page). Please expand.
https://blueprints.launchpad.net/dhis2/+spec/gis-sld-generator-wms
k

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: DHIS 2 developers in Launchpad
>>>> Post to : dhis2-devs@lists.launchpad.net
>>>> Unsubscribe : DHIS 2 developers in Launchpad
>>>> More help : ListHelp - Launchpad Help
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Knut Staring
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>
>
>
> --
> Cheers,
> Knut Staring
>

--
Cheers,
Knut Staring

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

···

On Wed, Nov 11, 2009 at 6:14 PM, Knut Staring knutst@gmail.com wrote:

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

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: DHIS 2 developers in Launchpad
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : DHIS 2 developers in Launchpad
More help : ListHelp - Launchpad Help

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

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


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

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: DHIS 2 developers in Launchpad
>>>>> Post to : dhis2-devs@lists.launchpad.net
>>>>> Unsubscribe : DHIS 2 developers in Launchpad
>>>>> More help : ListHelp - Launchpad Help
>>>>
>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Knut Staring
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Knut Staring
>>
>>
>>
>> --
>> Cheers,
>> Knut Staring
>
>
>
> --
> Cheers,
> Knut Staring
>

_______________________________________________
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