e" test requires lots of time for such a
> complex outer ring, and a single test will not find intersections.
>
> Have to think about the data structures but I am sure this will be
> much faster for most of the really complex MP.
>
> Gerd
>
>
>
> ___
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"
lations 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.
>
> Gerd
>
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
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/
ing 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
__________
> 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 Coord, immediat
ight 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
>
> ___
that relies 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
&g
d?
>
> 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
>
> I don'
>
> 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 diagnose
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/
>
> 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 generate-sea option
>
>
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
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
imply 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 Ge
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
=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 errors.
>
&
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
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
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
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,
I dropped 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'll b
im 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.2021 um 13:01 schrieb Ticker Berkin <
> >
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
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
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
> von Ticker Berkin
> Gesendet: Freitag, 12.
s 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 2021 09:16
> To: Development list
t; 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 will always
> appear a bit later.
> I suspect that´s what Gerd found to be confusing.
>
> Jan
>
>
> > Am 1
.
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 Berki
uot;
> 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:
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: [mkgmap-dev] Fix Sea Patch
>
> Hi Mike and Tick
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
heck 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 error in my
> map, but I
> think the remaining errors are tile boundary issues
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 overview b
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
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
;
> 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] Tiles
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
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 map
>
> Hi Ge
_________
> 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 of the overview map was
is 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-dev] T
t; 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
>
> Hi Gerd
&g
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
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
>
> Sorry about o
gt; 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 in DEM map
>
t 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 running mkgmap without
> splitter on just the coa
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
, 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
>
>
> ________
> Von: mkgmap-dev im Auftrag
> v
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
--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 data r
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
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
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
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
ing 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 10:50
>
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
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 -
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
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'.
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
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"
subst:We=>Mi|
> subst:Th=>Do|subst:Su=>So}' }
> website=* {set mkgmap:region='${mkgmap:region} ${website}'}
> etc.
>
> But maybe this breaks other functionality?
>
>
> Regards
> Karl
>
> On måndag 9 november 2020 kl. 10:57:39 CET Ticker Berkin wrote:
&
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
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
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
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
Hi Gerd
Patch attached to fix this
Ticker
On Sat, 2020-10-24 at 11:03 +0100, Roger Calvert wrote:
> Have found that the link to TYPViewer in the TYP file compiler manual
> is
> broken. The new link for this resource seems to be
> https://sites.google.com/site/sherco40/
>
> Regards,
>
>
Hi Karl
See embedded
Regards
Ticker
On Fri, 2020-10-23 at 18:36 +0200, 7770 wrote:
> Hi.
> I am working my way through adding swedish translations to as many
> types as
> possible in the mapnik.txt file.
> Currently i am done with the polygons.
>
> Aside from adding swedish i observe a few
Hi Karl
There are various threads on this, eg
http://gis.19327.n8.nabble.com/mapnik-TYP-file-changes-td5956558.html
I can't go through your points in detail until next week.
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Thanks Gerd
and for spotting the & instead of &&
Ticker
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl
If you are developing these for a device that supports multiple .img
files, the option
--add-boundary-nodes-at-admin-boundaries=NUM
allows you to build individual countries (or groups), have them all
loaded on the device, select the appropriate maps and have routing
between them.
hard coded tests like if (isClose(51.182575, -1.388928, 0.002))
> - dead code: getImgAngle() is not used
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 20. Oktober 2020 15:21
> An: Devel
Hi Vuki
Looking at OSM, the latest change for one of your problem areas is:
Relation: Lake Geneva (332617)
Version #235
Trying to fix the lake (4)
Edited 12 days ago by MFlamm
Changeset #92217016
So most likely you've picked up an incorrect polygon.
Probably unrelated are my comments about
pear with the default style.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 20. Oktober 2020 14:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
Hi Vuki
Various possibilities / questions:
Do you do anything particular with natural=background in your style.
The default is natural=land and the default style doesn't need to
generate anything for it because the device default background isn't
sea.
Do you have a typ file? Does it assign
Hi Gerd
With sharp-angle code enabled, most junctions will get compactDirs;
just a few less than the existing code. Original gmapsupp.img for my
test area was 9801728 and with this change it is 4096 bytes bigger.
I looked at some of the NodCheck angle errors and decided that not much
could be
reff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
>
> Hi Ticker,
>
> thanks for the patch. I'll have a closer look at the weekend.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Mittwoch, 14. O
Hi
Some more answers embedded
Ticker
On Thu, 2020-10-15 at 22:01 +0200, 7770 wrote:
> Hi!
> Thanks for answers.
>
> --add-pois-to-areas helped to achieve a map to display an icon on
> some types
> of areas, such as parking lots. Thanks for hints.
>
>
> About the mapnik TYP file which is
ds on the other side, the routing
+ * algorithm might prefer crossing the major road then multiple
+ * driving-side turns rather than the correct single turn.
+ *
+ * I haven't found a way of preventing this.
+ *
+ * Ticker Berkin
+ *
*/
public class AngleChecker {
private static final Logger
Hi
Also:
Routes through ferry terminals often involve service roads with a low
road-class. Fastest time routing avoids using lower class roads in the
middle of a journey.
Again, in a terminal there are often barriers and roads marked as
access=customer or similar and these might set
Hi Gerd
Yes, --order-by-decreasing-area will cause more polygon splitting as it
forces polygons to be split with the subdivision splitting. However the
code does try to keep the subdivision splitting to appropriate power-of
-2 for for the zoom level (as far as I can remember)
I've often seen
Hi
Some TYP file answers embedded.
Regards
Ticker
On Fri, 2020-10-09 at 11:37 +0200, 7700 wrote:
> Hi.
> Still on my learning path, and thanks for good documents, which have
> helped a
> lot.
>
> 2.
> When working with TYP files, i have read:
> If a polygon type is not listed in this
Hi
Sharp turn-angles impose a route-choosing penalty. For "fastest"
routing this is understandable. However these penalties are so high
that the algorithm might choose to cross the road in question and then
make 2 or 3 opposite turns to finally onto it in the correct direction.
For drive-on:left,
Hi
I've been experimenting with turn angles, compactDirs (4-bit) or not (8
-bit) format, sharp-angle delay and routing pop-ups and have some
observations:
1/ BaseCamp, MapSource, eTrex 30x (newish) and eTrex HCx (old) can give
different pop-ups for the same map and route. BaseCamp results are
Hi Gerd
Examining compactDir logic there seem to be some strange issues, eg
o When an start-of-road generates the first arc in a RouteNode, the
pairing of arcs for any following mid-section of other road is upset.
o It seems strange that the code stops using compact format when the
initial
Hi Gerd
Patch attached
Ticker
On Mon, 2020-09-21 at 05:55 +, Gerd Petermann wrote:
> Hi all,
>
> seems that something in this change was wrong. The current document
> doesn't show the changes.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von svn
Hi
I use mkgmap/Garmin a lot for road routing and driving and frequently
find cases where
1/ exit roads cause pop-ups telling me to turn to stay on the main
road.
2/ an obvious turn is needed to stay on the same road and no pop-up is
generated.
These were some of problems that
6:39 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've modified your patch a bit, please review.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 14. September 2020 17:39
> An: mkgmap devel
Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 14. September 2020 15:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error in Africa?
>
> Hi Gerd
>
> I don't understand how splitting the road in addRoadsWithoutLoops()
> changes anyth
Hi Gerd
Attached is a patch that doesn't assign a driving side to more types of
ways where it is not relevant. This speeds up processing slightly and,
in some circumstances, stop the warning:
"Tile contains both drive-on-left (#) and drive-on-right roads (#)"
Previously ferries were ignored,
401 - 500 of 1100 matches
Mail list logo
