logo separator

[mkgmap-dev] Building display.jar fails

From Felix Hartmann extremecarver at gmail.com on Mon Dec 13 12:27:30 GMT 2021

yes I also don't see a need for the route relation name in the search - but
I do see it as a need to see the route names on tooltip for all routes that
use a way. That's why I mean I would like to add them into non searchable
labels.
Even though for certain ways - I would like them included - e.g.
Donauradweg - because quite often you would like to know where is the
nearest point of the Donauradweg or other international/famous routes - but
not for local ones.

Locally you would often say let's meet on the Donauradweg at the
intersection with X or restaurant XY on Donauradweg - not in a city like
Vienna, but in mid sized cities. Everyone knows then what is meant - and
that kinda should be searchable via address search. No-one locally knows
the actual street names (if they exist). So in case there is no street name
label, using a route name instead makes sense too.

On Mon, 13 Dec 2021 at 13:10, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> I still don't see a use case for the route names in road labels. I've
> never felt the need to find a route relation.
>
> I am pretty sure that it can produce all kinds of confusion when you
> search for an address and the result
> contains lots of unrelated stuff because there is a route relation that
> has a word in its name which starts
> with the same word.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Montag, 13. Dezember 2021 12:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> okay - well I should try to find a way to put more content into the label
> 2-4 instead of 1 then. The cutoff is still good. Some routes have very long
> names.
>
> On Mon, 13 Dec 2021 at 12:43, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Hi Felix,
>
> the labels which are shown in MapSource / Basecamp search are those which
> are stored in MDR 15.
> We change them already with the --mdr7-del option but that doesn't help
> for the names of route relations.
> mkgmap reads the full labels from the LBL file in each map tile and
> calculates the string for MDR15.
> Still, MDR15 is not used with the device, so this only effects the PC
> programs.
> Roads have 4 labels, other objects have only 1. With roads, the
> first label is rendered, other labels are shown when you click on the road.
> All labels are indexed, and the --housenumber code sometimes adds labels
> so that addresses can be found.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Montag, 13. Dezember 2021 12:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> I tried a couple of places that are cut down to 170 characters - and some
> I can find in Mapsource or Basecamp, Others I cannot. So 170 is definitely
> too much for the search index. Is there a way to have separate label for
> search vs the label on tooltip/printed out on the label? For search it
> clearly should be less (both Mapsurce and Basecamp).
> In general it would be good to have a separation between name for search
> and name for the label. I know we have 4 labels, but I haven*t really
> understood which label is for what and where which label shows up.
>
> On Mon, 13 Dec 2021 at 11:46, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>> wrote:
> Hi Felix,
>
> okay, I've committed the changes with r4836.
> It would be good to know if these long strings cause trouble in MapSource.
> I wouldn't be surprised to find that they cause buffer overflows if Garmin
> doesn't expect more than N bytes, and that again can cause all kinds of
> trouble.
> Will try to reproduce the problem with a modified default style ...
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
> Gesendet: Montag, 13. Dezember 2021 11:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> it's working fine for me too. But I haven't got around to testing if the
> length should even be shorter related to search.function. Clearly anything
> over 170 is not useful. Maybe it should be even shorter, but apart from the
> value it works well
>
> On Mon, 13 Dec 2021 at 10:28, Ticker Berkin <rwb-mkgmap at jagit.co.uk
> <mailto:rwb-mkgmap at jagit.co.uk><mailto:rwb-mkgmap at jagit.co.uk<mailto:
> rwb-mkgmap at jagit.co.uk>><mailto:rwb-mkgmap at jagit.co.uk<mailto:
> rwb-mkgmap at jagit.co.uk><mailto:rwb-mkgmap at jagit.co.uk<mailto:
> rwb-mkgmap at jagit.co.uk>>>> wrote:
> Hi Gerd
>
> I don't have any problem with it
>
> Ticker
>
> On Mon, 2021-12-13 at 09:02 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > I got no feedback on the patch label_len170.patch. Any comments?
> >
> > Gerd
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20211213/6e73ffdc/attachment-0001.html>


More information about the mkgmap-dev mailing list