AlpineQuest & OfflineMaps

First off, I love the new feature which allows you to download a square area of map tiles, it is really great! That said the file sizes for google satelite images can get pretty huge. I do a lot of hiking based off gpx tracks that I download from various sources online(and then import into AlpineQuest to follow, and I would like to recommend the following:

1. download map tiles within some variable distance of a gpx track (or other). Would work something like this: user taps on open track in Alpinequest. Taps on new option in menu (that is already there) "store area within...". New dialog comes up. User specifies some distance (100m, 500m), and then all of the tiles within that range are downloaded.

2. this probably exists, but have an audible alarm that goes off if you stray more than X distance from a gps track. Would be similar to above in implementation. click on existing track, existing menu comes up with new option for "off trail warning" which opens a dialog for how far off the existing track you are.

Hi and thanks for the feedback.
The ability of storing maps along a path is a good idea and would be nice to have. Right now, there are many planned features waiting, so I can't give you an availability date, but I'll definitely try to add it. I've just added this feature in the wanted list, so I keep it in mind.

Concerning 2), this feature is already available, have a look at the Location Tracker: http://www.alpinequest.net/en/help/1.4/ ... h_warnings.

Best regards

I second this request. It would be a huge timesaver for users to define a path, and have the ability to save X levels deep of maps within some distance of the path. This would also ease the load on tileservers since people would then have the option to download exactly what they need, rather than large ranges out of convenience. Furthermore, this represents an important improvement for those who either have slow network speeds or have limited or expensive data plans.

Thanks

Hi,
I completely agree. I already had a look at this feature and it's not so easy to do, so I never found the time yet. Right now I'm very busy with the major 2.0 update, but I'll try to work on this just after. Don't hesitate to ask for an update then.
Best regards

Thanks for your reply. I was thinking since the code already exists to determine which tiles lie within a drawn region (which of course is rectangular, currently), then it might be worth considering that a path could be temporarily defined (for purposes of the path-download code) as a set of regions that are expanded from the path itself according to the distance the user specifies, or heck, just default to two tile-widths on either side of this meta-region. That would be wonderful for me.

In any event, I'm quite pleased with your program and look forward to fun features in new releases. Thanks

I would like to have this feature too, but things are not as simple... Imagine a "path" made with just two locations (for instance, the start location over Paris, and the final location over Berlin). How many expended regions do you need? How to compute them in the middle of the path? etc. I've some ideas, but it need some work.
But I'll definitely try to work on it again...

Right, it's an interesting problem, one hopefully left to built-in functions. I googled and found a javascript example. I know javascript is different than Google APIs and Java, but it may illustrate an approach you could adapt. The link:

http://stackoverflow.com/questions/3390 ... percentage

and possibly one using a Google API:

http://stackoverflow.com/questions/7676 ... her-points

The javascript (first) example simply feeds a percentage of the straight-line route and the starting and ending lat/lon coords into the function, and out comes the third point.

The second example may do exactly what you want, but given that I'm not skilled at evaluating its fitness for purpose, please have a look.

