On a regular basis I import .gpx track files that are generated in OruxMaps The files show recorded tracks and associated waypoints When the files are displayed in Locus Map Free (v 3.12.2) the manually created waypoints are displayed as small black squares Start and end waypoints are green and red circles At zoom 20 - 22 the black squares are on or very close to the track On zooming out the black squares move off the track At zoom 16 the black squares are displayed approx 50-60m north of the true position The track and the start/end waypoints remain in the correct position throughout
As a check I have imported .gpx files from other sources:
1 BaseCamp A route prepared using 'Via Points' These points also appear in Locus as small black squares that move north as I zoom out However, when the route is prepared using Blue Flag waypoints the display in Locus appears to be correct for all zoom levels
2 GraphHopper On-line route and waypoints displayed correctly for all zoom levels
Another Locus (Pro) user has replicated the above behaviour
Can someone please direct me to a relevant previous post or advise how I can overcome this problem of the shifting waypoints? I can provide a .gpx file if useful
Thanks
Hello,
file will be useful.
I'm anyway worried that problem will be in centering of icons. Maybe Orux use icons centered on center-center, where Locus use icons centered on bottom-center
menion
Here is a file Hope it is attached The Preview did not show it!
To demonstrate I go to zoom 22 place screen centre cursor on a black square then go out to zoom 16 The black square moves about 50 - 60m north Do the same for the start or finish circles and the icon stays in perfect centre of cursor
In .gpx text I see the waypoint 'type' is Starting Point and Finishing Point for the circle icons and Waypoint for the black squares
Hope you can make somethings from this
Hi
i think it´s a problem of created icon size, if i export one POI of your gpx with locus to kmz, i get a waypoint.png 24x24pix but the dot itselfe is only 5x5pix.
If you center this dot and zoom in, locus center as menion wrote to bottom center of this icon and so in such high zoomlevel "your centered dot" moves away.
(http://s7.postimg.org/ru8uzbwif/icon.jpg) (http://postimg.org/image/ru8uzbwif/)
Hello balloni55
Thanks for taking an interest in this matter This is important to me because the black dot icons give a false idea about the location of places I am trying to find sometimes in heavy forest
I have taken your lead about the created icon size and looked at that from another angle
Put the map centre (cursor) exactly on the coordinates for one of the black dot POI's (My method - tap on black dot and then follow the pop-up labels, select "Point detail" and then tap the map symbol at bottom) The black dot is shown with a clear gap to the cursor and gives the appearance of being unrelated to the POI at map centre Then zoom up and down The black dot stays fixed relative to the cursor Measurement from icon to map centre is approximately 2.5mm on screen ie about 80 pixels on my phone The 24x24 icon still would not touch the map centre at bottom of icon
Conclusion? Your idea about the icon size is right If the appropriate icon was selected then our problems would disappear The original Orux icon was an inverted tear-drop touching true location at bottom centre but in Locus this has changed to a black dot which does not touch the true POI location As noted before the start and finish circles are perfectly centred on location so it seems to be a Locus icon selection problem Is that right?
I like the use of blue or black dots for generic waypoints centred on the POI true location Is that possible to do?
Just to demonstrate a little further I have attached a .kml version of the same track This shows the POI icons with both the black dot and the Orux type tear-drop Note however that the tear-drop icons touch the true location at TOP-CENTRE (approximately)! May be there are some wider problems with icon selection/positioning
Thanks again
EDIT/CORRECTION Reference to 80 pixels above should be 40 pixels
Hello,
I think ... all is correct in Locus.
You KML file - when you look into file, there is exactly defined style of these two points:
<Style id="1">
<BalloonStyle>
<text>
<![CDATA[<p align="left"><font size="+1"><b>$[name]</b></font></p> <p align="left">$[description]</p>]]></text>
</BalloonStyle>
<IconStyle>
<Icon>
<href>http://www.oruxmaps.com/iconos/wpts_pin1.png</href>
</Icon>
<color>FFFFFFFF</color>
<colorMode>normal</colorMode>
<hotSpot x="0.5" xunits="fraction" y="1" yunits="fraction" />
</IconStyle>
<LabelStyle>
<color>FFFFFFFF</color>
</LabelStyle>
</Style>
So there is defined link to icon stored somewhere on orux's server and also "hotSpot" which define align of item compare to location coordinates.
In GPX, there is no such information. No link to image, no info about hotSpot. Only information is
<sym>Waypoint</sym>
Locus searches in internal database of symbol for one that has name "waypoint". In this case won pack with some Garmin icons. Anyway all icons attached to some points are by default centered to bottom-center (this is default option for KML files so Locus apply it on all waypoints no matter of source).
So one solution should be to remove this "symbol" references from GPX file- This cause that Locus set own correctly aligned icon to imported waypoints.
Well, another solution is on my side - mark all icons in code how they are aligned and when they are attached to any point, set them correctly. Hmm ...
EDIT: oki, this case will be fixed in next version
Hello menion
Effective analysis + clear explanation + decision to take action = normal service from Locus
Impressive Thanks for the very satisfactory outcome
Quote from: menion on November 25, 2015, 11:24:03Well, another solution is on my side - mark all icons in code how they are aligned and when they are attached to any point, set them correctly. Hmm ...
EDIT: oki, this case will be fixed in next version
May you think about handling external code in general... i.e. the stupid values of 10km/h average speed in Garmin tracks or the useless values of (Google) extensions for waypoints and a lot more. Sometimes i have a look into a downloaded track by a text editor it feels like a dump.
Better to have a strict handling: searching the appropriate tag, strip the values within the tag and delete the rest...
So you can avoid irritation of users and software.
Only an idea...
I'm not sure I perfectly understand. Any example? Or your post has nothing to do directly with icons and ti's representation in Locus, right?
Not directly. The additional values for icon position led me to this idea. You can ignore it.
Oki, I can. But I'll gladly improve some filtering if you will have again any smart idea. Currently values are not optimized during import, if you wrote about such improvement.
menion
Thanks
Ver 3.14.0 (Free) has definitely fixed the original problem When I import OruxMaps .gpx tracks the waypoint icons are now positioned correctly relative to the waypoint coordinates
Merry Christmas
Perfect, glad to hear it! Merry to You too.
Hello Menion
Some further observations on the above topic
Back on December 21 2015 I advised that the waypoint icons from Orux .gpx tracks (black dots) were now correctly positioned
I did not at that time re- check on the icons from Orux .kml tracks (balloons/inverted tear-drops) Refer my reply of 25 November 2015 I note that the balloon icons are still positioned to touch true location at top centre See screen shots All icons have exactly the same coordinates I note also that the brown "i" icon from Locus seems to move a little at high zooms
Perhaps a fix for the balloon icon can be arranged at some future date
Thanks
Hello,
I'm checking KML file once more. In KML is defined hotspot parameter for styles of icons, more about this parameter here:
https://developers.google.com/kml/documentation/kmlreference?csw=1#iconstyle
Hotspot is defined from lower left corner. This means that parameter y="1" yunits="fraction" define that top border of icon match defined coordinates. This means that icon is aligned with top border to defined coordinates of point. So correct value for "y" should be "0" in this case.
Menion
A very clear reply and thanks for the link
The problem obviously sits with the Orux .kml file definitions
Sorry for the bother