default style improvements

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

default style improvements

Ticker Berkin
Hi

I'd like to make quite a few changes and improvements to the default
style.

Some of these should be non-contentious:

The first change I propose is to make the layout consistent and clearer
and I've attached a patch to do this for the points/lines/polygons
files. The only change here is white-space (blanks, tabs, new-lines),
no other characters have been changed.

I've used:
 $ java ...  uk.me.parabola.mkgmap.osmstyle.StyleImpl pathTo/default
to check there are no semantic changes, but this program fails to dump
the <finalize> section, so I've checked these very carefully via other
methods.

Next changes I am thinking of are:

Simple layout where character changes are involved

Provide more information on unnamed objects where a good garmin mapping
hasn't been found, eg, after all the shop=known ... lines there is a
mop-up:
  shop=* & shop!=no & shop!=none [0x2e0c resolution 24]
changing this to:
  shop=* & shop!=no & shop!=none {add name='${shop|subst:"_=> "}'}
                                 [0x2e0c resolution 24]
will name unnamed shops with the value of the shop tag.
There are about 15 sections that benefit from this.

Add more commonly used tag-values, eg:
 tourism=bed_and_breakfast [0x2b02 resolution 24]
and other mop-ups

I think these sort of changes should be applied to the trunk

After this, the changes I'm thinking of will require more discussion.

Regards
Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

defaultStyleTidy1.patch (42K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Gerd Petermann
Hi Ticker,

reg. the curly brackets in the barrier section I must say that i don't like the old style
as well as your new one ;-)
I would put the closing bracket without indention:
barrier=bollard | barrier=cycle_barrier {
    add mkgmap:bicycle=yes;
    add mkgmap:foot=yes;
    addaccess no;
    set mkgmap:road-speed=1;
}

Besides that the changes are OK for me.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 12. November 2018 13:03
An: mkgmap development
Betreff: [mkgmap-dev] default style improvements

Hi

I'd like to make quite a few changes and improvements to the default
style.

Some of these should be non-contentious:

The first change I propose is to make the layout consistent and clearer
and I've attached a patch to do this for the points/lines/polygons
files. The only change here is white-space (blanks, tabs, new-lines),
no other characters have been changed.

I've used:
 $ java ...  uk.me.parabola.mkgmap.osmstyle.StyleImpl pathTo/default
to check there are no semantic changes, but this program fails to dump
the <finalize> section, so I've checked these very carefully via other
methods.

Next changes I am thinking of are:

Simple layout where character changes are involved

Provide more information on unnamed objects where a good garmin mapping
hasn't been found, eg, after all the shop=known ... lines there is a
mop-up:
  shop=* & shop!=no & shop!=none [0x2e0c resolution 24]
changing this to:
  shop=* & shop!=no & shop!=none {add name='${shop|subst:"_=> "}'}
                                 [0x2e0c resolution 24]
will name unnamed shops with the value of the shop tag.
There are about 15 sections that benefit from this.

Add more commonly used tag-values, eg:
 tourism=bed_and_breakfast [0x2b02 resolution 24]
and other mop-ups

I think these sort of changes should be applied to the trunk

After this, the changes I'm thinking of will require more discussion.

Regards
Ticker
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
Hi Gerd

I thought of doing it as you suggest but then it's wrong when there
is a [type ...] part, which I also want indented, ie

some condition {
   action1;
   action2;
   ...
   } [0x01 resolution 20]

not that I can find any examples. And I feel that its clearer that all
parts of a continuation of a rule are indented.

Ticker

On Mon, 2018-11-12 at 14:55 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> reg. the curly brackets in the barrier section I must say that i
> don't like the old style
> as well as your new one ;-)
> I would put the closing bracket without indention:
> barrier=bollard | barrier=cycle_barrier {
>     add mkgmap:bicycle=yes;
>     add mkgmap:foot=yes;
>     addaccess no;
>     set mkgmap:road-speed=1;
> }
>
> Besides that the changes are OK for me.
>
> Gerd

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Gerd Petermann
Hi Ticker,

OK, got your point. If no one complains I'll commit that patch on thursday.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 12. November 2018 16:19
An: mkgmap development
Betreff: Re: [mkgmap-dev] default style improvements

Hi Gerd

I thought of doing it as you suggest but then it's wrong when there
is a [type ...] part, which I also want indented, ie

some condition {
   action1;
   action2;
   ...
   } [0x01 resolution 20]

not that I can find any examples. And I feel that its clearer that all
parts of a continuation of a rule are indented.

Ticker

On Mon, 2018-11-12 at 14:55 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> reg. the curly brackets in the barrier section I must say that i
> don't like the old style
> as well as your new one ;-)
> I would put the closing bracket without indention:
> barrier=bollard | barrier=cycle_barrier {
>     add mkgmap:bicycle=yes;
>     add mkgmap:foot=yes;
>     addaccess no;
>     set mkgmap:road-speed=1;
> }
>
> Besides that the changes are OK for me.
>
> Gerd

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
In reply to this post by Ticker Berkin
All

I'd like any thoughts on changing and introducing new element TYPE
numbers for various OSM objects. I propose:

