Map-based visual editor of location-centric data, google maps api expertise critial

INTRODUCTION
We use flat tables with records which comprise five (5) PlaceNames with coordinates, per record, in addition to other data. The location-related field names and formats are set in stone and are the same from project to project (other fields change). In addition to the PlaceName data, each record also contains several "movement" fields. Those too remain the same between projects.

OBJECTIVE

Create an application which will take as input a flat table consisting of data generally described in the Introduction and allow the visual editing of the location and movement information. The application should have the following features:
1. Multiuser
2. Able to access data tables on a LAN
3. End user interface preferably MS Access-based (but not absolutely required)
4. Main editor window should consist of at least 2 panes.
5. The top pane will show a “live” map, e.g. based on Google Maps API or Bing Maps API and the 5 locations of the record being viewed/edited as well ancillary layers (in shapefile or KMZ format) such as routes.
6. Four of the five points will be connected via straight lines/arrows, in order (order is intrinsic to and explicit for each point)
7. Selected point attributes will be displayed as labels on the map
8. The bottom pane will show, in a tabular format, all of the records in the survey table being accessed by the application (scrollable table).
9. The map will zoom by default to show the 5 points for the selected record
10. The user can move any of the 5 location/point icons shown on the map. Moving and releasing a location icon to a new place on the map will update the address and lon, lat for the locations. The addresses will be updated via a reverse-geocoding process supported in the Google maps API. Another API can be used if feasible.
11. The directed arrows between the points in 5.c will dynamically adjust to the new locations
12. The user can choose display one or more routes (see item 5); routes will be labeled using attribute data from the route (line) layer
13. The user can edit a value in any of the fields specified in the Introduction, expect for the ID field. Some fields have predefined value choices.
14. Each edit will trigger an update to the value of the ELVIS_EDIT_FLAG field.
15. The application will provide at least one level of Undo for the edits (this feature can wait until the next version).

RESOURCES
A similar effort was undertaken in 2011, producing a working application (version 1) with some unsolved bugs. Source code and a complete working sample of the application are available and can be re-used at will for this project. A list of issues with the old application is available.
The developer of the v1 application is also available for consultation. Perceived benefits of re-using the older code include a complete and working implementation of Google Maps inside the GUI, with vector overlays including address reverse geocoding via map interaction.

FEE and SCHEDULE
We would like to have a working version of the application (versions 2.0) in three weeks time from the Notice To Proceed (“NTP”). The application should be able to edit data as requested above. The look and feel of the application can be polished later, after this initial deadline, based on user feedback. This initial deadline is based on current project requirements. The fee for this work is negotiable. We prefer a fixed-fee proposal.