[APP] - version 2.19.X+ (updated 17.3.2014)

[Raddino]

@menion
Cache is stored in folder. Folder was created by locus pro. If i open cache styx, it didn't show all attributes ( see screenshot)

Then if i update cache via addon, FP's are still invisible.

[Menion]

ah that's the problem with attributes, Locus do not break next attributes on new line. Perfect, thanks

problem with favorite points is weird. Anyway today I did a new way how to refresh whole screen after update so hope it will solve also this problem

[KaHeMu]

@Raddino: I'm unable to simulate issue with attributes and also missing favorite points. Are you updating over G4L and also caches stored in folder or some temporary?

@gynta: thanks for the video. I'm aware of this problem with multi-line texts. Unfortunately I use one small library for these lists, so I'll rather wait till author fix it, then waste of time on it by myself.

@balloni: nice list, thanks

1) I really hate long-clicks. You never know this possibility is there or not, so I do not want to use it. Anyway your point is clear, so I'll try to improve it in any way

2) hmm you're right. So button "Add attachment" also in this "edit" mode? Maybe yes

3) I'll really rather create some poll to check what most users think

In which manner you will do this?

4) current behaviour is exactly same as in old screen. Anyway I rewrote whole list of waypoints. Functionality remain same, it just looks more clear now, I hope ...

Like functionality in points or tracks list you have to select items and do things with 3-point-button. This is the way we normally expect in similar situations.

6) what means "don't work"? For me it works nice. After tap on "Update cacheL in bottom menu (Geoaching4Locus), cache screen udpate itself and immediately show changes. What happen to you?

For me it doesn't work, too, means nothing happens.

Edit: Sorry, after button 'actualize cache' (or similar) message 'actualize cache' pops up. But no feature in cache description and no logs are updated.

7) thanks, I know, fixed

you mean if you use "Offlinizer", so the one big image of tree do not fit to screen? I think it's a correct. Because imagine you should have there one big image and one small, then you will zoom in, to see that small one. And smaller images are more common then big I think

In former versions you could zoom out up to image fits.

[balloni55]

Hello menion,
thanks for your detailed answer

1) I really hate long-clicks. You never know this possibility is there or not, so I do not want to use it. Anyway your point is clear, so I'll try to improve it in any way

and i hate needles clicks waiting for your improvement

3. perfect, start a poll
for example: 1=Attachement, 2=Basic Info, 3=Listing, 4=Images, 5=Waypoints, 6=Logs, 7=Trackables
in configfile
default settings are          1/2/3/4/5/6/7
my modified settings are  2/3/5/4/6/7/1

4 1/2. for me it is also a needless click on button if no additional information exist, similar in cachelisting "hint" is only visible if a hint exist.

6. ok, update cache works, but i have to close the cache and reopen it to see the updated loggs.

7. it is different to pro, in pro you are able to scale down till srolling only in one axis is necessary, see attached screencast (first test, second pro)
https://www.dropbox.com/s/c6ewuldutjl6qme/video_3.mp4

[Menion]

@KaHeMu:
ad 4) yes I know, but here it's little bit more complicated. You are IN points screen and all buttons are related to current point. Anyway as I wrote, I rewrote screen with waypoint to new system, I want later apply also on screen with Points/Tracks, so we will see

ad 6) don't worry, I rewrote refresh of screen, so now it without disturbing recreate itself so all should be correctly refreshed

ad 7) below...

@balloni:

ad 7) thanks for video, it's same problem as KaHeMu wrote about. Hmm quite complicated. I changed one small parameter. It cause problems on your devices, but works better on different and opposite. Thanks anyway

[john_percy]

[off topic]

Artefacts when rendering closed ways
If a way (highway, aeroway etc) is a closed loop, and overlaps a tile boundary, spurious vertical and/or horizontal lines appear.

The first example is a road that is a loop, shown at two zooms; the second comes from a perimeter taxiway that is also a loop. This occurs in all themes.

[c.s.g.]

Hello,

using Locus Pro 2.19.1 only the first additional waypoint is imported from the attached GPX-file.
P149T72 is ok, P249T72 is missing.

c.s.g.

[stebu]

Hello,

using Locus Pro 2.19.1 only the first additional waypoint is imported from the attached GPX-file.
P149T72 is ok, P249T72 is missing.

c.s.g.

I just checked a couple of caches with 2 and 3 additional wpts, no problems here.
The attached GPX file has some errors, some of the angle brackets are still html-encoded:
&lt;p&gt;Additional Hidden Waypoints&lt;/p&gt;P149T72 - Parking&lt;br /&gt;N 47° 55.682 E 008° 30.995&lt;br /&gt;Von Mai bis in den Herbst leider gebührenpflichtig&lt;br /&gt;P249T72 - Parking&lt;br /&gt;N 47° 55.633 E 008° 30.709&lt;br /&gt;Von Mai bis in den Herbst leider gebührenpflichtig&lt;br /&gt;</groundspeak:long_description>

Code Select Expand

&lt; should be < 
and &gt; should be >

