Hi all, I am a bit desolated reg. this problem, maybe you have new ideas for me. I try to describe what happens: 1) The style adds a road and one or more overlay lines 2) Before housenumber processing the roads are processed by the so called RoadMerger which may connect two or more roads with similar attributes, after that there is no easy way to find the corresponding overlay lines for a road. 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. My first approach was to change the housenumber code so that it adds only nodes which are very close to the overlay line, but that turned out to be impossible in some cases, means, we either have bad results in address search or visible line distortions. Another approach would be to add the nodes also to the overlay ways, but as I said I see no easy and performant way to find the corresponding overlay lines, as they also may have a reverse order of points. My experience tells me that I should better try to find a completely different approach for the housenumbers, but up to now there was no "heureka" . If the img format would allow to say "use this point only for address search, but not for rendering" all would be easy, but I don't think that this is possible ? 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 . Gerd Gerd Petermann wrote

Hi Minko,

thanks for the picture. I think the fix is not yet catching all cases, so I'll continue working on it.

Gerd

________________________________________ Von:

mkgmap-dev-bounces@.org

<

mkgmap-dev-bounces@.org

> im Auftrag von Minko <

ligfietser@

> Gesendet: Mittwoch, 20. Januar 2016 17:22 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [Patch v1] reduce line distortion

Thanks for the fix Gerd!

For an example of this fixed issue, see http://www.dropbox.com/s/ny2c769np3zq40k/bug_fixed.jpg?raw=1

Gerd wrote:

...

I think a distance of less than 0.4 m is not visible, and nearly all calculated points are now closer than that. A binary based on r3658 is here: http://files.mkgmap.org.uk/download/287/mkgmap.jar

---

mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list

mkgmap-dev@.org

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-reduce-line-distortion-tp5865262p586... Sent from the Mkgmap Development mailing list archive at Nabble.com.

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: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Montag, 25. Januar 2016 13:45 An: mkgmap-dev@lists.mkgmap.org.uk 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Andrzej, I came more or less to the same conclusion. I think I also have a new and better idea regarding the data structures and - flow for the housenumber code. and the brute search algo suggested yesterday seems to be too slow. The current code suffers from rounding errors which happen because the position of an address is stored as a double which depends on the length of the way segment and the position of the nodes. A new node means a lot of recalculations and it is very complicated to compare the positions of addresses which are assigned to different intervals. My new idea whould store the position as an int which gives the metres from the start of the (original) road. I am not sure if that causes problems with houses which are before the start or after the end, but I think I should ease many calculations. 2nd idea: Instead of calculating a good split point and searching for a real Garmin point close to it which causes small or zero line distortion the algo could start calculating all those points Garmin points which are very close or on the way and check if they can be used to improve address search. If there are to few good points to split the algo can still combine some addresses at existing nodes to improve the result. I have to find out how this will work with the random case. Gerd ________________________________________ Von: mkgmap-dev-bounces@lists.mkgmap.org.uk <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Montag, 25. Januar 2016 23:41 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] [Patch v1] reduce line distortion Hi Gerd, I guess you already got very complicated code ;) I'm not perfectionist, I would accept some errors in processing. For example address placing precision could be in range 20-50m. If there is a node in this range, I would try use it for multiple addresses. I'm afraid that inserting a new node within distance 20m from existing node could distort lines on 24-bit layer and should be avoided. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev