Merge pull request #240 from cvvergara/minor-fixes-1

Minor fixes on problems detected on weblate

docs/basic/graph_views.rst

@@ -24,7 +24,7 @@ The graph requirements
 ===============================================================================
 
 In this chapter there are three graph requirements. It consists on three graphs
-based on a **fully connected** graph derived from ways: two for different types
+based on a **fully connected** graph derived from ``ways``: two for different types
 of vehicles and one for pedestrian, the source and the target in all of them are
 based on the ``source_osm`` and ``target_osm``.
 
@@ -542,15 +542,15 @@ Exercise 8: Testing the views for routing
 
 .. image:: images/chapter7/ch7-e3.png
   :scale: 25%
-  :alt: From the "|ch7_place_1|" to the "|ch7_place_2|"
+  :alt: From the |ch7_place_1| to the |ch7_place_2|
 
 .. rubric:: Problem
 
 * Test the created views
 
 In particular:
 
-* From the "|ch7_place_1|" to the "|ch7_place_2|" using the OSM identifier
+* From the |ch7_place_1| to the "|ch7_place_2| using the OSM identifier
 * the views to be tested are:
 
   * ``vehicle_net``
@@ -594,7 +594,8 @@ For ``vehicle_net``:
 For ``taxi_net``:
 
 * Similar as the previous one but with ``taxi_net``. (line **3**)
-* The results give the same route as with ``vehicle_net`` but ``cost`` is higher
+* The results give the same route as with ``vehicle_net`` but ``cost`` is
+  higher.
 
 .. literalinclude:: ../scripts/basic/chapter_7/all_sections.sql
   :language: sql

docs/basic/pedestrian.rst

@@ -111,7 +111,7 @@ Exercise 1: Single pedestrian routing
   * from "|place_1|"
   * to "|place_3|".
 
-* Calculate routes with costs in *osm2pgRouting* `length` default units.
+* Calculate routes with costs in *osm2pgRouting* ``length`` default units.
 
 .. image:: images/chapter5/pedestrian_route1.png
   :scale: 25%

docs/basic/plpgsql_function.rst

@@ -35,31 +35,32 @@ The detailed description:
 
 .. rubric:: Input parameters
 
-============  ==========  ===
-Column        type        Description
-============  ==========  ===
-edges_subset  REGCLASS    Edge table name identifier.
-lat1          NUMERIC     The latitude of the `departure` point.
-lon1          NUMERIC     The longitude of the `departure` point.
-lat2          NUMERIC     The latitude of the `destination` point.
-lon2          NUMERIC     The longitude of the `destination` point.
-do_debug      BOOLEAN     Flag to create a ``WARNING`` with the query that is been executed
-============  ==========  ===
+================  ==========  ================================================
+Parameter         type        Description
+================  ==========  ================================================
+``edges_subset``  REGCLASS    Edge table name identifier.
+``lat1``          NUMERIC     The latitude of the `departure` point.
+``lon1``          NUMERIC     The longitude of the `departure` point.
+``lat2``          NUMERIC     The latitude of the `destination` point.
+``lon2``          NUMERIC     The longitude of the `destination` point.
+``do_debug``      BOOLEAN     Flag to create a ``WARNING`` with the query that
+                              is been executed
+================  ==========  ================================================
 
 
 .. rubric::  Output columns
 
-============= =================================================
-Column          Description
-============= =================================================
-seq           For ordering purposes.
-gid           The edge identifier that can be used to JOIN the results to the ``ways`` table.
-name          The street name.
-azimuth       Between start and end node of an edge.
-length        In meters.
-minutes       Minutes taken to traverse the segment.
-route_geom    The road geometry with corrected directionality.
-============= =================================================
+================= =================================================
+Column            Description
+================= =================================================
+``seq``           For ordering purposes.
+``gid``           The edge identifier that can be used to JOIN the results to the ``ways`` table.
+``name``          The street name.
+``azimuth``       Between start and end node of an edge.
+``length``        In meters.
+``minutes``       Minutes taken to traverse the segment.
+``route_geom``    The road geometry with corrected directionality.
+================= =================================================
 
 
 For this chapter, the following points will be used for testing.
@@ -142,7 +143,7 @@ In particular use the following (lat, lon) value: ``(@POINT1_LAT@, @POINT1_LON@)
 * Using the Postgis distance operator `<-> <https://postgis.net/docs/geometry_distance_knn.html>`__ to order by distance.
 * Get only the first row, to obtain the nearest identifier of the vertex.
 
-For ways_vertices:
+For ``ways_vertices``:
 
 .. literalinclude:: ../scripts/basic/chapter_8/all-sections-8.sql
   :language: sql

docs/basic/sql_function.rst

@@ -47,7 +47,7 @@ output columns:
 .. rubric:: Input parameters
 
 ================= ========= =================
-Name              Type      Description
+Paramete          Type      Description
 ================= ========= =================
 ``edges_subset``  REGCLASS  The table/view that is going to be used for processing
 ``source_osm``    BIGINT    The OSM identifier of the `departure` location.
