subject:"\[mkgmap\-dev\] New branch for default typ file"

Re: [mkgmap-dev] New branch for default typ file

2019-12-21 Thread Joris Bo

Hi,

Sorry for my late reaction , I was out of the office
I use self made tools to generate the mapnik.txt, but for common use, the 
maintenance of a simple txt is easier for the community.
If necessary it is always possible to import the txt in a typ-editor change it 
manually and export it again.
Maintaining (new) languages is much more work, but so be it.

So as the source I suggest mapnik.txt from the mkgmap repository
The comment section can be removed

Kind regards Joris


-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Ticker Berkin
Verzonden: zaterdag 14 december 2019 10:42
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating mapnik.txt 
to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to the 
default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple .txt 
file with patches being supplied in the same way as other source files, or will 
it be regenerated from your translation spreadsheet and other sources? I'd 
prefer the simple text file approach, but this might allow changes into the 
file which make it incompatible with the tools Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of the 
file. I don't know how the java input libraries determine the conversion rules 
to internal unicode, but this file should be consistent with all the others 
that contain characters outside the simple ansi 7-bit range 
(roadNameConfig.txt, default/inc/address)

It contains the statement:
> CodePage=65001
This is saying the output should be unicode, but the output should be the same 
as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
> Hi Joris,
> 
> the file mapnik.txt says "Based on mkgmap default style version:
> r4262"
> Is it the right file?
> 
> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
> mkgmap:dest_hint=*)
> I want to look at the DestinationHook. If I got that right it should 
> be OK to have a zero-length road with that type to get the wanted 
> destination hint. In that case we don't have to care about rendering.
> 
> Gerd
> 
> 
> Von: Joris Bo 
> Gesendet: Montag, 9. Dezember 2019 20:45
> An: Development list for mkgmap; Gerd Petermann
> Betreff: RE: [mkgmap-dev] New branch for default typ file
> 
> Hi All,
> 
> I don't think any changes needed in mkgmap itself. When the draworder 
> of bay is lower then water it will display correctly.
> See attached new typ-file for correct usage.
> Even better (but this is a change in default style): don't use natural 
> = bay in polygons but only in points for displaying as name.
> 
> Today I spent some time testing and repairing.
> 
> The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and 
> also did not have the translations of all the languages anymore. It 
> also lost draworder of a lot of polygons which made the bay-problem 
> occur.
> 
> I did a complete recheck of the most recent default-style in: mkgmap 
> -r4386.zip and changed de typ-file accordingly.
> 
> I downloaded a full europe-latest from geofabrik today, builded it as 
> a big full europa map with the default style of r4386  and with mkgmap 
> r4386.jar No errors occured.
> 
> I think it’s up to date again but some review and comments are always 
> welcome.
> 
> See typ-file in attachement,
> 
> Kind regards,
> Joris
> 
> 
> 
> 
> 
> -----Oorspronkelijk bericht-----
> Van: mkgmap-dev  Namens Pinns 
> UK
> Verzonden: maandag 9 december 2019 18:31
> Aan: Gerd Petermann ;
> mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> Yes, you can do that with a draw level 1 higher than sea.
> 
> Draw orders are defined at the beginning of a (txt) typ file just 
> before the polygons
> 
> using the following format
> 
> Type=0x type number , draworder
> 
> It is good practice to sort the draworders , as that is how they 
> appear in a typ file
> 
> [_drawOrder]
> Type=0x03,1
> Type=0x28,1
> Type=0x54,1
> Type=0x01,2
> Type=0x09,2
>   Type=0x4E,2
>   Type=0x10F1C,2
> etc etc
> [end]
> I have no idea what the draworder for sea is , but just make it one 
> higher
> 
> On 09/12/2019 16:41, Gerd Petermann wrote:
> > Hi Nick,
> > 
> > I don't want to cut out islands from bay polygons, I thought about a 
> > proper typ for 0x3d which somehow marks "calmer wate

Re: [mkgmap-dev] New branch for default typ file

2019-12-18 Thread Ticker Berkin

Hi Randolph

This topic should probably become a new thread.

You shouldn't confuse the encoding of the java source text (rules
determined by the java language) with how a java program reads a text
file into its internal character format (however the programmers want
to do it, but the java library supplies converters for almost all
character sets/encodings).

I agree that the text file input processing of mkgmap should allow for
a BOM in all cases and use it to determine the correct unicode input
decoding. There are various possible input files with a mix of
character set/encoding determination and BOM acceptance.

A quick look for the the various txt inputs, I find:

style components: In the default style, all are pure 7-bit ascii.  
except inc/address which contains some UTF-8 encoded characters.

road-name-config: this is read as UTF-8.

TYP: This checks for a UFT-8 BOM as the first character on a line, and,
if not there, looks for a line starting with 'CodePage=' and uses what
follows, with cp65001 taken to mean UTF-8. It has some logic to default
to cp1252 and some other convolutions.
There are many incorrect assumptions in this handling, the main one
being that CodePage is there to determine the output charset, which can
be determined from the main mkgmap map options anyway.

-c options.cfg: I haven't studied the logic for this, but it probably
uses the character set/encoding determined by Java from the
environment; on unix maybe $LANG with typical value "en_GB.UTF-8"

command line parameters: ditto

copyright/licence-file: not looked

delete-tags-file: not looked

other files: ?

Most of these areas could benefit from a unified way of determining the
input character set and encoding, but we need to beware of backward
compatibility, where users have their own components in a code-page
relevant to their area.

I suggest something like the following, in order:

1/ Look for a BOM for any of the unicode encodings near the start of
the file; not necessarily the first character, because, without
changing the next level of the file parser, it might need to be in a
comment.

2/ Look for the 1st or 2nd line of the format:
{comment-indicator} -*- coding: {charset} -*-
where {comment-indicator} is typically a '#'. and {charset}, for
unicode, represents the encoding as well. This method is used by Python
and was common on unix systems and recognised by many text editors
before UTF-8 became ubiquitous.

3/ Default to UTF-8 or the environmental default depending on context,
to be compatible with current handling.

Ticker

On Tue, 2019-12-17 at 15:20 -0600, Randolph J. Herber wrote:
> Dear Sirs:
> There has been a thread of discussion of whether there should be a
> Beginning Of Message (BOM) at the beginning of a UTF-8 file.
> This discussion is complicated by the fact that some of the
> developers work on Unix, Linux, BSD, iOS, Solaris and Windows. These
> operating systems have UTF-8 handling libraries written at different
> times and to different Unicode standards. Originally the Unicode
> standard said that UTF-8 should not have a BOM character at the
> beginning of a file. Later Unicode changed the standard to a BOM is
> permissible, not required and not recommended. Microsoft added a BOM
> to the beginning of UTF-8 files before doing so was permissible to
> ease the problem of recognizing a UTF-8 file. This broke the other
> operating systems' handling of UTF-8. Microsoft petitioned for the
> permissibility of a BOM to avoid changing their file handling.
> At this time, I believe at all programs should use Unicode and not
> Microsoft code pages. I have had problems with Microsoft code pages
> since MSDOS days.
> Splitter and mkgmap are written in Java. Java still follows the
> original Unicode standard of no BOM at the beginning of a UTF-8 text
> file. This is a "not to fixed" situation per the Java language
> developers. This situation results in problems with Java,
> particularly in a Microsoft Windows environment,
> The code fragments below provide Java solutions to writing a BOM at
> the beginning of a UTF-8 text files so that Microsoft native text
> editors can handle them and, on reading a text file, provides   a
> automatic way of ignoring an optional BOM by checking for the BOM
> after file opening.
> A test for execution in a Windows environment is provided below if
> one decides to add a BOM only on Microsoft Windows.
> I have not downloaded the splitter and mkgmap sources and searched
> for the appropriate places in their sources to apply the changes. I
> feel the main splitter and mkgmap developers are placed better to
> make these changes. This is the reason that I did not provide patches
> to the sources.
> Randolph J. Herber.

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

Re: [mkgmap-dev] New branch for default typ file

2019-12-17 Thread Randolph J. Herber

haracter that selects the byte 
order of the text.


Byte order mark Description
EF BB BFUTF-8
FF FE   UTF-16, little endian
FE FF   UTF-16, big endian
FF FE 00 00 UTF-32, little endian
00 00 FE FF UTF-32, big-endian




On 12/14/2019 3:41 AM, Ticker Berkin wrote:

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:

CodePage=65001

This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?

reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
mkgmap:dest_hint=*)
I want to look at the DestinationHook. If I got that right it should
be OK to have a zero-length road with that type to get the wanted
destination hint. In that case we don't have to care about rendering.

Gerd


Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file

Hi All,

I don't think any changes needed in mkgmap itself. When the draworder
of bay is lower then water it will display correctly.
See attached new typ-file for correct usage.
Even better (but this is a change in default style): don't use
natural = bay in polygons but only in points for displaying as name.

Today I spent some time testing and repairing.

The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
also did not have the translations of all the languages anymore. It
also lost draworder of a lot of polygons which made the bay-problem
occur.

I did a complete recheck of the most recent default-style in: mkgmap
-r4386.zip and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as
a big full europa map with the default style of r4386  and with
mkgmap r4386.jar No errors occured.

I think it’s up to date again but some review and comments are always
welcome.

See typ-file in attachement,

Kind regards,
Joris





-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Pinns
UK
Verzonden: maandag 9 december 2019 18:31
Aan: Gerd Petermann;
mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, you can do that with a draw level 1 higher than sea.

Draw orders are defined at the beginning of a (txt) typ file just
before the polygons

using the following format

Type=0x type number , draworder

It is good practice to sort the draworders , as that is how they
appear in a typ file

[_drawOrder]
Type=0x03,1
Type=0x28,1
Type=0x54,1
Type=0x01,2
Type=0x09,2
   Type=0x4E,2
   Type=0x10F1C,2
etc etc
[end]
I have no idea what the draworder for sea is , but just make it one
higher

On 09/12/2019 16:41, Gerd Petermann wrote:

Hi Nick,

I don't want to cut out islands from bay polygons, I thought about
a proper typ for 0x3d which somehow marks "calmer water"
and a draw order that puts this above water and below any land type
polygon.
Is that possible?

Gerd


Von: Pinns UK
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann;mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:

Hi Nick,

my understanding is that you always have another water polygon,
either ocean or natural=water.

Gerd


Von: Pinns UK
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann;mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ;

Re: [mkgmap-dev] New branch for default typ file

2019-12-16 Thread Ticker Berkin

Hi all

As suggested elsewhere, bays should be rendered as transparent and only
 generated if named. I use this method for other areas and find it very
useful.

I don't understand what is being suggested by the references to POI in
this context; They are findable as Geographic > Water Features > Bay,
but to get the name of bay by trying to move the cursor over a POI
which might not exist and selecting it doesn't make sense.

Some comments (marked #RWB) on "20191209 mapnik update.pdf", attachment
to Joris posting 9-Dec 19:45 to reproduced in-line here

Changed Lines

Added 0x17
Breakwater
But later on also used for walls, bariers, fences and hedges: so not
easy to translate
I added it as a thin dark grey line, assuming fences, walls and hedges
are more common then
breakwaters and if used create a lot of cluttering if the line is to
thick.
#RWB I use the thinnest black line for all of these (also for cliff)
and give them the smallest label

Added 0x0b
highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*)
Set the same as 0x09 Trunk link. Is used for both motorway and Trunk
links. Would make sense to me
to use 0x09 for motorway and 0x09 for trunk instead, but should then be
changed in the default style.
#RWB Gerd had commented on these. They are very short and difficult to
spot unless you zoom right in. Not worth using 2 different routeable
lineTypes. Should be rendered the same as the less major road that it
replaces (ie primary_link, 0x08)
 
.
Added 0x1a
route=ferry [0x1a road_class=3 road_speed=0 resolution 19] same as 0x1b
#RWB would be nice if car-ferry (0x1a) is shown as more significant
than foot/bicycle only ferry (0x1b)

Changed Polygons

Added 0x1d
Leisure = common, depricated by osm wiki, used same color as park,
better to be removed from default style i
think.
#RWB wouldn't want to remove until all OSM usage has gone

Added 0x20
leisure=garden [0x20 resolution 21]

Added 0x25
place=square [0x25 resolution 22]

Added 0x12
highway=services [0x12 resolution 22]
landuse=retail [0x12 resolution 20-23]

Changed 0x1e (historic) to be 0x22
0x1e was historic is changed to 0x22

Added 0x52
natural=tundra [0x52 resolution 18]

Added 0x0f
landuse=commercial [0x0f resolution 19]
Same color as 0x08 commercical / shops

Added 0x26
landuse=farm [0x26 resolution 22]
landuse=farmyard [0x26 resolution 22]

Added 0x1c
landuse=greenfield [0x1c resolution 20]
landuse=meadow | landuse=grass [0x1c resolution 19]
landuse=farmland [0x1c resolution 20]

Wiki says: greenfield is to be developed in something new and so is
really different from being a
‘green meadow area’. Choosed color for green grass because meadow is
much more common
#RWB I hadn't spotted this distinction, but I don't think it is worth
trying to represent differently

Added 0x15
landuse=village_green [0x15 resolution 20]

Added 0x11
military=danger_area [0x11 resolution 20]
#RWB I show this as semi-transparent (red stripes) OVER whatever else
is on the map (eg any other landuse). I do the same with nature
-reserve/0x16 as green stripes

Added 0x23
amenity=* & area!=no & amenity!=grave_yard {add
name='${amenity|subst:"_=> "}'} [0x23 resolution 24]
This can be anything, lets say it most commonly is a building
#RWB It might be a building, but often it is an area that might contain
contains buildings etc, so I'd prefer it to be different so that
contained building show up 

Added 0x21
tourism=* & area!=no & waterway!=* {add name='${tourism|subst:"_=> "}'}
[0x21 resolution 24]
This can be anything, lets say it most commonly is something referred
to as green stuf

Added 0x24
man_made=* & area!=no {add name='${man_made|subst:"_=> "}'} [0x24
resolution 24]
This can be anything, lets say it most commonly is something referred
to as constructions such as bridges

Changed points

Moved bollard from 0x660f to 0x3200

Some suggestions for improvements of the default style

For examples also see my osm mapnik style at
https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin

leisure=water_park [0x09 resolution 21]
Is now rendered with the same code for (blue) water area’s but in my
opinion should be rendered as green
‘park or campsite‘ area and only the swimmingpool itself is blue water.
#RWB the garmin definition of 0x09 is "Marina", which isn't handled by
the default style. I suggest adding this and changing water_park to 
use 0x2a (default name/rendering Area/Body of Water/Green)

leisure=recreation_ground [0x19 resolution 21]
Is now rendered same as green sportsfacilities but maybe better the
same as park or campsite
#RWB 0x19 (garmin "Sports Complex") is a bit overloaded as ice_rink,
pitch, recreation_ground, sports_center, stadium and track. Maybe
recreation_ground could be changed to 0x1e

Islands and beaches both uses 0x53
#RWB Islands/Islets should change to 0x56/0x57 and only generated if
named and small. Then rendered as transparent

Industrial, quarry and construction share the same code 0x0c
  Line 100: landuse=construction [0x0c resolution 21]

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Gerd Petermann

Hi Randolph,
is there anything wrong regarding unicode support in mkgmap? If yes, please 
post a patch or - at least - describe more details.

Gerd


Von: mkgmap-dev  im Auftrag von 
Randolph J. Herber 
Gesendet: Samstag, 14. Dezember 2019 18:20
An: Development list for mkgmap; Pinns UK
Betreff: Re: [mkgmap-dev] New branch for default typ file

Dear Sirs:

Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8)
as that works in iOS and Unix.

Randolph J. Herber

On 12/14/2019 9:53 AM, Pinns UK wrote:
> Hi Gerd
>
> The reason for suggesting unicode is that it caters for all languages,
> not just  those specified by 1252 or 1250 or 1251
>
> However,   anyone not used to or bothered about codepages, will
> benefit from a mapnik.txt where the characters are 1252 compliant.
>
>  I now have all my maps using cp 65001 as  Basecamp/ (mapsource?)
> automatically selects the appropriate  language depending on the
> user's Region settings.
>
> Nick
>
>
>
>
> On 14/12/2019 15:11, Gerd Petermann wrote:
>> Hi all,
>>
>> when the source for the typ file specifies a codePage which is
>> different from the one used on the command line we see a warning
>> WARNING: SortCode in TYP txt file different from command line setting
>>
>> As an unexperienced user I would try to get rid of such a warning,
>> maybe causing more trouble than needed.
>> A comment in the source says "This is just a warning, not a definite
>> problem"
>>
>> In (1) Nick suggested to use unicode in the typ file, so I wonder in
>> what situation this warning is needed?
>>
>> Gerd
>> (1)
>> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html
>>
>> ________
>> Von: mkgmap-dev  im Auftrag
>> von Gerd Petermann 
>> Gesendet: Samstag, 14. Dezember 2019 15:21
>> An: Ticker Berkin; Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>
>> Hi Ticker & Joris
>>
>> I'd also prefer to maintain it as txt file, else I'd prefer to remove
>> the file and add a simple hint were to find Joris files.
>>
>> @Ticker:
>> The problem mentioned here is still there.
>> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
>>
>> I'll try to code a fix now.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag
>> von Ticker Berkin 
>> Gesendet: Samstag, 14. Dezember 2019 10:41
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>
>> Hi Joris & Gerd
>>
>> Great to see the typ-files now in trunk and all the work in updating
>> mapnik.txt to the current default style. Next week I plan to go through
>> "20191209 mapnik update.pdf" and comment on it and possible changes to
>> the default style.
>>
>> Some other questions however:
>>
>> How do you see mapnik.txt now being maintained; will it be as as simple
>> .txt file with patches being supplied in the same way as other source
>> files, or will it be regenerated from your translation spreadsheet and
>> other sources? I'd prefer the simple text file approach, but this might
>> allow changes into the file which make it incompatible with the tools
>> Joris uses to enhance it.
>>
>> It is currently in UTF8 format, with an appropriate BOM at the start of
>> the file. I don't know how the java input libraries determine the
>> conversion rules to internal unicode, but this file should be
>> consistent with all the others that contain characters outside the
>> simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
>>
>> It contains the statement:
>>> CodePage=65001
>> This is saying the output should be unicode, but the output should be
>> the same as the associated map.
>>
>> Also the FID should be removed.
>>
>> Regards
>> Ticker
>>
>> On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
>>> Hi Joris,
>>>
>>> the file mapnik.txt says "Based on mkgmap default style version:
>>> r4262"
>>> Is it the right file?
>>>
>>> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
>>> mkgmap:dest_hint=*)
>>> I want to look at the DestinationHook. If I got that right it should
>>> be OK to have a zero-length road with that type to get the wanted
>>> destination

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Randolph J. Herber

Dear Sirs:

Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8)
as that works in iOS and Unix.

Randolph J. Herber

On 12/14/2019 9:53 AM, Pinns UK wrote:

Hi Gerd

The reason for suggesting unicode is that it caters for all languages,
not just those specified by 1252 or 1250 or 1251

However, anyone not used to or bothered about codepages, will
benefit from a mapnik.txt where the characters are 1252 compliant.

I now have all my maps using cp 65001 as Basecamp/ (mapsource?)
automatically selects the appropriate language depending on the
user's Region settings.

Nick

On 14/12/2019 15:11, Gerd Petermann wrote:

Hi all,

when the source for the typ file specifies a codePage which is
different from the one used on the command line we see a warning

WARNING: SortCode in TYP txt file different from command line setting

As an unexperienced user I would try to get rid of such a warning,
maybe causing more trouble than needed.
A comment in the source says "This is just a warning, not a definite
problem"

In (1) Nick suggested to use unicode in the typ file, so I wonder in
what situation this warning is needed?

Gerd
(1)
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html

Von: mkgmap-dev im Auftrag
von Gerd Petermann

Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Ticker & Joris

I'd also prefer to maintain it as txt file, else I'd prefer to remove
the file and add a simple hint were to find Joris files.

@Ticker:
The problem mentioned here is still there.
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html

I'll try to code a fix now.

Gerd

Von: mkgmap-dev im Auftrag
von Ticker Berkin

Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:

CodePage=65001

This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?

reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
mkgmap:dest_hint=*)
I want to look at the DestinationHook. If I got that right it should
be OK to have a zero-length road with that type to get the wanted
destination hint. In that case we don't have to care about rendering.

Gerd

Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file

Hi All,

I don't think any changes needed in mkgmap itself. When the draworder
of bay is lower then water it will display correctly.
See attached new typ-file for correct usage.
Even better (but this is a change in default style): don't use
natural = bay in polygons but only in points for displaying as name.

Today I spent some time testing and repairing.

The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
also did not have the translations of all the languages anymore. It
also lost draworder of a lot of polygons which made the bay-problem
occur.

I did a complete recheck of the most recent default-style in: mkgmap
-r4386.zip and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as
a big full europa map with the default style of r4386 and with
mkgmap r4386.jar No errors occured.

I think it’s up to date again but some review and comments are always
welcome.

See typ-file in attachement,

Kind regards,
Joris

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Pinns UK

Hi Gerd

The reason for suggesting unicode is that it caters for all languages,
not just those specified by 1252 or 1250 or 1251

However, anyone not used to or bothered about codepages, will benefit
from a mapnik.txt where the characters are 1252 compliant.

I now have all my maps using cp 65001 as Basecamp/ (mapsource?)
automatically selects the appropriate language depending on the user's
Region settings.

Nick

On 14/12/2019 15:11, Gerd Petermann wrote:

Hi all,

when the source for the typ file specifies a codePage which is different from
the one used on the command line we see a warning
WARNING: SortCode in TYP txt file different from command line setting

As an unexperienced user I would try to get rid of such a warning, maybe
causing more trouble than needed.
A comment in the source says "This is just a warning, not a definite problem"

In (1) Nick suggested to use unicode in the typ file, so I wonder in what
situation this warning is needed?

Gerd
(1)
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html

Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Ticker & Joris

I'd also prefer to maintain it as txt file, else I'd prefer to remove the file
and add a simple hint were to find Joris files.

@Ticker:
The problem mentioned here is still there.
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
I'll try to code a fix now.

Gerd

Von: mkgmap-dev im Auftrag von Ticker Berkin

Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Some other questions however:

It contains the statement:

CodePage=65001

This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?

Gerd

Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file

Hi All,

Today I spent some time testing and repairing.

I did a complete recheck of the most recent default-style in: mkgmap
-r4386.zip and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as
a big full europa map with the default style of r4386 and with
mkgmap r4386.jar No errors occured.

I think it’s up to date again but some review and comments are always
welcome.

See typ-file in attachement,

Kind regards,
Joris

-Oorspronkelijk bericht-
Van: mkgmap-dev Namens Pinns
UK
Verzonden: maandag 9 december 2019 18:31
Aan: Gerd Petermann ;
mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Randolph J. Herber

Dear Sirs:

Re UTF-8

Microsoft does this to handle another problem: Microsoft uses many
different character set encodings (i.e., code pages, e.g., CP1252) and
the BOM is used by Microsoft to indicate that the "code page" is UTF-8.
Java was implemented to an older version of the Unicode standard that
prohibited an UTF-8 BOM. The problem is comes from moving back and forth
across that cultural divide. Yes, this is painful.

A solution to the reading issue from the Java side:

https://stackoverflow.com/questions/1835430/byte-order-mark-screws-up-file-reading-in-java

A solution for writing a UTF-8 BOM in Java:

|BufferedWriter out = new BufferedWriter(new OutputStreamWriter(new
FileOutputStream(the File), StandardCharsets.UTF_8))out.write('\ufeff');|

A check for execution in a Windows environment:

String OS = System.getProperty("os.name").toLowerCase();
Boolean isWindows = OS.indexOf("win") >= 0;

Perhaps, on output write the BOM in a Windows environment and use the
BOM optional on input.

http://www.unicode.org/faq/utf_bom.html

Q: What are some of the differences between the UTFs?

A: The following table summarizes some of the properties of each of the
UTFs.

