Hi , attached is a patch that reduces the img size. Up to now, mkgmap created many so called CoordNodes when a road and e.g. a building shared an OSM node. This is not needed and was not intended. As far as I know it just blows up the size of the img file (typically ~500kb for each tile). The patch reduces the amount of CoordNodes and also cleans some dead code around the highwayCount. Please test if you see any (new) routing problems with this patch, I tried quite a while and found none in BaseCamp. highwayCount_v1.patch <http://gis.19327.n5.nabble.com/file/n5748554/highwayCount_v1.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Smaller? For me my austria map size increased from 295MB to 345MB... Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... On 07.02.2013 22:25, GerdP wrote:
Hi ,
attached is a patch that reduces the img size. Up to now, mkgmap created many so called CoordNodes when a road and e.g. a building shared an OSM node. This is not needed and was not intended. As far as I know it just blows up the size of the img file (typically ~500kb for each tile).
The patch reduces the amount of CoordNodes and also cleans some dead code around the highwayCount.
Please test if you see any (new) routing problems with this patch, I tried quite a while and found none in BaseCamp.
highwayCount_v1.patch <http://gis.19327.n5.nabble.com/file/n5748554/highwayCount_v1.patch>
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554.html 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix, Felix Hartmann-2 wrote
Smaller?
For me my austria map size increased from 295MB to 345MB...
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though...
thanks for testing. I can reproduce the problems with austria.osm.pbf reg. img size: I see small decrease in img size when I use the default style, but with the (old) velomap style the img files are in fact bigger. I'll try to find out why. reg. routing: I tested only distances < 100km. I see problems when trying to route over more than 100 km with the patched version. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748574.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Felix, Felix Hartmann-2 wrote
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though...
please check: Are you still using this option? --x-reduce-point-density-polygon=6 1) It seems to be the reason for the broken routing (also in the trunk version) 2) althrough not documented, it is interpreted as --reduce-point-density-polygon=6 The help file for this option says that the recommended value is 8, but if the value is not specified, it uses the value from reduce-point-density. If both are not specified, the default for both is 2.6 I assume that you use the higher values because you see the severe "Area to small to split at ..." messages. Please ignore them as long as you don't see empty img files or try the MapArea_v1.patch http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at... @Steve: I have no good idea why this option breaks routing over long distances. It just changes the way how DouglasPeucker works for shapes. The higher the value, the more points of shapes are removed. Maybe fewer shapes are written, maybe more sub divisions are empty. Any hints? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748585.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
oops, seems I was trapped by some caching in BaseCamp. --x-reduce-point-density-polygon=6 doesn't break routing. Gerd GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... please check: Are you still using this option? --x-reduce-point-density-polygon=6
1) It seems to be the reason for the broken routing (also in the trunk version) 2) althrough not documented, it is interpreted as --reduce-point-density-polygon=6 The help file for this option says that the recommended value is 8, but if the value is not specified, it uses the value from reduce-point-density. If both are not specified, the default for both is 2.6
I assume that you use the higher values because you see the severe "Area to small to split at ..." messages. Please ignore them as long as you don't see empty img files or try the MapArea_v1.patch http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at...
@Steve: I have no good idea why this option breaks routing over long distances. It just changes the way how DouglasPeucker works for shapes. The higher the value, the more points of shapes are removed. Maybe fewer shapes are written, maybe more sub divisions are empty. Any hints?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748593.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
yes I'm still using that one. I think I can drop the --x , which I used because sometimes it was broken on the commandline check, but working below the hood. Never noticed any routing problems due to it. I probably don't have any time over the next 3 days though... Area to small to split, is not my aim. My aim is to make the map faster to draw on GPS. 6 is the highest value that leads to very small visible changes, therefore I use it over the default. On 08.02.2013 10:48, GerdP wrote:
oops, seems I was trapped by some caching in BaseCamp.
--x-reduce-point-density-polygon=6 doesn't break routing.
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... please check: Are you still using this option? --x-reduce-point-density-polygon=6
1) It seems to be the reason for the broken routing (also in the trunk version) 2) althrough not documented, it is interpreted as --reduce-point-density-polygon=6 The help file for this option says that the recommended value is 8, but if the value is not specified, it uses the value from reduce-point-density. If both are not specified, the default for both is 2.6
I assume that you use the higher values because you see the severe "Area to small to split at ..." messages. Please ignore them as long as you don't see empty img files or try the MapArea_v1.patch http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at...
@Steve: I have no good idea why this option breaks routing over long distances. It just changes the way how DouglasPeucker works for shapes. The higher the value, the more points of shapes are removed. Maybe fewer shapes are written, maybe more sub divisions are empty. Any hints?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748593.html 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi, I did not yet find the reason for the routing problem, but I can reproduce it with the patched version with a few steps now: 1) download austria.osm.pbf from geofabrik 2) split with java -Xmx2000m -jar splitter.jar --output-dir=e:\austria --max-nodes=1200000 austria.osm.pbf 3) execute mkgmap routing works: java -Xmx7000m -jar d:\mkgmap\dist\mkgmap.jar --route --nsis --max-jobs --preserve-element-order e:\austria\6324* routing is broken over long distances: java -Xmx7000m -jar d:\mkgmap\dist\mkgmap.jar --transparent --route --nsis --max-jobs --preserve-element-order e:\austria\6324* So, routing somehow depends on the background shape that is either written or not depending on the --transparent option. @Steve: Can the display tool help me to find out what's going wrong? Gerd Felix Hartmann-2 wrote
yes I'm still using that one. I think I can drop the --x , which I used because sometimes it was broken on the commandline check, but working below the hood. Never noticed any routing problems due to it. I probably don't have any time over the next 3 days though...
Area to small to split, is not my aim. My aim is to make the map faster to draw on GPS. 6 is the highest value that leads to very small visible changes, therefore I use it over the default. On 08.02.2013 10:48, GerdP wrote:
oops, seems I was trapped by some caching in BaseCamp.
--x-reduce-point-density-polygon=6 doesn't break routing.
Gerd
GerdP wrote
Hi Felix, Felix Hartmann-2 wrote
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... please check: Are you still using this option? --x-reduce-point-density-polygon=6
1) It seems to be the reason for the broken routing (also in the trunk version) 2) althrough not documented, it is interpreted as --reduce-point-density-polygon=6 The help file for this option says that the recommended value is 8, but if the value is not specified, it uses the value from reduce-point-density. If both are not specified, the default for both is 2.6
I assume that you use the higher values because you see the severe "Area to small to split at ..." messages. Please ignore them as long as you don't see empty img files or try the MapArea_v1.patch http://gis.19327.n5.nabble.com/Why-do-we-have-the-Area-too-small-to-split-at...
@Steve: I have no good idea why this option breaks routing over long distances. It just changes the way how DouglasPeucker works for shapes. The higher the value, the more points of shapes are removed. Maybe fewer shapes are written, maybe more sub divisions are empty. Any hints?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748593.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748624.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 08/02/13 17:26, GerdP wrote:
@Steve: Can the display tool help me to find out what's going wrong?
I'm working on something that might help. Thanks for the build instructions of a problem case. Oh, when I looked at the patch, I couldn't see where the boundary nodes were made into CoordNode's ? ..Steve
Steve Ratcliffe wrote
@Steve: Can the display tool help me to find out what's going wrong?
I'm working on something that might help.
Thanks for the build instructions of a problem case.
Oh, when I looked at the patch, I couldn't see where the boundary nodes were made into CoordNode's ?
Well, maybe this is a reason for the problems. I think all ways that are split into parts will run through this code in StyledConverter: way.getPoints().get(0).incHighwayCount(); way.getPoints().get(way.getPoints().size() - 1).incHighwayCount(); Maybe I overlooked a special case? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748627.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 08/02/13 17:40, GerdP wrote:
into parts will run through this code in StyledConverter: way.getPoints().get(0).incHighwayCount(); way.getPoints().get(way.getPoints().size() - 1).incHighwayCount(); Maybe I overlooked a special case?
Well certainly when a line is split each new end must become a node. ..Steve
Hi Steve,
into parts will run through this code in StyledConverter: way.getPoints().get(0).incHighwayCount(); way.getPoints().get(way.getPoints().size() - 1).incHighwayCount(); Maybe I overlooked a special case?
Well certainly when a line is split each new end must become a node.
Yes, I think that happens. I think the reason why routing is broken is probably not the patch itself. I guess that the patch just makes it more likely we hit an (old) error. I played a little bit with the display tool, esp. test.display.NetDisplay I see changes in the "Number of records" for eg. 63240003.img both in the trunk version and in the patched version. The img with --transparent has 5882 records, the other 5875 I think this should not be the case, or do you see a reason why --transparent should have an influence on the NET data ? Gerd
Hi Steve, maybe I found something which explains why long distance routing is broken. I tried to find out what changes I see depending on the --transparent option. I found differences for roads which are divided into multiple parts . The polyline parts "arrive" in different order in the RoadDef.addPolylineRef method. The comment in RoadDef.addPolylineRef says: * References to these are written to NET. At a given zoom * level, we're writing these in the order we get them, * which possibly needs to be the order the segments have * in the road. So, I guess we don't want the parts to arrive in different orders? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748746.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
I found differences for roads which are divided into multiple parts . The polyline parts "arrive" in different order in the RoadDef.addPolylineRef method.
Sounds plausible. That is probably something that I can add to NetCheck, then we can see if it is required in working maps. ..Steve
Hi Gerd
I found differences for roads which are divided into multiple parts . The polyline parts "arrive" in different order in the RoadDef.addPolylineRef method.
OK so I wrote code to check this. However... 1. In a complete map of the UK I did not see a single example of there being more than one line in the same RoadDef (at the same level). 2. Lines joining within the same RoadDef is not strictly required as there are many unconnected lines in non-mkgmap maps. I do see the breakage with --transparent in a UK map, so it looks as if there is another reason for it. ..Steve
Hi Steve, Steve Ratcliffe wrote
Hi Gerd
I found differences for roads which are divided into multiple parts . The polyline parts "arrive" in different order in the RoadDef.addPolylineRef method.
OK so I wrote code to check this. However...
1. In a complete map of the UK I did not see a single example of there being more than one line in the same RoadDef (at the same level).
2. Lines joining within the same RoadDef is not strictly required as there are many unconnected lines in non-mkgmap maps.
I do see the breakage with --transparent in a UK map, so it looks as if there is another reason for it.
thanks, I will try. I saw these effects in the austria map. The effect of the --transparent option is only a change in the number of shapes. This means also a change in the number of sub divisions and how different parts of a road are distributed to these sub divisions. So, --transparent doesn't directly cause a problem. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748810.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Steve, the test doesn't show any difference, so I think it will not detect the problem that I see. I try to describe it more detailed: - I've added a call to GpxCreator.createGpx for each line that is part of a road - I've made sure that all gpx files were written with unique names so that I don't overwrite something. Here's the patch I've used: order.patch <http://gis.19327.n5.nabble.com/file/n5748813/order.patch> I've executed the modifed version once with --transparent, renamed the gpx dir , again without Then I've compared the resulting gpx files and found a few ones that had different contents. These showed that the order of the line segments changed. The reason is that we first divide the roads into segements, then distribute the segments to different sub divisions and finally process the subdivisions without looking at the order of the line segments. So, if this matters, the result of the test should show whether or not the segments of a road are saved in order or not. Attached is also a zip archive showing the different results for a special way. gpx.zip <http://gis.19327.n5.nabble.com/file/n5748813/gpx.zip> Gerd GerdP wrote
Hi Steve, Steve Ratcliffe wrote
Hi Gerd
I found differences for roads which are divided into multiple parts . The polyline parts "arrive" in different order in the RoadDef.addPolylineRef method.
OK so I wrote code to check this. However...
1. In a complete map of the UK I did not see a single example of there being more than one line in the same RoadDef (at the same level).
2. Lines joining within the same RoadDef is not strictly required as there are many unconnected lines in non-mkgmap maps.
I do see the breakage with --transparent in a UK map, so it looks as if there is another reason for it. thanks, I will try. I saw these effects in the austria map. The effect of the --transparent option is only a change in the number of shapes. This means also a change in the number of sub divisions and how different parts of a road are distributed to these sub divisions. So, --transparent doesn't directly cause a problem.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748813.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I see files where every road has a different subdivision and line number, but that need not matter as long as everything matches up. I have found a way in which a file compiled with transparent is definately broken though. I have a file where the all entries in NET 1 are exactly the same (apart from the subdiv/line numbers) - they have the same offsets in the file etc. However NET 3, which is basically a list of pointers into NET 1, is not the same and there are entries that do not point to the beginning of a NET 1 entry. It may not be the only problem, but I will see if I can find out why it happens tomorrow. ..Steve
Hi Steve, I don't understand all of your comments, but I think that either I missunderstand the code in RoadDef or something is wrong. The comment in RoadDef says * A road definition. This ties together all segments of a single road * and provides street address information. but the current implementation works different. In StyledConverter, we create one MapRoad instance for each segment of an OSM way. MapRoad itself creates one instance of RoadDef for this single segment. The RoadDef class contains code to handle multiple segments at the same zoom level. So, if my assumption is right that the order of segments does matter, we should probably make sure that the entries in NET1 appear in the right order, or we should not create multiple RoadDef instances for a single OSM way. Gerd Steve Ratcliffe wrote
Hi Gerd,
I see files where every road has a different subdivision and line number, but that need not matter as long as everything matches up.
I have found a way in which a file compiled with transparent is definately broken though. I have a file where the all entries in NET 1 are exactly the same (apart from the subdiv/line numbers) - they have the same offsets in the file etc.
However NET 3, which is basically a list of pointers into NET 1, is not the same and there are entries that do not point to the beginning of a NET 1 entry.
It may not be the only problem, but I will see if I can find out why it happens tomorrow.
..Steve _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748864.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd
I don't understand all of your comments, but I think that either I
Yes, sorry, everything you were saying was fine, and I am confusing the issues by talking about other things. I will try to keep messages separate.
missunderstand the code in RoadDef or something is wrong.
Yes, something is wrong. Or more accurately: something is different to the way Garmin makes its maps, but it (mostly?) works.
The comment in RoadDef says * A road definition. This ties together all segments of a single road * and provides street address information.
Yes, I still believe that this is how it is meant to work.
but the current implementation works different.
Correct.
In StyledConverter, we create one MapRoad instance for each segment of an OSM way. MapRoad itself creates one instance of RoadDef for this single segment. The RoadDef class contains code to handle multiple segments at the same zoom level.
Yes. But I think the only time that we get multiple segments is when a line is split because it is too big for a subdivision.
So, if my assumption is right that the order of segments does matter, we should probably make sure that the entries in NET1 appear in the right order,
- I don't think that the order of the entries in NET1 matters. - The order of lines within a single NET1 entry may matter (but I don't know for sure).
or we should not create multiple RoadDef instances for a single OSM way.
We should probably join lines (like --merge-lines) and then prevent subdivisions from growing too much. The problem is that we grow subdivisions to fit lines so that there is a lot of overlap. The alternative is to limit subdivisions so that they only overlap a little and trim lines at their borders. It is similar to the same problem with splitter. Its hard to explain without a diagram, and I would like a tool that shows the layout of the subdivisions so that I can compare the strategy that we use compared to other maps. ..Steve
Hi Steve, Steve Ratcliffe wrote
We should probably join lines (like --merge-lines) and then prevent subdivisions from growing too much. The problem is that we grow subdivisions to fit lines so that there is a lot of overlap. The alternative is to limit subdivisions so that they only overlap a little and trim lines at their borders. It is similar to the same problem with splitter. Its hard to explain without a diagram, and I would like a tool that shows the layout of the subdivisions so that I can compare the strategy that we use compared to other maps.
I've just coded a small routine to draw a bbox gpx for each sub div. There seems to be one big difference: The sub divisions in the garmin map (extracted from gmapbmap.img) do not overlap, they are not even close together. Don't know it that is telling much, I think the img file contains only "Worldwide autoroute", no small streets. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748948.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Felix, I think I've found the reason for the problems (increased img size) Your style file probably contains many continue statements. This leads to the following situation: the same OSM way is added multiple times to the road network. For each node of a road, the highway count is increased. For a road that appears twice or more often, that means that all nodes will become routing nodes, not only those nodes that are also used in other streets. In the trunk version, this doesn't happen because each way is only counted once (but also ways that will not be added as roads) It is easy to fix that problem, but I still have no idea why routing breaks with the patch (in the default style we don't add roads multiple times) Attached is the corrected patch. highwayCount_v2.patch <http://gis.19327.n5.nabble.com/file/n5749522/highwayCount_v2.patch> Gerd Felix Hartmann-2 wrote
Smaller?
For me my austria map size increased from 295MB to 345MB...
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... On 07.02.2013 22:25, GerdP wrote:
Hi ,
attached is a patch that reduces the img size. Up to now, mkgmap created many so called CoordNodes when a road and e.g. a building shared an OSM node. This is not needed and was not intended. As far as I know it just blows up the size of the img file (typically ~500kb for each tile).
The patch reduces the amount of CoordNodes and also cleans some dead code around the highwayCount.
Please test if you see any (new) routing problems with this patch, I tried quite a while and found none in BaseCamp.
highwayCount_v1.patch <http://gis.19327.n5.nabble.com/file/n5748554/highwayCount_v1.patch>;
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5749522.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
okay I tested the v2.patch. Routing is pretty similar to without it. But it's not the same. Changes are small though. In general I would say in 6 out of 10 times better, in 4 times worse... (most times quite close though - tested with Mapsource/Basecamp, not on GPS). Filesize did decrease a little bit this time. (225MB for Austria *.img (without mdr which seems unchanged) vs 220MB new with patch). On 15.02.2013 10:57, GerdP wrote:
Hi Felix,
I think I've found the reason for the problems (increased img size)
Your style file probably contains many continue statements. This leads to the following situation: the same OSM way is added multiple times to the road network. For each node of a road, the highway count is increased. For a road that appears twice or more often, that means that all nodes will become routing nodes, not only those nodes that are also used in other streets. In the trunk version, this doesn't happen because each way is only counted once (but also ways that will not be added as roads)
It is easy to fix that problem, but I still have no idea why routing breaks with the patch (in the default style we don't add roads multiple times)
Attached is the corrected patch.
highwayCount_v2.patch <http://gis.19327.n5.nabble.com/file/n5749522/highwayCount_v2.patch>
Gerd
Felix Hartmann-2 wrote
Smaller?
For me my austria map size increased from 295MB to 345MB...
Routing over long distances is not working at all anymore (much much worse to before). Don't have time (need to sleep) to find out if any roads become unroutable though... On 07.02.2013 22:25, GerdP wrote:
Hi ,
attached is a patch that reduces the img size. Up to now, mkgmap created many so called CoordNodes when a road and e.g. a building shared an OSM node. This is not needed and was not intended. As far as I know it just blows up the size of the img file (typically ~500kb for each tile).
The patch reduces the amount of CoordNodes and also cleans some dead code around the highwayCount.
Please test if you see any (new) routing problems with this patch, I tried quite a while and found none in BaseCamp.
highwayCount_v1.patch <http://gis.19327.n5.nabble.com/file/n5748554/highwayCount_v1.patch>;
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ 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/PATCH-v1-highwayCount-tp5748554p5749522.html 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix, thanks, that sounds as expected, although I don't fully understand what it means when you add the same OSM way as different kinds of roads. I stopped searching for the reason of the routing problems which also occured with the default style. @Steve: Do you still work on it? Gerd Felix Hartmann-2 wrote
okay I tested the v2.patch. Routing is pretty similar to without it. But it's not the same. Changes are small though. In general I would say in 6 out of 10 times better, in 4 times worse... (most times quite close though - tested with Mapsource/Basecamp, not on GPS). Filesize did decrease a little bit this time. (225MB for Austria *.img (without mdr which seems unchanged) vs 220MB new with patch).
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5749703.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 17/02/13 18:53, GerdP wrote:
Hi Felix,
thanks, that sounds as expected, although I don't fully understand what it means when you add the same OSM way as different kinds of roads.
I stopped searching for the reason of the routing problems which also occured with the default style. @Steve: Do you still work on it?
If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong. ..Steve
Hi Steve, Steve Ratcliffe wrote
@Steve: Do you still work on it?
If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong.
I also have no idea what is wrong. I think that the NOD data is equal, so maybe it is simply related to the size or distance of sub divisions. If that is right, I should be able to find a threshold value by adding or removing things. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5750185.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I did a few more tests to track down why --transparent breaks long distance routing. My result: It seems that long distance routing needs the type 0x4b polygons that are created if you don't specify --transparent. Reason for this assumption: When I change mkgmap to add a different type as background (e.g. 0x50 for forest), long distance routing is more or less surely broken. Up to now, --transparent changes two things: 1) it sets a bit in the TRE header file 2) it avoids to create the backgroud polygon(s) with type 0x4b I am not sure if 2) is needed to get a transparent map. Attached is a small patch that changes mkgmap so that it always generates the background polygon. @Felix: Could you please try this with the --transparent option ? Is the map transparent or not ? Is long distance routing working ? If that doesn't work, another possible solution would be to disallow--transparent in combination with --route. I assume that would require to have the --transparent flag for all other layers? Ciao, Gerd addBackgroud.patch <http://gis.19327.n5.nabble.com/file/n5750309/addBackgroud.patch> GerdP wrote
Hi Steve, Steve Ratcliffe wrote
@Steve: Do you still work on it?
If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong. I also have no idea what is wrong. I think that the NOD data is equal, so maybe it is simply related to the size or distance of sub divisions. If that is right, I should be able to find a threshold value by adding or removing things.
Gerd
GerdP wrote
Hi Steve, Steve Ratcliffe wrote
@Steve: Do you still work on it?
If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong. I also have no idea what is wrong. I think that the NOD data is equal, so maybe it is simply related to the size or distance of sub divisions. If that is right, I should be able to find a threshold value by adding or removing things.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5750309.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I'll not have time to test until Tuesday (would have time today, but my server is just rendering a map of Europe, so that will take some hours). I use --transparent, and later use gmaptool to make the map not transparent. (gmt.exe -w -n %FID%*.img) I'll test if there is any difference. As my maps do much more turns, it's a different game anyhow. Overall the patch v2 is very similar to not using it, so I decided to use it for now. Long distance routing for my maps is like 80km air distance, 120-140km real distance, 150 turns. I would consider any output to be broken, if routing crashes before 50-60 turns. v1 was just like that, 50-60 turns max for me. I never noticed difference to 0x4b or another background polygon. I currently use: ( natural=land | landuse=land ) [0x10101 resolution 21-14 continue] ( natural=land | landuse=land | natural=cape ) | ( place=island & name=* ) [0x10100 resolution 22] Must say I never noticed a difference in routing when moving away from 0x4b years ago... I use --transparent because it gives higher performance when scrolling on old GPS like Vista HCx (and avoids the flashing). On 22.02.2013 11:45, GerdP wrote:
Hi,
I did a few more tests to track down why --transparent breaks long distance routing. My result: It seems that long distance routing needs the type 0x4b polygons that are created if you don't specify --transparent. Reason for this assumption: When I change mkgmap to add a different type as background (e.g. 0x50 for forest), long distance routing is more or less surely broken. Up to now, --transparent changes two things: 1) it sets a bit in the TRE header file 2) it avoids to create the backgroud polygon(s) with type 0x4b
I am not sure if 2) is needed to get a transparent map. Attached is a small patch that changes mkgmap so that it always generates the background polygon.
@Felix: Could you please try this with the --transparent option ? Is the map transparent or not ? Is long distance routing working ?
If that doesn't work, another possible solution would be to disallow--transparent in combination with --route. I assume that would require to have the --transparent flag for all other layers?
Ciao, Gerd
addBackgroud.patch <http://gis.19327.n5.nabble.com/file/n5750309/addBackgroud.patch>
GerdP wrote
Hi Steve, Steve Ratcliffe wrote
@Steve: Do you still work on it? If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong. I also have no idea what is wrong. I think that the NOD data is equal, so maybe it is simply related to the size or distance of sub divisions. If that is right, I should be able to find a threshold value by adding or removing things.
Gerd
GerdP wrote
Hi Steve, Steve Ratcliffe wrote
@Steve: Do you still work on it? If you mean the difference with --transparent then I've pretty much given up on finding the reason. It doesn't make a lot of sense - why is it different than say removing all the forest polygons? I've not found anything that mkgmap is doing wrong. I also have no idea what is wrong. I think that the NOD data is equal, so maybe it is simply related to the size or distance of sub divisions. If that is right, I should be able to find a threshold value by adding or removing things.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5750309.html 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hi Felix, Felix Hartmann-2 wrote
I'll not have time to test until Tuesday (would have time today, but my server is just rendering a map of Europe, so that will take some hours).
OK, no problem. Felix Hartmann-2 wrote
I use --transparent, and later use gmaptool to make the map not transparent. (gmt.exe -w -n %FID%*.img) I'll test if there is any difference. As my maps do much more turns, it's a different game anyhow.
Overall the patch v2 is very similar to not using it, so I decided to use it for now.
That's good to know. In the meantime I noticed that the additional hashset in v2 is not needed, a simple variable does the trick as well. I think I'll commit that today. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5750341.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi
When I change mkgmap to add a different type as background (e.g. 0x50 for forest), long distance routing is more or less surely broken.
OK good, I tried exactly the same thing yesterday, but MapSource wouldn't start up with the resulting map.
Up to now, --transparent changes two things: 1) it sets a bit in the TRE header file 2) it avoids to create the backgroud polygon(s) with type 0x4b
If no idea what the TRE header bit actually does. Polygons are opaque, so you need a polygon that covers the whole map, the 0x4b is the standard way of doing this, but other ones work for that purpose.
I am not sure if 2) is needed to get a transparent map. Attached is a small patch that changes mkgmap so that it always generates the background polygon.
My believe was that transparent maps were for contour lines or POI and similar uses. In these cases routing is not important, so I'm not really concerned unless we are doing something wrong.
If that doesn't work, another possible solution would be to disallow--transparent in combination with --route. I assume that would require to have the --transparent flag for all other layers?
Normally you would have an opaque map at the bottom and one or more transparent maps on top. Routing should happen normally on the bottom map. ..Steve
participants (4)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Steve Ratcliffe