2009-14-05 CAPRA Spec Meeting

Present: Rollie, Dwins, Funky-C, Seb.

Goals: Go through the CAPRA spec, determine actionable steps towards estimation and blockers.

Refers to CAPRA Terms of Reference  http://docs.google.com/Doc?id=dc2xqjrt_29d2xdw5ff&pli=1

SUMMARY

1. Serve geospatial data.

  • TODO: #js We know we can do this and should estimate it out.
  • Q: Except for .ame format. Do we need to read it? We don't think this requires any new UI stuff, but should confirm that with backend team.

2. Visualize data within a 3 & 2 D Earth context.

  • TODO: #js For 2-D, we know we can do this and should estimate it.
  • TODO: #js Investigate 3D and determine feasibility/difficulty of development. Get back to them with estimate.

3. Download geospatial data.

  • TODO: #js For most of this, we know we can do it and should estimate it.
  • Q: Except for question about range of file formats. Which are supported? Is .ame supported?
  • Pushback: Can we get references to 2.0 requirements removed from any official contract?

4. Edit and Analyze data with simple GIS tools.

  • Q: Much of the language here is unclear. "compose maps," "cleaning, updating, or basic analysis", need to be specified to avoid scope creep and facilitate estimation.
  • Q: How does "exporting in kml, shp, pdf" differ from downloading it? Does it imply a separate user interface for providing an embeddable URL, for example? If not, can we strike this feature from the contract?
  • TODO: #js Look at Rollie's design doc for "Export from GeoBuilder". Estimate if possible or else provide feedback, ask for clarification.
  • TODO: #biz Show Rollie's design doc for "Export from GeoBuilder" to WB and get their feedback, set their expectations, make sure they want it.
  • Q: Is this work going to be on the CAPRA budget, or will it be one the GeoBuilder project "budget" (since it clearly overlaps both)
  • Q: Printing maps from the user interface. Is downloading to PDF sufficient? We would like it to be; if it is, we should specify that in the contract.

5. Upload and style geospatial data.

  • TODO: #dzn Provide preliminary interaction design/wireframes/description of view and their interaction.
    • TODO: #biz When those preliminary specs are done, we should run them by the WB
    • TODO: #js When those preliminary specs are done, we should estimate them and/or ask questions, do pushback.

6. Detailed user profiles.

  • TODO: #dzn Provide a wireframe/functional spec of user profiles
    • TODO: #gs Estimate
  • Pushback: We think think it's stupid to *require* a user to fill out a detailed profile to access the site. That shouldn't be part of the final spec.
  • Q: How do we incentivize this for users? What should this look like from a user perspective? Who are the users, why do they want/need to use this, and what are they doing with it?

7. User Statistics

  • Q: Which user statistics? These need to be speced out before we can estimate anything.

8. Collaborative features

  • Q: These features need to be speced out before we can estimate anything.

9. i18n support

  • TODO: #js Estimate this.

10. Documentation

  • Q: Is it realistic to say that #js resources won't have to be dedicated to documentation? We doubt it. We should estimate this if this if we are right. Q: Will documents created in OpenOffice work for them?

11. 2.0 Design Document

  • Q: Is it realistic to say that #js and #gs resources won't have to be dedicated to this design document? We doubt it. We should estimate this if we are right.

Details

OVERALL

Who is the audience? Who are the users?

  • This is being shown to WB execs.
  • Ultimately, "people with spatial data"

What are the use cases?

  • People generating and consuming hazard maps

What incentives does this provide?

DATA CLEARING HOUSE

QUESTION: What about Apple MobileMe appeals to the World Bank? How is it related to / different from what they expect from CAPRA? Explain this analogy.

  • It seems to be just about production value, polish, usability, etc. Really?

ACTION: Show WB GeoExplorer, GeoCommons, etc., and make sure their expectations for user experience etc. are sane.

1. Serve geospatial data.

  • Do we need to support .ame reading?
  • A MapPanel showing the map.

2. Visualization

3-D:

What are we using for this? Probably Google Earth Embed KML Plugin.

ACTION: Need to investigate  http://tr.im/embedkml We don't know anything about this, or alternatives. Also, Embed KML doesn't work in Linux, so it's harder to develop on. Should factor this into planning, estimation. Make sure it (a) works with GeoServer, (b) works with GeoExt. If this investigation looks like it will take a lot of time, provide and estimate and track time.

QUESTION: Is this just 3D context, or is it actually 3D data Spec:

  • A MapPanel showing the map
  • CAPRA citation
  • Fitness of Use

3. Quick and easy access to download.

QUESTION: Which formats?

QUESTION: They mention some 2.0 features here -- searching integrated with downloading. That's off our 1.0 spec, right?

4.

QUESTION: Do we have to read and write AME? The terms of reference implies it, but we don't have that capability yet. (We would prefer to not have to implement it).

QUESTION: What, exactly, do they mean by "cleaning, updating, or basic analysis"? We need to get clearer use cases out of them.

QUESTION: What does "compose maps" refer to? What functionality does this entail? Is it more than just adding and ordering layers? This language should be more explicit.

QUESTION: Export in SHP, KML, etc.--is that different from just having it be downloadable? (Does it imply a user interface for embedding links?

QUESTION: Do they know what to expect with the embed-in-webpage bit? We must specify that functionality more in the contract to avoid scope creep.

QuESTION: Print maps from the user interface. To paper, or is PDF close enough? Let's make sure PDF is close enough.

5.

ACTION: Rollie provides preliminary account how how user creation, uploading, styling, map composition, etc. views would work together so we can start estimating out.

6.

ACTION: need wireframe/ funcitonal spec for this user profile.

We think think it's stupid to *require* a user to fill out a detailed profile to access the site. That shouldn't be part of the final spec.

QUESTION: How do we incentivize this for users? What should this look like from a user perspective? Who are the users, why do they want/need to use this, and what are they doing with it?

7.

The NEED To be better speced out before we start development.

QUESTION: What are users using this for? What metrics of success make sense? Should we decide metrics up front?

8.

The NEED To be better speced out before we start development.

QUESTION: See comments above. What metadata is useful to users? To CAPRA? To the world? Are these the same?

9. Translation

i18n support.

Documentation

We probably are going to have to worry about documentation, despite what's been said. Either we need assurances that this work won't be on our plate, or we should expect that it will be and estimate accordingly.

QUESTION: Will documents created in OpenOffice work for them (given Word requirements)?

Design Document

QUESTION: How much of jteam or gteam or design resources are going to be needed for this? Is it realistic that the design document should be entirely out of our scope, or should we be planning to allocate time for that?