If you assume a straight line between user-defined points on the path (since that's how it works anyway), and since you already know how far it is from point A to point B, then you can determine how many tiles it will take to cover that distance. I don't know if you use 0,0 as your reference point or the center of the tile, but either way I think it would be a useful starting point for grabbing tiles.

As for the perpendicular distance out from the line and its relationship with tile width, which I believe is what you're getting at with expanded regions, I personally would be satisfied with not using distance at all, and instead defaulting to X tile widths on either side of the line. You must already have routines to determine if duplicate tiles are being requested, and you skip those. Here, break the line into N points based on the zoom level the user is at (why calculate when there are only 19 anyway... just use a lookup table) and what the user specifies (e.g., could be viewing at zoom = 5 and specifies to gather tiles at zoom 1~7). Using the lat/lon calculation function (I hope java has something similar you could use), then you use those points as your tile download center points.

Sorry it's a bit unstructured but I hope this may prove helpful.

i've considered this some more and realize that although it's a complex problem, but one that can be solved. to use your example of a two-point path between paris and berlin, it seems useful to consider the line between those two points as composed of a number of points that lie between those two endpoints. the number of subdivisions depends on the level of detail the user requests in the standard dialog box.

converting the endpoints' values into UTM allows you to do the calculations on the line that establish the locations of the points that lie on the line. calculate sufficient numbers of those points to establish the center points of rectangles that define the tiles you request from the server. the final input is a user-specified radius (keep in settings, perhaps), which defines the extent of tiles to retrieve, as they deviate from the center of the line whose coordinates you've just calculated.

you already have an effective routine that determines which tiles to get in a user-defined rectangle and which are already in the index, and i suspect that code could be mostly reused to avoid multiple downloading once you build your dataset of points and tiles to request. i would happily put up with calculation overhead if it meant saving minutes or hours of unnecessary downloads.

any thoughts? thank you

hi. a few additional thoughts. i consulted a family member who is knowledgeable about transforms and dilation, and he suggests that the signed distance transform (SDT) would be very efficient in terms of processing time to handle what is being discussed above. see: https://en.wikipedia.org/wiki/Distance_transform and also see the french version, which has a formula in it. a scholarly article on the topic appears here: http://www.ensta.fr/~manzaner/Download/ ... era_04.pdf. its aim appears to be centered around medical imaging, but the techniques apply in either case. given that the utmost in accuracy is not needed here, the CDA 3x3 matrix would be quite enough so long as the region it calculates covers the path, then we're good. it comes in at about twice as fast as the CDA 7x7 and three times as fast as the dead reckoning 7x7, both of which offer more accurate region construction, but needlessly so.

Hi again and thanks for this additional information.
I'll have a look at all that soon and let you know.
Thanks a lot

hi. glad to help. hopefully it does move us closer to this very useful functionality. any further thoughts on the approach? have you tried out anything as a quick test? the .pdf is a bit dense for me, and the approach i first suggested, consisting of breaking the path into line segments and using the user radius to define centerpoints of several groups of tiles, should also work, though probably less elegantly as the more refined algorithm.

also to clarify an earlier point i suggested which concerned reusing your existing code that avoids reloading maps already in one's database, i was thinking that you could dynamically build an empty pointer list of tiles, which then allows you to avoid downloading the tiles multiple times. you'd just check the list, and if it's there, ignore and move on to the next dilation-predicted tile. iterate until that set is checked and then move on to the next set. when all sets are checked, then execute on the download list.

thanks

i would also like to vote for the ability to select a map area to download based on tracks/waypoints and a distance around them (and a zoom level). this is my top feature request by far. i know that the competing app, Gaia, has a "download maps for track" feature similar to this, but i think it has a hard-coded distance from the track that is downloaded.

the problem is that downloading satellite type maps at a high enough zoom level to be useful is nearly impossible due to file size. this, in turn, is a result of needing to select a giant rectangle to encompass all the areas i may visit on a trip.

if i could simply select several tracks and/or waypoints and download map tiles "within X distance" from these landmarks, then i could get high zoom levels of only the areas that truly interest me. this would reduce the file size required by a HUGE amount, and reduce load on the map source servers a significantly as well!

Another thing to think about - now that we have OSRM routing, would it be possible to download based on the OSRM route?

Yes it should be working with any tracks no matter how it has been created.

any progress on this? i hope the algorithms i linked to provided you with some ideas on how to implement this. i would welcome this function even if it's slow or has limited options. the time it would save, over manually dragging along a path, would be immense and well worth the time it takes to execute. i suspect in reality that nearly any code would execute so fast that the maps would be queued up, waiting for the server.

another option for this, would simply be allowing a user-defined polygon to be the download region, rather than the standard rectangle.

a further option would be to execute simulated travel along the path. a "play" button, essentially.

thanks