POINTS:

Use 0x2f0c instead of 0x4e00 for amenity=toilet always.
0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info".

Use 0x3200 instead of 0x660f for barrier=bollard barrier=...etc.
0x660f is "Land Features:Pillar" and so they all show in FIND, making
searching for nearby features less useful. 0x3200 is a small point,
that can be labeled with the type of barrier.

Use 0x6505 instead of 0x6603 for water=canal, lock
0x6603 is "Land Features:Basin"; 0x6505 is "Water Features:Canal"


LINES:

Use 0x11 instead of 0x07 for highway=cycleway
Suggested by Joris Bo. 0x07 is Alley and is already used for
highway=bridleway, service, mop-up

Use 0x13 for highway=raceway
This isn't handled at the moment and falls into the highway mop-up

Use 0x17 for various linear barriers and also man_made=breakwater

Use 0x1a for car ferries, 0x1b for other ferries
At the moment 0x1b is used for all ferries

Use 0x26 instead of 0x10a02 for intermittent steam & drain

@gerd - slightly concerned about func in mkgmap/reader/osm/GType.java:
 public static boolean isSpecialRoutableLineType(int type){
   return type >= 0x01 && type <= 0x13 || type == 0x16 || type == 0x1b;


POLYGONS:

Use 0x02 for place=suburb

Use 0x0f instead of 0x0c for landuse=commercial

Use 0x10 only for landuse=residential
Currently also used for farmyard

Use 0x11 instead of 0x04 for military=danger_area
This often covers a large area of other mixed use, and rendering it
with parts transparent is much more informative

Use 0x12 instead of 0x08 for landuse=retail

Use 0x13 only for building=*
Currently also used for amenity=* and man_made=...

Type 0x17, which shows as "Park" in green, is currently used for these
OSM objects:
park,playground,common,garden,greenfield,meadow,grass,village_green,squ
are/plaza
Keep this mapping for leisure=park, playground
Use 0x15 for landuse=village_green
Use 0x1c for landuse=meadow, grass, greenfield, farmland
Use 0x1d for leisure=common
Use 0x20 for leisure=garden
Use 0x25 for square/plaza

Use 0x1b instead of 0x10 for landuse=farmyard
Use 0x1b instead of 0x4e for landuse=farm

Use 0x21 instead of 0x1f for tourism=...

Use 0x22 instead of 0x1e for historic=...

Use 0x23 instead of 0x13 for mop-up amenity=*

Use 0x24 instead of 0x13 for man_made=...

Use 0x3b for mop-up waterway=*

Use 0x41 instead of 0x3c for small lakes

Use 0x48 for water=canal

Use 0x4c for water=lock
Use 0x4c for dock=drydock
This is "Intermittant Water"

Use 0x53 for natural=beach, sand
Suggested by Nick / Minko 27Sep18

Use 0x53 instead of 0x51 for natural=mud

Use 0x56 instead of 0x53 for small named islands/islets
And render as transparent/invisible

Use 0x58 for adminin boundary=ceremonial, eg UK counties
And render as transparent/invisible

Thanks
Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Joris Bo
Hello Ticker and All

In general  i 'm fine with the suggestions for new elements .
From a default style point of view I think we better not use 'mop-up' features at all but only use strictly defined elements.

Mop up rules and [tag = *] will always somewhere create unexpected behaviour (popup of fixme bugs, strange lines, rarely used elements) where defined elements will give us a more maintainable control over future change requests without disappointing current users who at the moment rely on the unpredictable mop-up rules.

Just let me know what the final style will be and I'll reflect these changes against the TYP-file proposal.

Kind regards,
Joris





-----Oorspronkelijk bericht-----
Van: mkgmap-dev <[hidden email]> Namens Ticker Berkin
Verzonden: dinsdag 13 november 2018 18:26
Aan: Development list for mkgmap <[hidden email]>
Onderwerp: Re: [mkgmap-dev] default style improvements

All

I'd like any thoughts on changing and introducing new element TYPE numbers for various OSM objects. I propose:

POINTS:

Use 0x2f0c instead of 0x4e00 for amenity=toilet always.
0x4e00 isn't findable. 0x2f0c is "Other:Rest Area/Tourist Info".

Use 0x3200 instead of 0x660f for barrier=bollard barrier=...etc.
0x660f is "Land Features:Pillar" and so they all show in FIND, making searching for nearby features less useful. 0x3200 is a small point, that can be labeled with the type of barrier.

Use 0x6505 instead of 0x6603 for water=canal, lock
0x6603 is "Land Features:Basin"; 0x6505 is "Water Features:Canal"


LINES:

Use 0x11 instead of 0x07 for highway=cycleway Suggested by Joris Bo. 0x07 is Alley and is already used for highway=bridleway, service, mop-up

Use 0x13 for highway=raceway
This isn't handled at the moment and falls into the highway mop-up

Use 0x17 for various linear barriers and also man_made=breakwater

Use 0x1a for car ferries, 0x1b for other ferries At the moment 0x1b is used for all ferries

Use 0x26 instead of 0x10a02 for intermittent steam & drain

@gerd - slightly concerned about func in mkgmap/reader/osm/GType.java:
 public static boolean isSpecialRoutableLineType(int type){
   return type >= 0x01 && type <= 0x13 || type == 0x16 || type == 0x1b;


POLYGONS:

Use 0x02 for place=suburb

Use 0x0f instead of 0x0c for landuse=commercial

Use 0x10 only for landuse=residential
Currently also used for farmyard

Use 0x11 instead of 0x04 for military=danger_area This often covers a large area of other mixed use, and rendering it with parts transparent is much more informative

Use 0x12 instead of 0x08 for landuse=retail

Use 0x13 only for building=*
Currently also used for amenity=* and man_made=...

Type 0x17, which shows as "Park" in green, is currently used for these OSM objects:
park,playground,common,garden,greenfield,meadow,grass,village_green,squ
are/plaza
Keep this mapping for leisure=park, playground Use 0x15 for landuse=village_green Use 0x1c for landuse=meadow, grass, greenfield, farmland Use 0x1d for leisure=common Use 0x20 for leisure=garden Use 0x25 for square/plaza

Use 0x1b instead of 0x10 for landuse=farmyard Use 0x1b instead of 0x4e for landuse=farm

Use 0x21 instead of 0x1f for tourism=...

Use 0x22 instead of 0x1e for historic=...

Use 0x23 instead of 0x13 for mop-up amenity=*

Use 0x24 instead of 0x13 for man_made=...

Use 0x3b for mop-up waterway=*

Use 0x41 instead of 0x3c for small lakes

Use 0x48 for water=canal

Use 0x4c for water=lock
Use 0x4c for dock=drydock
This is "Intermittant Water"

Use 0x53 for natural=beach, sand
Suggested by Nick / Minko 27Sep18

Use 0x53 instead of 0x51 for natural=mud

Use 0x56 instead of 0x53 for small named islands/islets And render as transparent/invisible

Use 0x58 for adminin boundary=ceremonial, eg UK counties And render as transparent/invisible

Thanks
Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
In reply to this post by Ticker Berkin
Hi

This is the next batch of default style changes.

I don't think anything here is contention. The changes are:

A few minor white-space changes that I missed in the previous batch.

Remove unnecessary () in conditions

Add tmp: prefix to tags that are just used by the style logic, so it is
clear they don't have special meaning to the mkgmap code and don't
overwrite osm tags. There are still a few tags created in relation that
I think should be renamed (mkgmap:boundary_name, mkgmap:relref,
mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute,
mkgmap:us_state) but I won't do this yet.

Ferries default to mkgmap:toll=yes

add a few new points:
 amenity=charging_station
 amenity=grave_yard, crematorium
 amenity=post_box
 amenity=recycling
 amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood
 amenity=swimming_pool
 tourism=bed_and_breakfast

add default name, either as [default_name ...] or {add name=...} to:
 amenity=fast_food
 amenity=prison
 amenity=restaurant
 amenity=playground
 amenity=recreation_ground
 shop=*
 tourism=*
 man_made=*

Improve Embassy name

Ticker


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

defaultStyleTidy2.patch (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
Hi Gerd, Andrzej & maybe others

I'm trying to understand a couple of bits of logic in the default
style:

'relation' sets mkgmap:us_interstate, mkgmap:us_usroute and
mkgmap:us_state but I can't find any use of these tags. It looks like
these were introduced in revision 3979, 5-Aug-2017 following
discussions on 27-Jul-2017 "Strange long distance routes on NĂ¼vi"

The other one is the use of cityxx / continue with_actions in the
'points' file. All the place=city/town/village/suburb/hamlet (&
island/islet) have logic explicit to prevent re-triggering once an
earlier rule has fired, but after these 'place=', I can't see any other
rule that would be relevant. I'd expect just removing & cityxx!=yes,
{set cityxx=yes} and "with_actions" to have the same effect and be the
normal way to express this.

Ticker





_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

popej
Hi Ticker,

I guess variables like mkgmap:us_interstate come from my style. I use
them for shields with road reference numbers. There are dedicated
shields for US maps and standard shields for other countries. These
variables allows to create single style for both cases.

This is an example from my style, file "lines":
# Set highway names to include the reference if there is one
highway=motorway                    & mkgmap:us_interstate=*    {name
'${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:us_usroute=*       {name
'${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:us_state=*         {name
'${mkgmap:us_state|highway-symbol:round:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2=USA   {name
'${name}' | '${ref}'; set mkgmap:refnam=yes} #disable box

highway=motorway & mkgmap:refnam!=* & mkgmap:admin_level2!=USA  {name
'${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set
mkgmap:refnam=yes}
highway=trunk    & mkgmap:refnam!=* & mkgmap:admin_level2!=USA  {name
'${ref|highway-symbol:hbox:12}'; addlabel '${name|not-equal:ref}'; set
mkgmap:refnam=yes}

highway=* & mkgmap:refnam!=* & mkgmap:us_interstate=*    {name
'${mkgmap:us_interstate|highway-symbol:interstate:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:us_usroute=*       {name
'${mkgmap:us_usroute|highway-symbol:shield:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:us_state=*         {name
'${mkgmap:us_state|highway-symbol:round:12}'; addlabel
'${name|not-equal:ref}'; set mkgmap:refnam=yes}
highway=* & mkgmap:refnam!=* & mkgmap:admin_level2=USA   {name '${name}'
| '${ref}'; set mkgmap:refnam=yes}   #disable box

highway=primary   & mkgmap:refnam!=* & (name=* | ref=*)  {name
'${name|not-equal:ref}' | '${ref|highway-symbol:box:12}'; set
mkgmap:refnam=yes}
highway=secondary & mkgmap:refnam!=* & (name=* | ref=*)  {name
'${name|not-equal:ref}' | '${ref|highway-symbol:oval:12}'; set
mkgmap:refnam=yes}
highway=*         & mkgmap:refnam!=*                     {name '${name}'
| '${ref}'}

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
Hi Andrzej

Is this logic general enough to move into the default style?
I assume it replaces:

# Display highway shield for mayor roads if they have a ref and make
them searchable by their name
(highway=motorway | highway=trunk) & ref=* {name '${ref|highway
-symbol:hbox}'; addlabel '${name}'}
highway=primary & ref=* {name '${ref|highway-symbol:box}'; addlabel
'${name}'}
(highway=secondary | highway=tertiary) & ref=* {name '${ref|highway
-symbol:oval}'; addlabel '${name}'}

but this tests for $ref being set and also handles tertiary.

If it goes into 'default' I think we should have a different naming
convention for style working tags, eg: tmp:fast_road, tmp:refnam,
tmp:us_usroute, etc

If it doesn't go into 'default' then the bits should be removed from
'relations' (and renaming xxx:fast_road, as above)

Regards
Ticker


On Tue, 2018-11-20 at 15:15 +0100, Andrzej Popowski wrote:
> Hi Ticker,
>
> I guess variables like mkgmap:us_interstate come from my style. I use
> them for shields with road reference numbers. There are dedicated
> shields for US maps and standard shields for other countries. These
> variables allows to create single style for both cases.

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

popej
Hi Ticker,

 > Is this logic general enough to move into the default style?

This is a solution for my maps and I have tried to make it universal.
There could be other propositions, for example some people could prefer
name of the road over ref number or include name into shield (but it
doesn't look good on nuvis).

For my topo maps, I set road name on level 0 and ref number on next
levels. But this is much complicated style.

--
Best regards,
Andrzej
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
In reply to this post by Ticker Berkin
Hi Gerd

Given lack of objections to any of this, could defaultStyleTidy2.patch
be applied to trunk.

Thanks
Ticker

On Fri, 2018-11-16 at 16:56 +0000, Ticker Berkin wrote:

> Hi
>
> This is the next batch of default style changes.
>
> I don't think anything here is contention. The changes are:
>
> A few minor white-space changes that I missed in the previous batch.
>
> Remove unnecessary () in conditions
>
> Add tmp: prefix to tags that are just used by the style logic, so it
> is
> clear they don't have special meaning to the mkgmap code and don't
> overwrite osm tags. There are still a few tags created in relation
> that
> I think should be renamed (mkgmap:boundary_name, mkgmap:relref,
> mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute,
> mkgmap:us_state) but I won't do this yet.
>
> Ferries default to mkgmap:toll=yes
>
> add a few new points:
>  amenity=charging_station
>  amenity=grave_yard, crematorium
>  amenity=post_box
>  amenity=recycling
>  amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood
>  amenity=swimming_pool
>  tourism=bed_and_breakfast
>
> add default name, either as [default_name ...] or {add name=...} to:
>  amenity=fast_food
>  amenity=prison
>  amenity=restaurant
>  amenity=playground
>  amenity=recreation_ground
>  shop=*
>  tourism=*
>  man_made=*
>
> Improve Embassy name
>
> Ticker
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Gerd Petermann
Hi Ticker,

yes, your are right. I was a bit distracted because of some work for JOSM...
Committed now .

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 26. November 2018 11:15
An: [hidden email]
Betreff: Re: [mkgmap-dev] default style improvements

Hi Gerd

Given lack of objections to any of this, could defaultStyleTidy2.patch
be applied to trunk.

Thanks
Ticker

On Fri, 2018-11-16 at 16:56 +0000, Ticker Berkin wrote:

> Hi
>
> This is the next batch of default style changes.
>
> I don't think anything here is contention. The changes are:
>
> A few minor white-space changes that I missed in the previous batch.
>
> Remove unnecessary () in conditions
>
> Add tmp: prefix to tags that are just used by the style logic, so it
> is
> clear they don't have special meaning to the mkgmap code and don't
> overwrite osm tags. There are still a few tags created in relation
> that
> I think should be renamed (mkgmap:boundary_name, mkgmap:relref,
> mkgmap:fast_road, mkgmap:us_interstate, mkgmap:us_usroute,
> mkgmap:us_state) but I won't do this yet.
>
> Ferries default to mkgmap:toll=yes
>
> add a few new points:
>  amenity=charging_station
>  amenity=grave_yard, crematorium
>  amenity=post_box
>  amenity=recycling
>  amenity=restaurant, cuisine=curry, fish_and_chips, indian, seafood
>  amenity=swimming_pool
>  tourism=bed_and_breakfast
>
> add default name, either as [default_name ...] or {add name=...} to:
>  amenity=fast_food
>  amenity=prison
>  amenity=restaurant
>  amenity=playground
>  amenity=recreation_ground
>  shop=*
>  tourism=*
>  man_made=*
>
> Improve Embassy name
>
> Ticker
>
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
In reply to this post by Ticker Berkin
Hi

Here is the third batch of default style changes. Changes are:


Add GBR section to inc/access_country and tidy up the layout


LINES

A few minor layout tidy-ups

Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
and show these lines even when also a highway

Ignore more highways when abandoned/disused/demolished

Ignore more highway tags that are not suitable for routing

Convert
highway=steps/corridor/stepping_stones/elevator/escalator/platform to
footway / bicycle=no and remove later test for steps

Convert highway=crossing/virtual to path

Don't convert footway to cycleway, but more rules to convert path to
footway/cycleway/bridleway

Add footway around man_made=pier even if area=yes

Fix common bad tagging for highway= and convert to the better values

Put routable path around highway=pedestrian closed areas;
squares/plazas often don't have other routing joining all entry/exit
ways. Similarly for footway. Then continue to allow any polygon
processing

Handle some rarer highway types

Show any other water lines


POINTS

Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue
with_actions bits. This was put in as a safety measure when this block
of rules was added, see
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html
[mkgmap-dev] Adaptions in style (needed to make good use of) for
overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46
BST 2013
and has never had any effect - there are no other tags on objects with
place=city/town... that need to be rendered

Group the rules amenity=restaurant/fast_food, cuisine= to clarify,
simplify and show better how it relates Garmin "Food & Drink" search.
The only overall effect of this is that
amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
category. Add some a few more cuisines.

For leisure=* where sport might be involved, show the sport if no name
available. NB name will defaulted by the standard code in <finalize>

Show canal/lock as 0x6505 (Water Features>Canal)


POLYGONS

Show aeroway=runway/taxiway/taxilane only if marked as area=yes

Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show
at

Show place=suburb

Show highway=pedestrian as square/plaza unless explicit area=no, but,
for highway=footway, only show if explicit area=yes

Don't assume any other closed highway is parking area, just
services/rest_area

Show all historic=*

Show drydock, canal & lock differently from standard natural=water, and
use a different code for small lakes

Show any other water area

Show all man_made=* unless explicit area=no

Regards
Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

defaultStyleTidy3.patch (37K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Gerd Petermann
Hi Ticker,

I did not yet understand all changes. Can you explain why
1) highway=trail is translated to track? I would have used path.
2) rest_area is converted to a routable way?

Gerd


________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 3. Dezember 2018 16:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements

Hi

Here is the third batch of default style changes. Changes are:


Add GBR section to inc/access_country and tidy up the layout


LINES

A few minor layout tidy-ups

Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
and show these lines even when also a highway

Ignore more highways when abandoned/disused/demolished

Ignore more highway tags that are not suitable for routing

Convert
highway=steps/corridor/stepping_stones/elevator/escalator/platform to
footway / bicycle=no and remove later test for steps

Convert highway=crossing/virtual to path

Don't convert footway to cycleway, but more rules to convert path to
footway/cycleway/bridleway

Add footway around man_made=pier even if area=yes

Fix common bad tagging for highway= and convert to the better values

Put routable path around highway=pedestrian closed areas;
squares/plazas often don't have other routing joining all entry/exit
ways. Similarly for footway. Then continue to allow any polygon
processing

Handle some rarer highway types

Show any other water lines


POINTS

Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue
with_actions bits. This was put in as a safety measure when this block
of rules was added, see
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html
[mkgmap-dev] Adaptions in style (needed to make good use of) for
overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46
BST 2013
and has never had any effect - there are no other tags on objects with
place=city/town... that need to be rendered

Group the rules amenity=restaurant/fast_food, cuisine= to clarify,
simplify and show better how it relates Garmin "Food & Drink" search.
The only overall effect of this is that
amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
category. Add some a few more cuisines.

For leisure=* where sport might be involved, show the sport if no name
available. NB name will defaulted by the standard code in <finalize>

Show canal/lock as 0x6505 (Water Features>Canal)


POLYGONS

Show aeroway=runway/taxiway/taxilane only if marked as area=yes

Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show
at

Show place=suburb

Show highway=pedestrian as square/plaza unless explicit area=no, but,
for highway=footway, only show if explicit area=yes

Don't assume any other closed highway is parking area, just
services/rest_area

Show all historic=*

Show drydock, canal & lock differently from standard natural=water, and
use a different code for small lakes

Show any other water area

Show all man_made=* unless explicit area=no

Regards
Ticker
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Ticker Berkin
Hi Gerd

I had various OSM maps for Great Britain, Spain, Italy, Belgium and
Morocco of different ages and when I found a highway tag that wasn't
handled, looked at a few examples of the way/relation on OSM.

For trail, I don't think I found many examples and 'track' seemed a
reasonable option because, the example I looked at:

https://www.openstreetmap.org/way/445188184

joined to 2 other 'track's. 'path' is probably better but that there is
logic to convert 'path' to footway/cycleway/bridleway.

The rest_area example I looked at didn't have any other highway into
it, just a closed highway=rest_area with the beginning and end along
the main highway. It seemed best to make it routable so that navigation
turns into it correctly, rather than it saying a 90 degrees turn to the
center, after having gone past the entrance.

One of the maps I used was about 6 months old, and lots of the examples
of bad tagging I went looking for, I found you'd recently fixed in OSM.

Ticker


On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I did not yet understand all changes. Can you explain why
> 1) highway=trail is translated to track? I would have used path.
> 2) rest_area is converted to a routable way?
>
> Gerd
>
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Montag, 3. Dezember 2018 16:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style improvements
>
> Hi
>
> Here is the third batch of default style changes. Changes are:
>
>
> Add GBR section to inc/access_country and tidy up the layout
>
>
> LINES
>
> A few minor layout tidy-ups
>
> Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
> and show these lines even when also a highway
>
> Ignore more highways when abandoned/disused/demolished
>
> Ignore more highway tags that are not suitable for routing
>
> Convert
> highway=steps/corridor/stepping_stones/elevator/escalator/platform to
> footway / bicycle=no and remove later test for steps
>
> Convert highway=crossing/virtual to path
>
> Don't convert footway to cycleway, but more rules to convert path to
> footway/cycleway/bridleway
>
> Add footway around man_made=pier even if area=yes
>
> Fix common bad tagging for highway= and convert to the better values
>
> Put routable path around highway=pedestrian closed areas;
> squares/plazas often don't have other routing joining all entry/exit
> ways. Similarly for footway. Then continue to allow any polygon
> processing
>
> Handle some rarer highway types
>
> Show any other water lines
>
>
> POINTS
>
> Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes,
> continue
> with_actions bits. This was put in as a safety measure when this
> block
> of rules was added, see
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html
> [mkgmap-dev] Adaptions in style (needed to make good use of) for
> overview2 branch
> From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46
> BST 2013
> and has never had any effect - there are no other tags on objects
> with
> place=city/town... that need to be rendered
>
> Group the rules amenity=restaurant/fast_food, cuisine= to clarify,
> simplify and show better how it relates Garmin "Food & Drink" search.
> The only overall effect of this is that
> amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
> category. Add some a few more cuisines.
>
> For leisure=* where sport might be involved, show the sport if no
> name
> available. NB name will defaulted by the standard code in <finalize>
>
> Show canal/lock as 0x6505 (Water Features>Canal)
>
>
> POLYGONS
>
> Show aeroway=runway/taxiway/taxilane only if marked as area=yes
>
> Increase resolution that amenity=cafe/fast_food/restaurant, shop=*
> show
> at
>
> Show place=suburb
>
> Show highway=pedestrian as square/plaza unless explicit area=no, but,
> for highway=footway, only show if explicit area=yes
>
> Don't assume any other closed highway is parking area, just
> services/rest_area
>
> Show all historic=*
>
> Show drydock, canal & lock differently from standard natural=water,
> and
> use a different code for small lakes
>
> Show any other water area
>
> Show all man_made=* unless explicit area=no
>
> Regards
> Ticker
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Gerd Petermann
Hi Ticker,

I think highway=trail is often used in the USA.
When I stumbled over one it often looked like a highway=path + surface=ground.

With rest_area I see the same problem as with highway=services mentioned here:
https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618

And yes, I fixed lots of highway=footpath and other typos during the last weeks.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 4. Dezember 2018 17:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements

Hi Gerd

I had various OSM maps for Great Britain, Spain, Italy, Belgium and
Morocco of different ages and when I found a highway tag that wasn't
handled, looked at a few examples of the way/relation on OSM.

For trail, I don't think I found many examples and 'track' seemed a
reasonable option because, the example I looked at:

https://www.openstreetmap.org/way/445188184

joined to 2 other 'track's. 'path' is probably better but that there is
logic to convert 'path' to footway/cycleway/bridleway.

The rest_area example I looked at didn't have any other highway into
it, just a closed highway=rest_area with the beginning and end along
the main highway. It seemed best to make it routable so that navigation
turns into it correctly, rather than it saying a 90 degrees turn to the
center, after having gone past the entrance.

One of the maps I used was about 6 months old, and lots of the examples
of bad tagging I went looking for, I found you'd recently fixed in OSM.

Ticker


On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I did not yet understand all changes. Can you explain why
> 1) highway=trail is translated to track? I would have used path.
> 2) rest_area is converted to a routable way?
>
> Gerd
>
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Montag, 3. Dezember 2018 16:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style improvements
>
> Hi
>
> Here is the third batch of default style changes. Changes are:
>
>
> Add GBR section to inc/access_country and tidy up the layout
>
>
> LINES
>
> A few minor layout tidy-ups
>
> Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
> and show these lines even when also a highway
>
> Ignore more highways when abandoned/disused/demolished
>
> Ignore more highway tags that are not suitable for routing
>
> Convert
> highway=steps/corridor/stepping_stones/elevator/escalator/platform to
> footway / bicycle=no and remove later test for steps
>
> Convert highway=crossing/virtual to path
>
> Don't convert footway to cycleway, but more rules to convert path to
> footway/cycleway/bridleway
>
> Add footway around man_made=pier even if area=yes
>
> Fix common bad tagging for highway= and convert to the better values
>
> Put routable path around highway=pedestrian closed areas;
> squares/plazas often don't have other routing joining all entry/exit
> ways. Similarly for footway. Then continue to allow any polygon
> processing
>
> Handle some rarer highway types
>
> Show any other water lines
>
>
> POINTS
>
> Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes,
> continue
> with_actions bits. This was put in as a safety measure when this
> block
> of rules was added, see
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html
> [mkgmap-dev] Adaptions in style (needed to make good use of) for
> overview2 branch
> From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46
> BST 2013
> and has never had any effect - there are no other tags on objects
> with
> place=city/town... that need to be rendered
>
> Group the rules amenity=restaurant/fast_food, cuisine= to clarify,
> simplify and show better how it relates Garmin "Food & Drink" search.
> The only overall effect of this is that
> amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
> category. Add some a few more cuisines.
>
> For leisure=* where sport might be involved, show the sport if no
> name
> available. NB name will defaulted by the standard code in <finalize>
>
> Show canal/lock as 0x6505 (Water Features>Canal)
>
>
> POLYGONS
>
> Show aeroway=runway/taxiway/taxilane only if marked as area=yes
>
> Increase resolution that amenity=cafe/fast_food/restaurant, shop=*
> show
> at
>
> Show place=suburb
>
> Show highway=pedestrian as square/plaza unless explicit area=no, but,
> for highway=footway, only show if explicit area=yes
>
> Don't assume any other closed highway is parking area, just
> services/rest_area
>
> Show all historic=*
>
> Show drydock, canal & lock differently from standard natural=water,
> and
> use a different code for small lakes
>
> Show any other water area
>
> Show all man_made=* unless explicit area=no
>
> Regards
> Ticker
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Lorenzo Mastrogiacomi
I don't think it's a good idea to add other bad highway tags to the default style. They should be fixed in osm. I would get rid of all these:

highway=minor
highway=byway
highway=driveway
highway=access
highway=footpath
highway=foot
highway=unsurfaced
highway=layby
highway=gallop


Lorenzo


Il giorno mar, 04/12/2018 alle 17.01 +0000, Gerd Petermann ha scritto:
Hi Ticker,

I think highway=trail is often used in the USA.
When I stumbled over one it often looked like a highway=path + surface=ground.

With rest_area I see the same problem as with highway=services mentioned here:
https://forum.openstreetmap.org/viewtopic.php?pid=728618#p728618


And yes, I fixed lots of highway=footpath and other typos during the last weeks.

Gerd

________________________________________
Von: mkgmap-dev <
[hidden email]
> im Auftrag von Ticker Berkin <
[hidden email]
>
Gesendet: Dienstag, 4. Dezember 2018 17:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements

Hi Gerd

I had various OSM maps for Great Britain, Spain, Italy, Belgium and
Morocco of different ages and when I found a highway tag that wasn't
handled, looked at a few examples of the way/relation on OSM.

For trail, I don't think I found many examples and 'track' seemed a
reasonable option because, the example I looked at:

https://www.openstreetmap.org/way/445188184


joined to 2 other 'track's. 'path' is probably better but that there is
logic to convert 'path' to footway/cycleway/bridleway.

