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 default on. They are not needed for creating a map, it's only to improve quality of osm-data or investigate problems.

Henning

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 --overview-mapname=name --overview-mapnumber=8 digit number --drive-on-left, --drive-on-right The above could all be set in the style files. In the case of family-id and product-id I would like these to override that given in the TYP file if possible as that would mean a generic TYP file could be used. But I guess the TYP file is not parsed by mkgmap so perhaps the TYP file location/name could be set here instead. Most styles have a country/region section in the points file and they can be set in there dependent on the country. Or possibly the info file, again depending on the country if that can be seen in the info style section. --copyright-message=note --license-file=file These can be set in the info style file as they rarely change anyway. I agree with most of what else you put on the web page, but I am far from expert on the matter; except I think the default character set should remain the same as it does make an effort to convert otherwise unprintable characters into something readable. Geoff

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 style-file. Turn-restriction also allow a specification for vehicle-groups. Don't know, if this is used very often, but I think you should handle it in style and not in general.

Henning

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-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 think it's independent of the part of the world. There are in general two use-cases:

* actual coastline data -> --generate-sea=.... * proofed coastline data -> --precomp-sea=... --generate-sea It should be possible to find a default for actual coastline-data. I've never played with floodblocker, so I can't say, which values are best. So maybe we could have --generate-sea-precomp=<file-name> and --generate-sea-actual Henning

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 polygons/no-mp are mutual exclusive. Using multipolygon the land and sea is modelled as one big multipolygon. So islands are cut out from the sea and that leads to some well known multipolygon artefacts. Using polygons the whole tile is covered with a sea polygon and all land area is added as polygons tagged with natural=land (the tag can be changed with the land-tag parameter). The advantage is that you don't have the multipolygon artefacts. Disadvantage is that sea polygon covers the whole tile. no-mp is the same al polygons. I think we should remove that. no-sea-sectors and extend-sea-sectors are required on the edges of a data extract, e.g. compile a map with the data of France. So you have a tile with coastline data of France that stops on the border of Belgium. So the data is incomplete and the sea-sectors algorithm tries to guess how the coastline is closed best. I guess the description of the extend-sea-sectors parameter (same as no-sea-sectors) is wrong but I must check that in the code. close-gaps repairs missing coastline data. All floodblocker options configure the floodblocker. This prevents the sea-generation if it detects that too many streets or other things are located within sea polygons. Maybe the fbdebug parameter could be removed and replaced by an entry in the log properties. WanMil

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 make that behaviour default if --bounds=... is set. I think that is the approach most people want (noone updates the bounds as often as the map data - so it is likely to still add an You should replace it with --location-autofill=is_in,nearest Bounds isn't needed any more, because it's default if you set --bounds=...

--ignore-turn-restrictions ,Strong Objection again. We don't have separate turn-restrictions for cyclists or pedestrians yet, so don't default it car centric. Currently as a cyclist, I'm better off if the map ignores turn-restrictions for cars. (many many oneway streets don't apply for cycling, but there are restrictions for cars in OSM at those crossings). There are restriction:bicycle=* and except=* defined for turn-restriction. I haven't checked, if they are used. --show-profiles=1 --- keep it. I need it differently depending on the country or map. Don't put options that one needs differently depending on the country into the style-file... You can handle country-specific rules via mkgmap:country=*

Henning

--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 it for a map of europe (or other multi country regions).

You cannot use it also if data of two countries - one with drive on left and one with drive on right - is in the same tile. When both options are not set and --check-roundabouts is set mkgmap makes an autodetection by analysing the direction of the first roundabout. But this detection stores the information in a static variable so when using max-jobs > 1 the drive-on-xxx info might be interchanged between tiles. WanMil

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 "move to style". My idea of the style system was that everything that determines how osm tags get converted into garmin terms was to be controlled by the style file. The mkgmap code should not be looking at a hardwired tag like maxspeed at all. If you want to change road_speed based on maxspeed it should be written in the style. For a start maxspeed is the wrong tag to use, a tag for average or typical speed would be better where such a thing exists. At the very least, it should only revise the speed down, never up (I think you might have made that point before), because a good road going through a town may be be slower because of speed restrictions but a single track road is usually not suitable for driving a 60mph just because that is the speed limit.

--ignore-turn-restrictions ,Strong Objection again. We don't have

The same applies, the style should be able to select cycle relevent turn restrictions if they exist, based on the style that you write. So OK, that's not going to happen soon, because the style system would have to be extended a bit to make it possible. So we will probably have to retain the option for now. But only because there isn't a way of specifying which tags should be used for turn restrictions in the style.

--delete-tags-file= It's a performance improvement. However it was once broken. Someone said it's working again. I once moved it into my style where it makes more sense. Don't know how much quicker it can make mkgmap.

I doubt that there is much performance improvement, especially after the style re-write. I thought it was mainly so you could easily remove things from the map while still using the default style. ..Steve

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 needed.

What do you object to?

I'll explain what I mean by "move to style".

My idea of the style system was that everything that determines how osm tags get converted into garmin terms was to be controlled by the style file. The mkgmap code should not be looking at a hardwired tag like maxspeed at all. If you want to change road_speed based on maxspeed it should be written in the style.

For a start maxspeed is the wrong tag to use, a tag for average or typical speed would be better where such a thing exists. At the very least, it should only revise the speed down, never up (I think you might have made that point before), because a good road going through a town may be be slower because of speed restrictions but a single track road is usually not suitable for driving a 60mph just because that is the speed limit.

