Hello all:
The proposed functions Steve is talking about are here
http://docs.pgrouting.org/2.2/en/src/convinience/doc/convenience.html#convenience-functions
You can comment on them here:
https://github.com/pgRouting/pgrouting/issues/368
https://github.com/pgRouting/pgrouting/issues/322
https://github.com/pgRouting/pgrouting/issues/317
https://github.com/pgRouting/pgrouting/issues/316
https://github.com/pgRouting/pgrouting/issues/315
https://github.com/pgRouting/pgrouting/issues/311
I will be working on the general internal library, because right now the graph it only accepts one kind of edges_sql which imply an internal vertex/edge comibnation and for the GSoC projects, other kinds of vertex/edge are needed. Astar is another function that uses a different vertex/edge, in this case is a different vertex definition. I will use that one during the bonding period of the GSoC program to test the changes so that several kinds of vertex/edge combination can be handled in the internal general library.
I’ve being working already since January with Rohith on the contraction hierarchies and fortunately he was selected in the GSoC. His algorithm requires a different type of vertex/edge so the general graph has to meet those requirements also . Here is a link to his task log he has done.
https://github.com/sankepallyrohithreddy/pgrouting/wiki/GSoc-2016-Contraction
Andrea will be using directly boost implemented algorithm, and that will give valuable information about the difficulty of using the general internal library that is based on boost. At the moment, its not defined if a different vertex/edge is needed, but flow algorithms accept negative values, so, probably it will.
https://github.com/Illedran/pgrouting/wiki/GSoC-2016-Flow
One of the main goals I have in my mind is to standardize the C function names to start with pgr_ and that implies a lot work: for example, all the code where its being used needs to be changed, and re-tested. Also start using namespace in the C++ code & nested namespaces
namespace pgRouting {
namespace algorithm { …}
namespace graph {…}
}
Any change I make in the General Internal library will need to be propagated to the development of the GSoC projects. (hopefully they will learn to live with my change of plans… didn’t work quite nice, go back to a different approach)
I also want to learn the habit of document the code as I write it (personal goal), the project is growing, and if left undocumented its going to be ugly to “debug”, “improve”, “add functionality”, “rewrite old very buggy functionality”,
Here is the documentation for developers:
http://docs.pgrouting.org/doxy/2.3-dev-develop/index.html
This is the general graph documentation (my favourite it even has figures)
http://docs.pgrouting.org/doxy/2.3-dev-develop/classPgr__base__graph.html
I feel lucky for version 2.3, because there will be other people besides me writing code. (which by the way I think its faster than making, proofreading, translating the user’s documentation).
Vicky
PD. Sorry if I don’t meet the high priorities of users or fellow developers.
···
On Wed, Apr 27, 2016 at 6:59 PM, Stephen Woodbridge <woodbri@swoodbridge.com> wrote:
There are various proposed functions that I wrote 3-4 years ago that are in the source tree. It is unlikely that I will have time to update these or to make them more generalized. For that matter, I’m not sure that all of them are still needed or generally useful to others users. So the first question we should ask is are they useful and what use cases do they fulfill? then decide if we want to spend more time on them or not.
I have discussed these with Vicky and she has agreed to follow up on them.
On my HIGH priority list of wants pgRouting is to get TRSP functions updated or rewritten using boost. I would like to see this made a priority. Being able to support complex turn restrictions would differentiate pgrouting for most other solutions.
Thanks,
-Steve
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
–
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