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] default style improvements

2018-11-19 Thread 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
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] Add a POI to the start of a relation (route:mtb)

2018-11-19 Thread Gerd Petermann 
Hi Andreas,

I assume you don't plan to implement that on your own and provide a patch?
I'll have a look this week...

Gerd


Von: mkgmap-dev  im Auftrag von 
andreas.schmidt.hetschb...@t-online.de 
Gesendet: Montag, 19. November 2018 09:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)

Hi Gerd,
 you got it.
 1-2) I see these Problems also. But there are at least partial goals one could 
achieve even if the route is incomplete or not sorted:

  *   One can search for MTB-Routes as POIs (taking into account that the POI 
could be shown SOMEwhere on the route)

  *   Obtain all the data which is avaiable on OSM About the route (like 
ascent/distance, Operator, Website )
3) At least the goals as in 1-2 will be reached, in addition mkgmap could check 
role = Forward/backward to be sure if the end or the beginning of the way is 
the first node. (if it is way).
 Andreas
Gesendet von Mail für Windows 10

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

Re: [mkgmap-dev] Add a POI to the start of a relation (route:mtb)

2018-11-19 Thread andreas . schmidt . hetschbach 
Hi Gerd,
 you got it. 
 1-2) I see these Problems also. But there are at least partial goals one could 
achieve even if the route is incomplete or not sorted:
• One can search for MTB-Routes as POIs (taking into account that the POI could 
be shown SOMEwhere on the route)
• Obtain all the data which is avaiable on OSM About the route (like 
ascent/distance, Operator, Website )
3) At least the goals as in 1-2 will be reached, in addition mkgmap could check 
role = Forward/backward to be sure if the end or the beginning of the way is 
the first node. (if it is way).
 Andreas 
Gesendet von Mail für Windows 10

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