yashsingh1/xdaforums huggingface dataset:
[Touch Diamond, MDA Compact IV General] ElfKaa:
Aha - a feature :) Allright - I haven´t read anything about this new features and used only intuitively.. Then for someone who did not know like me that it hides the names it will be better to change the description of that menu to be clear to understand everytime it changes..

(Not exactly the true that I didn´t find the reason :) I was asking myself why it could behave like this and I aswered myself that maybe you will tell me this - that it hides the names.. I didn´t tried it and I didn´t named the Waypoint :) then it looks like it does nothing and that it is a bug..)

Oh and - please - tell me, how can I remove the wayipont I created? If I longpress on it there is no option to remove it or edit.

About the bug with the map:

No, I meant that if I selected the old style display (multimaps). The old 4.12 beta 10 works perfectly and this issue (slow down - nearly freeze - and also wrong displaying tiles that I discovered yet also - black tiles sometimes appears instead of map - it could have some connection with this behavior also..) will only happen on new 4.12 b11.
[Touch Diamond, MDA Compact IV General] willpom:
Beta10, map freeze, program file corruption, re-install

Hi Klaus

Haven't yet tried beta11 but I have this on beta10. Whilst out on a route GCC froze (so did phone) for what appeared to be no apparent reason. So rebooted and restarted program. Would crash if I tried to load previous file or if I started a new one but then went to map. Required the entire app to be uninstalled and reinstalled. Having seen Lukas post I checked my maps and it froze from the transition from OSM map zoom 17 to 15. I download tiles previously and store rather than on the hoof; have larger zoom in town.

Will give beta11 a go over the weekend.

Will
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello low.flying.pigs, hello Lukas,

thank you for your thorough testing.

Please test the issues with the attached beta12 again. I can not reproduce all your issues (maybe because I have solved them in advance).

I don't want to switch the project back to beta11 only to verify thas it has bugs.

Will, your freeze should be solved with beta12 (beta11).

Waypoints can be deleted by deleting the corresponding track (t2f or main track). Maybe there is a feature missing...

Regards, Klaus (just back from a few days skiing)
[Touch Diamond, MDA Compact IV General] WolWer:
Hi, Klaus! I've tested beta12 today on S3857: Map looks great, espacially letters are clearly displayed. But: There's a constant mismatch between actual position and map, which is always about 10-20m beside road. Branch advises are precise. Just looks like there's missing some kind of offset in map position??? tx & cu WolWer
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

Many thanks for 4.12beta12 and the source code. Appreciated as always.

Unfortunately, the issues introduced in 4.12beta11 with map screen displacement and display along bottom width as reported in post 2118 remain with 4.12beta12.

These issues should be readily observable with .gcc files and .gpx and .kml files created using File/Export in GCC.

As previously detailed, it is not however a consistent behaviour. For instance, some .gpx and .kml files sourced elsewhere, when loaded in GCC exhibit these issues, whilst others do not.

If required, further details and files can be provided on request.

Further information to be added.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello low.flying.pigs,

what do you mean with:

Can you please clarify and describe in other words.

Klaus
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus

Bottom of the screen, across the whole width, i.e horizontally from left to right. Detailed as quoted below from post 2118.

Further to information in post 2118 and 2121, some additional observations and results from further testing:

Issues with displacement and display along bottom width may be observable on all devices.

Observed in Windows Mobile 2003 SE, 5.0, 6.0, 6.5, and 6.5.3, and Windows CE 5.0 Emulated Environments.

Observed as screen resolutions 240x320, 240x400, 480x480, 480x640 and 480x800.

Note, issue with display along bottom width only observed in Emulators when .gcc, .gpx or .kml loaded, but occurs on device regardless. This however is inconclusive given poor frame rate of emulator hampering observations.

Other OS and screen resolutions untested. It would not however appear these are relevant factors in causation. However, along with other factors and variables, may however affect the extent to which issues are observed, particularly so with display along bottom width.

