[test] point_layer_to_route_with_oneways.py

[brylie]

Test point_layer_to_route_with_oneways.py with QGIS 2.6.

[brylie]

I am looking in the sample data (testdata.sqlite) for a network with direction field. There are two network tables (network, network2), but neither seems to have a direction field.

Is there some sample data that I can use to test this script?

[brylie]

I have updated the import, and the script runs successfully. However, I cannot produce any output.

I have tried:

• creating a simple shapefile with two points, each near the network geometry
• copying/simplifying the routepoints1 table in testdata.sqlite

[anitagraser]

The topology of the network table is broken in your sqlite (check the intersection in the north east). Also, the order of points is from the east to the west, while the one way in the middle runs from west to east.

[brylie]

Alright, as far as I recall, the only modification I have made to the network table was to add another column. Would this possibly have broken the topology?

[anitagraser]

No, I don't see how that would have happened by only editing the attributes.

[brylie]

Hm, alright. I needed a table with direction attributes, so that I could test the oneways. How was the original topology created?

[anitagraser]

All that matters for the network analysis library is that the start and end nodes are properly snapped together, i.e. have exactly the same coordinates.

[brylie]

I am thinking that it might be good create a very basic set of tables to test the scripts. E.g.

• simple directed network
• simple route points
• simple route line

The more complex tables can be eliminated, while the simple three could be used for automated testing.

[anitagraser]

Sure, that was the idea behind testdata.sqlite. Do you mean that the current tables are too complex?

[brylie]

Well, slightly yes. I am just thinking

• the route points table possibly needs only two points,
• the directed network probably doesn't need more than two possible paths, and
• the route lines table coordinates can correspond to the route points table coordinates.

[anitagraser]

I disagree that two points would be enough: it has to be tested that the result is a consecutive route. Imho this cannot be ensured by only testing between one start and end point. There can be errors in the code which could cause to route to end up jumbled or broken.

I'm not sure if using the same coordinates for route lines and points really makes a difference ... Isn't the idea of testing to test different scenarios? Why make everything so same?

[brylie]

Here is a first attempt at visualizing a simple topology.

[brylie]

I am just proposing to reduce the problem to the minimum number of components and test on that. As additional bugs are found additional tests can be built with complexity needed.

E.g. for the sequential routing you mention, three points may be sufficient to demonstrate that the algorithm is working at a basic level for automated testing.

[anitagraser]

I appreciate the approach and please do feel free to write tests and have an sqlite file with data for these tests. For my manual tests during method development I prefer to have a little more complex test data in order to be able to discover issues.

[brylie]

Thanks Anita. I will take a look at how to create sqlite files and unit test python scripts.