subject:"\[mkgmap\-dev\] problem with splitter"

Well, the difference is small, but I have no idea what

problem you had in the first place, as the split worked fine

in both cases.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Steve 
Sgalowski <steve.sgalow...@gmail.com>
Gesendet: Samstag, 26. März 2016 13:59
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

does not look different to me , on the australia  latest file

Stephen
australia


On Sat, Mar 26, 2016 at 10:29 PM, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:

Steve,


Why didn't you use the new option?


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Steve Sgalowski 
<steve.sgalow...@gmail.com<mailto:steve.sgalow...@gmail.com>>
Gesendet: Samstag, 26. März 2016 11:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

this was done with australia-latest
unshure if it looks better or not

Steve
Australia


This email has been sent from a virus-free computer protected by Avast.
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>

On Sat, Mar 26, 2016 at 7:21 PM, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Steve,

could it be that the process is "unhappy" with two or more
commits within a short time ?

Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Steve Ratcliffe 
<st...@parabola.me.uk<mailto:st...@parabola.me.uk>>
Gesendet: Samstag, 26. März 2016 10:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

On 26/03/16 08:53, Gerd Petermann wrote:
> Hmm, seem that the build process hangs again...

Re-started and the r437 build is now available.

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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<mailto: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

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Steve,


Why didn't you use the new option?


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Steve 
Sgalowski <steve.sgalow...@gmail.com>
Gesendet: Samstag, 26. März 2016 11:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

this was done with australia-latest
unshure if it looks better or not

Steve
Australia


This email has been sent from a virus-free computer protected by Avast.
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>

On Sat, Mar 26, 2016 at 7:21 PM, Gerd Petermann 
<gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Steve,

could it be that the process is "unhappy" with two or more
commits within a short time ?

Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Steve Ratcliffe 
<st...@parabola.me.uk<mailto:st...@parabola.me.uk>>
Gesendet: Samstag, 26. März 2016 10:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

On 26/03/16 08:53, Gerd Petermann wrote:
> Hmm, seem that the build process hangs again...

Re-started and the r437 build is now available.

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-26 Thread Steve Sgalowski

trying r437 now
will advise gerd
Stephen g
Australia


This email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, Mar 26, 2016 at 7:21 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Steve,
>
> could it be that the process is "unhappy" with two or more
> commits within a short time ?
>
> Gerd
>
> 
> Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Steve Ratcliffe <st...@parabola.me.uk>
> Gesendet: Samstag, 26. März 2016 10:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct
> split
>
> On 26/03/16 08:53, Gerd Petermann wrote:
> > Hmm, seem that the build process hangs again...
>
> Re-started and the r437 build is now available.
>
> ..Steve
>
> ___
> 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

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Steve,

could it be that the process is "unhappy" with two or more
commits within a short time ?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Steve 
Ratcliffe <st...@parabola.me.uk>
Gesendet: Samstag, 26. März 2016 10:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

On 26/03/16 08:53, Gerd Petermann wrote:
> Hmm, seem that the build process hangs again...

Re-started and the r437 build is now available.

..Steve

___
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

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-26 Thread Steve Ratcliffe


On 26/03/16 08:53, Gerd Petermann wrote:

Hmm, seem that the build process hangs again...


Re-started and the r437 build is now available.

..Steve

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hmm, seem that the build process hangs again...

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik
Brunner <patrik.brun...@gmx.net>
Gesendet: Samstag, 26. März 2016 08:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Many thanks, Gerd.

If there is a compiled Version, i can test it this evening
Patrik

Am 26.03.2016 8:38 vorm. schrieb Gerd Petermann
<gpetermann_muenc...@hotmail.com>:

Hi all,

I tried to find out why splitter uses the bounding box provided in the file.

The feature was added by Chris Miller with splitter release 102 with this
comment:

"Added support for the tag in OSM files. Also added a --status-freq
parameter to periodically display status information."

I searched the archives to find out why this was done but found no hint, can
anybody remember what problem

he wanted to solve ?

For now I've added option --ignore-osm-bounds to splitter r437. See

http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=436

and

http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=437<http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=436>

(sorry for the two changes, I first thought that I cannot use
--ignore-osm-bounds as option name)

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik
Brunner <patrik.brun...@gmx.net>
Gesendet: Freitag, 25. März 2016 13:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Good news, Gerd.
.. as long as it's not too much thoughts... ;-)

Just to give you a heads up regarding the 'source' of the problem:
according to GeoFabrik the wrong bounds tag seems to be caused by
osmium-history-splitter used to split the world file.

Cheers
Patrik

On 25.03.2016 11:00, Gerd Petermann wrote:

Hi Patrik,

reg. performance for option 3: I don't expect any extra costs for this,
splitter already collects all the data and applies the bbox

after that. So, it always creates a (virtual) grid for the whole planet. With
normal resolutions this never was a bottle neck.

reg. implementation: I don't see any problem for any of the three options, but
option 3 may requrie more thoughts.

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag von Patrik Brunner
<patrik.brun...@gmx.net><mailto:patrik.brun...@gmx.net>
Gesendet: Freitag, 25. März 2016 10:35
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

yes, it's a complicated world with these non-rectancular countries, can't we
change that ? ;-)

I did some tests yesterday playing around with --no-trim and --polygon-files
with Luxembourge (small enough to do quick tests), the result is not that much
different if I'm skipping --no-trim or use the polygon file, the result ist
still 'quite' rectancular, just a few bits are really left aside but I will
have to do more tests with other countries (more complicated ones and bigger
ones than LUX) to see if in my case I could/should skip --no-trim for building
other maps too.

Regarding your implementation option:

* I would rather prefer not having option 2) implemented for the same
reason as you mention: it changes the default behaviour for everyone. And as we
have to say that for (rough guess) 99% of the cases the actual behaviour is
working that's too much.
* I like option 3). But enabling that by default would possibly increase
the time used to split as it first has to run through the file to see which
bounds (bounds tag or calculated one) have to be used... but I'm sure you could
answer that much better than me... ;-)
* Option 1) is possibly the cheapest to implement ?

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:

Hi Patrik,

good question. I also wondered if splitter can be changed to ignore wrong bounds

tags. My thoughts:

In your case the bbox is far too large, means it claims to contain data that is
not there.

The normal case is vice versa: The file contains some nodes outside of the bbox,

maybe from ferry lines or other long ways, and my understanding is that we don't

want to calculate the tiles based on those few nodes, since we might get a map
with

larger empty areas at the "border". No idea if that would cause more trouble.

With typical data from geofabrik and the --no-trim option there will always be
large

empty areas as most countries are not rectangular ;-)

Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default to false (means one
gets

the same result like now when he uses the defa

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-26 Thread Patrik Brunner

Many thanks, Gerd.
If there is a compiled Version, i can test it this evening
Patrik
Am 26.03.2016 8:38 vorm. schrieb Gerd Petermann <gpetermann_muenc...@hotmail.com>:

Hi all,

I tried to find out why splitter uses the bounding box provided in the file.
The feature was added by Chris Miller with splitter release 102 with this comment:
"Added support for the tag in OSM files. Also added a --status-freq parameter to periodically display status information."

I searched the archives to find out why this was done but found no hint, can anybody remember what problem
he wanted to solve ?

For now I've added option --ignore-osm-bounds to splitter r437. See

http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=436
and
http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=437

(sorry for the two changes, I first thought that I cannot use --ignore-osm-bounds as option name)

Gerd

Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner <patrik.brunner@gmx.net>
Gesendet: Freitag, 25. März 2016 13:32
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Good news, Gerd.
.. as long as it's not too much thoughts... ;-)

Just to give you a heads up regarding the 'source' of the problem:
according to GeoFabrik the wrong bounds tag seems to be caused by osmium-history-splitter used to split the world file.

Cheers
Patrik

On 25.03.2016 11:00, Gerd Petermann wrote:

Hi Patrik,

reg. performance for option 3: I don't expect any extra costs for this, splitter already collects all the data and applies the bbox
after that. So, it always creates a (virtual) grid for the whole planet. With normal resolutions this never was a bottle neck.

reg. implementation: I don't see any problem for any of the three options, but option 3 may requrie more thoughts.

Gerd

Von: mkgmap-dev

<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Patrik Brunner
<patrik.brunner@gmx.net>
Gesendet: Freitag, 25. März 2016 10:35
An:
mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

yes, it's a complicated world with these non-rectancular countries, can't we change that ? ;-)

I did some tests yesterday playing around with --no-trim and --polygon-files with Luxembourge (small enough to do quick tests), the result is not that much different if I'm skipping --no-trim or use the polygon file, the result ist still 'quite' rectancular,
just a few bits are really left aside but I will have to do more tests with other countries (more complicated ones and bigger ones than LUX) to see if in my case I could/should skip --no-trim for building other maps too.

Regarding your implementation option:
I would rather prefer not having option 2) implemented for the same reason as you mention: it changes the default behaviour for everyone. And as we have to say that for (rough guess) 99% of the cases the actual behaviour is working that's too much.
I like option 3). But enabling that by default would possibly increase the time used to split as it first has to run through the file to see which bounds (bounds tag or calculated one) have to be used... but I'm sure you could answer that much better than
me... ;-) Option 1) is possibly the cheapest to implement ?

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:

Hi Patrik,

good question. I also wondered if splitter can be changed to ignore wrong bounds
tags. My thoughts:

In your case the bbox is far too large, means it claims to contain data that is not there.
The normal case is vice versa: The file contains some nodes outside of the bbox,

maybe from ferry lines or other long ways, and my understanding is that we don't
want to calculate the tiles based on those few nodes, since we might get a map with
larger empty areas at the "border". No idea if that would cause more trouble.

With typical data from geofabrik and the --no-trim option there will always be large

empty areas as most countries are not rectangular ;-)

Possible changes in the code:
1) add a --ignore-osm-bounds option and set the default to false (means one gets
the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default to false
(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if needed.

I'd like to get some feedback from others first.

Gerd

Von: mkgmap-dev

<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von KeenOnKites
<keenonkites@gmx.net>
Gesendet: Freitag, 25. März 2016 00:13
An:
mkg

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi all,

I tried to find out why splitter uses the bounding box provided in the file.

The feature was added by Chris Miller with splitter release 102 with this
comment:

"Added support for the tag in OSM files. Also added a --status-freq
parameter to periodically display status information."

I searched the archives to find out why this was done but found no hint, can
anybody remember what problem

he wanted to solve ?

For now I've added option --ignore-osm-bounds to splitter r437. See

http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=436

and

http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=437<http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=436>

(sorry for the two changes, I first thought that I cannot use
--ignore-osm-bounds as option name)

Gerd

Good news, Gerd.
.. as long as it's not too much thoughts... ;-)

Just to give you a heads up regarding the 'source' of the problem:
according to GeoFabrik the wrong bounds tag seems to be caused by
osmium-history-splitter used to split the world file.

Cheers
Patrik

On 25.03.2016 11:00, Gerd Petermann wrote:

Hi Patrik,

reg. performance for option 3: I don't expect any extra costs for this,
splitter already collects all the data and applies the bbox

after that. So, it always creates a (virtual) grid for the whole planet. With
normal resolutions this never was a bottle neck.

reg. implementation: I don't see any problem for any of the three options, but
option 3 may requrie more thoughts.

Gerd

Gerd,

yes, it's a complicated world with these non-rectancular countries, can't we
change that ? ;-)

Regarding your implementation option:

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:

Hi Patrik,

good question. I also wondered if splitter can be changed to ignore wrong bounds

tags. My thoughts:

In your case the bbox is far too large, means it claims to contain data that is
not there.

The normal case is vice versa: The file contains some nodes outside of the bbox,

maybe from ferry lines or other long ways, and my understanding is that we don't

want to calculate the tiles based on those few nodes, since we might get a map
with

larger empty areas at the "border". No idea if that would cause more trouble.

With typical data from geofabrik and the --no-trim option there will always be
large

empty areas as most countries are not rectangular ;-)

Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default to false (means one
gets

the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default to false

(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if needed.

I'd like to get some feedback from others first.

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag von KeenOnKites <mailto:keenonki...@gmx.

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-25 Thread Patrik Brunner


Good news, Gerd.
.. as long as it's not too much thoughts... ;-)

Just to give you a heads up regarding the 'source' of the problem:
according to GeoFabrik the wrong bounds tag seems to be caused by 
osmium-history-splitter used to split the world file.


Cheers
Patrik

On 25.03.2016 11:00, Gerd Petermann wrote:


Hi Patrik,


reg. performance for option 3: I don't expect any extra costs for 
this, splitter already collects all the data and applies the bbox


after that. So, it always creates a (virtual) grid for the whole 
planet. With normal resolutions this never was a bottle neck.



reg. implementation: I don't see any problem for any of the three 
options, but option 3 may requrie more thoughts.



Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von Patrik Brunner <patrik.brun...@gmx.net>

*Gesendet:* Freitag, 25. März 2016 10:35
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

yes, it's a complicated world with these non-rectancular countries, 
can't we change that ? ;-)


I did some tests yesterday playing around with --no-trim and 
--polygon-files with Luxembourge (small enough to do quick tests), the 
result is not that much different if I'm skipping --no-trim or use the 
polygon file, the result ist still 'quite' rectancular, just a few 
bits are really left aside but I will have to do more tests with 
other countries (more complicated ones and bigger ones than LUX) to 
see if in my case I could/should skip --no-trim for building other 
maps too.


Regarding your implementation option:

  * I would rather prefer not having option 2) implemented for the
same reason as you mention: it changes the default behaviour for
everyone. And as we have to say that for (rough guess) 99% of the
cases the actual behaviour is working that's too much.
  * I like option 3). But enabling that by default would possibly
increase the time used to split as it first has to run through the
file to see which bounds (bounds tag or calculated one) have to be
used... but I'm sure you could answer that much better than me... ;-)
  * Option 1) is possibly the cheapest to implement ?

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:


Hi Patrik,


good question. I also wondered if splitter can be changed to ignore 
wrong bounds


tags. My thoughts:

In your case the bbox is far too large, means it claims to contain 
data that is not there.


The normal case is vice versa: The file contains some nodes outside 
of the bbox,


maybe from ferry lines or other long ways, and my understanding is 
that we don't


want to calculate the tiles based on those few nodes, since we might 
get a map with


larger empty areas at the "border". No idea if that would cause more 
trouble.


With typical data from geofabrik and the --no-trim option there will 
always be large


empty areas as most countries are not rectangular ;-)


Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default  to false  
(means one gets


the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default to false

(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if 
needed.



I'd like to get some feedback from others first.


Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Freitag, 25. März 2016 00:13
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

I couldn't go to sleep without getting to the ground of this...

I performed the following tests on linux, always with my standard 
--no-trim present:


  * original osm.pbf file downloaded from geofabrik (with the
problematic bounds tag in it)
-> FAILURE
  * converted with the help of osmconvert to normal osm format
-> FAILURE (which was to be expected, same file, just different
format)
  * deleted the osm tag with a simple command like 'cat file.osm |
grep -v bounds > file-nobounds.osm' and ran splitter against it,
always with the same options
-> SUCCESS

This leads me to the question why the bounds tag is read/used if it 
also works without and even gives less problem ?



 sorry for bombarding you (and the list), but I think it's 
nevertheless and interesting question.



Cheers
Patrik


On 24.03.2016 23:51, KeenOnKites wrote:

Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska 
already October 201

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-25 Thread Gerd Petermann

Hi Patrik,


reg. performance for option 3: I don't expect any extra costs for this, 
splitter already collects all the data and applies the bbox

after that. So, it always creates a (virtual) grid for the whole planet. With 
normal resolutions this never was a bottle neck.


reg. implementation: I don't see any problem for any of the three options, but 
option 3 may requrie more thoughts.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik 
Brunner <patrik.brun...@gmx.net>
Gesendet: Freitag, 25. März 2016 10:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

yes, it's a complicated world with these non-rectancular countries, can't we 
change that ? ;-)

I did some tests yesterday playing around with --no-trim and --polygon-files 
with Luxembourge (small enough to do quick tests), the result is not that much 
different if I'm skipping --no-trim or use the polygon file, the result ist 
still 'quite' rectancular, just a few bits are really left aside but I will 
have to do more tests with other countries (more complicated ones and bigger 
ones than LUX) to see if in my case I could/should skip --no-trim for building 
other maps too.

Regarding your implementation option:

  *   I would rather prefer not having option 2) implemented for the same 
