[mkgmap-dev] default style improvements
From Ticker Berkin rwb-mkgmap at jagit.co.uk on Mon Jan 7 10:47:35 GMT 2019
Hi On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote: > Bernhard Hiller <bhil at gmx.de> writes: > > > I often travel on bike in "nowhere land", where hotels and > > restaurants > > are rare. So I think it is good to show both PoIs if a hotel > > contains > > a restaurant. Of course, it would be more relevant to know how > > other > > users of OSM Garmin maps think about this topic (I use my own > > style, > > so the changes to the default style are not relevant for me). > > There are two issues; one is display, and the other is search. I > think > ti's pretty important that "show me cafes and restaurants nearby" > find > hotel restaurants (that are open to non-guests). I don't think it's > quite as important that they both show up. But when zoomed all the > way > in, it would be nice. Plus, mappers often put the hotel POI on the > building and a separate restuarant POI where the restaurant is. If the consensus is to have both 'Food & Drink' and 'Lodging' points, I'll can do it, preferably in a future change. There are many other cases like this; it's almost as if the default behaviour for 'points' processing should be [... continue ] > > A different point I'd like to suggest is a new line type for > > unpaved > > highways (which are not tracks). Unpaved public highways may be not > > very common in Europe, but they are rather normal in other areas of > > the world. > > The fact that they are rendered like paved highways makes many > > mappers > > think that it is useless to add this tag - and the little use of > > the > > surface tag in turn makes map makers think that it does not > > matter... Clouds of dust caused by other vehicles on that road or > > getting stuck in a muddy quagmire are not great user experiences. > > Treating them differently for routing purposes is a good step, but > > that is not such visible to many users. > > Agreed that unpaved public roads should have a different symbol. > (Even > where I am, in Massachusetts, US, they have a significant existence.) > > (I think the real reason they don't exist in the UK is that it's too > wet > and they would always be muddy. I drove on some roads there that are > so > minor that almost certainly would not have been paved in the US. > And > this UK non-existence of unpaved real roads has led to some > distortion > of their representation in OSM.) This request is slightly confused by 2 issues: 1/ The mkgmap/garmin attribute mkgmap:unpaved which is used by the routing option "avoid unpaved" on some (older?) Garmin devices to avoid unpaved roads. 2/ The line type 0x0a = "Unpaved Road" being used by the default style for highway=track, highway=unsurfaced and railway=abandoned Is the existing setting in the default style of mkgmap:unpaved (based on tags surface, mtb:scale, tracktype, sac_scale) adequate, or are there other tags/values that need to considered? Are you thinking of having another line type? The default style has used all but 1 of the non-extended road types that show on newer devices without a typ-file specification; and I was thinking of using the last one (0x0b) as the Hint portion of a *_link instead of 0x06, which is also used for highway=minor & highway=unclassified Which highway types should be changed, eg unclassified, minor, tertiary, *_link, ... motorway? Should this new road type have the same [road_class road_speed resolution] attributes as the existing highway that it is replacing or can it just have a single fixed set of these attributes? Given answers to these questions, it can be done, but again, in some future change Ticker > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
- Previous message: [mkgmap-dev] default style improvements
- Next message: [mkgmap-dev] line types for unpaved roads (was default style improvements)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list