Messages

Thanks

Yep. That's it. The gzip encoding. Accept-Encoding:none (yea, i know it is invalid, but locus rejects a blank value, and the server still returns the tiles, but without the gzip encoding) makes it work.

Please fix ;-)

Just did a bit more testing, indeed, this isn't a png. I've loaded providers.xml below, with 2 'maps', one with the original server, but the actual tile hardcoded, so locus should fill the entire screen with just one tile. The other one is the very same png from the very same tile, placed on my own host. Guess what, the real one fills the screen with "not exists" the fake one with the actual tile!!! I took a quick look at the traffic capture on both, both hosts return the file, there are no errors. The only difference i immediately spot is the gzip encoding used by the 'real' server, something i do not know how to enable on my fake one, but i'll probably find out later in order to try & reproduce. I may also try putting a blank "Accept-Encoding" as an extra header on the real thing, too (i wonder if locus will actually accept that).

Code Select Expand

<?xml version="1.0" encoding="UTF-8"?>
<providers>

<provider id="12345" type="0" visible="true" background="-1">
<name>Test</name>
<mode>real</mode>
<area>Test</area>
<url><![CDATA[http://amudanan.co.il/services/ajax.php?actions=gettile&z=14&y=6622&x=9792&type=png&showpublicpoints=false&shvilim=true&copyrighted=true]]></url>
<zoomPart>{z}-8</zoomPart>
<zoomMin>16</zoomMin>
<zoomMax>23</zoomMax>
<tileSize>256</tileSize>
<extraHeader><![CDATA[Referer#http://amudanan.co.il/]]></extraHeader>
<extraHeader><![CDATA[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1]]></extraHeader>
</provider>
<provider id="12346" type="0" visible="true" background="-1">
<name>Test</name>
<mode>fake</mode>
<area>Test</area>
<url><![CDATA[http://inf.homeip.net/tmp/test.png]]></url>
<zoomPart>{z}-8</zoomPart>
<zoomMin>16</zoomMin>
<zoomMax>23</zoomMax>
<tileSize>256</tileSize>
<extraHeader><![CDATA[Referer#http://inf.homeip.net]]></extraHeader>
<extraHeader><![CDATA[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1]]></extraHeader>
</provider>

</providers>

The problem is that every png from this server is displayed as "not exists", both fully transparent (as in your second link) and normal ones, with tracks (as in your first link). I don't know what so special about those pngs, but ill likely put a few of those on my own server, feed those into locus, and try finding out. Ill report as  soon as i know anything new.

I'll send you the mobac reference i've made for... mmm... let's call it a "personal use", privately, by email. Those are 2 "beanshell" map sources for the base and the tracks and the xml that layers them on top of each other. I see no reason why shouldn't the same layers combination eventually work with locus ;-)

EDIT/PS: email sent (to: locus (@t) asamm.com)

Those empty transparent images ARE ok. It is supposed to be a trails overlay, a lot of tiles are empty transparent images. Locus shows ALL the tiles as "Not exists", though.

Hi. I am trying to use the following custom online map source in an attempt to use it as an overlay on top of another map, yet trying to view it in a "standalone" mode for the sake of testing:

Code Select Expand

<provider id="10191" type="0" visible="true" background="-1">
    <name>Amudanan</name>
    <mode>Tracks</mode>
    <area>Israel</area>
    <url><![CDATA[http://amudanan.co.il/services/ajax.php?actions=gettile&z={z}&y={y}&x={x}&type=png&showpublicpoints=false&shvilim=true&copyrighted=true]]></url>
    <zoomPart>{z}-8</zoomPart>
    <zoomMin>16</zoomMin>
    <zoomMax>23</zoomMax>
    <tileSize>256</tileSize>
    <attribution><![CDATA[<a href="http://mapi.gov.il/">Terms of use</a>]]></attribution>
    <extraHeader><![CDATA[Referer#http://amudanan.co.il/]]></extraHeader>
    <extraHeader><![CDATA[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1]]></extraHeader>
</provider>

Locus attempts to load the map, yet shows all the tiles as "Not exists". Being 100% sure the params in the xml above are correct (tested using custom mobac map source), i've recorded a pcap of the locus network communication. Seems like Locus is receiving the tiles after all. See https://dl.dropbox.com/u/32489520/amuda ... tered.pcap for an example of one such tile being fetched by Locus. I've copied the data from pcap and un-gz-ed it, this is, indeed, a blank, transparent png file. Obviously, not all of them are blank, but this sample one is.

Any idea what's wrong?

Np,  thanks in advance for fixing

I know it did work for me before, and i have no idea when did it go broken, but it totally seems like the GPS auto off function + track recording service no longer work together for me. I've set the intervals to 0 meters, 0 seconds in the recording options, max. accuracy to 100 meters, GPS update interval in the GPS auto off to 15 seconds (yes, i know this is too fast, but it's good for testing), min accuracy there to 50 meters, max search time to 20 seconds (it is long enough, i've got the AGPS data updated). Starting the recording inside the main app works, the GPS locks very quickly, then the GPS goes off, and keeps turning on every 15 seconds, as expected, but... closing the main app, leaving just the service running, causes it to no longer turn the GPS on, ever.

NOTE: This is unrelated to power management, it still happens, even if i force the screen to stay on all the time.

search for MAPC2MAPC
or look at
 forum.asamm.cz/viewtopic.php?f=15&t=899

10x, i took a look at it. TBH, it's not nearly as convenient as the new Locus calibration or as Maprika. To calibrate using an external reference, you have to display the map inside that external reference, saving the points file in there, and only calibrate using the saved points inside this program after. Nowhere near the way Locus is now offering, really.

Also, the GUI of this app looks like something a person seeing winforms for the first time in his/her life would do. Ah, and the site looks like a first time encounter with html either. In fact, i wouldn't care if it was am open source or at least a free app, but the guy is asking quite some money for it, putting nasty red crosses over the map if you don't register (making the app useless). And yes, i know i can probably simply replace the whatever resource/file this cross is stored in with blank, that's not the point.

PS: Thanks anyway

Well, i didn't do any extensive testing, nor i had any practical use of it yes (such as actually using a picture of a map on a hike or something), but in general, it looks working really well, well, except for the out of mem crashes. BTW, the GUI, with an ability to use an existing map for the calibration of the new one, is a really nice idea, especially considering the existing map can be a fully offline vector map :-)

Something i have to add - having it in KMZ format, readable by google earth, is another bonus point here.

PS: Speaking about calibration using another map as a reference, are there any PC based tools that can calibrate using the same approach and output in the SQL db format ? (It's not a feature request, just a question if anyone knows any).

But as I can see on you ... user will just try to load into locus everything that is possible

Especially when trying to crash the app on purpose, knowing it tends to crash on heap allocs here and there, lol

I managed to crash the new test version despite the checks

What i did is calibrated a map pic, already having another one stored and calibrated before and then started choosing them multiple times inside the item manager. Eventually - i've got a crash.

Info-zip's "zip", the old good command line pkzip, rar (that can do zip files too and got command line version) and whats not.

Cyanogen ROMs have an interesting setting... it allows the user to set the VM heap size, the max is 48mbytes. I admit, i've seen this setting before, but didn't touch it, thinking "the apps are coded with the limited heap size in mind anyway, what's the point of touching it", i guess now i know better, lol.

EDIT: well, Locus still crashes miserably on this huge (5184x4623) file, but i guess i just demand too much from it, lol.