reason as you mention: it changes the default behaviour for everyone. And as we 
have to say that for (rough guess) 99% of the cases the actual behaviour is 
working that's too much.
  *   I like option 3). But enabling that by default would possibly increase 
the time used to split as it first has to run through the file to see which 
bounds (bounds tag or calculated one) have to be used... but I'm sure you could 
answer that much better than me... ;-)
  *   Option 1) is possibly the cheapest to implement ?

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:

Hi Patrik,


good question. I also wondered if splitter can be changed to ignore wrong bounds

tags. My thoughts:

In your case the bbox is far too large, means it claims to contain data that is 
not there.

The normal case is vice versa: The file contains some nodes outside of the bbox,

maybe from ferry lines or other long ways, and my understanding is that we don't

want to calculate the tiles based on those few nodes, since we might get a map 
with

larger empty areas at the "border". No idea if that would cause more trouble.

With typical data from geofabrik and the --no-trim option there will always be 
large

empty areas as most countries are not rectangular ;-)


Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default  to false  (means one 
gets

the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default  to false

(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if needed.


I'd like to get some feedback from others first.


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von KeenOnKites <keenonki...@gmx.net><mailto:keenonki...@gmx.net>
Gesendet: Freitag, 25. März 2016 00:13
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

I couldn't go to sleep without getting to the ground of this...

I performed the following tests on linux, always with my standard --no-trim 
present:

  *   original osm.pbf file downloaded from geofabrik (with the problematic 
bounds tag in it)
-> FAILURE
  *   converted with the help of osmconvert to normal osm format
-> FAILURE (which was to be expected, same file, just different format)
  *   deleted the osm tag with a simple command like 'cat file.osm | grep -v 
bounds > file-nobounds.osm' and ran splitter against it, always with the same 
options
-> SUCCESS

This leads me to the question why the bounds tag is read/used if it also works 
without and even gives less problem ?

 sorry for bombarding you (and the list), but I think it's nevertheless and 
interesting question.

Cheers
Patrik

On 24.03.2016 23:51, KeenOnKites wrote:
Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska already 
October 2014. It was an illegal value of maxlon="180.0005" causing splitter to 
bail out

When I convert the osm.pbf file with the help of osmconvert to osm and look at 
the first few lines I see a 'bounds' tag announcing the problematic bounding 
box (not illegal as in 2014, but still 'suboptimal'):



 osm -> get rid

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-25 Thread Patrik Brunner


Gerd,

yes, it's a complicated world with these non-rectancular countries, 
can't we change that ? ;-)


I did some tests yesterday playing around with --no-trim and 
--polygon-files with Luxembourge (small enough to do quick tests), the 
result is not that much different if I'm skipping --no-trim or use the 
polygon file, the result ist still 'quite' rectancular, just a few bits 
are really left aside but I will have to do more tests with other 
countries (more complicated ones and bigger ones than LUX) to see if in 
my case I could/should skip --no-trim for building other maps too.


Regarding your implementation option:

 * I would rather prefer not having option 2) implemented for the same
   reason as you mention: it changes the default behaviour for
   everyone. And as we have to say that for (rough guess) 99% of the
   cases the actual behaviour is working that's too much.
 * I like option 3). But enabling that by default would possibly
   increase the time used to split as it first has to run through the
   file to see which bounds (bounds tag or calculated one) have to be
   used... but I'm sure you could answer that much better than me... ;-)
 * Option 1) is possibly the cheapest to implement ?

Thanks Patrik

On 25.03.2016 07:33, Gerd Petermann wrote:


Hi Patrik,


good question. I also wondered if splitter can be changed to ignore 
wrong bounds


tags. My thoughts:

In your case the bbox is far too large, means it claims to contain 
data that is not there.


The normal case is vice versa: The file contains some nodes outside of 
the bbox,


maybe from ferry lines or other long ways, and my understanding is 
that we don't


want to calculate the tiles based on those few nodes, since we might 
get a map with


larger empty areas at the "border". No idea if that would cause more 
trouble.


With typical data from geofabrik and the --no-trim option there will 
always be large


empty areas as most countries are not rectangular ;-)


Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default  to false  
(means one gets


the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default  to false

(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if 
needed.



I'd like to get some feedback from others first.


Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Freitag, 25. März 2016 00:13
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

I couldn't go to sleep without getting to the ground of this...

I performed the following tests on linux, always with my standard 
--no-trim present:


  * original osm.pbf file downloaded from geofabrik (with the
problematic bounds tag in it)
-> FAILURE
  * converted with the help of osmconvert to normal osm format
-> FAILURE (which was to be expected, same file, just different
format)
  * deleted the osm tag with a simple command like 'cat file.osm |
grep -v bounds > file-nobounds.osm' and ran splitter against it,
always with the same options
-> SUCCESS

This leads me to the question why the bounds tag is read/used if it 
also works without and even gives less problem ?



 sorry for bombarding you (and the list), but I think it's 
nevertheless and interesting question.



Cheers
Patrik


On 24.03.2016 23:51, KeenOnKites wrote:

Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska 
already October 2014. It was an illegal value of maxlon="180.0005" 
causing splitter to bail out


When I convert the osm.pbf file with the help of osmconvert to osm 
and look at the first few lines I see a 'bounds' tag announcing the 
problematic bounding box (not illegal as in 2014, but still 
'suboptimal'):





Getting the statistics via osmconvert with --out-statistics seems to 
read through the file and checks the 'real' bounding box:


...
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
...


I'm now wondering if splitter get's confused by the existing but 
obviously strange bounds tag.


According to the findings in 2014 splitter can handle files without 
the bounds tag and just gets the real boundings from all the elements 
in the file.
I did not test to run it through splitter without the bounds tag as 
I'm having troubles converting the file properly on my windows... but 
I'll try that probably tomorrow again on linux (sort of late already 
today).

The process would be

osm.pbf

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-25 Thread Steve Sgalowski

I have the same problem , with splitter for australia , or
australia-oceania

even when i have search limit at 60,000 or 90,000  or in between these
 Figures
I stil get the same response in splitter log file .

Stephen


On Fri, Mar 25, 2016 at 4:33 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Patrik,
>
>
> good question. I also wondered if splitter can be changed to ignore wrong
> bounds
>
> tags. My thoughts:
>
> In your case the bbox is far too large, means it claims to contain data
> that is not there.
>
> The normal case is vice versa: The file contains some nodes outside of the
> bbox,
>
> maybe from ferry lines or other long ways, and my understanding is that we
> don't
>
> want to calculate the tiles based on those few nodes, since we might get a
> map with
>
> larger empty areas at the "border". No idea if that would cause more
> trouble.
>
> With typical data from geofabrik and the --no-trim option there will
> always be large
>
> empty areas as most countries are not rectangular ;-)
>
>
> Possible changes in the code:
>
> 1) add a --ignore-osm-bounds option and set the default  to false  (means
> one gets
>
> the same result like now when he uses the default)
>
> 2) add a --use-osm-bounds option and set the default  to false
>
> (means one might get a different result when using the default)
>
> 3) add code to check how the collected data matches the given bounds,
>
> use whatever is smaller. This might also be triggered by an option if
> needed.
>
>
> I'd like to get some feedback from others first.
>
>
> Gerd
>
>
> --
> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> KeenOnKites <keenonki...@gmx.net>
> *Gesendet:* Freitag, 25. März 2016 00:13
> *An:* mkgmap-dev@lists.mkgmap.org.uk
> *Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a
> correct split
>
> Gerd,
>
> I couldn't go to sleep without getting to the ground of this...
>
> I performed the following tests on linux, always with my standard
> --no-trim present:
>
>- original osm.pbf file downloaded from geofabrik (with the
>problematic bounds tag in it)
>-> FAILURE
>- converted with the help of osmconvert to normal osm format
>-> FAILURE (which was to be expected, same file, just different
>format)
>- deleted the osm tag with a simple command like 'cat file.osm | grep
>-v bounds > file-nobounds.osm' and ran splitter against it, always with the
>same options
>-> SUCCESS
>
> This leads me to the question why the bounds tag is read/used if it also
> works without and even gives less problem ?
>
>
>  sorry for bombarding you (and the list), but I think it's
> nevertheless and interesting question.
>
>
> Cheers
> Patrik
>
> On 24.03.2016 23:51, KeenOnKites wrote:
>
> Gerd,
>
> I did dig a bit deeper... also as it rang a bell:
> we had quite a similar problem with the wrong bounding box in Alaska
> already October 2014. It was an illegal value of maxlon="180.0005" causing
> splitter to bail out
>
> When I convert the osm.pbf file with the help of osmconvert to osm and
> look at the first few lines I see a 'bounds' tag announcing the problematic
> bounding box (not illegal as in 2014, but still 'suboptimal'):
>
> 
>  timestamp="2016-03-23T20:13:02Z">
>  maxlon="179."/>
>  version="2"
> ...
>
>
> Getting the statistics via osmconvert with --out-statistics seems to read
> through the file and checks the 'real' bounding box:
>
> ...
> lon min: -180.000
> lon max: -122.5122525
> lat min: 48.6234931
> lat max: 71.6061501
> ...
>
>
> I'm now wondering if splitter get's confused by the existing but obviously
> strange bounds tag.
>
> According to the findings in 2014 splitter can handle files without the
> bounds tag and just gets the real boundings from all the elements in the
> file.
> I did not test to run it through splitter without the bounds tag as I'm
> having troubles converting the file properly on my windows... but I'll try
> that probably tomorrow again on linux (sort of late already today).
> The process would be
>
> osm.pbf -> osm -> get rid of the bounds tag -> back to osm.pbf again (to
> have same source file format)
>  and then run the splitter and see what happens.
>
> But if I have a proper osm file with the 'problematic' bounds tag in it, I
> can also try to reproduce the problem with the osm file. If it is
> reproducible I just drop the tag and try it again.
>
> B

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-25 Thread Gerd Petermann

Hi Patrik,


good question. I also wondered if splitter can be changed to ignore wrong bounds

tags. My thoughts:

In your case the bbox is far too large, means it claims to contain data that is 
not there.

The normal case is vice versa: The file contains some nodes outside of the bbox,

maybe from ferry lines or other long ways, and my understanding is that we don't

want to calculate the tiles based on those few nodes, since we might get a map 
with

larger empty areas at the "border". No idea if that would cause more trouble.

With typical data from geofabrik and the --no-trim option there will always be 
large

empty areas as most countries are not rectangular ;-)


Possible changes in the code:

1) add a --ignore-osm-bounds option and set the default  to false  (means one 
gets

the same result like now when he uses the default)

2) add a --use-osm-bounds option and set the default  to false

(means one might get a different result when using the default)

3) add code to check how the collected data matches the given bounds,

use whatever is smaller. This might also be triggered by an option if needed.


I'd like to get some feedback from others first.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
KeenOnKites <keenonki...@gmx.net>
Gesendet: Freitag, 25. März 2016 00:13
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

I couldn't go to sleep without getting to the ground of this...

I performed the following tests on linux, always with my standard --no-trim 
present:

  *   original osm.pbf file downloaded from geofabrik (with the problematic 
bounds tag in it)
-> FAILURE
  *   converted with the help of osmconvert to normal osm format
-> FAILURE (which was to be expected, same file, just different format)
  *   deleted the osm tag with a simple command like 'cat file.osm | grep -v 
bounds > file-nobounds.osm' and ran splitter against it, always with the same 
options
-> SUCCESS

This leads me to the question why the bounds tag is read/used if it also works 
without and even gives less problem ?

 sorry for bombarding you (and the list), but I think it's nevertheless and 
interesting question.

Cheers
Patrik

On 24.03.2016 23:51, KeenOnKites wrote:
Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska already 
October 2014. It was an illegal value of maxlon="180.0005" causing splitter to 
bail out

When I convert the osm.pbf file with the help of osmconvert to osm and look at 
the first few lines I see a 'bounds' tag announcing the problematic bounding 
box (not illegal as in 2014, but still 'suboptimal'):



 osm -> get rid of the bounds tag -> back to osm.pbf again (to have 
same source file format)
 and then run the splitter and see what happens.
But if I have a proper osm file with the 'problematic' bounds tag in it, I can 
also try to reproduce the problem with the osm file. If it is reproducible I 
just drop the tag and try it again.

BTW: I've contacted geofabrik already via email

Patrik


On 24.03.2016 22:27, KeenOnKites wrote:
Gerd,

I'll play a bit more with this option and check what suits me best.

Again thanks for the incredibly quick answer to my problem/question.

Cheers
Patrik

On 24.03.2016 22:20, Gerd Petermann wrote:

Hi Patrik,


I think the wanted effect of the no-trim option is a rectangular map,

which some people prefer, esp. on the PC.


Gerd


Von: mkgmap-dev <mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von KeenOnKites <keenonki...@gmx.net><mailto:keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 22:16
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

Sorry, your explanations came in during I was writing up the test results ...

Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I can/should drop 
the option --no-trim for all map building or if I would suddenly run into 
other/new problems...

I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:

Hi Patrik,


I don't need the files, I downloaded the alaska file and tried some variants.

See also my last post, send a few minutes ago.


Gerd



Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Patrik Brunner <mailto:patrik.brun...@gmx.net> 
<mailto:patrik.brun...@gmx.net> 
<patrik.brun...@gmx.net><mailto

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Gerd,

I couldn't go to sleep without getting to the ground of this...

I performed the following tests on linux, always with my standard 
--no-trim present:


 * original osm.pbf file downloaded from geofabrik (with the
   problematic bounds tag in it)
   -> FAILURE
 * converted with the help of osmconvert to normal osm format
   -> FAILURE (which was to be expected, same file, just different format)
 * deleted the osm tag with a simple command like 'cat file.osm | grep
   -v bounds > file-nobounds.osm' and ran splitter against it, always
   with the same options
   -> SUCCESS

This leads me to the question why the bounds tag is read/used if it also 
works without and even gives less problem ?



 sorry for bombarding you (and the list), but I think it's 
nevertheless and interesting question.



Cheers
Patrik


On 24.03.2016 23:51, KeenOnKites wrote:

Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska 
already October 2014. It was an illegal value of maxlon="180.0005" 
causing splitter to bail out


When I convert the osm.pbf file with the help of osmconvert to osm and 
look at the first few lines I see a 'bounds' tag announcing the 
problematic bounding box (not illegal as in 2014, but still 'suboptimal'):





Getting the statistics via osmconvert with --out-statistics seems to 
read through the file and checks the 'real' bounding box:


...
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
...


I'm now wondering if splitter get's confused by the existing but 
obviously strange bounds tag.


According to the findings in 2014 splitter can handle files without 
the bounds tag and just gets the real boundings from all the elements 
in the file.
I did not test to run it through splitter without the bounds tag as 
I'm having troubles converting the file properly on my windows... but 
I'll try that probably tomorrow again on linux (sort of late already 
today).

The process would be

osm.pbf -> osm -> get rid of the bounds tag -> back to osm.pbf
again (to have same source file format)
 and then run the splitter and see what happens.

