[pgrouting-dev] pgRoutingLayer QGIS3 version

Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Vicky Vergara-2
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Vicky Vergara-2
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent
Hi Vicky,

Python has several linters. I propose to use for pgRoutingLayer project this tool: PyLint (http://pylint.pycqa.org). PyLynt is mantained by Python Code Quality Authority (http://meta.pycqa.org). I need to prepare and include a configuration file (.pylintrc) in repository.

To test this new release I will write a wiki explaining how can you do it.

Thanks,


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Worth Lutz

This may be helpful for the project.  https://editorconfig.org/ 

Take a look and see if it will help keep coding in the project consistent.

I have no connection with editorconfig except that I use it.

Worth Lutz


On 10/11/2018 1:06 PM, Cayetano Benavent wrote:
Hi Vicky,

Python has several linters. I propose to use for pgRoutingLayer project this tool: PyLint (http://pylint.pycqa.org). PyLynt is mantained by Python Code Quality Authority (http://meta.pycqa.org). I need to prepare and include a configuration file (.pylintrc) in repository.

To test this new release I will write a wiki explaining how can you do it.

Thanks,


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Vicky Vergara-2
Yes,
good idea, many editors use that .editorconfig file

On Thu, Oct 11, 2018 at 12:51 PM Worth Lutz <[hidden email]> wrote:

This may be helpful for the project.  https://editorconfig.org/ 

Take a look and see if it will help keep coding in the project consistent.

I have no connection with editorconfig except that I use it.

Worth Lutz


On 10/11/2018 1:06 PM, Cayetano Benavent wrote:
Hi Vicky,

Python has several linters. I propose to use for pgRoutingLayer project this tool: PyLint (http://pylint.pycqa.org). PyLynt is mantained by Python Code Quality Authority (http://meta.pycqa.org). I need to prepare and include a configuration file (.pylintrc) in repository.

To test this new release I will write a wiki explaining how can you do it.

Thanks,


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent
Hi,

We are already using editorconfig in pgRoutingLayer: https://github.com/pgRouting/pgRoutingLayer/blob/master/.editorconfig

I propose to use PyLint in addition to editorconfig, because the first is a code analysis tool. Editorconfig, as far as I know, is a tool to maintain consistent coding styles between different editors. 

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 11 oct. 2018 a las 21:32, Vicky Vergara (<[hidden email]>) escribió:
Yes,
good idea, many editors use that .editorconfig file

On Thu, Oct 11, 2018 at 12:51 PM Worth Lutz <[hidden email]> wrote:

This may be helpful for the project.  https://editorconfig.org/ 

Take a look and see if it will help keep coding in the project consistent.

I have no connection with editorconfig except that I use it.

Worth Lutz


On 10/11/2018 1:06 PM, Cayetano Benavent wrote:
Hi Vicky,

Python has several linters. I propose to use for pgRoutingLayer project this tool: PyLint (http://pylint.pycqa.org). PyLynt is mantained by Python Code Quality Authority (http://meta.pycqa.org). I need to prepare and include a configuration file (.pylintrc) in repository.

To test this new release I will write a wiki explaining how can you do it.

Thanks,


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Reply | Threaded
Open this post in threaded view
|

Re: [pgrouting-dev] pgRoutingLayer QGIS3 version

Worth Lutz

I agree with using a linter also.

Editorconfig just helps reduce the output of the linter.  :)

Worth Lutz


On 10/12/2018 4:31 AM, Cayetano Benavent wrote:
Hi,

We are already using editorconfig in pgRoutingLayer: https://github.com/pgRouting/pgRoutingLayer/blob/master/.editorconfig

I propose to use PyLint in addition to editorconfig, because the first is a code analysis tool. Editorconfig, as far as I know, is a tool to maintain consistent coding styles between different editors. 

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El jue., 11 oct. 2018 a las 21:32, Vicky Vergara (<[hidden email]>) escribió:
Yes,
good idea, many editors use that .editorconfig file

On Thu, Oct 11, 2018 at 12:51 PM Worth Lutz <[hidden email]> wrote:

This may be helpful for the project.  https://editorconfig.org/ 

Take a look and see if it will help keep coding in the project consistent.

I have no connection with editorconfig except that I use it.

Worth Lutz


On 10/11/2018 1:06 PM, Cayetano Benavent wrote:
Hi Vicky,

Python has several linters. I propose to use for pgRoutingLayer project this tool: PyLint (http://pylint.pycqa.org). PyLynt is mantained by Python Code Quality Authority (http://meta.pycqa.org). I need to prepare and include a configuration file (.pylintrc) in repository.

To test this new release I will write a wiki explaining how can you do it.

Thanks,


Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Does python has some sort of code linter?

Would be nice to lint the code and set some standards,
like use spaces instead of tabs, how many spaces, etc.
I am not a python expert but for C++ I use googles linter:

BTW, what do I have to do to test the the release?

Regards Vicky



On Wed, Oct 10, 2018 at 3:10 AM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have merged PR#82 and published the new pre-release "v3.0.0-alpha1":

I know we need to do more work but I have little time and I think priority is to have a QGIS3 version to share with community. 

More things: I would like to update the Readme file because it is totally outdated.

Thanks!
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<[hidden email]>) escribió:
Hi all,

Works I have done:
- I've updated develop branch because it was very outdated (now is paired with master).
- I've changed base branch (now is develop) for PR to merge all the works for QGIS3 version: https://github.com/pgRouting/pgRoutingLayer/pull/82
- I've created "gsoc2018" tag with all the works derived from GSOC 2018 by Aasheesh Tiwari past summer: https://github.com/pgRouting/pgRoutingLayer/tree/gsoc2018

In several days we remove python3 branch, we will merge PR#82 and we will create v3.0.0-alpha1 version (without pgr_DijkstraCost).
Regarding to DijkstraCost function, I will try to review it again to include in v3.0.0-alpha2 version (now I understand his utility in QGIS :) ).

It is important understand several things to do a better planning of pgRoutingLayer future:
- QGIS2 is developed entirely with Python 2.
- QGIS3 is developed entirely with Python 3 and PyQGIS API is very different to QGIS2.
- Python 2 EOL (end of life) is very near (Python 2 will be retired in 1 year) (https://pythonclock.org/ and https://www.python.org/dev/peps/pep-0373/).

Taking in consideration this information we should not spend time to code in Python 2 so we only can develop in one direction: QGIS3.
Last pgRoutingLayer version for QGIS2 should be 2.2 (actually this is the last version uploaded to QGIS plugin hub).

QGIS3 is very (very) superior to QGIS2 (most of his core has been rewrited) so if you can migrate version (2 to 3) you should do. I can help you if you do not know how to migrate version (it is very easy in all operative systems).

We are very near to have a QGIS3 version! 

Regards,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs


El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<[hidden email]>) escribió:
Hi Cayetano

Please Merge first the branch to "develop" branch.
And clean the repository
send a mail to this list about the branches that will be deleted,
wait 3 or 4 days for people to double check that no "important" work will be deleted.

Make sure that the tag that contains the GSoC students work was created.
(and the tag has as last commit, the last commit of the student during the program)
I really don't remember if I taged his work, we never continue work on a students branch,
that branch has to remain intact when the GoC program is over that contains the students work and his work only.

By cleaning the repo:
When people clone or update their fork, they would only get master and develop branch.
master has pgRoutingLayer v2.2.0 and branch develop has v3.0.0-dev

Because the version is a "major" change  we have to go thru the following phases:

v3.0.0-alpha (v3.0.0-alpha1 if needed see bellow)
v3.0.0-beta
v3.0.0-rc
etc.

Use that versioning numbering to create the following branches & tags
v3.0.0-alpha1  Includes all the functions that are coded
v3.0.0-alpha2  Remove function(s) that is(are)  well-known to have issues (issues must be documented on the issue list)
or
v3.0.0-alpha Include only the functions that supposedly work well
or
v3.0.0-alpha1 Includes only pgr_dijkstra
v3.0.0-alpha2 Includes also pgr_dijkstraCost
etc ...

I like third option best because also work on documentation has to be done.
So make users documentation of pgr_dijkstra and make the alpha with only that function
So gradually documentation and functionality come in an alpha


I know version pgRoutingLayer v3.0.0 will use python3 what I dont know, is which versions of QGIS it will work.
The version v2.0 didn't handle the functions with the "pgr_" is that going to remain the same?
Which versions of pgRouting  will it work with?
I guess you removed all the deprecated functions, so for example, and kept for example
for 2.1: pgr_dijkstra, pgr_drivingDistance and pgr_KSP
Maybe, many users (like me) have QGIS 2.18
Some instructions about testing the phases would be needed.


About initial decisions of what can be included:
Now that we are starting a new major
one thing is I learned is don't include what does not work

In our case, besides pgRoutingLayer code correctness, we depend on the correctness of pgRouting :
About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
compare VS
It gives a different perspective of the results of pgr_dijkstra


As reference:
This is the latest pgRouting documentation
This is the pgRouting 3.0.0-dev documentation (to be released on September 2019)

Lots of things to plan
:)

Regards
Vicky




On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <[hidden email]> wrote:
Hi all,

I have finally cleaned code and fixed last bugs in python3 branch from pgRoutingLayer with all the work done by student Aasheesh Tiwari (@AasheeshT) this summer in GSOC.
I would like to merge python3 branch with master and upload a QGIS3 version. I've tested this code and it is working well in QGIS3 although there is still a lot of work to do :)

It is important to note that I've removed several functions (what I really did is comment access from GUI):
- WithPoints family: these functions don't work well because they were a very last addition in GSOC. We will add this code when Aasheesh (or somebody) fixes them.
- TSP euclidean: This function is not working properly (before GSOC this function does not work well). I think is more useful to add pgr_TSP in the future that fix euclidean version.
- DijkstraCost: This function is not working properly and I don't undestand very well the purpose of this function in QGIS.

Deprecated functions were also removed (kdijkstra_path and kdijkstra_cost) but in this case we removed all the code.

Thanks,
Cayetano Benavent
Head of Data

<a href="tel:%2B34%20954%20095%20876" value="+34954701157" style="color:rgb(17,85,204)" target="_blank" moz-do-not-send="true">+34 954 095 876
www.geographica.gs
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://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
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

_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev


_______________________________________________
pgrouting-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pgrouting-dev