JavaScript代写:MCD4290 Surveying App

使用Google Map API代写一款测量类型的Web应用程序。

Aim

Often in real estate, surveyors are brought in to establish the exact size of properties and compare them against the deed to a property. This can then be used to determine where to set fences so that the fences sit on the boundaries between properties. For this assignment you will create an app to assist in surveying a property. Your app will allow someone to walk along the boundaries of a property or area and then display to them the perimeter and area of that property as well as given them an estimate of how much fencing would be required to border the area.

Background

Your team has been hired by Prop & Tee Pty Ltd, a British property development company based in London, UK. They are interested in expanding into Australia and Malaysia, however they don’t yet have the appropriate resources in place. After speaking with their representative, Sir Vayer, you have learned that they are interested in having your team develop an app that can be used by contractors to easily size up a property; this would tell them how big it is as well as how much it would cost them to develop.

For the moment, they are interested in a proof of concept which can calculate the area, perimeter and estimate the amount of fencing necessary to border the property. If they are satisfied with this prototype, they will pay for a full version of the app to be developed (including things like the dimensions, elevation, calculation of expandable areas, look up of local zoning laws, etc.).

What you are provided with

We have made available a skeleton version of the app. The skeleton provides you with several HTML pages and associated JavaScript and CSS files representing the structure of the app. You will need to implement the logic and functionality for each of these pages as described below.

The app skeleton can also be found on the MCD4290 Moodle site

The app skeleton contains three web pages that utilise MDL for their interface:

  • Regions List page (main index page)
  • Record Region page
  • View Region page

A “region” is a series of ordered corners bounding a polygonal area. We will assume this is a sensible shape, i.e., doesn’t have crossings.

In the app skeleton, these pages are mostly blank and include sample entries only to demonstrate how to change from one page to another. You may modify these as you like, however you should not change the names of these files.

The app skeleton contains a displayMessage function you can use to display toast messages like in Assignment 1.

What you need to do

This assignment consists of multiple tasks, including programming, documentation, and use of software tools. For the programming tasks, we suggest you complete each step together as a team before moving onto the next one. It is strongly recommended that you practice pair programming rather than trying to split up the coding and attempting parts individually.

You will need to communicate effectively with your team while working on the assignment. Your individual use of Git, Asana, and Google Drive will affect your final marks on this assignment and as with Assignment 1, your final marks will be scaled by your team contribution as determined by CATME.

Finally, there will be a 15 minute team “client” presentation (12 minute if the number of students is 3) as well as an individual interview on your submitted code, both of which will occur during your week 12 practical class. This is described in a later section in this document.

Getting started

  1. One team member should create an “assignment2” directory with the necessary initial directory structure in your team Git repository by committing the provided skeleton code (see the Skeleton code and also the “Submission” section below).
  2. One of your team members should set up an API key for Google Maps attached to a team Google account, if you didn’t already obtain one as part of the Week 5 prac exercise.
  3. Your team should read and discuss the list of required functionality below and create Asana tasks for the necessary features. You may need to think about and break these down into further subtasks. We strongly recommend doing pair programming for those that are weak in coding.
  4. Consider usability principles when designing the application interface and behaviour .

Required functionality

  1. Create a class/constructor for a Region
    The app will allow the user to record several different regions and calculate some information for these. This means it will be necessary to be able to distinguish them from one another. Create a constructor for a Region class which will have several private attributes: an array of corner locations, the date (and time) the region was saved, and any other necessary information.

  2. Location tracking
    On the Record Region page, the app should track and display the user’s current location. Their position and the location accuracy should be displayed graphically on an interactive map.
    This page should allow the user to repeatedly “add a corner” based on their current location as they walk the perimeter of an area. These corners will form a new Region. As the user adds corners they should be able to see the updated region polygon displayed on the map.
    The user should be prevented from adding a corner if the location accuracy is too low (e.g., the GeoLocation accuracy is greater than 10 metres).
    You should also ensure that the users are given a method to reset the Region if they make a mistake.
    Note:

    • Ensure corners stored in a Region are instances of the google.maps.LatLng class to allow you to use Google’s geometry API.
    • You can assume that the user visits each of the corners in order around the boundary of the Region.
  3. Persistent storage of Region instances
    The Record Region page should provide the user the ability to save the new region once they have finished recording the corners. This should store the region in local storage and return the user to the Region List (index) page.
    Note:

    • Be sure that you store regions in such a way that you can retrieve all of your regions from local storage later.
    • You may choose to allow the user to store a given Region with a nickname for easy identification later.
  4. Showing a list of Regions
    Once you have one or more Region instances stored in local storage, you should modify the Region List (index) page so that it displays a list of Regions that can be viewed. This list should be generated from information in local storage and should include the date/time when the region was recorded (and any other information you would like to display). Clicking on an entry in the list should cause the app to navigate to the View Region page and show that Region.

  5. Viewing a Region
    When the user views an existing region via the View Region page, the app should display the region on an interactive map.
    This page should provide the user a method to remove that Region, which will remove the Region from local storage and return them to Region List (index) page.

  6. Region area and perimeter
    You should add methods to the Region class which calculate and return the area and perimeter of the region. Update the View Region page to display this information.
    Note:

    • The Google Maps (spherical) geometry API provides useful functions; please see resources for documentation.
      • computeDistanceBetween() - returns the distance between two google.maps.LatLng class instances in metres.
      • computeArea() - given an array of google.maps.LatLng instances, returns the area of the corresponding polygon in square metres.
    • To use the geometry API you should add the “&libraries=geometry” to the query string to the URL used to load the Google Maps script. This is not always necessary but can cause errors in some circumstances if missing.
    • Ensure that you correctly create Region class instances when loading
      Regions from local storage, so that you can use these methods from the View Region page.
  7. Calculating fencing required
    Add one more method to the Region class to return an array of fence post locations, named boundaryFencePosts. You can assume that fence posts should be spaced at most every 4 metres, equally along each side of the boundary polygon with a fence post at each corner.
    For example a 14 metre side requires three fence posts along that side (excluding the corners). You can assume these three posts split the side into four equal spans and so are positioned 25%, 50%, and 75% of the way along the side.
    When on the View Region page, the user should be given a way of toggling on and off the display of fence posts on the map (represented as dots positioned along the boundary).
    Note:

    • The Google Maps (spherical) geometry API provides useful functions; please see resources for documentation.
      • computeDistanceBetween() - returns the distance between two google.maps.LatLng class instances in metres
      • interpolate() - returns a new google.maps.LatLng class instance representing the position between two specified google.maps.LatLng class instances based on a fraction of the distance between.
    • If you choose, you may elect to allow the user to choose their own maximum distance between fence posts (instead of 4 metres) and have your app update the resulting post positions.
      The programming tasks together are worth 9% of your unit mark. Feel free to modify or extend your app as you like, provided it has the required functionality. In particular, ensure you consider usability principles in designing the behaviour of the app.

Technical documentation

Your team should produce two short pieces of technical documentation for your app:

  • A basic Project Management Plan. This is internal documentation detailing:
    • Project aim and scope
    • Team members, and their responsibilities
    • How you are going to do the project, e.g., team meetings, minutes,
    • handling communication of changes to the code
    • Any other information you would want to give to a new team member
  • A User Guide. This is external documentation detailing:
    • How to get started using the app, with screenshots
    • Any known bugs or limitations

Your team will be assessed based on the quality of these documents. This will be worth 9% of your mark for the unit.

Presentation

Your team has now finished (or mostly finished) the prototype surveying app for Prop & Tee Pty Ltd. Their representative, Sir Vayer, has organised time for each of the prospective teams (yours and your competitors) to demonstrate their apps. Based on the client’s satisfaction with the prototypes and presentations, they will decide which team will be awarded the contract to produce the full app.

While you will be primarily presenting to the client (Prop & Tee Pty Ltd), your team can expect both representatives from the client as well as other hopeful software teams to be in the audience. Ensure that your presentation explains the features of the app. It should explain how the app works and describe any specialised hardware required. You should talk at a high level about architecture in order to explain how the app might be extended or what additional features could conceivably be built on top of it, but you should be careful not to include much technical detail or jargon.

This presentation will be a formal shared talk delivered in front of your prac class. It will be based on the app you produced for Assignment 2. As with any good presentation, it should be prepared well in advance of the due date (including any visual aides) and it should be well rehearsed as a team. Note that the purpose of this is not to ‘sell’ the app, but rather to convince the client that you met the requirements.

Format

Each student team will deliver a 15 minute oral presentation (in prac class) describing and demonstrating their app and detailing any issues they encountered. Every member of the team should present for 3-5 minutes.

  • The target audience for this presentation is the client who is expecting an explanation of what they are receiving.
  • This presentation would be delivered in a formal business setting and so all team members should be dressed appropriately
  • This presentation must discuss the structure and functionality of the application as well as any design decisions made

This presentation will be worth 6% of your final mark for the unit.

Testing the app

  • Save your assignment folder on your mobile device “Transfer files (MTP) option, under Use USB for” should be selected,
  • Go to file:///sdcard/ using google browser (on your mobile phone, open google browser and write file:///sdcard/ in the address bar),
  • Then select your folder and click on the index.html file.

Resources