@@ -402,7 +402,7 @@ Exercise 7: Using the function
 .. rubric:: Problem
 
 * Test the function with the three views
-* From the "|ch7_place_1|" to the |ch7_place_2| using the OSM identifier
+* From the |ch7_place_1| to the |ch7_place_2| using the OSM identifier
 
 .. rubric:: Solution
 

docs/basic/vehicle.rst

@@ -122,7 +122,7 @@ Exercise 2: Vehicle routing - returning
 .. rubric:: Solution:
 
 * Use ``cost_s`` (line **6**) and ``reverse_cost_s`` (line **7**) columns, in
-  units ``seconds``.
+  units seconds.
 * The vehicle is going from vertex |id_3| (line **10**) to |id_1| (line **11**).
 
 .. literalinclude:: ../scripts/basic/chapter_6/all_exercises.sql

docs/un_sdg/sdg11-cities.rst

@@ -124,7 +124,7 @@ Data obtained in :doc:`data`.
 This section will cover the status of the database in order to get the same
 results when processing the queries.
 
-Exercise 1: Set the search path
+Exercise 2: Set the search path
 --------------------------------------------------------------------------------
 
 First step in pre processing is to set the search path for ``Waterways``
@@ -141,7 +141,7 @@ particular table is to be imported.
    .. literalinclude:: ../scripts/un_sdg/sdg11/set_path.txt
 
 
-Exercise 2: Verify database configuration
+Exercise 3: Verify database configuration
 --------------------------------------------------------------------------------
 
 As part of the every project tasks: inspect the database structure.
@@ -166,14 +166,13 @@ As part of the every project tasks: inspect the database structure.
 
    .. literalinclude:: ../scripts/un_sdg/sdg11/get_tables.txt
 
-Exercise 6: Count the number of Waterways
+Exercise 4: Count the number of Waterways
 ................................................................................
 
 The importance of counting the information on this workshop is to make sure that
-the same data is used and consequently the results are same. Also, some of the
-rows can be seen to understand the structure of the table and how the data is
-stored in it.
-
+the same data is used and consequently the results are same.
+Also, some of the rows can be seen to understand the structure of the table and
+how the data is stored in it.
 
 .. literalinclude:: ../scripts/un_sdg/sdg11/all_exercises_sdg11.sql
     :start-after: exercise_6.txt
@@ -192,7 +191,7 @@ building the graph, the data has to be inspected to determine if there is any
 invalid data. This is a very important step to make sure that the data is of
 required quality. pgRouting can also be used to do some Data Adjustments.
 
-Exercise 7: Remove waterways not for the problem
+Exercise 5: Remove waterways not for the problem
 --------------------------------------------------------------------------------
 
 .. image:: images/sdg11/remove_waterways.png
@@ -230,7 +229,7 @@ altitude of the city, are to be removed from the ``waterways_ways`` table.
 
 .. note:: A better approach might be to fix the original data in OSM website.
 
-Exercise 8: Get the Connected Components of Waterways
+Exercise 6: Get the Connected Components of Waterways
 ================================================================================
 
 As the rivers in the data are not having single edge, i.e, multiple edges make up
@@ -299,7 +298,7 @@ Next query uses this output and stores the component id in the waterways_ways
     :end-before: exercise_10.txt
     :language: sql
 
-Exercise 10: Creating a function that gets the city buffer
+Exercise 7: Creating a function that gets the city buffer
 --------------------------------------------------------------------------------
 
 A function can be created for the same task. This will be help when the table
@@ -316,7 +315,7 @@ has more than one city.
   .. literalinclude:: ../scripts/un_sdg/sdg11/exercise_10.txt
 
 
-Exercise 11: Finding the components intersecting the buffer
+Exercise 8: Finding the components intersecting the buffer
 ================================================================================
 
 Next step is to find the components of waterways which lie in the buffer zone of
@@ -338,7 +337,7 @@ Output shows the distinct component numbers which lie in the buffer zone of the
 That is, the rivers that lie within the city.
 
 
-Exercise 12: Get the rain zones
+Exercise 9: Get the rain zones
 ================================================================================
 
 In this excercise the area , where if it rains, the
@@ -377,7 +376,7 @@ Create a Buffer around the river components.
 
 This will give us the requires area, where if it rains, the city will be affected.
 
-Exercise 13: Create a union of rain zones
+Exercise 10: Create a union of rain zones
 ================================================================================
 Multiple polygons that are obtained can also be merged using ``ST_Union``. This
 will give a single polygon as the output.

docs/un_sdg/sdg3-health.rst

@@ -105,8 +105,8 @@ this path.
 Exercise 3: Fixing the search path
 ...............................................................................
 
-In this case, search path of roads table is search path to ``roads`` and
-``buildings`` schemas. Following query is used to adjust the search path.
+In this case, the search path needs to include ``roads`` and
+``buildings`` schemas. The following query is used to adjust the search path.
 
 .. literalinclude:: ../scripts/un_sdg/sdg3/all_exercises_sdg3.sql
    :start-after: set_path.txt
@@ -143,7 +143,7 @@ With ``\dt`` the tables are listed showing the schema and the owner
 Preparing roads and buildings data
 ================================================================================
 
