[mkgmap-dev] Numbering loss in the version which came after the r3602
From GerdP gpetermann_muenchen at hotmail.com on Wed Aug 19 12:05:14 BST 2015
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 < > gpetermann_muenchen@ > > 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 at .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 < > alexandre.loss@ > >: >> 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_muenchen@ > > 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 interpolated >> numbers from addr:interpolations ways for roads with name RUA PORTO >> ALEGRE >> >> >> is not very clear about the reason and the final action, but I think the >> data is not okay and the algo is correct >> to ignore it. >> >> What do you think? >> Gerd >> >> Date: Wed, 17 Jun 2015 15:28:04 -0300 >> From: > alexandre.loss@ >> To: > mkgmap-dev at .org >> CC: > Adm_Tec_Tracksource@ >> Subject: Re: [mkgmap-dev] Numbering loss in the version which came after >> the r3602 >> >> Hi Andrzej, >> >> Ok, thank you for your time and analyses. >> Lets wait for Gerd. >> >> regards, >> Alexandre >> >> >> 2015-06-17 13:13 GMT-03:00 Andrzej Popowski < > popej at .onet > >: >> Hi Alexandre, >> >> I confirm, that there is no address on your map with current mkgmap. Data >> seems to be OK, so lets wait for Gerd opinion. >> >> >> -- >> Best regards, >> Andrzej >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ mkgmap-dev mailing list > mkgmap-dev at .org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> >> >> _______________________________________________ mkgmap-dev mailing list > mkgmap-dev at .org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> _______________________________________________ >> mkgmap-dev mailing list >> > mkgmap-dev at .org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at .org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > image.png (47K) > <http://gis.19327.n5.nabble.com/attachment/5852681/0/image.png> > image.png (36K) > <http://gis.19327.n5.nabble.com/attachment/5852681/1/image.png> -- View this message in context: http://gis.19327.n5.nabble.com/Numbering-loss-in-the-version-which-came-after-the-r3602-tp5848348p5852683.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
- Previous message: [mkgmap-dev] Numbering loss in the version which came after the r3602
- Next message: [mkgmap-dev] option to omit road refs from index:
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list