[pgrouting-dev] pgRoutingLayer QGIS3 version

Vicky Vergara vicky at georepublic.de
Wed Oct 10 06:43:54 PDT 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20181010/7a3cd0f5/attachment-0001.html>


More information about the pgrouting-dev mailing list