This page is for keeping track of the preparation of the CAPRA project: confirming the spec, estimation, etc.
CAPRA Terms of Reference http://docs.google.com/Doc?id=dc2xqjrt_29d2xdw5ff&pli=1
Unanswered questions are in bold.
First Roadmap
Based on notes from 20091505SpecMeeting
"From breakdown doc" means this is a quote from the email, subject "#js CAPRA overview", quoted in full here: JSCAPRAOverview
1. Serve geospatial data
Serve geospatial data. The site will host the data and be able to store data added by users. This data will primarily be the map products of the first phase of CAPRA, specifically the hazard and risk maps. The Hazard maps are in .ame format, the risk maps are in .shp format. The maps will be in multiple resolutions covering the same territory. It is required to transition smoothly between these maps whenever a user chooses to zoom in or out altering the scale or the map.
#1 We know we can do this and should estimate it out.
#11 Estimate .ame support
2. Visualize data within a 3 & 2 D Earth context
Visualization. The GUI will be a web based platform using a 3 & 2 D Earth model to allow the user to easily access and interact with data. Visualization will cite official CAPRA layers and have limitations on “Fitness of Use.”
#2 For 2-D, we know we can do this and should estimate it.
#3 Investigate 3D and determine feasibility/difficulty of development. Get back to them with estimate.
- When this is done, #js should #4 estimate the 3D visualization.
From breakdown doc:
Something similar to http://demo.mapfish.org/mapfishsample/trunk/examples/earth/earth.html where that users can switch to 3d view mode using the google earth plugin. This is simply another way to view the map, nothing else.
3. Download geospatial data
Download Data. The user interface should allow for quick and easy access and download of the data. The downloading capabilities of version 2.0 of the clearing house shall be tightly integrated to the search capabilities present in that version.
#5: For most of this, we know we can do it and should estimate it.
Pushback: Can we get references to 2.0 requirements removed from any official contract?
CH: "I imagine we can. Or at least clearly set in a separate section. I could see if they want us to make a 2.0 design doc they'd want to put what they want in 2.0 in some part."
4. Edit and Analyze data with simple GIS tools
From ToR:
Manipulating Data. The eventual goal for the Clearing House is to have rudimentary GIS functionality, for users with spatial data that requires cleaning, updating or basic analysis to become useful.
* User will be able to covert data between multiple spatial data formats, including shapefile, .kml and .ame.
* Ability to compose maps.
* Ability to export maps to blog/webpage in .shp, .pdf, .kml, and embedded webpage format.
* Ability to print maps from the user interface
#6 Estimate the map composition and updating parts of the CAPRA Clearing house.
#12 Estimate exporting in .shp, .pdf, .kml
#7: Estimate saving (and loading) a context document to the server.
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. A: CH: "Yeah, the final contract we'll just say exactly the functionality that we'll build." A: (from Whit, 5-15-09):
perhaps we could define compose maps as: combine and style available layer to create a new map? and updating as the act of adding and removing additional layers and style rules? unsure about cleaning and basic analysis.
Q: What are "cleaning" and "basic analysis"? We cannot estimate these features based on these descriptions.
From breakdown doc:
Export functionality =============== sort of a catchall, export may be the only step in a user workflow, and will be the endpoint for many workflows. different forms: * Save: persisting a context document to the server (possibly just a json state dump) * Downloads: shp, kml, pdf * Embeddable html snippet ala GeoBuilder
"Export from GeoBuilder"-like functionality
This requires the work from tickets 198,199, 200 and 215 from projects.opengeo.org/geoext/
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)
A: From Whit:
One way to view the the snippet export in CAPRA is as GeoBuilder reduced to three screens: metadata, choose layers, output. Hopefully, GeoBuilder will be a couple weeks ahead of CAPRA, and CAPRA will be able to at least fork if not smoothly reuse this design and code. In an ideal world, geobuilder would be done before we did snippet export in CAPRA. In reality, things will likely not be as neat, but if that means CAPRA funds some of geobuilder's dev, that's ok. CAPRA is the priority, the active contract, geobuilder is important but slightly longer arc.
Q: Is estimating this part of CAPRA estimation, or is it part of GeoBuilder estimation? A: CH: "Both? I mean, we should account for it in the CAPRA estimates, even if we end up in-kinding it (which we likely will)."
TODO: #js Look at Rollie's design doc for "Export from GeoBuilder". Estimate if possible or else provide feedback, ask for clarification.
http://projects.opengeo.org/geoext/wiki/GeoBuilder
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.
Printing
#9 Estimate printing
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.
A: From Cholmes:
Yeah, I hope we have time to integrate some of the nice mapfish printing UI stuff, and I'd like to see an estimate of what that would take. But contract I will be sure just specifies very basic pdf output, and if we go above and beyond then great.
A: From whit:
printing is already on the pushback wagon, and I would assume that if it goes forward, it will be however the mapfish plugin delivers it most easily and we should write the contract as so.
From breakdown doc:
UI for the mapfish integration. may be removed from this proposal
Based on this, it looks like we should have a *low priority* task to:
5. Upload and style geospatial data
From ToR:
Uploading Data. To encourage additions to the CAPRA database, adding data should be a quick and painless process.
# User may add files after creating user profile.
# Ability to style data into a comprehensible form.
# Ability to perform batch uploads.
See UploadWorkflow for rough workflow spec.
#13: #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.
From breakdown doc:
Will work against GeoServer user management and authentication api. * Login and registration interaction (intricacy somewhat dependent on interaction design. jit? level of desired security, etc?)
(from cholmes: this is optional, likely will cut) * allow any user to open styler onto existing layers * save SLD files for user (probably only for authenticated users) * render the styles where appropriate from geoserver
From breakdown doc:
This is the central participatory workflow 1. upload a shapefile or geotiff * in batch * w/ progress? 2. Prompt user for an metadata. * prompt a user to login or register if not logged in 3. if vectors, allow styling via styler
6. Detailed user profiles
From ToR:
User Profiles. To create a sense of participation and ownership the user profiles will be a central feature of the clearing house.
# Feature an individual’s maps and data contributions
# In order to access the site, users will register a detailed user profile.
See UserWorkflow
#14: #dzn Provide a wireframe/functional spec of user profiles
- TODO: #gs Estimate
From breakdown doc:
* Ability to browse profiles - user statistics (mockable?) - view of activity: maps and contributions
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. CH:
That is ultimately their call, but I agree, and have already pushed back on it. The ideal is we slowly extract more profile information as they do actions that are useful for them. Like when they get to exporting, or when they upload data.
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? CH: I've emailed World Bank people about getting user stories, with Rollie cced to extract more information.
7. User Statistics
User statistics. The clearing house shall feature prototype use of user statistics for adoption in Version 2.0. This use shall seek to further encourage user participation in the portal.
See StatisticQueries
Q: Which user statistics? These need to be speced out before we can estimate anything. CH:
I'll get back to you on this. But basically how many times a users maps have been clicked on. Maybe how many times their profile has been viewed. In the end we want to get stats on ratings/tags/comments/views on maps, styles and datasets. But for this we just need to demonstrate some of those concepts.
8. Collaborative features
Collaborative features. The clearing house shall feature prototype collaborative features for adoption in Version 2.0. These shall include the ability for users to tag, rate, score and comment on maps.
#16 : Design collaborative features
- #15 Estimate collaborative features
9. i18n support
Language. All software produced in associated with this contract will be in English and Spanish. All documents produced in association with this contract will be in English. The World Bank will provide support with translation as necessary.
#8: #js Estimate this.
10. Documentation
Document use and design of clearing house on CAPRA wiki
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. A: CH:
I'm having Sophia gather outreach team estimates, and have told them to do docs. A bit of jteam time should likely be in support of that.
Q: Will documents created in OpenOffice work for them? CH: I can ask.
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. CH: JS team will need to put some time in to the design document, since js team will play a big role in building 2.0
