Hi WanMil, two points: 1) line 517 is obsolete: mergePoints.add(end); It just blows up the size of the list and processing time. 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? Gerd
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
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road. A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction). Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail. WanMil
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.
Hi WanMil, the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : 223 (valid) turn restirictions, 25 invalid (The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road) Do you think that this could be okay? Gerd Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road. A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction). Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail. WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I will check that. WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I've found two problems but have no time today to fix it. Will post a patch within the next days. Thanks a lot for testing!! WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Attached is another patch that reverses roads in the RoadMerger if applicable. I have checked the patch by adding debug statements to the RestrictionRelation.addRestriction(..) method. There are some differences but as far as I could see the differences are only in some coords. I have checked some and all were caused by road merges. Example: 3---2--- \ 4--------1---5 When having a only_straightforward restriction from 4 via 1 to 5 point 2 is added to the restriction without merging. When merging the road 1-2 and 2-3 node 2 is no longer a routing node and therefor point 3 is added to the restriction instead of point 2. @Gerd: can you please check again if your tests still show any problem? Thanks! WanMil
Hi Gerd,
I've found two problems but have no time today to fix it. Will post a patch within the next days.
Thanks a lot for testing!!
WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Wanmil, if mkgmap is reversing roads, do you consider that I render cycleway:left=lane etc on non oneway streets? This has an impact if roads are reversed, the cycleway will be drawn on the wrong side of the street.
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.
Am Sonntag, 12. Januar 2014, 11:10:41 schrieb Minko:
Wanmil, if mkgmap is reversing roads, do you consider that I render cycleway:left=lane etc on non oneway streets? This has an impact if roads are reversed, the cycleway will be drawn on the wrong side of the street.
In my mind, oneway=-1 is a case of dirty mapping. I don't know a reason to map a street with this, because it's IMHO better to use oneway=yes. oneway=-1 should be marked as has to be fixed. I clean up this tag before i add something like *:forward or *:backward. Bernd
Bernd wrote
In my mind, oneway=-1 is a case of dirty mapping.
I don't know a reason to map a street with this, because it's IMHO better to use oneway=yes. oneway=-1 should be marked as has to be fixed.
I clean up this tag before i add something like *:forward or *:backward.
Bernd
I was referring to this patch where all roads are being reversed *without* a oneway=* tag. So whether oneway=-1 is good tagging or not is not relevant in this case. Other tags that have taken into account are motor_vehicle:forward=* motor_vehicle:backward=* bicycle:forward / backward etc
minko user , your e-mails are goeing into spam box , on gmail any ideas ? stephen galow On Sun, Jan 12, 2014 at 9:49 PM, Minko <ligfietser@online.nl> wrote:
Bernd wrote
In my mind, oneway=-1 is a case of dirty mapping.
I don't know a reason to map a street with this, because it's IMHO better to use oneway=yes. oneway=-1 should be marked as has to be fixed.
I clean up this tag before i add something like *:forward or *:backward.
Bernd
I was referring to this patch where all roads are being reversed *without* a oneway=* tag. So whether oneway=-1 is good tagging or not is not relevant in this case.
Other tags that have taken into account are motor_vehicle:forward=* motor_vehicle:backward=* bicycle:forward / backward etc
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am Sonntag, 12. Januar 2014, 12:49:39 schrieb Minko:
I was referring to this patch where all roads are being reversed *without* a oneway=* tag. So whether oneway=-1 is good tagging or not is not relevant in this case.
It was my error, this should be an answer in the thread 'wrong rendering...' sorry Bernd
Hi,
Wanmil, if mkgmap is reversing roads, do you consider that I render cycleway:left=lane etc on non oneway streets? This has an impact if roads are reversed, the cycleway will be drawn on the wrong side of the street.
If you create routable ways for them I think it patch will cause trouble. Maybe we need a tag like mkgmap:reversible=no tell the road merger that this road is not a oneway but still has a direction? Gerd
Hi,
Maybe we need a tag like mkgmap:reversible=no
Isn't a bigger problem there? The situation is that single OSM way creates multiple Garmin ways. This could be done by copying OSM way or by referencing OSM way for new Garmin object. Both variants can cause problems. If there is a copy, then it could be processed differently, for example when simplifying. And I think routable roads are processed different than non-routable. This would lead to misalignment for Garmin objects. If a new object uses a reference, then there will be problems like with reversing. And any other processing of OSM way can lead to some problems too. Multiplying of Garmin objects is done by "continue" statement in object definition. I'm not sure, how this is processed internally in mkgmap, probably it is using a reference. Maybe would be helpful if we could select if there should be copy or reference for Garmin object? For example there could be a statement like "continue_with_copy". -- Best regards, Andrzej
Hi Andrzej,
Isn't a bigger problem there?
The situation is that single OSM way creates multiple Garmin ways. This could be done by copying OSM way or by referencing OSM way for new Garmin object. Both variants can cause problems.
If there is a copy, then it could be processed differently, for example when simplifying. And I think routable roads are processed different than non-routable. This would lead to misalignment for Garmin objects.
If a new object uses a reference, then there will be problems like with reversing. And any other processing of OSM way can lead to some problems too.
since r2435 mkgmap always creates copies of the list with the point references, so that reversing of one copy doesn't influence the other copies. On the other hand, the routines that remove points (short-arc-removal with value
0 or the wrong-angle-handling in the high-prec-branch) make sure that the changes are applied to the copies as well, and this is done by overwriting the list of points again.
Multiplying of Garmin objects is done by "continue" statement in object definition. I'm not sure, how this is processed internally in mkgmap, probably it is using a reference. Maybe would be helpful if we could select if there should be copy or reference for Garmin object? For example there could be a statement like "continue_with_copy".
What problem do you want to solve with that? Should it reduce memory needs? Gerd
Hi Gerd,
since r2435 mkgmap always creates copies of the list with the point references, so that reversing of one copy doesn't influence the other copies.
So if copy is reversed too, then not because of routable roads merging but maybe because it is merged in a separate action too? Then suggested attribute mkgmap:reversible=no for a copy could solve problems.
For example there could be a statement like "continue_with_copy". What problem do you want to solve with that? Should it reduce memory needs?
Probably should be "continue_with_reference", if copy is default. It won't solve problems but could add some choice for map creator. -- Best regards, Andrzej
Gerd, I dont create a routable way for those items, but I dont know if the orientation will be different for the rendering if the way is reversed in direction. I assume left would become right, so a left sided bike lane would turn up on the right side?
If you create routable ways for them I think it patch will cause trouble. Maybe we need a tag like mkgmap:reversible=no tell the road merger that this road is not a oneway but still has a direction?
Gerd
Hi Minko, I see no problem as long as the bitmap for the routable way is not direction depended. The order of processing is now this: for one OSM way your style adds - one or more routable ways - one or more non-routable ways For each of them mkgmap creates a copy of the list of points and reverses the points for the oneway=-1 or oneway=reverse ways. Later, the routable ways are passed to the routine that removes short arcs or wrong angles. If the first one is changed by that routine, all other copies are changed as well to make sure that all copies are displayed at the same position. Next, the routable ways are passed to the road merger, the non-routable ways are not touched by the road merger or any other routine like the ones that splits roads with loops. As long as we keep that order it should work, allthough the splitting sometimes adds points which may cause small differences between the displayed road and the overlay lines. Gerd
Date: Sun, 12 Jan 2014 15:45:14 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Gerd, I dont create a routable way for those items, but I dont know if the orientation will be different for the rendering if the way is reversed in direction. I assume left would become right, so a left sided bike lane would turn up on the right side?
If you create routable ways for them I think it patch will cause trouble. Maybe we need a tag like mkgmap:reversible=no tell the road merger that this road is not a oneway but still has a direction?
Gerd
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, reg. turn restrictions I see no change in my test case, but I just compared the numbers. Gerd Date: Sat, 11 Jan 2014 22:25:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads Attached is another patch that reverses roads in the RoadMerger if applicable. I have checked the patch by adding debug statements to the RestrictionRelation.addRestriction(..) method. There are some differences but as far as I could see the differences are only in some coords. I have checked some and all were caused by road merges. Example: 3---2--- \ 4--------1---5 When having a only_straightforward restriction from 4 via 1 to 5 point 2 is added to the restriction without merging. When merging the road 1-2 and 2-3 node 2 is no longer a routing node and therefor point 3 is added to the restriction instead of point 2. @Gerd: can you please check again if your tests still show any problem? Thanks! WanMil
Hi Gerd,
I've found two problems but have no time today to fix it. Will post a patch within the next days.
Thanks a lot for testing!!
WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, what does that mean? Do you see the same following results: r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : 223 (valid) turn restirictions, 25 invalid I wonder how that's possible because there are a lot of changes between v2 and v3 of the patch. I fixed some problems that removed some turn restrictions. Can you please check again? WanMil
Hi WanMil,
reg. turn restrictions I see no change in my test case, but I just compared the numbers.
Gerd
Date: Sat, 11 Jan 2014 22:25:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached is another patch that reverses roads in the RoadMerger if applicable.
I have checked the patch by adding debug statements to the RestrictionRelation.addRestriction(..) method. There are some differences but as far as I could see the differences are only in some coords. I have checked some and all were caused by road merges.
Example:
3---2--- \ 4--------1---5 When having a only_straightforward restriction from 4 via 1 to 5 point 2 is added to the restriction without merging. When merging the road 1-2 and 2-3 node 2 is no longer a routing node and therefor point 3 is added to the restriction instead of point 2.
@Gerd: can you please check again if your tests still show any problem? Thanks!
WanMil
Hi Gerd,
I've found two problems but have no time today to fix it. Will post a patch within the next days.
Thanks a lot for testing!!
WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, sorry, I meant that with the new patch everything looks good because the number of restrictions is the same as without the patch. Gerd
Date: Sun, 12 Jan 2014 22:15:04 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Hi Gerd,
what does that mean? Do you see the same following results: r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : 223 (valid) turn restirictions, 25 invalid
I wonder how that's possible because there are a lot of changes between v2 and v3 of the patch. I fixed some problems that removed some turn restrictions. Can you please check again?
WanMil
Hi WanMil,
reg. turn restrictions I see no change in my test case, but I just compared the numbers.
Gerd
Date: Sat, 11 Jan 2014 22:25:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached is another patch that reverses roads in the RoadMerger if applicable.
I have checked the patch by adding debug statements to the RestrictionRelation.addRestriction(..) method. There are some differences but as far as I could see the differences are only in some coords. I have checked some and all were caused by road merges.
Example:
3---2--- \ 4--------1---5 When having a only_straightforward restriction from 4 via 1 to 5 point 2 is added to the restriction without merging. When merging the road 1-2 and 2-3 node 2 is no longer a routing node and therefor point 3 is added to the restriction instead of point 2.
@Gerd: can you please check again if your tests still show any problem? Thanks!
WanMil
Hi Gerd,
I've found two problems but have no time today to fix it. Will post a patch within the next days.
Thanks a lot for testing!!
WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ok, that's great! Anyhow I think we should first get a consensus if road might be reversed and where that should happen. Which solution do you prefer? I think an additional tag might solve most problems? WanMil
Hi WanMil,
sorry, I meant that with the new patch everything looks good because the number of restrictions is the same as without the patch.
Gerd
Date: Sun, 12 Jan 2014 22:15:04 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Hi Gerd,
what does that mean? Do you see the same following results: r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : 223 (valid) turn restirictions, 25 invalid
I wonder how that's possible because there are a lot of changes between v2 and v3 of the patch. I fixed some problems that removed some turn restrictions. Can you please check again?
WanMil
Hi WanMil,
reg. turn restrictions I see no change in my test case, but I just compared the numbers.
Gerd
Date: Sat, 11 Jan 2014 22:25:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached is another patch that reverses roads in the RoadMerger if applicable.
I have checked the patch by adding debug statements to the RestrictionRelation.addRestriction(..) method. There are some differences but as far as I could see the differences are only in some coords. I have checked some and all were caused by road merges.
Example:
3---2--- \ 4--------1---5 When having a only_straightforward restriction from 4 via 1 to 5 point 2 is added to the restriction without merging. When merging the road 1-2 and 2-3 node 2 is no longer a routing node and therefor point 3 is added to the restriction instead of point 2.
@Gerd: can you please check again if your tests still show any problem? Thanks!
WanMil
Hi Gerd,
I've found two problems but have no time today to fix it. Will post a patch within the next days.
Thanks a lot for testing!!
WanMil
Hi Gerd,
I will check that.
WanMil
Hi WanMil,
the patch has an influence on the number of turn restrictions. For a tile in northern Germany GPSMapEdit shows : r2946 with --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with activated mergeroads : 264 (valid) turn restirictions, 22 invalid r2946 with patch and --x-no-mergeroads: 264 (valid) turn restirictions, 22 invalid r2946 with patch and activated mergeroads : *223* (valid) turn restirictions, *25 *invalid
(The invalid turn restrictions are listed in the log. Those are the ones that prohibit to drive into the wrong end of a oneway road, but GPSMapEdit doesn't care when the turn restriction also forbids to walk into the road)
Do you think that this could be okay?
Gerd
Date: Wed, 8 Jan 2014 22:55:43 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] [PATCH] RoadMerger reverses roads
Attached patch improves the RoadMerger so that roads are reversed when it is required to be merged with another road.
A small test increased the mergerate by 2% (avg. 17% => 19% road network reduction).
Please check it. The p-road check is not yet implemented. There are also some performance improvements possible which I will post with the next patch version. Unit tests may fail.
WanMil
> 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.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, WanMil wrote
Anyhow I think we should first get a consensus if road might be reversed and where that should happen. Which solution do you prefer? I think an additional tag might solve most problems?
yes, I think a tag is the best solution. I guess most users don't care, so the default could be mkgmap:reversible=yes, and style can set mkgmap:reversible=no to flag that the road has a direction although oneway=no Gerd -- View this message in context: http://gis.19327.n5.nabble.com/RoadMerger-tp5791849p5792931.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (7)
-
Andrzej Popowski -
Bernd Weigelt -
Gerd Petermann -
GerdP
-
Minko -
Steve Sgalowski -
WanMil