On Mon, 2011-11-07 at 10:50 +0100, Thorsten Kukuk wrote:

Hi,

On Mon, Nov 07, David Fletcher wrote:

...

I have a problem with a stretch of road which is missing from my Garmin and causing crazy instructions i.e. turn around and find another way. Please take a look at Open Street Map here:- http://www.openstreetmap.org/?lat=51.44952&lon=-2.38914&zoom=16&layers=M where the first section of the road called Freezinghill Lane which heads south-westwards from the A420 is missing from the map on my Garmin. I believe this problem is caused by somebody adding a tag to the road to make it serve as a parish boundary as well as a road.

Or is it confusing mkgmap with an unexpected input combination?

Not mkgmap, but if the style does not handle this correct, yes, this can happen. I always use "continue" for boundarys and don't see this problem with my cards.

Thorsten

I'm getting the impression that, for an ordinary user who wants to make contributions to the Open Street Map community then reap the reward of free mapping, what I will call "the system" as a whole is a little inaccessible. Until a couple of years ago, I was working as an electronics/software engineer, so I do have an understanding of the syntax of the code that was being posted here earlier today. Unfortunately, together with various other circumstances, I became so tired of the people I was having to work for, and of being repeatedly made redundant, that I decided that at my time of life the most sensible thing for me to do was have a complete career change. So, in about one hour, I have an appointment to deliver my second driving lesson. As for Open Street Map / Garmin maps, I think that if a road is rendered as expected on the web site, it is reasonable to expect that same road to appear on my Garmin device without an ordinary user / contributor having to go delving into the technicalities to get it to work properly. At this time, I have no idea at all what a style is or how it affects the working of mkgmap. I do know how to gather tracking information, upload it to the Open Street Map web site, and use the editor there to add roads, footpaths etc. to the database. I do not know how to use "continue" to avoid what appears to be clashes between tags that are preventing "the system" working properly for me. Dave

On Mon, Nov 07, 2011 at 12:34:10PM +0100, Minko wrote:

Since Lambertus who compiles the world routable maps filters all boundaries with certain admin_levels out of the data, this could be an explanation that your highway is gone. Solution: remove the tag admin_level=10 from this road.

Alternative solution: instead of filtering the data, why not filter the style file (remove the rules that generate the unwanted objects)? IIRC, Lambertus also filters out power lines from the data. Does anyone want to have them in the default style? If not, I think that the default style should omit boundaries and power lines. They are rarely useful in well-mapped areas. I understand why Lambertus does not want to have power lines on his maps. They can be confusing on wide zoom levels when a power line goes through fields and forests, but there is no road next to it (not even a decent bicycle path). Other things that might be useful to remove from the default style are various natural=*, building=* and landuse=*, except waters. These could be generated in separate, transparent layers, similar to how I generate various route relations for Finland at http://www.polkupyoraily.net/osm/. A multi-layer map would allow the user to select what to see on the GPS receiver unit. When you go offroad, you would probably enable the power lines and maybe boundaries, and foot/bicycle routes and disable other routes, except maybe route=bus if you are looking for transportation back to the town. If nobody opposes this "diet" of the default style, I would like to do it. Marko

