date:20200914

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

2020-09-14 Thread Joao Almeida


Hi sorry I thought I had sent a response.

I created the poly with input from:
http://geojson.io/#map=2/-1.9/-22.3

I fixed the poly by changing it to:
TITLE
1
-11.21917  45.1531
-11.62209  34.99365
1.996625  35.73983
6.106414  40.61866
53.73163  36.25641
75.16701  36.08421
114.1697  42.97197
124.7262  50.37632
131.173  41.99621
142.6159  46.30106
157.2016  49.57275
188.1459  62.94648
188.1459  70.00644
138.345  74.25389
107.8036  67.25134
50.75002  58.12505
8.443355  47.85081
-10.49391  45.38269
-11.21917  45.1531
END
END

And I just posted how I fixed the DEM messages in post:

news://news.gmane.io:119/1e73ed7a-14ab-130b-ef5e-51003f136...@gmail.com
Reporting I found a fix for this.
I stopped having the messages and being able to compile my maps after I 
changed the following options:


Before:
--dem-dists=3312,3312,9942,13248,26512,44176
--overview-dem-dist=88368

After:

--overview-dem-dist=8
--dem-dists=9942

I'm not sure why some tiles where throwing the error, because I was able 
to compile other areas with the original settings.


Not sure if someone has an answer or wants to investigate.

Cheers


On 2/09/2020 5:48 pm, Gerd Petermann wrote:

Hi Joao,

how did you create this poly file? The value 189.84375 is obviously wrong and 
probably mkgmap / splitter fails to recognize that.

Gerd


Von: mkgmap-dev  im Auftrag von Joao Almeida 

Gesendet: Dienstag, 1. September 2020 13:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] DEM There is not enough room in a single garmin map 
for all the input data

For example.

This is the poly file with the areas.
Title
1
-30.41875 45.18952
-30.20899 13.02443
-14.68754 13.38583
-7.346309 27.84205
1.043668 31.57658
0.4144224 37.2386
10.27264 38.32281
14.46764 35.3111
19.29187 39.64797
18.66261 49.64685
6.706903 48.20123
-1.473327 45.18952
-29.16025 45.79186
-30.41875 45.18952
END
2
44.8813 49.04451
53.48103 55.67028
67.11473 57.35684
78.23146 55.54981
88.29943 49.88779
97.10889 53.74279
101.5137 52.89951
114.5181 51.93576
118.9228 49.88779
120.8106 45.79186
106.3379 39.64797
91.23593 41.93687
86.83118 46.99655
78.23146 37.2386
62.29049 34.22689
54.52977 36.63626
44.8813 49.04451
END
3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END
END


If I use this poly file I get the map too big error for areas in:

3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END


But if I only use the following poly file:

Title
1
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END

Note it is the same area as 3 in main file I don't get the map too big error.

Hope it clarifies

Thank you for the help.

On Tue, Sep 1, 2020 at 9:39 AM Joao Almeida 
mailto:joa...@gmail.com>> wrote:
Help please, could not find a solution that works.
I'm trying to build a map that includes DEM shading. I've tried splitting the 
map with max nodes 80, 60 and this last time 40. For some reason I 
always get the following message on the same tile regardless of the split 
maxnodes option.

There is however a different behaviour, this only happens if I try to include 
different polygon areas, if I just try the same are by it self it does not 
throw the message about map too big.

I'm happy to provide poly file and splitter settings and map build options to 
see if we can overcome this problem.

Thanks a lot.
Joao


SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (thrown in 
MapBuilder.buildDem()) DEM
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161841.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (thrown in 
MapBuilder.buildDem()) DEM




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

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

2020-09-14 Thread Joao Almeida


Reporting I found a fix for this.
I stopped having the messages and being able to compile my maps after I 
changed the following options:


Before:
--dem-dists=3312,3312,9942,13248,26512,44176
--overview-dem-dist=88368

After:

--overview-dem-dist=8
--dem-dists=9942

I'm not sure why some tiles where throwing the error, because I was able 
to compile other areas with the original settings.


Not sure if someone has an answer or wants to investigate.

Cheers


On 2/09/2020 8:18 pm, Joao Almeida wrote:

I was created from data from:
http://geojson.io/#map=2/20.0/0.0 
{
   "type": "FeatureCollection",
   "features": [
     {
       "type": "Feature",
       "properties": {},
       "geometry": {
         "type": "Polygon",
         "coordinates": [
           [
             [
               94.921875,
               -55.77657
             ],
             [
               189.84375,
               -55.77657
             ],
             [
               189.84375,
               -7.362466
             ],
             [
               94.921875,
               -7.362466
             ],
             [
               94.921875,
               -55.77657
             ]
           ]
         ]
       }
     }
   ]
}

Thanks for looking at this.
Joao

-- Forwarded message --
From: Gerd Petermann mailto:gpetermann_muenc...@hotmail.com>>
To: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk>>
Cc:
Bcc:
Date: Wed, 2 Sep 2020 07:48:52 +
Subject: Re: [mkgmap-dev] DEM There is not enough room in a single
garmin map for all the input data
Hi Joao,

how did you create this poly file? The value 189.84375 is obviously
wrong and probably mkgmap / splitter fails to recognize that.

Gerd


Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Joao
Almeida mailto:joa...@gmail.com>>
Gesendet: Dienstag, 1. September 2020 13:34
An: mkgmap-dev@lists.mkgmap.org.uk

Betreff: Re: [mkgmap-dev] DEM There is not enough room in a single
garmin map for all the input data

For example.

