Back to HabcMeetingMinutes
Working Group Meeting
July 17, 2007
| Attending: | Matt Austin | Al Sutherland |
| Dave Nicolson | Paul Ramsey | |
| Kevin Neufeld | Emily Gouge | |
| Sue Fox |
Discussion
* Paul gave an overview of how we put the analysis questions together and what the plans are for the requirements document. Refractions will create a document containing:
- the pertinent analysis questions; will be made as generic as possible
- a breakdown of the type of questions that the system will be able to answer
- user stories
- Will be a definitive list; generic with respect to data but specific with respect to form
- non-functional requirements (described below)
* Refractions will also provide a user interface design document
* Discussed what Refractions would address for non-functional requirements
- Usability
- Performance
- Security
- Legal
- Interoperability
- Scalability
* Usability
- Who is the target audience? General public? GIS Analyst?
- Matt feels the target audience is professionals who provide advice to decision-makers, but are not GIS Analysts.
- Paul pointed out that the spike of knowledge for these users is different between each user, because of the different domain expertise.
- Agreement that the goal is to unload work from GIS Analysts, so general public would be the target user.
- There are a number of different perspectives -- data, interface, and type of questions asked.
- Focus is on data
- How many variables will be provided?
- Too many will scare off users
- Matt suggested we could provide a lot of variables, but present the 'top 10' so users aren't overwhelmed
- Goal of the first delivery is to provide something compelling, not overwhelming
- Al mentioned that LandData BC was a system where about 12 queries were provided to users that they could refine slightly, and results were presented right away. Any other questions outside of the 12 queries were batched.
- Al will provide Refractions with documentation on this system.
* Performance
- General consensus that the system needs to provide some aspect of real-time performance to give users the ability to see results right away and refine their queries as necessary.
- For Phase 2, one column was used for each data set
- Becomes cumbersome to add more data sets (takes longer each time)
- Overall design philosophy is the incremental cost of adding a new data set should be the same
- Emily reported on her database engine research
- Lucid has offered better performance than Postgres, but there are a few stability issues
- Next step is to investigate SQL Server OLAP tools -- is a licensing cost associated with this solution
- Investigation will be ongoing as we proceed with user interface design
- A possible solution would be to build our own engine
- downside is net new code
- upside is better performance
- Matt asked about the option of only delivering a limited number of data sets
- Would only end up being 40 to 50, which may not be useful
* Security
- No security requirements
- By design, we are dealing with data that is public
* Legal
- Should provide some sort of disclaimer
- Source acknowledgment for data
- Providing this in metadata is sufficient
* Interoperability
- Map service interface per CGDI
- Seamless integration with provincial government standard applications
- Format requirements
- ARC Grid
- GRASS Grid
- R Grid (?)
* Scalability
- How many people can use system?
- How much data can it hold?
- Can meet performance requirements when there are 2 or fewer simultaneous users
* Matt asked about when the documents would be delivered
- Refractions has internal meeting on Jul 18, will discuss and let Matt know
* Requirements for data format will be given to data providers at a later date
* Anticipating that data layer information should be complete by the Fall
* Working group will meet every two weeks from now on, Refractions will meet with just Matt on the alternate weeks
* Next week's meeting will be on Monday Jul 23 at 10 (instead of Tuesday)
Action Items
* Al Sutherland to provide Refractions with LandData BC documentation. * Refractions to update and circulate schedule.
