You are not logged in.

#276 2015-09-13 21:52:22

groen_duiven
Member
From: Duiven (Gelderland)
Registered: 2011-07-26
Posts: 161

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

Not quite sure if I have to post it here ?

I've downloaded Routable Bicycle (Openfietsmap Light) Ontario version 10-09-2015

In Openstreetmap I see parking spaces written as:
Amenity = parking
parking=surface
surface-=asphalt

After installing I see (for example: Hamilton (ON) - King William Street only car towing truck as pictogram.
Here a screenshot: https://onedrive.live.com/redir?resid=4 … F75%213135
What goes wrong ?

groen_duiven

Offline

#277 2015-09-23 19:38:24

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

Typ file seems missing.
Maybe try a fresh download, if it still missing, you could post the download link here.

Offline

#278 2015-09-24 21:38:37

groen_duiven
Member
From: Duiven (Gelderland)
Registered: 2011-07-26
Posts: 161

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

After downloading new map of Ontario  (version 16-09-2015) problem solved.

In the version of 10-09-2015 were more strange things. In parks there were many watertaps instead of benches.


groen_duiven

Offline

#279 2015-09-25 08:48:14

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

Thats because I have to use other Garmin types to make some cycling features findable. I use parking for bicycle parking, normal car parks I have to shift to another garmin type, like towing truck ;-)
If the map does not have the original typ file, those "hacks" become visible. Maybe by some compiling error on the server of the map generation the typ file was lost?

Offline

#280 2015-11-05 00:23:56

beej71
Member
Registered: 2015-11-03
Posts: 5

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

Hi folks,

I downloaded the Lambertus osm_generic_new_gmapsupp.zip North America/Oregon Generic Routable (new style) and installed it on my Garmin GPSMap62st.

Looks really good, but I've noticed a couple potentially-missing items:

From https://www.openstreetmap.org/#map=19/4 … -121.35297

leisure=playground [point]

garmin-no-playground.png

From https://www.openstreetmap.org/#map=16/44.2548/-121.1544

lines associated with aeroway [ways], though the labels appear

garmin-no-airport.png

Ideas? Thanks!

Offline

#281 2015-11-05 08:26:36

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

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

Not all features found in OSM are being compiled into the Garmin maps. You would not be able to discern much on the map, if they were all there. I'm sure playgrounds are not included. After all, the Garmin maps are mainly intended for navigation.

The runways, however, should be visible, since their labels show up. I wonder whether that is a colour problem.

Offline

#282 2015-11-05 13:01:41

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

@beej71:
Leisure=playground is a feature that IS included, have a look at the polygon style
https://github.com/ligfietser/mkgmap-st … w/polygons

The problem with your shape is that you are using the highways also for the borders of the leisure=playground shape.
I don't think this is common practice on OSM and should be avoided, at least it will lead to rendering issues on the Garmin maps. It will draw the ways first and then the processing stops, it does not expect that those ways double as line for other shapes as well. Only in certain features (plazas, parking lots etc) ways are rendered as polygon shapes too.

About the runway line type, I use type 0x27, which is visible in Basecamp.
https://github.com/ligfietser/mkgmap-st … 0new/lines

Maybe this line type is invisible on the GPS (I havent specified a shape for it in the TYP file), I will have a look on this issue on my Oregon.
If you want to experiment it yourself, I can recommend the TYP file editor Typviewer.

Offline

#283 2015-11-05 13:16:14

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

ligfietser wrote:

The problem with your shape is that you are using the highways also for the borders of the leisure=playground shape.

Oops, the shape I meant was referring to leisure=park which is rendered fine, my mistake.

You mean this feature https://www.openstreetmap.org/node/3728637353

It should be rendered with leisure=playground [0x2c06 resolution 24] but I made point 0x2c06 invisible because it is also used for labels of leisure=park, garden etc otherwise it would clutter the map. If you give this feature a name the label would show up.

Offline

#284 2015-11-05 16:08:49

beej71
Member
Registered: 2015-11-03
Posts: 5

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

Cool. Thanks for the info! I'll try to learn more about this to see if I can troubleshoot it myself, as well.

Cheers,
-Beej