So there seems to be an error in your "process", Locus is working fine.

[gynta]

[off topic]

Artefacts when rendering closed ways

You are right.
downloading last England map from Locus store.

compare zoom 13,15,16:

[c.s.g.]

Hello stebu,

I just checked a couple of caches with 2 and 3 additional wpts, no problems here.
The attached GPX file has some errors, some of the angle brackets are still html-encoded:
&lt;p&gt;Additional Hidden Waypoints&lt;/p&gt;P149T72 - Parking&lt;br /&gt;N 47° 55.682 E 008° 30.995&lt;br /&gt;Von Mai bis in den Herbst leider gebührenpflichtig&lt;br /&gt;P249T72 - Parking&lt;br /&gt;N 47° 55.633 E 008° 30.709&lt;br /&gt;Von Mai bis in den Herbst leider gebührenpflichtig&lt;br /&gt;</groundspeak:long_description>

Code Select Expand

&lt; should be < 
and &gt; should be >

So there seems to be an error in your "process", Locus is working fine.

(1) This is an original GPX-file downloaded from geocaching.com.
(2) The additional waypoints for import into locus are not in the <groundspeak:long_description> although they are mentioned there in this listing as well. Waypoint information of that section is never imported to locus additional waypoints only to the long description .
(3) The GPX-file contains 3 <wpt> .... </wpt>  sections. The first contains the geocache information itself. the second and third the additional waypoint information of the parking area. I looks for me, that locus pro ignores the third <wpt>...</wpt> section for import.

c.s.g.

[Bucky Kid]

Thanks menion for test version. There's an inconsistence with waypoint edit finalizing. In edit mode initial layout with Ok/Cancel button is offered but after making some changes to text field (copy/pasting controls replace the global edit controls and won't revert back after losing focus of this text field) the system is changed to upper left button for upper level
however it's not changed after making changes to non-text field (eg. changing icon)
I'm preferring the initial style always (Ok/Cancel)
P.s. I see that opening new design waypoint panel takes longer. It's not dramatic delay but may eventually suxx when working with many waypoints at same time.

[stebu]

(1) This is an original GPX-file downloaded from geocaching.com.
(2) The additional waypoints for import into locus are not in the <groundspeak:long_description> although they are mentioned there in this listing as well. Waypoint information of that section is never imported to locus additional waypoints only to the long description .
(3) The GPX-file contains 3 <wpt> .... </wpt>  sections. The first contains the geocache information itself. the second and third the additional waypoint information of the parking area. I looks for me, that locus pro ignores the third <wpt>...</wpt> section for import.

Yes, I just noticed that the waypoints with invalid tags are inside the <groundspeak..> tags. And there are the real waypoints following.
This is how I have always done my waypoints for Locus without a problem.
I downloaded the GPX and got only one wpt?
I even added another cache into the GPX (three waypoints) and downloaded. Your cache 1 wpt, mine 3 wpts?
Odd

[stebu]

Missing waypoint:

Code Select Expand

  <wpt lat="47.928033" lon="8.516583">
    <time>2013-04-14T06:28:34.61</time>
    <name>P149T72</name>
    <cmt>Von Mai bis in den Herbst leider gebührenpflichtig</cmt>
    <desc>1Parking</desc>
    <url>http://www.geocaching.com/seek/wpt.aspx?WID=a68f140f-aba1-413b-9f74-33555a4c46be</url>
    <urlname>Parking</urlname>
    <sym>Parking Area</sym>
    <type>Waypoint|Parking Area</type>
  </wpt>
  <wpt lat="47.927217" lon="8.511817">
    <time>2013-04-14T06:28:34.613</time>
    <name>P249T72</name>
    <cmt>Von Mai bis in den Herbst leider gebührenpflichtig</cmt>
    <desc>2Parking</desc>
    <url>http://www.geocaching.com/seek/wpt.aspx?WID=ba2d2380-734a-464e-a2e9-b5571537505d</url>
    <urlname>Parking</urlname>
    <sym>Parking Area</sym>
    <type>Waypoint|Parking Area</type>
  </wpt>

I changed the desc field, added 1 and 2 in front of Parking and now I can see both waypoints on the map.
So definitely a Locus bug! It must not conclude that these are the same points, when description is the same.
Coords and name are different.

[Menion]

thanks c.s.g. and stebu. You are correct. Locus test waypoints by <name> tag, which is waypoints code, but also by <desc> which is used as name. But in this case, it do not make sense. So I added condition that <desc> and also coordinates have to be same, to mark waypoint as duplicate and do not import it.

@Bucky kid: thanks, I'll try to fix it

[voldapet]

[off topic]

@gynta @john_percy
this is old know limitation of mapsforge library. Map is separated into so called meta-tiles and all elements are cut on the border of mentioned meta-tiles. The issue occurs with polygons that are closed and contains new "cut" lines. Unfortunately theme is applied also on these new lines and this is the reason of wrong rendering. Basically we cannot solve it, because we don't know what the cut line is and what the normal element line is.