-First step is to prepare the data obtained from :ref:`un_sdg/data:Data for Sustainable Development Goals`.
+First step is to prepare the data obtained from :doc:`data`.
 
 This section will work the graph and data that is going to be used for processing.
 While building the graph, the data has to be inspected to determine if there is any
@@ -155,9 +155,9 @@ pgRouting can also be used to do some Data Adjustments.
 Exercise 5: Counting the number of roads and buildings
 --------------------------------------------------------------------------------
 
-The importance of counting the information on this workshop is to make
-sure that the same data is used and consequently the results are same.
-Also, some of the rows can be seen to  understand the structure of the table and
+The importance of counting the information on this workshop is to make sure that
+the same data is used and consequently the results are same.
+Also, some of the rows can be seen to understand the structure of the table and
 how the data is stored in it.
 
 .. literalinclude:: ../scripts/un_sdg/sdg3/all_exercises_sdg3.sql
@@ -615,7 +615,7 @@ For the following query,
   - As ``time`` = ``distance/speed``, ``length_m`` / ``1 m/s`` / ``60`` gives
     the time in minutes.
 
-- ``tag_id = '318'``  as 318 is the value for hospital in the configuration
+- ``tag_id = '318'`` as 318 is the value for hospital in the configuration
   table of the buildings.
 
 - ``10`` for 10 minutes, which is a threshold for ``agg_cost``
@@ -630,7 +630,7 @@ For the following query,
   .. literalinclude:: ../scripts/un_sdg/sdg3/exercise_15.txt
 
 Following figure shows the visualised output of the above query. The lines
-highlighted by ``red`` colour show the area from where the hospital can be reached
+highlighted by red colour show the area from where the hospital can be reached
 within 10 minutes of walking at the speed of ``1 m/s``.
 
 It is noticable from the output figure that some of the roads which are near to
@@ -770,7 +770,8 @@ Follow the steps given below to complete this task.
 Exercise 18: Find total population served by the hospital
 --------------------------------------------------------------------------------
 
-Final step is to find the total population served by the hospital based on travel-time.
+Final step is to find the total population served by the hospital based on
+travel time.
 
 .. literalinclude:: ../scripts/un_sdg/sdg3/all_exercises_sdg3.sql
     :start-after: exercise_20.txt

locale/en/LC_MESSAGES/basic/graph_views.po

@@ -9,7 +9,7 @@ msgid ""
 msgstr ""
 "Project-Id-Version: Workshop FOSS4G Belém 3.0\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2024-11-07 03:04+0000\n"
+"POT-Creation-Date: 2024-11-10 17:09+0000\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language: en\n"
@@ -42,9 +42,10 @@ msgstr ""
 #: ../../build/docs/basic/graph_views.rst:26
 msgid ""
 "In this chapter there are three graph requirements. It consists on three "
-"graphs based on a **fully connected** graph derived from ways: two for "
-"different types of vehicles and one for pedestrian, the source and the "
-"target in all of them are based on the ``source_osm`` and ``target_osm``."
+"graphs based on a **fully connected** graph derived from ``ways``: two "
+"for different types of vehicles and one for pedestrian, the source and "
+"the target in all of them are based on the ``source_osm`` and "
+"``target_osm``."
 msgstr ""
 
 #: ../../build/docs/basic/graph_views.rst:31
@@ -546,7 +547,7 @@ msgid "Exercise 8: Testing the views for routing"
 msgstr ""
 
 #: ../../build/docs/basic/graph_views.rst:543
-msgid "From the \"|ch7_place_1|\" to the \"|ch7_place_2|\""
+msgid "From the |ch7_place_1| to the |ch7_place_2|"
 msgstr ""
 
 #: ../../build/docs/basic/graph_views.rst:549
@@ -558,9 +559,7 @@ msgid "In particular:"
 msgstr ""
 
 #: ../../build/docs/basic/graph_views.rst:553
-msgid ""
-"From the \"|ch7_place_1|\" to the \"|ch7_place_2|\" using the OSM "
-"identifier"
+msgid "From the |ch7_place_1| to the \"|ch7_place_2| using the OSM identifier"
 msgstr ""
 
 #: ../../build/docs/basic/graph_views.rst:554
@@ -646,18 +645,18 @@ msgstr ""
 #: ../../build/docs/basic/graph_views.rst:597
 msgid ""
 "The results give the same route as with ``vehicle_net`` but ``cost`` is "
-"higher"
+"higher."
 msgstr ""
 
-#: ../../build/docs/basic/graph_views.rst:609
+#: ../../build/docs/basic/graph_views.rst:610
 msgid "For ``walk_net``:"
 msgstr ""
 
-#: ../../build/docs/basic/graph_views.rst:611
+#: ../../build/docs/basic/graph_views.rst:612
 msgid "Similar as the previous one but with ``walk_net``. (line **3**)"
 msgstr ""
 
-#: ../../build/docs/basic/graph_views.rst:612
+#: ../../build/docs/basic/graph_views.rst:613
 msgid "The results give a different route than of the vehicles."
 msgstr ""