Directions Directive

[tomhalley]

I'll keep it brief: It would be great if your library allowed implementation of the Directions API!

For example:

<google-map center="map.center" zoom="map.zoom">
    <direction type="origin" lat="45" long="23" name="Half Moon, Guildford" />
    <direction type="waypoint" lat="10" long="45" name="Fendon Sports Centrer, Fendon" />
    <direction type="destination" lat="13" long="28" name="Full House Inn, Brighton" />
</google-map>

Or even:

<google-map center="map.center" zoom="map.zoom">
    <origin lat="45" long="23" name="Half Moon, Guildford" />
    <waypoint lat="10" long="45" name="Fendon Sports Centrer, Fendon" />
    <destination lat="13" long="28" name="Full House Inn, Brighton" />
</google-map>

I'd quite like to work on this as this is a feature I need on one of my projects.

[cthrax]

I'm curious what one would do with static directions like this? Wouldn't it be better to use the embed API and just get a snapshot?

I'd think this might be better handled by getting a reference to the map and just making the calls externally, but maybe not. What would you do with a direction as shown above if there were multiple routes returned? Easy enough to handle in your own code, but then in this you would have to do some workaround like a callback or something that defaults to first in list or something.

These are just my first thoughts, so don't think we wouldn't potentially take this as a feature, but I just thought I'd throw those out there.

@nmccready You have any thoughts? This would be another service call, similar to the geocoding discussion we had.

[premiumFrye]

I'd be interested in this feature as well - otherwise I'm looking at having to impletement a inappbrowser opening up maps.google.com with directions.

[cthrax]

@nsquimby I pose the same questions to you. I'm trying to flesh out what this feature would accomplish and how.

[tomhalley]

I'm pretty new to Angular, so it was just a formatting idea. Maybe a
service that exposes some methods for adding directions to an existing map.
This was something I was looking for so that I could allow a user to build
directions to a place.
On 23 Jul 2014 19:41, "Myles Bostwick" notifications@github.com wrote:

I'm curious what one would do with static directions like this? Wouldn't
it be better to use the embed API and just get a snapshot?

I'd think this might be better handled by getting a reference to the map
and just making the calls externally, but maybe not. What would you do with
a direction as shown above if there were multiple routes returned? Easy
enough to handle in your own code, but then in this you would have to do
some workaround like a callback or something that defaults to first in list
or something.

These are just my first thoughts, so don't think we wouldn't potentially
take this as a feature, but I just thought I'd throw those out there.

@nmccready https://github.com/nmccready You have any thoughts? This
would be another service call, similar to the geocoding discussion we had.

—
Reply to this email directly or view it on GitHub
#578 (comment)
.

[tomhalley]

This might even be a non issue if the best way to add directions to a map
is already through making the calls externally. Ultimately I'd want to
simplify the coding for other developers.
On 23 Jul 2014 23:32, "Tom Halley" REDACTED wrote:

I'm pretty new to Angular, so it was just a formatting idea. Maybe a
service that exposes some methods for adding directions to an existing map.
This was something I was looking for so that I could allow a user to build
directions to a place.
On 23 Jul 2014 19:41, "Myles Bostwick" notifications@github.com wrote:

I'm curious what one would do with static directions like this? Wouldn't
it be better to use the embed API and just get a snapshot?

I'd think this might be better handled by getting a reference to the map
and just making the calls externally, but maybe not. What would you do with
a direction as shown above if there were multiple routes returned? Easy
enough to handle in your own code, but then in this you would have to do
some workaround like a callback or something that defaults to first in list
or something.

These are just my first thoughts, so don't think we wouldn't potentially
take this as a feature, but I just thought I'd throw those out there.

@nmccready https://github.com/nmccready You have any thoughts? This
would be another service call, similar to the geocoding discussion we had.

—
Reply to this email directly or view it on GitHub
#578 (comment)
.

[cthrax]

A service could be an interesting idea, there is the problem of getting to the map that you're targeting (as there could be multiple maps on a single page), but once that was overcome, some sort of mapManager or something, it could be useful. Of course at that point, it doesn't seem much different from just using the API that google provides, and nggm requires.

[premiumFrye]

Agree with @tomhalley89: directions displayed on the map would be nice. I'm
building a mobile app and am supposed to reduce the 'pain' (I know) of
opening google maps. New to both Angular, and Cordova/Ionic myself, so
there may be a better way (inappbrowser, or native call), but just saw this
thread and thought I'd voice I have a need for that too.

On Wed, Jul 23, 2014 at 5:37 PM, Myles Bostwick notifications@github.com
wrote:

A service could be an interesting idea, there is the problem of getting to
the map that you're targeting (as there could be multiple maps on a single
page), but once that was overcome, some sort of mapManager or something, it
could be useful. Of course at that point, it doesn't seem much different
from just using the API that google provides, and nggm requires.

—
Reply to this email directly or view it on GitHub
#578 (comment)
.

[cthrax]

