[mkgmap-dev] Pending changes

Wed Feb 17 14:12:14 GMT 2021

HI all

I agree with Ticker default style is a good source of ideas for both new 
and experienced users (at least it is to me) and as such, more is 
better, but I also see Gerd's point about new users getting blocked by 
too many or complicated rules. I think comments about those complicated 
rules, as Ticker adds in some cases, may help circumvent that problem, 
or may be some kind of <advanced></advanced> tagging.

El 17/2/21 a las 11:02, Gerd Petermann escribió:
> Hi Ticker,
>
> I agree that the default style is a starting point and because of that I think "less is better":
> 1) The more stuff we put into the default style the less likely it becomes that a newbe will try to understand it. I think it is more likely that users will try to add a rule for something that they miss instead of working through hundredts of complicated rules to find out what can be (hast to be) removed without risking to loose anything important.
> 2) The screens of many (most?) Garmin devices are too small for lots of details, the details are simply confusing anyone who's not interested in OSM but just wants a routable map for free.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Mittwoch, 17. Februar 2021 10:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Pending changes
>
> Hi Gerd
>
> My views on this.
>
> For most of mkgmap /resources/ (styles, typ-files, documentation,
> roadNameConfig.txt, sample.cfg) you don't need to decide if the change
> is good or bad, and, almost by definition, it is all cosmetic.
>
> Change requests go through this forum for discussion. After any
> refinements necessary, the changes can be incorporated into trunk. It
> is very unlikely that this will cause Map generation will become
> 'broken'. Mostly, it seems, no one much cares because they use their
> own styles, TYP files etc.
>
> I view the default style (and the other resources) as a starting point
> for new users and a source of ideas for existing users.
>
> It is the ideal place to put rules/comments on any sort of issue that
> can be addressed by a style. Generally, more is better; it is easy for
> a new user to start with lots and gradually comment out elements they
> don't want.
>
> Whenever I notice something that could be improved on my maps, or a
> good idea floating around the forum, I incorporated it into my files
> and try it. Every now and again, I try to get what I consider
> improvements into mkgmap. This isn't for my benefit but, I hope, other
> people might benefit from it.
>
> Similarly, mapnik.txt is a good place to put element translations (it
> would be nice if we came up with a mechanism where this translation
> effort could be shared by any TYP file).
>
> The core/java code is a different matter and I'm very grateful for your
> amazing work on "keeping it all together"
>
> Ticker
>
> On Fri, 2021-02-12 at 09:51 +0000, Gerd Petermann wrote:
>> Hi all,
>>
>> I have no idea what to do with patches for default style or typ
>> files. I can decide if I like a patch when I understand what's wrong
>> with the unpatched version, but I don't want to spent my time on
>> cosmetic changes. I simply don't know how to decide if a patch is
>> good or bad unless someone has a good example that shows a problem
>> with the unpatched version (only one problem if possible).
>>
>> I see two ways to handle this:
>> 1) Steve gives Ticker and /or Joris the right to commit changes to
>> trunk or
>> 2) Ticker and Joris create their own branch(es), either in the mkgmap
>> svn repo or somewhere else.
>>
>> ciao,
>> Gerd
>>
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
>> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
>> Gesendet: Freitag, 12. Februar 2021 10:37
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Pending changes
>>
>> Hi Carlos
>>
>> Some bridges are a bit of a strange case. There are a lot of areas
>> where I walk that are crossed by many small streams and no formal
>> paths, but, here and there, there are foot bridges over the streams.
>> These are normally mapped as [highway=path/footway, bridge=yes] and
>> mostly don't connect to anything, but sometime to another bridge or a
>> short section of unconnecting path.
>>
>> I want to see these on the map, but the little bits of highway will
>> just cause a routing error if they are picked up as the start or end
>> of
>> a route; hence my changes.
>>
>> The only problem I see is if the bridge/highway is connected to the
>> highway network at one end only and you want to generate a route with
>> the start or end your of your journey the other side of bridge, then
>> the routing algo might find another, closer start/end point.
>>
>> I could change it to be just 'set_unconnected_type' but I considered
>> the benefits and frequency of fixing paired isolated highway bits
>> outweighed an incorrect start/end point, which can be overcome by
>> simply starting the journey in the sensible way and the device will
>> recalculate or looking at the end-point route and, seeing it is
>> stupid,
>> choosing a better end-point.
>>
>> Ticker
>>
>> On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:
>>> Regarding your extra comment on #3, would it be really the case for
>>> bridges? What about any connected highway=* + bridge=yes?
>>>
>>> No objection for new additional changes
>>>
>>> El 11/2/21 a las 15:57, Ticker Berkin escribió:
>>>> Hi all
>>>>
>>>> I've re-made this set of changes, along with a few improvements
>>>> that
>>>> I've gathered over the last 6 months. Following list numbering is
>>>> the
>>>> same as original patch, but include some [extra] notes + new
>>>> items
>>>> at
>>>> the end.
>>>>
>>>> Relevant threads:
>>>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
>>>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
>>>>
>>>> 1/ Sometimes charges for using a pedestrian highway are expressed
>>>> as a
>>>> fee rather than a toll, so pick this up in mkgmap:toll.
>>>>
>>>> 2/ Show bridges using type 0x10107. With the mapnik addition,
>>>> these
>>>> look good for narrow highways, but might not show for wide
>>>> representations like motorways.
>>>>
>>>> 3/ Where it is likely that bits of highway might not be connected
>>>> to
>>>> the road/path system, use mkgmap:set_unconnected_type and
>>>> mkgmap:set_semi_connected_type to stop the NET/NOD rather than
>>>> relying
>>>> on NETnoNOD (now disabled) and --check-routing-island-len=+ve,
>>>> which is
>>>> being suspected of causing problems on some devices and BaseCamp.
>>>>
>>>> [extra] In all cases where unconnected/semi-connected changes are
>>>> mentioned, this only applies to lines not derived from an
>>>> original/OSM
>>>> standard highway.
>>>>
>>>> 4/ Quote some filter subst strings that contain spaces - no
>>>> actual
>>>> effect but clearer and safer.
>>>>
>>>> 5/ Have line for leisure=track even if area.
>>>>
>>>> 6/ Change the type for tracks/raceways etc from 0x30, which
>>>> doesn't
>>>> show on BaseCamp or MapSource, to 0x2a.
>>>>
>>>> 7/ For piers, if 'unconnecting', use marine type 0x1040c
>>>> (Obstruction:
>>>> Pier or Jetty) instead of footway.
>>>>
>>>> 8/ Change type for the various barriers from 0x17, which doesn't
>>>> show
>>>> on BaseCamp to 0x2b, see:
>>>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
>>>>
>>>> 9/ Consider natural=cliff a barrier.
>>>>
>>>> 10/ Add motorway[_link] roundabouts (yes, some do exist).
>>>>
>>>> 11/ Unquote some numbers - no actual effect.
>>>>
>>>> 12/ Tweak some road speeds.
>>>> [extra] A few more tweaked.
>>>>
>>>> 13/ Use 0x09 (high-speed ramp) for road class 4 links
>>>>
>>>> 14/ Add footway around car parks if 'connecting'.
>>>> [extra] This change is disabled.
>>>>
>>>> 15/ Disable coastline. For a long time the tag was suppressed by
>>>> the
>>>> Sea processing and it adds little to the map.
>>>>
>>>> 16/ Improve railway platform names and suppress footway if not
>>>> 'connecting'.
>>>>
>>>> 17/ Show disused:railway in the same way as railway=disused.
>>>>
>>>> 18/ Have cable_car, gondola, funicular as routable, by default
>>>> with
>>>> a
>>>> toll and pedestrian only.
>>>>
>>>> 19/ Show "Course of old Railway", unless a highway has taken over
>>>> the
>>>> way (for you Eric, but I like it as well).
>>>> [extra] This change is disabled
>>>>
>>>> 20/ Speed up car ferries.
>>>>
>>>> 21/ A few other layout/space fixes.
>>>>
>>>> Additional changes:
>>>>
>>>> 22/ motorroad=yes just sets mkgmap:fast_road, which generally
>>>> increases
>>>> the speed/class of the highway and decreases the resolution
>>>>
>>>> 23/ natural=landslide like other barriers (eg cliff)
>>>>
>>>> 24/ Don't generate (routable) line for highway=unclassified &
>>>> area=yes;
>>>> there are many instances in OSM where this is used to draw a
>>>> polygon
>>>> around a complex junction.
>>>>
>>>> 25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
>>>>
>>>> 26/ For ferry/platform/aerialway, blank out address fields to
>>>> prevent
>>>> it getting into the Address index
>>>>
>>>> 27/ Add comment about colour pallet to mapnik.txt
>>>>
>>>> Patch attached
>>>>
>>>> Ticker
>>>>
>>>> On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
>>>>> On [1] Ticker proposed a set of changes to default style lines
>>>>> file.
>>>>> There was a long discussion about point #14, which ended
>>>>> without
>>>>> a
>>>>> consensus. Other changes didn't get any objection, but they
>>>>> didn't
>>>>> get
>>>>> into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also
>>>>> with 7
>>>>> and 16, but for unconnected ways only, see #3.
>>>>>
>>>>> 2: more codes could be added for wider highways and their
>>>>> corresponding
>>>>> entries in mapnik.txt
>>>>>
>>>>> 3: not sure about this one, specially about semi-connected
>>>>> ways,
>>>>> which I
>>>>> think should remain as routable (also applies for 7, 16).
>>>>>
>>>>> [1]
>>>>> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm
>>>>> l
>>>>>
>>>>> _______________________________________________
>>>>> mkgmap-dev mailing list
>>>>> mkgmap-dev at lists.mkgmap.org.uk
>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>
>>>>> _______________________________________________
>>>>> mkgmap-dev mailing list
>>>>> mkgmap-dev at lists.mkgmap.org.uk
>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>> _______________________________________________
>>> mkgmap-dev mailing list
>>> mkgmap-dev at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev