Hi WanMil,
this doesn't seem to work. I still see the tag in the precompiled
sea data:
tag k=natural v=sea/
tag k=mkgmap:cache_area_size v=1048709826.5/
I don't fully understand the idea. The current implementation seems to
calculate the value when precompiling
Am 22.01.2014 21:28, schrieb Thorsten Kukuk:
When debugging this I found out that there are a lot of
maxspeed=none tags at least in my area, which leads to a
set mkgmap:road-speed-class = 0, which is of course really slow.
Are you using the default-style-rules?
Chris
On Thu, Jan 23, chris66 wrote:
Am 22.01.2014 21:28, schrieb Thorsten Kukuk:
When debugging this I found out that there are a lot of
maxspeed=none tags at least in my area, which leads to a
set mkgmap:road-speed-class = 0, which is of course really slow.
Are you using the
Am 23.01.2014 10:59, schrieb Thorsten Kukuk:
maxspeed=* mkgmap:road-speed-class!=* maxspeedkmh()=* { set
mkgmap:road-speed-class = 0 }
And if I understand this correct, everything not numeric
will map to mkgmap:road-speed-class = 0.
Which is Ok for maxspeed=walk, but not maxspeed=none.
Hi Thorsten,
I cannot reproduce your problem.
maxspeed=* mkgmap:road-speed-class!=* maxspeedkmh()=* { set
mkgmap:road-speed-class = 0 }
does not fire if maxspeed=none because in this case maxspeedkmh()=* is
evaluated to false.
To ensure that is does not fire you can add the echotags
Version mkgmap-r2981 was committed by wanmil on Thu, 23 Jan 2014
Do not calc the area size on sea precompilation (now really :-).
In r2971 I errorneously thought that precompilation uses the SeaPolygonRelation.
___
mkgmap-dev mailing list
Hi Gerd,
thanks for the hint. It's fixed now.
I have no time to test your patch now but it sounds good :-)
WanMil
Hi WanMil,
this doesn't seem to work. I still see the tag in the precompiled
sea data:
tag k=natural v=sea/
tag k=mkgmap:cache_area_size
Hi WanMil,
I just found Path2D.append(Shape s, boolean connect) which seems to do the same
as the addToPath() method. The advantage compared to multiple Area.add() calls
is that
each Area.add() call also tries and remove obsolete points and dangling edges.
The more edges an Area has, the more
Hi,
I found out that the boundary of France in bounds_20140101.zip
(http://www.navmaps.eu/boundaries) might be broken. Places in France are not
assigned to France anymore. If I use the previous bounds file
(bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
Hi Minko,
the boundary relation 2202162 was changed 5 or more times since 2014-01-01.
You can check yourself using a command like this:
java --Xmx6800m -cp d:\mkgmap\dist\mkgmap.jar
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryCoverageUtil
bounds_20140101.zip log
This will take a while
Hi Patrik,
it's bad. A good picture would not show any line between France and its
neighbours
on the continent.
Sorry for the typo, I use some more options for debugging and removed them
after copy+paste.
Gerd
Patrik Brunner wrote
Is that now good or bad ?
It's still running on
No Problem, Gerd.
BTW: looks like Norway has the same problem... didn't check deeper for
others, but those too (France and Norway) were quite promient.
Just to confirm: it doesn't matter that the command is still running ?
it did already create the level 2 files, seems to run through the
Patrik Brunner wrote
Just to confirm: it doesn't matter that the command is still running ?
it did already create the level 2 files, seems to run through the levels
by admin level I assume it doesn't 'revisit' admin level 2
yes, it goes from level 2 to level 11, so you can stop it.
The
Am Donnerstag, 23. Januar 2014, 22:18:50 schrieb Patrik Brunner:
BTW: looks like Norway has the same problem... didn't check deeper for
others, but those too (France and Norway) were quite promient.
Take a look at level 3, there is france, norway and other
--
amarok2 now playing:
Thanks Patrik for testing, yes Norway seems broken too in my mapsearch.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Minko,
mkgmap can give you hints what's wrong while precompiling the bounds.
The bounds_XXX.zip file does not contain any hint about the problem.
But the easiest solution is to open the admin_level=2 boundary relation
with JOSM.
I did that for Norway and France and they are looking good
Hi Bernd,
yes, that's typical. I assume the level 2 relations were broken
on 2014-01-01. The one for France was okay when I tested it today.
Gerd
Bernd Weigelt wrote
Am Donnerstag, 23. Januar 2014, 22:18:50 schrieb Patrik Brunner:
BTW: looks like Norway has the same problem... didn't check
Selon GerdP gpetermann_muenc...@hotmail.com:
Hi Bernd,
yes, that's typical. I assume the level 2 relations were broken
on 2014-01-01. The one for France was okay when I tested it today.
Gerd
Hi, Frenchman here,
Yes, there was a lot of work going on on the national boundaries around new
Hi Wanmil,
Dont know how to compile the bounds, I'll use yours.
Thanks in advance for recompiling them.
Hi Minko,
mkgmap can give you hints what's wrong while precompiling the bounds.
The bounds_XXX.zip file does not contain any hint about the problem.
But the easiest solution is to open
19 matches
Mail list logo
