New branch for default typ file

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

New branch for default typ file

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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Proposed changes default-style.docx (22K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

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 +0000, 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
> [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

backgroundArea.patch (820 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

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).
 * <p>
 * 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
> [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: New branch for default typ file

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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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).
 * <p>
 * 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
> [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: New branch for default typ file

AlaskaDave
"+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 <[hidden email]> 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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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).
 * <p>
 * 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
> [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


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

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

Re: New branch for default typ file

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 <
> [hidden email]> 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 <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > 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).
> >  * <p>
> >  * 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
> > > [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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Ticker Berkin
In reply to this post by Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

TYPs.patch (4K) Download Attachment
sameOrder.txt (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Greg Troxel-2

Ticker Berkin <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

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 <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Gerd Petermann
In reply to this post by Ticker Berkin
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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

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 +0000, 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 <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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
> [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: New branch for default typ file

Gerd Petermann
Hi Ticker,

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

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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 +0000, 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 <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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
> [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: New branch for default typ file

Ticker Berkin
Hi Gerd

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

Ticker


On Tue, 2018-11-27 at 09:25 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> okay, see
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4258
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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 +0000, 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 <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > 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
> > [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: New branch for default typ file

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 <[hidden email]>
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 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> okay, see
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4258
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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 +0000, 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 <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > 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
> > [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: New branch for default typ file

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 +0000, 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 <[hidden email]>
> 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 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > okay, see
> > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=425
> > 8
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > 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 +0000, 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 <[hidden email]> im
> > > Auftrag
> > > von Ticker Berkin <[hidden email]>
> > > 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
> > > [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: New branch for default typ file

Greg Troxel-2


Ticker Berkin <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Ben Konrath
Hi Greg,

On Tue, 27 Nov 2018 at 18:21, Greg Troxel <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Ticker Berkin
I just generate an XML file with negative ids like:

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="makePostcodeOSM.py">
 <node lat="50.9070538066" lon="-1.39997565144" id="-999999">
  <tag k="postcode" v="SO14 0AA" />
 </node>
 <node lat="50.9071275658" lon="-1.39858089334" id="-999998">
  <tag k="postcode" v="SO14 0AB" />
 </node>
...
</osm>

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 <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: New branch for default typ file

Greg Troxel-2
In reply to this post by Ben Konrath
Ben Konrath <[hidden email]> 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
12