Hi, the help file says merge-lines < ... > At the moment this option causes routing errors. Use only if routing is not needed in your map. Maybe I found the reason for the routing errors: If the segments of a road are merged, it might happen that the LineSplitterFilter has to split it because it has more than 250 points. The current implementation of LineSplitterFilter does this: The first part of a road is added as a road, all remaining parts are added as lines. With a simple change all parts are added as roads: Index: LineSplitterFilter.java =================================================================== --- LineSplitterFilter.java (revision 2581) +++ LineSplitterFilter.java (working copy) @@ -84,7 +84,7 @@ log.debug("saving next part"); l.setPoints(coords); next.doFilter(l); - l = new MapLine(line); + l = line.copy(); count = 0; first = false; The interesting part for me is that the following routines seem to expect exactly this, but parts of the code was never executed. See also http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748864.html I also wonder if it really makes sense to limit the check "Non-routable way with routable type ..." to resolution 24. I'll try to find out more tomorrow. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, the merge-lines happens for resolution >= 22 only. AFAIK the routing graph is based on resolution 24 only? So I would not expect a problem here? Anyhow I am not sure. I started also some tests about routing (I did have the idea expand the merge-lines filter to the routing graph). I saw some roundabouts multiple times in the routing graph but I did not analyze this in detail. I think I will have a look on in within the next days... WanMil
Hi,
the help file says merge-lines < ... > At the moment this option causes routing errors. Use only if routing is not needed in your map.
Maybe I found the reason for the routing errors: If the segments of a road are merged, it might happen that the LineSplitterFilter has to split it because it has more than 250 points. The current implementation of LineSplitterFilter does this: The first part of a road is added as a road, all remaining parts are added as lines. With a simple change all parts are added as roads: Index: LineSplitterFilter.java =================================================================== --- LineSplitterFilter.java (revision 2581) +++ LineSplitterFilter.java (working copy) @@ -84,7 +84,7 @@ log.debug("saving next part"); l.setPoints(coords); next.doFilter(l); - l = new MapLine(line); + l = line.copy();
count = 0; first = false;
The interesting part for me is that the following routines seem to expect exactly this, but parts of the code was never executed. See also http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748864.html
I also wonder if it really makes sense to limit the check "Non-routable way with routable type ..." to resolution 24. I'll try to find out more tomorrow.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, merge-lines happens for res < 22, see MapBuilder.java: if (mergeLines && res < 22) { My understanding is that routing is also done with the data of lower resolutions, e.g. for long distance routing, but my patch below is probably too simple, as it doesn't care about CoordNode. In StyledConverter a lot of code is used to split the way at the "right" point. Gerd WanMil wrote
Hi Gerd,
the merge-lines happens for resolution >= 22 only. AFAIK the routing graph is based on resolution 24 only? So I would not expect a problem here?
Anyhow I am not sure. I started also some tests about routing (I did have the idea expand the merge-lines filter to the routing graph). I saw some roundabouts multiple times in the routing graph but I did not analyze this in detail. I think I will have a look on in within the next days...
WanMil
Hi,
the help file says merge-lines < ... > At the moment this option causes routing errors. Use only if routing is not needed in your map.
Maybe I found the reason for the routing errors: If the segments of a road are merged, it might happen that the LineSplitterFilter has to split it because it has more than 250 points. The current implementation of LineSplitterFilter does this: The first part of a road is added as a road, all remaining parts are added as lines. With a simple change all parts are added as roads: Index: LineSplitterFilter.java =================================================================== --- LineSplitterFilter.java (revision 2581) +++ LineSplitterFilter.java (working copy) @@ -84,7 +84,7 @@ log.debug("saving next part"); l.setPoints(coords); next.doFilter(l); - l = new MapLine(line); + l = line.copy();
count = 0; first = false;
The interesting part for me is that the following routines seem to expect exactly this, but parts of the code was never executed. See also http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748864.html
I also wonder if it really makes sense to limit the check "Non-routable way with routable type ..." to resolution 24. I'll try to find out more tomorrow.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913.html 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/merge-lines-and-routing-tp5758913p5758917.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil,
merge-lines happens for res < 22, see MapBuilder.java: if (mergeLines && res < 22) {
Right, that's what I wanted to say...
My understanding is that routing is also done with the data of lower resolutions, e.g. for long distance routing, but my patch below is probably too simple, as it doesn't care about CoordNode.
If that's the case and lower resolutions are used for routing I am quite sure that the merge-lines filter (and some other filters too) are doing harm.
In StyledConverter a lot of code is used to split the way at the "right" point.
Gerd
If that's the case and lower resolutions are used for routing I am quite sure that the merge-lines filter (and some other filters too) are doing harm.
I agree. If I got this right, the list of points of a MapRoad should always start and end with a CoordNode (no matter what resolution) when it "arrives" in the LineAddFilter, else routing may not work. This is not always the case: The DouglasPeuckerFilter may remove the last point in case the previous point has the same coords and is also preserved. This can be fixed easily. The merge-lines filter can simply be changed to merge only non-routable ways, which also allows to use it for all resolutions. I also tried to change the LineSplitterFilter so that it splits roads only at coordNodes, but that did not help (routing was broken). Maybe the reason for this is somewhere in the code that writes to the img file, but I don't know where to look at, so I decided to disable line merging for roads which seems to work fine. Attached is a patch that implements the changes to allow using --merge-lines with --route The compiled binary is here: http://files.mkgmap.org.uk/download/118/mkgmap.jar Gerd
Attached is a patch that implements the changes to allow using --merge-lines with --route
Thanks for the patch. It looks reasonable. Did you see any improvement regarding routing? In the past I wasn't able to see any difference if --merge-lines is set or not. But I see that a lot of long distance routings do not work in MapSource and on my Oregon and Nüvi too. I will compile a map with the patch and will post some examples. WanMil
Hi WanMil, No, I did not find an example where merge-lines caused trouble with routing, but I did not try long distance routing. Routing is completely broken if you change the source so that merging is also done for roads in res 24, so it must be handled with care, but we may also allow it again for res < 24. Gerd WanMil wrote
Attached is a patch that implements the changes to allow using --merge-lines with --route
Thanks for the patch. It looks reasonable.
Did you see any improvement regarding routing? In the past I wasn't able to see any difference if --merge-lines is set or not.
But I see that a lot of long distance routings do not work in MapSource and on my Oregon and Nüvi too. I will compile a map with the patch and will post some examples.
WanMil _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759043.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Routing is completely broken if you change the source so that merging is also done for roads in res 24, so it must be handled with care,
The LineMergeFilter does not care about routing nodes. That should be the reason why routing fails when using it at res 24. Anyhow I did not yet fully understand about the relation of the routing network (NOD) to the map data at resolution 24. Are there any ids that are shared? When selecting a street how does the Garmin find the correct entry into the routing network?
but we may also allow it again for res < 24.
Unless there is a concrete example or a concrete explanation why it shouldn't be allowed I would allow it. WanMil
Routing is completely broken if you change the source so that merging is also done for roads in res 24, so it must be handled with care,
The LineMergeFilter does not care about routing nodes. That should be the reason why routing fails when using it at res 24.
yes, but not the only one. I created a version that made sure to split roads so that they start and end with coordNode, but that (alone) did not help.
Anyhow I did not yet fully understand about the relation of the routing network (NOD) to the map data at resolution 24. Are there any ids that are shared? When selecting a street how does the Garmin find the correct entry into the routing network?
I wish I could say that I understand it :-O
but we may also allow it again for res < 24.
Unless there is a concrete example or a concrete explanation why it shouldn't be allowed I would allow it.
yes, I agree.
Routing is completely broken if you change the source so that
merging is
also done for roads in res 24, so it must be handled with care,
The LineMergeFilter does not care about routing nodes. That should be the reason why routing fails when using it at res 24.
yes, but not the only one. I created a version that made sure to split roads so that they start and end with coordNode, but that (alone) did not help.
Do you mean the LineMergeFilter or the LineSplitterFilter?
Anyhow I did not yet fully understand about the relation of the routing network (NOD) to the map data at resolution 24. Are there any ids that are shared? When selecting a street how does the Garmin find the correct entry into the routing network?
I wish I could say that I understand it :-O
Let's have a look on the processing in mkgmap: 1. The StyledConverter applies the style to the Way object. This creates a MapRoad object. 2. The MapRoad object is added to the RoadNetwork 3. The MapRoad object is passed through the filters. Some of these filters may not care about routing nodes (CoordNode). But filters usually copy the MapRoad object before modifying it. 4. After all filters have been applied the RoadNetwork is generated. Do you think my short algo desription is correct? I think it's not bad to try to understand the different processing steps to see the big picture...
yes, but not the only one. I created a version that made sure to split roads so that they start and end with coordNode, but that (alone) did not help.
Do you mean the LineMergeFilter or the LineSplitterFilter?
While testing I changed the code so that merge-lines was applied to roads also on res 24. As a result you get e.g. one MapRoad containing all points of the original OSM way. This is passed through the filters and LineSplitterFilter will cut it into peaces of < 250 points without looking at coordNodes. So I changed LineSplitterFilter to split only at coordNodes.
Let's have a look on the processing in mkgmap:
1. The StyledConverter applies the style to the Way object. This creates a MapRoad object. 2. The MapRoad object is added to the RoadNetwork 3. The MapRoad object is passed through the filters. Some of these filters may not care about routing nodes (CoordNode). But filters usually copy the MapRoad object before modifying it. 4. After all filters have been applied the RoadNetwork is generated.
Do you think my short algo desription is correct? Yes, I think that's what happens.
I think it's not bad to try to understand the different processing steps to see the big picture... The next interesting part is that a RoadDef instance should collect parts of a road on different resolutions. In r2584 the program flow never allows that more than one segment is collected at one resolution, but RoadDef is implemented to do that. With my changes these dead code parts were reached (again), but routing did no longer work (not at all). So, I assume that the routines which build the network are wrong. I'll try to trace that down tomorrow.
Gerd
Hi WanMil, WanMil wrote
Let's have a look on the processing in mkgmap:
1. The StyledConverter applies the style to the Way object. This creates a MapRoad object. 2. The MapRoad object is added to the RoadNetwork 3. The MapRoad object is passed through the filters. Some of these filters may not care about routing nodes (CoordNode). But filters usually copy the MapRoad object before modifying it. 4. After all filters have been applied the RoadNetwork is generated.
Do you think my short algo desription is correct? I think it's not bad to try to understand the different processing steps to see the big picture...
I think the problem is that we do some calculations before the filters are applied, for example the StyledConverter calls road.setNumNodes(numNodes); which sets the number of coordNodes in a road. This number is written to the img file, so it causes errors if the number of these nodes doesn't match after the filters were used. I think the same problem may happen with the setStartsWithNode() method. I'd prefer to do these calculations after all the filters were applied, but I don't know yet if it's possible. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759091.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
WanMil wrote
I'd prefer to do these calculations after all the filters were applied, but I don't know yet if it's possible.
That sounds good. At least this approach avoids hard to find side effects of filters. And hopefully the code will get cleaner :-)
I had the same idea, but we still have to make sure that we don't loose important information in the filters, esp. regarding nodes shared by roads. I'd like to move all calls to methods of RoadNetwork after the filter chain, but that is not that simple. I think we have to move also all the code reg. restrictions, maybe also the housenumber part. A sketch for the new program flow: We keep StyledConverter up to the call of findUnconnectedRoads(); All other calculations regarding roads are probably better placed after the filter chain. I don't know how this will affect all the splitting routines. If we just move the code there is no benefit. I still don't fully understand the special cases reg. routing and resolution 24. If I got this right we add all roads to RoadNetwork and we do the routing calculations for all roads, no matter wheter they are written as resolution 24 or not. This is also true for the routines like setHighwayCounts() and findUnconnectedRoads(). Maybe this is okay because the users make sure that they add multiple copies of a road with different types on different resolutions, but should mkgmpa rely on that? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759311.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I'd like to move all calls to methods of RoadNetwork after the filter chain, but that is not that simple. I think we have to move also all the code reg. restrictions, maybe also the housenumber part.
Hi Gerd, please don't mind about the housenumber part. I think it might be more easy to redevelop it after your changes instead of keeping the current code. WanMil
Hi WanMil, okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24. Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581 I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines. Compiled binary is here: http://files.mkgmap.org.uk/download/119/mkgmap.jar Gerd
Date: Thu, 2 May 2013 20:01:32 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] merge-lines and routing
I'd like to move all calls to methods of RoadNetwork after the filter chain, but that is not that simple. I think we have to move also all the code reg. restrictions, maybe also the housenumber part.
Hi Gerd,
please don't mind about the housenumber part. I think it might be more easy to redevelop it after your changes instead of keeping the current code.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24.
Looks good.
Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581
Oh, I didn't expect that merge-lines noticeably decreases processing time. Nice :-)
I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines.
+1
Compiled binary is here: |http://files.mkgmap.org.uk/download/119/mkgmap.jar
|Gerd
I have one problem with merge-lines - I often copy a road to put non routable overlays on it. Currently I think sometimes the merge-lines or some other filters are enacted on those copies - hence stuff like oneway arrows (non routable) will be having a different shape, than the underlying road. I think I would need to have all ways that have a highway=* tag excluded at 24 (or make sure that if the way is done by using a continue/continue with_actions command - either before or after - will not be processed, or processed the same way as the highway). So assuming a road with highway=tertiary & oneway=yes I create to lines (0x04 and 0x10650) 1.: oneway=yes [0x10650 resolution 24 continue] highway=tertiary [0x04 resolution 20] both ways should be processed equally, 2. highway=tertiary [0x04 resolution 20 continue] oneway=yes [0x10650 resolution 24] both ways should be processed equally again. 3. however a way with railway=line & oneway=yes oneway=yes [0x10650 resolution 24 continue] railway=line [0x10651 resolution 22 continue] should be processed, as they don't include a routable copy/origin created using continue command. Therefore I think exclude all filtering that is not done to highway=* (or other definable keys) also for any other line that has a highway tag. I haven't tried the patch yet (will do now) - but I think it could make this above problem worse.... On 03.05.2013 04:20, Gerd Petermann wrote:
Hi WanMil,
okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24.
Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581
I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines.
Compiled binary is here: |http://files.mkgmap.org.uk/download/119/mkgmap.jar
|Gerd
Date: Thu, 2 May 2013 20:01:32 +0200 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] merge-lines and routing
I'd like to move all calls to methods of RoadNetwork after the filter chain, but that is not that simple. I think we have to move also all the code reg. restrictions, maybe also the housenumber part.
Hi Gerd,
please don't mind about the housenumber part. I think it might be more easy to redevelop it after your changes instead of keeping the current code.
WanMil _______________________________________________ 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, good point. Up to now we treat a road different because we split it into pieces before we apply the filters. This is done to make sure that no filter eliminates parts of a road which are needed for routing. I don't understand yet in what case this might change the results of the filters, so If you see these problems with the patched version (with or without merge-lines), please send some data to reproduce the problem (I'll try as well). Also let us know if merge-lines changed anything besides the img size. Gerd Date: Fri, 3 May 2013 16:46:23 -0400 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] merge-lines and routing I have one problem with merge-lines - I often copy a road to put non routable overlays on it. Currently I think sometimes the merge-lines or some other filters are enacted on those copies - hence stuff like oneway arrows (non routable) will be having a different shape, than the underlying road. I think I would need to have all ways that have a highway=* tag excluded at 24 (or make sure that if the way is done by using a continue/continue with_actions command - either before or after - will not be processed, or processed the same way as the highway). So assuming a road with highway=tertiary & oneway=yes I create to lines (0x04 and 0x10650) 1.: oneway=yes [0x10650 resolution 24 continue] highway=tertiary [0x04 resolution 20] both ways should be processed equally, 2. highway=tertiary [0x04 resolution 20 continue] oneway=yes [0x10650 resolution 24] both ways should be processed equally again. 3. however a way with railway=line & oneway=yes oneway=yes [0x10650 resolution 24 continue] railway=line [0x10651 resolution 22 continue] should be processed, as they don't include a routable copy/origin created using continue command. Therefore I think exclude all filtering that is not done to highway=* (or other definable keys) also for any other line that has a highway tag. I haven't tried the patch yet (will do now) - but I think it could make this above problem worse.... On 03.05.2013 04:20, Gerd Petermann wrote: Hi WanMil, okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24. Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581 I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines. Compiled binary is here: http://files.mkgmap.org.uk/download/119/mkgmap.jar Gerd > Date: Thu, 2 May 2013 20:01:32 +0200 > From: wmgcnfg@web.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] merge-lines and routing > > > I'd like to move all calls to methods of RoadNetwork after the filter chain, > > but that is not that simple. I think we have to move also all the code reg. > > restrictions, maybe also the housenumber part. > > Hi Gerd, > > please don't mind about the housenumber part. I think it might be more > easy to redevelop it after your changes instead of keeping the current code. > > WanMil > _______________________________________________ > 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
Well, it doesn't happen often - and I couldn't notice a change happened due to the patch - here is a screenshot of what the problem looks like (oneway=yes arrows, created using continue - then afterwards the road you see is created) - (location - Mödling, Austria - 200m south along the rails from the Trainstation): -- the problem is that on the left road, some filter moves the arrows away from the road - as the filter is only enacted on the arrows, but not on the road... (I think though this is not merge-lines, but a reduce filter). On 04.05.2013 03:02, Gerd Petermann wrote:
Hi Felix,
good point. Up to now we treat a road different because we split it into pieces before we apply the filters. This is done to make sure that no filter eliminates parts of a road which are needed for routing. I don't understand yet in what case this might change the results of the filters, so If you see these problems with the patched version (with or without merge-lines), please send some data to reproduce the problem (I'll try as well). Also let us know if merge-lines changed anything besides the img size.
Gerd
------------------------------------------------------------------------ Date: Fri, 3 May 2013 16:46:23 -0400 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] merge-lines and routing
I have one problem with merge-lines - I often copy a road to put non routable overlays on it. Currently I think sometimes the merge-lines or some other filters are enacted on those copies - hence stuff like oneway arrows (non routable) will be having a different shape, than the underlying road.
I think I would need to have all ways that have a highway=* tag excluded at 24 (or make sure that if the way is done by using a continue/continue with_actions command - either before or after - will not be processed, or processed the same way as the highway).
So assuming a road with highway=tertiary & oneway=yes I create to lines (0x04 and 0x10650)
1.: oneway=yes [0x10650 resolution 24 continue] highway=tertiary [0x04 resolution 20]
both ways should be processed equally,
2. highway=tertiary [0x04 resolution 20 continue] oneway=yes [0x10650 resolution 24]
both ways should be processed equally again.
3. however a way with railway=line & oneway=yes oneway=yes [0x10650 resolution 24 continue] railway=line [0x10651 resolution 22 continue]
should be processed, as they don't include a routable copy/origin created using continue command.
Therefore I think exclude all filtering that is not done to highway=* (or other definable keys) also for any other line that has a highway tag. I haven't tried the patch yet (will do now) - but I think it could make this above problem worse.... On 03.05.2013 04:20, Gerd Petermann wrote:
Hi WanMil,
okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24.
Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581
I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines.
Compiled binary is here: |http://files.mkgmap.org.uk/download/119/mkgmap.jar
|Gerd
> Date: Thu, 2 May 2013 20:01:32 +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] merge-lines and routing > > > I'd like to move all calls to methods of RoadNetwork after the filter chain, > > but that is not that simple. I think we have to move also all the code reg. > > restrictions, maybe also the housenumber part. > > Hi Gerd, > > please don't mind about the housenumber part. I think it might be more > easy to redevelop it after your changes instead of keeping the current code. > > WanMil > _______________________________________________ > 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
Hi Felix, ok, so the merge-lines patch is ok. Most of the filters are disabled for resolution 24, so I have no idea why this happens. It could be an effect of the short-arc-removal process which is now only done with roads, or maybe the two ways go into different sub division, but this is a short way, so this is unlikely. I'll try to reproduce it tomorrow. Gerd Felix Hartmann-2 wrote
Well, it doesn't happen often - and I couldn't notice a change happened due to the patch - here is a screenshot of what the problem looks like (oneway=yes arrows, created using continue - then afterwards the road you see is created) - (location - Mödling, Austria - 200m south along the rails from the Trainstation): -- the problem is that on the left road, some filter moves the arrows away from the road - as the filter is only enacted on the arrows, but not on the road... (I think though this is not merge-lines, but a reduce filter).
On 04.05.2013 03:02, Gerd Petermann wrote:
Hi Felix,
good point. Up to now we treat a road different because we split it into pieces before we apply the filters. This is done to make sure that no filter eliminates parts of a road which are needed for routing. I don't understand yet in what case this might change the results of the filters, so If you see these problems with the patched version (with or without merge-lines), please send some data to reproduce the problem (I'll try as well). Also let us know if merge-lines changed anything besides the img size.
Gerd
------------------------------------------------------------------------ Date: Fri, 3 May 2013 16:46:23 -0400 From:
extremecarver@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] merge-lines and routing
I have one problem with merge-lines - I often copy a road to put non routable overlays on it. Currently I think sometimes the merge-lines or some other filters are enacted on those copies - hence stuff like oneway arrows (non routable) will be having a different shape, than the underlying road.
I think I would need to have all ways that have a highway=* tag excluded at 24 (or make sure that if the way is done by using a continue/continue with_actions command - either before or after - will not be processed, or processed the same way as the highway).
So assuming a road with highway=tertiary & oneway=yes I create to lines (0x04 and 0x10650)
1.: oneway=yes [0x10650 resolution 24 continue] highway=tertiary [0x04 resolution 20]
both ways should be processed equally,
2. highway=tertiary [0x04 resolution 20 continue] oneway=yes [0x10650 resolution 24]
both ways should be processed equally again.
3. however a way with railway=line & oneway=yes oneway=yes [0x10650 resolution 24 continue] railway=line [0x10651 resolution 22 continue]
should be processed, as they don't include a routable copy/origin created using continue command.
Therefore I think exclude all filtering that is not done to highway=* (or other definable keys) also for any other line that has a highway tag. I haven't tried the patch yet (will do now) - but I think it could make this above problem worse.... On 03.05.2013 04:20, Gerd Petermann wrote:
Hi WanMil,
okay, this will be a big change that requires a branch. So, for now, I'd like to finish the merge-lines issue. Attached is version 2 of the patch that allows merging lines at all resolutuions except for roads on res 24.
Some numbers for a map of niedersachsen with default style and lots of enabled features: (seconds run time, gmapsupp.img size in bytes) r2581 with merge-lines: 99s, 127.567.872 r2581 with no-merge-lines: 103s, 128.182.272 patched r2585 with merge-lines: 95s, 125.599.744 patched r2585 with no-merge-lines: like r2581
I see no good reason why merge-lines is an option. I think we should enable it and remove the parm, or at least, make merge-lines the default and allow to switch it off with --no-merge-lines.
Compiled binary is here: |http://files.mkgmap.org.uk/download/119/mkgmap.jar
|Gerd
> Date: Thu, 2 May 2013 20:01:32 +0200 > From:
wmgcnfg@
<mailto:
wmgcnfg@
>
> To:
mkgmap-dev@.org
<mailto:
mkgmap-dev@.org
>
> Subject: Re: [mkgmap-dev] merge-lines and routing > > > I'd like to move all calls to methods of RoadNetwork after the filter chain, > > but that is not that simple. I think we have to move also all the code reg. > > restrictions, maybe also the housenumber part. > > Hi Gerd, > > please don't mind about the housenumber part. I think it might be more > easy to redevelop it after your changes instead of keeping the current code. > > WanMil > _______________________________________________ > 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
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
oneway_arrows_shifted.png (31K) <http://gis.19327.n5.nabble.com/attachment/5759595/0/oneway_arrows_shifted.pn...;
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759611.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, I got no more warnings about routing-problems to stderr with this version. Thanks! Henning
On 28.04.2013 16:30, WanMil wrote:
My understanding is that routing is also done with the data of lower resolutions, e.g. for long distance routing, but my patch below is probably too simple, as it doesn't care about CoordNode. If that's the case and lower resolutions are used for routing I am quite sure that the merge-lines filter (and some other filters too) are doing harm.
I am pretty sure, that routing is only done at the lowest resolution. This doesn't have to be 24 - (but using mkgmap it actually has to be 24 - Garmin City Navigator uses resolution 23). Maybe confusion is caused by routable basemaps? I would think for them the same principle of routing only using the lowest resolution/level is true. In any case, if the above were true, then there would need to be routing information added too all levels - which I cannot really believe that Garmin would do it...
Felix Hartmann-2 wrote
I am pretty sure, that routing is only done at the lowest resolution. This doesn't have to be 24 - (but using mkgmap it actually has to be 24 - Garmin City Navigator uses resolution 23).
yes, I think mkgmap is fixed on 24, but many places in the source code don't check for res==24, but level==0, that makes it difficult to understand. Felix Hartmann-2 wrote
Maybe confusion is caused by routable basemaps?
yes, maybe the informations that I found while working on the overview map confused me. I like to find out if and how this can be used for routing, that's why I got stuck in the overview2 branch. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759073.htm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 30.04.2013 00:04, GerdP wrote:
Felix Hartmann-2 wrote
I am pretty sure, that routing is only done at the lowest resolution. This doesn't have to be 24 - (but using mkgmap it actually has to be 24 - Garmin City Navigator uses resolution 23). yes, I think mkgmap is fixed on 24, but many places in the source code don't check for res==24, but level==0, that makes it difficult to understand.
Felix Hartmann-2 wrote
Maybe confusion is caused by routable basemaps? yes, maybe the informations that I found while working on the overview map confused me. I like to find out if and how this can be used for routing, that's why I got stuck in the overview2 branch.
Gerd I just checked the overview map of City Navigator. You're right it is routable (only at level 0 of course). So maybe Basecamp/Mapsource use it for long distance routing. However there is basically not much in them that is routable.
Highways are universally road_class=4, road_speed=6, important primary rods are road_class=2, road_speed=4 and less important primary roads --> especially those that are "dead-end" on the overview map, are road_class=1, road_speed=3. Some trunk roads --> (Schnellstraßen) especially in Germany are road_class=3, road_speed=5. The speeds / classes on the primary roads, don't necessarily correspond with the speed/class in the actual map. I don't really know though, if OSM material is of any use for creating such a routable basemap/overview map. The oveview map of City Navigator is very generalized. Highways are not entered for each direction as oneway, but as twoway streeets. So we would need to get some non OSM generalized map data - in order to create a working routable basemap. I would say that getting several map layers into the overview map, should be implemented first. Of course also for Overviewmaps, ONLY the level=0 is routable, just like for normal map images. Additional levels aren't routable. Then at some point we might need to move to static basemap content, based on either super simplified OSM, or based of some other databases...
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759073.htm... 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, thanks for the info. I agree that a routable overview map has not the highest priority. Reg. multiple levels: I'll try again on the weekend. Gerd
Date: Tue, 30 Apr 2013 10:03:14 -0400 From: extremecarver@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] merge-lines and routing
On 30.04.2013 00:04, GerdP wrote:
Felix Hartmann-2 wrote
I am pretty sure, that routing is only done at the lowest resolution. This doesn't have to be 24 - (but using mkgmap it actually has to be 24 - Garmin City Navigator uses resolution 23). yes, I think mkgmap is fixed on 24, but many places in the source code don't check for res==24, but level==0, that makes it difficult to understand.
Felix Hartmann-2 wrote
Maybe confusion is caused by routable basemaps? yes, maybe the informations that I found while working on the overview map confused me. I like to find out if and how this can be used for routing, that's why I got stuck in the overview2 branch.
Gerd I just checked the overview map of City Navigator. You're right it is routable (only at level 0 of course). So maybe Basecamp/Mapsource use it for long distance routing. However there is basically not much in them that is routable.
Highways are universally road_class=4, road_speed=6, important primary rods are road_class=2, road_speed=4 and less important primary roads --> especially those that are "dead-end" on the overview map, are road_class=1, road_speed=3. Some trunk roads --> (Schnellstraßen) especially in Germany are road_class=3, road_speed=5.
The speeds / classes on the primary roads, don't necessarily correspond with the speed/class in the actual map. I don't really know though, if OSM material is of any use for creating such a routable basemap/overview map. The oveview map of City Navigator is very generalized. Highways are not entered for each direction as oneway, but as twoway streeets.
So we would need to get some non OSM generalized map data - in order to create a working routable basemap.
I would say that getting several map layers into the overview map, should be implemented first. Of course also for Overviewmaps, ONLY the level=0 is routable, just like for normal map images. Additional levels aren't routable. Then at some point we might need to move to static basemap content, based on either super simplified OSM, or based of some other databases...
-- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913p5759073.htm... 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
-
Henning Scholland -
WanMil