Aan: Development list for mkgmap
Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt
to the current default style. Next week I plan to go through
"20191209 mapnik update.pdf" and
Hi Randolph
This topic should probably become a new thread.
You shouldn't confuse the encoding of the java source text (rules
determined by the java language) with how a java program reads a text
file into its internal character format (however the programmers want
to do it, but the java library
hat type to get the wanted
destination hint. In that case we don't have to care about rendering.
Gerd
Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for defau
Hi all
As suggested elsewhere, bays should be rendered as transparent and only
generated if named. I use this method for other areas and find it very
useful.
I don't understand what is being suggested by the references to POI in
this context; They are findable as Geographic > Water Features > Ba
: Development list for mkgmap; Pinns UK
Betreff: Re: [mkgmap-dev] New branch for default typ file
Dear Sirs:
Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8)
as that works in iOS and Unix.
Randolph J. Herber
On 12/14/2019 9:53 AM, Pinns UK wrote:
> Hi Gerd
>
> The r
-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html
I'll try to code a fix now.
Gerd
Von: mkgmap-dev im Auftrag
von Ticker Berkin
Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-de
Gerd
Petermann
Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Ticker & Joris
I'd also prefer to maintain it as txt file, else I'd prefer to remove the file
and add a simple
the wanted
destination hint. In that case we don't have to care about rendering.
Gerd
Von: Joris Bo
Gesendet: Montag, 9. Dezember 2019 20:45
An: Development list for mkgmap; Gerd Petermann
Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think a
nd-special-chars-tp5932059p5932168.html
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Samstag, 14. Dezember 2019 15:21
An: Ticker Berkin; Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Ticker & Joris
I
-special-chars-tp5932059p5932172.html
I'll try to code a fix now.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Samstag, 14. Dezember 2019 10:41
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Joris &
__
> Von: Joris Bo
> Gesendet: Montag, 9. Dezember 2019 20:45
> An: Development list for mkgmap; Gerd Petermann
> Betreff: RE: [mkgmap-dev] New branch for default typ file
>
> Hi All,
>
> I don't think any changes needed in mkgmap itself. When the
s.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the
polygons
using the following format
Type=0x type number , draworder
It is good pr
Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or
natur
_
Von: Pinns UK
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
> Hi Nick,
>
> my understanding is that you a
Hi,
see example of natural=bay, which can give problems:
https://www.openstreetmap.org/relation/9408222
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Petermann; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not
Ideally,mkgmap checks if islands are in a 'bay' area
In my area we
es and typ I have never encountered such a 'bay'
> > problem
> >
> > Kind regards,
> > Joris
> >
> >
> > -Oorspronkelijk bericht-
> > Van: mkgmap-dev Namens
> > Gerd
> > Petermann
> > Verzonden: zondag 8 decemb
ap-dev im Auftrag von Pinns
> UK
> Gesendet: Montag, 9. Dezember 2019 15:42
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Andrzej is correct about how transparency is defined
>
> Garmin regards all polygons with tra
p I have never encountered such a 'bay'
> problem
>
> Kind regards,
> Joris
>
>
> -Oorspronkelijk bericht-
> Van: mkgmap-dev Namens Gerd
> Petermann
> Verzonden: zondag 8 december 2019 10:50
> Aan: DD8KQ ; mkgmap-dev@lists.mkgmap.org.uk
> On
kgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore
require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then
: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore
require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second &#
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore
require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is
still needed
Xpm="32 32 2 1"
"0
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But
looking at TypViewer output, I guess that transparent pixels are defined
with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could b
r in my styles and typ I have never encountered such a 'bay' problem
Kind regards,
Joris
-Oorspronkelijk bericht-
Van: mkgmap-dev Namens Gerd Petermann
Verzonden: zondag 8 december 2019 10:50
Aan: DD8KQ ; mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for
ftrag von Andrzej
Popowski
Gesendet: Sonntag, 8. Dezember 2019 23:44
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd,
natural=bay is not a water but a name for an area. It can cover islands too:
https://wiki.openstreetmap.org/wiki/Tag:natura
Hi Gerd,
natural=bay is not a water but a name for an area. It can cover islands too:
https://wiki.openstreetmap.org/wiki/Tag:natural=bay
IMHO transparent polygon is a good solution.
--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@list
rg.uk
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
i can remember that some time ago i stumbled also about this fact and i
asked the community. I don't remember who gave me the hint but after
i've changed the colour into some kind of blue for polygon type 0x3d, it
c
e the same as 0x32.
Gerd
Von: mkgmap-dev im Auftrag von Ticker Berkin
Gesendet: Donnerstag, 5. Dezember 2019 11:20
An: mkgmap development
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from
branches/default-typ/res
t;
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 5. Dezember 2019 11:20
> An: mkgmap development
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> I
as 0x32.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 5. Dezember 2019 11:20
An: mkgmap development
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from
branches/default-typ/resources/typ-files were
Hi Gerd
I think it would be good if the files from branches/default
-typ/resources/typ-files were put into trunk and, in build.xml, after:
this is added:
Ticker
_
Greg Troxel-2 wrote
> I don't think it's off topic at all.
Well, I think it would be better to open a new thread, because this one is
about a default typ file for mkgmap.
Greg Troxel-2 wrote
>> project to add some non-OSM data to my maps but I thought the only way to
>> do this was with osmosis,
Ben Konrath writes:
> I realize this is a bit off-topic on this thread but I'm curious to know
> your process for combing non-OSM data with splitter. I was just starting a
I don't think it's off topic at all.
> project to add some non-OSM data to my maps but I thought the only way to
> do this
I just generate an XML file with negative ids like:
...
and give as a parameter to splitter after the main osm.pbf map data
file.
Ticker
On Sun, 2018-12-02 at 16:02 +0100, Ben Konrath wrote:
> Hi Greg,
>
> On Tue, 27 Nov 2018 at 18:21, Greg Troxel wrote:
> > Semi-related, I
Hi Greg,
On Tue, 27 Nov 2018 at 18:21, Greg Troxel wrote:
> Semi-related, I am carrying a diff to render "boundary=parcel"; I
> include state parcel boundary data with osm data in splitter. I have no
> idea how many others want this, but given that parcel data is not in
> OSM, merging while map
Ticker Berkin writes:
(I'm a long-term mkgamp user, sometimes contributor, mostly lurking
lately.)
> I don't think having:
>
> BRANCH: default-typ
>
> makes sense because I don't think there will ever be a single, ideal
> file. So better to accept now that it will be a collection of files,
>
ote:
> > Hi Ticker,
> >
> > okay, see
> > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=425
> > 8
> >
> > Gerd
> >
> > ________________________
> > Von: mkgmap-dev im Auftrag
> > von Ticker Be
nk we need another branch or do you think that the exising one makes
no sense?
Gerd
Von: Ticker Berkin
Gesendet: Dienstag, 27. November 2018 11:37
An: Gerd Petermann; Development list for mkgmap
Betreff: Re: AW: [mkgmap-dev] New branch for default typ f
__
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 27. November 2018 09:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> Happy with either, but slightly prefer typ-file
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 19. November 2018 13:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi
>
> I suspect there will be a few TYP files for diffe
on: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 19. November 2018 13:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi
>
> I suspect there will be a few TYP files for different usages.
>
&g
im Auftrag von Ticker
Berkin
Gesendet: Montag, 19. November 2018 13:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they ar
Hi Gerd
Should we start dist/examples/TYPs/* as per my email on 19-Nov?
Ticker
On Mon, 2018-11-19 at 12:44 -0500, Greg Troxel wrote:
> Ticker Berkin writes:
>
> > I suspect there will be a few TYP files for different usages.
>
> perhaps, but as I understand it there can be a lot of
> includ
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.
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 th
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Dienstag, 6. November 2018 10:43
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] New branch for default typ file
> >
> > Hi Gerd
> >
> &g
nderstand for a
> non-native speaker who grew up before SMS and Twitter and just learned to
> use smileys ;-)
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Dienstag, 6. November 2018 10:43
> An: Dev
: 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 ins
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=gar
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
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 have
Hi all,
I've created a new branch now with changes proposed by Joris. I hope this helps
bringing this forward.
Attached is a document from Joris.
Gerd
Proposed changes default-style.docx
Description: Proposed changes default-style.docx
___
mkgmap-de
52 matches
Mail list logo
