Home » Eclipse Projects » Spatiotemporal Epidemiological Modeler (STEM) » STEM Plan for Version 2(STEM Plan for Version 2)
| | |
Re: Features in Version 2 - some ideas [message #501595 is a reply to message #501357] |
Wed, 02 December 2009 23:49 |
Stefan Edlund Messages: 127 Registered: July 2009 Location: IBM |
Senior Member |
|
|
Hi Matthias,
these are all very good suggestion, let me try and comment on some of them but I'm sure others have some thoughts on it as well.
As for the feature request, that's what we originally wanted to do but there really isn't any other suitable forum provided by eclipse where anybody can easily provide input, unless we write the web app ourselves A wiki page was suggested but that might be too difficult to use for general audience.
I'm not sure I understand your first suggestion. If you know the distribution of farm size and the number of farms in each district, wouldn't you be able to roughly estimate the number of cattle in each district? That could then easily be incorporated into a STEM model.
We do not have a "parameter sensitivity" estimate right now, but I can see it being incorporated into the Experiment features in STEM. Experiments allow you to run many simulations varying all the values of the disease model parameters (either automatically or manually). I think it is a good suggestion. If you could give us an indication of the "importance" of such a feature to a public health person such as yourself it would be very helpful to us. It is actually possible to manually calculate the sensitivity of each parameter right now by looking at the log files generated when running experiments, but that would require some skills.
I don't know what the traffic light principle is. STEM allows you to compare the outcome of one simulation with another, and even compare simulation results with actual reference data if available. Perhaps you can explain this feature a little more?
The ability to add/remove nodes and edges from within the application has been requested many times so we need to do it for sure. One complication is that models in STEM points to graphs in the standard STEM library that cannot be modified. So one alternative is to make a copy of all the nodes/edges in the STEM library when you incorporate them into your model so you can edit them. However, the STEM libraries can be HUGE (like every region on the planet) so that might not be the best solution. A better solution is to keep a "change" log where the modifications done by the user are applied on top of the STEM library ones.
Importing other file formats into STEM is easier for some formats than other right now. We support ESRI shape files for GIS data for instance, but other formats would require more work. Is there any particular format that you encounter frequently that would be useful?
Regards,
/ Stefan
|
|
| |
Re: Features in Version 2 - some ideas [message #502521 is a reply to message #501595] |
Tue, 08 December 2009 16:46 |
Matthias Filter Messages: 75 Registered: July 2009 |
Member |
|
|
Hi Stefan,
To Stefan's comments:
to the first point - nodes without GIS information:
Maybe the example was not the best. Of course you could work something around the issue, if you don't have the exact position of a node, but this is extra work for the user that simply wants to apply STEM to e.g. a simple edgelist. In the end this might prevent potential users from applying STEM. So e.g. in the area I'm working in, there we have the situation, that we don't want to locate the farm or the production site on a map, because this would cause problems with data privacy. So actually for me the question is whether it is much effort to open the system for that kind of data, because the simulation infrastructure, e.g. the epidemiological models and the simulation infrastructure connected with them, are as far as I understood not directly affected by the exact location of the node.
So if this (nodes without GIS) would be possible then one could also extend the STEM functionality with features from the graph theory community that can help to descibe the network used in a simulation, e.g. distribution of the indegrees or outdegrees of nodes etc.. One solution might be that one assigns manually the same coordinates to all nodes where exact locations are missing and the system then applies some jittering when it comes to displaying the network. But this is for sure just one possibility.
- parameter sensitivity issue:
your idea is very good, the Experiment features should be able to cover this. For me personally a sensitivity analysis would be a must if I would have to base a decision on a simulation (except I can verify my simulation with independent historical real world date). But to be honest I don't have to make that kind of decision here.
- traffic light principle means a simple three colour coding scheme, red is bad and green is good.
to the other things I comment later.
Matthias
|
|
| |
Re: Features in Version 2 - some ideas [message #503835 is a reply to message #502584] |
Tue, 15 December 2009 22:56 |
Stefan Edlund Messages: 127 Registered: July 2009 Location: IBM |
Senior Member |
|
|
Hi Matthias,
to clarify, we do not require the exact location of farms, people etc in STEM since we know that would be a privacy problem. For instance, all the public health data we use to evaluate our models in STEM must be de-identified and contain aggregate information only, for example how many new cases of flu were reported in ZIP code xyz a given day.
So in your example, we don't want to exact lat/lon position of the farm, rather all we'd need to know is what STEM region it is located it. Right now, the finest granularity regions we have in STEM is down to admin level 2, which typically is county. So disclosing the county a farm is in should be okay, right?
Using your concept of "traffic lights" to indicate the confidence we have in the input to the model is an interesting idea. One thing we do know about is the year we have population data for a country, so if that year is far in the past we would be less confident in those numbers. It would take some effort to implement such a feature, right now I would put a higher priority on being able to handle zoonotic diseases, multi-serotype disease models and new improved stochastic models in STEM.
Jamie knows more about the ESRI shapefile import into STEM, Jamie can you let Matthias know how we support that?
Regards,
/ Stefan
|
|
| | | | |
Re: Features in Version 2 - some ideas [message #561892 is a reply to message #502584] |
Tue, 15 December 2009 22:56 |
Stefan Edlund Messages: 127 Registered: July 2009 Location: IBM |
Senior Member |
|
|
Hi Matthias,
to clarify, we do not require the exact location of farms, people etc in STEM since we know that would be a privacy problem. For instance, all the public health data we use to evaluate our models in STEM must be de-identified and contain aggregate information only, for example how many new cases of flu were reported in ZIP code xyz a given day.
So in your example, we don't want to exact lat/lon position of the farm, rather all we'd need to know is what STEM region it is located it. Right now, the finest granularity regions we have in STEM is down to admin level 2, which typically is county. So disclosing the county a farm is in should be okay, right?
Using your concept of "traffic lights" to indicate the confidence we have in the input to the model is an interesting idea. One thing we do know about is the year we have population data for a country, so if that year is far in the past we would be less confident in those numbers. It would take some effort to implement such a feature, right now I would put a higher priority on being able to handle zoonotic diseases, multi-serotype disease models and new improved stochastic models in STEM.
Jamie knows more about the ESRI shapefile import into STEM, Jamie can you let Matthias know how we support that?
Regards,
/ Stefan
|
|
| | | |
Goto Forum:
Current Time: Thu Dec 12 05:04:59 GMT 2024
Powered by FUDForum. Page generated in 0.04221 seconds
|