nt: 04 June 2020 06:11
To: daveswarth...@gmail.com
Cc: Development list for mkgmap
Subject: Re: [mkgmap-dev] Options file
Hi Dave,
I fear we can document whatever we want, this misunderstanding happens again
and again. With the --style option it is very obvious and the user will find
out. With
e 2020 06:11
To: daveswarth...@gmail.com
Cc: Development list for mkgmap
Subject: Re: [mkgmap-dev] Options file
Hi Dave,
I fear we can document whatever we want, this misunderstanding happens again
and again. With the --style option it is very obvious and the user will find
out. With
other options like
and in3.osm
Normally, this only makes sense for options like --description or --mapname
which typically change with each input file.
Gerd
Von: Dave Swarthout
Gesendet: Donnerstag, 4. Juni 2020 07:52
An: Gerd Petermann
Cc: Development list for mkgmap
Betre
name' doesn't exist.
> Maybe it should be changed to "SEVERE (Main): name: input file 'name'
> doesn't exist. Was it meant as an option?" because the "filename" has no
> dot and thus no extension?
>
> Gerd
>
> ________
ant as an option?" because the "filename" has no dot and thus
no extension?
Gerd
Von: Dave Swarthout
Gesendet: Donnerstag, 4. Juni 2020 01:11
An: Gerd Petermann
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Options file
gt; by
> splitter). "
>
> Gerd
>
> ____________
> Von: Dave Swarthout
> Gesendet: Mittwoch, 3. Juni 2020 16:59
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Options file
>
> OMG! An extra
re '-c template.args' (this file is generated by
splitter). "
Gerd
Von: Dave Swarthout
Gesendet: Mittwoch, 3. Juni 2020 16:59
An: Gerd Petermann
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Options file
OMG! An extra space?
Yep,
___
> Von: mkgmap-dev im Auftrag von
> Dave Swarthout
> Gesendet: Mittwoch, 3. Juni 2020 12:33
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Options file
>
> This is a two-part question.
> Firstly:
> I have been trying to change my compilation meth
age.
Gerd
Von: mkgmap-dev im Auftrag von Dave
Swarthout
Gesendet: Mittwoch, 3. Juni 2020 12:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] Options file
This is a two-part question.
Firstly:
I have been trying to change my compilation method to use a config file but am
havin
This is a two-part question.
Firstly:
I have been trying to change my compilation method to use a config file but
am having problems. During my experimentations I managed to insert the
style file directive "--style-file=directory|zip-filename|url" _after_ the
filespec for the OSM data file. My map
Hi again,
oops, sorry, meant motorway_link, not motorway_junction:
http://www.openstreetmap.org/node/21992225
I think this node should not be ignored, right?
Gerd
From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Sun, 17 May 2015 09:40:54 +0200
Subject: [mkgmap-dev
Hi all,
the discussion with Dave
http://gis.19327.n5.nabble.com/Routing-parameters-tp5844762.html
forced me to look at the sources for these two options
--process-destination and --process-exits
I think there are a few problems in the source LinkDestinationHook.java:
I think one is a typo: It
Hello Gerd,
sorry for the delay.
"better than nothing" simply means that this is actually the only possibility,
to create Points along a way to mark a hiking trail based on relations.
In fact this is not really satiesfying but it is actually the only way. That's
the reason why i said "better tha
need no extra deletion rule.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 11:10 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter,
sorry, did not notice that the way is a polygon, but
you probably got me right anyway.
On the other hand, I still
rg.uk
Date: Sat, 25 Apr 2015 22:46:43 +0200
Subject: Re: [mkgmap-dev] Options
Hi Gerd,
a closed loop is an interesting example.
I don’t know, what mkgmap:line2poitype=mid would do here.
At the moment I would expect to get additional POIs with all 4 tags
aerialway, leisure, name, sport
If
aerialway + name.
With --add-pois-to-lines=aerialway,name
I would expect the same result like after the deletion.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 8:21 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter,
what exactly would you want to
.
The only disadvantage of the existing solution
is,
that you should not forget the delete the not
used pois,
otherwise some lines would look really
ugly.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 7:04 AM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
the existing solution is,
that you should not forget the delete the not used pois,
otherwise some lines would look really ugly.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 7:04 AM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter
Hi Walter,
I am using add-pois-to-lines to place overlay symbols on aerialways.
Since the option has no parameters, for which tag is shall be
applied,
I am simply deleting all not needed POIs with some additional lines.
leisure=* & mkgmap:line2poi=true {delete
leisure}
natural=cliff&
ay, April 24, 2015 7:35 AM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Gert,
yes, I think it must be useful, I also see it in Minkos styles at
http://www.openfietsmap.nl/
I don't fully understand the "better than nothing" part .
The current code adds
for the minimum distance between two generated POI when the way
has more than 3 points.
Gerd
From: aleu...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Thu, 23 Apr 2015 19:11:32 +0200
Subject: [mkgmap-dev] Options
Hi,
accidentally(more or less) i found the thread regarding review of mkgmap
Hi,
accidentally(more or less) i found the thread regarding review of mkgmap
options and the list on wiki
http://wiki.openstreetmap.org/wiki/Mkgmap/dev/option-review.
--add-pois-to-lines
This can be useful if you plan to add marker e.g. for waymarked trails. Ok, in
fact it's not the best s
Hi,
accidentally(more or less) i found the thread regarding review of mkgmap options and the list on wiki http://wiki.openstreetmap.org/wiki/Mkgmap/dev/option-review.
--add-pois-to-lines
This can be useful if you plan to add marker e.g. for waymarked trails. Ok, in fact it's not the bes
Subject: Re: [mkgmap-dev] Options
Hi Steve,
okay, I'll try to update the wiki first. Can't believe that it is already
more than two years old :-O
Gerd
> Date: Sun, 5 Apr 2015 20:59:58 +0100
> From: st...@parabola.me.uk
> To: mkgmap-dev@lists.mkgmap.org.uk
> Su
Hi Steve,
okay, I'll try to update the wiki first. Can't believe that it is already
more than two years old :-O
Gerd
> Date: Sun, 5 Apr 2015 20:59:58 +0100
> From: st...@parabola.me.uk
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Options
>
>
Hi Gerd
I'd like to change some defaults.
My understanding so far is that most people want
a routable map with address search and housenumber search.
So, I think the following options should be on by default:
--route
--net
--index
--housenumbers
--x-split-name-index
--link-pois-to-ways
--driv
Hi,
I don't know the code that creates the indexes that well. Can't say.
Gerd
From: anorcar...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Sun, 5 Apr 2015 12:49:58 -0300
Subject: Re: [mkgmap-dev] Options
Gerd
beyond, it would be possible to do this also for a city searc
From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Sun, 5 Apr 2015 17:39:52 +0200
Subject: Re: [mkgmap-dev] Options
Hi Carlos,
you are probably right. I've added this option to my list
because it helped with the address search when
ref
s
used for housenumbers (mkgmap:street) is also used as a label.
If all 4 possible labels are filled with other names, the last one is
overwritten.
Gerd
> Date: Sun, 5 Apr 2015 17:06:34 +0200
> From: cdavi...@orangecorreo.es
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Opt
> Date: Sun, 5 Apr 2015 17:06:34 +0200
> From: cdavi...@orangecorreo.es
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Options
>
> In general I agree with your list, but I'm not sure if
> --x-split-name-index is a g
In general I agree with your list, but I'm not sure if
--x-split-name-index is a good candidate. First, it's still an
experimental option, and second, it was said it's not that useful for
English and other languages with street type at the end of street name.
El 05/04/15 a las 16:24, Gerd Pete
Hi all,
I'd like to change some defaults.
My understanding so far is that most people want
a routable map with address search and housenumber search.
So, I think the following options should be on by default:
--route
--net
--index
--housenumbers
--x-split-name-index
--link-pois-to-ways
--dri
As I remember correct, the result was: You should use continue or
continue_with_actions instead of these cycleway-options. ;)
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all,
I think this was discussed before, but I don't remember the result.
I must confess that I don't fully understand the idea of these two options
while make-opposite-cycleways seems to make sense.
To allow bicycle traffic for a road that is NOT a oneway, why do we add an
additional
way?
T
Hi,
the code in the overview2 branch is nearly ready for trunk now, but the
configuration and documentaion
is not yet ready.
The current implementation in the overview2 branch adds these new options:
--overview-levels
like levels, specifies additional levels that are to be written to the
ove
It would be quite hard to understand, if you have a part of it in
action-rules and a part in []. So I would like to keep it in []-part.
Also I don't like special tags very much.
We'll need a maximum for road_speed, a minimum, a fix value (actual
road_speed with --ignore-maxspeed) and a default
well the current behaviour is, that road_speed=* is not set fix at all.
It is only used if maxspeed is not found. That concept is clearly
flawed. So your proposal would be to keep that concept, but change it to
a line like the following:
a) highway=motorway [0x01 road_class=4 road_speed=6 road_
Hmm...ok so you want to add eg. road_speed_max=4 and after all style
processing mkgmap should convert maxspeed=* to road_speed and take care,
that road_speed has a maximum value of 4.
I think you wont need something like road_speed=* to set it fix (actual
behaviour, I wouldn't change this)and c
On 08.12.2012 20:40, WanMil wrote:
>> --drive-on-left, --drive-on-right -- Could this be included into the
>> country abbr list we have in the resources - there are not so many
>> drive-on-left countries anyhow, so we just add them, and assume
>> drive-on-right for all other countries. Option is a
On 10.12.2012 14:43, Henning Scholland wrote:
Hi Felix
Am 10.12.2012 14:20, schrieb Felix Hartmann:
road_speed=4 === set current road_speed to 4 or lower - if maxspeed is
lower, but not higher (new behaviour)
You mean: road_speed>4 {set road_speed=4 }
No I don't mean road_sped>4 -- I actual
Hi Felix
Am 10.12.2012 14:20, schrieb Felix Hartmann:
road_speed=4 === set current road_speed to 4 or lower - if maxspeed is
lower, but not higher (new behaviour)
You mean: road_speed>4 {set road_speed=4 }
road_speed_fixed=4 == set current road_speed to 4 no matter maxspeed,
recommended spee
> What sub-options to generate-sea does everyone use? Are the defaults
> most likely to result in an un-flooded map or does it depend too much
> on which part of the world you are creating a map for?
>
> ..Steve
Hi Steve,
I'll try to go more into detail of the suboptions:
multipolygon and polygo
On 10.12.2012 13:34, Steve Ratcliffe wrote:
>
> Hi Felix
>
> Thanks for your thoughts.
>
>> --ignore-maxspeeds , Strong Objection. For a bicycle map it is really
>> needed. I don't want mkgmap messing around with maxspeeds. It's also
>> about performance, why calculate something if it's not neede
Am 10.12.2012 13:34, schrieb Steve Ratcliffe:
> Hi Felix
>
> Thanks for your thoughts.
>
>> --ignore-maxspeeds , Strong Objection. For a bicycle map it is really
>> needed. I don't want mkgmap messing around with maxspeeds. It's also
>> about performance, why calculate something if it's not needed
On 10 Dec 2012, at 15:32, Steve Ratcliffe wrote:
>
>
> What sub-options to generate-sea does everyone use? Are the defaults
> most likely to result in an un-flooded map or does it depend too much
> on which part of the world you are creating a map for?
>
> .
I use
generate-sea:polygons,exte
Am 10.12.2012 12:32, schrieb Steve Ratcliffe:
> Thanks for the explanation, If there is no option that is clearly
> superior in all cases, then there is no problem in having more than
> one, it just falls to documentation to explain which one to use in
> which case.
>
> What sub-options to generate
Hi Felix
Thanks for your thoughts.
> --ignore-maxspeeds , Strong Objection. For a bicycle map it is really
> needed. I don't want mkgmap messing around with maxspeeds. It's also
> about performance, why calculate something if it's not needed.
What do you object to?
I'll explain what I mean by
Hi WanMil
Thanks for your thoughts. I'm building up a good picture of how
many of the options are used now.
Just a couple of points.
> [ --family-id , --family-name etc ]
> Of course keep them. But it would be helpful if at least the wiki gives
> some hints where the different values are used (
Am 10.12.2012 00:40, schrieb wilpin:
> although newbies may not realise tdbs are only required by Mapsource/Bascamp
+ QLandkarteGT
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--add-pois-to-lines
I think essential to keep this option so we can display hiking route icons -
a feature not encountered in Garmin's Active Route Topos
--no-poi-address
I don't think it works but we could do with an option to prevent
benches,pylons etc to be listed when searching for a poi
On 08.12.2012 20:03, Henning Scholland wrote:
> Am 08.12.2012 19:04, schrieb Felix Hartmann:
>> --location-autofil :: If I understand right, it is still a backup if
>> bounds fail. I currently use --location-autofill=bounds,is_in,nearest
>> because I want is_in first, secon nearest to provide the
On Sat, Dec 08, Geoff Sherlock wrote:
> Here are my thoughts:
>
> -n name, --mapname=name
> --description=text
> --country-name=name
> --country-abbr=abbreviation
> --region-name=name
> --region-abbr=abbreviation
> --latin1, --code-page=number
> --levels=levels code
> --family-id
> --family-name
> --drive-on-left, --drive-on-right -- Could this be included into the
> country abbr list we have in the resources - there are not so many
> drive-on-left countries anyhow, so we just add them, and assume
> drive-on-right for all other countries. Option is a very bad idea,
> because you can't use
Am 08.12.2012 19:04, schrieb Felix Hartmann:
> --location-autofil :: If I understand right, it is still a backup if
> bounds fail. I currently use --location-autofill=bounds,is_in,nearest
> because I want is_in first, secon nearest to provide the location if the
> precompiled bounds fail. Maybe mak
Here is my take on it for changes that are different or other input
compared to the wiki:
--country-name=? --- Well I use the cities list, but actually I would
prefer this option for single country maps to take preference. I don't
think the region--name is very important, because the search fun
> Hi
>
> I've written up my thoughts on each option on the wiki at:
>
> http://wiki.openstreetmap.org/wiki/Mkgmap/dev/option-review
>
> I think there are a few obsolete/unworking options that can be removed
> straight away.
>
> I will come up with a mechanism for documenting and applying defaul
Here are my thoughts:
-n name, --mapname=name
--description=text
--country-name=name
--country-abbr=abbreviation
--region-name=name
--region-abbr=abbreviation
--latin1, --code-page=number
--levels=levels code
--family-id
--family-name
--product-id
--product-version
--series-name
--area-name
--over
Hi
> As one of the "too many" complainers, my issue was not so much that
> there were a lot of options, but that the typical new person's strategy
> of ignoring them all did not lead to success. What you're doing
> addresses that point, and also reduces unneeded options.
OK, although calling w
Am 07.12.2012 11:12, schrieb michael lohr:
> --ignore-turn-restrictions should be kept for pure walking/cycling maps,
> unless this can be achieved in the style. i never tried but something
> like type=restriction {delete type} could maybe replace it.
I think it's the better way, to move it into
Am 06.12.2012 21:18, schrieb Steve Ratcliffe:
> I think there are a few obsolete/unworking options that can be removed
> straight away.
--adjust-turn-headings
Sometimes leads to routing errrors.
Should be removed or reworked.
Chris
___
mkgmap-dev m
--ignore-turn-restrictions should be kept for pure walking/cycling maps,
unless this can be achieved in the style. i never tried but something
like type=restriction {delete type} could maybe replace it.
--add-pois-to-lines can be used for hiking path symbols
micha
Am 06.12.2012 21:18, schri
Am 07.12.2012 00:42, schrieb Greg Troxel:
--check-foo:
replace with --warnings/--nowarnings, defaulting to warnings. Put in
some output warning file, with a prefix by warning type for grep.
Don't worry about enabling/disabling them individually.
I think such warnings shouldn't be defaul
Hi Steve,
here are my thoughts about it:
--latin1 should be removed it's the same as --code-page=1252
--index default on could break map-creation on older machines, don't
know if this would be good
--createbounds keep or put it in a separate tool, maybe together with
create precompiled sea
-
Thanks for putting time into the options issue.
As one of the "too many" complainers, my issue was not so much that
there were a lot of options, but that the typical new person's strategy
of ignoring them all did not lead to success. What you're doing
addresses that point, and also reduces unne
Hi
I've written up my thoughts on each option on the wiki at:
http://wiki.openstreetmap.org/wiki/Mkgmap/dev/option-review
I think there are a few obsolete/unworking options that can be removed
straight away.
I will come up with a mechanism for documenting and applying default
to options and
Sorry for my previous message. Clicked on the wrong button.
El 29/03/11 17:48, Felix Hartmann escribió:
>
> On 29.03.2011 17:25, Carlos Dávila wrote:
>
>> El 29/03/11 16:50, Steve Ratcliffe escribió:
>>
>>> The aim is not just to remove options, but is much more about
>>> improving how it
El 29/03/11 17:48, Felix Hartmann escribió:
>
> On 29.03.2011 17:25, Carlos Dávila wrote:
>
>> El 29/03/11 16:50, Steve Ratcliffe escribió:
>>
>>> The aim is not just to remove options, but is much more about
>>> improving how it works in the default case without options, or to
>>> remove
Also, if I'm not sure whether it is called "Avenida de la
> Libertad", "Avenida la Libertad" or "Avenida Libertad", using spell menu
> is much faster. Would it be possible to get partial searches working in
> address search?
>
I know that this is technical possible and expect it to work in the near
On 29.03.2011 17:25, Carlos Dávila wrote:
> El 29/03/11 16:50, Steve Ratcliffe escribió:
>> The aim is not just to remove options, but is much more about
>> improving how it works in the default case without options, or to
>> remove the need for various options altogether that only ever existed
>
El 29/03/11 16:50, Steve Ratcliffe escribió:
> The aim is not just to remove options, but is much more about
> improving how it works in the default case without options, or to
> remove the need for various options altogether that only ever existed
> to work around some bug that is fixed or could b
The aim is not just to remove options, but is much more about
improving how it works in the default case without options, or to
remove the need for various options altogether that only ever existed
to work around some bug that is fixed or could be fixed very easily.
The problem with --remove-shor
On 25/03/2011 17:17, Steve Ratcliffe wrote:
> Hi
>
> There is a new branch for an overhaul of the options. There are a
> number of recent (and not so recent!) posts about options that are
> badly documented, have the wrong defaults or just plain shouldn't
> exist.
>
> The first couple of things I p
On 25.03.2011 18:22, Marko Mäkelä wrote:
> Hi Steve,
>
> On Fri, Mar 25, 2011 at 01:17:22PM +, Steve Ratcliffe wrote:
>> Things already on the list include: --charset, --remove-short-arcs
> I agree that --charset (and possibly --latin1) should be removed, but
> what is bad about remove-short-
> Hi
>
> There is a new branch for an overhaul of the options. There are a
> number of recent (and not so recent!) posts about options that are
> badly documented, have the wrong defaults or just plain shouldn't
> exist.
That's great! I think we should invest some time on mkgmap
documentation. So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/25/2011 06:17 AM, Steve Ratcliffe wrote:
> 2. Add a way to document old options and and give a warning that the
> option is no longer in use and what should replace it if anything.
> This will allow for options to be removed from the help list,
Hi Steve,
On Fri, Mar 25, 2011 at 01:17:22PM +, Steve Ratcliffe wrote:
>Things already on the list include: --charset, --remove-short-arcs
I agree that --charset (and possibly --latin1) should be removed, but
what is bad about remove-short-arcs? I thought that it is useful when
the map has
> Things already on the list include: --charset, --remove-short-arcs,
> --ignore-osm-bounds, setting options inside the style (which can
> already be done, its just not really used properly).
>
> .
Is there any reason to remove --ignore-osm-bounds or is there any
replacement? I use it very often
Hi
I think it would be better for the user of mkgmap, that they get with
the same used parameter the same result. Opt-in is better then opt-out.
If I set --route, map should contain routing information and if I don't
set --route, there shouldn't be any routing information in the map. I
think t
Hi
There is a new branch for an overhaul of the options. There are a
number of recent (and not so recent!) posts about options that are
badly documented, have the wrong defaults or just plain shouldn't
exist.
The first couple of things I plan to do in preparation are:
1. Make it possible to nega
Valentijn Sessink schreef:
> Like in the attached patch?
... which seems to contain a superfluous, but harmless, comment in
SubArea.java. Sorry for that.
V.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/list
Steve Ratcliffe schreef:
> Perhaps it belongs in the splitter doc then? Or the splitter
> could leave out (or comment out) the description lines
> by default, unless the --description option is given.
Like in the attached patch? (Usual disclaimers apply: I'm not a
programmer, I don't know Java, b
Steve Ratcliffe schreef:
> Perhaps it belongs in the splitter doc then? Or the splitter
> could leave out (or comment out) the description lines
> by default, unless the --description option is given.
I agree. Although then still a remark about the -c filename
"description" could be useful. (As y
Hi
> But I do understand what you are saying. Does anyone else have an
> opinion about this?
Perhaps it belongs in the splitter doc then? Or the splitter
could leave out (or comment out) the description lines
by default, unless the --description option is given.
..Steve
___
Marko Mäkelä schreef:
>> +Please note: if you use "-c template.args", then that file may
>> +contain a "description" that will override this option.
> I would say "-c filename" instead of "-c template.args", so that it will
> be possible to search for that string. And instead of "will over
Hi Valentijn,
> I agree. However, the "--description" not working gave me headaches,
> that's why I mentioned it at the --description description.
OK, I hope that it is a correct balance. Make the help text too verbose,
and people won't read it. Make it too terse, and people won't understand it
Hi all,
Marko Mäkelä schreef:
> "on on" should be "or on"
Fixed (see attachment)
>> +Please note: if you use splitter.jar to build a template.args file
>> +and use -c template.args, then that file may contain a
[...]
> I think that this is a general remark that would better be documented
Valentijn, Steve, list,
On Tue, Aug 25, 2009 at 07:42:59AM +0200, Valentijn Sessink wrote:
> This may be a better description of --description, it sort of warns for
> the description that splitter puts in the args file.
> Index: resources/help/en/options
>
Steve, list,
This may be a better description of --description, it sort of warns for
the description that splitter puts in the args file.
Best regards,
Valentijn
--
Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
Index: resources/help/en/options
===
Use this patch instead - minor typo/whitespace fixups.
Index: README
===
--- README (revision 1118)
+++ README (working copy)
@@ -32,69 +32,43 @@
there. Another way would be to use a USB memory card writer.
Another convenient way
Here's a patch that:
adds some options to the help file
improves wording in the help file
adds TODO items in the help file when I think something should be
there but don't know the answer
a bit of general cleanup in the help file
removes option description from README, pointing pe
90 matches
Mail list logo
