logo separator

[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 &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: 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 &lt;

> popej at .onet

> &gt;:
>> 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)
> &lt;http://gis.19327.n5.nabble.com/attachment/5852681/0/image.png&gt;
> image.png (36K)
> &lt;http://gis.19327.n5.nabble.com/attachment/5852681/1/image.png&gt;





--
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.


More information about the mkgmap-dev mailing list