Hi Andrzej, current implementation applies housenumbers to routable ways only. If I got that right, garmin format would allow to have non-routable ways with housenumber info, but that would be stored in NOD as well. Gerd popej wrote

Hi,

what about address search and house numbers? I have some some specific questions:

Which types of lines can be used for address search?

Which types do get house numbers? I understand that house numbers from points are transfered to a lines, but does it depend on line type or object tagging, other then addr:*?

Can I use non-routable line for address search?

-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3259-remove-most-checks-regarding-rou... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Minko, maybe as a work around you can make them routable for taxi or so. Gerd ligfietser wrote

Hi Gerd, Would be nice if it could be added, because I make roads that are forbidden to cycle non-routable. The parallel cycleways often dont carry the streetnames, so the addresses on these roads are not found.

...

current implementation applies housenumbers to routable ways only. If I got that right, garmin format would allow to have non-routable ways with housenumber info, but that would be stored in NOD as well.

Gerd

---

mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3259-remove-most-checks-regarding-rou... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Gerd, it would great to have non-routable roads with house numbers. I use that kind of object to implement address search for POIs. -- Best regards, Andrzej

Hi Minko,

I found out that the routing errors still exist when you have two routable lines on top of each other, one with and one without road speed/class parameters. If the GPS finds an address on such road, routing goes mad. In my style I use type 0x02 for all cycleroutes. I need to use 0x02 because this is one of the few type that are always rendered on top of all other lines.

just to make sure: your style creates two lines for one OSM way, they have different types, but both below 0x3f, and one has road speed/class , the other has not. Which one come first?

If it were possible to skip address search on the last routable line somehow I could make it not routable, but I'm not sure.

For mkgmap, a routable line is one that has a road speed/class and a non-extended type. I am not familiar with the code regarding indexes for address search. I don't know ihow this is related to routing.

Normally multiple routable lines are not often needed, so the removal of those warnings is still ok.

I think when it causes problems, we should try to find a better solution or print a warning. Gerd

Hi Minko, I am still not sure if we are talking about the same stuff. A routable line is one that has roadspeed/class and a non-extended type. These lines are internally called roads. The algo in StyledConverter collects all lines (routable and not-routable) in different lists, and after removal of wrong angles and obsolete points, all non-routable lines are added before all roads. The order within the two different lists is maintained. So, the order is only important if you add multiple non-routable lines or multiple roads for one OSM way . Felix said he adds up to 7 lines for one OSM way, so we should find out which combinations are bad. Gerd

Date: Fri, 9 May 2014 12:09:14 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Hi Gerd

...

just to make sure: your style creates two lines for one OSM way, they have different types, but both below 0x3f,

Well, it doesnt happen if 0x02 is replaced by 0x31. I think it only happens with "standard" routable line types (0x01-0x13, 0x16, 0x1a,0x1b) but i havent tested them all

...

and one has road speed/class , the other has not. Which one come first?

The ones with routing parameters come first. After this I handle the cycle routes with line 0x02 to make sure they are always rendered on top (on all GPS devices). I always needed to put on 0x02 routing parameters too because of this issue. I thought I might give it a try to remove them, but it seems the issue is still the case.

...

I think when it causes problems, we should try to find a better solution or print a warning.

A warning would be fine, in case multiple routable lines are detected. If that's too complicated, I would suggest to print the old warning only with --check-styles: "Non-routable way with routable type 0x.. starting at ... is used for a routable map. This can lead to routing errors if multiple routable lines on this way are used."

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

Hi Minko, okay, got it. So maybe we have to separate the "well known" routable types 0x01 -0x13 , 0x1a, 0x1b, 0x16 from others which are also routable? Gerd ligfietser wrote

Hi Gerd,

Let me give an example when it goes wrong then: highway=unclassified [0x06 road_class=3 road_speed=2 resolution 23 continue with_actions] bicycleroute=yes [0x02 road_class=4 road_speed=3 resolution 22 continue]

I have to use continue because this rule must continue for highway=pedestrian areas which are also handled in the polygons style.

If I remove the road parameters from the second line routing breaks: bicycleroute=yes [0x02 resolution 22 continue]

_______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3259-remove-most-checks-regarding-rou... Sent from the Mkgmap Development mailing list archive at Nabble.com.

