A couple of fixes

tutorial/01-nodes.osm

@@ -29,12 +29,12 @@ If you define a bounding box using a fixed set of points, then the query will
 only ever use that geographic area. But sometimes you want to run a query over
 whatever section of the map you're currently looking at.
 
-The Overpass Turbo IDE provides a third way to define a bounding box. But automatically
+The Overpass Turbo IDE provides a third way to define a bounding box, by automatically
 inserting the coordinates for the current map view into your query.
 This is specified by including the "`{{box}}`" shortcut instead of the coordinates. Overpass Turbo will then adjust
 your query before its run.
 
-This won't happen if you submit a query directly to the API. Its only a feature of the IDE. But
+This won't happen if you submit a query directly to the API. It's only a feature of the IDE. But
 helpful when you're writing queries interactively.
 
 When should you use the different variations?

tutorial/02-node-output.osm

@@ -44,7 +44,7 @@ node;
 
 //...and output data about those nodes
 
-//Outputing ids only means Overpass Turbo can't draw you a map,
+//Outputting ids only means Overpass Turbo can't draw you a map,
 //you'll just get some XML output
 out ids;
 

tutorial/10-the-default-set.osm

@@ -22,7 +22,7 @@ and produce output from multiple named sets of results.
 */
 [bbox:-25.38653, 130.99883, -25.31478, 131.08938];
 
-//find nodes within out bounding box that have a name
+//find nodes within our bounding box that have a name
 //and write the result to the default set
 node["name"]->._;
 

tutorial/14-searching-by-polygon.osm

@@ -3,8 +3,8 @@ OverpassQL supports searching for features within a polygon defined by a collect
 points.
 
 The `poly` filter accepts a single parameter. This must be a string value that
-contains an even number of latitude and longitude pairs. Collectively these
-coordinates should define a closed shape on the map.
+contains latitude and longitude pairs. Collectively these coordinates should define a
+closed shape on the map.
 
 This polygon is then used as the boundary for the query.
 

tutorial/16-ways-and-their-nodes.osm

@@ -5,7 +5,7 @@ their outline.
 In OverpassQL we do this using the "recurse down" statement "`>`".
 
 This statement takes an input set of elements and then finds any
-node (or way, or relation) that are a member of those elements.
+node (or way, or relation) that is a member of those elements.
 
 The members of a way are its nodes.
 

tutorial/17-ways-and-their-tags.osm

@@ -6,7 +6,7 @@ That includes filtering them based on their tags. Or using them to search
 nearby on the map.
 
 The query below selects just those ways in our bounding box that have been
-tagged as a tourist attraction. As the time of writing, that results in a
+tagged as a tourist attraction. At the time of writing, that results in a
 single way which marks out the boundary of Uluṟu.
 
 See the query comments for other variations to try, including finding

tutorial/20-relations.osm

@@ -6,7 +6,7 @@ Relations are collections of nodes and ways. They describe logical groupings of
 objects that go beyond their basic spatial relationship. For example a relation
 can be used to describe:
 
-* a bus route, which connects a set of bus stop (nodes) and ways (the route)
+* a bus route, which connects a set of bus stops (nodes) and ways (the route)
 * an administrative boundary
 * a multipolygon, such as a collection of buildings that represent a single location
 

tutorial/22-areas.osm

@@ -47,20 +47,20 @@ way(area);
 ```
 
 The `area` filter restricts the ways (or nodes, or relations) we're interested in
-to just those that within an area we've already found. This type of spatial query
+to just those within an area we've already found. This type of spatial query
 isn't normally available for ways and relations. I presume this is to limit the amount
 of indexing required to support this type of query.
 
 The `area` query and the `area` filter both work with named sets. By default they work
 with the default set (`_`). And this is what the example query uses.
 
 But an alternate way to write this example is to explicitly store the area we're
-interested in a named set. I find this a bit clearer in practice.
+interested in in a named set. I find this a bit clearer in practice.
 
 Here's how this would look, using a named set called `ourArea`:
 
 ```
-area["name"="Uluru-Kata Tjuta National Park"]->.ourArea;
+area["name"="Uluṟu-Kata Tjuṯa National Park"]->.ourArea;
 (
  way(area.ourArea)["natural"="bare_rock"];
  >;

tutorial/24-mapToArea.osm

@@ -16,7 +16,7 @@ that is found just east of Uluṟu. This is stored in a temporary named set.
 We then use the `map_to_area` statement to find the area corresponding to
 that relation. This is saved in a variable called `mutitjulu`.
 
-We then do a couple of type agnostic queries to find node, ways and relations
+We then do a couple of type agnostic queries to find nodes, ways and relations
 that are tagged as buildings or leisure areas.
 
 @title 24 - Find the area derived from a feature