[pgrouting-dev] Proposed functions

[Vicky Vergara]

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 at 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 at 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 at georepublic.de
Web: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20160427/4afd65ab/attachment.html>