But if I have a proper osm file with the 'problematic' bounds tag in 
it, I can also try to reproduce the problem with the osm file. If it 
is reproducible I just drop the tag and try it again.


BTW: I've contacted geofabrik already via email

Patrik


On 24.03.2016 22:27, KeenOnKites wrote:

Gerd,

I'll play a bit more with this option and check what suits me best.

Again thanks for the incredibly quick answer to my problem/question.

Cheers
Patrik

On 24.03.2016 22:20, Gerd Petermann wrote:


Hi Patrik,


I think the wanted effect of the no-trim option is a rectangular map,

which some people prefer, esp. on the PC.


Gerd



*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im 
Auftrag von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:16
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

Sorry, your explanations came in during I was writing up the test 
results ...


Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I 
can/should drop the option --no-trim for all map building or if I 
would suddenly run into other/new problems...


I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:


Hi Patrik,


I don't need the files, I downloaded the alaska file and tried some 
variants.


See also my last post, send a few minutes ago.


Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im 
Auftrag von Patrik Brunner <patrik.brun...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:03
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file 
that belongs to alaska.osm.pbf (also downloaded from Geofabrik) 
which, according to documentation, anyway would disable --no-trim 
option.


Do you still need the resulting densities-out of the failure ? It's 
about 700 kb... if yes, how should I provide it ? Just attach it here ?


You have to excuse my question, I'm not the crack: is this now a 
problem of the pbf file, or the splitter ? ... or just the way I 
try to use it ?


Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:



Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but thi

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Gerd,

I did dig a bit deeper... also as it rang a bell:
we had quite a similar problem with the wrong bounding box in Alaska 
already October 2014. It was an illegal value of maxlon="180.0005" 
causing splitter to bail out


When I convert the osm.pbf file with the help of osmconvert to osm and 
look at the first few lines I see a 'bounds' tag announcing the 
problematic bounding box (not illegal as in 2014, but still 'suboptimal'):


   
   

Getting the statistics via osmconvert with --out-statistics seems to 
read through the file and checks the 'real' bounding box:


   ...
   lon min: -180.000
   lon max: -122.5122525
   lat min: 48.6234931
   lat max: 71.6061501
   ...


I'm now wondering if splitter get's confused by the existing but 
obviously strange bounds tag.


According to the findings in 2014 splitter can handle files without the 
bounds tag and just gets the real boundings from all the elements in the 
file.
I did not test to run it through splitter without the bounds tag as I'm 
having troubles converting the file properly on my windows... but I'll 
try that probably tomorrow again on linux (sort of late already today).

The process would be

   osm.pbf -> osm -> get rid of the bounds tag -> back to osm.pbf again
   (to have same source file format)
    and then run the splitter and see what happens.

But if I have a proper osm file with the 'problematic' bounds tag in it, 
I can also try to reproduce the problem with the osm file. If it is 
reproducible I just drop the tag and try it again.


BTW: I've contacted geofabrik already via email

Patrik


On 24.03.2016 22:27, KeenOnKites wrote:

Gerd,

I'll play a bit more with this option and check what suits me best.

Again thanks for the incredibly quick answer to my problem/question.

Cheers
Patrik

On 24.03.2016 22:20, Gerd Petermann wrote:


Hi Patrik,


I think the wanted effect of the no-trim option is a rectangular map,

which some people prefer, esp. on the PC.


Gerd



*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:16
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

Sorry, your explanations came in during I was writing up the test 
results ...


Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I 
can/should drop the option --no-trim for all map building or if I 
would suddenly run into other/new problems...


I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:


Hi Patrik,


I don't need the files, I downloaded the alaska file and tried some 
variants.


See also my last post, send a few minutes ago.


Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im 
Auftrag von Patrik Brunner <patrik.brun...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:03
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file 
that belongs to alaska.osm.pbf (also downloaded from Geofabrik) 
which, according to documentation, anyway would disable --no-trim 
option.


Do you still need the resulting densities-out of the failure ? It's 
about 700 kb... if yes, how should I provide it ? Just attach it here ?


You have to excuse my question, I'm not the crack: is this now a 
problem of the pbf file, or the splitter ? ... or just the way I try 
to use it ?


Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:



Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the 
details.


It works without --no-trim, probably also with an appropriate 
polygon file.


Does that help?


Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im 
Auftrag von Gerd Petermann <gpetermann_muenc...@hotmail.com>

*Gesendet:* Donnerstag, 24. März 2016 21:01
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im 
Auftrag von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 20:25
*An:* Develo

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

I'll play a bit more with this option and check what suits me best.

Again thanks for the incredibly quick answer to my problem/question.

Cheers
Patrik

On 24.03.2016 22:20, Gerd Petermann wrote:

Hi Patrik,

I think the wanted effect of the no-trim option is a rectangular map,

which some people prefer, esp. on the PC.

Gerd

*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:16
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a
correct split

Gerd,

Sorry, your explanations came in during I was writing up the test
results ...

Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I
can/should drop the option --no-trim for all map building or if I
would suddenly run into other/new problems...

I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:

Hi Patrik,

I don't need the files, I downloaded the alaska file and tried some
variants.

See also my last post, send a few minutes ago.

Gerd

*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
von Patrik Brunner <patrik.brun...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:03
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a
correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file
that belongs to alaska.osm.pbf (also downloaded from Geofabrik)
which, according to documentation, anyway would disable --no-trim option.

Do you still need the resulting densities-out of the failure ? It's
about 700 kb... if yes, how should I provide it ? Just attach it here ?

You have to excuse my question, I'm not the crack: is this now a
problem of the pbf file, or the splitter ? ... or just the way I try
to use it ?

Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:

Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the
details.

It works without --no-trim, probably also with an appropriate
polygon file.

Does that help?

Gerd

*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im
Auftrag von Gerd Petermann <gpetermann_muenc...@hotmail.com>

*Gesendet:* Donnerstag, 24. März 2016 21:01
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a
correct split

Hi Patrik,

please provide the complete log from splitter and the densities-out.txt

Gerd

*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im
Auftrag von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 20:25
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] Problem with splitter: Failed to find a
correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427)
when splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:

Warning: No solution found for partition
(49.7900390625,-179.9560546875) to (73.828125,180.0) with
6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a
correct split
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at
uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:

java -Xmx1536M -jar

D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
--max-threads=2

--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
--keep-complete=true --mapid=9821 --max-nodes=80
--output=xml --output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA

D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:

http

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Patrik,

I think the wanted effect of the no-trim option is a rectangular map,

which some people prefer, esp. on the PC.

Gerd

Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
KeenOnKites <keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 22:16
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

Sorry, your explanations came in during I was writing up the test results ...

Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I can/should drop
the option --no-trim for all map building or if I would suddenly run into
other/new problems...

I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:

Hi Patrik,

I don't need the files, I downloaded the alaska file and tried some variants.

See also my last post, send a few minutes ago.

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag von Patrik Brunner
<patrik.brun...@gmx.net><mailto:patrik.brun...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 22:03
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file that
belongs to alaska.osm.pbf (also downloaded from Geofabrik) which, according to
documentation, anyway would disable --no-trim option.

Do you still need the resulting densities-out of the failure ? It's about 700
kb... if yes, how should I provide it ? Just attach it here ?

You have to excuse my question, I'm not the crack: is this now a problem of the
pbf file, or the splitter ? ... or just the way I try to use it ?

Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:

Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the details.

It works without --no-trim, probably also with an appropriate polygon file.

Does that help?

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag von Gerd Petermann <mailto:gpetermann_muenc...@hotmail.com>
<gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com>
Gesendet: Donnerstag, 24. März 2016 21:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Patrik,

please provide the complete log from splitter and the densities-out.txt

Gerd

Von: mkgmap-dev
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
im Auftrag von KeenOnKites <keenonki...@gmx.net><mailto:keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 20:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when
splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:
Warning: No solution found for partition (49.7900390625,-179.9560546875) to
(73.828125,180.0) with 6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
at
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:
java -Xmx1536M -jar
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
--max-threads=2
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
--keep-complete=true --mapid=9821 --max-nodes=80 --output=xml
--output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

The osmconvert statistics about that file is:
PS Freizeitkarte-Entwicklung> .\tool

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Gerd,

Sorry, your explanations came in during I was writing up the test 
results ...


Think it's all clear so far.

As we're creating lot of different maps I'm just wondering if I 
can/should drop the option --no-trim for all map building or if I would 
suddenly run into other/new problems...


I'll contact geofabrik with the details.

Many thanks and happy Easter.
Patrik

On 24.03.2016 22:07, Gerd Petermann wrote:


Hi Patrik,


I don't need the files, I downloaded the alaska file and tried some 
variants.


See also my last post, send a few minutes ago.


Gerd




*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von Patrik Brunner <patrik.brun...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 22:03
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file 
that belongs to alaska.osm.pbf (also downloaded from Geofabrik) which, 
according to documentation, anyway would disable --no-trim option.


Do you still need the resulting densities-out of the failure ? It's 
about 700 kb... if yes, how should I provide it ? Just attach it here ?


You have to excuse my question, I'm not the crack: is this now a 
problem of the pbf file, or the splitter ? ... or just the way I try 
to use it ?


Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:



Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the 
details.


It works without --no-trim, probably also with an appropriate polygon 
file.


Does that help?


Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von Gerd Petermann <gpetermann_muenc...@hotmail.com>

*Gesendet:* Donnerstag, 24. März 2016 21:01
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 20:25
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) 
when splitting the US_ALASKA file downloadable from Geofabrik.


The exception is:

Warning: No solution found for partition
(49.7900390625,-179.9560546875) to (73.828125,180.0) with
6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a
correct split
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)


The complete command line with the splitter call is:

java -Xmx1536M -jar

D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
--max-threads=2

--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
--keep-complete=true --mapid=9821 --max-nodes=80
--output=xml --output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf


The pbf source file comes from:

http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf


The osmconvert statistics about that file is:

PS Freizeitkarte-Entwicklung>
.\tools\osmconvert\windows\osmconvert.exe
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf
--out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Patrik,


I don't need the files, I downloaded the alaska file and tried some variants.

See also my last post, send a few minutes ago.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Patrik 
Brunner <patrik.brun...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 22:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file that 
belongs to alaska.osm.pbf (also downloaded from Geofabrik) which, according to 
documentation, anyway would disable --no-trim option.

Do you still need the resulting densities-out of the failure ? It's about 700 
kb... if yes, how should I provide it ? Just attach it here ?

You have to excuse my question, I'm not the crack: is this now a problem of the 
pbf file, or the splitter ? ... or just the way I try to use it ?

Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:


Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the details.

It works without --no-trim, probably also with an appropriate polygon file.

Does that help?


Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Gerd Petermann 
<gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com>
Gesendet: Donnerstag, 24. März 2016 21:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


Von: mkgmap-dev 
<mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von KeenOnKites <keenonki...@gmx.net><mailto:keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 20:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when 
splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:
Warning: No solution found for partition (49.7900390625,-179.9560546875) to 
(73.828125,180.0) with 6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:
java -Xmx1536M -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
 --max-threads=2 
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim 
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
--keep-complete=true --mapid=9821 --max-nodes=80 --output=xml 
--output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

The osmconvert statistics about that file is:
PS Freizeitkarte-Entwicklung> .\tools\osmconvert\windows\osmconvert.exe 
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf --out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334
relrefs max: 681
relrefs max object: relation 3337277
PS Freizeitkarte-Entwicklung>
Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.
- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting properly without 
any problems. Do I need to change something in the arguments ? Or is it a 
simple problem of th

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

2016-03-24 Thread Patrik Brunner


Gerd,

Yes, alaska.osm.pbf is small.

It works without --no-trim. And it also works with the polygon file that 
belongs to alaska.osm.pbf (also downloaded from Geofabrik) which, 
according to documentation, anyway would disable --no-trim option.


Do you still need the resulting densities-out of the failure ? It's 
about 700 kb... if yes, how should I provide it ? Just attach it here ?


You have to excuse my question, I'm not the crack: is this now a problem 
of the pbf file, or the splitter ? ... or just the way I try to use it ?


Thanks already now for your help.
Patrik

On 24.03.2016 21:14, Gerd Petermann wrote:



Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the 
details.


It works without --no-trim, probably also with an appropriate polygon 
file.


Does that help?


Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von Gerd Petermann <gpetermann_muenc...@hotmail.com>

*Gesendet:* Donnerstag, 24. März 2016 21:01
*An:* Development list for mkgmap
*Betreff:* Re: [mkgmap-dev] Problem with splitter: Failed to find a 
correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


*Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag 
von KeenOnKites <keenonki...@gmx.net>

*Gesendet:* Donnerstag, 24. März 2016 20:25
*An:* Development list for mkgmap
*Betreff:* [mkgmap-dev] Problem with splitter: Failed to find a 
correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) 
when splitting the US_ALASKA file downloadable from Geofabrik.


The exception is:

Warning: No solution found for partition
(49.7900390625,-179.9560546875) to (73.828125,180.0) with
6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a
correct split
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at

uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)


The complete command line with the splitter call is:

java -Xmx1536M -jar

D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
--max-threads=2

--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
--keep-complete=true --mapid=9821 --max-nodes=80
--output=xml --output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA

D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf


The pbf source file comes from:

http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf


The osmconvert statistics about that file is:

PS Freizeitkarte-Entwicklung>
.\tools\osmconvert\windows\osmconvert.exe
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf
--out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334
relrefs max: 681
relrefs max object: relation 3337277
PS Freizeitkarte-Entwicklung>

Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.

- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting 
properly without any problems. Do I need to change something in the 
arguments ? Or is it a simple problem of the actual pbf file ?


Any ideas are very welcome

Cheers
Patrik





___
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

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Patrik,


yes, the problem is the wrong bounding box in the downloaded file.

I don't know why it says that it spans to 180, because there is no node

between -129 and 180. Because of that and the option --no-trim

splitter would have to write huge empty tiles, that's why it stops.


I think you should contact geofabrik, besides that you can use

osmconvert to correct the bbox like this:

osmconvert.exe -b=-180,49.8,-129,73 alaska-latest.osm.pbf 
-o=alaska-correct.osm.pbf

or use the poly file from the geofabrik download page.


Gerd



Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd 
Petermann <gpetermann_muenc...@hotmail.com>
Gesendet: Donnerstag, 24. März 2016 21:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split



Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the details.

It works without --no-trim, probably also with an appropriate polygon file.

Does that help?


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd 
Petermann <gpetermann_muenc...@hotmail.com>
Gesendet: Donnerstag, 24. März 2016 21:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
KeenOnKites <keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 20:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when 
splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:
Warning: No solution found for partition (49.7900390625,-179.9560546875) to 
(73.828125,180.0) with 6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:
java -Xmx1536M -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
 --max-threads=2 
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim 
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
--keep-complete=true --mapid=9821 --max-nodes=80 --output=xml 
--output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

The osmconvert statistics about that file is:
PS Freizeitkarte-Entwicklung> .\tools\osmconvert\windows\osmconvert.exe 
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf --out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334
relrefs max: 681
relrefs max object: relation 3337277
PS Freizeitkarte-Entwicklung>
Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.
- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting properly without 
any problems. Do I need to change something in the arguments ? Or is it a 
simple problem of the actual pbf file ?

Any ideas are very welcome

Cheers
Patrik



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Ahh, sorry, I just noticed that the file alaska.osm.pbf is small.

The problem is here is that the bounding box spans from -180 to 180,

but this box is most empty. I have to run splitter now to find the details.

It works without --no-trim, probably also with an appropriate polygon file.

