[patch v1] link-pois-to-ways and restrictions
Hi all, attached is a patch that changes the handling of option --link-pois-to-ways. In trunk, this option has two effects: 1) If a POI with a tag like access=mkgmap:road-speed=1 (e.g. highway=traffic-lights) is found in a way, the way is split at the preceding and following point and the change is applied to the remaining part. The length of the effected part depends only on the distance to the next point. If the way is straight, that can be > 300m, if the POI is in an a curve, it might be < 10m. 2) If a POI with a tag like mkgmap:bicycle=no (e.g. barrier=bollard) is found in a way, splits the way and before and after the POI so that the length of the affected way segment is typically less 100m. (max 50m before + max. 50m after the POI) Next, the way is split again at the POI, so that routing over the POI is not done for the restricted vehicles. The effect is that routing to a point close to the POI might not work (don't know that for sure, the device might ignore the restriction if the target cannot be reached "legally"). I think the wanted behaviour is this: 1) The change in speed should be applied to max. 25m before and after the POI or to the connection with another way, whatever comes first. 2) A POI like a barrier should not change access to the way before or after the POI, only at the POI. The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions. The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default. If I hear no complains, I'll commit that next sunday. Gerd
Am 23.12.2013 12:22, schrieb Gerd Petermann:
1) If a POI with a tag like access=mkgmap:road-speed=1
???
The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions.
What do you mean with "route restrictions" ? Greetings Chris
Hi Chris,
To: mkgmap-dev@lists.mkgmap.org.uk From: chris66nrw@gmx.de Date: Mon, 23 Dec 2013 13:20:00 +0100 Subject: Re: [mkgmap-dev] [patch v1] link-pois-to-ways and restrictions
Am 23.12.2013 12:22, schrieb Gerd Petermann:
1) If a POI with a tag like access=mkgmap:road-speed=1
??? The default style points file assigns this for some barrier=*
The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions.
What do you mean with "route restrictions" ?
sorry, a route restriction is the internal name for it. These route restriction are created for restriction relations like http://wiki.openstreetmap.org/wiki/Relation:restriction Gerd
Am 23.12.2013 15:15, schrieb Gerd Petermann:
What do you mean with "route restrictions" ?
sorry, a route restriction is the internal name for it. These route restriction are created for restriction relations like http://wiki.openstreetmap.org/wiki/Relation:restriction
Ah ok so you mean turn-restrictions. What is the advantage for implementing the point-barriers this way? Chris
Am 24.12.2013 09:40, schrieb chris66:
Am 23.12.2013 15:15, schrieb Gerd Petermann:
What do you mean with "route restrictions" ?
sorry, a route restriction is the internal name for it. These route restriction are created for restriction relations like http://wiki.openstreetmap.org/wiki/Relation:restriction
Ah ok so you mean turn-restrictions. What is the advantage for implementing the point-barriers this way?
Hi Chris Think about a POI you want to route to. The road passing this POI has a barrier in front of the POI and with old implementation the passing road will be avoided for eg. 100m Maybe there is another road passing the other POI-side (without entrance), which passes the POI in 80m. So Garmin will route you to a point of the useless side of the POI, just because it's closer. With new implementation you will be routed to the passing road and routing will stop at the barrier. Henning
Chris66 wrote
Am 23.12.2013 15:15, schrieb Gerd Petermann:
What do you mean with "route restrictions" ?
sorry, a route restriction is the internal name for it. These route restriction are created for restriction relations like http://wiki.openstreetmap.org/wiki/Relation:restriction
Ah ok so you mean turn-restrictions. What is the advantage for implementing the point-barriers this way?
I think the major advantage is that the way is split into fewer parts, and that typically improves routing. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 24.12.2013 11:14, schrieb GerdP:
I think the major advantage is that the way is split into fewer parts, and that typically improves routing.
Hi, I see one possible regression: I believe that turn-restrictions are more strict than normal restrictions. Example: A dead end service road to a private property with a gate in the mid. Gate-Node is tagged with access=private. I guess that Garmin is able to route to the property in the old implementation (access=private is ignored because there is no other way to destination) and is not able to route with the new implementation, but that's just a guess. Didn't test it. Chris
Hi Chris, I'll try to create a test case for that to find out. Gerd Chris66 wrote
Am 24.12.2013 11:14, schrieb GerdP:
I think the major advantage is that the way is split into fewer parts, and that typically improves routing.
Hi, I see one possible regression:
I believe that turn-restrictions are more strict than normal restrictions.
Example: A dead end service road to a private property with a gate in the mid. Gate-Node is tagged with access=private.
I guess that Garmin is able to route to the property in the old implementation (access=private is ignored because there is no other way to destination) and is not able to route with the new implementation, but that's just a guess. Didn't test it.
Chris
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
I think the wanted behaviour is this: 1) The change in speed should be applied to max. 25m before and after the POI or to the connection with another way, whatever comes first. 2) A POI like a barrier should not change access to the way before or after the POI, only at the POI.
The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions.
I've tested part 2) of the patch and it worked fine for me!
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
If I hear no complains, I'll commit that next sunday.
I propose to move the link-pois-to-ways handling before merging roads. Do you think it's complicated to move it? WanMil
Hi WanMil,
I think the wanted behaviour is this: 1) The change in speed should be applied to max. 25m before and after the POI or to the connection with another way, whatever comes first. 2) A POI like a barrier should not change access to the way before or after the POI, only at the POI.
The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions.
I've tested part 2) of the patch and it worked fine for me!
well, I think that means that part 1) is not yet working. I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
If I hear no complains, I'll commit that next sunday.
I propose to move the link-pois-to-ways handling before merging roads. Do you think it's complicated to move it?
Ahh, I forgot about this. I got a cold last weekend, so I'm not able to concentrate very well. If I got this right, it should work if we add new instances to roads and roadTypes for each part of the way, maybe with a fake id. Not sure if it will reduce the number of roads, I think more important is to fix the above problem. Gerd
Hi Gerd,
Hi WanMil,
I think the wanted behaviour is this: 1) The change in speed should be applied to max. 25m before and after the POI or to the connection with another way, whatever comes first. 2) A POI like a barrier should not change access to the way before or after the POI, only at the POI.
The attached patch implements this changed behaviour. The type 2) POI are converted to route restrictions.
I've tested part 2) of the patch and it worked fine for me!
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work. I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; } But the road speed of ways with barrier=bollard does not seem to be changed.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions?
If I hear no complains, I'll commit that next sunday.
I propose to move the link-pois-to-ways handling before merging roads. Do you think it's complicated to move it?
Ahh, I forgot about this. I got a cold last weekend, so I'm not able to concentrate very well.
Get well soon!
If I got this right, it should work if we add new instances to roads and roadTypes for each part of the way, maybe with a fake id. Not sure if it will reduce the number of roads, I think more important is to fix the above problem.
I aggree. WanMil
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions?
The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C Gerd
Hi WanMil,
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
I checked all commits back to r2851 from Dec 1st but didn't find the point you are addressing. Can you please also check which commit do you mean?
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions?
The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
Ah, that's a funny bit coding within the Garmin format....
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, with r2790 you moved the code to evaluate mkgmap:road-speed from addRoadWithoutLoops() to postConvertRules(). Gerd WanMil wrote
Hi WanMil,
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
I checked all commits back to r2851 from Dec 1st but didn't find the point you are addressing.
Can you please also check which commit do you mean?
The patch also changes the meaning of route restrictions. In r2907 and before, route restrictions prohibit access for pedestrians and emergency, the patched version allows them by default.
Does that mean a common turn restriction from a=>b also means that pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency
is
implemented different to the other exceptions? The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
Ah, that's a funny bit coding within the Garmin format....
Gerd
_______________________________________________ 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/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil, it is probably better to change the POI code so that it creates modified copies of the corresponding GType instance instead of adding tags. The code adds a tag like mkgmap:road-speed=-1 to the a part of the way, but that is not evaluated later. Before r2790, the tag was evaluated, but the code did not verify whether the way already contained the same key with maybe mkgmap:road-speed=+2. I'll try to fix it tomorrow. Gerd GerdP wrote
Hi WanMil,
with r2790 you moved the code to evaluate mkgmap:road-speed from addRoadWithoutLoops() to postConvertRules().
Gerd WanMil wrote
Hi WanMil,
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
I checked all commits back to r2851 from Dec 1st but didn't find the point you are addressing.
Can you please also check which commit do you mean?
> > The patch also changes the meaning of route restrictions. > In r2907 and before, route restrictions prohibit access for > pedestrians and emergency, the patched version > allows them by default.
Does that mean a common turn restriction from a=>b also means
that
pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions? The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
Ah, that's a funny bit coding within the Garmin format....
Gerd
_______________________________________________ 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/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, r2790 is quite old. I have tested the link-pois-to-ways code at some time after that but maybe I did check access restrictions only. The change was intended to implement the calculation at one point only. The main idea is, that there is a clear distinction between code before postConvertRules() and after that. Code before postConvertRules() can use (and has to implement) several more tags than after postConvertRules(). I get the feeling that it might be easier to move the handling of the link-pois-to-ways to an earlier point in the processing. The current code is quite complicated. Maybe it could be moved after processing the points style file and just before processing the lines and polygons style file. At this point modifications might be possible on the OSM way data like we do before the style processing is started (e.g. LinkDestinationHook). If you want to leave the code where it is I would recommend to put the mkgmap:road-speed calcs etc. to separate methods so that they can be called from postConvertRules() and the pois handling. That also encapsulates these tags. WanMil
Hi WanMil,
it is probably better to change the POI code so that it creates modified copies of the corresponding GType instance instead of adding tags. The code adds a tag like mkgmap:road-speed=-1 to the a part of the way, but that is not evaluated later. Before r2790, the tag was evaluated, but the code did not verify whether the way already contained the same key with maybe mkgmap:road-speed=+2. I'll try to fix it tomorrow.
Gerd
GerdP wrote
Hi WanMil,
with r2790 you moved the code to evaluate mkgmap:road-speed from addRoadWithoutLoops() to postConvertRules().
Gerd WanMil wrote
Hi WanMil,
well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
I am not sure, but I think you moved the evaluation of the tags mkgmap:road-speed and mkgmap:road-class so that the interpretation of the POI has no effect. Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
I checked all commits back to r2851 from Dec 1st but didn't find the point you are addressing.
Can you please also check which commit do you mean?
> > > > > > The patch also changes the meaning of route restrictions. > > In r2907 and before, route restrictions prohibit access for > > pedestrians and emergency, the patched version > > allows them by default. > > Does that mean a common turn restriction from a=>b also means
that
> pedestrians never can route a=>b?
yes, in trunk all turn restrictions are created without an exception for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions? The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
Ah, that's a funny bit coding within the Garmin format....
Gerd
_______________________________________________ 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/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil,
r2790 is quite old. I have tested the link-pois-to-ways code at some time after that but maybe I did check access restrictions only. The change was intended to implement the calculation at one point only. The main idea is, that there is a clear distinction between code before postConvertRules() and after that. Code before postConvertRules() can use (and has to implement) several more tags than after postConvertRules().
okay
I get the feeling that it might be easier to move the handling of the link-pois-to-ways to an earlier point in the processing. The current code is quite complicated. Maybe it could be moved after processing the points style file and just before processing the lines and polygons style file. At this point modifications might be possible on the OSM way data like we do before the style processing is started (e.g. LinkDestinationHook).
I think we have to process the lines style first, because we need to know the access tags and road speed and road class.
If you want to leave the code where it is I would recommend to put the mkgmap:road-speed calcs etc. to separate methods so that they can be called from postConvertRules() and the pois handling. That also encapsulates these tags.
I prefer to create a modified copy of the GType instance. I have to find out why it was not done like this all the time. An old comment for the POI handling in StyledConverter says: // we can't modify the road class or type in // the GType as that's global so for now just // transfer the tags to the way Gerd
Hi WanMil, attached is a patch for r2914. It fixes the problem with --link-poi-to-ways that was introduced with r2790 in the branch. With this patch the option should again work like in trunk r2889. If you think it is okay please commit it and I'll post a 2nd version of the link-pois-to-ways patch later. Gerd
Date: Fri, 27 Dec 2013 21:42:59 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] [patch v1] link-pois-to-ways and restrictions
Hi Gerd,
r2790 is quite old. I have tested the link-pois-to-ways code at some time after that but maybe I did check access restrictions only. The change was intended to implement the calculation at one point only. The main idea is, that there is a clear distinction between code before postConvertRules() and after that. Code before postConvertRules() can use (and has to implement) several more tags than after postConvertRules().
I get the feeling that it might be easier to move the handling of the link-pois-to-ways to an earlier point in the processing. The current code is quite complicated. Maybe it could be moved after processing the points style file and just before processing the lines and polygons style file. At this point modifications might be possible on the OSM way data like we do before the style processing is started (e.g. LinkDestinationHook).
If you want to leave the code where it is I would recommend to put the mkgmap:road-speed calcs etc. to separate methods so that they can be called from postConvertRules() and the pois handling. That also encapsulates these tags.
WanMil
Hi WanMil,
it is probably better to change the POI code so that it creates modified copies of the corresponding GType instance instead of adding tags. The code adds a tag like mkgmap:road-speed=-1 to the a part of the way, but that is not evaluated later. Before r2790, the tag was evaluated, but the code did not verify whether the way already contained the same key with maybe mkgmap:road-speed=+2. I'll try to fix it tomorrow.
Gerd
GerdP wrote
Hi WanMil,
with r2790 you moved the code to evaluate mkgmap:road-speed from addRoadWithoutLoops() to postConvertRules().
Gerd WanMil wrote
Hi WanMil,
> well, I think that means that part 1) is not yet working.
No, I really only tested part 2), so I tested barriers only. Now I've tested part 1) also but it does not seem to work.
I've changed the rule in the points file to barrier=bollard | barrier=cycle_barrier { set mkgmap:road-speed=0; }
But the road speed of ways with barrier=bollard does not seem to be changed. yes, neither the patched version nor trunk do work.
> I am not sure, but I think you moved the evaluation of the > tags mkgmap:road-speed and mkgmap:road-class > so that the interpretation of the POI has no effect. > Was that intended?
I don't understand. Which commit do you mean? Your patch is for r2907 and I don't think that there was any change after that?
I meant the change in the branch. The tag is now only evaluated in postConvertRules(), and that is called before the POI evaluation.
I checked all commits back to r2851 from Dec 1st but didn't find the point you are addressing.
Can you please also check which commit do you mean?
> > > > > > > > > > > The patch also changes the meaning of route restrictions. > > > In r2907 and before, route restrictions prohibit access for > > > pedestrians and emergency, the patched version > > > allows them by default. > > > > Does that mean a common turn restriction from a=>b also means
that
> > pedestrians never can route a=>b? > > yes, in trunk all turn restrictions are created without an exception > for pedestrians or emergency.
Funny bug. I wonder why the exceptions for pedestrians and emergency is implemented different to the other exceptions? The bits are coded at a different place, see wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format#Table_C
Ah, that's a funny bit coding within the Garmin format....
Gerd
_______________________________________________ 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/patch-v1-link-pois-to-ways-and-restrictions-t... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
chris66 -
Gerd Petermann -
GerdP
-
Henning Scholland -
WanMil