Areas only cover Finland :-(
http://maps.google.com/maps?q=roettsches.de%2Fdominik%2Fareas.kml
Sorry, that link didn't work, here's the right one:
http://maps.google.com/maps?q=http%3A%2F%2Froettsches.de%2Fdominik%2Fareas.kml
d
___
mkgmap-dev
On Wed, Apr 27, 2011 at 10:14:14AM +0300, Dominik Röttsches wrote:
Can I tell the splitter to ignore the map's bounding box altogether and
find its own? Any other ideas how to make it take into account the
whole merged map?
Can you split each extract separately and then tell mkgmap to produce a
Version 1926 was commited by steve on 2011-04-27 09:21:37 +0100 (Wed, 27 Apr
2011)
When sorting, characters that have a sort position of zero
t a given strength are treated as if they were not present.
This mainly affects how shields are treated in sorting. They are now
ignored, except
How do I run osmosis in a windows batch file? If I put this line in the
osmosis.bat file:
set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways boundary=administrative
-tf accept-relations boundary=administrative --used-node -wx
europe-boundaries.osm
I get this error: only one default
Hi Marko,
Can you split each extract separately and then tell mkgmap to produce a
map from the tiles generated by the three splitter runs?
Good idea, thanks. Generation seems to have worked, at least combining Finland
and Germany. When adding US, it complained map area too small to split.
This is a copy of my windows Bat file. Hope it helps.
bin\osmosis.bat -v --rx -b5 enableDateParsing=no file=planet.new.osm.gz
--bb top=-6 left=107.1 bottom=-48 right=163.5 completeWays=yes
completeRelations=yes --wx -bc5 file=o:\garmin\splitter\Australia.osm
Regards,
Markus_g
You need to - infront of tf. --tf instead of -tf ;)
Henning
Am 27.04.2011 12:01, schrieb Minko:
How do I run osmosis in a windows batch file? If I put this line in the
osmosis.bat file:
set OSMOSIS_OPTIONS=--rb europe.osm.pbf -tf accept-ways
boundary=administrative -tf accept-relations
Thanks Henning,
Probably in front of wx as well, otherwise I got an error again. Now it's
running.
set OSMOSIS_OPTIONS=--rb europe.osm.pbf --tf accept-ways
boundary=administrative --tf accept-relations boundary=administrative
--used-node --wx europe-boundaries.osm
I came across a similar problem last year. The trouble was with the
merge function of osmosis. It takes the bounding box of the output file,
from the first input file, regardless of the bounding boxes of the other
input files. But the data from all the input files is in the merged
file. I
On Wed, Apr 27, 2011 at 02:48:03PM +0100, Adrian wrote:
I worked around this problem, but it is not at all convenient. You
create the output file in uncompressed .osm format. This can result in
a large file. Then you edit the file with a hexadecimal editor, because
it will be too large to edit
Thanks WanMil,
just two questions are left:
What about location-autofil and index? Are they needed both or just index?
index is required. location-autofill should be set to 0.
Is it possible to input boundary-file as pbf?
Not yet, but that's easy to implement so I will add it soon.
WanMil
Just run a small test, if I dont specify boundsdirectory, mkgmap complains
about no boundary directory found.
I got a few 'file not found messages' but I think they were caused by the fact
that I ran osmosis with a bounding box that was too small (didnt want to
process whole europe). The first
With a boundsdirectory it went fine. I haven't paid attention to the
performance, with a few tiles it was ok I guess. I'll try to compile the whole
Benelux end of this week and compare the processing times.
The osmosis step took a lot of time, I'm now trying a bigger bounding box (with
whole
Hello
Here is a new patch. I have reproduced the actual error you see on a
gmapsupp of 1.2G. This patch fixes that and also the other cases I believe.
The patch still has the debugging in. If it still fails, could you send
me the output again.
There is no need, for the purpose of testing
done with the path and the last data.
create header 512
dir: header blocks(slots) 4
dir: headerBlocks 7
header blocks needed 1
dir: end slot 7
file size in blocks 18
bs 512: tot blocks 1778759, tot header blocks 7766
bs 1024: tot blocks 889549, tot header blocks 2037
bs 2048: tot blocks 444934,
I plan to add an R*-tree to get a better performance in the locator
branch. Maybe this might be reused.
If someone (Daniel?) likes to implement the R*-tree please lift your
fingers. I am not very keen on doing this and it would help a lot!
Have you looked around, if there is some
16 matches
Mail list logo
