Re: [mkgmap-dev] log messages for housenumbers
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 6500'1'xyz Bonn Bikemap 6500'2'xyz or splitter tile 65020xyz DACH Basemap 6502'1'xyz ... so i can use more then one image per region and layer, some devices are problematic Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
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 https://www.openstreetmap.org/#map=19/50.97521/7.06026 or Aachener Straße 399, https://www.openstreetmap.org/#map=19/50.93686/6.91106 In both cases i got only the old list of street parts Searching for Brühler Straße 255 https://www.openstreetmap.org/#map=19/50.89835/6.95261 results in a checkered flag in front of the building. First i thought it is a problem with the spaces in the streetname, triggered from a rule in my style, but now i think it is related to the length of the street. Luxemburger doesn't appear in this log. i didn't search for the Luxemburger in the logs, but i stored the complete log files, compressed 44 MB, i can upload them, if wanted, a map image, too. BTW, it happened on every long street, tested in Bonn with the Königswinterer Straße Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] log messages for housenumbers
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. To verify that, please try to search in MapSource without a city name. MapSource, hmmh, didn't use that since years, but i install it tomorrow Maybe you can upload the input file for 65001032.img, so that I can do some tests on my own. 6532.o5m? this file is deleted, but tomorrow i can use the same region from my DACH build this evening for an upload. Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] the north sea is empty
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 mkgmap:skipSizeFilter=true }[0x32 resolution 10]
adding a polygon definition to the TYP does the trick, but i had to add the
draworder '6', too. An empty draworder is bad ;-)
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Adresssearch with new bounds 20.0.15
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] the north sea is empty
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 sri lanka extract and some lines from the mkgmap log any hints? Bernd java -ea -Xmx6G -jar /home/bernd/map_build/splitter-r421/splitter.jar --geonames-file=/home/bernd/map_build/cities15000.zip --mapid=65030001 --output=o5m --precomp-sea=/home/bernd/map_build/sea_20150206.zip --write-kml=sri_lanka.kml --keep-complete --overlap=0 --split-file=/home/bernd/map_build/areas/sri_lanka_areas.list /home/bernd/map_build/o5m/sri_lanka.o5m java -ea -Xmx6G -Dlog.config=/home/bernd/map_build/mkgmap_log.props -jar /home/bernd/map_build/mkgmap-r3472/mkgmap.jar --read-config=/home/bernd/map_build/styles/basemap_style/options --bounds=/home/bernd/map_build/bounds_20150206.zip --precomp-sea=/home/bernd/map_build/sea_20150206.zip --generate-sea --style-file=/home/bernd/map_build/styles/basemap_style --name-tag-list=name:de,name,name:en,int_name --mapname=65031001 --family-id=4 --product-id=44 --description=sri_lanka_20150219_1200_basemap --family-name=Basemap --draw-priority=10 /home/bernd/map_build/tiles/*.o5m /home/bernd/map_build/styles/styles_typ.txt 2015/02/21 18:06:00 INFORMATION (SeaGenerator): /home/bernd/map_build/tiles/65030001.o5m: Load precompiled sea tiles 2015/02/21 18:06:00 INFORMATION (SeaGenerator): /home/bernd/map_build/tiles/65030001.o5m: Started loading coastlines from sea_262144_3702784.osm.pbf 2015/02/21 18:06:00 INFORMATION (SeaGenerator): /home/bernd/map_build/tiles/65030001.o5m: Finished loading coastlines from sea_262144_3702784.osm.pbf -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] r3469 in housenumber2 branch
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] bounds file from 19.02.1015
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 Favorite Game album: Rodeo Radio ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] housenumber2 branch
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 usefull Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] housenumber2 branch
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 15 minutes Please, give give me a hind which logging options are usefull Bernd Made another test with my sri lankian extract, has one only tile, the map is build was successful. Maybe something is wrong while merging the images? Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Railway tracks drawn around station buildings
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
building=no {delete building}
somewhere at the start of lines?
I have problems to understand, why you're using such catchalls like
railway=* in lines, IMHO it is better to use exact rules
railway=station as polygons are buildings and should be treated like that
[points] default GARMIN symbol
railway=station | railway=halt [0x2f08 resolution 23]
no entry for railway=station in lines or polygons
[lines]
railway=rail [0x14 resolution 22]
[polygons]
building!=no [0x13 resolution 24 continue with_actions]
this is shortened what we used in our styles,
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] java error - UnknownFormatConversionException: Conversion = '''
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
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 other ugly code Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug in handling of bus stops
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 only one line
2015/02/02 10:47:31 FEIN (RuleSet): /home/bernd/map_build/tiles/6531.o5m:
skipping part of rule 392 # Part of the previous OR expression:
((($last:word='Laan')$last:word=*)) {delete last:word;} because previous part
matched already for http://www.openstreetmap.org/way/85641102
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Bug in handling of bus stops
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
(amenity=bus_station |
highway=bus_stop |
railway=tram_stop |
railway=halt |
railway=station)
{
#eliminate double ^ or double - ; no idea why they are entered twice otherwise
delete public_transport;
}
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] PT rules in relations file
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 for the double entries, but how can i filter them?
Bernd
With the new filter, it works as expected, there is now only one entry, no
double entries in the list now
for the node above 'Unkel (Rb27,re8)
thank you, Maxim
# Public transportation routes.
# We could want to sort the matching relations by ref first.
type=route
(route=bus|
route=trolleybus|
route=ferry|
route=subway|
route=train|
route=tram)
(ref=* |
name=*)
{
add ref='${name}';
apply {
#set route_ref='$(route_ref),${ref}' | '${ref}';
set route_ref='$(route_ref),${ref|not-contained:,:route_ref}' |
'$(route_ref)' | '${ref}';
set mkgmap:relref='${ref}';
apply role=passengers {
set route_ref='$(route_ref),${mkgmap:relref}' | '${mkgmap:relref}';
}
delete mkgmap:relref;
}
}
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problems with address search in Germany
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 line 'Spell Country'
second line 'Deutschland'
now i got only 'Country' in the second line
next step
add the country name 'Deutschland' seems to work
third step
'Spell City'
adding 'Koln' breaks after 'Ko' results in some cities with 'Ko' like Konz or
Korschenbroich
go back to 'Spell City'
move the cursors manually to the third position behind the 'o' add 'ln',
results in 'No results found'
Searching for streets in Cologne didn't work, too
But with with
mkgmap:country=* {echotags ''}
in inc/address, i got following as example.
4611686018434217727 (4611686018434217727) -
[mkgmap:admin_level6=Köln,
mkgmap:admin_level9=Chorweiler,
mkgmap:admin_level5=Regierungsbezirk Köln,
name=Bundesamt für Verfassungsschutz,
addr:city=Köln,
mkgmap:postcode=50765,
addr:postcode=50765,
mkgmap:postal_code=50765,
addr:street=Merianstraße,
mkgmap:street=Merianstraße,
mkgmap:tagsincomplete=true,
addr:housenumber=96,
mkgmap:mp_created=true,
mkgmap:cache_area_size=4114.5802001953125,
mkgmap:housenumber=96,
building=yes,
mkgmap:country=DE,
addr:country=DE,
mkgmap:stylefilter=polygon,
mkgmap:admin_level4=Nordrhein-Westfalen,
mkgmap:region=Köln,
mkgmap:admin_level10=Volkhoven/Weiler,
mkgmap:city=Chorweiler]
It strikes me that mkgmap_country for germany has only the letters 'DE' i've
expected mkgmap:country=DEU Belgium or the Nederlands are correct tagged
withmkgmap:country=BEL or mkgmap:country=NLD
Where is the problem?
thanks
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Patch: New filter not-contained
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
Bernd
--
amarok2 now playing:
artist: Ike Tina Turner
title: The Things I Used To Do
album: The Soul Anthology
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems with address search in Germany
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
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:country!=* addr:country=* { set
mkgmap:country='${addr:country|country-ISO:}' }
mkgmap:country!=* is_in:country=* { set
mkgmap:country='${is_in:country|country-ISO:}' }
Thank you Gerd
with the default inc/address i got now mkgmap:admin_level=DEU, but the
searches in Germany didn't work. Searches in Belgium are successful.
And you're right, there must be a problem with the bounds from January, 18th,
with the one from January, 6th, the search works as expected.
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] minxed-index branch ready for trunk?
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 parts of the name are also useless for
searching by name.
But if i add
mkgmap:country=LUX |
mkgmap:country=DEU |
mkgmap:country=BEL |
mkgmap:country=AUT
to the country list, i got lots of list entries like
Straße, Kieler
Weg, Bonner
...
This are my changes
###
# Get the last full word if a \s (whitespace) exist in name
# if the last full word is a roman number - i.e. if a street has been named
after a King or
# a Pope - get the last two words
# set the labels used for address search (34):
# the 3rd label is set with the last:word as 1st word followed by comma and
the remaining words
# the 4th label skipping the 1st word (that is usually Via, Rue, Avenida etc,
so not really useful in search)
( mkgmap:country=ITA |
mkgmap:country=FRA |
mkgmap:country=CHE |
mkgmap:country=ESP |
mkgmap:country=BEL |
mkgmap:country=LUX |
mkgmap:country=DEU |
mkgmap:country=AUT
)
highway=*
name ~ '.*\s.*'
{ set last:word='${name|part: :-1}' }
# the ignore list should be greater
last:word=*
(
last:word = Straße|
last:word = Weg|
last:word = Ring|
last:word = Platz|
last:word = Straat|
last:word = Laan
)
{ delete last:word }
last:word ~ '(I|II|III|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}'
}
# only for the tests
last:word=*
{echo '${mkgmap:label:1} | ${mkgmap:label:2} | ${mkgmap:label:3} | \
${mkgmap:label:4}';
echotags ''}
###
the result is something like that:
320136003: Am Stadtpark | null | Stadtpark, Am | Stadtpark
320136003 - [mkgmap:admin_level6=Rheinisch-Bergischer
Kreis,mkgmap:admin_level5=Regierungsbezirk Köln,name=Am
Stadtpark,mkgmap:postal_code=42799,mkgmap:postcode=42799,mkgmap:street=Am
Stadtpark,route_ref=255,694,255,highway=residential,
mkgmap:country=DEU,mkgmap:admin_level2=DEU,last:word=Stadtpark,
mkgmap:label:3=Stadtpark, Am ,mkgmap:label:1=Am
Stadtpark,mkgmap:admin_level4=Nordrhein-
Westfalen,mkgmap:city=Leichlingen,mkgmap:region=Nordrhein-
Westfalen,mkgmap:admin_level8=Leichlingen,mkgmap:label:4=Stadtpark ]
--
amarok2 now playing:
artist: Lemar
title: Don't Give It Up
album: Time To Grow
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] PT rules in relations file
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 relations, btw apply_once didn't
help
this is my code
# Public transportation routes.
type=route
(route=bus|
route=trolleybus|
route=ferry|
route=subway|
route=train|
route=tram)
(ref=* |
name=*)
{
add ref='${name}';
apply {
set route_ref='$(route_ref),${ref}' | '${ref}';
set mkgmap:relref='${ref}';
apply role=passengers {
set route_ref='$(route_ref),${mkgmap:relref}' | '${mkgmap:relref}';
}
delete mkgmap:relref;
}
}
How can get this result? And where is my error?
Bernd
[1] http://www.openstreetmap.org/way/58522211
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] PT rules in relations file
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues with barrier=*
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues with barrier=*
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Issues with barrier=*
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 Bernd -- amarok2 now playing: artist: Roy Orbison title: Hound Dog Man album: The Soul Of Rock And Roll ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile contains both drive-on-left and drive-on-right roads
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 there are (95) roads in Surinam (drive-on-left) and (7568) roads in French Guiana (drive-on-right) ! Right ? So it's not a problem, isn't it ? The GRAVE is frightening ! Steph I have seen the same problem on Dec.19th with my chinese extract, maybe while hongkong drives on left? The map is created, but not tested at this moment, will do it today Bernd signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile contains both drive-on-left and drive-on-right roads
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 description: IN-Delhi input-file: 6513.o5m II: building basemap Time started: Sun Dec 21 11:13:42 CET 2014 SCHW: uk.me.parabola.mkgmap.osmstyle.StyledConverter /home/bernd/map_build/tiles/6513.o5m: Attention: Tile contains both drive- on-left (1006) and drive-on-right roads (17025) SCHW: uk.me.parabola.mkgmap.osmstyle.StyledConverter /home/bernd/map_build/tiles/6511.o5m: Attention: Tile contains both drive- on-left (142) and drive-on-right roads (41611) Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Sun Dec 21 11:17:44 CET 2014 Total time taken: 242305ms But i have more problems with this message for nonroutable layers like boundary, housenumbers and fixme. II: building boundary Time started: Sun Dec 21 11:12:38 CET 2014 java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.elementData(ArrayList.java:400) at java.util.ArrayList.get(ArrayList.java:413) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:690) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:221) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:120) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:82) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Sun Dec 21 11:13:42 CET 2014 Total time taken: 64197ms Bernd -- amarok2 now playing: artist: Radiohead title: Optimistic album: Radiohead (Boxset) ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile contains both drive-on-left and drive-on-right roads
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 local planet file three days ago, which is possible also corrupted, a new cut off is affected, too http://files.mkgmap.org.uk/download/241/6519.o5m.zip Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Tile contains both drive-on-left and drive-on-right roads
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 china had only a size of 202 MB against 256 MB of the old one But it isn't a problem to fetch a new planet and update this one, takes two hours. Overnight i will build a new mapset with all mapstyles and check your new changes thank you very much Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problematic routing on road_class=3 ferry routes for hikers
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 preserve values with where set before. addaccess and setaccess are very strong rules that block most other rules, if they are used to early highway=* with addaccess=* in 'lines' block every access rule except something like'set bicycle=*'. mkgmap:* are also showstoppers, which should be used only at the end of all actions. IMHO it is correct used in the default style with inc/access in the finalize section. In my style i try to separate rendering and routing rules/actions from access rules by adding all access rules to inc/access and i try to use only add access rules there. inc/access is called in the finalize section. i prefere to preserve the original access values and the default inc/access IMHO does this in the right way Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
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 matches include '../inc/address'; include '../inc/name' ; IMHO only with this call housenumber routing works correct. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
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 have an example where it is needed ? Puuh last year i had some troubles with searches, that are solved, when i add this lines to polygons and points. i can't descripe this problems anymore, sorry, maybe something with incorrecct or incomplete boundaries, i have to look in my old mailings to Franco Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Incorrect runabout exit indication
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. I use roundabout in the following way, so i got the hints in the correct way and don't see the ugly orange rings ;-) #-- # secondary as example | highway=secondary [0x12004 resolution 21-20 continue] | highway=secondary [0x11004 resolution 24-22 continue] | highway=secondary junction=roundabout | [0x0c resolution 24 road_class=2 road_speed=2] | highway=secondary [0x04 resolution 24 road_class=3 road_speed=4] | | highway=secondary_link [0x12004 resolution 22-22 continue] | highway=secondary_link [0x11004 resolution 24-23 continue] | highway=secondary_link[0x08 resolution 24 road_class=3 road_speed=3] Most of my routable ways are invisible and used on level 1 oder resolution 24. | [_line] | Type=0x0c | UseOrientation=N | Xpm=32 1 2 1 | ! c #FF | c none | | ;12345678901234567890123456789012 | String1=0x02,Kreisverkehr | String2=0x04,Roundabout | ExtendedLabels=N | [end] You can find my style here https://github.com/berndw1960/aiostyles Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap 3313 bug: POI names missing
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).
When using an old version of mkgmap (2815? file date 24 Nov 2013), the
names are shown - see screenshots.
The file size of the map of Bavaria is 207 MB with the old version, and
some 170 MB with the new version...
I include my points file.
Thanks for your hints,
Bernhard
add something like this to end of 'points'. 'lines', 'polygons'
| finalize
| # The finalizer section is executed for each element when a rule with an
| element type matches
|
| name=* { name '${name}' }
this is from my 'point'
| finalize
| # The finalizer section is executed for each element when a rule with an
| # element type matches
|
|
| include '../inc/roadspeed' ;
|
| include '../inc/access' ;
|
| name=* { name '${name}' }
|
| include '../inc/address' ;
|
| include '../inc/phone' ;
|
| highway=* ref=* { addlabel '${ref}' }
| highway=* int_ref=* { addlabel '${int_ref}' }
| highway=* nat_ref=* { addlabel '${nat_ref}' }
| highway=* ref_ref=* { addlabel '${reg_ref}' }
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap 3313 bug: POI names missing
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/roadspeed' ;
|
|
|
| include '../inc/access' ;
|
|
|
| name=* { name '${name}' }
|
|
|
| include '../inc/address' ;
|
|
|
| include '../inc/phone' ;
|
|
|
| highway=* ref=* { addlabel '${ref}' }
| highway=* int_ref=* { addlabel '${int_ref}' }
| highway=* nat_ref=* { addlabel '${nat_ref}' }
| highway=* ref_ref=* { addlabel '${reg_ref}' }
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3289: Style filter arguments can now be quoted.
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
{
set cs:phone='${cs:phone|
subst:^00~+|
subst:[-()]~|
subst:^0~+353|
subst:^+3530~+353}'
}
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3289: Style filter arguments can now be quoted.
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 month ago and i think, it's better, when i fix my style, too. Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Dead Link in style manual
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problem with splitter r393
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 uk.me.parabola.splitter.O5mMapParser.readAuthor(O5mMapParser.java:408) at uk.me.parabola.splitter.O5mMapParser.readVersionTsAuthor(O5mMapParser.java:372) at uk.me.parabola.splitter.O5mMapParser.readNode(O5mMapParser.java:251) at uk.me.parabola.splitter.O5mMapParser.readFile(O5mMapParser.java:187) at uk.me.parabola.splitter.O5mMapParser.parse(O5mMapParser.java:133) at uk.me.parabola.splitter.Main.processOSMFiles(Main.java:1362) at uk.me.parabola.splitter.Main.processMap(Main.java:874) at uk.me.parabola.splitter.Main.genProblemLists(Main.java:697) at uk.me.parabola.splitter.Main.partitionAreasForProblemListGenerator(Main.java:729) at uk.me.parabola.splitter.Main.split(Main.java:307) at uk.me.parabola.splitter.Main.start(Main.java:181) at uk.me.parabola.splitter.Main.main(Main.java:151) here are the log files http://files.mkgmap.org.uk/download/210/20140526_0900.zip Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with splitter r393
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: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with splitter r393
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 extract, then i can give you the informations, but it will take some hours. I think, osmupdate 0.3F has a problem with this large extract, ~6.3 GB, because i have to create a new extract very often. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with splitter r393
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 didn't copy it to another place. S.M.A.R.T monitoring is enabled. But i'll test both, RAM and HDD, this night to be sure BTW: there only a few changes in the three splitter.log, the areas.list are more or less identical. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch v1] improve splitter
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 here: http://files.mkgmap.org.uk/download/209/splitter.zip For me, it's seems to be a great improvement Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] logging.properities
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] logging.properities
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: http://osm.thkukuk.de/tk-osm.tar.bz2) thank you Bernd -- amarok2 now playing: artist: Phil Collins title: Colours album: But Seriously ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
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 {product} uintx
StringTableSize = 60013 {product}
the same value here
bernd@apoll:~ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -
version | grep StringTable
bool PrintStringTableStatistics= false
{product}
uintx StringTableSize = 60013
{product}
java version 1.7.0_51
OpenJDK Runtime Environment (IcedTea 2.4.4) (suse-24.13.5-x86_64)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
Bernd
--
amarok2 now playing:
artist: http://www.swr3.de
title: Marchin on / One Republic; Timbaland
album: SWR3
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
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 mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
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 Time started: Thu May 08 18:07:33 CEST 2014 Time finished: Thu May 08 18:14:20 CEST 2014 Total time taken: 406425ms with -XX:StringTableSize=103 time started: Thu May 08 18:16:20 CEST 2014 Time finished: Thu May 08 18:23:06 CEST 2014 Total time taken: 405556ms This are tests on my small laptop with 3.6 GB RAM with 64bit Linux Bernd I tried both, and the smaller values seemed to work better for mkgmap. I guess it depends on the input files what value is best, but at least the default 1009 doesn't work well, so any much higher prime value should help. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] finalize and some ways with overlays
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]
highway=cycleway[0x1100a resolution 24 continue]
highway=cycleway[0x0a resolution 24 road_class=0 road_speed=1]
finalize
# The finalizer section is executed for each element when a rule with an
element type matches
# calculate the access rules
include 'inc/access' ;
--
inc/access includes for testing some ways this additional test
highway=* bicycle=official { echo ' 1 ${highway} | ${bicycle} |
${mkgmap:bicycle} ' }
output for this way
http://www.openstreetmap.org/way/243198140
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
243198140: 1 cycleway | official | null
..
How can i fix this?
Or is there something wrong in my style?
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] finalize and some ways with overlays
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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r325: improved split algo and new option
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 I also let splitter output pbf... Maybe I could change that in future to 05m.. I download a planet.pbf, convert it to o5m, time ~50 mins,and cut the needed polies from that planet.o5m. an update of my germany.o5m, 3,2 GB. takes now 3 minutes. I update the planet once a month, my extracts everytime i need them. thats much faster then download a new pbf everyday or update this pbf. and with the local planet it is easier to create special maps for friends like bonn+100 or dach+ Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter r325: improved split algo and new option
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 the max-nodes value. some infos about splitter 321 vs. 325 Intel i5 QUAD @ 2.7 Ghz, 16 GB RAM ramsize = -Xmx6G maxnodes = 160 o5m as input and output rel tiles timeuse_areas sri lanka o5m size 17.1 M 321 1 2s yes 325 1 3s no 325 1 3s yes oal (Ost-Allgäu) o5m size 78.7 M 321 4 7s yes 325 3 8s no 325 3 7s yes china o5m size 261.1 M 321 16 18s yes 325 15 25s no 325 15 18s yes bonn +100km o5m size 739.9 M 321 35 53s yes 325 28 62s no 325 28 54s yes germany o5m size 3.2 G 321 152 250syes 325 124 256syes DACH+ o5m size 8.3 G 321 357 703syes 325 392 866sno 325 392 733syes europe (just for fun) o5m size 22.7 G 321 10384645s no 325 10465267s no 325 10464681s yes the whole planet o5m size 45.1 G not tested yet, maybe tonight -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with this restriction?
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 they also build a network. Current code doesn't use this knowledge. I'll think about this again later. Thanks Gerd I'm back home now and will test r3230 or later to create a new mapset. Bernd -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] delete name not working
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 http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] delete name not working
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 playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Problem with this restriction?
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 uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:536) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:131) at uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.addRestriction(RestrictionRelation.java:535) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:495) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:248) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Time finished: Thu Apr 24 20:50:54 CEST 2014 Total time taken: 31241ms last entry in mkgmap.log.0 2014/04/24 20:50:53 Warnung (RoadNetwork): /home/bernd/map_build/tiles/65020018.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/browse/relation/2254003 (at http://www.openstreetmap.org/?mlat=48.119082mlon=11.583557zoom=17) the angle of the from and to way don't match the restriction http://www.openstreetmap.org/relation/2254003 link to mapdata http://files.mkgmap.org.uk/download/204/65020018.o5m Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with this restriction?
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? Hi Bernd, the error is fixed with r3229. I am also checking why the restriction 2254003 is ignored. The angle doesn't look that bad, but mkgmap calculates an angle which seems to say right turn. Gerd From: weigelt.be...@web.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Thu, 24 Apr 2014 21:00:47 +0200 Subject: [mkgmap-dev] Problem with this restriction? 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 uk.me.parabola.imgfmt.app.net.RoadNetwork.addRestriction(RoadNetwork.java:536) at uk.me.parabola.mkgmap.general.MapDetails.addRestriction(MapDetails.java:131) at uk.me.parabola.mkgmap.reader.osm.RestrictionRelation.addRestriction(RestrictionRelation.java:535) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:495) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:248) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Time finished: Thu Apr 24 20:50:54 CEST 2014 Total time taken: 31241ms last entry in mkgmap.log.0 2014/04/24 20:50:53 Warnung (RoadNetwork): /home/bernd/map_build/tiles/65020018.o5m: Turn restriction (no_u_turn) http://www.openstreetmap.org/browse/relation/2254003 (at http://www.openstreetmap.org/?mlat=48.119082mlon=11.583557zoom=17) the angle of the from and to way don't match the restriction http://www.openstreetmap.org/relation/2254003 link to mapdata http://files.mkgmap.org.uk/download/204/65020018.o5m Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Grave (RestrictionRelation) with mkgmap-r3181 and mkgmap-r3182
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 http://www.openstreetmap.org/browse/way/77065617 doesn't have required node I see this with one relation, where the 'to' way is on two tiles, see the attached files and the output from mkgmap bernd@apoll:~ pygmap3 II: using splitter-r321 II: using mkgmap-r3178 II: using sea_20140407.zip II: using bounds_20140407.zip II: now updating bonn.o5m, please wait... II: splitting the mapdata with areas.list... II: Now building bikemap Time started: Fri Apr 11 18:21:47 CEST 2014 Schwerwiegend (RestrictionRelation): /home/bernd/map_build/tiles/65010032.o5m: Turn restriction (only_straight_on) http://www.openstreetmap.org/browse/relation/2522150 (at http://www.openstreetmap.org/?mlat=51.371699mlon=6.438973zoom=17) way http://www.openstreetmap.org/browse/way/9662689 doesn't have required node Time finished: Fri Apr 11 18:26:10 CEST 2014 Total time taken: 262676ms -- bonn ready! -- Bernd bonn.kml Description: application/vnd.google-earth.kml # List of areas # Generated Thu Apr 10 19:02:07 CEST 2014 # 65010001: 2314240,251904 to 2342912,296960 # : 49.658203,5.405273 to 50.273438,6.372070 65010002: 2342912,245760 to 2365440,274432 # : 50.273438,5.273438 to 50.756836,5.888672 65010003: 2342912,274432 to 2365440,296960 # : 50.273438,5.888672 to 50.756836,6.372070 65010004: 2365440,245760 to 2379776,266240 # : 50.756836,5.273438 to 51.064453,5.712891 65010005: 2365440,266240 to 2379776,276480 # : 50.756836,5.712891 to 51.064453,5.932617 65010006: 2365440,276480 to 2371584,296960 # : 50.756836,5.932617 to 50.888672,6.372070 65010007: 2371584,276480 to 2379776,296960 # : 50.888672,5.932617 to 51.064453,6.372070 65010008: 2379776,251904 to 2387968,282624 # : 51.064453,5.405273 to 51.240234,6.064453 65010009: 2387968,260096 to 2404352,282624 # : 51.240234,5.581055 to 51.591797,6.064453 65010010: 2379776,282624 to 2390016,296960 # : 51.064453,6.064453 to 51.284180,6.372070 65010011: 2390016,282624 to 2408448,296960 # : 51.284180,6.064453 to 51.679688,6.372070 65010012: 2310144,296960 to 2342912,339968 # : 49.570313,6.372070 to 50.273438,7.294922 65010013: 2312192,339968 to 2342912,395264 # : 49.614258,7.294922 to 50.273438,8.481445 65010014: 2342912,296960 to 2365440,319488 # : 50.273438,6.372070 to 50.756836,6.855469 65010015: 2342912,319488 to 2365440,333824 # : 50.273438,6.855469 to 50.756836,7.163086 65010016: 2342912,333824 to 2365440,358400 # : 50.273438,7.163086 to 50.756836,7.690430 65010017: 2342912,358400 to 2365440,401408 # : 50.273438,7.690430 to 50.756836,8.613281 65010018: 2365440,331776 to 2379776,356352 # : 50.756836,7.119141 to 51.064453,7.646484 65010019: 2365440,356352 to 2379776,401408 # : 50.756836,7.646484 to 51.064453,8.613281 65010020: 2379776,354304 to 2390016,397312 # : 51.064453,7.602539 to 51.284180,8.525391 65010021: 2390016,354304 to 2408448,387072 # : 51.284180,7.602539 to 51.679688,8.305664 65010022: 2379776,331776 to 2390016,354304 # : 51.064453,7.119141 to 51.284180,7.602539 65010023: 2390016,331776 to 2396160,354304 # : 51.284180,7.119141 to 51.416016,7.602539 65010024: 2396160,331776 to 2400256,354304 # : 51.416016,7.119141 to 51.503906,7.602539 65010025: 2400256,331776 to 2410496,342016 # : 51.503906,7.119141 to 51.723633,7.338867 65010026: 2400256,342016 to 2410496,354304 # : 51.503906,7.338867 to 51.723633,7.602539 65010027: 2365440,296960 to 2379776,321536 # : 50.756836,6.372070 to 51.064453,6.899414 65010028: 2365440,321536 to 2379776,331776 # : 50.756836,6.899414 to 51.064453,7.119141 65010029: 2379776,296960 to 2390016,315392 # : 51.064453,6.372070 to 51.284180,6.767578 65010030: 2379776,315392 to 2390016,321536 # : 51.064453,6.767578 to 51.284180,6.899414 65010031: 2379776,321536 to 2390016,331776 # : 51.064453,6.899414 to 51.284180,7.119141 65010032: 2390016,296960 to 2394112,317440 # : 51.284180,6.372070 to 51.372070,6.811523 65010033: 2394112,296960 to 2410496,317440 # : 51.372070,6.372070 to 51.723633,6.811523 65010034: 2390016,317440 to 2398208,331776 # : 51.284180,6.811523 to 51.459961,7.119141 65010035: 2398208,317440 to 2410496,331776 # : 51.459961,6.811523 to 51.723633,7.119141 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finalize section not working as expected
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 try this
this workaround for routing blocking crossing:barrier
crossing:barrier!=no
{addaccess yes;
set mkgmap:road-speed=0;}
work expected in include 'inc/compat_access'; after include 'inc/access';
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finalize section not working as expected
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
(
smoothness~'.*(horrible|impassable)' |
smoothness=very_bad |
mtb:scale0 |
mtb:scale:imba0
)
{ set mkgmap:bicycle=no }
highway=path
(
sac_scale~'.*(mountain|alpine)_hiking' |
smoothness=bad
)
{ add mkgmap:bicycle=no; }
this rules at the end of inc/compat_access didn't work, tested with inc/access
before and after inc/compat_access and they didn't work, if i do them at the
begin of inc/access.
This is a little bit to high for my little mind
It works, if i do this rules in inc/access, it is clear for me, why this works
highway=path
(
smoothness~'.*(horrible|impassable)' |
smoothness=very_bad |
mtb:scale0 |
mtb:scale:imba0
)
{ set bicycle=no }
highway=path
(
sac_scale~'.*(mountain|alpine)_hiking' |
smoothness=bad
)
{ add bicycle=no; }
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finalize section not working as expected
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 http://files.mkgmap.org.uk/detail/190 you can use the xx.o5m from Franco's testcase, please route from somewhere near the turning circle [1] to OAL12 [2] in Irsee. You can use bicycle, tourcycling or mountainbike with short distance on your oregon. Then take a look at the Waldbauschülerpfad [3], the southwestern part [4] is the problem Please keep in mind, this problem happened not with every extract from a local planet, but with Franco's xx.o5m and my DACH extract. BTW: Cyclerouting works great now, i'm using most time tourcycling with short distance. Great work, thank you Bernd [1] http://www.openstreetmap.org/#map=18/47.91460/10.60397 [2] http://www.openstreetmap.org/#map=19/47.90889/10.57541 [3] http://www.openstreetmap.org/#map=18/47.91155/10.57797 [4] http://www.openstreetmap.org/way/32695806 -- amarok2 now playing: artist: The Housemartins title: Rap Around The Clock album: Raise The Flag ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Finalize section not working as expected
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 without need.
If I got that right any tag related to access should be set before this
line. In f:\osm\berndw\bikemap_not_ok it comes after this line.
Does that make sense?
Truly jein ;-)
I understand what you mean, but i have made also tests with include
inc/compat_access _before_ inc/access in lines with the same annoyance.
I can live with a changed inc/access, but it is only a workaround for me.
It's easier with a unchanged file, when i try to tell you my thoughts.
My english isn't good enough for exact descriptions
Bernd
--
amarok2 now playing:
artist: Madonna
title: Spotlight
album: You Can Dance
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap --check-styles and line count
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 |
bicycle=yes)[0x0a resolution 24 road_class=0 road_speed=1]
highway=footway[0x0d resolution 24 road_class=0 road_speed=0]
IMHO mkgmap count four lines, is that correct?
now it is difficult to find the error, if the files includes up to 700 lines, i
think, there are some larger styles around the world
mkgmap tells:
Error in style: Error: (lines:393): Stack size is 0
but the line with the error is line 485 in the style file
my error was to use '[' instead '(' ;-)
Bernd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] HTTP Error 500: INTERNAL SERVER ERROR
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
Re: [mkgmap-dev] Infinite loop splitter
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 This is the splitter.log from march, 1st 2014 splitter version 317 compiled 2014-02-27T07:09:08+ boundary-tags=use-exclude-list cache= Elapsed time: 10m 0s Memory: Current 2278MB (1176MB used, 1102MB free) Max 5461MB Elapsed time: 12m 0s Memory: Current 2278MB (1178MB used, 1100MB free) Max 5461MB Elapsed time: 14m 0s Memory: Current 2278MB (1178MB used, 1100MB free) Max 5461MB Elapsed time: 16m 0s Memory: Current 2278MB (1178MB used, 1100MB free) Max 5461MB * Full GC * Elapsed time: 11h 4m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 6m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 8m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 10m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 12m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 14m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Elapsed time: 11h 16m 7s Memory: Current 2386MB (743MB used, 1643MB free) Max 5461MB Bernd -- amarok2 now playing: artist: Sade title: The Sweetest Taboo album: The Best of Sade ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bounds and sea on pleiades
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 from my scripting
experience it shouldn't be that hard.
I think is better to use a link, named bounds.zip, to the latest file, with my
python script i check for the date in latest/
if config.get('navmap', 'sea') == latest:
target = http.client.HTTPConnection(osm2.pleiades.uni-wuppertal.de)
target.request(GET, /sea/latest/)
htmlcontent = target.getresponse()
data = htmlcontent.read()
data = data.decode('utf8')
pattern = re.compile('sea_201\d{5}.zip')
sea_rev_pre = sorted(pattern.findall(data), reverse=True)[1]
sea_rev = os.path.splitext(os.path.basename(sea_rev_pre))[0]
target.close()
config.set('navmap', 'sea_rev', (sea_rev))
m2c
Bernd
--
amarok2 now playing:
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] question on new style
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 1450lmt unit , there is no hospitals comming up now on the poi
section
i have included amenity = hospital and building = hospital
here is the code i use for it
amenity=hospital { name '${emergency} ${name} ${name}' | '${emergency}' |
'${name}' '${name }' }[0x2000 resolution 24-10]
building=hospital [0x2000 resolution 24-10]
but i am still not getting any hospitals included in the poi section
Stephen
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] boundary France broken?
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: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
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 a case of dirty mapping. I don't know a reason to map a street with this, because it's IMHO better to use oneway=yes. oneway=-1 should be marked as has to be fixed. I clean up this tag before i add something like *:forward or *:backward. Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH] RoadMerger reverses roads
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...' sorry Bernd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error
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
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap error
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] little bug in default style
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 routing. Style file lines, line 118 Warning: routable type 0x02 is used for non-routable line with level 0. This may break routing. Style file lines, line 123 Bernd -- amarok2 now playing: artist: Eric Clapton title: County Jail Blues album: Blues ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mergeroad-branch r2795
-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 java.lang.NoSuchMethodError: uk.me.parabola.mkgmap.osmstyle.StyledConverter.init(Luk/me/parabola/mkgmap/reader/osm/Style;Luk/me/parabola/mkgmap/general/MapCollector;Ljava/util/Properties;)V at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.createConverter(OsmMapDataSource.java:259) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.setupHandler(OsmMapDataSource.java:158) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:43) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:216) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJ1ASEACgkQwCMdlf933K/IKACgnbcOExs2ckU/LMHaFRqcz7PL RbwAn1/4MbPwi/S6QPINNq64YOum4uel =bbwn -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroad-branch r2795
-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) iEYEARECAAYFAlJ1BsoACgkQwCMdlf933K+eAgCfX0FzhjtrRVrNndrOk7zf3hkj UEoAniO0IhgHe7GHrZsIxY6h0k8P8L/T =JELF -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch
-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 tUAAn1a88z9lfmB8P7F6R/hsJlL+nZua =fq/M -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mergeroads branch
-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 maxspeedkmh() and maxspeedmph() to parse the maxspeed tag. I've made a test with this style rules, but with a enabled inc/roadspeed i got this error java.lang.AssertionError: value is null at uk.me.parabola.mkgmap.reader.osm.Tags.put(Tags.java:73) at uk.me.parabola.mkgmap.reader.osm.Element.addTag(Element.java:44) at uk.me.parabola.mkgmap.osmstyle.function.CachedFunction.value(CachedFunction.java:62) at uk.me.parabola.mkgmap.osmstyle.eval.NumericOp.eval(NumericOp.java:47) at uk.me.parabola.mkgmap.osmstyle.eval.AndOp.eval(AndOp.java:34) at uk.me.parabola.mkgmap.osmstyle.ActionRule.resolveType(ActionRule.java:59) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:68) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay(StyledConverter.java:214) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:239) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) This happened with most, but not all, tiles created from splitter, 30 of 32 tiles around Bonn + 100 km, print out this error, 2 tiles are ok Maybe i forgot to delete some of my old rules, but i can't find anything Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlI0a5gACgkQwCMdlf933K+NlQCgkOg+DD1UiE7kl2ynXAzaIn8t VpQAoJqefMrGn1tSo0Yn2szIL63UyUz+ =hTz1 -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Phone number normalisation with style 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 find any malformed phonenumber Bernd signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v2] Fix housenumber assignment for streets with refs
-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 to the default style. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHJc3IACgkQwCMdlf933K9XxgCfdcyOvVHCNv2vx6JNwZPfuTDB ZLEAn1+j6v20Y+1XDjg7zXZEbUOz1Tr6 =xqiK -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v1] Fix housenumber assignment for streets with refs
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 you Bernd signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HOUSE NUMBER RANGE: Difference too large
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 meant to be 231-235, and it should be just 231. The img format doesn't seem to allow one road segment with housenumbers in a large range, I can't say exactly the allowed values. I've committed r2561 to print a warning containing the OSM id when mkgmap is not able to convert the housenumber information into a valid bit string. signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] HOUSE NUMBER RANGE: Difference too large
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 signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] HOUSE NUMBER RANGE: Difference too large
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap and memory-full-error
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 this topic. @Christian: activities are another problem, IMHO it is something changed in the original Garmin-Maps, to prefer some ways for different use. Maybe a special tag or similar Bernd Hi, sounds like you copy the img file to the internal memory of the device and your device records tracks. The easiest solution is to use an SD card for the img file. Alternative: Remove saved tracks to free memory. Gerd Christian H. Bruhn wrote Hi! I've downgraded my Oregon 450 from firmware 6.xx to 5.50, because this was the last firmware without the activity routing. With the activity routing the routing of my maps was broken (car routing over steps and ignoring of access=no). With the firmware 5.50 the routing was correct again. But after a few weeks I get the famous memory-full-error. Now I read that in the past several people reported this error with maps made with mkgmap. The only advice I found, was to use an recent firmware. Is there a known bug in mkgmap? How can I avoid the error? Christian ___ mkgmap-dev mailing list mkgmap-dev@.org http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-and-memory-full-error-tp5763280p5763285.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] one problem with splitter
-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: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9BW0ACgkQwCMdlf933K+1wQCfbzEvsrMVh/NygY0MtQTbes61 p7QAnib9CVWgZIZ70dzIJxL49nG/px4P =9+ti -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] A question to Splitter
-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 splitter_log That should work on my system, but it never works with windows. IMHO it is better to use verbosity-levels to reduce the output, Most (Linux-)programs create an output on stdout only if an error happened. An example is the new output of '--check-styles', this is enough. | Found one style in /home/bernd/map_build/mystyles/bikemap_style | finished check-styles Sorry, i'm not a programmer, so i can't implement this. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9F8kACgkQwCMdlf933K9KMQCgggl9WZwugqoWZvOM+qMiaeS8 ZDcAnjRqsPcAiKbFp1gLzJEPMVYe0vzH =L5gr -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] one problem with splitter
-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 output file you should be able to diff them. I have send you a PM in German, i can't descripted this problem in english language Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9KE4ACgkQwCMdlf933K9cMwCgjggADmMlBkTfIv7xkrj101Pd 1QQAnj05jfmXXSzwNVUxwVWvwX0k3Nwu =010E -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] A question to Splitter
-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 - http://www.enigmail.net/ iEYEARECAAYFAlF9KMgACgkQwCMdlf933K/VKwCfcVXTlqXzZU/OgZ1B5SlTqcZU PIUAn2sF3roiP1TJ7675BQrMWgeZZ2HM =S/C6 -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] one problem with splitter
-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 sometimes PSpad http://www.pspad.com/ Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF9R1cACgkQwCMdlf933K9fDgCcCkATv+i5VFQrliJW4v+Th7w/ 0tsAoIGqH0YqY7JrlIxC2ccLwnYwzmLr =zRXm -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
-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 consider printing a warning when the 2nd type in an overlay definition is of routable type. IMHO the routing issues with housenumbers (not all housenumbers available in address search) is a completely different story. My 'overlays' is now completly empty, the routing over roundabouts work as expected. Housenumber-routing works, too. And i found some older postings from 2011 and earlier, which descript a similar problem with 'overlays' IMHO is 'overlays' obsolet, because most things can be done in 'lines' Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlFpgwsACgkQwCMdlf933K8SMACYs9eUkclaNQQ2hKYsSPFQRgLd ZwCgntSIQztRVeX2jopmO4jK01NtFFw= =mzYa -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
-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) are routable without any problem, but with housenumbers nearby not. Could it be, that the housenumbers attached to the nonroutable overlay instead of the routable, but not visible way? I've tested the overlay-functions a long time, there are problems, except that only a few types working. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFn94YACgkQwCMdlf933K8F8ACfchQE6sGrJUrlekXIrJAdJwfq +FkAn2AUF6vMKneCP/qaEPnJa7y8P2KP =+VN8 -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
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 0x10006, they didn't work So i used 0x06 as the nonroutable type for visibiltity. this works for all tested ways, see below. BTW the last part of Robert-Bosch-Street is tagged as junction=roundabout, and the housenumbers 10-14 will be attached to this part. Bernd ## living_street 0x0071b: 0x07, 0x1b ## roundabouts # motorway 0x00c01: 0x0c, 0x01 # trunk 0x00c02: 0x0c, 0x02 # primary 0x00c03: 0x0c, 0x03 # secondary 0x00c04: 0x0c, 0x04 # tertiary 0x00c05: 0x0c, 0x05 # residential 0x00c06: 0x0c, 0x06 # service 0x00c07: 0x0c, 0x07 # cycleway 0x00c15: 0x0c, 0x15 ## highway ramps (big) # motorway_link 0x00901: 0x09, 0x01 # trunk_link 0x00902: 0x09, 0x02 ## highway ramps (small) # primary_link 0x00803: 0x08, 0x03 # secondary_link 0x00804: 0x08, 0x04 # tertiary_link 0x00805: 0x08, 0x05 ## highway pedestrian 0x00d07: 0x0d, 0x07 ## highway cycleway 0x00715: 0x07, 0x15 ## highway with bicycle allowed 0x0070d: 0x07, 0x0d ## unknown roads 0x0072c: 0x07, 0x2c #eof signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
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 works like roundabout and the optic is like residential. You can test this with maps from my server, your account is enabled there. Bernd signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
-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 Robert-Bosch-Straße is tagged as 'junction=roundabout' and is closed loop. Robert-Bosch-Straße 10 - 14 are IMHO attached to this part. Is it possible, that this circumstances breaks routing? I didn't no another roundabout with buildings nearby, so i can't test this Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlkh8ACgkQwCMdlf933K9lJwCgjBqM1j7wD+sLEr+lkLR43Oan n24AoIFIJPJQHFECm8NlGTHQXS9ygEhQ =1ga7 -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## No roads near target bug in Schwabmünchen
-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 street. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlln0ACgkQwCMdlf933K/KCwCfUi6aVHvDtYcrxXVtV8Q+/IOT wdYAoIn8woztS3rg0IhAOMlIdrznlcGC =bc0n -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem with bounds_*.zip
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 example is in the marine/options which should be corrected. Any other places? Sorry to bring this old thread up, but i had this problem again. 'name-tag-list=name:de,name,int_name' in $STYLE/options didn't work got something like this 'Sh??rii Lnkaa' instead of 'Sri Lanka' 'name-tag-list=name:de,name,int_name' in '-c map.conf' work got 'Sri Lanka' my maps are build with latin1 and mkgmap v2562 and before Bernd signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] No roads near target bug in Schwabmünchen
No problem, the maps without x-housenumbers are OK, Bernd Hier sollte eigentlich eine Signatur stehen. -Original Message- From: Steve Ratcliffe st...@parabola.me.uk To: Development list for mkgmap mkgmap-dev@lists.mkgmap.org.uk Sent: Fr., 22 Mär 2013 22:54 Subject: Re: [mkgmap-dev] 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 mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] No roads near target bug in Schwabmünchen
-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 bug hit's the Nüvi as well as the Oregon), maybe there is some yet unknown restriction the img file has to obey. Hi i can reproduce this problem on a lot of street near my home. when the displayed name, on the top of the screen, is like 'Ritterstrasse 7', see the number, then the problem is there with 'Rheinstrasse' without number(!) the problem isn't there Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFK3FAACgkQwCMdlf933K9PzQCeO0dh4OIeDobShTkIOUX3R5OA 6/gAnRaP1vCJX6nftyv3vcLgUl9SFLRA =dWzD -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] No roads near target bug in Schwabmünchen
-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 able to build some maps with 'x-housenumber' IMHO the source of this problem, and without it. Bernd -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFK4KAACgkQwCMdlf933K/gBACeIFh0f07qSZzusjRQzim+dKa4 OGkAnjSj9SHjOsDnVklT/P8o3IgjPSDd =8YFv -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
