Shouldn't both options --gmapi and --nsis imply --tdbfile?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Shouldn't both options --gmapi and --nsis imply --tdbfile?

Gerd Petermann
In the German forum (1) a newbe stumbled over this problem.
He started to create his map using options --gmapi and --index and finally also wanted a gmapsupp.img, too.  So he added option --gmapsupp .
Now, with this combination mkgmap doesn't create the mdx file. One has to specify --tdbfile to get this back again, which is really not intuitive.
I think both options --gmapi and --nsis shoud imply --tdbfile, or maybe better, we should simply create the index for the requested output files
when --index is given.

I never understood why adding option --gmapsupp suppresses the creation of the pc index file(s). Is it really only because the current implementation
requires more memory?

(1) https://forum.openstreetmap.org/viewtopic.php?pid=736898#p736898

Gerd

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

Greg Troxel-2
Gerd Petermann <[hidden email]> writes:

> I never understood why adding option --gmapsupp suppresses the
> creation of the pc index file(s). Is it really only because the
> current implementation requires more memory?

I don't understand either, and it feels like a bug.

I have long been in favor of having the defaults make the map that a
user of a reasonably modern device (oregon, etrex 30, etc.) would want,
if they understood the options.  It seems like index/route should be on
by default, and there can be --no-index for devices where that causes
trouble.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

EthnicFood IsGreat
In reply to this post by Gerd Petermann
>
> Message: 1
> Date: Sun, 03 Feb 2019 09:15:33 -0500
> From: Greg Troxel <[hidden email]>
> To: Gerd Petermann <[hidden email]>
> Cc: "[hidden email]" <[hidden email]>
> Subject: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis
> imply --tdbfile?
>
>
> Gerd Petermann <[hidden email]> writes:
>
>> I never understood why adding option --gmapsupp suppresses the
>> creation of the pc index file(s). Is it really only because the
>> current implementation requires more memory?
> I don't understand either, and it feels like a bug.
>
> I have long been in favor of having the defaults make the map that a
> user of a reasonably modern device (oregon, etrex 30, etc.) would want,
> if they understood the options.  It seems like index/route should be on
> by default, and there can be --no-index for devices where that causes
> trouble.
>
>
>
> ------------------------------
>
>
+1

Mark


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

Ticker Berkin
Hi

I think it is reasonable that mkgmap, when explicitly being used to
generate GMAPSUPP.IMG doesn't generate PC files unless other options
imply that a PC image is also wanted - it does take extra time and a
lot of memory. Options --gmapi or --tdbfile imply PC files are wanted
and should cause generation of PC indexes if --index is on.

My thoughts on the default values of options:

When new features are introduced, they should be OFF by default -
experts who follow the development can turn them on if they want to
experiment. A while later, when the feature has settled down and is
thought to be generally good, the default should be changed to ON.

Some candidates for now being ON by default

--gmapsupp
--index
--location-autofill=is_in,nearest
--route
--add-pois-to-area
--link-pois-to-ways
--process-exits
--process-destination
--remove-ovm-work-files

maybe also --check_roundabout*, but I'm not sure of the default values
for these and the help text doesn't say

About now would be the time for changing:
--add-boundary-nodes-at-admin-boundaries= from 0 to 2

Regards
Ticker

On Mon, 2019-02-04 at 18:12 -0500, EthnicFood IsGreat wrote:

> >
> > Message: 1
> > Date: Sun, 03 Feb 2019 09:15:33 -0500
> > From: Greg Troxel <[hidden email]>
> > To: Gerd Petermann <[hidden email]>
> > Cc: "[hidden email]" <
> > [hidden email]>
> > Subject: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis
> > imply --tdbfile?
> >
> >
> > Gerd Petermann <[hidden email]> writes:
> >
> > > I never understood why adding option --gmapsupp suppresses the
> > > creation of the pc index file(s). Is it really only because the
> > > current implementation requires more memory?
> > I don't understand either, and it feels like a bug.
> >
> > I have long been in favor of having the defaults make the map that
> > a
> > user of a reasonably modern device (oregon, etrex 30, etc.) would
> > want,
> > if they understood the options.  It seems like index/route should
> > be on
> > by default, and there can be --no-index for devices where that
> > causes
> > trouble.
> >
> >
> >
> > ------------------------------
> >
> >
> +1
>
> Mark
>
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

Gerd Petermann
Hi all,

I still don't dare to change the option handling in mkgmap completely. My understanding is that we have two groups of users:
- One large group uses mkgmap since long and has all kinds of scripts which expect exactly the current behaviour.
Thus I consider backward compatibility very important.
- One small group (the newbies) try to create a map on their own and those are lost with all the options needed to get a good map.
I think those users would also not profit if we suddenly change all kinds of defaults because they will find even more confusing hints and
howtos.

