Hi Andrzej, thanks for the suggestions. I think I am frustrasted because the code handles so many special cases with many different "tricks", I think it is already much too complex and the result is a bit unpredictable, means, once the error is near xyz Street 12, after a small change it might be at xyz Street 18. This makes it very difficult to compare different strategies.
The algo adds new nodes where - an existing interval is not plausible, this often happens with random numbering, but also when a road is missing in the road network or name mismatches prohibit simple results - a group of houses should be found at the same position. This typically happens when a service road is missing and is a rather optional optimisation - the existing intervals cause the Garmin algo to locate the address(es) at the wrong place, this typically happens when few houses are placed along a long part straight part of the road, e.g. a single house near the end of a 150 m long road. This is also more optimisation. In many cases new nodes are just duplicates of existing nodes, these don't create cosmetic problems, but in areas with random numbers ~ 1000 or more really new nodes are needed for one tile. The overlays are "created" by the style, means, one OSM way is added two or more times, in special cases with different oneway attributes so that the points are reverted. I also thought that I should simply handle the overlay lines later, but some styles also add multiple routable ways for the same OSM way, and only one should be used for the address search, else Garmin would show multiple entries. The housenumber code follows after equal roads were merged and also after all the splitting that is done to remove loops, too long lines etc. as well as the clipping at tile boundaries. In the end, 5 lines which were added by the style for the same OSM way may appear with different sets of points, maybe sharing all, maybe sharing only a few. I simply don't dare to change all that nor do I want to do it. In short, I'd prefer to have a completely different code but seem to be unable to write it. I'll continue tomorrow, maybe sleep brings new ideas ;-) Gerd ________________________________________ Von: [email protected] <[email protected]> im Auftrag von Andrzej Popowski <[email protected]> Gesendet: Montag, 25. Januar 2016 13:45 An: [email protected] Betreff: Re: [mkgmap-dev] [Patch v1] reduce line distortion Hi Gerd, > 3) When the housenumber functions add new nodes to the road to > improve the address search, these nodes may be > 1m away from > the overlay line. Maybe do not add nodes? Or limit these nodes to cases with random numbering? I guess GPS finds position of an address as an interpolation between numbers assigned to 2 consecutive nodes. In many cases you can drop intermediate points, without worsen the functionality. > So, I'll try again to fix the overlay lines using a brute search > algo, maybe the performance doesn't matter as there are not so > many added nodes . Wouldn't be easer to move creation of overlays to this stage of algorithm? Or mark some object for creating overlays earlier and do it now? Just a thought, I don't know these algorithms. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
