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 -~----------~----~----~----~------~----~------~--~---
