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 negate any option by pre-pending it with 'no' (eg --no-route). This has the effect of turning off the option for the following files. This is not currently possible. It will also give a consistent way to turn off options that are by default active. 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, without actually removing them from the program, so as not to break existing scripts. If anyone has any thoughts on how the options could be improved now would be a good time to discuss it. 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). ..Steve
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 this is important, because not every user of mkgmap reads mkgmap-dev and knows, why the new map behave different with same parameters. If I set an old parameter or a parameter, which isn't necessary, mkgmap should print out a warning and a short explanation. E.g. Don't use --charset=cp1250, use --code-page=1250 instead. To keep all users up to date, I think it would be the best way, to have a wiki-page or direct at mkgmap-wiki-page a mkgmap-call which should be used to create a good map. Or maybe in the help-printout of mkgmap a hint, which parameter should be used in typical usecase. E.g. which layer should be used to get a well performing map. Henning
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 for my test maps. Or is mkgmap now capable of reading multiple bound statements?
Thanks, N.
Hi Steve, On Fri, Mar 25, 2011 at 01:17:22PM +0000, 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 too high resolution for Garmin, such as when someone draws a 1-metre line for highway=steps,step_count=5. Marko
On 25.03.2011 18:22, Marko Mäkelä wrote:
Hi Steve,
On Fri, Mar 25, 2011 at 01:17:22PM +0000, 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 too high resolution for Garmin, such as when someone draws a 1-metre line for highway=steps,step_count=5.
I think Steve meant that remove-short-arcs is always set when route is used. Cause anything else is plain stupid. If map is routable, then remove-short-arcs HAS to be used, else in many places routing get's broken.
-----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, without actually removing them from the program, so as not to break existing scripts.
If anyone has any thoughts on how the options could be improved now would be a good time to discuss it.
..Steve _______________________________________________
As a user, I would rather see a warning that the option is deprecated and will be removed in a future version. In this application, that future version might be reported by a date 6, 9, or 12 months from now. This will give all developers enough time to make sure that all new/modified options are working as they should, and give downstream providers, gmapsupp creators, and other administrators of tools that depend on mkgmap ample notice that the application will be substantially changing. Additionally, if there is a flurry of activity on the users maillist about arguments being deprecated, it may warrant rethinking on a particular configuration option or better documentation of the replaced option. - -- Jeff Harris. OASAASLLS http://barbershopbass.com/public.key 2006 Barbershopper of the Year, AHSOW Fremont-Hayward Chapter Alumnus Random Baritone Guy, Palo Alto-Mountain View Chapter www.barbershop-harmony.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNjOPyAAoJELq82vdIW8cwr38H/1kFu/YiVVv2RsywOsdtEAAN 2iD/VujYjqnysHcX7LmX673YxQbNpWpS6QPEztd/m+d3oQI9iLpaOziCdnJLGYsI X/QYb3Xa2T7zxxSGCWXa0yo9Vd6JuXtk19ahbMkvGq0PfBG3Z1p3Brw+0PLXq/rS HmXsvXsY7CBDGIctzAi9ZB0N/3N8vwQL3N91LyOZYvVwy0w48Ns4QvQ3iacAqJlF vYMCB3ApqrYf2bjnoxNvUh62XUVDxSpUekyiHBvWagU4wNLK12bQrGQF/LwIFsJV z79QcNFXe2Xb7SS5vm5eZ9Sib+HLnhN+EYBM7gYes/Ja7dGPLNyPDRbEOPSbST8= =taMi -----END PGP SIGNATURE-----
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. Some pages of the osm-wiki should also rewritten or removed. Either the documentation is up to date or we should throw it away.
The first couple of things I plan to do in preparation are:
1. Make it possible to negate any option by pre-pending it with 'no' (eg --no-route). This has the effect of turning off the option for the following files. This is not currently possible. It will also give a consistent way to turn off options that are by default active.
Good idea although I think it does not make sense for all options. What about options that are not boolean?
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, without actually removing them from the program, so as not to break existing scripts.
That's a kind of option deprecation. I am not a big supporter for keeping old options for a very long time. If an option does not make good sense and has no function just remove it. If anyone wants to stick on this old option one can use older mkgmap releases. The help file should differ between "normal" options that are useful for any mkgmap user (route, index, family-name, family-id etc.), "advanced" options for higher requirements (max-jobs, drive-on-left, check-roundabouts, ignore-maxspeeds etc) and "developer" options that need a somehow deep knowledge of mkgmap (block-size, preserve-element-order, max-flare-length-ratio, keep-going etc.).
If anyone has any thoughts on how the options could be improved now would be a good time to discuss it.
The generate sea option has a kind of its own option system. I would prefer to break that and use single options. generate-sea=multipolygon,close-gap=3000,floodblocker => sea-generation=multipolygon sea-close-gap=3000 sea-floodblocker What about the report-XXX options? Shouldn't this be configured in the log.properties of the logging system? What about dropping the support for .csv files? The help file points out that support will be dropped. I vote for this. Keep mkgmap slight.
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).
If we want to use the option file in the styles then the mkgmap deploy should not pack the style files into the jar file. Put all classes into the jar file but the styles (and some other resources?) should be deployed easily changeable as flat files.
..Steve
WanMil
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 plan to do in preparation are:
1. Make it possible to negate any option by pre-pending it with 'no' (eg --no-route). This has the effect of turning off the option for the following files. This is not currently possible. It will also give a consistent way to turn off options that are by default active.
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, without actually removing them from the program, so as not to break existing scripts.
If anyone has any thoughts on how the options could be improved now would be a good time to discuss it.
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).
..Steve
You may want to remove --net and build it in to --route. Another idea is to have "super options", which combine various sub-options, e.g. --make-routeable, which implies --route, --net, --remove-short-arcs, --adjust-turn-headings or --debug-OSM-left, which implies --drive-on-left, --check-roundabouts, --check-roundabout-flares, --report-dead-ends, --max-flare-length-ratio=5 or --optimise, which implies --reduce-point-density-polygon=4, --merge-lines, --reduce-point-density=5.4 etc
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-short-arcs is that it is not optional. If it is not given then routing will break and you get streams of 'error' messages that are of no help to anyone, since the map data is perfectly fine. To create a correct routing network mkgmap has to deal with short arcs in the network. The --ignore-osm-bounds option was only ever a work around for mkgmap not dealing with files containing several bounds as produced by josm. This option is not harmless; if used with several tiles produced by splitter it will destroy inter-tile routing. And yet there are several places on the web that demonstrate exactly that problem [1] Another example: --no-sorted-roads, this is documented as making mkgmap run faster, but as far as I know it never did (there was some completely different reason for why mkgmap was running slow at the time this option was introduced). The downside of the option is that it produces a broken map where any kind of searching for roads is likely to fail. Again it is not optional; the roads have to be sorted, and even if it did take longer, that is just the price that would have to be paid to create a working map. A quick search shows that people are actually using this option and so producing broken maps. ..Steve [1] Eg, just to pick the first one I found (there are many more) http://acrosscanadatrails.posterous.com/making-routable-mapsource-maps
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 be fixed very easily.
The problem with --remove-short-arcs is that it is not optional. If it is not given then routing will break and you get streams of 'error' messages that are of no help to anyone, since the map data is perfectly fine. To create a correct routing network mkgmap has to deal with short arcs in the network.
The --ignore-osm-bounds option was only ever a work around for mkgmap not dealing with files containing several bounds as produced by josm. This option is not harmless; if used with several tiles produced by splitter it will destroy inter-tile routing. And yet there are several places on the web that demonstrate exactly that problem [1]
Another example: --no-sorted-roads, this is documented as making mkgmap run faster, but as far as I know it never did (there was some completely different reason for why mkgmap was running slow at the time this option was introduced). The downside of the option is that it produces a broken map where any kind of searching for roads is likely to fail. Again it is not optional; the roads have to be sorted, and even if it did take longer, that is just the price that would have to be paid to create a working map.
A quick search shows that people are actually using this option and so producing broken maps.
..Steve
[1] Eg, just to pick the first one I found (there are many more) http://acrosscanadatrails.posterous.com/making-routable-mapsource-maps --road-name-pois was also introduced as a workaround before we have address search working and so candidate to be deprecated, but I still find it useful as it speeds up searches. For example, if I want to find a street called Avenida de la Libertad via address search I have to type the complete name (after selecting country and city) whereas via spell menu typing Libertad is enough to show a list where I can select the desired one. 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?
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 to work around some bug that is fixed or could be fixed very easily.
The problem with --remove-short-arcs is that it is not optional. If it is not given then routing will break and you get streams of 'error' messages that are of no help to anyone, since the map data is perfectly fine. To create a correct routing network mkgmap has to deal with short arcs in the network.
The --ignore-osm-bounds option was only ever a work around for mkgmap not dealing with files containing several bounds as produced by josm. This option is not harmless; if used with several tiles produced by splitter it will destroy inter-tile routing. And yet there are several places on the web that demonstrate exactly that problem [1]
Another example: --no-sorted-roads, this is documented as making mkgmap run faster, but as far as I know it never did (there was some completely different reason for why mkgmap was running slow at the time this option was introduced). The downside of the option is that it produces a broken map where any kind of searching for roads is likely to fail. Again it is not optional; the roads have to be sorted, and even if it did take longer, that is just the price that would have to be paid to create a working map.
A quick search shows that people are actually using this option and so producing broken maps.
..Steve
[1] Eg, just to pick the first one I found (there are many more) http://acrosscanadatrails.posterous.com/making-routable-mapsource-maps --road-name-pois was also introduced as a workaround before we have address search working and so candidate to be deprecated, but I still find it useful as it speeds up searches. For example, if I want to find a street called Avenida de la Libertad via address search I have to type the complete name (after selecting country and city) whereas via spell menu typing Libertad is enough to show a list where I can select the desired one. 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?
And is another candidate that really should be sent into the desert. I get at least 5 people a week complaining search for POI with my maps is broken, because they use another map produced with --road-name-pois which completly havocs the POI search on older generation GPS. I'm really pissed of about the road-name-pois command because it produces maps that may even crash GPS and gives the image of mkgmap producing faulty maps -- or said differently -- because of this option in many forums I read comments as take care when using OSM maps on your GPS, as they may break it (no other mkgmap bug currently is able to crash your GPS, other than for example not using --remove-short-arcs when --route is given, which may also crash your GPS) Try out a city navigator map to sea what is possible with address search. In principle you only need to enter/exit the housenumber field, then entering a streetname (with autocompletion for name which does not exist on POI search) and results will be listed. There is no need to enter country/city except to filter down results (valid for Mapsource/Basecamp/Vista HCx/Nuvi 255W)
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 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-short-arcs is that it is not optional. If it is not given then routing will break and you get streams of 'error' messages that are of no help to anyone, since the map data is perfectly fine. To create a correct routing network mkgmap has to deal with short arcs in the network.
The --ignore-osm-bounds option was only ever a work around for mkgmap not dealing with files containing several bounds as produced by josm. This option is not harmless; if used with several tiles produced by splitter it will destroy inter-tile routing. And yet there are several places on the web that demonstrate exactly that problem [1]
Another example: --no-sorted-roads, this is documented as making mkgmap run faster, but as far as I know it never did (there was some completely different reason for why mkgmap was running slow at the time this option was introduced). The downside of the option is that it produces a broken map where any kind of searching for roads is likely to fail. Again it is not optional; the roads have to be sorted, and even if it did take longer, that is just the price that would have to be paid to create a working map.
A quick search shows that people are actually using this option and so producing broken maps.
..Steve
[1] Eg, just to pick the first one I found (there are many more) http://acrosscanadatrails.posterous.com/making-routable-mapsource-maps
--road-name-pois was also introduced as a workaround before we have address search working and so candidate to be deprecated, but I still find it useful as it speeds up searches. For example, if I want to find a street called Avenida de la Libertad via address search I have to type the complete name (after selecting country and city) whereas via spell menu typing Libertad is enough to show a list where I can select the desired one. 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? _______________________________________________
And is another candidate that really should be sent into the desert. I get at least 5 people a week complaining search for POI with my maps is broken, because they use another map produced with --road-name-pois which completly havocs the POI search on older generation GPS. I'm really pissed of about the road-name-pois command because it produces maps that may even crash GPS and gives the image of mkgmap producing faulty maps -- or said differently -- because of this option in many forums I read comments as take care when using OSM maps on your GPS, as they may break it (no other mkgmap bug currently is able to crash your GPS, other than for example not using --remove-short-arcs when --route is given, which may also crash your GPS)
Try out a city navigator map to sea what is possible with address search. In principle you only need to enter/exit the housenumber field, then entering a streetname (with autocompletion for name which does not exist on POI search) and results will be listed. There is no need to enter country/city except to filter down results (valid for Mapsource/Basecamp/Vista HCx/Nuvi 255W)
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
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 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-short-arcs is that it is not optional. If it is not given then routing will break and you get streams of 'error' messages that are of no help to anyone, since the map data is perfectly fine. To create a correct routing network mkgmap has to deal with short arcs in the network.
The --ignore-osm-bounds option was only ever a work around for mkgmap not dealing with files containing several bounds as produced by josm. This option is not harmless; if used with several tiles produced by splitter it will destroy inter-tile routing. And yet there are several places on the web that demonstrate exactly that problem [1]
Another example: --no-sorted-roads, this is documented as making mkgmap run faster, but as far as I know it never did (there was some completely different reason for why mkgmap was running slow at the time this option was introduced). The downside of the option is that it produces a broken map where any kind of searching for roads is likely to fail. Again it is not optional; the roads have to be sorted, and even if it did take longer, that is just the price that would have to be paid to create a working map.
A quick search shows that people are actually using this option and so producing broken maps.
..Steve
[1] Eg, just to pick the first one I found (there are many more) http://acrosscanadatrails.posterous.com/making-routable-mapsource-maps
--road-name-pois was also introduced as a workaround before we have address search working and so candidate to be deprecated, but I still find it useful as it speeds up searches. For example, if I want to find a street called Avenida de la Libertad via address search I have to type the complete name (after selecting country and city) whereas via spell menu typing Libertad is enough to show a list where I can select the desired one. 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? _______________________________________________
And is another candidate that really should be sent into the desert. I get at least 5 people a week complaining search for POI with my maps is broken, because they use another map produced with --road-name-pois which completly havocs the POI search on older generation GPS. I'm really pissed of about the road-name-pois command because it produces maps that may even crash GPS and gives the image of mkgmap producing faulty maps -- or said differently -- because of this option in many forums I read comments as take care when using OSM maps on your GPS, as they may break it (no other mkgmap bug currently is able to crash your GPS, other than for example not using --remove-short-arcs when --route is given, which may also crash your GPS)
Try out a city navigator map to sea what is possible with address search. In principle you only need to enter/exit the housenumber field, then entering a streetname (with autocompletion for name which does not exist on POI search) and results will be listed. There is no need to enter country/city except to filter down results (valid for Mapsource/Basecamp/Vista HCx/Nuvi 255W)
I can't search with your method using City Navigator maps. On nuvi 300 I always have to enter a country->city as first steps. On the legend HCx if I enter a house number and go to street names field it I get "Nothing found". Could you give further details how you do it?
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 future. It needs just some more entries in the search index. (And maybe some bits correctly set... ;-)
participants (10)
-
Carlos Dávila -
Charlie Ferrero -
Felix Hartmann -
Henning Scholland -
Jeff Harris -
Johann Gail -
Marko Mäkelä -
Nakor -
Steve Ratcliffe -
WanMil