The rest_area example I looked at didn't have any other highway into
it, just a closed highway=rest_area with the beginning and end along
the main highway. It seemed best to make it routable so that navigation
turns into it correctly, rather than it saying a 90 degrees turn to the
center, after having gone past the entrance.

One of the maps I used was about 6 months old, and lots of the examples
of bad tagging I went looking for, I found you'd recently fixed in OSM.

Ticker


On Tue, 2018-12-04 at 15:27 +0000, Gerd Petermann wrote:
Hi Ticker,

I did not yet understand all changes. Can you explain why
1) highway=trail is translated to track? I would have used path.
2) rest_area is converted to a routable way?

Gerd


________________________________________
Von: mkgmap-dev <
[hidden email]
> im Auftrag
von Ticker Berkin <
[hidden email]
>
Gesendet: Montag, 3. Dezember 2018 16:04
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] default style improvements

Hi

Here is the third batch of default style changes. Changes are:


Add GBR section to inc/access_country and tidy up the layout


LINES

A few minor layout tidy-ups

Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes
and show these lines even when also a highway

Ignore more highways when abandoned/disused/demolished

Ignore more highway tags that are not suitable for routing

Convert
highway=steps/corridor/stepping_stones/elevator/escalator/platform to
footway / bicycle=no and remove later test for steps

