Skip to end of metadata
Go to start of metadata
This page describes the plan for implementing a specific task. This includes a list of the task developer(s), description of the task, links to related architecture (and/or design) pages, proposed inputs/outputs of task, some details of implementation of the task, and the proposed task reviewers.

Task Overview

Task Description

A description of the task. This could be a cut/paste from the google doc.

Task Stake Holders

Fill in the primary and secondary (if there is one) developer for the task. Also, add the relevant architect working with your subsystem on the task and if you are working with a designer, add them here. Finally, identify who is going to be the reviewer of the task page before the work starts and then at the end as part of the code review/task review (best to keep this person consistent if possible)
  • Developer(s):
  • Architect:
  • Designer:
  • Task Reviewer(s):

Architecture and Design Inputs

Add links to the architecture pages for relevant topics. The details of the design for the task should be added back into the architecture. Please work with the architects and leads on that. Here are some example links:

Other Inputs

  • (delete me) List other inputs, such as current implementations, use cases, results from previous tasks, dependencies needed etc.

Entry Criteria

  • Assumptions:
    • (delete me) List the assumptions applying to this task.
  • Dependencies:
    • (delete me) List the necessary dependencies that need to be fulfilled before starting this task

Proposed Task Work Description

Context and Problem description


Proposed Work Steps

Proposed Task Outcome Description

Initial Comments:

  • Easy to set up with Tomcat.
  • Java Web app is somewhat flexible in terms of heap and storage requirements but I don't think it scales.
  • It uses a MySQL (or Postgres, or Oracle) as a backend which would be required with the instance of Geoportal. MySQL has a cluster component and scales well but I don't know how the geoportal instance would scale with multiple instances, because state is mostly on the mysql database I'm assuming it would be okay but I don't know for certain.
  • Documentation is sparse.
  • There appears to be a RESTful API which includes json support which would make it easily integrable for services to use as a catalog.

If we are going to consider erecting a relational database just for geoportal I would recommend investigating erecting a relational database as our sole catalog. Most databases support geospatial awareness (MySQL, PostGIS and Oracle) and they scale well (MySQL cluster, Oracle) and we would cut out the middle man. Geoportal from my first experience gives me the impression to being a glorified web application wrapper to the SQL database. We could essentially manage our catalogs directly with a relational database which is aware of geospatial content and optimized for searching against it and the other cataloged metadata.

Test Cases Required to Succeed


(delete me) Fill out sections above in design period (as much as possible). Fill out sections below after completion of the task

Task Documentation on Completion

Summary of any key results/important technical findings

Work Result As Implemented

Code Produced
Documentation Produced
Tests Passed

Lessons Learned

Scribbles, Scratch Materials

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.