logo separator

[mkgmap-dev] [Patch v1] reduce line distortion

From Gerd Petermann GPetermann_muenchen at hotmail.com on Mon Jan 25 14:23:35 GMT 2016

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


More information about the mkgmap-dev mailing list