Am 22.03.2018 um 11:19 schrieb Gerd Petermann:
I cannot reproduce it with the default style and a freshly downloaded area
around the node, so either
someone changed OSM data that was part of the problem or it is related to your
style.
I'm using a very old mkgmap version (3631) with a
Hi,
what does the error "distance to road to large" mean?
SCHWERWIEGEND (ExtNumbers): 1094.osm.gz: internal error, distance to
road too large, road id=184899623, SS12 Strada Nazionale Del Canaletto
Nord house 1070(47) http://www.openstreetmap.org/node/4712532420
Chris
Am 01.03.2018 um 09:28 schrieb Gerd Petermann:
Yes, it is a pity, but I think this is not only a problem in mkgmap, it is a
general problem in OSM,
therefore I think you should discuss this first in the OSM forums / lists. The
type=area proposal is
quite old is not often used.
There are
Am 12.02.2017 um 13:56 schrieb Ticker Berkin:
Hi
With these default rules, my device (Etrex Legend HCx) renders
roundabouts nicely (dark medium line, looks same as 0x04/0x05 line) and
has a suitable 'hover' label. No typ file.
Ticker
Yes, on my Etrex20 and Nuvi 250 I'm also getting a
Am 16.10.2015 um 20:46 schrieb Alexandre Loss:
> I agree also that "mkgmap:ignore-for-routing=yes" is more clear.
I used this tag already in OSM to mark isolated ways. :-)
https://www.openstreetmap.org/way/111674198#map=18/54.3354/8.5915
Chris
___
Am 17.08.2015 um 15:16 schrieb Gerd Petermann:
Shouldn't we interpret this like bicycle=no?
-1
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 12.08.2015 um 10:46 schrieb Gerd Petermann:
I'd like to remove the code and the option, I think it produces more or less
unpredictable results
and I found no problems with maps created without the option.
ok for me.
Chris
___
mkgmap-dev
Am 28.07.2015 um 17:22 schrieb Gerd Petermann:
Hi Ben,
okay, I did not yet think about the case that the device knows in which
direction you are currently driving
when it re-calculates a route. I did only consider the case that you are
planning while standing still.
If I remember
Am 02.05.2015 um 11:19 schrieb Ben Konrath:
Hi,
Here's a small improvement to the tower entry of the default style.
man_made=mast is a valid OSM tag and it is used a bit so I think we should
include it.
https://taginfo.openstreetmap.org/tags/man_made=mast
+1
It's even rendered on the
Am 06.03.2015 um 10:11 schrieb Gerd Petermann:
I'd like to have a special tag with the meaning xxx access is allowed, all
other is forbidden
so that one doesn't have to set a lot of tags to no just to make sure.
highway=* {add access=no; add bicycle=yes}
should work?
Chris
Am 09.02.2015 um 01:51 schrieb A drian:
I prefer the whitelist because it gives you better control: you know exactly
which tags are going to be rendered.
+1
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 12.01.2015 um 08:42 schrieb Gerd Petermann:
Hi Chris,
thanks for the hint. Please check r3401 .
Hi Gerd,
thank you for the quick implemention.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
could we add amenity=clinic to the default style?
http://wiki.openstreetmap.org/wiki/Tag%3Aamenity%3Dclinic
Usage count in OSM:
13.400.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 16.11.2014 03:49, schrieb Brian Egge:
Frequently in areas where sidewalks are drawn, my GPS decides we are
driving on the sidewalk and not on the road. When this happens it displays
'Driving on Trail'. I've verified the footways are tagged, and I've viewed
the default style rule. I've
Am 23.10.2014 13:49, schrieb Stéphane MARTIN:
Compiling the map for France, I get this error (twice) :
GRAVE (StyledConverter): 6237.o5m: Found multiple points with equal
coords as CoordPOI at
http://www.openstreetmap.org/?mlat=43.859890mlon=4.441025zoom=17
- mkgmap-r3337
-
Am 22.06.2014 22:33, schrieb WanMil:
could you post a patch for all the changes? Otherwise I will not be able
to commit it soon because I do not have much time at the moment...
Hi,
this is my suggestion:
--
# building
Am 23.06.2014 11:37, schrieb Minko:
PS
I made a small mistake with copy/paste, it should be
route=ferry seasonal!=* {add mkgmap:ferry=1} [0x1b road_class=3
road_speed=0 resolution 24]
A few reasons that ferries are not routable:
- Bad connections on OSM
- Ferry lines are only
Am 23.06.2014 21:51, schrieb WanMil:
P.S.: Should we add route=ferry { add mkgmap:ferry=yes } [0x1a
road_class=3 road_speed=0 resolution 19] to the default style?
Or 0x1b?
No, because it's already there:
route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0
resolution 19]
Hi,
at the end of polygons we have some catch all rule:
(building=* | amenity=*) area!=no [0x13 resolution 24]
tourism=* area!=no waterway!=* [0x13 resolution 24]
# man_made can be used on areas or lines
man_made=* area!=no
(man_made!=door man_made!=embankment man_made!=breakwater
Am 22.06.2014 22:32, schrieb WanMil:
Is anyone able to route over ferries or is it regression? (I remeber
that I was able to route over ferries some time ago).
I have checked that the ferry is connected correctly to a highway so it
should not be a data problem.
WanMil
Hi,
Sylt-Romo
Hi,
why do we map amenity=nursing_home and leisure=water_park
to the same Garmin element in default-style?
points:
amenity=nursing_home [0x2b04 resolution 24]
leisure=water_park [0x2b04 resolution 24]
Chris
___
mkgmap-dev mailing list
Am 18.06.2014 11:21, schrieb svn commit:
Version mkgmap-r3300 was committed by steve on Wed, 18 Jun 2014
Remove duplicate check for null in ensurePage().
Hi,
could you we add some minor / important / performance
(etc.) hint to the commit comments?
So that users can better decide if a new
Am 19.06.2014 17:53, schrieb Minko:
Suggestion:
amenity=nursing_home [0x3005 resolution 24] (can be found under
community)
leisure=water_park [0x2d09 resolution 24]
ok, alternatively we could map nursing_home to hospital
(0x3002), but I'm fine with your suggestion.
Chris
Am 18.02.2014 10:04, schrieb Marko Mäkelä:
man_made=pipeline
type=water
location=underground
This rule in lines fires:
man_made=cable|(man_made=* man_made ~ '.*pipe.*')
{name '${name} (${operator})' | '${name}' | '${operator}' }
[0x28 resolution 23]
I wrote this rule with visible
Am 13.03.2014 09:39, schrieb Gerd Petermann:
Hi Chris,
I agree, but I am not an expert reg. style rules.
Please send a proposal.
Gerd
Something like:
man_made=* location=underground {delete man_made}
in front of the main rule.
Chris
___
Am 06.03.2014 08:40, schrieb svn commit:
- larger precompiled sea and bounds data (~30%)
So, it's not compatible with old sea and bounds files?
chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 17.02.2014 10:12, schrieb Gerd Petermann:
I've added the code to optimize non-routable ways in r3059.
Your example looks much better now.
Hi Gerd,
I assume it's in the high-precision branch, and not in trunc?
Chris
___
mkgmap-dev mailing
Am 15.02.2014 17:32, schrieb Andrzej Popowski:
since Garmin started to create OSM maps, we can directly compare
different processing of input data. Please look at railways on both
attached pictures. Mkgmap version (simp-mkg.png) is created with branch
high-prec-coord-r3053.
In order to
Am 22.01.2014 21:28, schrieb Thorsten Kukuk:
When debugging this I found out that there are a lot of
maxspeed=none tags at least in my area, which leads to a
set mkgmap:road-speed-class = 0, which is of course really slow.
Are you using the default-style-rules?
Chris
Am 23.01.2014 10:59, schrieb Thorsten Kukuk:
maxspeed=* mkgmap:road-speed-class!=* maxspeedkmh()=* { set
mkgmap:road-speed-class = 0 }
And if I understand this correct, everything not numeric
will map to mkgmap:road-speed-class = 0.
Which is Ok for maxspeed=walk, but not maxspeed=none.
Hi,
I have a question to the section in the doc of the new style
system:
---
Access restrictions of roads are now defined by setting special mkgmap:*
access tags (mkgmap:car, mkgmap:foot, mkgmap:bicycle, mkgmap:truck,
mkgmap:bus, mkgmap:taxi, mkgmap:emergency, mkgmap:delivery). Roads are
blocked
Am 19.01.2014 11:18, schrieb Gerd Petermann:
I think the idea of the change was that the java code should not
interpret the meaning of osm
tags like private. So, the style author has to decide what that means to him
and set the mkgmap:xxx values accordingly.
So, destination has to be mapped
Am 19.01.2014 11:54, schrieb Gerd Petermann:
in styles\default\inc\compat_lines I see this rule:
access=destination { set mkgmap:throughroute=no }
If you don't use the compat_lines file, you should add
something similar to your style file.
Thank's, this is what I was looking for.
Chris
Am 12.01.2014 11:02, schrieb Minko:
Normalization step before running the style files is maybe a better option,
but beware for other tags like vehicle:backward=* or vehicle:forward=*
If the direction of the way is reversed, these should reverse too.
Yes, that's the reason roads should not be
Am 12.01.2014 14:26, schrieb Gerd Petermann:
But what would be good is a non-reversing normalization:
oneway=yes/true/1 - oneway=yes
oneway=-1/reverse - oneway=-1
I don't think so. A lot of work was done to remove tag depended java code
and change it into style rules. I think this
Am 24.12.2013 11:14, schrieb GerdP:
I think the major advantage is that the way is split into fewer parts,
and that typically improves routing.
Hi,
I see one possible regression:
I believe that turn-restrictions are more strict than
normal restrictions.
Example: A dead end service road to a
Am 23.12.2013 15:15, schrieb Gerd Petermann:
What do you mean with route restrictions ?
sorry, a route restriction is the internal name for it.
These route restriction are created for restriction relations
like http://wiki.openstreetmap.org/wiki/Relation:restriction
Ah ok so you mean
Am 23.12.2013 12:22, schrieb Gerd Petermann:
1) If a POI with a tag like access=mkgmap:road-speed=1
???
The attached patch implements this changed behaviour.
The type 2) POI are converted to route restrictions.
What do you mean with route restrictions ?
Greetings
Chris
Am 20.12.2013 10:52, schrieb Minko:
If you look at the traffic rules you might be right Thorsten.
Pedestrians may only use cycleways if there are no adjacent footways.
In general on OSM sidewalks are not mapped very frequently so I would suggest
to set access default on yes.
Unless mkgmap
Am 15.12.2013 12:52, schrieb Gerd Petermann:
while debugging the I found this http://www.openstreetmap.org/relation/2560683
which seems to be ignored by mkgmap.
I can confirm this.
I guess the problem could be that both ways
http://www.openstreetmap.org/way/189568203 and
Am 18.11.2013 23:58, schrieb Colin Smale:
I am not using
adjust-turn-headings. I tried it some time ago and decided at that time
that it was not an improvement.
It even can produce routing errors. Don't know if this has been fixed
in newer versions of mkgmap.
Chris
Am 03.11.2013 13:23, schrieb Steve Ratcliffe:
On 02/11/13 10:01, chris66 wrote:
would it be a problem to make it work also with the quotes?
To make it consistent with the existing usage.
After some thought I would rather not do that. In tag matches,
the quotes remove the special meaning
Am 01.11.2013 23:34, schrieb Steve Ratcliffe:
Note there are no quotes around ${maxspeed}.
would it be a problem to make it work also with the quotes?
To make it consistent with the existing usage.
The style rules are complicated enough. ;-)
With this enhancment it is ready for committing.
Am 11.07.2013 13:14, schrieb Andrzej Popowski:
If class 4 network is not continuous, then routing will fail. I have
made some maps for Poland, that should work in BaseCamp. The main
changes to default style is that I added motorway_links, trunk_links and
trunk roundabouts to class 4.
Am 11.07.2013 13:47, schrieb Andrzej Popowski:
Hi,
I'm creating maps for Europe, which is a big piece of data. Splitting it
is a main problem. I'm using Windows 7 x64 and recent splitter 306. My
experiences are following:
Hi,
I'm also running on W7-64 and have no problems.
Maybe you have
Am 18.06.2013 20:24, schrieb WanMil:
By the way: The given house number is not assigned to the street Ermen
because its distance is greater than 150m. It would be no problem to
increase the max distance between housenumber and road segment (maybe
300m?).
But in this case this would be
Hi,
Question concerning the housenumber algorithm.
Would in this situation:
http://www.openstreetmap.org/?lat=51.75231lon=7.49462zoom=18
the housenumber 26 assigned to the (unnamed) service road?
If not, would it be difficult to implement this?
So, the expected behavior is:
If nearest road
Hi,
Garmin will do strange loops when routing this way:
http://osrm.at/3yV
(OSRM is routing correctly here).
Default mkgmap style. V2606
Options:
description=OSM_CityMap
series-name=OSM_CityMap
family-name=OSM_CityMap
country-name=Deutschland
country-abbr=DEU
family-id=66
product-id=1
Am 10.06.2013 15:34, schrieb GerdP:
I can reproduce it with r2644, and I guess it is an old problem.
I don't know why, but the road
http://www.openstreetmap.org/browse/way/23101541
which is tagged with motorcycle=no
sets this road as not routable for cars because
motorcar and
Am 10.06.2013 17:06, schrieb chris66:
Thank you for the quick solution. Indeed when I remove
the motorcycle=yes in my local osm file routing is ok.
-yes +no
Should we add a rule in default style to delete motorcycle ?
Chris
___
mkgmap-dev
Am 02.05.2013 23:08, schrieb Jozef Riha:
is there a way how can i say which features are taking up the most space
in resulting map? there may be some space for optimizations but i don't
really know where to start.
First think you should delete are buildings. They are also slowing the
map on
Am 12.04.2013 10:39, schrieb Minko:
The only problem was that older devices show only . or ? on the
streetnames with only the first capital visible.
Labels are rendered fine, as long they are horizontal (pois for instance).
That is correct. The old devices can show rotated text only
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function is_connected may help a little.
Also ORS is not able to find a foot-route to the hospital:
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function is_connected may help a little.
Also ORS is not able to find a foot-route to the hospital:
Am 06.04.2013 22:04, schrieb Enrico Liboni:
Strange it seems for me ORS is working,
Yes, because you have set ORS to car mode. The highway=steps are not
routable for cars, so in car mode they are no routing-islands.
Garmin is working a little bit different, because the routing network
is the
Okay, thanks, I will test it.
Hi,
I'm not discovering a big difference to the old logic but agree
that it is the cleaner and more consistent solution.
So for me it's ok to commit.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am 31.03.2013 09:45, schrieb Marko Mäkelä:
Look at the ways around the POI. Could the nearest routeable way be a
routing island (not connected to the rest of the road network, for
example because of a missing junction node)?
The only routing island I find in this area is this footway:
Am 31.03.2013 12:23, schrieb chris66:
The only routing island I find in this area is this footway:
Also could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing islands are one of the worst things in OSM-routing.
The new mkgmap function
Am 31.03.2013 13:22, schrieb chris66:
The new mkgmap function is_connected may help a little.
So what you could try in your style:
highway=steps {add mkgmap:check_connected = true}
preceeding your ordinary highway=steps ...
Chris
___
mkgmap-dev
Am 30.03.2013 10:59, schrieb WanMil:
what is the benefit of the new handling?
There are many benefits:
Okay, thanks, I will test it.
Here is the patched mkgmap:
http://rapidshare.com/files/3509423819/dist.zip
Chris
___
mkgmap-dev mailing list
Am 16.03.2013 18:37, schrieb Francisco Moraes:
Gerd,
I don't see a version 2530 for download yet, only 2529.
Francisco
Note on download page:
These snapshots are created automatically each night when there are
changes.
r2530 was commited today, so you will see this in the download folder
Chris
Am 14.03.2013 21:25, schrieb GerdP:
Hi Chris,
please tell me the options that you use for mkgmap. I have to find out if
these generated ways
should be ignored or if they are generated with errors.
Gerd
Chris66 wrote
Am 10.03.2013 10:44, schrieb GerdP:
check_connected_v2
Am 15.03.2013 17:20, schrieb GerdP:
Hi Chris,
please check: Do they disappear when you remove option process-destination?
No.
road not connected to other roads, added as line:
http://www.openstreetmap.org/browse/way/116661654
road not connected to other roads, added as line:
Am 10.03.2013 10:44, schrieb GerdP:
check_connected_v2.patch
http://gis.19327.n5.nabble.com/file/n5752599/check_connected_v2.patch
Issue:
Errorlog is reporting ways which do not exist in OSM:
road not connected to other roads, added as line:
Am 10.03.2013 09:35, schrieb GerdP:
If the way 98294931 lies on the boundary of the tile, the way 98294932
could simply be missing in the input file. Please check that.
Indeed, there is a tile border between the ways:
http://up.picr.de/13713349eu.jpg
If this is the case, I wonder if I
Am 04.03.2013 10:15, schrieb GerdP:
attached is a patch that implements the check discussed here:
http://gis.19327.n5.nabble.com/Style-function-is-connected-tp5750777.html
check_connected_v1.patch
http://gis.19327.n5.nabble.com/file/n5751822/check_connected_v1.patch
If a way is a
Am 09.03.2013 13:05, schrieb GerdP:
Reg. the false positives: Sounds like it works as expected, a routable way
that is only connected to non-routable ways is itself not routable. Or do
you think this should not be done?
Yes this sounds reasonable.
I just was wondering why this way
Am 09.03.2013 14:24, schrieb GerdP:
I assume you style doesn't add way 98294932 as a road.
It should because it's a normal highway=service.
highway=service {add mkgmap:check_connected = true}
# 0x07 = routable line (invisible via TYP)
highway=service area!=yes
[0x07 road_class=0
but B not connected to A.
Chris
Am 09.03.2013 14:48, schrieb chris66:
Am 09.03.2013 14:24, schrieb GerdP:
I assume you style doesn't add way 98294932 as a road.
It should because it's a normal highway=service.
highway=service {add mkgmap:check_connected = true}
# 0x07 = routable
Am 09.03.2013 17:43, schrieb GerdP:
I think this is not possible, but I will try to reproduce the problem
tomorrow.
I noticed that way 98294932 is rather short. Maybe you use the length()
function to filter those?
No, I use length() only for buildings.
Both service roads are visible on my
Am 01.03.2013 12:37, schrieb GerdP:
maybe much easier:
let the style add a tag mkgmap:check_if_connected
for roads that should not be routable if not connected.
StyledConverter could evaluate that tag after all roads are known.
Hi Gerd,
good to hear.
So I will stop my plans for writting a
Am 26.02.2013 20:54, schrieb GerdP:
Hi Steffen,
the problem is caused by missing files which are included as base-styles.
See default/info.
I had the same problem and did not find out how to use them, so I commented
the lines in info
When I had this problem I extracted the referenced
Hi,
would a new style function is_connected() be difficult to implement ?
It should result no for example on this way:
http://www.openstreetmap.org/browse/way/45838172
Because it is not connected to any other highway.
Benefit: You could make such routing islands non routable.
Greetings
Chris
Am 25.02.2013 15:38, schrieb GerdP:
Besides that, the question is where you want to stop. If two ways are
connected to each other, but
not to any other road, should they be routable? Three, four... ?
You never can be perfect. For me a simple test would be sufficient.
way.is_connected()
{
Am 24.02.2013 20:18, schrieb WanMil:
I've had the same problem with a Nüvi 1490T when compiling a map with
the default style and mkgmap r2494. I had turned on housenumbers but
didn't test if the problem doesn't exist without housenumbers.
Hi,
my problem was caused by using routable lines
I wrote:
- Route Calculation (even to short distance destinations) often stops at
68% or 81% with error message not enough memory.
This is not related to the --x-housenumbers option (also occurs without
using this option). Maybe some glitch in my style
Chris
Hi,
Recently more and more fuel stations are getting a 'brand' instead of
'operator' or 'name'.
Some examples:
http://www.openstreetmap.org/browse/node/1801313286
http://www.openstreetmap.org/browse/node/1803239322
http://www.openstreetmap.org/browse/node/1924797484
Could we change the style
Am 03.01.2013 09:11, schrieb Felix Hartmann:
I have found (or better someone told me about a problem) a road that
crahes Mapsource.
Go to Tossa del Mar in Spain, and on the GI-681 - just outside the
residential area of Tossa del Mar - close to the Campo del Futbol /
below the
Am 03.01.2013 14:07, schrieb Felix Hartmann:
--merge-lines
Is also a candidate for producing of routing errors.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 03.01.2013 14:15, schrieb Minko:
I think the problem is that a tertiary highway
http://www.openstreetmap.org/browse/way/114405617 forms part of the square
which is tagged as residential highway area=yes.
It is drawn first as tertiary highway and also as residential road, so two
Am 22.11.2012 16:05, schrieb WanMil:
Do we have a style-function for this?
item( ${destination}, 1 ) - Bonn
item( ${destination}, 2 ) - Rodenkirchen
No we don't and it will not be so easy to implement that because the
functions do not have any parameters yet at the moment. So it's a big
Am 18.12.2012 17:23, schrieb WanMil:
I have created a new exit_hints branch which may adds a new interesting
workaround feature.
[..]
Please try and comment if you find it useful or if you have ideas how to
realize it in a better way!
Works very well already, good work!
One minor issue:
Am 18.12.2012 17:23, schrieb WanMil:
It is activated if the option --process-destination is set.
I suggest a suboption for this:
--process-destination=dest,exit
because not everyone may like the appearance[1] of the links
(motorway_link - motorway - motorway_link)
Chris
[1]
Am 24.12.2012 10:53, schrieb Chris66:
The way would be to improve the reduce-point-density
options.
Of course this would not help for buildings mapped with 4 points
but could improve roundabouts and streets mapped with a high
density.
Chris
Am 06.12.2012 21:18, schrieb Steve Ratcliffe:
I think there are a few obsolete/unworking options that can be removed
straight away.
--adjust-turn-headings
Sometimes leads to routing errrors.
Should be removed or reworked.
Chris
___
mkgmap-dev
Am 27.11.2012 13:18, schrieb Steve Ratcliffe:
I made this commit to make remove-short-arcs on by default. Due to my
misconfiguration of the email address it didn't go to the main list.
There is more to this than I thought. I remember the default being 5,
but the code currently has 0 as the
Am 19.11.2012 13:06, schrieb Chris66:
what is wrong with these rules?
When I activate the second rule I get a corrupted gmapsupp.img.
(The first one is working ok).
highway=* ref=* maxspeed 1
{ add display_name = '${ref} (${maxspeed})' }
# highway=* name=* maxspeed 1
{ add
Hi,
this junction has routing errors on my nuvi when using
the option --adjust-turn-headings :
http://www.openstreetmap.org/?lat=51.74341lon=7.47611zoom=17
Screenshot nuvi:
http://up.picr.de/12583675ix.png
Basecamp is ok.
Chris
___
mkgmap-dev
Am 21.11.2012 10:39, schrieb RocketMan:
I have a similar issue with streets named Main St 16/2. The name is
truncated to Main St 16 in the turn directions.
Yes, this seems to be the same problem.
See:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q4/005263.html
so ; is replaced by /.
Hi,
Many destinations are entered with several cities,
for example destination=Bonn;Rodenkirchen
My Nüvi is displaying only the first entry:
Rechts abfahren nach A 555 (Bonn
The right ) is missing also in this case.
Bug or feature ?
Some times ago there was a patch concerning the ;
handling,
Hi,
what is wrong with these rules?
When I activate the second rule I get a corrupted gmapsupp.img.
(The first one is working ok).
# Maxspeed (test)
highway=* ref=* maxspeed 1
{ add display_name = '${ref} (${maxspeed})' }
# highway=* name=* maxspeed 1
{ add display_name = '${name}
Am 19.11.2012 13:26, schrieb Henning Scholland:
When I activate the second rule I get a corrupted gmapsupp.img.
Corrupt means that the map looks like a map without Typfile.
In general I think it's better to use set instead of add. I don't know
what happens if you use add display_name if
Am 19.11.2012 17:23, schrieb GerdP:
Hi all,
I've committed r239 now.
Hi Gerd,
I get many error messages:
Sorry, way x is missing y node(s).
Can they be ignored ?
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi,
the motorway_link lacks oneway check in default style is very useful
in finding routing errors like this one:
http://osrm.at/1Kq
oneway=no was removed some days ago - oneway=yes is implied.
But the check is incomplete because some values are missing.
Here the corrected lines (I suggest the
Am 14.11.2012 15:03, schrieb GerdP:
if you are testing the --keep-complete or the --problem-list option,
please update to r232.
The older versions in the branch are known to have stupid bugs causing
extreme memory needs (and possibly long run times).
Hi,
I didn't follow the splitter
Am 02.11.2012 21:01, schrieb WanMil:
Would the current implementation copy the dest from 1) to 3) ?
Yes - as long as the motorway_link 2) and motorway 3) do not have other
connections afterwards.
Hi WanMil,
So the algorithm also seems to forward the destination from one
motorway-segment
Am 04.11.2012 17:54, schrieb WanMil:
So the algorithm also seems to forward the destination from one
motorway-segment to the next one. Don't think this is needed.
Did you observe that? The patch should not do that. The forwarding stops
after the first non *_link segment.
Just noticed that
Hi,
thank you, will test it.
Is your algorithm able to fill gaps?
Example:
1) motorway_link destination=a_city
2) motorway_link no destination tag
3) motorway no destination tag
Would the current implementation copy the dest from 1) to 3) ?
Chris
Am 02.11.2012 16:03, schrieb WanMil:
Hi,
is the OSM-Id accessible via style file?
Example:
highway=motorway mkgmap:osm-id=12032234 { add name=test }
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 26.10.2012 08:34, schrieb Carlos Dávila:
Where is it picking up the configuration to amend the labelling?
These may be default labels added by Garmin software
Yes, and if using a Typfile they can be set there.
Chris
___
mkgmap-dev mailing
1 - 100 of 207 matches
Mail list logo