Convert highway=crossing/virtual to path

Don't convert footway to cycleway, but more rules to convert path to
footway/cycleway/bridleway

Add footway around man_made=pier even if area=yes

Fix common bad tagging for highway= and convert to the better values

Put routable path around highway=pedestrian closed areas;
squares/plazas often don't have other routing joining all entry/exit
ways. Similarly for footway. Then continue to allow any polygon
processing

Handle some rarer highway types

Show any other water lines


POINTS

Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes,
continue
with_actions bits. This was put in as a safety measure when this
block
of rules was added, see
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html

[mkgmap-dev] Adaptions in style (needed to make good use of) for
overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46
BST 2013
and has never had any effect - there are no other tags on objects
with
place=city/town... that need to be rendered

Group the rules amenity=restaurant/fast_food, cuisine= to clarify,
simplify and show better how it relates Garmin "Food & Drink" search.
The only overall effect of this is that
amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
category. Add some a few more cuisines.

For leisure=* where sport might be involved, show the sport if no
name
available. NB name will defaulted by the standard code in <finalize>

Show canal/lock as 0x6505 (Water Features>Canal)


POLYGONS

Show aeroway=runway/taxiway/taxilane only if marked as area=yes

Increase resolution that amenity=cafe/fast_food/restaurant, shop=*
show
at

