Wrong spelling for "euclidean"

[dkastl]

There is at least one place, where "euclidean" is spelled wrong:
https://docs.pgrouting.org/2.6/en/pgr_eucledianTSP.html#pgr-euclediantsp

Since this is also in the URL of the function, the URL will change, when the name changes, so we could add a warning message in v2.7, that the function will change its name in v3.0:

• Add deprecation notice in v2.7(or v2.6 bug-fix release)
• Rename the function (and other occurrences) in v3.0

[cvvergara]

I would like:
v2.6.2 for a bug fixes like the one in #1152 which is an internal C/C++ code change
and
v2.7.0 for when we know exactly what is coming on 3.0:

• No internal C/C++ code change
• deprecate functions that will be gone on 3.0
• add warning messages to functions that are deprecated and will be gone on 3.0
• Backport from 3.0-dev the documentation that we are standardizing
• Backport the SQL comments soon to be standardized

[cvvergara]

My dyslexia showed up, I apologize

[SunveerSingh]

Hey, I would like to help in this issue, please let me know if I can help.

[dkastl]

@SunveerSingh , thank you for your offer to help! This task goes beyond just fixing text in the documentation, so it requires quite some coordination with release, because the function name will change, too.

@cvvergara will let you know, when she will make the internal changes. It would be definitly good to have some people testing it and give feedback.

[SunveerSingh]

@dkastl Thank you, lets see what @cvvergara say.

[cvvergara]

@SunveerSingh
This fix needs a new release, like I mentioned above
But you can inspect all the steps that are needed to make a release, for example

#1095

[cvvergara]

Working on pgr_eucledianTSP name change

Traveling Sales Person - Family of functions
pgr_TSP - When input is given as matrix cell information.
pgr_eucledianTSP - When input are coordinates.

Current use example

-- will use euclidean distances of the information

SELECT * FROM pgr_eucledianTSP(
        $$
        SELECT id,  x,  y  FROM edge_table_vertices_pgr
        $$
    )

&
-- will use the distances given (start_vid, end_vid, agg_cost) etiher the information is stored on a table or its obtained by using a CostMatrix function like this

SELECT * FROM pgr_TSP(
        $$
        SELECT start_vid, end_vid, agg_cost FROM mycostmatrix
        $$
    )
SELECT * FROM pgr_TSP(
    $$
    SELECT * FROM pgr_dijkstraCostMatrix(
        'SELECT id, source, target, cost, reverse_cost FROM edge_table',
        (SELECT array_agg(id) FROM edge_table_vertices_pgr),
        false
    )
    $$
);

Both functions are using simulated annealing to be solved,
But there are many other approximation methods to solve TSP, that in the future they could be implemented

option A

• pgr_eucledianTSP -> pgr_TSPannealingEuclidean
• pgr_TSP -> pgr_TSPannealing

Where

• pgr_TSP : have the name of the problem first
• annealing : have the name of the algorithm used
• Euclidean : when data is (id,x,y) then it will use euclidean distances

option B

change

• pgr_eucledianTSP -> pgr_TSPeuclidean
• pgr_TSP -> pgr_TSP

Where

• pgr_TSP : have the name of the problem first
• Euclidean : when data is (id,x,y) then it will use euclidean distances

Leave for the future the implementation of other algorithms that approximate a solution to TSP

option C

• pgr_eucledianTSP -> pgr_TSP
• pgr_TSP -> pgr_TSP

Where

• pgr_TSP : have the name of the problem first

Leave for the future the implementation of other algorithms that approximate a solution to TSP
Internally figure out if the query gives (id,x,y) or if it gives (start_vid, end_vid, agg_cost) as data
Then the name euclidean can be avoided.

option D

• pgr_eucledianTSP -> pgr_TSPannealing
• pgr_TSP -> pgr_TSPannealing

Where

• pgr_TSP : have the name of the problem first
• annealing : have the name of the algorithm used

Internally figure out if the query gives (id,x,y) or if it gives (start_vid, end_vid, agg_cost) as data
Then the name euclidean can be avoided.

my preference

My preference is tackle the different algorithms now so A or D

• A is fast to solve basically is name changes
• D is more complicated, but not impossible

The work could be done like this:

• Do option B, make the PR to develop
• Do option A, make the PR to develop
• Try to do option D in at most 2 weeks time do PR to develop (doable? doable fast?, if its too difficult then dont do the PR)
  Then choose.

[dkastl]

Option B sounds also good for me as a start.

[cvvergara]

I have ready
Option A, B, & D in PR so we can decide

[dkastl]

Where is Option C? ;-)

I somehow find the solution without euclideanor annealing to be part of the function name the best looking one.

[cvvergara]

Because that is the least of my preferences I didnt make one :(

Leave for the future the implementation of other algorithms that approximate a solution to TSP
Internally figure out if the query gives (id,x,y) or if it gives (start_vid, end_vid, agg_cost) as data
Then the name euclidean can be avoided.

I prefer to work it out in the present.

[cvvergara]

As the start option B I will merge

[cvvergara]

PR was merged, the name change iwith correct spelling is done