[pgrouting-users] pgr_maxFlow

pgRouting pgrouting-users
1

Hi

Great news on getting version 2.5 out

Looking around the documentation I have noticed the function pgr_maxFlow, its only listed as a proposed function.

Just how stable is it ? Was it ever finished ? Does it work?

regards

Dave.

2

Hi Dave,

The function is listed as “stable proposed”, and the info box on top explains a bit, what we mean with this:
http://docs.pgrouting.org/latest/en/proposed.html#stable

Often those functions are ready, but they are missing some extra work on tests or documentation for example.
Or they have been developed during GSoC, and we hope to get some feedback from real-world use cases.
Maybe by “hiding” these functions a bit, only few people find and try them. But feedback is actually what we hope for.

pgr_maxFlow falls into the GSoC category, and some feedback would be great!

Best regards,
Daniel

···

On Mon, Sep 25, 2017 at 4:27 PM, Dave Potts <mrdapotts@gmail.com> wrote:

Hi

Great news on getting version 2.5 out

Looking around the documentation I have noticed the function pgr_maxFlow, its only listed as a proposed function.

Just how stable is it ? Was it ever finished ? Does it work?

regards

Dave.

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

–

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

3

HiSo its a workable function, but there may be bugs in it!

From a look at the source code, it seems that most of work is done by the boost library and any possible errors would be in the calling interface which is a mixture of C/C++

···

On 25 September 2017 at 09:21, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Dave,

The function is listed as “stable proposed”, and the info box on top explains a bit, what we mean with this:
http://docs.pgrouting.org/latest/en/proposed.html#stable

Often those functions are ready, but they are missing some extra work on tests or documentation for example.
Or they have been developed during GSoC, and we hope to get some feedback from real-world use cases.
Maybe by “hiding” these functions a bit, only few people find and try them. But feedback is actually what we hope for.

pgr_maxFlow falls into the GSoC category, and some feedback would be great!

Best regards,
Daniel

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

On Mon, Sep 25, 2017 at 4:27 PM, Dave Potts <mrdapotts@gmail.com> wrote:

Hi

Great news on getting version 2.5 out

Looking around the documentation I have noticed the function pgr_maxFlow, its only listed as a proposed function.

Just how stable is it ? Was it ever finished ? Does it work?

regards

Dave.

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

–

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

4

Hi
Ignore previous email

Thanks for the prompt reply
So its a workable function, but there may be bugs in it!

From a look at the source code, it seems that most of work is done by the boost library and any possible errors would be in the calling interface which is a mixture of C/C++

There is no support for this code, if I find any bugs you would be interested in any solutions, but otherwise I am on my own

Dave

···

On 25 September 2017 at 09:28, Dave Potts <mrdapotts@gmail.com> wrote:

HiSo its a workable function, but there may be bugs in it!

From a look at the source code, it seems that most of work is done by the boost library and any possible errors would be in the calling interface which is a mixture of C/C++

On 25 September 2017 at 09:21, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Dave,

The function is listed as “stable proposed”, and the info box on top explains a bit, what we mean with this:
http://docs.pgrouting.org/latest/en/proposed.html#stable

Often those functions are ready, but they are missing some extra work on tests or documentation for example.
Or they have been developed during GSoC, and we hope to get some feedback from real-world use cases.
Maybe by “hiding” these functions a bit, only few people find and try them. But feedback is actually what we hope for.

pgr_maxFlow falls into the GSoC category, and some feedback would be great!

Best regards,
Daniel

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

On Mon, Sep 25, 2017 at 4:27 PM, Dave Potts <mrdapotts@gmail.com> wrote:

Hi

Great news on getting version 2.5 out

Looking around the documentation I have noticed the function pgr_maxFlow, its only listed as a proposed function.

Just how stable is it ? Was it ever finished ? Does it work?

regards

Dave.

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

–

Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

5

Thanks for the prompt reply
So its a workable function, but there may be bugs in it!

Like in every other function, too :wink:

From a look at the source code, it seems that most of work is done by the
boost library and any possible errors would be in the calling interface
which is a mixture of C/C++

That's right.
Vicky also added a Boost logo on every function's documentation site, if it
makes use of Boost Library:
http://docs.pgrouting.org/latest/en/pgr_maxFlow.html#pgr-maxflow

There is no support for this code, if I find any bugs you would be
interested in any solutions, but otherwise I am on my own

Like with every function, there is support by wwriting to the list or
reporting a bug on Github.
There is no guaranteed time until a bug gets fix, but it depends on the
case and how easy/difficult it is.

If support or bug fixes are important for you, and if you're in the lucky
situation to be able to afford commercial support, then you are definitely
not on your own. :wink:

Best regards,
Daniel

Dave

On 25 September 2017 at 09:28, Dave Potts <mrdapotts@gmail.com> wrote:

HiSo its a workable function, but there may be bugs in it!

From a look at the source code, it seems that most of work is done by the
boost library and any possible errors would be in the calling interface
which is a mixture of C/C++

On 25 September 2017 at 09:21, Daniel Kastl <daniel@georepublic.de>
wrote:

Hi Dave,

The function is listed as "stable proposed", and the info box on top
explains a bit, what we mean with this:
http://docs.pgrouting.org/latest/en/proposed.html#stable

Often those functions are ready, but they are missing some extra work on
tests or documentation for example.
Or they have been developed during GSoC, and we hope to get some
feedback from real-world use cases.
Maybe by "hiding" these functions a bit, only few people find and try
them. But feedback is actually what we hope for.

pgr_maxFlow falls into the GSoC category, and some feedback would be
great!

Best regards,
Daniel

On Mon, Sep 25, 2017 at 4:27 PM, Dave Potts <mrdapotts@gmail.com> wrote:

Hi

Great news on getting version 2.5 out

Looking around the documentation I have noticed the function
pgr_maxFlow, its only listed as a proposed function.

Just how stable is it ? Was it ever finished ? Does it work?

regards

Dave.

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: https://georepublic.info

6

Hi all,

Sorry for the late response.
Initially was under the “Experimental” category, I went through the code, cleaned code & fixed pgr_edgeDisjointPaths that is why there is a:

Breaking change on:

  • pgr_edgeDisjointPaths:
    • Added path_id, cost and agg_cost columns on the result
    • Parameter names changed- The many version results are the union of the one to one version

And I moved them up to the “Stable” section.

On version 2.x only the the functions on 2.0 are in the main area of the documentation, everything new either is “Stable” or “Experimental”

The Stable ones are the most likely to be moved to the main area of the documentation on version 3.0

Everything done by GSoC Students is on experimental section unless there has being a procedure like the one I did on the max flow functions.

And, like Daniel mentioned, feedback is important.

And you are not on your own, i’ve being feeling that way for this last 2 years of code rewrite, but now I am into a point where I think the internal code is stable and more members of the community can participate in bug fixing, more rewriting, or adding new functions with ease. For example, currently, I am on gitter [1], I am still working with Vidham, and Anthony Tasca, with the focus on the functions needed to make pgr_trsp work correctly.

A way to learn how pgRouting works internally & contribute would be to read code and document the code. (Just by reading 2.0 code I knew it had bugs)

Vicky

[1] https://gitter.im/pgRouting/pgrouting

···

–

Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44, 
81739 München, Germany

Vicky Vergara
Operations Research

eMail: vicky@[georepublic.de](http://georepublic.de)
Web: [https://georepublic.info](https://georepublic.info)

Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9

Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl