Re: [mkgmap-dev] Spurious points & Basecamp blank tiles

[Andrzej Popowski]

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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Spurious points & Basecamp blank tiles

[Teemu Peltonen]

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/4b3969d726e7b3e36eaa4f0fb8323a744a6c33cf). 



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


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

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


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




--
View this message in context:
http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885635.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list


mkgmap-dev@.org

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


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





--
View this message in context: 
http://gis.19327.n8.nabble.com/Spurious-points-Basecamp-blank-tiles-tp5885434p5885999.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



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

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

[Ticker Berkin]

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, rheinskipper1...@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: rheinskipper1...@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: rheinskipper1...@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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

[rheinskipper1000]

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: rheinskipper1...@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: rheinskipper1...@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




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

Re: [mkgmap-dev] splitter r440 released

[Henning Scholland]

Should have read your mail better :(

I think the test should be implemented in mkgmap while reading the input
data tiles.

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

Re: [mkgmap-dev] splitter r440 released

[Henning Scholland]

As you know, I'm using overlapping tiles, but in different gmapsupps.
Never had any problems. Is splitter still able to split overlapping tiles?

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

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

[Gerd Petermann]

Hi Ticker,

Ticker Berkin wrote
> The messing with the area happens after style processing so doesn't
> effect the result of the area_size() function.

you are right, sorry for the noise.

Gerd



--
View this message in context: 
http://gis.19327.n8.nabble.com/mkgmap-drawLevel-and-order-by-decreasing-area-tp5885926p5886052.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap:drawLevel and --order-by-decreasing-area

[Ticker Berkin]

Hi Gerd

The messing with the area happens after style processing so doesn't
effect the result of the area_size() function.

Ticker

On Wed, 2016-11-16 at 23:00 -0700, Gerd Petermann wrote:
> Hi all,
> 
> Ticker Berkin wrote
> > It is used in conjunction with --order-by-decreasing-area and
> > overrides
> > the natural polygon area that is used for output sorting, hence
> > influencing which polygons are rendered over others.
> 
> in fact it also overrides the value returned by the style function
> area_size(), I  don't know if that is a good idea. 
> @Ticker: I assume you used this trick to avoid a new field like
> skipSizeFilter in MapLine?
> 
> Gerd
> 
> 
> 
> --
> View this message in context: http://gis.19327.n8.nabble.com/mkgmap-d
> rawLevel-and-order-by-decreasing-area-tp5885926p5886043.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev