WanMil wrote
> Please have a look at the attached image.
>
> The green area is the land data contained in the OSM data to be split.
> The blue area is sea but the left coastline (grey) is not contained in
> the OSM data.
>
> If you trim before merging the sea density the left border of the tile
I still get this message in mkgmap
when processing data that was created
with splitter r275 and --precomp-sea option.
It seems that it is not sufficient to count the nodes in the precompiled
sea data, which leads me to the assumption that this is a general problem
with polygons.
I don't know wha
Am 22.11.2012 16:05, schrieb WanMil:
>> Do we have a style-function for this?
>>
>> item( ${destination}, 1 ) -> Bonn
>> item( ${destination}, 2 ) -> Rodenkirchen
>
> No we don't and it will not be so easy to implement that because the
> functions do not have any parameters yet at the moment. So
Am 28.12.2012 12:57, schrieb Chris66:
> Am 22.11.2012 16:05, schrieb WanMil:
>>> Do we have a style-function for this?
>>>
>>> item( ${destination}, 1 ) -> Bonn
>>> item( ${destination}, 2 ) -> Rodenkirchen
>> No we don't and it will not be so easy to implement that because the
>> functions do not
I am trying to creat a sample map with a custom TYP file.
Running mkgmap.jar -c 5060.cfg 5060.TYP *.osm.pbf results in an error
message which says:
WARNING: input file ... has a different sort order (20007 rather than 0
The 5060.cfg file contains the following lines:
description=Liechtenstein
co
> Am 22.11.2012 16:05, schrieb WanMil:
>>> Do we have a style-function for this?
>>>
>>> item( ${destination}, 1 ) -> Bonn
>>> item( ${destination}, 2 ) -> Rodenkirchen
>>
>> No we don't and it will not be so easy to implement that because the
>> functions do not have any parameters yet at the mome
The style uses a tag display_name. This is an internal mkgmap tag and
should therefore be name mkgmap:display_name.
Attached patch changes this but still accepts the old display_name
(issuing a warning).
WanMil
Index: resources/styles/builtin-tag-list
=
Hi
> WARNING: input file ... has a different sort order (20007 rather than 0
> I have read the thread started Dec. 22nd but the error message doesn't
> disappear.
It doesn't work with the patch applied?
I will commit it now. I hesitated because, with the patch there
would be no warning if the
Hi everybody,
I noticed that with every img I create there is a *_license.txt file
generated that reads:
Map data (c) OpenStreetMap and contributors
http://www.openstreetmap.org/
Map data licenced under Creative Commons Attribution ShareAlike 2.0
See http://creativecommons.org/li
Version 2427 was committed by steve on 2012-12-28 13:57:35 + (Fri, 28 Dec
2012)
When a typ file is first, before the map files, an incorrect message
is triggered about different sort-orders.
Worse it uses the "no sort order" value for the generated
index, and so the index will not work.
___
Am 28.12.2012 14:54, schrieb Steve Ratcliffe:
> I will commit it now. I hesitated because, with the patch there
> would be no warning if the TYP file had a different code-page
> to the maps (if that matters).
Hi Steve,
the code page is the same in the cfg-file (latin1) as well as in the
binary t
11 matches
Mail list logo