question regarding MapRoad
Hi Steve, I'd like to change the way how MapRoad objects are handled in the sub division split process. Current implementation is like this: 1) StyledConverter creates a MapRoad instance with max. 250 points, if a road has more points, multiple instances are created, each with its own RoadDef. 2) When the sub divisions are created, a MapRoad is never split, so the final result is that each instance is written to exactly one sub division. The Garmin format seems to imply that we should rather split the MapRoad to match a given bbox of a sub division. This will produce smaller img files because the offsets to the sub division centers are smaller, and if we allow to start with MapRoad instances having > 250 points, we also have fewer NOD entries. I tried to implement this, but I can't find a nice way to store the information about the order of the segments of a road. This is needed when finally the RoadDef.addPolylineRef() method is called. I think that we either have to make sure that each part of a road is processed in the correct order, or we have to restore the order after all the filters where used. (For the different levels, a road will be split into different parts, if a road goes out and in we can have multiple segments in one sub div, not directly connected to each other) I have no idea yet how to do this. Can you help? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
I'd like to change the way how MapRoad objects are handled in the sub division split process. Current implementation is like this: 1) StyledConverter creates a MapRoad instance with max. 250 points, if a road has more points, multiple instances are created, each with its own RoadDef.
Yes MapRoad should probably not be limited to 250 points since it is in .mkgmap.general and the limitations should be applied on the conversion to Polyline.
...
I have no idea yet how to do this. Can you help?
OK - not sure where to start and I think the first task is to understand how the data flows through the different classes. I will think about it over the weekend. ..Steve
Hi Steve,
Yes MapRoad should probably not be limited to 250 points since it is in .mkgmap.general and the limitations should be applied on the conversion to Polyline. yes, absolutely, and I already have it working.
OK - not sure where to start and I think the first task is to understand how the data flows through the different classes. I will think about it over the weekend.
I did a lot of research during the last days and created some patches based on it. My general approach for now: 1) StyledConverter (and RoadMerger) should try to create as few MapRoads as possible, so that indexes do not contain multiple entries. 2) With the end of StyledConverter.end() we know the number of a) MapRoad instances and b) CoordNode instances. With the current implementation that means: For a routable map we must make sure that this number is not changed in the following chain for level 0, means, no filter should remove a MapRoad instance (or replace it by a MapLine) or replace a CoordNode by a normal Coord instance. The current implementation contain errors like this, e.g. in LineSplitterFilter (fixed with r2765). I try to add sanity checks for this. 3) For all levels > 0 there is no need to bother about CoordNodes, and it is also okay to drop MapRoad instances in the filters. Current implementation of the filters doesn't completely ignore CoordNodes, so it is possible that overlaying lines are "moved". This should not happen. Conclusion: To remove obsolete checks in StyledConverter we have to make sure that all these errors are fixed and that all img write methods are working correct with the changed input. The latter is quite difficult. I'll create a branch to experiment with this. Gerd
Hi, I've created branch reduce_limits. This is for testing of patches that reduce img size and improve the creation of NOD and NET. Style processing is like in trunk. @Steve: Regarding MapRoad I still found no good solution. For now, I've added code to sort segments in RoadDef, but this is not fail safe. Trying to code sort of double linked list to solve it... Gerd GerdP wrote
Hi Steve,
Yes MapRoad should probably not be limited to 250 points since it is in .mkgmap.general and the limitations should be applied on the conversion to Polyline. yes, absolutely, and I already have it working.
OK - not sure where to start and I think the first task is to understand how the data flows through the different classes. I will think about it over the weekend.
I did a lot of research during the last days and created some patches based on it. My general approach for now: 1) StyledConverter (and RoadMerger) should try to create as few MapRoads as possible, so that indexes do not contain multiple entries.
2) With the end of StyledConverter.end() we know the number of a) MapRoad instances and b) CoordNode instances. With the current implementation that means: For a routable map we must make sure that this number is not changed in the following chain for level 0, means, no filter should remove a MapRoad instance (or replace it by a MapLine) or replace a CoordNode by a normal Coord instance. The current implementation contain errors like this, e.g. in LineSplitterFilter (fixed with r2765). I try to add sanity checks for this.
3) For all levels > 0 there is no need to bother about CoordNodes, and it is also okay to drop MapRoad instances in the filters. Current implementation of the filters doesn't completely ignore CoordNodes, so it is possible that overlaying lines are "moved". This should not happen.
Conclusion: To remove obsolete checks in StyledConverter we have to make sure that all these errors are fixed and that all img write methods are working correct with the changed input. The latter is quite difficult.
I'll create a branch to experiment with this.
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633p5782155.... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, finally I found a way to store the correct order of segments even if they were created during the sub div split process. The code for this is quite complex, so this is makes only sense if we can use it to implement a better split algo or when it really improves something. See r2778 in the branch. Gerd GerdP wrote
Hi,
I've created branch reduce_limits. This is for testing of patches that reduce img size and improve the creation of NOD and NET. Style processing is like in trunk.
@Steve: Regarding MapRoad I still found no good solution. For now, I've added code to sort segments in RoadDef, but this is not fail safe. Trying to code sort of double linked list to solve it...
Gerd GerdP wrote
Hi Steve,
Yes MapRoad should probably not be limited to 250 points since it is in .mkgmap.general and the limitations should be applied on the conversion to Polyline. yes, absolutely, and I already have it working.
OK - not sure where to start and I think the first task is to understand how the data flows through the different classes. I will think about it over the weekend.
I did a lot of research during the last days and created some patches based on it. My general approach for now: 1) StyledConverter (and RoadMerger) should try to create as few MapRoads as possible, so that indexes do not contain multiple entries.
2) With the end of StyledConverter.end() we know the number of a) MapRoad instances and b) CoordNode instances. With the current implementation that means: For a routable map we must make sure that this number is not changed in the following chain for level 0, means, no filter should remove a MapRoad instance (or replace it by a MapLine) or replace a CoordNode by a normal Coord instance. The current implementation contain errors like this, e.g. in LineSplitterFilter (fixed with r2765). I try to add sanity checks for this.
3) For all levels > 0 there is no need to bother about CoordNodes, and it is also okay to drop MapRoad instances in the filters. Current implementation of the filters doesn't completely ignore CoordNodes, so it is possible that overlaying lines are "moved". This should not happen.
Conclusion: To remove obsolete checks in StyledConverter we have to make sure that all these errors are fixed and that all img write methods are working correct with the changed input. The latter is quite difficult.
I'll create a branch to experiment with this.
Gerd
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633p5782333.... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
finally I found a way to store the correct order of segments even if they were created during the sub div split process. The code for this is quite complex, so this is makes only sense if we can use it to implement a better split algo or when it really improves something.
Sounds good. I'm not sure what to suggest here. What we have works, although it may be sub-optimal in some way. I never had a theory on how sub-divisions should be used and I was kind of suprised that the first thing I tried seemed to work (this was before routing). It would probably be better to create a grid of subdivisions and cut the roads at nodes near the boundary so that there is a lot less overlapping. I've no idea how much, if any, difference it would make though, and it would entail a fairly substantial re-write. ..Steve
Hi Steve,
It would probably be better to create a grid of subdivisions and cut the roads at nodes near the boundary so that there is a lot less overlapping. I've no idea how much, if any, difference it would make though, and it would entail a fairly substantial re-write.
I think the existing split algo works fine, the only open question for me is whether it could be better to clip lines or shapes under certain circumstances. I'll use the branch to play with this. I am also playing with a ShapeMerge algo similar to merge-lines. What I have reduces img size nicely is far too slow for now . Gerd
Hi Steve,
Sounds good. I'm not sure what to suggest here. What we have works, although it may be sub-optimal in some way. I never had a theory on how sub-divisions should be used and I was kind of suprised that the first thing I tried seemed to work (this was before routing).
If I got that right, the device has to read all RGN data for all sub divs which intersect the selected part of the map when it has to render the picture that should be displayed. So, a subdiv that contains many objects located somewhere in the middle and one large object that makes it much bigger in size might be something that should be avoided, as it creates a large subdiv area, overlapping many other, without containing much info that is useful. I have no idea what kind of caching the device uses. Maybe it is useful to detect large objects and place them in their own sub divisions? With large I mean big dimension. Another question is whether we shoud try to put as many objects as possible into one subdiv. I could imagine that the device is happier if it finds more, but smaller subdivs. I think it is worth trying. Another interesting point: Empty subdivs. I don't see many of them in my Garmin map, but mkgmap creates quite a lot. An empty subdiv is created when we split a subdiv into two equal halves, and all data is in one half. It is quite simple to change the current algo to split again at a different position so that both parts contain more or less the same amount of data. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd
Another question is whether we shoud try to put as many objects as possible into one subdiv. I could imagine that the device is happier if it finds more, but smaller subdivs. I think it is worth trying.
Yes all those things sound reasonable and worth trying. Would be useful to have a tool that can show or confirm how the subdivisions and objects are lining up. Do you know of the ImgViewer program: http://garmin-img.cvs.sourceforge.net/viewvc/garmin-img/ImgViewer/ It shows subdiv boundaries.
Another interesting point: Empty subdivs. I don't see many of them in my Garmin map, but mkgmap creates quite a lot. An empty subdiv is created when we split a subdiv into two equal halves, and all data is in one half. It is quite simple to change the current algo to split again at a different position so that both parts contain more or less the same amount of data.
Yes I believe that empty subdivs can be removed at least for the highest resolution. They are chained between levels, so you can probably remove any empty subdivision that does not have any non-empty child subdivisions too. This makes a big difference if you have a large mostly empty map such as over an ocean. ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
It would probably be better to create a grid of subdivisions and cut the roads at nodes near the boundary so that there is a lot less overlapping. I've no idea how much, if any, difference it would make though, and it would entail a fairly substantial re-write.
Do you still consider this idea? Cgpsmapper supports parameter "TRESIZE". I assume that this parameter define size of subdivision in TRE. It could be equivalent to definition in file MapSplitter.java: public static final int MAX_DIVISION_SIZE = 0x7fff; Using "TRESIZE" in cgpsmapper directly influence 2 feature of resulting img: file size and processing speed in device. And there are real gains in map redraw speed when using small values for TRESIZE. I usually set it for 511. I have experimenting a bit with MAX_DIVISION_SIZE in mkgmap. I have observed increase in file size, when using small value, but no increase in processing speed. I think this discussion gives some explanations. As I understand, mkgmap doesn't split map objects to fit subdivisions. So there is no gain from using smaller subdivisions, because there is no reduction in processed objects size. I would expect that proper truncating objects to subdivisions could be another big improvement for mkgmap. Please, don't abandon this idea. -- Best regards, Andrzej
Hi Andrzej,
Do you still consider this idea?
I have experimenting a bit with MAX_DIVISION_SIZE in mkgmap. I have observed increase in file size, when using small value, but no increase in processing speed. I think this discussion gives some explanations. As I understand, mkgmap doesn't split map objects to fit subdivisions. So there is no gain from using smaller subdivisions, because there is no reduction in processed objects size.
Tried the same with the same result some time ago.
I would expect that proper truncating objects to subdivisions could be another big improvement for mkgmap. Please, don't abandon this idea.
I agree, but it requires a redesign of the MapSplit algo, which is complex. I don't want to start complex changes before autumn, but if anybody else wants to start, that would be great. Gerd
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
GerdP
-
Steve Ratcliffe