Hi Minko, I think you found a bug in GPSMapEdit. I've just verified that mkgmap doesn't write the type 0x02 line into NET or NOD, so I assume that GPSMapEdit shows some defaults when it finds a line with type 0x02. I can reproduce the routing errors on the device: 0x02 as road works, without road it fails or the device crashes after a few seconds. So I think it is not a good idea to use 0x02 without road-class/speed. Gerd

Date: Fri, 9 May 2014 15:47:05 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

Hi Gerd

I have noticed types between 0x30-3f are behaving inconsistent, they are not rendered at all in Mapsource/Basecamp, even with a typ file. Routing seems to work but not very reliable.

After some more tests, I notice other remarkable things:

I search for an address on an unclassified road (type 0x06, road_class=3 road_speed=2) This road also has a bicycle route (routable line without road class/speed):

[0x02 resolution 22 continue] gpsmapedit shows road_class=5 road_speed=3 on this line 0x02 (??) and routing errors happen. It always routes to the tile border and then a straight direct line to the address that I search for.

[0x05 resolution 22 continue] gpsmapedit shows road_class=1 road_speed=3, routing error

[0x06 resolution 22 continue] gpsmapedit shows road_class=0 road_speed=3, routing error

[0x10 resolution 22 continue] gpsmapedit shows road_class=0 road_speed=0, routing error

[0x0a resolution 22 continue] gpsmapedit shows road_class=0 road_speed=1, no routing error

[0x29 resolution 22 continue] gpsmapedit dont show road_class nor road_speed, no routing error

Normally I set on type 0x02 road_class=4 road_speed=3, and then the routing is ok.

Any idea why a default value of road_speed and class is assigned altough I don't specify it? Is there a way how to show/print the routing parameters that mkgmap sets on every line?

...

okay, got it. So maybe we have to separate the "well known" routable types 0x01 -0x13 , 0x1a, 0x1b, 0x16 from others which are also routable?

Gerd

---

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

Hi Gerd

If I got that right, we should 1) warn when the style file lines uses types 0x02 - 0x09 without road class/speed if -check-styles is used

2) warn if a line is added multiple times, once with type between 0x01 and 0x3f and road class/speed, once with type 0x02 - 0x09 and without road class/speed.

I've implemented that with r3267.

Gerd

I also found errors with 0x01, 0x10, 0x13 but not 0x18 or 0xa So better warn with 0x01-0x13;0x16 without road class/speed

that sounds like the original list was not so bad: //return type >= 0x01 && type <= 0x13 || type == 0x1a || type == 0x1b || type == 0x16; what about 0x16, 0x1a and 0x1b ?

0xa is in the range 0x01 - 0x13. Is this really an exception? And is it the only one?

Hi Gerd 0x16: routing error 0x1a: no routing error (double checked this) 0x1b: routing error So it's weird that only 0x1a shows no routing error. Better keep the original list then to be safe?

what about 0xa ? Or was that meant to be 0x1a ?

Hi Gerd 0x0a gives also a routing error, so everything in the range 0x01-0x13, 0x16 and 0x1b

As there are clearly differences in features supported by various models, would it maybe be an idea to externalise the differences in some way? How about a file to contain the capabilities of device types, an option to target a particular entry in that file, and a way to expose the selected device in the style files? That could also help address the differences in supported POI categories and icons. Colin On 2014-05-11 11:52, Gerd Petermann wrote:

Hi Minko,

thanks for your help. This is now implemented with r3269.

Gerd

...

Date: Sun, 11 May 2014 11:45:47 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

...

what about 0xa ? Or was that meant to be 0x1a ?

Hi Gerd

0x0a gives also a routing error, so everything in the range 0x01-0x13, 0x16 and 0x1b _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

