highway count not fixed yet... - merge-roads-branch
Just cannot find the topic on the merge-roads-branch. Is it known that the highway count error is not fully fixed yet? I still get loads of them.
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked. Gerd WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok. WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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 WanMil, yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow. Gerd WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact. The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!? WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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 WanMil, yes, first and last node should be coordNode, so the assert is ok. Unfortunately, the data flow in StyledConverter is so complex that it is difficult to say why the assertion is triggered. I guess one of the split routines is still missing a call of incHighwayCount(). Gerd
Date: Thu, 26 Sep 2013 21:42:28 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact.
The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!?
WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yeah, I guess it should be possible to simplify them be reimplementation. But that's only a rough guess.... A test case would be great to find the missing incHighwayCount()!
Hi WanMil,
yes, first and last node should be coordNode, so the assert is ok. Unfortunately, the data flow in StyledConverter is so complex that it is difficult to say why the assertion is triggered. I guess one of the split routines is still missing a call of incHighwayCount().
Gerd
Date: Thu, 26 Sep 2013 21:42:28 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact.
The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!?
WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
> Just cannot find the topic on the merge-roads-branch. > > Is it known that the highway count error is not fully fixed yet? I > still > get loads of them. > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context:
http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc...
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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
_______________________________________________ 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
Hi WanMil, at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all. Gerd
Date: Thu, 26 Sep 2013 21:53:20 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yeah, I guess it should be possible to simplify them be reimplementation. But that's only a rough guess....
A test case would be great to find the missing incHighwayCount()!
Hi WanMil,
yes, first and last node should be coordNode, so the assert is ok. Unfortunately, the data flow in StyledConverter is so complex that it is difficult to say why the assertion is triggered. I guess one of the split routines is still missing a call of incHighwayCount().
Gerd
Date: Thu, 26 Sep 2013 21:42:28 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact.
The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!?
WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote > Ok, but I need some food (style, data etc.) to reproduce it... > >> Just cannot find the topic on the merge-roads-branch. >> >> Is it known that the highway count error is not fully fixed yet? I >> still >> get loads of them. >> _______________________________________________ >> mkgmap-dev mailing list >>
> mkgmap-dev@.org
>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > _______________________________________________ > 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/highway-count-not-fixed-yet-merge-roads-branc...
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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
_______________________________________________ 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed. On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12 and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
Date: Thu, 26 Sep 2013 21:53:20 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yeah, I guess it should be possible to simplify them be reimplementation. But that's only a rough guess....
A test case would be great to find the missing incHighwayCount()!
Hi WanMil,
yes, first and last node should be coordNode, so the assert is ok. Unfortunately, the data flow in StyledConverter is so complex that it is difficult to say why the assertion is triggered. I guess one of the split routines is still missing a call of incHighwayCount().
Gerd
Date: Thu, 26 Sep 2013 21:42:28 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact.
The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!?
WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
> Hi WanMil, > > reg. the highway count: > I guess you already noticed, but just to make sure: > In trunk the absolute value of the counter does not really matter > as long as it is > 1 for each point that should be converted to a > node. I think a lot of routines are calling > incHighwayCount() "just to make sure", so a node where two > arcs meet might have a counter > 2. > You have introduced decHighwayCount(), so now > each place where this counter is incremented has > to be double checked. > > Gerd > > > WanMil wrote >> Ok, but I need some food (style, data etc.) to reproduce it... >> >>> Just cannot find the topic on the merge-roads-branch. >>> >>> Is it known that the highway count error is not fully fixed yet? I >>> still >>> get loads of them. >>> _______________________________________________ >>> mkgmap-dev mailing list >>> > >> mkgmap-dev@.org > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> >> _______________________________________________ >> 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/highway-count-not-fixed-yet-merge-roads-branc...
> 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 >
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context:
http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc...
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
_______________________________________________ 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
_______________________________________________ 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
Hi, ok, the problems with way 156936823 are probably also the cause for the assertion. I was not yet able to reproduce the problem. Please check: 1) You use --remove-short-arcs without a value. This is evaluated as --remove-short-arcs=0.0 @Steve: I think this is not intended and should be changed so that the default value 5.0 is used in this case as well? 2) I found no short arc < 5.0 m in the area around this way, and the way is not very special (besides that it has a tag "fixme=tracktype"). Please post the rules that are used for this way. 3) Is it possible that the way is near a tile boundary? Gerd Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed. On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12 and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote: Hi WanMil, at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all. Gerd > Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@web.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@web.de > > > To: mkgmap-dev@lists.mkgmap.org.uk > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> 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 > > > >>> > > > >> > > > >> _______________________________________________ > > > >> 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/highway-count-not-fixed-yet-merge-roads-branc... > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
OK, I've fixed that in trunk.
Date: Fri, 27 Sep 2013 08:07:50 +0100 From: steve@parabola.me.uk To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
On 27/09/13 08:04, Gerd Petermann wrote:
@Steve: I think this is not intended and should be changed so that the default value 5.0 is used in this case as well?
Yes, it should have the default value when no argument is given. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, WanMil, attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created. Gerd Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed. On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12 and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote: Hi WanMil, at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all. Gerd > Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@web.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@web.de > > > To: mkgmap-dev@lists.mkgmap.org.uk > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> 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/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> 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 > > > >>> > > > >> > > > >> _______________________________________________ > > > >> 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/highway-count-not-fixed-yet-merge-roads-branc... > > > > 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 > > > > > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it? I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting? 2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged. 3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging... WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@web.de <mailto:wmgcnfg@web.de> > To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@web.de <mailto:wmgcnfg@web.de> > > > To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@lists.mkgmap.org.uk <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil wrote
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
Don't think so. All routines that replace or add points after that must make sure that they maintain the correct highway count. WanMil wrote
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
No, it just increases the possibility that the counter overflows. Maybe we should not use this counter at all. The information that it "hides" is that a point connects two or more roads. I think a better solution would be to have a method markRoutingNodes() which uses the counter and sets a bit flag in the coord instance. This routine would replace setHighwayCounts() and resetHighwayCounts(). WanMil wrote
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
This is a good idea. Maybe do it before and after? That also means that decHighwayCount() is obsolete, doesn't it? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
Don't think so. All routines that replace or add points after that must make sure that they maintain the correct highway count.
Ok, which routines perform such modifications? I couldn't find any such modifications of MapRoad instances after the StyledConverter.
WanMil wrote
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
No, it just increases the possibility that the counter overflows.
Maybe that's true for the trunk but in the branch there are real cases where it matters. Assume the following two ways: x>>>>>>>>>x===========x 1 2 1 (x = Node; >> oneway line; === oneway=no; highway count below nodes) The style might duplicate the oneway=no way into to oneway=yes ways >>>>>>>>>>> x>>>>>>>>>x<<<<<<<<<<<x 1 2 1 The merger might merge two of the ways: <<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 1 1 As a result the highway count of the 2nd and 3rd node is wrong. It should be 2 instead of 1. And AFAIK this difference matters.
Maybe we should not use this counter at all. The information that it "hides" is that a point connects two or more roads. I think a better solution would be to have a method markRoutingNodes() which uses the counter and sets a bit flag in the coord instance. This routine would replace setHighwayCounts() and resetHighwayCounts().
I don't understand the advantage? I think maintaining the highway count is the same like markRoutingNodes(). How do you want to know when to call markRoutingNodes()?
WanMil wrote
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
This is a good idea. Maybe do it before and after? That also means that decHighwayCount() is obsolete, doesn't it?
decHighwayCount() is obsolete as long as the highway counters are recalculated after mergeRoads(). When recalculating the highway count after mergeRoads() the RoadMerger does not care about (correct) highway counts (maybe a perf improvement might require correct highway counts but I don't know if the improvement is neccessary).
Gerd
Hi WanMil, thanks for the ascii graphics, I think that explains what goes wrong with Felix' style. I still don't see a need to change the setHighwayCount() method as long as we call it after the mergeRoads(). Why don't I like the usage of the highway count? Well, in some places we increment the counter for the 1st and last point of a way and the comment says // make sure the way has nodes at each end If that is really needed, I'd prefer to set a flag instead of messing up the counter. Gerd
Date: Sun, 29 Sep 2013 13:01:17 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
WanMil wrote
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
Don't think so. All routines that replace or add points after that must make sure that they maintain the correct highway count.
Ok, which routines perform such modifications? I couldn't find any such modifications of MapRoad instances after the StyledConverter.
WanMil wrote
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
No, it just increases the possibility that the counter overflows.
Maybe that's true for the trunk but in the branch there are real cases where it matters.
Assume the following two ways:
x>>>>>>>>>x===========x 1 2 1
(x = Node; >> oneway line; === oneway=no; highway count below nodes)
The style might duplicate the oneway=no way into to oneway=yes ways
>>>>>>>>>>> x>>>>>>>>>x<<<<<<<<<<<x 1 2 1
The merger might merge two of the ways:
<<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 1 1
As a result the highway count of the 2nd and 3rd node is wrong. It should be 2 instead of 1. And AFAIK this difference matters.
Maybe we should not use this counter at all. The information that it "hides" is that a point connects two or more roads. I think a better solution would be to have a method markRoutingNodes() which uses the counter and sets a bit flag in the coord instance. This routine would replace setHighwayCounts() and resetHighwayCounts().
I don't understand the advantage? I think maintaining the highway count is the same like markRoutingNodes(). How do you want to know when to call markRoutingNodes()?
WanMil wrote
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
This is a good idea. Maybe do it before and after? That also means that decHighwayCount() is obsolete, doesn't it?
decHighwayCount() is obsolete as long as the highway counters are recalculated after mergeRoads(). When recalculating the highway count after mergeRoads() the RoadMerger does not care about (correct) highway counts (maybe a perf improvement might require correct highway counts but I don't know if the improvement is neccessary).
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I've commited the changes to the merge_road branch. setHighwayCount() still need to be changed. In case the merged road has the same id as the duplicate road you have the same problem again. <<<<<<<<<<< (not counted due to same id) x>>>>>>>>>x>>>>>>>>>>>x 1 1 1 should be <<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 2 2 I still don't understand how you want to check which node is a routing node. It's easy for the first and the last node but how to proceed with the nodes inbetween? WanMil
Hi WanMil,
thanks for the ascii graphics, I think that explains what goes wrong with Felix' style. I still don't see a need to change the setHighwayCount() method as long as we call it after the mergeRoads().
Why don't I like the usage of the highway count? Well, in some places we increment the counter for the 1st and last point of a way and the comment says // make sure the way has nodes at each end If that is really needed, I'd prefer to set a flag instead of messing up the counter.
Gerd
Date: Sun, 29 Sep 2013 13:01:17 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
WanMil wrote
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
Don't think so. All routines that replace or add points after that must make sure that they maintain the correct highway count.
Ok, which routines perform such modifications? I couldn't find any such modifications of MapRoad instances after the StyledConverter.
WanMil wrote
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are
preserved
by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
No, it just increases the possibility that the counter overflows.
Maybe that's true for the trunk but in the branch there are real cases where it matters.
Assume the following two ways:
x>>>>>>>>>x===========x 1 2 1
(x = Node; >> oneway line; === oneway=no; highway count below nodes)
The style might duplicate the oneway=no way into to oneway=yes ways
>>>>>>> x>>>>>>>>>x<<<<<<<<<<<x 1 2 1
The merger might merge two of the ways:
<<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 1 1
As a result the highway count of the 2nd and 3rd node is wrong. It should be 2 instead of 1. And AFAIK this difference matters.
Maybe we should not use this counter at all. The information that it "hides" is that a point connects two or more roads. I think a better solution would be to have a method markRoutingNodes() which uses the counter and sets a bit flag in the coord instance. This routine would replace setHighwayCounts() and resetHighwayCounts().
I don't understand the advantage? I think maintaining the highway count is the same like markRoutingNodes(). How do you want to know when to call markRoutingNodes()?
WanMil wrote
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been
merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a
problem
with merging...
This is a good idea. Maybe do it before and after? That also means that decHighwayCount() is obsolete, doesn't it?
decHighwayCount() is obsolete as long as the highway counters are recalculated after mergeRoads(). When recalculating the highway count after mergeRoads() the RoadMerger does not care about (correct) highway counts (maybe a perf improvement might require correct highway counts but I don't know if the improvement is neccessary).
Gerd
_______________________________________________ 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
Hi WanMil,
setHighwayCount() still need to be changed. In case the merged road has the same id as the duplicate road you have the same problem again.
<<<<<<<<<<< (not counted due to same id) x>>>>>>>>>x>>>>>>>>>>>x 1 1 1
should be
<<<<<<<<<<< x>>>>>>>>>x>>>>>>>>>>>x 1 2 2
okay, now I understand. I forgot that the merged ways still have an id from one of the original OSM ways. Wouldn't it be better to create a new way with a fake id in the merge process? I think that also would help debugging. Gerd
Wouldn't it be better to create a new way with a fake id in the merge process?
That would possibly create problems with through route relations and turn restrictions which reference the original way ids.
I think that also would help debugging.
I my opinion a fake id does not really help debugging because you don't have any reference. A good way would be to use the original id but an indicator that the way has been modified. WanMil
Gerd
Hi WanMil,
Wouldn't it be better to create a new way with a fake id in the merge process?
That would possibly create problems with through route relations and turn restrictions which reference the original way ids.
OK, understood.
I think that also would help debugging.
I my opinion a fake id does not really help debugging because you don't have any reference. A good way would be to use the original id but an indicator that the way has been modified.
The problem that I see is that we write messages to the log containing the way ids. This can be very confusing when the way is not nearly identical to the way in the input file, esp. if the log message relates to points of a different way that was merged into the stated way. Maybe you can create a tag like mkgmap:road-merge-info that contains the merged ids? That would at least allow to modify StyledConverter.getDebugName() to use that info. Gerd
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7... C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml prepare: ivy-availability: download-ivy: init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml resolve-compile: compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List<Way> dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details. On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@web.de <mailto:wmgcnfg@web.de> > To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@web.de <mailto:wmgcnfg@web.de> > > > To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@lists.mkgmap.org.uk <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
_______________________________________________ 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
Hi Felix, is fixed with r2726. Gerd Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List <Way> dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From:
extremecarver@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> > > To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
okay, it seems that my problems are fixed now. I don't have good enough internet to actually check the created maps (waiting for comments if broken within the next 2-3 days) - but the filesize vs the working older version of the merge-roads branch has increased ever so slightly (instead of breaking down by 20-50%) and no more errors are displayed on running mkgmap (at least for the first 10 countries compiled so far..).... best include the patch to the branch - without it I would say the branch is not safe/usable... On 03.10.2013 13:37, GerdP wrote:
Hi Felix,
is fixed with r2726.
Gerd
Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List <Way> dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@ To: mkgmap-dev@.org Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@ <mailto: wmgcnfg@ > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@ <mailto: wmgcnfg@ > > > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto: mkgmap-dev@.org > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.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/highway-count-not-fixed-yet-merge-roads-branc... 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, a corrected version of the patch is already in the branch, so you should test with an unpatched r2726. Not sure what you mean with the filesize, why should it change that much? Gerd Felix Hartmann-2 wrote
okay, it seems that my problems are fixed now. I don't have good enough internet to actually check the created maps (waiting for comments if broken within the next 2-3 days) - but the filesize vs the working older version of the merge-roads branch has increased ever so slightly (instead of breaking down by 20-50%) and no more errors are displayed on running mkgmap (at least for the first 10 countries compiled so far..)....
best include the patch to the branch - without it I would say the branch is not safe/usable... On 03.10.2013 13:37, GerdP wrote:
Hi Felix,
is fixed with r2726.
Gerd
Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List
<Way>
dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@ To: mkgmap-dev@.org Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@ <mailto: wmgcnfg@ > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@ <mailto: wmgcnfg@ > > > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto: mkgmap-dev@.org > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.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/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
oh damn, I mixed up the dates in the log and wondered why the patch didn't apply without "handwork"... - however besides one empty line additionally I ended up with 2726 anyhow.... So all good. with filesize I meant 2716-2722 which sometimes crashed, sometimes lost lots of data in the tiles. so now the branch seems to be quite stable for me again... On 03.10.2013 15:58, GerdP wrote:
Hi Felix,
a corrected version of the patch is already in the branch, so you should test with an unpatched r2726.
Not sure what you mean with the filesize, why should it change that much? Gerd
Felix Hartmann-2 wrote
okay, it seems that my problems are fixed now. I don't have good enough internet to actually check the created maps (waiting for comments if broken within the next 2-3 days) - but the filesize vs the working older version of the merge-roads branch has increased ever so slightly (instead of breaking down by 20-50%) and no more errors are displayed on running mkgmap (at least for the first 10 countries compiled so far..)....
best include the patch to the branch - without it I would say the branch is not safe/usable... On 03.10.2013 13:37, GerdP wrote:
Hi Felix,
is fixed with r2726.
Gerd
Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List
<Way>
dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From: extremecarver@ To: mkgmap-dev@.org Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From: wmgcnfg@ <mailto: wmgcnfg@ > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From: wmgcnfg@ <mailto: wmgcnfg@ > > > > To: mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org <mailto: mkgmap-dev@.org > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto: mkgmap-dev@.org > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.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/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.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/highway-count-not-fixed-yet-merge-roads-branc... 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 Gerd, I think we are using JDK 1.7 now. So your fix is targeting back to 1.6? WanMil
Hi Felix,
is fixed with r2726.
Gerd
Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List <Way> dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From:
extremecarver@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> > > To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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 WanMil, yes and no. As long as build.xml contains <property name="ant.build.javac.target" value="1.6"/> the compile fails if you use new 1.7 features. Gerd WanMil wrote
Hi Gerd,
I think we are using JDK 1.7 now. So your fix is targeting back to 1.6?
WanMil
Hi Felix,
is fixed with r2726.
Gerd
Felix Hartmann-2 wrote
I'm having problems compiling mkgmap with this patch... (trunk1 is my folder for the merge-roads branch). dunno really what's going on here... I only have jdk 7 installed (update 40) and uninstalled java jdk7 and jre7...
C:\garmin\mkgmap_trunk1>ant dist Buildfile: C:\garmin\mkgmap_trunk1\build.xml
prepare:
ivy-availability:
download-ivy:
init-ivy: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = C:\garmin\mkgmap_trunk1\ivysetting s.xml
resolve-compile:
compile: [javac] Compiling 474 source files to C:\garmin\mkgmap_trunk1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 1.6 [javac] C:\garmin\mkgmap_trunk1\src\uk\me\parabola\mkgmap\osmstyle\StyledCon verter.java:1751: error: diamond operator is not supported in -source 1.6 [javac] List
<Way>
dupIdHighways = new ArrayList<>(); [javac] ^ [javac] (use -source 7 or higher to enable diamond operator) [javac] 1 error [javac] 1 warning
BUILD FAILED C:\garmin\mkgmap_trunk1\build.xml:237: Compile failed; see the compiler error ou tput for details.
On 28.09.2013 14:35, WanMil wrote:
Hi Gerd,
in my opinion recalculating the highway counter after removing the short arcs should fix all problems, shouldn't it?
I've added three changes to the patch: 1. When calculating the highway count ways with duplicate id are not considered. This avoid that all points of a duplicated way are preserved by all filters. I think this should be modified a bit. For the first and last point of those ways the highway count should be increased and also all points where another way is connected. I have no use case where this matters but I think it is the "correct" counting?
2. I have added the problematic point in the error message of the MapBuilder in case a node is not a CoordNode. Just having the way id might not be enough information and the way also might have been merged.
3. I have moved the recalculation of the highway counters after the merge procedure. This should not change anything but it avoids a problem with merging...
WanMil
Hi Felix, WanMil,
attached is a patch that might solve the problem. I was still not able to reproduce it, so it's just a guess: In a special case, we create a new Coord instance to replace a CoordPOI instance. This new instance has highway count = 0. A very special case might be that this point is later used to split the way, in that case it would have highwaycount=1 for a first or last point of a road. The patch increments the count when the coord is created.
Gerd
------------------------------------------------------------------------ Date: Fri, 27 Sep 2013 02:51:58 +0200 From:
extremecarver@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
no, I don't use any roundabout command like options, but adjust turn headings?? -- see below for all commandline options. From style I don't call much except loads of continues and continue with action, as well as some link to pois stuff like reduce road_class/road_speed.
On the old version the only very occasional problem note I get is the following - in this case for Bayern (Germany Bundesland) Geofabrik extract: start compilation 21:45:44 Velomap bayern this is run58 SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823) SEVERE (MapBuilder): c:\openmtbmap\maps\65260023.osm.pbf: possible routing problem: road end-points not both coordNodes: (http://www.openstreetmap.org/browse/way/156936823)
I'm using theese commandline options: start /low /b /wait java -jar -Xms6000M -Xmx10300M c:\openmtbmap\mkgmap.jar %max-jobs% %generate-sea% %precomp-seaxx% %style-file% --nsis %indx% %levels% --adjust-turn-headings --add-pois-to-areas --reduce-point-density=3.4 --reduce-point-density-polygon=6 --housenumbers --remove-short-arcs --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:16, 23:14, 22:12, 21:11, 20:10, 19:9, 18:8, 17:7, 16:6, 15:5, 14:4, 13:3, 12:2, 11:0, 10:0" --description=openmtbmap_%abr% --show-profiles=1 %locationxx% --route --country-abbr=%abr% --country-name=%country% --mapname=%FID%0000 --family-id=%FID% --product-id=1 --series-name=openmtbmap_%country%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapsetc --keep-going --area-name="%country%_%date%_openmtbmap.org" -c c:\openmtbmap\maps\template.%countryx% 7*.img >NUL
with these variables in general: set generate-sea=--generate-sea --latin1 set precomp-seaxx=--precomp-sea=c:\openmtbmap\maps\sea.zip set levels=--levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12
and for most countries: set indx=--index (not using index for Asia continent as asia continent with index was crashing in Basecamp/Mapsource very often, only few compiles actually worked) set max-jobs=--max-jobs=8 (for some countries 7 as I ran out of memory on them and server started to swap=slower) On 26.09.2013 21:57, Gerd Petermann wrote:
Hi WanMil,
at least we should know if options like frig-roundabout are used. Afaik the default style will never touch these routines. I guess Felix uses almost all.
Gerd
> Date: Thu, 26 Sep 2013 21:53:20 +0200 > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch > > Yeah, I guess it should be possible to simplify them be > reimplementation. But that's only a rough guess.... > > A test case would be great to find the missing incHighwayCount()! > > > Hi WanMil, > > > > yes, first and last node should be coordNode, so the assert is ok. > > Unfortunately, the data flow in StyledConverter is > > so complex that it is difficult to say why the assertion is triggered. I > > guess one of the split routines is still > > missing a call of incHighwayCount(). > > > > Gerd > > > > > > > Date: Thu, 26 Sep 2013 21:42:28 +0200 > > > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> > > To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > Subject: Re: [mkgmap-dev] highway count not fixed yet... - > > merge-roads-branch > > > > > > Yes, it is meant to reduce the number of CoordNodes because that should > > > reduce the size of the routing network and might have a positive impact. > > > > > > The assertion reported by Felix seems to be a problem of the highway > > > count. The assertion checks if the first node of a MapRoad is a > > > CoordNode. I think this is required, isn't is? > > > While writing I am thinking of no exit roads. What about these roads? I > > > think the first and the last point should also be a CoordNode?!? > > > > > > WanMil > > > > > > > Hi WanMil, > > > > > > > > yes, it will not cause problems. On the other hand, if you do it to > > > > reduce the number of CoordNodes, we should try to have a correct > > > > counter. I think the short-arc-removal is not always correctly > > > > maintaining it. I'll have a look at it tomorrow. > > > > > > > > Gerd > > > > > > > > > > > > > > > > > > > > WanMil wrote > > > >> Hi Gerd, > > > >> > > > >> decHighwayCount() is called only on the node where two roads are > > merged. > > > >> So assuming that the highway count gives the number of connected roads > > > >> calling this method in such a case should be ok. > > > >> > > > >> WanMil > > > >> > > > >>> Hi WanMil, > > > >>> > > > >>> reg. the highway count: > > > >>> I guess you already noticed, but just to make sure: > > > >>> In trunk the absolute value of the counter does not really matter > > > >>> as long as it is > 1 for each point that should be converted to a > > > >>> node. I think a lot of routines are calling > > > >>> incHighwayCount() "just to make sure", so a node where two > > > >>> arcs meet might have a counter > 2. > > > >>> You have introduced decHighwayCount(), so now > > > >>> each place where this counter is incremented has > > > >>> to be double checked. > > > >>> > > > >>> Gerd > > > >>> > > > >>> > > > >>> WanMil wrote > > > >>>> Ok, but I need some food (style, data etc.) to reproduce it... > > > >>>> > > > >>>>> Just cannot find the topic on the merge-roads-branch. > > > >>>>> > > > >>>>> Is it known that the highway count error is not fully fixed yet? I > > > >>>>> still > > > >>>>> get loads of them. > > > >>>>> _______________________________________________ > > > >>>>> mkgmap-dev mailing list > > > >>>>> > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>>>> > > > >>>> > > > >>>> _______________________________________________ > > > >>>> mkgmap-dev mailing list > > > >>> > > > >>>> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > >>> > > > >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -- > > > >>> View this message in context: > > > >>> > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > >>> Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > >>> _______________________________________________ > > > >>> mkgmap-dev mailing list > > > >>> > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > >>> > > > >> > > > >> _______________________________________________ > > > >> mkgmap-dev mailing list > > > > > > > >> mkgmap-dev@.org <mailto:mkgmap-dev@.org> > > > > > > > >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > View this message in context: > > http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... > > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > > _______________________________________________ > > > > mkgmap-dev mailing list > > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > > > > > _______________________________________________ > > > mkgmap-dev mailing list > > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > _______________________________________________ > > mkgmap-dev mailing list > >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Steve Ratcliffe wrote
On 26/09/13 20:49, Gerd Petermann wrote:
yes, first and last node should be coordNode
Is that really true? What if the road only joins others at the middle?
well, I don't know if it is really needed, but least the program increments highway count for the first and last node before calling addRoadAfterSplittingLoops(). This routine may split the way again before it is converted to a MapRoad instance. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil, it is difficult to maintain the correct value when nodes are merged. in short-arc-removal. On the other hand, we can simply count the real value again after that. Attached is a patch that implements that. I did not see much difference in the img size, and I doubt that it solves Felix problem. Gerd
Date: Thu, 26 Sep 2013 21:42:28 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] highway count not fixed yet... - merge-roads-branch
Yes, it is meant to reduce the number of CoordNodes because that should reduce the size of the routing network and might have a positive impact.
The assertion reported by Felix seems to be a problem of the highway count. The assertion checks if the first node of a MapRoad is a CoordNode. I think this is required, isn't is? While writing I am thinking of no exit roads. What about these roads? I think the first and the last point should also be a CoordNode?!?
WanMil
Hi WanMil,
yes, it will not cause problems. On the other hand, if you do it to reduce the number of CoordNodes, we should try to have a correct counter. I think the short-arc-removal is not always correctly maintaining it. I'll have a look at it tomorrow.
Gerd
WanMil wrote
Hi Gerd,
decHighwayCount() is called only on the node where two roads are merged. So assuming that the highway count gives the number of connected roads calling this method in such a case should be ok.
WanMil
Hi WanMil,
reg. the highway count: I guess you already noticed, but just to make sure: In trunk the absolute value of the counter does not really matter as long as it is > 1 for each point that should be converted to a node. I think a lot of routines are calling incHighwayCount() "just to make sure", so a node where two arcs meet might have a counter > 2. You have introduced decHighwayCount(), so now each place where this counter is incremented has to be double checked.
Gerd
WanMil wrote
Ok, but I need some food (style, data etc.) to reproduce it...
Just cannot find the topic on the merge-roads-branch.
Is it known that the highway count error is not fully fixed yet? I still get loads of them. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/highway-count-not-fixed-yet-merge-roads-branc... 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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Steve Ratcliffe -
WanMil