Distinction between smooth paved/rough paved/unpaved streets

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Distinction between smooth paved/rough paved/unpaved streets

Alexandre Folle de Menezes

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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Carlos Dávila-2
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.
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Gerd Petermann
In reply to this post by Alexandre Folle de Menezes
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Alexandre Folle de Menezes
In reply to this post by Alexandre Folle de Menezes
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-unpaved-streets-tp5886735p5886737.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Greg Troxel-2
In reply to this post by Carlos Dávila-2

Carlos Dávila <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Alexandre Folle de Menezes
In reply to this post by Carlos Dávila-2

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 [hidden email] 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Greg Troxel-2

Alexandre Folle de Menezes <[hidden email]> writes:

> On 01/12/2016 11:35, Greg Troxel wrote:
>> Carlos Dávila <[hidden email]> 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.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Alexandre Folle de Menezes
In reply to this post by Alexandre Folle de Menezes
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.8183%3B-29.4400%2C-49.8053#map=16/-29.4358/-49.8118&layers=N

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-unpaved-streets-tp5886735p5886737.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Gerd Petermann
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 <[hidden email]> im Auftrag von Alexandre Folle de Menezes <[hidden email]>
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.8183%3B-29.4400%2C-49.8053#map=16/-29.4358/-49.8118&layers=N

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-unpaved-streets-tp5886735p5886737.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> [hidden email]
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Distinction between smooth paved/rough paved/unpaved streets

Greg Troxel-2
In reply to this post by Alexandre Folle de Menezes

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.



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

signature.asc (167 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

SCHWERWIEGEND (MapSplitter): Area too small to split at

Walter Schlögl
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

SCHWERWIEGEND_MapSplitter.txt (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Gerd Petermann
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 <[hidden email]> im Auftrag von Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Walter Schlögl
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Gerd Petermann
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 <[hidden email]> im Auftrag von Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Walter Schlögl
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Gerd Petermann
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 <[hidden email]> im Auftrag von Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Walter Schlögl
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Gerd Petermann
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 <[hidden email]> im Auftrag von Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: SCHWERWIEGEND (MapSplitter): Area too small to split at

Walter Schlögl
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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 <[hidden email]> im Auftrag von
Walter Schlögl <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev