[mkgmap-dev] RoadMerger
From WanMil wmgcnfg at web.de on Mon Jan 6 21:20:06 GMT 2014
Hi Gerd, > Hi WanMil, > > two points: > 1) line 517 is obsolete: > mergePoints.add(end); > It just blows up the size of the list and processing time. Yep. I've found another important thing: the road merger can merge many more ways when it reverses non oneway ways. This should be no problem so let's do it :-) I will post another patch. > > 2) You were right regarding closed ways and different results. > The merge may create p-shaped loops. > See way 80605369. > If the northern node 381305537 is merged first: > 2014/01/06 10:20:40 Fein (RoadMerger): e:\gerd\sp_out\63240030.o5m: > Merge 33134762 and 80605369 with angle 23.159455845890676 > and later: > 2014/01/06 10:20:40 Fein (RoadMerger): e:\gerd\sp_out\63240030.o5m: > Merge 33134762 and 80605327 with angle 44.86962367701949 > This produced a p-shaped road (including a loop). > > If the node 374244500 is processed first, no merge > happens because this would produce a closed loop, so > the node is added to mergeCompletedPoints. > > The p-shaped road is split later in StyledConverter, so this is not an > error, > but obviously it makes no sense to merge first and split again later. > Maybe you see a simple solution for this? It's possible to exclude all merges where one or more points of the second way (excluding the merging point) is already part of the first way. To me it doesn't sound good regarding performance... But I will try and maybe it's better then splitting it afterwards. > > Gerd >
- Previous message: [mkgmap-dev] RoadMerger
- Next message: [mkgmap-dev] [PATCH] RoadMerger reverses roads
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list