topic Re: Getting Driving Directions using lat/long instead of physical addresses in ArcGIS API for Silverlight Questions

Getting Driving Directions using lat/long instead of physical addresses

SangamLama — Tue, 30 Nov 2010 18:09:55 GMT

Hi all,
If I am to pass lat/long instead of physcial addresses for both starting and ending point of a route, how would I pass that?

The live sample shows how to get directions using physical addresses.

Could anyone provide a brief example?

Thanks

Re: Getting Driving Directions using lat/long instead of physical addresses

JenniferNery — Tue, 30 Nov 2010 18:30:59 GMT

The Geocode service you are using should be able to accept lat/lon fields to identify a location.

In this sample, http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#RoutingDirections, notice that Locator calls AddressToLocationAsync. Instead, you need to call LocationToAddressAsync as in this other sample, http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#LocationToAddress.

Re: Getting Driving Directions using lat/long instead of physical addresses

SangamLama — Mon, 06 Dec 2010 18:18:51 GMT

The Geocode service you are using should be able to accept lat/lon fields to identify a location.

In this sample, http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#RoutingDirections, notice that Locator calls AddressToLocationAsync. Instead, you need to call LocationToAddressAsync as in this other sample, http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#LocationToAddress.

Hi there,

Here's how I implemented Driving Directions. It doesn't work because I haven't called LocationsToAddress function. I wanted to first understand why I need to use it to begin with. Because it seemed to me that as long as the Mappoints for starting and ending addresses were passed in Stops, I was good to go?

Could someone take a peak at what I've done and explain what's missing where? Both the stops have lat/long instead of physical address.

public RouteResult GetDirections(double latitude, double longitude)
        {
            List<Graphic> _stops = new List<Graphic>();
            MapPoint point1 = new MapPoint();
            point1.X = latitude;
            point1.Y = longitude;
            Graphic stop1 = new Graphic() { Geometry = point1 };

            List<AddressCandidate> startingAdd = GeocodeAddress("380 New York St, Redlands, CA, 92373");
            AddressCandidate start = startingAdd[0];
            MapPoint point2 = new MapPoint();
            point2.X = start.Location.X;
            point2.Y = start.Location.Y;
            Graphic stop2 = new Graphic() { Geometry = point2 };

            _stops.Add(stop1);
            _stops.Add(stop2);

             _routeTask = new RouteTask("http://tasks.arcgisonline.com/ArcGIS/rest/services/NetworkAnalysis/ESRI_Route_NA/NAServer/Route");
            _routeTask.SolveCompleted += _routeTask_SolveCompleted;
            _routeTask.Failed += _routeTask_Failed;

            _routeTask.SolveAsync(new RouteParameters()
            {
                ReturnRoutes = false,
                ReturnDirections = true,
                DirectionsLengthUnits = esriUnits.esriMiles,
                Stops = _stops,
                UseTimeWindows = false
            });



            handle.WaitOne();
            return _routeResult;
}

void _routeTask_SolveCompleted(object sender, RouteEventArgs e)
        {
            _routeResult = e.RouteResults[0];
            handle.Set();
        }

        void _routeTask_Failed(object sender, TaskFailedEventArgs e)
        {
            _routeResult = null;
            handle.Set();
        }

Thanks!!

Re: Getting Driving Directions using lat/long instead of physical addresses

JenniferNery — Fri, 10 Dec 2021 22:06:04 GMT

Ah okay I see what you're doing now.

In this case, you do not need LocationToAddressAsync nor AddressToLocationAsync.

Using this sample http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#RoutingDirections, I commented out code for initializing locator and subscribing to its events. Instead, I subscribed to MouseClick.

 if (_stops.Count < 2)
  _stops.Add(new Graphic(){Geometry = e.MapPoint});
 if(_stops.Count == 2)
  _routeTask.SolveAsync(_routeParams);

Since you already have the lat/lon values, you do not need to get MapPoints from an event such as MouseClick, you can simply do:

_stops.Add(new Graphic(){Geometry = new MapPoint(lat, lon}); // for both start and end location.

That should be all you need to do.

Re: Getting Driving Directions using lat/long instead of physical addresses

SangamLama — Fri, 10 Dec 2021 22:06:07 GMT

Ah okay I see what you're doing now.

In this case, you do not need LocationToAddressAsync nor AddressToLocationAsync.

Using this sample http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#RoutingDirections, I commented out code for initializing locator and subscribing to its events. Instead, I subscribed to MouseClick.
 if (_stops.Count < 2)
  _stops.Add(new Graphic(){Geometry = e.MapPoint});
 if(_stops.Count == 2)
  _routeTask.SolveAsync(_routeParams);
Since you already have the lat/lon values, you do not need to get MapPoints from an event such as MouseClick, you can simply do:
_stops.Add(new Graphic(){Geometry = new MapPoint(lat, lon}); // for both start and end location.
That should be all you need to do.

Hi Jennifer,
thanks for the response. That did clear out the confusion. I found the bug that was causing the function to not work properly.

Let me confirm this with you -- for class MapPoint, X property means latitude, and Y property means longitude? or is it the other way around?

Re: Getting Driving Directions using lat/long instead of physical addresses

DominiqueBroux — Tue, 07 Dec 2010 14:20:31 GMT

for class MapPoint, X property means latitude, and Y property means longitude? or is it the other way around?

It's the other way : X means longitude and Y means latitude.

Re: Getting Driving Directions using lat/long instead of physical addresses

SangamLama — Tue, 07 Dec 2010 14:24:40 GMT

It's the other way : X means longitude and Y means latitude.

thank you!