Spurious points & Basecamp blank tiles
Hi, I have been creating Garmin map from Finnish national topographic database and lately I updated the process to use mkgmap to convert OSM PBF files to Garmin IMG. I have encountered a problem with Garmin PC software showing blank tiles (http://kartat.hylly.org/mkgmap/mkgmap2.png) and digging further i discovered that there are extra points in IMG files on those tiles http://kartat.hylly.org/mkgmap/mkgmap1.png. These points does not exist in the source data (http://kartat.hylly.org/mkgmap/M431_osm.osm.pbf and http://kartat.hylly.org/mkgmap/mkgmap3.png) nor are those Garmin types referenced in any way in style files (https://github.com/pailakka/mtk2garmin/tree/master/mtk2garmin_style). Do you have any idea what I might be doing wrong, or any pointers which way to look in mkgmap source is this happens to be some kind of bug in mkgmap? Best regards, Teemu Peltonen
This is not a mkgmap error but clearly points to a type number Basecamp objects to. Perhaps your 0x30 in lines? -- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
7.11.2016, 20:59, nwillink kirjoitti:
This is not a mkgmap error but clearly points to a type number Basecamp objects to.
Perhaps your 0x30 in lines?
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
0x30 types were problematic, but I tested that these artifacts are created without 0x30 lines. It looks like artifacts appear after I merge original OSM data to pbf files. Original custom pbf files converted from National Topographic Database GML has node/way/relations ids starting from 5000000000. Merged OSM data naturally has much smaller ids. I'm thinking this could have something to do with this problem. -Teemu
Hi Teemu, I do not yet know why but it seems that it causes problems when you use type 0x1001 in the points file. Either this type is not allowed or mkgmap does something wrong when it encodes it for the img format. Gerd Teemu Peltonen wrote
Hi,
I have been creating Garmin map from Finnish national topographic database and lately I updated the process to use mkgmap to convert OSM PBF files to Garmin IMG. I have encountered a problem with Garmin PC software showing blank tiles (http://kartat.hylly.org/mkgmap/mkgmap2.png) and digging further i discovered that there are extra points in IMG files on those tiles http://kartat.hylly.org/mkgmap/mkgmap1.png. These points does not exist in the source data (http://kartat.hylly.org/mkgmap/M431_osm.osm.pbf and http://kartat.hylly.org/mkgmap/mkgmap3.png) nor are those Garmin types referenced in any way in style files (https://github.com/pailakka/mtk2garmin/tree/master/mtk2garmin_style).
Do you have any idea what I might be doing wrong, or any pointers which way to look in mkgmap source is this happens to be some kind of bug in mkgmap?
Best regards,
Teemu Peltonen
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all. My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx. I don't know if this is a problem of Garmin devices or cGPSmapper. -- Best regards, Andrzej
Hi, those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens. -Teemu On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Teemu, please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that. Gerd Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski <
popej@.onet
> wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with cGPSmapper and contains point type 0x1001 (among other rather exotic types) without problems. Polish map file used to generate this file can be found from http://kartat.hylly.org/mkgmap/M431.7z. It also looks like that these artifacts does not exists when the img is created from a pbf file containing no actual OSM data. Map generated from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style definitions works perfectly fine. 0x1001 points are, however missing so they might definitely be part of the problem. The only difference between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is that OSM data is merged to M431_osm.osm.pbf with osmconvert. -Teemu 9.11.2016, 13:40, Gerd Petermann kirjoitti:
Hi Teemu,
please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that.
Gerd
Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski < popej@.onet > wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, there are points 0x1001 in img and it looks correctly in BaseCamp. If I compile mp with mkgmap, then points 0x1001 becomes 0x1000 but map still works in BaseCamp. -- Best regards, Andrzej
Hi Teemu, Maybe I have a fix for this. We have special code in mkgmap for POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities and those are special. With the attached patch only those with subtype = 0 are: type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0 This seems to fix the problem, but maybe it is only a workaround. Another observation: The MP file gives a label for each of these 0x1001 POI, the pbf file doesn't. A binary based on r3701 is here: http://files.mkgmap.org.uk/download/312/mkgmap.jar type_0x1001.patch <http://gis.19327.n8.nabble.com/file/n5885745/type_0x1001.patch> Gerd Teemu Peltonen wrote
Hi,
http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with cGPSmapper and contains point type 0x1001 (among other rather exotic types) without problems. Polish map file used to generate this file can be found from http://kartat.hylly.org/mkgmap/M431.7z.
It also looks like that these artifacts does not exists when the img is created from a pbf file containing no actual OSM data. Map generated from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style definitions works perfectly fine. 0x1001 points are, however missing so they might definitely be part of the problem. The only difference between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is that OSM data is merged to M431_osm.osm.pbf with osmconvert.
-Teemu
9.11.2016, 13:40, Gerd Petermann kirjoitti:
Hi Teemu,
please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that.
Gerd
Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski < popej@.onet > wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi all, I did not get any feedback on this patch. I am not sure if it fixes the problem or if it's just a work around. Does anybody expect a problem with it? Gerd Gerd Petermann wrote
Hi Teemu,
Maybe I have a fix for this. We have special code in mkgmap for POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities and those are special. With the attached patch only those with subtype = 0 are: type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0
This seems to fix the problem, but maybe it is only a workaround. Another observation: The MP file gives a label for each of these 0x1001 POI, the pbf file doesn't.
A binary based on r3701 is here: http://files.mkgmap.org.uk/download/312/mkgmap.jar type_0x1001.patch <http://gis.19327.n8.nabble.com/file/n5885745/type_0x1001.patch>
Gerd Teemu Peltonen wrote
Hi,
http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with cGPSmapper and contains point type 0x1001 (among other rather exotic types) without problems. Polish map file used to generate this file can be found from http://kartat.hylly.org/mkgmap/M431.7z.
It also looks like that these artifacts does not exists when the img is created from a pbf file containing no actual OSM data. Map generated from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style definitions works perfectly fine. 0x1001 points are, however missing so they might definitely be part of the problem. The only difference between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is that OSM data is merged to M431_osm.osm.pbf with osmconvert.
-Teemu
9.11.2016, 13:40, Gerd Petermann kirjoitti:
Hi Teemu,
please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that.
Gerd
Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski < popej@.onet > wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Is the following syntax correct? seamark:type=fairway {name 'fairway'} { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=02 } [0x10302 resolution 18] Von: Gerd Petermann Gesendet: Mittwoch, 16. November 2016 16:38 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles Hi all, I did not get any feedback on this patch. I am not sure if it fixes the problem or if it's just a work around. Does anybody expect a problem with it? Gerd Gerd Petermann wrote
Hi Teemu,
Maybe I have a fix for this. We have special code in mkgmap for POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities and those are special. With the attached patch only those with subtype = 0 are: type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0
This seems to fix the problem, but maybe it is only a workaround. Another observation: The MP file gives a label for each of these 0x1001 POI, the pbf file doesn't.
A binary based on r3701 is here: http://files.mkgmap.org.uk/download/312/mkgmap.jar type_0x1001.patch <http://gis.19327.n8.nabble.com/file/n5885745/type_0x1001.patch>
Gerd Teemu Peltonen wrote
Hi,
http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with cGPSmapper and contains point type 0x1001 (among other rather exotic types) without problems. Polish map file used to generate this file can be found from http://kartat.hylly.org/mkgmap/M431.7z.
It also looks like that these artifacts does not exists when the img is created from a pbf file containing no actual OSM data. Map generated from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style definitions works perfectly fine. 0x1001 points are, however missing so they might definitely be part of the problem. The only difference between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is that OSM data is merged to M431_osm.osm.pbf with osmconvert.
-Teemu
9.11.2016, 13:40, Gerd Petermann kirjoitti:
Hi Teemu,
please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that.
Gerd
Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski < popej@.onet > wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area. Also, slightly confusing to have level and resolution in the same style. And the wrong thread. Regards Ticker
My first test look really promising. All the draw order problems for fairway on river Rhine in the Mainz/Wiesbaden area are gone. It looks very beautiful now: https://mega.nz/#!dFE1QIKK!BfIobp0WApKJtGdthwWvDt8IzNluZSwOaixW7PnmvJk However I still found one spot where the fairway is still not visible: https://mega.nz/#!IM1FjK6R!Q0pDo43Qu8alan4Qrk4QCGsQtTyoQg7eWQx5cLs_EU8 But this should not be a mkgmap issue because same problem also exists in openseamap online map. I will investigate further and keep you informed. Thank you so much for this great improvement. It is a huge step for the openseamap project because it is pre-condition for rendering crowdsourced water depth as different shades of blue. There are 7 different predefined extended types for water depth which all have same built in draw order. Now chances are good that they can be controlled. And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style is based on default style which uses RESOLUTION. Von: Ticker Berkin Gesendet: Mittwoch, 16. November 2016 17:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area. Also, slightly confusing to have level and resolution in the same style. And the wrong thread. Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
My first test look really promising. All the draw order problems for fairway on river Rhine in the Mainz/Wiesbaden area are gone. It looks very beautiful now: https://mega.nz/#!dFE1QIKK!BfIobp0WApKJtGdthwWvDt8IzNluZSwOaixW7PnmvJk However I still found one spot where the fairway is still not visible: https://mega.nz/#!IM1FjK6R!Q0pDo43Qu8alan4Qrk4QCGsQtTyoQg7eWQx5cLs_EU8 But this should not be a mkgmap issue because same problem also exists in openseamap online map. I will investigate further and keep you informed. Thank you so much for this great improvement. It is a huge step for the openseamap project because it is pre-condition for rendering crowdsourced water depth as different shades of blue. There are 7 different predefined extended types for water depth which all have same built in draw order. Now chances are good that they can be controlled. And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style is based on default style which uses RESOLUTION. Ups, thread was still wrong. Von: Ticker Berkin Gesendet: Mittwoch, 16. November 2016 17:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area. Also, slightly confusing to have level and resolution in the same style. And the wrong thread. Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Meanwhile I repaired the “Bad Godesberg” fairway polygon (in osm data) and now can confirm that draw order works perfectly for fairway on river polygons. After that I tested intertidal zones on top of sea polygons. Everything works perfect. It is amazing: https://mega.nz/#!oJ1WmLKT!AbxYucPbfP79F1Rv_5B5btUK3KkkWktBnqtyfTZIBV8 I tried to achieve this for about 5 years, but had no chance. And now it works. Many thanks to Ticker for making this possible. And sorry for mixing up threads. It´s because I´m so excited about the new feature! Von: rheinskipper1000@gmx.de Gesendet: Mittwoch, 16. November 2016 18:45 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area My first test look really promising. All the draw order problems for fairway on river Rhine in the Mainz/Wiesbaden area are gone. It looks very beautiful now: https://mega.nz/#!dFE1QIKK!BfIobp0WApKJtGdthwWvDt8IzNluZSwOaixW7PnmvJk However I still found one spot where the fairway is still not visible: https://mega.nz/#!IM1FjK6R!Q0pDo43Qu8alan4Qrk4QCGsQtTyoQg7eWQx5cLs_EU8 But this should not be a mkgmap issue because same problem also exists in openseamap online map. I will investigate further and keep you informed. Thank you so much for this great improvement. It is a huge step for the openseamap project because it is pre-condition for rendering crowdsourced water depth as different shades of blue. There are 7 different predefined extended types for water depth which all have same built in draw order. Now chances are good that they can be controlled. And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style is based on default style which uses RESOLUTION. Ups, thread was still wrong. Von: Ticker Berkin Gesendet: Mittwoch, 16. November 2016 17:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area. Also, slightly confusing to have level and resolution in the same style. And the wrong thread. Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
After some more testing I can confirm that even three different draw levels also work as expected. This example shows fairway on top of intertidal zone which is on top of sea polygon: https://drive.google.com/file/d/0Bz9KchYfWW3reHRrSGR6c0Jmc0U/view?usp=sharin... But I got some errors regarding ShapeMergeFilter which I think were introduced with the new option: https://drive.google.com/file/d/0Bz9KchYfWW3rbUhkMVF2R3p4REU/view?usp=sharin... Von: rheinskipper1000@gmx.de Gesendet: Mittwoch, 16. November 2016 22:08 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area Meanwhile I repaired the “Bad Godesberg” fairway polygon (in osm data) and now can confirm that draw order works perfectly for fairway on river polygons. After that I tested intertidal zones on top of sea polygons. Everything works perfect. It is amazing: https://mega.nz/#!oJ1WmLKT!AbxYucPbfP79F1Rv_5B5btUK3KkkWktBnqtyfTZIBV8 I tried to achieve this for about 5 years, but had no chance. And now it works. Many thanks to Ticker for making this possible. And sorry for mixing up threads. It´s because I´m so excited about the new feature! Von: rheinskipper1000@gmx.de Gesendet: Mittwoch, 16. November 2016 18:45 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area My first test look really promising. All the draw order problems for fairway on river Rhine in the Mainz/Wiesbaden area are gone. It looks very beautiful now: https://mega.nz/#!dFE1QIKK!BfIobp0WApKJtGdthwWvDt8IzNluZSwOaixW7PnmvJk However I still found one spot where the fairway is still not visible: https://mega.nz/#!IM1FjK6R!Q0pDo43Qu8alan4Qrk4QCGsQtTyoQg7eWQx5cLs_EU8 But this should not be a mkgmap issue because same problem also exists in openseamap online map. I will investigate further and keep you informed. Thank you so much for this great improvement. It is a huge step for the openseamap project because it is pre-condition for rendering crowdsourced water depth as different shades of blue. There are 7 different predefined extended types for water depth which all have same built in draw order. Now chances are good that they can be controlled. And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style is based on default style which uses RESOLUTION. Ups, thread was still wrong. Von: Ticker Berkin Gesendet: Mittwoch, 16. November 2016 17:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles Hi Not quite, you should have something like: seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18] but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area. Also, slightly confusing to have level and resolution in the same style. And the wrong thread. Regards Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Can you drop some sample input that shows this behaviour along with your command-line/options and style somewhere, and I'll try and work out what is happening. Ticker On Thu, 2016-11-17 at 15:04 +0100, rheinskipper1000@gmx.de wrote:
After some more testing I can confirm that even three different draw levels also work as expected. This example shows fairway on top of intertidal zone which is on top of sea polygon: https://drive.google.com/file/d/0Bz9KchYfWW3reHRrSGR6c0Jmc0U/view?usp =sharing
But I got some errors regarding ShapeMergeFilter which I think were introduced with the new option: https://drive.google.com/file/d/0Bz9KchYfWW3rbUhkMVF2R3p4REU/view?usp =sharing
Von: rheinskipper1000@gmx.de Gesendet: Mittwoch, 16. November 2016 22:08 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
Meanwhile I repaired the “Bad Godesberg” fairway polygon (in osm data) and now can confirm that draw order works perfectly for fairway on river polygons.
After that I tested intertidal zones on top of sea polygons. Everything works perfect. It is amazing: https://mega.nz/#!oJ1WmLKT!AbxYucPbfP79F1Rv_5B5btUK3KkkWktBnqtyfTZIBV 8
I tried to achieve this for about 5 years, but had no chance. And now it works. Many thanks to Ticker for making this possible.
And sorry for mixing up threads. It´s because I´m so excited about the new feature!
Von: rheinskipper1000@gmx.de Gesendet: Mittwoch, 16. November 2016 18:45 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
My first test look really promising. All the draw order problems for fairway on river Rhine in the Mainz/Wiesbaden area are gone. It looks very beautiful now:
https://mega.nz/#!dFE1QIKK!BfIobp0WApKJtGdthwWvDt8IzNluZSwOaixW7PnmvJ k
However I still found one spot where the fairway is still not visible:
https://mega.nz/#!IM1FjK6R!Q0pDo43Qu8alan4Qrk4QCGsQtTyoQg7eWQx5cLs_EU 8
But this should not be a mkgmap issue because same problem also exists in openseamap online map. I will investigate further and keep you informed.
Thank you so much for this great improvement. It is a huge step for the openseamap project because it is pre-condition for rendering crowdsourced water depth as different shades of blue. There are 7 different predefined extended types for water depth which all have same built in draw order. Now chances are good that they can be controlled.
And sorry for mixing LEVEL and RESOLUTION. I used LEVEL but my style is based on default style which uses RESOLUTION.
Ups, thread was still wrong.
Von: Ticker Berkin Gesendet: Mittwoch, 16. November 2016 17:05 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Spurious points & Basecamp blank tiles
Hi
Not quite, you should have something like:
seamark:type=fairway {name 'fairway'; set mkgmap:drawLevel=60 } [0x10306 level 2] waterway=riverbank { set mkgmap:drawLevel=02 } [0x10302 resolution 18]
but you only need one of the mkgmap:drawLevel for the fairway to be written after/overwrite the riverbank. Which you use depends on what you want the behaviour to be with other polygons sharing the same area.
Also, slightly confusing to have level and resolution in the same style.
And the wrong thread.
Regards Ticker _______________________________________________ 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
Here it is: https://mega.nz/#!VVcjRIIY!r6OT24vLy1KCTaM6ZHJP2VTOdtyaOnF1GenO6xjygyY Unfortunately it is really big. I also tried it with small input but had no errors then. Von: Ticker Berkin Gesendet: Donnerstag, 17. November 2016 16:55 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area Can you drop some sample input that shows this behaviour along with your command-line/options and style somewhere, and I'll try and work out what is happening. Ticker On Thu, 2016-11-17 at 15:04 +0100, rheinskipper1000@gmx.de wrote:
After some more testing I can confirm that even three different draw levels also work as expected. This example shows fairway on top of intertidal zone which is on top of sea polygon: https://drive.google.com/file/d/0Bz9KchYfWW3reHRrSGR6c0Jmc0U/view?usp =sharing
But I got some errors regarding ShapeMergeFilter which I think were introduced with the new option: https://drive.google.com/file/d/0Bz9KchYfWW3rbUhkMVF2R3p4REU/view?usp =sharing
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment. However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap. Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery. I should be able to come up with the correct fix in a day or two. Ticker
Hi Gerd Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away. I've also moved the code that shares common coord. The patch is independent of the pending drawLevel patch Ticker On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, thanks for the patch. I was not yet able to reproduce the problem reported by rheinskipper1000. Do you have a test case for me? Gerd ________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 23. November 2016 13:39:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area Hi Gerd Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away. I've also moved the code that shares common coord. The patch is independent of the pending drawLevel patch Ticker On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd After thinking I'd found the problem and stopping it (horizontal & vertical flat areas), I thought I'd better test on rheinskipper1000's data, so I downloaded all of ... from list mail: Fri, 18 Nov 2016 14:58:01 +0100 Here it is: https://mega.nz/#!VVcjRIIY!r6OT24vLy1KCTaM6ZHJP2VTOdtyaOnF1GenO6xjygyY Unfortunately is really big. I also tried it with small input but had no errors then. ... (it is >2G) and discovered other orientations as well. Only 10 occurrences in 141 tiles. His tile 63210102.osm.pbf has 3 examples. from areas.list 63210102: 2449408,266240 to 2469888,284672 # : 52.558594,5.712891 to 52.998047,6.108398 I can extract and send you his command line, -c options and style if it would help. Not sure if his sea.zip is relevant. Regards Ticker On Thu, 2016-11-24 at 06:57 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the patch. I was not yet able to reproduce the problem reported by rheinskipper1000. Do you have a test case for me?
Gerd Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 23. November 2016 13:39:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
Hi Gerd
Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away.
I've also moved the code that shares common coord.
The patch is independent of the pending drawLevel patch
Ticker
On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ 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 Ticker, I thought you have a small test case. It would be great if you can reproduce it with only one tile and post a link to the needed package. Gerd Von: Ticker Berkin<mailto:rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 24. November 2016 12:25 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area Hi Gerd After thinking I'd found the problem and stopping it (horizontal & vertical flat areas), I thought I'd better test on rheinskipper1000's data, so I downloaded all of ... from list mail: Fri, 18 Nov 2016 14:58:01 +0100 Here it is: https://mega.nz/#!VVcjRIIY!r6OT24vLy1KCTaM6ZHJP2VTOdtyaOnF1GenO6xjygyY Unfortunately is really big. I also tried it with small input but had no errors then. ... (it is >2G) and discovered other orientations as well. Only 10 occurrences in 141 tiles. His tile 63210102.osm.pbf has 3 examples. from areas.list 63210102: 2449408,266240 to 2469888,284672 # : 52.558594,5.712891 to 52.998047,6.108398 I can extract and send you his command line, -c options and style if it would help. Not sure if his sea.zip is relevant. Regards Ticker On Thu, 2016-11-24 at 06:57 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the patch. I was not yet able to reproduce the problem reported by rheinskipper1000. Do you have a test case for me?
Gerd Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 23. November 2016 13:39:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
Hi Gerd
Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away.
I've also moved the code that shares common coord.
The patch is independent of the pending drawLevel patch
Ticker
On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ 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 http://files.mkgmap.org.uk/download/314/tstArea.zip This contains simple shell script, options file, style and single tile Ticker On Thu, 2016-11-24 at 11:45 +0000, Gerd Petermann wrote:
Hi Ticker,
I thought you have a small test case. It would be great if you can reproduce it with only one tile and post a link to the needed package.
Gerd
Von: Ticker Berkin Gesendet: Donnerstag, 24. November 2016 12:25 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
Hi Gerd
After thinking I'd found the problem and stopping it (horizontal & vertical flat areas), I thought I'd better test on rheinskipper1000's data, so I downloaded all of
... from list mail: Fri, 18 Nov 2016 14:58:01 +0100 Here it is: https://mega.nz/#!VVcjRIIY!r6OT24vLy1KCTaM6ZHJP2VTOdtyaOnF1GenO6xjygy Y
Unfortunately is really big. I also tried it with small input but had no errors then. ...
(it is >2G)
and discovered other orientations as well. Only 10 occurrences in 141 tiles. His tile 63210102.osm.pbf has 3 examples.
from areas.list 63210102: 2449408,266240 to 2469888,284672 # : 52.558594,5.712891 to 52.998047,6.108398
I can extract and send you his command line, -c options and style if it would help. Not sure if his sea.zip is relevant.
Regards Ticker
On Thu, 2016-11-24 at 06:57 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the patch. I was not yet able to reproduce the problem reported by rheinskipper1000. Do you have a test case for me?
Gerd Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 23. November 2016 13:39:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by -decreasing -area
Hi Gerd
Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away.
I've also moved the code that shares common coord.
The patch is independent of the pending drawLevel patch
Ticker
On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ 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 Ticker, thanks, I can reproduce it with this data. Will look at the pending patched tomorrow. Gerd Ticker Berkin wrote
Hi Gerd
http://files.mkgmap.org.uk/download/314/tstArea.zip
This contains simple shell script, options file, style and single tile
Ticker
On Thu, 2016-11-24 at 11:45 +0000, Gerd Petermann wrote:
Hi Ticker,
I thought you have a small test case. It would be great if you can reproduce it with only one tile and post a link to the needed package.
Gerd
Von: Ticker Berkin Gesendet: Donnerstag, 24. November 2016 12:25 An:
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing -area
Hi Gerd
After thinking I'd found the problem and stopping it (horizontal & vertical flat areas), I thought I'd better test on rheinskipper1000's data, so I downloaded all of
... from list mail: Fri, 18 Nov 2016 14:58:01 +0100 Here it is: https://mega.nz/#!VVcjRIIY!r6OT24vLy1KCTaM6ZHJP2VTOdtyaOnF1GenO6xjygy Y
Unfortunately is really big. I also tried it with small input but had no errors then. ...
(it is >2G)
and discovered other orientations as well. Only 10 occurrences in 141 tiles. His tile 63210102.osm.pbf has 3 examples.
from areas.list 63210102: 2449408,266240 to 2469888,284672 # : 52.558594,5.712891 to 52.998047,6.108398
I can extract and send you his command line, -c options and style if it would help. Not sure if his sea.zip is relevant.
Regards Ticker
On Thu, 2016-11-24 at 06:57 +0000, Gerd Petermann wrote:
Hi Ticker,
thanks for the patch. I was not yet able to reproduce the problem reported by rheinskipper1000. Do you have a test case for me?
Gerd Von: mkgmap-dev <
mkgmap-dev-bounces@.org
> im Auftrag
von Ticker Berkin <
rwb-mkgmap@.co
>
Gesendet: Mittwoch, 23. November 2016 13:39:16 An:
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] mkgmap:drawLevel and --order-by -decreasing -area
Hi Gerd
Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away.
I've also moved the code that shares common coord.
The patch is independent of the pending drawLevel patch
Ticker
On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Ticker, OK, I think you found a flaw in the Area code which I introduced with the highprec stuff. I think it would be better to change class Area to store high prec values, but for now your work around seems okay to me. Gerd Ticker Berkin wrote
Hi Gerd
Attached patch stops the errors from shapeMergeFilter. The java2D intersect.() / converter used for clipping sometimes generates flattened shapes which I now check for and chuck away.
I've also moved the code that shares common coord.
The patch is independent of the pending drawLevel patch
Ticker
On Sat, 2016-11-19 at 10:46 +0000, Ticker Berkin wrote:
Your right - it is big. My system didn't want to download it without installing some add-ons which I don't want to do at the moment.
However, I have reproduced the same diagnostic from one of my maps and am investigating that. It is more related to --order-by-.. than mkgmap:drawLevel and the boundaries of different precisions used by mkgmap.
Looking at the map output at a very high resolution in the problem area, I can't see any difference between when I get the error and when I've made it not happen by some trickery.
I should be able to come up with the correct fix in a day or two.
Ticker
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
emptyArea_v2.patch (6K) <http://gis.19327.n8.nabble.com/attachment/5886418/0/emptyArea_v2.patch>;
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd, Just noticed that you didn't include the change to resources/styles/default/inc/water_polygons that was in drawLevel_v2.patch -natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10] +natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x32 resolution 10] This change is harmless when --no-order-by..., reflects the default behaviour of the code when --order-by... but users might want to change it to a high value to show sea up to the coastline. Ticker
Hi Ticker, this was not intended, I mixed my own tests with your patch. Did you try to use mkgmap:drawLevel for other polygons, e.g. buildings? Gerd Ticker Berkin wrote
Hi Gerd,
Just noticed that you didn't include the change to resources/styles/default/inc/water_polygons that was in drawLevel_v2.patch
-natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10] +natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x32 resolution 10]
This change is harmless when --no-order-by..., reflects the default behaviour of the code when --order-by... but users might want to change it to a high value to show sea up to the coastline.
Ticker
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd No - this was the only occurrence. Ticker On Mon, 2016-11-28 at 02:38 -0700, Gerd Petermann wrote:
Hi Ticker,
this was not intended, I mixed my own tests with your patch. Did you try to use mkgmap:drawLevel for other polygons, e.g. buildings?
Gerd
Ticker Berkin wrote
Hi Gerd,
Just noticed that you didn't include the change to resources/styles/default/inc/water_polygons that was in drawLevel_v2.patch
-natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10] +natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x32 resolution 10]
This change is harmless when --no-order-by..., reflects the default behaviour of the code when --order-by... but users might want to change it to a high value to show sea up to the coastline.
Ticker
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious -points-Basecamp-blank-tiles-tp5885434p5886587.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Gerd Petermann wrote
this was not intended, I mixed my own tests with your patch.
That was probably too short. I committed your change together with my own test changes in r3704 and reverted both with r3705. Do you think that the change in inc/is mandantory when --order-by-decreasing-area is used ? Gerd -- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd No, it shouldn't make any difference. It was more like documentation and a pointer to where the tag was used and could be changed. But I wasn't sure about all the ways sea polygons could come into being and so having this ensured the same area was always set. It also matches a comment in SeaGenerator.java Ticker On Mon, 2016-11-28 at 02:57 -0700, Gerd Petermann wrote:
Gerd Petermann wrote
this was not intended, I mixed my own tests with your patch.
That was probably too short. I committed your change together with my own test changes in r3704 and reverted both with r3705. Do you think that the change in inc/is mandantory when --order-by-decreasing-area is used ?
Gerd
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious -points-Basecamp-blank-tiles-tp5885434p5886589.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, unfortunately I didn't have time or ability to test the patch. Seems like problems are solved when I changed POI types (https://github.com/pailakka/mtk2garmin/commit/4b3969d726e7b3e36eaa4f0fb8323a...). Looks like 0x10f__ types are not working on polygons despite both IMG and TYP being seemingly fine with them. -Teemu 16.11.2016, 17:38, Gerd Petermann kirjoitti:
Hi all,
I did not get any feedback on this patch. I am not sure if it fixes the problem or if it's just a work around. Does anybody expect a problem with it?
Gerd
Gerd Petermann wrote
Hi Teemu,
Maybe I have a fix for this. We have special code in mkgmap for POI with type >= 0x0100 && type <= 0x1100, they are considered to be cities and those are special. With the attached patch only those with subtype = 0 are: type >= 0x0100 && type <= 0x1100 && (type & 0xff) == 0
This seems to fix the problem, but maybe it is only a workaround. Another observation: The MP file gives a label for each of these 0x1001 POI, the pbf file doesn't.
A binary based on r3701 is here: http://files.mkgmap.org.uk/download/312/mkgmap.jar type_0x1001.patch <http://gis.19327.n8.nabble.com/file/n5885745/type_0x1001.patch>
Gerd Teemu Peltonen wrote
Hi,
http://kartat.hylly.org/mkgmap/M431_cgpsmapper.img is created with cGPSmapper and contains point type 0x1001 (among other rather exotic types) without problems. Polish map file used to generate this file can be found from http://kartat.hylly.org/mkgmap/M431.7z.
It also looks like that these artifacts does not exists when the img is created from a pbf file containing no actual OSM data. Map generated from http://kartat.hylly.org/mkgmap/M431.osm.pbf with the same style definitions works perfectly fine. 0x1001 points are, however missing so they might definitely be part of the problem. The only difference between M431_osm.osm.pbf (from the original post )and M431.osm.pbf is that OSM data is merged to M431_osm.osm.pbf with osmconvert.
-Teemu
9.11.2016, 13:40, Gerd Petermann kirjoitti:
Hi Teemu,
please provide a link to a small map with an 0x1001 type created with cGPSmapper. Maybe we can learn from that.
Gerd
Teemu Peltonen wrote
Hi,
those same types worked with cGPSmapper without a problem. Thank you for this insight, I'll try to change types and see what happens.
-Teemu
On Wed, Nov 9, 2016 at 12:31 PM, Andrzej Popowski < popej@.onet > wrote:
Hi,
I have once created a test map for all possible objects, using cGPSmapper. I have found, that some objects are problematic. I don't remember details, but I think sometimes map doesn't work at all.
My current set of good points exclude 0x1001. Actually I think that for types 0x01xx to 0x11xx only subtype 0 is accepted. And some POI types doesn't work at all, for example 12xx, 13xx, 31xx-3fxx.
I don't know if this is a problem of Garmin devices or cGPSmapper.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- View this message in context: http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp588543... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Teemu,
Looks like 0x10f__ types are not working on polygons despite both IMG and TYP being seemingly fine with them.
Types 0x10f__ are called "customizable area", they should work correctly but are invisible without graphics in TYP file. And don't forget about draw order for each area. -- Best regards, Andrzej
participants (8)
-
Andrzej Popowski -
Gerd Petermann -
Gerd Petermann
-
nwillink -
rheinskipper1000＠gmx.de -
Teemu P -
Teemu Peltonen
-
Ticker Berkin