[mkgmap-dev] Sample basic mkgmap config file

Wed Nov 13 11:12:15 GMT 2019

Hi Ticker,

I don't think that it will be of much help when we distribute a sample without any hint regarding the usage.

The attached patch shows how to change build.xml so that it copies a sample.cfg to examples directory. I think we need at least a README.html or HOWTO.html
that explains how to use it and I have no idea where to start with this.

Here is a brief description how I create a map for my bicycle tours:
1) Extract attached zip file to produce a directory map containing makemap.cmd and mkgmaps.args
2) Create a gpx file with a router like brouter http://brouter.de/brouter-web
3) Load the gpx file into JOSM and draw a polygon around it, store it as map.poly in the map directory
4) Download osm.pbf from geofabrik that covers the map.poly (typically europe-lastest.osm.pbf)
5) Modify the first rows in script makemap.cmd so that the wanted osm input file is used and map name is set
6) Execute the script (don't try it, it will only work on my PC)

If you look at the script you will find that it requires some tools and input files in exactly the right places
and there is no code to react on errors, so it may help some people but probably it will only be confusing for a newbie, esp.
one who uses Linux.

The program map-composer (1)  tries to solve this problem with a dialog, but it is only available in German.

(1) http://composer.waldpfa.de/

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, 12. November 2019 15:32
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file

Hi Gerd

It would be good if this idea was resurrected - initially just
releasing the file, as you last had it, somewhere under
trunk/resources. Then suggestions can be incorporated and mention made
of it elsewhere in the documentation.

Ticker

On Thu, 2019-02-21 at 10:50 +0000, Ticker Berkin wrote:
> Hi Gerd
>
> Sorry to hear that your're not well.
>
> It seems that the behaviour of this feature is device dependent (I
> used
> the same map on the same SD card on both my devices).
>
> Each device was consistent in its behaviour for all streets I looked
> at, regardless of street name length.
>
> I didn't like the effect of this option on the old eTrex Legend, but
> it
> was justifiable.
>
> On the new 30x it is plain misleading, picking one suffix to show on
> the street completion list then show results that include all the
> other
> suffixes.
>
> Having --split-name-index without --road-names-config would, I
> imagine,
> greatly increase the index size. And again, I don't think this option
> gives anything that a UK user would expect.
>
>
> Reading the documentation for the option, one of the reasons for it
> was
> to show just the significant part of the name at outer zoom levels
> and
> the full name as you zoom it. This doesn't happen on my devices, the
> full street name appears in one go as you zoom in.
>
> It would be interesting to know the behaviour on other devices and
> maybe all that should be done is add a bit more to the documentation.
>
> I don't think either should be enabled in the sample.cfg
>
> Best wishes
> Ticker
>
>
> On Wed, 2019-02-20 at 10:44 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I am currently sick again (influenca), so I will not do anything
> > complex during the next days. Please provide more details so that I
> > can try to reproduce this. Maybe the results depend on the device,
> > maybe it's the firmware, or maybe there is a bug. I guess you see
> > this problem also with other (longer) street names?
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Mittwoch, 20. Februar 2019 11:38
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Sample basic mkgmap config file
> >
> > Hi Gerd
> >
> > I've just built a map with --split-name-index and --road-name
> > -config
> > as
> > below, using latest trunk.
> >
> > On my old eTrex Legend, I still get the behaviour as described
> > earlier.
> > I didn't use --split-name-index before, but it seems to behave as
> > expected - all words except the suffix words are in the street list
> > and
> > can be found quickly and the result list then shows the full name.
> >
> > On my new eTrex 30x the behaviour is slightly different and worse.
> > In
> > the example from before, if I enter 'Xx' into the Street part of
> > the
> > address search, the selection list shows just "Xx Avenue". If I
> > select
> > this, the result list shows all addresses in Xx Avenue/Close/Way...
> >
> > I don't think this is relevant, but none of these streets have
> > house
> > number information and I've used option --no-housenumbers. The
> > result
> > list has 1 entry per street.
> >
> > Regards
> > Ticker
> >
> > On Tue, 2019-02-19 at 18:21 +0000, Gerd Petermann wrote:
> > > 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
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sample.patch
Type: application/octet-stream
Size: 1034 bytes
Desc: sample.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191113/d0b5ee27/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: map.zip
Type: application/x-zip-compressed
Size: 1641 bytes
Desc: map.zip
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191113/d0b5ee27/attachment-0001.bin>