Observed when 'Draw map whilst shifting' is not selected, and also when it is selected, being inherently most easily observed when the map is at all times displayed when shifting and when initial smoothness and fluidity of map scrolling prior to 4.12beta11 was without issue.

Observed whether maps are on device memory, memory card, or downloaded.

All .gcc logs, .gpx tracks and .kml files, both created from .gcc files using File/Export within GCC, cause GCC to exhibit these issues regardless of mapping zoom level. Some .gpx and .kml files sourced elsewhere (such as gpsies.com), when loaded in GCC, cause GCC to exhibit these issues, whilst others are observed to only be misplaced at zoom level 7 or lower.

It may be the case that other .gpx and .kml files if tested may exhibit misplacement differently, but resultant from the same underlying issue. It may be the case that this varies dependent on the content of the file. It would in any event appear to be an issue with GCC introduced in 4.11beta11 and still present in 4.11beta12 as files, where applicable, work normally in 4.11beta10.

If required, further details and files can be provided on request.

Further information to be added.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] Blaustein:
Sorry Guys,

I can't reproduce your issues. On my side it all works perfect. If I load a kml file (created with GCC), there is no difference in offset between 4.12beta10 and 4.12beta12 (see screenshots). And it covers exactly the original logged track. Some displacement can happen due to inaccrurate maps and inaccurate GPS signal. Please give me exact step by step instructions to create the displaced track display.

And I don't know what should be the matter with the "whole bottom". If I beg you to tell me in other words it helps absolutely nothing when you copy your old posting. Beleive me I have read your old posting more than once. Please describe in other words and make a screenshot.

Klaus
[Touch Diamond, MDA Compact IV General] WolWer:
Funny - it's not only tracks beside instead on road, but also actual position (little blue arrow) is exactly on track, but quite reasonable (ca. 25m) beside road! Also branch advises exactly meet the real point - but map is quite a few meters off! cu - WoWe

p. s. "Bottom of the screen, across the whole width, i.e horizontally from left to right." I also don't understand l.f.s in this matter.
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

I have now had opportunity to take some screen shots as attached:

1, 2 and 3: show section of .gpx track at zoom levels 10, 11 and 12 correctly displayed in 4.12beta10

4, 5 and 6: as above, same .gpx and same maps, track however incorrectly displaced in 4.12beta12

7: shows issue with display along bottom width when present in 4.12beta12.

8: shows issue with display along bottom width when not present in 4.12beta12.

These examples demonstrate the issues, further screen shots if required can be provided. The issues introduced with 4.12beta11 which remain in 4.12beta12 are immediately apparent in ordinary usage in the normal manner when present. There are no special instructions to observe them, and they do not occur in 4.12beta10. Issues remain when .dat is removed and GCC thereby reset and all settings at default except for input/output files and map files settings.

With regards to your quoted comments above and with all due respect, you requested in post 2122 that I clarify and describe in other words "display along bottom width" which I fulfilled by return in post 2123 with "Bottom of the screen, across the whole width, i.e horizontally from left to right."

Your request gave no indication that you had read post 2118, of which "display along bottom width" was a briefly summarised description of the applicable part, hence quoting that again for clarity.

I have not anywhere used the words "whole bottom" you quote, as such words would be entirely vague, inaccurate, misleading and meaningless. A single request for clarification, which was fulfilled by return, does not ordinarily constitute begging.

It is not apparent what exactly is not understood in the actual description, which is thorough and matches screen shot 7: "map tiles, or parts thereof, that are present at the current zoom level, are not displayed at the bottom width of the map screen either immediately or at all, and instead a black or white area is shown dependent on whether White Background is selected from Menu > Options > Map Screen. When displacement is apparent, the vertical height of the section affected appears to correlate to the amount of displacement."

If required, upon clarification of what exactly is not currently understood, I can provide an alternative description to address that.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello low.flying.pigs,

