Yes, I agree. It does sound that way. Can Exhibit essentially do everything that TimeLine can do? In other words, is TimeLine a subset of Exhibit? Are Ajax and TimeGrid also subsets of Exhibit? The more I read the more it seems like Exhibit is the product to work with and learn.
- John David Karger wrote: > Sounds like you want to use multiple sources and use google > spreadsheets. Exhibit does both of these out of the box (you just list > all your sources in the header, and they can be google spreadsheets). > Sounds easier than writing new code for timeline. > > LarryK wrote: > >> On Oct 31, 1:01 pm, John Callahan <[EMAIL PROTECTED]> wrote: >> >> >>> Thank you Larry. Exhibit looks very interesting. I like the example >>> using Google spreadsheet as well as ical and rss feeds. Cool. Two >>> quick questions you might know off-hand: >>> >>> 1) Can TimeLine also use Google spreadsheet as a data source? I thought >>> so but did not see it listed under the Loading data section on >>> http://code.google.com/p/simile-widgets/wiki/Timeline. >>> >>> >> Doesn't do so out of the box, but you could write the sw and then >> contribute it to the project... >> >> You'd have to write the sw to pull down the Google spreadsheet data as >> a data source. >> I'd then create a json data record and then load the event data into >> the Timeline. >> >> Since you can use the sw in the Exhibit project that fetches the >> Google spreadsheet data, shouldn't be too hard >> >> >> >>> 2) For Exhibit or TimeLine, can you have multiple data sources painted >>> on the same TimeLine? I'm thinking of a few Google spreadsheets mixed >>> with a few RSS feeds. >>> >>> >>> >> I don't know about Exhibit. For Timeline: Yes. You can call your event >> source's loadXXX (eg loadJSON, loadXML) more than once. >> Or you can first download all of your data (from multiple sources), >> massage it, then load it into the Timeline. >> >> Eg, you might want to munge the events' color attribute for the second >> data source. >> >> If you first download your event data, you could definitely use the >> combined data set as a source for Exhibit. >> >> >> >>> Thanks. And thanks for such a great project. I'm looking forward to >>> using it. >>> >>> >>> >> You're welcome. David H is the key person. I'm happy to help keep it >> ticking along. >> >> Larry >> ps. Please send links to any demos or examples that you develop with >> Timeline, Exhibit, et al. >> >> >> >> >>> - John >>> >>> **************************************** >>> John Callahan >>> Geospatial Application Developer >>> >>> Delaware Geological Survey >>> University of Delaware >>> 227 Academy St, Newark DE 19716-7501 >>> Tel: (302) 831-3584 >>> >>> Email: [EMAIL PROTECTED]://www.dgs.udel.edu >>> **************************************** >>> >>> LarryK wrote: >>> >>> >>>> Hi John, >>>> >>>> Exhibit is more of a data analysis tool than Timeline or Timeplot >>>> since Exhibit comes standard with controls for filtering the data, >>>> viewing it in different ways (tabular, Timeline and more). It could >>>> certainly use more documentation. >>>> >>>> Which to use depends on your use case and users. Depending on how you >>>> configure it, Exhibit will require more of a training investment by >>>> your users. On the other hand, Exhibit can be configured to present a >>>> minimal (and easily understandable) set of features. Eg: >>>> http://people.csail.mit.edu/dfhuynh/projects/timeline-exhibit/timelin... >>>> >>>> Regards, >>>> >>>> Larry >>>> >>>> On Oct 31, 9:11 am, John Callahan <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>>> Thanks Larry for the response. I agree with the JSON and date format >>>>> suggestions. I was leaning toward that based on what I've read >>>>> elsewhere. Good idea about using SurveyMonkey, or similar type of >>>>> webform-based package, to input data. Since I'm writing the code from >>>>> scratch to extract and reformat the data into JSON, it really doesn't >>>>> matter that scheme of the database; I can adjust code around that. That >>>>> could be easier than recreating an new input mechanism. >>>>> >>>>> I'll take a look at Exhibit. It might be just me but from a quick look >>>>> at the pages, it's hard to determine exactly what it does. TimeLine and >>>>> TimePlot are easy to understand and very close to what I was looking >>>>> for. I'll spend some more time with Exhibit. Thanks again. >>>>> >>>>> - John >>>>> >>>>> **************************************** >>>>> John Callahan >>>>> Geospatial Application Developer >>>>> >>>>> Delaware Geological Survey >>>>> University of Delaware >>>>> 227 Academy St, Newark DE 19716-7501 >>>>> Tel: (302) 831-3584 >>>>> >>>>> Email: [EMAIL PROTECTED]://www.dgs.udel.edu >>>>> **************************************** >>>>> >>>>> LarryK wrote: >>>>> >>>>> >>>>>> Hi John, >>>>>> >>>>>> Sounds good to me. Think of Timeline as a reporting mechanism. So >>>>>> first you have a standard CRUD dbms system, then add on an output >>>>>> method that produces the xml or json file (a report) that your >>>>>> Timeline or Timeplot page will consume. >>>>>> >>>>>> You should also look into Exhibit which enables much more filtering >>>>>> and display options out of the box. >>>>>> >>>>>> Projects have also been completed which use Google docs spreadsheets >>>>>> to hold the data. That way you can use Google as your crud system. >>>>>> >>>>>> You could also use a db crud builder such as Dabble or FormAssembly to >>>>>> gather your data. Or SurveyMonkey. Or lots of other choices. Then >>>>>> build a much smaller piece of sw to handle the data extraction and >>>>>> reformatting into a form that can be consumed by Timeline, Timeplot or >>>>>> Exhibit. >>>>>> >>>>>> I suggest JSON since you are writing the extract sw. It's much more >>>>>> compact than xml, so uses less time for sending down the wire. It's >>>>>> also much faster to parse. If you want, you can also include >>>>>> Javascript date object declarations (see the Timeline wiki) instead of >>>>>> date strings that then have to be parsed by the browser. At that point >>>>>> your data format is no longer valid JSON, but that may not be a >>>>>> concern compared with the speed advantage. >>>>>> >>>>>> I haven't tried Timeplot lately so I don't know as much about it. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Larry >>>>>> >>>>>> On Oct 30, 12:56 pm, callahan <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> >>>>>>> I starting a couple of projects where I hope to use TimeLine and >>>>>>> TimePlot. Our goal is to have users contribute to the database >>>>>>> through an online interface. One thought was to create a webform that >>>>>>> allows users to enter data into a database (MySQL) then write a script >>>>>>> (probably PHP or Python) that queries the database and returns XML or >>>>>>> JSON data (not sure which is best) to the eventsource of the time* >>>>>>> object. >>>>>>> >>>>>>> For single events, this should be easy since all you need to capture >>>>>>> is date/range, title, and description. For time series data, it would >>>>>>> take more work since a dataset (csv, xls, tab files) would need to >>>>>>> uploaded and parsed before going into the database. In any case, >>>>>>> we'd need to work with authentication, editing submitted data, quality >>>>>>> assurance, and similar issues. >>>>>>> >>>>>>> Has anyone done this before? Are there any obvious pitfalls (database >>>>>>> schema, performance lag) that are known? Does this approach make >>>>>>> sense? Thanks for any help you can provide. >>>>>>> >>>>>>> - John >>>>>>> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
