Worldwide routable Garmin maps: Missing/incorrect feature requests

I will add this as test:


(place=hamlet | place=locality | boundary=estate |  place=isolated_dwelling) & boundary=administrative [0x1f00 resolution 24]
(place=hamlet | place=locality | boundary=estate |  place=isolated_dwelling) & boundary!=administrative [0x0b00 resolution 24]

In the typ file 0x1f00 will be rendered in grey without dot. Resolution 18 might be useful in empty areas like yours but clutters the maps in highly populated regions like Western Europe. I noticed in your example there are a lot of single place=locality nodes as well as place=locality on boundaries. IMHO this should be avoided. You could make this single node part of that relation (as administrative centre) but with a locality this looks like tagging for the renderer.

Many thanks ligfietser,

What you have tested looks good to me. Your experience will be best in deciding appropriate resolutions. I don’t like labels to appear, then disappear, then appear again as one zooms in, but that may just be a glitch in BaseCamp.

From what I can see in OSM someone has added Australian level 10 administrative boundaries (parishes in government parlance, used mainly in property deeds these days) and left the place labels to default to the centre of each admin area (which is easy and sensible, but it does create confusion if the parish name is derived from another feature in the parish - which is common - and if both are rendered identically without user control). I take your point that in OSM the parish names could be anchored elsewhere. This is actually flagged as fixme in OSM, which does not trust the defaults, though an argument could also be made to leave all area labels in the centre of the area (or along the boundary as used by Mapnik).

Moreover, moving selected admin area labels to coincide with an eponymous locally-recognised ‘locality’ would not solve the problem that many admin areas share the name of a hamlet, village, or larger population centre located somewhere in the admin area.

So I think what you have tested is a good compromise. It renders the admin area labels in a distinct way. Sometimes we get two labels with the same name (see “Upper Main Arm”) but your tested method makes it obvious what kind of feature each represents. Also, by using a distinct TYP code you have allowed users to tailor (or not display) the admin area labels if so desired.

Your tested method does not distinguish between localities (areas, not necessarily administrative) and hamlets (small population centres at a ‘point’ location), which I think could be done usefully without clutter, but I bow to your experience.

Also your approach might be extended to places other than localities and hamlets (e.g. villages and towns). Billinudgel is the name of both a parish (admin area) and village, which is shown only on the village in your test above, though I am not sure why from the style information you posted.

Thanks again for all your work.

Just add a node with tag place=city|town|village|hamlet, and add it to the boundary relation with role “label”.
Both the node and the relation are representations of the same real feature, so the role is “label” and not “admin_centre”.

Mapnik renders as expected, nominatim understand the data as expected, and with maps compiled by mkgmap in the Garmin (at least in nuvi) the streets are assoociated to the right place, and if you ask the route to that place you are directed to the node.

That might be a bug, or might be not. Can you give an exact location / place name where this happens? I recently noticed the same with some city place names (type 0x04) where it seemed to matter in which font (large or normal) it was defined in the typ file. In the normal font the place names disappeared at a certain zoom level (bug in Basecamp). This might be the same case as yours.
Another explanation is that there isnt enough space to show the label. Basecamp decides which one to show and which one not, you can only control this by making the fonts smaller.

Yes, I can add that later, but let’s first see how this goes, one step at a time.
What should be fixed first is to remove place tags either from the boundaries or those single nodes if both represent the same thing, but both are entered to please the renderers. Using a single node somewhere in the centre of the area, which is part of the boundary relation and with role=label is the best way to go (thanks Muralito). Is that the case, than the tag place=locality on the boundary should be removed.
If you use both, there will be double names rendered on different places.

It’s because of the zoom level, I see two labels with ‘Billinudgel’ as I zoom further in, because the village renders earlier.

That’s a good example.
Here http://www.openstreetmap.org/relation/6069698 is Billinudgel a place=locality
And then you have a place=village with the same name, https://www.openstreetmap.org/node/113763292.
You can add role=label but this is not what you want right?

There are many cases like this, also with cities, towns, counties etc
I prefer not to render those names because it leads to cluttering and confusion. If someone wants to find the village centre of Billinudgel he sees two features. In the Netherlands we have decided not to put a tag place=* on boundary areas at all. I dont know what common practise is for OSM in general?

Thanks ligfietser and muralito. I still have a lot to learn (not just about OSM). So I am reluctant to edit features added by someone else to OSM, particularly when they may have good reasons to label a certain way. However, when the translation to garmin uses separate TYP codes for the different feature classes (OSM tags) anyone can control whether/how the labels appear on their personal maps. I agree with the Netherlands convention not to put a tag place=* on boundary areas, and I can achieve that for my own maps (without offending anyone on OSM) if a separate TYP code is used as tested above by ligfietser.