Does that help?


Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Gerd 
Petermann <gpetermann_muenc...@hotmail.com>
Gesendet: Donnerstag, 24. März 2016 21:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split


Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
KeenOnKites <keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 20:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when 
splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:
Warning: No solution found for partition (49.7900390625,-179.9560546875) to 
(73.828125,180.0) with 6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:
java -Xmx1536M -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
 --max-threads=2 
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim 
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
--keep-complete=true --mapid=9821 --max-nodes=80 --output=xml 
--output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

The osmconvert statistics about that file is:
PS Freizeitkarte-Entwicklung> .\tools\osmconvert\windows\osmconvert.exe 
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf --out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334
relrefs max: 681
relrefs max object: relation 3337277
PS Freizeitkarte-Entwicklung>
Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.
- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting properly without 
any problems. Do I need to change something in the arguments ? Or is it a 
simple problem of the actual pbf file ?

Any ideas are very welcome

Cheers
Patrik



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hi Patrik,


please provide the complete log from splitter and the densities-out.txt

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von 
KeenOnKites <keenonki...@gmx.net>
Gesendet: Donnerstag, 24. März 2016 20:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with splitter: Failed to find a correct split

Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when 
splitting the US_ALASKA file downloadable from Geofabrik.

The exception is:
Warning: No solution found for partition (49.7900390625,-179.9560546875) to 
(73.828125,180.0) with 6'702'717 nodes
uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at 
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)

The complete command line with the splitter call is:
java -Xmx1536M -jar 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
 --max-threads=2 
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
ities15000.zip --no-trim 
--precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
--keep-complete=true --mapid=9821 --max-nodes=80 --output=xml 
--output-dir=D:/fzk/develop/fzk
-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

The pbf source file comes from:
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

The osmconvert statistics about that file is:
PS Freizeitkarte-Entwicklung> .\tools\osmconvert\windows\osmconvert.exe 
.\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf --out-statistics
timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2016-03-23T05:41:43Z
lon min: -180.000
lon max: -122.5122525
lat min: 48.6234931
lat max: 71.6061501
nodes: 4360214
ways: 185550
relations: 2245
node id min: 27207079
node id max: 4072166815
way id min: 4708608
way id max: 404980503
relation id min: 13971
relation id max: 6033189
keyval pairs max: 310
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334
relrefs max: 681
relrefs max object: relation 3337277
PS Freizeitkarte-Entwicklung>
Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.
- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting properly without 
any problems. Do I need to change something in the arguments ? Or is it a 
simple problem of the actual pbf file ?

Any ideas are very welcome

Cheers
Patrik



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem with splitter: Failed to find a correct split


Hello together,

I'm running into a problem with the splitter (r435 aswell as r427) when 
splitting the US_ALASKA file downloadable from Geofabrik.


The exception is:

   Warning: No solution found for partition
   (49.7900390625,-179.9560546875) to (73.828125,180.0) with 6'702'717
   nodes
   uk.me.parabola.splitter.SplitFailedException: Failed to find a
   correct split
at
   
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:152)
at
   
uk.me.parabola.splitter.SplittableDensityArea.split(SplittableDensityArea.java:196)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:645)
at uk.me.parabola.splitter.Main.split(Main.java:258)
at uk.me.parabola.splitter.Main.start(Main.java:187)
at uk.me.parabola.splitter.Main.main(Main.java:157)


The complete command line with the splitter call is:

   java -Xmx1536M -jar
   
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
   --max-threads=2
   
--geonames-file=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/c
   ities15000.zip --no-trim
   --precomp-sea=D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
   --keep-complete=true --mapid=9821 --max-nodes=80
   --output=xml --output-dir=D:/fzk/develop/fzk
   -mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
   
D:/fzk/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf


The pbf source file comes from:

   http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf


The osmconvert statistics about that file is:

   PS Freizeitkarte-Entwicklung>
   .\tools\osmconvert\windows\osmconvert.exe
   .\work\Freizeitkarte_US_ALASKA\Freizeitkarte_US_ALASKA.osm.pbf
   --out-statistics
   timestamp min: 2007-06-05T03:23:59Z
   timestamp max: 2016-03-23T05:41:43Z
   lon min: -180.000
   lon max: -122.5122525
   lat min: 48.6234931
   lat max: 71.6061501
   nodes: 4360214
   ways: 185550
   relations: 2245
   node id min: 27207079
   node id max: 4072166815
   way id min: 4708608
   way id max: 404980503
   relation id min: 13971
   relation id max: 6033189
   keyval pairs max: 310
   keyval pairs max object: relation 60189
   noderefs max: 2000
   noderefs max object: way 42394334
   relrefs max: 681
   relrefs max object: relation 3337277
   PS Freizeitkarte-Entwicklung>

Interesting to mention:
- splitter exception mentiones a complete different coverage area than 
osmconvert statistics.

- the area is near -180 / +180... always complicated.

Do I miss something ? All other pbf's I've tried are splitting properly 
without any problems. Do I need to change something in the arguments ? 
Or is it a simple problem of the actual pbf file ?


Any ideas are very welcome

Cheers
Patrik



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-06 Thread Gerd Petermann

Hi Andrzej,

okay, good points. That would probably also happen with a simple input filter
in mkgmap. I'll see if I can improve splitter, I think it should be possible.

Gerd



Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski 
<po...@poczta.onet.pl>
Gesendet: Sonntag, 6. März 2016 15:49
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon

Hi Gerd,

> We already have UnusedElementsRemoverHook.java which magically
> detects elements in the input file which will not appear in the
> output file. If we change this filter to check against a poly
> instead of a bbox it might be good enough.

I have already tested something like that, I have extracted USA using
osmosis and bounding poly. I don't like results, mostly because
filtering is not precise. For example I can get a full lake area on a
map but all object on an island are missing, because they are entirely
outside poly, while lake is partially inside. Or I can get contours,
where missing middle part is replaced by a straight line.

If you are thinking about filtering in mkgmap or splitter, then I would
prefer it as a precise cut and trim with bounding poly.

--
Best regards,
Andrzej
___
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

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-06 Thread Andrzej Popowski


Hi Gerd,


We already have UnusedElementsRemoverHook.java which magically
detects elements in the input file which will not appear in the
output file. If we change this filter to check against a poly
instead of a bbox it might be good enough.


I have already tested something like that, I have extracted USA using 
osmosis and bounding poly. I don't like results, mostly because 
filtering is not precise. For example I can get a full lake area on a 
map but all object on an island are missing, because they are entirely 
outside poly, while lake is partially inside. Or I can get contours, 
where missing middle part is replaced by a straight line.


If you are thinking about filtering in mkgmap or splitter, then I would 
prefer it as a precise cut and trim with bounding poly.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-05 Thread Gerd Petermann

Hi Andrzej,

sure, if you change the poly you can avoid the situation. The problem
appears most likely when a highly populated area is close to, but outside of 
the poly 
and a lowly populated area inside and the polygon line is a long diagonal line 
at this place.

I'll see if I can improve the algo. 
I think as long as mkgmap doesn't support poly files we have to solve the 
problem in splitter.

On the other hand, a simple filter in mkgmap should also be possible. We 
already have 
UnusedElementsRemoverHook.java which magically detects elements in the input 
file
which will not appear in the output file. If we change this filter to check 
against a poly 
instead of a bbox it might be good enough. 
I only hesitate to implement that because one might expect that this woud also 
allow splitting maps at country borders, which requires much more work
when routing across these borders should work.

Gerd







Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski 
<po...@poczta.onet.pl>
Gesendet: Sonntag, 6. März 2016 02:00
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon

Hi Gerd,

> I don't yet have a solution, I just know that the current approach
> is not okay.

No easy solution. I think maybe the best would be to trim border tiles
according to bounding polygon. This could be suitable for irregular
tiles too.

Other idea could be to estimate full content of a tile on border, adding
a number of nodes proportional to area outside bounding polygon. This
won't be precise but I guess quite easy to implement.

In my case simplification of bounding polygon was sufficient to get
usable split.

--
Best regards,
Andrzej
___
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

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-05 Thread Andrzej Popowski


Hi Gerd,


I don't yet have a solution, I just know that the current approach
is not okay.


No easy solution. I think maybe the best would be to trim border tiles 
according to bounding polygon. This could be suitable for irregular 
tiles too.


Other idea could be to estimate full content of a tile on border, adding 
a number of nodes proportional to area outside bounding polygon. This 
won't be precise but I guess quite easy to implement.


In my case simplification of bounding polygon was sufficient to get 
usable split.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-05 Thread Gerd Petermann

Hi Andrzej,

I think I understand now what the problem is,
and I also think that the high resolution is making it worse.
The current algo in fact ignores node counts outside the polygon,
the higher the resolution the smaller the grid areas and the more
data outside the polygon is ignored. 
I don't yet have a solution, I just know that the current approach is not okay. 

Gerd  


Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski 
<po...@poczta.onet.pl>
Gesendet: Samstag, 5. März 2016 20:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon

Hi Gerd,

I observe the same problem using standard extract of North America
http://download.geofabrik.de/north-america-latest.osm.pbf

I have packed my batches and splitter output (densities, areas) into an
archive:
http://files.mkgmap.org.uk/download/292/split-poly2.7z

I have used splitter r428 and mkgmap 3669.

I hope you can repeat it with current extract, it shouldn't be much
different. I got some tiles with size like 30-60MB, 2 of them didn't
compile with mkgmap. Average size of tiles was about 12MB.

--
Best regards,
Andrzej
___
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

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-05 Thread Andrzej Popowski


Hi Gerd,

I observe the same problem using standard extract of North America
http://download.geofabrik.de/north-america-latest.osm.pbf

I have packed my batches and splitter output (densities, areas) into an 
archive:

http://files.mkgmap.org.uk/download/292/split-poly2.7z

I have used splitter r428 and mkgmap 3669.

I hope you can repeat it with current extract, it shouldn't be much 
different. I got some tiles with size like 30-60MB, 2 of them didn't 
compile with mkgmap. Average size of tiles was about 12MB.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-03 Thread Gerd Petermann

Hi Andrzej,

okay, I understand. If you can reproducde it with the large
file I'd still like to check that.

Gerd


Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski 
<po...@poczta.onet.pl>
Gesendet: Donnerstag, 3. März 2016 19:56
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon

Hi Gerd,

I can't repeat the problem on smaller extracts. The problem is not so
important, I would leave it for now, unless it reappear on easier to
track dataset.

--
Best regards,
Andrzej
___
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

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-03 Thread Andrzej Popowski


Hi Gerd,

I can't repeat the problem on smaller extracts. The problem is not so 
important, I would leave it for now, unless it reappear on easier to 
track dataset.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-01 Thread Gerd Petermann

Hi Andrzej,

interesting, seems you are using a very high resolution value,
else the densities-out.txt should be much smaller. 
With resolution 13 the latest planet file produced a file with ~ 61MB (zipped 
~18MB)
Maybe this is part of the problem...

Gerd


Von: mkgmap-dev-boun...@lists.mkgmap.org.uk 
<mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski 
<po...@poczta.onet.pl>
Gesendet: Mittwoch, 2. März 2016 08:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] problem with splitter and bounding polygon

Hi Gerd,

thanks for your interest. That was split for 7GB custom pbf,
densities-out.txt was over 1GB. I will try to prepare some small subset
for test.

--
Best regards,
Andrzej
___
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

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-01 Thread Andrzej Popowski


Hi Gerd,

thanks for your interest. That was split for 7GB custom pbf, 
densities-out.txt was over 1GB. I will try to prepare some small subset 
for test.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-01 Thread Gerd Petermann

Hi Andrzej,

I'll try to reproduce the problem. Please provide details regarding the
splitter options, the poly file,
and the densities-out.txt written by splitter. 

Gerd


popej wrote
> Hi,
> 
> I'm trying to compile a map of USA using North America extract form 
> Geofabrik. I use splitter r427 with bounding polygon, something like that:
> 
> splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf
> 
> The result is that I get errors in mkgmap:
> SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in 
> BufferedImgFileWriter.ensureSize()) There is not enough room in a single 
> garmin map for all the input data. The .osm file should be split into 
> smaller pieces first.
> 
> This error appears for some tiles at the map border.
> 
> My guess is, that splitter uses only nodes inside bounding poly to 
> compute tiles sizes. When a rectangular tile is placed on a polygon 
> border, estimated node number could be significantly smaller than the 
> full number actually saved in this tile. This could lead to problems as 
> above.
> 
> I don't have any suggestions for a solution, so I'm going to try to go 
> around it using a simplified poly. I hope, that maybe someone could get 
> an idea how to correct it.
> 
> -- 
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/problem-with-splitter-and-bounding-polygon-tp5868839p5868847.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] problem with splitter and bounding polygon

2016-03-01 Thread Carlos Dávila


El 01/03/16 a las 22:23, Andrzej Popowski escribió:

Hi,

I'm trying to compile a map of USA using North America extract form 
Geofabrik. I use splitter r427 with bounding polygon, something like 
that:


splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf

The result is that I get errors in mkgmap:
SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in 
BufferedImgFileWriter.ensureSize()) There is not enough room in a 
single garmin map for all the input data. The .osm file should be 
split into smaller pieces first.


This error appears for some tiles at the map border.

My guess is, that splitter uses only nodes inside bounding poly to 
compute tiles sizes. When a rectangular tile is placed on a polygon 
border, estimated node number could be significantly smaller than the 
full number actually saved in this tile. This could lead to problems 
as above.


I don't have any suggestions for a solution, so I'm going to try to go 
around it using a simplified poly. I hope, that maybe someone could 
get an idea how to correct it.



Did you try reducing --max-nodes value?

--
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, 
.ppt, .pptx, .mdb, mdbx
Instale LibreOffice desde http://es.libreoffice.org/descarga/
LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. 
Gratis y totalmente legal.
LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas 
versiones.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] problem with splitter and bounding polygon

2016-03-01 Thread Andrzej Popowski


Hi,

I'm trying to compile a map of USA using North America extract form 
Geofabrik. I use splitter r427 with bounding polygon, something like that:


splitter --polygon-file=usa.poly ... north-america-latest.osm.pbf

The result is that I get errors in mkgmap:
SEVERE (MapFailedException): pbf\29729241.osm.pbf: (thrown in 
BufferedImgFileWriter.ensureSize()) There is not enough room in a single 
garmin map for all the input data. The .osm file should be split into 
smaller pieces first.


This error appears for some tiles at the map border.

My guess is, that splitter uses only nodes inside bounding poly to 
compute tiles sizes. When a rectangular tile is placed on a polygon 
border, estimated node number could be significantly smaller than the 
full number actually saved in this tile. This could lead to problems as 
above.


I don't have any suggestions for a solution, so I'm going to try to go 
around it using a simplified poly. I hope, that maybe someone could get 
an idea how to correct it.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-07 Thread GerdP

Hi all,

I've committed r417 to fix a few rare problems in splitter:
1) The initial problem reported by Stephen:
splitter printed Warning: No solution found for partition ... but did not
stop when at least one partition was ok.
2) It tries a bit harder to find a solution when it turns out
that no good solution is found.
3) It prints a warning when the user choses a rather bad combination
of --max-nodes and --resolution.

I've also removed the code that optimized parts of a solution,
it did not really work in most cases. I'll try to find a solution for that
again
later.

Gerd


