Hi Johann, Been trying your patch and it works well. Certainly doesn't seem to break the routing. However, it doesn't always merge ways that, as far as I can tell, should be merged. I have studied your code so I know how you're doing the matching. One thought, would rounding the coords before merging help? If it isn't that, something else must be not quite right. Cheers, Mark
Hello again,
Been trying your patch and it works well. Certainly doesn't seem to break the routing. However, it doesn't always merge ways that, as far as I can tell, should be merged. I have studied your code so I know how you're doing the matching. One thought, would rounding the coords before merging help? If it isn't that, something else must be not quite right.
I'm being so stupid today, it's the subdivisions. The lines that are not matching are in different subdivision so they don't get compared. That's a shame but the upside of only merging within a subdivision is that it's really quick. Mark
I'm being so stupid today, it's the subdivisions. The lines that are not matching are in different subdivision so they don't get compared.
Thanks for the hint, this was it. I have noted that the lines are not merged at subdivisions, but not thought to the final end. I think its time to stop programming for today :-/
That's a shame but the upside of only merging within a subdivision is that it's really quick.
Would it be possible to merge lines across more subdivisions or is this a natural limit? Also there seems to be some inaccuracys at rounding, as the line ends do not meet exactly. (Or is this a displaying problem of the QLandkarte?)
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev .
Johann,
I'm being so stupid today, it's the subdivisions. The lines that are not matching are in different subdivision so they don't get compared.
Thanks for the hint, this was it. I have noted that the lines are not merged at subdivisions, but not thought to the final end. I think its time to stop programming for today :-/
That's a shame but the upside of only merging within a subdivision is that it's really quick.
Would it be possible to merge lines across more subdivisions or is this a natural limit?
I can't be 100% sure without some study but I think it should be possible to merge across a whole tile. Somewhere like makeMapAreas() is about right because there it's looping through the resolutions and driving the subdivision creation. I think the merging needs to happen around there before the subdivisions are created. What would be very nice is to keep your existing merging within subdivision as the default behaviour and then have a merge within tile option for those with CPU to burn. Something like: --merge-lines merge in subdiv --merge-lines=1 ditto --merge-lines=2 merge in tile
Also there seems to be some inaccuracys at rounding, as the line ends do not meet exactly. (Or is this a displaying problem of the QLandkarte?)
Using gpsmapedit the lines join pretty well (a lot better now that the coords are rounded!) Cheers, Mark
That's a shame but the upside of only merging within a subdivision is that it's really quick.
Would it be possible to merge lines across more subdivisions or is this a natural limit?
I can't be 100% sure without some study but I think it should be possible to merge across a whole tile. Somewhere like makeMapAreas() is about right because there it's looping through the resolutions and driving the subdivision creation. I think the merging needs to happen around there before the subdivisions are created.
What would be very nice is to keep your existing merging within subdivision as the default behaviour and then have a merge within tile option for those with CPU to burn. Something like:
--merge-lines merge in subdiv --merge-lines=1 ditto --merge-lines=2 merge in tile
The merge lines patch is designed from start for high line numbers. It uses internal hashlists for performance reasons. I would expect the runtime to raise n*log(n), not n². So I do not expect it to burn cpu, but would need a test to proove it. But I'm not sure, if merging across tiles would improve the whole thing. As far as I understand, a line could not go across multiple subdivisions. So it has to be splitted anyway at its bounds. I expect no usefull effects from merging before. What I really would like, is to apply the merge filter before any creating of routing data. This would be the most reasonable place with the most effect, even to routing quality. But one step after the other.... And I'm sorry, I could not spend that much time to the mkgamp project. Regards, Johann
Johann,
The merge lines patch is designed from start for high line numbers. It uses internal hashlists for performance reasons. I would expect the runtime to raise n*log(n), not n². So I do not expect it to burn cpu, but would need a test to proove it.
OK.
But I'm not sure, if merging across tiles would improve the whole thing. As far as I understand, a line could not go across multiple subdivisions. So it has to be splitted anyway at its bounds. I expect no usefull effects from merging before.
That's a good point, so it's probably not worth the effort to merge lines across subdivs.
What I really would like, is to apply the merge filter before any creating of routing data. This would be the most reasonable place with the most effect, even to routing quality.
That's true but it's non-trivial (as you know).
But one step after the other.... And I'm sorry, I could not spend that much time to the mkgamp project.
No problem. Are you happy with the current state of the merge patch? If so, I can commit it to trunk. Cheers, Mark
Are you happy with the current state of the merge patch? If so, I can commit it to trunk.
Yes, the current state seems cause no problems. The comments from the testers are not discouraging. From my side you can commit it. Maybe somtimes in the future mkgmap will be refactored and then the line merging gets shifted to an earlier stage, but at the moment it has reached a stable point. Even if it works not as expected, it could be disabled with changing a single line. Regards, Johann
Hi Johann,
Been trying your patch and it works well. Certainly doesn't seem to break the routing. However, it doesn't always merge ways that, as far as I can tell, should be merged. I have studied your code so I know how you're doing the matching. One thought, would rounding the coords before merging help? If it isn't that, something else must be not quite right.
Yes, I have been trying for myself the last hour and detected too, that some lines should be connected, but aren't. I had not found out the error for now. But I've seen line endings not matching exactly. Don't now if it had to do something with the rounding. I don't think, that rounding before merging will help, but will have a look at it. I need to prepare some test cases. Regards, Johann
participants (2)
-
Johann Gail -
Mark Burton