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-le...@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-le...@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-le...@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-le...@lists.mkgmap.org.uk
%(web_page_url)slistinfo/%(_internal_name)s
