Hi Gerd,
On Mon, May 27, Gerd Petermann wrote:
> Hi Thorsten,
>
> I am not sure: Do you still have this problem? I was not able to reproduce it
> with the
> your style files in the git repo (commit
> f6e5f5404048e043499a7c299886ac7d2d3fd263)
Which git repo? I don't use git...
I only need o
Hi Thorsten,
> > I am not sure: Do you still have this problem? I was not able to reproduce
> > it with the
> > your style files in the git repo (commit
> > f6e5f5404048e043499a7c299886ac7d2d3fd263)
>
> Which git repo? I don't use git...
sorry, I confused the nick names. I tested with
https:
Hi Minko,
it is quite easy to exclude the ovm_* files, but you can have similar problems
with other files like
the default overview file osmmap.img.
I am not sure what to do in this case, as the name is configurable.
@Steve: Is there a simple way to identify an img file that contains the
ov
Hi Gerd,
Well, the point is that a default overview file has to be made out of those
img's, so it wont be there yet.
> it is quite easy to exclude the ovm_* files, but you can have similar
> problems with other files like
> the default overview file osmmap.img.
> I am not sure what to do in thi
Hi Minko,
it might be there if you execute mkgmap twice, once with *.osm as input,
next time with *.img
I am not sure yet if the other combiner options like --gmapsupp, --index
etc. have problems with this.
Gerd
Minko-2 wrote
> Hi Gerd,
>
> Well, the point is that a default overview file has t
Hi,
is there a way to recognize this situation in mkgmap and issue a warning?
I guess there should be no type 0x4a or 0x4b polygon in the input files when
creating
the gmapsupp?
Gerd
Minko-2 wrote
> Ah, I think what goes wrong.
> You merged the contour lines tiles together with the osm map.
>
Hi,
The 0x4a/0x4b polygon shouldn't be a problem as long as the upper map is
transparent.
But there are more issues with combining two map layers on top of each other, I
noticed that merging img layers that were made with a different versions of
mkgmap also leads to rendering problems. Don't kno
Yes, I agree this will lead to problems and it would be better if mkgmap also
recognize and skips processing the overview img and other index img's
(*_mdr.img) before compiling img tiles.
> it might be there if you execute mkgmap twice, once with *.osm as
> input,
> next time with *.img
> I am
Hi Gerd,
Here is an example where I combine several img's, for instance to merge
Lambertus img tiles into one big map or to add contour lines or hiking routes:
http://www.openfietsmap.nl/downloads/osm_combi
I have to filter out the index img's and overview img's with several batch
files, so if m
Jepand it is working as expected. There is only a problem with
international cycle-routes in level 7 (res 14). They are not rendered
completely, but I'm investigating it. So don't know jet if it's a
problem in mkgmap or in style or in osm-relation (maybe to many
subrelations)
Henning
Am 27.
Hi Minko,
reg. problems with different mkgmap versions:
I think this should not happen, but I have no idea why it fails.
Can you tell me two release versions that show this problem?
Or can you post two img files (one good, one bad) created with
different mkgmap versions but no other changes?
Mayb
Hi Gerd,
Thats a bit difficult to reproduce. In the past I noticed this quite often,
but maybe because I've been changing the parameters with the newer mkgmap
versions.
I'll let you know when I see this happening again.
One example where I can see this behaviour, are the velomaps with contourlin
Hi Minko,
is it possible that it depends on the bbox of the tiles?
Gerd
Minko-2 wrote
> Hi Gerd,
> Thats a bit difficult to reproduce. In the past I noticed this quite
> often,
> but maybe because I've been changing the parameters with the newer mkgmap
> versions.
> I'll let you know when I see
Hi Minko,
I did not try your batch file, but r2623 will ignore ovm_* files specified as
command line args.
It will still put the overview map into the gmapsupp if you use something like
mkgmap --gmapsupp *.img
Gerd
> Date: Mon, 27 May 2013 12:05:11 +0200
> From: ligfiet...@online.nl
> To: mkgm
Thanks Gerd,
r2623 ignores now ovm files as expected.
Could you implement the commit from mkgmap-r2606 into the overview branch,
because the non routable lines are still deleted?
And in the points style file I would suggest to replace (place=capitol |
place=capital) with place=city from the li
Hi,
I've committed r2624 in the overview2 branch:
-merged with trunk and applied changes suggested below.
I want to find the cause for the polygon type 0x4a errors before I merge it
back into trunk.
Ciao,
Gerd
Minko-2 wrote
> Thanks Gerd,
>
> r2623 ignores now ovm files as expected.
>
> C
The problem only exists in Mapsource. Basecamp/GPS have no problems.
I'm still of the very strong opinion - that merging contourlines based
on viewfinderpanoramas.org data - is not possible under odbl/viewfinders
license. So for me Freizeitkarte is a very strong breach of odbl usage
conditions.
I have been running mkgmap with only occasional issues for a long time.
I just updated to the latest svn, and got an assertion. This was with
java 1.6 on a mac, so I updated to 1.7.Then, I still get an exception:
+ java -enableassertions -Xmx3072m -jar mkgmap.jar --max-jobs --latin1
--descr
On Mon, May 27, Felix Hartmann wrote:
> I don't think you can create a garmin map - and say that the .img files
> - are under a NC license - the .img must stay under odbl. If someone
> could clear this up - perfect.
If you follow the various dicussions on osm.org: the .img can be under
any lice
Hi Greg,
Greg Troxel wrote
> I have been running mkgmap with only occasional issues for a long time.
> I just updated to the latest svn, and got an assertion. This was with
> java 1.6 on a mac, so I updated to 1.7.Then, I still get an exception:
if you compile from source, please use
ant
Hi Minko,
forgot to answer this part:
> The 0x4a/0x4b polygon shouldn't be a problem as long as the upper map is
> transparent.
If you create a map and don't use --transparent, mkgmap will add the 0x4b
polygons.
My idea was that mkgmap could detect if two overlapping parts both contain 0x4b
p
Hi Felix,
I think the problem is caused by the bounding boxes of the tiles.
Please send me splitters areas.list (or whatever you have)
of all the tiles that you are processing when this error occurs.
The data below looks like you have a tile that (almost) spans planet?
Gerd
Felix Hartmann-2 wro
Hi Gerd
> If you create a map and don't use --transparent, mkgmap will add the
> 0x4b polygons.
> My idea was that mkgmap could detect if two overlapping parts both
> contain 0x4b polygons as
> this is a hint that one was not properly created with --transparent,
> but maybe this will not
> always
23 matches
Mail list logo
