Hi Joao 1) Have you tried NT equivalent types? ie 0x2d --> 0x10e2d 2) Use the customizable pois : 0x11500 - 115FF r Nick On 04/02/2025 20:44, Joao Almeida via mkgmap-dev wrote:
Hi Ticker, No the String does not make any difference I've tested with multiple combinations. The only thing that makes a difference is FontStyle=NoLabel or the name tag not being present in the POINT tags.
The whole thing is very frustrating...
On 4/02/2025 11:10 pm, Ticker Berkin via mkgmap-dev wrote:
Hi Joao
In the .typ file having something like:
[_point] type=0x02d subtype=0x09 String=Swimming Pool String1=0x01,Piscine String2=0x02,Schwimmbad String3=0x03,Zwembad String15=0x15,Basen String10=0x10,Piscina String5=0x05,Piscina ... [end]
StringX is just to make it unique and I generally use the language code here, but, AFIR, it doesn't matter what number. The entry without a language code defaults to 0x00. Code Zero is used if there isn't a specific entry the device language.
Worrying that it doesn't display a point in an area. You might find the --order- by.. option fixes it. If not will need to look at the order in which mkmap outputs the sections
Ticker
On Tue, 2025-02-04 at 22:37 +1100, Joao Almeida via mkgmap-dev wrote:
Not sure what you mean by adding a name with the .TYP file, can you explain a bit more?
lowest priority I mean. Everything else is more important therefore it will be displayed instead of the POINTS.
I'll try the flag you mention and test it.
On 4/02/2025 9:41 pm, Ticker Berkin via mkgmap-dev wrote:
Hi
I've no experience of this but some thoughts:
Doesn't adding a name with the .TYP file work?
When you say "lowest priority", do you mean it draws Points after Polygons and Lines and is this the order mkgmap outputs things.
--order-by-decreasing-area might help as it keeps everything in each subdivision contained, rather than letting areas 'leak' into adjacent subdivisions, so conflicting with the order of writing.
Ticker
On Tue, 2025-02-04 at 20:29 +1100, Joao Almeida via mkgmap-dev wrote:
Hi,
I've been trying to work with the rendering issues with the garmin Tread since I got mine a couple of years ago. I have a Tread SxS edition. And moved from a Montana 700i and before than from the old Montana. In those devices my maps were perfect, what I rendered in basecamp rendered pretty much the same way in the devices.
With the Tread that is not the case at all!
Here are some of my findings so far.
Many of the DEFAULT mkgmap POINT codes and previous Garmin POINT codes are not rendered by the Tread. Do not confuse POI's with POINTS, POINTS are embedded map points like amenities, locations and other points. POIs are added by the user these normaly are gpx Items or orverlay layers. For this purpose I'm referring to POINTS.
I tested what POINTS were being rendered by the Tread device with the mkgmap test-map... Then I applied my TYP to the test map and managed to find what POINTS were rendered or not.
HERE are my findings: For the Tread to render a POINT IT CANNOT BE defined as FontStyle=NoLabel.
ALSO the POI itself has to have a NAME defined (data from OSM) or added via the Style. As an example I added this to my style: amenity = toilets { addlabel 'TOILETS' }
[0x2200 resolution 24] #tread DEFAULT ICON
Also. The render of POINTS seems to depend massively on the rendering of the layers IE: Poligons and Lines. I've observed that the POINTS seem to have the lowest possible rendering priority compared to the other elements.
Hope it helps...
Let me know if you find a way to display a POINT without a label or a name...
Cheers Joao
On 11/12/2024 2:15 am, Ticker Berkin wrote:
Hi Scott
I'd suggest looking at what sort of details and labelling the devices show with their Garmin map, and then, as Nick/osm@pins suggests, find a tool to extract and format the TYP subfile and see what it defines.
The chance of mkgmap being reworked to generate the next generation container format is low. The chance of this providing functionally that will support addition point types, label formatting changes or feature selection based on devices is unknown, but, I'd suggest, also very low.
Ticker
On Mon, 2024-12-09 at 08:42 -0800, scott taggart wrote: > M, > Thanks for you input. I will dig deeper into mkgmap > source code. > For what it's worth, I'd love to see some feedback from > anyone in > the > OSM/mkgmap community regarding the XT2 and Tread devices and > whether > OSM- >> mkgmap generated maps are working properly (specifically text >> labels). >> I'm > curious if there will have to be some re-working of mkgmap to > accommodate > these devices. > Scott
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s
_______________________________________________ mkgmap-dev mailing list -- mkgmap-dev@lists.mkgmap.org.uk To unsubscribe send an email to mkgmap-dev-leave@lists.mkgmap.org.uk %(web_page_url)slistinfo/%(_internal_name)s