I strongly oppose the change. 1. I think the default mkgmap style should be kinda universal and not only for motorists. It shouldn't be specific and not show advanced stuff that is only for certain user groups (routes, and so on). 2. Multi layer maps are not a good solution. a) they work differently depending on the gps unit (older Garmin GPS only allow only one gmapsupp.IMG but inside you can disable/enable layers; newer Garmin PNAs don't allow for this, but you can enable/disable maps only based on name.IMG being separate). 3. Therefore: basic stuff like building=*, power lines, and also most landuse/natural keys should be in the default mkgmap style. Boundaries are a bit of a different case, as you cannot see them physically (most). I would leave national boundaries in for all zoom levels, but cut down on more specific boundaries (I would propose: boundary=administrative & admin_level<5 [0x1d resolution 20] boundary=administrative & admin_level<7 [0x1c resolution 23] # boundary=administrative & admin_level<9 [0x1c resolution 22] ´boundary=political [0x1c resolution 24] and move the boundary block to the beginning of the style-file and use it with "continue". Also move railway=abandoned to res 24. 4. Points file: I don't think the following are needed to be displayed - the access rules could still apply - however for them to be more effective they should be moved up front of the points file): barrier=bollard | barrier=bus_trap {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 24] barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate {add access = no; add foot = yes} [0x660f resolution 24] Also take into account the default style purpose (resources/styles/info): The default style. This is a heavyweight style that is designed for use when mapping and especially in lightly covered areas. }

On Mon, Nov 07, 2011 at 01:20:06PM +0100, Felix Hartmann wrote:

1. I think the default mkgmap style should be kinda universal and not only for motorists. It shouldn't be specific and not show advanced stuff that is only for certain user groups (routes, and so on).

Side note: My family is car-free. If anything, a leaner default style could be making the life of off-road users harder. But, they already need to combine contour lines separately.

2. Multi layer maps are not a good solution. a) they work differently depending on the gps unit (older Garmin GPS only allow only one gmapsupp.IMG but inside you can disable/enable layers; newer Garmin PNAs don't allow for this, but you can enable/disable maps only based on name.IMG being separate).

Thank you for educating me. I did not know that newer units do not allow multiple layers within a gmapsupp.img.

3. Therefore: basic stuff like building=*, power lines, and also most landuse/natural keys should be in the default mkgmap style.

What if we extend the mkgmap style language with an 'import' or 'include' directive familiar from other languages? There already is the base-style directive (used in resources/styles/marine/info), but it allows a style to import only one other style. For polygons, the default style could 'import' or 'include' the following new styles: water (sea and lake polygons) natural (forests etc.) landuse,building (land use by humans) commercial (shop=*, amenity=*) There could be some leaner styles distributed with mkgmap that would include only the 'water' and 'commercial' polygons. Similarly, for lines, there could be multiple styles, all of which would be included by the default style: motor (motorways, trunk roads etc. that are only for motor vehicles) non_motor (footway, cycleway, path, track) boundary infrastructure (power=line etc.)

4. Points file: I don't think the following are needed to be displayed - the access rules could still apply - however for them to be more effective they should be moved up front of the points file): barrier=bollard | barrier=bus_trap {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 24] barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate {add access = no; add foot = yes} [0x660f resolution 24]

I think that these are useful when collecting data for a map. Even though my area has good Bing coverage now, you cannot see all barriers in aerial images, especially if there are trees nearby.

Also take into account the default style purpose (resources/styles/info): The default style. This is a heavyweight style that is designed for use when mapping and especially in lightly covered areas.

Right. The default style can stay, but I think that a leaner style could be useful in densely covered areas. Marko

On Tue, Nov 08, Felix Hartmann wrote:

Actually all of the following cannot activate/deactivate at the same time layers or maps (doesn't matter) if they are withing ONE gmapsupp.img: extrex 10,20,30, gpsmap 62, Oregon, Dakota, Colorado, edge 800, Montana. Also nearly all Nuvi (released less than about 3 years), and probably the newest Zumo or motorcycle units either. They will show all layers or maps at the same time. To activate/deactivate them separately they need to be named like srtm.IMG, mtbmap_D.IMG, and so on (and I think no name can be longer than 8 characters, at least that was the case on older units).

They can be as long as vfat allows. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

On Mon, Nov 07, 2011 at 02:01:32PM +0200, Rich wrote:

would it be possible to create such default layer styles ? so user could use them without designing their own style.

Sure, that is my idea. A while back, I suggested that we should try to create multiple map layers in one pass. For example, the various routes-* styles currently need to be processed separately. It takes a few minutes per layer for Finland. Almost all of this time is needed for parsing the map data. Even a "null" style needs this much time. But, this is just an optimization, not strictly needed to make the style change happen.

for example, i find power lines very useful outside of large cities, which is where i do quite some mapping work. same goes for buildings - i'd actually want to see them in some more distinct colour in the default style files, currently they are nearly invisible. but seeing them allows me to better decide what data to collect.

Right, I have similar needs myself. However, last summer when I was bicycling in the middle of nowhere, I got a bit distracted by power lines looking like roads (1-pixel wide line at wide zoom levels). So, I do understand people who want to be able to disable or enable the "clutter" when using the GPS unit. Marko

On Mon, Nov 07, 2011 at 01:36:08PM +0100, Minko wrote:

I dont think it's a good idea to strip down the default styles and use layers instead, because they don't work in Basecamp/Mapsource.

In which way do they not work? I sometimes use QLandkarteGT for diagnosing problems or for browsing the map. There, I have not seen an option to select which map layers are visible. All of them are, and the TYP files are apparently applied to every layer. So, a multi-layer should "work" in QLandkarte. Marko

On 11/07/11 16:42, Minko wrote:

I never worked with Qlandkarte. Mapsource and Basecamp are not capable of displaying multiple maps on top of each other if they don't have the same Family ID. If they have the same FID, you cannot select which layer you like to see and which layer not. You see them all. You can use multiple layers and give them different FID's but then you can see only one layer.

so i guess just cutting down the default style wouldn't be too good... how about having several "default" styles instead ? that would also allow users to look at the differences and ease the initial understanding on changing the styles themselves -- Rich

I don't yet know how your system works but I totally agree with this approach. When I was working as a software engineer, the main job was a text screen with a menus driven user interface. Every "hard coded" menu was actually a linked list of options with the texts automatically loaded from a file in the appropriate language. Every configuration file, used to control the testing of a list of items of particular types, was also loaded into a linked list and driven by exactly the same code as the "hard coded" menus with parameter files for each item. I'm telling you this as a new member so that you know that I am familiar with the concepts you are talking about. Unfortunately, radical life style changes have been forced upon me by circumstances, hence I needed to do a bit of a career change. Dave On Mon, 2011-11-07 at 18:40 +0000, Roger Calvert wrote:

I don't want to comment specifically on any of the recent topics, but I think there is a general point which is worth making.

A very flexible system is when the program (mkgmap) holds only information about data structures. Data values are held in the configuration (style) file and the actual input files. It is the configuration file which should carry out customisation for a particular purpose.

Rather than putting extra specific data values in mkgmap, some extra facilities for style files (such as the suggestion that it should be possible to access mkgmap internal constants) and a number of different sample (default) styles would give flexibility both now and for future developments. It might also be possible to incorporate more of the mkgmap command line options in the style file.

Roger

______________________________________________________________________

Roger Calvert

______________________________________________________________________

On 07/11/2011 17:38, Rich wrote:

...

On 11/07/11 16:42, Minko wrote:

...

I never worked with Qlandkarte. Mapsource and Basecamp are not capable of displaying multiple maps on top of each other if they don't have the same Family ID. If they have the same FID, you cannot select which layer you like to see and which layer not. You see them all. You can use multiple layers and give them different FID's but then you can see only one layer. so i guess just cutting down the default style wouldn't be too good... how about having several "default" styles instead ? that would also allow users to look at the differences and ease the initial understanding on changing the styles themselves

---

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

IIRC, Lambertus also filters out power lines from the data. Does anyone want to have them in the default style? If not, I think that the default style should omit boundaries and power lines. They are rarely useful in well-mapped areas. I completely disagree. Power lines very useful in non-urban well-mapped areas where they are signficant features. But I can see that some people would find them clutter in a dense city. I don't understand the objection to boundaries. Do people really expect those not to appear? I don't understand how we can be talking about "default style" and "multi-layer map" at the same time. It would seem that the default style should support a map that is broadly useful to all people in all circumstances (a tall order). It may be that we end up with a rural and and urban default style, and people have to choose. A multi-layer map with selectable elemnts is a reason to change the default style to simple when the out-of-the-box mkgmap can process the files multiple times, make transparent layers according to a (supplied!) config file, and then merge the results multiple layers into one .img (and make multiple .gmapi/windows). It doesn't seem we are there yet.

Marko Mäkelä <marko.makela@iki.fi> writes:

On Tue, Nov 08, 2011 at 04:58:40PM -0500, Greg Troxel wrote:

...

I don't understand how we can be talking about "default style" and "multi-layer map" at the same time. It would seem that the default style should support a map that is broadly useful to all people in all circumstances (a tall order).

Making the default style modular could be a mere refactoring change at first. It does not need to have any end-user visible effects.

...

It may be that we end up with a rural and and urban default style, and people have to choose.

If we split the default style so that it imports a number of substyle definitions, then it would be easy to introduce and maintain an urban' or 'sparse' style: it would just import a small number of the substyles that the default style is based on.

That sounds excellent to me. What I was not comfortable with was trimming the one true style. But having a few top-level files that include a number of substyles would be great, and I don't care whether sparse or full is default as long as both are in-tree and maintained. It will be an interesting experiment to see what people prefer.

...

A multi-layer map with selectable elemnts is a reason to change the default style to simple when the out-of-the-box mkgmap can process the files multiple times, make transparent layers according to a (supplied!) config file, and then merge the results multiple layers into one .img (and make multiple .gmapi/windows). It doesn't seem we are there yet.

Right. The refactoring of the default style would be only a first step on a long path.

Based on what Felix told us, we would probably also need to provide end-users with a simple way of converting multiple .img files to a single gmapsupp.img, so that users of old and new devices can make use of the map layers.

Agreed, and you don't have to get that old to need a single file - my etrex vista hcx bought in spring 2009 and still being sold is like that.

Minko <ligfietser@online.nl> writes:

How about introducing a typ file (or several) instead of several styles? To my opinion the maps without a typ file look like crap, especially in very dense mapped areas. For Lambertus' maps we already started to adapt the default style to use it together with a typ file, you can download a test map at http://code.google.com/p/mkgmap-style-sheets/downloads/list or look at some screenshots in this topic: http://forum.openstreetmap.org/viewtopic.php?id=13257

I've been using Charlie Ferrero's TYP file. Generally I really like it, and I can't imagine going back. But I have two issues: There isn't open source code to create TYP files from representations that are reasonable to edit with free tools and store in version control systems (and be diffable, etc.). Fixing this would let us bring a TYP file into the mkgmap source sanely, and then have a style that matches it. Style files get edited for multiple reasons; one is to match TYP files, and another is catching up with tag usage. I'm not suren if Charlie's style files are be a bit out of date (not complaining; what I have to use for free is awesome), but structurally it would be hard to keep them in sync; I think what's needed is a merger of those and the modern mkgmap style, but I haven't spent the time to really dig in (which is a clue that just using what Charlie publishes is very good - I think my big issue is town boundaries being missing, but even that I'm not sure of). So, besides the Free text<>TYP converter, one path forward could be (and I'm really curious what Charlie thinks here): Check in a TYP file that is intended to provide lots of drawing primitives, and Charlie's TYP is probably a good choice (or at least starting place). Hold our noses while editing it (with the web tools). Have a text file that documents what the codes do alongside it. Have a style file that is aimed at this checked-in TYP, and use the various perl programs (or probably easy to redo in java) to poke the family id into the TYP.

If a default typ file is introduced I dont think its a good idea to maintain the default style without a typ file. This is not going to work and you will not benefit of the extra value that a typ file can add. Reason is that a map without a typ file only can display a very limited amount of lines. Extended line types are without a typ file are either invisible or displayed as a thin black line, and therefore not useable in the default style file. For example you still can't add bridges or tunnels because this will not render very well without a typ file. So there are two options, either develop another alternative set of styles which can be used with a typ file (something like I'm working on for Lambertus' maps) and maintain the default style file that is used without a typ file, or adapt the default style file and add a sparse typ file in which the extended line elements are worked out.

First, I fully agree with you that frequently edited binary files are not suitable to be put under version control. There should be some textual source format that can contain comments (which will not make its way to the binary) and can be diffed. On Wed, Nov 09, 2011 at 08:34:36AM -0500, Greg Troxel wrote:

There isn't open source code to create TYP files from representations that are reasonable to edit with free tools and store in version control systems (and be diffable, etc.).

Depending what you mean by "reasonable to edit", it might be possible to use widely available general-purpose tools for this. Three alternatives spring to my mind: high-level scripting languages such as Perl, some assembler (NASM or gas), and rolling our own text-to-TYP converter in Java. Perl is reasonably multi-platform, and it has awesome support for parsing and fiddling with binary data. Unfortunately, it is not installed on every platform by default. Assemblers are probably even less likely to be installed already (except on Unix-like systems), and an assembler source file would probably be too low-level. A custom converter could also allow icons to be read from some NetPBM-style textual representation (or separate image files, if desired). Given that most OSM tools are based on Java, that probably leaves the Java text-to-TYP approach. It is not necessarily that hard to do. There exist free parser generator tools such as JFlex and ANTLR. It might be good to be compatible with some existing text file syntax, but it might also be sufficient if we maintain a matching TYP-to-text tool for importing existing TYP files and for diagnostics purposes.

Have a style file that is aimed at this checked-in TYP, and use the various perl programs (or probably easy to redo in java) to poke the family id into the TYP.

In my opinion, the text-to-TYP converter should take the family-id as a command-line parameter. Marko

On Mon, 2011-11-07 at 13:06 +0100, Thorsten Kukuk wrote:

On Mon, Nov 07, David Fletcher wrote:

...

Until a couple of years ago, I was working as an electronics/software engineer, so I do have an understanding of the syntax of the code that was being posted here earlier today. Unfortunately, together with various other circumstances, I became so tired of the people I was having to work for, and of being repeatedly made redundant, that I decided that at my time of life the most sensible thing for me to do was have a complete career change. So, in about one hour, I have an appointment to deliver my second driving lesson.

As for Open Street Map / Garmin maps, I think that if a road is rendered as expected on the web site, it is reasonable to expect that same road to appear on my Garmin device without an ordinary user / contributor having to go delving into the technicalities to get it to work properly.

If you was an electronics/software engineer, you should know that we are all only humans who makes mistakes. You cannot avoid that.

And you don't need to go into technicality details to get it work propoerly, normally you should inform the person who is creating the map, so that he can debug and fix the bug.

Yes I put my hands up and admit that I was being a little mischievous here. I know all about the old garbage-in produces garbage-out principle, but I was trying to make a point as if I were ignorant of the operation of computers and software, just like many Internet users who have probably downloaded the Garmin map and may or may not have noticed that there is a fault with it, but have no idea how to approach fixing the problem. It looks like in this case, the garbage in question is an admin_level tag that should not have been placed directly on a road. So, for now, I have an answer to my problem, thanks. I used the Open Street Map message service to pass on the text of the reply about this, to the person who objected to me removing the tags in the first place, to give him chance to respond. If I hear nothing from him in a couple of days I will see if I can somehow convert the tag into a relation. Dave

On Tue, 2011-11-08 at 10:56 +0000, SomeoneElse wrote:

David Fletcher wrote:

...

It looks like in this case, the garbage in question is an admin_level tag that should not have been placed directly on a road. So, for now, I have an answer to my problem, thanks. I used the Open Street Map message service to pass on the text of the reply about this, to the person who objected to me removing the tags in the first place, to give him chance to respond.

Another option, of course, is to create your own Garmin maps using data from e.g. http://download.geofabrik.de/osm/europe/

If you don't filter the data as is done behind the scenes at http://garmin.openstreetmap.nl/ then your road won't disappear, and you'll be able to modify the way that it looks on your GPS too.

I'd rather try to do "the right thing" and just make it work, so that it also works for others who don't have the technical understanding to sort out the problem. Imagine somebody who wants to use a Garmin device loaded with the UK mapping to drive to somebody's house at the bottom end of Freezinghill Lane. Because of the tag problem, the Garmin sends this person on a route that is 10 miles longer than it should have been. The result is unnecessary expense and environmental pollution, and the whole Open Street Map project getting a bad reputation in the eyes of the public. Better to fix the problem properly so that everybody benefits. Dave

David Fletcher wrote:

I'm getting the impression that, for an ordinary user who wants to make contributions to the Open Street Map community then reap the reward of free mapping, what I will call "the system" as a whole is a little inaccessible.

As for Open Street Map / Garmin maps, I think that if a road is rendered as expected on the web site, it is reasonable to expect that same road to appear on my Garmin device without an ordinary user / contributor having to go delving into the technicalities to get it to work properly.

Part of the problem is that OSM isn't "a map" but instead "some data". The default mapnik rendering on www.openstreetmap.org is just one example of a map that can be created from that data. It doesn't render everything and it wouldn't make sense for it to. The same's true of Garmin maps - no one Garmin map can be ideal for everyone (for my own use I create different ones for walking and driving, for example)

At this time, I have no idea at all what a style is or how it affects the working of mkgmap.

The beginners' documentation for mkgmap isn't very newbie-friendly, though http://wiki.openstreetmap.org/wiki/Mkgmap/help/How_to_create_a_map and http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles are definitely worth a read if you've not seen them already. Without doing anything too complicated it's possible to figure out how to add new entries to one of the style files so that "thing X" gets rendered a bit like "thing Y" but as a different Garmin item. As well as this list there's also the OSM help site http://help.openstreetmap.org/ and the Garmin forum on the OSM forum site http://forum.openstreetmap.org/viewforum.php?id=26 of course. The help site (and probably the forum too) gets users of all levels of familiarity with the software from "someone told me I can get free Garmin maps here" upwards. Cheers, Andy

On Tue, 2011-11-08 at 22:38 +0000, Dave F. wrote:

On 07/11/2011 09:44, David Fletcher wrote:

...

Hi there everybody!

I caused annoyance to at least one other Open Street Map user by deleting some of these tags.

I'm the guy who got 'annoyed'.

To all mkgmap users, please don't put the cart before the horse. OSM is a database for *many* renderers (including mkgmap) to use. Removing legitimate tags from OSM to get mkgmap to work is vandalism & wrong. The problem is clearly within mkgmap as it obviously can't filter/assimilate OSM data.

There are two duplicated tags on these ways/relation & it would be better if they were just within the relation. However this was clearly not the reason for the tag removal as only one was deleted.

Oh, & power lines are fantastic navigation items.

Dave F.

Hi Dave Yes as you correctly pointed out to me, I have been a member of OSM for several years. The trouble is, for me, during most of that time the OSM web site has been pretty unresponsive therefore unusable. So I've only been making contributions for 3 or 4 months therefore I am the learner. So, if you know what to do, would you mind please putting the boundary tags into the relation section for the roads in question so that it works for everybody? Then I can take a look afterwards and learn from what you've done. And yes Dave I totally agree with you about the power lines - just the big 300kV and above jobs on pylons - they are fantastic land marks and definitely should be included. Dave