--- Log opened Sat Jun 01 00:00:19 2013
01:05 #navit: < Navit> The following compiles failed: http://download.navit-project.org/logs/navit/wince_arm/svn/navit-svn-5522.failed
02:18 -!- cp15` [breblu@p57B1DE6E.dip0.t-ipconnect.de] has joined #navit
02:18 -!- cp15 [chynpc@p57B1DE7E.dip0.t-ipconnect.de] has quit [Disconnected by services]
02:18 -!- cp15` is now known as cp15
02:19 -!- mode/#navit [+o cp15] by ChanServ
03:01 -!- noradtux [~noradtux@f054122138.adsl.alicedsl.de] has quit [Ping timeout: 276 seconds]
03:06 -!- noradtux [~noradtux@g224063184.adsl.alicedsl.de] has joined #navit
05:03 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has joined #navit
05:44 -!- drlizau [~liz@billiau.net] has joined #navit
05:46 #navit: < Navit> xenos1984 * r5523 /trunk/navit/navit/gui/internal/gui_internal_poi.c: Fix:gui/internal:Load POI icon from icon_src field for custom POIs. http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5523
07:54 #navit: < Navit> martin-s * r5524 /trunk/navit/navit/graphics/gtk_drawing_area/graphics_gtk_drawing_area.c: Add:graphics_gtk_drawing_area:Avoid double caching, allow to read image from buffer http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5524
08:11 -!- vvompy [~wompy@ip-178-203-195-6.unitymediagroup.de] has quit [Read error: No route to host]
08:13 -!- vvompy [~wompy@ip-178-203-195-6.unitymediagroup.de] has joined #navit
08:17 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
09:08 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
09:11 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
10:19 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit []
10:27 #navit: < pini> Hi Navit devs
10:35 #navit: < pini> I've just checked the wiki pages and provided some inputs in the brainstorming page
10:36 #navit: < pini> to me the key issues are:
10:36 #navit: < pini> * release process
10:38 #navit: < pini> * split up navit.xml or allow user to override bits of a fixed default configuration
10:51 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
11:32 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
11:48 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
12:04 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit [Ping timeout: 259 seconds]
12:08 -!- drlizau [~liz@billiau.net] has quit [Remote host closed the connection]
12:21 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
13:04 #navit: <@cp15> pini, can you give a few more details on the release process?
13:11 #navit: < pini> cp15: well, I think there should be more versionned releases
13:11 #navit: < pini> with identified short/long term goals
13:12 #navit: < pini> it's been a long time since release 0.2.0
13:12 #navit: < pini> next identified release is 0.5.0 and nobody knows what are the blockers for this release to happen
13:12 #navit: <@cp15> True, do you like to volunteer for a release manager?
13:13 #navit: < pini> aha... nice try :)
13:13 #navit: <@cp15> :-)
13:13 #navit: < pini> kazer was good at it
13:14 #navit: <@cp15> Yeah, but I think currently he appears about 5 times a year
13:14 #navit: < pini> to be honest I don't have enough time to invest in this task
13:15 #navit: < pini> and mu feelng isthat it's a very consuming one
13:15 #navit: < pini> * my feeling
13:16 #navit: <@cp15> Common problem... Many people who know what to do and nobody here who has time to do it
13:16 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit []
13:17 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
13:19 #navit: < pini> another way to go would be time driven releases
13:19 #navit: <@cp15> A new release every month or so?
13:19 #navit: < pini> say 0.5.0 is due for a given date
13:20 #navit: < pini> then every people involved would have to set their own goals for this release
13:20 #navit: <@cp15> And if the goals aren't met?
13:21 #navit: < pini> they're dropped... only met goals are released
13:21 #navit: < pini> it would imply two branches
13:22 #navit: < pini> navit, as many other floss projects is a do-ocraty
13:23 #navit: <@cp15> Well, with only volunteers I don't see a different model
13:23 #navit: < pini> what misses is a set of rules
13:24 #navit: <@cp15> Like?
13:24 #navit: < pini> it shouldn't be to time consuming to agree about a set of tasks/features and date for next release
13:25 #navit: < pini> then evrybody work as usual
13:25 #navit: < pini> when the release appoach, the achiveid tasks/features are merged in stable branch
13:25 #navit: < pini> * achieved
13:26 #navit: < pini> and the release is done; then focus on next one
13:27 #navit: < pini> might be a better approach than looking for a director
13:27 #navit: < Mineque> hello guys :)
13:27 #navit: < pini> _o/
13:27 #navit: <@cp15> Actually that seems to me more time consuming than saying: Currently it works good, lets call it a release
13:28 #navit: < pini> well, as a package maintainer, them main difficulty is to identify a stable svn revision and the corresponding changelog
13:30 #navit: < pini> and my feeling is that development goes many directions at a time with no short term goals, let alone long term ones
13:30 #navit: < pini> achieving a short term gives motivation
13:31 #navit: < pini> * short term goal
13:31 #navit: <@cp15> And achieving a long term goal?
13:32 #navit: < pini> let's start with short term ones :)
13:32 #navit: < pini> long temr is world domination ;P
13:33 #navit: < pini> removing autotools, switching to git, splitting navit.xml are acceptable short term goals
13:34 #navit: < pini> identifying a new feature and implementing it for all GUIs is another one
13:36 #navit: <@cp15> I am not sure whether git is the way to go. Using git you tend to create many local repositories and are not motivated to bring them into the main repository
13:36 #navit: < ventYl> git is the way to go
13:37 #navit: < pini> my experience with git is that it allow you to organize your work locally, and push it when it's ready / acceptable
13:37 #navit: < pini> remenber floss devs are motivated by publishing their work
13:37 #navit: < pini> they *will* push their work to the main repo
13:38 #navit: < pini> I've switched to git for debian packaging and at my day job a couple of years ago, and I won't go bask to svn
13:39 #navit: <@cp15> Lets take the linux kernel as an example. How many git repositories are there? Thousands? Nobody of them actually tries to push them to the main repository
13:39 #navit: < pini> a work which isn't pushed to a main repository is dead
13:39 #navit: < pini> who wants to work for nothing being released?
13:40 #navit: < ventYl> cp15: imho that isn't result of using git
13:40 #navit: <@cp15> Well, I often code a feature because I need it. If it works for me that is fine
13:40 #navit: < pini> cp15: but then you push it to svn
13:41 #navit: < pini> to release it
13:41 #navit: < pini> you won't keep it just for yourself
13:41 #navit: <@cp15> Yeah, because svn forces me to commit often to not loose track of the changes
13:41 #navit: < pini> git isn't different than svn in this regard
13:42 #navit: <@cp15> But a git commit is quite different to a svn commit. It has no publication function
13:42 #navit: < pini> well... I can't argue. just trust the devs
13:43 #navit: < pini> floss involved people *want* their work to be published
13:44 #navit: < pini> I started packaging navit for myself, and was too happy I could actually push it into Debian
13:44 #navit: < ventYl> cp15: it *has* publication function. main difference is in fashion repos are synced. in svn you cannot commit offline. in git you can while syncing repos after going online
13:44 #navit: < ventYl> i see no special benefit in not beeing able to commit offline
13:45 #navit: <@cp15> Well, for the development work pushing is completely optional
13:45 #navit: < ventYl> looks like variation from "security throught obscurity" to "publicity throught bureaucracy"
13:46 #navit: < ventYl> cp15: with bigger projects common habit is to pull from partial repositories to main one by maintainer
13:47 #navit: < pini> cp15: so you're afraid that devs could be satisfied with their own local forks?
13:48 #navit: < pini> floss just doesn't work this way
13:49 #navit: <@cp15> That is a good example... Works for me... I don't care about the rest and I don't want to have discussion about getting in the main tree
13:49 #navit: < pini> speaking for myself: I don't have svn commit rights
13:49 #navit: <@cp15> That is a problem which can be fixed :-)
13:49 #navit: < pini> when I encounter a problem, I make a patch that I submit to troc
13:49 #navit: < pini> * trac
13:50 #navit: <@cp15> And if you are lucky someone finds your patch
13:50 #navit: < pini> I've benn lucky so far :)
13:50 #navit: < pini> just to say that my patches don't sleep on my box
13:51 #navit: < pini> would be the same with git
13:51 #navit: < pini> since I use git locally
13:53 #navit: < pini> in fact there might be some people already using git for navit dev, through git-svn
13:54 #navit: <@cp15> Like me?
13:54 #navit: < pini> you'll tell us :)
13:54 #navit: <@cp15> There is even a semi public git clone of the svn which I am using as basis
13:55 #navit: <@cp15> But recently I tend to prefer svn again. I have about 10 repositories with changes rotting in them
13:56 #navit: < pini> matter of taste. what I loke with git is that you push your changes once they are completed
13:56 #navit: < pini> * like
13:57 #navit: <@cp15> One of its biggest advantages and disadvantages at the same time. I prefer to have problematic code that I know of in the repository over nearly working code I don't know of
13:58 #navit: < pini> well... keeping thing on svn doesn't prevent devs to use git locally. so it's not such a hot topic imho
13:59 #navit: < pini> I for myself will keep going with git anyway
13:59 #navit: <@cp15> Agreed :-) But the initial git-svn checkout is terribly slow with sourceforge
14:00 #navit: < pini> what I found out really anoying with sf svn is the changelog display
14:00 #navit: < pini> it takes ages
14:01 #navit: <@cp15> Yep... Since sf forces us to move the svn repository soon I will move it to our own server
14:05 #navit: < pini> ack. If you stay with svn, just try to set up a better svn viewer than sf's one
14:05 #navit: <@cp15> Any suggestions?
14:06 #navit: < pini> unfortunately no... I quit svn years ago. But I can have a look
14:07 #navit: < pini> while on it, please have a tour on github; I really like their interface
14:10 #navit: < pini> Haw about trac svn?
14:10 #navit: <@cp15> There are requests that we move from trac to mantis
14:10 #navit: < pini> arghhh... please no!
14:11 #navit: <@cp15> Sigh... x people, (x+1) opinions
14:11 #navit: < pini> I have to use mantis at work. trac has my preference, by far
14:12 #navit: < pini> trac has a great advantage over any other ticket tracking system: it is *simple*
14:13 #navit: <@cp15> Why? Actually I don't care much, I tend to not look into trac and I probably won't get better with mantis. But what I dislike is the way python works together with apache. If you change something in a python script, you have n apache instances using the old version and m using the new one
14:14 #navit: < pini> I only know trac on the user experience side. not on the admin side
14:16 #navit: < pini> anyway... I won't make a real case about that. do-ocraty an so on....
14:17 #navit: < pini> you might want to have a look at redmine too
14:21 #navit: < pini> changing subject: do you think it's possible to have a user-side navit.xml defining only the preferecens the user want to change? i.e. overriding settings set by a default navit.xml.
14:30 #navit: < Mineque> i've used to use redmine some time ago
14:30 #navit: < Mineque> it's nice but you'll have to look closer at svn, git integration
14:30 #navit: < Mineque> because it didnt explore it much
14:30 #navit: < Mineque> *I
14:33 #navit: <@cp15> pini, I like to take a different approach (partially already implemented). The navit.xml stays fixed and the user can configure the required stuff via gui
14:36 #navit: < xenos1984> but will these gui settings be saved somewhere or does the user have to do this configuration each time he uses navit?
14:38 #navit: < pini> cp15: the problem I ofent encounter is having to sync the user's navit.xml with the project's one
14:39 #navit: < pini> having local user preferences overriding global navit.xml should lesser the burden
14:40 #navit: < pini> the last debian navit but is related to that (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710494)
14:40 #navit: < xenos1984> i agree with pini - i would also prefer a few custom settings, and a default navit.xml that gets updated with new navit releases
15:27 #navit: < Navit> martin-s * r5525 /trunk/navit/navit/graphics.c /trunk/navit/navit/graphics.h: Add:Core:Begin of support for reading icons from zip file http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5525
15:46 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit []
15:47 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
15:53 #navit: < pini> afk
16:01 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has quit [Ping timeout: 264 seconds]
16:09 #navit: < Navit> martin-s * r5526 /trunk/navit/navit/gui/internal/gui_internal.h /trunk/navit/navit/gui/internal/gui_internal_widget.c: Fix:gui_internal:Cleaned up scroll buttons a bit http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5526
16:30 #navit: < Navit> martin-s * r5527 /trunk/navit/navit/gui/internal/gui_internal.c /trunk/navit/navit/gui/internal/gui_internal_keyboard.c /trunk/navit/navit/gui/internal/gui_internal_poi.c /trunk/navit/navit/gui/internal/gui_internal_widget.c /trunk/navit/navit/gui/internal/gui_internal_widget.h: Add:gui_internal:Made scroll buttons more abstract http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5527
16:39 -!- _rd [~rd@p5088F861.dip0.t-ipconnect.de] has joined #navit
17:45 -!- Mineque_ [~Mineque@178.217.184.139] has joined #navit
17:45 -!- Mineque_ [~Mineque@178.217.184.139] has quit [Client Quit]
19:11 #navit: < _rd> Has anybody managed to generate altitude maps for navit from strm2 data?
19:12 #navit: < _rd> Found a few days back the height_line_x in navit_shipped.xml....concluding that somebody must have managed.
19:12 #navit: < _rd> Is there some reference which documents the process?
19:12 #navit: < _rd> would http://www.kleineisel.de/blogs/index.php/osmmap/ work as maptool input data?
19:15 #navit: <@cp15> _rd, if you want to document and maintain the process I can give you instructions
19:40 #navit: < _rd> cp15, I can document the process, if I can maintain the process I can only tell, when I know it ;-)
19:42 #navit: <@cp15> Ok :-)
19:42 #navit: <@cp15> Do you know gdal?
19:43 #navit: < _rd> No, I did not use that before. But at least it comes with Debian.
19:44 #navit: <@cp15> Ok, you need the gdal_contour program. Check that you have it installed
19:45 #navit: < _rd> yes, I have that, version 1.9.0
19:48 #navit: <@cp15> Ok, download the raw data from http://srtm.csi.cgiar.org/
19:51 #navit: <@cp15> When done unzip the data. You should get one or more tif files
19:52 #navit: < _rd> I did that a few years back
19:52 #navit: < _rd> rd@blackbox:/mnt/disk/opt/srtmdata$ ls dds.cr.usgs.gov/srtm/version2_1/
19:52 #navit: < _rd> Documentation index.html NAVMac800QSFile SRTM3 SRTM30 SWBD
19:52 #navit: < _rd> Do you know if they have been updated?
19:53 #navit: < _rd> yes, the homepage says so...
19:54 #navit: <@cp15> Doesn't matter. The old data is fine
19:55 #navit: <@cp15> convert the tif images to a shapefile using "gal_contour -a name filename.tif filename.shp -i 10"
19:57 #navit: < _rd> while downloading the new ones, I can work on the old ones at least.
19:57 #navit: <@cp15> Then download http://www.navit-project.org/~cp15/shp2osm.pl
19:58 #navit: <@cp15> Convert the shape files to osm with that tool. You might need to install additional perl modules
19:58 #navit: < _rd> do I need to run gal_contour for each tiff file?
19:58 #navit: <@cp15> Yes... Theoretically you could merge the tiffs into larger ones, but gdal_contour works already bad enough on the existing size
19:59 #navit: <@cp15> For a beginning I would pick the one which contains your location
20:00 #navit: <@cp15> When you have the osm file, process it with maptool as usual
20:01 #navit: < _rd> Do I get for each shape file an osm file and then I run them all throug maptool?
20:02 #navit: <@cp15> For a beginning yes, of course this means that you get a map for each tif file which is quite inconvenient
20:02 #navit: <@cp15> I will show you later how to merge navit maps
20:04 #navit: < Navit> martin-s * r5528 /trunk/navit/navit/gui/internal/gui_internal.h /trunk/navit/navit/gui/internal/gui_internal_html.c /trunk/navit/navit/gui/internal/gui_internal_widget.c /trunk/navit/navit/gui/internal/gui_internal_widget.h: Add:gui_internal:Further code in preparation of making the box widget scrollable http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5528
20:11 #navit: < Navit> martin-s * r5529 /trunk/navit/navit/navit_shipped.xml: Add:Core:Activate code to make layout setting persistent http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5529
20:26 #navit: < _rd> I opened the generated osm file with josm.
20:27 #navit: < _rd> Looks good, I get some kind of realistic values, i.e. there are tags contour_ext and name. name is a number which seems to represent the elevantion.
20:28 #navit: < _rd> What does not work right now is that the area for which the osm data seem to be generated is somewhere in the north sea.
20:29 #navit: < _rd> That is not what I expected, since I picked a tif from southern germany: SRTM3/Sueddeutschland/N47E006.tif
20:32 #navit: <@cp15> Can you run gdalinfo on N47E006.tif?
20:35 -!- Usul1 [~matthias@stw-104-013.ras.uni-rostock.de] has joined #navit
20:35 #navit: < Usul1> hi everybody :)
20:36 #navit: * Usul1 hero of the day: compiled navit on Mint without big strugles :D
20:36 #navit: <@cp15> Then you can finally join the development :-)
20:37 #navit: < Usul1> well yes, I wanted to see how the current svn looks like :)
20:37 #navit: < Usul1> but currently all is a bit to much
20:38 #navit: < Usul1> BTW if I want to replace the old map icons with the original OSM map icons, can I just do it and submit an patch?
20:38 #navit: <@cp15> What license do they have?
20:38 #navit: < Usul1> CC0
20:39 #navit: < Usul1> http://wiki.openstreetmap.org/wiki/Map_Icons
20:39 #navit: <@cp15> I think a patch isn't the correct way. Better but them into a tar, since diffs doesn't make much sense
20:39 #navit: < Usul1> ok, should I pay attention to the SVG dimensions or something similar?
20:40 #navit: <@cp15> Which one of the many possibilities from Map_Icons do you like to choose?
20:40 #navit: < Usul1> the very first is the official mapnik style http://www.sjjb.co.uk/mapicons/contactsheet
20:41 #navit: < Usul1> (that wiki page was one of my very first wiki edits at OSM :))
20:42 #navit: <@cp15> Ok, I am fine with the icons. But they are b/w which won't look too nice
20:43 #navit: <@cp15> I think it doesn't make sense to color them by hand so a script is needed
20:43 #navit: < _rd> http://paste.kde.org/756140/ shows the output of gdalinfo
20:44 #navit: <@cp15> And what coordinates do you get in the osm output?
20:45 #navit: < Usul1> Here seems to be a converter script: https://trac.openstreetmap.org/browser/applications/share/map-icons
20:46 -!- tryagain [~tryagain@178.216.76.15] has joined #navit
20:46 #navit: < _rd> Something like 53N and 3E.
20:46 #navit: < Usul1> oh srtm :)
20:47 #navit: <@cp15> Hmm...
20:48 #navit: <@cp15> can you try running ogrinfo on the generated shape file?
20:52 #navit: < _rd> http://paste.kde.org/756146/
20:52 #navit: < _rd> Does not provide a whole lot of information to me.
20:55 -!- Mineque [~Mineque@178.217.184.139] has quit [Quit: Lost terminal]
20:56 -!- Mineque [~Mineque@178.217.184.139] has joined #navit
20:58 #navit: < Usul1> pini: are you here?
20:59 #navit: < xenos1984> hi Usul1, actually i had a closer look at the icons after our discussion yesterday, and i figured out how one can style / color them a bit better ;)
20:59 #navit: * Usul1 is listening carefully :)
20:59 #navit: < xenos1984> and without this hacky converter script... instead it takes some CSS magic
21:00 #navit: < Usul1> coool OO
21:00 #navit: < xenos1984> well, i need to edit the svg files a bit by hand...
21:00 #navit: < xenos1984> but the result looks quite pretty in the end
21:00 #navit: < Usul1> If I can help, just give me a ping :)
21:00 #navit: < xenos1984> and i also have an idea how to get icons both with and without background from the same file :)
21:01 #navit: < _rd> Are there cmake build issues right now?
21:01 #navit: < xenos1984> i will try to implement that in a minute and put it online, then you can have a look ;)
21:02 #navit: < _rd> [ 94%] Generating navit.pot
21:02 #navit: < _rd> /usr/bin/xgettext: /home/rd/SW.nobackup/navit-clean-build/po/navit_shipped.glade:2:1: XML or text declaration not at start of entity
21:02 #navit: < _rd> Is the issue I ran into right now.
21:02 #navit: < Usul1> BTW I was suprised that svn tags were use, but currently they eem to be abandoned?
21:06 #navit: < Usul1> FYI pini added a few hints about further development from his point of view as Debian maintainer: http://wiki.navit-project.org/index.php?title=Brainstorming&curid=7096&diff=14764&oldid=14407&rcid=32986
21:07 #navit: < tryagain> pini. Regarding navit.xml split, i've found a nice sample inside neo-cs skin from https://wiki.navit-project.org/index.php/OSD_Layouts . Author uses xi:inclue to pull permanent parts of system-wide navit.xml to personal one.
21:07 #navit: < tryagain> extracted user-side navit.xml is here: http://pastebin.com/8S0BKg1E
21:08 #navit: < tryagain> Looks very nice. Thoiugh i have not tested it yet :)
21:09 #navit: < Usul1> tryagain: interesting :)
21:10 #navit: < Usul1> But I'm still confused of all the navit.xml files and file parts which substitude each other
21:10 #navit: < Usul1> No idea how all that fit together
21:12 #navit: < tryagain> hm will pull the Car vehicle profile from the default file. You also may paste your own vehicle profile there, or xi:include it from another file.
21:12 #navit: < xenos1984> some example SVG file with color styling: http://manuelhohmann.dyndns.org/osm/Icons/svg/amenity/prison.svg
21:12 #navit: < Mineque> xenos1984: but why prison example? :D
21:12 #navit: < xenos1984> and this is where the colors come from: http://manuelhohmann.dyndns.org/osm/Icons/svg/default.css
21:12 #navit: < xenos1984> Mineque: because it uses semi-transparency for the prisoner ;)
21:12 #navit: < Usul1> quiet well done xenos1984 :)
21:13 #navit: < xenos1984> thanks Usul1 :)
21:14 #navit: < Usul1> Can we derive icons with box (e.g. for UI buttons, lists, ...) and without them (for map) ?
21:14 #navit: < xenos1984> and the trick is: if i use a svg to png converter that understands css media types (such as batik), i can specify either "screen" (which gives the result you see, with background) or "print" (which gives an icon without background)
21:15 #navit: < xenos1984> so, yes, we can ;)
21:15 #navit: < Usul1> I understand, that is pretty cool :)
21:16 #navit: < xenos1984> there are also some icons i'd like to improve / redesign... like the bed & breakfast
21:16 #navit: < Usul1> What do you think, should we use the filenames by sjb and fix the map styles, or just replacing the existing files?
21:17 #navit: < xenos1984> hm... good question... i haven't looked at the filenames yet, i guess one should see which ones fit better
21:18 #navit: < Mineque> xenos1984: are you up to date with osd layouts?
21:18 #navit: < xenos1984> Mineque: hm... more or less, haven't done anything in this direction recently
21:19 #navit: < tryagain> BTW we now support $NAVIT_USER_DATADIR in image path, so we could use instead of
21:19 #navit: < tryagain> so no manual editing of osd skins is needed anymore
21:19 #navit: < Usul1> +1
21:19 #navit: < xenos1984> Usul1: what do you think about this for bed & breakfast? http://manuelhohmann.dyndns.org/osm/Icons/svg/accommodation/bedbreakfast.svg i don't really like the "B&B" in sjb's icon, it's just not international to use letters as abbreviations ;)
21:20 #navit: < Usul1> looks good
21:20 #navit: < Usul1> but do we have a b&b poi currently? http://wiki.navit-project.org/index.php/User:Usul/MapIconsNG
21:21 #navit: < xenos1984> hm... not really, but i guess i was just in the mood to design this ;)
21:21 #navit: < Usul1> hehe :)
21:21 #navit: < Mineque> tryagain: you're using that one 003 or just example? ;)
21:22 #navit: < Usul1> But maybe we should restrain ourself with introducing new icons. To much different icons for (mostly) the same POI category results in somewhat like visual clutter
21:25 #navit: < xenos1984> well, of course there should be only one icon for each poi type ;)
21:26 #navit: < Usul1> I tried to point out, that at the map, a seperation between hotel/hostel/B6B might not be THAT important ;)
21:26 #navit: < tryagain> using for example :)
21:26 #navit: < Usul1> BTW is anyone using Eclipse with the cmake generator?
21:27 #navit: < Mineque> hehe, i would be suprised if it still works
21:28 #navit: < tryagain> seems to be nothing very special at first sight... Why should it be broken?
21:32 #navit: <@cp15> _rd, indeed not helpful. Can you try ogrinfo with the -al or -so options?
21:34 #navit: < Mineque> tryagain: really old, unmaintained xml ;)
21:37 #navit: < Usul1> Mineque: Do you know if anybody still uses this config editor? http://sourceforge.net/projects/navitconfigurat/
21:37 #navit: < tryagain> pini Also, for linux distributions it might be helpful to xi:include $NAVIT_USER_DATADIR/osd.xml to pull user-selected (symlinked) skin.
21:38 #navit: <@cp15> I think the navitconfigurator is pretty new
21:38 #navit: < Usul1> cp15: I think it had already a wiki page ;)
21:40 #navit: < _rd> http://paste.kde.org/756164/
21:40 #navit: < _rd> is for -al, -so does not give useful information
21:42 #navit: <@cp15> Ok, looks like the coordinates get transformed
21:43 #navit: < _rd> so the shape file still look ok?
21:43 #navit: <@cp15> Not sure, it would be better if it would contain wgs84 coordinates
21:44 #navit: < _rd> http://paste.kde.org/756170/
21:44 #navit: < _rd> The osm definitely contains wrong coordinates
21:45 #navit: < Usul1> You try to convert SRTM contour lines?
21:45 #navit: <@cp15> You haven't used the GK option?
21:50 #navit: < _rd> which GK option?
21:50 #navit: <@cp15> The perl script has one, but don't use it
21:51 #navit: <@cp15> Strange, for me gdal_contour gives a wgs84 shapefile
21:52 #navit: <@cp15> Layer SRS WKT:
21:52 #navit: <@cp15> GEOGCS["GCS_WGS_1984",
21:52 #navit: < _rd> I did use the GK option: ./shp2osm.pl test.shp GK
21:54 #navit: <@cp15> Ah, then try without
21:54 #navit: <@cp15> On the other hand I doubt it will work better
21:54 #navit: < _rd> Do you have an idea why my navit build fails?
21:55 #navit: <@cp15> What error do you get?
21:56 #navit: < Usul1> I updated my todays experience in the wiki http://wiki.navit-project.org/index.php/Eclipse
21:56 #navit: < Navit> martin-s * r5530 : Add:Build:Experimental script for recoloring svg images http://navit.svn.sourceforge.net/viewvc/navit?view=revision&revision=5530
21:56 #navit: < Usul1> good night!
21:56 -!- Usul1 [~matthias@stw-104-013.ras.uni-rostock.de] has quit [Quit: Leaving.]
21:56 #navit: < _rd> at [ 94%] Generating navit.pot
21:57 #navit: < _rd> /usr/bin/xgettext: /home/rd/SW.nobackup/navit-clean-build/po/navit_shipped.glade:2:1: XML or text declaration not at start of entity
21:57 #navit: <@cp15> What does navit_shipped.glade contain?
21:57 -!- drlizau [~liz@billiau.net] has joined #navit
21:58 #navit: <@cp15> Ok, more tomorrow... Good night
21:59 #navit: < Mineque> Usul1 i've never used it.
21:59 #navit: < Mineque> uh too late...
22:00 #navit: < _rd> without the GK josm cannot make sense of the .osm file anymore.
22:04 #navit: < _rd> my navit builds again, thanks.
22:22 #navit: < xenos1984> gn8
22:22 -!- xenos1984 [~quassel@131.237.196.88.dyn.estpak.ee] has quit [Remote host closed the connection]
23:51 -!- tryagain [~tryagain@178.216.76.15] has quit [Remote host closed the connection]
--- Log closed Sun Jun 02 00:00:19 2013