Show place=suburb

Show highway=pedestrian as square/plaza unless explicit area=no, but,
for highway=footway, only show if explicit area=yes

Don't assume any other closed highway is parking area, just
services/rest_area

Show all historic=*

Show drydock, canal & lock differently from standard natural=water,
and
use a different code for small lakes

Show any other water area

Show all man_made=* unless explicit area=no

Regards
Ticker
_______________________________________________
mkgmap-dev mailing list
[hidden email]

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

_______________________________________________
mkgmap-dev mailing list
[hidden email]

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

_______________________________________________
mkgmap-dev mailing list
[hidden email]

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



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

Joris Bo
In reply to this post by Ticker Berkin
Hello

I updated a typ-file up to these changes of Ticker
Kind regards, Joris


-----Oorspronkelijk bericht-----
Van: mkgmap-dev <[hidden email]> Namens Ticker Berkin
Verzonden: maandag 3 december 2018 16:04
Aan: Development list for mkgmap <[hidden email]>
Onderwerp: Re: [mkgmap-dev] default style improvements

Hi

Here is the third batch of default style changes. Changes are:


Add GBR section to inc/access_country and tidy up the layout


LINES

A few minor layout tidy-ups

Do aeroway=runway/taxiway/taxilane as lines unless marked as area=yes and show these lines even when also a highway

