jcundill / streeto Goto Github PK

need to push this action onto an asnycWithProgress block

In the example shown below, there are marked ways, pavements, on both sides of a single road.

Route Choice Scorer considers both of them to be valid separate route options, and ends up scoring the leg well as the lengths of both options are very similar.

Need a better mechanism for assessing whether the alternatives are in fact different. Currently, we just look at the points they have in common,

Jon,
Should the Fitness reported on the "Course Evolution Progress" dialog be the same as the "Overall Score" in the "Course Details" tab?

*
Peter

For a Scatter Event - Typically put out 20 controls and have three “courses”: Long being the fastest finisher to get 16 controls; Medium being the fastest finisher to get 12 controls and short is the fastest to get 8 controls.

• So the “algorithm” could be to spread the controls such that it takes say 11 km to get 16, 7km to get 12; 4km to get 8 controls (or something like that).

When invoked from the preference dialog, the options to split the map over two sheets are not applied.

Also, not properly saved and remembered next time you run the program

Score Event (eg typically 40mins or 60mins to get the max points possible by visiting as many controls as possible, not necessarily all of the same value, and there being a penalty for late finishing):

• There is the placement of controls - looking for a good general spread, such that the distance to visit all controls would be a significantly tantalising challenge for the fast runners (eg 40min event, say 4min/km, running distance = 10km => shortest route to all controls should be say 11km?)
• For mid-range runners - say we wanted them to be able to visit 10 controls by going 6.6km (ie 6mins/km)
• For slow/walkers - maybe at 10mins/km we would want them to be able to visit 7 controls in 4km?
• Then there is the issue for some scoring schemes of having different points for different control Id’s - and then the challenge becomes how to distribute the high value controls (Some setters want to give all participants the ability to get to the high points and the difference in results comes down to having the running speed to pickup the minor points as well. Another approach is to put the higher points at the extremities so they are only available to fast runners (but this is a less favoured approach).
• For the common Australian StreetO the controls are (Total of 26 controls):
• 4 controls worth 20 each; 4 worth 30 each; 4 worth 40 each; 4 worth 50 each; and 4 worth 60 each
• 4 or 5 high pointed controls (eg 80,90,100, 110, 120)
• 1 very high point control (eg 200)

If the start and finish control are in the same location, can get the same ControlSite instance used for both during the GA processing.
Need to clone the course before renumbering it

Get an 'Application is damaged' when trying to open the application if the dmg has been downloaded

This is due to https://bugs.openjdk.java.net/browse/JDK-8276150

The java runtime libs are signed but the application itself isn't signed at the moment.

Workaround sudo xattr -d com.apple.quarantine /Applications/StreetO.app after installing the application

Note: the above command will remove the extended attribute that tells the mac that this file was downloaded and needs checking. This is a bit of a nasty hack, but does work.

Currently, we only look up new Street Furniture if the map region changes.

But we only ask for it in a 5K radius, so moving to a new location in the same map extract will not get Street Furniture for that area.

Currently, OSM data imports are handled automatically.

This is convenient and makes the application easy to use.

However, some parts of the world, Australia for example, do not have pre-generated, small scale, PBF extracts available for download via the GeoFabrik API.

Sites exist that let you create and download a PBF file of a chosen area, a town or a region, for yourself.

Add an option to allow the user to import a PBF they have already downloaded, rather than always auto-importing a PBF for them.

See https://bugs.openjdk.java.net/browse/JDK-8275723

Needs javaFX runtime updating to a later version, currently 17.0.2 is only available as an EA build.

The app does run on it however.

Currently, alternate route choices are assessed purely on distance differences.

What is more realistic is to assess them by the probable time it would take you to run the alternate legs.

This is the 'go over the hill or around the hill', decision. The application has the elevations of the route points, so it should be fairly straightforward to factor this into the RouteChoiceScorer logic.