Making PolarRoute-server compatible with latest PolarRoute and MeshiPhi versions

[thomaszwagerman]

Specifically updating how evaluate_route works with PolarRoute changes to route_calc api:

# From
calc_route = route_calc(route_file.name, mesh_file.name)

# To
calc_route = route_calc(df, from_wp, to_wp, mesh.json, "fuel")

Also removing all TempFile related code, as now longer required for new API.

[davidwyld]

I appreciate this is still in draft, but looks good so far, I'm very pleased to finally be getting rid of the need to deal with tempfiles now we can use the python interface more directly.

Feel free to make any other improvements to this function you feel are necessary.

I'm sure you will, but don't forget to restrict the polar-route version in the pyproject.toml from this point.

[github-actions]

Coverage Report

File	Stmts	Miss	Branch	BrPart	Cover	Missing
polarrouteserver
__init__.py	3	0	0	0	100%
_version.py	11	0	0	0	100%
celery.py	15	3	0	0	0	80%
polarrouteserver/route_api
__init__.py	4	0	0	0	100%
models.py	72	2	0	0	0	97%
responses.py	33	0	2	0	100%
serializers.py	120	5	36	4	4	94%
tasks.py	124	21	28	7	7	82%
utils.py	108	10	42	4	4	91%
views.py	277	17	52	4	4	94%
polarrouteserver/route_api/management
__init__.py	0	0	0	0	100%
polarrouteserver/route_api/management/commands
__init__.py	0	0	0	0	100%
ensure_adminuser.py	22	22	6	0	0	0%
insert_mesh.py	26	26	8	0	0	0%
polarrouteserver/utils
__init__.py	0	0	0	0	100%
loggers.py	10	10	0	0	0	0%
TOTAL	825	116	174	19	85%

[thomaszwagerman]

Satisfied this successfully runs and returns routes

[davidwyld]

As I've said, this is a huge improvement, thanks for doing this.

I wonder if we should add to the testing of this functionality in test_utils? I'm happy to write a test if you don't have time.

Don't forget to update the changelog in this PR too.

[thomaszwagerman]

I've added route_type parameter as a positional argument and updated the route evaluation API endpoint + schema.

Opened an issue in PolarRoute for related issues within route_calc

[davidwyld]

Worth discussing whether we want to expose route_type in the API?

Want me to implement a test for evaluate_route? Or we can just open an issue since there isn't one to begin with so I don't want it to hold back this branch.

[davidwyld]

I'm a bit unsure what to do about this, I guess we just leave the dynamic version numbers in the history then they get sorted out at tag/release time?

[davidwyld]

I'm unsure whether we need to expose route_type in this function, but I guess there's no harm in it as long as we think about whether it ultimately gets exposed in the API. I think this is fine.

[davidwyld]

I'm not sure if it's possible for the submitted route to have waypoint names, we may want to preserve those in the future, but lets leave this as is for now, they don't really matter for SIIS at least.

[davidwyld]

Ah okay so we are exposing route_type in the api. Do we actually want to do this?