On 10/14/2009 01:14 AM, Mark Burton wrote:
These tags expect an integer value, optionally preceded by a + or -
which make the adjustment relative to the original value.
This is a good idea.
But I think it would be better to allow for non-integer values of
adjustment. E.g. if I have a long
Mark Burton schrieb:
This is something that was briefly discussed not too long ago and the
idea is that a road's speed or class can be modified by the
presence of a POI that defines new values for either/both of them. This,
hopefully, will make ways that have stuff like traffic signals and
On Wed, 14 Oct 2009 08:45:52 +0200
Ralf Kleineisel r...@kleineisel.de wrote:
On 10/14/2009 01:14 AM, Mark Burton wrote:
These tags expect an integer value, optionally preceded by a + or -
which make the adjustment relative to the original value.
This is a good idea.
But I think it
Hi Chris,
Does it work with and without the --ignore-maxspeeds option?
It occurs after the maxspeed processing.
By the why: Is the --ignore-maxspeeds option documented
somewhere? All I understand is that it turns off
the default mkgmap handling of maxspeed tags, so that
only the
Just realised, as the patch is now, it will only apply one delta to the
way's speed/class. If a way has multiple POIs that can change the
speed/class, only the last one processed (the order is, essentially,
random) will have an effect.
Cheers,
Mark
This is something that was briefly discussed not too long ago and the
idea is that a road's speed or class can be modified by the
presence of a POI that defines new values for either/both of them. This,
hopefully, will make ways that have stuff like traffic signals and
crossings, etc. less
Mark Burton wrote:
This is something that was briefly discussed not too long ago and the
idea is that a road's speed or class can be modified by the
presence of a POI that defines new values for either/both of them. This,
hopefully, will make ways that have stuff like traffic signals and