@nsquimby Utilizing the google maps api and getting a reference to the map object created by nggm, would give you the directions on the map. The proposed template format would require ahead of time knowledge of the directions and of the route to choose (if there are multiple routes). In essence making this a more difficult solution, at least to my mind. But since both of you are asking for it, I must be missing something, so please elaborate more on how this feature would differ from using the google provided API and what it would simplify.

[tomhalley]

It would be good to have a consistent service as part of the library that
could be used directly in a controller. I would just end up building a
wrapper around the Google api anyway so would be good having that in a
library for others to use as well. A service wrapper is definitely a lot
better than having bits of Ajax against Googles API scattered around in
your code base.
On 23 Jul 2014 23:37, "Myles Bostwick" notifications@github.com wrote:

A service could be an interesting idea, there is the problem of getting to
the map that you're targeting (as there could be multiple maps on a single
page), but once that was overcome, some sort of mapManager or something, it
could be useful. Of course at that point, it doesn't seem much different
from just using the API that google provides, and nggm requires.

—
Reply to this email directly or view it on GitHub
#578 (comment)
.

[tomhalley]

And not only that but the static calls could select a route depending on
options defined by the developer, such as longest, shortest, fastest etc.
On 23 Jul 2014 23:56, "Myles Bostwick" notifications@github.com wrote:

@nsquimby https://github.com/nsquimby Utilizing the google maps api and
getting a reference to the map object created by nggm, would give you the
directions on the map. The proposed template format would require ahead of
time knowledge of the directions and of the route to choose (if there are
multiple routes). In essence making this a more difficult solution, at
least to my mind. But since both of you are asking for it, I must be
missing something, so please elaborate more on how this feature would
differ from using the google provided API and what it would simplify.

—
Reply to this email directly or view it on GitHub
#578 (comment)
.

[cthrax]

@tomhalley89 the biggest concern I have about providing a service such as this is that it will have to expose all the same functionality as the google API itself. I'm not saying it's the wrong thing to do, but it increases the scope of this library significantly. So the real question is what value is the abstraction adding?

Pros:

• Contains all google maps interactions to one library

Cons:

• Creates the need for understanding the abstraction and in most cases the underlying API as well
• Creates another layer to have to debug when issues arise
• Creates a pain point when the underlying API is updated (meaning consumers have to wait for new release and could be non-trivial to add)

I'm trying to fill out the Pros list with more and am not seeing it. That's why I keep asking for more. So if you can fill it out a bit more, that would be awesome.

[tomhalley]

@cthrax I'm afraid I don't agree with the cons you've put forward:

Creates the need for understanding the abstraction and in most cases the underlying API as well

Making a service that wraps the google API and simplifies common tasks makes this a non-issue. The whole point of this addition is to simplify the Google API for the developer.

Creates another layer to have to debug when issues arise

Assuming it's implemented poorly. With the proper level of abstraction this wouldn't be a problem.

Creates a pain point when the underlying API is updated (meaning consumers have to wait for new release and could be non-trivial to add)

Well yes, but then you could say that about any library that wraps around a third party API. Again, if it's poorly implemented then yes it will cause issues. With the proper level of abstraction, the Directions part could break on an API change without any knock on effect to the google-maps directive. I'm assuming Google is pretty good about informing developers before they make API changes as well so as long as the fixes are made in time it should be fine.

In terms of pros:

• Adds additional directions functionality to map
• Simplifies the underlying Directions API with a wrapper service.
• Allows a static route to be defined in markup with options for route type etc.

[premiumFrye]

Agreed with @tomhalley89 on all points, but also, providing directions would create a marked increase in this project's scope--It's not my call to say what @cthrax should or shouldn't do, but I would find use in this functionality. As mentioned, I'm working on an Ionic mobile app, so opening directions in the app is the target. In the mean time, I'm going to give phonegap-googlemaps-plugin a shot. My use case fits that better, but it's not angular-y :/

[cthrax]

@tomhalley89 @nsquimby Alright guys, I talked with the other collaborators on this project and the scope increase of adding this would be more than the support we're getting to maintain this project at this point.

However, this feature is ripe for someone to write a plugin to get this functionality. You both seem to have a better grasp of the utility of this feature, so if you want to create a plugin, we'd be happy to provide any direction (haha, pun intended), on making that happen.

[nmccready]

All I have talked over this with @cthrax a ton; and we can possibly get to this on 2.0.1-2.0.x . But right now there are too many things to fix (129+ current issues) with not enough help with only @cthrax , myself, and @rickhuizinga .

So we need to come up with some basic requirements so that someone can implement this and be PR'ed into the library.

Also like @cthrax said this is ripe for an extension. However we need to come up with a organization for github or merge with an existing org.

[tomhalley]

@cthrax @nmccready Excellent, thanks for the update! I can scope out some basic requirements and post them here for people to review. Once those have been finalized it'll be easier to figure out if we need a separate org or if it can just be PR'd.

I'll draft some requirements tonight.

[nmccready]

@tomhalley89 any update?

[maeishoj]

any update on this?

[nmccready]

Some other people need to step in. I don't have time for this. Closing unless someone else wants to implement.