Hi all, I've committed r239 now. - r237 and r238 fixed o5m read and write issues r239: - don't calculate bbox for all ways of a multipolygon rel, instead try to find closed polygons and calculate the bbox for each polygon. - don't treat type=boundariy relation like multipolygon Relation - add --output=simulate for testing, this allows to run the split process without writing the OSM output files. - make output better readable I think the --keep-complete is now working good enough, please let me know if anything is wrong or missing. Next on my todo list: - add/complete javadoc - update the doc file intro.txt - add o5m support to mkgmap - make sea generator compatible with new osmwriter interface - try to use thread(s) for the OSM reader - try to calculate reasonable value for max-areas based on available heap, number of tiles and file size -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 19.11.2012 17:23, schrieb GerdP:
Hi all,
I've committed r239 now. - r237 and r238 fixed o5m read and write issues r239: - don't calculate bbox for all ways of a multipolygon rel, instead try to find closed polygons and calculate the bbox for each polygon. - don't treat type=boundariy relation like multipolygon Relation - add --output=simulate for testing, this allows to run the split process without writing the OSM output files. - make output better readable Hi Gerd, things might be to do for RC:
add --keep-complete=<filename of problematic polygons list> and write a list of problematic polygons to the given filename. --keep-complete shouldn't generate such a list --write-kml create a kml-file with all areas in a folder, planet-partition-1 in a folder and planet-partition-2 in a folder, if --keep-complete isn't set, only write areas Henning
- try to calculate reasonable value for max-areas based on available heap, number of tiles and file size Cant we use the size of the *.img in gmapsupp for finetune the splitting areas ? Depending on the kind of style-sheat and the data splitting areas with the same size of nodes is not perfect. Dirk
Hello Dirk, flabot@googlemail.com wrote
- try to calculate reasonable value for max-areas based on available heap, number of tiles and file size
Cant we use the size of the *.img in gmapsupp for finetune the splitting areas ? Depending on the kind of style-sheat and the data splitting areas with the same size of nodes is not perfect.
Hmm, this is a completely different problem. The default value 255 for the max-areas parameter is typically too small, as a result, the program reads the input file many times, even if heap would allow e.g. 1024 areas. You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736447.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information?
Gerd
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
Dirk -- Sent from Gmail Mobile
flabot@googlemail.com wrote
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
OK, I think I understand. What could be the goal of the optimization process? I assume you want to reduce the number of tiles? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736511.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am Dienstag, 20. November 2012 schrieb GerdP :
flabot@googlemail.com <javascript:;> wrote
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
OK, I think I understand. What could be the goal of the optimization process? I assume you want to reduce the number of tiles?
Nö but make the mkgmap tile about the Same size nö matter whats in the tiles
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736511.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <javascript:;> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Sent from Gmail Mobile
Am 19.11.2012 23:53, schrieb flabot@googlemail.com:
You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information?
Gerd
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
I don't know if this is useful at all. Because you/splitter don't know about dispersion of the nodes. For example take a two tiles who separate Berlin in two parts. Both tiles would have capacity of some more nodes. But if you enlarge the southern tile a little bit to north, you may get problems. Maybe it would be more helpful to output a list of percentage of used nodes in a tile. So you now, that you can increase --max-nodes. Henning
I dont Wang to modify only One area. Of you make the South of Berlin Birger you have to fix the enges of the Otter tiles a Bit. Only Fine-tune. But Doping this from Time to Time so get a Slow move of the areas and get tiles of about the Same size in mkgmap Output You want get Obersize tiles. Dirk Am Dienstag, 20. November 2012 schrieb Henning Scholland :
Am 19.11.2012 23:53, schrieb flabot@googlemail.com <javascript:_e({}, 'cvml', 'flabot@googlemail.com');>:
You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information?
Gerd
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
I don't know if this is useful at all. Because you/splitter don't know about dispersion of the nodes. For example take a two tiles who separate Berlin in two parts. Both tiles would have capacity of some more nodes. But if you enlarge the southern tile a little bit to north, you may get problems.
Maybe it would be more helpful to output a list of percentage of used nodes in a tile. So you now, that you can increase --max-nodes.
Henning
-- Sent from Gmail Mobile
Hello Dirk, seems you have a german spell checker active ;-) I still don't understand what the problem is. Why do you want equally sized tiles? Doesn't that mean you would prefer many small tiles? Ciao, Gerd Date: Tue, 20 Nov 2012 11:12:31 +0100 From: flabot@googlemail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r239 I dont Wang to modify only One area. Of you make the South of Berlin Birger you have to fix the enges of the Otter tiles a Bit. Only Fine-tune. But Doping this from Time to Time so get a Slow move of the areas and get tiles of about the Same size in mkgmap Output You want get Obersize tiles. Dirk Am Dienstag, 20. November 2012 schrieb Henning Scholland : Am 19.11.2012 23:53, schrieb flabot@googlemail.com: You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information? Gerd Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter. I don't know if this is useful at all. Because you/splitter don't know about dispersion of the nodes. For example take a two tiles who separate Berlin in two parts. Both tiles would have capacity of some more nodes. But if you enlarge the southern tile a little bit to north, you may get problems. Maybe it would be more helpful to output a list of percentage of used nodes in a tile. So you now, that you can increase --max-nodes. Henning -- Sent from Gmail Mobile _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Well, split France and then I think it is obvious, why there are problems (especially as if you choose a low maxnodes value for france, you still produce maps that crash Garmin GPS devices, once installed/active)... On 20.11.2012 14:23, Gerd Petermann wrote:
Hello Dirk,
seems you have a german spell checker active ;-)
I still don't understand what the problem is. Why do you want equally sized tiles? Doesn't that mean you would prefer many small tiles?
Ciao, Gerd
------------------------------------------------------------------------ Date: Tue, 20 Nov 2012 11:12:31 +0100 From: flabot@googlemail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter r239
I dont Wang to modify only One area. Of you make the South of Berlin Birger you have to fix the enges of the Otter tiles a Bit. Only Fine-tune. But Doping this from Time to Time so get a Slow move of the areas and get tiles of about the Same size in mkgmap Output You want get Obersize tiles.
Dirk
Am Dienstag, 20. November 2012 schrieb Henning Scholland :
Am 19.11.2012 23:53, schrieb flabot@googlemail.com:
You describe an algorithm that uses the result of mkgmap processing to "optimize" the position or size of the tiles. Can you describe more detailed what splitter should do with this information?
Gerd
Mkgmap can Output a List of the size of Evelyn tile. In the next Splitter Run Splitter have the Output of mkgmap an an Areas.list. So there Splitter can Take the Old Areas.list with the mkgmap Output an perhaps the input-osm-Data and Fine-tune the area-List. But this should be an option in splitter.
I don't know if this is useful at all. Because you/splitter don't know about dispersion of the nodes. For example take a two tiles who separate Berlin in two parts. Both tiles would have capacity of some more nodes. But if you enlarge the southern tile a little bit to north, you may get problems.
Maybe it would be more helpful to output a list of percentage of used nodes in a tile. So you now, that you can increase --max-nodes.
Henning
-- Sent from Gmail Mobile
_______________________________________________ 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
Well, split France and then I think it is obvious, why there are problems (especially as if you choose a low maxnodes value for france, you still produce maps that crash Garmin GPS devices, once installed/active)...
Well, I don't want to crash my GPS ;-) If I split france (an older extract) with maxnodes=1000000 I see messages like this: Area (43.5498046875,1.23046875) to (43.7255859375,1.40625) contains 1.013.349 nodes but can't be split further Is that the obvious problem you are talking about? If I got this right, you have to use a higher resolution to fix that (with my extract, resolution=14 was enough. I don't know what you have to change in mkgmap settings to work with that. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736622.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
The problem are tiles with loads of nodes, that are not used by default style (or I think virtually most styles, except maybe openseemap). So you end up with mkgmap rendering 1 or 2 tiles, with say 10 nodes only (if at all). On 20.11.2012 16:21, GerdP wrote:
Felix Hartmann-2 wrote
Well, split France and then I think it is obvious, why there are problems (especially as if you choose a low maxnodes value for france, you still produce maps that crash Garmin GPS devices, once installed/active)... Well, I don't want to crash my GPS ;-) If I split france (an older extract) with maxnodes=1000000 I see messages like this: Area (43.5498046875,1.23046875) to (43.7255859375,1.40625) contains 1.013.349 nodes but can't be split further
Is that the obvious problem you are talking about? If I got this right, you have to use a higher resolution to fix that (with my extract, resolution=14 was enough. I don't know what you have to change in mkgmap settings to work with that.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736622.html 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
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Hello Felix, ok, I think I understand the problem. Did you try using something like osmfilter to delete data which is not needed before using splitter? Would that be an option? Gerd Felix Hartmann-2 wrote
The problem are tiles with loads of nodes, that are not used by default style (or I think virtually most styles, except maybe openseemap). So you end up with mkgmap rendering 1 or 2 tiles, with say 10 nodes only (if at all). On 20.11.2012 16:21, GerdP wrote:
Felix Hartmann-2 wrote
Well, split France and then I think it is obvious, why there are problems (especially as if you choose a low maxnodes value for france, you still produce maps that crash Garmin GPS devices, once installed/active)... Well, I don't want to crash my GPS ;-) If I split france (an older extract) with maxnodes=1000000 I see messages like this: Area (43.5498046875,1.23046875) to (43.7255859375,1.40625) contains 1.013.349 nodes but can't be split further
Is that the obvious problem you are talking about? If I got this right, you have to use a higher resolution to fix that (with my extract, resolution=14 was enough. I don't know what you have to change in mkgmap settings to work with that.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736622.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736738.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
If there is a Way to autofilter per style_sheat ... Yes But That is nö way Am Mittwoch, 21. November 2012 schrieb GerdP :
Hello Felix,
ok, I think I understand the problem. Did you try using something like osmfilter to delete data which is not needed before using splitter? Would that be an option?
Gerd
Felix Hartmann-2 wrote
The problem are tiles with loads of nodes, that are not used by default style (or I think virtually most styles, except maybe openseemap). So you end up with mkgmap rendering 1 or 2 tiles, with say 10 nodes only (if at all). On 20.11.2012 16:21, GerdP wrote:
Felix Hartmann-2 wrote
Well, split France and then I think it is obvious, why there are problems (especially as if you choose a low maxnodes value for france, you still produce maps that crash Garmin GPS devices, once installed/active)... Well, I don't want to crash my GPS ;-) If I split france (an older extract) with maxnodes=1000000 I see messages like this: Area (43.5498046875,1.23046875) to (43.7255859375,1.40625) contains 1.013.349 nodes but can't be split further
Is that the obvious problem you are talking about? If I got this right, you have to use a higher resolution to fix that (with my extract, resolution=14 was enough. I don't know what you have to change in mkgmap settings to work with that.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736622.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- keep on biking and discovering new trails
Felix openmtbmap.org & www.velomap.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736738.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <javascript:;> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Sent from Gmail Mobile
No, The main reason being, that in long run that would probably mean to prefilter all data based on per country defined criteria - meaning a lot of work. Even though for /la merdique OSM de France/ -- the french import massacre, maybe in future it will be the only solution. Even though I don't yet really know, what I should cut out via osmfilter... On 21.11.2012 07:57, GerdP wrote:
Hello Felix,
ok, I think I understand the problem. Did you try using something like osmfilter to delete data which is not needed before using splitter? Would that be an option?
Gerd
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Felix Hartmann-2 wrote
No, The main reason being, that in long run that would probably mean to prefilter all data based on per country defined criteria - meaning a lot of work.
Even though for /la merdique OSM de France/ -- the french import massacre, maybe in future it will be the only solution. Even though I don't yet really know, what I should cut out via osmfilter... On 21.11.2012 07:57, GerdP wrote:
OK, today I started to collect some information regarding the algorithm that is used in splitter. Just to make sure that I understand the problem with france extract: 1) a few tiles (covering parts of the atlantic) contain very few nodes (less than 200) 2) other tiles containing Paris have too many nodes if you use --max-nodes=1000000 The goal would be to create the tiles so that none has less than x nodes (maybe 10% of max-nodes?) and none has more than <max-nodes> nodes. Also, we prefer tiles with small aspect ratio. Correct? Optionally, we might calculate some kind of correction factor using the output of mkgmap. Maybe it will be sufficient to have the file sizes of input and output files and the areas.list of a former splitter run. Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736854.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Henning, I fear I don't understand what you mean.
add --keep-complete=<filename of problematic polygons list> and write a list of problematic polygons to the given filename. --keep-complete shouldn't generate such a list
Do you mean that splitter should generate the list only if the user gives a name (path) for it?
--write-kml create a kml-file with all areas in a folder, planet-partition-1 in a folder and planet-partition-2 in a folder, if --keep-complete isn't set, only write areas
These planet-xxx files are only meant for debugging. I think we can completely drop the creation. Or do you plan to use it for something else? Ciao, Gerd
Henning
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 19.11.2012 20:22, schrieb Gerd Petermann:
Hi Henning,
I fear I don't understand what you mean.
add --keep-complete=<filename of problematic polygons list> and write a list of problematic polygons to the given filename. --keep-complete shouldn't generate such a list
Do you mean that splitter should generate the list only if the user gives a name (path) for it? Yes and only one list with all problematic objects.
--write-kml create a kml-file with all areas in a folder, planet-partition-1 in a folder and planet-partition-2 in a folder, if --keep-complete isn't set, only write areas
These planet-xxx files are only meant for debugging. I think we can completely drop the creation. Or do you plan to use it for something else? No, only for debugging. Could also be removed completly.
Henning btw: http://www.aighes.de/data/mkgmap.zip with output of 239
Henning Scholland wrote
Do you mean that splitter should generate the list only if the user gives a name (path) for it? Yes and only one list with all problematic objects.
OK, I agree that we need only one list. Should splitter try to add a name for each object so that we see something like way:101580 # Rue Docteur Bordier .... rel:47796 # Netherlands This would blow up the file and increase run time a little bit, but could be done when splitter runs the MultiTileProcessor. Another possibly interesting information would be to know why the object is a problem case. We have two very different cases: a) a polygon crosses two or more tiles b) a polygon leaves a tile, and no other tile contains the outer nodes I think this is also what Chris would like to know when we looks at the "way x is missing y nodes" messages. Henning Scholland wrote
These planet-xxx files are only meant for debugging. I think we can completely drop the creation. Or do you plan to use it for something else? No, only for debugging. Could also be removed completly.
OK, I comment the lines that produce the planet-xxx files. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736512.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Chris, this message appears if a way that is in the problem list is not complete. It just means that splitter cannot "keep-complete" this way because the input is already not complete. It is hard to say if that is important for you ;-) Splitter writes these ways no matter how many nodes are missing (if not all of them) My intention with this message is: If you find that a way is missing in the map, you should first check if splitter complained with such a message. Gerd
To: mkgmap-dev@lists.mkgmap.org.uk From: chris66nrw@gmx.de Date: Mon, 19 Nov 2012 20:06:34 +0100 Subject: Re: [mkgmap-dev] splitter r239
Am 19.11.2012 17:23, schrieb GerdP:
Hi all,
I've committed r239 now.
Hi Gerd,
I get many error messages:
Sorry, way x is missing y node(s).
Can they be ignored ?
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am 19.11.2012 20:17, schrieb Gerd Petermann:
Hi Chris,
this message appears if a way that is in the problem list is not complete. It just means that splitter cannot "keep-complete" this way because the input is already not complete. It is hard to say if that is important for you ;-) Splitter writes these ways no matter how many nodes are missing (if not all of them)
My intention with this message is: If you find that a way is missing in the map, you should first check if splitter complained with such a message. The problem is, that the complete way isn't rendered, if only one node is missing. I don't know if it would be good, if mkgmap skip missing nodes. It could course other problems.
Henning
Henning Scholland wrote
My intention with this message is: If you find that a way is missing in the map, you should first check if splitter complained with such a message. The problem is, that the complete way isn't rendered, if only one node is missing. I don't know if it would be good, if mkgmap skip missing nodes. It could course other problems.
Really? I was not aware of this. I thought that mkgmap requires only those points that fall into the bbox saved with the tile (the one that has overlap=0) plus for cross-tile-ways, the next nodes outside of the bbox are needed to calculate the position of the way, but anything else should be obsolete if the way is not a closed way. Am I wrong? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r239-tp5736433p5736510.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Mon, Nov 19, 2012 at 10:02:43PM +0100, Henning Scholland wrote:
The problem is, that the complete way isn't rendered, if only one node is missing. I don't know if it would be good, if mkgmap skip missing nodes. It could course other problems.
I thought that the 'correct' handling of missing nodes in ways is to pretend that the nodes do not exist. Only if the way is not closed (start and end node ID differ), the polygon would be omitted. FWIW, I sometimes see complaints in stderr or stdout about missing nodes when I fix problems in JOSM. Marko
Am 20.11.2012 13:34, schrieb Marko Mäkelä:
On Mon, Nov 19, 2012 at 10:02:43PM +0100, Henning Scholland wrote:
The problem is, that the complete way isn't rendered, if only one node is missing. I don't know if it would be good, if mkgmap skip missing nodes. It could course other problems. I thought that the 'correct' handling of missing nodes in ways is to pretend that the nodes do not exist. Only if the way is not closed (start and end node ID differ), the polygon would be omitted.
FWIW, I sometimes see complaints in stderr or stdout about missing nodes when I fix problems in JOSM. So maybe I'm wrong and it was another reason, that ways wasn't be rendered.
Henning
If my input file is Germany, perhaps it's an option to tell splitter to look up in an europe-dump for the missing ways ? Am Montag, 19. November 2012 schrieb Gerd Petermann :
Hi Chris,
this message appears if a way that is in the problem list is not complete. It just means that splitter cannot "keep-complete" this way because the input is already not complete. It is hard to say if that is important for you ;-) Splitter writes these ways no matter how many nodes are missing (if not all of them)
My intention with this message is: If you find that a way is missing in the map, you should first check if splitter complained with such a message.
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk <javascript:_e({}, 'cvml', 'mkgmap-dev@lists.mkgmap.org.uk');> From: chris66nrw@gmx.de <javascript:_e({}, 'cvml', 'chris66nrw@gmx.de');> Date: Mon, 19 Nov 2012 20:06:34 +0100 Subject: Re: [mkgmap-dev] splitter r239
Am 19.11.2012 17:23, schrieb GerdP:
Hi all,
I've committed r239 now.
Hi Gerd,
I get many error messages:
Sorry, way x is missing y node(s).
Can they be ignored ?
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <javascript:_e({}, 'cvml', 'mkgmap-dev@lists.mkgmap.org.uk');> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Sent from Gmail Mobile
participants (7)
-
Chris66 -
Felix Hartmann -
flabot＠googlemail.com -
Gerd Petermann -
GerdP
-
Henning Scholland -
Marko Mäkelä