NameUTF-8 UTF-16 UTF-16BEUTF-16LEUTF-32 UTF-32BE
UTF-32LE
Smallest code point
Largest code point 10 10 10 10 10 10 10
Code unit size 8 bits 16 bits 16 bits 16 bits 32 bits 32 bits 32
bits
Byte order N/A big-endian little-endian big-endian
little-endian

Fewest bytes per character 1 2 2 2 4 4
4
Most bytes per character4 4 4 4 4 4
4

In the table indicates that the byte order is determined by a byte
order mark, if present at the beginning of the data stream, otherwise it
is big-endian.

http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf

Table 2-4. The Seven Unicode Encoding Schemes

Encoding Scheme Endian Order BOM Allowed?

UTF-8 N/A yes

The remainder of the table omitted.

https://docs.microsoft.com/en-us/windows/win32/intl/using-byte-order-marks

Using Byte Order Marks

* 05/30/2018
* 2 minutes to read
*
o
o

<https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Intl/using-byte-order-marks.md>

Always prefix a Unicode plain text file with a byte order mark, which
informs an application receiving the file that the file is byte-ordered.
Available byte order marks are listed in the following table. Because
Unicode plain text is a sequence of 16-bit code values, it is sensitive
to the byte ordering used when the text is written.

Note

A byte order mark is not a control character that selects the byte order
of the text.

Byte order mark Description
EF BB BFUTF-8
FF FE UTF-16, little endian
FE FF UTF-16, big endian
FF FE 00 00 UTF-32, little endian
00 00 FE FF UTF-32, big-endian

On 12/14/2019 3:41 AM, Ticker Berkin wrote:

Hi Joris & Gerd

Some other questions however:

It contains the statement:

CodePage=65001

This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version:
r4262"
Is it the right file?

Gerd

Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgm

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Gerd Petermann

Hi all,

when the source for the typ file specifies a codePage which is different from 
the one used on the command line we see a warning
WARNING: SortCode in TYP txt file different from command line setting

As an unexperienced user I would try to get rid of such a warning, maybe 
causing more trouble than needed.
A comment in the source says "This is just a warning, not a definite problem"

In (1) Nick suggested to use unicode in the typ file, so I wonder in what 
situation this warning is needed?

Gerd
(1) 
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html

Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Ticker & Joris

I'd also prefer to maintain it as txt file, else I'd prefer to remove the file 
and add a simple hint were to find Joris files.

@Ticker:
The problem mentioned here is still there.
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
I'll try to code a fix now.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:
> CodePage=65001
This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
> Hi Joris,
>
> the file mapnik.txt says "Based on mkgmap default style version:
> r4262"
> Is it the right file?
>
> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
> mkgmap:dest_hint=*)
> I want to look at the DestinationHook. If I got that right it should
> be OK to have a zero-length road with that type to get the wanted
> destination hint. In that case we don't have to care about rendering.
>
> Gerd
>
> 
> Von: Joris Bo 
> Gesendet: Montag, 9. Dezember 2019 20:45
> An: Development list for mkgmap; Gerd Petermann
> Betreff: RE: [mkgmap-dev] New branch for default typ file
>
> Hi All,
>
> I don't think any changes needed in mkgmap itself. When the draworder
> of bay is lower then water it will display correctly.
> See attached new typ-file for correct usage.
> Even better (but this is a change in default style): don't use
> natural = bay in polygons but only in points for displaying as name.
>
> Today I spent some time testing and repairing.
>
> The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
> also did not have the translations of all the languages anymore. It
> also lost draworder of a lot of polygons which made the bay-problem
> occur.
>
> I did a complete recheck of the most recent default-style in: mkgmap
> -r4386.zip and changed de typ-file accordingly.
>
> I downloaded a full europe-latest from geofabrik today, builded it as
> a big full europa map with the default style of r4386  and with
> mkgmap r4386.jar No errors occured.
>
> I think it’s up to date again but some review and comments are always
> welcome.
>
> See typ-file in attachement,
>
> Kind regards,
> Joris
>
>
>
>
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens Pinns
> UK
> Verzonden: maandag 9 december 2019 18:31
> Aan: Gerd Petermann ;
> mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Yes, you can do that with a draw level 1 higher than sea.
>
> Draw orders are defined at the beginning of a (txt) typ fil

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Gerd Petermann

Hi Ticker & Joris

I'd also prefer to maintain it as txt file, else I'd prefer to remove the file 
and add a simple hint were to find Joris files.

@Ticker:
The problem mentioned here is still there.
http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
I'll try to code a fix now.

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:
> CodePage=65001
This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
> Hi Joris,
>
> the file mapnik.txt says "Based on mkgmap default style version:
> r4262"
> Is it the right file?
>
> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
> mkgmap:dest_hint=*)
> I want to look at the DestinationHook. If I got that right it should
> be OK to have a zero-length road with that type to get the wanted
> destination hint. In that case we don't have to care about rendering.
>
> Gerd
>
> 
> Von: Joris Bo 
> Gesendet: Montag, 9. Dezember 2019 20:45
> An: Development list for mkgmap; Gerd Petermann
> Betreff: RE: [mkgmap-dev] New branch for default typ file
>
> Hi All,
>
> I don't think any changes needed in mkgmap itself. When the draworder
> of bay is lower then water it will display correctly.
> See attached new typ-file for correct usage.
> Even better (but this is a change in default style): don't use
> natural = bay in polygons but only in points for displaying as name.
>
> Today I spent some time testing and repairing.
>
> The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
> also did not have the translations of all the languages anymore. It
> also lost draworder of a lot of polygons which made the bay-problem
> occur.
>
> I did a complete recheck of the most recent default-style in: mkgmap
> -r4386.zip and changed de typ-file accordingly.
>
> I downloaded a full europe-latest from geofabrik today, builded it as
> a big full europa map with the default style of r4386  and with
> mkgmap r4386.jar No errors occured.
>
> I think it’s up to date again but some review and comments are always
> welcome.
>
> See typ-file in attachement,
>
> Kind regards,
> Joris
>
>
>
>
>
> -----Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens Pinns
> UK
> Verzonden: maandag 9 december 2019 18:31
> Aan: Gerd Petermann ;
> mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Yes, you can do that with a draw level 1 higher than sea.
>
> Draw orders are defined at the beginning of a (txt) typ file just
> before the polygons
>
> using the following format
>
> Type=0x type number , draworder
>
> It is good practice to sort the draworders , as that is how they
> appear in a typ file
>
> [_drawOrder]
> Type=0x03,1
> Type=0x28,1
> Type=0x54,1
> Type=0x01,2
> Type=0x09,2
>   Type=0x4E,2
>   Type=0x10F1C,2
> etc etc
> [end]
> I have no idea what the draworder for sea is , but just make it one
> higher
>
> On 09/12/2019 16:41, Gerd Petermann wrote:
> > Hi Nick,
> >
> > I don't want to cut out islands from bay polygons, I thought about
> > a proper typ for 0x3d which somehow marks "calmer water"
> > and a draw order that puts this above water and below any land type
> > polygon.
> > Is that possible?
> >
> > Gerd
> >
> &g

Re: [mkgmap-dev] New branch for default typ file

2019-12-14 Thread Ticker Berkin

Hi Joris & Gerd

Great to see the typ-files now in trunk and all the work in updating
mapnik.txt to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and comment on it and possible changes to
the default style.

Some other questions however:

How do you see mapnik.txt now being maintained; will it be as as simple
.txt file with patches being supplied in the same way as other source
files, or will it be regenerated from your translation spreadsheet and
other sources? I'd prefer the simple text file approach, but this might
allow changes into the file which make it incompatible with the tools
Joris uses to enhance it.

It is currently in UTF8 format, with an appropriate BOM at the start of
the file. I don't know how the java input libraries determine the
conversion rules to internal unicode, but this file should be
consistent with all the others that contain characters outside the
simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)

It contains the statement:
> CodePage=65001
This is saying the output should be unicode, but the output should be
the same as the associated map.

Also the FID should be removed.

Regards
Ticker

On Tue, 2019-12-10 at 09:59 +, Gerd Petermann wrote:
> Hi Joris,
> 
> the file mapnik.txt says "Based on mkgmap default style version:
> r4262"
> Is it the right file?
> 
> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
> mkgmap:dest_hint=*)
> I want to look at the DestinationHook. If I got that right it should
> be OK to have a zero-length road with that type to get the wanted
> destination hint. In that case we don't have to care about rendering.
> 
> Gerd
> 
> 
> Von: Joris Bo 
> Gesendet: Montag, 9. Dezember 2019 20:45
> An: Development list for mkgmap; Gerd Petermann
> Betreff: RE: [mkgmap-dev] New branch for default typ file
> 
> Hi All,
> 
> I don't think any changes needed in mkgmap itself. When the draworder
> of bay is lower then water it will display correctly.
> See attached new typ-file for correct usage.
> Even better (but this is a change in default style): don't use
> natural = bay in polygons but only in points for displaying as name.
> 
> Today I spent some time testing and repairing.
> 
> The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and
> also did not have the translations of all the languages anymore. It
> also lost draworder of a lot of polygons which made the bay-problem
> occur.
> 
> I did a complete recheck of the most recent default-style in: mkgmap
> -r4386.zip and changed de typ-file accordingly.
> 
> I downloaded a full europe-latest from geofabrik today, builded it as
> a big full europa map with the default style of r4386  and with
> mkgmap r4386.jar No errors occured.
> 
> I think it’s up to date again but some review and comments are always
> welcome.
> 
> See typ-file in attachement,
> 
> Kind regards,
> Joris
> 
> 
> 
> 
> 
> -----Oorspronkelijk bericht-----
> Van: mkgmap-dev  Namens Pinns
> UK
> Verzonden: maandag 9 december 2019 18:31
> Aan: Gerd Petermann ; 
> mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> Yes, you can do that with a draw level 1 higher than sea.
> 
> Draw orders are defined at the beginning of a (txt) typ file just
> before the polygons
> 
> using the following format
> 
> Type=0x type number , draworder
> 
> It is good practice to sort the draworders , as that is how they
> appear in a typ file
> 
> [_drawOrder]
> Type=0x03,1
> Type=0x28,1
> Type=0x54,1
> Type=0x01,2
> Type=0x09,2
>   Type=0x4E,2
>   Type=0x10F1C,2
> etc etc
> [end]
> I have no idea what the draworder for sea is , but just make it one
> higher
> 
> On 09/12/2019 16:41, Gerd Petermann wrote:
> > Hi Nick,
> > 
> > I don't want to cut out islands from bay polygons, I thought about
> > a proper typ for 0x3d which somehow marks "calmer water"
> > and a draw order that puts this above water and below any land type
> > polygon.
> > Is that possible?
> > 
> > Gerd
> > 
> > 
> > Von: Pinns UK 
> > Gesendet: Montag, 9. Dezember 2019 16:17
> > An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
> > 
> > Hi Gerd
> > 
> > Yes, I suppose so
> > 
> > On 09/12/2019 15:14, Gerd Petermann wrote:
> > > Hi Nick,
> > > 
> > > my understanding is that you always have another water polygon,
> > > either ocean or natura

Re: [mkgmap-dev] New branch for default typ file

2019-12-10 Thread Gerd Petermann

Hi Joris,

the file mapnik.txt says "Based on mkgmap default style version: r4262"
Is it the right file?

reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | 
mkgmap:dest_hint=*)
I want to look at the DestinationHook. If I got that right it should be OK to 
have a zero-length road with that type to get the wanted destination hint. In 
that case we don't have to care about rendering.

Gerd

Von: Joris Bo 
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file

Hi All,

I don't think any changes needed in mkgmap itself. When the draworder of bay is 
lower then water it will display correctly.
See attached new typ-file for correct usage.
Even better (but this is a change in default style): don't use natural = bay in 
polygons but only in points for displaying as name.

Today I spent some time testing and repairing.

The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did 
not have the translations of all the languages anymore. It also lost draworder 
of a lot of polygons which made the bay-problem occur.

I did a complete recheck of the most recent default-style in: mkgmap-r4386.zip 
and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as a big 
full europa map with the default style of r4386  and with mkgmap r4386.jar No 
errors occured.

I think it’s up to date again but some review and comments are always welcome.

See typ-file in attachement,