GerdP wrote
 Hi Steve,
 
 I suggest to look at the rules in the default style and the style 
 manual:
 http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
 
 I am not that familiar with style rules, and I prefer java coding.
 
 Gerd
 
 Date: Wed, 7 Jan 2015 17:15:59 +1000
 From: 

 steve.sgalowski@

 To: 

 mkgmap-dev@.org

 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
 
 gerd p would love more on the routing mate in my map but when i tried
 before to upgrade the script file , it did not work may be i send the
 script file i use ,  so you can help me convert it over to the new
 scripting you do mate 
 or provide me with plenty of examples and i can try gerd 
 stephen 
 
 On Wed, Jan 7, 2015 at 5:11 PM, Gerd Petermann lt;

 gpetermann_muenchen@

 gt; wrote:
 
 
 
 Hi Stephen,
 
 okay, I forgot to ask you about other details:
 1) You use options like --process-exits and other used for routing, but
 your
 style doesn't set any of the access attributes like mkgmap:car,
 mkgmap:foot etc
 which are needed to get proper routing info in the map.
 I guess you don't care about routing?
 
 2) Your cmd file contains the option --pois-to-areas-placement=tagelist 
 I think this is a very old typo which overrides a good default:
 pois-to-areas-placement=entrance=main;entrance=yes;building=entrance
 
 Please check the docu about the meaning:
 http://www.mkgmap.org.uk/doc/options
 
 Gerd
 
 Date: Wed, 7 Jan 2015 16:57:41 +1000
 From: 

 steve.sgalowski@

 To: 

 mkgmap-dev@.org

 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
 
 gerd , have tried some of your ideas no not all worked for me however have
 worked out and are combining my poi strings am re checking now with the
 new poi test file you have just uploaded to mkgmap server 
 stephen 
 
 On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann lt;

 gpetermann_muenchen@

 gt; wrote:
 
 
 
 Hi Stephen,
 
 yes, you should have received an answer a now.
 
 Gerd
 
 Date: Tue, 6 Jan 2015 19:15:51 +1000
 From: 

 steve.sgalowski@

 To: 

 mkgmap-dev@.org

 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)
 
 gerd P 
 did you get my direct e-mail to you sir 
 stephen 
 
 On Tue, Jan 6, 2015 at 10:18 AM, GerdP lt;

 gpetermann_muenchen@

 gt; wrote:
 Hi Stephen,
 
 
 
 the log shows no problems. Why do you think that max-nodes=40 doesn't
 
 work?
 
 Do you see an error message in mkgmap?
 
 If yes, please provide your style files so that I can reproduce the
 problem.
 
 Maybe your style still adds one POI for each point of each highway?
 
 
 
 Gerd
 
 
 
 
 
 steve sgalowski wrote
 
 canada splitter log file
 
 as expected ,  looks like i was correct
 
 the size of the split has to be smaller
 
 stephen
 

 
 On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 
 
 
 
 cdavilam@
 
 
 
 
 
 wrote:
 

 
 Final file size depends on the amount of data in the input, not on the
 
 value of max-nodes. If you need a final img smaller than a given size
 you
 
 have to reduce the area covered by the input file or reduce the number
 of
 
 osm elements from the input that go into the map playing with your style
 
 files.
 

 
 El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 

 
 gerd and carlos
 
 i am now running the splitter log file setup on my canada map
 
 and see what it does , the end result on this map = 6.8 gb img file
 
 wonder why some country can exceed and others not
 
 stephen
 

 

 
 On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 
 
 
 
 cdavilam@
 
 
 
  
 mailto:
 
 
 

  cdavilam@
 
 
 
  wrote:
 

 
 Not sure what you mean. If you split a given country in a higher
 
 number of tiles (lower max-nodes) final size will be the same or
 
 slightly bigger, as there are more duplicated info due to overlap.
 
 Or you are loosing some information in the process to reduce final
 
 file size.
 

 
 El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 

 
 in some of the countries i do , if i dont make the node count
 
 small , the map size exceedds , size limit of 3 gb
 
 then unshure how , canada has done this ok
 

 
 stephen
 

 

 
 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
 
 
 
 
 
 gpetermann_muenchen@
 
 
 
  
 mailto:
 
 
 

  gpetermann_muenchen@
 
 
 
 
 
 
 mailto:
 
 
 

  gpetermann_muenchen@
 
 
 
  
 mailto:
 
 
 

  gpetermann_muenchen@
 
 
 
  wrote:
 

 
 Hi all

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-06 Thread Gerd Petermann

Hi Stephen,

yes, you should have received an answer a now.

Gerd

Date: Tue, 6 Jan 2015 19:15:51 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd P 
did you get my direct e-mail to you sir 
stephen 

On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com wrote:
Hi Stephen,



the log shows no problems. Why do you think that max-nodes=40 doesn't

work?

Do you see an error message in mkgmap?

If yes, please provide your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

 canada splitter log file

 as expected ,  looks like i was correct

 the size of the split has to be smaller

 stephen



 On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 



 cdavilam@



 

 wrote:



 Final file size depends on the amount of data in the input, not on the

 value of max-nodes. If you need a final img smaller than a given size you

 have to reduce the area covered by the input file or reduce the number of

 osm elements from the input that go into the map playing with your style

 files.



 El 05/01/15 a las 22:07, Steve Sgalowski escribió:



 gerd and carlos

 i am now running the splitter log file setup on my canada map

 and see what it does , the end result on this map = 6.8 gb img file

 wonder why some country can exceed and others not

 stephen





 On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 



 cdavilam@



  mailto:



 cdavilam@



  wrote:



 Not sure what you mean. If you split a given country in a higher

 number of tiles (lower max-nodes) final size will be the same or

 slightly bigger, as there are more duplicated info due to overlap.

 Or you are loosing some information in the process to reduce final

 file size.



 El 05/01/15 a las 21:34, Steve Sgalowski escribió:



 in some of the countries i do , if i dont make the node count

 small , the map size exceedds , size limit of 3 gb

 then unshure how , canada has done this ok



 stephen





 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

 



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



 

 mailto:



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



  wrote:



 Hi all,



 I wonder what splitter should do in this case:



 Stephen uses paramter --max-nodes=8

 and splitter reports

 Highest node count in a single grid element is 557,084



 It is obvious that at least one tile will have much more

 than the

 requested 80.000 nodes,

 on the other hand, the file africa.osm.pbf contains large

 nearly

 empty areas,

 and that makes it very difficult to find a good split.

 The current version r416 fails because it doesn't accept

 tiles

 with less than 5% of

 the max-nodes value, so it searches for a solution where

 every

 tile has at least 4000 nodes,

 and that might not exist.



 I see these options:

 1) splitter can continue trying to split the data, accepting

 almost empty output files

 (e.g. some with  5 nodes and very high aspect ratios like

 32)

 2) if that fails,  splitter can set the max-nodes value to

 557,084

 and try again

 3) or stop with an error message that tells the user that

 it is

 not possible

 to split with the used resolution

 4) or restart using a higher resolution  (15 would be

 required

 here instead of 13),



 @Stephen

 What reason do you have to use such a small max-nodes value?

 Would it be ok for you to use a higher one?



 Gerd





 ___

 mkgmap-dev mailing list





 mkgmap-dev@.org



 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





 ___

 mkgmap-dev mailing list



 mkgmap-dev@.org



 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



 splitter.log (356K)

 http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log











--

View this message in context: 
http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html

Sent from the Mkgmap Development mailing list archive at Nabble.com.

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

yes gerd p i did
will try it ok gerd p
ty
stephen


On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Stephen,

 yes, you should have received an answer a now.

 Gerd

 --
 Date: Tue, 6 Jan 2015 19:15:51 +1000
 From: steve.sgalow...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

 gerd P

 did you get my direct e-mail to you sir

 stephen


 On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
 wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like
  32)
  2) if that fails,  splitter can set the max-nodes value to
  557,084
  and try again
  3) or stop with an error message that tells the user that
  it is
  not possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be
  required
  here instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes
 value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
  splitter.log (356K)
  http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

gerd P

did you get my direct e-mail to you sir

stephen


On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like
  32)
  2) if that fails,  splitter can set the max-nodes value to
  557,084
  and try again
  3) or stop with an error message that tells the user that
  it is
  not possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be
  required
  here instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes
 value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
  splitter.log (356K)
  http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

gerd , have tried some of your ideas
no not all worked for me
however have worked out and are combining my poi strings
am re checking now with the new poi test file you have just uploaded to
mkgmap server

stephen


On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Stephen,

 yes, you should have received an answer a now.

 Gerd

 --
 Date: Tue, 6 Jan 2015 19:15:51 +1000
 From: steve.sgalow...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

 gerd P

 did you get my direct e-mail to you sir

 stephen


 On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
 wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like
  32)
  2) if that fails,  splitter can set the max-nodes value to
  557,084
  and try again
  3) or stop with an error message that tells the user that
  it is
  not possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be
  required
  here instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes
 value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
  splitter.log (356K)
  http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-06 Thread Gerd Petermann

Hi Stephen,

okay, I forgot to ask you about other details:
1) You use options like --process-exits and other used for routing, but your
style doesn't set any of the access attributes like mkgmap:car, mkgmap:foot etc
which are needed to get proper routing info in the map.
I guess you don't care about routing?

2) Your cmd file contains the option --pois-to-areas-placement=tagelist 
I think this is a very old typo which overrides a good default:
pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

Please check the docu about the meaning:
http://www.mkgmap.org.uk/doc/options

Gerd

Date: Wed, 7 Jan 2015 16:57:41 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd , have tried some of your ideas no not all worked for me however have 
worked out and are combining my poi strings am re checking now with the new poi 
test file you have just uploaded to mkgmap server 
stephen 

On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Stephen,

yes, you should have received an answer a now.

Gerd

Date: Tue, 6 Jan 2015 19:15:51 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd P 
did you get my direct e-mail to you sir 
stephen 

On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com wrote:
Hi Stephen,



the log shows no problems. Why do you think that max-nodes=40 doesn't

work?

Do you see an error message in mkgmap?

If yes, please provide your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

 canada splitter log file

 as expected ,  looks like i was correct

 the size of the split has to be smaller

 stephen



 On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 



 cdavilam@



 

 wrote:



 Final file size depends on the amount of data in the input, not on the

 value of max-nodes. If you need a final img smaller than a given size you

 have to reduce the area covered by the input file or reduce the number of

 osm elements from the input that go into the map playing with your style

 files.



 El 05/01/15 a las 22:07, Steve Sgalowski escribió:



 gerd and carlos

 i am now running the splitter log file setup on my canada map

 and see what it does , the end result on this map = 6.8 gb img file

 wonder why some country can exceed and others not

 stephen





 On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 



 cdavilam@



  mailto:



 cdavilam@



  wrote:



 Not sure what you mean. If you split a given country in a higher

 number of tiles (lower max-nodes) final size will be the same or

 slightly bigger, as there are more duplicated info due to overlap.

 Or you are loosing some information in the process to reduce final

 file size.



 El 05/01/15 a las 21:34, Steve Sgalowski escribió:



 in some of the countries i do , if i dont make the node count

 small , the map size exceedds , size limit of 3 gb

 then unshure how , canada has done this ok



 stephen





 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

 



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



 

 mailto:



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



  wrote:



 Hi all,



 I wonder what splitter should do in this case:



 Stephen uses paramter --max-nodes=8

 and splitter reports

 Highest node count in a single grid element is 557,084



 It is obvious that at least one tile will have much more

 than the

 requested 80.000 nodes,

 on the other hand, the file africa.osm.pbf contains large

 nearly

 empty areas,

 and that makes it very difficult to find a good split.

 The current version r416 fails because it doesn't accept

 tiles

 with less than 5% of

 the max-nodes value, so it searches for a solution where

 every

 tile has at least 4000 nodes,

 and that might not exist.



 I see these options:

 1) splitter can continue trying to split the data, accepting

 almost empty output files

 (e.g. some with  5 nodes and very high aspect ratios like

 32)

 2) if that fails,  splitter can set the max-nodes value to

 557,084

 and try again

 3) or stop with an error message that tells the user that

 it is

 not possible

 to split with the used resolution

 4) or restart using a higher resolution  (15 would be

 required

 here instead of 13),



 @Stephen

 What reason do you have

Re: [mkgmap-dev] Problem in splitter (Africa)

gerd p
would love more on the routing mate in my map
but when i tried before to upgrade the script file , it did not work
may be i send the script file i use ,  so you can help me convert it over
to the new scripting you do mate

or provide me with plenty of examples and i can try gerd

stephen


On Wed, Jan 7, 2015 at 5:11 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi Stephen,

 okay, I forgot to ask you about other details:
 1) You use options like --process-exits and other used for routing, but
 your
 style doesn't set any of the access attributes like mkgmap:car,
 mkgmap:foot etc
 which are needed to get proper routing info in the map.
 I guess you don't care about routing?

 2) Your cmd file contains the option --pois-to-areas-placement=tagelist
 I think this is a very old typo which overrides a good default:
 pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

 Please check the docu about the meaning:
 http://www.mkgmap.org.uk/doc/options

 Gerd

 --
 Date: Wed, 7 Jan 2015 16:57:41 +1000
 From: steve.sgalow...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

 gerd , have tried some of your ideas
 no not all worked for me
 however have worked out and are combining my poi strings
 am re checking now with the new poi test file you have just uploaded to
 mkgmap server

 stephen


 On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com wrote:

 Hi Stephen,

 yes, you should have received an answer a now.

 Gerd

 --
 Date: Tue, 6 Jan 2015 19:15:51 +1000
 From: steve.sgalow...@gmail.com
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

 gerd P

 did you get my direct e-mail to you sir

 stephen


 On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
 wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-06 Thread Gerd Petermann

Hi Steve,

I suggest to look at the rules in the default style and the style 
manual:
http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf

I am not that familiar with style rules, and I prefer java coding.

Gerd

Date: Wed, 7 Jan 2015 17:15:59 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd p would love more on the routing mate in my map but when i tried before to 
upgrade the script file , it did not work may be i send the script file i use , 
 so you can help me convert it over to the new scripting you do mate 
or provide me with plenty of examples and i can try gerd 
stephen 

On Wed, Jan 7, 2015 at 5:11 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Stephen,

okay, I forgot to ask you about other details:
1) You use options like --process-exits and other used for routing, but your
style doesn't set any of the access attributes like mkgmap:car, mkgmap:foot etc
which are needed to get proper routing info in the map.
I guess you don't care about routing?

2) Your cmd file contains the option --pois-to-areas-placement=tagelist 
I think this is a very old typo which overrides a good default:
pois-to-areas-placement=entrance=main;entrance=yes;building=entrance

Please check the docu about the meaning:
http://www.mkgmap.org.uk/doc/options

Gerd

Date: Wed, 7 Jan 2015 16:57:41 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd , have tried some of your ideas no not all worked for me however have 
worked out and are combining my poi strings am re checking now with the new poi 
test file you have just uploaded to mkgmap server 
stephen 

On Tue, Jan 6, 2015 at 7:54 PM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:



Hi Stephen,

yes, you should have received an answer a now.

Gerd

Date: Tue, 6 Jan 2015 19:15:51 +1000
From: steve.sgalow...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Problem in splitter (Africa)

gerd P 
did you get my direct e-mail to you sir 
stephen 

On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com wrote:
Hi Stephen,



the log shows no problems. Why do you think that max-nodes=40 doesn't

work?

Do you see an error message in mkgmap?

If yes, please provide your style files so that I can reproduce the problem.

Maybe your style still adds one POI for each point of each highway?



Gerd





