I like Jean's proposals for making map representation and display more
general in ACEDB. I'm also glad to see that Richard endorses most of them.
Here are some further ideas on map DISPLAY, interspersed among lines from
Jean's proposal (which are indented and preceded by ">").
>
>RULE2:
>As far as the map display is concerned, anything in the Contains
>paragraph will appear on the map. In particular a Map may well
>contain another map.
>
>Its display will be specialised if it belongs to a class with a
>specialised display code (i.e.: Gene, Chrom_Band, Rearrangement,
>later submaps).
>
>Otherwise, any object containing the construction
>Map xxx Position 3.2 Error .3
>will be displayed as a point locus (gMapDisplayAnyLocus)
>
>any with
>Map xxx Ends Left 4.2 Error .1
> Right 4.8 Error .2
>will be displeaed as a segment (gMapDisplayAnyInterval)
>
>RULE3:
>On firstpick (gMapSelect):
>a) The selected box, and all boxes refreeing to the same key turn
>lighblue.
>b) All neighbours (i.e. keys referred to in the selected obj) turn
>LIGHTGREEN
>c) All tags referred to via mappingTag (Inside, Outside etc) as
>obtained via a bsFlatten(mappingTag,2) recolor according to their
>relative position: GREEN if happy, RED if Problem, LIGHTRED if marginal.
>
Although these colours and behaviors seem reasonable for system-defaults,
it
would be nice to give individual database administrators and users more
control to set their own visual characteristics for map displays. Richard's
comments underscore the fact that people sometimes want different color
coding.
Some of our users want to be able to specify either vertical or horizontal
display of any map. They also would like to have more user and/or data
administrator control over setting display behaviors such as
color [SEE ALSO MY SEPARATE NEWS ITEM ON COLOR IN GENERAL]
pattern (so color is not always necessary)
line width (for segments)
symbol (for points)
typography (for alphanumeric characters)
visibility (i.e., whether object appears on map display)
Each of these could start off with a well chosen set of defaults.
Furthermore, we would like users to be able to reset some or all of these
visual characteristics for abitrary subsets of map objects, depending on
the
results of arbitrary queries. For example, the flybase project wants
to be able to visually distinguish those clones that have been verified by
in-situ as well as PCR experiments. Sometimes they may want to ONLY
display
those clones, while hiding others. I can imagine some mechanism (like the
table-definer window and display control windows) that would allow users to
store a query along with a set of map display characteristics
that would bring up the particular kind of map they want to see. At
another level, perhaps we could let data administrators set global defaults
in a
configuration file (ala options.wrm), where they could assign
database-specific
map display defaults to particular classes, subclasses, "Inside",
"Outside", etc.
>************************************************************
>
>Interesting properties:
>
>a) Every box on the map will be recolored according to the Inside,
>Outside etc mapping tags irrespective of their class, irrespective
>of their class and peculiar displays.
Very good to do this in a general way.
>
>b) I do not prerregister friends any more, i.e. sets of objetc
>coloring lightgreen in advance. This enormously simplifis the code.
>It also behaves much better because "friends" are not transitive.
>The overhead of accessing the object rather tahn a preregistered
>table is negligeable. It anticipates on the second pick(display) and
>is in fact faster than preregistering all sets of friends.
>
>c) Any new class will appear on the map if it XREF to a tag to the
>right of the Contains tag. In particular, in the runnig prototype i
>have a well behaved YAC/STS map, when the code was compiled before
>including these classes in the model files. This completely solves
>the problem of the Bentley database who had to call his YACs
>deficiencies and the like.
Excellent!
>
>d) The generic map making algorithms depend only on the mappingTags
>and thus run on arbitrary maps.
>
>e) As a side effect, you will note that the mappingTags are part of
>the models but will not appear in the ace files. Furthermore, a YAC
>say can be said to Contains other yacs, clones, STS, genes, i.e. any
>etherogeneous set you want, since you can define one level of tags
>under the mappingTag contains.
Is it possible to assign different default kinds of visual behavior for
each
type of mappingTag (Contains, etc.)? -- e.g., x for hits and o for misses?
>
>f) As required by John McCarthy and others, the numbers defining the
>map position are now explicitelly qualified.
What measurement units will be used for map positions? It probably needs to
be something relative, like percent of the whole map, in order to support
recursive nesting of maps.
> +=====================================================================+
> | John L. McCarthy. . | Internet:..JLMcCarthy at lbl.gov |
> | Computer Science R&D MS 50B-3238 | Bitnet: ...JLMCCARTHY at LBL |
> | Lawrence Berkeley Laboratory .| telephone: (510) 486-5307 |
> | 1 Cyclotron Road . | |
> | BERKELEY, CA 94720, U.S.A. . | FAX: (510) 486-4004 |
> +=====================================================================+