Kind regards,
Joris

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Pinns UK
Verzonden: maandag 9 december 2019 18:31
Aan: Gerd Petermann ; 
mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, you can do that with a draw level 1 higher than sea.

Draw orders are defined at the beginning of a (txt) typ file just before the 
polygons

using the following format

Type=0x type number , draworder

It is good practice to sort the draworders , as that is how they appear in a 
typ file

[_drawOrder]
Type=0x03,1
Type=0x28,1
Type=0x54,1
Type=0x01,2
Type=0x09,2
  Type=0x4E,2
  Type=0x10F1C,2
etc etc
[end]
I have no idea what the draworder for sea is , but just make it one higher

On 09/12/2019 16:41, Gerd Petermann wrote:
> Hi Nick,
>
> I don't want to cut out islands from bay polygons, I thought about a proper 
> typ for 0x3d which somehow marks "calmer water"
> and a draw order that puts this above water and below any land type polygon.
> Is that possible?
>
> Gerd
>
> 
> Von: Pinns UK 
> Gesendet: Montag, 9. Dezember 2019 16:17
> An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Yes, I suppose so
>
> On 09/12/2019 15:14, Gerd Petermann wrote:
>> Hi Nick,
>>
>> my understanding is that you always have another water polygon, either ocean 
>> or natural=water.
>>
>> Gerd
>>
>> 
>> Von: Pinns UK 
>> Gesendet: Montag, 9. Dezember 2019 16:04
>> An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
>>
>> Hi Gerd
>>
>> In case of 2) you need 2 polygons for doing each job; one showing
>> 'water' and the other one not
>>
>> Ideally,mkgmap checks if islands are in a 'bay' area
>>
>> In my area we have lots of natural=bays ; fortunately they do not
>> include islands
>>
>> On 09/12/2019 14:51, Gerd Petermann wrote:
>>> Hi,
>>>
>>> thanks for the help.
>>> I see two ways to handle the a polygon with natural=bay:
>>> 1) in ponts style with natural=bay & name=*  []
>>> 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
>>>
>>> In case of 1) we just need option add-pois-to-areas In case of 2) we
>>> would want to render the water area covered by the bay polygon different, 
>>> but not anything on the land or on islands. Would that be possible?
>>>
>>> Gerd
>>>
>>>
>>>
>>> 
>>> Von: mkgmap-dev  im Auftrag
>>> von Pinns UK 
>>> Gesendet: Montag, 9. Dezember 2019 15:42
>>> An: mkgmap-dev@lists.mkgmap.org.uk
>>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>>
>>> Andrzej is correct about how transparency is defined
>>>
>>> Garmin regards all polygons with transparency  as bitmaps and
>>> therefore require 2 colours.
>>

Re: [mkgmap-dev] New branch for default typ file

2019-12-09 Thread Pinns UK


Hi Gerd

Yes, you can do that with a draw level 1 higher than sea.

Draw orders are defined at the beginning of a (txt) typ file just before 
the polygons


using the following format

Type=0x type number , draworder

It is good practice to sort the draworders , as that is how they appear 
in a typ file


[_drawOrder]
Type=0x03,1
Type=0x28,1
Type=0x54,1
Type=0x01,2
Type=0x09,2
 Type=0x4E,2
 Type=0x10F1C,2
etc etc
[end]
I have no idea what the draworder for sea is , but just make it one higher

On 09/12/2019 16:41, Gerd Petermann wrote:

Hi Nick,

I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d 
which somehow marks "calmer water"
and a draw order that puts this above water and below any land type polygon.
Is that possible?

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:

Hi Nick,

my understanding is that you always have another water polygon, either ocean or 
natural=water.

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not
include islands

On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

2019-12-09 Thread Gerd Petermann

Hi Nick,

I don't want to cut out islands from bay polygons, I thought about a proper typ 
for 0x3d which somehow marks "calmer water"
and a draw order that puts this above water and below any land type polygon.
Is that possible?

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:
> Hi Nick,
>
> my understanding is that you always have another water polygon, either ocean 
> or natural=water.
>
> Gerd
>
> 
> Von: Pinns UK 
> Gesendet: Montag, 9. Dezember 2019 16:04
> An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> In case of 2) you need 2 polygons for doing each job; one showing
> 'water' and the other one not
>
> Ideally,mkgmap checks if islands are in a 'bay' area
>
> In my area we have lots of natural=bays ; fortunately they do not
> include islands
>
> On 09/12/2019 14:51, Gerd Petermann wrote:
>> Hi,
>>
>> thanks for the help.
>> I see two ways to handle the a polygon with natural=bay:
>> 1) in ponts style with natural=bay & name=*  []
>> 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
>>
>> In case of 1) we just need option add-pois-to-areas
>> In case of 2) we would want to render the water area covered by the bay 
>> polygon different, but not anything on the land or on islands. Would that be 
>> possible?
>>
>> Gerd
>>
>>
>>
>> ________________________
>> Von: mkgmap-dev  im Auftrag von 
>> Pinns UK 
>> Gesendet: Montag, 9. Dezember 2019 15:42
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>
>> Andrzej is correct about how transparency is defined
>>
>> Garmin regards all polygons with transparency  as bitmaps and therefore
>> require 2 colours.
>>
>> The Bitmap need to be shown below the xpm
>>
>> If a polygon is completely transparent then a second 'dummy' colour is
>> still needed
>>
>> Xpm="32 32 2 1"
>> "0 c none"
>> "1 c #C8C8C8"
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ""
>> ;12345678901234567890123456789012
>> [end]
>>
>> On 09/12/2019 14:19, Andrzej Popowski wrote:
>>> Hi Gerd,
>>>
>>> I use TypViewer for creating typ files and I don't know XPM details.
>>> But looking at TypViewer output, I guess that transparent pixels are
>>> defined with color like that:
>>>
>>> "  c none"
>>>
>>> where space ' ' is used for marking pixels.
>>>
>>> Changing draw order instead of transparent graphics could be a
>>> solution too, but I'm not sure if covered polygon label would remain
>>> visible. And without label, there is not much use of this object.
>>>
>> ___
>> 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] New branch for default typ file

2019-12-09 Thread Andrzej Popowski


Hi,

see example of natural=bay, which can give problems:
https://www.openstreetmap.org/relation/9408222

--
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] New branch for default typ file

2019-12-09 Thread Pinns UK


Hi Gerd

Yes, I suppose so

On 09/12/2019 15:14, Gerd Petermann wrote:

Hi Nick,

my understanding is that you always have another water polygon, either ocean or 
natural=water.

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not
include islands

On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

2019-12-09 Thread Ticker Berkin

Hi

Sorry - seems that the name went from mkgmap.txt

Ticker

On Mon, 2019-12-09 at 15:13 +, Ticker Berkin wrote:
> Hi
> 
> My understanding was that mkgmap.txt rather than mapnik.txt was going
> to be one of the typ-files examples
> 
> Ticker
> 
> On Mon, 2019-12-09 at 10:18 +, Joris Bo wrote:
> > Hello,
> > 
> > Where can i find the mapnik.txt which has been referred to? It is
> > not
> > in the download zip is it?
> > I did have a quick look on the files I once sended, but I don't yet
> > see anything really wrong in there.
> > 
> > The natural=bay area has a 'land fill color' but also a draworder
> > lower then all the other water areas
> > So it should appear on the bottom anyway. In fact this would in a
> > way
> > represent the 'transparent' option
> > 
> > I think in mapnik, bays are only rendered as poi because the see
> > and
> > water area's duplicate those
> > A bay is a part of the lake, coastline or sea.
> > This was my conclusion after a lot of water and bay rendering in
> > Norway fjords. 
> > So maybe it's better to remove natural=bay 0x3d from the default
> > polygon and only use a name in the POI file anyway.
> > 
> > Would be nice if I could get the mapnik.txt and an example area to
> > have a better look.
> > So far in my styles and typ I have never encountered such a 'bay'
> > problem
> > 
> > Kind regards,
> > Joris
> > 
> > 
> > -Oorspronkelijk bericht-
> > Van: mkgmap-dev  Namens
> > Gerd
> > Petermann
> > Verzonden: zondag 8 december 2019 10:50
> > Aan: DD8KQ ; mkgmap-dev@lists.mkgmap.org.uk
> > Onderwerp: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi typ file experts,
> > please, can anybody post a patch to fix the mapnik.txt regarding
> > 0x3d?
> > I really don't understand the details.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von DD8KQ 
> > Gesendet: Freitag, 6. Dezember 2019 16:42
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi Gerd
> > 
> > i can remember that some time ago i stumbled also about this fact
> > and
> > i asked the community. I don't remember who gave me the hint but
> > after i've changed the colour into some kind of blue for polygon
> > type
> > 0x3d, it changed to be OK from that time on
> > 
> > Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
> > > Hi Ticker,
> > > 
> > > I've learned that polygon type 0x3d (natural=bay) in mapnik typ
> > > is
> > > wrong. It renders as a gray area and may hide the sea below.
> > > I am not sure what the correction is. If possible I would use
> > > "transparent" without any colour, else the same as 0x32.
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Donnerstag, 5. Dezember 2019 11:20
> > > An: mkgmap development
> > > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > > 
> > > Hi Gerd
> > > 
> > > I think it would be good if the files from branches/default
> > > -typ/resources/typ-files were put into trunk and, in build.xml,
> > > after:
> > > 
> > >   > > name="chars/ascii/row02.trans"/> this is added:
> > >  
> > > 
> > > Ticker
> > > 
> > > ___
> > > 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 mhai...@t-online.de dd...@gmx.de
> > 
> > #
> > 
> > ___
> > 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

Re: [mkgmap-dev] New branch for default typ file

2019-12-09 Thread Gerd Petermann

Hi Nick,

my understanding is that you always have another water polygon, either ocean or 
natural=water.

Gerd


Von: Pinns UK 
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not

Ideally,mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not
include islands

On 09/12/2019 14:51, Gerd Petermann wrote:
> Hi,
>
> thanks for the help.
> I see two ways to handle the a polygon with natural=bay:
> 1) in ponts style with natural=bay & name=*  []
> 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
>
> In case of 1) we just need option add-pois-to-areas
> In case of 2) we would want to render the water area covered by the bay 
> polygon different, but not anything on the land or on islands. Would that be 
> possible?
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  im Auftrag von Pinns 
> UK 
> Gesendet: Montag, 9. Dezember 2019 15:42
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Andrzej is correct about how transparency is defined
>
> Garmin regards all polygons with transparency  as bitmaps and therefore
> require 2 colours.
>
> The Bitmap need to be shown below the xpm
>
> If a polygon is completely transparent then a second 'dummy' colour is
> still needed
>
> Xpm="32 32 2 1"
> "0 c none"
> "1 c #C8C8C8"
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ;12345678901234567890123456789012
> [end]
>
> On 09/12/2019 14:19, Andrzej Popowski wrote:
>> Hi Gerd,
>>
>> I use TypViewer for creating typ files and I don't know XPM details.
>> But looking at TypViewer output, I guess that transparent pixels are
>> defined with color like that:
>>
>> "  c none"
>>
>> where space ' ' is used for marking pixels.
>>
>> Changing draw order instead of transparent graphics could be a
>> solution too, but I'm not sure if covered polygon label would remain
>> visible. And without label, there is not much use of this object.
>>
> ___
> 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] New branch for default typ file

2019-12-09 Thread Ticker Berkin

Hi

My understanding was that mkgmap.txt rather than mapnik.txt was going
to be one of the typ-files examples

Ticker

On Mon, 2019-12-09 at 10:18 +, Joris Bo wrote:
> Hello,
> 
> Where can i find the mapnik.txt which has been referred to? It is not
> in the download zip is it?
> I did have a quick look on the files I once sended, but I don't yet
> see anything really wrong in there.
> 
> The natural=bay area has a 'land fill color' but also a draworder
> lower then all the other water areas
> So it should appear on the bottom anyway. In fact this would in a way
> represent the 'transparent' option
> 
> I think in mapnik, bays are only rendered as poi because the see and
> water area's duplicate those
> A bay is a part of the lake, coastline or sea.
> This was my conclusion after a lot of water and bay rendering in
> Norway fjords. 
> So maybe it's better to remove natural=bay 0x3d from the default
> polygon and only use a name in the POI file anyway.
> 
> Would be nice if I could get the mapnik.txt and an example area to
> have a better look.
> So far in my styles and typ I have never encountered such a 'bay'
> problem
> 
> Kind regards,
> Joris
> 
> 
> -Oorspronkelijk bericht-
> Van: mkgmap-dev  Namens Gerd
> Petermann
> Verzonden: zondag 8 december 2019 10:50
> Aan: DD8KQ ; mkgmap-dev@lists.mkgmap.org.uk
> Onderwerp: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi typ file experts,
> please, can anybody post a patch to fix the mapnik.txt regarding
> 0x3d?
> I really don't understand the details.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von DD8KQ 
> Gesendet: Freitag, 6. Dezember 2019 16:42
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> i can remember that some time ago i stumbled also about this fact and
> i asked the community. I don't remember who gave me the hint but
> after i've changed the colour into some kind of blue for polygon type
> 0x3d, it changed to be OK from that time on
> 
> Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
> > Hi Ticker,
> > 
> > I've learned that polygon type 0x3d (natural=bay) in mapnik typ is
> > wrong. It renders as a gray area and may hide the sea below.
> > I am not sure what the correction is. If possible I would use
> > "transparent" without any colour, else the same as 0x32.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 5. Dezember 2019 11:20
> > An: mkgmap development
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi Gerd
> > 
> > I think it would be good if the files from branches/default
> > -typ/resources/typ-files were put into trunk and, in build.xml,
> > after:
> > 
> >   > name="chars/ascii/row02.trans"/> this is added:
> >  
> > 
> > Ticker
> > 
> > ___
> > 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 mhai...@t-online.de dd...@gmx.de
> 
> #
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2019-12-09 Thread Pinns UK


Hi Gerd

In case of 2) you need 2 polygons for doing each job; one showing 
'water' and the other one not


Ideally,    mkgmap checks if islands are in a 'bay' area

In my area we have lots of natural=bays ; fortunately they do not 
include islands


On 09/12/2019 14:51, Gerd Petermann wrote:

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd




Von: mkgmap-dev  im Auftrag von Pinns UK 

Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:

"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.


___
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] New branch for default typ file

2019-12-09 Thread Gerd Petermann

Hi,

thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=*  []
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]

In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon 
different, but not anything on the land or on islands. Would that be possible?

Gerd

Von: mkgmap-dev  im Auftrag von Pinns 
UK 
Gesendet: Montag, 9. Dezember 2019 15:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore
require 2 colours.

The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is
still needed

Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:
> Hi Gerd,
>
> I use TypViewer for creating typ files and I don't know XPM details.
> But looking at TypViewer output, I guess that transparent pixels are
> defined with color like that:
>
> "  c none"
>
> where space ' ' is used for marking pixels.
>
> Changing draw order instead of transparent graphics could be a
> solution too, but I'm not sure if covered polygon label would remain
> visible. And without label, there is not much use of this object.
>
___
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] New branch for default typ file

2019-12-09 Thread Pinns UK


Andrzej is correct about how transparency is defined

Garmin regards all polygons with transparency  as bitmaps and therefore 
require 2 colours.


The Bitmap need to be shown below the xpm

If a polygon is completely transparent then a second 'dummy' colour is  
still needed


Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
""
;12345678901234567890123456789012
[end]

On 09/12/2019 14:19, Andrzej Popowski wrote:

Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details. 
But looking at TypViewer output, I guess that transparent pixels are 
defined with color like that:


"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a 
solution too, but I'm not sure if covered polygon label would remain 
visible. And without label, there is not much use of this object.



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

Re: [mkgmap-dev] New branch for default typ file

2019-12-09 Thread Andrzej Popowski


Hi Gerd,

I use TypViewer for creating typ files and I don't know XPM details. But 
looking at TypViewer output, I guess that transparent pixels are defined 
with color like that:


"  c none"

where space ' ' is used for marking pixels.

Changing draw order instead of transparent graphics could be a solution 
too, but I'm not sure if covered polygon label would remain visible. And 
without label, there is not much use of this object.


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

Re: [mkgmap-dev] New branch for default typ file

2019-12-09 Thread Joris Bo

Hello,

Where can i find the mapnik.txt which has been referred to? It is not in the 
download zip is it?
I did have a quick look on the files I once sended, but I don't yet see 
anything really wrong in there.

The natural=bay area has a 'land fill color' but also a draworder lower then 
all the other water areas
So it should appear on the bottom anyway. In fact this would in a way represent 
the 'transparent' option

I think in mapnik, bays are only rendered as poi because the see and water 
area's duplicate those
A bay is a part of the lake, coastline or sea.
This was my conclusion after a lot of water and bay rendering in Norway fjords. 
So maybe it's better to remove natural=bay 0x3d from the default polygon and 
only use a name in the POI file anyway.

Would be nice if I could get the mapnik.txt and an example area to have a 
better look.
So far in my styles and typ I have never encountered such a 'bay' problem

Kind regards,
Joris


-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd Petermann
Verzonden: zondag 8 december 2019 10:50
Aan: DD8KQ ; mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for default typ file

Hi typ file experts,
please, can anybody post a patch to fix the mapnik.txt regarding 0x3d?
I really don't understand the details.

Gerd


Von: mkgmap-dev  im Auftrag von DD8KQ 

Gesendet: Freitag, 6. Dezember 2019 16:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

i can remember that some time ago i stumbled also about this fact and i asked 
the community. I don't remember who gave me the hint but after i've changed the 
colour into some kind of blue for polygon type 0x3d, it changed to be OK from 
that time on

Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
> Hi Ticker,
>
> I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It 
> renders as a gray area and may hide the sea below.
> I am not sure what the correction is. If possible I would use "transparent" 
> without any colour, else the same as 0x32.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag 
> von Ticker Berkin 
> Gesendet: Donnerstag, 5. Dezember 2019 11:20
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> I think it would be good if the files from 
> branches/default-typ/resources/typ-files were put into trunk and, in 
> build.xml, after:
> 
>   name="chars/ascii/row02.trans"/> this is added:
>  
>
> Ticker
>
> ___
> 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 mhai...@t-online.de dd...@gmx.de

#

___
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] New branch for default typ file

2019-12-09 Thread Gerd Petermann

Hi Andrzej,

good to see that you are still active!
That was my thought as well. I just don't know how to make a typ transparent. I 
feel completely incapable when it comes to graphics, so I never used a typ file 
editor.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Sonntag, 8. Dezember 2019 23:44
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd,

natural=bay is not a water but a name for an area. It can cover islands too:
https://wiki.openstreetmap.org/wiki/Tag:natural=bay

IMHO transparent polygon is a good solution.

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

Re: [mkgmap-dev] New branch for default typ file

2019-12-08 Thread Andrzej Popowski


Hi Gerd,

natural=bay is not a water but a name for an area. It can cover islands too:
https://wiki.openstreetmap.org/wiki/Tag:natural=bay

IMHO transparent polygon is a good solution.

--
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] New branch for default typ file

2019-12-08 Thread Gerd Petermann

Hi typ file experts,
please, can anybody post a patch to fix the mapnik.txt regarding 0x3d?
I really don't understand the details.

Gerd


Von: mkgmap-dev  im Auftrag von DD8KQ 

Gesendet: Freitag, 6. Dezember 2019 16:42
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

i can remember that some time ago i stumbled also about this fact and i
asked the community. I don't remember who gave me the hint but after
i've changed the colour into some kind of blue for polygon type 0x3d, it
changed to be OK from that time on

Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
> Hi Ticker,
>
> I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It 
> renders as a gray area and may hide the sea below.
> I am not sure what the correction is. If possible I would use "transparent" 
> without any colour, else the same as 0x32.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von 
> Ticker Berkin 
> Gesendet: Donnerstag, 5. Dezember 2019 11:20
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> I think it would be good if the files from 
> branches/default-typ/resources/typ-files were put into trunk and, in 
> build.xml, after:
> 
>  
> this is added:
>  
>
> Ticker
>
> ___
> 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 mhai...@t-online.de dd...@gmx.de

#

___
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] New branch for default typ file

2019-12-06 Thread DD8KQ


Hi Gerd

i can remember that some time ago i stumbled also about this fact and i
asked the community. I don't remember who gave me the hint but after
i've changed the colour into some kind of blue for polygon type 0x3d, it
changed to be OK from that time on

Am 06.12.2019 um 09:17 schrieb Gerd Petermann:

Hi Ticker,

I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It 
renders as a gray area and may hide the sea below.
I am not sure what the correction is. If possible I would use "transparent" 
without any colour, else the same as 0x32.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Donnerstag, 5. Dezember 2019 11:20
An: mkgmap development
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

I think it would be good if the files from 
branches/default-typ/resources/typ-files were put into trunk and, in build.xml, 
after:

 
this is added:
 

Ticker

___
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 mhai...@t-online.de dd...@gmx.de

#

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

Re: [mkgmap-dev] New branch for default typ file

2019-12-06 Thread Ticker Berkin

Hi Gerd

Looking at mkgmap.txt, neither 0x32 or 0x3d have a _drawOrder and so
the render priority is device specific but probably the same. So, if
the same and unless --order-by-decreasing-area is specified, either
could be shown on top in an apparently random way.

0x3d is given colour #F2EFE9

0x32 has:
CustomColor=Day
DaycustomColor:#4D80B3
Xpm="0 0 1 0"
"1 c #AAD3DF"

I'd avoid using transparent if possible (can only be done by creating
an 'icon') but it could be changed to have the same colour as you
suggest or just specifying _drawOrder.

There will probably be many other cases like this where whatever is
provided with mkgmap could be done differently. 

I don't expect any one typ-file to be definitive and for any
experienced map generator to accept it fully, but rather having a set
of examples, with some tailored to the default style.

I doubt if anyone has created svn/branches/defaut-typ to be able to
experiment and comment on these, but once some examples are commonly
available, I'm sure they will be of use.

An enhancement that I'd consider useful would be a way of selecting
bits of typ-files from different sources. This could be by allowing a
list on the command line or an 'include' command within the typ-file.
Then having rules about how a duplicate object overwrites or combines
with the definition so far. 

Ticker

On Fri, 2019-12-06 at 08:17 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I've learned that polygon type 0x3d (natural=bay) in mapnik typ is
> wrong. It renders as a gray area and may hide the sea below.
> I am not sure what the correction is. If possible I would use
> "transparent" without any colour, else the same as 0x32.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 5. Dezember 2019 11:20
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> I think it would be good if the files from branches/default
> -typ/resources/typ-files were put into trunk and, in build.xml,
> after:
> 
>  name="chars/ascii/row02.trans"/>
> this is added:
> 
> 
> 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] New branch for default typ file

2019-12-06 Thread Gerd Petermann

Hi Ticker,

I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It 
renders as a gray area and may hide the sea below.
I am not sure what the correction is. If possible I would use "transparent" 
without any colour, else the same as 0x32.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 5. Dezember 2019 11:20
An: mkgmap development
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

I think it would be good if the files from 
branches/default-typ/resources/typ-files were put into trunk and, in build.xml, 
after:


this is added:


Ticker

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

Re: [mkgmap-dev] New branch for default typ file

2019-12-05 Thread Ticker Berkin

Hi Gerd

I think it would be good if the files from branches/default
-typ/resources/typ-files were put into trunk and, in build.xml, after:


this is added:


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

Re: [mkgmap-dev] New branch for default typ file

2018-12-02 Thread Gerd Petermann

Greg Troxel-2 wrote
> I don't think it's off topic at all.

Well, I think it would be better to open a new thread, because this one is
about a default typ file for mkgmap.

Greg Troxel-2 wrote
>> project to add some non-OSM data to my maps but I thought the only way to
>> do this was with osmosis, combining a generated change file with the real
>> data. Is your process documented somewhere? If not, do you mind sharing
>> it
>> here?
> 
> I have generated a file "lots.osm" which has parcel data as polygons
> with boundary=parcel tags, and just call splitter with
> "us-northeast-latest.osm.pbf" and "lots.osm".
> 
> My lots.osm file has negative numbers for ids.  I remember using some
> python code to read shapefiles and write the osm file, but I no longer
> remember the details.  There is nothing odd about the file, other than
> using negative ids.
> 
> With 64-bit ids, perhaps I should be picking some other private range
> that isn't negative.  But I bet it doesn't matter as long as they are
> unique.

Yes, unique ids are most important, for splitter it doesn't matter if ids
are positive or negative. 
Just make sure to avoid 0 and Long.MAX_VALUE (9223372036854775807  or 0x7fff
  ).
In mkgmap we reserve a range of ids starting at 4611686018427387904 (0x4000
  ).

When "keep-complete" is active only the data in the first file is kept
complete, therefore later files should not contain relations.

If you use a program like osmosis or osmconvert to merge the files first you
should make sure that the files
are sorted by type (nodes, ways, relations) and each type by id (smallest
first).
The files from geofabrik are sorted this way.

Gerd



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-12-02 Thread Greg Troxel

Ben Konrath  writes:

> I realize this is a bit off-topic on this thread but I'm curious to know
> your process for combing non-OSM data with splitter. I was just starting a

I don't think it's off topic at all.

> project to add some non-OSM data to my maps but I thought the only way to
> do this was with osmosis, combining a generated change file with the real
> data. Is your process documented somewhere? If not, do you mind sharing it
> here?

I have generated a file "lots.osm" which has parcel data as polygons
with boundary=parcel tags, and just call splitter with
"us-northeast-latest.osm.pbf" and "lots.osm".

My lots.osm file has negative numbers for ids.  I remember using some
python code to read shapefiles and write the osm file, but I no longer
remember the details.  There is nothing odd about the file, other than
using negative ids.

With 64-bit ids, perhaps I should be picking some other private range
that isn't negative.  But I bet it doesn't matter as long as they are
unique.

I've been doing this for years with no problems.

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

Re: [mkgmap-dev] New branch for default typ file

2018-12-02 Thread Ticker Berkin

I just generate an XML file with negative ids like:



 
  
 
 
  
 
...


and give as a parameter to splitter after the main osm.pbf map data
file.

Ticker

On Sun, 2018-12-02 at 16:02 +0100, Ben Konrath wrote:
> Hi Greg,
> 
> On Tue, 27 Nov 2018 at 18:21, Greg Troxel  wrote:
> >  Semi-related, I am carrying a diff to render "boundary=parcel"; I
> > include state parcel boundary data with osm data in splitter.  I
> > have no
> > idea how many others want this, but given that parcel data is not
> > in
> > OSM, merging while mapbuilding (or a separate transparent parcel
> > map)
> > seems pretty useful.  What I'm doing is not really ok, but I'm just
> > mentioning the concept.
> I realize this is a bit off-topic on this thread but I'm curious to
> know your process for combing non-OSM data with splitter. I was just
> starting a project to add some non-OSM data to my maps but I thought
> the only way to do this was with osmosis, combining a generated
> change file with the real data. Is your process documented somewhere?
> If not, do you mind sharing it here?
> 
> Thanks, Ben
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-12-02 Thread Ben Konrath

Hi Greg,

On Tue, 27 Nov 2018 at 18:21, Greg Troxel  wrote:

> Semi-related, I am carrying a diff to render "boundary=parcel"; I
> include state parcel boundary data with osm data in splitter.  I have no
> idea how many others want this, but given that parcel data is not in
> OSM, merging while mapbuilding (or a separate transparent parcel map)
> seems pretty useful.  What I'm doing is not really ok, but I'm just
> mentioning the concept.
>

I realize this is a bit off-topic on this thread but I'm curious to know
your process for combing non-OSM data with splitter. I was just starting a
project to add some non-OSM data to my maps but I thought the only way to
do this was with osmosis, combining a generated change file with the real
data. Is your process documented somewhere? If not, do you mind sharing it
here?

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

Re: [mkgmap-dev] New branch for default typ file

2018-11-27 Thread Greg Troxel

Ticker Berkin  writes:

(I'm a long-term mkgamp user, sometimes contributor, mostly lurking
lately.)

> I don't think having:
>
> BRANCH: default-typ
>
> makes sense because I don't think there will ever be a single, ideal
> file. So better to accept now that it will be a collection of files,
> and, as nothing exists at the moment, they might as well go in 'trunk'.

As I see it, branches are useful for protecting trunk from changes that
are in-progress or controversial.  Adding some typ sources doesn't seem
to rise to that.  But if so, then surely we'd have a branch until it's
reviewed, and then merge it and delete the branch.  I'm unclear on if
that's the choice, or if there is some other suggestion that I don't
understand.

> I don't know what the best visual effect should be either, but, having
> tried a complex example I found somewhere, the raw Garmin device
> rendering (with just a _drawOrder section in the TYP file) looked much,
> much better.

Having a bunch of examples sounds good.  I would like to head to a
default typ file that is integrated with the default style, so that
rendering is more or less aligned with mapnik, but perhaps a bit more
detailed at high zoom.

I used to use cferrero's style/typ and really liked it, but with mkgmap
improvements over the years it was no longer usable without more clue
than I had.   The big thing over no-typ was showing traffic lights.

Semi-related, I am carrying a diff to render "boundary=parcel"; I
include state parcel boundary data with osm data in splitter.  I have no
idea how many others want this, but given that parcel data is not in
OSM, merging while mapbuilding (or a separate transparent parcel map)
seems pretty useful.  What I'm doing is not really ok, but I'm just
mentioning the concept.

# 0x23 is depth countour - thin.  Wacky but useful.  0x1c is too heavy
boundary=parcel [0x23 resolution 20]
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-11-27 Thread Ticker Berkin

Hi Gerd

I don't think having:

BRANCH: default-typ

makes sense because I don't think there will ever be a single, ideal
file. So better to accept now that it will be a collection of files,
and, as nothing exists at the moment, they might as well go in 'trunk'.

In trunk, they will be visible sooner to all mkgmap users. Then any in
the dist/examples/typ-files directory could be selected to be used as
-is or a starting point for modification.

I don't know what the best visual effect should be either, but, having
tried a complex example I found somewhere, the raw Garmin device
rendering (with just a _drawOrder section in the TYP file) looked much,
much better.

I'm hoping others will submit examples, then we just need some
reference in the documentation to point people to the examples, along
with good comments in the files themselves.

Ticker

On Tue, 2018-11-27 at 10:59 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> well, we have it because I wrote that I'd like to have a typ file for
> the default style. My problem is that I cannot help with that because
> I feel helpless when it comes to questions reg. "what looks better?" 
>  or "what should be rendered and how?"
> Do you think we need another branch or do you think that the exising
> one makes no sense?
> 
> Gerd
> 
> 
> Von: Ticker Berkin 
> Gesendet: Dienstag, 27. November 2018 11:37
> An: Gerd Petermann; Development list for mkgmap
> Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> Is it worth having a branch for typ-files development?
> 
> Ticker
> 
> 
> On Tue, 2018-11-27 at 09:25 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > okay, see
> > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=425
> > 8
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 27. November 2018 09:56
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi Gerd
> > 
> > Happy with either, but slightly prefer typ-files.
> > 
> > I don't think it's worth me doing another patch, it was really just
> > a
> > 1
> > line change to build.xml and inserting the attached file
> > 
> > Ticker
> > 
> > 
> > On Tue, 2018-11-27 at 06:27 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > I don't like the directory name TYPs. One reason is that the
> > > directory doesn't contain *.TYP files, the other is that one
> > > might
> > > want to write TYPes instead.
> > > I'd prefer typ-files or maybe typ-sources.
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Montag, 19. November 2018 13:07
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > > 
> > > Hi
> > > 
> > > I suspect there will be a few TYP files for different usages.
> > > 
> > > I propose that they should be handled like the styles, where they
> > > are
> > > gathered in a directory resources/TYPs and the build process
> > > copies
> > > then to dist/examples/TYPs
> > > 
> > > I don't think a new branch is necessary, as there is nothing in
> > > the
> > > system at the moment.
> > > 
> > > I'd like to submit my most basic TYPfile and attach the file and
> > > patch.
> > > This, along with option --order-by-decreasing-area, has been
> > > adequate
> > > for me for a few years (but I have problems with my new Etrex 30x
> > > not
> > > showing some line types)
> > > 
> > > 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] New branch for default typ file

2018-11-27 Thread Gerd Petermann

Hi Ticker,

well, we have it because I wrote that I'd like to have a typ file for the 
default style. My problem is that I cannot help with that because
I feel helpless when it comes to questions reg. "what looks better?"  or "what 
should be rendered and how?"
Do you think we need another branch or do you think that the exising one makes 
no sense?

Gerd


Von: Ticker Berkin 
Gesendet: Dienstag, 27. November 2018 11:37
An: Gerd Petermann; Development list for mkgmap
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file

Hi Gerd

Is it worth having a branch for typ-files development?

Ticker


On Tue, 2018-11-27 at 09:25 +, Gerd Petermann wrote:
> Hi Ticker,
>
> okay, see
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4258
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 27. November 2018 09:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Happy with either, but slightly prefer typ-files.
>
> I don't think it's worth me doing another patch, it was really just a
> 1
> line change to build.xml and inserting the attached file
>
> Ticker
>
>
> On Tue, 2018-11-27 at 06:27 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I don't like the directory name TYPs. One reason is that the
> > directory doesn't contain *.TYP files, the other is that one might
> > want to write TYPes instead.
> > I'd prefer typ-files or maybe typ-sources.
> >
> > Gerd
> >
> > ____
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 19. November 2018 13:07
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> >
> > Hi
> >
> > I suspect there will be a few TYP files for different usages.
> >
> > I propose that they should be handled like the styles, where they
> > are
> > gathered in a directory resources/TYPs and the build process copies
> > then to dist/examples/TYPs
> >
> > I don't think a new branch is necessary, as there is nothing in the
> > system at the moment.
> >
> > I'd like to submit my most basic TYPfile and attach the file and
> > patch.
> > This, along with option --order-by-decreasing-area, has been
> > adequate
> > for me for a few years (but I have problems with my new Etrex 30x
> > not
> > showing some line types)
> >
> > 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] New branch for default typ file

2018-11-27 Thread Ticker Berkin

Hi Gerd

Is it worth having a branch for typ-files development?

Ticker


On Tue, 2018-11-27 at 09:25 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> okay, see 
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4258
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 27. November 2018 09:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi Gerd
> 
> Happy with either, but slightly prefer typ-files.
> 
> I don't think it's worth me doing another patch, it was really just a
> 1
> line change to build.xml and inserting the attached file
> 
> Ticker
> 
> 
> On Tue, 2018-11-27 at 06:27 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I don't like the directory name TYPs. One reason is that the
> > directory doesn't contain *.TYP files, the other is that one might
> > want to write TYPes instead.
> > I'd prefer typ-files or maybe typ-sources.
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 19. November 2018 13:07
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi
> > 
> > I suspect there will be a few TYP files for different usages.
> > 
> > I propose that they should be handled like the styles, where they
> > are
> > gathered in a directory resources/TYPs and the build process copies
> > then to dist/examples/TYPs
> > 
> > I don't think a new branch is necessary, as there is nothing in the
> > system at the moment.
> > 
> > I'd like to submit my most basic TYPfile and attach the file and
> > patch.
> > This, along with option --order-by-decreasing-area, has been
> > adequate
> > for me for a few years (but I have problems with my new Etrex 30x
> > not
> > showing some line types)
> > 
> > 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] New branch for default typ file

2018-11-27 Thread Gerd Petermann

Hi Ticker,

okay, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4258

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 27. November 2018 09:56
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

Happy with either, but slightly prefer typ-files.

I don't think it's worth me doing another patch, it was really just a 1
line change to build.xml and inserting the attached file

Ticker


On Tue, 2018-11-27 at 06:27 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't like the directory name TYPs. One reason is that the
> directory doesn't contain *.TYP files, the other is that one might
> want to write TYPes instead.
> I'd prefer typ-files or maybe typ-sources.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 19. November 2018 13:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi
>
> I suspect there will be a few TYP files for different usages.
>
> I propose that they should be handled like the styles, where they are
> gathered in a directory resources/TYPs and the build process copies
> then to dist/examples/TYPs
>
> I don't think a new branch is necessary, as there is nothing in the
> system at the moment.
>
> I'd like to submit my most basic TYPfile and attach the file and
> patch.
> This, along with option --order-by-decreasing-area, has been adequate
> for me for a few years (but I have problems with my new Etrex 30x not
> showing some line types)
>
> 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] New branch for default typ file

