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.
Best,
Steve
On Mon, Jul 1, 2013 at 10:45 AM, Stephen Mather
<stephen@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
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@smathermather.com <mailto:stephen@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@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Daniel - if this is not happening in osm2pgrouting now it probably should
get implemented this way.
It's already fixed. There was a pull request, which changed various ID's to
bigint and I reverted "gid" to integer. Other ID's seem to be OK.
Daniel
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
On 6/30/2013 10:37 PM, Daniel Kastl wrote:
Daniel - if this is not happening in osm2pgrouting now it probably
should get implemented this way.It's already fixed. There was a pull request, which changed various ID's
to bigint and I reverted "gid" to integer. Other ID's seem to be OK.
Ok, cool. My brain is only partially engaged in pgrouting at the moment. I just did a dist-upgrade from squeeze to wheezy and I need to recompile a lot of extra stuff and the autotools stuff seems to be broken in the new versions or incompatible with my old project config files. It would nice if the world upgraded to cmake 
-Steve
It seems the pgr_tsp requires four or more locations.
I assume its required because pgr_tsp is attempting to rewrite a result from the traveling salesman problem in to some optiminal version
dave.
On 05/07/13 08:34, Dave Potts wrote:
It seems the pgr_tsp requires four or more locations.
I assume its required because pgr_tsp is attempting to rewrite a result from the traveling salesman problem in to some optiminal version
dave.
Sorry slight keyboard problem :-O, what I should have sent is
I assume its required because pgr_tsp is attempting to rewrite a result from the traveling salesman problem in to some optiminal version, is it possible to have access to the raw solution, just because I might have to deal with a case where I only have 3 nodes instead of the required 4?
Dave.
On 7/5/2013 2:40 AM, Dave Potts wrote:
On 05/07/13 08:34, Dave Potts wrote:
It seems the pgr_tsp requires four or more locations.
I assume its required because pgr_tsp is attempting to rewrite a
result from the traveling salesman problem in to some optiminal versiondave.
Sorry slight keyboard problem :-O, what I should have sent is
I assume its required because pgr_tsp is attempting to rewrite a result
from the traveling salesman problem in to some optiminal version, is it
possible to have access to the raw solution, just because I might have
to deal with a case where I only have 3 nodes instead of the required 4?
You can't optimize 3 points they are by definition optimized in the symmetric case. This was throwing the code into an infinite loop so I think I checked in a check for this and return an error.
The code might be modified to just return the input as the results, but when I look at doing this it was not trivial to do so I just throw the error.
-Steve