250 likes | 260 Views
Forecast Production System: Technology and Infrastructure Aleksander Bandelj, Academa d.o.o. EGOWS 2008 - Ljubljana. Agenda. System overview Data model (ProBa) Data editing (ProEditor) Data presentation and product generation (ProPro) Conclusion Future directions. System Overview.
E N D
Forecast Production System: Technology and Infrastructure Aleksander Bandelj, Academa d.o.o EGOWS 2008 - Ljubljana
Agenda • System overview • Data model (ProBa) • Data editing (ProEditor) • Data presentation and product generation (ProPro) • Conclusion • Future directions
System Overview Web content and services Model Editor XML pipeline Javascript Model Behaviour Model Transaction XQuery XSLT Data Model viewed as XML XML content Prognostic Data model Model Storage and Query Relational database Java modules (OSGI) Java Virtual machine Grid, process and service management
Prognostic Data Model • Data model: not a numerical model • Data model is specification of application data • First defined as F-Logic ontology with mapping to Java and database • Now in Ecore (simplified UML) • EMF is Java runtime for Ecore (core of Eclipse Modeling Project)
Ecore diagram example In box: Object attribute Box: Object class Inheritance Relationship
Prognostic data model • MetData in Domain (hierarchy of spatial areas) • MetData has variable groupings: GeneralVars, SynopVars, ... • Vars have DataRange and scalar values • DataRange is mapped to scalar value at different gradations • Gradation mapping depends on Domain, its geographical type and hierarchy
Prognostic data model Domain DataRange MetData Vars
DataRange • Automatic conversion between DataRanges in different gradations and domains • Editing in different gradations • DataRange carries descriptions in several languages and locales • Products in several languages and gradations
DataRange Domain geography type Locale text DataRange
Coord and EventVars • MetData may also have several Coords (observations at different heights) • Coords may also have different Vars • EventVars for warning and other events • Different DataSources (human, computational model, ...)
Coord and EventVars Coord
Model storage • Stored in relational database (PostgreSQL) by object-relational mapping • Mapping described as annotations on model elements
HQL instead of SQL Objects, not tables Analogous to SQL but more expressive (dot notation ) Caching of objects Model database query from MetData d where d.timeStampValid=time(:valid) and d.timeStampUpdate in ( select max(d.timeStampUpdate)from MetData dwhere d.timeStampValid=time(:valid)and d.domain.meteosiType='SYN' and d.domain.area.country.isoCode2 in ('IT','SI','AT','HU','HR')and d.note!=nullgroupby d.domain.wmoId ) orderby d.domain.wmoId
Model behaviour • Epsilon (Javascript for model procesing) • Model comprehensions (OCL) • Forecast initialization for (fc in Forecast!MetData.allInstances) { -- if completely new forecast, take Vars from validGuessesvar validGuesses := guesses.select(e | e.domain.meteosiId= fc.domain.meteosiId and e.valid=fc.valid and e.validStart.isDefined() and e.validEnd.isDefined() )if (not fc.id.isDefined()) { fc.initVars('newEmptyVARS');var lastFirstGuess := guesses.select(e | e.state=2 and e.domain.meteosiId=fc.domain.meteosiId and e.valid=fc.valid).latest(); -- take validStart End from lastFirstGuess (Data) fc.validStart := lastFirstGuess.validStart; • Forecast validation (prototype)
Data editing • User interface dynamically created from data model • Tree, tree table, property sheet, form • Customizable at runtime
Data editing • User interface available as: • desktop application (RCP) • web browser (prototype) • Data to edit specified by model query • Web version accesses data directly • Desktop application uses model transaction change log to transmit only changed data to server
Forecast editor • Extended user interface for forecast editing • Spreadsheet-like domain/time matrix editor • Cells may be coloured by Epsilon program (warnings) • Data lens (view data at different gradations)
Data presentation and product generation • Developed by customer from initial template • Cocoon: everything is XML • Sitemap: map URLs to pipelines • XML pipelines with serialization as last stage (PDF, SVG, XML, text) • Docbook (XSLT) as serialization
Data presentation and product generation • Model data is mapped to XML tree and accessed from Xquery • Product URL = HQL + XQuery + Serialization • Javascript code may pass data to other pipelines, generate data or process data during pipeline execution • Met Office is Web 2.0 frontend to Cocoon backend
Conclusions • High level data modeling mandatory • Solution must be general and extensible • Performance is OK and can be pushed still further. In general, database is a bottleneck • Every temporary solution tends to become a permanent one
Future directions • Generalize from application/solution to development environment for meteorological applications • Data model is already completely dynamic, but still has dependencies on customized generated Java code, remove them • Let user evolve data model • Weather and forecast visualization inside ProEditor