New branch for default typ file
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
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
"+ve" does indeed mean positive. It's an older shorthand term sometimes used by scientists in the U.S. Dave On Wed, Nov 7, 2018 at 1:02 PM Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I think what confused me was the use of abbreviation cf (I did not know that) and that seaSize is a named constant which means it should be in upper case. See my changes in r4248. There is another confusing comment in Way.java: // this is unadulterated size, +ve if clockwise I guess that +ve means positive? This is hard to understand for a non-native speaker who grew up before SMS and Twitter and just learned to use smileys ;-)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
Hi Gerd Sorry about the various language/abbreviation issues - I'll do my best to avoid them in future. I'm happy with your modified patch for setting background / sea areas. Thanks Ticker PS - I'm well before twitter and SMS and refuse to use smilies ;) On Wed, 2018-11-07 at 14:39 +0700, Dave Swarthout wrote:
"+ve" does indeed mean positive. It's an older shorthand term sometimes used by scientists in the U.S.
Dave
On Wed, Nov 7, 2018 at 1:02 PM Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Ticker,
I think what confused me was the use of abbreviation cf (I did not know that) and that seaSize is a named constant which means it should be in upper case. See my changes in r4248. There is another confusing comment in Way.java: // this is unadulterated size, +ve if clockwise I guess that +ve means positive? This is hard to understand for a non-native speaker who grew up before SMS and Twitter and just learned to use smileys ;-)
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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.
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 <rwb-mkgmap@jagit.co.uk> 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.
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. November 2018 13:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are gathered in a directory resources/TYPs and the build process copies then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in the system at the moment.
I'd like to submit my most basic TYPfile and attach the file and patch. This, along with option --order-by-decreasing-area, has been adequate for me for a few years (but I have problems with my new Etrex 30x not showing some line types)
Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, okay, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4258 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. November 2018 13:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are gathered in a directory resources/TYPs and the build process copies then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in the system at the moment.
I'd like to submit my most basic TYPfile and attach the file and patch. This, along with option --order-by-decreasing-area, has been adequate for me for a few years (but I have problems with my new Etrex 30x not showing some line types)
Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. November 2018 13:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are gathered in a directory resources/TYPs and the build process copies then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in the system at the moment.
I'd like to submit my most basic TYPfile and attach the file and patch. This, along with option --order-by-decreasing-area, has been adequate for me for a few years (but I have problems with my new Etrex 30x not showing some line types)
Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. November 2018 13:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are gathered in a directory resources/TYPs and the build process copies then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in the system at the moment.
I'd like to submit my most basic TYPfile and attach the file and patch. This, along with option --order-by-decreasing-area, has been adequate for me for a few years (but I have problems with my new Etrex 30x not showing some line types)
Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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 <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Montag, 19. November 2018 13:07 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi
I suspect there will be a few TYP files for different usages.
I propose that they should be handled like the styles, where they are gathered in a directory resources/TYPs and the build process copies then to dist/examples/TYPs
I don't think a new branch is necessary, as there is nothing in the system at the moment.
I'd like to submit my most basic TYPfile and attach the file and patch. This, along with option --order-by-decreasing-area, has been adequate for me for a few years (but I have problems with my new Etrex 30x not showing some line types)
Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Ticker Berkin <rwb-mkgmap@jagit.co.uk> 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]
Hi Greg, On Tue, 27 Nov 2018 at 18:21, Greg Troxel <gdt@lexort.com> 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
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 <gdt@lexort.com> 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
Ben Konrath <ben@bagu.org> 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.
Greg Troxel-2 wrote
I don't think it's off topic at all.
Well, I think it would be better to open a new thread, because this one is about a default typ file for mkgmap. Greg Troxel-2 wrote
project to add some non-OSM data to my maps but I thought the only way to do this was with osmosis, combining a generated change file with the real data. Is your process documented somewhere? If not, do you mind sharing it here?
I have generated a file "lots.osm" which has parcel data as polygons with boundary=parcel tags, and just call splitter with "us-northeast-latest.osm.pbf" and "lots.osm".
My lots.osm file has negative numbers for ids. I remember using some python code to read shapefiles and write the osm file, but I no longer remember the details. There is nothing odd about the file, other than using negative ids.
With 64-bit ids, perhaps I should be picking some other private range that isn't negative. But I bet it doesn't matter as long as they are unique.
Yes, unique ids are most important, for splitter it doesn't matter if ids are positive or negative. Just make sure to avoid 0 and Long.MAX_VALUE (9223372036854775807 or 0x7fff ffff ffff ffff). In mkgmap we reserve a range of ids starting at 4611686018427387904 (0x4000 0000 0000 0000). When "keep-complete" is active only the data in the first file is kept complete, therefore later files should not contain relations. If you use a program like osmosis or osmconvert to merge the files first you should make sure that the files are sorted by type (nodes, ways, relations) and each type by id (smallest first). The files from geofabrik are sorted this way. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
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: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/> Ticker
Hi Ticker, I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/> Ticker
Hi Gerd Looking at mkgmap.txt, neither 0x32 or 0x3d have a _drawOrder and so the render priority is device specific but probably the same. So, if the same and unless --order-by-decreasing-area is specified, either could be shown on top in an apparently random way. 0x3d is given colour #F2EFE9 0x32 has: CustomColor=Day DaycustomColor:#4D80B3 Xpm="0 0 1 0" "1 c #AAD3DF" I'd avoid using transparent if possible (can only be done by creating an 'icon') but it could be changed to have the same colour as you suggest or just specifying _drawOrder. There will probably be many other cases like this where whatever is provided with mkgmap could be done differently. I don't expect any one typ-file to be definitive and for any experienced map generator to accept it fully, but rather having a set of examples, with some tailored to the default style. I doubt if anyone has created svn/branches/defaut-typ to be able to experiment and comment on these, but once some examples are commonly available, I'm sure they will be of use. An enhancement that I'd consider useful would be a way of selecting bits of typ-files from different sources. This could be by allowing a list on the command line or an 'include' command within the typ-file. Then having rules about how a duplicate object overwrites or combines with the definition so far. Ticker On Fri, 2019-12-06 at 08:17 +0000, Gerd Petermann wrote:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default -typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ##################################################### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de #####################################################
Hi typ file experts, please, can anybody post a patch to fix the mapnik.txt regarding 0x3d? I really don't understand the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von DD8KQ <dd8kq@gmx.de> Gesendet: Freitag, 6. Dezember 2019 16:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ##################################################### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de ##################################################### _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Hi Andrzej, good to see that you are still active! That was my thought as well. I just don't know how to make a typ transparent. I feel completely incapable when it comes to graphics, so I never used a typ file editor. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Sonntag, 8. Dezember 2019 23:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd, natural=bay is not a water but a name for an area. It can cover islands too: https://wiki.openstreetmap.org/wiki/Tag:natural=bay IMHO transparent polygon is a good solution. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that: " c none" where space ' ' is used for marking pixels. Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object. -- Best regard, Andrzej
Andrzej is correct about how transparency is defined Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours. The Bitmap need to be shown below the xpm If a polygon is completely transparent then a second 'dummy' colour is still needed Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end] On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
Hi, thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18] In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file Andrzej is correct about how transparency is defined Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours. The Bitmap need to be shown below the xpm If a polygon is completely transparent then a second 'dummy' colour is still needed Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end] On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not Ideally, mkgmap checks if islands are in a 'bay' area In my area we have lots of natural=bays ; fortunately they do not include islands On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nick, my understanding is that you always have another water polygon, either ocean or natural=water. Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file Hi Gerd In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not Ideally, mkgmap checks if islands are in a 'bay' area In my area we have lots of natural=bays ; fortunately they do not include islands On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes, I suppose so On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nick, I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible? Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file Hi Gerd Yes, I suppose so On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Yes, you can do that with a draw level 1 higher than sea. Draw orders are defined at the beginning of a (txt) typ file just before the polygons using the following format Type=0x type number , draworder It is good practice to sort the draworders , as that is how they appear in a typ file [_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi All, I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name. Today I spent some time testing and repairing. The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur. I did a complete recheck of the most recent default-style in: mkgmap-r4386.zip and changed de typ-file accordingly. I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured. I think it’s up to date again but some review and comments are always welcome. See typ-file in attachement, Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file Hi Gerd Yes, you can do that with a draw level 1 higher than sea. Draw orders are defined at the beginning of a (txt) typ file just before the polygons using the following format Type=0x type number , draworder It is good practice to sort the draworders , as that is how they appear in a typ file [_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris, the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file? reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering. Gerd ________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file Hi All, I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name. Today I spent some time testing and repairing. The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur. I did a complete recheck of the most recent default-style in: mkgmap-r4386.zip and changed de typ-file accordingly. I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured. I think it’s up to date again but some review and comments are always welcome. See typ-file in attachement, Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file Hi Gerd Yes, you can do that with a draw level 1 higher than sea. Draw orders are defined at the beginning of a (txt) typ file just before the polygons using the following format Type=0x type number , draworder It is good practice to sort the draworders , as that is how they appear in a typ file [_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci... I'll try to code a fix now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem" In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed? Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci... ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Ticker & Joris I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files. @Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci... I'll try to code a fix now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd The reason for suggesting unicode is that it caters for all languages, not just those specified by 1252 or 1250 or 1251 However, anyone not used to or bothered about codepages, will benefit from a mapnik.txt where the characters are 1252 compliant. I now have all my maps using cp 65001 as Basecamp/ (mapsource?) automatically selects the appropriate language depending on the user's Region settings. Nick On 14/12/2019 15:11, Gerd Petermann wrote:
Hi all,
when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting
As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem"
In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed?
Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci...
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Ticker & Joris
I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files.
@Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci... I'll try to code a fix now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed.
Regards Ticker
On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Dear Sirs: Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8) as that works in iOS and Unix. Randolph J. Herber On 12/14/2019 9:53 AM, Pinns UK wrote:
Hi Gerd
The reason for suggesting unicode is that it caters for all languages, not just those specified by 1252 or 1250 or 1251
However, anyone not used to or bothered about codepages, will benefit from a mapnik.txt where the characters are 1252 compliant.
I now have all my maps using cp 65001 as Basecamp/ (mapsource?) automatically selects the appropriate language depending on the user's Region settings.
Nick
On 14/12/2019 15:11, Gerd Petermann wrote:
Hi all,
when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting
As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem"
In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed?
Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci...
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Ticker & Joris
I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files.
@Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci...
I'll try to code a fix now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed.
Regards Ticker
On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote: > Hi Gerd, > > I use TypViewer for creating typ files and I don't know XPM > details. > But looking at TypViewer output, I guess that transparent > pixels > are defined with color like that: > > " c none" > > where space ' ' is used for marking pixels. > > Changing draw order instead of transparent graphics could be > a > solution too, but I'm not sure if covered polygon label would > remain visible. And without label, there is not much use of > this object. > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Randolph, is there anything wrong regarding unicode support in mkgmap? If yes, please post a patch or - at least - describe more details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Randolph J. Herber <army.bronze.star@gmail.com> Gesendet: Samstag, 14. Dezember 2019 18:20 An: Development list for mkgmap; Pinns UK Betreff: Re: [mkgmap-dev] New branch for default typ file Dear Sirs: Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8) as that works in iOS and Unix. Randolph J. Herber On 12/14/2019 9:53 AM, Pinns UK wrote:
Hi Gerd
The reason for suggesting unicode is that it caters for all languages, not just those specified by 1252 or 1250 or 1251
However, anyone not used to or bothered about codepages, will benefit from a mapnik.txt where the characters are 1252 compliant.
I now have all my maps using cp 65001 as Basecamp/ (mapsource?) automatically selects the appropriate language depending on the user's Region settings.
Nick
On 14/12/2019 15:11, Gerd Petermann wrote:
Hi all,
when the source for the typ file specifies a codePage which is different from the one used on the command line we see a warning WARNING: SortCode in TYP txt file different from command line setting
As an unexperienced user I would try to get rid of such a warning, maybe causing more trouble than needed. A comment in the source says "This is just a warning, not a definite problem"
In (1) Nick suggested to use unicode in the typ file, so I wonder in what situation this warning is needed?
Gerd (1) http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci...
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 14. Dezember 2019 15:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Ticker & Joris
I'd also prefer to maintain it as txt file, else I'd prefer to remove the file and add a simple hint were to find Joris files.
@Ticker: The problem mentioned here is still there. http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-speci...
I'll try to code a fix now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Samstag, 14. Dezember 2019 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed.
Regards Ticker
On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote: > Hi Gerd, > > I use TypViewer for creating typ files and I don't know XPM > details. > But looking at TypViewer output, I guess that transparent > pixels > are defined with color like that: > > " c none" > > where space ' ' is used for marking pixels. > > Changing draw order instead of transparent graphics could be > a > solution too, but I'm not sure if covered polygon label would > remain visible. And without label, there is not much use of > this object. > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Dear Sirs: Re UTF-8 Microsoft does this to handle another problem: Microsoft uses many different character set encodings (i.e., code pages, e.g., CP1252) and the BOM is used by Microsoft to indicate that the "code page" is UTF-8. Java was implemented to an older version of the Unicode standard that prohibited an UTF-8 BOM. The problem is comes from moving back and forth across that cultural divide. Yes, this is painful. A solution to the reading issue from the Java side: https://stackoverflow.com/questions/1835430/byte-order-mark-screws-up-file-r... A solution for writing a UTF-8 BOM in Java: |BufferedWriter out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(the File), StandardCharsets.UTF_8))out.write('\ufeff');| A check for execution in a Windows environment: String OS = System.getProperty("os.name").toLowerCase(); Boolean isWindows = OS.indexOf("win") >= 0; Perhaps, on output write the BOM in a Windows environment and use the BOM optional on input. http://www.unicode.org/faq/utf_bom.html Q: What are some of the differences between the UTFs? A: The following table summarizes some of the properties of each of the UTFs. Name UTF-8 UTF-16 UTF-16BE UTF-16LE UTF-32 UTF-32BE UTF-32LE Smallest code point 0000 0000 0000 0000 0000 0000 0000 Largest code point 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF Code unit size 8 bits 16 bits 16 bits 16 bits 32 bits 32 bits 32 bits Byte order N/A <BOM> big-endian little-endian <BOM> big-endian little-endian Fewest bytes per character 1 2 2 2 4 4 4 Most bytes per character 4 4 4 4 4 4 4 In the table <BOM> indicates that the byte order is determined by a byte order mark, if present at the beginning of the data stream, otherwise it is big-endian. http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf Table 2-4. The Seven Unicode Encoding Schemes Encoding Scheme Endian Order BOM Allowed? UTF-8 N/A yes The remainder of the table omitted. https://docs.microsoft.com/en-us/windows/win32/intl/using-byte-order-marks Using Byte Order Marks * 05/30/2018 * 2 minutes to read * o o <https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Intl/using-byte-order-marks.md> Always prefix a Unicode plain text file with a byte order mark, which informs an application receiving the file that the file is byte-ordered. Available byte order marks are listed in the following table. Because Unicode plain text is a sequence of 16-bit code values, it is sensitive to the byte ordering used when the text is written. Note A byte order mark is not a control character that selects the byte order of the text. Byte order mark Description EF BB BF UTF-8 FF FE UTF-16, little endian FE FF UTF-16, big endian FF FE 00 00 UTF-32, little endian 00 00 FE FF UTF-32, big-endian On 12/14/2019 3:41 AM, Ticker Berkin wrote:
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed.
Regards Ticker
On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Dear Sirs: There has been a thread of discussion of whether there should be a /Beginning Of Message/ /(BOM)/ at the beginning of a UTF-8 file. This discussion is complicated by the fact that some of the developers work on Unix, Linux, BSD, iOS, Solaris and Windows. These operating systems have UTF-8 handling libraries written at different times and to different Unicode standards. Originally the Unicode standard said that UTF-8 should *not* have a BOM character at the beginning of a file. Later Unicode changed the standard to a BOM is permissible, not required and not recommended. Microsoft added a BOM to the beginning of UTF-8 files before doing so was permissible to ease the problem of recognizing a UTF-8 file. This broke the other operating systems' handling of UTF-8. Microsoft petitioned for the permissibility of a BOM to avoid changing their file handling. At this time, I believe at all programs should use Unicode and not Microsoft code pages. I have had problems with Microsoft code pages since MSDOS days. Splitter and mkgmap are written in Java. Java still follows the original Unicode standard of no BOM at the beginning of a UTF-8 text file. This is a "not to fixed" situation per the Java language developers. This situation results in problems with Java, particularly in a Microsoft Windows environment, The code fragments below provide Java solutions to writing a BOM at the beginning of a UTF-8 text files so that Microsoft native text editors can handle them and, on reading a text file, provides a automatic way of ignoring an optional BOM by checking for the BOM after file opening. A test for execution in a Windows environment is provided below if one decides to add a BOM only on Microsoft Windows. I have not downloaded the splitter and mkgmap sources and searched for the appropriate places in their sources to apply the changes. I feel the main splitter and mkgmap developers are placed better to make these changes. This is the reason that I did not provide patches to the sources. Randolph J. Herber. On 12/14/2019 9:44 AM, Randolph J. Herber wrote:
Dear Sirs:
Re UTF-8
Microsoft does this to handle another problem: Microsoft uses many different character set encodings (i.e., code pages, e.g., CP1252) and the BOM is used by Microsoft to indicate that the "code page" is UTF-8. Java was implemented to an older version of the Unicode standard that prohibited an UTF-8 BOM. The problem is comes from moving back and forth across that cultural divide. Yes, this is painful.
A solution to the reading issue from the Java side:
https://stackoverflow.com/questions/1835430/byte-order-mark-screws-up-file-r...
A solution for writing a UTF-8 BOM in Java:
|BufferedWriter out = new BufferedWriter(new OutputStreamWriter(new FileOutputStream(the File), StandardCharsets.UTF_8))out.write('\ufeff');|
A check for execution in a Windows environment:
String OS = System.getProperty("os.name").toLowerCase(); Boolean isWindows = OS.indexOf("win") >= 0;
Perhaps, on output write the BOM in a Windows environment and use the BOM optional on input.
http://www.unicode.org/faq/utf_bom.html
Q: What are some of the differences between the UTFs?
A: The following table summarizes some of the properties of each of the UTFs.
Name UTF-8 UTF-16 UTF-16BE UTF-16LE UTF-32 UTF-32BE UTF-32LE Smallest code point 0000 0000 0000 0000 0000 0000 0000 Largest code point 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF 10FFFF Code unit size 8 bits 16 bits 16 bits 16 bits 32 bits 32 bits 32 bits Byte order N/A <BOM> big-endian little-endian <BOM> big-endian little-endian Fewest bytes per character 1 2 2 2 4 4 4 Most bytes per character 4 4 4 4 4 4 4
In the table <BOM> indicates that the byte order is determined by a byte order mark, if present at the beginning of the data stream, otherwise it is big-endian.
http://www.unicode.org/versions/Unicode5.0.0/ch02.pdf
Table 2-4. The Seven Unicode Encoding Schemes
Encoding Scheme Endian Order BOM Allowed?
UTF-8 N/A yes
The remainder of the table omitted.
https://docs.microsoft.com/en-us/windows/win32/intl/using-byte-order-marks
Using Byte Order Marks
* 05/30/2018 * 2 minutes to read * o o <https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/Intl/using-byte-order-marks.md>
Always prefix a Unicode plain text file with a byte order mark, which informs an application receiving the file that the file is byte-ordered. Available byte order marks are listed in the following table. Because Unicode plain text is a sequence of 16-bit code values, it is sensitive to the byte ordering used when the text is written.
Note
A byte order mark is not a control character that selects the byte order of the text.
Byte order mark Description EF BB BF UTF-8 FF FE UTF-16, little endian FE FF UTF-16, big endian FF FE 00 00 UTF-32, little endian 00 00 FE FF UTF-32, big-endian
On 12/14/2019 3:41 AM, Ticker Berkin wrote:
Hi Joris & Gerd
Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style.
Some other questions however:
How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it.
It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed.
Regards Ticker
On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo<jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev<mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann<gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK<osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann;mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK<osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann;mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev<mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK<osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An:mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote: > Hi Gerd, > > I use TypViewer for creating typ files and I don't know XPM > details. > But looking at TypViewer output, I guess that transparent > pixels > are defined with color like that: > > " c none" > > where space ' ' is used for marking pixels. > > Changing draw order instead of transparent graphics could be > a > solution too, but I'm not sure if covered polygon label would > remain visible. And without label, there is not much use of > this object. > _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Randolph This topic should probably become a new thread. You shouldn't confuse the encoding of the java source text (rules determined by the java language) with how a java program reads a text file into its internal character format (however the programmers want to do it, but the java library supplies converters for almost all character sets/encodings). I agree that the text file input processing of mkgmap should allow for a BOM in all cases and use it to determine the correct unicode input decoding. There are various possible input files with a mix of character set/encoding determination and BOM acceptance. A quick look for the the various txt inputs, I find: style components: In the default style, all are pure 7-bit ascii. except inc/address which contains some UTF-8 encoded characters. road-name-config: this is read as UTF-8. TYP: This checks for a UFT-8 BOM as the first character on a line, and, if not there, looks for a line starting with 'CodePage=' and uses what follows, with cp65001 taken to mean UTF-8. It has some logic to default to cp1252 and some other convolutions. There are many incorrect assumptions in this handling, the main one being that CodePage is there to determine the output charset, which can be determined from the main mkgmap map options anyway. -c options.cfg: I haven't studied the logic for this, but it probably uses the character set/encoding determined by Java from the environment; on unix maybe $LANG with typical value "en_GB.UTF-8" command line parameters: ditto copyright/licence-file: not looked delete-tags-file: not looked other files: ? Most of these areas could benefit from a unified way of determining the input character set and encoding, but we need to beware of backward compatibility, where users have their own components in a code-page relevant to their area. I suggest something like the following, in order: 1/ Look for a BOM for any of the unicode encodings near the start of the file; not necessarily the first character, because, without changing the next level of the file parser, it might need to be in a comment. 2/ Look for the 1st or 2nd line of the format: {comment-indicator} -*- coding: {charset} -*- where {comment-indicator} is typically a '#'. and {charset}, for unicode, represents the encoding as well. This method is used by Python and was common on unix systems and recognised by many text editors before UTF-8 became ubiquitous. 3/ Default to UTF-8 or the environmental default depending on context, to be compatible with current handling. Ticker On Tue, 2019-12-17 at 15:20 -0600, Randolph J. Herber wrote:
Dear Sirs: There has been a thread of discussion of whether there should be a Beginning Of Message (BOM) at the beginning of a UTF-8 file. This discussion is complicated by the fact that some of the developers work on Unix, Linux, BSD, iOS, Solaris and Windows. These operating systems have UTF-8 handling libraries written at different times and to different Unicode standards. Originally the Unicode standard said that UTF-8 should not have a BOM character at the beginning of a file. Later Unicode changed the standard to a BOM is permissible, not required and not recommended. Microsoft added a BOM to the beginning of UTF-8 files before doing so was permissible to ease the problem of recognizing a UTF-8 file. This broke the other operating systems' handling of UTF-8. Microsoft petitioned for the permissibility of a BOM to avoid changing their file handling. At this time, I believe at all programs should use Unicode and not Microsoft code pages. I have had problems with Microsoft code pages since MSDOS days. Splitter and mkgmap are written in Java. Java still follows the original Unicode standard of no BOM at the beginning of a UTF-8 text file. This is a "not to fixed" situation per the Java language developers. This situation results in problems with Java, particularly in a Microsoft Windows environment, The code fragments below provide Java solutions to writing a BOM at the beginning of a UTF-8 text files so that Microsoft native text editors can handle them and, on reading a text file, provides a automatic way of ignoring an optional BOM by checking for the BOM after file opening. A test for execution in a Windows environment is provided below if one decides to add a BOM only on Microsoft Windows. I have not downloaded the splitter and mkgmap sources and searched for the appropriate places in their sources to apply the changes. I feel the main splitter and mkgmap developers are placed better to make these changes. This is the reason that I did not provide patches to the sources. Randolph J. Herber.
Hi, Sorry for my late reaction , I was out of the office I use self made tools to generate the mapnik.txt, but for common use, the maintenance of a simple txt is easier for the community. If necessary it is always possible to import the txt in a typ-editor change it manually and export it again. Maintaining (new) languages is much more work, but so be it. So as the source I suggest mapnik.txt from the mkgmap repository The comment section can be removed Kind regards Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Ticker Berkin Verzonden: zaterdag 14 december 2019 10:42 Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Onderwerp: Re: [mkgmap-dev] New branch for default typ file Hi Joris & Gerd Great to see the typ-files now in trunk and all the work in updating mapnik.txt to the current default style. Next week I plan to go through "20191209 mapnik update.pdf" and comment on it and possible changes to the default style. Some other questions however: How do you see mapnik.txt now being maintained; will it be as as simple .txt file with patches being supplied in the same way as other source files, or will it be regenerated from your translation spreadsheet and other sources? I'd prefer the simple text file approach, but this might allow changes into the file which make it incompatible with the tools Joris uses to enhance it. It is currently in UTF8 format, with an appropriate BOM at the start of the file. I don't know how the java input libraries determine the conversion rules to internal unicode, but this file should be consistent with all the others that contain characters outside the simple ansi 7-bit range (roadNameConfig.txt, default/inc/address) It contains the statement:
CodePage=65001 This is saying the output should be unicode, but the output should be the same as the associated map.
Also the FID should be removed. Regards Ticker On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
Hi Joris,
the file mapnik.txt says "Based on mkgmap default style version: r4262" Is it the right file?
reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) I want to look at the DestinationHook. If I got that right it should be OK to have a zero-length road with that type to get the wanted destination hint. In that case we don't have to care about rendering.
Gerd
________________________________________ Von: Joris Bo <jorisbo@hotmail.com> Gesendet: Montag, 9. Dezember 2019 20:45 An: Development list for mkgmap; Gerd Petermann Betreff: RE: [mkgmap-dev] New branch for default typ file
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Pinns UK Verzonden: maandag 9 december 2019 18:31 Aan: Gerd Petermann <gpetermann_muenchen@hotmail.com>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear in a typ file
[_drawOrder] Type=0x03,1 Type=0x28,1 Type=0x54,1 Type=0x01,2 Type=0x09,2 Type=0x4E,2 Type=0x10F1C,2 etc etc [end] I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d which somehow marks "calmer water" and a draw order that puts this above water and below any land type polygon. Is that possible?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:17 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or natural=water.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 16:04 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing 'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help. I see two ways to handle the a polygon with natural=bay: 1) in ponts style with natural=bay & name=* [....] 2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas In case of 2) we would want to render the water area covered by the bay polygon different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Montag, 9. Dezember 2019 15:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is still needed
Xpm="32 32 2 1" "0 c none" "1 c #C8C8C8" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" "00000000000000000000000000000000" ;12345678901234567890123456789012 [end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details. But looking at TypViewer output, I guess that transparent pixels are defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a solution too, but I'm not sure if covered polygon label would remain visible. And without label, there is not much use of this object.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all As suggested elsewhere, bays should be rendered as transparent and only generated if named. I use this method for other areas and find it very useful. I don't understand what is being suggested by the references to POI in this context; They are findable as Geographic > Water Features > Bay, but to get the name of bay by trying to move the cursor over a POI which might not exist and selecting it doesn't make sense. Some comments (marked #RWB) on "20191209 mapnik update.pdf", attachment to Joris posting 9-Dec 19:45 to reproduced in-line here Changed Lines Added 0x17 Breakwater But later on also used for walls, bariers, fences and hedges: so not easy to translate I added it as a thin dark grey line, assuming fences, walls and hedges are more common then breakwaters and if used create a lot of cluttering if the line is to thick. #RWB I use the thinnest black line for all of these (also for cliff) and give them the smallest label Added 0x0b highway=motorway_link & (mkgmap:exit_hint=true | mkgmap:dest_hint=*) Set the same as 0x09 Trunk link. Is used for both motorway and Trunk links. Would make sense to me to use 0x09 for motorway and 0x09 for trunk instead, but should then be changed in the default style. #RWB Gerd had commented on these. They are very short and difficult to spot unless you zoom right in. Not worth using 2 different routeable lineTypes. Should be rendered the same as the less major road that it replaces (ie primary_link, 0x08) . Added 0x1a route=ferry [0x1a road_class=3 road_speed=0 resolution 19] same as 0x1b #RWB would be nice if car-ferry (0x1a) is shown as more significant than foot/bicycle only ferry (0x1b) Changed Polygons Added 0x1d Leisure = common, depricated by osm wiki, used same color as park, better to be removed from default style i think. #RWB wouldn't want to remove until all OSM usage has gone Added 0x20 leisure=garden [0x20 resolution 21] Added 0x25 place=square [0x25 resolution 22] Added 0x12 highway=services [0x12 resolution 22] landuse=retail [0x12 resolution 20-23] Changed 0x1e (historic) to be 0x22 0x1e was historic is changed to 0x22 Added 0x52 natural=tundra [0x52 resolution 18] Added 0x0f landuse=commercial [0x0f resolution 19] Same color as 0x08 commercical / shops Added 0x26 landuse=farm [0x26 resolution 22] landuse=farmyard [0x26 resolution 22] Added 0x1c landuse=greenfield [0x1c resolution 20] landuse=meadow | landuse=grass [0x1c resolution 19] landuse=farmland [0x1c resolution 20] Wiki says: greenfield is to be developed in something new and so is really different from being a ‘green meadow area’. Choosed color for green grass because meadow is much more common #RWB I hadn't spotted this distinction, but I don't think it is worth trying to represent differently Added 0x15 landuse=village_green [0x15 resolution 20] Added 0x11 military=danger_area [0x11 resolution 20] #RWB I show this as semi-transparent (red stripes) OVER whatever else is on the map (eg any other landuse). I do the same with nature -reserve/0x16 as green stripes Added 0x23 amenity=* & area!=no & amenity!=grave_yard {add name='${amenity|subst:"_=> "}'} [0x23 resolution 24] This can be anything, lets say it most commonly is a building #RWB It might be a building, but often it is an area that might contain contains buildings etc, so I'd prefer it to be different so that contained building show up Added 0x21 tourism=* & area!=no & waterway!=* {add name='${tourism|subst:"_=> "}'} [0x21 resolution 24] This can be anything, lets say it most commonly is something referred to as green stuf Added 0x24 man_made=* & area!=no {add name='${man_made|subst:"_=> "}'} [0x24 resolution 24] This can be anything, lets say it most commonly is something referred to as constructions such as bridges Changed points Moved bollard from 0x660f to 0x3200 Some suggestions for improvements of the default style For examples also see my osm mapnik style at https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin leisure=water_park [0x09 resolution 21] Is now rendered with the same code for (blue) water area’s but in my opinion should be rendered as green ‘park or campsite‘ area and only the swimmingpool itself is blue water. #RWB the garmin definition of 0x09 is "Marina", which isn't handled by the default style. I suggest adding this and changing water_park to use 0x2a (default name/rendering Area/Body of Water/Green) leisure=recreation_ground [0x19 resolution 21] Is now rendered same as green sportsfacilities but maybe better the same as park or campsite #RWB 0x19 (garmin "Sports Complex") is a bit overloaded as ice_rink, pitch, recreation_ground, sports_center, stadium and track. Maybe recreation_ground could be changed to 0x1e Islands and beaches both uses 0x53 #RWB Islands/Islets should change to 0x56/0x57 and only generated if named and small. Then rendered as transparent Industrial, quarry and construction share the same code 0x0c Line 100: landuse=construction [0x0c resolution 21] Line 108: landuse=quarry [0x0c resolution 19] Line 111: landuse=industrial [0x0c resolution 19-23] Playgrounds and parks share the same code This gives every park a playground symbol #RWB suggest changing playground to 0x1f, leaving park as 0x17 Postbox and recycling share the same code 0x2f15 #RWB There are limited options for searchable points, this is Community
Utility
Prison and public building share the same code 0x3007 amenity=prison [0x3007 resolution 24 default_name 'Prison'] amenity=public_building [0x3007 resolution 24] #RWB limited options: Community > Government Office taxi and busstop share the same code 0x2f17 #RWB limited options: Transportation > Transit Services internet access and emergency phone share the same code 0x2f12 #RWB internet_access should probably be removed from the style. 0x2f12 is Other > Communications viewpoints, arts_centre, artwork and attractions share the same code Line 101: amenity=arts_centre [0x2c04 resolution 24] Line 252: tourism=attraction [0x2c04 resolution 24] Line 253: tourism=artwork [0x2c04 resolution 24] Line 270: tourism=viewpoint {name '${name} - ${description}' | '${name}'} [0x2c04 resolution 24] #RWB limited options: Attractions > Landmark. This doesn't seem a good choice, but I don't see a better one No occurences for amenity=car_club [0x2f0d resolution 24] found in osm database Does not make sense for rendering #RWB Garmin has a search for this: Other > Automobile Club; so the best osm mapping was added. Swimmingpools have also a poi same as waterparks in a villa-areas now you get a lot of swimming symbols Line 191: leisure=swimming_pool [0x2d09 resolution 24] Line 193: leisure=water_park [0x2d09 resolution 24] Line 248: sport=swimming [0x2d09 resolution 24] #RWB findable as Recreation > Swimming pool. The default style should be changed to not add them as a searchable POI if not accessible leisure=swimming_pool could probably better be removed from poi and added to polygons so it appears as a blue water area instead of a poi #RWB see above re POI. Could as as polygon - suggest 0x3a Busstops on lines (platforms) should be limited to only one poi in stead of poi on every node Use: mkgmap:line2poi != true or mkgmap:line2poitype = mid N50° 50.691' E4° 21.108' #RWB Suggest only generate explicit bus_stop Ticker On Mon, 2019-12-09 at 19:45 +0000, Joris Bo wrote:
Hi All,
I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly. See attached new typ-file for correct usage. Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.
Today I spent some time testing and repairing.
The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.
I did a complete recheck of the most recent default-style in: mkgmap -r4386.zip and changed de typ-file accordingly.
I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386 and with mkgmap r4386.jar No errors occured.
I think it’s up to date again but some review and comments are always welcome.
See typ-file in attachement,
Kind regards, Joris
Hi, see example of natural=bay, which can give problems: https://www.openstreetmap.org/relation/9408222 -- Best regards, Andrzej
Hello, Where can i find the mapnik.txt which has been referred to? It is not in the download zip is it? I did have a quick look on the files I once sended, but I don't yet see anything really wrong in there. The natural=bay area has a 'land fill color' but also a draworder lower then all the other water areas So it should appear on the bottom anyway. In fact this would in a way represent the 'transparent' option I think in mapnik, bays are only rendered as poi because the see and water area's duplicate those A bay is a part of the lake, coastline or sea. This was my conclusion after a lot of water and bay rendering in Norway fjords. So maybe it's better to remove natural=bay 0x3d from the default polygon and only use a name in the POI file anyway. Would be nice if I could get the mapnik.txt and an example area to have a better look. So far in my styles and typ I have never encountered such a 'bay' problem Kind regards, Joris -----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 8 december 2019 10:50 Aan: DD8KQ <dd8kq@gmx.de>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file Hi typ file experts, please, can anybody post a patch to fix the mapnik.txt regarding 0x3d? I really don't understand the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von DD8KQ <dd8kq@gmx.de> Gesendet: Freitag, 6. Dezember 2019 16:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- ##################################################### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de ##################################################### _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi My understanding was that mkgmap.txt rather than mapnik.txt was going to be one of the typ-files examples Ticker On Mon, 2019-12-09 at 10:18 +0000, Joris Bo wrote:
Hello,
Where can i find the mapnik.txt which has been referred to? It is not in the download zip is it? I did have a quick look on the files I once sended, but I don't yet see anything really wrong in there.
The natural=bay area has a 'land fill color' but also a draworder lower then all the other water areas So it should appear on the bottom anyway. In fact this would in a way represent the 'transparent' option
I think in mapnik, bays are only rendered as poi because the see and water area's duplicate those A bay is a part of the lake, coastline or sea. This was my conclusion after a lot of water and bay rendering in Norway fjords. So maybe it's better to remove natural=bay 0x3d from the default polygon and only use a name in the POI file anyway.
Would be nice if I could get the mapnik.txt and an example area to have a better look. So far in my styles and typ I have never encountered such a 'bay' problem
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 8 december 2019 10:50 Aan: DD8KQ <dd8kq@gmx.de>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi typ file experts, please, can anybody post a patch to fix the mapnik.txt regarding 0x3d? I really don't understand the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von DD8KQ <dd8kq@gmx.de> Gesendet: Freitag, 6. Dezember 2019 16:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on
Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default -typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ-files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
#####################################################
Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de
#####################################################
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Sorry - seems that the name went from mkgmap.txt Ticker On Mon, 2019-12-09 at 15:13 +0000, Ticker Berkin wrote:
Hi
My understanding was that mkgmap.txt rather than mapnik.txt was going to be one of the typ-files examples
Ticker
On Mon, 2019-12-09 at 10:18 +0000, Joris Bo wrote:
Hello,
Where can i find the mapnik.txt which has been referred to? It is not in the download zip is it? I did have a quick look on the files I once sended, but I don't yet see anything really wrong in there.
The natural=bay area has a 'land fill color' but also a draworder lower then all the other water areas So it should appear on the bottom anyway. In fact this would in a way represent the 'transparent' option
I think in mapnik, bays are only rendered as poi because the see and water area's duplicate those A bay is a part of the lake, coastline or sea. This was my conclusion after a lot of water and bay rendering in Norway fjords. So maybe it's better to remove natural=bay 0x3d from the default polygon and only use a name in the POI file anyway.
Would be nice if I could get the mapnik.txt and an example area to have a better look. So far in my styles and typ I have never encountered such a 'bay' problem
Kind regards, Joris
-----Oorspronkelijk bericht----- Van: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> Namens Gerd Petermann Verzonden: zondag 8 december 2019 10:50 Aan: DD8KQ <dd8kq@gmx.de>; mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] New branch for default typ file
Hi typ file experts, please, can anybody post a patch to fix the mapnik.txt regarding 0x3d? I really don't understand the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von DD8KQ <dd8kq@gmx.de> Gesendet: Freitag, 6. Dezember 2019 16:42 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on
Am 06.12.2019 um 09:17 schrieb Gerd Petermann:
Hi Ticker,
I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file
Hi Gerd
I think it would be good if the files from branches/default -typ/resources/typ-files were put into trunk and, in build.xml, after: <include name="styles/noname/**"/> <include name="chars/ascii/row02.trans"/> this is added: <include name="typ -files/*.txt"/>
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
#####################################################
Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhaiduk@t-online.de dd8kq@gmx.de
#####################################################
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (11)
-
Andrzej Popowski -
Ben Konrath -
Dave Swarthout -
DD8KQ -
Gerd Petermann -
Gerd Petermann
-
Greg Troxel -
Joris Bo -
Pinns UK -
Randolph J. Herber -
Ticker Berkin