--- Log opened Tue Apr 15 00:00:02 2014
05:04 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has joined #navit
05:37 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has joined #navit
06:28 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
07:06 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has joined #navit
08:02 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
08:28 -!- drlizau [~liz@billiau.net] has joined #navit
10:29 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has joined #navit
10:41 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
12:22 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
15:06 -!- tryagain_ [~tryagain@87.245.203.24] has joined #navit
15:11 -!- xenos1984_ [~quassel@131.237.196.88.dyn.estpak.ee] has joined #navit
15:12 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has quit [Ping timeout: 265 seconds]
17:58 -!- tryagain_ is now known as tryagain
19:02 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has joined #navit
19:16 -!- j_f-f [~quassel@orion2589.server4you.de] has quit [Remote host closed the connection]
19:19 -!- j_f-f [~quassel@orion2589.server4you.de] has joined #navit
19:45 -!- sleske [~sleske@p4FD454D6.dip0.t-ipconnect.de] has joined #navit
19:45 #navit: < sleske> Hi!
19:52 -!- mlechner [~mlechner@p54BAA5FB.dip0.t-ipconnect.de] has joined #navit
19:55 #navit: < sleske> tryagain: Thanks for the comments on trac #1177 (houseno. interpolation for OSM).
19:55 #navit: < tryagain> np
19:56 #navit: < sleske> Ah, you're actually online. Nice :-).
19:56 #navit: < tryagain> :)
19:56 #navit: < sleske> Well, I'm still trying to understand what maptool does to transfrom OSM files into binfiles...
19:56 #navit: < sleske> ... and how I could put in OSM interpolation information.
19:56 #navit: < sleske> My current plan is:
19:57 #navit: < sleske> Transform the OSM interpolation data into special binfile attributes, like "interpolation_odd=23-35".
19:58 #navit: < sleske> There already is interpolation code in the housenumber search in search.c, so the search would work automatically once I add the new attributes to the list of attributes it uses.
19:58 #navit: < sleske> This part works, I tested it by faking the interpolation attributes in a binfile :-).
19:59 #navit: < tryagain> Why don't you use existing attributes used in the search code?
20:00 #navit: < sleske> Mainly because the existing attributes are too specific - I'd need to arbitrarily choose one, which seems ugly. Also, they are apparently used by a converter which cp15 wrote (but which is not public), so I didn't want to use them for a different purpose.
20:02 #navit: < tryagain> hm... If you can figure out their purpose from the code, i guess it would be better to reuse them
20:02 #navit: < tryagain> why do you say different purpose?
20:03 #navit: < sleske> Well, the existing attrs are of the form house_number_left* and house_number_right* (in attr_def.h).
20:03 #navit: < sleske> They are apparently used by cp15's converter for TomTom maps.
20:04 #navit: < sleske> It seems that in those maps, the interpolation information is on the street itself, not on a dedicated "interpolation way" linek in OSM. Thus for TomTom you need to indicate whether the interpolation is for the right or left street side - thus the left/right thing. This would not make sense for OSM interpolations, where right/left is meaningless.
20:05 #navit: < tryagain> ah, true
20:05 #navit: < tryagain> then new attr could be an option
20:06 #navit: < sleske> Well, there's also house_number_{left/right/}interpolation in attr_def.h, which is apparently not used at all. Still uses left and right.
20:07 #navit: < sleske> Yes, so I thought the cleanest solution would be something like interpolation_1_step, and interpolation_2_step, and maybe interpolation_alpha (for things like 22a, 22b ...).
20:09 #navit: < tryagain> sounds reasonable
20:10 #navit: < sleske> Anyway, that is mostly an stylistic detail, which can be cleaned up later.
20:10 #navit: < sleske> I'm really stuck on how to get the interpolation information into the binfile :-(.
20:11 #navit: < sleske> The problem: The interpolation information is spread between the nodes (which have the house numbers), and the interpolation ways (which record the fact that there is an interpolation).
20:11 #navit: < sleske> For my solution, I need all that information on the way.
20:11 #navit: < sleske> So I must somehow copy the houseno. from node to way - but nodes and ways are processed individually in maptool.
20:12 #navit: < sleske> At the moment I'm trying to understand how it works for node coordinates (which also need to be copied to ways), to do the same.
20:14 #navit: < tryagain> Worst thing is that you don't know which nodes you'll need. Any addressed node could appear as part of interpolation. But you probably won't be able to store all addressed nodes.
20:15 #navit: < sleske> Yes, sad but true.
20:15 #navit: < tryagain> So you'll have to select all interpolations during way processing (this can be done during parsing phase), probably storing them in a file
20:16 #navit: < tryagain> After that, you'll have to process all nodes while keeping interpolation table in memory
20:18 #navit: < tryagain> that could be done in a way similar to one we have to process relations
20:19 -!- drlizau [~liz@billiau.net] has joined #navit
20:24 -!- mlechner [~mlechner@p54BAA5FB.dip0.t-ipconnect.de] has quit [Quit: Verlassend]
20:24 #navit: < tryagain> You can treat address interpolation as a relation. So to read your interpolations file you implement a function like process_associated_street_setup which defines nodes/ways of interest and function(s) to act on them
20:25 #navit: < tryagain> Then process the whole nodes table
20:26 #navit: < tryagain> But that means another whole node table pass..
20:29 #navit: < sleske> Thanks for all that information. I'll need to process that... thankfully IRC is logged :-).
20:30 #navit: < tryagain> np
20:30 #navit: < tryagain> I have to go now
20:30 #navit: < tryagain> see you
20:30 -!- tryagain [~tryagain@87.245.203.24] has quit [Remote host closed the connection]
20:30 #navit: < sleske> ok, see you!
20:34 #navit: < sleske> tryagain: One more question about OSM interpolation. Maybe you can answer it later (I'll check the logs).
20:34 #navit: < sleske> I was thinking of just re-using the system for the coordinates.
20:35 #navit: < sleske> We already store all the node coordinates, because we need them to write out the ways.
20:35 -!- _rd [~rd@p57B48D57.dip0.t-ipconnect.de] has quit [Ping timeout: 265 seconds]
20:35 #navit: < sleske> Can't I just store the houseno information along with the coordinates? Then that information would also be available when writing out the interpolation ways.
20:35 #navit: < sleske> Or am I missing something?
20:51 #navit: < sleske> Well, gotta go now, too. See you!
20:51 -!- sleske [~sleske@p4FD454D6.dip0.t-ipconnect.de] has quit [Quit: leaving]
20:51 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
21:33 -!- xenos1984_ [~quassel@131.237.196.88.dyn.estpak.ee] has quit [Remote host closed the connection]
--- Log closed Wed Apr 16 00:00:02 2014