Jump to content

Advanced Google Maps and Apple Maps Search Workflow - Version 2.0.2 Release 12 February 2018


Recommended Posts

1 hour ago, deanishe said:

Very useful indeed.

 

I've submitted a couple of feature requests on GitHub, as I wouldn't want you to vegetate during the holidays :) 

 

On a more technical level, have you considered putting all the Perl code in external script files instead of pasting everything into Script boxes? There's a lot of duplication in there, it  makes the code harder to follow (though I must say, I don't think I've ever seen such readable Perl), and it undermines the utility of git commits when every change is to info.plist.

 

Eggsellent! Glad you like it.

 

I have responded to your github issues, all seem completely logical to me so I can see what I can do on them.

 

On the externalising of the Perl, that would actually be rather logical and I had not considered that, I think that would be logical now the flow has matured more. Also, anything that helps reduce the duplication is a bonus. I managed to pull about 80% of the duplication in this new version, but would like to remove as much as possible. I will have a look at this for the next version also.

 

And thank you! I know Perl can be a NIGHTMARE, hence I like to make it as readable and maintainable as possible. If you have any tips, or anything you think could be cleaned up, I am always all ears.

Link to comment

Just came across your workflow. Great work! Here's a feature request that may not be feasible. What if a modifier copied the distance to the clipboard.

I'm doing my taxes and going through hundreds of journeys. Tried to automate it with google sheets but can't get paste the multiple requests error, hence looking on Alfred.

 

I'm about to go do it manually (probably using your workflow, I'll see what works best), but it might be useful for others in the future?

 

Link to comment
1 hour ago, Damoeire said:

What if a modifier copied the distance to the clipboard.

 

That information isn't available to the workflow. It doesn't fetch any data from Google's API. It generates a URL and sends that to your browser.

 

At a technical level, what you're asking for has very little in common with what the workflow currently does and the way it works. Adding the functionality would also slow down the workflow a lot.

 

For what you're trying to do, you'd be much better off writing a script that can fetch all the data you need from the API. It sounds like you already have all the addresses in a spreadsheet, and it would be fairly simple to feed that into a script that can get all the distances at once.

Link to comment

Thanks @deanishe.

 

Same issue of me not understanding how the workflows work! But worth a try. I don't want to hijack this thread, -BUT- if I did, I would say I have tried this script 

http://dumptext.com/4baaCaig/raw/  and some others.

 

And everytime I get:

 

Error

Service invoked too many times for one day: route. (line 8).

 

And when I reduce the size of the spreadsheet that doesn't seem to help, but I presume I need to wait 24hours for the service to reset, so that didn't help to debug.

I've actually done it manually now, (with a little help from Keyboard Maestro) it didn't take long. At various points I've had the above script and similar working a little, but usually only part of the spreadsheet. If I came back to the spreadsheet (google sheets) it would usually start again rather than trying to complete the ones that had already been done, therefore not solving the error issue.

If that makes sense. Anyway.... @stuartcryan's excellent workflow isn't the place for me to be discussing this, and its done. Next years tax return I'll try again!

 

Link to comment
5 minutes ago, Damoeire said:

it would usually start again rather than trying to complete the ones that had already been done

 

It would if you call it on every row. It's up to you to only call it on rows that haven't been done.

 

As a general tip, when you're debugging or trying to get something to work, use the smallest possible dataset. If you'd tested the scripts on a dozen or so addresses, you wouldn't have sprung the API limit before you got the script working.

Link to comment

Howdy all,

So, for you fine people who have given me so many awesome workflows, I give you the Advanced Google Maps AND NOW APPLE MAPS Search Workflow available on Github --> https://github.com/stuartcryan/advanced-google-maps-alfred-workflow.

 

A couple of quick things:

  1. Didn't you just release a major update 1.3.0? Yahuh, I most certainly did, however after that some amazing ideas came out of the woodworks, and it became a mere stepping stone to what the workflow is today.
  2. Why didn't you wait to release 2.0.0? Quite simply, I thought it was complete, however, like I mentioned above, some GREAT ideas came out in the week after release from some passionate members of the community, and I figured, WHY NOT! In putting these in, I was able to create added flexibility when re-working the code base, to support several features that previously, were not possible.
  3. Why 2.0.0 not 1.4.0? The 2.0.0 release has changed a lot, including adding Apple Maps Support, new updating mechanism, all new location for configuration, and other major changes. Hence 2.0.0 seemed more appropriate.
  4. Why is there no download link right here where you are reading right now? Ahh now that is a good question, because there are some things you should know first, so jump back to the first post and get all the juicy deets!

 

