Re: [mkgmap-dev] bicycle=use_sidepath
Hi, reg. routing errors: I think we should only consider results of current software, means, recent maps created by Garmin or with latest versions of mkgmap and latest Garmin software (firmware or PC software). So, if you can reproduce a case where Garmin software ignores restrictions, please post details, else I prefer to think that mkgmap is writing wrong img data. Besides that I fear that Felix is right, the risk is high that the cycleway is not connected to other roads. Unfortunately it is quite complex to detect parallel roads, I already needed that for the housenumber code and found no algo. Gerd Date: Mon, 17 Aug 2015 17:05:00 +0300 From: marko.mak...@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] bicycle=use_sidepath On Mon, Aug 17, 2015 at 03:34:26PM +0200, Felix Hartmann wrote: Definitely not I would say. It will just cause routing to break down for cyclists IMHO. Too often such sidepathes won't be connected - or maybe the sidepath is not even entered in OSM. It might not even matter if the sidepaths have been entered and connected. For long-distance routing, I believe that the Garmin Edge 705 completely ignores cycleways for the middle section of the route. Cycleways would only be considered for the first and last 5 kilometers or so. So, if you have a 50-kilometer route that would involve riding on a cyclepath next to a highway=trunk, Garmin Edge 705 would send you on a 200-kilometer detour using smaller roads. I had this happen to me a few years ago. Ways like http://www.openstreetmap.org/way/167517631 were being ignored, and http://www.openstreetmap.org/way/17065902 was tagged bicycle=no already then. That said, I guess that treating more bicycle=* values in the same way as bicycle=no will not make the situation much worse. If you want proper long-distance bicycle routing, you have to use a precalculated route (or better routing software, such as Brouter). 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] bicycle=use_sidepath
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
[mkgmap-dev] bicycle=use_sidepath
Hi all, while looking at the sharp angles problem I noticed that the default style ignores the tag bicycle=use_sidepath. Shouldn't we interpret this like bicycle=no? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, 2015 at 03:34:26PM +0200, Felix Hartmann wrote: Definitely not I would say. It will just cause routing to break down for cyclists IMHO. Too often such sidepathes won't be connected - or maybe the sidepath is not even entered in OSM. It might not even matter if the sidepaths have been entered and connected. For long-distance routing, I believe that the Garmin Edge 705 completely ignores cycleways for the middle section of the route. Cycleways would only be considered for the first and last 5 kilometers or so. So, if you have a 50-kilometer route that would involve riding on a cyclepath next to a highway=trunk, Garmin Edge 705 would send you on a 200-kilometer detour using smaller roads. I had this happen to me a few years ago. Ways like http://www.openstreetmap.org/way/167517631 were being ignored, and http://www.openstreetmap.org/way/17065902 was tagged bicycle=no already then. That said, I guess that treating more bicycle=* values in the same way as bicycle=no will not make the situation much worse. If you want proper long-distance bicycle routing, you have to use a precalculated route (or better routing software, such as Brouter). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
Definitely not I would say. It will just cause routing to break down for cyclists IMHO. Too often such sidepathes won't be connected - or maybe the sidepath is not even entered in OSM. That key should only reflect in lower priority to cycle on that road - as on a universal map focussed on car routing like the default mkgmap style - it should simply be ignored... On 17 August 2015 at 15:16, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi all, while looking at the sharp angles problem I noticed that the default style ignores the tag bicycle=use_sidepath. Shouldn't we interpret this like bicycle=no? Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org VeloMap.org Floragasse 9/11 1040 Wien Austria - Österreich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
For the Netherlands bicycle=use_sidepath should definitely be set to no; Unconnected or not drawn cycleways in combination with bicycle=use_sidepath on the main highway are mapping errors on OSM and should corrected in the database. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, 2015 at 04:33:20PM +0200, Gerd Petermann wrote: I think we should only consider results of current software, means, recent maps created by Garmin or with latest versions of mkgmap and latest Garmin software (firmware or PC software). Old but still somewhat usable devices do not receive updates any more. The very last firmware update for the Edge 705 was in 2010, almost 5 years ago. So, if you can reproduce a case where Garmin software ignores restrictions, please post details, else I prefer to think that mkgmap is writing wrong img data. Unfortunately I do not have the Edge 705 any more, so I cannot post details. But I think that Thorsten Kukuk posted a plausible explanation of what probably was going on. Unfortunately it is quite complex to detect parallel roads, I already needed that for the housenumber code and found no algo. Sure. For what it is worth, detecting parallel roads could also be useful for providing better turn instructions (copying the name of the main way to the cycleway). Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:street and street name matching for house number searchs
Your patch caught 19293 lines of my log. Although those cases must also be corrected in OSM data, they can now be put in a second priority level, so +1 from me to commit the patch. Have you thought about including alt_name in the match search when matching with name fails? I have found some cases where it can help. El 17/08/15 a las 10:42, Gerd Petermann escribió: Hi Carlos, today I revieved the source and found that my statement was no longer true, mkgmap knows the roads and can ignore the capitalization. My argument was based on a previous version in the housenumber2 branch. The attached patch will solve many, but probably not all cases. Instead of WARN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad e:\osm_out_work\niedersachsen\20150810_082633\63240021.o5m: found no plausible road for address Am kleinen Esch 1D(0) http://www.openstreetmap.org/node/1601720743 it will now print WARN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\osm_out_work\niedersachsen\20150810_082633\63240021.o5m: accepting match in spite of different capitalization Am Kleinen Esch 1D (http://www.openstreetmap.org/browse/way/43561741) house: http://www.openstreetmap.org/node/1601720743 and it will use the address. I did not check special cases, e.g. when there are multiple close roads with different spelling. Also, addr:interpolation ways with different spelling may not yet fully work, but it should help in most cases. A binary is here: |http://files.mkgmap.org.uk/download/275/mkgmap.jar |Gerd Date: Sun, 16 Aug 2015 17:20:38 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] addr:street and street name matching for house number searchs OK, I see, not an easy matter. I will then have to deal with the nearly 90.000 lines of this type in my log for Spain;-) El 13/08/15 a las 08:10, Gerd Petermann escribió: Hi Carlos, not sure what to do here. See first this discussion: http://gis.19327.n5.nabble.com/address-search-and-case-significance-of-street-name-tp5840995.html My problem reg. suppression of certain messages is that current code in mkgmap is not able to find a nearly matching road name, so it has no way to say differs only in capitalization or maybe differs only slightly, it just doesn't find a road. Gerd Date: Wed, 12 Aug 2015 13:54:51 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] addr:street and street name matching for house number searchs HousenumberRoad throws a warning when addr:street from a node and name of the street the node is next to are not equal, even if they differ only in the capitalization. See for example nodes http://www.openstreetmap.org/node/2486105470 and http://www.openstreetmap.org/node/2486105464 (addr:street=carrer del Montseny) which are next to way http://www.openstreetmap.org/way/8590864 with name=Carrer del Montseny. One of the names is more correct than the other but, having in mind that Garmin changes capitalization arbitrarily, I'm not sure if we should keep these warnings. Another case to discuss is when one of addr:street or way name contains special letters and the other one not (eg. Asturies vs Astúries). Here one of the names is wrongly written and should be corrected in OSM data, so may be worth keeping the warning. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
On Mon, Aug 17, Marko Mäkelä wrote: It might not even matter if the sidepaths have been entered and connected. For long-distance routing, I believe that the Garmin Edge 705 completely ignores cycleways for the middle section of the route. Cycleways would only be considered for the first and last 5 kilometers or so. Since the roads in Iceland are strange, I debugged some routing errors, where I should go a way 1000km longer then the normal way. The problem is road_class. It looks like, that at least the Garmin GPS 62s, at the beginning prefers increasing road_classes, and later decreasing ones. But in the middle, it is avoiding going up and down. So if you reach road_class=2, and there is a short cycleway with road_class=1, and a very long primary road with road_class=3, Garmin will use the very long primary road. Even if you route for shortest distance. I workarounded this by increasing the road_class of cycleways for my style. Thorsten -- Thorsten Kukuk, Senior Architect SLES Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bicycle=use_sidepath
Hi Marko, okay, I agree that Thorstens theory sounds good. I plan to verify it during the next days, maybe it can be used to add checks or change the default style. Gerd Date: Mon, 17 Aug 2015 20:42:23 +0300 From: marko.mak...@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] bicycle=use_sidepath On Mon, Aug 17, 2015 at 04:33:20PM +0200, Gerd Petermann wrote: I think we should only consider results of current software, means, recent maps created by Garmin or with latest versions of mkgmap and latest Garmin software (firmware or PC software). Old but still somewhat usable devices do not receive updates any more. The very last firmware update for the Edge 705 was in 2010, almost 5 years ago. So, if you can reproduce a case where Garmin software ignores restrictions, please post details, else I prefer to think that mkgmap is writing wrong img data. Unfortunately I do not have the Edge 705 any more, so I cannot post details. But I think that Thorsten Kukuk posted a plausible explanation of what probably was going on. Unfortunately it is quite complex to detect parallel roads, I already needed that for the housenumber code and found no algo. Sure. For what it is worth, detecting parallel roads could also be useful for providing better turn instructions (copying the name of the main way to the cycleway). Best regards, 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
[mkgmap-dev] Commit: r3629: remove dead test code
Version mkgmap-r3629 was committed by gerd on Mon, 17 Aug 2015 remove dead test code ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] addr:street and street name matching for house number searchs
Hi Carlos, today I revieved the source and found that my statement was no longer true, mkgmap knows the roads and can ignore the capitalization. My argument was based on a previous version in the housenumber2 branch. The attached patch will solve many, but probably not all cases. Instead of WARN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad e:\osm_out_work\niedersachsen\20150810_082633\63240021.o5m: found no plausible road for address Am kleinen Esch 1D(0) http://www.openstreetmap.org/node/1601720743 it will now print WARN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\osm_out_work\niedersachsen\20150810_082633\63240021.o5m: accepting match in spite of different capitalization Am Kleinen Esch 1D (http://www.openstreetmap.org/browse/way/43561741) house: http://www.openstreetmap.org/node/1601720743 and it will use the address. I did not check special cases, e.g. when there are multiple close roads with different spelling. Also, addr:interpolation ways with different spelling may not yet fully work, but it should help in most cases. A binary is here: http://files.mkgmap.org.uk/download/275/mkgmap.jar Gerd Date: Sun, 16 Aug 2015 17:20:38 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] addr:street and street name matching for house number searchs OK, I see, not an easy matter. I will then have to deal with the nearly 90.000 lines of this type in my log for Spain;-) El 13/08/15 a las 08:10, Gerd Petermann escribió: Hi Carlos, not sure what to do here. See first this discussion: http://gis.19327.n5.nabble.com/address-search-and-case-significance-of-street-name-tp5840995.html My problem reg. suppression of certain messages is that current code in mkgmap is not able to find a nearly matching road name, so it has no way to say differs only in capitalization or maybe differs only slightly, it just doesn't find a road. Gerd Date: Wed, 12 Aug 2015 13:54:51 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] addr:street and street name matching for house number searchs HousenumberRoad throws a warning when addr:street from a node and name of the street the node is next to are not equal, even if they differ only in the capitalization. See for example nodes http://www.openstreetmap.org/node/2486105470 and http://www.openstreetmap.org/node/2486105464 (addr:street=carrer del Montseny) which are next to way http://www.openstreetmap.org/way/8590864 with name=Carrer del Montseny. One of the names is more correct than the other but, having in mind that Garmin changes capitalization arbitrarily, I'm not sure if we should keep these warnings. Another case to discuss is when one of addr:street or way name contains special letters and the other one not (eg. Asturies vs Astúries). Here one of the names is wrongly written and should be corrected in OSM data, so may be worth keeping the warning. -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev housenumber-capitalization-v1.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
