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] http://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 -~----------~----~----~----~------~----~------~--~---