So please enjoy, this release has had EXTENSIVE testing prior to release, I have to say I am pretty chuffed with it all around!

Stuart

 

Version 2.0.0 Changes

  • Renamed workflow to 'Advanced Google Maps and Apple Maps Workflow for Alfred'. Left bundleID intact deliberately
  • Changed workflow logo to support new multi-brand mix
  • Added feature for custom locations other than 'home' and 'work'
  • Added default transportation mode setting
  • Added fallback location setting in case there are issues with CoreLocationCLI
  • Added hooks for Alfred fallback searches (for example if you load Alfred and just enter an address without invoking the workflow)
  • Added multi-machine configuration parameters and provided a default catchall feature for this
  • Added contact address handler functionality (to enable the workflow to serve as a Contact Address Handler hook)
  • Migrated (future) work and home addresses out of keychain.
  • Added keychain cleanup function once addresses have been manually migrated to workflow environment variables
  • Implemented OneUpdater code by Vitor so updating will be simple as pie
  • Externalised Perl code for much better gitifying, as well as better code reuse
  • Added external triggers for other workflows to hook into
  • Various code cleanups
  • Significantly improved error handling to do things more gracefully
  • Rectified issues with commas in addresses causing things to break a little
  • Other minor bug fixes and improvements as I went along through the code, improved readability also

And in case you missed them - Version 1.3.0 Changes

  • dirfc: Directions from Current Address. See the installation instructions above to install Homebrew and CoreLocationCLI
  • dirtc: Directions to Current Address. See the installation instructions above to install Homebrew and CoreLocationCLI
  • dir, dirfc and dirtc now support Google transit type (walk, drive, pt [public transport] and bike)
  • dir now supports 'here'. Here anywhere in the transit plan translates to the current GPS coordinates using CoreLocationCLI. Technically this probably does away with the need for dirfc and dirtc, but, leaving them there for consistency.
  • dir now supports 'work' and 'home' as modifiers
  • Overhaul of changes to properly use Google API parameters
  • Mass code cleanup and refactoring for simplification. Most flows now leverage the dir base code.
  • Additional error handling implemented surrounding maximum number of waypoints
  • Fixed a bug where special characters would not work in stored URLs
  • Implemented a workflow environment variable for getting a local Google URL
  • Changed to use Alfred's native URL opening functionality, this enables you to select a preferred browser
Edited by stuartcryan
Link to comment

Super useful workflow.


This feature though is not working for me: All commands now support the following modifiers: walk, bike, drive, pt (public transport). The modifier can be invoked by 'dirX ' e.g. 'dirfw pt ' will give you public transport directions. This also works with 'dir' and multiple waypoints.


I have tried it in with 'dirfw pt'. 'dir to to drive', etc. but it seems the modifiers are not recognised.

Link to comment
9 hours ago, Guy Stan said:

Super useful workflow.


This feature though is not working for me: All commands now support the following modifiers: walk, bike, drive, pt (public transport). The modifier can be invoked by 'dirX ' e.g. 'dirfw pt ' will give you public transport directions. This also works with 'dir' and multiple waypoints.


I have tried it in with 'dirfw pt'. 'dir to to drive', etc. but it seems the modifiers are not recognised.

Hi Guy,

When you try 'dirfw pt DESTINATION ADDRESS' can you please open up the debugger in Alfred (look for the little bug in the top right of the workflow page) and check if there is any error output there? Also the modifiers can only be used as the first point so you have to have 'dir drive ORIGIN to DESTINATION' not 'dir ORIGIN to DESTINATION drive'.

 

It should also give you the URL that is used (if you set to all information), and I would be keen to grab the URL that it generates (you can redact the source and destination address out). Also are you using Google or Apple maps?

 

Cheers,
Stuart

Edited by stuartcryan
added extra info.
Link to comment

'dirfh pt work': so if the modifier is put first after the command dirfh (or any command) then everything works.

