[pgrouting-dev] pgRoutingLayer QGIS3 version

Cayetano Benavent cayetano.benavent at geographica.gs
Fri Oct 12 01:31:25 PDT 2018


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

+34 954 095 876
www.geographica.gs


El jue., 11 oct. 2018 a las 21:32, Vicky Vergara (<vicky at georepublic.de>)
escribió:

> Yes,
> good idea, many editors use that .editorconfig file
>
> On Thu, Oct 11, 2018 at 12:51 PM Worth Lutz <wal3 at mindspring.com> 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
>>
>> +34 954 095 876 <%2B34%20954%20095%20876>
>> www.geographica.gs
>>
>>
>> El mié., 10 oct. 2018 a las 15:44, Vicky Vergara (<vicky at georepublic.de>)
>> 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:
>>> https://github.com/cpplint/cpplint
>>>
>>> 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 <
>>> cayetano.benavent at geographica.gs> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have merged PR#82
>>>> <https://github.com/pgRouting/pgRoutingLayer/pull/82> and published
>>>> the new pre-release "v3.0.0-alpha1":
>>>> https://github.com/pgRouting/pgRoutingLayer/releases/tag/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
>>>>
>>>> +34 954 095 876
>>>> www.geographica.gs
>>>>
>>>>
>>>> El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent (<
>>>> cayetano.benavent at geographica.gs>) 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
>>>>> <https://github.com/pgRouting/pgRoutingLayer/pull/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
>>>>>
>>>>> +34 954 095 876
>>>>> www.geographica.gs
>>>>>
>>>>>
>>>>> El mié., 3 oct. 2018 a las 17:01, Vicky Vergara (<vicky at georepublic.de>)
>>>>> 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 withPoints & all proposed functions
>>>>>> https://docs.pgrouting.org/2.6/en/proposed.html#stable
>>>>>> There is a warning. and some detected issues:
>>>>>>
>>>>>> https://github.com/pgRouting/pgrouting/issues?q=is%3Aopen+is%3Aissue+label%3AwithPoints
>>>>>>
>>>>>> About experimental functions:
>>>>>> https://docs.pgrouting.org/2.6/en/proposed.html#experimental-functions
>>>>>>
>>>>>> About pgr_dijkstraCost in QGiS I use it (to generate the image) here:
>>>>>>
>>>>>> https://workshop.pgrouting.org/2.5.0/en/chapters/shortest_path.html#exercise-5-many-pedestrians-going-to-different-destinations-returning-aggregate-costs
>>>>>> compare VS
>>>>>>
>>>>>> https://workshop.pgrouting.org/2.5.0/en/chapters/shortest_path.html#exercise-4-many-pedestrians-going-to-different-destinations
>>>>>> It gives a different perspective of the results of pgr_dijkstra
>>>>>>
>>>>>>
>>>>>> As reference:
>>>>>> This is the latest pgRouting documentation
>>>>>> https://docs.pgrouting.org/2.6/en/index.htm
>>>>>> This is the pgRouting 3.0.0-dev documentation (to be released on
>>>>>> September 2019)
>>>>>> https://docs.pgrouting.org/dev/en/index.html
>>>>>>
>>>>>> Lots of things to plan
>>>>>> :)
>>>>>>
>>>>>> Regards
>>>>>> Vicky
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 2, 2018 at 7:32 PM Cayetano Benavent <
>>>>>> cayetano.benavent at geographica.gs> 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
>>>>>>>
>>>>>>> +34 954 095 876
>>>>>>> www.geographica.gs
>>>>>>> _______________________________________________
>>>>>>> pgrouting-dev mailing list
>>>>>>> pgrouting-dev at lists.osgeo.org
>>>>>>> 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 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> pgrouting-dev mailing list
>>>>>> pgrouting-dev at lists.osgeo.org
>>>>>> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>>>>
>>>>> _______________________________________________
>>>> pgrouting-dev mailing list
>>>> pgrouting-dev at lists.osgeo.org
>>>> 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 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
>>>
>>>
>>> _______________________________________________
>>> pgrouting-dev mailing list
>>> pgrouting-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>> _______________________________________________
>> pgrouting-dev mailing listpgrouting-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> 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 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
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20181012/06a74aa9/attachment-0001.html>


More information about the pgrouting-dev mailing list