Pita Project Builder
To provide “meta-design” capabilities for the PitA-Board, mechanisms are needed that permit individuals who are not necessarily programmers to create scenarios for use in group design sessions. Initially, this would be content focused, allowing domain experts to specify data such as GIS maps and other related information along with interaction elements such preexisting commands and actions. Eventually, it would be ideal to allow scenario designers and end users to influence behavioral aspects of the simulation environment, as well.
An initial “proof of concept” of such an environment has been created using swiki technologies. This version shows the basic idea of allowing the scenario designer to upload a geo-referenced map and specify the which commands should be used and where they appear on the board along with what piece numbers are associated with what actions.
This note describes some of the ways this could be extended.
Multiple Maps
Rather than a single map as in the proof-of-concept implementation, the ability to have multiple maps is needed. Each map needs to be associated with a name so that they can be called up as needed. In addition, support for other image formats than jpeg (such as gif, tiff, etc.), could be provided.
There is also the need for maps that can be overlaid on top of other maps (for example, to show roads, boundaries. This requires the use of a format that supports transparency.
- Data Sets
- Vector data—currently the data is limited to image formats. Vector formats, which specify the lines that make up the data rather than simply the rendered pixels, might be more flexible. However, there is also the issue of performance of rendering this data that needs to be studied. (it may be the case that having these rendered “on demand” on some other platform to the appropriate size and resolution for a given situation, might be preferred—this may be related to the wmt/wms item, below).
- Raster data—many forms of data are available in formats that, similar to images, are represented by values within an x-y grid. However, these values do not necessarily represent color values (although they could be mapped to color values to aid visualization). Often, these are much different resolution than images and ways of interpolating/mapping between resolutions needs to be provided.
Currently, it is assumed that the boundaries, home view, and location of the entire project are all specified by the size, extent, and location of the base map. It may be that the project may want to have a large base map but begin with a focus on a certain area. Alternatively, there may be several base maps that overlap but have differing extents, and the project focused on the overlap. It would be useful to be able to specify the world focus separately from the scope of the individual maps.
Images and maps are now shown as they are, without any information on what the coloring or icons represents. It would be useful to provide this information (and a way for the designer to specify it in the project builder). However, in the PitA-Board, traditional ways of showing legends (i.e., as part of the map image) are less than ideal as they take up “interaction space.”
One way that has been investigated in a cursory manner is to use an icon on the command tool associated with a layer indicating what that layer contains (e.g., a red line indicating roads). However, this is not very satisfactory in cases where the layer contains several components (e.g., different types of roads).
- More Detail in Board Margins
Another idea is to show a more detailed legend in the board margins when map is shown on board. However, e-beam drawing and color selection capabilities use much of the “margin real estate,” leaving room for only a few legends,
- Show legend in reflection space
The reflection space would seem to offer potential to display this information. Some mechanism would still be needed to specify the information and to organize the display of multiple legends.
- Linkages to (sub) projects
Projects may need to operate at different levels (e.g., different scales) for different phases of the scenario. Sometimes zooming and panning can accomplish this, but in other cases, weak scaling techniques do not provide sufficient detail for some situations. One alternative would be to impelment a more general scaling model (a la pad, pad++) or use (via wms) graphics engines that do support such scaling. A quicker short-term approach, may be to allow projects to link to other (sub) projects, which would contain the appropriately scaled maps, etc.
This needs to be cleaned up. Currently, commands are simply unary Smalltalk method names. Actions have a “pretty name” associated with each more complex piece of Smalltalk code.
Organize commands, actions, etc into “languages” rather than showing every possible item in every choice list, allow one to select a “language” and only have the commands, actions, etc associated with that language be active.
Specify kiosks and their position on the board
Specify the menu that represents the choices for a kiosk.
Specify the action to take place when
OpenGIS (more to do here)
Specify just URL—easier, but would have to parse extent from that (or does wmt return a world description?)
Specify information to generate URL, but would require meta-data about what is on the server
Allow specification of single map to return with all layers, but then couldn’t turn individual ones on and off
- Reflection Space Linkages
Part of constructing a scenario is providing information related to the task at hand that could be activated at the appropriate time. We need to give some more thought to how do this in a general fashion.
It would be good to have ways to have hierarchical relationships among project-builder swikis that would allow caching and mirroring of content to allow local copies of projects to be available when the server is not accessible. This may allow faster access to the local copies.
|
![[spacer]](/schemes/blue/line.gif){kind=small}