I have a vague conjecture that it could depend on the setting "App maximized". Please deselect this setting and test again if the map is offset furthermore. On my devices (WM6.1) it is all ok, but WM6.5 may behave somewhat different.

Klaus
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
Hello Blaustein / Klaus,

Further to information in post 2118, 2121 and 2123, some additional observations and results from further testing:

Issues remain whether App maximized is selected or not.

Regardless of App maximized, it can be observed a factor in track displacement, in addition to zoom level, is map position as per attached screen shots 9, 10 and 11. Note how track displacement position changes when map position is moved. There may be other factors. 12 depicts the issue with display along bottom width with App maximized disabled.

Issues observed also in Windows Mobile 6.1 Emulated Environment.

There are no entries in the GpsCycleComputer.log file.

There are no exceptions shown by .NetCF Remote Performance Monitor.

An example .gpx file that allows the issues to be observed can be downloaded here.

No issues are exhibited in 4.12beta10 using the same .gpx, maps, or OpenStreetMaps on the GCC download list.

It would appear that at least in some circumstances, .gcc, .gpx and .kml files are not drawn correctly in relation to the coordinates of their points on the map screen in 4.10beta11 and 4.10beta12. To observe, load the .gpx and download OpenStreetMaps (if necessary, in GCC, enter 53.71, -0.45 as coordinates to display roughly the area in the screen shots)

Note a separate unrelated issue: 4.12beta11 amended .kml file handling compatibility. This could be amended further to enable usage of the .kml file also available for download. Other software loads the file without issue, 4.12beta12 does not.

Further information to be added.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] WolWer:
It's not displacement of tracks, but of map itself, since actual GPS position (small blue arrow) is also shown quite reasonable beside road, but exactly on track! Displacement of map is about 25m south, resp. shifting map 25m northward would show gps position and tracks correct:

Act. gps pos.: 50.955490/6.786828, pos. arrow in map (click on center) 50.955316/6.786657 in zoom level 0,2km = 1cm (320x240). Displacement decreaseses with higher zoom levels! cu - WolWer
[Touch Diamond, MDA Compact IV General] ElfKaa:
Hello Klaus,

I didn´t noticed any shift on beta 11 - didn´t yet tried beta 12..

But if I understand it well the issue did also beta 11 for others..

I didn´t made any track by planning - editing, Now I tried only record my trip and it is perfectly aligned and displayed correctly.. The only what I had noticed is the mentioned freeze while zooming if the planned trip on map screen (created by edit points inside the GPS Cycle Computer map)

I will infor you after I check the behavior for beta 12.

With regards

Lukas
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
The track drawn is inherently displaced in some circumstances as it is not in alignment with the map. It could be said the GPS current location arrow drawn on the map, in some circumstances, is also similarly displaced.

I have not anywhere stated whether it is the track displaced in relation to the map, or the map displaced in relation to the track. This is because from my own observations and testing, it is not definitively conclusive either way and could be either or a combination of both. GPS current location arrow would align with the track if both were similarly displaced. Both are subject to displacement independent of one another.

Furthermore, in so far as notifying and confirming the existence of the issue of displacement, which has now been achieved, the exact underlying cause or causes, are largely immaterial.

In my observations and testing, non of the displacement observed can be realigned with the map merely by shifting the map accordingly. The difference between the coordinates on the main screen and clicking in the apparent centre of the arrow is minimal, occurs in 4.10beta10, and has no apparent relationship to displacement far in excess of that distance. It may be that any minimal difference is due to inaccuracy in actually selecting the centre of the arrow. Thereafter any apparent relationship in that difference due to inaccuracy, to the displacement in a particular circumstance, is coincidental, hence no apparent relationship to displacement far in excess of that distance.

I do not however dispute your observations. I have stated tracks appear displaced by varying amounts dependent on the current zoom level and position of the map, that it is not a consistent behaviour, that other factors and variables may however affect the extent to which issues are observed, and that other files if tested may exhibit misplacement differently, but resultant from the same underlying issue. It may be the case that this varies dependent on the content of the file. It would in any event appear to be an issue with GCC introduced in 4.11beta11 and still present in 4.11beta12 as files, where applicable, work normally in 4.11beta10.

