Am Freitag, 27. Februar 2015, 13:05:37 schrieb GerdP:
the file mkgmap.log.2 doesn't contain any line
regarding file 65001032, but 6532.
Is there a trick ?
There is no trick ;-)
the '1' is part of my map id, because i build different layers
Splitter tile 6500'0'xyz
Bonn Basemap
Am Freitag, 27. Februar 2015, 13:49:28 schrieb GerdP:
I see Bergisch Gladbacher Straße only as B506 Bergisch Gladbacher
Straße.
Did you search for that?
Similar L361 Aachener Straße.
I searched by enter city, streetname and a existing housenumber
Bergisch Gladbacher Straße 795
Am Freitag, 27. Februar 2015, 14:59:50 schrieb GerdP:
Hi Gerd
do you get better results with the trunk version?
I have created my maps with trunk over a long time with no problems, the
address search works.
If not, I think it is a problem with the indexes, not with
the housenumber code.
Am Samstag, 21. Februar 2015, 18:17:35 schrieb Bernd Weigelt:
not only the north sea, other sea polygons, too
i use these options to create my maps over a long time
Found the solution, error or what ever
I had no polygon 0x32 in my TYP file, only this line in water_polygons
natural=sea { add
Am Samstag, 21. Februar 2015, 09:00:50 schrieb Arndt:
Can you help me?
Hi Arndt
as workaround you can use the file from February, 6th.
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi
not only the north sea, other sea polygons, too
i use these options to create my maps over a long time
for my own devices i use a smaller daily used map around bonn/germany without
any coastline, so i can't say what is wrong and since which time.
as example the command line options for the
Am Donnerstag, 19. Februar 2015, 20:15:08 schrieb Stéphane MARTIN:
Thank you Gerd !
Tested with r3471, seems to work ok, will test over the next days.
Bernd
--
amarok2 now playing:
artist: The BossHoss
title: My Favorite Game
album: Rodeo Radio
___
Hi
who is the maintainer für the files on http://osm2.pleiades.uni-wuppertal.de ?
the bounds file from 19.02.2015 is buggy, i got the same problems as on end
January http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2015q1/022634.html
Bernd
--
amarok2 now playing:
artist: The BossHoss
title: My
Am Donnerstag, 19. Februar 2015, 11:02:04 schrieb Thorsten Kukuk:
For, it looks like it's ending in an endless loop.
Maybe the same problem here, but it's seems to happen after the last tile.
The build porcess hangs now over 15 minutes
Please, give give me a hind which logging options are
Am Donnerstag, 19. Februar 2015, 12:14:59 schrieb Bernd Weigelt:
Am Donnerstag, 19. Februar 2015, 11:02:04 schrieb Thorsten Kukuk:
For, it looks like it's ending in an endless loop.
Maybe the same problem here, but it's seems to happen after the last tile.
The build porcess hangs now over
Am Montag, 9. Februar 2015, 09:11:43 schrieb Gerd Petermann:
Hi Gerd
yes, got that in my mind when I proposed my 2nd alternative,
but it should probably be something like
railway=* !(tunnel=yes) (building=no ! building!=*) [0x14 resolution 22]
Or maybe we should add a general rule
Am Sonntag, 8. Februar 2015, 14:51:43 schrieb Bernd Weigelt:
looks like a lot of work
BTW
is really simple to remove unused colours with TYPwiz4, need only four or five
clicks with the mouse
very nice tool
Bernd
___
mkgmap-dev mailing list
Am Samstag, 7. Februar 2015, 11:21:53 schrieb Steve Ratcliffe:
I like the idea of having patches where they can be viewed
and tracked. Having a build available for the patch would
be a good idea too. So I will look into adding this
Please be sure, that no one add a patch with a backdoor or
Am Montag, 2. Februar 2015, 10:27:46 schrieb Gerd Petermann:
Hi Bernd,
you can enable logging with
uk.me.parabola.mkgmap.osmstyle.RuleSet.level=FINE
and look for messages containing this:
skipping part of rule
Hello Gerd
Wow, made a fast test with my Bonn extract, 1 GB logfiles with
Am Sonntag, 1. Februar 2015, 11:42:38 schrieb GerdP:
This is clearly not intended and should be fixed.
Hi
FYI
Franco fixed this in May 2014 in our style with this workaround
https://github.com/berndw1960/aiostyles/commit/0209b139bd7ec07ff24a31d86ba30194b5b2f268
public_transport=platform
Am Mittwoch, 7. Januar 2015, 18:29:02 schrieb Bernd Weigelt:
Am Mittwoch, 7. Januar 2015, 18:11:29 schrieb Bernd Weigelt:
And where is my error?
Found one of my errors, because the node belongs to four route relations.
http://www.openstreetmap.org/node/31172863
ok, thats the reason
Hi
since a few days, don't know the exact date, i have problems with the address
search in Germany on my Oregon 650. The problem is not related to the new
firmware 4.40, i got it also with 4.30
A, hopely understandable, description
search for an address, before the problem i got a menu
first
Am Mittwoch, 28. Januar 2015, 12:12:25 schrieb Maxim Düster:
Hello!
type=route route=bus ref=* {
apply {
set route_ref='$(route_ref),${ref|not-contained:,:route_ref}' |
'$(route_ref)' | '${ref}'; }
}
This should possibly answer my question from January, 7th
thank you
Am Mittwoch, 28. Januar 2015, 07:55:43 schrieb GerdP:
1) the tag mkgmap:admin_level2 is missing, so
that seems to be a problem in the bounds file.
2) your style rules in inc/address do not yet use the country-ISO
filter. The default style looks like this now:
# first set the country code
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, Switzerland. France, Luxembourg and Belgium a lot of streets
are tagged with 'An, Zum, In, ...' This
Hi
i'm playing around with the PT rules in relations, as example this node [1].
The node belongs to two route relations (RE8 and RB27) and one track relation
(2324)
When i enable the rules in relations i got the labels
Unkel (Re8,re8,rb27,rb27)
my wanted result is to get only one entry per
Am Mittwoch, 7. Januar 2015, 18:11:29 schrieb Bernd Weigelt:
And where is my error?
Found one of my errors, because the node belongs to four route relations.
http://www.openstreetmap.org/node/31172863
ok, thats the reason for the double entries, but how can i filter them?
Bernd
Am Montag, 29. Dezember 2014, 14:58:30 schrieb Gerd Petermann:
It should have a tag like mkgmap:car=no.
ok, that is another new thing for me ;-)
i'll try it asap
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am Montag, 29. Dezember 2014, 16:33:43 schrieb Bernd Weigelt:
Am Montag, 29. Dezember 2014, 14:58:30 schrieb Gerd Petermann:
It should have a tag like mkgmap:car=no.
ok, that is another new thing for me ;-)
i'll try it asap
Bernd
done, works as expected
thx
Bernd
Am Sonntag, 28. Dezember 2014, 18:04:48 schrieb Helge Olav Helgesen:
Hi
I noticed this when my GPS sent me through this
i noticed this some days ago with my Oregon 650 and this
https://www.openstreetmap.org/node/1758316328
First i thougt, i used the bike mode, but it was in the car mod, too
Am 20.12.2014 um 22:25 schrieb Stéphane MARTIN:
Le 20/12/2014 17:50, Stéphane MARTIN a écrit :
Hi,
I got this line in a log file :
2014/12/20 17:36:29 GRAVE (StyledConverter): 29730001.o5m: Attention:
Tile contains both drive-on-left (95) and drive-on-right roads (7568)
It's because
Am Sonntag, 21. Dezember 2014, 09:49:51 schrieb Bernd Weigelt:
I have seen the same problem on Dec.19th with my chinese extract, maybe
while hongkong drives on left?
In my case the problems/messages are here
mapname: 6511
description: PK-Lahore
input-file: 6511.o5m
mapname: 6513
Am Sonntag, 21. Dezember 2014, 12:02:32 schrieb Gerd Petermann:
this part of the source is rather old, please post
data that allows to reproduce the problem.
Ok, i'm now uploading the files to http://files.mkgmap.org.uk/, it seems that
6519.o5m is corrupted.
china.o5m is cut out from a
Am Sonntag, 21. Dezember 2014, 07:35:03 schrieb GerdP:
the problem was caused by a missing check for an empty map.
I've changed that with r3388.
I am not sure what you mean with corrupted data. The file seems
to be ok for me.
I've got 2 tiles with a size of 30 Kb and the new extract of
Am Samstag, 25. Oktober 2014, 09:31:33 schrieb Gerd Petermann:
if I got it right, the idea is to use the prefixed tags
like mkgmap:bicycle only in the finalize section.
So that would include also the setaccess and addaccess actions.
Don't know if the current rules in inc\access are meant to
Am Samstag, 25. Oktober 2014, 10:23:13 schrieb Gerd Petermann:
I think we also have to add
include 'inc/address';
to the polygon rules.
+1
this is my finalize section in polygons for a long time
finalize
# The finalizer section is executed for each element when a rule with an
element type
Am Samstag, 25. Oktober 2014, 10:57:05 schrieb Gerd Petermann:
If I got it right, the housenumber code is only interested in streetnames
given by mkgmap:street or addr:street. These may also be set in inc/address,
but I don't think that this has an effect on the housenumber code.
Do you
Am Samstag, 4. Oktober 2014, 09:38:35 schrieb Gerd Petermann:
Hi
It stores the roundabout once as
roundabout, once as a normal street, so that the device shows the correct
color and bitmap, but obviously this confuses the algo in your device.
The v5 and v6 versions don't contain this trick.
Am Samstag, 5. Juli 2014, 11:13:57 schrieb Bernhard Hiller:
When creating maps with current (3313) version of mkgmap, POIs do not
have proper names on an Oregon 600. Instead, the category of the POI -
as used in the style file - is shown (e.g. Pharmacy instead of the
name of the pharmacy).
Am Samstag, 5. Juli 2014, 11:31:52 schrieb Bernd Weigelt:
Please ignore this part of the previuos mail, CP error ;-)
this is from my 'point'
| finalize
| # The finalizer section is executed for each element when a rule with an
| # element type matches
|
|
|
|
| include '../inc
Am Dienstag, 3. Juni 2014, 10:10:41 schrieb GerdP:
f you change them so that the action block doesn't span two lines
it seems to work. I don't know if this should be fixed in the code.
Thank you Gerd
i've changed inc/phone and now it works again ;-)
cs:phone=* mkgmap:country=IRL
Am Dienstag, 3. Juni 2014, 20:53:50 schrieb Steve Ratcliffe:
As Gerd says, it is because the change didn't allow filter expressions
to be split onto more than one line. I've just committed a simple
change to allow the original expression to work again.
Thank you, Steve
it was a cp error some
Hi
the link to the java docs on side 9 is dead
i had to use this one
http://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi
FYI:
splitter r393 dies with following error, if i try to split my DACH-extract,
all other extracts are not affected
java.lang.ArrayIndexOutOfBoundsException: -184650
at
uk.me.parabola.splitter.O5mMapParser.setStringRefPair(O5mMapParser.java:355)
at
Am Montag, 26. Mai 2014, 10:21:31 schrieb Gerd Petermann:
Wow, 80 seconds to get a hint ;-)
this looks like an error in the o5m file. Is osmconvert able to read it?
What shall i do?
convert from o5m to osm and back?
No problem
Bernd
--
amarok2 now playing:
Am Montag, 26. Mai 2014, 10:31:46 schrieb Gerd Petermann:
Hi Gerd
okay, so it is probably a special case
Please post a link to the complete o5m file.
Sorry, my mistake
Didn't check the o5m file, only ask for that, what i should do ;-)
I have to test osmconvert 0.7T against the old and a new
Am Montag, 26. Mai 2014, 04:27:13 schrieb GerdP:
Hi Gerd
Maybe you have a hardware problem?
RAM? HDD?
Don't think so, because then it should be more often, not only by this
extract. If my HDD has a problem, the error should be the same as this
morning, because i've renamed the file and
Am Donnerstag, 22. Mai 2014, 20:03:48 schrieb Gerd Petermann:
Hi Gerd
Please try with your workload and let me know the results.
If you are not happy with the new result, please send the densities_out.txt
and the splitter.log.
I've made some tests with the patched version, you find my logs
Hi
I'm searching for a good logging.properities file ?
In the best case with descriptions or comments, but a ready to use file is
good enough
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am Donnerstag, 22. Mai 2014, 10:05:15 schrieb Gerd Petermann:
Hi Gerd
attached are three versions:
looging.props\mkgmap_log.props : no timestamps
looging.props\logging.properties : the default used by mkgmap
looging.props\logging.properties_tk : a version from Thorsten Kukuk
(found here:
Am Freitag, 9. Mai 2014, 09:04:22 schrieb Gerd Petermann:
I just found out that the JRE on my PC uses 60013 as default:
C:\Users\Gerdjava -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal
-version | findstr StringTable bool
PrintStringTableStatistics= false
Am Donnerstag, 8. Mai 2014, 17:13:43 schrieb Gerd Petermann:
In short, try java run time parameter
-XX:StringTableSize=13 for mkgmap.
IMHO you forgot a Zero ;-)
-XX:StringTableSize=103
Bernd
___
mkgmap-dev mailing list
Am Donnerstag, 8. Mai 2014, 17:33:22 schrieb Gerd Petermann:
Hello Gerd
I've made three tests with my bonn extract
without -XX:StringTableSize
Time started: Thu May 08 17:57:43 CEST 2014
Time finished: Thu May 08 18:04:54 CEST 2014
Total time taken: 430804ms
with -XX:StringTableSize=13
Hi
i have a problem, that the finalize section to often calls inc/access, in my
case for every overlay and the routable way.
IMHO it should call it only for the routable way(s) with road_speed and
road_class.
an example
lines:
highway=cycleway[0x1200a resolution 23-23 continue]
Am Donnerstag, 8. Mai 2014, 19:42:54 schrieb Gerd Petermann:
Hi
but now there are a lot of loops for tests that do nothing, except heating my
CPU ;-)
I don't know, how can this be done better
Bernd
I think that's the idea of the finalize section. It is called for
each added element.
Am Mittwoch, 7. Mai 2014, 11:37:58 schrieb Felix Hartmann:
Well I still use pbf and not o5m.
First pbf is smaller..
Second - Geofabrik only offers pbf - that's why I stayed with it.
I don't think I can cut a lot of time by first converting to 05m, then
hand it over to splitter...
Actually
Am Dienstag, 6. Mai 2014, 13:56:42 schrieb Gerd Petermann:
It is now less likely that splitter creates tiles with a low number of
nodes, it is more likely that all tiles have nearly the same number of
nodes, and typically you will see fewer tiles.
Maybe this also means that you can increase
Am Freitag, 25. April 2014, 10:00:42 schrieb Gerd Petermann:
okay, r3230 looks better now, and it still fixes the problem reported
be Enrico.
I think we may still improve the railway=tram lines somehow.
They are often pairs of parallel lines, sharp angles
are for sure not correct, and
Am Freitag, 25. April 2014, 05:34:32 schrieb franco_bez:
Hi Franco
I think this is a problem in our style, so we should fix it there ;-)
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am Freitag, 25. April 2014, 07:10:29 schrieb GerdP:
Hi Gerd
I did not try, but I think you just have to move the include 'inc/name';
line
after the changes of the name tag.
That was my first thoughts, too, but i will also test our changes at the start
of inc/name.
Bernd
--
amarok2 now
Hi
I got this error if i build a map around DE-Starnberg
Time started: Thu Apr 24 20:50:22 CEST 2014
java.lang.AssertionError
at
uk.me.parabola.imgfmt.app.net.RouteRestriction.init(RouteRestriction.java:88)
at
Thank you , Gerd
Hier sollte eigentlich eine Signatur stehen.
-Original Message-
From: Gerd Petermann gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk mkgmap-dev@lists.mkgmap.org.uk
Sent: Do., 24 Apr. 2014 23:06
Subject: Re: [mkgmap-dev] Problem with this restriction?
Am Freitag, 11. April 2014, 12:50:25 schrieb Waxy:
Grave (RestrictionRelation): 63240003.o5m: Turn restriction
(no_left_turn) http://www.openstreetmap.org/browse/relation/1172857 (at
http://www.openstreetmap.org/?mlat=-21.007077mlon=55.271317zoom=17)
way
Am Montag, 24. März 2014, 08:23:56 schrieb Gerd Petermann:
when you put these lines in the finalize section,
is that before or after the line
include 'inc/access';
both tested, same result
?
Remember that mkgmap evaluates mkgmap:bicycle=*, not bicycle=*.
But this could be my error, i will
Am Montag, 24. März 2014, 09:19:44 schrieb Bernd Weigelt:
include 'inc/access';
both tested, same result
?
Remember that mkgmap evaluates mkgmap:bicycle=*, not bicycle=*.
But this could be my error, i will try this
Made some tests:
highway=path
Am Montag, 24. März 2014, 10:20:58 schrieb Gerd Petermann:
Hi Bernd,
sorry, I can't follow.
Please post two complete styles, one that is working as expected, another
which is not. This will help to find out what is different.
Done
http://files.mkgmap.org.uk/detail/189
Am Montag, 24. März 2014, 11:49:34 schrieb Gerd Petermann:
check the line
access=* { addaccess '${access}' }
in inc\access
I copied inc/access from the default style, there is the same line
i have added compat_access for my style, because i don't want to change
something in inc/access
Hi
my style include a lot of rules like this:
highway=footway[0x1200d resolution 23-23 continue]
highway=footway[0x1100d resolution 24 continue]
highway=footway
(bicycle=designated |
bicycle=permissive |
bicycle=official |
Hi
Got this, if try to download a file from
http://www.mkgmap.org.uk/download/mkgmap.html
thx
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am Samstag, 8. März 2014, 23:49:18 schrieb GerdP:
So, if you use osmconvert/osmfilter to update your files
it is probably better to use a 64 bit Linux installation.
BTW
Hmmh, i saw this error on a 64 bit linux system with 16 GiB RAM and i use
osmupdate to update an extract from a local planet
Am Freitag, 31. Januar 2014, 15:37:50 schrieb Patrik Brunner:
So one could always download the latest file from the paths
./bounds/latest/bounds.zip and ./sea/latest/sea.zip
Not sure how complex it is to achieve this during your automated
generation/preparation/publishing, but guessing
Am Sonntag, 26. Januar 2014, 20:52:28 schrieb Steve Sgalowski:
try this
# Hospital
amenity=hospital
{ name '${emergency} ${name} ${name}' | '${emergency}' |'${name}' '${name }}
[0x3002 resolution 24]
with my old style file
on my nuvi
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:
Am Sonntag, 12. Januar 2014, 11:10:41 schrieb Minko:
Wanmil, if mkgmap is reversing roads, do you consider that I render
cycleway:left=lane etc on non oneway streets? This has an impact if roads
are reversed, the cycleway will be drawn on the wrong side of the street.
In my mind, oneway=-1 is
Am Sonntag, 12. Januar 2014, 12:49:39 schrieb Minko:
I was referring to this patch where all roads are being reversed *without* a
oneway=* tag. So whether oneway=-1 is good tagging or not is not relevant
in this case.
It was my error, this should be an answer in the thread 'wrong rendering...'
Am Samstag, 28. Dezember 2013, 16:57:02 schrieb Jaromír Mikeš:
Any idea what can be wrong?
line 42
{add mkgmap:label:1='${name}' | 'Marina}
missing '
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Am Samstag, 28. Dezember 2013, 17:30:52 schrieben Sie:
Am Samstag, 28. Dezember 2013, 16:57:02 schrieb Jaromír Mikeš:
Any idea what can be wrong?
line 42
{add mkgmap:label:1='${name}' | 'Marina}
missing '
sorry error is in line 40
ernd
___
i got this messages, when i try to build a map with the default style
Found it, because i have disabled the overview map in default/options
Found one style in /home/bernd/map_build/mystyles/defaultmap_style
Warning: routable type 0x01 is used for non-routable line with level 0. This
may break
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all
with the mergeroad-branch, i have got this errors
svn is r2795,
no problems with mergeroad-branch r2774
Bernd
Time started: Sat Nov 02 12:14:28 CET 2013
Found one style in /home/bernd/map_build/mystyles/bikemap_style
finished check-styles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 02.11.2013 14:49, schrieb Gerd Petermann:
you should do a full rebuild (ant clean dist)
Uuh, shame on me ;-)
thank you, it works again
Bernd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 15.09.2013 19:07, schrieb WanMil:
Thanks! I've comitted a fix.
thank you, too
it works now
Bernd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
iEYEARECAAYFAlI1+v8ACgkQwCMdlf933K8dAwCdG7riv8/UKkz3ZHRqomtIgSgl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 08.09.2013 14:01, schrieb WanMil:
Hi
* Instead of using hardcoded rules for maxspeed it is now possible
to control that via style file. Set the mkgmap:road-speed-class tag
to the desired class value (0 to 7) and use the new functions
Am 24.08.2013 12:55, schrieb Colin Smale:
I put the following code in
inc/phone and used the include function to invoke that from
inc/address, instead of the existing two lines which derive
mkgmap:phone.
looks good ;-)
I have made a test with a small area in Germany Bonn + 100Km, i didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 25.06.2013 11:26, schrieb Minko:
Thanks Wanmil, I tested it and addresses along streets with ref's
show up in the search now
My tests are also successful, but i had to change some rules in my
styles to make them work.
These rules are now similar
Am 21.06.2013 09:52, schrieb Minko:
Thanks Wanmil!
Can you upload a patched mkgmap.jar file?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
+1
I want to test it ;-)
thank
Am 19.06.2013 05:59, schrieb GerdP:
Hi Gerd
thank you
I've fixed the housenumber.
Bernd
the problem is caused by this highway:
http://www.openstreetmap.org/browse/way/44174652
and the building
http://www.openstreetmap.org/browse/way/225876050
with addr:housenumber=231235.
I guess it was
Am 18.06.2013 08:18, schrieb GerdP:
Please post the data so that we can try to reproduce the
problem.
I've two files to http://files.mkgmap.org.uk/, i can't find anything in
the log, but the O5M is the right one.
mapname: 65000105
description: DE-Duisburg
input-file: 65000105.o5m
Bernd
HOUSE NUMBER RANGE: Difference too large
I got this message, when i build a map with my DACH-poly, but i can't
find the object.
Is it possible, to get the object-ID?
Logging is enabled with loglevel 'WARNING'
Bernd
signature.asc
Description: OpenPGP digital signature
Am 29.05.2013 23:41, schrieb GerdP:
Hello
no, Gerd, this is a problem with some maps build with mkgmap, but it is
not seen on every Oregon. It also happened, if the maps are installed on
the SD-card.
I have never seen this with my Oregon.
On the Garmin-Forum there are a lot of threads with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi
'java -jar splitter.jar --help=options splitter_options' print out
very long lines, up to 267 characters.
I found SplitterParams.java, but i don't now how to fix this
I'm using openSUSE Linux as OS
Bernd
-BEGIN PGP SIGNATURE-
Version:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.04.2013 13:38, schrieb Henning Scholland:
Hi Henning
I'm sending stdout to a file lika splitter.log. Terminal stays
clean and in case of an error I (or a dev) can take a look in the
log.
Something like that?
java -jar splitter.jar 21
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.04.2013 15:00, schrieb GerdP:
What problem do you have with the diff? If you use e.g. java -jar
splitter.jar --help splitter.options you should get a normal text
file. If you do that again with an older version of splitter and
another
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.04.2013 14:42, schrieb Henning Scholland:
No just java -jar splitter.jar splitter.log
thanks, that work for me, too
Bernd
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 28.04.2013 17:48, schrieb Geoff Sherlock:
I think you are viewing in notepad. If viewed in wordpad or in any
unix utility it should look fine.
Sorry, i'm using kate ;-) http://kate-editor.org/ my preferred OS is
openSUSE
on Windows, i'm using
Am 15.04.2013 15:54, schrieb Josef Latt:
this style is missing cycleway=track ...
Could someone contact Bernd.
I'm here ;-)
Thanks for this hint
And you should have my mail-address
Bernd
signature.asc
Description: OpenPGP digital signature
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 13.04.2013 17:58, schrieb Franco Bez:
As the use of routable types for road2 in overlays might break the
routing (route goes to tile border and then jumps on a straight
line to the target, a non existant way is used for routing), you
should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.04.2013 13:28, schrieb Franco Bez:
I will do a few more tests soon, and post the results here. I
currently have the impression that at least the roundabout -
overlay - problem might still be there.
Ok, all roundabouts with this overlay(s)
Am 10.04.2013 09:10, schrieb GerdP:
My understanding of the program code is that it simply adds lines with the
given types.
Maybe it was meant to be
Make sure that only the first way in the overlays file is routeable.
+1
I made some tests with nonroutable Types for the overlays like
Am 10.04.2013 17:55, schrieb Gerd Petermann:
Hello Gerd
does that mean that you think that it only works when the 2nd type is also
routable?
IMHO yes, but maybe types like 0x14, 0x15,to 0x2f also work, i didn't
test them.
all other types 0x10001ff didn't work for me.
0x0c with overlay 0x06
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 10.04.2013 14:35, schrieb GerdP:
My result with an Oregon 450t , software version 5.50: version
2447: routing to POI Schönwetter Automobile works, but address
Robert-Bosch-Straße 14 doesn't work.
As i write in the other mail, the last part of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 10.04.2013 18:27, schrieb GerdP:
with it works I mean that you don't see the described routing
problems. Do you mean the same or do you talk about how it looks
like?
I didn't see this routing problems on other streets, only on this
special
Am 20.03.2013 08:38, schrieb Gerd Petermann:
Hi all,
Solved, if i use 'name-tag-list=name:de,name,int_name' in '-c map.conf'
'name_tag = name:de, name' in ³STYLE/options' didn't work.
Don't know why ;-)
I didn't try, but the source code evaluates name-tag-list, not name_tag.
The wrong
] No roads near target bug in Schwabmünchen
On 21/03/13 23:00, Bernd Weigelt wrote:
Done
bayern_basemap_gmapsupp.img.zip
Thanks, I will investigate. No guarantees that I will be able to find
anything quickly though.
..Steve
___
mkgmap-dev mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 20.03.2013 11:47, schrieb franco_bez:
Gerd
This sounds very bad indeed. I can only partly agree that the bug
has to be fixed in the garmin software, not the img file. As the
bug not only affects one single garmin device (Remember the same
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 21.03.2013 11:19, schrieb GerdP:
sounds reasonable if their is no routable way to that adress. Does
that mean that one has to be careful how he selects the target or
are some roads never displayed without a number?
Yes, that worksforme.
I'm
101 - 200 of 210 matches
Mail list logo
