[mkgmap-dev] Pending changes

Wed Feb 17 09:47:52 GMT 2021

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