openaustralia/planningalerts

View on GitHub
app/views/atdis/_section_4_3_1.html.haml

Summary

Maintainability
Test Coverage
:markdown
  <h4 id="section4.3.1">4.3.1 Info [Mandatory]</h4>

  The `info` record is the top-level block that contains unique identifying information about a single development application. The `info` record must contain the following fields:

%table
  %tr
    %th M/O
    %th{ colspan: 2 } Fields
    %th Notes
  %tr
    %td M
    %td
      %code dat_id
    %td
    %td An id that uniquely identifies the application within this authority
  %tr
    %td M
    %td
      %code development_type
    %td
    %td Relevant category requested by Planning and Infrastructure for the Local Development Performance Monitoring program
  %tr
    %td M
    %td
      %code application_type
    %td
    %td The Agency needs to collect statistics on types of application so that it can assess the effectiveness of different assessment pathways. Valid types are: DA, CDC, S96, Review, Appeal, Other.
  %tr
    %td M
    %td
      %code last_modified_date
    %td
    %td The date of the last change to this record
  %tr
    %td M
    %td
      %code description
    %td
    %td A short, human readable description of the application
  %tr
    %td M
    %td
      %code authority
    %td
    %td Identifying information for this Authority
  %tr
    %td M
    %td
    %td
      %code ref
    %td The unique Authority identifier (UAI) for this authority
  %tr
    %td M
    %td
    %td
      %code name
    %td Human readable Authority name
  %tr
    %td M
    %td
      %code lodgement_date
    %td
    %td Date the application was lodged with the Authority
  %tr
    %td M
    %td
      %code determination_date
    %td
    %td Date that the application was determined at the Authority
  %tr
    %td M
    %td
      %code determination_type
    %td
    %td One of the determination types specified below
  %tr
    %td M
    %td
      %code status
    %td
    %td Current status of the application with the Authority
  %tr
    %td O
    %td
      %code notification_start_date
    %td
    %td Start date for notification period of application
  %tr
    %td O
    %td
      %code notification_end_date
    %td
    %td End date for notification period of application
  %tr
    %td O
    %td
      %code officer
    %td
    %td Name of responsible officer from the Authority
  %tr
    %td O
    %td
      %code estimated_cost
    %td
    %td Estimated cost of the work described by the application
  %tr
    %td O
    %td
      %code related_apps
    %td
    %td List of fully qualified authority/ref/dat_id for related applications

:markdown
  **Notes**

  * If the field `dat_id` contains non-URL characters in its raw form, then it must be URL-encoded so that it can form part of a valid URL.

  * The value `development_type` should be the relevant category requested by Planning and Infrastructure for the Local Development Performance Monitoring program. ATDIS seeks to reduce Council manual work effort spent each year extracting, collating and reporting DA data for the annual Local Development Performance Monitoring report prepared by Planning and Infrastructure. In this context, `development_type` is a key piece of data needed for this report.

  * The field `last_modified_date` captures the date at which the authority last modified the record. This allows consuming systems to know if an application changes over time. The `last_modified_date` field in the info record should capture the date that the application was last changed in the underlying source system. Vendors are responsible for determining which internal date in their system is the relevant field to use to populate this value. Conceptually, the `last_modified_date` field is the business concept that represents the date/time that the application was changed.

  * Dates can be specified with or without time information. For example, the following are both valid date values (see also 4.3.8):

    ```
    "determination_date": "2013-06-20T02:01:07Z"
    ```

    ```
    "determination_date": "2013-06-20"
    ```

  * If the application does not have a determination date (yet, or at all), the value “`null`” should be specified for the `determination_date` field.

  * The `notification_start_date` and `notification_end_date` are optional fields. Vendors are free to populate this value if it is available in the source system.

  * The contents of `determination_type` and should be one of the values:
    * Pending
    * Refused by Council
    * Refused under delegation
    * Withdrawn
    * Approved by Council
    * Approved under delegation
    * Rejected

  * If the application does not have a notification period at all, the value “`null`” should be specified for the `notification_start_date` and `notification_end_date` fields.

  * The contents of `estimated_cost` and should be a formatted currency string in Australian Dollars, of the form “$300,000”.

  * If an application is related to other applications either within this LGA or in another LGA, then `related_apps` may contain a list of references to other applications. The reference should include the `authority/ref` value for that LGA as well as the `dat_id` in each case. The reference should be a URI that includes the protocol and the globally unique application id followed by the `dat_id` and `.json`. The specification does not prescribe the *type* of the relationship, other than to say that if this field is included, consuming systems should assume that the other applications are related to this one in some form. The intent of this field is to capture the relationship between applications with different application numbers.

  * If a consuming system accesses a specific record using the globally unique identifier, the System should return data for just the single application record that was asked, and no others.

  * Any globally unique id used in `related_apps` should also include the format (`.json`) in the URL.