logo separator

[mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10

From Dave Swarthout daveswarthout at gmail.com on Fri Jun 5 00:52:04 BST 2020

Those were my suggestions based on my rather limited experience. I knew
there are options for the java environment that require a single hyphen
(ex: -Xmx4000m -jar), and then there is the configuration file parameter
(which I forgot) but I ignored those for the sake of simplicity.

I think given what you just said, the need for a comprehensive help guide
is essential. Otherwise these sorts of questions and the amount of time it
takes to sort out the answers will only increase as the program grows more
complicated.

Also, if your 3rd point is true it only adds more confusion to the debate "
3) The typ file can appear anywhere but it is a good idea to place it at
the end"

How can it be "a good idea" to place the filespec for the TYP file at the
end if it is also true that  it "can appear anywhere"? The two assertions
appear to be in conflict in my reading of that statement

Dave

On Thu, Jun 4, 2020 at 10:34 PM Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Dave,
>
> sorry, but your suggestion would be very wrong, esp. this one:
> "These parameters must be preceded by a double dash (two hyphens with no
> spaces between them) which are immediately followed by a command string.
> Each such parameter must be terminated with a comma with no space before or
> after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)"
>
> 1) For historic reasons, some parameters require only one dash, e.g. -c or
> -n.
> 2) Only some parameters expect a comma separated option list, and since
> r4517 a "dangling" comma in those lists should provoke an error message.
> 3) The typ file can appear anywhere but it is a good idea to place it at
> the end
>
> The option handling is very difficult to understand, esp. as mkgmap offers
> so many different ways to do it. There is no way to document it in a few
> short sentences.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Dave Swarthout <daveswarthout at gmail.com>
> Gesendet: Donnerstag, 4. Juni 2020 17:05
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
>
> Pitney wrote:
> "The issue with options and order (of precedence?) still confuses me after
> using mkgmap for years."
>
> I reckon that was my point in opening this topic all along. I think I've
> got it now and it makes sense but the documentation could still be made
> clearer IMO. For example:
>
> Invoking the mkgmap java program involves supplying a list of parameters
> or commands that allow the user to control the operation of the program and
> the output generated by it.
>
> These parameters must be preceded by a double dash (two hyphens with no
> spaces between them) which are immediately followed by a command string.
> Each such parameter must be terminated with a comma with no space before or
> after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)
>
> All input file specifications (filename.ext) must follow the last option
> in the invocation string. You may use a full path for that filespec as long
> as it is enclosed in quotes. (Windows/Dos example:
> "C:\Users\username\Downloads\Maps\MyState.osm")
>
> Any type file specification (filename.typ) containing custom bitmaps for
> Garmin lines, polygons and points must be the last file specification in
> the list of input files.
>
> Etc.
>
> Thanks also to Gerd for the latest releases which addressed the spurious
> space issue and improved the program's error reporting. I'm sure these will
> go a long way toward smoother operations for those of us who are only
> casual users of mkgmap.
>
> Dave
>
> On Thu, Jun 4, 2020 at 9:12 PM Pitney <mappitney at gmail.com<mailto:
> mappitney at gmail.com>> wrote:
> Hello
> The issue with options and order (of precedence?) still confuses me after
> using mkgmap for years. My solution is to not use option files and to hard
> code all file references. Not good scripting practice but it works.
> I think this is a case of where examples are worth a thousand words. I
> understand in theory option and file order but do not know how to implement
> it in practice. Examples (in a separate file?) and how to work out which
> files they will effect may reduce confusion.
> I only have a tablet in quarantine so I apologize for any formatting
> issues.
> Pitney
>
> On June 4, 2020, at 2:11 AM, mkgmap-dev-request at lists.mkgmap.org.uk
> <mailto:mkgmap-dev-request at lists.mkgmap.org.uk> wrote:
>
> Send mkgmap-dev mailing list submissions to
>         mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> or, via email, send a message with subject or body 'help' to
>         mkgmap-dev-request at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-request at lists.mkgmap.org.uk>
>
> You can reach the person managing the list at
>         mkgmap-dev-owner at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-owner at lists.mkgmap.org.uk>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mkgmap-dev digest..."
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200605/b22468bb/attachment.html>


More information about the mkgmap-dev mailing list