This is the poly file with the areas.
Title
1
-30.41875 45.18952
-30.20899 13.02443
-14.68754 13.38583
-7.346309 27.84205
1.043668 31.57658
0.4144224 37.2386
10.27264 38.32281
14.46764 35.3111
19.29187 39.64797
18.66261 49.64685
6.706903 48.20123
-1.473327 45.18952
-29.16025 45.79186
-30.41875 45.18952
END
2
44.8813 49.04451
53.48103 55.67028
67.11473 57.35684
78.23146 55.54981
88.29943 49.88779
97.10889 53.74279
101.5137 52.89951
114.5181 51.93576
118.9228 49.88779
120.8106 45.79186
106.3379 39.64797
91.23593 41.93687
86.83118 46.99655
78.23146 37.2386
62.29049 34.22689
54.52977 36.63626
44.8813 49.04451
END
3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END
END


If I use this poly file I get the map too big error for areas in:

3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END


But if I only use the following poly file:

Title
1
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END

Note it is the same area as 3 in main file I don't get the map too
big error.

Hope it clarifies

Thank you for the help.

On Tue, Sep 1, 2020 at 9:39 AM Joao Almeida mailto:joa...@gmail.com>>> wrote:
Help please, could not find a solution that works.
I'm trying to build a map that includes DEM shading. I've tried
splitting the map with max nodes 80, 60 and this last time
40. For some reason I always get the following message on the
same tile regardless of the split maxnodes option.

There is however a different behaviour, this only happens if I try
to include different polygon areas, if I just try the same are by it
self it does not throw the message about map too big.

I'm happy to provide poly file and splitter settings and map build
options to see if we can overcome this problem.

Thanks a lot.
Joao


SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m:
(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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception
while creating DEM file 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.
SE

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

2020-09-14 Thread Joao Almeida


Hi sorry I thought I had sent a response.

I created the poly with input from:
http://geojson.io/#map=2/-1.9/-22.3

I fixed the poly by changing it to:
TITLE
1
-11.21917  45.1531
-11.62209  34.99365
1.996625  35.73983
6.106414  40.61866
53.73163  36.25641
75.16701  36.08421
114.1697  42.97197
124.7262  50.37632
131.173  41.99621
142.6159  46.30106
157.2016  49.57275
188.1459  62.94648
188.1459  70.00644
138.345  74.25389
107.8036  67.25134
50.75002  58.12505
8.443355  47.85081
-10.49391  45.38269
-11.21917  45.1531
END
END

And I just posted how I fixed the DEM messages in post:

news://news.gmane.io:119/1e73ed7a-14ab-130b-ef5e-51003f136...@gmail.com
Reporting I found a fix for this.
I stopped having the messages and being able to compile my maps after I 
changed the following options:


Before:
--dem-dists=3312,3312,9942,13248,26512,44176
--overview-dem-dist=88368

After:

--overview-dem-dist=8
--dem-dists=9942

I'm not sure why some tiles where throwing the error, because I was able 
to compile other areas with the original settings.


Not sure if someone has an answer or wants to investigate.

Cheers


On 2/09/2020 5:48 pm, Gerd Petermann wrote:

Hi Joao,

how did you create this poly file? The value 189.84375 is obviously wrong and 
probably mkgmap / splitter fails to recognize that.

Gerd


Von: mkgmap-dev  im Auftrag von Joao Almeida 

Gesendet: Dienstag, 1. September 2020 13:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] DEM There is not enough room in a single garmin map 
for all the input data

For example.

This is the poly file with the areas.
Title
1
-30.41875 45.18952
-30.20899 13.02443
-14.68754 13.38583
-7.346309 27.84205
1.043668 31.57658
0.4144224 37.2386
10.27264 38.32281
14.46764 35.3111
19.29187 39.64797
18.66261 49.64685
6.706903 48.20123
-1.473327 45.18952
-29.16025 45.79186
-30.41875 45.18952
END
2
44.8813 49.04451
53.48103 55.67028
67.11473 57.35684
78.23146 55.54981
88.29943 49.88779
97.10889 53.74279
101.5137 52.89951
114.5181 51.93576
118.9228 49.88779
120.8106 45.79186
106.3379 39.64797
91.23593 41.93687
86.83118 46.99655
78.23146 37.2386
62.29049 34.22689
54.52977 36.63626
44.8813 49.04451
END
3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END
END


If I use this poly file I get the map too big error for areas in:

3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END


But if I only use the following poly file:

Title
1
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END

Note it is the same area as 3 in main file I don't get the map too big error.

Hope it clarifies

Thank you for the help.

On Tue, Sep 1, 2020 at 9:39 AM Joao Almeida 
mailto:joa...@gmail.com>> wrote:
Help please, could not find a solution that works.
I'm trying to build a map that includes DEM shading. I've tried splitting the 
map with max nodes 80, 60 and this last time 40. For some reason I 
always get the following message on the same tile regardless of the split 
maxnodes option.

There is however a different behaviour, this only happens if I try to include 
different polygon areas, if I just try the same are by it self it does not 
throw the message about map too big.

I'm happy to provide poly file and splitter settings and map build options to 
see if we can overcome this problem.

Thanks a lot.
Joao


SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (thrown in 
MapBuilder.buildDem()) DEM
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161841.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (thrown in 
MapBuilder.buildDem()) DEM




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

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

2020-09-14 Thread Joao Almeida


Hi sorry I thought I had sent a response.

I created the poly with input from:
http://geojson.io/#map=2/-1.9/-22.3

I fixed the poly by changing it to:
TITLE
1
-11.21917  45.1531
-11.62209  34.99365
1.996625  35.73983
6.106414  40.61866
53.73163  36.25641
75.16701  36.08421
114.1697  42.97197
124.7262  50.37632
131.173  41.99621
142.6159  46.30106
157.2016  49.57275
188.1459  62.94648
188.1459  70.00644
138.345  74.25389
107.8036  67.25134
50.75002  58.12505
8.443355  47.85081
-10.49391  45.38269
-11.21917  45.1531
END
END

And I just posted how I fixed the DEM messages in post:

news://news.gmane.io:119/1e73ed7a-14ab-130b-ef5e-51003f136...@gmail.com
Reporting I found a fix for this.
I stopped having the messages and being able to compile my maps after I 
changed the following options:


Before:
--dem-dists=3312,3312,9942,13248,26512,44176
--overview-dem-dist=88368

After:

--overview-dem-dist=8
--dem-dists=9942

I'm not sure why some tiles where throwing the error, because I was able 
to compile other areas with the original settings.


Not sure if someone has an answer or wants to investigate.

Cheers


On 2/09/2020 5:48 pm, Gerd Petermann wrote:

Hi Joao,

how did you create this poly file? The value 189.84375 is obviously wrong and 
probably mkgmap / splitter fails to recognize that.

Gerd


Von: mkgmap-dev  im Auftrag von Joao Almeida 

Gesendet: Dienstag, 1. September 2020 13:34
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] DEM There is not enough room in a single garmin map 
for all the input data

For example.

This is the poly file with the areas.
Title
1
-30.41875 45.18952
-30.20899 13.02443
-14.68754 13.38583
-7.346309 27.84205
1.043668 31.57658
0.4144224 37.2386
10.27264 38.32281
14.46764 35.3111
19.29187 39.64797
18.66261 49.64685
6.706903 48.20123
-1.473327 45.18952
-29.16025 45.79186
-30.41875 45.18952
END
2
44.8813 49.04451
53.48103 55.67028
67.11473 57.35684
78.23146 55.54981
88.29943 49.88779
97.10889 53.74279
101.5137 52.89951
114.5181 51.93576
118.9228 49.88779
120.8106 45.79186
106.3379 39.64797
91.23593 41.93687
86.83118 46.99655
78.23146 37.2386
62.29049 34.22689
54.52977 36.63626
44.8813 49.04451
END
3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END
END


If I use this poly file I get the map too big error for areas in:

3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END


But if I only use the following poly file:

Title
1
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END

Note it is the same area as 3 in main file I don't get the map too big error.

Hope it clarifies

Thank you for the help.

On Tue, Sep 1, 2020 at 9:39 AM Joao Almeida 
mailto:joa...@gmail.com>> wrote:
Help please, could not find a solution that works.
I'm trying to build a map that includes DEM shading. I've tried splitting the 
map with max nodes 80, 60 and this last time 40. For some reason I 
always get the following message on the same tile regardless of the split 
maxnodes option.

There is however a different behaviour, this only happens if I try to include 
different polygon areas, if I just try the same are by it self it does not 
throw the message about map too big.

I'm happy to provide poly file and splitter settings and map build options to 
see if we can overcome this problem.

Thanks a lot.
Joao


SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m: (thrown in 
MapBuilder.buildDem()) DEM
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161841.o5m: exception while creating 
DEM file 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.
SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161841.o5m: (thrown in 
MapBuilder.buildDem()) DEM




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

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

2020-09-14 Thread Joao Almeida


Reporting I found a fix for this.
I stopped having the messages and being able to compile my maps after I 
changed the following options:


Before:
--dem-dists=3312,3312,9942,13248,26512,44176
--overview-dem-dist=88368

After:

--overview-dem-dist=8
--dem-dists=9942

I'm not sure why some tiles where throwing the error, because I was able 
to compile other areas with the original settings.


Not sure if someone has an answer or wants to investigate.

Cheers


On 2/09/2020 8:18 pm, Joao Almeida wrote:

I was created from data from:
http://geojson.io/#map=2/20.0/0.0 
{
   "type": "FeatureCollection",
   "features": [
     {
       "type": "Feature",
       "properties": {},
       "geometry": {
         "type": "Polygon",
         "coordinates": [
           [
             [
               94.921875,
               -55.77657
             ],
             [
               189.84375,
               -55.77657
             ],
             [
               189.84375,
               -7.362466
             ],
             [
               94.921875,
               -7.362466
             ],
             [
               94.921875,
               -55.77657
             ]
           ]
         ]
       }
     }
   ]
}

Thanks for looking at this.
Joao

-- Forwarded message --
From: Gerd Petermann mailto:gpetermann_muenc...@hotmail.com>>
To: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk>>
Cc:
Bcc:
Date: Wed, 2 Sep 2020 07:48:52 +
Subject: Re: [mkgmap-dev] DEM There is not enough room in a single
garmin map for all the input data
Hi Joao,

how did you create this poly file? The value 189.84375 is obviously
wrong and probably mkgmap / splitter fails to recognize that.

Gerd


Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Joao
Almeida mailto:joa...@gmail.com>>
Gesendet: Dienstag, 1. September 2020 13:34
An: mkgmap-dev@lists.mkgmap.org.uk

Betreff: Re: [mkgmap-dev] DEM There is not enough room in a single
garmin map for all the input data

For example.

This is the poly file with the areas.
Title
1
-30.41875 45.18952
-30.20899 13.02443
-14.68754 13.38583
-7.346309 27.84205
1.043668 31.57658
0.4144224 37.2386
10.27264 38.32281
14.46764 35.3111
19.29187 39.64797
18.66261 49.64685
6.706903 48.20123
-1.473327 45.18952
-29.16025 45.79186
-30.41875 45.18952
END
2
44.8813 49.04451
53.48103 55.67028
67.11473 57.35684
78.23146 55.54981
88.29943 49.88779
97.10889 53.74279
101.5137 52.89951
114.5181 51.93576
118.9228 49.88779
120.8106 45.79186
106.3379 39.64797
91.23593 41.93687
86.83118 46.99655
78.23146 37.2386
62.29049 34.22689
54.52977 36.63626
44.8813 49.04451
END
3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END
END


If I use this poly file I get the map too big error for areas in:

3
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END


But if I only use the following poly file:

Title
1
94.921875 -55.77657
189.84375 -55.77657
189.84375 -7.362466
94.921875 -7.362466
94.921875 -55.77657
END