Ignore more highways when abandoned/disused/demolished

Ignore more highway tags that are not suitable for routing

Convert
highway=steps/corridor/stepping_stones/elevator/escalator/platform to footway / bicycle=no and remove later test for steps

Convert highway=crossing/virtual to path

Don't convert footway to cycleway, but more rules to convert path to footway/cycleway/bridleway

Add footway around man_made=pier even if area=yes

Fix common bad tagging for highway= and convert to the better values

Put routable path around highway=pedestrian closed areas; squares/plazas often don't have other routing joining all entry/exit ways. Similarly for footway. Then continue to allow any polygon processing

Handle some rarer highway types

Show any other water lines


POINTS

Removed all the {set cityxx/tmp:city}, & cityxx/tmp:city!=yes, continue with_actions bits. This was put in as a safety measure when this block of rules was added, see http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017943.html
[mkgmap-dev] Adaptions in style (needed to make good use of) for
overview2 branch
From Felix Hartmann extremecarver at gmail.com on Tue May 7 18:44:46 BST 2013 and has never had any effect - there are no other tags on objects with place=city/town... that need to be rendered

Group the rules amenity=restaurant/fast_food, cuisine= to clarify, simplify and show better how it relates Garmin "Food & Drink" search.
The only overall effect of this is that
amenity=fast_food,cuisine=pizza/grill moves to the "Fast Food"
category. Add some a few more cuisines.

For leisure=* where sport might be involved, show the sport if no name available. NB name will defaulted by the standard code in <finalize>

Show canal/lock as 0x6505 (Water Features>Canal)


POLYGONS

Show aeroway=runway/taxiway/taxilane only if marked as area=yes

Increase resolution that amenity=cafe/fast_food/restaurant, shop=* show at

Show place=suburb

Show highway=pedestrian as square/plaza unless explicit area=no, but, for highway=footway, only show if explicit area=yes

Don't assume any other closed highway is parking area, just services/rest_area

Show all historic=*

Show drydock, canal & lock differently from standard natural=water, and use a different code for small lakes

Show any other water area

Show all man_made=* unless explicit area=no

Regards
Ticker

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

mkgmap.typ (25K) Download Attachment
mkgmap.txt (148K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: default style improvements

ligfietser
On the forum someone asked if highway=services could be added to the polygons style.

For example like in the generic new maps:
landuse=retail | highway=services [0x08 resolution 22-20]

If added, prevent that it also will be mopped up by excluding it in the lines style


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
12