cleans some comments

03-spatial-operations.qmd

@@ -1100,10 +1100,7 @@ In our example, the minimum value has to be always the upper left corner of the
 
 Focal functions or filters play a dominant role in image processing.
 For example, low-pass or smoothing filters use the mean function to remove extremes.
-By contrast, high-pass filters accentuate features.
-The line detection Laplace and Sobel filters might serve as an example here.
-<!-- jn: references?? -->
-<!-- md: I'm not familiar with those methods, this sentence is from 'geocompr' (perhaps we can remove it to keep things simple) -->
+By contrast, high-pass filters, often created with custom neighborhood weights, accentuate features.
 
 In the case of categorical data, we can replace the mean with the mode, which is the most common value.
 To demonstrate applying a mode filter, let's read the small sample categorical raster `grain.tif`.

04-geometry-operations.qmd

@@ -284,9 +284,7 @@ nz_shift
 
 Scaling enlarges or shrinks objects by a factor, and can be applied either globally or locally.
 Global scaling increases or decreases all coordinates values in relation to the origin coordinates, while keeping all geometries topological relations intact.
-**geopandas** implements local scaling using the [`.scale`](https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.scale.html) method.
-<!-- jn: what with global scaling? -->
-<!-- md: I think that global scaling can be acheived when passing a "center" that is the same for all geometries (rather than the centroid of each). I'm not 100% sure that's the definition of "global" scaling - will be happy if you can confirm and then will be happy to add it to the note below. -->
+**geopandas** implements scaling using the [`.scale`](https://geopandas.org/en/stable/docs/reference/api/geopandas.GeoSeries.scale.html) method.
 Local scaling treats geometries independently and requires points around which geometries are going to be scaled, e.g., centroids.
 In the example below, each geometry is shrunk by a factor of two around the centroids (@fig-affine-transformations (b)).
 To achieve that, we pass the `0.5` and `0.5` scaling factors (for x and y, respectively), and the `'centroid'` option for the point of origin.

06-reproj.qmd

@@ -73,9 +73,7 @@ But which one is correct?
 The short answer is that the third way to identify CRSs is correct: `EPSG:4326` is understood by **geopandas** and **rasterio** packages covered in this book, plus many other software projects for working with geographic data including [QGIS](https://docs.qgis.org/3.22/en/docs/user_manual/working_with_projections/working_with_projections.html) and [PROJ](https://proj.org/development/quickstart.html).
 `EPSG:4326` is future-proof.
 Furthermore, although it is machine readable, unlike the proj-string representation `EPSG:4326` is short, easy to remember and highly 'findable' online (searching for `EPSG:4326` yields a dedicated page on the website [epsg.io](https://epsg.io/4326), for example).
-The more concise identifier `4326` is also understood by **geopandas** and **rasterio**, but we recommend the more explicit `AUTHORITY:CODE` representation to prevent ambiguity and to provide context.
-<!-- jn: if we recommend the more explicit representation, why do we use the shorter one in the book? I prefer the longer one, but it is open for the discussion. We need to be consistent. -->
-<!-- md: I'm not sure I see why we recommend 'AUTHORITY:CODE'. Perhaps we can simply say that it is more clear, but since EPSG is the "default" and most common authority the shorter version also works and therefore we use it in the book? -->
+The more concise identifier `4326` is also understood by **geopandas** and **rasterio**.
 
 The longer answer is that none of the three descriptions are sufficient, and more detail is needed for unambiguous CRS handling and transformations: due to the complexity of CRSs, it is not possible to capture all relevant information about them in such short text strings.
 For this reason, the Open Geospatial Consortium (OGC, which also developed the Simple Features specification that the **geopandas** package implements) developed an open standard format for describing CRSs that is called WKT (Well Known Text).

07-read-write.qmd

@@ -104,20 +104,8 @@ ne.plot();
 
 ## Geographic data packages {#sec-geographic-data-packages}
 
-Many Python packages have been developed for accessing geographic data, two of which are presented in @tbl-data-packages and demonstrated below.
+Several Python packages have been developed for accessing geographic data, two of which are demonstrated below.
 These provide interfaces to one or more spatial libraries or geoportals and aim to make data access even quicker from the command line.
-<!-- jn: a table with data packages should have more examples of packages (at least ~5)... we do not need, however, to explain all of them... is that possible? -->
-<!-- md: I'm not aware of data packages in Python (never used any until now). unless we do find examples, I guess we can omit the table and simply describe the two packages 'cartopy' and 'osmnx'? -->
-
-| Package     | Description                                                                                       |
-|-------------|---------------------------------------------------------------------------------------------------|
-| **cartopy** | Download layers from [Natural Earth Data](https://www.naturalearthdata.com/downloads/)            |
-| **osmnx**   | Access to [OpenStreetMap](https://www.openstreetmap.org/) data and conversion to spatial networks |
-
-: Selected Python packages for geographic data retrieval {#tbl-data-packages}
-
-Each data package has its own syntax for accessing data.
-This diversity is demonstrated in the subsequent code chunks, which show how to get data using the packages from @tbl-data-packages.
 
 Administrative borders are often useful in spatial analysis.
 These can be accessed with the [`cartopy.io.shapereader.natural_earth`](https://scitools.org.uk/cartopy/docs/latest/reference/generated/cartopy.io.shapereader.natural_earth.html) function from the **cartopy** package [@cartopy].
@@ -170,8 +158,6 @@ parks[['name', 'geometry']].explore()
 
 It should be noted that the **osmnx** package downloads OSM data from the [Overpass API](https://wiki.openstreetmap.org/wiki/Overpass_API), which is rate limited and therefore unsuitable for queries covering very large areas.
 To overcome this limitation, you can download OSM data extracts, such as in Shapefile format from [Geofabrik](https://download.geofabrik.de/), and then load them from the file into the Python environment.
-<!-- jn: it seems that on the Geofabrik website there is no Shapefile format available for download (except for Antarctica)... we need to fix the above sentence... -->
-<!-- md: for continent-level there are no Shapefiles, but for the country-level or for smaller regions there are Shapefiles available in almost all cases, e.g., regions of france https://download.geofabrik.de/europe/france.html, so the statement is still true at this point. I guess we can add a note that this service relies on a commercial company, and the Shapefile download options may be limited in the future? -->
 
 OpenStreetMap is a vast global database of crowd-sourced data, is growing daily, and has a wider ecosystem of tools enabling easy access to the data, from the [Overpass turbo](https://overpass-turbo.eu/) web service for rapid development and testing of OSM queries to [osm2pgsql](https://osm2pgsql.org/) for importing the data into a PostGIS database.
 Although the quality of datasets derived from OSM varies, the data source and wider OSM ecosystems have many advantages: they provide datasets that are available globally, free of charge, and constantly improving thanks to an army of volunteers.
@@ -289,10 +275,6 @@ Spatial vector data comes in a wide variety of file formats.
 Most popular representations such as `.shp`, `.geojson`, and `.gpkg` files can be imported and exported with **geopandas** functions `read_file` and `to_file` (covered in @sec-data-output), respectively.
 
 **geopandas** uses GDAL to read and write data, via **fiona** (the [default](https://github.com/geopandas/geopandas/issues/2217)) or **pyogrio** packages (a recently developed alternative to **fiona**, which will become the default in the future, see [note](https://geopandas.org/en/stable/docs/user_guide/io.html) in "Reading and writing files" tutorial).
-<!-- jn: as far as I understand, pyogrio will be the default in the future, right? if so, we should mention it here -->
-<!-- md: good to know and important point! now added -->
-<!-- jn: also, given the above, which one should be present? -->
-<!-- md: I didn't understand this comment -->
 After **fiona** is imported, the command `fiona.supported_drivers` can be used to list drivers available to GDAL, including whether they can (`'r'`), append (`'a'`), or write (`'w'`) data, or all three.
 
 ```{python}