Note it is the same area as 3 in main file I don't get the map too
big error.

Hope it clarifies

Thank you for the help.

On Tue, Sep 1, 2020 at 9:39 AM Joao Almeida mailto:joa...@gmail.com>>> wrote:
Help please, could not find a solution that works.
I'm trying to build a map that includes DEM shading. I've tried
splitting the map with max nodes 80, 60 and this last time
40. For some reason I always get the following message on the
same tile regardless of the split maxnodes option.

There is however a different behaviour, this only happens if I try
to include different polygon areas, if I just try the same are by it
self it does not throw the message about map too big.

I'm happy to provide poly file and splitter settings and map build
options to see if we can overcome this problem.

Thanks a lot.
Joao


SEVERE (MapFailedException): C:\Garmin\SPLITT~4\44161838.o5m:
(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.
SEVERE (MapBuilder): C:\Garmin\SPLITT~4\44161838.o5m: exception
while creating DEM file 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.
SE

Re: [mkgmap-dev] Error in Africa?

2020-09-14 Thread Ticker Berkin

Hi Gerd

Yes - sorry - I see it now.

Ticker



On Mon, 2020-09-14 at 15:34 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> mergeRoads() is called before any addRoadsWithoutLoops().
> I hope this clarifies all?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 14. September 2020 15:17
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error in Africa?
> 
> Hi Gerd
> 
> I don't understand how splitting the road in addRoadsWithoutLoops()
> changes anything - won't the bits (and the other OSM ways with same
> typ/names/class/speed) just be joined up again during StyledConverted
> end() processing in the call mergeRoads().
> 
> For a road with many points, it is going to be LineSplitterFilter
> that
> creates too many road segments. Probably the easiest way to prevent
> this many-pointed road causing this problem is to split it before
> invoking the filter but after mergeRoads(). However I maintain that a
> single OSM way won't cause the problem and so stopping RoadMerger
> from
> creating the problem is a safe solution. RoadMerger.MAX_MERGED_POINTS
> should be re-expressed as per StyledConverter.MAX_ROAD_POINTS.
> 
> I understand the change to remove the warning in MapSplitter about a
> single item being too big.
> 
> Ticker
> 
> On Sun, 2020-09-06 at 08:56 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I've now found the time to look at the details. The problem was not
> > the size of the sub division but the number of Polyline instances
> > created for the long road.
> > This has to be < 0x80. The corresponding check was only implemented
> > with an assert statement and Valentins call doesn't enable
> > assertions, so invalid data was written.
> > I've attached a patch which implements the splitting in
> > StyledConverter and which throws a MapFailedException instead of
> > using an assertion.
> > Open problem: MapSplitter still
> > SCHW: uk.me.parabola.mkgmap.build.MapSplitter
> >  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> > subdivision
> > http://www.openstreetmap.org/?mlat=10.489948&mlon=-13.065190&zoom=1
> > 7
> > SCHW: uk.me.parabola.mkgmap.build.MapSplitter
> >  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> > subdivision
> > http://www.openstreetmap.org/?mlat=10.368004&mlon=-12.969704&zoom=1
> > 7
> > while the map seems to be OK. So I think the estimation also needs
> > a
> > fix?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von valentin3...@gmail.com 
> > Gesendet: Dienstag, 4. August 2020 12:28
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] Error in Africa?
> > 
> > Hi, Ticker.
> > 
> > Thanks for your investigation.
> > I am very impressed with how some people are using the wrong tags.
> > With --x-no-mergeroads option, my problem was fixed. Great!
> > 
> > Best regadrs,
> > Valrntin
> > 
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Driving side warnings

2020-09-14 Thread Ticker Berkin

Hi Gerd

Attached is a patch that doesn't assign a driving side to more types of
ways where it is not relevant. This speeds up processing slightly and,
in some circumstances, stop the warning:
"Tile contains both drive-on-left (#) and drive-on-right roads (#)"

Previously ferries were ignored, this patch additional ignores one-way
roads and roads that don't allow motor vehicles (eg footpaths &
cycleways)

Ticker
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(revision 4574)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java	(working copy)
@@ -305,6 +305,7 @@
 			
 			boolean wasReversed = false;
 			String oneWay = way.getTag(TK_ONEWAY);
+			boolean noDrivingSide = false;
 			if (oneWay != null){
 if("-1".equals(oneWay) || "reverse".equals(oneWay)) {
 	// it's a oneway street in the reverse direction
@@ -313,10 +314,12 @@
 	way.reverse();
 	wasReversed = true;
 	way.addTag(TK_ONEWAY, "yes");
+	noDrivingSide = true;
 }
 
 if (way.tagIsLikeYes(TK_ONEWAY)) {
 	way.addTag(TK_ONEWAY, "yes");
+	noDrivingSide = true;
 	if (foundType.isRoad() && hasSkipDeadEndCheckNode(way))
 		way.addTag("mkgmap:dead-end-check", "false");
 } else { 
@@ -328,7 +331,7 @@
 			if (cw.isRoad()){
 roads.add(cw);
 numRoads++;
-if (!cw.isFerry()) {
+if (!noDrivingSide && !cw.isFerry() && (cw.getAccess() & ~(AccessTagsAndBits.FOOT|AccessTagsAndBits.BIKE)) != 0) {
 	String countryIso = LocatorConfig.get().getCountryISOCode(way.getTag(TKM_COUNTRY));
 	if (countryIso != null) {
 		boolean drivingSideIsLeft = LocatorConfig.get().getDriveOnLeftFlag(countryIso);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error in Africa?

2020-09-14 Thread Gerd Petermann

Hi Ticker,

mergeRoads() is called before any addRoadsWithoutLoops().
I hope this clarifies all?

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 14. September 2020 15:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error in Africa?

Hi Gerd

I don't understand how splitting the road in addRoadsWithoutLoops()
changes anything - won't the bits (and the other OSM ways with same
typ/names/class/speed) just be joined up again during StyledConverted
end() processing in the call mergeRoads().

For a road with many points, it is going to be LineSplitterFilter that
creates too many road segments. Probably the easiest way to prevent
this many-pointed road causing this problem is to split it before
invoking the filter but after mergeRoads(). However I maintain that a
single OSM way won't cause the problem and so stopping RoadMerger from
creating the problem is a safe solution. RoadMerger.MAX_MERGED_POINTS
should be re-expressed as per StyledConverter.MAX_ROAD_POINTS.

I understand the change to remove the warning in MapSplitter about a
single item being too big.

Ticker

On Sun, 2020-09-06 at 08:56 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've now found the time to look at the details. The problem was not
> the size of the sub division but the number of Polyline instances
> created for the long road.
> This has to be < 0x80. The corresponding check was only implemented
> with an assert statement and Valentins call doesn't enable
> assertions, so invalid data was written.
> I've attached a patch which implements the splitting in
> StyledConverter and which throws a MapFailedException instead of
> using an assertion.
> Open problem: MapSplitter still
> SCHW: uk.me.parabola.mkgmap.build.MapSplitter
>  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> subdivision
> http://www.openstreetmap.org/?mlat=10.489948&mlon=-13.065190&zoom=17
> SCHW: uk.me.parabola.mkgmap.build.MapSplitter
>  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> subdivision
> http://www.openstreetmap.org/?mlat=10.368004&mlon=-12.969704&zoom=17
> while the map seems to be OK. So I think the estimation also needs a
> fix?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von valentin3...@gmail.com 
> Gesendet: Dienstag, 4. August 2020 12:28
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Error in Africa?
>
> Hi, Ticker.
>
> Thanks for your investigation.
> I am very impressed with how some people are using the wrong tags.
> With --x-no-mergeroads option, my problem was fixed. Great!
>
> Best regadrs,
> Valrntin
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] highway=unclassified & area=yes

2020-09-14 Thread Ticker Berkin

Hi Bernd

Once you start looking you see all sorts of mapping errors - I've been
finding a lot of roads mapped as long closed ways. What seems like a
common fix to this is to create a correctly joined and tagged linear
way and leave the area untouched.

I don't understand what you mean by creating highway=virtual; if
editing OSM you might just as well create a correct road. If defining
style rules just respect or ignore the highway type in conjunction with
area=yes.

I thought about doing what Mike Baggaley does and dropping all but
pedestrian/service but I felt this might lose some important roads so I
only drop "unclassified" because this seems to be the type chosen for
an arbitary commented area. I think some mappers thought "unclassified"
was not a real road and so wouldn't be used for routing, rather than
the formal OSM definition as a "minor public road".

Ticker

On Mon, 2020-09-14 at 10:37 +0200, Bernd Weigelt wrote:
> Hi
> 
> I have made a test in the region nearby and got lots of ways with
> area=yes
> 
> changed your rule a little bit ;-)
> 
> ... & area=yes {echo '${highway}'}
> 
> 
> Most of this ways didn't have a virtual way between each node across
> the area,
> so they are possibly lost for routing and create lot of islands, when
> deleting
> highway=*
> 
> I think this problem can't be solved with rules, only in the map
> data.
> 
> Maybe creating virtual way (highway=virtual) in the area is a
> solution, then
> the area can be used without routing problems
> 
> Bernd
> 
> Am Sonntag, 13. September 2020, 18:18:40 CEST schrieb Mike Baggaley:
> > In my style I have the following:
> > 
> > (highway=motorway | highway=trunk | highway=primary |
> > highway=secondary |
> > highway=tertiary | highway=motorway_link | highway=trunk_link |
> > highway=primary_link | highway=secondary_link |
> > highway=tertiary_link |
> > highway=residential | highway=unclassified | highway=track |
> > highway=bridleway | highway=cycleway | highway=footway |
> > highway=path) &
> > area=yes {delete highway} # delete unwanted areas
> > 
> > I leave highway=service and highway=pedestrian as these are valid
> > but the
> > others are not.
> 
> ___
> 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] Display Zipfile

2020-09-14 Thread Ticker Berkin

Hi Gerd

Trying to use display/src/test/ZipFile.java to reconstitute a tile .img
from the constituents in a .gmap directory tree or extracted from a
gmapsupp.img so I could run other display diagnostics I found it was
broken, probably due to blocksize optimisation project. I attach a
patch that gets it working again and has some comments about how it
might be used.

Ticker
Index: src/test/ZipFile.java
===
--- src/test/ZipFile.java	(revision 553)
+++ src/test/ZipFile.java	(working copy)
@@ -17,11 +17,15 @@
 package test;
 
 import uk.me.parabola.imgfmt.FileSystemParam;
+import uk.me.parabola.imgfmt.Sized;
 import uk.me.parabola.imgfmt.fs.FileSystem;
 import uk.me.parabola.imgfmt.fs.ImgChannel;
 import uk.me.parabola.imgfmt.sys.FileImgChannel;
+import uk.me.parabola.imgfmt.sys.FileLink;
 import uk.me.parabola.imgfmt.sys.ImgFS;
+import uk.me.parabola.imgfmt.Utils;
 
+import java.io.Closeable;
 import java.io.File;
 import java.io.IOException;
 import java.nio.ByteBuffer;
@@ -31,6 +35,17 @@
 /**
  * Combines several files into one .img file.
  * Kind of the opposite of ExtractFile.
+ *
+ * It can be used to reconstitute a tile .img file from the .LBL/.TRE/.RGN/.NET/.NOD etc files
+ * so that other display diagnostics can be run.
+ * eg, starting with just gmapsupp.img, extract all the components:
+ *  $ doDisplay test.ExtractFile gmapsupp.img
+ * or, from a --gmapi directory, the components are in $family-name.gmap/Product1/${tilename}
+ * then, for either:
+ *  $ doDisplay test.ZipFile ${tilename}.img ${tilename}.*
+ * now you can the various checks and displays in the tile, eg:
+ *  $ doDisplay test.check.NodCheck ${tilename}.img
+ *
  * @author Steve Ratcliffe
  */
 public class ZipFile {
@@ -57,19 +72,51 @@
 		for (String name : inlist) {
 			System.out.println("file " + name);
 			File f = new File(name);
-			try (FileImgChannel fin = new FileImgChannel(name, "r");
- ImgChannel fout = fs.create(f.getName().toUpperCase()))
-			{
-ByteBuffer buf = ByteBuffer.allocate(64*1024);
-while (fin.read(buf) > 0) {
-	buf.flip();
-	fout.write(buf);
-	buf.compact();
-}
-			}
+			FileCopier fc = new FileCopier(name);
+			ImgChannel fout = fs.create(f.getName().toUpperCase());
+			((FileLink)fout).link(fc, fc.file(fout));
 		}
 
-		fs.sync();
-		fs.close();
+		Utils.closeFile(fs);
 	}
 }
+
+/**
+ * Copies file to composite .img.
+ *
+ * based on similar in mkgmap/builders/GmapsuppBuilder.java
+ */
+class FileCopier implements Sized {
+	private final String filename;
+	private long fileSize;
+
+	public FileCopier(String filename) {
+		this.filename = filename;
+		File f = new File(filename);
+		fileSize = f.length();
+	}
+
+	Closeable file(ImgChannel fout) {
+		return () -> sync(fout);
+	}
+
+	public void sync(ImgChannel fout) throws IOException {
+		try (ImgChannel fin = new FileImgChannel(filename, "r")) {
+			copyFile(fin, fout);
+		}
+	}
+
+	private static void copyFile(ImgChannel fin, ImgChannel fout) throws IOException {
+		ByteBuffer buf = ByteBuffer.allocate(1024);
+		while (fin.read(buf) > 0) {
+			buf.flip();
+			fout.write(buf);
+			buf.compact();
+		}
+	}
+
+	public long getSize() {
+		return fileSize;
+	}
+
+}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error in Africa?

2020-09-14 Thread Ticker Berkin

Hi Gerd

I don't understand how splitting the road in addRoadsWithoutLoops()
changes anything - won't the bits (and the other OSM ways with same
typ/names/class/speed) just be joined up again during StyledConverted
end() processing in the call mergeRoads().

