In todays call we discussed the need for new types of graphs in STEM.
Suggestions included
1. Ability to Model on Lattices
2. Addition of a better map of Europe
3. How to maintain and expose a variety of maps in the designer perspective
4. How to free STEM of the requirement that we have a fixed set of polygons. We want to visualize maps but we could, for example, define a higher resolution map of Europe without polygons and just draw cricles.
5. Other Tesselations of the world

1) Regarding lattices, STEM already has a little button on top of the menu bar that looks like a lattice with nodes and edges. This is the create graph button and right now it launches a wizard that creates and empty graph (all you can do is name it). You can try this button today. Ideally when you press the button the wizard should allow the user some options one of which would be square lattice with a way to specify number of rows and edges. This will then appear in the project explorer and it can be dragged into a users project.

2) The big issue with a better map of Europe is finding data available with an EPL friendly license. We are working in this.
3) Suggestions? Using the new graph button we can in principle enable a variety of graph creation algorithms programatically (not just lattices but also tesselations)
4) Suggestions?
5) See 3 above.

I would appreciate such a feature very much as well. What one could consider additionally is whether this would be a way to incorporate and simulate on other network structures as well. I could imagine that one gives the user the opportunity to upload a file in a defined format, e.g. a DyNetML or other usual file formats in network analysis.
What is still not clear to me is the question, whether a user could then in principle combine this proprietary graph from his workspace with the ones that come with the installation? If this would be possible, I guess some of the other issues raised in this news thread can be solved as well.

2.: nodes without GIS information:
... There are situations, where users don't want to locate the node site on a map, because this would cause problems with data privacy, e.g. a farm or a hospital etc.. So the question is whether it is much effort to open the system for data without GIS information, i.e. arbitrary placing nodes into existing country maps. 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.. http://en.wikipedia.org/wiki/Centrality

I will post a sample file asap.

3.: graphical editors:
Library that might be of interest: http://jung.sourceforge.net/ and that is also compatible with the pajek ".net"-format.

Arik, I don't think we're trying to replace all the existing .properties and .xml files in STEM, they've served us well in generating the standard libraries available.

I think the idea is to come up with a common graph format that (with as little effort as possible) other graphs formats can be converted to and then imported into STEM when the user is building a new scenario.

Looking into the .pajek format, it seems to be heavily focused on how to visualize networks with commands for fonts, colors, node shapes etc. etc. It even has a free editor/visualizer. There's less focus on node/edge attributes and no type system as far as I can tell. We would need to encode lots of that extra information into the labels, is that right?

I think in the end this discussion leads to the conclusion that we have to define a generic (XML) format for epidemiological models. I searched quite a while on the web and discussed it with external experts but no-one new about an existing standard. What I found was the following:
http://docs.epigrass.metamodellers.com/using.html#specifying -a-model-the-script
BTW - Epigrass seems to be quite close to what STEM is doing, just with a different programming language.

Anyway, I think, to generate a new standard is probably something that takes some time and that should be guided by someone who has experience in this. I guess, there are for sure experts in the eclipse community for this. Independent from this we need an interim standard, so that the different developments in STEM can continue. Imho, this should be defined in the near future.