Fix some minor issues in docs.

docs/develop/Import.md

@@ -24,7 +24,7 @@ with multiple tags that may constitute a principal tag. Take for example a
 motorway bridge. In OSM, this would be a way which is tagged with
 `highway=motorway` and `bridge=yes`. This way would appear in the `place` table
 once with `class` of `highway` and once with a `class` of `bridge`. Thus the
-*uique key* for `place` is (`osm_type`, `osm_id`, `class`).
+*unique key* for `place` is (`osm_type`, `osm_id`, `class`).
 
 ## Configuring the Import
 
@@ -55,8 +55,8 @@ suffix match can be defined similarly with a string that starts with a `*`. Any
 other string constitutes an exact match.
 
 The second part of the rules defines a list of values and the properties that
-apply to a successful match. Value strings may be either empty, which again
-means that thy match against any value, or describe an exact match. Prefix
+apply to a successful match. Value strings may be either empty, which
+means that they match any value, or describe an exact match. Prefix
 or suffix matching of values is not possible.
 
 For a rule to match, it has to find a valid combination of keys and values. The
@@ -66,7 +66,7 @@ The rules in a configuration file are processed sequentially and the first
 match for each tag wins.
 
 A rule where key and value are the empty string is special. This defines the
-fallback when none of the rules matches. The fallback is always used as a last
+fallback when none of the rules match. The fallback is always used as a last
 resort when nothing else matches, no matter where the rule appears in the file.
 Defining multiple fallback rules is not allowed. What happens in this case,
 is undefined.
@@ -121,17 +121,17 @@ One or more of the following properties may be given for each tag:
 
 * `address`
 
-    At tag to the list of address tags. If the tag starts with `addr:` or
+    Add tag to the list of address tags. If the tag starts with `addr:` or
     `is_in:`, then this prefix is cut off before adding it to the list.
 
 * `postcode`
 
-    At the value as a postcode to the address tags. If multiple tags are
+    Add the value as a postcode to the address tags. If multiple tags are
     candidate for postcodes, one wins out and the others are dropped.
 
 * `country`
 
-    At the value as a country code to the address tags. The value must be a
+    Add the value as a country code to the address tags. The value must be a
     two letter country code, otherwise it is ignored. If there are multiple
     tags that match, then one wins out and the others are dropped.
 

docs/develop/Ranking.md

@@ -21,7 +21,7 @@ Usually only administrative boundaries and place nodes and areas are
 eligible to be part of an address. All other objects have an address rank
 of 0.
 
-Note that the search rank of a place place a role in the address computation
+Note that the search rank of a place plays a role in the address computation
 as well. When collecting the places that should make up the address parts
 then only places are taken into account that have a lower address rank than
 the search rank of the base object.
@@ -37,7 +37,7 @@ into the database. There are a few hard-coded rules for the assignment:
     * highway nodes
     * landuse that is not an area
 
-Other than that, the ranks can be freely assigned via the json file
+Other than that, the ranks can be freely assigned via the JSON file
 defined with `CONST_Address_Level_Config` according to their type and
 the country they are in.
 
@@ -78,12 +78,13 @@ definition is used as a fallback, when nothing more specific for a given
 country exists.
 
 `tags` contains the ranks for key/value pairs. The ranks can be either a
-single number, in which case they are to search and address rank, or a tuple
+single number, in which case they are the search and address rank, or an array
 of search and address rank (in that order). The value may be left empty.
 Then the rank is used when no more specific value is found for the given
 key.
 
-Countries and key/value combination may appear in multiple defintions. Just
+Countries and key/value combination may appear in multiple definitions. Just
 make sure that each combination of counrty/key/value appears only once per
 file. Otherwise the import will fail with a UNIQUE INDEX constraint violation
 on import.
+

docs/develop/overview.md

@@ -1,6 +1,6 @@
 # Basic Architecture
 
-Nominatim provides geocoding based on OpenStreetMap data. It uses a Postgresql
+Nominatim provides geocoding based on OpenStreetMap data. It uses a PostgreSQL
 database as a backend for storing the data.
 
 There are three basic parts to Nominatim's architecture: the data import,
@@ -15,10 +15,10 @@ the import can be found in the database table `place`.
 The __address computation__ or __indexing__ stage takes the data from `place`
 and adds additional information needed for geocoding. It ranks the places by
 importance, links objects that belong together and computes addresses and
-the search index. Most of this work is done in Pl/pqSQL via database triggers
+the search index. Most of this work is done in PL/pgSQL via database triggers
 and can be found in the file `sql/functions.sql`.
 
-The __search frontend__ implements the actual API. It takes queries for
-search and reverse geocoding queries from the user, looks up the data and
+The __search frontend__ implements the actual API. It takes search
+and reverse geocoding queries from the user, looks up the data and
 returns the results in the requested format. This part is written in PHP
 and can be found in the `lib/` and `website/` directories.