Henning Scholland wrote
But not at all. If there are larger spaces with no data, no-trim=false
will create ugly looking maps. As you can see here:
http://www.aighes.de/data/scandinavia.png world.kml was created out of
planet.osm with scandinavia.poly and no-trim=false
btw: Are there
Am 27.11.2012 12:47, schrieb GerdP:
Henning Scholland wrote
But not at all. If there are larger spaces with no data, no-trim=false
will create ugly looking maps. As you can see here:
http://www.aighes.de/data/scandinavia.png world.kml was created out of
planet.osm with scandinavia.poly and
the reason for the error is the new split algorithm introduced with
splitter r245 and r246. But the split algorithm is *not* defective. It's
more an unfortunate combination of circumstances.
The new split algorithm created the tile 66923055 which covers most of
iceland and a very
the reason for the error is the new split algorithm introduced with
splitter r245 and r246. But the split algorithm is *not* defective. It's
more an unfortunate combination of circumstances.
The new split algorithm created the tile 66923055 which covers most of
iceland and a
WanMil wrote
Yes. I assume it is possible to define multiple separated polygons
within the polygon file?
Yes, it is.
Gerd
--
View this message in context:
http://gis.19327.n5.nabble.com/splitter-r246-tp5737445p5737824.html
Sent from the Mkgmap Development mailing list archive at
Reg. overlap: I agree that overlap should be ignored with --keep-complete.
I just don't have enough experience to decide this alone.
I wasnot sure whether overlap=0 should be forced with --keep-complete or
whether it should be ignored only if user did not explicitely specify a
value.
I
Well done!
- Original Message -
From: Steve Ratcliffe st...@parabola.me.uk
To: mkgmap development mkgmap-dev@lists.mkgmap.org.uk
Sent: Tuesday, November 27, 2012 3:46 AM
Subject: [mkgmap-dev] mkgmap birthday
Hi
On this day, 6 years ago, revision 1 was committed to svn.
$ svn
Hi
I made this commit to make remove-short-arcs on by default. Due to my
misconfiguration of the email address it didn't go to the main list.
There is more to this than I thought. I remember the default being 5,
but the code currently has 0 as the default. So 0 shouldn't work
and that ties in
Am 26.11.2012 23:13, schrieb WanMil:
Some small hints about your mkgmap configuration:
* I propose to use precompiled sea files (e.g.
http://www.navmaps.eu/wanmil/sea_20121020.zip). It's faster and takes
less memory.
Hi WanMil,
is it possible to generate the precompiled files by myself? I
Am 27.11.2012 13:18, schrieb Steve Ratcliffe:
I made this commit to make remove-short-arcs on by default. Due to my
misconfiguration of the email address it didn't go to the main list.
There is more to this than I thought. I remember the default being 5,
but the code currently has 0 as the
Am 26.11.2012 23:13, schrieb WanMil:
Some small hints about your mkgmap configuration:
* I propose to use precompiled sea files (e.g.
http://www.navmaps.eu/wanmil/sea_20121020.zip). It's faster and takes
less memory.
Hi WanMil,
is it possible to generate the precompiled files by myself? I
Hi
what do you mean by boundary nodes? Are these the nodes
which are needed for tile-to-tile routing ?
Yes, exactly.
This was just my impression looking at this late last night,
I will have to look into the history of the code. I'm on a train heading
towards the floods at the moment, so not
Am 27.11.2012 13:51, schrieb WanMil:
Am 26.11.2012 23:13, schrieb WanMil:
Some small hints about your mkgmap configuration:
* I propose to use precompiled sea files (e.g.
http://www.navmaps.eu/wanmil/sea_20121020.zip). It's faster and takes
less memory.
Hi WanMil,
is it possible to generate
WanMil wrote
Hi Uli,
the reason for the error is the new split algorithm introduced with
splitter r245 and r246. But the split algorithm is *not* defective. It's
more an unfortunate combination of circumstances.
The new split algorithm created the tile 66923055 which covers most of
14 matches
Mail list logo
