--------------------------------------------------------------------------- From yangshao@comp.nus.edu.sg Thu Jun 24 19:11:25 1999 From: Yang Shaofa To: Leong Hon Wai , Foo Hee Meng , Ong Tat Wee Subject: Minutes of RADS GIS/GUI Design Meeting 3 ======================================================= Minutes of RADS GIS/GUI Design Meeting 3 Meeting: RADS GIS/GUI Design Meeting Date: 24-June-1999 Time: 10:00am -- 12:30pm Attendees: LeongHW, FooHM, OngTW, YangSF ------------------------------------------------------- TODO List: * contact Steven for designing of splash screen graphic [LHW: maybe] * provide the GIS group with design of one module of GIS, eg. MODEL, as sample, and ask them to design other modules. * provide the GUI group with one sample use case (or OID ), and ask them to develop other use cases (OIDs) and workflow * David to summarize the coding conventions of C++ and Shaofa to convert them into that of Java ------------------------------------------------------- Naming Conventions: (Nomenclature) General Principles: * these conventions are COMPUSULORY for codings that need to iterate with external modules/programs RECOMMENDED but not compusulory for codings that are only "internal". * try to use long names to avoid ambiguiouties & conflicts Class Names: --start with RADSGIS or RADSGUI e.g. RADSGISModel, RADSGISView, RADSGUIMenuBar --message class using * RADSMsg (if adopt approach of only one message class that encapsulates all messages) Or * RADS...Msg (if adopt approach of one class for each message) Function Names: On whether to use underscore (_) to connect prefix with actual names: to be decided by David & Shaofa ---------------------------------------------------------- Codes to give to GIS, GUI groups: * main program flow eg. initialization of RADSMM engine) * programs/classes that are unclear or difficult for the two groups to understand eg. drivers, etc ---------------------------------------------------------- New Components to add in for GUI: Splash Screen ---------------------------------------------------------- Features of Splash Screen: * several pictures display in order * disply status of current processing [note: the initial startup could takes about half a minute.] ---------------------------------------------------------- More on MFC or Java: * David to compile Java into .exe file and test * memory hogging for Java is serious, current program uses about ?18M on postel ---------------------------------------------------------- Decision on comm between GUI & GIS: GUI comm directly with MODEL & VIEW 'coz the other approach adds complexity ---------------------------------------------------------- OO Analysis of each module: MODEL: --Init: * DB --> map * P.T.D.S. --> D. S. --Search by: * road name * bus/MRT stop * place of interest * famous building name * major "town" [note: MODEL works on only real world coordinates. ] FILTER: VIEW: --Knows scale, origin, offset --Knows world coordinate system; --Knows screen coordinate system; **NOTE: It is recommended that screen and world coord system should have consistent orientation. --Init: * show map --Show * render * clip (draw on offscreen buffer first, then transfer to video memory) ie. paint from buffer --Pan: * fixed increment/decrement * move to area whose center is defined by user [note: shape of view volume remained unchanged. ] --Zoom: * fixed increment/decrement of scale * zoom to user-selected area ?question: user can select the area to zoom from mini-map or the viewport GUI: --Knows scale, origin, offset --Route Planning Dialog --Evt loop --Search dialog --Proerty sheets --Status bar for display info about * source * destination * user preference [note: this is important 'coz the user needs to know what he has selected. ] --Visual feedback of View's actions eg: if user zoom with a "selected rectangle", then the GUI must update the view ("track the selected rectangle") as the user moves the mouse. eg: if user searches for a place say Orchard Rd, and MODEL then tells VIEW to show Orchard Rd, then GUI must update this info of the new view volume on the mini-map --Define keyboard shorcuts ---------------------------------------------------------- On Comm betw modules: MODEL <--> VIEW: all in real world coordinate GUI <--> GIS: events/actions that needs translation between screen and real world coordinate comm with VIEW eg. to display name of clicked building Else comm with MODEL eg. search for a place of interest ---------------------------------------------------------- On Scale of map: * Physical Scale: used in printed map, format is printed_size : real_world_size eg. 1cm : 45km * Screen Scale: used in map displayed on monitor, format is displayed_size : real_world_size eg. 1dpi : 10km ---------------------------------------------------------- On Coordinate system: must fix one coordinate system ---------------------------------------------------------- Steps of program startup: 1. show splash screen 2. init RADSMM 3. init GIS, first MODEL then VIEW (draw map on offscreen buffer) 4. show GUI window with all GUI objects and map 5. enter event loop [note: the map and the GUI objects should be showed at the same time] ---------------------------------------------------------- New Features to add in: * hieracical (multi-level) route planning optimization criteria Time, Fare, Number of Transfers [note: this is already available in RADSMM engine] * allow user to save preferences (& start/end locations?), so that he can use the same preferences to do planning of different start/end locations conveniently ---------------------------------------------------------- On Message Class: alternatives are: -- One class RADSMsg to encapsulate details of messages, it * provides no services. * carries the actual objects to be passed betw modules and each module Individual module is responsible of decoding messages received. All messages are instances of RADSMsg. -- One class for each message, may inherited from one base message class Each message object is "intelligient" enough to * provide respective services to modules communicating Individual module just request information from message object. ------------------End---------------------------------------- Yours sinceresly, Shaofa ---------------------------------------------------------------------------