<div dir="ltr"><div class="gmail_default" style="font-family:comic sans ms,sans-serif">Hello all:<br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">The proposed functions Steve is talking about are here<br><a href="http://docs.pgrouting.org/2.2/en/src/convinience/doc/convenience.html#convenience-functions">http://docs.pgrouting.org/2.2/en/src/convinience/doc/convenience.html#convenience-functions</a><br><br>You can comment on them here:<br><a href="https://github.com/pgRouting/pgrouting/issues/368">https://github.com/pgRouting/pgrouting/issues/368</a><br><a href="https://github.com/pgRouting/pgrouting/issues/322">https://github.com/pgRouting/pgrouting/issues/322</a><br><a href="https://github.com/pgRouting/pgrouting/issues/317">https://github.com/pgRouting/pgrouting/issues/317</a><br><a href="https://github.com/pgRouting/pgrouting/issues/316">https://github.com/pgRouting/pgrouting/issues/316</a><br><a href="https://github.com/pgRouting/pgrouting/issues/315">https://github.com/pgRouting/pgrouting/issues/315</a><br><a href="https://github.com/pgRouting/pgrouting/issues/311">https://github.com/pgRouting/pgrouting/issues/311</a><br><br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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.<br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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.<br><a href="https://github.com/sankepallyrohithreddy/pgrouting/wiki/GSoc-2016-Contraction">https://github.com/sankepallyrohithreddy/pgrouting/wiki/GSoc-2016-Contraction</a><br><br>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. <br><a href="https://github.com/Illedran/pgrouting/wiki/GSoC-2016-Flow">https://github.com/Illedran/pgrouting/wiki/GSoC-2016-Flow</a><br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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 <br>namespace pgRouting {<br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif"> namespace algorithm { ....}<br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif"> namespace graph {....}<br>}<br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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)<br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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", <br>Here is the documentation for developers:<br><a href="http://docs.pgrouting.org/doxy/2.3-dev-develop/index.html">http://docs.pgrouting.org/doxy/2.3-dev-develop/index.html</a><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">This is the general graph documentation (my favourite it even has figures)<br><a href="http://docs.pgrouting.org/doxy/2.3-dev-develop/classPgr__base__graph.html">http://docs.pgrouting.org/doxy/2.3-dev-develop/classPgr__base__graph.html</a><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">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).<br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">Vicky<br><br><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif">PD. Sorry if I don't meet the high priorities of users or fellow developers.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 27, 2016 at 6:59 PM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com" target="_blank">woodbri@swoodbridge.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
I have discussed these with Vicky and she has agreed to follow up on them.<br>
<br>
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.<br>
<br>
Thanks,<br>
-Steve<br>
<br>
---<br>
This email has been checked for viruses by Avast antivirus software.<br>
<a href="https://www.avast.com/antivirus" rel="noreferrer" target="_blank">https://www.avast.com/antivirus</a><br>
<br>
_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>