Maybe there is someone who volunteers to create a small beginners guide?
A very simple one woud be this:
Recommended options to create a map for car routing with full address search:
--gmapi --gmapsupp --nsis --index --split-name-index --bounds=bounds.zip --housenumbers  --route --check-roundabouts --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits

Just reading Tickers comment it seems that we created almost the same list here, but I would not recommend to use --remove-ovm-work-files.
In fact I thought about removing this option as it is likely to cause trouble when you try to compile the map in multiple steps.

The default for --add-boundary-nodes-at-admin-boundaries is (and was) 2 since the merge into trunk.

Gerd


________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 5. Februar 2019 09:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?

Hi

I think it is reasonable that mkgmap, when explicitly being used to
generate GMAPSUPP.IMG doesn't generate PC files unless other options
imply that a PC image is also wanted - it does take extra time and a
lot of memory. Options --gmapi or --tdbfile imply PC files are wanted
and should cause generation of PC indexes if --index is on.

My thoughts on the default values of options:

When new features are introduced, they should be OFF by default -
experts who follow the development can turn them on if they want to
experiment. A while later, when the feature has settled down and is
thought to be generally good, the default should be changed to ON.

Some candidates for now being ON by default

--gmapsupp
--index
--location-autofill=is_in,nearest
--route
--add-pois-to-area
--link-pois-to-ways
--process-exits
--process-destination
--remove-ovm-work-files

maybe also --check_roundabout*, but I'm not sure of the default values
for these and the help text doesn't say

About now would be the time for changing:
--add-boundary-nodes-at-admin-boundaries= from 0 to 2

Regards
Ticker

On Mon, 2019-02-04 at 18:12 -0500, EthnicFood IsGreat wrote:

> >
> > Message: 1
> > Date: Sun, 03 Feb 2019 09:15:33 -0500
> > From: Greg Troxel <[hidden email]>
> > To: Gerd Petermann <[hidden email]>
> > Cc: "[hidden email]" <
> > [hidden email]>
> > Subject: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis
> >     imply   --tdbfile?
> >
> >
> > Gerd Petermann <[hidden email]> writes:
> >
> > > I never understood why adding option --gmapsupp suppresses the
> > > creation of the pc index file(s). Is it really only because the
> > > current implementation requires more memory?
> > I don't understand either, and it feels like a bug.
> >
> > I have long been in favor of having the defaults make the map that
> > a
> > user of a reasonably modern device (oregon, etrex 30, etc.) would
> > want,
> > if they understood the options.  It seems like index/route should
> > be on
> > by default, and there can be --no-index for devices where that
> > causes
> > trouble.
> >
> >
> >
> > ------------------------------
> >
> >
> +1
>
> Mark
>
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

popej
Hi,

I'm against changing defaults for existing options.

I'm in the first group of users, I have scripts with options. A change
of defaults would probably require to change options in my scripts. I'm
afraid I wouldn't catch changes in mkgmap and in many cases I would get
a faulty map without knowing the reason.

For example, I never use --process-destination --process-exits in
scripts, I don't want these features in my maps and I'm not even sure,
if my styles support correctly these options.

I rather suggest to prepare an example of config file, which would
contain recommended options for default style. It could be dedicated to
second group of users.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

Joris Bo
In reply to this post by Gerd Petermann
Hello

I was a newbie two years ago or so.. It took me a lot and a lot of time to fall in all the gaps and holes and try to understand.
I,m  still reading the options manual trying to find out what polygon-size-limits really mean.

The internet does help but I think only for techies knowing what all the words mean in the first place.
I first started with mapuploader but also that one tries to expose all the options to the user making it very difficult.
As soon as you find out where all the options are good for you also don;t need the interface anymore

For that reason I created an excel sheet user interface with some one trick buttons creating cmd scripts to be executed.
I'm not fan of the VBA excel as a generic distributable thing, don't worry, but the concept is clear:
Download geofabrik region sea and bounds if not already exists and kick the map with default style which ends up with mymap-setup.exe and gmapsupp.img and runs the silent  installer immediately.

To keep the cmd-scripts of the older generation intact for backword compatibility, maybe these are some options:
        mkgmap-simple.jar --http://geofabrik/europe/luxembourg-latest.osm.pbf
        or mkgmap.jar --default --http://geofabrik/europe/luxembourg-latest.osm.pbf
        or mkgmap.cmd or mkgmap.ps1  doing the same (one for linux, mac and windows)

Maybe this can help newbies

Gr Joris


-----Oorspronkelijk bericht-----
Van: mkgmap-dev <[hidden email]> Namens Gerd Petermann
Verzonden: dinsdag 5 februari 2019 10:13
Aan: Development list for mkgmap <[hidden email]>
Onderwerp: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?