steve sgalowski wrote

 canada splitter log file

 as expected ,  looks like i was correct

 the size of the split has to be smaller

 stephen



 On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 



 cdavilam@



 

 wrote:



 Final file size depends on the amount of data in the input, not on the

 value of max-nodes. If you need a final img smaller than a given size you

 have to reduce the area covered by the input file or reduce the number of

 osm elements from the input that go into the map playing with your style

 files.



 El 05/01/15 a las 22:07, Steve Sgalowski escribió:



 gerd and carlos

 i am now running the splitter log file setup on my canada map

 and see what it does , the end result on this map = 6.8 gb img file

 wonder why some country can exceed and others not

 stephen





 On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 



 cdavilam@



  mailto:



 cdavilam@



  wrote:



 Not sure what you mean. If you split a given country in a higher

 number of tiles (lower max-nodes) final size will be the same or

 slightly bigger, as there are more duplicated info due to overlap.

 Or you are loosing some information in the process to reduce final

 file size.



 El 05/01/15 a las 21:34, Steve Sgalowski escribió:



 in some of the countries i do , if i dont make the node count

 small , the map size exceedds , size limit of 3 gb

 then unshure how , canada has done this ok



 stephen





 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann

 



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



 

 mailto:



 gpetermann_muenchen@



  mailto:



 gpetermann_muenchen@



  wrote:



 Hi all,



 I wonder what splitter should do in this case:



 Stephen uses paramter --max-nodes=8

 and splitter reports

 Highest node count in a single grid element is 557,084



 It is obvious that at least one tile will have much more

 than the

 requested 80.000 nodes,

 on the other hand, the file africa.osm.pbf contains large

 nearly

 empty areas,

 and that makes it very difficult to find a good split.

 The current version r416 fails because it doesn't accept

 tiles

 with less than 5% of

 the max-nodes value, so it searches for a solution where

 every

Re: [mkgmap-dev] Problem in splitter (Africa)

gerd p

under stood mate , but why does it only happen to this one , but when i
change others max nodes it is all ok

i will send the style files i use ,

stephen


On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like
  32)
  2) if that fails,  splitter can set the max-nodes value to
  557,084
  and try again
  3) or stop with an error message that tells the user that
  it is
  not possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be
  required
  here instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes
 value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
  splitter.log (356K)
  http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-05 Thread GerdP

Hi Stephen,

the log shows no problems. Why do you think that max-nodes=40 doesn't
work?
Do you see an error message in mkgmap?
If yes, please provide your style files so that I can reproduce the problem.
Maybe your style still adds one POI for each point of each highway?

Gerd


steve sgalowski wrote
 canada splitter log file
 as expected ,  looks like i was correct
 the size of the split has to be smaller
 stephen
 
 On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila lt;

 cdavilam@

 gt;
 wrote:
 
 Final file size depends on the amount of data in the input, not on the
 value of max-nodes. If you need a final img smaller than a given size you
 have to reduce the area covered by the input file or reduce the number of
 osm elements from the input that go into the map playing with your style
 files.

 El 05/01/15 a las 22:07, Steve Sgalowski escribió:

 gerd and carlos
 i am now running the splitter log file setup on my canada map
 and see what it does , the end result on this map = 6.8 gb img file
 wonder why some country can exceed and others not
 stephen


 On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila lt;

 cdavilam@

 gt; lt;mailto:

 cdavilam@

 gt; wrote:

 Not sure what you mean. If you split a given country in a higher
 number of tiles (lower max-nodes) final size will be the same or
 slightly bigger, as there are more duplicated info due to overlap.
 Or you are loosing some information in the process to reduce final
 file size.

 El 05/01/15 a las 21:34, Steve Sgalowski escribió:

 in some of the countries i do , if i dont make the node count
 small , the map size exceedds , size limit of 3 gb
 then unshure how , canada has done this ok

 stephen


 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
 lt;

 gpetermann_muenchen@

 gt; lt;mailto:

 gpetermann_muenchen@

 gt;
 lt;mailto:

 gpetermann_muenchen@

 gt; lt;mailto:

 gpetermann_muenchen@

 gt; wrote:

 Hi all,

 I wonder what splitter should do in this case:

 Stephen uses paramter --max-nodes=8
 and splitter reports
 Highest node count in a single grid element is 557,084

 It is obvious that at least one tile will have much more
 than the
 requested 80.000 nodes,
 on the other hand, the file africa.osm.pbf contains large
 nearly
 empty areas,
 and that makes it very difficult to find a good split.
 The current version r416 fails because it doesn't accept
 tiles
 with less than 5% of
 the max-nodes value, so it searches for a solution where
 every
 tile has at least 4000 nodes,
 and that might not exist.

 I see these options:
 1) splitter can continue trying to split the data, accepting
 almost empty output files
 (e.g. some with  5 nodes and very high aspect ratios like
 32)
 2) if that fails,  splitter can set the max-nodes value to
 557,084
 and try again
 3) or stop with an error message that tells the user that
 it is
 not possible
 to split with the used resolution
 4) or restart using a higher resolution  (15 would be
 required
 here instead of 13),

 @Stephen
 What reason do you have to use such a small max-nodes value?
 Would it be ok for you to use a higher one?

 Gerd


 ___
 mkgmap-dev mailing list
 

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 splitter.log (356K)
 lt;http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.loggt;





--
View this message in context: 
http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

i will send theat gerd , when i get back home
error msg was that , there is not enough room in a single file to hold all
must split file into smaller sizes

that is why i cut down max nodes  per a file

stephen


On Tue, Jan 6, 2015 at 10:18 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:

 Hi Stephen,

 the log shows no problems. Why do you think that max-nodes=40 doesn't
 work?
 Do you see an error message in mkgmap?
 If yes, please provide your style files so that I can reproduce the
 problem.
 Maybe your style still adds one POI for each point of each highway?

 Gerd


 steve sgalowski wrote
  canada splitter log file
  as expected ,  looks like i was correct
  the size of the split has to be smaller
  stephen
 
  On Tue, Jan 6, 2015 at 7:25 AM, Carlos Dávila 

  cdavilam@

  
  wrote:
 
  Final file size depends on the amount of data in the input, not on the
  value of max-nodes. If you need a final img smaller than a given size
 you
  have to reduce the area covered by the input file or reduce the number
 of
  osm elements from the input that go into the map playing with your style
  files.
 
  El 05/01/15 a las 22:07, Steve Sgalowski escribió:
 
  gerd and carlos
  i am now running the splitter log file setup on my canada map
  and see what it does , the end result on this map = 6.8 gb img file
  wonder why some country can exceed and others not
  stephen
 
 
  On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 

  cdavilam@

   mailto:

  cdavilam@

   wrote:
 
  Not sure what you mean. If you split a given country in a higher
  number of tiles (lower max-nodes) final size will be the same or
  slightly bigger, as there are more duplicated info due to overlap.
  Or you are loosing some information in the process to reduce final
  file size.
 
  El 05/01/15 a las 21:34, Steve Sgalowski escribió:
 
  in some of the countries i do , if i dont make the node count
  small , the map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
  

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

  
  mailto:

  gpetermann_muenchen@

   mailto:

  gpetermann_muenchen@

   wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more
  than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large
  nearly
  empty areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept
  tiles
  with less than 5% of
  the max-nodes value, so it searches for a solution where
  every
  tile has at least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data,
 accepting
  almost empty output files
  (e.g. some with  5 nodes and very high aspect ratios like
  32)
  2) if that fails,  splitter can set the max-nodes value to
  557,084
  and try again
  3) or stop with an error message that tells the user that
  it is
  not possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be
  required
  here instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes
 value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
  splitter.log (356K)
  http://gis.19327.n5.nabble.com/attachment/5829156/0/splitter.log





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829158.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

in some of the countries i do , if i dont make the node count small , the
map size exceedds , size limit of 3 gb
then unshure how , canada has done this ok

stephen


On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com wrote:

 Hi all,

 I wonder what splitter should do in this case:

 Stephen uses paramter --max-nodes=8
 and splitter reports
 Highest node count in a single grid element is 557,084

 It is obvious that at least one tile will have much more than the
 requested 80.000 nodes,
 on the other hand, the file africa.osm.pbf contains large nearly empty
 areas,
 and that makes it very difficult to find a good split.
 The current version r416 fails because it doesn't accept tiles with less
 than 5% of
 the max-nodes value, so it searches for a solution where every tile has at
 least 4000 nodes,
 and that might not exist.

 I see these options:
 1) splitter can continue trying to split the data, accepting almost empty
 output files
 (e.g. some with  5 nodes and very high aspect ratios like 32)
 2) if that fails,  splitter can set the max-nodes value to 557,084 and try
 again
 3) or stop with an error message that tells the user that it is not
 possible
 to split with the used resolution
 4) or restart using a higher resolution  (15 would be required here
 instead of 13),

 @Stephen
 What reason do you have to use such a small max-nodes value?
 Would it be ok for you to use a higher one?

 Gerd





 ___
 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] Problem in splitter (Africa)

2015-01-05 Thread Gerd Petermann

Hi all,

I wonder what splitter should do in this case:

Stephen uses paramter --max-nodes=8 
and splitter reports 
Highest node count in a single grid element is 557,084

It is obvious that at least one tile will have much more than the requested 
80.000 nodes,
on the other hand, the file africa.osm.pbf contains large nearly empty areas,
and that makes it very difficult to find a good split.
The current version r416 fails because it doesn't accept tiles with less than 
5% of 
the max-nodes value, so it searches for a solution where every tile has at 
least 4000 nodes,
and that might not exist.

I see these options:
1) splitter can continue trying to split the data, accepting almost empty 
output files
(e.g. some with  5 nodes and very high aspect ratios like 32)
2) if that fails,  splitter can set the max-nodes value to 557,084 and try again
3) or stop with an error message that tells the user that it is not possible
to split with the used resolution
4) or restart using a higher resolution  (15 would be required here instead of 
13),

@Stephen
What reason do you have to use such a small max-nodes value? 
Would it be ok for you to use a higher one?

Gerd




  ___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-05 Thread Carlos Dávila

Not sure what you mean. If you split a given country in a higher number 
of tiles (lower max-nodes) final size will be the same or slightly 
bigger, as there are more duplicated info due to overlap. Or you are 
loosing some information in the process to reduce final file size.


El 05/01/15 a las 21:34, Steve Sgalowski escribió:
in some of the countries i do , if i dont make the node count small , 
the map size exceedds , size limit of 3 gb

then unshure how , canada has done this ok

stephen


On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann 
gpetermann_muenc...@hotmail.com 
mailto:gpetermann_muenc...@hotmail.com wrote:


Hi all,

I wonder what splitter should do in this case:

Stephen uses paramter --max-nodes=8
and splitter reports
Highest node count in a single grid element is 557,084

It is obvious that at least one tile will have much more than the
requested 80.000 nodes,
on the other hand, the file africa.osm.pbf contains large nearly
empty areas,
and that makes it very difficult to find a good split.
The current version r416 fails because it doesn't accept tiles
with less than 5% of
the max-nodes value, so it searches for a solution where every
tile has at least 4000 nodes,
and that might not exist.

I see these options:
1) splitter can continue trying to split the data, accepting
almost empty output files
(e.g. some with  5 nodes and very high aspect ratios like 32)
2) if that fails,  splitter can set the max-nodes value to 557,084
and try again
3) or stop with an error message that tells the user that it is
not possible
to split with the used resolution
4) or restart using a higher resolution  (15 would be required
here instead of 13),

@Stephen
What reason do you have to use such a small max-nodes value?
Would it be ok for you to use a higher one?

Gerd




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

gerd and carlos
i am now running the splitter log file setup on my canada map
and see what it does , the end result on this map = 6.8 gb img file
wonder why some country can exceed and others not
stephen


On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila cdavi...@orangecorreo.es
wrote:

 Not sure what you mean. If you split a given country in a higher number of
 tiles (lower max-nodes) final size will be the same or slightly bigger, as
 there are more duplicated info due to overlap. Or you are loosing some
 information in the process to reduce final file size.

 El 05/01/15 a las 21:34, Steve Sgalowski escribió:

 in some of the countries i do , if i dont make the node count small , the
 map size exceedds , size limit of 3 gb
 then unshure how , canada has done this ok

 stephen


 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann 
 gpetermann_muenc...@hotmail.com mailto:gpetermann_muenc...@hotmail.com
 wrote:

 Hi all,

 I wonder what splitter should do in this case:

 Stephen uses paramter --max-nodes=8
 and splitter reports
 Highest node count in a single grid element is 557,084

 It is obvious that at least one tile will have much more than the
 requested 80.000 nodes,
 on the other hand, the file africa.osm.pbf contains large nearly
 empty areas,
 and that makes it very difficult to find a good split.
 The current version r416 fails because it doesn't accept tiles
 with less than 5% of
 the max-nodes value, so it searches for a solution where every
 tile has at least 4000 nodes,
 and that might not exist.

 I see these options:
 1) splitter can continue trying to split the data, accepting
 almost empty output files
 (e.g. some with  5 nodes and very high aspect ratios like 32)
 2) if that fails,  splitter can set the max-nodes value to 557,084
 and try again
 3) or stop with an error message that tells the user that it is
 not possible
 to split with the used resolution
 4) or restart using a higher resolution  (15 would be required
 here instead of 13),

 @Stephen
 What reason do you have to use such a small max-nodes value?
 Would it be ok for you to use a higher one?

 Gerd



 ___
 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

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-05 Thread GerdP

Hi Stephen,

last year mkgmap failed for a tile in Canada because of 
a special case, see my post:
http://gis.19327.n5.nabble.com/ontario-canada-maps-tp5798080p5798490.html

At that time I changed mkgmap so that it doesn't
generate as many POI for these ways, and maybe later
we also changed the split algo in mkgmap to 
avoid this problem.
I think there is no good reason to use a very small --max-nodes
value when you plan to create a map for a country
or continent. It may be useful for the new devices with only
8 MB on a memory card.

Gerd


steve sgalowski wrote
 in some of the countries i do , if i dont make the node count small , the
 map size exceedds , size limit of 3 gb
 then unshure how , canada has done this ok
 
 stephen
 
 
 On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann 

 gpetermann_muenchen@

 wrote:
 
 Hi all,

 I wonder what splitter should do in this case:

 Stephen uses paramter --max-nodes=8
 and splitter reports
 Highest node count in a single grid element is 557,084

 It is obvious that at least one tile will have much more than the
 requested 80.000 nodes,
 on the other hand, the file africa.osm.pbf contains large nearly empty
 areas,
 and that makes it very difficult to find a good split.
 The current version r416 fails because it doesn't accept tiles with less
 than 5% of
 the max-nodes value, so it searches for a solution where every tile has
 at
 least 4000 nodes,
 and that might not exist.

 I see these options:
 1) splitter can continue trying to split the data, accepting almost empty
 output files
 (e.g. some with  5 nodes and very high aspect ratios like 32)
 2) if that fails,  splitter can set the max-nodes value to 557,084 and
 try
 again
 3) or stop with an error message that tells the user that it is not
 possible
 to split with the used resolution
 4) or restart using a higher resolution  (15 would be required here
 instead of 13),

 @Stephen
 What reason do you have to use such a small max-nodes value?
 Would it be ok for you to use a higher one?

 Gerd





 ___
 mkgmap-dev mailing list
 

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

 
 ___
 mkgmap-dev mailing list

 mkgmap-dev@.org

 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829141.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

i will run splitter log now on all my countries i need to update due to my
international work
and as done i will post accordingly

stephen


