Talk:LocDB Module Climate

What to implement first
Well, so far about my proposals for a climatic module. I have documented my ideas on how the final result should look like.

On the first stept, we might skip all the JS stuff except the unit calculators. Just implement two or three fix tables without the possibility to delete them or add new ones. The unit calculators are already in use by the ModGeo and can be stolen from there without any modification of their code. We just need to supply them with the approriate parameters in the JS part.

-- Hansm 10:52, 13 September 2008 (UTC)

I will try to reverse direction of discussion - may be we should start from choosing a result that data will be used to produce? Of course any data is valuable and the more the better. If we stick to 12-month division we could present one, may be two sets of data on a two-dimensional chart. What if we got 3 tables for one location - let's say rainfall, temperature and wind speed? There may be a couple solutions for presenting tables in one illustration in the article. I like one with 2d chart with months on X axis and then two sets of data on left and right Y axes. The third and further types of data could be selected on choice - may be with radio buttons under chart. Another option is to make temperature graph always displayed and choosing only the 2nd data set with radio button (in the example: rainfall or wind). What do you think of that? Is it possible to draw such a chart? With some PHP library for example? LukeWestwalker ⇔ 17:59, 17 September 2008 (UTC)


 * Your graph looks nice. Also, the idea with selectable data display sounds temptatious, but how about printing the article? Printed radio buttons are toothless tigers. There is still an other problem. For toggling data sets on and off, you will have to rely on javascript, which is a limitation in use. Sure, the locDb heavily bases on JS, but this is only the playground for power authors, not for normal readers.


 * I have had the idea to show some few graphs with important data sets and offer the complete set of graphs on a special page linked from the tool bar.


 * Drawing graphs or displaying tables is only half of the story. I think one important issue would be a search like "Show me all places in South America where the water temperature is between 20°C and 25°C in December".


 * -- Hansm 18:45, 17 September 2008 (UTC)


 * Looks to me like "only" a task of a suitable query from a database of a design suitable for such queries. If it worked, should be really an attractive feature. But on the whole I see a couple of definitions that should take place: 1.presentation (drawing graphs) with printing articles in mind, 2.infrastructure of database for various purposes, 3. data management forms. The latter point may be considered covered according to what you described |here. I have no idea for the first two, though. Anything decided yet? LukeWestwalker ⇔ 15:49, 18 September 2008 (UTC)


 * To 1.presentation: Graphs that display data from the locDB can not be made on the fly, i.e. when a user loads an article. This graphs should be prepared by a server sided background process that checkes periodicaly for changes in the used data sets. The result would not be a regular image as uploaded on shared:. Thus, we would need a special template for the authors to include those graphes. I already have done something simular with graphs that show statistical data of the Wikivoyage project.
 * To 2.infrastructure: I'm not sure how you mean this. This is actualy the location DB itself, not the part used for data management, but that what I have told you to shortcut in our practising sessions. Or did you mean a read only HTML user interface for sending queries to the locDB?
 * -- Hansm 07:42, 20 September 2008 (UTC)


 * Ok, so this would be clear for presentation. As to infrastructure I mean db structure and may be anything more which is needed on the server or in the code (like scripts that update graphs). Sorry for being unclear on this. LukeWestwalker ⇔ 11:36, 21 September 2008 (UTC)