For a road with many points, it is going to be LineSplitterFilter that
creates too many road segments. Probably the easiest way to prevent
this many-pointed road causing this problem is to split it before
invoking the filter but after mergeRoads(). However I maintain that a
single OSM way won't cause the problem and so stopping RoadMerger from
creating the problem is a safe solution. RoadMerger.MAX_MERGED_POINTS
should be re-expressed as per StyledConverter.MAX_ROAD_POINTS.

I understand the change to remove the warning in MapSplitter about a
single item being too big.

Ticker

On Sun, 2020-09-06 at 08:56 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I've now found the time to look at the details. The problem was not
> the size of the sub division but the number of Polyline instances
> created for the long road.
> This has to be < 0x80. The corresponding check was only implemented
> with an assert statement and Valentins call doesn't enable
> assertions, so invalid data was written.
> I've attached a patch which implements the splitting in
> StyledConverter and which throws a MapFailedException instead of
> using an assertion.
> Open problem: MapSplitter still
> SCHW: uk.me.parabola.mkgmap.build.MapSplitter 
>  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> subdivision 
> http://www.openstreetmap.org/?mlat=10.489948&mlon=-13.065190&zoom=17
> SCHW: uk.me.parabola.mkgmap.build.MapSplitter 
>  f:\dwnload\temp\63240201.osm.pbf: Single item predicted to exceed
> subdivision 
> http://www.openstreetmap.org/?mlat=10.368004&mlon=-12.969704&zoom=17
> while the map seems to be OK. So I think the estimation also needs a
> fix?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von valentin3...@gmail.com 
> Gesendet: Dienstag, 4. August 2020 12:28
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Error in Africa?
> 
> Hi, Ticker.
> 
> Thanks for your investigation.
> I am very impressed with how some people are using the wrong tags.
> With --x-no-mergeroads option, my problem was fixed. Great!
> 
> Best regadrs,
> Valrntin
> 
> ___
> 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] DEM display level.

2020-09-14 Thread Joao Almeida

Yes, I've tested several times and seems to be if the map is big (area 
wise it behaves like that.


I can upload screenshots if it explains better

Thanks


On 14/9/20 17:57, Carlos Dávila wrote:
Are you sure BaseCamp doesn't also show DEM at 30 km-20 km zoom level in 
Mongolia map and 3000 km in Europe map?


El 14/9/20 a las 5:12, Joao Almeida escribió:

Hi,

I have a question about the behavior of mkgmap.
If I build 2 different maps using the same exact settings I get 2 
different outputs for DEM display.


Let me try to explain.

my settings for DEM :
--overview-dem-dist=8
--dem-dists=9942

If I build a map, let's say Mongolia, I have DEM rendering from zoom 
level 3000km in basecamp... obviously not very useful but it is there.


If I build another map, let's say of europe, the DEM rendering only 
occurs at zoomlevel 30km and below to 20m.


Does anyone know why?

Thank you
Joao

___
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] DEM display level.

2020-09-14 Thread Joao Almeida

Yes, I've tested several times and seems to be if the map is big (area 
wise it behaves like that.


I can upload screenshots if it explains better

Thanks

On 14/9/20 17:57, Carlos Dávila wrote:
Are you sure BaseCamp doesn't also show DEM at 30 km-20 km zoom level in 
Mongolia map and 3000 km in Europe map?


