[pgrouting-dev] pgRoutingLayer QGIS3 version
Worth Lutz
wal3 at mindspring.com
Fri Oct 12 08:34:15 PDT 2018
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
>
> +34 954 095 876 <tel:%2B34%20954%20095%20876>
> www.geographica.gs <http://www.geographica.gs/>
>
>
> El jue., 11 oct. 2018 a las 21:32, Vicky Vergara
> (<vicky at georepublic.de <mailto: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
> <mailto: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 <tel:%2B34%20954%20095%20876>
>> www.geographica.gs <http://www.geographica.gs/>
>>
>>
>> El mié., 10 oct. 2018 a las 15:44, Vicky Vergara
>> (<vicky at georepublic.de <mailto: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
>> <mailto: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 <tel:%2B34%20954%20095%20876>
>> www.geographica.gs <http://www.geographica.gs/>
>>
>>
>> El jue., 4 oct. 2018 a las 12:44, Cayetano Benavent
>> (<cayetano.benavent at geographica.gs
>> <mailto: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 <tel:%2B34%20954%20095%20876>
>> www.geographica.gs <http://www.geographica.gs/>
>>
>>
>> El mié., 3 oct. 2018 a las 17:01, Vicky Vergara
>> (<vicky at georepublic.de
>> <mailto: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 numberingto 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
>> <mailto: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 <tel:%2B34%20954%20095%20876>
>> www.geographica.gs
>> <http://www.geographica.gs/>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> <mailto: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 <http://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
>> <mailto:pgrouting-dev at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> <mailto: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 <http://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
>> <mailto:pgrouting-dev at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>>
>>
>>
>> _______________________________________________
>> pgrouting-dev mailing list
>> pgrouting-dev at lists.osgeo.org
>> <mailto:pgrouting-dev at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> <mailto: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 <http://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 <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20181012/13ff9536/attachment-0001.html>
More information about the pgrouting-dev
mailing list