On 26/02/11 22:30, Carlos Dávila wrote:
> El 26/02/11 22:58, Steve Ratcliffe escribió:
>> Hi
>>
>>
Does that not happen on the current trunk too?
>>> No, it works fine with trunk on the same input files.
>>>
>> Interesting, I'll try and compile a map of Spain and see if there is
>> a
El 26/02/11 22:58, Steve Ratcliffe escribió:
> Hi
>
>
>>> Does that not happen on the current trunk too?
>>>
>>>
>> No, it works fine with trunk on the same input files.
>>
> Interesting, I'll try and compile a map of Spain and see if there is
> anything obvious that is wrong or d
Hi
>> Does that not happen on the current trunk too?
>>
> No, it works fine with trunk on the same input files.
Interesting, I'll try and compile a map of Spain and see if there is
anything obvious that is wrong or different.
..Steve
___
mkgmap-dev mai
I'm wondering if we can get closed areas to generate as POIs?
signature.asc
Description: OpenPGP digital signature
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Attached is a patch that takes care of the series-name/family-name issue.
N.
Index: src/uk/me/parabola/mkgmap/combiners/NsisBuilder.java
===
--- src/uk/me/parabola/mkgmap/combiners/NsisBuilder.java(revision 1862)
+++ src/uk/m
Am 26.02.2011 18:02, schrieb Steve Ratcliffe:
>> What about Russian? Many users in Russia use mkgmap with
>> -charset:cp1251 or
>> -code-page:1251. The index-branch version 1861 does not work correctly
>> with
>> the Russian haracter set.
>>
>
> Hello
>
> That is a good point I will make sure th
El 26/02/11 17:46, Steve Ratcliffe escribió:
>
>>>
>>>
>> I still have the missing "Calle*" streets on MapSource. Any chance to
>> fix it before merge?
>>
>>
> Does that not happen on the current trunk too?
>
No, it works fine with trun
ValentinAK wrote:
>What about Russian? Many users in Russia use mkgmap with
>-charset:cp1251 or
>-code-page:1251. The index-branch version 1861 does not work correctly
>with
>the Russian character set.
>
Hello
That is a good point I will make sure that it doesn't crash or work badly
compared t
What about Russian? Many users in Russia use mkgmap with -charset:cp1251 or
-code-page:1251. The index-branch version 1861 does not work correctly with
the Russian character set.
--
View this message in context:
http://gis.638310.n2.nabble.com/Global-index-branch-tp6067663p6067966.html
Sent from
>>
>I still have the missing "Calle*" streets on MapSource. Any chance to
>fix it before merge?
>
Does that not happen on the current trunk too?
If it doesn't then perhaps it is something that can be fixed but otherwise it
is a case of new developmen
Now only lines which endpoints are outside or on the bounding box are
closed.
WanMil
As András Kolesár found out the PolygonSplitter did not close all
polygons. There were several more places in the code where polygons were
not closed. I am not really sure if that caused any problems in the ma
On 2/18/2011 5:19 PM, Minko wrote:
> Right now mkgmap copy and pastes --series-name into those fields,
> whereas family-name seems more logical. The drop-down name in mapsource is
> the series-name.
Sorry I was unclear: the name in the MapSource drop-down menu is not set
when building the instal
El 26/02/11 15:16, Steve Ratcliffe escribió:
> Hi
>
> I am planning to merge back the 'index' branch to trunk.
>
> Is there anything that needs tidying up before that is done?
>
> ..Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
>
> 2011/2/26 WanMil:
>
>>> Could mkgmap be aware of the tile borders when closing polygons? When
>>> the open endpoints are within the current tile, do not close the
>>> polygon, and possibly emit a complaint to the error log. When the
>>> endpoints are outside the current tile borders, close by add
> Hi
>
> I am planning to merge back the 'index' branch to trunk.
>
> Is there anything that needs tidying up before that is done?
>
> ..Steve
Hi Steve,
that's great. I don't know anything that needs tidying up.
Thanks for you enormous effort you spent to make the index working!
WanMil
Hi
I am planning to merge back the 'index' branch to trunk.
Is there anything that needs tidying up before that is done?
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 1862 was commited by wanmil on 2011-02-26 14:15:14 + (Sat, 26 Feb
2011)
Improved error logging for sea multipolygons
The ways created by the sea generator do not contain any reference to the
original OSM ids. To give a hint which ways are used the start and the mid
point are now l
2011-02-26 Marko Mäkelä:
>>Current default map style in mkgmap does not depict barriers.
>>Is there a reason for that or it was simply not added to "lines" file
>>yet?
>
> I guess that the reason is that the default style is supposed to be
> useable with the "built-in TYP file" in various Garmin de
Just found out that this fine typ editor finally has been translated into
English, it can be downloaded at http://opheliat.free.fr/michel40/TYPViewer3.5
They also improved the installation (previous versions of setup.exe didn't work
on my windows vista pc).
Screenshot:
http://sites.google.com/si
2011/2/26 WanMil :
>> Could mkgmap be aware of the tile borders when closing polygons? When
>> the open endpoints are within the current tile, do not close the
>> polygon, and possibly emit a complaint to the error log. When the
>> endpoints are outside the current tile borders, close by adding li
On Sat, Feb 26, 2011 at 11:45:56AM +0100, WanMil wrote:
>If there are problems with the sea multipolygon logging is supplied
>with two coordinates (start and mid/end point) of the ways so that it
>is possible to investigate the problem.
Thanks WanMil, this did the trick for me:
2011/02/26 15:19
Hi Tomas,
On Sat, Feb 26, 2011 at 12:39:24PM +0200, Tomas Straupis wrote:
>Current default map style in mkgmap does not depict barriers.
>Is there a reason for that or it was simply not added to "lines" file
>yet?
I guess that the reason is that the default style is supposed to be
useable with
Sorry, wrong list.
Am 26.02.2011 13:15, schrieb Josef Latt:
> Hi,
>
> in the thread 'mkgmap and values with semicolon in it' in the mkgmap
> mailing list you can read that values with semikolons should be avoided.
>
> IMHO it would b better to remove this so that you only can overwrite the
> pro
Hi,
in the thread 'mkgmap and values with semicolon in it' in the mkgmap
mailing list you can read that values with semikolons should be avoided.
IMHO it would b better to remove this so that you only can overwrite the
properties.
Greetings
Josef
--
PGP Schlüssel: 311D1055
http://keyserver.pgp
WanMil,
Many thanks.
I have a little further information:
If I examine the screen on my GPS with a magnifying glass near to the
'thin blue line' artefact, where a road crosses this line there is an
artefact crossing the road line also. However this is NOT directly in
line with the 'blue' lin
>
>>
>> I have just noticed 'thin blue line' (I estimate about 1 pixel wide)
>> along every tile edge )or border). This is more obvious when I 'zoom
>> out' and it highlights my tiles because there is this blue sea-coloured
>> border around them.
>>
>> I am using the Geofabrik GB OSM download and
If there are problems with the sea multipolygon logging is supplied with
two coordinates (start and mid/end point) of the ways so that it is
possible to investigate the problem.
WanMil
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
> On Fri, Feb 25, 2011 at 11:36:39PM +0100, WanMil wrote:
>> But I also found out that some polygons that crosses the tile border
>> which are closed in the OSM data are not neccessarily closed in the
>> tiles. This has to be investigated.
>> Does the splitter ensure that all closed ways in the OSM
Hello
Current default map style in mkgmap does not depict barriers.
Is there a reason for that or it was simply not added to "lines" file yet?
barrier=wall [0x00 resolution 20]
barrier=fence [0x00 resolution 20]
Thank you
--
Tomas Straupis
___
flabot googlemail.com googlemail.com> writes:
>
> you use http://dev.openstreetmap.de/aio/africa-daily/ ?
>
I do not understand your brief reply.
This is where I download the OSM files for Great Britain:
http://download.geofabrik.de/osm/europe/
Are you suggesting this source may be the pr
On Fri, Feb 25, 2011 at 11:36:39PM +0100, WanMil wrote:
>But I also found out that some polygons that crosses the tile border
>which are closed in the OSM data are not neccessarily closed in the
>tiles. This has to be investigated.
>Does the splitter ensure that all closed ways in the OSM dump ar
On Fri, Feb 25, 2011 at 11:36:11PM +0100, Thorsten Kukuk wrote:
>Same as for Felix: Please provide an alternative form of tagging,
>which does not need semicolons.
We do not write recycling=paper;plastic;cardboard. The alternative form
that is already used for this case is simple: recycling:paper
32 matches
Mail list logo
