OpenStreetMap Forum

The Free Wiki World Map

You are not logged in.

#351 2018-12-03 10:04:56

Beddhist
Member
From: Doembang Nangbuat, TH
Registered: 2009-07-28
Posts: 420
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Then our mkgmap config needs fixing, because it transforms the service station driveway into road type 0x10000, then transforms the services polygon into an alleyway. I think it's that alleyway that is the problem, because it is not connected to anything and pois are located along it.

Offline

#352 2018-12-03 11:03:09

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Peter, can you point me exactly to the line where this happens? I cant'find any services in the line style.
There is only a mob up rule, maybe this should exclude highway=services?

Offline

#353 2018-12-03 13:28:53

Beddhist
Member
From: Doembang Nangbuat, TH
Registered: 2009-07-28
Posts: 420
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

I'm not sure why you are looking in the line file, as we are dealing with a polygon (that gets converted into a line). I found this on line 68 in polygons:

landuse=retail | highway=services [0x08 resolution 22-20]

However, I have no idea what converts it from 0x08 (shopping centre poly) to 0x07 (alley). I could never quite get my head around mkgmap's logic and syntax.

Offline

#354 2018-12-03 13:53:41

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Polygons are never converted into routable lines. If you want to get something routable it must be specified in the lines style.
The reason why highway=services is being converted is because of the mob up rule.

# Mop up any unrecognised highway types
highway=* & highway!=proposed & area!=yes & highway!=pedestrian [0x07 road_class=0 road_speed=0 resolution 23] 

It is easy to ignore highway=services, just include highway!=services into the rule above.

Offline

#355 2018-12-04 01:27:02

Russ McD
Member
From: Hereford & Chiang Mai.
Registered: 2011-04-17
Posts: 234

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Thanks for looking at this.  Will the MKGMAP team now pick this up and action ?
And will that simple fix render the highway=services as a polygon, maybe even with a new Garmin hex code if there are any suitable ones left ? smile

Last edited by Russ McD (2018-12-04 01:30:31)

Offline

#356 2018-12-04 08:42:31

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

I can fix it for the generic routable new style maps but for the default mkgmap rules you have to discuss this on the mkgmap-dev mailing list.

Offline

#357 2018-12-04 16:01:08

GerdP
Member
Registered: 2015-12-18
Posts: 817

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Russ McD wrote:

Thanks for looking at this.  Will the MKGMAP team now pick this up and action ?
And will that simple fix render the highway=services as a polygon, maybe even with a new Garmin hex code if there are any suitable ones left ? smile

In the past, it was suggested to add area=yes for highway=services. This was changed in 2017:
https://wiki.openstreetmap.org/w/index. … id=1414117
So, yes, I think we should add a rule in mkgmap to handle this.

Online

#358 2018-12-05 12:43:59

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Russ McD wrote:

Thanks for looking at this.  Will the MKGMAP team now pick this up and action ?

Yes, they are working on this http://www.mkgmap.org.uk/pipermail/mkgm … 29261.html
Also a default typ file is being developed, so maybe Lambertus "new style" and old mapnik typ file can be replaced sooner or later.

Offline

#359 2018-12-25 05:59:05

Russ McD
Member
From: Hereford & Chiang Mai.
Registered: 2011-04-17
Posts: 234

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

On another issue, under the thread title of "missing requests", would the addition of a Traffic Light POI (& icon) to the styles be a difficult thing to add ?
It would make life a bit easier, when plotting on the go, to know which junctions have had the lights added, and which still need doing.
Russ.

Offline

#360 2018-12-26 09:36:07

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

It would be not difficult but it will create a lot of pois which will clutter the map and makes it unreadable on a small gps screen. Android maps like osmand render them but those maps have a much larger screen resolution so you can display more details.

Offline

#361 2018-12-27 02:59:29

Russ McD
Member
From: Hereford & Chiang Mai.
Registered: 2011-04-17
Posts: 234

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

OK noted.  As an interim measure, I used Overpass to pull out the nodes from the Thai map, then created a POI file along with a small icon.  It actually looks OK on the Zumo 400/550 and will work fine for me.
Anyway, appreciate the reply. 
Rgds, Russ.

Offline

#362 2019-07-15 18:32:36

iay
Member
From: Edinburgh
Registered: 2019-06-19
Posts: 4
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

I realise this thread may be less relevant with the recent availability issues at garmin.osm.nl, but is it still worth submitting issues for the styles here? I have spotted a couple of things that don't seem to be right.

