[OpenGeo Team] #js CAPRA overview
whit <whit@…> Wed, May 13, 2009 at 6:14 PM Reply-To: team@… To: team@…
thanks to everyone for taking a look at the CAPRA doc and getting moving on this today. sophia is setting up a trac that should be available for tomorrows planning work.
I won't go into the general bits in the depth I did on the phone call, but the general idea is that CAPRA is the proto-geonode. Here is the breakdown of the work as I see from the request document and talking to cholmes.
not really imediately concerning jteam::
* .ame review * version 2.0 document * documentation
Basically, we are charged with planning and estimating the "clearing house"
The GeoServer Side (not our direct responsibility, but what we will be working with)::
* REST API for uploading data * REST API for user account management * mapfish printing integration (might get cut)
The jteam side (what we will be building)::
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
Printing
UI for the mapfish integration. may be removed from this proposal
3d
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.
User Management
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?)
* Ability to browse profiles
- user statistics (mockable?)
- view of activity: maps and contributions
Data Upload Workflow
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
User styling
(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
Collaborative Features
possibly just mockup or where appropriate, local storage
Each service will apply to each our "content types": layers, styles, maps
* ratings: 1-5 stars * simple comments * simple tags
To utilitize the api provided by geoserver for each of these we will need the following views:
* UI elements for the basic CRUD of said annotations in the context of each piece of "content" * views to navigate layers, style and maps by rating, or tag
i18n framework
everything must be translatable into spanish
Concerns
web applications and geoserver
There is alot of CMSish stuff implied here and not all of it seems like core GeoServer bits (mainly in the ratings et al. category). Views can logically hang on the urls of different pieces of content, but it's less clear where some of the more general bits for browsing collections might live (maybe not an issue if the rest api allows for containers for layers, maps, users, etc). We've committed to a REST API for users and uploading, are we will to extend this api if it makes sense for our "content" and how costly is such an extension.
doing everything in a single viewport, though not so web friendly, is an easy way to ignore this concern, but we might revisit it post p.o.c.
time constraints
cholmes think the July deadline maybe important to client budget cycles (POC goes on end of this cycles funds so we can get written into the next cycle), so we may need to err on the side of slick vs. complete per paul's earlier comment.
Estimation
The main thing is to not be surprised by effort required or resources needed. we plan to go over 30k, we would like to know roughly but accurately by how much and what that buys us. so the estimate is almost more important for internal purposes and we should plan to adapt it whenever conditions dictate. We should adjust other commitments to allow all hands on deck if that's what it takes to get CAPRA delivered at the best time for both parties as this could lead to immediate and secondary streams of work.
-w
