Comments (15)
Ok, so we should still review the documentation anyway to make sure gid AS id
appears, at least in the introductory samples. I can take care of that.
from osm2pgrouting.
Yes, you are right. Some time ago the field name was id
. This commit changed the name to avoid other problems:
07f1634#diff-45d504039e209ed5a5031dc80d94a3a310eaccce17f1ce5ff57548bb02cb2040
Documentation should be changed in pgRouting docs. You could propose the change opening a PR.
Thanks @skyNacho
from osm2pgrouting.
It's correct that sometimes you see gid
and sometimes id
in spatial datasets, and we didn't really declare one as "default" in pgRouting, probably because pgRouting is supposed to work with any network data and the SQL text
argument in pgrouting functions allows you to easily adjust the column name with gid AS id
.
from osm2pgrouting.
Understood. In that case I will close this issue and will improve the documentation to avoid confusion for new users.
from osm2pgrouting.
I am opening again.
Yes, you are right. Some time ago the field name was id.
More long time ago was gid
https://github.com/pgRouting/osm2pgrouting/blob/osm2pgrouting-2.0.0/src/Export2DB.cpp#L84
On the rewrite I changed it to id
This commit changed the name to avoid other problems:
I made that commit, the problems were that osm2pgrouting users were using with gid
for many years before and it broke code
So I had to turn the id
to gid
again :-(
The default on pgRouting's inner query is id
for the edges identifier,
and the standard name for geometry (PostGIS) is geom
osm2pgrouting creates gid
and the_geom
, instead of id
and geom
Before I arrived to pgRouting the_geom
was used also in PostGIS, but now it follows a standard which is geom
, and that was not changed on osm2pgroutingand not changed on the topology functions of pgRouting
But back to the id
name
Examples:
If id
is used, then the following query can be used as inner query
SELECT * FROM ways;
SELECT * FROM pgr_dijkstra(`SELECT * FROM ways`, 1, 2)
if gid
is used, then this is compulsory:
SELECT gid AS id, source, target, cost, reverse_cost FROM ways;
SELECT * FROM pgr_dijkstra(`SELECT gid AS id, source, target, cost, reverse_cost FROM ways`, 1, 2)
Maybe have a configuration file with column names.
As new users might want id
to avoid doing gid AS id
or to avoid renaming the column with ALTER TABLE
For example, if the user wants to use identificador
for the id column and desde
for the source
column, hasta
for the target
column for example then the inner queries would be:
SELECT gid AS id, fuente AS source, hasta AS target ....
from osm2pgrouting.
Well, I don't know that well about the gid
vs. id
history ;-)
But somehow I like in our documentation that we always write like
SELECT * FROM pgr_dijkstra(`SELECT gid AS id, source, target, cost, reverse_cost FROM ways`, 1, 2)
Because it shows in a very simple example, that the column names in a network table can actually have different names, and to make them fit you just need to use ALIAS
. I think as a PostgreSQL beginner I would have first renamed all my column names to match.
So I don't think it's possible to find a common default anymore, neither for the_geom
vs. geom
nor id
vs gid
. But I think that's OK. However, I think we can write our documentation better, and I find the feedback of @skyNacho very valuable, because many things that may be obvious for us, who know pgRouting for a very long time, are maybe mysterious or unclear for new users.
from osm2pgrouting.
We dont use gid
in the documentation:
For example:
https://docs.pgrouting.org/3.2/en/pgr_withPoints.html#one-to-one
SELECT * FROM pgr_withPoints(
'SELECT id, source, target, cost, reverse_cost FROM edge_table ORDER BY id',
'SELECT pid, edge_id, fraction, side from pointsOfInterest',
-1, 3,
details := true);
from osm2pgrouting.
To me it was confusing to follow the installation documentation and hitting an error when pgr_dijsktra could not find the 'id' column. So, either all documentation is reviewed and updated to ensure examples work out-of-the-box, or the naming convention in osm2pgrouting is modified so that tables work out-of-the-box (this would require reviewing all documentation anyway).
I understand @dkastl 's point to showcase the flexibility of pgRouting with regards to column names. However, forcing all queries to use alias seems an over complication. My instinct would be to adopt PostGIS's naming as the standard. But I am unable to evaluate the implications in terms of documentation review, updates in production deployments, modifications in third-party software and so on.
from osm2pgrouting.
@skyNacho What about to make it configurable?
from osm2pgrouting.
From my perspective making it configurable, the pgRouting user opts to use names that are not by default on pgRouting
from osm2pgrouting.
That could be a suitable solution. It could have a default that simplifies operation but provide flexibility for cases where the naming conventions are different for whatever reason.
Do you have an example of how the configuration would be like?
from osm2pgrouting.
Currently we have xml for configuration
https://github.com/pgRouting/osm2pgrouting/blob/osm2pgrouting-2.0.0/mapconfig.xml
As I am not a front-end person, and there is a plan for a complete rewrite,
I would need to opinions of json or xml for the rewrite
but following the xml format, to something like this
db_config_default.xml
<?xml version="1.0" encoding="UTF-8"?>
<dbconfiguration>
<column name="id" alias="id">
<column name="source" alias="source">
<column name="target" alias="target">
<column name="cost" alias="cost">
<column name="reverse_cost" alias="reverse_cost">
<column name="geom" alias="geom">
....
</dbconfiguration>
So an old style user of som2pgrouting would change to gid
and geom
db_config_oldstyle.xml
<?xml version="1.0" encoding="UTF-8"?>
<dbconfiguration>
<column name="id" alias="gid">
<column name="source" alias="source">
<column name="target" alias="target">
<column name="cost" alias="cost">
<column name="reverse_cost" alias="reverse_cost">
<column name="geom" alias="the_geom">
....
</dbconfiguration>
maybe a spanish would create
mi_configuracion_de_base_de_datos.xml
<?xml version="1.0" encoding="UTF-8"?>
<dbconfiguration>
<column name="id" alias="id">
<column name="source" alias="desde">
<column name="target" alias="hasta">
<column name="cost" alias="costo">
<column name="reverse_cost" alias="costo_regreso">
<column name="geom" alias="geometria">
....
</dbconfiguration>
from osm2pgrouting.
I think it makes sense. So, the github repository would provide different xml options and one can decide which one to choose or even to adapt it if needed. I guess this change would not affect existing deployments of pgRouting, but only new OSM->pgRouting data imports with a new version of osm2pgrouting, right?
Regarding the question on json vs xml, although I tend to favor json, if xml is already in use for configuration I would stick to that.
from osm2pgrouting.
Yes, it would require a new major version. because it would break code,
maybe scripts that already exist, would need to be changed
from osm2pgrouting.
I just sent a pull request with minimal changes to pgRouting concepts section. I believe that should be enough for new users to understand the use of aliases in pgRouting queries.
from osm2pgrouting.
Related Issues (20)
- Table "ways" has "gid" as id HOT 2
- Migrate to GH Actions
- How is the column "cost" and similars calculated? HOT 5
- mapconfig_for_cars.xml -> "unclassified" has wrong priority HOT 7
- Issue with data import: fe_sendauth: no password supplied HOT 3
- osm2pgrouting does not compile with libpqxx v 7.1.1, 7.2.0. Compiles okay with 6.4.7 HOT 8
- Remove "priority" and "max-speed"
- New release? HOT 4
- 2.3.7 compile error HOT 5
- Move branch master to "main"
- Release v2.3.8 HOT 1
- Some way are not imported in the ways table HOT 2
- Too many edges HOT 4
- Error opening /usr/share/osm2pgrouting/mapconfig.xml HOT 1
- Problem creating topology on pgrouting HOT 2
- unable to open / parse config file HOT 3
- osm_relations table does not get populated
- unclosed token at line 51376846 Failed to open / parse data file
- Problem compiling on alpine linux (libpqxx) HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from osm2pgrouting.