Distinction between smooth paved/rough paved/unpaved streets
Hi, Here in my city there are basically 3 types of paving on streets: * Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect. In fact, I found the following rule: highway=residential [0x06 road_class=0 road_speed=2 resolution 22] It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type? Thanks in advance, Alexandre
El 01/12/16 a las 07:16, Alexandre de Menezes escribió:
Hi,
Here in my city there are basically 3 types of paving on streets:
* Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved
I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect.
In fact, I found the following rule:
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type?
Thanks in advance,
Alexandre
You can use something like this: highway=residential & (surface=concrete | surface=asphalt) [0x06 road_class=X road_speed=Y resolution 22] highway=residential & (surface=sett | surface=paving_stones) [0x06 road_class=A road_speed=B resolution 22] highway=residential [0x06 road_class=0 road_speed=2 resolution 22] Try different X and Y values to fit your needs.
Carlos Dávila <cdavilam@orangecorreo.es> writes:
You can use something like this: highway=residential & (surface=concrete | surface=asphalt) [0x06 road_class=X road_speed=Y resolution 22] highway=residential & (surface=sett | surface=paving_stones) [0x06 road_class=A road_speed=B resolution 22] highway=residential [0x06 road_class=0 road_speed=2 resolution 22] Try different X and Y values to fit your needs.
I would also suggest to set a special speed for surface=sett/etc. and to use the regular paved speed for roads that are either not marked with a surface tag or have some unknown value. Basically, assume it's ok unless there is a specific tag you understand.
Yes, my plan was to add "paved" with the first group. How do I add unmarked roads? On 01/12/2016 11:35, Greg Troxel wrote:
Carlos Dávila <cdavilam@orangecorreo.es> writes:
You can use something like this: highway=residential & (surface=concrete | surface=asphalt) [0x06 road_class=X road_speed=Y resolution 22] highway=residential & (surface=sett | surface=paving_stones) [0x06 road_class=A road_speed=B resolution 22] highway=residential [0x06 road_class=0 road_speed=2 resolution 22] Try different X and Y values to fit your needs.
I would also suggest to set a special speed for surface=sett/etc. and to use the regular paved speed for roads that are either not marked with a surface tag or have some unknown value. Basically, assume it's ok unless there is a specific tag you understand.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Alexandre Folle de Menezes <afmlistas@terra.com.br> writes:
On 01/12/2016 11:35, Greg Troxel wrote:
Carlos Dávila <cdavilam@orangecorreo.es> writes:
You can use something like this: highway=residential & (surface=concrete | surface=asphalt) [0x06 road_class=X road_speed=Y resolution 22] highway=residential & (surface=sett | surface=paving_stones) [0x06 road_class=A road_speed=B resolution 22] highway=residential [0x06 road_class=0 road_speed=2 resolution 22] Try different X and Y values to fit your needs.
I would also suggest to set a special speed for surface=sett/etc. and to use the regular paved speed for roads that are either not marked with a surface tag or have some unknown value. Basically, assume it's ok unless there is a specific tag you understand.
Yes, my plan was to add "paved" with the first group. How do I add unmarked roads?
There is a syntax for not having a tag, but I would also have that as the last thing. So I would just do: highway=residential & (surface=sett | surface=paving_stones) [0x06 road_class=0 road_speed=X resolution 22] highway=residential [0x06 road_class=0 road_speed=2 resolution 22] and let things without a surface tag end up in the same category as surface=asphalt. Around me, most roads are asphalt and they rarely have paved or surface tags. Plus, there is processing for unpaved, and those rules result in different values. I'm not suggesting to change that.
Hi Alexandre, the default style sets special tag mkgmap:unpaved. As far as I know this is only used for the road avoidance, but you should be able to see this effect on routing. Gerd Alexandre de Menezes wrote
Hi,
Here in my city there are basically 3 types of paving on streets:
* Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved
I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect.
In fact, I found the following rule:
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type?
Thanks in advance,
Alexandre
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Distinction-between-smooth-paved-rough-paved-... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Yes, I see that unpaved roads appear different on the device screen and can be avoided in routing. My main concern is in routing preferably trough concrete/asphalt (smooth and silent) over sett/paving_stones (noisy). I'll test Carlos' suggestion and post my comments later this week. Best regards, Alexandre On 01/12/2016 05:41, Gerd Petermann wrote:
Hi Alexandre,
the default style sets special tag mkgmap:unpaved. As far as I know this is only used for the road avoidance, but you should be able to see this effect on routing.
Gerd
Alexandre de Menezes wrote
Hi,
Here in my city there are basically 3 types of paving on streets:
* Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved
I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect.
In fact, I found the following rule:
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type?
Thanks in advance,
Alexandre
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Distinction-between-smooth-paved-rough-paved-... 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 all, So as promised, I tested the changes and they kind of worked. The routing did indeed prefer asphalt to concrete, the problem is that it preferred too much. On some of my testes it would add six blocks to my route to avoid a sett street. In the end, I reverted back to the default style for this. I have now a different but related problem. The GPS seems to prefer unpaved streets to cobblestone ones. It sometimes traces a route much longer, on unpaved roads, to avoid a cobblestone street. Here's an example: http://www.openstreetmap.org/directions?engine=osrm_car&route=-29.4331%2C-49... On the link above the best route is traced, but on my GPS the suggested path goes to the next exit ("Rua 11") abd then returns, all on unpaved roads. I believe cobblestone should be handled like sett, and be preferred over unpaved. Any hint? Thanks in advance, Alexandre On 01/12/2016 11:07, Alexandre Folle de Menezes wrote:
Hi Gerd,
Yes, I see that unpaved roads appear different on the device screen and can be avoided in routing. My main concern is in routing preferably trough concrete/asphalt (smooth and silent) over sett/paving_stones (noisy). I'll test Carlos' suggestion and post my comments later this week.
Best regards,
Alexandre
On 01/12/2016 05:41, Gerd Petermann wrote:
Hi Alexandre,
the default style sets special tag mkgmap:unpaved. As far as I know this is only used for the road avoidance, but you should be able to see this effect on routing.
Gerd
Alexandre de Menezes wrote
Hi,
Here in my city there are basically 3 types of paving on streets:
* Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved
I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect.
In fact, I found the following rule:
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type?
Thanks in advance,
Alexandre
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Distinction-between-smooth-paved-rough-paved-... 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 Alexandre, I think you just have to remove the surface=cobblestone part from the default style so that highways with this tag are not treated like unpaved roads. In fact I think that we should remove it from the default style as well. Maybe it is there because the default style is cyclist friendly ;-) Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Alexandre Folle de Menezes <afmlistas@terra.com.br> Gesendet: Montag, 2. Januar 2017 21:50:57 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Distinction between smooth paved/rough paved/unpaved streets Hi all, So as promised, I tested the changes and they kind of worked. The routing did indeed prefer asphalt to concrete, the problem is that it preferred too much. On some of my testes it would add six blocks to my route to avoid a sett street. In the end, I reverted back to the default style for this. I have now a different but related problem. The GPS seems to prefer unpaved streets to cobblestone ones. It sometimes traces a route much longer, on unpaved roads, to avoid a cobblestone street. Here's an example: http://www.openstreetmap.org/directions?engine=osrm_car&route=-29.4331%2C-49... On the link above the best route is traced, but on my GPS the suggested path goes to the next exit ("Rua 11") abd then returns, all on unpaved roads. I believe cobblestone should be handled like sett, and be preferred over unpaved. Any hint? Thanks in advance, Alexandre On 01/12/2016 11:07, Alexandre Folle de Menezes wrote:
Hi Gerd,
Yes, I see that unpaved roads appear different on the device screen and can be avoided in routing. My main concern is in routing preferably trough concrete/asphalt (smooth and silent) over sett/paving_stones (noisy). I'll test Carlos' suggestion and post my comments later this week.
Best regards,
Alexandre
On 01/12/2016 05:41, Gerd Petermann wrote:
Hi Alexandre,
the default style sets special tag mkgmap:unpaved. As far as I know this is only used for the road avoidance, but you should be able to see this effect on routing.
Gerd
Alexandre de Menezes wrote
Hi,
Here in my city there are basically 3 types of paving on streets:
* Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved
I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect.
In fact, I found the following rule:
highway=residential [0x06 road_class=0 road_speed=2 resolution 22]
It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type?
Thanks in advance,
Alexandre
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Distinction-between-smooth-paved-rough-paved-... 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
As I understand it, the garmin format has only a single unpaved bit. So the mkgmap style basically has to map all surface types to either paved (no tags) or unpaved (mkgmap:unpaved=1). Another approach is to set speeds on roads that you wish to avoid, using the speed as a weight. I am curious what you actually want. Assume an area with a 50 km/h speed limit. Then on a paved street one can go 50. What speeds would you set for cobblestone/sett and dirt so that the min-time route would be the behavior you desire and why? I am not trying to give you a hard time - I have been thinking about how to make routes that people want for a long time, but not done much about it and this is another interesting case.
If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter
Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter
Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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
Hi Gerd, many thanks, the logfile looks much better now with the windows EOL style. It seems, that not so many mkgmap users are using windows, otherwise this would have been found much earlier. I am now working on a supressions of those many adresses at the same place. It looks as if somebody has tagged every door on every level of these buildings. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 11:21 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Walter, thanks for the feedback. I am using Windows, but all my favorite tools are able to handle unix style, so I never noticed. I wonder why you create those POI, is the --hosuenumbers option not working for you? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 18:24:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, many thanks, the logfile looks much better now with the windows EOL style. It seems, that not so many mkgmap users are using windows, otherwise this would have been found much earlier. I am now working on a supressions of those many adresses at the same place. It looks as if somebody has tagged every door on every level of these buildings. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 11:21 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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 _______________________________________________ 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
Hi Gerd, I am using the housenumber option, but only if there is a building. If there is an addr tag without building I want to see every 5th housenumber directly in the map without clicking and the other numbers as hidden POI with 1x1 pixel, so that I can show the number with clicking. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 6:32 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, thanks for the feedback. I am using Windows, but all my favorite tools are able to handle unix style, so I never noticed. I wonder why you create those POI, is the --hosuenumbers option not working for you? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 18:24:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, many thanks, the logfile looks much better now with the windows EOL style. It seems, that not so many mkgmap users are using windows, otherwise this would have been found much earlier. I am now working on a supressions of those many adresses at the same place. It looks as if somebody has tagged every door on every level of these buildings. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 11:21 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Walter, I tried to reproduce the error messages by adding the rule to points in the default style but (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] that doesn't produce such a large number of POI in a small area. I assume you have other rules which add one POI for each of the 271 addr:housenumber nodes near 52.218652 6.881467. Anyhow, I will try to change the code to avoid that error message. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 19:13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, I am using the housenumber option, but only if there is a building. If there is an addr tag without building I want to see every 5th housenumber directly in the map without clicking and the other numbers as hidden POI with 1x1 pixel, so that I can show the number with clicking. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 6:32 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, thanks for the feedback. I am using Windows, but all my favorite tools are able to handle unix style, so I never noticed. I wonder why you create those POI, is the --hosuenumbers option not working for you? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 18:24:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, many thanks, the logfile looks much better now with the windows EOL style. It seems, that not so many mkgmap users are using windows, otherwise this would have been found much earlier. I am now working on a supressions of those many adresses at the same place. It looks as if somebody has tagged every door on every level of these buildings. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 11:21 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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
Hi Gerd, you are right, there is more code to add the addr for housenumber 2,3,4,6,...9,11,... mkgmap_POI_addr=* & !(addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1') & name!=* { add name='${mkgmap_POI_addr}' } [0x1604 resolution 24] If there are any splitter parameter relevant for this error message, I can provide that. Now I am suppressing all adresses that are currently causing this error. It covers Enschede, Wageningen, Amsterdam, Zaandam, Utrecht, Rotterdam addr:postcode=7513BH & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=6708PG & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=6708GA & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=6708AK & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=6706HC & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=1079NR & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=1503EE & addr:street=Pharus { delete addr:housenumber } addr:postcode=3526WH & addr:street=Europaplein { delete addr:housenumber } addr:postcode=3526WP & addr:street=Europaplein { delete addr:housenumber } addr:postcode=3571SM & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=3571AD & addr:housenumber~'.*-.*' { delete addr:housenumber } addr:postcode=3706AA & addr:street='Laan van Vollenhove' {delete addr:housenumber } addr:postcode=3067VM & addr:street='Hendrick Staetsweg' { delete addr:housenumber } addr:postcode=3024NK & addr:street='Kees van Dongenhof' { delete addr:housenumber } addr:postcode=3012CC & addr:street='Kruisplein' { delete addr:housenumber } addr:postcode=3072DB & addr:street='Laan op Zuid' { delete addr:housenumber } addr:postcode=3032CG & addr:street='Hofdijk' { delete addr:housenumber } Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Sunday, January 15, 2017 10:03 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, I tried to reproduce the error messages by adding the rule to points in the default style but (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] that doesn't produce such a large number of POI in a small area. I assume you have other rules which add one POI for each of the 271 addr:housenumber nodes near 52.218652 6.881467. Anyhow, I will try to change the code to avoid that error message. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 19:13:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, I am using the housenumber option, but only if there is a building. If there is an addr tag without building I want to see every 5th housenumber directly in the map without clicking and the other numbers as hidden POI with 1x1 pixel, so that I can show the number with clicking. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 6:32 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, thanks for the feedback. I am using Windows, but all my favorite tools are able to handle unix style, so I never noticed. I wonder why you create those POI, is the --hosuenumbers option not working for you? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 18:24:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerd, many thanks, the logfile looks much better now with the windows EOL style. It seems, that not so many mkgmap users are using windows, otherwise this would have been found much earlier. I am now working on a supressions of those many adresses at the same place. It looks as if somebody has tagged every door on every level of these buildings. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 11:21 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, okay, now I understand. All messages produced with the logger have unix style endings, while "normal" messages produced with system.out.* have the system dependent line endings. I've found one place in UsefullFormatter which used a hard coded '\n' and changed that in r3753. Hope that fixes this problem. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Samstag, 14. Januar 2017 10:44:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Gerg, I am using the command 2>>Filename.txt Since all other lines in this file are having the correct cr-lf end and only these lines are having the unix lf end without cr I am sure that the command itself is working correct and mkgmap is generating the wrong line end for this message. Yes, I am generating a POI for every 5th addr tag. At these places there are nearly hundred of addr tags at the same location. I could identify these 18 places and suppress only those addr tags, but I would prefer a more general solution if there is one. This command generates visible addr POIs for the housenumbers 1, 5, 10, 15, 20, .... but only, if there is no building. (addr:housenumber~'.*0' | addr:housenumber~'.*5' | addr:housenumber='1' | addr:unit=* | addr:door=*) { name '${addr:unit}/${addr:door}' | '${addr:housenumber}/${addr:unit}' | '${addr:door}' | '${addr:unit}' | '${addr:housenumber}'} [0x1E04 resolution 24] If there is a building, it will get the addr via --poi-address. Walter -----Ursprüngliche Nachricht----- From: Gerd Petermann Sent: Saturday, January 14, 2017 7:36 AM To: Development list for mkgmap Subject: Re: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at Hi Walter, hmm, all log messages are written with the same routine, each message is one line, and they should all have the correct line ending. When you say logfile, is that the output written to stderr or do you use java option like -Dlog.config=logging.properties to configure the details? See http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging for more info about that. If you use a command like this java -jar mkgmap.jar .... > mkgmap.log 2>mgkmap.err the two files mkgmap.log and mkgmap.err should also have cr-lf style. Reg. the message itself : It seems that your style genenrates a POI for each of the 271 addr:xxx nodes in this area. I think the algo in MapSplitter can be changed to handle that. Will try that later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Walter Schlögl <Walter.Schloegl-Resch@aon.at> Gesendet: Freitag, 13. Januar 2017 23:37:12 An: Development list for mkgmap Betreff: [mkgmap-dev] SCHWERWIEGEND (MapSplitter): Area too small to split at If there are too many address tags (or maybe also other tags) mkgmap generates a lot of error messages. For all these error messages the <CR><LF> is missing at the end, if it runs under windows. Would it be possible to add the correct EOL chars so that the logfile keeps it's readability? All other messages outputted with echo are having a correct <CR><LF> at the end. If anybody has a solution how to reduce these errors it would also be helpfull. Here are the areas I have found in my logfile. SCHWERWIEGEND (MapSplitter): 50120092.o5m: Area too small to split at http://www.openstreetmap.org/?mlat=52.218511&mlon=6.881390&zoom=17 (reduce the density of points, length of lines, etc.) SCHWERWIEGEND (MapBuilder): 50120092.o5m: Too many POIs at location http://www.openstreetmap.org/?mlat=52.218554&mlon=6.881454&zoom=17 - 210-901 Emmastraat will be ignored ... More areas are in attached logfile excerpt. Walter _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (7)
-
Alexandre de Menezes -
Alexandre Folle de Menezes
-
Carlos Dávila -
Gerd Petermann -
Gerd Petermann
-
Greg Troxel -
Walter Schlögl