Hi all,

I still don't dare to change the option handling in mkgmap completely. My understanding is that we have two groups of users:
- One large group uses mkgmap since long and has all kinds of scripts which expect exactly the current behaviour.
Thus I consider backward compatibility very important.
- One small group (the newbies) try to create a map on their own and those are lost with all the options needed to get a good map.
I think those users would also not profit if we suddenly change all kinds of defaults because they will find even more confusing hints and howtos.

Maybe there is someone who volunteers to create a small beginners guide?
A very simple one woud be this:
Recommended options to create a map for car routing with full address search:
--gmapi --gmapsupp --nsis --index --split-name-index --bounds=bounds.zip --housenumbers  --route --check-roundabouts --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits

Just reading Tickers comment it seems that we created almost the same list here, but I would not recommend to use --remove-ovm-work-files.
In fact I thought about removing this option as it is likely to cause trouble when you try to compile the map in multiple steps.

The default for --add-boundary-nodes-at-admin-boundaries is (and was) 2 since the merge into trunk.

Gerd


________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 5. Februar 2019 09:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis imply --tdbfile?

Hi

I think it is reasonable that mkgmap, when explicitly being used to generate GMAPSUPP.IMG doesn't generate PC files unless other options imply that a PC image is also wanted - it does take extra time and a lot of memory. Options --gmapi or --tdbfile imply PC files are wanted and should cause generation of PC indexes if --index is on.

My thoughts on the default values of options:

When new features are introduced, they should be OFF by default - experts who follow the development can turn them on if they want to experiment. A while later, when the feature has settled down and is thought to be generally good, the default should be changed to ON.

Some candidates for now being ON by default

--gmapsupp
--index
--location-autofill=is_in,nearest
--route
--add-pois-to-area
--link-pois-to-ways
--process-exits
--process-destination
--remove-ovm-work-files

maybe also --check_roundabout*, but I'm not sure of the default values for these and the help text doesn't say

About now would be the time for changing:
--add-boundary-nodes-at-admin-boundaries= from 0 to 2

Regards
Ticker

On Mon, 2019-02-04 at 18:12 -0500, EthnicFood IsGreat wrote:

> >
> > Message: 1
> > Date: Sun, 03 Feb 2019 09:15:33 -0500
> > From: Greg Troxel <[hidden email]>
> > To: Gerd Petermann <[hidden email]>
> > Cc: "[hidden email]" <
> > [hidden email]>
> > Subject: Re: [mkgmap-dev] Shouldn't both options --gmapi and --nsis
> >     imply   --tdbfile?
> >
> >
> > Gerd Petermann <[hidden email]> writes:
> >
> > > I never understood why adding option --gmapsupp suppresses the
> > > creation of the pc index file(s). Is it really only because the
> > > current implementation requires more memory?
> > I don't understand either, and it feels like a bug.
> >
> > I have long been in favor of having the defaults make the map that a
> > user of a reasonably modern device (oregon, etrex 30, etc.) would
> > want, if they understood the options.  It seems like index/route
> > should be on by default, and there can be --no-index for devices
> > where that causes trouble.
> >
> >
> >
> > ------------------------------
> >
> >
> +1
>
> Mark
>
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Shouldn't both options --gmapi and --nsis imply --tdbfile?

Mike Baggaley
In reply to this post by Gerd Petermann
>I still don't dare to change the option handling in mkgmap completely. My
understanding is that we have two groups of users:
>- One large group uses mkgmap since long and has all kinds of scripts which
expect exactly the current behaviour.
>Thus I consider backward compatibility very important.
>- One small group (the newbies) try to create a map on their own and those
are lost with all the options needed to get a good map.
>I think those users would also not profit if we suddenly change all kinds
of defaults because they will find even more confusing >hints and howtos.

I don't agree with that at all. I am a long standing user who uses scripts
and options files to build my map, but still think we should be aiming to
improve the user interface which is pretty hostile to new users. Adding new
functionality without rationalising any of the existing interface generally
makes it even more complicated for newbies. All that is needed is that
changes need to be staged such they are backward compatible for a time with
a clear statement that a certain option is deprecated and is due be
removed/changed, then later this is followed up with another statement and
the actual removal. Changing my script to use a new or changed option takes
a matter of moments. Changing of defaults can be handled in a similar way.
Initially send out a note saying the default will change, indicating that
any scripts may need to explicitly specify the option. If a user has got to
the stage where he has developed a script to generate their map, then they
must know what they are doing, and it will not take much effort to tweak the
script when an occasional user interface change comes along. I don't think
there is any suggestion that there will be so many changes to the interface
that it would become painful, and the occasional change seems to me a very
small price to pay for improving the usability for new users.

Regards,
Mike

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev