Hello,
Is there any particular reason why the sql functions expect the unique
identifier have a "GID" of the table that contains the network data. I
am asking since some sql functions expect an "ID" unique identifier
while the functions in the routing_dd_wrapper expects a "GID"
identifier in which it is just renamed to "ID".
This is a bit confusing for me.
Anyway, will there be any objections if I will just expect that the
table that contains the network data have a "ID" field name as its
record unique identifier.
Mario.
On 6/21/2012 11:42 PM, Mario Basa wrote:
Hello,
Is there any particular reason why the sql functions expect the unique
identifier have a "GID" of the table that contains the network data. I
am asking since some sql functions expect an "ID" unique identifier
while the functions in the routing_dd_wrapper expects a "GID"
identifier in which it is just renamed to "ID".
This is a bit confusing for me.
Anyway, will there be any objections if I will just expect that the
table that contains the network data have a "ID" field name as its
record unique identifier.
Hi Mario,
I think the origin of this has something to do with the fact that some of the algorithms allocate space based on a vector that is more efficient if the ID values are contiguous. The assumption was the vendor data ID values might be more random and therefore less contiguous than GID values which are assigned when the shapefile loader loads the data and are contiguous.
This issue is mostly with the Boost based algorithms. I think it is fine to make the change you are suggesting, the user should be able to select any column as a unique integer identifier and alias it to ID.
-Steve