El 14/9/20 a las 5:12, Joao Almeida escribió:

Hi,

I have a question about the behavior of mkgmap.
If I build 2 different maps using the same exact settings I get 2 
different outputs for DEM display.


Let me try to explain.

my settings for DEM :
--overview-dem-dist=8
--dem-dists=9942

If I build a map, let's say Mongolia, I have DEM rendering from zoom 
level 3000km in basecamp... obviously not very useful but it is there.


If I build another map, let's say of europe, the DEM rendering only 
occurs at zoomlevel 30km and below to 20m.


Does anyone know why?

Thank you
Joao

___
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] highway=unclassified & area=yes

2020-09-14 Thread Bernd Weigelt

Hi

I have made a test in the region nearby and got lots of ways with area=yes

changed your rule a little bit ;-)

... & area=yes {echo '${highway}'}


Most of this ways didn't have a virtual way between each node across the area,
so they are possibly lost for routing and create lot of islands, when deleting
highway=*

I think this problem can't be solved with rules, only in the map data.

Maybe creating virtual way (highway=virtual) in the area is a solution, then
the area can be used without routing problems

Bernd

Am Sonntag, 13. September 2020, 18:18:40 CEST schrieb Mike Baggaley:
> In my style I have the following:
>
> (highway=motorway | highway=trunk | highway=primary | highway=secondary |
> highway=tertiary | highway=motorway_link | highway=trunk_link |
> highway=primary_link | highway=secondary_link | highway=tertiary_link |
> highway=residential | highway=unclassified | highway=track |
> highway=bridleway | highway=cycleway | highway=footway | highway=path) &
> area=yes {delete highway} # delete unwanted areas
>
> I leave highway=service and highway=pedestrian as these are valid but the
> others are not.



signature.asc
Description: This is a digitally signed message part.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] precomp sea test environment

2020-09-14 Thread Joris Bo

Hello Gerd

Sounds good. I think both use cases are necessary.
When compiling a new sea.zip it should complain avoiding it to be published or 
used.
When using a zip (with lots of thankyou to http://osm.thkukuk.de !! ) it should 
detect an accidentally bad zip and avoid starting the build process.

The chances of current land suddenly turning into sea is far less then broken 
coastlines, so I guess we don't need to worry about that. I assume the 
reference file can be 'fixed' as well within the mkgmap commits. Maybe the 
check should only be done if a specific option is given on the commandline. 
Then you can always continue in case of a bad reference not yet fixed.

Kind regards,
Joris






-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd Petermann
Verzonden: maandag 14 september 2020 11:33
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] precomp sea test environment

Hi all,

my current approach for a verification routine is this:
The precomp-sea data contains tiles 512*256 tiles, each covering an area of 
50.000x50.000 Garmin units. There is an index  that tells mkgmap if a tile is 
completely land or sea or if it contains a mix of both.  Only the mixed tiles 
are stored in pbf format.
Obviously the content of the mixed tiles are likely to change whenever someone 
changes the natural=coastline data. Also tiles with sea-only may change to 
mixed when a small island is mapped for the first time, so the check should 
only look at land-only tiles in the index.
Next thought: If an edge of such a land-only tile is very close to the coast it 
might become a (correct) mixed tile soon, but it should never be sea-only for a 
long time even with lots of global warming.

So, I have compiled a text file with 256 lines, each containing 512 characters 
(either x or blank) to indicate the land-only areas for a sea.zip created with 
land-polygons-split-4326 data from 2020-09-13.
(I might have used only one bit for each tile but it is much easier to maintain 
the text file and it is zipped to less than 4kb).
If you open the file with a text editor and chose a small font you'll see the 
familiar shapes of the continents and large islands.

My plan is to add this file as a reference to ressources and load it when the 
precomp-sea index is loaded (this happens only once when mkgmap is started). If 
the reference file contains an 'x' and the corresponding entry in the index 
says "sea-only" something is probably wrong.

I see two use cases:
1) PrecompSeaGenerator should warn when it computes a new set of precomp-sea 
data
2) mkgmap should warn when such a bad precomp-sea file is used. Open question: 
Should it always warn or only when the generated sea in any map tiles are 
affected?

Another possible approach would be to store also the mixed and sea-only status 
in the reference (see sea-check-lms.zip). This would allow to do more 
plausibility checks, e.g. if a previously sea-only tile became land-only. Not 
sure if this ever happened in the past.

What do you think? Did I miss something?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 12. September 2020 12:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] precomp sea test environment

Hi all,

it seems the correctness of the input files provided at [1] is not as good as 
Wanmil and I thought. Wrong data like a single closed way tagged 
natural=coastline near the center of Africa was not removed. I've corrected it 
a few minutes ago, see version 1 of https://www.openstreetmap.org/way/845273583.

Still working on a simple check ...

ciao,
Gerd
[1] https://osmdata.openstreetmap.de/data/land-polygons.html



Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Donnerstag, 10. September 2020 20:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] precomp sea test environment

Hi all,

OK, I'll try to find a good solution. For hgt files we have the file 
resources/known-hgt.bin  which tells mkgmap which *.hgt files it should be able 
to find. I think the same can be done for those rectangles which will always be 
"land" in the index.txt file. I just have to filter those which are close to 
the coast so that they might change.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Donnerstag, 10. September 2020 18:49
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] precomp sea test environment

I also face wrong sea from time to time. I agree a pre-check would be much 
useful. Also your sea-check style+empty tiles, thanks Gerd.

El 10/9/20 a las 11:27, Joris Bo escribió:
> Hi Gerd
>
> I recently (24-8-2020) had the same problem. The bad sea.zip was about 14Mb 
> smaller then usual.
> A pre-check and warning would be great.
>
> Kind Regards
> Joris
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens Gerd 
> Petermann
> Verzonden: donderdag 10 septemb