2018-11-27 Thread Ticker Berkin

Hi Gerd

Happy with either, but slightly prefer typ-files.

I don't think it's worth me doing another patch, it was really just a 1
line change to build.xml and inserting the attached file

Ticker


On Tue, 2018-11-27 at 06:27 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I don't like the directory name TYPs. One reason is that the
> directory doesn't contain *.TYP files, the other is that one might
> want to write TYPes instead.
> I'd prefer typ-files or maybe typ-sources.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 19. November 2018 13:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
> 
> Hi
> 
> I suspect there will be a few TYP files for different usages.
> 
> I propose that they should be handled like the styles, where they are
> gathered in a directory resources/TYPs and the build process copies
> then to dist/examples/TYPs
> 
> I don't think a new branch is necessary, as there is nothing in the
> system at the moment.
> 
> I'd like to submit my most basic TYPfile and attach the file and
> patch.
> This, along with option --order-by-decreasing-area, has been adequate
> for me for a few years (but I have problems with my new Etrex 30x not
> showing some line types)
> 
> 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] New branch for default typ file

2018-11-26 Thread Gerd Petermann

Hi Ticker,

I don't like the directory name TYPs. One reason is that the directory doesn't 
contain *.TYP files, the other is that one might want to write TYPes instead.
I'd prefer typ-files or maybe typ-sources.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 19. November 2018 13:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi

I suspect there will be a few TYP files for different usages.

I propose that they should be handled like the styles, where they are
gathered in a directory resources/TYPs and the build process copies
then to dist/examples/TYPs

I don't think a new branch is necessary, as there is nothing in the
system at the moment.

I'd like to submit my most basic TYPfile and attach the file and patch.
This, along with option --order-by-decreasing-area, has been adequate
for me for a few years (but I have problems with my new Etrex 30x not
showing some line types)

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

Re: [mkgmap-dev] New branch for default typ file

2018-11-26 Thread Ticker Berkin

Hi Gerd

Should we start dist/examples/TYPs/* as per my email on 19-Nov?

Ticker 


On Mon, 2018-11-19 at 12:44 -0500, Greg Troxel wrote:
> Ticker Berkin  writes:
> 
> > I suspect there will be a few TYP files for different usages.
> 
> perhaps, but as I understand it there can be a lot of
> include/not-include in styles, so I see TYP files being different as
> a
> high-level difference, within which there can be maps built for
> different reasons.   And I would hope there would be fewer TYP files,
> just because things are confusing enough.
> 
> > I propose that they should be handled like the styles, where they
> > are
> > gathered in a directory resources/TYPs and the build process copies
> > then to dist/examples/TYPs
> > 
> > I don't think a new branch is necessary, as there is nothing in the
> > system at the moment.
> > 
> > I'd like to submit my most basic TYPfile and attach the file and
> > patch.
> > This, along with option --order-by-decreasing-area, has been
> > adequate
> > for me for a few years (but I have problems with my new Etrex 30x
> > not
> > showing some line types)
> 
> That sounds fine to me.  I would hope that the TYP file is not
> actually
> checked in, but the source code that the mkgmap TYP compiler users,
> so
> it can be edited easily.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-11-19 Thread Greg Troxel

Ticker Berkin  writes:

> I suspect there will be a few TYP files for different usages.

perhaps, but as I understand it there can be a lot of
include/not-include in styles, so I see TYP files being different as a
high-level difference, within which there can be maps built for
different reasons.   And I would hope there would be fewer TYP files,
just because things are confusing enough.

> I propose that they should be handled like the styles, where they are
> gathered in a directory resources/TYPs and the build process copies
> then to dist/examples/TYPs
>
> I don't think a new branch is necessary, as there is nothing in the
> system at the moment.
>
> I'd like to submit my most basic TYPfile and attach the file and patch.
> This, along with option --order-by-decreasing-area, has been adequate
> for me for a few years (but I have problems with my new Etrex 30x not
> showing some line types)

That sounds fine to me.  I would hope that the TYP file is not actually
checked in, but the source code that the mkgmap TYP compiler users, so
it can be edited easily.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-11-19 Thread Ticker Berkin

Hi

I suspect there will be a few TYP files for different usages.

I propose that they should be handled like the styles, where they are
gathered in a directory resources/TYPs and the build process copies
then to dist/examples/TYPs

I don't think a new branch is necessary, as there is nothing in the
system at the moment.

I'd like to submit my most basic TYPfile and attach the file and patch.
This, along with option --order-by-decreasing-area, has been adequate
for me for a few years (but I have problems with my new Etrex 30x not
showing some line types)

Ticker
Index: build.xml
===
--- build.xml	(revision 4255)
+++ build.xml	(working copy)
@@ -406,6 +406,7 @@
 
 
 
+
 			
 		
 		
Index: resources/TYPs/sameOrder.txt
===
--- resources/TYPs/sameOrder.txt	(revision 0)
+++ resources/TYPs/sameOrder.txt	(working copy)
@@ -0,0 +1,119 @@
+;---
+; This is an example TYP file.
+; A TYP file controls how the Garmin device renders polygons, lines and points.
+;  See https://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile
+; for more information.
+;
+; This example sets most polygons to have the same drawOrder
+;  See https://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types
+; so that mkgmap option --order-by-decreasing-area works in an optimum manner.
+; It exposes all the known non-extended Garmin polygon representations, eg
+; 0x01-0x03=City and provides some hidden polygons for naming large areas such
+; as Counties, Islands...
+;---
+;
+[_drawOrder]
+; nothing shows, even with: Type=0x00,2
+Type=0x01,2
+Type=0x02,2
+Type=0x03,2
+Type=0x04,2
+Type=0x05,2
+Type=0x06,2
+; 0x07/Airport default drawOrder is lower that most other polygons on some Garmin devices; make it the same.
+Type=0x07,2
+Type=0x08,2
+Type=0x09,2
+Type=0x0a,2
+Type=0x0b,2
+Type=0x0c,2
+Type=0x0d,2
+Type=0x0e,2
+Type=0x0f,2
+Type=0x10,2
+Type=0x11,2
+Type=0x12,2
+Type=0x13,2
+; the following Greens default drawOrder is lower than most on some Garmin devices; make them the same.
+Type=0x14,2
+Type=0x15,2
+Type=0x16,2
+Type=0x17,2
+Type=0x18,2
+Type=0x19,2
+Type=0x1a,2
+Type=0x1b,2
+Type=0x1c,2
+Type=0x1d,2
+Type=0x1e,2
+Type=0x1f,2
+Type=0x20,2
+; to here
+Type=0x21,2
+Type=0x22,2
+Type=0x23,2
+Type=0x24,2
+Type=0x25,2
+Type=0x26,2
+Type=0x27,2
+Type=0x28,2
+Type=0x29,2
+Type=0x2a,2
+Type=0x2b,2
+Type=0x2c,2
+Type=0x2d,2
+Type=0x2e,2
+Type=0x2f,2
+Type=0x30,2
+Type=0x31,2
+Type=0x32,2
+Type=0x33,2
+Type=0x34,2
+Type=0x35,2
+Type=0x36,2
+Type=0x37,2
+Type=0x38,2
+Type=0x39,2
+Type=0x3a,2
+Type=0x3b,2
+Type=0x3c,2
+Type=0x3d,2
+Type=0x3e,2
+Type=0x3f,2
+Type=0x40,2
+Type=0x41,2
+Type=0x42,2
+Type=0x43,2
+Type=0x44,2
+Type=0x45,2
+Type=0x46,2
+Type=0x47,2
+Type=0x48,2
+Type=0x49,2
+; The following two are overview/main background. Give them a lower drawOrder.
+Type=0x4a,1
+Type=0x4b,1
+Type=0x4c,2
+Type=0x4d,2
+Type=0x4e,2
+Type=0x4f,2
+Type=0x50,2
+Type=0x51,2
+Type=0x52,2
+Type=0x53,2
+Type=0x54,2
+Type=0x55,2
+; The following don't seem to have any known pre-defined meaning to Garmin
+; devices and can be used to give a 'hover' or 'select' name and details without
+; other representation, being hidden with a lower drawOrder than the background.
+Type=0x56,0
+Type=0x57,0
+Type=0x58,0
+Type=0x59,0
+Type=0x5a,0
+Type=0x5b,0
+Type=0x5c,0
+Type=0x5d,0
+Type=0x5e,0
+Type=0x5f,0
+[end]
;---
; This is an example TYP file.
; A TYP file controls how the Garmin device renders polygons, lines and points.
;  See https://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile
; for more information.
;
; This example sets most polygons to have the same drawOrder
;  See https://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types
; so that mkgmap option --order-by-decreasing-area works in an optimum manner.
; It exposes all the known non-extended Garmin polygon representations, eg
; 0x01-0x03=City and provides some hidden polygons for naming large areas such
; as Counties, Islands...
;---
;
[_drawOrder]
; nothing shows, even with: Type=0x00,2
Type=0x01,2
Type=0x02,2
Type=0x03,2
Type=0x04,2
Type=0x05,2
Type=0x06,2
; 0x07/Airport default drawOrder is lower that most other polygons on some 
Garmin devices; make it the same.
Type=0x07,2
Type=0x08,2
Type=0x09,2
Type=0x0a,2
Type=0x0b,2
Type=0x0c,2
Type=0x0d,2
Type=0x0e,2
Type=0x0f,2
Type=0x10,2
Type=0x11,2
Type=0x12,2
Type=0x13,2
; the following Greens default drawOrder is lower than most on some Garmin 
devices; make them the same.
Type=0x14,2
Type=0x15,2
Type=0x16,2
Type=0x17,2
Type=0x18,2
Type=0x19,2
Type=0x1a,2
Type=0x1b,2
Type=0x1c,2
Type=0x1d,2

Re: [mkgmap-dev] New branch for default typ file

2018-11-07 Thread Ticker Berkin

Hi Gerd

Sorry about the various language/abbreviation issues - I'll do my best
to avoid them in future.

I'm happy with your modified patch for setting background / sea areas.

Thanks
Ticker

PS - I'm well before twitter and SMS and refuse to use smilies ;)

On Wed, 2018-11-07 at 14:39 +0700, Dave Swarthout wrote:
> "+ve" does indeed mean positive.  It's an older shorthand term
> sometimes used by scientists in the U.S.
> 
> Dave
> 
> On Wed, Nov 7, 2018 at 1:02 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > Hi Ticker,
> > 
> > I think what confused me was the use of abbreviation cf (I did not
> > know that) and that seaSize is a named constant which means
> > it should be in upper case. See my changes in r4248.
> > There is another confusing comment in Way.java:
> > // this is unadulterated size, +ve if clockwise
> > I guess that +ve means positive? This is hard to understand for a
> > non-native speaker who grew up before SMS and Twitter and just
> > learned to use smileys ;-)
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Dienstag, 6. November 2018 10:43
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> > 
> > Hi Gerd
> > 
> > It's not the name of the map feature that I'm talking about; rather
> > the
> > string representation of the type which my device displays, along
> > with
> > the name, when the map feature is selected.
> > 
> > So, for instance, I'd like to use one of the other the Park
> > representations, say 0x20, for leisure=garden. In the TYP file I'd
> > like
> > to set the String for this type, but don't want to override the
> > colour
> > / bitmap or whatever representation.
> > 
> > Concerning the background polygon, I want to set it's area to
> > bigger
> > than the sea area, where the default is set in SeaGenerator.java
> > with
> > the comment:
> > 
> > /**
> >  * When order-by-decreasing-area we need all bit of sea to be
> > output
> > consistently.
> >  * Unless _draworder changes things, having seaSize as BIG causes
> > polygons beyond the
> >  * coastline to be shown. To hide these and have the sea show up to
> > the
> > high-tide
> >  * coastline, can set this to be very small instead (or use
> > _draworder).
> >  * 
> >  * mkgmap:drawLevel can be used to override this value in the style
> > -
> > the default style has:
> >  * natural=sea { add mkgmap:skipSizeFilter=true; set
> > mkgmap:drawLevel=2
> > } [0x32 resolution 10]
> >  * which is equivalent to Long.MAX_VALUE-2.
> >  */
> > private static final long seaSize = Long.MAX_VALUE-2; // sea is BIG
> > 
> > I don't think having method just used by addBackground adds
> > anything to
> > clarity. I could put a constant with MAX_VALUE-1 and comment into
> > MapperBasedMapDataSource instead if you'd prefer
> > 
> > 
> > Regards
> > Ticker
> > 
> > On Tue, 2018-11-06 at 00:16 -0600, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > Ticker Berkin wrote
> > > > Does anyone know if it would be possible to change mkgmap to
> > allow
> > > > this?
> > >
> > > Not sure if this is what you want, did you try default_name?
> > > See e.g.
> > > amenity=emergency_phone [0x2f12 resolution 24 default_name
> > 'Emergency
> > > Phone']
> > >
> > > I don't understand the comment in the patch:
> > >   background.setFullArea(Long.MAX_VALUE-1); // cf:
> > > SeaGenerator.java:
> > > seaSize
> > > Wouldn't it be better to have a method named something like
> > > setAreaSizeToMax() ?
> > >
> > > Gerd
> > >
> > >
> > >
> > > --
> > > Sent from:
> > > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > > ___
> > > 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

Re: [mkgmap-dev] New branch for default typ file

2018-11-06 Thread Dave Swarthout

"+ve" does indeed mean positive.  It's an older shorthand term sometimes
used by scientists in the U.S.

Dave

On Wed, Nov 7, 2018 at 1:02 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Ticker,
>
> I think what confused me was the use of abbreviation cf (I did not know
> that) and that seaSize is a named constant which means
> it should be in upper case. See my changes in r4248.
> There is another confusing comment in Way.java:
> // this is unadulterated size, +ve if clockwise
> I guess that +ve means positive? This is hard to understand for a
> non-native speaker who grew up before SMS and Twitter and just learned to
> use smileys ;-)
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker Berkin 
> Gesendet: Dienstag, 6. November 2018 10:43
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> It's not the name of the map feature that I'm talking about; rather the
> string representation of the type which my device displays, along with
> the name, when the map feature is selected.
>
> So, for instance, I'd like to use one of the other the Park
> representations, say 0x20, for leisure=garden. In the TYP file I'd like
> to set the String for this type, but don't want to override the colour
> / bitmap or whatever representation.
>
> Concerning the background polygon, I want to set it's area to bigger
> than the sea area, where the default is set in SeaGenerator.java with
> the comment:
>
> /**
>  * When order-by-decreasing-area we need all bit of sea to be output
> consistently.
>  * Unless _draworder changes things, having seaSize as BIG causes
> polygons beyond the
>  * coastline to be shown. To hide these and have the sea show up to the
> high-tide
>  * coastline, can set this to be very small instead (or use
> _draworder).
>  * 
>  * mkgmap:drawLevel can be used to override this value in the style -
> the default style has:
>  * natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2
> } [0x32 resolution 10]
>  * which is equivalent to Long.MAX_VALUE-2.
>  */
> private static final long seaSize = Long.MAX_VALUE-2; // sea is BIG
>
> I don't think having method just used by addBackground adds anything to
> clarity. I could put a constant with MAX_VALUE-1 and comment into
> MapperBasedMapDataSource instead if you'd prefer
>
>
> Regards
> Ticker
>
> On Tue, 2018-11-06 at 00:16 -0600, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > Ticker Berkin wrote
> > > Does anyone know if it would be possible to change mkgmap to allow
> > > this?
> >
> > Not sure if this is what you want, did you try default_name?
> > See e.g.
> > amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency
> > Phone']
> >
> > I don't understand the comment in the patch:
> >   background.setFullArea(Long.MAX_VALUE-1); // cf:
> > SeaGenerator.java:
> > seaSize
> > Wouldn't it be better to have a method named something like
> > setAreaSizeToMax() ?
> >
> > Gerd
> >
> >
> >
> > --
> > Sent from:
> > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > ___
> > 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
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-11-06 Thread Gerd Petermann

