Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Gerd, I think the attached small update should be OK - I have also tweaked a couple of other bits. I can't seem to compile it into a document as I get a syntax error in ../resources/make.param (using Microsoft NMAKE). I haven't used this style of document creation for over 20 years :) Mike Hi Mike, the sources are in the doc directory. Gerd styles-document.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Hi Bernd you can't get something like bonn_20150503_1700_basemap oder bonn_20150503_1700_fixme, only the description you set in template.args I'm not sure if I understand your problem, since solution looks simple form me - add required description after template.args, like: ... mkgmap.jar ... -c options -c template.args --description=bonn_20150503_1700_basemap --gmapsupp -- Best regards, Andrzej ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource error: MDR_TRIM_ADDR.CXX-347-6.16.3.0
Ok Steve, However this isn't a serious problem. Since we know the rules, it's just a matter of apply it. Maybe a simple note in the mkgmap documentation is enough to handle of this problem. I mean, this can be treat as a rule than a error. Thank you again by your prompt support and have a nice weekend. Alexandre (Enviado via iPad) Em 06/03/2015, às 07:37, Steve Ratcliffe st...@parabola.me.uk escreveu: Hi But the must interesting thing is that the order can be ascending or descending. Do you confirm that the order doesn't matter since it is ordered? The maps in the MDR1 section must be in ascending order of map number. Mkgmap always sorts them into ascending order and then tries to renumber all the references to the map tile to match. This sometimes (or always) fails and is a bug. I don't know what the bug is, so I suppose that if they are originally sorted in decending order then it will happen to work. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3491: Revert to using multisortkey to sort street names.
Version mkgmap-r3491 was committed by steve on Fri, 06 Mar 2015 Revert to using multisortkey to sort street names. The 'saving memory' fix lead to incorrect sorting. There would be other ways to slightly reduce the peak memory usage, but they will need some more thought. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
Hi Marko, not a problem for me. I try to solve this problem: The style author wants different routable ways for bicycle and others. I don't care why the author wants that, I just look for an easy way to do it. Gerd Date: Fri, 6 Mar 2015 14:43:56 +0200 From: marko.mak...@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] access rules On Fri, Mar 06, 2015 at 10:11:27AM +0100, Gerd Petermann wrote: 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. What about combined ways: highway=path bicycle=designated foot=designated segregated=no You have a traffic sign for that in Germany too, don’t you? (Even though it is not common.) BTW, in Finland, highway=pedestrian is allowed for bicycles with maxspeed=20. In Germany, it is pedestrian-only. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
On Fri, Mar 06, 2015 at 10:11:27AM +0100, Gerd Petermann wrote: 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. What about combined ways: highway=path bicycle=designated foot=designated segregated=no You have a traffic sign for that in Germany too, don’t you? (Even though it is not common.) BTW, in Finland, highway=pedestrian is allowed for bicycles with maxspeed=20. In Germany, it is pedestrian-only. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
Hi Chris,
no, it doesn't. The way might have a tag motor_vehicle=yes or
hgv=yes or ...
One has to know and remove all these tags (or set them to no)
which are evaluated in inc/access.
Gerd
Chris66 wrote
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
___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
View this message in context:
http://gis.19327.n5.nabble.com/access-rules-tp5836036p5836121.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Hi Bernd, I fear I can't follow. I would expect that you run splitter once to create the tiles. You run mkgmap once for each layer with a different --description for each layer. I would not use template.args for this. I prefer to use the write-kml option in splitter. I load the file in JOSM to see what tile contains e.g. data from my hometown. Gerd Bernd Weigelt wrote Am Freitag, 6. März 2015, 08:12:51 schrieb Gerd Petermann: I think Bernd should either not use the template.args file or add --description=xyz before --gmapsupp ? I never looked at it: What tool shows the description of an individual tile and where? Hi Gerd template.args shouldn't overwrite mkgmap's description, while splitter's description has to much limits splitter's description is not the best solution, when you created more then one layer(=gmapsupp.img) for a region, because you can't get something like bonn_20150503_1700_basemap oder bonn_20150503_1700_fixme, only the description you set in template.args, here bonn_20150503_1700. or you have to run splitter for every layer. splitter and my dach extract takes ~ 9 minutes per run with mkgmap's description i can created different descriptions, but then i can't use template.args. and with mkgmap's description i can see more the one installed gmapsupp of bonn But template.args with cities15000.zip is a good possibility to find out in which tiles which city is, see the splitter.log, maybe it is usable in different ways. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Problem-to-understand-splitter-jar-description-tp5835976p5836122.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Am Freitag, 6. März 2015, 08:12:51 schrieb Gerd Petermann: I think Bernd should either not use the template.args file or add --description=xyz before --gmapsupp ? I never looked at it: What tool shows the description of an individual tile and where? Hi Gerd template.args shouldn't overwrite mkgmap's description, while splitter's description has to much limits splitter's description is not the best solution, when you created more then one layer(=gmapsupp.img) for a region, because you can't get something like bonn_20150503_1700_basemap oder bonn_20150503_1700_fixme, only the description you set in template.args, here bonn_20150503_1700. or you have to run splitter for every layer. splitter and my dach extract takes ~ 9 minutes per run with mkgmap's description i can created different descriptions, but then i can't use template.args. and with mkgmap's description i can see more the one installed gmapsupp of bonn But template.args with cities15000.zip is a good possibility to find out in which tiles which city is, see the splitter.log, maybe it is usable in different ways. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Am Freitag, 6. März 2015, 09:31:32 schrieb GerdP: Hi Gerd I fear I can't follow. I would expect that you run splitter once to create the tiles. You run mkgmap once for each layer with a different --description for each layer. I would not use template.args for this. I prefer to use the write-kml option in splitter. I load the file in JOSM to see what tile contains e.g. data from my hometown. That's what i have done before i'm using template.args and i will do this again in the future. As you remember, you gave me the hint 'keep it simple' and your command line includes tiles/template.args, not tiles/*.o5m ;-) this are my new old command lines for the basemap java -ea -Xmx6G -jar /home/bernd/map_build/splitter-r421/splitter.jar splitter.log --geonames-file=/home/bernd/map_build/cities15000.zip --mapid=6501 --output=o5m --precomp-sea=/home/bernd/map_build/sea_20150302.zip --write-kml=bonn.kml --keep-complete --overlap=0 --split-file=/home/bernd/map_build/areas/bonn_areas.list /home/bernd/map_build/o5m/bonn.o5m java -ea -Xmx6G -jar /home/bernd/map_build/mkgmap-housenumbers2-r3490/mkgmap.jar --bounds=/home/bernd/map_build/bounds_20150302.zip --precomp-sea=/home/bernd/map_build/sea_20150302.zip --generate-sea --style-file=/home/bernd/map_build/styles/basemap_style --name-tag-list=name:de,name,name:en,int_name --mapname=65001001 --family-id=4 --product-id=44 --description=bonn_20150306_1700_basemap --family-name=Basemap --draw-priority=10 -c /home/bernd/map_build/styles/options /home/bernd/map_build/tiles/*.o5m /home/bernd/map_build/styles/styles_typ.txt splitter.log includes lines like Area 65010001: 2322432,370688 to 2367488,401408 covers (0x237000,0x5a800) to (0x242000,0x62000) DE-Wiesbaden bonn.kml description ![CDATA[DE-Wiesbaden]] /description and my layer a description bonn_20150306_1700_basemap BTW: the Oregon 650 don't show the family-name, the Oregon 450 shos it, but this seems to be a limit of the device Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] access rules
Hi Chris,
I think you got me wrong.
I don't propose to change the interpretation of bicycle=designated.
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.
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk
From: chris66...@gmx.de
Date: Fri, 6 Mar 2015 09:57:41 +0100
Subject: Re: [mkgmap-dev] access rules
Am 06.03.2015 um 08:07 schrieb Gerd Petermann:
Any thoughts?
http://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated
In this context, designated refers to the legal access a given mode of
transport has on a route, and is not meant to imply that OpenStreetMap
access=* permissions have been automatically designated only to that
transport mode! If different from a way's access permission defaults,
you must also include *=no key/value combinations for transport modes
which are restricted from using that way!
So, I think we should NOT add something like
bicycle=designated {add foot = no; add horse = no}
to the default style.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] MapSource error: MDR_TRIM_ADDR.CXX-347-6.16.3.0
Hi But the must interesting thing is that the order can be ascending or descending. Do you confirm that the order doesn't matter since it is ordered? The maps in the MDR1 section must be in ascending order of map number. Mkgmap always sorts them into ascending order and then tries to renumber all the references to the map tile to match. This sometimes (or always) fails and is a bug. I don't know what the bug is, so I suppose that if they are originally sorted in decending order then it will happen to work. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Hi Bernd, okay, sorry, I really did not want to say that using -c template.args is better than *.o5m. Don't know why I used it in my example :-( I think there is one case where it might be better: when you use a polygon-desc-file for splitter the generated template.args files contain the mapping between the *.o5m name and the desired mapname. I think Thorsten uses this with overlapping polygons. Gerd Bernd Weigelt wrote Am Freitag, 6. März 2015, 09:31:32 schrieb GerdP: Hi Gerd I fear I can't follow. I would expect that you run splitter once to create the tiles. You run mkgmap once for each layer with a different --description for each layer. I would not use template.args for this. I prefer to use the write-kml option in splitter. I load the file in JOSM to see what tile contains e.g. data from my hometown. That's what i have done before i'm using template.args and i will do this again in the future. As you remember, you gave me the hint 'keep it simple' and your command line includes tiles/template.args, not tiles/*.o5m ;-) this are my new old command lines for the basemap java -ea -Xmx6G -jar /home/bernd/map_build/splitter-r421/splitter.jar splitter.log --geonames-file=/home/bernd/map_build/cities15000.zip --mapid=6501 --output=o5m --precomp-sea=/home/bernd/map_build/sea_20150302.zip --write-kml=bonn.kml --keep-complete --overlap=0 --split-file=/home/bernd/map_build/areas/bonn_areas.list /home/bernd/map_build/o5m/bonn.o5m java -ea -Xmx6G -jar /home/bernd/map_build/mkgmap-housenumbers2-r3490/mkgmap.jar --bounds=/home/bernd/map_build/bounds_20150302.zip --precomp-sea=/home/bernd/map_build/sea_20150302.zip --generate-sea --style-file=/home/bernd/map_build/styles/basemap_style --name-tag-list=name:de,name,name:en,int_name --mapname=65001001 --family-id=4 --product-id=44 --description=bonn_20150306_1700_basemap --family-name=Basemap --draw-priority=10 -c /home/bernd/map_build/styles/options /home/bernd/map_build/tiles/*.o5m /home/bernd/map_build/styles/styles_typ.txt splitter.log includes lines like Area 65010001: 2322432,370688 to 2367488,401408 covers (0x237000,0x5a800) to (0x242000,0x62000) DE-Wiesbaden bonn.kml description /description and my layer a description bonn_20150306_1700_basemap BTW: the Oregon 650 don't show the family-name, the Oregon 450 shos it, but this seems to be a limit of the device Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Problem-to-understand-splitter-jar-description-tp5835976p5836129.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Gerd, happy to update the documentation, but where do I find its source?
I only have a PDF of the style manual.
Regards,
Mike
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 06 March 2015 10:05
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Mike,
reg. wrong car routing in oneways: I'll check that, I see no reason now.
Sounds like continue is handled like continue with actions in this case?
reg. docu for mkgmap:synthesised: yes, please post a patch for that
Gerd
_
From: m...@tvage.co.uk mailto:m...@tvage.co.uk
To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
Date: Fri, 6 Mar 2015 09:56:28 +
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Gerd,
It is possible that the order might have some significance. However, in my
own style file I also add the cycleway first and it works fine, providing I
do not attempt to start, finish or add a via point to the road. Attempting
to start, finish or add a point I can understand might be problematic as the
software would not know whether to put the point on the road or the cycleway
and may well use the order in which the lines were added.
I removed the mkgmap:synthesized line as according to the style manual the
value is yes if the way was added by the make-oppositecycleways option, and
a check of the code showed that it was the only place it was set. If the
updated style file is to replace the make-oppositecycleways option, then
this line is no longer required, as it is specific to the cycleway. To
retain the functionality, I guess that the additional line should be
highway=* (oneway=yes | oneway=-1 | oneway=true | oneway=1 |
oneway=reverse) (oneway:bicycle=no | cycleway=opposite |
cycleway=opposite_lane | cycleway=opposite_track) {delete oneway; delete
cycleway; set access=no; delete foot; delete vehicle; delete motor_vehicle;
delete motorcar; delete goods; delete hgv; delete psv; delete emergency;
delete taxi; delete bus; add bicycle=yes; set highway=cycleway; set
mkgmap:synthesised=true} [0x10 road_class=0 road_speed=1 resolution 24
continue]
Perhaps the documentation could be enhanced to mention setting
mkgmap:synthesised in a style.
Regards,
Mike
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 06 March 2015 06:40
To: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Mike,
_
Hi Gerd, I added the following to the lines file in my style and it works
fine there if I remove the --make-opposite-cycleways option, allowing just
cycling and walking against the flow. However, it doesn't seem to work
correctly if I add it to the default style (it allows cars to go the wrong
way along the one-way street).
highway=* (oneway=yes | oneway=-1 | oneway=true | oneway=1 |
oneway=reverse) (oneway:bicycle=no | cycleway=opposite |
cycleway=opposite_lane | cycleway=opposite_track) {delete oneway; delete
cycleway; set access=no; delete foot; delete vehicle; delete motor_vehicle;
delete motorcar; delete goods; delete hgv; delete psv; delete emergency;
delete taxi; delete bus; add bicycle=yes; set highway=cycleway} [0x10
road_class=0 road_speed=1 resolution 24 continue]
I can't see why this might be happening. Has anyone any ideas (the attached
patch is what I changed)?
I think that is the problem I was discussing with Minko. The order in which
routable ways are added
by the style matters, although we don't know exactly why.
With the --make-opposite-cycleways the cycle way is added after the normal
way,
with your change below it is added before.
Garmin algos seem to use only one way in some cases, esp. at the beginning
of a route.
Further thoughts:
1) Your new patch also removes the special handling for mkgmap:synthesised
in inc/access
-#limit artificial cycleways to to resolution 24
-mkgmap:synthesised=yes mkgmap:bicycle=yes { set
mkgmap:highest-resolution-only = true }
This is okay for your case, but I should mention that the tag
mkgmap:synthesised is also evaluated within mkgmap to avoid some
meaningless warnings in e.g. the roundabout checks.
In other words: A style that adds multiple routable ways for one OSM way
should try to setmkgmap:synthesised=true
when options like --check-roundabouts or --check-roundabout-flares are used.
I think we might as well set that a corresponding flag in mkgmap when it
detects
that more than one routable way was added (with res 24) for one OSM way.
2) Maybe we can replace the --make-opposite-cycleways option by
a new special tag like mkgmap:add_cycleway=[before|after] ?
Gerd
___ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Mike,
the sources are in the doc directory.
Gerd
Mike Baggaley wrote
Hi Gerd, happy to update the documentation, but where do I find its
source?
I only have a PDF of the style manual.
Regards,
Mike
From: Gerd Petermann [mailto:
gpetermann_muenchen@
]
Sent: 06 March 2015 10:05
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Mike,
reg. wrong car routing in oneways: I'll check that, I see no reason now.
Sounds like continue is handled like continue with actions in this
case?
reg. docu for mkgmap:synthesised: yes, please post a patch for that
Gerd
_
From:
mike@.co
lt;mailto:
mike@.co
gt;
To:
mkgmap-dev@.org
lt;mailto:
mkgmap-dev@.org
gt;
Date: Fri, 6 Mar 2015 09:56:28 +
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Gerd,
It is possible that the order might have some significance. However, in my
own style file I also add the cycleway first and it works fine, providing
I
do not attempt to start, finish or add a via point to the road. Attempting
to start, finish or add a point I can understand might be problematic as
the
software would not know whether to put the point on the road or the
cycleway
and may well use the order in which the lines were added.
I removed the mkgmap:synthesized line as according to the style manual the
value is yes if the way was added by the make-oppositecycleways option,
and
a check of the code showed that it was the only place it was set. If the
updated style file is to replace the make-oppositecycleways option, then
this line is no longer required, as it is specific to the cycleway. To
retain the functionality, I guess that the additional line should be
highway=* (oneway=yes | oneway=-1 | oneway=true | oneway=1 |
oneway=reverse) (oneway:bicycle=no | cycleway=opposite |
cycleway=opposite_lane | cycleway=opposite_track) {delete oneway; delete
cycleway; set access=no; delete foot; delete vehicle; delete
motor_vehicle;
delete motorcar; delete goods; delete hgv; delete psv; delete emergency;
delete taxi; delete bus; add bicycle=yes; set highway=cycleway; set
mkgmap:synthesised=true} [0x10 road_class=0 road_speed=1 resolution 24
continue]
Perhaps the documentation could be enhanced to mention setting
mkgmap:synthesised in a style.
Regards,
Mike
From: Gerd Petermann [mailto:
gpetermann_muenchen@
]
Sent: 06 March 2015 06:40
To:
mkgmap-dev@.org
lt;mailto:
mkgmap-dev@.org
gt;
Subject: Re: [mkgmap-dev] --make-opposite-cycleways option
Hi Mike,
_
Hi Gerd, I added the following to the lines file in my style and it works
fine there if I remove the --make-opposite-cycleways option, allowing just
cycling and walking against the flow. However, it doesn't seem to work
correctly if I add it to the default style (it allows cars to go the wrong
way along the one-way street).
highway=* (oneway=yes | oneway=-1 | oneway=true | oneway=1 |
oneway=reverse) (oneway:bicycle=no | cycleway=opposite |
cycleway=opposite_lane | cycleway=opposite_track) {delete oneway; delete
cycleway; set access=no; delete foot; delete vehicle; delete
motor_vehicle;
delete motorcar; delete goods; delete hgv; delete psv; delete emergency;
delete taxi; delete bus; add bicycle=yes; set highway=cycleway} [0x10
road_class=0 road_speed=1 resolution 24 continue]
I can't see why this might be happening. Has anyone any ideas (the
attached
patch is what I changed)?
I think that is the problem I was discussing with Minko. The order in
which
routable ways are added
by the style matters, although we don't know exactly why.
With the --make-opposite-cycleways the cycle way is added after the
normal
way,
with your change below it is added before.
Garmin algos seem to use only one way in some cases, esp. at the beginning
of a route.
Further thoughts:
1) Your new patch also removes the special handling for mkgmap:synthesised
in inc/access
-#limit artificial cycleways to to resolution 24
-mkgmap:synthesised=yes mkgmap:bicycle=yes { set
mkgmap:highest-resolution-only = true }
This is okay for your case, but I should mention that the tag
mkgmap:synthesised is also evaluated within mkgmap to avoid some
meaningless warnings in e.g. the roundabout checks.
In other words: A style that adds multiple routable ways for one OSM way
should try to setmkgmap:synthesised=true
when options like --check-roundabouts or --check-roundabout-flares are
used.
I think we might as well set that a corresponding flag in mkgmap when it
detects
that more than one routable way was added (with res 24) for one OSM way.
2) Maybe we can replace the --make-opposite-cycleways option by
a new special tag like mkgmap:add_cycleway=[before|after] ?
Gerd
___ mkgmap-dev mailing list
mkgmap-dev@.org
lt;mailto:
mkgmap-dev@.org
gt;
Re: [mkgmap-dev] Problem to understand splitter.jar --description
Am Samstag, 7. März 2015, 04:50:15 schrieb Andrzej Popowski: I'm not sure if I understand your problem, since solution looks simple form me - add required description after template.args, like: ... mkgmap.jar ... -c options -c template.args --description=bonn_20150503_1700_basemap --gmapsupp hi Andrzej Thank you for that additional hint. gmapsupp is the last option in my style option, in my buildscript are only variable options, except such for testing I will test it Bernd -- amarok2 now playing: artist: Tito Tarantula meets Mittermeier title: Exorcize Your Funky Little Demon album: Mittermeier Friends ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