I look forward to your future feedback with interest, as with that of all users that take the time to positively contribute.

Further information to be added.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] ElfKaa:
Hi everyone,

can someone describe me what the shift and when it happenings?

I am recording my track by GCC and displaying with GCC with no problem, I have not noticed any arrow shift or the track shift. Do you use 1:1 display? Or do you use the old multimaps style? I am using beta 11 with no problem (even the one with track2follow displaying freeze while editing it)

Lukas

---------- Post added at 11:24 PM ---------- Previous post was at 11:06 PM ----------

Aha - do you mean the shift that is visible while you zoom out e.g. to level 9 or less? I have noticed this a lot earlier but it was not for me as big problem - but - yes - if I unzoom to e.g. level 4 I see the track in the topmost Poland near the sea even it was recorded in Czech republic :) so the shift can be maybe thousand kilometers :) But if I zoom to 5, I see the whole Czech republic in the display 240 px width and the shift is maybe about 100 km, if I zoom to level 6 the shift can be then about 20 km, but if I zoom to 9 it is nearly perfect - can be e.g about 500 m but I am using zoom starting at level 11 - there the shift is nearly invisible, on level 13 it is nearly perfect and on level 14 and more I am exactly on the road.. (so it is about 3 meters max difference). Is this what you mentioned?

Lukas
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
It would appear you are describing the same underlying issue of displacement, as observed in the circumstances of your particular observation.

Now existence of the underlying issue of displacement has been widely established and observed, it can be anticipated a forthcoming beta release / releases as required, will address and resolve it. In the interim however, unless specifically requested, it would not appear there is any further testing of this issue required at this stage.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] ElfKaa:
Alright, but GCC always did this behavior for me - every version I ever had and what I remember. But I thought that it could be caused of my maps that are not exactly aligned, I think I have noticed this maybe on version something like 4.3 ?? :) This little shift has been there always and it is not a bug of the latest GCC for sure.. But it wasn´t as strange to me as I wrote previously as it is only visible for me on very low levels. If I use level 13 or more which are useful - on these levels I can see the trip great to me.. I never noticed something like you send the screenshots here - like I was in the river with my bike :) Are you sure that this not happens with your maps only? I am using mainly OpenStreetMaps or OpenCycleMaps.. The screenshots that you created is from some other maps what I don´t have and haven´t seen before..

Lukas
[Touch Diamond, MDA Compact IV General] low.flying.pigs:
The example screen shots referred to, in post 2126, show the same .gpx track on the same map placed normally in 4.12beta10 (as per all previous versions) and displaced in 4.12beta12 (same as 4.12beta11).

Alternative maps downloaded using GCC, with the same .gpx file in use, all show the same results, the track being placed normally up to 4.12beta10 and displaced in 4.12beta11 and 4.12beta12. The screen shots from post 2126 are attached again, in addition to the OpenSteetMap mapping downloaded via GCC for ease of comparison, showing the same results. Note: the lack of fine control on the map screen, which is not ordinarily required, makes precision alignment for the purposes of these screen grabs very tedious and difficult.

Based on the aforementioned, and numerous other reasons, it can be stated with reasonable certainty displacement is not related to the actual map files in usage.

Whilst displacement observed depends on the circumstances of observation, it is however consistently reproducible when the variables are the same. As detailed previously, an example .gpx file that allows the issues to be observed can be downloaded here.

To observe, load the .gpx and download OpenStreetMaps (or any other working mapping) using GCC (or by whatever other method from a OSM tile server) (if necessary, in GCC, enter 53.71, -0.45 as coordinates to display roughly the area in the screen shots) Compare and contrast between 4.12beta10 and 4.12beta12 (ensure any existing .dat is removed (by deletion or renaming) and GCC thereby reset and all settings at default except for input/output files and map files settings as required.)