A related question would be whether the garmin.osm.nl site automatically consumes these styles when they change, or if Lambertus needs to be involved?

My third question is perhaps a little tangential: I've tried building maps myself using the styles discussed here, but I haven't been able to exactly replicate what I get from the garmin.osm.nl site: it's probably just a missing option of some kind, or some kind of process issue. Are the scripts used by that site to actually generate maps available for inspection somewhere?

Offline

#363 2019-07-15 19:02:09

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

1) yes please go ahead and drop them here
2) yes, the latest style from github will be processed,  no need to contact him
3) the generic maps will use the default mkgmap style, the generic new styles you can find here: https://github.com/ligfietser/mkgmap-st … eric%20new

Offline

#364 2019-07-15 21:10:54

iay
Member
From: Edinburgh
Registered: 2019-06-19
Posts: 4
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

I should start by saying I'm fairly new to all of this and the learning cliff is pretty extreme but I think I'm starting to get my head round things. I've been using the garmin.osm.nl "generic new" maps as one of my map sets since I replaced my original GPS with a newer one after the GPS week roll-over.

I've been doing a bit of OSM editing in my area, but some things aren't -- or aren't entirely -- OSM data errors. The first thing I've dug deep enough that it looks like a style issue is that an area round where I live appears in the garmin.osm maps as "Nature Reserve", e.g., at N55.93251° W3.17980°. It's not a nature reserve.

This appears to be the rendering of this feature, which is a designated local cultural conservation area with restrictions on building types.

I think I have two problems here. The first is that it's a boundary=protected_area (correct) but that the original editor has set its subtype to protection_class=22 to indicate the kind of protected area. I think I'm right in saying that should actually be protect_class=22

It would be interesting to know if anyone agrees that's mistagged; obviously I can go in and fix it if so. It actually seems to be a common error in this city, with 25 occurrences in the .osm file, probably all by the same mapper.

However, I think that the current style would still render this area incorrectly because the polygons file says:

leisure=nature_reserve | boundary=protected_area | boundary=nature_reserve [0x16 resolution 20 continue]

There's no attention being paid to the value of protect_class (and even less so protection_class!) and in fact the only reference I can find to protect_class is also in polygons, like this:

boundary = national_park & protect_class > 2 {set boundary=nature_reserve}
boundary = national_park [0x16 resolution 18 continue]

In other words, any "protected area" ends up being a type 0x16 polygon, which is defined in the TYP file as follows:

[_polygon]
Type=0x16
String1=0x04,Nature reserve

So apart from the mistagging issue (if I'm right about that) I think the style would also need to be modified something like the following:

leisure=nature_reserve | (boundary=protected_area & protect_class<=2) | boundary=nature_reserve [0x16 resolution 20 continue]

That's not a real proposal, though, because the values of protect_class are really complicated. I wouldn't want to propose something that accidentally hid a lot of real nature reserves...

Sorry about the long explanation. It's mainly there because, as I say, I'm pretty new to this so I'm not sure which conclusions are correct and which are not. Over to the experts!

Offline

#365 2019-07-16 18:46:11

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Thanks for your remarks, protect_class is the correct tag, protection_class not and should be corrected.
I also agree with you that social-protected-areas are not equal to nature reserves.
So in the styles an exception should be made for protect_class=21-29
I can adapt the code like this, I have to test if it works:

boundary=protected_area & protect_class>=21 & protect_class<=29 {delete boundary}
leisure=nature_reserve | boundary=protected_area | boundary=nature_reserve [0x16 resolution 20 continue]

Offline

#366 2019-07-16 19:44:48

iay
Member
From: Edinburgh
Registered: 2019-06-19
Posts: 4
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Thanks, that proposal makes sense to me. I should also be able to put together a test too but it may take me a few days.

I'll go ahead and make the tag changes in the OSM data for my area; again, this will probably be a couple of days.

Offline

#367 2019-07-17 08:09:17

ligfietser
Moderator
Registered: 2008-10-09
Posts: 5,082
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Ian,
I've tested it and committed the changes into github, so it will be implemented in future updates, thanks!

Offline

#368 2019-07-17 09:12:27

iay
Member
From: Edinburgh
Registered: 2019-06-19
Posts: 4
Website

Re: Worldwide routable Garmin maps: Missing/incorrect feature requests

Fantastic. I figured out how to get JOSM to show me the other local cases and have uploaded a changeset fixing those.

Offline

Board footer

Powered by FluxBB