Hi all,
See e.g. the link roads which meat at
https://www.openstreetmap.org/node/606366325
I really wonder how mkgmap should treat roads like that which build a sharp
angle. Current code doesn't merge them. I don't know how it worked in 2014 but
today I see no good reason for that. Routing resu
Hi Gerd,
I believe this activity is a precursor to reducing zig zags at low
resolutions (though I may be confusing two different activities). I think
the case shown here would be better handled by seeing whether at the low
resolution the two entry points to the A13 can be reduced to a single poin
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:
yes I figured out the only current possible division would be to convert ft
to mt - that could be run against population number as well of course..
Dividing the population number to get maps of India or China a bit less
cluttered without using a specific style would be quite handy. Though yes -
bes
...|conv:"from=>to" does speed and weight conversions as well as length
This is the table (from mkgmap/osmstyle/eval/UnitConversions.java)
static {
Map m = LENGTH_FACTORS;
m.put("m", 1.0);
m.put("km", 1000.0);
m.put("ft", 0.3048);
m.put("feet", 0.3048);
Ah true, can use other conversion too, so it's doable...
On Fri, 7 May 2021, 18:47 Ticker Berkin wrote:
> ...|conv:"from=>to" does speed and weight conversions as well as length
>
> This is the table (from mkgmap/osmstyle/eval/UnitConversions.java)
>
> static {
> Map m = LENGTH_FACTORS
I think merging would be fine. Garmin hates sharp angles anyhow and will
likely not chose them for a car route. And if cycling or walking it doesn't
matter too much if really an announcement is not given. Anyhow on sharp
turns there is usually a turn announcement also on the same road - most
switch
Hi all,
I found a few glitches with v4 of the patch. A code block was duplicated (just
decreased performance) and the calculation of points where only two roads meet
was wrong.
Attached are now two different versions, both probably a bit faster:
-v5 corrects the calculation, so probably merges
Hi Gerd,
Please find attached the previously discussed patch that splits checking and
fixing roundabouts and flares and provides enhanced flare analysis. I note
that some checks are performed when the style is being processed with others
being performed later. I have not attempted to combine these
