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 im Auftrag von Ticker Berkin Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: this is added: 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 mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with drive-on
Hi Carlos,
I'll have a look at it. I also think about a change regarding the detect
method. If I got it right it assumes right hand traffic for countires which do
not appear in LocatorConfig.xml. It might better ignore those entries when the
majority of roads is in a known country.
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
Gesendet: Freitag, 6. Dezember 2019 16:14
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on
I agree it seems admin_level value is wrong. I've added a comment on
changeset aobut it. A warning as you suggest may be useful to detect
such cases.
El 6/12/19 a las 8:19, Gerd Petermann escribió:
> Hi Carlos,
>
> see https://www.openstreetmap.org/way/303677783 and
> https://www.openstreetmap.org/way/303677781
> I guess the admin_level of those two ways is wrong. There are more ways in
> this area with admin_level=2.
>
> To find them I've added
> highway=* {echotags "c"}
> as last line in the lines file to check what values the roads have in
> mkgmap:admin_level2 and mkgmap:country
>
> Maybe I should add code in the boundary generator to warn when it stores a
> name for mkgmap:admin_level2 which doesn't
> show up in LocatorConfig.xml?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von Gerd
> Petermann
> Gesendet: Donnerstag, 5. Dezember 2019 20:08
> An: Carlos Dávila; mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Problem with drive-on
>
> Hi Carlos,
>
> seems my file was even older. I can reproduce the problem with the bounds
> file created 2019-11-29.
> I'll have a closer look tomorrow.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Carlos Dávila
> Gesendet: Donnerstag, 5. Dezember 2019 19:58
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] Problem with drive-on
>
> I have just realized my bounds.zip file is more than one year old (it
> should be automatically updated every week=-O). I'll try with a new one.
>
> El 5/12/19 a las 15:13, Gerd Petermann escribió:
>> Hi Carlos,
>>
>> I just tried to reproduce the problem. I've downloaded the area in your bbox
>> (a bit larger) to file in.osm.pbf
>> and used splitter to cut out your area with
>> java -jar splitter.jar --split-file=areas.list in.osm.pbf
>> Then I used
>> java -jar mkgmap.jar --drive-on=detect --bounds=bounds.zip --route
>> 63240001.osm.pbf
>> I don't see the message.
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev im Auftrag von Gerd
>> Petermann
>> Gesendet: Mittwoch, 4. Dezember 2019 21:16
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Problem with drive-on
>>
>> Hi Carlos,
>>
>> My understanding is that your style (or the bounds file) sets at least two
>> different mkgmap:country values for the tile.
>> Maybe you can post a link to that tile?
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev im Auftrag von
>> Carlos Dávila
>> Gesendet: Mittwoch, 4. Dezember 2019 12:15
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Problem with drive-on
>>
>> I am preparing an areas.list file to split Oceania, so that each tile
>> contains only roads driven on the same side. I have found a tile where
>> all roads should be driven on left side, as it all lies within
>> Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695)
>> and drive-on-right roads (57)". I have reduced tile size to narrow down
>> the problem. These are its coordinates: -288768,6178816 to
>> -210944,6219776. It includes two islands, right one is detected by
>> mkgmap as right side driven, but it is left driven (to my knowledge).
>> Any idea why this happens?
>>
>>
>>
___
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
Re: [mkgmap-dev] Problem with drive-on
I agree it seems admin_level value is wrong. I've added a comment on
changeset aobut it. A warning as you suggest may be useful to detect
such cases.
El 6/12/19 a las 8:19, Gerd Petermann escribió:
Hi Carlos,
see https://www.openstreetmap.org/way/303677783 and
https://www.openstreetmap.org/way/303677781
I guess the admin_level of those two ways is wrong. There are more ways in this
area with admin_level=2.
To find them I've added
highway=* {echotags "c"}
as last line in the lines file to check what values the roads have in
mkgmap:admin_level2 and mkgmap:country
Maybe I should add code in the boundary generator to warn when it stores a name
for mkgmap:admin_level2 which doesn't
show up in LocatorConfig.xml?
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Donnerstag, 5. Dezember 2019 20:08
An: Carlos Dávila; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on
Hi Carlos,
seems my file was even older. I can reproduce the problem with the bounds file
created 2019-11-29.
I'll have a closer look tomorrow.
Gerd
Von: mkgmap-dev im Auftrag von Carlos Dávila
Gesendet: Donnerstag, 5. Dezember 2019 19:58
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on
I have just realized my bounds.zip file is more than one year old (it
should be automatically updated every week=-O). I'll try with a new one.
El 5/12/19 a las 15:13, Gerd Petermann escribió:
Hi Carlos,
I just tried to reproduce the problem. I've downloaded the area in your bbox (a
bit larger) to file in.osm.pbf
and used splitter to cut out your area with
java -jar splitter.jar --split-file=areas.list in.osm.pbf
Then I used
java -jar mkgmap.jar --drive-on=detect --bounds=bounds.zip --route
63240001.osm.pbf
I don't see the message.
Gerd
Von: mkgmap-dev im Auftrag von Gerd
Petermann
Gesendet: Mittwoch, 4. Dezember 2019 21:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with drive-on
Hi Carlos,
My understanding is that your style (or the bounds file) sets at least two
different mkgmap:country values for the tile.
Maybe you can post a link to that tile?
Gerd
Von: mkgmap-dev im Auftrag von Carlos Dávila
Gesendet: Mittwoch, 4. Dezember 2019 12:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with drive-on
I am preparing an areas.list file to split Oceania, so that each tile
contains only roads driven on the same side. I have found a tile where
all roads should be driven on left side, as it all lies within
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695)
and drive-on-right roads (57)". I have reduced tile size to narrow down
the problem. These are its coordinates: -288768,6178816 to
-210944,6219776. It includes two islands, right one is detected by
mkgmap as right side driven, but it is left driven (to my knowledge).
Any idea why this happens?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] space before name
Hi Gerd, the already compiled version of mkgmap that you provided works perfectly but I ask you this behavior will be there also in the next releases? Many thanks. --enrico -- 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
Re: [mkgmap-dev] space before name
Hi Enrico, If you like you can improve the patch. If you just want to try the effect use the mkgmap.jar provided with the link. Gerd Von: mkgmap-dev im Auftrag von demon_box Gesendet: Freitag, 6. Dezember 2019 11:11 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] space before name Hi Gerd, thanks for your answer. Now what I have to do with you patch attached? Thanks. --enrico -- 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
Re: [mkgmap-dev] New branch for default typ file
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 +, 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 im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 5. Dezember 2019 11:20 > An: mkgmap development > Betreff: Re: [mkgmap-dev] New branch for default typ file > > Hi Gerd > > I think it would be good if the files from branches/default > -typ/resources/typ-files were put into trunk and, in build.xml, > after: > > name="chars/ascii/row02.trans"/> > this is added: > > > 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
Re: [mkgmap-dev] space before name
Hi Gerd, thanks for your answer. Now what I have to do with you patch attached? Thanks. --enrico -- 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
Re: [mkgmap-dev] New branch for default typ file
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 im Auftrag von Ticker Berkin Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: this is added: Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] space before name
Hi Enrico,
mkgmap replaces duplicated blanks (' ') by a single one, so only one leading
blank is written to the img file. Attached patch changes this
so that duplicated blanks are not removed.
I was surprised that leading and trailing blanks are not completely removed,
probably because this is already done when the data is read from
the input file.
I assume this is related to your other post regarding positioning of POI
labels. This is done by the Garmin software, so I suggest to ask Garmin if
there is a way to influence that. No idea how leading blanks are treated when
you search for objects, you may play with this, but I am sure it makes no sense.
Compiled binary is here:
http://files.mkgmap.org.uk/detail/457
Gerd
Von: mkgmap-dev im Auftrag von
demon_box
Gesendet: Mittwoch, 4. Dezember 2019 21:43
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] space before name
Hi I would insert 5 space carachters but I don't know how.
This work:
name=* {name 'x${name}'}
but this dont't work:
name=* {name ' ${name}'}
How can I make this?
thanks
--enrico
--
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
spaces.patch
Description: spaces.patch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
