Posted
over 9 years
ago
From r3366 there are some improvements to the support for driving on the left or right.
Each tile has a flag to say if roads are drive on the left or right. It is known to
make a difference with roundabouts and may be used in other ways.
The options
... [More]
--drive-on-left and --drive-on-right were
replaced by --drive-on=left and --drive-on=right.
You can also add detect which will use the country information to select
the correct side. The default is equivalent to
--drive-on=detect,right which means that if detection fails, it
will use drive on the right.
The old flags --drive-on-left and --drive-on-right still work.
The detection uses the precompiled bounds (or country-abbr/country-name) to
determine the country in which the roads are located, and the resource file
LocatorConfig.xml contains a new attribute driveOnLeft="true" for all known
drive-on-left countries
If a tile covers two countries where you drive on different sides of the road, then
it cannot work for the whole tile and you get a warning. In the future we will be able to cut tiles on country boundaries
so that the problem will then not arise. [Less]
|
Posted
over 9 years
ago
There has always been a way to convert a tag
value from meters to feet, this was originally for contour heights
which need to be in feet, but the default for OSM is for them to
be in meters.
With the release of version r3353 these conversions are
... [More]
much more useful
and can be applied to speeds as well as lengths. They also take into account
any unit that is already specified.
So for example if you specify a conversion of meters to feet,
then "100" will be converted to "328", "100m" will be converted to "328"
but "100ft" will be left as "100". Furthermore "100km" would
result in "328000".
If any of the units are not recognised then the value remains completely
unchanged.
Input Result
100 328
100m 328
100ft 100
100km 328000
100xyz 100xyz
Here are some examples.natural=hill & height=* {
set height='${height|conv:"m=>ft"}';
}
highway=* & maxspeed=* {
set limit='${maxspeed|conv:"kmh=>mph"}';
}
The possible units are:
Length: m, km, ft (feet), mi (miles).
Speed: mph; km/h (or kmh, kmph), knots
[Less]
|
Posted
over 9 years
ago
There has always been a way to convert a tag
value from meters to feet, this was originally for contour heights
which need to be in feet, but the default for OSM is for them to
be in meters.
With the release of version r3353 these conversions are
... [More]
much more useful
and can be applied to speeds as well as lengths. They also take into account
any unit that is already specified.
So for example if you specify a conversion of meters to feet,
then "100" will be converted to "328", "100m" will be converted to "328"
but "100ft" will be left as "100". Furthermore "100km" would
result in "328000".
If any of the units are not recognised then the value remains completely
unchanged.
Input
Result
100
328
100m
328
100ft
100
100km
328000
100xyz
100xyz
Here are some examples.natural=hill & height=* {
set height='${height|conv:"m=>ft"}';
}
highway=* & maxspeed=* {
set limit='${maxspeed|conv:"kmh=>mph"}';
}
The possible units are:
Length: m, km, ft (feet), mi (miles).
Speed: mph; km/h (or kmh, kmph), knots
[Less]
|
Posted
over 9 years
ago
There has always been a way to convert a tag
value from meters to feet, this was originally for contour heights
which need to be in feet, but the default for OSM is for them to
be in meters.
With the release of version r3353 these conversions are
... [More]
much more useful
and can be applied to speeds as well as lengths. They also take into account
any unit that is already specified.
So for example if you specify a conversion of meters to feet,
then "100" will be converted to "328", "100m" will be converted to "328"
but "100ft" will be left as "100". Furthermore "100km" would
result in "328000".
If any of the units are not recognised then the value remains completely
unchanged.
Input
Result
100
328
100m
328
100ft
100
100km
328000
100xyz
100xyz
Here are some examples.natural=hill & height=* {
set height='${height|conv:"m=>ft"}';
}
highway=* & maxspeed=* {
set limit='${maxspeed|conv:"kmh=>mph"}';
}
The possible units are:
Length: m, km, ft (feet), mi (miles).
Speed: mph; km/h (or kmh, kmph), knots
[Less]
|
Posted
over 9 years
ago
A recent change to data in Columbia, South America in Open Street Map
may cause a problem when creating a map of that area.
There is a long standing bug in mkgmap that results in a crash when
compiling the object
... [More]
http://www.openstreetmap.org/way/313259878
which is in Columbia. The addr:housenumber is ":702" which triggers
the bug. Probably that is just a typo and it should be just "702",
however this should not cause a crash in mkgmap.
The problem is now fixed in r3354, so you should upgrade if affected
by this problem. I think you will only see it if using the
--add-pois-to-areas option.
Due to the nature of the fix, the resulting .img files may be a little
smaller than before.
[Less]
|
Posted
over 9 years
ago
A recent change to data in Columbia, South America in Open Street Map
may cause a problem when creating a map of that area.
There is a long standing bug in mkgmap that results in a crash when
compiling the object
... [More]
http://www.openstreetmap.org/way/313259878
which is in Columbia. The addr:housenumber is ":702" which triggers
the bug. Probably that is just a typo and it should be just "702",
however this should not cause a crash in mkgmap.
The problem is now fixed in r3354, so you should upgrade if affected
by this problem. I think you will only see it if using the
--add-pois-to-areas option.
Due to the nature of the fix, the resulting .img files may be a little
smaller than before.
[Less]
|
Posted
over 9 years
ago
A recent change to data in Columbia, South America in Open Street Map
may cause a problem when creating a map of that area.
There is a long standing bug in mkgmap that results in a crash when
compiling the object
... [More]
http://www.openstreetmap.org/way/313259878
which is in Columbia. The addr:housenumber is ":702" which triggers
the bug. Probably that is just a typo and it should be just "702",
however this should not cause a crash in mkgmap.
The problem is now fixed in r3354, so you should upgrade if affected
by this problem. I think you will only see it if using the
--add-pois-to-areas option.
Due to the nature of the fix, the resulting .img files may be a little
smaller than before. [Less]
|
Posted
almost 10 years
ago
For quite some time it has been possible to build a map
using unicode to display characters in various languages.
Now searching should also work in versions r3294 and later.
All of Western, Central and Eastern European characters
should be available
... [More]
as well as Arabic, Greek and various
others. It is unlikely to work with Chinese characters
and that will require further investigation.
Ensure that you are using the options --code-page=65001 --index --route
as well any others that you need. [Less]
|
Posted
almost 10 years
ago
For quite some time it has been possible to build a map
using unicode to display characters in various languages.
Now searching should also work in versions r3294 and later.
All of Western, Central and Eastern European characters
should be available
... [More]
as well as Arabic, Greek and various
others. It is unlikely to work with Chinese characters
and that will require further investigation.
Ensure that you are using the options --code-page=65001 --index --route
as well any others that you need.
[Less]
|
Posted
almost 10 years
ago
For quite some time it has been possible to build a map
using unicode to display characters in various languages.
Now searching should also work in versions r3294 and later.
All of Western, Central and Eastern European characters
should be available
... [More]
as well as Arabic, Greek and various
others. It is unlikely to work with Chinese characters
and that will require further investigation.
Ensure that you are using the options --code-page=65001 --index --route
as well any others that you need.
[Less]
|