Links: ------ [1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, I certainly was not envisioning anything with SQL! More like an "ini-file". At present the program itself and the default styles have to address all kinds of devices, so they probably play it safe. Users can customise the program and styles or develop their own, but there is no mechanism to support sharing the nuances of each type of device within the distribution. What I am suggesting will allow some of the differences to be collected, and Let's see if I can work through an example. 1) the command line java -jar mkgmap.jar ........ --target-device=oregon450t 2) the "device capability database", let's call it "devcap" [oregon450t] camp_site_poi_type=0x2b03 routable_types=1,2,3,4,5 has_extended_icons=true 3) the styles tourism=campsite & mkgmap:device=oregon450t {} [0x2b05 resolution 24] tourism=campsite & mkgmap:device!=oregon450t {} [0x2b03 resolution 24] tourism=campsite & devcap:has_extended_icons=true {} [0x2b05 resolution 24] 4) the styles, if we could use variables in the last block tourism=campsite {} [$(devcap:camp_site_poi_type) resolution 24] 5) the style checker respects the routable_types information from devcap to generate/suppress warnings 6) some kind of simple 'include' function in the devcap file to allow device families to be used [oregon] camp_site_poi_type=0x2b04 routable_types=1,2,3,4,5 [oregon450t] include oregon camp_site_poi_type=0x2b04 All pretty simple basic functions, which when you combine them, open a world of possibilities. You can keep it really simple by just implementing the option plus exposing that in the styles, or you can make it really complex by putting all the information about POI icons, supported features etc in the devcap file. Once the framework is there, it can be leveraged (I hate that word) for many things limited only by imagination. I'm afraid my experience is limited to various Nuvi models plus the wealth of vicarious experience gained from following this list! Colin On 2014-05-12 07:04, Gerd Petermann wrote:

Hi Colin,

I am not sure what you mean. Let me try an example: I am aware that my Oregon 450t needs e.g. tourism=camp_site [0x2b05 resolution 24] instead of tourism=camp_site [0x2b03 resolution 24] which is used in the default style.

If I got you right, you want to create some kind of database to keep track of these differences and a style that uses a symbol to reference the database. So, for my example, we would have a database with a symbol "camp_site_poi_type" and a default value 0x2b03 and a special value for the Oregon 450t containing 0x2b05. The style would then use something like

tourism=camp_site [db:camp_site_poi_type resolution 24]

When reading the style, mkgmap could look up the database to find the right value.

If the database would use SQL, we probably need a few tables for device types, groups of device types, firmware versions, etc. Without SQL, it might be another XML file.

Any ideas how many differences we have and how they could be stored?

Gerd

------------------------- Date: Sun, 11 May 2014 12:22:50 +0200 From: colin.smale@xs4all.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

As there are clearly differences in features supported by various models, would it maybe be an idea to externalise the differences in some way? How about a file to contain the capabilities of device types, an option to target a particular entry in that file, and a way to expose the selected device in the style files? That could also help address the differences in supported POI categories and icons. Colin

On 2014-05-11 11:52, Gerd Petermann wrote:

...

Hi Minko,

thanks for your help. This is now implemented with r3269.

Gerd

...

Date: Sun, 11 May 2014 11:45:47 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.

...

what about 0xa ? Or was that meant to be 0x1a ?

Hi Gerd

0x0a gives also a routing error, so everything in the range 0x01-0x13, 0x16 and 0x1b _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

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

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

Links: ------ [1] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

I think these pages could be a good start, but they need to be updated: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types

Andrzej, you are absolutely right. The problem you describe is exactly what I was addressing earlier. I am hoping to allow a user of mkgmap to allow for these differences in behaviour by using a simple text editor, instead of a Java IDE. I propose making this accessible to the masses instead of the very few who have both the knowledge and the time required to change the code of mkgmap, its styles and TYP-files. You say yourself that there is no single solution - no "one size fits all". That's why I propose that mkgmap should not TRY to be a best-fit compromise, but to provide a flexible platform that allows many more people to get a more optimal result for their device in a more convenient way. Colin On 2014-05-12 15:15, Andrzej Popowski wrote:

Hi Colin,

...

Users can customise the program and styles or develop their own, but there is no mechanism to support sharing the nuances of each type of device within the distribution.

I understand the problem but I don't think mkgmap code or default style is a right place to solve it. We could expect more flexibility to create conditional styles from mkgamp, but any hardcoded dependency on Garmin hardware would be a nightmare to maintain.

Another aspect of this problem is that there is no single solution. You could be interested in a map for Oregon while I'm interested in a map for multiple devices. Our expectation for a mkgmap would be different.

Each developer decides, what objects to use on a map and which Garmin type assign to an object. Even if I create a topo map, I try to select Garmin types, that are visible in nuvi. I try to select objects for POI, which fit reasonably well with search categories in Mapsource, outdoor device and nuvi. In case of conflicts, I can prefer good solution for outdoor device, while other developer could prefer nuvi. We both could be unsatisfied, if mkgmap would prefer Mapsource.

I'm sure that any knowledge about particular behavior of a device is very valuable for a developer. If mkgmap would allow for conditional definition in a style, then your idea could lead to a separated project of creating a configurable default style. I would be interested in it, but I'm sure I won't use it without my own adaptations.