roadnav-devel Mailing List for Roadnav (Page 2)
Status: Inactive
Brought to you by:
rllynch
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
(9) |
Oct
(3) |
Nov
(11) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(6) |
Feb
(6) |
Mar
(2) |
Apr
(25) |
May
(42) |
Jun
(4) |
Jul
(8) |
Aug
(4) |
Sep
(8) |
Oct
(16) |
Nov
(7) |
Dec
(2) |
2008 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
(23) |
Aug
(13) |
Sep
|
Oct
(14) |
Nov
|
Dec
(1) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Dustin S. <du...@vi...> - 2008-08-29 01:59:38
|
So I was thinking about playing with an idea... I'm thinking about the best way to get rid of the initial US-map downloading (its a problem due to some redesign stuff I've been doing), and the main problem with all of that is then the user is left with this *huge* blank space where the map is supposed to be. So then I thought, what if we showed the generic NASA image initially, then show the user the download window initially (thus allowing the frame to load, thus getting rid of some of the issues I've been hitting on... ) http://visibleearth.nasa.gov/view_rec.php?id=2433 I haven't actually added the ability to render this, but I might add it later tonight if I still think its a good idea. My thought would be that it would be included in the initial distribution, and when the user starts up, thats displayed to them, and would continue to be until a reasonable zoom level. I've got the 8000x4000 image compressed to 3MB (so ideally it could be included in the download/distribution package), and it doesn't look all that bad until you zoom in at like the state level. I'm going to see how big the 21600 image goes down to... Dustin -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-08-28 18:31:15
|
Moyer, Todd (TMOYER) wrote: > I've been meaning to try to play around with the roadnav skins. I was > thinking of shooting for something like this: > > http://i-go.com/en/products/iGO_2006_SD/screenshots.php > > I'm not sure how close we could get with just skinning, but I'm willing to > give it a try, and I could definitely write up the documentation as I went. > But it seems like I should wait to see if the whole skin creation process is > going to change... > I would say if you're interested in re-skinning roadnav, go for it. Were you planning on just doing it, or making a mock-up in photoshop or something first? A limitation I see with the current skin system is that its all fixed sizes -- can't readjust anything, and it doesn't "flow". All of the buttons are static images, which (obviously) aren't resizable or localizable. I was thinking at some point it might be useful to create a set of controls that can draw themselves in a certain way. Another problem is that the current skin mechanism only applies to the main window -- you cant skin any of the other dialogs at the moment. I would say if you're interested in re-skinning roadnav, go for it. In fact, what could be useful is if you used an XRC designer and created XRC versions of all the different dialogs that roadnav currently supports -- and then redesign them as appropriate... then we could work on integrating those into the actual code. Dustin > > Todd Moyer > ARINC > Principal Engineer > 410.266.4241 > > > --------------------- > This e-mail (including any attachments) is intended only for the use of the > individual or entity named above and may contain privileged, proprietary, or > confidential information. The information may also contain technical data > subject to export control laws. > --------------------- > > -----Original Message----- > From: roa...@li... > [mailto:roa...@li...] On Behalf Of Dustin > Spicuzza > Sent: Wednesday, August 27, 2008 8:39 PM > To: Roadnav Dev List > Subject: [Roadnav-devel] Skins, XRC, and OpenStreetMap > > Hey, > > Does anyone have any thoughts about the current skin/theme system? > Namely, has anyone actually created skins other than the defaults? I noticed > one of the items on the TODO list is "Create better skin documentation"... > I have finally started playing with wxWidgets XML resource system, XRC, and > its interesting -- and could be a viable solution to replace the existing > skinning stuff (and do it on all dialogs). > > I've found XRC to be a useful way to separate the design of the dialog from > the actual implementation. Another advantage I can see is that we can use a > number of wx-standard tools (wxFormBuilder, XRCed, etc) to modify (and > preview) the XRC files, instead of editing the skin files by hand. XRC > naturally supports all of the wx controls, and I believe some types of > custom controls as well. For those interested, I've found that wxFormBuilder > is an excellent XRC prototyping tool. > > To help jumpstart our transition to better OpenStreetMap support, I created > an test interface to the OSM "Name Finder" (used to search for items and > return their coordinates/etc so they can be downloaded), and placed it in > libroadnav/branches/DownloadWindowTest. Its a standalone executable, so it > doesn't actually download maps, but it can display results of searches for > places. Unfortunately, the OSM name finder is rather limited in the types of > things that it can search for currently. > > I compiled a Windows executable if you're interested in seeing it: > http://www.virtualroadside.com/DownloadWindow.zip , you have to unzip it > into a directory so the XRC file is in the same directory. If you want, you > can modify the xrc file quite easily too. :) > > Dustin > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes Grand prize is a trip for two to an Open Source event anywhere in the > world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > |
From: Moyer, T. \(TMOYER\) <TM...@ar...> - 2008-08-28 17:19:44
|
I've been meaning to try to play around with the roadnav skins. I was thinking of shooting for something like this: http://i-go.com/en/products/iGO_2006_SD/screenshots.php I'm not sure how close we could get with just skinning, but I'm willing to give it a try, and I could definitely write up the documentation as I went. But it seems like I should wait to see if the whole skin creation process is going to change... Todd Moyer ARINC Principal Engineer 410.266.4241 --------------------- This e-mail (including any attachments) is intended only for the use of the individual or entity named above and may contain privileged, proprietary, or confidential information. The information may also contain technical data subject to export control laws. --------------------- -----Original Message----- From: roa...@li... [mailto:roa...@li...] On Behalf Of Dustin Spicuzza Sent: Wednesday, August 27, 2008 8:39 PM To: Roadnav Dev List Subject: [Roadnav-devel] Skins, XRC, and OpenStreetMap Hey, Does anyone have any thoughts about the current skin/theme system? Namely, has anyone actually created skins other than the defaults? I noticed one of the items on the TODO list is "Create better skin documentation"... I have finally started playing with wxWidgets XML resource system, XRC, and its interesting -- and could be a viable solution to replace the existing skinning stuff (and do it on all dialogs). I've found XRC to be a useful way to separate the design of the dialog from the actual implementation. Another advantage I can see is that we can use a number of wx-standard tools (wxFormBuilder, XRCed, etc) to modify (and preview) the XRC files, instead of editing the skin files by hand. XRC naturally supports all of the wx controls, and I believe some types of custom controls as well. For those interested, I've found that wxFormBuilder is an excellent XRC prototyping tool. To help jumpstart our transition to better OpenStreetMap support, I created an test interface to the OSM "Name Finder" (used to search for items and return their coordinates/etc so they can be downloaded), and placed it in libroadnav/branches/DownloadWindowTest. Its a standalone executable, so it doesn't actually download maps, but it can display results of searches for places. Unfortunately, the OSM name finder is rather limited in the types of things that it can search for currently. I compiled a Windows executable if you're interested in seeing it: http://www.virtualroadside.com/DownloadWindow.zip , you have to unzip it into a directory so the XRC file is in the same directory. If you want, you can modify the xrc file quite easily too. :) Dustin ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Roadnav-devel mailing list Roa...@li... https://lists.sourceforge.net/lists/listinfo/roadnav-devel |
From: Dustin S. <du...@vi...> - 2008-08-28 00:38:41
|
Hey, Does anyone have any thoughts about the current skin/theme system? Namely, has anyone actually created skins other than the defaults? I noticed one of the items on the TODO list is "Create better skin documentation"... I have finally started playing with wxWidgets XML resource system, XRC, and its interesting -- and could be a viable solution to replace the existing skinning stuff (and do it on all dialogs). I've found XRC to be a useful way to separate the design of the dialog from the actual implementation. Another advantage I can see is that we can use a number of wx-standard tools (wxFormBuilder, XRCed, etc) to modify (and preview) the XRC files, instead of editing the skin files by hand. XRC naturally supports all of the wx controls, and I believe some types of custom controls as well. For those interested, I've found that wxFormBuilder is an excellent XRC prototyping tool. To help jumpstart our transition to better OpenStreetMap support, I created an test interface to the OSM "Name Finder" (used to search for items and return their coordinates/etc so they can be downloaded), and placed it in libroadnav/branches/DownloadWindowTest. Its a standalone executable, so it doesn't actually download maps, but it can display results of searches for places. Unfortunately, the OSM name finder is rather limited in the types of things that it can search for currently. I compiled a Windows executable if you're interested in seeing it: http://www.virtualroadside.com/DownloadWindow.zip , you have to unzip it into a directory so the XRC file is in the same directory. If you want, you can modify the xrc file quite easily too. :) Dustin |
From: Dustin S. <du...@vi...> - 2008-08-13 16:57:23
|
Steve Franks wrote: > > I'm all for little bitty widgets, myself. The map is king. Maybe a > fullscreen mode would be a good way of having rich UI sometimes, and > minimal UI others (do I recall it's already in there?). Shame I'm at > work and can't check. Still, I'd like a minimalist theme in any > event. Probably more hotkeys too, I'm a serious hotkey junky. > Actually, I'd be surprised if there isn't some widget/button generator > tool out there, maybe for web design? Simple questions like color, XY > size, round/square corners, 3d edges, etc, would go a long distance in > a short time...spending a couple hours fooling around with > gimp/photoshop is fun sometimes, but once you have kids, forget > finding the time ;) > > Steve > Right, you're talking about the skin though (which also needs some work too), I'm talking exclusively about the colors used to draw the map. Sorry for the confusion. Dustin |
From: Dustin S. <du...@vi...> - 2008-08-13 16:57:16
|
Steve Franks wrote: > > I'm all for little bitty widgets, myself. The map is king. Maybe a > fullscreen mode would be a good way of having rich UI sometimes, and > minimal UI others (do I recall it's already in there?). Shame I'm at > work and can't check. Still, I'd like a minimalist theme in any > event. Probably more hotkeys too, I'm a serious hotkey junky. > Actually, I'd be surprised if there isn't some widget/button generator > tool out there, maybe for web design? Simple questions like color, XY > size, round/square corners, 3d edges, etc, would go a long distance in > a short time...spending a couple hours fooling around with > gimp/photoshop is fun sometimes, but once you have kids, forget > finding the time ;) > > Steve > Right, you're talking about the skin though (which also needs some work too), I'm talking exclusively about the colors used to draw the map. Sorry for the confusion. Dustin |
From: Steve F. <ste...@ie...> - 2008-08-13 16:25:32
|
On Wed, Aug 13, 2008 at 12:03 AM, Dustin Spicuzza <du...@vi...> wrote: > Hey, > > So I've been thinking about this a bit, and I'm wondering if anyone has > any opinions about the current map themes? Personally, I hate the > daytime theme (I like the nighttime one for the most part though). > Which, I realize that users can adjust the map themes if they don't like > it, but it might be nice to give a nicer default. > > What do you think of making the default daytime theme look more like > google maps or mapquest? I don't have a handheld GPS system, but it > might also be useful to see what colors they use and borrow some ideas > from there too. > > I've played with the colors a bit, and *some* of the color settings > wouldn't make a whole lot of sense to use, but others (like the water) > work out really well for the drawing that roadnav does. I'm not > suggesting a *total* ripoff of any of them -- though IANAL, I don't > think it would be against any laws to do so -- but we could take the > best colors from all of the alternatives. Or something. > > Thoughts welcome (and if I don't get thoughts, then I'll just change it ;) ) > > Dustin > > -- > Innovation is just a problem away > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > I'm all for little bitty widgets, myself. The map is king. Maybe a fullscreen mode would be a good way of having rich UI sometimes, and minimal UI others (do I recall it's already in there?). Shame I'm at work and can't check. Still, I'd like a minimalist theme in any event. Probably more hotkeys too, I'm a serious hotkey junky. Actually, I'd be surprised if there isn't some widget/button generator tool out there, maybe for web design? Simple questions like color, XY size, round/square corners, 3d edges, etc, would go a long distance in a short time...spending a couple hours fooling around with gimp/photoshop is fun sometimes, but once you have kids, forget finding the time ;) Steve |
From: Dustin S. <du...@vi...> - 2008-08-13 07:03:07
|
Hey, So I've been thinking about this a bit, and I'm wondering if anyone has any opinions about the current map themes? Personally, I hate the daytime theme (I like the nighttime one for the most part though). Which, I realize that users can adjust the map themes if they don't like it, but it might be nice to give a nicer default. What do you think of making the default daytime theme look more like google maps or mapquest? I don't have a handheld GPS system, but it might also be useful to see what colors they use and borrow some ideas from there too. I've played with the colors a bit, and *some* of the color settings wouldn't make a whole lot of sense to use, but others (like the water) work out really well for the drawing that roadnav does. I'm not suggesting a *total* ripoff of any of them -- though IANAL, I don't think it would be against any laws to do so -- but we could take the best colors from all of the alternatives. Or something. Thoughts welcome (and if I don't get thoughts, then I'll just change it ;) ) Dustin -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-08-13 06:53:03
|
Awesome! I'd test it but I don't have FreeBSD installed. Hopefully there won't be too many bugs for the next release... at the moment, I'm doing all my dev work in Windows (I love Visual Studio, what can I say?), and then once its done I'll start running it on Linux (on my carputer)... which should hopefully be close enough. :) Dustin Steve Franks wrote: > Y'all, > > Thought you'd like to know that roadnav is now officially supported on > FreeBSD. As an incidental, FreeBSD has some sort of way of magically > sniffing out dependencies between things, making a quick look > interesting to more than just FreeBSD users, I suspect. > > Any who would like to test the port (and give me feedback; I'm in > charge of making sure it works 'out-of-the-box' for everyone on > FreeBSD): > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/astro/roadnav/ > > As 0.19 is the latest official release, that's what one gets with this > build. If one is wishing to build roadnav svn source on freebsd, one > mostly has to just change the path for wx_gtk2 and /usr/local/lib and > /usr/local/include when configuring, and it builds fine. > > Best, > Steve > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-08-13 06:49:18
|
Dustin Spicuzza wrote: > I'm also going to add some scaling/panning > functionality so that its more like google maps. :) > Ok, so I went ahead and added "google maps" styled zooming tonight, and it makes a *huge* difference (IMO)! Definitely will be a highlight of the next release (except for those of you with fast computers, once again). :) Dustin -- Innovation is just a problem away |
From: Steve F. <ste...@ie...> - 2008-08-11 16:44:45
|
Y'all, Thought you'd like to know that roadnav is now officially supported on FreeBSD. As an incidental, FreeBSD has some sort of way of magically sniffing out dependencies between things, making a quick look interesting to more than just FreeBSD users, I suspect. Any who would like to test the port (and give me feedback; I'm in charge of making sure it works 'out-of-the-box' for everyone on FreeBSD): http://www.freebsd.org/cgi/cvsweb.cgi/ports/astro/roadnav/ As 0.19 is the latest official release, that's what one gets with this build. If one is wishing to build roadnav svn source on freebsd, one mostly has to just change the path for wx_gtk2 and /usr/local/lib and /usr/local/include when configuring, and it builds fine. Best, Steve |
From: Dustin S. <du...@vi...> - 2008-08-11 06:58:58
|
I *finally* have the threaded map drawing working -- though really, I had the threaded part working a few weeks ago, it just took forever to separate out MapControl into a bunch of separate & (mostly) independent components. There are a number of things broken at the moment, such as waypoints, tracks, 3d mode (don't enable it, it may screw up your settings royally), certain types of zooming/unzooming, and various other things I haven't found yet. Now would be a good time for someone to look at the map rendering API I've introduced and tell me it sucks. :) Also, anyone interested in starting work on the improved OSM stuff and data structures (unless you've already started, which would be great), I think that I like how I've restructured the drawing stuff, so it should be safe to assume its not going to change a whole lot in the near future. Theres a few notes in the code about some of this too. I'd encourage anyone interested to build the code and try it out, on slower computers the GUI *should* be more responsive -- it certainly is on my computer (though the map drawing speed is about the same). After working out some of the bugs, I'm also going to add some scaling/panning functionality so that its more like google maps. :) I expect to apply these same techniques to other CPU-intensive tasks such as building/downloading maps (yes, they're threaded, but the GUI still freezes, which is annoying) after I get this part mostly bug-free. This is very untested, and quality is worse than alpha, so there will not be builds posted at this time. Dustin -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-07-28 23:48:18
|
Steve Franks wrote: > Hey y'all - > > I'm curious on whether there is any consensus on a 0.20 release? I'm > adding support for Roadnav to FreeBSD, but they build everything from > source, as opposed to rpm/apt/whatever, and they kind of want the > released version of a project. I've got 0.19 in progress right now, > but it seems there are some pretty compelling things going on at the > moment. > I'm aiming to get a number of the things in my mind completed by the end of August or September. However, this has probably no basis in reality, and will take much longer. :) I suppose we should settle on what would be included with a 0.20 release.. though, IMO its all a work in progress for now. > Any major architectural or dependency changes in 0.20 not covered > trivially by configure? > AFAIK, the only real dependency is wxWidgets... automake probably takes care of the rest -- if not, send a patch. :) Dustin -- Innovation is just a problem away |
From: Steve F. <ste...@ie...> - 2008-07-28 23:33:39
|
Hey y'all - I'm curious on whether there is any consensus on a 0.20 release? I'm adding support for Roadnav to FreeBSD, but they build everything from source, as opposed to rpm/apt/whatever, and they kind of want the released version of a project. I've got 0.19 in progress right now, but it seems there are some pretty compelling things going on at the moment. Any major architectural or dependency changes in 0.20 not covered trivially by configure? Best, Steve |
From: Dustin S. <du...@vi...> - 2008-07-23 18:35:45
|
Martin, Martin Shaw wrote: > Hi Dustin. > > Very interested to hear you're looking into the memory structures and > associated index mechanisms. Have you considered R-Trees for spatial > lookups? I'm working on another project (network related) in which I > am using R-Trees to index in memory objects. As one of the early > applications for R-Trees is in looking up 2d coordinates I thought it > might be an option here. Obviously I don't know the context of what > you're trying to do - it's been a while since I looked at the roadnav > code and then it was in relation to parsing OSM data. > R-Tree structures look very much like what I was describing... which, at work I'm also working on a network-related thing where such a structure could be really useful too! Awesome.. now no reinventing of the wheel. :) My thought here is a generic structure that can be used to store coordinates/items, such as roads, tracks, and waypoints to eliminate the current linear search methods. It would also make quite a few other operations much easier and faster, in my opinion. > Well I'm going to try to get up to date on the project - I think > roadnav is a great effort and if I can free up some time for a home > project I'll certainly be happy to get involved. > Awesome. I'd recommend looking at branches/wx3 code instead of trunk... thats where I've been doing my dev stuff, and I'm reorganizing the tree and such to make it a bit easier to understand. > BTW I had a look for #roadnav on freenode today but I couldn't see it > - is the channel active at the moment? > The IRC channel is up and running... I just logged into my home PC. There was a guy there last night... I'm not sure what one needs to do to make it searchable though, I just do /join #roadnav :) Dustin |
From: Martin S. <ma...@s4...> - 2008-07-23 17:23:00
|
Hi Dustin. Very interested to hear you're looking into the memory structures and associated index mechanisms. Have you considered R-Trees for spatial lookups? I'm working on another project (network related) in which I am using R-Trees to index in memory objects. As one of the early applications for R-Trees is in looking up 2d coordinates I thought it might be an option here. Obviously I don't know the context of what you're trying to do - it's been a while since I looked at the roadnav code and then it was in relation to parsing OSM data. Well I'm going to try to get up to date on the project - I think roadnav is a great effort and if I can free up some time for a home project I'll certainly be happy to get involved. BTW I had a look for #roadnav on freenode today but I couldn't see it - is the channel active at the moment? Cheers. Martin. 2008/7/23 Dustin Spicuzza <du...@vi...>: > I've been thinking a lot about roadnav recently, and so I want to share > with the community some thoughts that I've jotted down (not necessarily > new/novel or intelligible, but I'm including them for completeness). > Please discuss and give feedback. These ramble a bit, and aren't in any > specific order at the moment, and most of these goals are not present in > the TODO list (which reminds me, I really need to update the changelog). > > - What if the compiled maps are in a structure similar to a > database? Very large binary file(s), and one or two index files used for > fast lookup. I would imagine there is a lot of overhead involved with > opening and closing file handles for lots of tiny files (roadnav's > current data implementation). See the next point for an idea related to > this... > > - Optimized data structures: A major improvement I think would be > creating a data structure that will work in memory and in file > structures, that indexes objects along 2 axis (ie, latitude/longitude). > I've given this a bit of thought, and I think a good strategy here could > be a type of radix tree or a trie. A large amount of time seems to be > spent doing linear searches on large arrays (in Boston here, I've > measured libroadnav doing linear searches in excess of 200,000 objects, > only using 200-2000 of the objects in the general case). This type of > structure would be useful for many types of on screen objects, and for > reverse lookup of addresses too. It may be useful for this data > structure to index along zoom levels too. > > - Point::Point()... lots of point objects being constructed all the > time. wxGPSEvent is the same way, but its larger. > > - Need to remove DownloadThread, and have it only launch a thread as > necessary. The idea is sound, but no sense using up system resources you > don't need to use. Additionally, it needs to detect failed downloads and > quit annoying the user > > - I liked that dual map pane idea Steve suggested, supporting > different zoom levels and such. Need a more effcient mapcontrol however. > > - Skinning support -- why not use XRC? Could be a viable solution, > but maybe not. There needs to be an easy way for a program feature to > add a progress bar and/or other widgets to the main interface, without > it getting cluttered. The skin should resize better too... ie the buttons. > > - Separation of map data, and address data (this may already be the > case in a limited sense, but I don't think so). This allows roadnav to > be used to do just generalized queries on map data and such. > > - Where possible, remove string comparisons! This is what enum is for. > > - Waypoint management is currently messy and non-intuitive IMO. > > -- There are a number of thoughts related to reorganizing MapControl > and its drawing mechanisms, however > > -- I've improved some of the GPS code in my branch, but I think > there are still some residual error problems there. However, my last > long trip was very uneventful and didn't have any annoying error > messages as before. > > -- Continued reorganization of the source tree into sensible > subdivisions. I created the update_build.sh script, which makes changing > around file locations less annoying -- it automatically updates VS > project files and Makefiles. > > -- I'd like to give more thought to the reorganization of the > options structure introduced in my branch also. Better categorization > and such. > > Ideally, I'm aiming for a next stable-ready release within a few months, > though not all of my above thoughts or the TODO list > > I intend to eventually do a lot of these in the near future, roadnav is > currently my primary free time project -- I'd love it if others could > help out too, patches or otherwise very welcome. I'm currently doing > work up against the incorrectly named wx3 branch (I'll change it soon, I > promise). If anyone wants to chat, I've registered the #roadnav channel > on freenode. > > Dustin > > -- > Innovation is just a problem away > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > |
From: Dustin S. <du...@vi...> - 2008-07-23 03:38:30
|
Richard L. Lynch wrote: > Seems reasonable to me. Additionally, Roadnav only supports the old > TIGER/Line format, and at some point those files will be pulled from > the USCB's web site. The new TIGER/Line data is in shapefile format, > a format Roadnav does not support. If OSM has already imported all > the TIGER/Line data and cleaned it up, in my opinion it makes sense to > clean up OSM support and switch over, hopefully before USCB pulls the > old TIGER/Line data. Then this sounds official, Roadnav will move towards primarily using OSM data. > > If you need some help overhauling the OSM code or moving away from zip > codes, let me know. I can make some time available to help out. Absolutely, that would be great. I've looked over OSM stuff a little bit, and I'm still not clear on how some of their data is linked together (for example, there seems to be a concept of regions/areas, but its not clear how to obtain the information for these). However, I've been devoting my time towards some other issues, such as the following: Right now, I'm in the process of drastically altering MapControl to attempt to split out its functionality, and make it more amenable to threading. Last week, I wrote a sample control/renderer that does flicker-free threaded drawing on a control in the way I want it to work, and addresses quite a few of the annoyances I have with roadnav at the moment -- I've uploaded the project file (very small, 13k) at http://www.virtualroadside.com/wxTest.zip . It sleeps for one second to simulate a drawing delay, and just draws a solid color to the control. Some of the advantages of this drawing model are the following: -- When the user drags the map around, there is no lag -- its instant. It doesn't show the part of the screen that hasn't been rendered yet, but this is the model that google maps uses, and it seems to be an effective strategy until we can get our rendering time down to zero (mostly for the benefit of low-end hardware) -- A full bitmap of the current map is always lying around, so that drawing tracks and waypoints is instant without having to recalculate anything -- Most importantly, while the map is busy getting rendered, the GUI doesn't hang for a few seconds Right now, I'm trying to decide where the MapControls functionality needs to be split at... and converting things along the way. I hope to have this working by the end of the week... but we'll see. Dustin -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-07-23 03:36:37
|
In case anyone is interested in this, I've registered the #roadnav channel on freenode, I'll have my client sitting there. Dustin Dustin Spicuzza wrote: > This winter, I just started using IRC in conjunction with open source > projects, and I've found its an extremely useful way to instantly > communicate about things instead of using email... which could be useful > for roadnav development (though, I think I'm the only one doing active > development right now, AFAIK). I think it could be especially useful for > people wanting to start contributing, since you could get immediate > answers from others)... anyways, anyone interested in such a thing? > > Dustin > > -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2008-07-23 03:34:37
|
I've been thinking a lot about roadnav recently, and so I want to share with the community some thoughts that I've jotted down (not necessarily new/novel or intelligible, but I'm including them for completeness). Please discuss and give feedback. These ramble a bit, and aren't in any specific order at the moment, and most of these goals are not present in the TODO list (which reminds me, I really need to update the changelog). - What if the compiled maps are in a structure similar to a database? Very large binary file(s), and one or two index files used for fast lookup. I would imagine there is a lot of overhead involved with opening and closing file handles for lots of tiny files (roadnav's current data implementation). See the next point for an idea related to this... - Optimized data structures: A major improvement I think would be creating a data structure that will work in memory and in file structures, that indexes objects along 2 axis (ie, latitude/longitude). I've given this a bit of thought, and I think a good strategy here could be a type of radix tree or a trie. A large amount of time seems to be spent doing linear searches on large arrays (in Boston here, I've measured libroadnav doing linear searches in excess of 200,000 objects, only using 200-2000 of the objects in the general case). This type of structure would be useful for many types of on screen objects, and for reverse lookup of addresses too. It may be useful for this data structure to index along zoom levels too. - Point::Point()... lots of point objects being constructed all the time. wxGPSEvent is the same way, but its larger. - Need to remove DownloadThread, and have it only launch a thread as necessary. The idea is sound, but no sense using up system resources you don't need to use. Additionally, it needs to detect failed downloads and quit annoying the user - I liked that dual map pane idea Steve suggested, supporting different zoom levels and such. Need a more effcient mapcontrol however. - Skinning support -- why not use XRC? Could be a viable solution, but maybe not. There needs to be an easy way for a program feature to add a progress bar and/or other widgets to the main interface, without it getting cluttered. The skin should resize better too... ie the buttons. - Separation of map data, and address data (this may already be the case in a limited sense, but I don't think so). This allows roadnav to be used to do just generalized queries on map data and such. - Where possible, remove string comparisons! This is what enum is for. - Waypoint management is currently messy and non-intuitive IMO. -- There are a number of thoughts related to reorganizing MapControl and its drawing mechanisms, however -- I've improved some of the GPS code in my branch, but I think there are still some residual error problems there. However, my last long trip was very uneventful and didn't have any annoying error messages as before. -- Continued reorganization of the source tree into sensible subdivisions. I created the update_build.sh script, which makes changing around file locations less annoying -- it automatically updates VS project files and Makefiles. -- I'd like to give more thought to the reorganization of the options structure introduced in my branch also. Better categorization and such. Ideally, I'm aiming for a next stable-ready release within a few months, though not all of my above thoughts or the TODO list I intend to eventually do a lot of these in the near future, roadnav is currently my primary free time project -- I'd love it if others could help out too, patches or otherwise very welcome. I'm currently doing work up against the incorrectly named wx3 branch (I'll change it soon, I promise). If anyone wants to chat, I've registered the #roadnav channel on freenode. Dustin -- Innovation is just a problem away |
From: Richard L. L. <rl...@us...> - 2008-07-22 22:46:36
|
Seems reasonable to me. Additionally, Roadnav only supports the old TIGER/Line format, and at some point those files will be pulled from the USCB's web site. The new TIGER/Line data is in shapefile format, a format Roadnav does not support. If OSM has already imported all the TIGER/Line data and cleaned it up, in my opinion it makes sense to clean up OSM support and switch over, hopefully before USCB pulls the old TIGER/Line data. Your analysis in b) is correct. Roadnav started out just supporting TIGER/Line and as a result it has a heavy US bias. Zip codes, and to a lesser extent counties, link many key structures together and are heavily used in the code. If you need some help overhauling the OSM code or moving away from zip codes, let me know. I can make some time available to help out. Rich On Tue, Jul 22, 2008 at 9:29 AM, Dustin Spicuzza <du...@vi...> wrote: > In my opinion, dropping Tiger support should be a short term goal as > opposed to a long term goal -- OpenStreetMap has matured enough where its a > viable source of map information (especially considering their recent large > imports of data). There are a number of problems for better OSM support > however: > > a) The current download mechanism for it sucks -- AFAIK you can only > specify coordinates and then download in that general area. To solve this > one, we need to add a download dialog that uses the search functionality > available through > > b) All of the internal data structures are very very biased towards > US-focused addresses. For example (correct me if I'm wrong) but I believe > that roadnav currently stores data by zip code, and a lot of the internal > lookup mechanisms are focused by zip code and by county. I know that roadnav > currently sorta supports OSM, but I haven't looked at how it handles non-us > addresses yet. Side effects from this US-centric approach is things like the > turn by turn directions would need to be adjusted. > > I believe that currently the address information and the mapping > information are all globbed together right now, and I think something that > will help globalization is to store address information and map information > separately. However, completely rewriting a lot of this stuff for (b) will > take a lot of effort due to how ingrained US addresses are in roadnav. > > Better OSM support is on my short list for things to do on Roadnav, but I'm > not quite to that part of my list yet... > > Dustin > > > > Lambertus wrote: > >> The Tiger data has been imported into the OpenStreetMap database some time >> ago (started late 2007). Since then a lot of people are busy cleaning up the >> raw Tiger data, connecting roads, enhancing accuracy etc. I can imagine that >> in the long term direct support for the Tiger data will be dropped in favor >> of OpenStreetMap within RoadNav. An added bonus is that OSM also has data >> from outside the US. >> >> Richard L. Lynch wrote: >> >> >>> The TIGER/Line data doesn't connect road segments together, so Roadnav >>> assumes that road segments that end at the same long/lat coordinates are >>> connected. This is occasionally an incorrect assumption, but it's the best >>> that can be done with the TIGER/Line data. >>> >>> Rich >>> >>> On Fri, Jul 18, 2008 at 10:14 PM, De Garcia <re...@fs... <mailto: >>> re...@fs...>> wrote: >>> >>> Hi, I was looking at the code on MapControlDataImporter_TigerLine .h >>> and .cpp which is where the Type 1 records are parse and store, as >>> well as all other records from tiger/line data. Each line on the RT1 >>> file corresponds to a chain/road, and my question is how do you know >>> which chain/road is connected to another chain/road. Mainly how do >>> you connect one road to another, where in the code are you doing >>> this? Or where in the tiger/line data do you know which road >>> connects another. I would really appreciate if someone could help me >>> with this information. >>> >>> Thank you for the help >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's >>> challenge >>> Build the coolest Linux based applications with Moblin SDK & win great >>> prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the >>> world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Roadnav-devel mailing list >>> Roa...@li... >>> https://lists.sourceforge.net/lists/listinfo/roadnav-devel >>> >>> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Roadnav-devel mailing list >> Roa...@li... >> https://lists.sourceforge.net/lists/listinfo/roadnav-devel >> >> > > > -- > Innovation is just a problem away > > |
From: Dustin S. <du...@vi...> - 2008-07-22 13:29:42
|
In my opinion, dropping Tiger support should be a short term goal as opposed to a long term goal -- OpenStreetMap has matured enough where its a viable source of map information (especially considering their recent large imports of data). There are a number of problems for better OSM support however: a) The current download mechanism for it sucks -- AFAIK you can only specify coordinates and then download in that general area. To solve this one, we need to add a download dialog that uses the search functionality available through b) All of the internal data structures are very very biased towards US-focused addresses. For example (correct me if I'm wrong) but I believe that roadnav currently stores data by zip code, and a lot of the internal lookup mechanisms are focused by zip code and by county. I know that roadnav currently sorta supports OSM, but I haven't looked at how it handles non-us addresses yet. Side effects from this US-centric approach is things like the turn by turn directions would need to be adjusted. I believe that currently the address information and the mapping information are all globbed together right now, and I think something that will help globalization is to store address information and map information separately. However, completely rewriting a lot of this stuff for (b) will take a lot of effort due to how ingrained US addresses are in roadnav. Better OSM support is on my short list for things to do on Roadnav, but I'm not quite to that part of my list yet... Dustin Lambertus wrote: > The Tiger data has been imported into the OpenStreetMap database some > time ago (started late 2007). Since then a lot of people are busy > cleaning up the raw Tiger data, connecting roads, enhancing accuracy > etc. I can imagine that in the long term direct support for the Tiger > data will be dropped in favor of OpenStreetMap within RoadNav. An added > bonus is that OSM also has data from outside the US. > > Richard L. Lynch wrote: > >> The TIGER/Line data doesn't connect road segments together, so Roadnav >> assumes that road segments that end at the same long/lat coordinates are >> connected. This is occasionally an incorrect assumption, but it's the >> best that can be done with the TIGER/Line data. >> >> Rich >> >> On Fri, Jul 18, 2008 at 10:14 PM, De Garcia <re...@fs... >> <mailto:re...@fs...>> wrote: >> >> Hi, I was looking at the code on MapControlDataImporter_TigerLine .h >> and .cpp which is where the Type 1 records are parse and store, as >> well as all other records from tiger/line data. Each line on the RT1 >> file corresponds to a chain/road, and my question is how do you know >> which chain/road is connected to another chain/road. Mainly how do >> you connect one road to another, where in the code are you doing >> this? Or where in the tiger/line data do you know which road >> connects another. I would really appreciate if someone could help me >> with this information. >> >> Thank you for the help >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Roadnav-devel mailing list >> Roa...@li... >> https://lists.sourceforge.net/lists/listinfo/roadnav-devel >> > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > -- Innovation is just a problem away |
From: Lambertus <os...@na...> - 2008-07-22 07:43:14
|
The Tiger data has been imported into the OpenStreetMap database some time ago (started late 2007). Since then a lot of people are busy cleaning up the raw Tiger data, connecting roads, enhancing accuracy etc. I can imagine that in the long term direct support for the Tiger data will be dropped in favor of OpenStreetMap within RoadNav. An added bonus is that OSM also has data from outside the US. Richard L. Lynch wrote: > The TIGER/Line data doesn't connect road segments together, so Roadnav > assumes that road segments that end at the same long/lat coordinates are > connected. This is occasionally an incorrect assumption, but it's the > best that can be done with the TIGER/Line data. > > Rich > > On Fri, Jul 18, 2008 at 10:14 PM, De Garcia <re...@fs... > <mailto:re...@fs...>> wrote: > > Hi, I was looking at the code on MapControlDataImporter_TigerLine .h > and .cpp which is where the Type 1 records are parse and store, as > well as all other records from tiger/line data. Each line on the RT1 > file corresponds to a chain/road, and my question is how do you know > which chain/road is connected to another chain/road. Mainly how do > you connect one road to another, where in the code are you doing > this? Or where in the tiger/line data do you know which road > connects another. I would really appreciate if someone could help me > with this information. > > Thank you for the help > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel |
From: Richard L. L. <rl...@us...> - 2008-07-21 01:25:42
|
The TIGER/Line data doesn't connect road segments together, so Roadnav assumes that road segments that end at the same long/lat coordinates are connected. This is occasionally an incorrect assumption, but it's the best that can be done with the TIGER/Line data. Rich On Fri, Jul 18, 2008 at 10:14 PM, De Garcia <re...@fs...> wrote: > Hi, I was looking at the code on MapControlDataImporter_TigerLine .h and > .cpp which is where the Type 1 records are parse and store, as well as all > other records from tiger/line data. Each line on the RT1 file corresponds to > a chain/road, and my question is how do you know which chain/road is > connected to another chain/road. Mainly how do you connect one road to > another, where in the code are you doing this? Or where in the tiger/line > data do you know which road connects another. I would really appreciate if > someone could help me with this information. > > Thank you for the help > |
From: Dustin S. <du...@vi...> - 2008-07-19 16:15:20
|
I would love to know that too, haven't gotten around to that part of the code yet... curious, what are you trying to accomplish? Dustin De Garcia wrote: > Hi, I was looking at the code on MapControlDataImporter_TigerLine .h and .cpp which is where the Type 1 records are parse and store, as well as all other records from tiger/line data. Each line on the RT1 file corresponds to a chain/road, and my question is how do you know which chain/road is connected to another chain/road. Mainly how do you connect one road to another, where in the code are you doing this? Or where in the tiger/line data do you know which road connects another. I would really appreciate if someone could help me with this information. > > Thank you for the help > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Roadnav-devel mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-devel > -- Innovation is just a problem away |
From: De Garcia<re...@fs...> - 2008-07-19 02:14:12
|
Hi, I was looking at the code on MapControlDataImporter_TigerLine .h and .cpp which is where the Type 1 records are parse and store, as well as all other records from tiger/line data. Each line on the RT1 file corresponds to a chain/road, and my question is how do you know which chain/road is connected to another chain/road. Mainly how do you connect one road to another, where in the code are you doing this? Or where in the tiger/line data do you know which road connects another. I would really appreciate if someone could help me with this information. Thank you for the help |