I just tried to type 'dirfw pt' with nothing after and that didn't work (obviously now that I think about it). If I type 'dirfw pt home' then this works.

 

Maybe it would be good to modify the example to 'dirfw pt home' (instead of 'dirfw pt') and insist that the modifier must be given directly after the command to help others not stumble upon the same thing?

 

Thank you for building such an awesome workflow and being so responsive!

Link to comment

By the way, would there be scope to include a modifier ‘fly’, which currently doesn’t seem to be in place? Maybe it is different for that one? It is just that google has a symbol for fly options in directions, so I was just wondering about this possibility. 

Edited by Guy Stan
Link to comment

 

10 hours ago, Guy Stan said:

By the way, would there be scope to include a modifier ‘fly’, which currently doesn’t seem to be in place? Maybe it is different for that one? It is just that google has a symbol for fly options in directions, so I was just wondering about this possibility. 

 

I had a look at the API reference as I didn't remember seeing that as an option. At this point in time, there is no option to force the flights as a travelmode https://developers.google.com/maps/documentation/urls/guide#directions-action

 

So, I have logged this as a feature request on my own GitHub instance to track https://github.com/stuartcryan/advanced-google-maps-alfred-workflow/issues/20, and have also taken a step further and added the feature request to Google's issue tracker https://issuetracker.google.com/u/1/issues/71937166. Starring the second and adding a comment +1 (with any other comments, on the GitHub issue) would be helpful.

 

Alas this is one that I won't be able to do until Google makes the change, and there is no guarantee, but I have tried my best.

 

10 hours ago, Guy Stan said:

'dirfh pt work': so if the modifier is put first after the command dirfh (or any command) then everything works.

I just tried to type 'dirfw pt' with nothing after and that didn't work (obviously now that I think about it). If I type 'dirfw pt home' then this works.

 

Maybe it would be good to modify the example to 'dirfw pt home' (instead of 'dirfw pt') and insist that the modifier must be given directly after the command to help others not stumble upon the same thing?

 

Thank you for building such an awesome workflow and being so responsive!

 

Duly noted and that is a good call, I will update everything now, and the info in the readme will update on the next version.

 

You are most welcome ;) Please consider a donation if you can, this one has been an EPIC EPIC EPIC amount of work and takes a lot of time even after to give support, so donations are always welcome.

Link to comment

Hi, I just configured your complex and amazing workflow. I wonder if it's possible to simply call up a map of an address, rather than always have to look up directions from one location to another?

 

I see that I can use the "maps" keyword to look up a map of an address without needing directions between two locations. I also see that the "maps" keyword may be deprecated. I'd like to see the functionality of a non-direction map be kept in the future!

Edited by paulw
learned more
Link to comment
5 hours ago, paulw said:

Hi, I just configured your complex and amazing workflow. I wonder if it's possible to simply call up a map of an address, rather than always have to look up directions from one location to another?

 

I see that I can use the "maps" keyword to look up a map of an address without needing directions between two locations. I also see that the "maps" keyword may be deprecated. I'd like to see the functionality of a non-direction map be kept in the future!

 

Howdy Paul,

Thank you for the feedback, I have often wondered if anyone got use out of this particular part of the workflow. So I will certainly take your request into account in future versions. Having just gone through two major releases in one holiday period and exhausting a LOOOOOOOT of Dev time, I don't foresee any major changes (or deprecation of anything) for some time so you are definitely safe for now.

 

Also :) Glad to hear you are happy with it, haha it is a LOOOOONG labour of love.

Stu

Link to comment
  • 1 month later...
  • 7 months later...

Hi Stuart,

 

I have just updated to OSX 10.14 Mojave, and I now notice that CoreLocationCLI doesn't work anymore (it times out after about 5 seconds.I have reinstalled CoreLocationCLI from scratch too to make sure).

 

This is not an issue with your Alfred Workflow but maybe something to consider and look into.

 

Do you know if this works for you on Mojave?

 

I have logged an issue with CoreLocationCLI. Here is the link on GitHub: https://github.com/fulldecent/corelocationcli/issues/20

 

Maybe you could also follow up on my issue to help see if a resolution can be found.

Link to comment
  • 1 year later...
  • 7 months later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...