docs: fix incorrect table names in the workshop documentation#272
docs: fix incorrect table names in the workshop documentation#272prashsti29 wants to merge 4 commits intopgRouting:developfrom
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (19)
✅ Files skipped from review due to trivial changes (8)
🚧 Files skipped from review as they are similar to previous changes (10)
WalkthroughThe PR updates documentation, SQL scripts, views, and translation files to replace generic Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
docs/un_sdg/sdg11-cities.rst (1)
272-283:⚠️ Potential issue | 🟡 MinorSame inconsistency applies to component column rubrics.
These rubrics reference
ways_vertices_pgrbut should match the actual table name used in the SQL scripts (waterways_verticesbased on context snippets).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/un_sdg/sdg11-cities.rst` around lines 272 - 283, The rubrics that mention the `component` column refer to the wrong table name (`ways_vertices_pgr`)—update those rubric lines so they match the actual table used in the SQL scripts (replace `ways_vertices_pgr` with `waterways_vertices`) wherever phrases like "Add a ``component`` column on the edges and ways_vertices_pgr tables" and "Fill up the ``component`` column on the ways_vertices_pgr table." appear; ensure the text exactly uses `waterways_vertices` to keep wording consistent with the SQL examples (`only_connected3.txt`/`only_connected4.txt`) and avoid future confusion.docs/un_sdg/sdg3-health.rst (1)
429-462:⚠️ Potential issue | 🟡 MinorUpdate rubric text to match actual table names created by SQL script.
The rubrics reference
ways_vertices_pgrbut the SDG3 SQL script at line 86 creates a table namedroads_verticesin theroadsschema (SELECT * INTO roads.roads_vertices). All subsequent operations in the SQL script useroads_vertices, notways_vertices_pgr. Update the rubric text in lines 429, 433, 442, 451 to reference the correct table name.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/un_sdg/sdg3-health.rst` around lines 429 - 462, The rubric headings incorrectly reference the table ways_vertices_pgr; update each rubric text that mentions ways_vertices_pgr to reference the actual table name used by the SQL (roads_vertices or schema-qualified roads.roads_vertices) so they match the SQL script and subsequent operations; search for occurrences of "ways_vertices_pgr" in the shown rubrics and replace them with "roads_vertices" (or "roads.roads_vertices" if you prefer schema-qualified naming) so the rubrics refer to the real table created by the SQL.
🧹 Nitpick comments (1)
docs/advanced/chapter-12.rst (1)
102-102: Minor wording clarification suggested.The text says "Creates a ways_vertices_pgr table" but the example uses
planet_osm_roads, which would createplanet_osm_roads_vertices_pgr(as shown on line 157). Consider using generic wording like "Creates a<table>_vertices_pgrtable" to match the actual naming pattern, or keep it as a generic reference to the concept.This is a minor documentation clarity issue and the current wording is acceptable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/advanced/chapter-12.rst` at line 102, The sentence "Creates a ways_vertices_pgr table" should be clarified to reflect the actual naming pattern shown in the example (e.g., planet_osm_roads -> planet_osm_roads_vertices_pgr); update the wording to something like "Creates a <table>_vertices_pgr table" or otherwise refer generically to a "<table>_vertices_pgr" table so it matches the example and the naming convention used with planet_osm_roads/planet_osm_roads_vertices_pgr.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/scripts/basic/pedestrian/images.sql`:
- Around line 17-24: Update the inner SELECTs and JOINs to use the ways table
primary key `gid`: in each pedestrian view (e.g., pedestrian_one_to_one,
pedestrian_many_to_one, pedestrian_one_to_many, pedestrian_many_to_many) change
the inner query string to select "gid AS id, source, target, length AS cost FROM
ways" instead of "id", and update the final SELECT JOIN to use "JOIN ways
ON(edge = gid)" instead of "ON(edge = id)"; ensure every occurrence of the inner
query and JOIN in this file is updated consistently.
In `@docs/scripts/basic/sql_function/sql_function.sql`:
- Around line 211-213: The example calls wrk_dijkstra('ways', ...) but
wrk_dijkstra contains a hardcoded LEFT JOIN vehicle_net USING (id), causing
mismatches; either change the example to call wrk_dijkstra('vehicle_net',
`@CH7_ID_1`@, `@CH7_ID_2`@) or refactor the wrk_dijkstra function to accept the
target table/view name for both the path source and the join (remove the
hardcoded LEFT JOIN vehicle_net and use the passed table identifier when
building the JOIN). Locate the wrk_dijkstra definition and the LEFT JOIN
vehicle_net USING (id) and update the call or make the JOIN table dynamic so
schema mismatches are avoided.
In `@docs/scripts/basic/withPoints/images.sql`:
- Around line 40-42: The wrk_withPoints call is being passed the table/values
from ways which lack the required id and geom columns; update the call to supply
a source that provides an id column and a geom column (e.g., wrap ways in a
SELECT that aliases an identifier column as id and constructs a geometry from
the latitude/longitude as geom, or pass a subquery that returns id and geom) so
wrk_withPoints receives the expected id and geom fields.
- Around line 14-20: The SQL queries passed to pgr_findCloseEdges incorrectly
reference columns "id" and "geom" on the ways table; change the query strings
('SELECT id, geom from ways') to use the actual column names with aliases:
'SELECT gid AS id, the_geom AS geom from ways' (or alternatively revert to using
the walk_net view which already provides those aliases), so update both
occurrences used with pgr_findCloseEdges and any UNIONed SELECTs accordingly.
In `@docs/scripts/basic/withPoints/withPoints.sql`:
- Around line 139-141: The SQL currently passes the literal 'ways' into
wrk_withPoints which expects a table/view with columns named id, geom, length,
source, target, and name; because the real table has gid, the_geom, length_m,
etc., remove the 'ways' parameter or instead pass a properly aliased view (like
the previous walk_net materialized view) that maps gid AS id, the_geom AS geom,
length_m AS length and preserves source, target, name so wrk_withPoints will
find the required column names.
In `@docs/un_sdg/sdg11-cities.rst`:
- Line 250: The rubric text "Create a ways_vertices_pgr table" is incorrect;
update the rubric in sdg11-cities.rst to read "Create a waterways_vertices
table" so it matches the SQL in all_exercises_sdg11.sql which creates
waterways.waterways_vertices (refer to the rubric string and the table name
waterways.waterways_vertices to locate and change the text).
In `@docs/un_sdg/sdg3-health.rst`:
- Around line 549-552: Rewrite the awkward sentence to clearly refer to the
table and its vertices: change "There are multiple road ways_vertices_pgr near
the hospital" to something like "There are multiple vertices in
ways_vertices_pgr near the hospital" (or "There are multiple ways_vertices_pgr
entries near the hospital"), and ensure the following sentence still references
the existing function name closest_vertex and columns geom and gid so it reads:
"Create a function to find the geographically closest road vertex.
closest_vertex takes the geometry of the other table as input and returns the
gid of the closest vertex by comparing geom from both tables."
---
Outside diff comments:
In `@docs/un_sdg/sdg11-cities.rst`:
- Around line 272-283: The rubrics that mention the `component` column refer to
the wrong table name (`ways_vertices_pgr`)—update those rubric lines so they
match the actual table used in the SQL scripts (replace `ways_vertices_pgr` with
`waterways_vertices`) wherever phrases like "Add a ``component`` column on the
edges and ways_vertices_pgr tables" and "Fill up the ``component`` column on the
ways_vertices_pgr table." appear; ensure the text exactly uses
`waterways_vertices` to keep wording consistent with the SQL examples
(`only_connected3.txt`/`only_connected4.txt`) and avoid future confusion.
In `@docs/un_sdg/sdg3-health.rst`:
- Around line 429-462: The rubric headings incorrectly reference the table
ways_vertices_pgr; update each rubric text that mentions ways_vertices_pgr to
reference the actual table name used by the SQL (roads_vertices or
schema-qualified roads.roads_vertices) so they match the SQL script and
subsequent operations; search for occurrences of "ways_vertices_pgr" in the
shown rubrics and replace them with "roads_vertices" (or "roads.roads_vertices"
if you prefer schema-qualified naming) so the rubrics refer to the real table
created by the SQL.
---
Nitpick comments:
In `@docs/advanced/chapter-12.rst`:
- Line 102: The sentence "Creates a ways_vertices_pgr table" should be clarified
to reflect the actual naming pattern shown in the example (e.g.,
planet_osm_roads -> planet_osm_roads_vertices_pgr); update the wording to
something like "Creates a <table>_vertices_pgr table" or otherwise refer
generically to a "<table>_vertices_pgr" table so it matches the example and the
naming convention used with planet_osm_roads/planet_osm_roads_vertices_pgr.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 818a3cee-70ab-4f7d-9501-dc38284cb1c4
📒 Files selected for processing (14)
docs/advanced/chapter-12.rstdocs/basic/graphs.rstdocs/interactions/code/QGISfunctions.sqldocs/interactions/code/functions.sqldocs/scripts/basic/graphs/graphs.sqldocs/scripts/basic/graphs/images.sqldocs/scripts/basic/pedestrian/images.sqldocs/scripts/basic/pedestrian/pedestrian.sqldocs/scripts/basic/sql_function/sql_function.sqldocs/scripts/basic/withPoints/images.sqldocs/scripts/basic/withPoints/withPoints.sqldocs/un_sdg/sdg11-cities.rstdocs/un_sdg/sdg3-health.rstdocs/un_sdg/sdg7-energy.rst
| 'SELECT id, source, target, | ||
| length AS cost | ||
| FROM walk_net', | ||
| FROM ways', | ||
| @ID_1@, | ||
| @ID_3@, | ||
| directed := false) | ||
| ) | ||
| SELECT seq, start_vid, end_vid, geom AS geom FROM dijkstra JOIN walk_net ON(edge = id); | ||
| SELECT seq, start_vid, end_vid, geom AS geom FROM dijkstra JOIN ways ON(edge = id); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if ways table has 'id' column or if it should be 'gid'
rg -n "FROM ways" --type sql -B2 -A2 docs/scripts/basic/ | head -60
# Also check how other files handle the ways table column naming
ast-grep --pattern 'SELECT $_, source, target$$$FROM ways'Repository: pgRouting/workshop
Length of output: 3819
🏁 Script executed:
cat docs/scripts/basic/pedestrian/images.sqlRepository: pgRouting/workshop
Length of output: 2600
🏁 Script executed:
# Search for ways table creation or schema definition
rg -n "CREATE TABLE.*ways|gid|id.*PRIMARY" --type sql docs/scripts/ -i | grep -E "(CREATE|ways|gid)" | head -40Repository: pgRouting/workshop
Length of output: 2850
🏁 Script executed:
# Also check the data loading scripts or SQL setup files
find docs/scripts -name "*.sql" -type f | xargs grep -l "ways_vertices_pgr\|CREATE.*ways" | head -10Repository: pgRouting/workshop
Length of output: 272
🏁 Script executed:
# Verify the pattern - check if any ways table actually has 'id' column
# Search for ways table definition or schema
rg -n "CREATE TABLE.*ways|ALTER TABLE.*ways" --type sql docs/Repository: pgRouting/workshop
Length of output: 1236
🏁 Script executed:
# Check data loading or initialization scripts
find docs -name "*.sql" -type f | xargs grep -l "INSERT INTO ways\|COPY ways" | head -5Repository: pgRouting/workshop
Length of output: 44
🏁 Script executed:
# Check the pedestrian.sql file to see if it has the same pattern issues
head -80 docs/scripts/basic/pedestrian/pedestrian.sql | tail -40Repository: pgRouting/workshop
Length of output: 930
🏁 Script executed:
# Search for any README or documentation about the data schema
find docs -name "README*" -o -name "*.md" | head -20Repository: pgRouting/workshop
Length of output: 44
🏁 Script executed:
# Check if there are any SQL files that set up or initialize the ways table with 'id' column
rg "CREATE TABLE.*ways.*id|gid" --type sql -A5 docs/ | head -60Repository: pgRouting/workshop
Length of output: 4169
Fix column references in the inner query and JOIN clause: use gid instead of id.
The ways table uses gid as its primary key, not id. This is evident from the pattern used in other files within the codebase (e.g., docs/scripts/basic/vehicles/images.sql and docs/scripts/basic/graphs/graphs.sql), which all use SELECT gid AS id and JOIN ways ON(edge = gid).
The inner query (lines 17-19) should be:
'SELECT gid AS id, source, target,
length AS cost
FROM ways'And the final SELECT statement (line 24) should use:
FROM dijkstra JOIN ways ON(edge = gid)This same issue appears in all four views in this file (pedestrian_one_to_one, pedestrian_many_to_one, pedestrian_one_to_many, pedestrian_many_to_many, and related views).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/scripts/basic/pedestrian/images.sql` around lines 17 - 24, Update the
inner SELECTs and JOINs to use the ways table primary key `gid`: in each
pedestrian view (e.g., pedestrian_one_to_one, pedestrian_many_to_one,
pedestrian_one_to_many, pedestrian_many_to_many) change the inner query string
to select "gid AS id, source, target, length AS cost FROM ways" instead of "id",
and update the final SELECT JOIN to use "JOIN ways ON(edge = gid)" instead of
"ON(edge = id)"; ensure every occurrence of the inner query and JOIN in this
file is updated consistently.
| 'SELECT id, geom from ways', | ||
| ST_SetSRID(ST_Point(@POINT1_LON@, @POINT1_LAT@), 4326) , 0.5) | ||
|
|
||
| UNION | ||
|
|
||
| SELECT 2 AS pid, * from pgr_findCloseEdges( | ||
| 'SELECT id, geom from walk_net', | ||
| 'SELECT id, geom from ways', |
There was a problem hiding this comment.
Column name mismatch: ways table uses gid and the_geom, not id and geom.
The queries 'SELECT id, geom from ways' will fail because the ways table uses different column names:
gidinstead ofidthe_geominstead ofgeom
The previous walk_net materialized view provided these aliases. Either:
- Update the queries to use the correct column names:
'SELECT gid AS id, the_geom AS geom from ways' - Or revert to using a view that provides the expected column aliases
Proposed fix
SELECT 1 AS pid, * from pgr_findCloseEdges(
- 'SELECT id, geom from ways',
+ 'SELECT gid AS id, the_geom AS geom from ways',
ST_SetSRID(ST_Point(`@POINT1_LON`@, `@POINT1_LAT`@), 4326) , 0.5)
UNION
SELECT 2 AS pid, * from pgr_findCloseEdges(
- 'SELECT id, geom from ways',
+ 'SELECT gid AS id, the_geom AS geom from ways',
ST_SetSRID(ST_Point(`@POINT2_LON`@, `@POINT2_LAT`@), 4326) , 0.5)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/scripts/basic/withPoints/images.sql` around lines 14 - 20, The SQL
queries passed to pgr_findCloseEdges incorrectly reference columns "id" and
"geom" on the ways table; change the query strings ('SELECT id, geom from ways')
to use the actual column names with aliases: 'SELECT gid AS id, the_geom AS geom
from ways' (or alternatively revert to using the walk_net view which already
provides those aliases), so update both occurrences used with pgr_findCloseEdges
and any UNIONed SELECTs accordingly.
| 'ways', | ||
| @POINT1_LAT@, @POINT1_LON@, | ||
| @POINT2_LAT@, @POINT2_LON@); |
There was a problem hiding this comment.
Same column compatibility issue applies to wrk_withPoints call.
As noted above, the wrk_withPoints function expects id and geom columns which ways doesn't provide directly.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/scripts/basic/withPoints/images.sql` around lines 40 - 42, The
wrk_withPoints call is being passed the table/values from ways which lack the
required id and geom columns; update the call to supply a source that provides
an id column and a geom column (e.g., wrap ways in a SELECT that aliases an
identifier column as id and constructs a geometry from the latitude/longitude as
geom, or pass a subquery that returns id and geom) so wrk_withPoints receives
the expected id and geom fields.
| 'ways', | ||
| @POINT1_LAT@, @POINT1_LON@, | ||
| @POINT2_LAT@, @POINT2_LON@); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the column names in the ways table definition
rg -n "CREATE TABLE.*ways|INTO ways" --type sql -A 20 docs/scripts/
# Check if there's any view or alias that makes 'ways' compatible
ast-grep --pattern 'CREATE VIEW ways AS $$$'Repository: pgRouting/workshop
Length of output: 1598
🏁 Script executed:
# First, let's look at the actual file and the specific lines mentioned
head -n 150 docs/scripts/basic/withPoints/withPoints.sql | tail -n 20Repository: pgRouting/workshop
Length of output: 348
🏁 Script executed:
# Check the wrk_withPoints function definition to see what columns it expects
sed -n '32,115p' docs/scripts/basic/withPoints/withPoints.sqlRepository: pgRouting/workshop
Length of output: 1936
🏁 Script executed:
# Search for the ways table definition in the entire docs/scripts directory
rg -n "CREATE TABLE.*ways\b|CREATE.*TABLE.*ways\(" docs/scripts/ --type sql -A 15Repository: pgRouting/workshop
Length of output: 44
🏁 Script executed:
# Check if there's a ways view that aliases columns
rg -n "CREATE.*VIEW.*ways|CREATE MATERIALIZED VIEW.*ways" docs/scripts/ --type sql -A 10Repository: pgRouting/workshop
Length of output: 44
🏁 Script executed:
# Find the walk_net definition
rg -n "walk_net|taxi_net" docs/scripts/basic/withPoints/withPoints.sql -B 5 -A 5Repository: pgRouting/workshop
Length of output: 253
🏁 Script executed:
# Look for CREATE VIEW or CREATE MATERIALIZED VIEW definitions
rg -n "CREATE.*VIEW.*walk_net|CREATE.*VIEW.*taxi_net" docs/scripts/ --type sql -A 15Repository: pgRouting/workshop
Length of output: 2386
🏁 Script executed:
# Check all wrk_withPoints calls in the file to see the pattern
rg -n "wrk_withPoints" docs/scripts/basic/withPoints/withPoints.sql -B 2 -A 5Repository: pgRouting/workshop
Length of output: 862
Remove the 'ways' parameter or replace it with a properly aliased view.
The wrk_withPoints function requires columns named id, geom, length, source, target, and name. The ways table has incompatible column names: gid (not id), the_geom (not geom), and length_m (not length). The previous walk_net materialized view properly aliased these columns (gid AS id, the_geom AS geom, length_m AS length), which is why it works. Passing 'ways' directly will cause runtime SQL errors.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/scripts/basic/withPoints/withPoints.sql` around lines 139 - 141, The SQL
currently passes the literal 'ways' into wrk_withPoints which expects a
table/view with columns named id, geom, length, source, target, and name;
because the real table has gid, the_geom, length_m, etc., remove the 'ways'
parameter or instead pass a properly aliased view (like the previous walk_net
materialized view) that maps gid AS id, the_geom AS geom, length_m AS length and
preserves source, target, name so wrk_withPoints will find the required column
names.
| (edges) table. Follow the steps given below to complete this task. | ||
|
|
||
| .. rubric:: Create a vertices table. | ||
| .. rubric:: Create a ways_vertices_pgr table. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the actual table name created in the SDG11 SQL script
rg -n "INTO.*vertices|CREATE.*vertices" docs/scripts/un_sdg/sdg11/ --type sqlRepository: pgRouting/workshop
Length of output: 157
Fix table name in rubric to match actual SQL output.
The rubric on line 250 says "Create a ways_vertices_pgr table" but the SQL in all_exercises_sdg11.sql (line 46) actually creates waterways.waterways_vertices. Update the rubric to "Create a waterways_vertices table" to match the actual SQL output.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/un_sdg/sdg11-cities.rst` at line 250, The rubric text "Create a
ways_vertices_pgr table" is incorrect; update the rubric in sdg11-cities.rst to
read "Create a waterways_vertices table" so it matches the SQL in
all_exercises_sdg11.sql which creates waterways.waterways_vertices (refer to the
rubric string and the table name waterways.waterways_vertices to locate and
change the text).
| There are multiple road ways_vertices_pgr near the hospital. Create a function to find | ||
| the geographically closest road vertex. ``closest_vertex`` function takes geometry | ||
| of other table as input and gives the gid of the closest vertex as output by | ||
| comparing ``geom`` of both the tables. |
There was a problem hiding this comment.
Awkward phrasing: "road ways_vertices_pgr" should be clarified.
The sentence "There are multiple road ways_vertices_pgr near the hospital" is grammatically awkward. Consider rephrasing to:
- "There are multiple vertices in
ways_vertices_pgrnear the hospital" - "There are multiple
ways_vertices_pgrentries near the hospital"
Suggested fix
-There are multiple road ways_vertices_pgr near the hospital. Create a function to find
+There are multiple vertices in ``ways_vertices_pgr`` near the hospital. Create a function to find🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/un_sdg/sdg3-health.rst` around lines 549 - 552, Rewrite the awkward
sentence to clearly refer to the table and its vertices: change "There are
multiple road ways_vertices_pgr near the hospital" to something like "There are
multiple vertices in ways_vertices_pgr near the hospital" (or "There are
multiple ways_vertices_pgr entries near the hospital"), and ensure the following
sentence still references the existing function name closest_vertex and columns
geom and gid so it reads: "Create a function to find the geographically closest
road vertex. closest_vertex takes the geometry of the other table as input and
returns the gid of the closest vertex by comparing geom from both tables."
prashsti29
force-pushed
the
docs/table-name-fixes
branch
from
1b4c2a8 to
b510f9a
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
locale/en/LC_MESSAGES/basic/graphs.po (1)
345-396: 🛠️ Refactor suggestion | 🟠 MajorUpdate sibling locale catalogs to remove orphaned msgids.
The English translation changes are correct. However, the Spanish (
locale/es/LC_MESSAGES/basic/graphs.po) and Swedish (locale/sv/LC_MESSAGES/basic/graphs.po) locale files contain 22 orphaned msgids each that no longer exist in the template. These include old msgids referencing "vertices table" (e.g., "Exercise 1: Create a vertices table", "Create the vertices table corresponding to the edges inways") which have been renamed to "ways_vertices_pgr" in the current template. Remove these orphaned entries from both locale files to keep translations in sync with the template.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@locale/en/LC_MESSAGES/basic/graphs.po` around lines 345 - 396, Remove the 22 orphaned msgid entries in both locale/es/LC_MESSAGES/basic/graphs.po and locale/sv/LC_MESSAGES/basic/graphs.po that no longer exist in the template (these are old entries referencing the "vertices table" such as "Exercise 1: Create a vertices table" and "Create the vertices table corresponding to the edges in ``ways``"); ensure you delete only the obsolete msgid/msgstr blocks so the remaining translations stay intact and the files match the current English template (locale/en/LC_MESSAGES/basic/graphs.po) where "vertices table" was renamed to "ways_vertices_pgr".
🧹 Nitpick comments (1)
locale/en/LC_MESSAGES/un_sdg/sdg11-cities.po (1)
12-21: Consider fully syncing PO header metadata with the current workshop release.Line 12 and Line 21 were regenerated, but this catalog header still carries older release branding in the same header block. Keeping PO header fields aligned with the current POT reduces translator confusion.
Suggested header sync
-# Copyright (C) 2010-2024 pgRouting Developers -# This file is distributed under the same license as the Workshop FOSS4G -# Belém package. +# Copyright (C) 2010-2025 pgRouting Developers +# This file is distributed under the same license as the Workshop FOSS4G Auckland package. @@ -"Project-Id-Version: Workshop FOSS4G Belém 3.0\n" +"Project-Id-Version: Workshop FOSS4G Auckland 3.1\n"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@locale/en/LC_MESSAGES/un_sdg/sdg11-cities.po` around lines 12 - 21, The PO header in locale/en/LC_MESSAGES/un_sdg/sdg11-cities.po contains outdated metadata (fields like POT-Creation-Date, PO-Revision-Date, Last-Translator, Language, Language-Team, Generated-By) that differ from the regenerated POT; update these header fields to match the current workshop release/POT values (synchronize POT-Creation-Date, PO-Revision-Date, Last-Translator, Language-Team, Generated-By and any charset/encoding entries) so the PO header fully reflects the current POT metadata and avoids translator confusion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/scripts/basic/vehicles/vehicles.sql`:
- Around line 15-19: The SQL call to pgr_dijkstra uses wrong column names;
update the SELECT string passed into pgr_dijkstra in vehicles.sql (the SQL
literal used in the pgr_dijkstra invocation) to alias the actual ways table
columns to the expected names: select gid AS id, source, target, cost_s AS cost,
reverse_cost_s AS reverse_cost FROM ways; also apply the same fix in images.sql
inside the vehicle_route_going_png and vehicle_route_coming_png view definitions
so their pgr_dijkstra SELECT strings use gid AS id, cost_s AS cost, and
reverse_cost_s AS reverse_cost.
In `@locale/en/LC_MESSAGES/un_sdg/sdg3-health.po`:
- Around line 569-575: Replace the incorrect phrase "road ways_vertices_pgr"
with the intended conceptual term "road vertices" in the message string; ensure
the sentence reads "There are multiple road vertices near the hospital..." and
keep references to the function name `closest_vertex`, the output field `gid`,
and input field `geom` unchanged so the description still explains that
`closest_vertex` takes another table's geometry and returns the gid of the
closest vertex.
In `@locale/en/LC_MESSAGES/un_sdg/sdg7-energy.po`:
- Around line 28-37: The msgid string for SDG 7 contains the incorrect phrase
"7th Sustainable Development Goal 11"; update the msgid text to remove the
trailing "11" so it reads "7th Sustainable Development Goal" (keep the rest of
the msgid content unchanged) — locate and edit the msgid that begins with
"`Affordable and Clean Energy` is the 7th Sustainable Development Goal 11..."
and replace "Goal 11" with "Goal" to match the correct source RST.
---
Outside diff comments:
In `@locale/en/LC_MESSAGES/basic/graphs.po`:
- Around line 345-396: Remove the 22 orphaned msgid entries in both
locale/es/LC_MESSAGES/basic/graphs.po and locale/sv/LC_MESSAGES/basic/graphs.po
that no longer exist in the template (these are old entries referencing the
"vertices table" such as "Exercise 1: Create a vertices table" and "Create the
vertices table corresponding to the edges in ``ways``"); ensure you delete only
the obsolete msgid/msgstr blocks so the remaining translations stay intact and
the files match the current English template
(locale/en/LC_MESSAGES/basic/graphs.po) where "vertices table" was renamed to
"ways_vertices_pgr".
---
Nitpick comments:
In `@locale/en/LC_MESSAGES/un_sdg/sdg11-cities.po`:
- Around line 12-21: The PO header in
locale/en/LC_MESSAGES/un_sdg/sdg11-cities.po contains outdated metadata (fields
like POT-Creation-Date, PO-Revision-Date, Last-Translator, Language,
Language-Team, Generated-By) that differ from the regenerated POT; update these
header fields to match the current workshop release/POT values (synchronize
POT-Creation-Date, PO-Revision-Date, Last-Translator, Language-Team,
Generated-By and any charset/encoding entries) so the PO header fully reflects
the current POT metadata and avoids translator confusion.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: a2af4f25-0f18-441a-910f-e10c1ef6d7e4
📒 Files selected for processing (19)
docs/scripts/basic/graphs/images.sqldocs/scripts/basic/sql_function/images.sqldocs/scripts/basic/sql_function/sql_function.sqldocs/scripts/basic/vehicles/images.sqldocs/scripts/basic/vehicles/vehicles.sqldocs/scripts/basic/withPoints/images.sqldocs/scripts/basic/withPoints/withPoints.sqllocale/en/LC_MESSAGES/advanced/chapter-12.polocale/en/LC_MESSAGES/basic/graphs.polocale/en/LC_MESSAGES/basic/pedestrian.polocale/en/LC_MESSAGES/un_sdg/sdg11-cities.polocale/en/LC_MESSAGES/un_sdg/sdg3-health.polocale/en/LC_MESSAGES/un_sdg/sdg7-energy.polocale/pot/advanced/chapter-12.potlocale/pot/basic/graphs.potlocale/pot/basic/pedestrian.potlocale/pot/un_sdg/sdg11-cities.potlocale/pot/un_sdg/sdg3-health.potlocale/pot/un_sdg/sdg7-energy.pot
✅ Files skipped from review due to trivial changes (7)
- locale/pot/advanced/chapter-12.pot
- locale/pot/un_sdg/sdg3-health.pot
- docs/scripts/basic/sql_function/sql_function.sql
- locale/pot/basic/graphs.pot
- locale/en/LC_MESSAGES/advanced/chapter-12.po
- locale/pot/un_sdg/sdg7-energy.pot
- docs/scripts/basic/sql_function/images.sql
🚧 Files skipped from review as they are similar to previous changes (3)
- docs/scripts/basic/withPoints/withPoints.sql
- docs/scripts/basic/graphs/images.sql
- docs/scripts/basic/withPoints/images.sql
| SELECT * FROM pgr_dijkstra( | ||
| 'SELECT id, source, target, cost, reverse_cost | ||
| FROM vehicle_net', | ||
| FROM ways', | ||
| @ID_1@, @ID_3@, | ||
| directed := true); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check for inconsistent column references across vehicle SQL files
# Expect: Either all queries use aliased columns (gid AS id, cost_s AS cost)
# or all use direct columns (id, cost, reverse_cost)
echo "=== Checking column usage in changed files ==="
echo "--- Direct 'id, cost, reverse_cost' references (new pattern) ---"
rg -n 'SELECT\s+id,\s*source,\s*target,\s*cost,\s*reverse_cost' docs/scripts/basic/vehicles/
echo ""
echo "--- Aliased 'gid AS id, cost_s AS cost' references (old pattern) ---"
rg -n 'gid\s+AS\s+id.*cost_s' docs/scripts/basic/vehicles/
echo ""
echo "=== Checking ways table schema definition or usage elsewhere ==="
rg -n -C2 'CREATE TABLE.*ways|ways\s*\(' docs/scripts/ | head -50Repository: pgRouting/workshop
Length of output: 1247
🏁 Script executed:
# Check images.sql to see full context of the aliased and direct column references
echo "=== images.sql lines around 5, 16 (direct references) ==="
sed -n '1,20p' docs/scripts/basic/vehicles/images.sql | cat -n
echo ""
echo "=== images.sql lines around 79-100 (aliased references) ==="
sed -n '70,105p' docs/scripts/basic/vehicles/images.sql | cat -n
echo ""
echo "=== vehicles.sql lines 15-26 (direct references being reviewed) ==="
sed -n '15,26p' docs/scripts/basic/vehicles/vehicles.sql | cat -nRepository: pgRouting/workshop
Length of output: 2883
🏁 Script executed:
# Search for ways table schema definition
echo "=== Looking for ways table schema or setup ==="
find docs/scripts -name "*.sql" -type f | xargs grep -l "CREATE TABLE.*ways\|ALTER TABLE.*ways" | head -5
echo ""
echo "=== Searching for ways table structure in any documentation or schema files ==="
find . -type f \( -name "*schema*" -o -name "*setup*" -o -name "*create*" \) | head -20
echo ""
echo "=== Checking if gid vs id is ever mentioned in comments or docs ==="
rg -i "gid|column.*id" docs/ -A2 | head -40Repository: pgRouting/workshop
Length of output: 2975
🏁 Script executed:
# Check graphs.sql for ways table creation
echo "=== graphs.sql (likely contains ways table schema) ==="
cat -n docs/scripts/basic/graphs/graphs.sql | head -100Repository: pgRouting/workshop
Length of output: 3921
Fix column names to match the ways table schema.
This query will fail with a "column does not exist" error. The ways table uses gid (not id), cost_s (not cost), and reverse_cost_s (not reverse_cost), as confirmed by the table schema and other queries in graphs.sql that correctly alias these columns (e.g., 'SELECT gid AS id, source, target, cost_s AS cost, reverse_cost_s AS reverse_cost FROM ways').
Update line 16 to:
'SELECT gid AS id, source, target, cost_s AS cost, reverse_cost_s AS reverse_cost
FROM ways',Also check images.sql lines 5 and 16, which have the same issue in the vehicle_route_going_png and vehicle_route_coming_png views.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/scripts/basic/vehicles/vehicles.sql` around lines 15 - 19, The SQL call
to pgr_dijkstra uses wrong column names; update the SELECT string passed into
pgr_dijkstra in vehicles.sql (the SQL literal used in the pgr_dijkstra
invocation) to alias the actual ways table columns to the expected names: select
gid AS id, source, target, cost_s AS cost, reverse_cost_s AS reverse_cost FROM
ways; also apply the same fix in images.sql inside the vehicle_route_going_png
and vehicle_route_coming_png view definitions so their pgr_dijkstra SELECT
strings use gid AS id, cost_s AS cost, and reverse_cost_s AS reverse_cost.
| #: ../../build/docs/un_sdg/sdg3-health.rst:549 | ||
| msgid "" | ||
| "There are multiple road vertices near the hospital. Create a function to " | ||
| "find the geographically closest road vertex. ``closest_vertex`` function " | ||
| "takes geometry of other table as input and gives the gid of the closest " | ||
| "vertex as output by comparing ``geom`` of both the tables." | ||
| "There are multiple road ways_vertices_pgr near the hospital. Create a " | ||
| "function to find the geographically closest road vertex. ``closest_vertex`` " | ||
| "function takes geometry of other table as input and gives the gid of the " | ||
| "closest vertex as output by comparing ``geom`` of both the tables." | ||
| msgstr "" |
There was a problem hiding this comment.
Over-correction: "road ways_vertices_pgr" should remain "road vertices" (conceptual use).
The phrase "road ways_vertices_pgr" at line 571 is grammatically incorrect. Here, "vertices" is used conceptually to mean "vertex points on the road network," not as a table reference. The PR objective explicitly states that conceptual uses should remain unchanged.
Note the inconsistency: line 572 still correctly uses "road vertex" (singular) as a concept.
📝 Suggested fix
#: ../../build/docs/un_sdg/sdg3-health.rst:549
msgid ""
-"There are multiple road ways_vertices_pgr near the hospital. Create a "
+"There are multiple road vertices near the hospital. Create a "
"function to find the geographically closest road vertex. ``closest_vertex`` "
"function takes geometry of other table as input and gives the gid of the "
"closest vertex as output by comparing ``geom`` of both the tables."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@locale/en/LC_MESSAGES/un_sdg/sdg3-health.po` around lines 569 - 575, Replace
the incorrect phrase "road ways_vertices_pgr" with the intended conceptual term
"road vertices" in the message string; ensure the sentence reads "There are
multiple road vertices near the hospital..." and keep references to the function
name `closest_vertex`, the output field `gid`, and input field `geom` unchanged
so the description still explains that `closest_vertex` takes another table's
geometry and returns the gid of the closest vertex.
| msgid "" | ||
| "`Affordable and Clean Energy` is the 7th Sustainable Development Goal 11." | ||
| " It aspires to ensure access to `affordable, reliable, sustainable` and " | ||
| "`modern` energy for all. Today renewable energy is making impressive " | ||
| "gains in the electricity sector. As more and more new settlements are " | ||
| "built, there would be new electricity distribution network developed. " | ||
| "Electricity Distribution is very expensive infrastructure. Finding the " | ||
| "optimal path for laying this infrastructure is very crucial to maintain " | ||
| "the affordability of electricity for everyone. This exercise focusses on " | ||
| "finding this optimal path/network for laying the electricity distribution" | ||
| " equipment." | ||
| "`Affordable and Clean Energy` is the 7th Sustainable Development Goal 11. It " | ||
| "aspires to ensure access to `affordable, reliable, sustainable` and `modern` " | ||
| "energy for all. Today renewable energy is making impressive gains in the " | ||
| "electricity sector. As more and more new settlements are built, there would " | ||
| "be new electricity distribution network developed. Electricity Distribution " | ||
| "is very expensive infrastructure. Finding the optimal path for laying this " | ||
| "infrastructure is very crucial to maintain the affordability of electricity " | ||
| "for everyone. This exercise focusses on finding this optimal path/network " | ||
| "for laying the electricity distribution equipment." |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the source RST file for this text to determine if it's pre-existing
rg -n "7th Sustainable Development Goal" --type rstRepository: pgRouting/workshop
Length of output: 177
Fix source RST: Remove incorrect "11" from SDG 7 description.
The text "7th Sustainable Development Goal 11" in the source RST file (docs/un_sdg/sdg7-energy.rst:13) is factually incorrect—SDG 7 is Affordable and Clean Energy, not Goal 11. This should be "7th Sustainable Development Goal" without the "11". The PO file reflects this pre-existing error from the source.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@locale/en/LC_MESSAGES/un_sdg/sdg7-energy.po` around lines 28 - 37, The msgid
string for SDG 7 contains the incorrect phrase "7th Sustainable Development Goal
11"; update the msgid text to remove the trailing "11" so it reads "7th
Sustainable Development Goal" (keep the rest of the msgid content unchanged) —
locate and edit the msgid that begins with "`Affordable and Clean Energy` is the
7th Sustainable Development Goal 11..." and replace "Goal 11" with "Goal" to
match the correct source RST.
|
Rejecting this pull request. Most of the changes are worse in naming. All things should not be ways_vertices_pgr and ways_vertices_pgr and ways is more of a naming we use when coming raw out of osm2pgrouting. |
2 participants
Fixes # .
Changes proposed in this pull request:
verticeswithways_vertices_pgrin SQL scriptsThe workshop scripts referenced a table called
verticeswhich does not exist in the standard osm2pgrouting schema. The correct table isways_vertices_pgr, which maps OSM IDs to internal pgRouting vertex IDs.@pgRouting/admins
Summary by CodeRabbit