Hi Ticker,

I think what confused me was the use of abbreviation cf (I did not know that) 
and that seaSize is a named constant which means
it should be in upper case. See my changes in r4248.
There is another confusing comment in Way.java:
// this is unadulterated size, +ve if clockwise
I guess that +ve means positive? This is hard to understand for a non-native 
speaker who grew up before SMS and Twitter and just learned to use smileys ;-)

Gerd

Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 6. November 2018 10:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file

Hi Gerd

It's not the name of the map feature that I'm talking about; rather the
string representation of the type which my device displays, along with
the name, when the map feature is selected.

So, for instance, I'd like to use one of the other the Park
representations, say 0x20, for leisure=garden. In the TYP file I'd like
to set the String for this type, but don't want to override the colour
/ bitmap or whatever representation.

Concerning the background polygon, I want to set it's area to bigger
than the sea area, where the default is set in SeaGenerator.java with
the comment:

/**
 * When order-by-decreasing-area we need all bit of sea to be output
consistently.
 * Unless _draworder changes things, having seaSize as BIG causes
polygons beyond the
 * coastline to be shown. To hide these and have the sea show up to the
high-tide
 * coastline, can set this to be very small instead (or use
_draworder).
 * 
 * mkgmap:drawLevel can be used to override this value in the style -
the default style has:
 * natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2
} [0x32 resolution 10]
 * which is equivalent to Long.MAX_VALUE-2.
 */
private static final long seaSize = Long.MAX_VALUE-2; // sea is BIG

I don't think having method just used by addBackground adds anything to
clarity. I could put a constant with MAX_VALUE-1 and comment into
MapperBasedMapDataSource instead if you'd prefer

Regards
Ticker

On Tue, 2018-11-06 at 00:16 -0600, Gerd Petermann wrote:
> Hi Ticker,
>
> Ticker Berkin wrote
> > Does anyone know if it would be possible to change mkgmap to allow
> > this?
>
> Not sure if this is what you want, did you try default_name?
> See e.g.
> amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency
> Phone']
>
> I don't understand the comment in the patch:
>   background.setFullArea(Long.MAX_VALUE-1); // cf:
> SeaGenerator.java:
> seaSize
> Wouldn't it be better to have a method named something like
> setAreaSizeToMax() ?
>
> Gerd
>
>
>
> --
> Sent from:
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> 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] New branch for default typ file

2018-11-06 Thread Ticker Berkin

Hi Gerd

It's not the name of the map feature that I'm talking about; rather the
string representation of the type which my device displays, along with
the name, when the map feature is selected.

So, for instance, I'd like to use one of the other the Park
representations, say 0x20, for leisure=garden. In the TYP file I'd like
to set the String for this type, but don't want to override the colour
/ bitmap or whatever representation.

Concerning the background polygon, I want to set it's area to bigger
than the sea area, where the default is set in SeaGenerator.java with
the comment:

/**
 * When order-by-decreasing-area we need all bit of sea to be output
consistently.
 * Unless _draworder changes things, having seaSize as BIG causes
polygons beyond the
 * coastline to be shown. To hide these and have the sea show up to the
high-tide
 * coastline, can set this to be very small instead (or use
_draworder).
 * 
 * mkgmap:drawLevel can be used to override this value in the style -
the default style has:
 * natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2
} [0x32 resolution 10]
 * which is equivalent to Long.MAX_VALUE-2.
 */
private static final long seaSize = Long.MAX_VALUE-2; // sea is BIG

I don't think having method just used by addBackground adds anything to
clarity. I could put a constant with MAX_VALUE-1 and comment into
MapperBasedMapDataSource instead if you'd prefer

Regards
Ticker

On Tue, 2018-11-06 at 00:16 -0600, Gerd Petermann wrote:
> Hi Ticker,
> 
> Ticker Berkin wrote
> > Does anyone know if it would be possible to change mkgmap to allow 
> > this? 
> 
> Not sure if this is what you want, did you try default_name?
> See e.g.
> amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency
> Phone']
> 
> I don't understand the comment in the patch:
>   background.setFullArea(Long.MAX_VALUE-1); // cf:
> SeaGenerator.java:
> seaSize 
> Wouldn't it be better to have a method named something like
> setAreaSizeToMax() ?
> 
> Gerd
> 
> 
> 
> --
> Sent from: 
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> 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] New branch for default typ file

2018-11-05 Thread Gerd Petermann

Hi Ticker,

Ticker Berkin wrote
> Does anyone know if it would be possible to change mkgmap to allow 
> this? 

Not sure if this is what you want, did you try default_name?
See e.g.
amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency
Phone']

I don't understand the comment in the patch:
background.setFullArea(Long.MAX_VALUE-1); // cf: 
SeaGenerator.java:
seaSize 
Wouldn't it be better to have a method named something like
setAreaSizeToMax() ?

Gerd



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] New branch for default typ file

2018-11-05 Thread Ticker Berkin

Hi all

Some comments on this and other requests/ideas relating to TYP file.

Beware of moving the test for building=* up in the file - there might
be other, more significant, tags that won't be triggered

My Garmin device doesn't show polygons with type > 0x5f, lines > 0x3d, points > 
0x72. I haven't tested the behaviour with a TYP file

I feel that the default style and associated TYP file should not use
extended types, and stick as far as possible to well known Garmin
meanings for type. A couple of extended types have crept into the
default style recently.

However, some of the Garmin types are overloaded with slightly
different OSM meanings and could be spread out over unused types. eg
polygon 0x17 is used for common, garden, park, playground,
square/plaza, greenfield, meadow, grass, village_green but there are
unused types that look similar (0x14-16, 0x1e-20)

Having change some of these mappings for my system, I'd like to be able
to name them correctly in the TYP file but not change any other aspect
of their representation from the device default. mkgmap (and possibly
the TYP format) doesn't allow just:
;
[_polygon]
Type=0x1b
String=Farm
[end]
;
Does anyone know if it would be possible to change mkgmap to allow
this? It is possible to change the representation but not supply the
string and the device shows it's inbuilt title.

Concerning language/translation, there should always be a default
language translation (American-english?), followed by common language
differences, eg
;
[_polygon]
Type=0x25
String=Square
String1=0x01,Place
String1=0x02,German
for this
String1=0x05,Piazza
String1=0x08,Plaza
Xpm=...
...

Another TYP usage is to have transparent polygons showing counties,
small island name etc, such that hovering over them gives useful
information. Again, the TYP compiler won't allow a transparent block
colour, but would be nice to be able to say:
;
[_polygon]
Type=0x58
String=County
Xpm="0 0 1 0"
"a c none"
[end]
;
It is possible to get round this by having a bit-map with 2 colours and
not using the non-transparent one. Another way of getting a similar
effect is to reduce the [_drawOrder] for this type, but this is
incorrect with transparent maps.

On the subject of _drawOrder, I use --order-by-decreasing-area and have
all polygons from 0x01 to 0x5f to set to the same level except 0x4b
(map background). I have attached a simple patch that stops this being
a special case by causing the background to be written before the Sea.
@gerd - can you apply - thanks.

I haven't been through all of Joris's document in detail and will
probably have more comments

I also have lots of minor changes to the default style that shouldn't
be controversial and will post this later

Regards
Ticker

On Tue, 2018-10-30 at 10:00 +, Gerd Petermann wrote:
> Hi all, 
> 
> I've created a new branch now with changes proposed by Joris. I hope
> this helps bringing this forward.
> Attached is a document from Joris. 
> 
> Gerd
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java	(revision 4247)
+++ src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java	(working copy)
@@ -108,6 +108,7 @@
 		background.setPoints(mapper.getBounds().toCoords());
 		background.setType(0x4b); // background type
 		background.setMinResolution(0); // On all levels
+		background.setFullArea(Long.MAX_VALUE-1); // cf: SeaGenerator.java: seaSize

 		mapper.addShape(background);
 	}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] New branch for default typ file

2018-10-30 Thread Gerd Petermann

Hi all, 

I've created a new branch now with changes proposed by Joris. I hope this helps 
bringing this forward.
Attached is a document from Joris. 

Gerd

Proposed changes default-style.docx
Description: Proposed changes default-style.docx
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

52 matches

Mail list logo