With regards to you alone it would appear having apparently observed a displacement issue prior to 4.12beta11 released 9 March 2014, potentially as long ago as 4.3 released June 2010, and in every version over the intervening approximate three and three quarter years (10 releases between 4.4 to 4.11 in addition to numerous betas, for example 4.10 had 10 betas, 4.11 had 20 betas, and 4.12 has 12 betas to date):

As a general note to all readers, kindly submit any and all issues observed, no matter the perceived importance, in a timely fashion so that they can be rectified as required for the benefit of all users.

As a specific note, the duration of observation was not before clear, in light of this now, whilst the description portrays displacement, it may or may not have the same underlying cause as that observed to occur starting with 4.12beta11. As previously stated, the characteristics vary and there may be more than one cause.

It remains the case now the underlying issue of displacement has been widely established and observed, it can be anticipated a forthcoming beta release / releases as required, will address and resolve it. In the interim however, unless specifically requested, it would not appear there is any further testing of this issue required at this stage.

Further information to be added.

low.flying.pigs
[Touch Diamond, MDA Compact IV General] Blaustein:
Hello dedicated tester,

the displacement issue was caused by the fact that osm maps in y direction are not linear dependant from latitude but nonlinear: y = arsinh(tan(lat)). In versions up to 4.12beta10 the track and the map boundaries was calculatet the same way from the lat / lon values.

Since Version beta11 I have fixed the map 1:1 to the screen pixels to have an improved map display. This made necessary many changes in program structure (some algorithms must now go the opposite way). The data flow for track display and map display go now the opposite way and there was the deviation from arsinh(tan(lat)) to linear not handled correct. At small distances there is no difference noticable, but at larger distances (many km) there was a displacement in y direction.

The .kml file from bikely.com caused an error because it additionally contains 1400 waypoints (one for each trackpoint) which lead in GCC to an array overflow which was not handled (also the waypont names was not correctly read).

Please test the attached beta13 against these issues with osm style maps and the old calibrated .jpg maps. Also test different .kml and .gpx files.

Thanks for your assistance.

Klaus
[Touch Diamond, MDA Compact IV General] WolWer:
Hi, Klaus! Displacement of map seems to be fixed, and track is on road again. Tx & cu WolWer
[Touch Diamond, MDA Compact IV General] ElfKaa:
low.flying.pigs:

The error is bad - I agree with you - description lower.., but - do you really use levels lower than 7 ??

You can try that this was always happened in GCC from whatever version I ever had.. Try e.g. 4.3 or 3.8 version or whatever the most old you could find.. I don´t see this like too much big problem - but if Klaus could really fix this - alright - but if not - nevermind - I think this zoom outs to see the whole world on the small screen is useless. On level 6 I see the whole Czech republic with also the whole slovakia on screen 400px of width and the shift is nearly invisible (could be 10 km at maximum)..

---------

Hello Klaus,

I can confirm that the map is now perfectly aligned to the track upto level 6. So I think it is mainly fixed, even it is not perfect yet for someone who would like to use this lowest levels 1 upto 6.

The crash on level 23 I can also confirm..

It also causing the shift of the track and blank screen (to me it is completely black (also there appear a text "no map" in the right corner) before crashing while next time pressing zoom/unzoom buttons..

Thanks

Lukas
[Touch Diamond, MDA Compact IV General] willpom:
low.flying.pigs, out of interest how did you get OS tiles?
[Touch Diamond, MDA Compact IV General] WolWer:
GCC on S3867

Acoustic branch advises operate fine on S3867 - at the time no prob with beta13! Tx & cu WolWer

p. s.: What's about user definable info-bar in map view?
[Touch Diamond, MDA Compact IV General] WolWer:
l.f.p described his method to get maps suitable for GCC in post 2053. Also refer to GPS Cycle Computer.htm, chapter 10. cu - WolWer