.osm.pbf I can also use a larger file like
> europe-latest.osm.pbf if needed.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Enrico Liboni
> Gesendet: Mittwoch, 10. Juni 2020 23:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-
I would not be
>> surprised to find that Garmin reduces the support for the old format. It
>> may even happen without intention.
>>
>> Gerd
>>
>> ____
>> Von: mkgmap-dev im Auftrag von
>> Enrico Liboni
>>
correctly.
> You should also check the output from splitter reg. the bounds.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag von
> Enrico Liboni
> Gesendet: Mittwoch, 10. Juni 2020 22:49
> An: Development list for mkgmap
> Bet
t; polygons.
> In one command you list the input files, in the other you use *.pbf.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Enrico Liboni
> Gesendet: Mittwoch, 10. Juni 2020 22:19
> An: Development list for mkgmap
> Be
and
sort the result.
On Wed, Jun 10, 2020 at 10:19 PM Enrico Liboni wrote:
> I'm getting a weird behaviour: I merge <5MB pbfs, when using osmium I get
> a 8MB img file while with osmosis it is less than 4MB! The latter seems
> fine since the initial pbfs are less than 5MB. I'd like t
I'm getting a weird behaviour: I merge <5MB pbfs, when using osmium I get
a 8MB img file while with osmosis it is less than 4MB! The latter seems
fine since the initial pbfs are less than 5MB. I'd like to use osmium in my
scripts since it performs better.
Am I doing something wrong? Thanks to
. It is entirely dependent on the device firmware which code
pages are supported.
Gerd
On Wed, Jun 10, 2020 at 12:21 AM Enrico Liboni wrote:
> On my shining new Garmin Zumo XT I can't seem to be able to build unicode
> maps, when I start the device I get "Maps are corrupts and connot be use
On my shining new Garmin Zumo XT I can't seem to be able to build unicode
maps, when I start the device I get "Maps are corrupts and connot be used."
I'm using the latest and greatest mkgmap r4525, fresh pbf from geofabrik -
to reproduce:
wget
not contain ids which overlap the OSM ids.
I just noticed that my file Hoehendaten_Freizeitkarte_EUROPE.osm.pbf
contains node ids starting with 7.500.000.000, so I have to create or
download a new file now.
Gerd
On Mon, Jun 8, 2020 at 10:22 AM Enrico Liboni wrote:
> Hi there.
>
> I
Hi there.
I create my maps with contours using the following command
java -jar ./mkgmap/mkgmap.jar --description="*$family_name - OSM*"
--output-dir="$dest"/ \
--family-id=10030 --product-id=1 --family-name="*$family_name - Map*"
--route --remove-short-arcs --bounds=bounds.zip \
Ticker, Lig - many thanks the lake is back now! I moved 'inc/*_polygons'
as suggested.
I'll test further to see if any adverse impact, but it does not seems the
case so far. Guess this change should be made in the default style in next
release, since we may have other lakes or bays that are
Folks, since sometime Lake Garda in Italy is not rendered correctly. I did
not report this a few months ago since I was using an old version of mkgmap
but I'm now using very latest one and fresh geofabrik pbf but the problem
remains. At a first glance OSM data seems fine:
Steve, thanks for the answer. You'r right, I tested with 3674 and I can
replicate the address search issue, while with 3672 search works ok. So
you'r right that's the version. Also, up to 3672 the typ file used for the
2nd family map 10031 works (i.e. I can see the contour lines as I defined
in
Folks, I had a weird problem I just sorted out - it was known that the
position of the TYP file on command line may have some influence, I
remember I read somewhere it is better to place it at the end as last
argument. What is weird is something happen among r3642 and r3695 which
changed the
make much sense and
> is not very useful for search. For these cases it could be useful to have a
> list of "street names beginnings" to be removed (eg. Calle, Calle de la,
> Calle de el, Calle del, Calle la, Calle, el, etc.)
>
> El 18/09/16 a las 09:33, Enrico Liboni escribi
Is there any difference in how index is build depending on parameters order?
If I use:
--housenumbers --index --gmapsupp
I get a 97888256 byte file
If I use:
--gmapsupp --index --housenumbers
I get a 97884160 byte file
but index search seems to work the very same.
Thanks,
Enrico
Folks the index branch has been merged with main since sometime and the
experimental --x-split-name-index works for me as documented but I still
don't get an optimal user experience.
Example, there might be multiple streets named with the same word (example
in Padova, Italy: Via Dietro Duomo,
le.
>
> At the moment I am looking for a solution for 2 very big parts,
> which are in total bigger than 4 GB.
>
> One idea is to splitt POIs, ways and areas into 3 layers
> and generate every layer into one file.
>
> I have not done it yes, but it could work.
>
> Walter
Folks, if I download two countries pbf from geofabrik, merge them via
osmosis and then build a single img map routing works fine across the
countries.
If I create two img files, one per country and put it on my garmin device,
enable both maps, I can see all the ways seems correctly linked but
-index.
Enrico
On Mon, Jan 12, 2015 at 12:19 PM, Bernd Weigelt weigelt.be...@web.de
wrote:
Am Sonntag, 11. Januar 2015, 22:11:43 schrieb Enrico Liboni:
Pls. let me know your point,
Hi Enrico
when playing around with your rules, i have seen that in the german
speaking
parts of Italy
|IV|V|VI.*|IX|X|XI.*|XV.*|XX.*)' {set
last:word='${name|part: -3}' }
last:word=* { set mkgmap:label:3='${last:word}, ${name|part: -1}';set
mkgmap:label:4='${name|part: 1}' }
On Fri, Jan 9, 2015 at 4:12 PM, Enrico Liboni elib...@gmail.com wrote:
How could I have missed this one...! What
How could I have missed this one...! What is exactly the expected behavior?
In the gmappsupp.img file each word of the street name should be indexed
apart from a country-based list of stop words (pending to be defined) -
right?
Currently I workaround the original issue working with just the
I would be interested as well to know if/how it is possible to include DEM
data directly in the gmapsupp file...
On Mon, Dec 29, 2014 at 11:59 PM, Andrzej Popowski po...@poczta.onet.pl
wrote:
Hi Mike
option --show-profiles sets a flag in TDB file, which is a part of
installation for PC. I'm
ops - you must be right! thanks
On Thu, Oct 23, 2014 at 8:29 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Enrico,
splitter r412 should produce fewer tiles, so one explanation might be that
the last for
tiles were not produced by r412. Since your listing shows different
I updated my splitter version from 314 to 412 - now, it's pretty late but I
read about the new split algorithm that might cause some different sizes
than before, maybe I searched too quickly but I can't seem to explain why
the final gmapsupp went from 87MB to 107MB.
Looking at the split output
Thanks for the feedback.
Andrezej, 0x11 is defined in the TYP file - good catch on the fact *secondary
highways which aren't tunnels are analyzed* at the end - although this
should not impact the tunnels.
Gerd, you are stating the map will contain two lines, since:
highway=secondary [0x04
I'll give a try with your proposal, I believe it might fix the routing
however if I got it right, tunnels will not be visible as per my 1st email
attempt.
On the other side, related to your comment* with your latest rules,
secondary highway with tunnel finishes processing of this object*, I
Dzięki Andrzej! By removing road_class=2 road_speed=3 from the 2nd line,
routing works and tunnels are visible - here is how it looks line:
highway=secondary ( network=e-road | int_ref=* ) [0x04 resolution 18-19
continue]
highway=secondary [0x04 resolution 20-21 continue]
highway=secondary
I'm having troubles on rendering tunnels properly on secondary ways. I have
my typ file with a dark line (0x11), in the line's style file I set:
highway=secondary ( network=e-road | int_ref=* ) [0x04 resolution 18-19
continue]
highway=secondary [0x04 road_class=2 road_speed=3 resolution 20
I experienced the same issue with a my new Montana 600... I first realized
it when I miss a turn and magically I gained 5 mins.
Now I guess I know why!
On Tue, Aug 19, 2014 at 6:56 PM, Bernhard Hiller b...@gmx.de wrote:
Cze´sć Andrzej,
thanks for this (bad) information. Looks like the
interesting... sea in Austria, that's maybe the issue
On Thu, Mar 6, 2014 at 1:26 PM, Felix Hartmann extremecar...@gmail.comwrote:
Oh well - there seems to be some problem with the new sea file:
java.lang.NullPointerException
at
@Thorsten - you could try from command line by using the java jar command:
jar cMf sea.zip sea/*
not sure about the zip version but this should create a separate entry for
sea/ directory as well -
Enrico
On Thu, Mar 6, 2014 at 4:52 PM, Thorsten Kukuk ku...@suse.de wrote:
On Thu, Mar 06,
Glad to hear this! Did you test also the PartFilter one?
Enrico
On Sun, Aug 11, 2013 at 8:38 PM, Carlos Dávila cdavi...@orangecorreo.eswrote:
I have just started to use the new SubstitutionFilter. It's saving a lot
of code, checks for errors, etc. Thanks a lot Enrico.
WanMil, Steve, attached the updated rules-filters.txt (and the
correspondent html version w/ asciidoc).
Thanks for committing this change as well!
Enrico
On Tue, Aug 13, 2013 at 12:24 PM, WanMil wmgc...@web.de wrote:
Hi Enrico,
thanks for your contributions! I am sure Steve will commit
Great! let me know once the PartFiler is committed - if no one has any
issue with it - I'll update the wiki then.
Enrico
On Friday, August 9, 2013, Steve Ratcliffe wrote:
On 09/08/13 09:26, Enrico Liboni wrote:
you deserve credits too... since you had the idea ;)
Hey - I'm not sure how
you deserve credits too... since you had the idea ;)
Hey - I'm not sure how is the process to have this change (and also the
other one on PartFilter) included in mkgmap, I suppose Steve|WanMil
can/will commit this, right?
Enrico
On Thu, Aug 8, 2013 at 12:34 AM, Henning Scholland
}}' }
// a_word [Dd]e [Ee]l anything- a_word, anything [Dd]e [Ee]l
// Calle De el Gato Loco- Gato Loco, Calle De el
highway=* name ~ '.*\s[Dd]e [Ee]l .*' {set new:name='${name|part: 3}},
${name|part: 4}}' }
On Wed, Aug 7, 2013 at 1:06 AM, Enrico Liboni elib...@gmail.com wrote:
It might be useful
I updated the SubstitutionFilter.java class in order to allow regexp on
the subst filters by using the operator ~ to state the first argument
is a regexp. The default behavior is maintained if no operator (i.e.
remove string) or = is used
This is convenient for mass corrections or in case
That's weird... we did the same tests and it fails, but now it is eems it
is partially working fo ryoru... I'll give another try tonight.
On Tue, Aug 6, 2013 at 12:02 AM, Carlos Dávila cdavi...@orangecorreo.eswrote:
El 05/08/13 23:09, Carlos Dávila escribió:
El 05/08/13 19:42, Steve
.
On Mon, Aug 5, 2013 at 11:13 PM, Carlos Dávila cdavi...@orangecorreo.eswrote:
El 05/08/13 23:03, Henning Scholland escribió:
Am 05.08.2013 21:50, schrieb Enrico Liboni:
I believe that indexing just the last word make more sense to avoid a
lot of useless entries, since words in the middle
I tried with 2663 but I did not succeed :( Address search is not returning
any value when I type some letters and tap on done, I tried with my usual
Via Wolfgang Amadeus Mozart but neither with Via Via W Via Wo
Wolf Wolfgang Amadeus Mozart etc. the result is the same: no street
found
However if I
got it - this explains why I was getting different results if compared to
Carlos...
By the way - I got another idea in the meantime that could partially help.
I'm opening another thread for it.
Thanks,
Enrico
On Wed, Aug 7, 2013 at 12:13 AM, Steve Ratcliffe st...@parabola.me.ukwrote:
Hi
I
It might be useful to be able to get the last part of a value list but the
current implementation of PartFilter does not allow this, i.e. you can get
the 1st, 2nd, 3rd and so on but you can't get the last, the one before the
last and so on.
The change is trivial, in doFilter replace:
if
Folks, as you know – this comes up time to time – address search is
unpractical in most Latin countries where the street/square name usually
starts with the type (Via, Viale,Corso, Piazza etc [IT]; Avenida, Calle,
Plaza etc [ES]; Avenue, Boulevard, Rue, Place etc [FR] etc.) followed by
the
2013
El 05/08/13 12:50, Enrico Liboni escribió:
I'm working on that since a few weeks ago for Spanish and Catalan, but
it takes quite a long time to find all combination possibilities and
also to fix all errors in the names I'm finding in the OSM data. As an
example, you can see the line
Steve you are the man! I'm rebuilding my map now. By the way, I believe
that indexing just the last word make more sense to avoid a lot of useless
entries, since words in the middle are usually first names or prepositions.
I'll have a try and let you know. Thanks!
Enrico
On Mon, Aug 5, 2013 at
file in precompiled sea directory sea_20130701.zip
but the file index.txt is there (in .gz format) in WanMil's zipped
sea_20130701.zip
Any clue?
Thanks again
Enrico
On Mon, Aug 5, 2013 at 9:50 PM, Enrico Liboni elib...@gmail.com wrote:
Steve you are the man! I'm rebuilding my map now
Strange it seems for me ORS is working,
http://www.zimagez.com/zimage/screenshot-04062013-095909pm.php
On Fri, Apr 5, 2013 at 11:36 AM, chris66 chris66...@gmx.de wrote:
could be these 2 steps-islands:
http://www.openstreetmap.org/?mlat=45.6603mlon=12.25836zoom=18
Indeed, routing
Marko, Chris
thanks a lot, I'll give a try with the styles - actually I'm not using
any custom style. One strange behavior I loaded the very same map in
another Garmin device (different model) and I can route to it properly -
but I did not disable the basemap so maybe it's defaulting to it and
Folks, I'm sometime getting routing issues to some POIs - most seems ok but
some are always showing the problem. I'm wondering if what I'm hitting is
the problem described at:
http://wiki.openstreetmap.org/wiki/Mkgmap/known_issues#add-pois-to-areas_sometimes_places_the_POI_outside_the_polygon
gmapbmap.img to gmapbmap.iii and restart the
device, the result is worste since it can't route to most POIs/address
now.
By the way this also means that gmapbmap has some relations with
routing on the osm map... confused!!!
Enrico
On Sat, Mar 30, Enrico Liboni wrote:
* Folks, I'm sometime
outside the proper polygon).
Thanks again,
Enrico
On Sat, Mar 30, 2013 at 5:01 PM, Thorsten Kukuk ku...@suse.de wrote:
On Sat, Mar 30, Enrico Liboni wrote:
If I go to Tools-Settings-Map-Map Info only the OSM map is enabled.
However I believe the basemap - if I understood correctly what
Hi, today I upgraded mkgmap from r2307 to r2423 and downloaded fresh pbfs
and bounds before regenerating my maps: the gmapsupp file is created
correctly but address search does not work as expected.
When searching for an address, if I select Italy and try to type a city
only a dozen are available
Thanks for the feedbacks, I don't think I'm creating imgs files and then
merge them - as Colin is doing. What I do is the following:
1. download some countries *.pbf files from geofabick and place in a $DATA
folder
2. run splitter on them (java -jar $SPLITTER_HOME/splitter.jar
--output-dir=$DATA
several attempts and all seems
fine.
Thanks,
Enrico
On Sun, Jun 24, 2012 at 3:08 PM, Enrico Liboni elib...@gmail.com wrote:
Thanks for the feedbacks, I don't think I'm creating imgs files and then
merge them - as Colin is doing. What I do is the following:
1. download some countries *.pbf
Routing works excellent on my Nuvi except when the Start/End points are in
different countries; if it is the case:
1. the device takes a lot (minutes) to calculate the route - also if the
two points/cities are pretty close, while for routes within the same
country takes seconds.
2. the route to
Hi - to test if --index now works out of the box, I just used mkgmap r2226
to generate a gmapsupp.img for my Nuvi SD card (I'm a linux user, no
mapsource).
It works! However street name search string need to start exactly with the
street name prefix entered in OSM, example: for a street (via in
57 matches
Mail list logo
