Hi
Is it a particular problem to never merge ferry lines? If derived from
a relation, what elements is the relation using? Probably these
shouldn't be merged either.
Ticker
On Mon, 2021-05-10 at 09:57 +, Gerd Petermann wrote:
> Hi all,
>
> found another problem: In what situation should Ro
Hi all
Maybe railway=platform shouldn't generate a routable line.
Pure duplication of (parts of) roads with identical Garmin img
attributes could be suppressed. These could come from duplication by
the style or distinct OSM ways. In the case of platform=railway, I'd
have thought it to be better m
much
> else use of a division factor for values that I can think of. So
> right now only 3.28, 3.28^2, 3.28^3 and so on is possible (i did not
> actually check if it is possible to convert twice, but think so).
>
> On Fri, 7 May 2021 at 16:56, Ticker Berkin
> wrote:
>
Hi Felix
I don't think there is any way to do maths on tag values.
It should not be too difficult to implement additional variable filters
that do a simple maths op with a constant, eg:
{set population='${population|divide:"7"}'}
Ticker
On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann wrote:
ters or so.
> I didn't try it but I guess it could lead to routing problems if your
> start is at the end of the road.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 4. Mai 2021 10:06
&
Hi Gerd & others
This is a quite common physical set-up; a highway with another, more
minor, highway/track/path leading off it with a "barrier" at the
junction, inhibiting access to the minor highway.
Often the only clear access restrictions visible on-the-ground are on
the barrier, so these are
Hi Gerd
I'm away at moment, without full access to sources, so can't follow the
current progress with partitioning, etc.
Regarding finding a point IN (and not ON) polygon:
1/ Try bounds center.
2/ Assumed determined [counter-]clockwise from area calculation.
Pick 3 sequential points, bisect th
_____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
>
> Hi Gerd and others
>
> The cause for this unrendered area
is sometimes erronously connecting
> ways which trunk doesn't connect (only with BoundaryRelation).
>
> I think it will take a one or two more weeks before this branch is
> getting stable.
>
> Gerd
>
>
> Von: mkgmap-dev im Auf
___________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. April 2021 13:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Empty rectangles in map
>
> Hi Gerd and others
>
> The cause for this unrendered area is a
etimes returns
> ON when it should return IN/ON
> I think it happens when a ring has start /end node ON and also 2nd or
> 2nd-last node ON.
> Probably a special case created by the ShapeSplitter. Attached patch
> fixes the problem in IsInUtil.
>
> Gerd
>
>
Hi Gerd and others
The cause for this unrendered area is as follows:
A large multipolygon (larger than the maximum size for a level 1
subdiv) exists, and is broken into some similar size pieces and some
smaller pieces to expose inners/holes. The same problem can be caused
by any polygons having t
Hi Gerd
I think I'm getting somewhere with this and will try and have a proper
fix in a day or so. It is related to subdivision splitting.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkg
ea logic.
With option --x-no-mergeshapes (and current trunk) it appears that
cutting to this island group happens twice from the left, with 1 line
continuing to the right and twice from the top, with 1 line continuing
to the bottom.
Ticker
On Sun, 2021-04-25 at 13:50 +0100, Ticker Berkin w
7;t go to the edge of the
forest triangle. Also it only shows when detail-level is set to
"highest"
Ticker
On Sun, 2021-04-25 at 11:03 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Just tried this with latest trunk and my standard environment (mainly
> --order-by-decreasi
Hi Gerd
Is there a simple way to look at an .osm.pbf file with JOSM?
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
I presume this will be most use to people who generate sea-latest.zip.
I use --generate-sea=..., so using the current OSM data for the area
concerned, and, before loading onto a device, look at the overview map
with GPSMapEdit to check the sea has worked correctly.
If the country cut has prob
Hi Gerd
Just tried this with latest trunk and my standard environment (mainly
--order-by-decreasing-area
and get very inconsistent results.
On GPSMapEdit seems reasonable - shows forest triangle and, within, a
small area with a number of holes.
MapSource shows a white square, no forest colour a
____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 18:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Polyline base optimisation
>
> Hi Gerd
>
> It needs to know if there are deltas < 0, deltas > 0, an
s
> calculated but I still think that your version is even more
> confusing.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 17:34
> An: Development list for mkgmap
> Betreff
hich will never find a better
> encoding?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 8. April 2021 13:58
> An: mkgmap development
> Betreff: [mkgmap-dev] Polyline base optimisation
>
Hi Gerd
If starting with unsigned deltas in polyline encoding, and attempting
to reduce the length by testing reduced x/yBase values, there isn't any
point in testing Base-1, as the normal number of bits will be the same
(added sign bit) and there will be some overflows.
Patch attached to change
Hi Gerd
Problem is that IdentityHashMap is the ideal solution, but ordering
behaviour depends on internal java object handles. A solution to this
stability issue would be to rotate joinedWays.originalWays so, say, the
one with the lowest ID is first, doing this just before the full point
-list is
w you used that code?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 15. März 2021 17:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
>
> Hi Gerd
>
> You migh
_________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 1. April 2021 14:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness
Hi Gerd
2 more thoughts:
For elements from Polish input, set a distinct role. This can be
spotted early and either the order rule or direction rule can be
applied (they are closed, so the area/direction can be calculated
immediately). This then allowed OSM data with a blank role to be
handled as
I meant intersecting polygons
Ticker
On Thu, 2021-04-01 at 12:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I agree that calcContains should be changed as you suggest.
>
> My view otherwise is that the code should be as simple as possible
> for
> "correct" cas
etry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Ticker,
>
> yes, that's what I plan to do. Right now I try to understand what is
> done with the data in collection intersectingPolygons.
>
Hi Gerd
Wouldn't it be more efficient to choose a point within a each polygon
and then use IsInUtils.isPointInShape and the relative areas to test if
this polygon is in others. The point could be the centre of the
polygon, after checking isPointInShape == IN on itself, and, if not,
make do with th
Hi Gerd
I think this might be the reason why you backed out the Polish
inner/outer definition changes:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2019q1/029478.html
Maybe there needs to be an option to say how multiple DATA{sameLevel}
should be handled:
a/ first outer, following inners.
b/ ou
the rules for touching outer rings.
>
>
> So, I started to use already tested code where possible, e.g.
> IsInUtil. See attached patch. Run times seem similar to the existing
> code in trunk.
> Just experimental so far, but at least a lot less code...
>
> Gerd
>
> __
Hi Gerd
I'm revising my opinion about considering the geometry to determine
inner and outer. All the different BitSets, containsMatrix etc logic
is too complex, and if it then conflicts with the explicit definition
of the MP it just gets worse.
I'd simpify it along these lines:
split the polyg
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 29. März 2021 10:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> On a road, if there is a normal
nts on strictly straight line""
>
> I commited only parts of your patch, I think the stuff regarding
> closed shapes is too confusing and the changed loop logic really
> doesn't improve robustness or readability.
> See r4619 and r4620.
>
> Gerd
>
> __
lies on this?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 25. März 2021 10:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
int is preserved?
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 23. März 2021 14:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
&g
de fails.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 23. März 2021 13:10
> An: mkgmap development
> Betreff: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> I was trying to
Hi Gerd
I was trying to diagnose a problem with a repeating points in polylines
as reported by GPSMapEdit and found a problem in
RemoveObsoletePointsFilter where it duplicates a point.
Also in this and/or RoundCoordsFilter I've made some changes:
1/ stop the chain when polygons get too small
2/ k
ocessing?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Mike Baggaley
> Gesendet: Mittwoch, 17. März 2021 15:18
> An: 'Ticker Berkin'; 'mkgmap development'
> Betreff: Re: [mkgmap-dev] Removal of floodblocker
Hi all
I think it is time that that the floodblocker logic is removed.
I doubt if anyone uses it.
The recommended way to have sea is to use --precomp-sea and
floodblocker is irrelevant to this.
Using the coastline data from the normal OSM input, the common sea
problems are in tiles that extend
Hi Gerd
You might consider the some of the ideas here as improvements to the
initial parts of MP processing.
This is a patch based on trunk rather than the new branch. It isn't
structured as for final usage, rather for minimising the spread of
changes, working in parallel with the existing code s
Hi Gerd
Some possible test cases:
Looking at the problems my code is detecting, the complicated cases are
when possible polygons share 2 or more end-points with other possibles;
for instance:
http://www.openstreetmap.org/relation/5329106
adjacent buildings, touching each other, are mapped as a
Hi
I think this is more an interpretation of what a Bay means and it being
an inner of a relation isn't relevant. Islands shouldn't be cut-out of
Bays with a MP relation. It is expected that they are rendered as
transparent rather than blue and mapnik.txt does this.
There was a thread about this
be mkgmap can simply ignore incomplete MP after logging a warning.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 13. März 2021 12:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] tile takes very long time to generate
&
Hi Gerd
I think the extra testing should be removed and the logic should work
on the assumption of correct data; just emitting warning/errors when
problems are found during the normal processing.
It also has extra complexity due to early versions of the splitter not
keeping relations/polygons com
place=sea or place=island MPs or maybe add a tag to tell mkgmap
> that only a POI is needed. No idea how much work that would be or
> what side effects it would have.
>
> I've not yet checked why the mentioned MP takes s long, maybe
> it's because the MP contains some
Hi
I'm not sure of all the rules regarding relations and resultant
polygons and some of the MultiPolygonRelation.java code defeat me but
some thoughts:
Even though the relation might not have any relevant tags, it is what
causes all the significant inner and/or outer polygons to be create by
mkgm
Hi Mike
Does this work? There is no information about the tagging when the
elements are read back from the ovm_ file.
In MapBuilder I think you have to test for isOverviewComponent rather
than isOverviewCombined and I don't think changes to
OverviewMapDataSource make any difference to anything.
Hi Vuki
>From the code, it looks like the command line option
--[overview-]levels=...
is used in preference to the style/options file
[overview-]levels=...
line
This could be make cleared in the style manual section 3.4 and the
command line options description.
Ticker
On Mon, 2021-03-01 at 1
Hi
The default style has 5 levels of overview map! This seems excessive.
I'd have thought 2 or 3 would be acceptable and save a lot of space
The only contents is larger and larger cities, fast trunk roads and
motorways, some boundaries, sea and, at 3 of the 5 levels, coastline.
I don't think coa
Hi
I can't remember all the details of this message, but what has happened
is a tile needs 3-byte references to a city index and this will force
the full MDR for all tiles to use 3-byte city references, so growing
the index structure a lot. So, probably not relevant for overview.
Ticker
On Sun,
ropped the corresponding naming
> actions for simplification, and the mopup at the end also ;-)
>
> Jan
>
>
> > Am 21.02.2021 um 22:32 schrieb Ticker Berkin <
> > rwb-mkg...@jagit.co.uk>:
> >
> > Hi Jan
> >
> > I don't think you&#x
se: correct.
> In right stadium pois for all swim inside except for the areas:
> wrong.
>
> What I expect is this: 2-expected.jpg
> Left as before, but In the right pois for all swim inside including
> areas.
>
> Hope I made it clearer
> Jan
>
>
> > Am 21.02.2
Hi Jan
I'm slightly confused as to what you are trying to do here when you say
it works for nodes but not polygons.
After you've output a POI from the first rule what are you trying to
do?
Ticker
On Sun, 2021-02-21 at 10:42 +0100, jan meisters wrote:
> Hi Gerd,
>
> my first impression didn´t g
Hi Mike & Gerd
No problems with this.
Concerning *-sea-sectors. My reading of the documentation implies
extend-sea-sectors and no-sea-sectors are alternatives. The
comprehension difficulty is because of the naming of 'extend-sea
-sectors', which are very different from the 'sea-sectors' that 'no-
ker 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 im Auftrag
> vo
#x27; function. Of course, this assumes that you don't use a
> generic typ code for several different objects. Or am I missing
> something?
>
> Regards,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 15 February 2
mkgmap-dev] Pending changes
>
> Hi Ticker,
>
> in fact 3200 - 3f1f strictly follow their given resolution value -
> other than e.g. 2a-2f, which only appear at kind of 24+, no matter
> what resolution is given.
> Even if both ranges are styled to resolution 24: 2a-2f wil
etter 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:5
uot;gate"
> or "lift_gate" popping up in the map on my Oregon. I think they might
> be useful for mappers but they are not very useful for the normal
> user. Maybe it is only on my device but I don't see any need for
> this.
>
> Gerd
>
>
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/0
ine-file
> and that followed by --precomp-sea. Happy to tweak this.
>
> Cheers,
> Mike
>
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 07 February 2021 17:36
> To: Development list for mkgmap
> Subject: Re: [mkg
Hi Mike / Gerd
This patch seems fine to me.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
nd land within land. It doesn't then go back and recursively
> check for
> nested problems - I suspect this would be quite an overhead.
>
> The code is certainly not perfect, but does produce enormously
> improved
> results for me at least. I can still see at least one erro
Hi Gerd & Arndt
I'm reasonably sure the change in option handling is the problem and
attach a patch to fix it.
Ticker
On Mon, 2021-01-25 at 18:05 +0000, Ticker Berkin wrote:
> Hi Arndt
>
> One of the changes in this set is which options get passed through to
> the overv
Hi Arndt
One of the changes in this set is which options get passed through to
the overview builder and maybe this could have an effect. What options
are you using?
Does the overview map with the working version have a DEM section? It
is possible it didn't and the options change means it now does
Hi Gerd
Given that the overview map is for use on computers with 100s of G of
disk space and the main map will be a G or so, can an extra few 10K or
so in the overview map really be a problem for anyone?
Building British-and-ireland, with default style and just --gmapsupp
(ie no index or routing)
>
> No such exception with unpatched mkgmap.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 23. Januar 2021 11:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev]
Hi Gerd
I've just tried this and don't get a problem (with or without -ea)
I used Ranko's osm.pbf, splitter-r595 and my development mkgmap which
is trunk + overview patch + couple of trivial changes.
Where were you getting the exception?
Ticker
On Sat, 2021-01-23 at 07:18 +, Gerd Peterma
x4a polygons (close to the country boundaries )
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 21. Januar 2021 16:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM
rd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 13. Januar 2021 11:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
>
> Hi Gerd
>
> My understanding
not used on
> the device, esp. not when it has negative effects.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 13. Januar 2021 10:41
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-d
patch worsens the
> map).
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 11. Januar 2021 12:39
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
&
ould be disabled for
> the ovm_ maps.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 6. Januar 2021 10:19
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
>
> Hi Gerd
Hi Gerd
Thinking about this more, any attempt at merging will most likely cause
violation of the rule that all overlaying polygons must be in the same
subdivision.
Also, just feeding all the points/lines/polygons back through the non
-order-by splitting process could cause similar problems, so my
y could/should be disabled for
> the ovm_ maps.
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 6. Januar 2021 10:19
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
>
> Hi Gerd
>
> S
gt; Gerd
> (1)
> https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 5. Januar 2021 10:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned
an still see at least one error
> in my map, but I think the remaining errors are tile boundary issues
> that are resolved differently on adjacent tiles. I am thinking of a
> small app to read the mkgmap log file and the coastline data,
> reversing whatever mkgmap says is wrong. By ru
Hi Gerd
shapeMergeFilter.merge() sorts the shapes according to typ, skipSize,
fullArea and name. For --order-by to work for the overview, this must
not happen; the order in the ovm_ files must be used. This is the same
idea as when the more than 1 detail tiles are displayed on a device.
The size
is
> responsible for all of this, but I might be wrong.
>
> I am working on a routing issue that I found while looking at Carlos'
> problem. It only happens with --x-no-force-end-nodes-routing-nodes.
>
> Gerd
>
>
>
>
Hi Gerd
I think it is simplest to do that. Then later some of the sea options
texts can be reworded if any of us feel strongly about it.
Ticker
On Mon, 2021-01-04 at 15:30 +, Gerd Petermann wrote:
> Hi Ticker,
>
> not sure what to do now. Do you think i should commit Mikes patch
> without c
--coastlinefile, no manipulation takes place.
Ticker
On Sat, 2021-01-02 at 18:09 +, Ticker Berkin wrote:
> Hi Mike & Gerd
>
> I'd suggest something like:
> ...
> When this option is specified the land and sea polygons are derived
> from the given precompiled d
Hi Mike & Gerd
I always try to use the coastline data in the downloaded OSM map to
generate the sea with option:
--generate-sea=multipolygon,extend-sea
-sectors,close-gaps=750
and have only ever had 1 problem with faulty
coastline. In this case it wasn't a reversed section but a lake had
been ta
Hi Mike & Gerd
The floodblocker code is still there and, I think, doesn't work any
better or worse than before. I'd never suggest anyone tried use it to
fix coastline errors and I think it should be removed.
I plan to look through all the sea stuff in detail on Monday
Ticker
On Sat, 2021-01-02 a
Hi Mike & Gerd
I'd suggest something like:
...
When this option is specified the land and sea polygons are derived
from the given precompiled data rather than the natural=coastline ways
from the input OSM files.
...
The coastline ways not removed or modified, leaving it up the style to
decid
Hi
I prefer:
--name-tag-list=name:en,int_name,name,place_name,loc_name
for most maps, but where the country frequently has parallel naming in
a European language, eg French for Morocco, I use:
--name-tag-list=name:en,int_name,name:fr,name,place_name,loc_name
Adjust above for your own lang
n copying the options. Or
> maybe I change the code so that only the hgt/dem options are copied.
> I guess I was too lazy there.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 29. Dezember 2020 1
Hi Gerd & Carlos
Reading and trying to understand the code, I'm finding a few strange
things with the Overview map generation, DEM, 0x4a etc
The most significant is that the MapBuilder invocation for the combined
overview map normally runs without any options being passed to it. Only
if --overvie
Hi Gerd & Carlos
I've started looking at this, but can't do anything serious until
tomorrow.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
In the October changes to arcs and headings I mistakenly removed a
variable needed for setting reverse arc direct headings, ie half the
route nodes had the wrong value. Routing mostly worked with this error
but occasionally threw up strange decisions on my eTrex HCx.
Patch attached - sorr
Hi Karl & Gerd
The comments starting:
;GRMN_TYPE: ...come from TYPViewer idea of what the code should be used for and
are
not 'absolute', and, for city/town/etc might be very different from
mkgmap default style usage.
Some other comments to your later questions embedded. Often there isn't
a good
Hi Dave
The factors you mention can have a mix of effects.
The default for drive-on is 'detect,right', so, without a method of
knowing the country, mkgmap will use 'right'. The bounds file gives the
information that 'detect' will use, so, for the tile in question it
will be correct as 'left'. Wit
Hi Dave
There are a few things going on here that might have effects on the
routing behaviours you are seeing.
Driving side - as Gerd has elaborated. I have an example where the
Garmin routing algorithm will do 2 left turns, a u-turn and then a
right turn anyway across the traffic to avoid the co
Hi Karl
It is the labels (mkgmap:label:n n=1..4) that show as the "name" on the
device.
These can also be set with the "addlabel" and "name" commands; see
style manual section 4.3.5 and 4.3.6
The various style files have the rule:
name=* {name '${name}'}
to do this, but sometimes the "name" comm
bsite:
> opening_hours=* {set
> mkgmap:region='${opening_hours|subst:Tu=>Di|subst:We=>Mi|
> subst:Th=>Do|subst:Su=>So}' }
> website=* {set mkgmap:region='${mkgmap:region} ${website}'}
> etc.
>
> But maybe this breaks other functionality?
>
>
Hi Karl
I don't think what you are hoping for can be done. Some of it is
possible for special cases, but not generally.
If a POI has a name and the name is the same as a TYP translation, then
logic can be added to the rule for the point to suppress the name, eg,
for english:
sport=swimming {set
Hi
I have two examples where a larger polygon is drawn over smaller ones -
near start of 'polygons':
leisure=nature_reserve
{set mkgmap:drawLevel=75} [0x16 resolution 19 continue]
military=danger_area
{set mkgmap:drawLevel=75} [0x11 resolution 20 continue]
...
mkgmap:drawLevel is used t
a, according to the documentation only
> > works if the
> > polygons have the same draw order, which these two do not by
> > default.
> >
> >
> > Regards
> > Karl
> >
> > On måndag 2 november 2020 kl. 18:18:11 CET Ticker Berkin wrote:
> &
Hi
I understand that many users prefer a fixed order of rendering based on
the polygon type, and this is part of the definition of mapnik.txt and
seems to be the 'Garmin' way of doing things.
If there is a consensus that the draworder should be different, then
make it so. I'd think that wetland a
Hi Randolph
It's the actual editing of the file, looking at the context of the
typecode and then trying to come up with the best short string in ones
native or well understood language that takes the time, and then
getting agreement on the changes.
However, I have no problem with you adding (ie n
401 - 500 of 1134 matches
Mail list logo