Offline

#285 2015-11-05 17:42:18

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

Beej,
On my Oregon the type 0x27 (runways) were invisible too. Strange, because 0x27 was the default Garmin typ for runways.
Apparently something has happened in the firmware and those lines are not rendered anymore without a typ file?
Anyway, I added this type to the TYP file so next time it will be rendered on the device.
You can download the improved file here:
https://github.com/ligfietser/mkgmap-st … w/2000.typ (view raw to download it)

Thanks for reporting this!

Offline

#286 2016-02-17 09:48:57

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

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

Feature request ....
We plot a lot of GPS tracks over here in the jungles of Thailand .... To aid differentiating those that genuinely dead end, against those that just might have stopped for another reason (jungle canopy/cloud cover on traced tracks, etc), ...when physically verified, we tag the last node as noexit=yes
Is there any way a small "no-through road" icon (similar to that used on road signs) can be added into the mkgmap latest style to pick up on this noexit tag, and have it display on the units at higher zoom levels ?

Offline

#287 2016-02-17 12:24:45

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

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

You mean a sign like this one?

120px-France_road_sign_C13a.svg.png

The only problem I can see is that there is no universal sign that is used and understood everywhere. I wonder whether we could give it the name "Road ends" such, that it only shows when the cursor hovers above it. That way people can find out what it means, but the maps won't be cluttered with redundant labels.

Last edited by Beddhist (2016-02-17 12:28:02)

Offline

#288 2016-02-17 17:05:55

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

Only a name would be very difficult to find. I can make a small icon like this, but we unfortunately cannot control the zoom levels anymore in Basecamp and the newer devices (only in Mapsource), so it might clutter the map at lower zoom levels. Only if i make it very tiny it will be acceptable?*
523.bmp?raw=1

*) I'm afraid it will clutter the map in areas like here: http://overpass-turbo.eu/s/et1

Offline

#289 2016-02-17 17:34:49

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

This doesn't look good... sad

no%20through%20road.jpg?raw=1

Offline

#290 2016-02-17 21:11:53

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

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

Very good examples. Thanks ligfietser. I was wondering whether this would happen. hmm Is this rendered at the highest zoom only?

I don't think they need to be findable.

Russ, try loading the data from overpass into a gpx file. You can then use Garmin POILoader to load them into your GPS.

Regards,
Peter.

Offline

#291 2016-02-17 21:36:15

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

No unfortunately not the highest zoomlevel (otherwise you would see much more pois, shops cafes parking lots etc).
At this lower zoom only the not supported poi types are rendered. Garmin does not have a default poi for no exit, so I have to use a marine or other poi type. Those poi types appear at lower zoom levels no matter what I have set in mkgmap. So yes, I think it's better to download pois with overpass. Or create your own custom map with mkgmap.

Offline

#292 2016-02-18 02:05:14

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

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

Thanks for the replies... and Yes, I was wondering if it would add a lot of clutter in the cities.  I have also taken a look at the wiki more closely, and after seeing that in encourages the use of the noexit tag where traced tracks disappear under clouds, then this would not really serve a purpose after all.
If by hovering the cursor, the text appears, then great, but in the mean time I appreciate the recommendation to make a POI file for Thailand and will implement that as a solution. 
Rgds.

Offline

#293 2016-04-06 02:57:43

moreton
Member
Registered: 2016-03-11
Posts: 20

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

Could OSM Tags: boundary=administrative (with a place tag), place=locality and place=hamlet be translated into distinct garmin POI type codes? At present, (at least in the new style) they all appear to be assigned to 00b/00. This causes duplication and confusing rendering in some areas because (i) admin areas (with a place=locality tag) and localities are rendered with a dot, whereas they are intended as areas rather than point locations; (ii) an admin area is labelled by default at its geographic centre, which may be in rough topography away from the accessible or populated area locally recognised as a locality, or a named hamlet, which commonly shares the name of the admin area.

An example is the area around www.openstreetmap.org/#map=15/-28.4976/153.4969

Standard OSM rendering handles it well by showing admin area names only as boundary labels (and only at high zoom), and showing localities as areas (no dot). Admittedly, population centres such as hamlets, villages etc are also shown without a dot, but that works OK in Mapnik.

