[pgrouting-dev] Integer types

[Stephen Woodbridge]

Steve M,

Daniel is correct, it would be a major job to convert all C/C++ 
functions to support bigint. In general, the way to deal with this is 
similar to the way shp2pgsql deals with it. What needs to happen it the 
we maintain a vendor id column that gives us a back reference to the the 
vendor record, but we also add a new gid column that is a serial data 
type. This will assign a new sequential integer gid to each record 
imported into the database that is compatible with our code.

Users have tried to use the vendor edge ids and node ids in the past, 
but have run into problems because this are not allows integers, some 
time they are bigints or alpha-numeric, neither of which are supported.

This has additional benefits of compressing the range of gid numbers 
which is more efficient and fast memory-wise for all the boost code.

Daniel - if this is not happening in osm2pgrouting now it probably 
should get implemented this way.

Thanks,
   Steve W

On 6/30/2013 9:58 PM, Daniel Kastl wrote:
>
>
>
> On Mon, Jul 1, 2013 at 10:45 AM, Stephen Mather
> <stephen at smathermather.com <mailto:stephen at smathermather.com>> wrote:
>
>     In general using OSM data is working great in pgRouting.  One place
>     which still needs to be patched with allowing big integers is
>     alphashape and points as polygon.
>
>
> Hi Steve,
>
> You're right that big integers are not supported and I just had to
> revert a change in osm2pgrouting, because I had tried to change "gid" to
> bigint, which caused wrong topology and routes. I think such a change
> would be a more difficult task, because pgRouting makes use of shortest
> path implementation of Boost library.
>
> Nevertheless I believe that it's not really urgent issue and problem
> that pgRouting does not support bigint right now. OSM just needs these
> 32bit ID's, because in their database every way and node gets an ID. For
> pgRouting we just use a subset of this data (roads), so I would doubt
> that there is right now road network data of a size, that really
> requires bigint type.
>
> Of course it'S necessary that import tools like osm2pgrouting are able
> to handle 32bit ID's when they parse OSM data, and they may store
> "osm_id" as an attribute for reference to the original OSM object. But
> there is no need to use the same ID's for "gid", "source" and "target"
> attributes. It would be even bad for performance not to renumber the
> ID's to have smaller numbers.
>
> Or did I misunderstand something?
>
> Daniel
>
>
>
>
>
>
>     Best,
>     Steve
>     _______________________________________________
>     pgrouting-dev mailing list
>     pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
>     http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>