logo separator

[mkgmap-dev] Sample basic mkgmap config file

From Gerd Petermann gpetermann_muenchen at hotmail.com on Tue Feb 19 18:21:21 GMT 2019

What you describe would be an error in my understanding. Can you still reproduce it?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Dienstag, 19. Februar 2019 19:06
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file

Hi Gerd

I experimented with --road-name-config=../roadNameConfig.txt just after
it was committed to trunk a few months ago, using my old eTrex Legend
HCx. Nothing strange in my style.

roadNameConfig.txt included:

# english
#no prefix1:en = "East ", "North ", "South ", "West "
suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive",
"Gardens", " Gate", " Grove", " Lane", " Mews", " Parade", " Park",
"Passage", " Place", " Rise", " Road", " Square", " Street", "Terrace",
" View", " Walk", " Way", " Yard"
...
lang:GBR = en

Around where I live there are  "Xx Road", "Xx Avenue", "Xx Close", "Xx
Mews" and "Xx Way"

Doing Find > Address, I select the "Region" (=country), enter the
"City" and, into the "Street" field, enter "X" and it shows the list of
matching streets, just "Xx". Then entering a "Number" (or clearing the
Number field to show all addresses in the street) it shows, in a single
list, all the matching addresses in Xx Road, Avenue, Close, Mews and
Way.

It is much quicker and I consider it more natural, to select the
particular Street in the "Street" stage (from the small, presented list
of 5 in this case) and then be shown the matching addresses in just
this street.

Does this make sense?

Ticker


On Tue, 2019-02-19 at 17:26 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand what you mean with
> "Removing all the common suffixes (road/street/etc) to the second
> stage
> of address searching just makes finding an address awkward and
> unnatural. It is normal to select the full street in 1 stage then the
> locations within the street in the next stage."
> Is that something that you do in your style?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 19. Februar 2019 12:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
>
> Hi Gerd
>
> --split-name-index and --road-name-config behave as expected, but:
>
> UK roads are always indexed by their first word, even when the word
> is
> 'The'.
>
> Removing all the common suffixes (road/street/etc) to the second
> stage
> of address searching just makes finding an address awkward and
> unnatural. It is normal to select the full street in 1 stage then the
> locations within the street in the next stage.
>
> My opinion is that using --order-by-decreasing-area and then, if you
> have a typ-file, setting all [_drawOrder] to the same value, gives a
> good map, whereas attempting to pre-define which polygons overwrite
> others using [_drawOrder] will be wrong in some cases.
>
> Ticker
>
> On Thu, 2019-02-14 at 17:35 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > thanks for the  comments.
> > - I forgot route, that was not intended.
> > - no-tdbfile and nsis are a bad combination, and I see no problem
> > when we generate all possible formats
> > unless one starts to create really large maps.
> > - I am not aware of problems with --split-name-index or --road-name
> > -config, please give examples in a new thread. Besides that
> > I see no problems to remove those.
> > - I agree that --add-pois-to-lines is a rather problematic option,
> > but I see no need to add no-add-pois-to-lines
> > - My understanding is that we don't need order-by-decreasing-area
> > once we have a default typ?
> >
> > Gerd
> >
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Donnerstag, 14. Februar 2019 18:19
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
> >
> > Hi
> >
> > I have a few suggestions / comments:
> >
> > I don't agree with --recommended because this file will often
> > required
> > some tweaking and eventually become the basis of the new users
> > building
> > environment.
> >
> > I think forward slash (/) works as a directory seperator on
> > DOS/Windows
> > so can always use this.
> >
> > It should be written to assume various items are in the current
> > directory, including the .cfg file itself, the outputs from
> > splitter,
> > bounds.zip, sea.zip and mkgmap release subdirectory
> >
> > It should be aimed at generating a GMAPSUPP.IMG file to put on a
> > Garmin
> > device. All the PC bits for basecamp/mapsource are a distraction
> > and
> > a
> > great deal of time can be wasted trying to get these installed on a
> > PC
> > and then trying to use them install the map image on a device; so
> > shouldn't have 'gmapi' and should have 'no-tdbfile'
> >
> > Should specify: code-page=1252
> >
> > I'm not convinced of the general benefits of 'split-name-index' and
> > 'road-name-config'. They don't give good behaviour for the UK
> >
> > The 'bounds' option to location-autofill doesn't do anything
> >
> > No need to specify the style - it will use 'default'
> >
> > name-tag-list=name:XX,int_name,name,place_name,loc_name is a useful
> > option where XX is the map user's language code
> >
> > Should specify: route
> >
> > I don't think 'check-roundabouts' is of any benefit for a new user
> >
> > Option 'add-pois-to-lines' generates a lot of 'not very useful'
> > POIs
> > and I think it is better turned off. This is a topic that could be
> > re
> > -visited in 'default style improvements'
> >
> > 'make-opposite-cycleways' is wrong for a lot of countries
> >
> > I'd specify: 'order-by-decreasing-area' as the way to get a map
> > that
> > shows polygon features overlayed in the best order, without having
> > to
> > make fixed arbitrary decisions about all the [_drawOrder] levels in
> > a
> > typ-file.
> >
> > Following, inline, is a version with some changes - feel free to
> > take/ignore whatever you think is best. It should probably be more
> > heavily commented.
> >
> > Regards
> > Ticker
> >
> > #
> > # Set options to create a routable map for a Garmin GPS
> > # Assumes that the files bounds.zip and sea.zip exist
> > #
> > gmapsupp
> > code-page=1252
> > no-tdbfile
> > nsis
> > index
> > #split-name-index
> > #road-name-config=mkgmap/examples/roadNameConfig.txt
> > bounds=bounds.zip
> > location-autofill=is_in,nearest
> > housenumbers
> > #name-tag-list=name:en,int_name,name,place_name,loc_name
> > max-jobs
> > route
> > drive-on=detect
> > no-add-pois-to-lines
> > add-pois-to-areas
> > precomp-sea=sea.zip
> > #make-opposite-cycleways
> > link-pois-to-ways
> > process-destination
> > process-exits
> > order-by-decreasing-area
> >
> > #that's it
> >
> > On Thu, 2019-02-14 at 14:29 +0100, Andrzej Popowski wrote:
> > > Hi Gerd,
> > >
> > > maybe treat it like default style, which is kind of build in? For
> > > example, when invoking mkgmap with an option --recommended,
> > > mkgmap
> > > could
> > > include all options from default config.
> > >
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list