Commit: r2707: Don't complete remove an unconnected road.
Version 2707 was committed by steve on Mon, 16 Sep 2013 Don't complete remove an unconnected road. If mkgmap:set_unconnected_type=none and the road is unconnected then the road was completely removed and was not available for any rule matching after a continue. Now it is not added to the removed list, so that it can still be used as a line.
Hi, this mail was blocked by the list: sorry for being late on this, I just returned from a three week tour trough France and was offline all the time. I think the original code worked as designed, please see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017976.html Maybe the problem should be solved somewhere else? Gerd svn commit wrote
Version 2707 was committed by steve on Mon, 16 Sep 2013
Don't complete remove an unconnected road.
If mkgmap:set_unconnected_type=none and the road is unconnected then the road was completely removed and was not available for any rule matching after a continue.
Now it is not added to the removed list, so that it can still be used as a line. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 22/09/13 07:57, GerdP wrote:
I think the original code worked as designed, please see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017976.html
OK I can see that in the case you were responding to that makes sense. It all depends on whether continue is being used to create an overlay which is to be considered a part of the underlying road, or a separate line. In the first case it makes sense to remove the line too, and in the second it doesn't. Since Felix filed both bugs, I think he should take a look at both cases and think about which behaviour he would like to see ;) ..Steve
I cannot understand the difference of the patch.... In any case, I consider if "continue" is used, and remove unconnected road, then only the unconnected road should not be put into the map - afterwards the object should be treated as if it hadn't been "touched" yet. Future roads shouldn't be removed, as maybe there is an use object xx if unconnected for future roads. In effect I believe if remove unconnected =yes is given plus continue, it is like setting the whole line/command "#". On 22.09.2013 18:08, Steve Ratcliffe wrote:
On 22/09/13 07:57, GerdP wrote:
I think the original code worked as designed, please see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017976.html OK I can see that in the case you were responding to that makes sense.
It all depends on whether continue is being used to create an overlay which is to be considered a part of the underlying road, or a separate line. In the first case it makes sense to remove the line too, and in the second it doesn't.
Since Felix filed both bugs, I think he should take a look at both cases and think about which behaviour he would like to see ;)
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, ok, my understanding of the "mkgmap:set_unconnected_type=none" feature was that it allows to remove unconnected roads, while "mkgmap:set_unconnected_type=0x?" could be used to mark a road as unconnected. The way it is used in r2707 means the road is not added to the road network, but overlays might still show up in the map. I don't mind to keep this solution. Gerd
Date: Mon, 23 Sep 2013 03:55:13 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Commit: r2707: Don't complete remove an unconnected road.
I cannot understand the difference of the patch....
In any case, I consider if "continue" is used, and remove unconnected road, then only the unconnected road should not be put into the map - afterwards the object should be treated as if it hadn't been "touched" yet.
Future roads shouldn't be removed, as maybe there is an use object xx if unconnected for future roads. In effect I believe if remove unconnected =yes is given plus continue, it is like setting the whole line/command "#". On 22.09.2013 18:08, Steve Ratcliffe wrote:
On 22/09/13 07:57, GerdP wrote:
I think the original code worked as designed, please see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017976.html OK I can see that in the case you were responding to that makes sense.
It all depends on whether continue is being used to create an overlay which is to be considered a part of the underlying road, or a separate line. In the first case it makes sense to remove the line too, and in the second it doesn't.
Since Felix filed both bugs, I think he should take a look at both cases and think about which behaviour he would like to see ;)
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 23/09/13 02:55, Felix Hartmann wrote:
I cannot understand the difference of the patch....
As I understand it the issue that Gerd pointed out was: when continue is used to overlay little arrows on top of a road to indicate it is one-way or something similar. In that case, if the road is unconnected you would want the arrows to be removed too, since they are really part of the road, and have no meaning without the road. ..Steve
okay, well I never thought about that case. It could be useful - however in that case I would rather have another command like remove all if unconnected and not 0x. 0x could be misread for 0x00... On 23.09.2013 12:35, Steve Ratcliffe wrote:
On 23/09/13 02:55, Felix Hartmann wrote:
I cannot understand the difference of the patch....
As I understand it the issue that Gerd pointed out was: when continue is used to overlay little arrows on top of a road to indicate it is one-way or something similar.
In that case, if the road is unconnected you would want the arrows to be removed too, since they are really part of the road, and have no meaning without the road.
..Steve
Hi, Felix Hartmann-2 wrote
okay, well I never thought about that case. It could be useful - however in that case I would rather have another command like remove all if unconnected and not 0x. 0x could be misread for 0x00...
Sorry, I probably was not clear about that 0x stuff. mkgmap:set_unconnected_type=0x? meant mkgmap:set_unconnected_type=<type> So, if I got this right we need three different results regarding unconnected roads: 1) ignore the way added by the rule containing the mkgmap:set_unconnected_type=none action (that is what r2707 implements with "none") 2) ignore the OSM way including all overlays etc. (that was the behaviour before r2707 with "none") 3) change the road to a non-routable line by giving it a different non-routable type I would prefer to change "none" back to the old behaviour and add a new option,e.g. "ignore_this" that implements 1) What do you think? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 24.09.2013 08:34, GerdP wrote:
Hi,
Felix Hartmann-2 wrote
okay, well I never thought about that case. It could be useful - however in that case I would rather have another command like remove all if unconnected and not 0x. 0x could be misread for 0x00... Sorry, I probably was not clear about that 0x stuff. mkgmap:set_unconnected_type=0x? meant mkgmap:set_unconnected_type=<type>
So, if I got this right we need three different results regarding unconnected roads: 1) ignore the way added by the rule containing the mkgmap:set_unconnected_type=none action (that is what r2707 implements with "none") 2) ignore the OSM way including all overlays etc. (that was the behaviour before r2707 with "none") 3) change the road to a non-routable line by giving it a different non-routable type yes - if people need 2) then yes. Because it would IMHO be much better to simply add again an set_unconnected_type=none for the overlays too. However 1) cannot be achieved on the branch before 2707.
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case!
I would prefer to change "none" back to the old behaviour and add a new option,e.g. "ignore_this" that implements 1)
I don't mind what is called what - as long as 1) exists....
What do you think?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case!
hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it. Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Felix, please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2). Gerd GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
oops, sorry, it's vice versa. branch is now 1) and used to be 2) Gerd GerdP wrote
Hi Felix,
please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2).
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, hi Felix, I haven't following the whole thread. But: The branch should work the same like the trunk. If there are any differences please let me know. WanMil
oops, sorry, it's vice versa. branch is now 1) and used to be 2)
Gerd
GerdP wrote
Hi Felix,
please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2).
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
Hi WanMil, it probably does, and I think that both are wrong now, but I like to hear Felix first, as he seems to be the only one in the list who uses this feature. In short: Felix reported an error caused by one of the mergeroads patches without explicitely mentioning the use of the patch. Steve posted a fix which was just a work-around, Felix reported that the fix is ok and Steve committed it to trunk. In the meantime you created the branch and Felix seemed to use only that. In my eyes the trunk version was broken since r2707, but I got no other feedback. Gerd WanMil wrote
Hi Gerd, hi Felix,
I haven't following the whole thread. But: The branch should work the same like the trunk. If there are any differences please let me know.
WanMil
oops, sorry, it's vice versa. branch is now 1) and used to be 2)
Gerd
GerdP wrote
Hi Felix,
please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2).
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Ok, lots of interleaving actions.... Feel free to change the parts in the branch as you like! I've just ported the patch or merged changes from the trunk without having a deeper look into the changes. WanMil
Hi WanMil,
it probably does, and I think that both are wrong now, but I like to hear Felix first, as he seems to be the only one in the list who uses this feature.
In short: Felix reported an error caused by one of the mergeroads patches without explicitely mentioning the use of the patch. Steve posted a fix which was just a work-around, Felix reported that the fix is ok and Steve committed it to trunk. In the meantime you created the branch and Felix seemed to use only that. In my eyes the trunk version was broken since r2707, but I got no other feedback.
Gerd
WanMil wrote
Hi Gerd, hi Felix,
I haven't following the whole thread. But: The branch should work the same like the trunk. If there are any differences please let me know.
WanMil
oops, sorry, it's vice versa. branch is now 1) and used to be 2)
Gerd
GerdP wrote
Hi Felix,
please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2).
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I was using the merge-roads with Steve's patch. My internet currently is so slow, I need about 5 hours to download 500MB - so actually it might be broken again, I cannot really check. Maybe I was wrong about that the bug first appeared in the merge-roads branch. I just know 4-5 month ago it wasn't there... So maybe it was rather recently introduced on trunk and then carried forward to everything building on it.. On trunk at least (at the time Steve posted the patch) - the patch solved the problem/bug! On 04.10.2013 12:18, GerdP wrote:
Hi WanMil,
it probably does, and I think that both are wrong now, but I like to hear Felix first, as he seems to be the only one in the list who uses this feature.
In short: Felix reported an error caused by one of the mergeroads patches without explicitely mentioning the use of the patch. Steve posted a fix which was just a work-around, Felix reported that the fix is ok and Steve committed it to trunk. In the meantime you created the branch and Felix seemed to use only that. In my eyes the trunk version was broken since r2707, but I got no other feedback.
Gerd
WanMil wrote
Hi Gerd, hi Felix,
I haven't following the whole thread. But: The branch should work the same like the trunk. If there are any differences please let me know.
WanMil
oops, sorry, it's vice versa. branch is now 1) and used to be 2)
Gerd
GerdP wrote
Hi Felix,
please note that WanMil merged trunk into mergeroads branch. If I got it right, you should now see overlaying lines where the road was deleted because of the mkgmap:set_unconnected_type=none feature. So, the branch used to be 1) and is now 2).
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Note that the "old" behaviour has always been 1). It only changed with the merge-roads patches/branch. At least for revision <2650 this was for sure the case! hmm, you never mentioned that you use the patch :-( If you find an error in a patch or branch, please make sure to mention it.
Now we have a "fixed" trunk version and a branch version that doesn't contain the fix posted by Steve. What do you use?
Gerd
mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n5.nabble.com/Commit-r2707-Don-t-complete-remove-an-unconne... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
svn commit -
WanMil