If these OSM tags were translated as separate garmin type codes, interested users could modify TYP files to eliminate the duplication of names and/or use label types that indicate the feature type.

Suggested translations are:
OSM boundary=administrative & place=locality: POI Type 01f/00 (county or parish)
OSM place=locality: POI Type 064/0a (locale)?
OSM place=hamlet; POI Type 00c/00 (town < 50K)

These features could then be distinguished with TYP entries like:
-------------------------------
[_point]
Type=0x00c
SubType=0x00
;GRMN_TYPE: Small city or town center, typically less than 50K inhabitants/Non NT
String1=0x04,Small town
ExtendedLabels=Y
FontStyle=NormalFont
CustomColor=No
DayXpm="3 3 1 1"   Colormode=0
"!    c #000000"
"!!!"
"!!!"
"!!!"
[end]

[_point]
Type=0x01f
SubType=0x00
;GRMN_TYPE: County or parish center/Non NT, NT
String1=0x04,County or parish
ExtendedLabels=Y
FontStyle=NoLabel (invisible)
CustomColor=No
DayXpm="1 1 2 1"   Colormode=16
"!    c #C0C0C0"
"      c none"
" "
[end]

[_point]
Type=0x064
SubType=0x0a
;GRMN_TYPE: Geographical Named Locale/Non NT, NT
String1=0x04,Locality
ExtendedLabels=Y
FontStyle=NormalFont
CustomColor=DayAndNight
DaycustomColor:#838383
NightcustomColor:#838383
DayXpm="1 1 2 1"   Colormode=16
"!    c #C0C0C0"
"      c none"
" "
[end]
------------------------------------

My suggestion is to set all of the above features to appear at about the same zoom level (around resolution = 18 or 19 bits), and not then disappear at some higher zoom levels (as occurs at present for some of these labels in BaseCamp, which may be a law unto itself).

Larger population centres are perhaps already translated into corresponding Garmin POI types (lifted from TYPViewer):
0x00100=Large city with >10 million inhabitants/Non NT
0x00200=Large city center, typically 1M+ inhabitants/Non NT
0x00300=Large city with a range of (2-5] million inhabitants/Non NT
0x00400=Large city with a range of (1-2] million inhabitants/Non NT
0x00500=City with the range of (0.5-1] million inhabitants/Non NT
0x00600=City with the range of (200-500] thousand inhabitants/Non NT
0x00700=City with the range of (100-200] thousand inhabitants/Non NT
0x00800=Medium city center, typically 50K-1M inhabitants/Non NT
0x00900=City with the range of (20-50] thousand inhabitants/Non NT
0x00a00=City with the range of (10-20] thousand inhabitants/Non NT
0x00b00=City with the range of (5-10] thousand inhabitants/Non NT
0x00c00=Small city or town center, typically less than 50K inhabitants/Non NT
0x00d00=City of unknown population/Non NT

Offline

#294 2016-04-06 13:27:25

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

Re: 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.

place_locality.jpg?raw=1

Offline

#295 2016-04-06 23:50:04

moreton
Member
Registered: 2016-03-11
Posts: 20

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

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.

Offline

#296 2016-04-07 00:30:50

muralito
Member
Registered: 2012-09-04
Posts: 1,851

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

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.

Offline

#297 2016-04-07 08:42:50

ligfietser
Member
Registered: 2008-10-09
Posts: 5,224
Website

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

moreton wrote:

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.

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.

moreton wrote:

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.

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.

moreton wrote:

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.

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?

place_locality2.jpg?raw=1

Offline

#298 2016-04-08 02:39:44

moreton
Member
Registered: 2016-03-11
Posts: 20

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

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.

Offline

#299 2016-04-10 07:37:11

moreton
Member
Registered: 2016-03-11
Posts: 20

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

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/b … /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

Last edited by moreton (2016-04-11 01:07:05)

Offline

#300 2017-01-21 23:51:34

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

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

On roads

surface=compacted

should be rendered as unpaved.

Thanks,
Peter.

Offline

Board footer

Powered by FluxBB