Messages

[UPDATE to this first post: As can be seen from the posts below, the URL system for accessing Via Michelin map tiles have been reverse-engineered and can easily be put into a simple algorithm. The question that remains is if it would be possible to incorporate support for this (and perhaps other "non-standard" tile server systems) into Locus. That would make Locus an even more formidable tool, IMHO. A secondary question is if, otherwise, any other tool, e.g. MOBAC, could be of help to get a cache of tiles from this type of server.]

UPDATE to this first post: As can be seen from the posts below, the URL system for accessing Via Michelin map tiles have been reverse-engineered and can easily be put into a simple algorithm. The question that remains is if it would be possible to incorporate support for this (and perhaps other "non-standard" tile server systems) into Locus. That would make Locus an even more formidable tool, IMHO. A secondary question is if, otherwise, any other tool, e.g. MOBAC, could be of help to get a cache of tiles from this type of server.

Hi, could anyone say if it is possible to add Via Michelin as a map source to Locus?

//http://www.viamichelin.com/

I've added other 'third-party' map sources by hand before, but they had other 'structure' than Via Michelin, so I'm not sure if it would work.

The Via Michelin maps are excellent especially for France, their Android app is not very good though.

I just want to say that 1.4.2.2 works fine for me (logging in, downloading caches) so it is not something affecting every user.
I use Nexus 7, Android 4.1.1, Locus Pro 2.5.6.

Some added info:
Regarding #3 above, the setting of "download rest info on show" does not matter for this issue.

Also another feature request:
5. After viewing details for a cache with corrected coordinates and thereby causing the cache icon to move, recenter the map view on the new icon location. (In the current behaviour, the focus does not change, and it can be very hard to find where the "?"-icon moved.)

If there are some of these ideas that would be better directed at main Locus development, please tell me so. Also if arcao would rather like issues to be added to github, I'd be happy to do so.

Some views on and wishes for use of Geocaching4Locus/live map with "corrected coordinates" of gc.com:

I (and many other cachers that I know) solve a great number of mystery/unknown caches, and usually take a lot of time before having an opportunity to find the actual cache. I have these "solution coordinates" entered into the "corrected coordinates" system of gc.com. In all I have probably a couple of hundred unfound caches with "corrected coordinates" entered. Locus with G4L has some handling of this, but I think it could be better, or perhaps I need help in how to use it in a better way.

As it is now, I almost always use the "live map" feature of Locus + G4L, see a lot of traditional caches, unknowns, multis etc. The ones I've "solved" are in the wrong/public location, but if I select the cache and view the details, the cache icon is moved to the "corrected" location on the map. However, it seems as if as soon as the live map does an update, the cache icon is moved back to the wrong/public location.

Furthermore, the icon displayed for a "corrected" cache is the same as for a normal cache of the same type, making it impossible to see which cache icons indicate real locations, and which are "fake", without going into details view.

These are my wishes and hopes:
1. Let live map do a scan of displayed caches for "corrected coordinaes" and automatically and immediately move the cache icon to the "corrected coordinates" (automatically on cache load, or, if this would be too resource intensive, triggered by the user). (feature request?)
2. Use differentiated icons or a flag/marker on existing cache type icons to indicate a cache which has "corrected coordinates". (like c:geo handles the same case) (fix?)
3. Do not let a "live map" update revert a "corrected" cache icon back to the "public" location. (fix?)
4. Allow filtering out non-corrected unknowns/multis/etc - or rather, add an extra option to "force" (unfound) caches with corrected coordinates to be displayed regardless of cache type hide settings. (example use: "hide unknown caches, but override this for caches with corrected coordinates") (One possible issue here would be the "challenge" unknown caches, that are actually at the public coordinates, but these have as requirement to have "challenge" in the cache title, so that could be sorted out automatically too.) (feature request?)

Perhaps some of these things would work better with imported PQs instead of live mapping(?), but for me this is not a good option since I visit a lot of different areas and do not want to set up PQs all the time.

Anyone with interest in and reverse-engineering skills to produce the XML lines for Eniro maps?

Good to hear, thanks for your dedication!
I guess it will still be a trouble for those who keep the 1.5.1 version around for tiles download?

See attached file.
With this selection it now stops for me at 6450/31122 images, I think it initially stopped at 6492 or so before I tried to restart it.

Originally it halted at earlier zoom levels too:
9,25,56 images - no problems
169 images, stops at 111, then stops at 100 at every retry.
552 images, stops at 247, then stops at 200 at every retry.
2068 images, stops at 743, then stops at 700 at every retry.
5850 images, stops at 58??, then stops at 5850 at every retry.
After having tried some other ways to get to the data, mostly using path tool to "paint" the desired area in paths, without selecting too much off-shore area, it seems it can now get past the earlier stall points.

I am not sure that my theory from the first post is correct, it is just the only cause I can think of.

I seem to have stumbled upon a problem.
For Google Maps (Satellite/Hybrid tested) not all zoom levels seem to be available for all locations (I have found this specifically with off-shore ocean areas, but it is probably the case for other regions too).
When doing automated map tile downloading, it seems the downloading will stall when it reaches such a tile in such a zoom level. There seems to be no way to continue past this to get the rest of the tiles available at that zoom level.
For example, I am trying to download map tiles of an area which is a large ocean bay with some islands. If I select the whole area, the first few zoom levels will be downloaded fine, and then it will start fine but always stop on the same point in the first problem zoom level. If I try a more zoomed in level, it will start fine on that level too, but then always stop at the same point. No error message is given beyond the "check internet connection and SD card free space" (both of which have been checked of course). Restarting/continuing downloads will always stop at the same place on the problem zoom levels.
This has been tried with map screen select, area select, POI area, and path selection methods, failing in the same way. I have also tried with the OSM map, which works fine with same area and zoom levels.
If I do manual map scrolling around with the Google maps, I reach a point out in the ocean where the tiles turn grey and are marked "unknown error", I guess this is another sign of the same problem.
This greatly reduces the usability of the map tiles download tool in areas where the desired zoom levels are not available in the whole selected area.
Could this be fixed? Are there any current workarounds? (Except very time consuming detailed area selection per zoom level.)