The critical Blocks needed to sort a List of coordinates by distance from an Android device in a way that does not trip the LineString bug are shown @rohitcr2k .
Sufficient information is posted to determine the nearest location. Then you can use the coordinates provided to post a route to that location without tripping the bug. The original, 'simple' method to sort destinations based on distance from your Android works fine in the National Parks tutorial. When a developer uses the simple method, users cannot later post a
LineString (the route) on the Map as you discovered. Why is this alternate method necessary? Using runtime Markers along with a
LineString contribute to the bug that prevents developers from posting the route
LineString after working with runtime Markers Evan mentioned.
The Blocks in the Button3 event handler determine the nearest of all the destinations stored in the Destinations.csv, the csv file used in the National Parks tutorial. Both methods find the the closest location. These Block determine the nearest destination without using the Marker blocks (used in the National Parks tutorial). This more complex method should allow you to calculate distances and sort them without using runtime Markers.
The Button3 Blocks calculate distances and determine the nearest without using runtime Markers. The algorithm
-
iterates through the csv/list of coordinates to obtain the required information.
-
calculates a distance from the Android to each of the locations. The calculation requires coordinates from a LocationSensor or hard coded to use in the route Procedure Origin coordinates.
-
saves each distance calculated in a List of distances. The distances are calculated by iterating through fulldestinationList. The distanceBetweenLocationsMiles Procedure makes the actual calculation.
-
creates a List of the distances to all the destinations (newDestinationDistances). Simultaneously the newDestinationDistancesandLocation List (the original destination list with the calculated distance as a new item) is created. Both Lists are needed later to identify the nearest location.
-
uses the getMinimumValueInList2 Procedure to determine how close the Android is to each stored location from the lists.
-
searches the newDestinationDistancesandLocation List for the 'shortest' straight-line distance. In the example it searches for 243.9 miles (the calcMinDistance). The distance you determine to the nearest location will be very different.
-
then finds the calcMinDistance in the newDestinationDistancesaandLocation List, the code extracts the latitude,longitude and Location Name corresponding to what the code determined as the closest location (shortest distance) from the newDestinationDistancesandLocation List items.
-
the corresponding coordinates (closestDestination) display in Label3 and theLocationName in Label4.
-
some blocks Blocks you need are in the National Parks tutorial and the Blocks are not reproduced here. Also missing are the Blocks required to initialize the Lists. You need to provide the 'missing' Blocks and the List initialization Blocks.
Reproduce the Blocks, add the missing pieces and you can determine the closestDestination coordinates.
Use the lat,lon coordinates of the nearest location in your route Procedure destination puzzle pieces. Parse the lat,lon two element csv to obtain the destination lat and the destination lon. Display the route on your map.
Calculating the nearest destination without using the runtime Marker information will allow you to post just the nearest marker and the driving route to it on your map.
The route is calculated but does not display when you use the route Procedure because of the bug. The bug means you cannot use the CreateMarker command prior to drawing the LineString route (or something related). The LineString displays the route graphics.
Passing information using Labels can create execution issues; much better to provide the information you want to use for endLat etc. in a variable.