ChazZ S wrote:
> "The problem here is that it's hard to define "continuity" when all you
> have as input is a series of independent events. One thing that we could
> do is to define a "time window" that makes events that are more distant
> than a certain time period be considered disconnected.. I prefer this
> better than additional markup on the input data file.
>
> Thoughts?"
>
> The additional markup in the data file could be as simple as a blank
> line between chunks of data.
The problem I have with this is that the data file at this point
contains implicit timeplot semantics... doesn't really matter if it's a
single newline char or, say, some XML markup or #...-like comment:
requiring timeplot-specific info in the data file reduces the ability to
use timeplot to digest whatever it's already out there (or might be easy
to surface).
Adding a single like to break up 'windows' of connected events is
trivial when done by hand, but it's not so trivial when you have a
dataset exported from the resultset of a database query: such
'post-filtering' logic need to be applied to the query result and it's
therefore on the shoulders of the data producer and it's also not
available for manipulation by the data consumer (who, normally, has a
much better idea about what to do with the data than the producer).
This is why I think it's much more useful to augment timeplot with
parameters that the timeplot embedder can tweak rather than apply an
additional burden on the dialog between the data producer and the data
consumer (which, hopefully, won't be the same person/group, so that
second order network effects can happen)
> I agree with your idea of a "time window" it would allow a
> user/programmer to determine what is a continuous set. Another
> suggestion; continuity could be implicitly "broken" by separate "loads"
> into an event source. If i were to:
>
> plot.loadText("data1.txt", ",", eventSrc);
> plot.loadText("data2.txt", ",", eventSrc);
>
> this would result in a plot of these two sources but there would be no
> connecting line between the last of data1 and the first of data2.
Hmm, there are problems with that: say that data1.txt and data2.txt
where the results of two different queries run against two different
datasets, one that contains events with granularity one minute but the
entire day and another that has granularity 1 seconds but only for a few
hours. If I want to plot them differently, I plot them against different
geometries or using different plotting styles and I'm done. If, on the
other hand, I want to mash them up to benefit of the higher-resolution
for those two hours anyway, I can just load the two together.
The more I think about it, the more it seems to me that allowing
timeplot to operate with a user-defined 'continuity window' over a
particular dataset is the best solution for this problem.
> In addition i have seen that people are having trouble with cluttered
> axis labeling, a simple solution would be the ability to explicitly set
> an interval, be it seconds, min, hours, days, etc. etc.
This happens mostly on geological-scale data ATM, which is something
I've added only recently and I haven't had the chance to fix the X
labeling algorithm accordingly.
Although, you're right: timeplot tries to be smart in understanding the
granularity of the various axis (this is because I've had pretty bad
experiences in the past with plotting tools that were so rigid that
required continuous tweaking of the plotting parameters as the dataset
changed over time), but it's really up to the timeplot embedder to drive
the plotting and timeplot shouldn't try to be smarter than that.
> I would also
> think that text overlap could be detected and the labels could be
> culled, staggered, or something so they dont overlap, same goes with the
> showing of values. if you have a couple plots that are close and maybe
> cross at times, the labels that show up should not be overlapped either.
Yes, there is a lot that can be done in this area. Unfortunately, it's
not easy due to the very different behaviors that browsers have in
reporting the size of a <div>, but nothing that can't be fixed with some
good javascript library (like jquery + dimention plugins, for example).
> thx for listening.
my pleasure... thanks for the useful feedback!
> -ChazZ
--
Stefano Mazzocchi
Digital Libraries Research Group Research Scientist
Massachusetts Institute of Technology
E25-131, 77 Massachusetts Ave skype: stefanomazzocchi
Cambridge, MA 02139-4307, USA email: stefanom at mit . edu
-------------------------------------------------------------------
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
