Re: [mkgmap-dev] Wierd routing problem
That seems to have done the trick :) I've emailed the CreateIMG author, referring him to this discussion, in case he'd like to issue an updated version. I'll also investigate some of the other new options you describe, but for now I think I've got something which works pretty well. Thank you! -- John In article dub112-w83092afe92bc7355bb53aa9e...@phx.gbl, gpetermann_muenc...@hotmail.com says... Hi John, I was able to reproduce the problem. I think it is caused by a wrong flag in the map regarding drive-on-left, means, Basecamp probably assumes that you are driving on the right side. The problem can be fixed using the --drive-on=left option or the --bounds option which allows mkgmap to detect the correct setting for a country. Please note that the script createIMG.bat is quite out-aged, it doesn't use powerful options like --index, --bounds, --precomp-sea, and --housenumbers. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patch for omitting nearby POIs with the same name and type
Hi, please find attached a patch that adds two new options: --max-same-poi-distance=distance and --include-nearby-poi-types=type[,type...]. These options are used to determine whether nearby POIS are duplicates and should be omitted from the map, extending the existing check for duplicates at the exact same location. They help to reduce the problems cause by OSM data frequently having an area such as a building tagged with the same information as a point or where multiple areas are given the same name - this is most problematic if the --add-pois-to-areas option is used. It may be valid for some named POI types to be found close together hence the option to omit certain types of POI from the nearby processing. I have the distance set to 50 with bus stops and cave entrances always included and this seems to work well for me (I don't use the default style). If --max-same-poi-distance is omitted or set to 0, the check works as previously. Please try and if OK, commit. Thanks, Mike nearbypoi.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] Warnings about correct ways produced by --check-roundabout-flares
Using --max-flare-length-ratio some of the warnings disappear, but it seems to have quite a random effect or at least not as described in options file. Many ways longer than the specified value are kept in the warnings. Among the removed ones there are both valid and invalid warnings, so not too useful. In addition to the examples below, there are also warnings about ways that are not connected to any roundabout: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/319137664) does not start at flare? http://www.openstreetmap.org/?mlat=36.678070mlon=-6.144893zoom=17 Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/31889812) is not oneway? http://www.openstreetmap.org/?mlat=41.485840mlon=2.132381zoom=17 El 11/08/15 a las 08:31, Gerd Petermann escribió: Hi Carlos, up to now I did not even understand what a roundabout-flare is ;-) Did you try the --max-flare-length-ratio option? Gerd Date: Mon, 10 Aug 2015 18:12:27 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Warnings about correct ways produced by --check-roundabout-flares Option --check-roundabout-flares produces a lot of warnings about ways that are correct IMHO, like the following examples: (RouteNode): 55114001.o5m: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/22974731) points in wrong direction? http://www.openstreetmap.org/?mlat=39.476332mlon=-6.340242zoom=17 (RouteNode): 55114002.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/53537671) does not finish at flare? http://www.openstreetmap.org/?mlat=36.471647mlon=-6.207968zoom=17 (RouteNode): 55114001.o5m: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/183666800) points in wrong direction? http://www.openstreetmap.org/?mlat=40.026175mlon=-6.096136zoom=17 (RouteNode): 55114001.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/55608338) points in wrong direction? http://www.openstreetmap.org/?mlat=39.430758mlon=-6.365738zoom=17 (RouteNode): 55114002.o5m: Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/226321374) points in wrong direction? http://www.openstreetmap.org/?mlat=37.234124mlon=-7.250831zoom=17 Code for this check was written long ago now and perhaps could be improved some way to avoid such noise. I can supply more examples if needed, my log is full of them. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
So... Does this means that you fix it? It's good to hear this, because in that example I sent, in fact there was an error in data. But as soon I share this in my group, I receive a storm of examples were the data are similar that, but aren't problem in data. Alexandre (Enviado via iPad) Em 19/08/2015, às 02:49, Gerd Petermann gpetermann_muenc...@hotmail.com escreveu: Hi Alexandre, okay, good to hear that. I decided to make mkgmap tests regarding addr:interpolation ways rather strict because in some areas (mostly Canada) these errors appear extremely often, caused by bad imports. Seems to be a generel problem of OSM generators ;-) Gerd Date: Tue, 18 Aug 2015 15:40:40 -0300 From: alexandre.l...@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk CC: adm_tec_tracksou...@googlegroups.com Subject: Re: [mkgmap-dev] Numbering loss in the version which came after the r3602 Hi Gerd, I'm sorry the delay to answer, but I came on vacation and had many pending issues waiting for me. Regard this specific issue, your interpretation of the problem of duplication/overlap in the numbering interpolation is correct. In fact the data doesn't make sense and I agree with you that this case is an error in the data. To prove this, I got the short example sent before and correctly input the numbers eliminating the overlapping as shown below: And then I compiled the map with mkgmap versions 3612 and 3629 (the last one I found) and the numbers were not missed this time, proving you theory. Snapshot taken form MapSource of a map compiled wiht mkgmap r3612 Snapshot taken form MapSource of a map compiled wiht mkgmap r3629 image.png So I think we can close the case and I have some work do clean the maps of my group. Thanks again for your attention and analysis. Best regards, Alexandre Loss 2015-07-21 9:06 GMT-03:00 Alexandre Loss alexandre.l...@gmail.com: Hi Gerd and Steve, Thanks by your attention. I'm in vocation now and without access to my computer, so I can't provide more information if you need till my return in beginning of August. But I think that the data is correct because in despite the streets have the same name, they are different road since they aren't connect (there is a gap / a block between them). So I believe that the algo couldn't consider the name of street. But I understand your point of view, since it looks that can have a number overlapping/shadow of both streets, what would be a logical error. Unfortunately, I can make more test these days but as soon I come back I will. Thanks, Alexandre (Enviado via iPad) Em 21/07/2015, às 06:21, Gerd Petermann gpetermann_muenc...@hotmail.com escreveu: Hi Alexandre, I think the problem here is that you have two ways named RUA PORTO ALEGRE, one with id 2, the other with id 46, and both are in the same city. So far no problem, but the addr:interpolation ways on those two roads also produce a bunch of duplicate numbers. As a result, the new algo decides to ignore them. Unfortunately, the log FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to different roads in cluster RUA PORTO ALEGRE 2(0) 2(1) FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to different roads in cluster RUA PORTO ALEGRE 3(0) 3(1) FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/13 800..2, step=2 generated even interpolated number(s) for id=2, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/14 801..3, step=2 generated odd interpolated number(s) for id=2, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 419..205, step=2 generated odd interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 203..3, step=2 generated odd interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 418..204, step=2 generated even interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 202..2, step=2 generated even interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\testdata\03205200-vila_velha.osm: found problems with
Re: [mkgmap-dev] Numbering loss in the version which came after the r3602
Hi Alexandre, whenever you think that mkgmap can do better please post the corresponding data. Gerd Alexandre Loss wrote So... Does this means that you fix it? It's good to hear this, because in that example I sent, in fact there was an error in data. But as soon I share this in my group, I receive a storm of examples were the data are similar that, but aren't problem in data. Alexandre (Enviado via iPad) Em 19/08/2015, às 02:49, Gerd Petermann lt; gpetermann_muenchen@ gt; escreveu: Hi Alexandre, okay, good to hear that. I decided to make mkgmap tests regarding addr:interpolation ways rather strict because in some areas (mostly Canada) these errors appear extremely often, caused by bad imports. Seems to be a generel problem of OSM generators ;-) Gerd Date: Tue, 18 Aug 2015 15:40:40 -0300 From: alexandre.loss@ To: mkgmap-dev@.org CC: Adm_Tec_Tracksource@ Subject: Re: [mkgmap-dev] Numbering loss in the version which came after the r3602 Hi Gerd, I'm sorry the delay to answer, but I came on vacation and had many pending issues waiting for me. Regard this specific issue, your interpretation of the problem of duplication/overlap in the numbering interpolation is correct. In fact the data doesn't make sense and I agree with you that this case is an error in the data. To prove this, I got the short example sent before and correctly input the numbers eliminating the overlapping as shown below: And then I compiled the map with mkgmap versions 3612 and 3629 (the last one I found) and the numbers were not missed this time, proving you theory. Snapshot taken form MapSource of a map compiled wiht mkgmap r3612 Snapshot taken form MapSource of a map compiled wiht mkgmap r3629 image.png So I think we can close the case and I have some work do clean the maps of my group. Thanks again for your attention and analysis. Best regards, Alexandre Loss 2015-07-21 9:06 GMT-03:00 Alexandre Loss lt; alexandre.loss@ gt;: Hi Gerd and Steve, Thanks by your attention. I'm in vocation now and without access to my computer, so I can't provide more information if you need till my return in beginning of August. But I think that the data is correct because in despite the streets have the same name, they are different road since they aren't connect (there is a gap / a block between them). So I believe that the algo couldn't consider the name of street. But I understand your point of view, since it looks that can have a number overlapping/shadow of both streets, what would be a logical error. Unfortunately, I can make more test these days but as soon I come back I will. Thanks, Alexandre (Enviado via iPad) Em 21/07/2015, às 06:21, Gerd Petermann lt; gpetermann_muenchen@ gt; escreveu: Hi Alexandre, I think the problem here is that you have two ways named RUA PORTO ALEGRE, one with id 2, the other with id 46, and both are in the same city. So far no problem, but the addr:interpolation ways on those two roads also produce a bunch of duplicate numbers. As a result, the new algo decides to ignore them. Unfortunately, the log FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to different roads in cluster RUA PORTO ALEGRE 2(0) 2(1) FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator e:\testdata\03205200-vila_velha.osm: keeping duplicate numbers assigned to different roads in cluster RUA PORTO ALEGRE 3(0) 3(1) FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/13 800..2, step=2 generated even interpolated number(s) for id=2, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/14 801..3, step=2 generated odd interpolated number(s) for id=2, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 419..205, step=2 generated odd interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/65 203..3, step=2 generated odd interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 418..204, step=2 generated even interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN: uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberIvl e:\testdata\03205200-vila_velha.osm: http://www.openstreetmap.org/way/66 202..2, step=2 generated even interpolated number(s) for id=46, RUA PORTO ALEGRE FEIN:
Re: [mkgmap-dev] patch for omitting nearby POIs with the same name and type
Hi Mike, thanks for the patch. I think the docu should mention that --max-same-poi-distance expects a value in metres. Looking at the code I see one small -maybe unwanted - side effect: If --max-same-poi-distance 0 only duplicated named POI are removed. When I coded the original code I thought that it is ok to remove e.g. pillars when they appear at the same map point. For those that like to test: I've uploaded a binary here: http://files.mkgmap.org.uk/download/276/mkgmap.jar Gerd From: m...@tvage.co.uk To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 19 Aug 2015 23:14:53 +0100 Subject: [mkgmap-dev] patch for omitting nearby POIs with the same name and type Hi, please find attached a patch that adds two new options: --max-same-poi-distance=distance and --include-nearby-poi-types=type[,type...]. These options are used to determine whether nearby POIS are duplicates and should be omitted from the map, extending the existing check for duplicates at the exact same location. They help to reduce the problems cause by OSM data frequently having an area such as a building tagged with the same information as a point or where multiple areas are given the same name – this is most problematic if the --add-pois-to-areas option is used. It may be valid for some named POI types to be found close together hence the option to omit certain types of POI from the nearby processing. I have the distance set to 50 with bus stops and cave entrances always included and this seems to work well for me (I don’t use the default style). If --max-same-poi-distance is omitted or set to 0, the check works as previously. Please try and if OK, commit. Thanks,Mike ___ 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] What's the meaning of the 'has no region' warnings?
Hi, On Wed, Aug 19, Gerd Petermann wrote: I still have no idea where the data is used. Maybe the device shows some additional info when you drive on a motorway. When Mark Burton committed the code with r984 he did not describe the wanted effect, but he also seemed to be unsure about its positive effects, see here: http://www.mkgmap.org.uk/websvn/listing.php?repname=mkgmaprev=984 and here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001293.html It looks like this is the code responsible for exit:to and similar variables. I played with this some time ago and the informations are shown in mapsource, don't remember anymore about my GPS device. The problem is, with the current way how things are mapped in OSM, it is nearly impossible to fill out this fields correct only with a style file. This would need help of mkgmap itself. That's why I stopped looking at it. But I haven't found a way to search for them, too. In the end, I would let the code stay and not remove it. 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
[mkgmap-dev] road construction
with road construction can there be many road speeds , e.g. 40, 60, 20 ,80 and 50, 70 ( kph) but still with the same classification as construction . or could this also be the same for un paved roads . stephen ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] What's the meaning of the 'has no region' warnings?
Hi all, I hesitate to commit this patch because I think that we probably can remove the code instead of fixing it. I found this in imgformat-1.0.pdf: Highway Records, Exit Records and Highway Data Records These records were apparently used by the old Roads and Recreation maps to describe services available at various highway exits, rest areas and so on In mkgmap we have code to write these records, and this code prints the has no region warning. I still have no idea where the data is used. Maybe the device shows some additional info when you drive on a motorway. When Mark Burton committed the code with r984 he did not describe the wanted effect, but he also seemed to be unsure about its positive effects, see here: http://www.mkgmap.org.uk/websvn/listing.php?repname=mkgmaprev=984 and here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001293.html I don't know if the problems regarding the basemap were solved later, but my Oregon 600 doesn't seem to allow to search for exits at alll. Maybe I have to enable/disable an option for this. Does anybody know more? Gerd Date: Tue, 18 Aug 2015 21:14:49 +0200 From: cdavi...@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] What's the meaning of the 'has no region' warnings? Regarding your patch I just can say that it zaps the warnings. I don't have any idea of other effects it may have either. El 13/08/15 a las 07:29, Gerd Petermann escribió: Hi Steve, attached is a patch to use the nodes' region. Please check: If I got that right, mkgmap collects and writes the exists for each highway, so I wonder what should happen when the input file contains two different highways with the same ref (maybe A1). I have no idea where the highway/exit info is used, so I don't know how to test the effect. Gerd To: mkgmap-dev@lists.mkgmap.org.uk From: st...@parabola.me.uk Date: Wed, 12 Aug 2015 23:08:26 +0100 Subject: Re: [mkgmap-dev] What's the meaning of the 'has no region' warnings? Hi Gerd @Steve: The code was introduced with r984 and it used the default region to create a label instead of first checking the nodes' region attribute. I don't understand that. This was before the bounds file, and I would think that there would have been close to zero chance that any exit nodes would have had a region tag in OSM at that time. So I guess it was just not important at the time. I certainly don't recall any reason for it. ..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