On Tue, Jan 6, 2015 at 7:14 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:

 Hi Stephen,

 last year mkgmap failed for a tile in Canada because of
 a special case, see my post:
 http://gis.19327.n5.nabble.com/ontario-canada-maps-tp5798080p5798490.html

 At that time I changed mkgmap so that it doesn't
 generate as many POI for these ways, and maybe later
 we also changed the split algo in mkgmap to
 avoid this problem.
 I think there is no good reason to use a very small --max-nodes
 value when you plan to create a map for a country
 or continent. It may be useful for the new devices with only
 8 MB on a memory card.

 Gerd


 steve sgalowski wrote
  in some of the countries i do , if i dont make the node count small , the
  map size exceedds , size limit of 3 gb
  then unshure how , canada has done this ok
 
  stephen
 
 
  On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann 

  gpetermann_muenchen@

  wrote:
 
  Hi all,
 
  I wonder what splitter should do in this case:
 
  Stephen uses paramter --max-nodes=8
  and splitter reports
  Highest node count in a single grid element is 557,084
 
  It is obvious that at least one tile will have much more than the
  requested 80.000 nodes,
  on the other hand, the file africa.osm.pbf contains large nearly empty
  areas,
  and that makes it very difficult to find a good split.
  The current version r416 fails because it doesn't accept tiles with less
  than 5% of
  the max-nodes value, so it searches for a solution where every tile has
  at
  least 4000 nodes,
  and that might not exist.
 
  I see these options:
  1) splitter can continue trying to split the data, accepting almost
 empty
  output files
  (e.g. some with  5 nodes and very high aspect ratios like 32)
  2) if that fails,  splitter can set the max-nodes value to 557,084 and
  try
  again
  3) or stop with an error message that tells the user that it is not
  possible
  to split with the used resolution
  4) or restart using a higher resolution  (15 would be required here
  instead of 13),
 
  @Stephen
  What reason do you have to use such a small max-nodes value?
  Would it be ok for you to use a higher one?
 
  Gerd
 
 
 
 
 
  ___
  mkgmap-dev mailing list
 

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
 
 
  ___
  mkgmap-dev mailing list

  mkgmap-dev@.org

  http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev





 --
 View this message in context:
 http://gis.19327.n5.nabble.com/Problem-in-splitter-Africa-tp5829130p5829141.html
 Sent from the Mkgmap Development mailing list archive at Nabble.com.
 ___
 mkgmap-dev mailing list
 mkgmap-dev@lists.mkgmap.org.uk
 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-05 Thread Carlos Dávila

Final file size depends on the amount of data in the input, not on the 
value of max-nodes. If you need a final img smaller than a given size 
you have to reduce the area covered by the input file or reduce the 
number of osm elements from the input that go into the map playing with 
your style files.


El 05/01/15 a las 22:07, Steve Sgalowski escribió:

gerd and carlos
i am now running the splitter log file setup on my canada map
and see what it does , the end result on this map = 6.8 gb img file
wonder why some country can exceed and others not
stephen


On Tue, Jan 6, 2015 at 7:00 AM, Carlos Dávila 
cdavi...@orangecorreo.es mailto:cdavi...@orangecorreo.es wrote:


Not sure what you mean. If you split a given country in a higher
number of tiles (lower max-nodes) final size will be the same or
slightly bigger, as there are more duplicated info due to overlap.
Or you are loosing some information in the process to reduce final
file size.

El 05/01/15 a las 21:34, Steve Sgalowski escribió:

in some of the countries i do , if i dont make the node count
small , the map size exceedds , size limit of 3 gb
then unshure how , canada has done this ok

stephen


On Tue, Jan 6, 2015 at 5:24 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com
mailto:gpetermann_muenc...@hotmail.com
mailto:gpetermann_muenc...@hotmail.com
mailto:gpetermann_muenc...@hotmail.com wrote:

Hi all,

I wonder what splitter should do in this case:

Stephen uses paramter --max-nodes=8
and splitter reports
Highest node count in a single grid element is 557,084

It is obvious that at least one tile will have much more
than the
requested 80.000 nodes,
on the other hand, the file africa.osm.pbf contains large
nearly
empty areas,
and that makes it very difficult to find a good split.
The current version r416 fails because it doesn't accept tiles
with less than 5% of
the max-nodes value, so it searches for a solution where every
tile has at least 4000 nodes,
and that might not exist.

I see these options:
1) splitter can continue trying to split the data, accepting
almost empty output files
(e.g. some with  5 nodes and very high aspect ratios like 32)
2) if that fails,  splitter can set the max-nodes value to
557,084
and try again
3) or stop with an error message that tells the user that
it is
not possible
to split with the used resolution
4) or restart using a higher resolution  (15 would be required
here instead of 13),

@Stephen
What reason do you have to use such a small max-nodes value?
Would it be ok for you to use a higher one?

Gerd



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem in splitter (Africa)

2015-01-05 Thread Andrzej Popowski


Hi Gerd,

 3) or stop with an error message that tells the user
 that it is not possible to split with the used resolution

Seems to be the best solution. Let user decide how to proceed.

You could include some advices in final message, but the choice of 
solution depends on user requirements, you can't always guess what they are.


--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

2014-10-20 Thread Gerd Petermann

Hi Patrik,

I have checked the data from geofabrik. The invalid (?)
bounds tag really is in the data (also in the *.osm.bz2 file)

I am not sure what to do with this.
I can change splitter to ignore invalid bounds,
but I think you should contact the guys at geofabrik
to correct the data.

Regarding the differences in the reported min/max values:
osmconvert reports correct values, the values reported by splitter
in the line starting Exact map coverage is 
depend on the bounds tag. If (valid) bounds were found,
they are used, if not, splitter also reports (and uses)
the real min/max values found in the nodes.

Gerd

 Date: Sun, 19 Oct 2014 15:58:02 +0200
 From: keenonki...@gmx.net
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf
 file
 
 Gents,
 
 We run into a problem with the splitter about invalid bbox area in pbf 
 file throwing the following error:
 java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
 (49.808900356292725,-179.95320081710815) to 
 (73.79793405532837,180.00049352645874)
 
 But this is sort of strange as osmconvert tells me different values for 
 the bbox. Additionally it has to be said that another file containing a 
 larger area (while containing the complete dataset of the file that 
 causes the trouble) works without troubles with the same call of 
 splitter and the same set of precompiled sea files and so on...
 
 Any help/comments would be appreciated
 
 More Details:
 
 The file triggering the problem:
 --
 http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf
 
 And here the call and the output of the splitter:
 --
 java -Xmx1536M -jar 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
  
 --max-threads=2 
 --geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip
  
 --no-trim 
 --precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
 --keep-complete=true --mapid=9861 --max-nodes=80 --output=xml 
 --output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
  
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
 Splitter version 412 compiled 2014-06-21T13:47:04+0100
 boundary-tags=use-exclude-list
 cache=
 description=
 geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip
 keep-complete=true
 mapid=9861
 max-areas=512
 max-nodes=80
 max-threads=2
 mixed=false
 no-trim=true
 num-tiles=
 output=xml
 output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
 overlap=auto
 polygon-desc-file=
 polygon-file=
 precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
 problem-file=
 problem-report=
 resolution=13
 search-limit=20
 split-file=
 status-freq=120
 stop-after=dist
 write-kml=
 Elapsed time: 0s   Memory: Current 479MB (5MB used, 474MB free) Max 1365MB
 Time started: Sun Oct 19 15:28:09 CEST 2014
 Map is being split for resolution 13:
   - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
   - areas are multiples of 0x800 map units wide and high
 Processing 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
 Bounding box -179.9532 49.8089 180.000502 73.797941
 java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
 (49.808900356292725,-179.95320081710815) to 
 (73.79793405532837,180.00049352645874)
  at 
 uk.me.parabola.splitter.BinaryMapParser.parse(BinaryMapParser.java:233)
  at crosby.binary.BinaryParser.handleBlock(Unknown Source)
  at crosby.binary.file.FileBlock.process(Unknown Source)
  at crosby.binary.file.BlockInputStream.process(Unknown Source)
  at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1380)
  at uk.me.parabola.splitter.Main.processMap(Main.java:878)
  at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574)
  at uk.me.parabola.splitter.Main.split(Main.java:252)
  at uk.me.parabola.splitter.Main.start(Main.java:181)
  at uk.me.parabola.splitter.Main.main(Main.java:151)
 uk.me.parabola.splitter.SplitFailedException: ERROR: file 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
  
 contains unexpected data
  at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1402)
  at uk.me.parabola.splitter.Main.processMap(Main.java:878)
  at uk.me.parabola.splitter.Main.calculateAreas

Re: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

2014-10-20 Thread Patrik Brunner


Gerd,

many thanks. I think I got the point:

 * splitter fails on a wrong bounds tag if that one would be absent
   it would check real bounds according existing nodes.
 * osmconvert doesn't read out that wrong tag (else it would be the
   'wrong bounds' too) but just reports bounds according to existing nodes

It might be an option to have an '--override-bounds' or 
'--ignore-bounds' argument for splitter for the future, but I completely 
agree: the data should be fixed at the source, at geofabrik...

... fixing the tools isn't the right solution for this... ;-)

I've learnt again something about these files, and the behaviour of the 
different tools around them, thanks for teaching me, really appreciated


Cheers Patrik

On 20.10.2014 10:16, Gerd Petermann wrote:

Hi Patrik,

I have checked the data from geofabrik. The invalid (?)
bounds tag really is in the data (also in the *.osm.bz2 file)

I am not sure what to do with this.
I can change splitter to ignore invalid bounds,
but I think you should contact the guys at geofabrik
to correct the data.

Regarding the differences in the reported min/max values:
osmconvert reports correct values, the values reported by splitter
in the line starting Exact map coverage is 
depend on the bounds tag. If (valid) bounds were found,
they are used, if not, splitter also reports (and uses)
the real min/max values found in the nodes.

Gerd

 Date: Sun, 19 Oct 2014 15:58:02 +0200
 From: keenonki...@gmx.net
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Problem with splitter r412: invalid bbox area 
in pbf file


 Gents,

 We run into a problem with the splitter about invalid bbox area in pbf
 file throwing the following error:
 java.lang.IllegalArgumentException: invalid bbox area in pbf file:
 (49.808900356292725,-179.95320081710815) to
 (73.79793405532837,180.00049352645874)

 But this is sort of strange as osmconvert tells me different values for
 the bbox. Additionally it has to be said that another file containing a
 larger area (while containing the complete dataset of the file that
 causes the trouble) works without troubles with the same call of
 splitter and the same set of precompiled sea files and so on...

 Any help/comments would be appreciated

 More Details:
 
 The file triggering the problem:
 
--

 http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

 And here the call and the output of the splitter:
 
--

 java -Xmx1536M -jar
 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar 


 --max-threads=2
 
--geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip 


 --no-trim
 
--precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 


 --keep-complete=true --mapid=9861 --max-nodes=80 --output=xml
 
--output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 

 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

 Splitter version 412 compiled 2014-06-21T13:47:04+0100
 boundary-tags=use-exclude-list
 cache=
 description=
 
geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip

 keep-complete=true
 mapid=9861
 max-areas=512
 max-nodes=80
 max-threads=2
 mixed=false
 no-trim=true
 num-tiles=
 output=xml
 
output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA

 overlap=auto
 polygon-desc-file=
 polygon-file=
 
precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea

 problem-file=
 problem-report=
 resolution=13
 search-limit=20
 split-file=
 status-freq=120
 stop-after=dist
 write-kml=
 Elapsed time: 0s Memory: Current 479MB (5MB used, 474MB free) Max 1365MB
 Time started: Sun Oct 19 15:28:09 CEST 2014
 Map is being split for resolution 13:
 - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
 - areas are multiples of 0x800 map units wide and high
 Processing
 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

 Bounding box -179.9532 49.8089 180.000502 73.797941
 java.lang.IllegalArgumentException: invalid bbox area in pbf file:
 (49.808900356292725,-179.95320081710815) to
 (73.79793405532837,180.00049352645874)
 at
 uk.me.parabola.splitter.BinaryMapParser.parse(BinaryMapParser.java:233)
 at crosby.binary.BinaryParser.handleBlock(Unknown Source)
 at crosby.binary.file.FileBlock.process(Unknown Source)
 at crosby.binary.file.BlockInputStream.process(Unknown Source)
 at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1380

Re: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

2014-10-20 Thread KeenOnKites


Gerd,

I did a quick test with success:

 * using osmconvert to get *.osm file
 * removed the 'wrong' bounds tag
 * using osmconvert to convert back to *.pbf file
 * running splitter with success

I will contact geofabrik guys many thanks again.

Patrik

On 20.10.2014 10:28, Patrik Brunner wrote:

Gerd,

many thanks. I think I got the point:

  * splitter fails on a wrong bounds tag if that one would be
absent it would check real bounds according existing nodes.
  * osmconvert doesn't read out that wrong tag (else it would be the
'wrong bounds' too) but just reports bounds according to existing
nodes

It might be an option to have an '--override-bounds' or 
'--ignore-bounds' argument for splitter for the future, but I 
completely agree: the data should be fixed at the source, at geofabrik...

... fixing the tools isn't the right solution for this... ;-)

I've learnt again something about these files, and the behaviour of 
the different tools around them, thanks for teaching me, really 
appreciated


Cheers Patrik

On 20.10.2014 10:16, Gerd Petermann wrote:

Hi Patrik,

I have checked the data from geofabrik. The invalid (?)
bounds tag really is in the data (also in the *.osm.bz2 file)

I am not sure what to do with this.
I can change splitter to ignore invalid bounds,
but I think you should contact the guys at geofabrik
to correct the data.

Regarding the differences in the reported min/max values:
osmconvert reports correct values, the values reported by splitter
in the line starting Exact map coverage is 
depend on the bounds tag. If (valid) bounds were found,
they are used, if not, splitter also reports (and uses)
the real min/max values found in the nodes.

Gerd

 Date: Sun, 19 Oct 2014 15:58:02 +0200
 From: keenonki...@gmx.net
 To: mkgmap-dev@lists.mkgmap.org.uk
 Subject: [mkgmap-dev] Problem with splitter r412: invalid bbox area 
in pbf file


 Gents,

 We run into a problem with the splitter about invalid bbox area in pbf
 file throwing the following error:
 java.lang.IllegalArgumentException: invalid bbox area in pbf file:
 (49.808900356292725,-179.95320081710815) to
 (73.79793405532837,180.00049352645874)

 But this is sort of strange as osmconvert tells me different values 
for
 the bbox. Additionally it has to be said that another file 
containing a

 larger area (while containing the complete dataset of the file that
 causes the trouble) works without troubles with the same call of
 splitter and the same set of precompiled sea files and so on...

 Any help/comments would be appreciated

 More Details:
 
 The file triggering the problem:
 
--

 http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

 And here the call and the output of the splitter:
 
--

 java -Xmx1536M -jar
 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar 


 --max-threads=2
 
--geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip 


 --no-trim
 
--precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 


 --keep-complete=true --mapid=9861 --max-nodes=80 --output=xml
 
--output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 

 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

 Splitter version 412 compiled 2014-06-21T13:47:04+0100
 boundary-tags=use-exclude-list
 cache=
 description=
 
geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip

 keep-complete=true
 mapid=9861
 max-areas=512
 max-nodes=80
 max-threads=2
 mixed=false
 no-trim=true
 num-tiles=
 output=xml
 
output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA

 overlap=auto
 polygon-desc-file=
 polygon-file=
 
precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea

 problem-file=
 problem-report=
 resolution=13
 search-limit=20
 split-file=
 status-freq=120
 stop-after=dist
 write-kml=
 Elapsed time: 0s Memory: Current 479MB (5MB used, 474MB free) Max 