okay, got it. So it means drop maxspeed processing, drop the option, and move it into the style instead... So that's best anyhow. I would propose it to be changed that way (drop the option and new notation for the style-file): road_speed=4 === set current road_speed to 4 or lower - if maxspeed is lower, but not higher (new behaviour) road_speed_fixed=4 == set current road_speed to 4 no matter maxspeed, recommended speed, or other tags (same behaviour as currently using --ignore-maxspeeds) road_speed_variable == 4 set to current road_speed 4 if no maxspeed or other tags exist (what other tags are actually existing in osm yet?) - decrease or increase it based on the tags/maxspeed (current behaviour, at least until there are tags like average speed in OSM). and yeah, I'm sure autorouting and time calculation gets better, if the speed is not increased just because maxspeed is high. That concept was pretty flawed in my eyes since the beginning (it works out somehow, because we don't set the actual speed, but a category which is usually handled lower by garmin algos than the maxspeed in osm). We cannot code maxspeed like NT maps have anyhow (meaning neat popups reminding you if you go to fast or similar things) - and in NT maps maxspeed doesn't equal average speed for calculation either. The only change for the worse could happen for people using Nuvi GPS devices from Garmin with mkgmap maps regulary (without sometimes reverting to other maps), where the device based on past speed per road_class, actually increased the time for calculation). I don't know however what happens on map updates anyhow, and if these values are calculated on a per map basis, or for all maps, and how map updates affect it. In general it would be the much better behaviour. For road_speed_variable - we will need some rework/extension once tags about the typical or average speed exist in OSM. Maybe then we would need to add a forth mode like road_speed_typicalspeed == 4 that is enacted if typicalspeed doesn't exist. typicalspeed could be set from various tags via the style-file.

...

--ignore-turn-restrictions ,Strong Objection again. We don't have

The same applies, the style should be able to select cycle relevent turn restrictions if they exist, based on the style that you write.

So OK, that's not going to happen soon, because the style system would have to be extended a bit to make it possible. So we will probably have to retain the option for now. But only because there isn't a way of specifying which tags should be used for turn restrictions in the style.

yip, for right now it is not possible within the style-file. Default on is fine, if for right now it can be switched off.

...

--delete-tags-file= It's a performance improvement. However it was once broken. Someone said it's working again. I once moved it into my style where it makes more sense. Don't know how much quicker it can make mkgmap.

I doubt that there is much performance improvement, especially after the style re-write.

I thought it was mainly so you could easily remove things from the map while still using the default style.

well if I remember it correctly, it was thought to be for maps consisting of very few objects, e.g. a plain POI map, or a plain railway map, and to speed up mkgmap. Dunno how and if it is used in that way, and if it improves speed.

..Steve

-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

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 actually mean not an action part, but the part in the square brackets []. Same for lower down. e.g. [0x0c road_class=2 road_speed=4 resolution 24 continue] road_speed_fixed=4 == set current road_speed to 4 no matter maxspeed, recommended speed, or other tags (same behaviour as currently using --ignore-maxspeeds) You mean: ...=... {set road_speed=4 } road_speed_variable == 4 set to current road_speed 4 if no maxspeed or other tags exist (what other tags are actually existing in osm yet?) - decrease or increase it based on the tags/maxspeed (current behaviour, at least until there are tags like average speed in OSM). I don't understand the reason for it. In general I think everything is solvable with current style-functionality. Can you give an example, were it isn't possible to handle it? Well, the current style-functionality would require much more lines in your style, for the same output. Let's assume you use --ignore-maxspeed (because otherwise I don't know at all what happens, if you use rules to change maxspeed),

a simple line like highway=primary [0x03 road_class=2 road_speed=6] would need to be rewritten to highway=primary & maxspeed>90 [... highway=primary & maxspeed>70 [... and so on. On the other hand if you currently don't use --ignore-maxspeed then you would need to do the following (and hope it works which I don't know): highway=primary & maxspeed > 90 {set maxspeed=89} and so on, if you want it to depend on other tag combinations, that means one additional line again. So no, the current treatment of maxspeed/speed in general is far too complicated and not working well. Using a different notation system in the [ ] would make it much easier and better suited, and no need for a commandline switch anymore.

Henning

-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

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_speed_max=6 resolution=16] If you want mkgmap to only decrease the road_speed based on maxspeed. b) highway=primary [0x03 road_class=3 road_speed=4 road_speed_max=4 road_speed_min=4 resolution 18] in order to stop mkgmap from processing the max-speed. whereas c) highway=primary [0x03 road_class=3 road_speed=4 road_speed_max=7 road_speed_min=0 resolution 18] (current mkgmap behaviour) is not what most people want. I think currently it is pretty clumsy (asumming it works as writen above. I thought road_speed_max and road_speed_min are only working inside the {action part} ... or do you mean that if I want mkgmap to stay clear from fiddling around I should write: d) highway=primary {road_speed_max=4 road_speed_min=4} [0x03 road_class=3 road_speed=4 resolution 18] --- (leaving out road_speed shouldn't be allowed, as there needs to be a way to even if a max and min speed is set previously, to make the street not routable at all, by omitting road_class and road_speed) I still think that mkgmap should never increase the road_speed based on maxspeed by default. It should however use maxspeed as upper limit for the road_speed, and that an automatic behaviour as in a) or d) is to be expected, while c) could be set via style-file if you want maxspeed to take precedence. The current treatment of mkgmap:road_speed=+1 is definitely not optimal, I have documented that a while ago on the mailinglist. It does not work for all circumstances. There can be outcomes that are not intended. On 10.12.2012 15:08, Henning Scholland wrote:

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 could also be used as a default, if there is no maxspeed, road_speed_max=* to set a maximum road_speed and road_speed_min=* to set a minimum.

Henning

-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org