fix some typos

migrations/011.sustainability.down.sql

@@ -1,15 +1,15 @@
--- Remove sustainability fields, update in paralell with adding new fields
+-- Remove sustainability fields, update in parallel with adding new fields
 -- BREEAM rating
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_breeam_rating;
 -- BREEAM date
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_breeam_date;
 
--- DEC (display energy certifcate, only applies to non domestic buildings)
+-- DEC (display energy certificate, only applies to non domestic buildings)
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_dec;
 -- DEC date
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_dec_date;
 
---DEC certifcate lmk key, this would be lmkkey, no online lookup but can scrape through API. Numeric (25)
+--DEC certificate lmk key, this would be lmkkey, no online lookup but can scrape through API. Numeric (25)
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_dec_lmkey;
 
 -- Aggregate EPC rating (Estimated) for a building, derived from inidividual certificates

migrations/011.sustainability.down1-extra.sql

@@ -1,4 +1,4 @@
--- Remove sustainability fields, update in paralell with adding new fields
+-- Remove sustainability fields, update in parallel with adding new fields
 -- Last significant retrofit date YYYY
 -- Need to add a constraint to sust_retrofit_date
 -- Renewal technologies
@@ -6,7 +6,7 @@
 -- Values:
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_renewables_tech;
 
---Has a building had a major renovation without extenstion (captured in form)
+--Has a building had a major renovation without extension (captured in form)
 --Boolean yes/no - links to the the DATE
 ALTER TABLE buildings DROP COLUMN IF EXISTS sust_retrofitted;
 

migrations/011.sustainability.up.sql

@@ -20,7 +20,7 @@ ALTER TABLE buildings
 ALTER TABLE buildings
     ADD COLUMN IF NOT EXISTS sust_breeam_date smallint;
 
--- DEC (display energy certifcate, only applies to non domestic buildings)
+-- DEC (display energy certificate, only applies to non domestic buildings)
 -- A - G
 CREATE TYPE sust_dec
 AS ENUM ('A',

migrations/011.sustainability.up1-extra.sql

@@ -1,10 +1,10 @@
--- Remove sustainability fields, update in paralell with adding new fields
+-- Remove sustainability fields, update in parallel with adding new fields
 -- Last significant retrofit date YYYY
 -- Need to add a constraint to sust_retrofit_date
 ALTER TABLE buildings
     ADD CONSTRAINT sust_retrofit_date_end CHECK (sust_retrofit_date <= DATE_PART('year', CURRENT_DATE));
 
---Has a building had a major renovation without extenstion (captured in form)
+--Has a building had a major renovation without extension (captured in form)
 --Boolean yes/no - links to the the DATE
 ALTER TABLE buildings
     ADD COLUMN IF NOT EXISTS sust_retrofitted boolean DEFAULT 'n';

migrations/016.landuse.down.sql

@@ -1,4 +1,4 @@
---Landuse is hierachical. Highest level is Order (ie. Residential) then Group (ie Residential-Dwelling) then Class (ie Residential-Dwelling-Detached house)
+--Landuse is hierarchical. Highest level is Order (ie. Residential) then Group (ie Residential-Dwelling) then Class (ie Residential-Dwelling-Detached house)
 --Interface will collected most detailed (class) but visualise highest level (order)
 --Landuse is a table as #358
 --Land use class, group and order will be stored in a new table

migrations/016.landuse.up.sql

@@ -1,5 +1,5 @@
 -- Create land use and fields
---Landuse is hierachical. Highest level is Order (Residential) then Group (Residential-Dwelling) then Class (Residential-Dwelling-Detached house)
+--Landuse is hierarchical. Highest level is Order (Residential) then Group (Residential-Dwelling) then Class (Residential-Dwelling-Detached house)
 --Some ETL work required to get this together refer to analysis repo
 --Prerequesite is to have first run bulk_data_sources migrations
  --Then create table landuse_order for the app, this is used as foreign key for current and original landuse_order
@@ -36,11 +36,11 @@ FROM reference_tables.landuse_classifications a
 WHERE a.level = 'class'
   AND a.is_used;
 
---Landuse is hierachical. Highest level is Order (Residential) then Group (Residential-Dwelling) then Class (Residential-Dwelling-Detached house)
+--Landuse is hierarchical. Highest level is Order (Residential) then Group (Residential-Dwelling) then Class (Residential-Dwelling-Detached house)
 --Interface will collected most detailed (class) but visualise highest level (order)
 --Landuse is a table as #358
 --Prerequisite run bulk_sources migration first
- -- Land use is table with 3 levels of hierachy (highest to lowest). order > group > class
+ -- Land use is table with 3 levels of hierarchy (highest to lowest). order > group > class
 
 
 -- Land use order, singular. Client and db constrained with foreign key

migrations/022.community.down.sql

@@ -3,7 +3,7 @@
 -- -- Ownership type, enumerate type from:
 -- ALTER TABLE buildings DROP COLUMN IF EXISTS ownership_type;
 
--- -- Ownerhsip perception, would you describe this as a community asset?
+-- -- Ownership perception, would you describe this as a community asset?
 -- -- Boolean yes / no
 -- ALTER TABLE buildings DROP COLUMN IF EXISTS ownership_perception;
 

migrations/unreleased/0xx.team.down.sql

@@ -1,3 +1,3 @@
--- Remove team fields, update in paralell with adding new fields
+-- Remove team fields, update in parallel with adding new fields
 -- Award or awards (may be multiple) stored as json b object
 ALTER TABLE buildings DROP COLUMN IF EXISTS team_awards;

migrations/unreleased/0xx.team.up.sql

@@ -3,6 +3,6 @@
 ALTER TABLE buildings
     ADD COLUMN IF NOT EXISTS team_awards jsonb;
 
---To validate this input, the following confirms it's an valid object but not that the items in the object are validated agains those we will acccept
+--To validate this input, the following confirms it's an valid object but not that the items in the object are validated against those we will accept
 ALTER TABLE buildings
     ADD CONSTRAINT data_is_valid CHECK (is_jsonb_valid ('{"type": "object"}', team_awards));