Open Bushmills opened 5 years ago
vshcherb
commented
5 years ago We are working on our api which is pretty big already https://github.com/osmandapp/osmand-api-demo (check documentation here)
I've found old post https://www.reddit.com/r/tasker/comments/50zgsp/help_osmand_api/
Bushmills
commented
5 years ago I hoped for some "native" support for an already existing ecosystem of programs, plugins and extensions - but I suppose it should be quite feasable to load a plugin into OsmAnd which offers Locale API towards automation apps, and translates calls to OsmAnd API (which, to my knowledge, isn't supported by anything other than OsmAnd itself and the API demo program yet)
vshcherb
commented
5 years ago We are working on including more and more API. OsmAnd API is used by many apps including 3rd party which I can't name and OsmAnd Telegram for example. Anyway we don't have API yet to change some settings and we will be gradually introducing them
flamingm0e
commented
5 years ago We are working on our api which is pretty big already https://github.com/osmandapp/osmand-api-demo (check documentation here)
I've found old post https://www.reddit.com/r/tasker/comments/50zgsp/help_osmand_api/
For those of us that are idiots, is there any documentation on how to call the API from Automate or Tasker? Inputting these manually into the phone is time consuming just to test every possible combination.
Also called "automation support", these allow sort of remote controlling features of OsmAnd through automation apps like Locale, Tasker, Automagic etc. through the Local API, and make those apps respond to OsmAnd triggered events (Tasker event API). Both APIs support passing data through named variables.
Some OsmAnd features which could be accessed from an automation app are: Map selection, zoom, jump to position, follow, mark waypoint, start/stop track recording, publish current position, day/night mode.
Examples of events to pass to the automation app: navigation started, waypoint reached, destination reached, navigation direction (message), GPS lost/found.
Neither list is comprehensive or complete, many more functions are useful to have.
Purposes of supporting such interface: Additional means of controlling aspects of OsmAnd operation become easy to add, without modification of OsmAnd code, not even installing a different version. For example, a speech driven interface, mapping functions to bluetooth controllers, more finegrained or accurate control of map zooming by velocity, automatically starting track recording when exiting a defined geofence (and finish recording when entering the same or another), addition of a "spool" mechanism for sending location updates when connection is temporarily down, trigger "keep screen on" when moving, use display timeout when not moving etc.
As many of those features which are often only interesting to a small subset of users can then be added according need, these interfaces may also be helpful to keep the wishlist smaller, and the code base leaner. Furthermore, level of individuality in configuring OsmAnd is extended considerably, making it in many cases unnecessary to decide on usefulness of features from majority view.
Consider also that some of those automation apps (Automagic) comes with a built-in scripting language, which can be used to control those OsmAnd features programmatically on the fly, without the need to add comparable facilities to OsmAnd.
My own motivation of suggesting addition of such an interface is that I hope to be able to reduce needed manual interaction with OsmAnd while driving, but have things happen on an event driven base, me just watching it happen. But I've been called "lazy" before :)