Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot. Now i have one observation and a few questions. 1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps? 2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all. Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something. I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example? If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP. 3.
From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22] But even with this, the parking polygons do not show any picture/symbol. What else is needed? Kind regards Karl
Hi Karl, reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files. Hi. Still on my learning path, and thanks for good documents, which have helped a lot. Now i have one observation and a few questions. 1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps? 2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all. Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something. I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example? If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP. 3.
From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22] But even with this, the parking polygons do not show any picture/symbol. What else is needed? Kind regards Karl _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, unfortunately --no-trim has not helped, i can still observe such gaps. The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log Kind regards Karl On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl, please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/ Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files. Hi, unfortunately --no-trim has not helped, i can still observe such gaps. The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log Kind regards Karl On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, screenshot and log uploaded. Kind regards, Karl On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl, okay, looked at 217.bmp. It doesn't seem to be related to tile boundaries. I think someone else reported similar problems, only visible on the device. I've never seen them on my Oregon. Do the gaps disappear when you zoom in or out? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 15:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files. Hi Gerd, screenshot and log uploaded. Kind regards, Karl On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi. Both actually, i can follow such lines for many kilometers. In the past i was also able to find similar cases on www.opentopomap.org, which for sure has routing problems over longer distances. Here is one such place which i was able to locate just now: https://www.opentopomap.org/#map=15/58.92148/18.28258 If i recall correctly, this show (or showed) a white line on a GPS. Kind regards, Karl On fredag 9 oktober 2020 kl. 15:41:35 CEST Gerd Petermann wrote:
Hi Karl,
okay, looked at 217.bmp. It doesn't seem to be related to tile boundaries. I think someone else reported similar problems, only visible on the device. I've never seen them on my Oregon. Do the gaps disappear when you zoom in or out?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 15:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi Gerd, screenshot and log uploaded. Kind regards, Karl
On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Karl, I think this might be related to the multipolygon cutting. There is this comment in the code for MultipolygonCutter: // try to find a cut point that is a multiple of 2048 to // avoid that gaps are painted by MapSource and QLandkarteGT // between the cutting lines In some cases this fails, maybe you see the result. I don't think that we can always find such a good cut point, so there is probably not much we can do about it. @Ticker: Is it possible that option --order-by-decreasing-area produces more of these cases? Besides that it is unlikely that this has an effect on routing. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 16:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files. Hi. Both actually, i can follow such lines for many kilometers. In the past i was also able to find similar cases on www.opentopomap.org, which for sure has routing problems over longer distances. Here is one such place which i was able to locate just now: https://www.opentopomap.org/#map=15/58.92148/18.28258 If i recall correctly, this show (or showed) a white line on a GPS. Kind regards, Karl On fredag 9 oktober 2020 kl. 15:41:35 CEST Gerd Petermann wrote:
Hi Karl,
okay, looked at 217.bmp. It doesn't seem to be related to tile boundaries. I think someone else reported similar problems, only visible on the device. I've never seen them on my Oregon. Do the gaps disappear when you zoom in or out?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 15:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi Gerd, screenshot and log uploaded. Kind regards, Karl
On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP-files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes, --order-by-decreasing-area will cause more polygon splitting as it forces polygons to be split with the subdivision splitting. However the code does try to keep the subdivision splitting to appropriate power-of -2 for for the zoom level (as far as I can remember) I've often seen narrow white bands like this, mainly in the sea where they are more obvious. If I remember correctly this was noticeable on BaseCamp and they come and go with zooming, even within the same map -level. Ticker On Sat, 2020-10-10 at 06:09 +0000, Gerd Petermann wrote:
Hi Karl,
I think this might be related to the multipolygon cutting. There is this comment in the code for MultipolygonCutter: // try to find a cut point that is a multiple of 2048 to // avoid that gaps are painted by MapSource and QLandkarteGT // between the cutting lines
In some cases this fails, maybe you see the result. I don't think that we can always find such a good cut point, so there is probably not much we can do about it. @Ticker: Is it possible that option --order-by-decreasing-area produces more of these cases?
Besides that it is unlikely that this has an effect on routing.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 16:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi. Both actually, i can follow such lines for many kilometers. In the past i was also able to find similar cases on www.opentopomap.org, which for sure has routing problems over longer distances.
Here is one such place which i was able to locate just now: https://www.opentopomap.org/#map=15/58.92148/18.28258 If i recall correctly, this show (or showed) a white line on a GPS.
Kind regards, Karl
On fredag 9 oktober 2020 kl. 15:41:35 CEST Gerd Petermann wrote:
Hi Karl,
okay, looked at 217.bmp. It doesn't seem to be related to tile boundaries. I think someone else reported similar problems, only visible on the device. I've never seen them on my Oregon. Do the gaps disappear when you zoom in or out?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 15:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi Gerd, screenshot and log uploaded. Kind regards, Karl
On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, Ticker and Karl just for information, in April i've made a Garmin Map for whole Europe just to see, if its working on my environment. And having a look into the Stockholm Area Karl mentioned, i do not see these artefacts on my map opened in MapSource. I didnt check it on my GPSMAP 276Cx. See also the attached picture, hope it will come through Am 10.10.2020 um 10:42 schrieb Ticker Berkin:
Hi Gerd
Yes, --order-by-decreasing-area will cause more polygon splitting as it forces polygons to be split with the subdivision splitting. However the code does try to keep the subdivision splitting to appropriate power-of -2 for for the zoom level (as far as I can remember)
I've often seen narrow white bands like this, mainly in the sea where they are more obvious. If I remember correctly this was noticeable on BaseCamp and they come and go with zooming, even within the same map -level.
Ticker
On Sat, 2020-10-10 at 06:09 +0000, Gerd Petermann wrote:
Hi Karl,
I think this might be related to the multipolygon cutting. There is this comment in the code for MultipolygonCutter: // try to find a cut point that is a multiple of 2048 to // avoid that gaps are painted by MapSource and QLandkarteGT // between the cutting lines
In some cases this fails, maybe you see the result. I don't think that we can always find such a good cut point, so there is probably not much we can do about it. @Ticker: Is it possible that option --order-by-decreasing-area produces more of these cases?
Besides that it is unlikely that this has an effect on routing.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 16:49 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi. Both actually, i can follow such lines for many kilometers. In the past i was also able to find similar cases on www.opentopomap.org, which for sure has routing problems over longer distances.
Here is one such place which i was able to locate just now: https://www.opentopomap.org/#map=15/58.92148/18.28258 If i recall correctly, this show (or showed) a white line on a GPS.
Kind regards, Karl
On fredag 9 oktober 2020 kl. 15:41:35 CEST Gerd Petermann wrote:
Hi Karl,
okay, looked at 217.bmp. It doesn't seem to be related to tile boundaries. I think someone else reported similar problems, only visible on the device. I've never seen them on my Oregon. Do the gaps disappear when you zoom in or out?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 15:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi Gerd, screenshot and log uploaded. Kind regards, Karl
On fredag 9 oktober 2020 kl. 14:43:30 CEST Gerd Petermann wrote:
Hi Karl,
please upload a screenshot and the splitter.log to http://files.mkgmap.org.uk/
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 14:40 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi, unfortunately --no-trim has not helped, i can still observe such gaps.
The splitter command: java -Xmx1200m -jar ../mkgmap/splitter-r597/splitter.jar \ --output-dir=norden/splitted/ \ --mapid=77700001 \ --max-nodes=1500000 \ --no-trim \ norden/norden.o5m > norden/splitted/splitter.log
Kind regards Karl
On fredag 9 oktober 2020 kl. 11:51:24 CEST Gerd Petermann wrote:
Hi Karl,
reg. the gaps betweet tiles: This sounds like you use splitter with --no-trim=false. Try without it.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7700 <7770@foskan.eu> Gesendet: Freitag, 9. Oktober 2020 11:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Disconnected map sections, types in TYP -files.
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
Now i have one observation and a few questions.
1. i observe that in the map created (mkgmap 4585) i can see disconnected map sections, they usually show up as a thin white line in the map, often easier to see over water or darker areas. The gap sometimes makes the routing calculations fail if the gap is in the routing direction and big enough. I have observed these gaps not inly in the maps have made, but also at opentopomap, but not with garmin.opensteetmap.nl (to mention some examples). Pictures can be provided if wanted. Is there a proper way to eliminate these gaps when generating the maps?
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set? Is the example mapnik.txt file complete or just an example?
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
3. From which type number can i define my own type to avoid collission with existing types? I am thinking of adding handling for aerialways.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ 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
-- ##################################################### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de #####################################################
Hi Some TYP file answers embedded. Regards Ticker On Fri, 2020-10-09 at 11:37 +0200, 7700 wrote:
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
If you have a TYP file, I think it is correct that any polygons not in the [_draworder] section won't show. If you don't have a [_polygon] entry, you'll get the default representation for your device. Information on the default [_draworder] assumed by some devices is documented here and there on the web and there are comments about it in mkgmap-rXXXX/examples/typ-files/sameOrder.txt
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set?
There have been postings in this group about all the types generated from the default style. You have to examine examples/styles/default/{points,lines,polygons} for the current, definitive, list
Is the example mapnik.txt file complete or just an example?
I think it has an entry for everything in the current default style.
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
Yes - a big difference. mapnik.txt is attempting to reproduce a particular look. I find that it doesn't look good on small devices and I much prefer a very basic TYP file that doesn't change anything where most devices give a reasonable representation by default.
3. From which type number can i define my own type to avoid collission with existing types?
For lines, you need to beware of routable/non-routable and there are not many free entries in the non-extended section.
I am thinking of adding handling for aerialways.
Look at the thread "default style lines enhancements" from july: http://gis.19327.n8.nabble.com/default-style-lines-enhancements-td59712 80.html It has something on this.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
I think you are just seeking the [_point] parking icon 0x2f0b. Depending on the OSM tagging, there might be a polygon with type 0x05 or 0x06.
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
to define a polygon icon or solid colour that will be repeated over the parking area. mapnik.txt just defines a solid colour
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi! Thanks for answers. --add-pois-to-areas helped to achieve a map to display an icon on some types of areas, such as parking lots. Thanks for hints. About the mapnik TYP file which is included in mkgmap. in the [_drawOrder] section types seems to be prefixed with an extra zero, say 0x03d, but later the same type is given as 0x3d. Is there a reason for that, or can i just as well change the numbers and remove the extra zero? In the TYP file, i am considering adding swedish names, which i hope to post later when done if you think it is of help. Swedish has a string code 0x07 (iirc), but may i choose StringN where N is a number freely from one not yet taken? I tried mapping aerialways to railroad, that was the best i could think of. They do work in similar way, there is a fixed infrastructure, often with fixed entry and exit points, cars can usually not route, but pedestrians may. On land i guess that typically one cannot cross the rail at any point, but it is often possible under the aerialway. This seems to work and is a possible addition in lines file, just after railway (after line 236): # Add ski lifts and alike aerialway=* {add name='Aerialway ${name} (${aerialway})' | 'Aerialway ($ {aerialway})' } [0x14 resolution 22] An off topic question, i noted that on GPSMAP 66st the fuel stations (amenity=fuel) never show up earlier than if zooming in to 80 m or closer which is rather inconvenient when driving and looking at the map to locate a fuel station. It does not help to set the device to show more or most details, nor to change the resolution while compiling the maps. Is there some way to force some types to show earlier? As a note, on a etrex vista hcx the fuel stations show earlier if i changed the resolution. Regards Karl On fredag 9 oktober 2020 kl. 15:48:42 CEST Ticker Berkin wrote:
Hi
Some TYP file answers embedded.
Regards Ticker
On Fri, 2020-10-09 at 11:37 +0200, 7700 wrote:
Hi. Still on my learning path, and thanks for good documents, which have helped a lot.
2. When working with TYP files, i have read: If a polygon type is not listed in this section, then it will not be displayed at all.
Is this valid? If it is, then it means i really have to add every single item which may be generated and which is on the map, otherwise i risk loosing information without even knowing, say if i want to change very small portions from how the device displays something.
If you have a TYP file, I think it is correct that any polygons not in the [_draworder] section won't show. If you don't have a [_polygon] entry, you'll get the default representation for your device.
Information on the default [_draworder] assumed by some devices is documented here and there on the web and there are comments about it in mkgmap-rXXXX/examples/typ-files/sameOrder.txt
I have found that there some information sets that cover a lot of types that garmin devices can show, but is it possible to extract a list from mkgmap, for example extracting the default set?
There have been postings in this group about all the types generated from the default style. You have to examine examples/styles/default/{points,lines,polygons} for the current, definitive, list
Is the example mapnik.txt file complete or just an example?
I think it has an entry for everything in the current default style.
If i didn't make errors, it seems there is a difference between generating gmapsupp with no TYP and this example TYP.
Yes - a big difference. mapnik.txt is attempting to reproduce a particular look. I find that it doesn't look good on small devices and I much prefer a very basic TYP file that doesn't change anything where most devices give a reasonable representation by default.
3. From which type number can i define my own type to avoid collission with existing types?
For lines, you need to beware of routable/non-routable and there are not many free entries in the non-extended section.
I am thinking of adding handling for aerialways.
Look at the thread "default style lines enhancements" from july: http://gis.19327.n8.nabble.com/default-style-lines-enhancements-td59712 80.html It has something on this.
4. Related to the polygon amenity=parking and displaying of a picture. on maps such as from garmin.openstreetmap.nl, the polygon for amenity=parking displays the same parking symbol (garmin default, round with red P and black border) as for a point amenity=parking. I tried generating the individual tiles with the style present from mkgmap using --style-file=path/styles/, in which i see a mapping in the polygons file: amenity=parking | parking=surface [0x05 resolution 22]
I think you are just seeking the [_point] parking icon 0x2f0b. Depending on the OSM tagging, there might be a polygon with type 0x05 or 0x06.
But even with this, the parking polygons do not show any picture/symbol. What else is needed?
to define a polygon icon or solid colour that will be repeated over the parking area. mapnik.txt just defines a solid colour
Kind regards Karl
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Some more answers embedded Ticker On Thu, 2020-10-15 at 22:01 +0200, 7770 wrote:
Hi! Thanks for answers.
--add-pois-to-areas helped to achieve a map to display an icon on some types of areas, such as parking lots. Thanks for hints.
About the mapnik TYP file which is included in mkgmap. in the [_drawOrder] section types seems to be prefixed with an extra zero, say 0x03d, but later the same type is given as 0x3d. Is there a reason for that, or can i just as well change the numbers and remove the extra zero?
Some of the dedicated TYP editors reformat the file and one puts in these leading zeros. They do no harm but make file file more difficult to search. I'd recommend not making global changes at the same time as significant changes so that the diff/patch is small and clearly shows what you intend
In the TYP file, i am considering adding swedish names, which i hope to post later when done if you think it is of help. Swedish has a string code 0x07 (iirc), but may i choose StringN where N is a number freely from one not yet taken?
Yes - add swedish (is 0x07), you can use any StringN - mkgmap doesn't care.
I tried mapping aerialways to railroad, that was the best i could think of. They do work in similar way, there is a fixed infrastructure, often with fixed entry and exit points, cars can usually not route, but pedestrians may. On land i guess that typically one cannot cross the rail at any point, but it is often possible under the aerialway. This seems to work and is a possible addition in lines file, just after railway (after line 236): # Add ski lifts and alike aerialway=* {add name='Aerialway ${name} (${aerialway})' | 'Aerialway ($ {aerialway})' } [0x14 resolution 22]
I consider aerielways closer to footways or pedestrian ferries because they are point-to-point and can be used in a route. I have this in my style: aerialway=cable_car | aerialway=gondola | railway=funicular { add aerialway=funicular; # for following add name='${aerialway|subst:"_=> "}'; add vehicle=no; set mkgmap:toll='${toll}' | '${fee}' | yes; set mkgmap:ferry=yes; set mkgmap:numbers=false; } [0x2f road_class=0 road_speed=1 resolution 22] I set ferry as I hopes it stops "closest way" to start/end of route. 0x2f is considered by BaseCamp to be "Cable Car"; other Garmin software might have a different interpretation.
An off topic question, i noted that on GPSMAP 66st the fuel stations (amenity=fuel) never show up earlier than if zooming in to 80 m or closer which is rather inconvenient when driving and looking at the map to locate a fuel station. It does not help to set the device to show more or most details, nor to change the resolution while compiling the maps. Is there some way to force some types to show earlier?
Not that I know of. You could try putting out another POI that shows at a lower resolution, but you'd have to experiment with your particular device. Assuming you need fuel to be findable, consider something like: amenity=fuel [0x2f01 resolution 23] [0x230f resolution 20-22] I've not tried this, but 0x230f shows as a fuel pump on one of my devices at this resolution
As a note, on a etrex vista hcx the fuel stations show earlier if i changed the resolution. Regards Karl
participants (5)
-
7700 -
7770
-
DD8KQ -
Gerd Petermann -
Ticker Berkin