In the specific example we have discussed, I am not convinced that the parishes and eponymous localities or hamlets represent the same thing. The ‘parish’ is an administrative area (which often has no administrative centre: that occurs several layers up at shire or city level - ‘local government areas’ in Australian political parlance). Someone interested in title deeds may be interested in the parish name and geographic location (or may be happy that the parish label if used is consistently at the geographic centre). On the other hand, if you ask a local for directions to a ‘locality’, they will send you to an accessible and likely populated area (albeit sometimes sparsely populated) that may be some distance from the geographic centre of an eponymous parish. This can be important for example to emergency services responding to a request for assistance from a locality. Hamlets, villages and towns are easy as they have more defined boundaries (often with a road sign) and the mapping convention is to show a dot at their centre. It would be good to be able to distinguish these different types of places on the map (hopefully in the future).

Regarding examples of labels that come and go during zoom, in ligfietser’s test map above (post #294) some parish labels show (Upper Main Arm, Palmwoods, Yelgun etc.) while others do not (Main Arm, The Pocket, Middle Pocket, Billinudgel) even at the same zoom level. Some seem to be in clear areas (like Main Arm, well South of the hamlet of Main Arm). For me in BaseCamp, parish labels of Main Arm and The Pocket often blink on-off-on as I zoom in, but it is complicated. Sometimes once ‘Main Arm’ parish label has appeared at close zoom it stays on when later zoomed out. Also the behaviour for some labels depends whether I have added a transparent contour overlayer to the (new style) base map. So as ligfietser says it may well be BaseCamp working to avoid clashes of some kind. In any case, it is one reason for me to use the capability for ExtendedLabels=Y, FontStyle=NoLabel (invisible) on an unwanted label type (such as OSM boundary=administrative & place=locality) if that is made possible by use of distinct TYP codes, as in ligfietser’s test.

In case anyone has been interested in the identity of the admin-boundary-derived ‘localities’ mentioned above, after closer inspection I think they are neither parishes (largely historical cadastral admin areas) nor current ABS SSCs (statistical areas) nor current gazetted ‘Localities and State Suburbs’ (officially recognised area names); but they may be ‘suburbs’ as shown on some (presumably out-dated) maps such as the NSW base map that can be viewed on the LPI SIX website (consistent with the source tag). For example, Palmwoods is included under Main Arm and Middle Pocket is included under The Pocket in current ‘State Suburbs’. See for example http://betaworks.abs.gov.au/betaworks/betaworks.nsf/projects/ASGSBoundariesOnline/frame.htm

But this does not alter (except to strengthen) the underlying propositions:

(i) Localities as identified by locals frequently do not coincide with the geographic centre of an eponymous administrative area (defined by a boundary that governments are free to change over time).

(ii) It is probably better not to label administrative areas in OSM, to avoid confusion with eponymous localities, hamlets, villages, towns, cities, shires etc.

(iii) But because some OSM contributors will label administrative areas, it is very helpful if the (mkgmap) conversion styles assign these to different TYP codes, so that users can choose which labels they wish to display on their own maps/computers/GPSr units.

(iv) It would also be good to use a separate TYP code for non-admin-area-derived localities, so that these can be displayed as areas (no place dot) as distinct from hamlets, villages, towns etc which can logically and by convention be associated with a dot location on a map.

The MPC TYP codes seem to allow this by:
OSM boundary=administrative & place=locality (or anything below state level): Point Type 01f/00 (county)
OSM place=locality & boundary!=*: Point Type 064/0a (locale)
OSM place=hamlet; Point Type 00c/00 (town < 5K)
Other OSM place tags can translate to other Point Types (depending on current population) as noted above.

If the boundaries themselves are desired for display, MPC offers these Line Types (again lifted from TYPViewer):
Type=0x1c: Major political boundary (typically used for state, provincial borders)
Type=0x1d: Minor political boundary (typically used for county/parish borders)
Type=0x1e: International boundary

On roads

surface=compacted

should be rendered as unpaved.

Thanks,
Peter.

Not sure which map you are looking at but that is already implemented Peter:

# Flag unpaved roads.
highway=*
& (surface=cobblestone | surface=compacted | surface=dirt |
   surface=earth | surface=grass | surface=grass_paver |
   surface=gravel | surface=grit | surface=ground | surface=mud |
   surface=pebblestone | surface=sand | surface=unpaved |
   mtb:scale=* |
   tracktype ~ 'grade[2-6]' |
   smoothness ~ '.*(bad|horrible|impassable)' |
   sac_scale ~ '.*(mountain|alpine)_hiking' |
   sport=via_ferrata)
{ add mkgmap:unpaved=1 }

You are correct, it is. It’s just that it is nearly invisible, like here:

If you zoom in the brown dashes disappear, if you zoom out they become so small they become obscure.

Is this different from how other dirt roads are displayed? I have seen many where it is very well visible. What’s more, when I put my mouse pointer on them I get two info boxes, one of them saying “unpaved”. This doesn’t happen here.

Thanks for your time.

I think it depends on the OSM highway tags. It is not a highway=track (normal dirt roads) but a tertiary, those are maybe too wide for the dashed lines?
You can change that by editing the typ file. I’m not sure why you don’t see that label ‘unpaved’


[_line]
Type=0x10002
UseOrientation=N
Xpm="32 7 2  1"
"! c #7B6500"
"  c none"
"!!!!!!  !!!!!!  !!!!!!  !!!!!!  "
"!!!!!!  !!!!!!  !!!!!!  !!!!!!  "
"                                "
"                                "
"                                "
"                                "
"                                "
;12345678901234567890123456789012
String1=0x04,unpaved
String2=0x03,onverhard
String3=0x02,Unbefestigt
String4=0x01,sans revêtement
ExtendedLabels=Y
FontStyle=NoLabel (invisible)
CustomColor=No
[end]

I have found out that the ref tag is the cause, without ref or name tag, the label unpaved is rendered.
I dont know how to solve this, I can’t remove the ref or name tag unfortunately.

Edit: found a mkgmap option ‘addlabel unpaved’ and committed it to the style sheet. I also made ‘ice_roads’ not routable. https://github.com/ligfietser/mkgmap-style-sheets/commit/31b7b63845e75fb1ab4a62bb39b3230c38f631f5

All good, thanks for that. At least, the option to not route over unpaved works.

Another one: paved tracks are rendered as unpaved roads. I assume the routing engines treat them as unpaved. I realise that in Europe a lot of these are closed to motor vehicles and whence routing thru them is probably undesirable. In Thailand there is a continuum from unpaved tracks to paved tracks to small roads, all usable by any vehicle that physically fits. It is desirable to get routed thru anything paved.

Regards,
Peter.

Depends what someone calls paved and what unpaved. That really makes a difference in what country you are. Guess the situation in Thailand is very different than Europe. For my OFM I consider tracks with grade1 or surface=asphalt as paved (same rendering as paved unclassified). Is that what you have in mind?

I have found that

highway=track
surface=paved

is rendered as an unpaved road and when you put the mouse pointer over it it says: “unpaved road”.

In Thailand most small roads and residential streets have a concrete surface.

You are absolutely right Peter. Looking at the generic new styles, the rule that is causing this issue is this one:

(highway=bridleway | highway=path | highway=track | highway=unsurfaced)
& surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
{ add mkgmap:unpaved=1 }

If my interpretation is correct, it says that all those types of highway are considered as unpaved, unless there is a surface, tracktype, smoothness AND sac_scale parameter! This rule makes no sense at all so must be corrected. The mkgmap default rule is the same so I will discuss this on the mkgmap-dev list first.

In the default style the rule is preceded by this one:

highway=*
& (surface=cobblestone | surface=compacted | surface=dirt |
   surface=earth | surface=grass | surface=grass_paver |
   surface=gravel | surface=grit | surface=ground | surface=mud |
   surface=pebblestone | surface=sand | surface=unpaved |
   mtb:scale=* |
   tracktype ~ 'grade[2-6]' |
   smoothness ~ '.*(bad|horrible|impassable)' |
   sac_scale ~ '.*(mountain|alpine)_hiking' |
   sport=via_ferrata)
{ add mkgmap:unpaved=1 } 

So I think the rule is not that wrong.

I dont understand it Gerd. What does “&” mean then? To me it says make highway=track unpaved if surface AND tracktype AND smoothness AND sac_scale are not empty. Otherwise I cant explain why surface=paved is set unpaved by mkgmap?

I also understand the rule like that.
It should not set mkgmap:unpaved=1 for a way with highway=track and surface=paved
I did not yet try it. If it does I’d say something is wrong in mkgmap.

Now I’ve tested it, and it worked ok. Even with avoidance. The only thing that is not correct is the generic new typ file, it still says unpaved because that is the label if there is no streetname. I can try to correct it by adding a second label.
But still, the syntax is a bit strange: & surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*

Unpaved will not be applied if one of those values is not empty, and I read it as ALL of above values must be not empty.
And then it is still not correct. Say someone tagged the track with surface=soil (1014 values in OSM, but not specified as unpaved by mkgmap). It is better specify a rule like

highway=track & surface! ~ '.*(paved|asphalt|sett|concrete|paving_stones|metal|wood)' { add mkgmap:unpaved=1 } 

And what about cobblestone? Paved or unpaved?