Re: [mkgmap-dev] precomp sea test environment

2020-09-14 Thread Gerd Petermann

Hi all,

my current approach for a verification routine is this:
The precomp-sea data contains tiles 512*256 tiles, each covering an area of 
50.000x50.000 Garmin units. There is an index  that tells mkgmap if a tile is 
completely land or sea or if it contains a mix of both.  Only the mixed tiles 
are stored in pbf format.
Obviously the content of the mixed tiles are likely to change whenever someone 
changes the natural=coastline data. Also tiles with sea-only may change to 
mixed when a small island is mapped for the first time, so the check should 
only look at land-only tiles in the index.
Next thought: If an edge of such a land-only tile is very close to the coast it 
might become a (correct) mixed tile soon, but it should never be sea-only for a 
long time even with lots of global warming.

So, I have compiled a text file with 256 lines, each containing 512 characters 
(either x or blank) to indicate the land-only areas for a sea.zip created with 
land-polygons-split-4326 data from 2020-09-13.
(I might have used only one bit for each tile but it is much easier to maintain 
the text file and it is zipped to less than 4kb).
If you open the file with a text editor and chose a small font you'll see the 
familiar shapes of the continents and large islands.

My plan is to add this file as a reference to ressources and load it when the 
precomp-sea index is loaded (this happens only once when mkgmap is started). If 
the reference file contains an 'x' and the corresponding entry in the index 
says "sea-only" something is probably wrong.

I see two use cases:
1) PrecompSeaGenerator should warn when it computes a new set of precomp-sea 
data
2) mkgmap should warn when such a bad precomp-sea file is used. Open question: 
Should it always warn or only when the generated sea in any map tiles are 
affected?

Another possible approach would be to store also the mixed and sea-only status 
in the reference (see sea-check-lms.zip). This would allow to do more 
plausibility checks, e.g. if a previously sea-only tile became land-only. Not 
sure if this ever happened in the past.

What do you think? Did I miss something?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 12. September 2020 12:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] precomp sea test environment

Hi all,

it seems the correctness of the input files provided at [1] is not as good as 
Wanmil and I thought. Wrong data like a single closed way tagged 
natural=coastline near the center of Africa was not removed. I've corrected it 
a few minutes ago, see version 1 of https://www.openstreetmap.org/way/845273583.

Still working on a simple check ...

ciao,
Gerd
[1] https://osmdata.openstreetmap.de/data/land-polygons.html



Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Donnerstag, 10. September 2020 20:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] precomp sea test environment

Hi all,

OK, I'll try to find a good solution. For hgt files we have the file 
resources/known-hgt.bin  which tells mkgmap which *.hgt files it should be able 
to find. I think the same can be done for those rectangles which will always be 
"land" in the index.txt file. I just have to filter those which are close to 
the coast so that they might change.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Donnerstag, 10. September 2020 18:49
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] precomp sea test environment

I also face wrong sea from time to time. I agree a pre-check would be
much useful. Also your sea-check style+empty tiles, thanks Gerd.

El 10/9/20 a las 11:27, Joris Bo escribió:
> Hi Gerd
>
> I recently (24-8-2020) had the same problem. The bad sea.zip was about 14Mb 
> smaller then usual.
> A pre-check and warning would be great.
>
> Kind Regards
> Joris
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens Gerd Petermann
> Verzonden: donderdag 10 september 2020 11:16
> Aan: mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: [mkgmap-dev] precomp sea test environment
>
> Hi all,
>
> today I stumbled over a bad sea.zip file that was created in 2019-11-08. Most 
> of the two Americas was flooded.
> I wondered if I should add some code to mkgmap to detect this case?  Eg. 
> mkgmap could check some points which are clearly inside continents.
>
> Besides that it is rather simple to produce a test style for the sea which 
> just creates an overview map. I've created some empty tiles which cover full 
> planet and used them to create an overview map containing only sea polygons. 
> This compilation takes ~1 minute. A quick glance at osmmap.img should show 
> the familiar shapes of the continents, if not something is wrong and that 
> probably means that the precomp-sea data is bad.
> I've attached this, maybe it is of some help.
>
> Gerd
>
>
>
>
> _

Re: [mkgmap-dev] DEM display level.

2020-09-14 Thread Carlos Dávila

Are you sure BaseCamp doesn't also show DEM at 30 km-20 km zoom level in 
Mongolia map and 3000 km in Europe map?


El 14/9/20 a las 5:12, Joao Almeida escribió:

Hi,

I have a question about the behavior of mkgmap.
If I build 2 different maps using the same exact settings I get 2 
different outputs for DEM display.


Let me try to explain.

my settings for DEM :
--overview-dem-dist=8
--dem-dists=9942

If I build a map, let's say Mongolia, I have DEM rendering from zoom 
level 3000km in basecamp... obviously not very useful but it is there.


If I build another map, let's say of europe, the DEM rendering only 
occurs at zoomlevel 30km and below to 20m.


Does anyone know why?

Thank you
Joao

___
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] DEM There is not enough room in a single garmin map for all the input data

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

Re: [mkgmap-dev] Error in Africa?

[mkgmap-dev] Driving side warnings

Re: [mkgmap-dev] Error in Africa?

Re: [mkgmap-dev] highway=unclassified & area=yes

[mkgmap-dev] Display Zipfile

Re: [mkgmap-dev] Error in Africa?

Re: [mkgmap-dev] DEM display level.

Re: [mkgmap-dev] DEM display level.

Re: [mkgmap-dev] highway=unclassified & area=yes

Re: [mkgmap-dev] precomp sea test environment

Re: [mkgmap-dev] precomp sea test environment

Re: [mkgmap-dev] DEM display level.

17 matches

Site Navigation

Mail list logo

Footer information