The European boundaries compiled by WanMil are available for download:
http://www.navmaps.eu/wanmil/europe_bounds_20110429.zip
Johan
On Fri, 29 Apr 2011 22:49:54 +0200, WanMil wrote:
> Great! That was a silly bug...
>
> I think I found another big issue that affects quite a lot of
> bound
Hi WanMil
you did a very, very fine job on the locator and especially with this
version 1935. In my opinion it's only a short time now before the
locator branch is to be integrated into the core. Cities ánd streets
which I couldn't find using version 1930 can now be found in the Garmin
i
in addition to Minko: according to
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
Belgium provinces should all be in admin_level 6
For Luxembourg: the cities are all in admin_level 8, the provinces (I
think the Luxembourg name 'district' comes closest) are in admin_level
The Luxembourg country border been fixed in JOSM (nice to have
validator around!). However, still some validator errors for the France
border relations. Hopefully some French mappers step in to update these
borders.
Cheers Johan
On Wed, 04 May 2011 19:32:07 +0200, Josef Latt
wrote:
>
, can be found in Garmin
(1) Groussherzogtum Lëtzebuerg (2) Luxembourg (3) negative, can't be
found in Garmin
(1) België - Belgique - Belgien (2) Belgique (3) negative, can't be
found in Garmin
Cheers, Johan
On Wed, 04 May 2011 22:23:54 +0200, navmaps wrote:
> in addi
Hi Carlos, it's my experience that skipping is_in, addr: and openGeoDB
works best for the Garmin index. What you'll then see is that some OSM
boundaries need to be improved. But getting that done will create a
perfectly working index (except for adresses, but it's always nice to
have some
I'm a proponent of skipping is_in and openGeoDB completely:
1. that shifts the attention in the right way: to improve faulty
boundaries.
2. I noticed that using is_in and openGeoDB caused a multiple country
selection in my Garmin for the same country; (on my Garmin) it's
technically bette
I've had a similar problem for Belgium. It appeared as 'Belgique' (the
name in the Locator config) and as 'België - Belgique - Belgien' (the
name in the admin_level 2 relation). Since I stopped using is_in and
openGeoDb in my style files my problem on Belgium disappeared.
Cheers, Johan
O
is used as primary boundary (both before admin_level 8 is
used in the style files).
Cheers, Johan
On Sat, 07 May 2011 23:25:03 +0200, Carlos Dávila
wrote:
> El 06/05/11 17:41, Carlos Dávila escribió:
>> El 05/05/11 00:50, navmaps escribió:
>>>Hi Carlos, it's my e
A few days ago I tried --rb file=d:\europe.osm.pbf --tf accept-ways
boundary=administrative --used-node --write-xml
file=d:\mkgmap-europe-boundaries.osm
Thus I created 1.508 bounds files and a workable map (still a few
problems finding cities and streets through cities -> selects streets,
but
Hi Wanmil
I don't propose spending too much time working on efficiency. First of
all: a boundary is a boundary. All elements inside should exactly match
the 'real world' boundary in order to avoid highways to be found in the
next city. Second: there's still some quality problems in the locator
Dear Wanmil
1. I would like to see it merged, you've done a great job on it
2. bug 1: please add 'België - Belgique - Belgien' to LocatorConfig.xml
3. bug 2: it's impossible to get the Dutch city of Middelburg in the
index. I did a test changing the boundary name to Middleburg which
worked great
However, for the first time (ever in my short mkgmap map making life) I
get an error when Mapsource builds the index. Everything was fine till
locator version 1969. Locator version 1977 gives a
MDR_TRIM_ADDR.CXX-440.6.16.3.0 error code.
I'll try another test run tomorrow
Cheers, Johan
On Thu,
My 2nd attempt, running mkgmap again, also failed and produced the same
error message. Index building on smaller sized maps (< 100 Mb) is ok.
Yet, I suppose that somehow a bug has been introduced between locator
1969 and locator 1977
Johan
On Thu, 23 Jun 2011 23:45:06 +0200, navmaps wr
It appears someone (I can't find out who) likes the boundary_segments a
lot. The three boundary_segments of Luxembourg now make up the
Luxembourg border. That's in my opinion inconsistent with map_features
and with the tagging of all other European countries. Personally I
dislike boundary_segme
I've send Loll78 a message to check into this discussion, let's hope he
responds. It has to do with a proposed relation change which seems to be
intended to be applied to the France border. Luckily that border hasn't
changed yet. Take a look at
http://wiki.openstreetmap.org/wiki/Relations/Propo
r European/worldwide countries. My changeset: 8715072, new
relation number for the Luxembourg border: 1662399.
Cheers, Johan
On Mon, 11 Jul 2011 20:04:22 +0200, navmaps wrote:
> I've send Loll78 a message to check into this discussion, let's hope
> he
> responds. It has to do with
I noticed that level 8 boundaries in Germany use the name of the city,
and that lavel 8 boundaries in Austria always have the prefix 'Gemeinde'
in the name before the name of the city. That prefix is in my opinion
obsolete information. Using a Garmin one always needs to type this
prefix 'Gemein
+ 1 for the merge.
I would also like to see address search possible, but the question is:
who has the information to program that into mkgmap?
Cheers, Johan
On Mon, 18 Jul 2011 20:41:17 +0200, Felix Hartmann wrote:
> Well I still don't like the results, but if it's fully optional and
> the
> o
WanMil compiled new boundaries for (1) Europe and (2) worldwide. Both
files are available in the developers section of www.navmaps.eu
Cheers, Johan
On Sun, 15 May 2011 17:11:45 +0200, WanMil wrote:
> .. can be downloaded from
> http://www.navmaps.eu/wanmil/europe_bounds_20110515.zip
>
> The for
Thanks, works great! I have no ideas yet to further improve the filter
function.
On Sat, 23 Jul 2011 14:14:43 +0200, WanMil wrote:
> Hi,
>
> the style system provides a substitution filter which can remove the
> 'Gemeinde' prefix:
>
> The following rule from the locator branch is expanded with
>
benefit from the changes you need to use bounds that are
>> preprocessed
>> by r2013 or later. I will do that within the next days and upload
>> them
>> to the navmaps page.
>>
>> r2013 still can use the old preprocessed bounds because the format
>> is
>&
Thanks Steve. I don't have any memory problems using 2042. (-Xmx16000M
with 16G memory on board, compiling about 75% of the Geofabrik Europe
map)
Cheers, Johan
On Fri, 30 Sep 2011 14:22:50 +0100 (BST), svn commit wrote:
> Version 2042 was commited by steve on 2011-09-30 14:22:50 +0100 (Fri,
> 3
It might be handy to get the mistakes out of mkgmap before updating it
with new features to 2108 etc.
1. Steve's patch on the error as reported by Jonas is not committed yet
2. version 2106 introduced a second error in handling the style files
Cheers, Johan
On Mon, 21 Nov 2011 20:09:32 + (
@ 1: sorry, I don't have the Java knowledge to test patches
@ 2: using thedefault styles:
at uk.me.parabola.mkgmap.osmstyle.StyleImpl.(StyleImpl.java:140)
at
uk.me.parabola.mkgmap.osmstyle.StyleImpl.readBaseStyle(StyleImpl.java
:518)
Cheers, Johan
On Mon, 21 Nov 2011 22:37:25 +, S
I found the problem. The info file in styles/default contains an error:
the words 'summary: The default style' are not preceded by a '#'
Cheers, Johan
On 22.11.2011 00:21, Steve Ratcliffe wrote:
> Hi
>
> Again I don't see that, but the top part of this stack trace is
> missing
> so I can't tell
Correction: the words 'base-style=location' in the info file are not
preceded by the '#'
On 23.11.2011 19:45, navmaps wrote:
> I found the problem. The info file in styles/default contains an
> error:
> the words 'summary: The default style' are not pre
With both my maps I've no difference between Mapsource and the search
results in my Nüvi 205. However, my Central Europe map shows both the
Friedrichstrasse in Spandau close to the roundabout and the
Friedrichstrasse close to the Unter den Linden. My North-West Europe map
(build with the same p
28 matches
Mail list logo