1365MB

 Time started: Sun Oct 19 15:28:09 CEST 2014
 Map is being split for resolution 13:
 - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
 - areas are multiples of 0x800 map units wide and high
 Processing
 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

 Bounding box -179.9532 49.8089 180.000502 73.797941
 java.lang.IllegalArgumentException: invalid bbox area in pbf file:
 (49.808900356292725,-179.95320081710815) to
 (73.79793405532837,180.00049352645874

[mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

2014-10-19 Thread KeenOnKites


Gents,

We run into a problem with the splitter about invalid bbox area in pbf 
file throwing the following error:
java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
(49.808900356292725,-179.95320081710815) to 
(73.79793405532837,180.00049352645874)


But this is sort of strange as osmconvert tells me different values for 
the bbox. Additionally it has to be said that another file containing a 
larger area (while containing the complete dataset of the file that 
causes the trouble) works without troubles with the same call of 
splitter and the same set of precompiled sea files and so on...


Any help/comments would be appreciated

More Details:

The file triggering the problem:
--
http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf

And here the call and the output of the splitter:
--
java -Xmx1536M -jar 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar 
--max-threads=2 
--geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip 
--no-trim 
--precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
--keep-complete=true --mapid=9861 --max-nodes=80 --output=xml 
--output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

Splitter version 412 compiled 2014-06-21T13:47:04+0100
boundary-tags=use-exclude-list
cache=
description=
geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip
keep-complete=true
mapid=9861
max-areas=512
max-nodes=80
max-threads=2
mixed=false
no-trim=true
num-tiles=
output=xml
output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
overlap=auto
polygon-desc-file=
polygon-file=
precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
problem-file=
problem-report=
resolution=13
search-limit=20
split-file=
status-freq=120
stop-after=dist
write-kml=
Elapsed time: 0s   Memory: Current 479MB (5MB used, 474MB free) Max 1365MB
Time started: Sun Oct 19 15:28:09 CEST 2014
Map is being split for resolution 13:
 - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
 - areas are multiples of 0x800 map units wide and high
Processing 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf

Bounding box -179.9532 49.8089 180.000502 73.797941
java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
(49.808900356292725,-179.95320081710815) to 
(73.79793405532837,180.00049352645874)
at 
uk.me.parabola.splitter.BinaryMapParser.parse(BinaryMapParser.java:233)

at crosby.binary.BinaryParser.handleBlock(Unknown Source)
at crosby.binary.file.FileBlock.process(Unknown Source)
at crosby.binary.file.BlockInputStream.process(Unknown Source)
at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1380)
at uk.me.parabola.splitter.Main.processMap(Main.java:878)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574)
at uk.me.parabola.splitter.Main.split(Main.java:252)
at uk.me.parabola.splitter.Main.start(Main.java:181)
at uk.me.parabola.splitter.Main.main(Main.java:151)
uk.me.parabola.splitter.SplitFailedException: ERROR: file 
/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf 
contains unexpected data

at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1402)
at uk.me.parabola.splitter.Main.processMap(Main.java:878)
at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574)
at uk.me.parabola.splitter.Main.split(Main.java:252)
at uk.me.parabola.splitter.Main.start(Main.java:181)
at uk.me.parabola.splitter.Main.main(Main.java:151)

osmconvert output containing the statistics about the file
--
tools/osmconvert/linux/osmconvert32 
work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf 
--out-statistics

timestamp min: 2007-06-05T03:23:59Z
timestamp max: 2014-10-18T11:48:05Z
lon min: -180.000
lon max: -122.5122521
lat min: 48.6234931
lat max: 71.6048217
nodes: 4028420
ways: 171349
relations: 1803
node id min: 27207079
node id max: 3136662460
way id min: 4708608
way id max: 308379297
relation id min: 13971
relation id max: 4116925
keyval pairs max: 302
keyval pairs max object: relation 60189
noderefs max: 2000
noderefs max object: way 42394334

Re: [mkgmap-dev] Problem with splitter r412: invalid bbox area in pbf file

2014-10-19 Thread GerdP

Hi Patrik,

the error message is about the bounds tag in the input file.
I did not look at the file, but a value  180.0 is clearly not okay.

The other values are not about the bbox, but 
about the min/max values of nodes.
I don't know why splitter and osmconvert report different values
here.

I'll have a closer look at the files later.

Gerd


keenonkites wrote
 Gents,
 
 We run into a problem with the splitter about invalid bbox area in pbf 
 file throwing the following error:
 java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
 (49.808900356292725,-179.95320081710815) to 
 (73.79793405532837,180.00049352645874)
 
 But this is sort of strange as osmconvert tells me different values for 
 the bbox. Additionally it has to be said that another file containing a 
 larger area (while containing the complete dataset of the file that 
 causes the trouble) works without troubles with the same call of 
 splitter and the same set of precompiled sea files and so on...
 
 Any help/comments would be appreciated
 
 More Details:
 
 The file triggering the problem:
 --
 http://download.geofabrik.de/north-america/us/alaska-latest.osm.pbf
 
 And here the call and the output of the splitter:
 --
 java -Xmx1536M -jar 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/splitter/splitter.jar
  
 --max-threads=2 
 --geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip
  
 --no-trim 
 --precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea 
 --keep-complete=true --mapid=9861 --max-nodes=80 --output=xml 
 --output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
  
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
 Splitter version 412 compiled 2014-06-21T13:47:04+0100
 boundary-tags=use-exclude-list
 cache=
 description=
 geonames-file=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/cities/cities15000.zip
 keep-complete=true
 mapid=9861
 max-areas=512
 max-nodes=80
 max-threads=2
 mixed=false
 no-trim=true
 num-tiles=
 output=xml
 output-dir=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA
 overlap=auto
 polygon-desc-file=
 polygon-file=
 precomp-sea=/home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/sea
 problem-file=
 problem-report=
 resolution=13
 search-limit=20
 split-file=
 status-freq=120
 stop-after=dist
 write-kml=
 Elapsed time: 0s   Memory: Current 479MB (5MB used, 474MB free) Max 1365MB
 Time started: Sun Oct 19 15:28:09 CEST 2014
 Map is being split for resolution 13:
   - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
   - areas are multiples of 0x800 map units wide and high
 Processing 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
 Bounding box -179.9532 49.8089 180.000502 73.797941
 java.lang.IllegalArgumentException: invalid bbox area in pbf file: 
 (49.808900356292725,-179.95320081710815) to 
 (73.79793405532837,180.00049352645874)
  at 
 uk.me.parabola.splitter.BinaryMapParser.parse(BinaryMapParser.java:233)
  at crosby.binary.BinaryParser.handleBlock(Unknown Source)
  at crosby.binary.file.FileBlock.process(Unknown Source)
  at crosby.binary.file.BlockInputStream.process(Unknown Source)
  at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1380)
  at uk.me.parabola.splitter.Main.processMap(Main.java:878)
  at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574)
  at uk.me.parabola.splitter.Main.split(Main.java:252)
  at uk.me.parabola.splitter.Main.start(Main.java:181)
  at uk.me.parabola.splitter.Main.main(Main.java:151)
 uk.me.parabola.splitter.SplitFailedException: ERROR: file 
 /home/pab/develop/fzk-mde-garmin/Freizeitkarte-Entwicklung/work/Freizeitkarte_US_ALASKA/Freizeitkarte_US_ALASKA.osm.pbf
  
 contains unexpected data
  at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1402)
  at uk.me.parabola.splitter.Main.processMap(Main.java:878)
  at uk.me.parabola.splitter.Main.calculateAreas(Main.java:574)
  at uk.me.parabola.splitter.Main.split(Main.java:252)
  at uk.me.parabola.splitter.Main.start(Main.java:181)
  at uk.me.parabola.splitter.Main.main(Main.java:151)
 
 osmconvert output containing the statistics about the file
 --
 tools/osmconvert/linux/osmconvert32

[mkgmap-dev] Problem with splitter r393

Hi

FYI:

splitter r393 dies with following error, if i try to split my DACH-extract,
all other extracts are not affected

java.lang.ArrayIndexOutOfBoundsException: -184650
at 
uk.me.parabola.splitter.O5mMapParser.setStringRefPair(O5mMapParser.java:355)
at 
uk.me.parabola.splitter.O5mMapParser.readAuthor(O5mMapParser.java:408)
at 
uk.me.parabola.splitter.O5mMapParser.readVersionTsAuthor(O5mMapParser.java:372)
at 
uk.me.parabola.splitter.O5mMapParser.readNode(O5mMapParser.java:251)
at 
uk.me.parabola.splitter.O5mMapParser.readFile(O5mMapParser.java:187)
at uk.me.parabola.splitter.O5mMapParser.parse(O5mMapParser.java:133)
at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1362)
at uk.me.parabola.splitter.Main.processMap(Main.java:874)
at uk.me.parabola.splitter.Main.genProblemLists(Main.java:697)
at 
uk.me.parabola.splitter.Main.partitionAreasForProblemListGenerator(Main.java:729)
at uk.me.parabola.splitter.Main.split(Main.java:307)
at uk.me.parabola.splitter.Main.start(Main.java:181)
at uk.me.parabola.splitter.Main.main(Main.java:151)



here are the log files
http://files.mkgmap.org.uk/download/210/20140526_0900.zip

Bernd


-- 
amarok2 now playing:




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter r393

Hi Bernd,

this looks like an error in the o5m file. Is osmconvert able to read it?

Gerd

 From: weigelt.be...@web.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Date: Mon, 26 May 2014 10:20:11 +0200
 Subject: [mkgmap-dev] Problem with splitter r393
 
 Hi
 
 FYI:
 
 splitter r393 dies with following error, if i try to split my DACH-extract,
 all other extracts are not affected
 
 java.lang.ArrayIndexOutOfBoundsException: -184650
 at 
 uk.me.parabola.splitter.O5mMapParser.setStringRefPair(O5mMapParser.java:355)
 at 
 uk.me.parabola.splitter.O5mMapParser.readAuthor(O5mMapParser.java:408)
 at 
 uk.me.parabola.splitter.O5mMapParser.readVersionTsAuthor(O5mMapParser.java:372)
 at 
 uk.me.parabola.splitter.O5mMapParser.readNode(O5mMapParser.java:251)
 at 
 uk.me.parabola.splitter.O5mMapParser.readFile(O5mMapParser.java:187)
 at uk.me.parabola.splitter.O5mMapParser.parse(O5mMapParser.java:133)
 at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1362)
 at uk.me.parabola.splitter.Main.processMap(Main.java:874)
 at uk.me.parabola.splitter.Main.genProblemLists(Main.java:697)
 at 
 uk.me.parabola.splitter.Main.partitionAreasForProblemListGenerator(Main.java:729)
 at uk.me.parabola.splitter.Main.split(Main.java:307)
 at uk.me.parabola.splitter.Main.start(Main.java:181)
 at uk.me.parabola.splitter.Main.main(Main.java:151)
 
 
 
 here are the log files
 http://files.mkgmap.org.uk/download/210/20140526_0900.zip
 
 Bernd
 
 
 -- 
 amarok2 now playing:
 
 
 
 
 ___
 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

Re: [mkgmap-dev] Problem with splitter r393

Am Montag, 26. Mai 2014, 10:21:31 schrieb Gerd Petermann:

Wow, 80 seconds to get a hint ;-)

 this looks like an error in the o5m file. Is osmconvert able to read it?

What shall i do?

convert from o5m to osm and back?

No problem

Bernd


-- 
amarok2 now playing:




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter r393

Hi Bernd,

okay, so it is probably a special case :-(
Please post a link to the complete o5m file.

Gerd

 From: weigelt.be...@web.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Date: Mon, 26 May 2014 10:28:33 +0200
 Subject: Re: [mkgmap-dev] Problem with splitter r393
 
 Am Montag, 26. Mai 2014, 10:21:31 schrieb Gerd Petermann:
 
 Wow, 80 seconds to get a hint ;-)
 
  this looks like an error in the o5m file. Is osmconvert able to read it?
 
 What shall i do?
 
 convert from o5m to osm and back?
 
 No problem
 
 Bernd
 
 
 -- 
 amarok2 now playing:
 
 
 
 
 ___
 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

Re: [mkgmap-dev] Problem with splitter r393

Hi Bernd,

and you may use 7zip to compress the o5m file first.

Gerd

 From: weigelt.be...@web.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Date: Mon, 26 May 2014 10:28:33 +0200
 Subject: Re: [mkgmap-dev] Problem with splitter r393
 
 Am Montag, 26. Mai 2014, 10:21:31 schrieb Gerd Petermann:
 
 Wow, 80 seconds to get a hint ;-)
 
  this looks like an error in the o5m file. Is osmconvert able to read it?
 
 What shall i do?
 
 convert from o5m to osm and back?
 
 No problem
 
 Bernd
 
 
 -- 
 amarok2 now playing:
 
 
 
 
 ___
 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

Re: [mkgmap-dev] Problem with splitter r393

Am Montag, 26. Mai 2014, 10:31:46 schrieb Gerd Petermann:

Hi Gerd

 okay, so it is probably a special case
 Please post a link to the complete o5m file.

Sorry, my mistake

Didn't check the o5m file, only ask for that, what i should do ;-)

I have to test osmconvert 0.7T against the old and a new extract, then i can 
give you the informations, but it will take some hours.

I think, osmupdate 0.3F  has a problem with this large extract, ~6.3 GB, 
because i have to create a new extract very often.



Bernd

-- 
amarok2 now playing:




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter r393

Hi Bernd,

no problem. I'll try to improve the error handling for this case.

Gerd

 From: weigelt.be...@web.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Date: Mon, 26 May 2014 11:03:36 +0200
 Subject: Re: [mkgmap-dev] Problem with splitter r393

 Am Montag, 26. Mai 2014, 10:31:46 schrieb Gerd Petermann:

 Hi Gerd

  okay, so it is probably a special case
  Please post a link to the complete o5m file.

 Sorry, my mistake

 Didn't check the o5m file, only ask for that, what i should do ;-)

 I have to test osmconvert 0.7T against the old and a new extract, then i can 
 give you the informations, but it will take some hours.

 I think, osmupdate 0.3F  has a problem with this large extract, ~6.3 GB, 
 because i have to create a new extract very often.

 Bernd

 -- 
 amarok2 now playing:

 ___
 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

Re: [mkgmap-dev] Problem with splitter r393

Hi Bernd,

I've added a check in r395.

reg. osmupdate I suggest to contact Markus Weber:
markus.we...@gmx.com

Gerd

From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Mon, 26 May 2014 11:06:18 +0200
Subject: Re: [mkgmap-dev] Problem with splitter r393




Hi Bernd,

no problem. I'll try to improve the error handling for this case.

Gerd

 From: weigelt.be...@web.de
 To: mkgmap-dev@lists.mkgmap.org.uk
 Date: Mon, 26 May 2014 11:03:36 +0200
 Subject: Re: [mkgmap-dev] Problem with splitter r393
 
 Am Montag, 26. Mai 2014, 10:31:46 schrieb Gerd Petermann:
 
 Hi Gerd
 
  okay, so it is probably a special case
  Please post a link to the complete o5m file.
 
 Sorry, my mistake
 
 Didn't check the o5m file, only ask for that, what i should do ;-)
 
 I have to test osmconvert 0.7T against the old and a new extract, then i can 
 give you the informations, but it will take some hours.
 
 I think, osmupdate 0.3F  has a problem with this large extract, ~6.3 GB, 
 because i have to create a new extract very often.
 
 
 
 Bernd
 
 -- 
 amarok2 now playing:
 
 
 
 
 ___
 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

Re: [mkgmap-dev] Problem with splitter r393

Am Montag, 26. Mai 2014, 04:27:13 schrieb GerdP:

Hi Gerd

 Maybe you have a hardware problem?

RAM? HDD?

Don't think so, because then it should be more often, not only by this 
extract. If my HDD has a problem, the error should be the same as this 
morning, because i've renamed the file and didn't copy it to another place.
S.M.A.R.T monitoring is enabled.

But i'll test both, RAM and HDD, this night to be sure

BTW: there only a few changes in the three splitter.log, the areas.list are 
more or less identical.

Bernd


-- 
amarok2 now playing:




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with splitter r393