--- Log opened Sat May 04 00:00:19 2013 01:07 #navit: < Navit> The following compiles failed: http://download.navit-project.org/logs/navit/wince_arm/svn/navit-svn-5471.failed 01:09 -!- z30 [~Z30@77.242.202.227] has joined #navit 01:12 -!- KaZeR_W [~Z30@77.242.202.228] has quit [Ping timeout: 256 seconds] 01:32 -!- woglinde [~henning@f052238131.adsl.alicedsl.de] has quit [Ping timeout: 245 seconds] 02:22 -!- cp15` [ofgigp@p57B1C1E3.dip0.t-ipconnect.de] has joined #navit 02:22 -!- cp15 [nsctxa@p57B1D637.dip0.t-ipconnect.de] has quit [Disconnected by services] 02:22 -!- cp15` is now known as cp15 02:22 -!- mode/#navit [+o cp15] by ChanServ 03:00 -!- KaZeR_W [~Z30@77.242.202.229] has joined #navit 03:01 -!- noradtux [~noradtux@g224055121.adsl.alicedsl.de] has quit [Ping timeout: 264 seconds] 03:03 -!- z30 [~Z30@77.242.202.227] has quit [Ping timeout: 256 seconds] 03:05 -!- noradtux [~noradtux@e176061139.adsl.alicedsl.de] has joined #navit 07:39 -!- drlizau [~liz@billiau.net] has joined #navit 07:39 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has joined #navit 07:53 -!- tryagain [~tryagain@178.216.76.16] has joined #navit 07:57 #navit: < tryagain> _rd different behavior might be related to the fact that your data does not contain German boundary. Addressing parsing highly depends on having country info, and it's better to have proper boundary in your input osm data. 07:58 #navit: < tryagain> Are there any rasons for you not to use data downloaded from the maps.navit-project.org? 08:01 #navit: < tryagain> Also, it seems that Dattenhausen is more like suburb rather than a separate village, as it has no associated boundary of admin_level=8. 08:03 #navit: < tryagain> btw, today map data has 89281 zip for Dattenhousen instead of yesterday 72135. Also 82544 has changed to 89446. 08:14 #navit: < tryagain> actually, Dattenhousen suburb of Altenstadt have no boundaries in osm data. So navit approximates its boundaries and finds Lindenstrasse in another suburb of Altenstadt, Illereichen. 08:24 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 08:26 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has joined #navit 08:29 #navit: < _rd> Good morning tryagain 08:29 #navit: < _rd> I have maptool patched to get some more/other pois and tracks. 08:33 #navit: < _rd> nothing spectacular, but useful for me, http://paste.kde.org/737378/ shows the diff 08:34 #navit: < _rd> did the zip change, because yesterday we used Dettenhausen (not Dattenhausen)? 08:36 #navit: < _rd> 72135 Dettenhausen is a village, no suburb. 08:41 #navit: < _rd> I think it has a boundary[8] relation, not sure if that matches admin_level 08:44 #navit: < tryagain> good morning _rd 08:44 #navit: < tryagain> yes, i was looking different town today 08:48 #navit: < tryagain> Can you please try downloading germany boundary relation 72135 with all its members, then save it in separate .osm file. This can be done with josm. Then feed both osm file from geofabrik and that boundary file to navit. Unsure if this can be done for pbf files though. 08:49 #navit: < tryagain> like this: "cat 1.osm 2.osm |maptool outfile.bin" 09:14 #navit: < _rd> what do you mean with "germany boundary relation 72135" ? Is that the germany boundary or the boundary of Dettenhausen? 09:20 #navit: < tryagain> that's germany country boundary. I do not expect it to be included in geofabrik data pieces smaller than whole country, but it's needed for maptool to process boundaries correctly 09:22 #navit: < tryagain> ups, it seems i misspeleed it 09:24 #navit: < tryagain> http://www.openstreetmap.org/browse/relation/51477 09:31 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has quit [] 09:31 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has joined #navit 09:39 #navit: < _rd> I assume, I can directly download the XML from there without josm, right? 09:39 #navit: < _rd> I have josm installed, but I would not know how to get that relation only. 09:55 #navit: < _rd> tryagain, do you know what I need for USA? Country or state (e.g. California) boundry relations? 10:22 #navit: < _rd> tryagain, do you know what needs to go first boundry.osm or data.osm ? 10:23 #navit: < _rd> (as maptool input) 10:37 -!- Brinky_ [brinky@faui2k3.org] has joined #navit 10:38 -!- Brinky_ is now known as Brinky 10:47 #navit: < _rd> tryagain, can you explain why navit needs the germany boundary to figure out if a Lindenstraße 6 is in Dettenhausen or not in Dettenhausen? That sounds somehow very odd.... 11:50 #navit: < tryagain> _rd you should have not only relation xml itself, but also all ways it refers to and nodes which that ways refer to. So xml from relation browse page is not sufficient. 11:51 #navit: < tryagain> order of boundary.osm and data.osm is not important 11:57 #navit: < tryagain> to download while relation with josm, go to file->download object (maybe get object, i'm translating from russian interface i have), then select object type "relation", enter object id and make sure the the second checkbox "Download relation members" is active, then press "download object" 11:57 #navit: < tryagain> s/while/whole/ 11:59 #navit: < tryagain> germany boundary is needed to know that admin_level=8 boundaries are actually town boundaries. This is not the same through all osm data and changes from country to country 12:02 #navit: < tryagain> For USA, you'll also need the country boundary to have admin_level=8 boundary relations converted to town polygons. 12:26 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection] 13:08 -!- tanago [~tanago@vlan-209-172-107.comnet.bg] has joined #navit 13:23 -!- udovdh [~udovdh@pindarots.xs4all.nl] has quit [Quit: Leaving] 13:30 -!- udovdh [~udovdh@pindarots.xs4all.nl] has joined #navit 13:47 -!- tg [~irc@eu.tgbit.net] has quit [Ping timeout: 248 seconds] 14:02 #navit: < _rd> tryagain, thanks for the detailed instructions, that enabled me to download the relation in josm. If it is just that information which maptool gets out of the country boundary, couldn't that be supplied by a command line option? Also why do I need the entire relation? Should have any German state data which have at least part of the German boundary have the informantion? 14:07 -!- tg [~irc@eu.tgbit.net] has joined #navit 14:27 #navit: < tryagain> _rd maptool needs a closed (without any gaps) country boundary polygon to be able to judge if a point (or subcoutry polygon) belongs to the given country. Then it can apply country-specific rules. So partial data won't help. 14:27 #navit: < tryagain> Did you have any success using the map built with boundary data? 14:37 #navit: < _rd> still building....I should have taken a smaller portion. 14:42 #navit: < tryagain> in your patch, you seem to be removing some street types. Why? 14:56 #navit: < Navit> martin-s * r5472 /trunk/navit/navit/xmlconfig.c: Add:Core:Possibility to use ezxml together with glib for easier debugging http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5472 15:24 #navit: < Navit> martin-s * r5473 /trunk/navit/navit/gui/internal/gui_internal_html.c: Add:gui_internal:Ignore p tag in html http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5473 15:27 #navit: < Navit> mdankov * r5474 /trunk/navit/navit/map/binfile/binfile.c: Fix:map_binfile:Do not return housenumber search result in unindexed search if street name is not specified for a given item. http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5474 16:19 #navit: < _rd> tryagain, I think it was because I saw duplicates. I rarely see surface without a tracktype anyways. And does it make sense to specify tracktype and surface? Aren't they somewhat redundant? 16:20 #navit: < _rd> But maybe I could reenable them, because --dedupe-ways should eliminate them anyways (?) 16:25 #navit: < tryagain> _rd dedupe-ways afaik dedupes ways from several osm files fed to maptool at the same time, like you're feeding germany boundary together with geofabrik data. It has nothing to do with duplicates generated by maptool from the same road. 16:56 -!- woglinde [~henning@f052230058.adsl.alicedsl.de] has joined #navit 18:07 -!- tanago2 [~tanago@vlan-209-173-132.comnet.bg] has joined #navit 18:09 -!- tanago [~tanago@vlan-209-172-107.comnet.bg] has quit [Ping timeout: 268 seconds] 18:10 -!- tanago [~tanago@vlan-132-6-38.comnet.bg] has joined #navit 18:11 -!- tanago2 [~tanago@vlan-209-173-132.comnet.bg] has quit [Ping timeout: 252 seconds] 18:13 -!- tanago [~tanago@vlan-132-6-38.comnet.bg] has quit [Read error: Connection reset by peer] 18:15 -!- tanago [~tanago@vlan-132-12-8.comnet.bg] has joined #navit 19:05 -!- rd_ [~rd@p57B48DEC.dip0.t-ipconnect.de] has joined #navit 19:06 -!- rd_ is now known as Guest86948 19:08 -!- _rd [~rd@p57B4B168.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds] 19:52 #navit: < Navit> martin-s * r5475 /trunk/navit/CMakeLists.txt /trunk/navit/cmake/navit_xml_parser_glade.cmake: Add:Build:Improved gettext handling http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5475 19:56 #navit: < Guest86948> tryagain, the germany boundary did not really help, I still get random matches for Lindenstraße 6 20:05 #navit: < Navit> martin-s * r5476 /trunk/navit/cmake/FindXGettextGlade.cmake: Fix:Build:Correctly check for xgettext http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5476 21:25 #navit: < Guest86948> tryagain, I rebuild the map again, this time it worked with the germany boundary, not sure why it did not work last time. 21:25 #navit: < Guest86948> Many thanks for your help :-) 21:45 -!- tanago [~tanago@vlan-132-12-8.comnet.bg] has quit [Quit: Nettalk6 - www.ntalk.de] 21:50 -!- Guest86948 [~rd@p57B48DEC.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 22:12 -!- drlizau [~liz@billiau.net] has joined #navit 22:27 -!- tryagain [~tryagain@178.216.76.16] has quit [Read error: Connection reset by peer] 22:46 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection] --- Log closed Sun May 05 00:00:19 2013