Hi all,
the last months brought a lot of improvements, but there is still a lot to do:
Before summer I only plan to improve readability/stability and maybe
performance of code:use one internal representation for vehicles (mkgmap:car,
mkgmap:bicycle,...)
and only translate it to the img
Hi Gerd,
Bugfix: Internal oneway handling
At the moment all oneway ways are normalized to onway=yes (they are
reversed when they are tagged with oneway=-1). But all other tags are
left untouched. So that will be something like
http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetm
Hi WanMil,
WanMil wrote
> Bugfix: Internal oneway handling
> At the moment all oneway ways are normalized to onway=yes (they are
> reversed when they are tagged with oneway=-1). But all other tags are
> left untouched. So that will be something like
> http://josm.openstreetmap.de/browser/josm/
Am 16.04.2014 22:01, schrieb GerdP:
Why do you think that it is a bug?
Think about oneway=-1 and in style you add oneway-arrows (link mapnik
does). In style you will handle -1 special, because arrows should drawn
in oposite direction of way. If mkgmap now changes direction of the way,
arrows s
.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
Am 16.04.2014 22:01, schrieb GerdP:
Why do you think that it is a bug?
Think
about oneway=-1 and in style you add oneway-arrows (link mapnik
does). In style you will handle -1 special,
ignore this because in the points file you can't detect
the direction of the way.
Gerd
Date: Wed, 16 Apr 2014 23:00:35 +0200
From: o...@aighes.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
Am 16.04.2014 22:01, schrieb GerdP:
Why do you
: [mkgmap-dev] mkgmap ToDo list
I currently have basically no time - so I'm just reading on
the list in skip through mode. Unable to test - but I'm pretty
sure there is a big bug related to the oneway handling and
reversing of ways. I'm als
On 16/04/14 07:08, Gerd Petermann wrote:
@Steve: Maybe we should keep this list somewhere at
http://www.mkgmap.org.uk/ and try to maintain it?
Thanks, this is a good list. Some of the items may need some
explanation for people that are not already very familiar with
the code.
I've put it at ht
Hi @ all,
while thinking about creation of simple maps with less features I
thought about an better parameter for splitter then just the number of
OSM-nodes. Actually splitter writes density-files (but also based on
OSM-nodes). You can imagine that the number of OSM-nodes may differ a
lot in
Hi Henning,
I don't understand. What would be the content of that file?
What would you do with it?
Gerd
Henning Scholland wrote
> Hi @ all,
>
> while thinking about creation of simple maps with less features I
> thought about an better parameter for splitter then just the number of
> OSM-no
Hi Gerd,
splitter is able to write a density file, which stores the density of
OSM-nodes in the specific area. Afterwards the file is splitted and
processed by mkgmap. mkgmap will use only the objects, which are
addressed in style-file.
Example: In a rectangle of 100x100m are 5 nodes belongin
tile size
will be different, in other words, you have to find
out how much higher the max-nodes value can be.
Gerd
> Date: Fri, 25 Apr 2014 19:27:09 +0200
> From: o...@aighes.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> Hi Gerd,
> s
find
out how much higher the max-nodes value can be.
Gerd
> Date: Fri, 25 Apr 2014 19:27:09 +0200
> From: o...@aighes.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> Hi Gerd,
> splitter is able to write a density file, which stores
higher the max-nodes value can be.
>>
>> Gerd
>>
>>
>>
>> > Date: Fri, 25 Apr 2014 19:27:09 +0200
>> > From:
> osm@
>> > To:
> mkgmap-dev@.org
>> > Subject: Re: [mkgmap-dev] mkgmap ToDo list
>> >
>> > H
Hi Gerd,
I would like to have img-tiles which have globally nearly the same
filesize, so that they use the space of devices like eTrex 10.
With my actual map I use globally the same value for max-nodes. But the
size of the img-tiles differ more then factor 2. Eg. a tile in Germany
is between
Hi Henning,
okay, got it.
You mentioned the density file written by splitter. I have no idea how,
but you may find a way to manipulate the values in that file.
DensityMap.readMap() contains the code to read that file
which simply represents the content of the density map
(x and y index and numb
ate: Fri, 25 Apr 2014 21:54:05 +0200
> From: o...@aighes.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> Hi Gerd,
>
> I would like to have img-tiles which have globally nearly the same
> filesize, so that they use the space of devices
While this possibly can be solved in Splitter or Mkgmap, it could also
be solved by your build-script when you add a maximum tile size check
and re-split (with a lower number of max-nodes) until you get two or
more sub-tiles. Granted, this adds complexity to the script but it works
well for me.
to a multiple of map units as now).
So, for your script that means you don't have to find the max-nodes
value.
I'll think about this again...
Gerd
> Date: Tue, 29 Apr 2014 14:59:36 +0200
> From: o...@na1400.info
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> While this possibly can be solved in Splitter or Mkgmap, it could also
> be solved by your build-script when you add a maximum tile size check
> and re-split (with a lower number of max-nodes) unti
you don't have to find the max-nodes
> > value.
> >
> > I'll think about this again...
> >
> > Gerd
> >
> > > Date: Tue, 29 Apr 2014 14:59:36 +0200
> > > From: o...@na1400.info
> > > To: mkgmap-dev@lists.mkgmap.org.uk
> > >
optimization you will
see a factor 3 or higher between the largest tile and the smallest.
Can you confirm that?
Gerd
Date: Tue, 29 Apr 2014 15:32:38 +0200
From: o...@na1400.info
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
Num-tiles=x would indeed be better for
t.
>> Can you confirm that?
>>
>> Gerd
>>
>>> Date: Tue, 29 Apr 2014 15:32:38 +0200
>>> From:
> osm@
>>> To:
> mkgmap-dev@.org
>>> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>>>
>>> Num-tiles=x would indeed
that?
Gerd
Date: Tue, 29 Apr 2014 15:32:38 +0200
From:
osm@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] mkgmap ToDo list
Num-tiles=x would indeed be better for this specific need.
It is my experience that it regularly takes multiple calls to
Splitter
to get 2+ sub-tiles when
.uk
> Date: Tue, 29 Apr 2014 20:30:27 +0200
> From: o...@na1400.info
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> These are the direct results from Splitter. The format is o5m, both
> input as output. Splitter version is: r321.
>
> For this test I split the origi
.@na1400.info
Subject: Re: [mkgmap-dev] mkgmap ToDo list
These are the direct results from Splitter. The format is o5m, both
input as output. Splitter version is: r321.
For this test I split the original source with --max-nodes=800.
Then
I render the initial tiles, when the result is larger
Hi Lambertus,
okay, so that's what I meant reg. the factor 3 between largest and smallest
part.
Gerd
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Tue, 29 Apr 2014 20:48:24 +0200
> From: o...@na1400.info
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> I don't have
mkgmap-dev@lists.mkgmap.org.uk
Date: Tue, 29 Apr 2014 20:48:24 +0200
From: o...@na1400.info
Subject: Re: [mkgmap-dev] mkgmap ToDo list
I don't have the number for Germany, but perhaps the world suffices?
The image size distribution of my generic map is:
<2MB some
2-3MB 260
3-4MB 410
4-5MB 600
5-6
cript, too.
If you do that for e.g. Germany, how small is tpically the smallest
*.img file ?
Is it probably near 4 MB?
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Tue, 29 Apr 2014 20:30:27 +0200
From: o...@na1400.info
Subject: Re: [mkgmap-dev] mkgmap ToDo list
These are the direct results
Hi Lambertus,
are these numbers the result of your script or the basic results of
splitter?
Henning
Am 29.04.2014 20:48, schrieb o...@na1400.info:
I don't have the number for Germany, but perhaps the world suffices?
The image size distribution of my generic map is:
<2MB some
2-3MB 260
3-
Both actually. You'll notice that there is no image larger then 8MB,
this is because of my script. The distribution below 8MB is purely the
result of Splitter' behavior.
On 2014-04-29 22:17, Henning Scholland wrote:
Hi Lambertus,
are these numbers the result of your script or the basic result
e that script, too.
If you do that for e.g. Germany, how small is tpically the smallest
*.img file ?
Is it probably near 4 MB?
Gerd
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Tue, 29 Apr 2014 20:30:27 +0200
From: o...@na1400.info
Subject: Re: [mkgmap-dev] mkgmap ToDo list
These are the direct res
Date: Tue, 29 Apr 2014 20:30:27 +0200
From: o...@na1400.info
Subject: Re: [mkgmap-dev] mkgmap ToDo list
These are the direct results from Splitter. The format is o5m, both
input as output. Splitter version is: r321.
For this test I split the original source with --max-nodes=800.
Then
I render
On 30.04.2014 13:36, Lambertus wrote:
To get a better optimum in file size, using the process I described
earlier, you could start off with a huge --max-nodes setting and then
'search' for the highest --max-nodes that works for each specific area.
Well that's basically what I do. I have fo
You apparently do manually over a long timespan what my script
essentially does on each map update run. Attached is my script
(build.php), it will not run it but it might give you an example of how
I implemented this.
The interesting bits are the two functions render() and subsplit(). They
ca
they will be routing nodes.
These special nodes could be counted e.g. 10 times to
give a better estimate.
Gerd
> Date: Wed, 30 Apr 2014 13:36:19 +0200
> From: o...@na1400.info
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> Multithreading
Perhaps you can use this parameter for makensis:
-X'SetCompressor /FINAL bzip2'
bzip2 compresses faster then lzma2
On 30/04/2014 13:47, Felix Hartmann wrote:
plus multithreading the nsis.exe in the background
as nsis packing is super slow... (damn, when will they ever update nsis
to lzma2 and
On 30.04.2014 14:46, Lambertus wrote:
Perhaps you can use this parameter for makensis:
-X'SetCompressor /FINAL bzip2'
bzip2 compresses faster then lzma2
Yes - but far far worse. Making the 2GB limit also 25% nearer...
On 30/04/2014 13:47, Felix Hartmann wrote:
plus multithreading the nsis.
19 +0200
> From: o...@na1400.info
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap ToDo list
>
> Multithreading the tile rendering for a single map is indeed a bit
> difficult and I gave it up because you need to keep track which image
> id's are alread
9:32 +0200
From: extremecar...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
if that doesn't seriously (more than 30-40%) slow down the splitter,
I assume it would be much better...
On 30.04.2014 14:06, Gerd Peterm
splitter?
Gerd
Date: Wed, 30 Apr 2014 14:59:32 +0200
From: extremecar...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
if that doesn't seriously (more than 30-40%) slow down the splitter, I
assume it would be much better...
On 30.04.2014 14:06,
ar...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] mkgmap ToDo list
if that doesn't seriously (more than 30-40%) slow down the splitter, I
assume it would be much better...
On 30.04.2014 14:06, Gerd Petermann wrote:
Hi,
if I got that right the number of
> |http://files.mkgmap.org.uk/download/206/splitter.jar
>>
>> Please let me know if it works as expected.
>>
>> Gerd
>> |
>> ----------------
>> Date: Sun, 4 May 2014 22:20:20 +0200
>> From:
> osm@
>>
--
Date: Sun, 4 May 2014 22:20:20 +0200
From:
osm@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] mkgmap ToDo list
Great, many thanks. I'm currently trying to create as large as
(automatically) possible contour tiles and a lot of t
-dev] mkgmap ToDo list
Great, many thanks. I'm currently trying to create as large as
(automatically) possible contour tiles and a lot of time is put in
subsplitting a tile again and again until two subtiles appear. This
new option would save much time.
On 05/04/2014 10:13 PM, Gerd Petermann
; yes, I want to code that tomorrow. I prefer to make it "give me n
>>> tiles", but if that turns out to be
>>> difficult I try the simple version. I can think of scenarios where
>>> it is not possible to create exactly
>>> n tiles.
>>>
&
46 matches
Mail list logo
