roadnav-devel Mailing List for Roadnav
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: Ramaddan <ram...@ga...> - 2009-06-23 22:39:42
|
Hi, Just in case this question is redundant, please excuse me. I was trying out the latest version of Roadnav fromthe svn, and it really looks very promising. I was just wondering if anyone can tell me when will the next version be released? Currently, the latest svn version is very unstable, which is expected, and I still can't seem to figure out how to use maps outside of the US, no matter what I download. Is it supposed to work with maps outside the US? I use Ubuntu Jaunty 9.04, and can help make Ubuntu packages, but I might require some directions with that, as I'm still an amateur in terms of packaging. Regards, Ramaddan ----------------------------------------------------------------------------------------------------------------------- Send big files for free. Simple steps. No registration. Visit now http://www.nawelny.com |
From: Dustin S. <du...@vi...> - 2009-05-18 04:18:17
|
Hey, Given that I haven't contributed to the project since January, and I haven't been able to motivate myself to begin work again (mostly due to other interesting projects), I've decided to formally suspend my involvement in Roadnav until such a time where I find myself bored or at a point where I need Roadnav again. For better or for worse, I don't have a need for GPS anymore, and I've been far too busy with other things that have come up that are more interesting. I know I haven't actually made very many contributions that anyone has been able to see, but theres a lot of cool stuff sitting in the experimental branch (and libsdbx) if anyone wants to dive in there and finish it up (in particular, I'm quite proud of the work that I did with libsdbx). I anticipate at some point I will probably return to this stuff, but I'm not going to make any promises for when that will be. I'll still stay subscribed to this list and answer any questions about stuff I have written if anyone goes through it. Dustin -- Innovation is just a problem away |
From: Dustin S. <du...@vi...> - 2009-05-05 21:56:38
|
wrote: > I've been reading over the experimental MapBackend stuff, it's really > impressive how the serialization and everything is setup. I ran into a > question though, what will actually hold the MapObjects that are > loaded from file and need to be rendered? So if you look at the MapBackend.h file: The RTree (MapObjectsIndex) is used to find a set of ID's that need to be loaded from file and rendered (or whatever needs to be done with them). There is a MapObjectsFile (m_mapObjectsFile) which holds the actual objects. I believe the search ID for this is the ID held in the RTree. Its important to note that all the sdbx trees and structures have LRU caches in them (at least, if I remember correctly they do) and they should have mechanisms to tune the caches as well, so if you read from those structures you shouldn't need to stick them in a separate list or anything like that, as its already holding the most recently used data in its cache. Its possible some of these mechanisms aren't quite defined yet, but the OSM data importer *does* work if I remember correctly, so if you step through how it inserts the data it may become more obvious on how to get the data out. I thought I wrote a file that documented this... hmm. Probably should do that then.. > > I couldn't see any functions in MapBackend that would be used to load > the data from the file. I assume that MapControl is what will hold the > data to be rendered inside the MapLocations class? Actually, no. The MapControl should just render the data. It shouldn't hold anything, someone else should hold it and pass it in to it. MapLocations is only used to hold user-defined Waypoints and Tracks, not map data. I assume that is > setup from how it was originally implemented, does there need to be > any changes to how it is setup to work with the new backend? Yeah, MapLocations needs to be redone most likely. I was thinking possibly in an R*Tree or something, so that it can scale to really large sets of waypoints/tracks without losing performance. Dustin -- Innovation is just a problem away |
From: Brandon G. <bra...@gm...> - 2009-05-05 21:40:03
|
I've been reading over the experimental MapBackend stuff, it's really impressive how the serialization and everything is setup. I ran into a question though, what will actually hold the MapObjects that are loaded from file and need to be rendered? I couldn't see any functions in MapBackend that would be used to load the data from the file. I assume that MapControl is what will hold the data to be rendered inside the MapLocations class? I assume that is setup from how it was originally implemented, does there need to be any changes to how it is setup to work with the new backend? |
From: Dustin S. <du...@vi...> - 2009-05-02 00:27:02
|
Brandon Green wrote: > > Hey, I'm interesting in contributing to this project(recently > unemployed, so have lots of free time atm), I've been looking through > the code in the experimental branch and reading up on rtrees and OSM. > > So my question is, what would be best to try to start working on? I saw > that recently Dustin mentioned he would start making progress again > soon, should I look into getting the libroadnav minimal sample in the > experimental branch rendering? That would be excellent. I believe where I left off was at trying to get the OSM download window to work correctly/consistently. The next part was to figure out how to adequately express the rendering settings properly... I don't really like the existing way of storing colors/etc, and it doesn't fit particularly well in the OSM model. Dustin -- Innovation is just a problem away |
From: Brandon G. <bra...@ho...> - 2009-05-02 00:21:16
|
Hey, I'm interesting in contributing to this project(recently unemployed, so have lots of free time atm), I've been looking through the code in the experimental branch and reading up on rtrees and OSM. So my question is, what would be best to try to start working on? I saw that recently Dustin mentioned he would start making progress again soon, should I look into getting the libroadnav minimal sample in the experimental branch rendering? _________________________________________________________________ Windows Live™ Hotmail®:…more than just e-mail. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_more_042009 |
From: Dustin S. <du...@vi...> - 2009-04-16 21:26:42
|
Ray Morris wrote: > My friend and I would love to see Roadnav > development pick up again, "finishing" the stuff > you have in experimental. I appreciate the > developer documentation for Roadnav and particularly > the availibility of libroadnav with good documentation. > So often with open source what you need is out there, > but not well documented so you'd have to slog through > the source of various projects picking them apart and > trying to figure out if they might work for you, and > if so how. Roadnav is a wonderful exception. I dunno, the documentation doesn't seem to be particularly good in my opinion.. but whatever. > > Is there anything we can do to help? I'm not > a very good C programmer, and haven't done ANY GUI > work in C, as all of my stuff is web based, mostly > Perl. My friend whom I'm working with is a C# programmer > who is a little scared of C by I'm trying to get him > to brave C a little a bit. We might be most helpful > with peripheral things like we have a virtualization > platform to test it under various different operating > systems, or what ever. > Its actually all done in C++. Moving from C# to C++ is a bit more difficult than moving C++ to C#, but its doable. Tell him to stop being a wimp. :) > We / he is doing a complete integrated carputer > package. Something like MythTV, if you're familiar > with that. He has a working, themeable system that > does mp3s, photos, DVDs, and AM/FM should work soon. > Al wrote a theft recovery package which we intend > to integrate and we have some other ideas we'll be > adding. The idea is to provide a nicely integrated > system that works well without any hacking, and a > combined interface. The big missing part is GPS. > While I'm a Linux guy, he's working in .NET 2.0 > on Windows. We may well port it to Linux using > Mono. He spent a little time the other day with > wx.net trying to get libroadnav to compile and > run in Windows, but hasn't had any luck so far. If you are using trunk, that should compile. Experimental does not compile if I remember correctly. See http://roadnav.sourceforge.net/wiki/index.php/Development and http://roadnav.sourceforge.net/wiki/index.php/Compiling , that should have information on how to compile. The key thing is to have wx installed properly -- the rest should follow easily from that. > He'd like to find someone to do a tidy .NET wrapper > so he can integrate GPS without needing to develop > a full understanding of wxWindows and all that. While its probably possible, I would imagine it could be rather difficult to do. I would imagine the easiest solution would be to wrap up libroadnav into a COM object or something... and that doesn't sound particularly easy. :) > > Let me know what we can do to help, and if you > know anyone working on the Windows side, or who > might be interested in working on the Windows > package. AFAIK, there is nobody actively working on Roadnav at the moment. There are a few really big things that need to be done to libroadnav in experimental (and there are some smaller things that have to be done before these can get done, but I don't quite recall what they are). - The MapControl needs to render based on the new map database data. The new database is vastly different from the old format, but should offer many speed improvements. - OSM data needs to be imported correctly. There is a search window that allows you to search for the data, but it doesn't always download it, and the window freezes. I'm not quite sure if that error was on the client or OSM server side however. - There needs to be a better (and threadsafe) way to store map options. This is actually harder than it sounds, and should match the database storage so its easy to lookup the settings. What my goal was is to get the minimal sample working correctly, and then move from there to fixing the main roadnav app to work correctly (since there are a ton of changes to the API in experimental). Dustin -- Innovation is just a problem away |
From: Ray M. <su...@be...> - 2009-04-16 17:05:33
|
My friend and I would love to see Roadnav development pick up again, "finishing" the stuff you have in experimental. I appreciate the developer documentation for Roadnav and particularly the availibility of libroadnav with good documentation. So often with open source what you need is out there, but not well documented so you'd have to slog through the source of various projects picking them apart and trying to figure out if they might work for you, and if so how. Roadnav is a wonderful exception. Is there anything we can do to help? I'm not a very good C programmer, and haven't done ANY GUI work in C, as all of my stuff is web based, mostly Perl. My friend whom I'm working with is a C# programmer who is a little scared of C by I'm trying to get him to brave C a little a bit. We might be most helpful with peripheral things like we have a virtualization platform to test it under various different operating systems, or what ever. We / he is doing a complete integrated carputer package. Something like MythTV, if you're familiar with that. He has a working, themeable system that does mp3s, photos, DVDs, and AM/FM should work soon. Al wrote a theft recovery package which we intend to integrate and we have some other ideas we'll be adding. The idea is to provide a nicely integrated system that works well without any hacking, and a combined interface. The big missing part is GPS. While I'm a Linux guy, he's working in .NET 2.0 on Windows. We may well port it to Linux using Mono. He spent a little time the other day with wx.net trying to get libroadnav to compile and run in Windows, but hasn't had any luck so far. He'd like to find someone to do a tidy .NET wrapper so he can integrate GPS without needing to develop a full understanding of wxWindows and all that. Let me know what we can do to help, and if you know anyone working on the Windows side, or who might be interested in working on the Windows package. -- Ray B. Morris su...@be... Strongbox - The next generation in site security: http://www.bettercgi.com/strongbox/ Throttlebox - Intelligent Bandwidth Control http://www.bettercgi.com/throttlebox/ Strongbox / Throttlebox affiliate program: http://www.bettercgi.com/affiliates/user/register.php On 04/15/2009 03:15:59 PM, Dustin Spicuzza wrote: > Ray Morris wrote: > > I see there hasn't been any Roadnav > > development recently. Roadster and GMap > > seem to have similarly stalled. We are > > willing to put up some cash to get one of > > these projects going again. Is there any > > developer interest, assuming you could be > > paid (but not extremely WELL paid) for your > > work? > > Last year I was the primary person doing development on Roadnav > (username: virtuald/randomperson83), and theres actually a lot of > neat > stuff sitting in the experimental branch waiting to be finished. In > particular, the user interface responsiveness should be greatly > improved > (a version that was working in the summer had demonstrated those > changes, but only worked in debug mode because I was an idiot about > asserts() ), and moving to open street map data should be a huge > improvement as well. > > However, I stopped development in January because of my work with a > local FIRST Robotics Team had been eating all of my time, and I've > been > intending to finish the changes as soon as that stopped sucking my > time > (this month). I'm anticipating that I'll begin working on this stuff > again either late this month or next month, but no guarantees. > > Personally, I'm probably not interested in the money, unless its more > than I think it is -- but even then, probably not. > > Dustin > > |
From: Dustin S. <du...@vi...> - 2009-04-15 20:29:04
|
Ray Morris wrote: > I see there hasn't been any Roadnav > development recently. Roadster and GMap > seem to have similarly stalled. We are > willing to put up some cash to get one of > these projects going again. Is there any > developer interest, assuming you could be > paid (but not extremely WELL paid) for your > work? Last year I was the primary person doing development on Roadnav (username: virtuald/randomperson83), and theres actually a lot of neat stuff sitting in the experimental branch waiting to be finished. In particular, the user interface responsiveness should be greatly improved (a version that was working in the summer had demonstrated those changes, but only worked in debug mode because I was an idiot about asserts() ), and moving to open street map data should be a huge improvement as well. However, I stopped development in January because of my work with a local FIRST Robotics Team had been eating all of my time, and I've been intending to finish the changes as soon as that stopped sucking my time (this month). I'm anticipating that I'll begin working on this stuff again either late this month or next month, but no guarantees. Personally, I'm probably not interested in the money, unless its more than I think it is -- but even then, probably not. Dustin -- Innovation is just a problem away |
From: Ray M. <su...@be...> - 2009-04-15 20:04:27
|
I see there hasn't been any Roadnav development recently. Roadster and GMap seem to have similarly stalled. We are willing to put up some cash to get one of these projects going again. Is there any developer interest, assuming you could be paid (but not extremely WELL paid) for your work? -- Ray B. Morris su...@be... Strongbox - The next generation in site security: http://www.bettercgi.com/strongbox/ Throttlebox - Intelligent Bandwidth Control http://www.bettercgi.com/throttlebox/ Strongbox / Throttlebox affiliate program: http://www.bettercgi.com/affiliates/user/register.php |
From: Corfiot <co...@co...> - 2008-12-18 08:49:08
|
On Wed, 17 Dec 2008 13:51:53 -0500 Dustin Spicuzza <du...@vi...> wrote: ----------------------- Original Message ----------------------- > > > > > > > We work on adding in Roadnav > > > > 1.) Triangulation > > You mean like using radio signals as alternative to using a GPS device? > That would be really cool -- you're certainly welcome submit a patch. > Otherwise, I'm not quite sure what you're talking about. > > Our implementation has the scope to help users of the Roadnav to estimate a position on the map by using the current position and to measurement of the "Azimuth" (angle between North and the view -line of a point). This is very helpful for passengers "out of road" on hills, mounts, country sites or in the sea. With two measurements (from two different points) of the azimuth angle you have the Real Position of a point and the possibility to navigate to this point. > Keep in mind that the trunk is rather out of date, so I would recommend > patching against the code for the wx3 branch of roadnav/libroadnav from > http://roadnav.sourceforge.net/downloads.php. I'm hoping that > experimental libroadnav will be compiling (and maybe even working) again > this weekend... > ASAP > Technically, this discussion belongs in roadnav-devel. :) ASAP > > Dustin > > > > -- > Innovation is just a problem away > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Roadnav-users mailing list > Roa...@li... > https://lists.sourceforge.net/lists/listinfo/roadnav-users > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Scanned with Copfilter Version 0.84beta1 (P3Scan 2.2.1) > AntiSpam: SpamAssassin 3.1.8 > by Markus Madlener @ http://www.copfilter.org --------------------- Original Message Ends -------------------- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Scanned with Copfilter Version 0.84beta1 (ProxSMTP 1.6) AntiVirus: ClamAV 0.90.1/8762 - Mon Dec 15 16:57:35 2008 by Markus Madlener @ http://www.copfilter.org |
From: <p4d...@sn...> - 2008-10-31 23:56:07
|
Great idea Ragnar. I suggested that to them, and they liked it. They said they'll do it, but it'll take a few weeks. So we're gonna have to wait a little bit I guess. Kyle On Oct 27, 2008, at 2:56 AM, Ragnar Kjørstad roadnav-at- ragnark.vestdata.no |RoadNav| wrote: > On Mon, Oct 27, 2008 at 1:35 AM, <p4d...@sn...> wrote: >> I hunted through their website yesterday, and my search >> yielded no >> results for any sort of file that gives the latest date, etc. >> Therefore, instead of submitting my code as-is, I emailed the >> maintainer of the files, and asked that person about the naming >> scheme. Hopefully they realize how difficult it is to link to files >> with constantly changing names, and move to a more static naming >> scheme. If they don't think that's viable, I'll ask them if they >> could >> create a file with the, uh... appendention (date modified) and let us >> know the link to that. Unfortunately... on the website they >> explicitly >> state that not all files have all been modified on the same date... >> so >> the links don't actually have all the same appendentions, which makes >> that option not so viable either. This really sucks, I hope they just >> rename them all and keep them that way. Anyway... I'll keep in touch >> about the response. I don't expect one until tomorrow. > > A common way of handling this issue is to add a ".latest" symlink that > points to the newest file. > > > -- > Ragnar Kjørstad > > ------------------------------------------------------------------------- > 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-10-28 07:29:48
|
Just out of curiosity, does anyone have strong feelings about unique ID sizes? Specifically, thinking in terms of map nodes and related objects. Heres a mini-rant I just wrote in comments about this ( looking through my code, you may notice a tendency to mini-rant about things...) First, lets look at the number of objects we can have depending on the size of the unique ID: 32 bits: 4294967296 (4 billion) 40 bits: 1099511627776 (1 trillion) 48 bits: 281474976710656 (281 trillion) 64 bits: 18446744073709551615 (ridiculously big number) 32 bits will be good enough for really tiny systems, but I'm pretty sure quite a few people will run out of unique ID's with this many nodes. Now we could add another 8 bits, and go to 1 trillion. And for most users, that will be far more than enough. Loading a planet.osm file might go over this number. But we could be reasonably sure that it would work for most people. If you add another 8 bits, then you get 281 trillion unique ID's. This will almost certainly be enough for almost anyone. And if you use this many.. then you're going to run into other problems, I suspect. I'm pretty sure that Roadnav is never (in the near future at least) going to need 64 bits for ID's. Really. Ever. However, you can argue that despite the waste of space, its more efficient that 48 bits. Which looking at the ASM code, this seems to be the case. So which to choose? I say.. all of them! Just make sure we use the right typedefs and it will all magically work. :) But then which to pick as a default? @todo For 48 bits or 40 bits, it may be useful to just use a custom type at this point. More efficient too on 32 bit systems. Or not, depending on padding issues. @todo Heres an interesting question: what if different things use different unique ID types? Obviously certain things require different sizes.. Dustin -- Innovation is just a problem away |
From: R. K. <ro...@ra...> - 2008-10-27 10:20:28
|
On Mon, Oct 27, 2008 at 1:35 AM, <p4d...@sn...> wrote: > I hunted through their website yesterday, and my search yielded no > results for any sort of file that gives the latest date, etc. > Therefore, instead of submitting my code as-is, I emailed the > maintainer of the files, and asked that person about the naming > scheme. Hopefully they realize how difficult it is to link to files > with constantly changing names, and move to a more static naming > scheme. If they don't think that's viable, I'll ask them if they could > create a file with the, uh... appendention (date modified) and let us > know the link to that. Unfortunately... on the website they explicitly > state that not all files have all been modified on the same date... so > the links don't actually have all the same appendentions, which makes > that option not so viable either. This really sucks, I hope they just > rename them all and keep them that way. Anyway... I'll keep in touch > about the response. I don't expect one until tomorrow. A common way of handling this issue is to add a ".latest" symlink that points to the newest file. -- Ragnar Kjørstad |
From: <p4d...@sn...> - 2008-10-27 00:35:34
|
I hunted through their website yesterday, and my search yielded no results for any sort of file that gives the latest date, etc. Therefore, instead of submitting my code as-is, I emailed the maintainer of the files, and asked that person about the naming scheme. Hopefully they realize how difficult it is to link to files with constantly changing names, and move to a more static naming scheme. If they don't think that's viable, I'll ask them if they could create a file with the, uh... appendention (date modified) and let us know the link to that. Unfortunately... on the website they explicitly state that not all files have all been modified on the same date... so the links don't actually have all the same appendentions, which makes that option not so viable either. This really sucks, I hope they just rename them all and keep them that way. Anyway... I'll keep in touch about the response. I don't expect one until tomorrow. Kyle On Oct 25, 2008, at 12:21 PM, Dustin Spicuzza dustin-at- virtualroadside.com |RoadNav| wrote: > I would recommend looking through their site to see if they have > listed > somewhere their naming convention for those files, or something where > you should be able to have the program make a query which can tell you > the date of the latest updates (or maybe theres a '_Features_latest' > file?). > > Failing that, just add an option to the roadnav options to specify > that > suffix (probably the easiest place to do it is in the URL options, > despite that technically it isn't a URL... ). > > Just send the diffs and I'll commit it to trunk, and we can post an > updated build. > > Dustin |
From: Dustin S. <du...@vi...> - 2008-10-25 19:20:57
|
I would recommend looking through their site to see if they have listed somewhere their naming convention for those files, or something where you should be able to have the program make a query which can tell you the date of the latest updates (or maybe theres a '_Features_latest' file?). Failing that, just add an option to the roadnav options to specify that suffix (probably the easiest place to do it is in the URL options, despite that technically it isn't a URL... ). Just send the diffs and I'll commit it to trunk, and we can post an updated build. Dustin p4d...@sn... wrote: > Alright Dustin, I appreciate your help. My changes to the code are > functional, however, since I'd never seen this code before, I simply > hardcoded in the "_Features_20080815" bit to make sure I changed the > right things. Now... as I expect this 20080815 bit is the date it was > modified (or something similar) I don't think that should be hard > coded, do you? For instance, for Idaho, I think ideally the code would > grab ID_Features_* or even ID_* (hoping that they modify the file > instead of just creating new ones, of course). However, I honestly > don't know how to do that. I'd be able to do it if the file was stored > locally, like walking through a directory and looking for a file name > that matched, but since I'm sending a request to a server, I need to > know my link is correct, and I obviously can't send wildcards in > links. How can this be done? > > Kyle > > > On Oct 25, 2008, at 10:43 AM, Dustin Spicuzza dustin-at- > virtualroadside.com |RoadNav| wrote: > > >> Looking at my map cache... the top of my MI_DECI.txt file looks like >> so: >> >> Feature_ID|Feature_Name|Class|State_Alpha|State_num|County| >> County_num|Primary_lat_DMS|Primary_lon_DMS|Primary_lat_DEC| >> Primary_lon_DEC|Source_State_Alpha|Source_lat_DMS|Source_lon_DMS| >> Source_lat_DEC|Source_lon_DEC|Elevation_Meters|Map_Name >> 205015|Continental >> Divide|Ridge|CO|08|Grand|049|390001N|1063550W| >> 39.00027|-106.5972536|||||3914|Independence >> Pass >> >> Whereas the top of the MI_Features_20080815.txt looks like this: >> >> FEATURE_ID|FEATURE_NAME|FEATURE_CLASS|STATE_ALPHA|STATE_NUMERIC| >> COUNTY_NAME|COUNTY_NUMERIC|PRIMARY_LAT_DMS|PRIMARY_LONG_DMS| >> PRIMARY_LAT_DEC|PRIMARY_LONG_DEC|SOURCE_LAT_DMS|SOURCE_LONG_DMS| >> SOURCE_LAT_DEC|SOURCE_LONG_DEC|ELEVATION|MAP_NAME >> 431069|Big >> Swamp|Swamp|IN|18|Steuben|151|414532N|0844852W| >> 41.7589384|-84.8144022|||||315|Camden >> >> So... yes, they look about the same. I'm slightly amused that the >> first >> set of items reside outside the state though.. heh. Anyways. >> >> Dustin >> >> >> p4d...@sn... wrote: >> >>> Alright Dustin, I think I can make the change. However, I never >>> looked at the previous files that were downloaded, and don't know >>> what >>> they looked like. Could you look at http://geonames.usgs.gov/docs/stategaz/ID_Features_20080815.zip >>> and tell me if it looks like what we'd expect ID_DECI.zip to look >>> like? If so, then I'll continue. Thanks! >>> >>> Kyle >>> >>> On Oct 25, 2008, at 10:15 AM, Dustin Spicuzza dustin-at- >>> virtualroadside.com |RoadNav| wrote: >>> >>> >>> >>>> p4d...@sn... wrote: >>>> >>>> >>>>> Whenever one needs to download a map, one gets an "Error reading >>>>> <link> (An error occurred during negotiation)" The links changed. >>>>> All the files are named something different now... I think they >>>>> have dates appended to the end of them too, which might make this >>>>> difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm >>>>> . The code needs to be updated to somehow use this. I mean, we >>>>> could change the map root in the preferences, but the filenames >>>>> aren't even what the program is expecting. I don't want to mess >>>>> with the source if I don't need to. It's too bad, I needed to >>>>> reinstall and lost all my cached maps, and now roadnav is >>>>> completely useless because I can't get any maps. Is this an easy >>>>> fix? >>>>> >>>>> >>>>> >>>> It may be an easy fix -- someone else could speak to this. Rich? >>>> >>>> Personally, I'm not going to take the time to fix it. I already have >>>> had >>>> a huge lack of free time to work on Roadnav, and given what I'm >>>> working >>>> on totally discards the TIGER/Line support, so its not worth it >>>> for me >>>> to get distracted (especially since I'm not particularly familiar >>>> with >>>> the data in question). >>>> >>>> However, if you or someone else wants to fix this in trunk, that >>>> would >>>> probably be a useful thing. :) >>>> >>>> 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 >>>> >>>> >>> ------------------------------------------------------------------------- >>> 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 >> >> >> ------------------------------------------------------------------------- >> 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: <p4d...@sn...> - 2008-10-25 19:05:17
|
Alright Dustin, I appreciate your help. My changes to the code are functional, however, since I'd never seen this code before, I simply hardcoded in the "_Features_20080815" bit to make sure I changed the right things. Now... as I expect this 20080815 bit is the date it was modified (or something similar) I don't think that should be hard coded, do you? For instance, for Idaho, I think ideally the code would grab ID_Features_* or even ID_* (hoping that they modify the file instead of just creating new ones, of course). However, I honestly don't know how to do that. I'd be able to do it if the file was stored locally, like walking through a directory and looking for a file name that matched, but since I'm sending a request to a server, I need to know my link is correct, and I obviously can't send wildcards in links. How can this be done? Kyle On Oct 25, 2008, at 10:43 AM, Dustin Spicuzza dustin-at- virtualroadside.com |RoadNav| wrote: > Looking at my map cache... the top of my MI_DECI.txt file looks like > so: > > Feature_ID|Feature_Name|Class|State_Alpha|State_num|County| > County_num|Primary_lat_DMS|Primary_lon_DMS|Primary_lat_DEC| > Primary_lon_DEC|Source_State_Alpha|Source_lat_DMS|Source_lon_DMS| > Source_lat_DEC|Source_lon_DEC|Elevation_Meters|Map_Name > 205015|Continental > Divide|Ridge|CO|08|Grand|049|390001N|1063550W| > 39.00027|-106.5972536|||||3914|Independence > Pass > > Whereas the top of the MI_Features_20080815.txt looks like this: > > FEATURE_ID|FEATURE_NAME|FEATURE_CLASS|STATE_ALPHA|STATE_NUMERIC| > COUNTY_NAME|COUNTY_NUMERIC|PRIMARY_LAT_DMS|PRIMARY_LONG_DMS| > PRIMARY_LAT_DEC|PRIMARY_LONG_DEC|SOURCE_LAT_DMS|SOURCE_LONG_DMS| > SOURCE_LAT_DEC|SOURCE_LONG_DEC|ELEVATION|MAP_NAME > 431069|Big > Swamp|Swamp|IN|18|Steuben|151|414532N|0844852W| > 41.7589384|-84.8144022|||||315|Camden > > So... yes, they look about the same. I'm slightly amused that the > first > set of items reside outside the state though.. heh. Anyways. > > Dustin > > > p4d...@sn... wrote: >> Alright Dustin, I think I can make the change. However, I never >> looked at the previous files that were downloaded, and don't know >> what >> they looked like. Could you look at http://geonames.usgs.gov/docs/stategaz/ID_Features_20080815.zip >> and tell me if it looks like what we'd expect ID_DECI.zip to look >> like? If so, then I'll continue. Thanks! >> >> Kyle >> >> On Oct 25, 2008, at 10:15 AM, Dustin Spicuzza dustin-at- >> virtualroadside.com |RoadNav| wrote: >> >> >>> p4d...@sn... wrote: >>> >>>> Whenever one needs to download a map, one gets an "Error reading >>>> <link> (An error occurred during negotiation)" The links changed. >>>> All the files are named something different now... I think they >>>> have dates appended to the end of them too, which might make this >>>> difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm >>>> . The code needs to be updated to somehow use this. I mean, we >>>> could change the map root in the preferences, but the filenames >>>> aren't even what the program is expecting. I don't want to mess >>>> with the source if I don't need to. It's too bad, I needed to >>>> reinstall and lost all my cached maps, and now roadnav is >>>> completely useless because I can't get any maps. Is this an easy >>>> fix? >>>> >>>> >>> It may be an easy fix -- someone else could speak to this. Rich? >>> >>> Personally, I'm not going to take the time to fix it. I already have >>> had >>> a huge lack of free time to work on Roadnav, and given what I'm >>> working >>> on totally discards the TIGER/Line support, so its not worth it >>> for me >>> to get distracted (especially since I'm not particularly familiar >>> with >>> the data in question). >>> >>> However, if you or someone else wants to fix this in trunk, that >>> would >>> probably be a useful thing. :) >>> >>> 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 >>> >> >> >> ------------------------------------------------------------------------- >> 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 > > > ------------------------------------------------------------------------- > 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-10-25 17:46:33
|
Heh... I totally mispasted that: MI_DECI.txt: Feature_ID|Feature_Name|Class|State_Alpha|State_num|County|County_num|Primary_lat_DMS|Primary_lon_DMS|Primary_lat_DEC|Primary_lon_DEC|Source_State_Alpha|Source_lat_DMS|Source_lon_DMS|Source_lat_DEC|Source_lon_DEC|Elevation_Meters|Map_Name 1039646|Deer Creek|Stream|OH|39|Fulton|051|413840N|0841605W|41.6444951|-84.2680039|MI|414233N|0841807W|41.7091667|-84.3019444|219|Fayette MI_Features_20080815.txt: FEATURE_ID|FEATURE_NAME|FEATURE_CLASS|STATE_ALPHA|STATE_NUMERIC|COUNTY_NAME|COUNTY_NUMERIC|PRIMARY_LAT_DMS|PRIMARY_LONG_DMS|PRIMARY_LAT_DEC|PRIMARY_LONG_DEC|SOURCE_LAT_DMS|SOURCE_LONG_DMS|SOURCE_LAT_DEC|SOURCE_LONG_DEC|ELEVATION|MAP_NAME 431069|Big Swamp|Swamp|IN|18|Steuben|151|414532N|0844852W|41.7589384|-84.8144022|||||315|Camden There... not that it makes too much of a difference. Dustin Dustin Spicuzza wrote: > Looking at my map cache... the top of my MI_DECI.txt file looks like so: > > Feature_ID|Feature_Name|Class|State_Alpha|State_num|County|County_num|Primary_lat_DMS|Primary_lon_DMS|Primary_lat_DEC|Primary_lon_DEC|Source_State_Alpha|Source_lat_DMS|Source_lon_DMS|Source_lat_DEC|Source_lon_DEC|Elevation_Meters|Map_Name > 205015|Continental > Divide|Ridge|CO|08|Grand|049|390001N|1063550W|39.00027|-106.5972536|||||3914|Independence > Pass > > Whereas the top of the MI_Features_20080815.txt looks like this: > > FEATURE_ID|FEATURE_NAME|FEATURE_CLASS|STATE_ALPHA|STATE_NUMERIC|COUNTY_NAME|COUNTY_NUMERIC|PRIMARY_LAT_DMS|PRIMARY_LONG_DMS|PRIMARY_LAT_DEC|PRIMARY_LONG_DEC|SOURCE_LAT_DMS|SOURCE_LONG_DMS|SOURCE_LAT_DEC|SOURCE_LONG_DEC|ELEVATION|MAP_NAME > 431069|Big > Swamp|Swamp|IN|18|Steuben|151|414532N|0844852W|41.7589384|-84.8144022|||||315|Camden > > So... yes, they look about the same. I'm slightly amused that the first > set of items reside outside the state though.. heh. Anyways. > > Dustin > > > p4d...@sn... wrote: > >> Alright Dustin, I think I can make the change. However, I never >> looked at the previous files that were downloaded, and don't know what >> they looked like. Could you look at http://geonames.usgs.gov/docs/stategaz/ID_Features_20080815.zip >> and tell me if it looks like what we'd expect ID_DECI.zip to look >> like? If so, then I'll continue. Thanks! >> >> Kyle >> >> On Oct 25, 2008, at 10:15 AM, Dustin Spicuzza dustin-at- >> virtualroadside.com |RoadNav| wrote: >> >> >> >>> p4d...@sn... wrote: >>> >>> >>>> Whenever one needs to download a map, one gets an "Error reading >>>> <link> (An error occurred during negotiation)" The links changed. >>>> All the files are named something different now... I think they >>>> have dates appended to the end of them too, which might make this >>>> difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm >>>> . The code needs to be updated to somehow use this. I mean, we >>>> could change the map root in the preferences, but the filenames >>>> aren't even what the program is expecting. I don't want to mess >>>> with the source if I don't need to. It's too bad, I needed to >>>> reinstall and lost all my cached maps, and now roadnav is >>>> completely useless because I can't get any maps. Is this an easy fix? >>>> >>>> >>>> >>> It may be an easy fix -- someone else could speak to this. Rich? >>> >>> Personally, I'm not going to take the time to fix it. I already have >>> had >>> a huge lack of free time to work on Roadnav, and given what I'm >>> working >>> on totally discards the TIGER/Line support, so its not worth it for me >>> to get distracted (especially since I'm not particularly familiar with >>> the data in question). >>> >>> However, if you or someone else wants to fix this in trunk, that would >>> probably be a useful thing. :) >>> >>> 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 >>> >>> >> ------------------------------------------------------------------------- >> 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-10-25 17:44:07
|
Looking at my map cache... the top of my MI_DECI.txt file looks like so: Feature_ID|Feature_Name|Class|State_Alpha|State_num|County|County_num|Primary_lat_DMS|Primary_lon_DMS|Primary_lat_DEC|Primary_lon_DEC|Source_State_Alpha|Source_lat_DMS|Source_lon_DMS|Source_lat_DEC|Source_lon_DEC|Elevation_Meters|Map_Name 205015|Continental Divide|Ridge|CO|08|Grand|049|390001N|1063550W|39.00027|-106.5972536|||||3914|Independence Pass Whereas the top of the MI_Features_20080815.txt looks like this: FEATURE_ID|FEATURE_NAME|FEATURE_CLASS|STATE_ALPHA|STATE_NUMERIC|COUNTY_NAME|COUNTY_NUMERIC|PRIMARY_LAT_DMS|PRIMARY_LONG_DMS|PRIMARY_LAT_DEC|PRIMARY_LONG_DEC|SOURCE_LAT_DMS|SOURCE_LONG_DMS|SOURCE_LAT_DEC|SOURCE_LONG_DEC|ELEVATION|MAP_NAME 431069|Big Swamp|Swamp|IN|18|Steuben|151|414532N|0844852W|41.7589384|-84.8144022|||||315|Camden So... yes, they look about the same. I'm slightly amused that the first set of items reside outside the state though.. heh. Anyways. Dustin p4d...@sn... wrote: > Alright Dustin, I think I can make the change. However, I never > looked at the previous files that were downloaded, and don't know what > they looked like. Could you look at http://geonames.usgs.gov/docs/stategaz/ID_Features_20080815.zip > and tell me if it looks like what we'd expect ID_DECI.zip to look > like? If so, then I'll continue. Thanks! > > Kyle > > On Oct 25, 2008, at 10:15 AM, Dustin Spicuzza dustin-at- > virtualroadside.com |RoadNav| wrote: > > >> p4d...@sn... wrote: >> >>> Whenever one needs to download a map, one gets an "Error reading >>> <link> (An error occurred during negotiation)" The links changed. >>> All the files are named something different now... I think they >>> have dates appended to the end of them too, which might make this >>> difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm >>> . The code needs to be updated to somehow use this. I mean, we >>> could change the map root in the preferences, but the filenames >>> aren't even what the program is expecting. I don't want to mess >>> with the source if I don't need to. It's too bad, I needed to >>> reinstall and lost all my cached maps, and now roadnav is >>> completely useless because I can't get any maps. Is this an easy fix? >>> >>> >> It may be an easy fix -- someone else could speak to this. Rich? >> >> Personally, I'm not going to take the time to fix it. I already have >> had >> a huge lack of free time to work on Roadnav, and given what I'm >> working >> on totally discards the TIGER/Line support, so its not worth it for me >> to get distracted (especially since I'm not particularly familiar with >> the data in question). >> >> However, if you or someone else wants to fix this in trunk, that would >> probably be a useful thing. :) >> >> 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 >> > > > ------------------------------------------------------------------------- > 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: <p4d...@sn...> - 2008-10-25 17:28:01
|
Alright Dustin, I think I can make the change. However, I never looked at the previous files that were downloaded, and don't know what they looked like. Could you look at http://geonames.usgs.gov/docs/stategaz/ID_Features_20080815.zip and tell me if it looks like what we'd expect ID_DECI.zip to look like? If so, then I'll continue. Thanks! Kyle On Oct 25, 2008, at 10:15 AM, Dustin Spicuzza dustin-at- virtualroadside.com |RoadNav| wrote: > p4d...@sn... wrote: >> Whenever one needs to download a map, one gets an "Error reading >> <link> (An error occurred during negotiation)" The links changed. >> All the files are named something different now... I think they >> have dates appended to the end of them too, which might make this >> difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm >> . The code needs to be updated to somehow use this. I mean, we >> could change the map root in the preferences, but the filenames >> aren't even what the program is expecting. I don't want to mess >> with the source if I don't need to. It's too bad, I needed to >> reinstall and lost all my cached maps, and now roadnav is >> completely useless because I can't get any maps. Is this an easy fix? >> > It may be an easy fix -- someone else could speak to this. Rich? > > Personally, I'm not going to take the time to fix it. I already have > had > a huge lack of free time to work on Roadnav, and given what I'm > working > on totally discards the TIGER/Line support, so its not worth it for me > to get distracted (especially since I'm not particularly familiar with > the data in question). > > However, if you or someone else wants to fix this in trunk, that would > probably be a useful thing. :) > > 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-10-25 17:15:17
|
p4d...@sn... wrote: > Whenever one needs to download a map, one gets an "Error reading <link> (An error occurred during negotiation)" The links changed. All the files are named something different now... I think they have dates appended to the end of them too, which might make this difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm. The code needs to be updated to somehow use this. I mean, we could change the map root in the preferences, but the filenames aren't even what the program is expecting. I don't want to mess with the source if I don't need to. It's too bad, I needed to reinstall and lost all my cached maps, and now roadnav is completely useless because I can't get any maps. Is this an easy fix? > It may be an easy fix -- someone else could speak to this. Rich? Personally, I'm not going to take the time to fix it. I already have had a huge lack of free time to work on Roadnav, and given what I'm working on totally discards the TIGER/Line support, so its not worth it for me to get distracted (especially since I'm not particularly familiar with the data in question). However, if you or someone else wants to fix this in trunk, that would probably be a useful thing. :) Dustin -- Innovation is just a problem away |
From: <p4d...@sn...> - 2008-10-25 09:29:58
|
Whenever one needs to download a map, one gets an "Error reading <link> (An error occurred during negotiation)" The links changed. All the files are named something different now... I think they have dates appended to the end of them too, which might make this difficult. I'm thinking regex. You can download them by hand fromhttp://geonames.usgs.gov/domestic/download_data.htm. The code needs to be updated to somehow use this. I mean, we could change the map root in the preferences, but the filenames aren't even what the program is expecting. I don't want to mess with the source if I don't need to. It's too bad, I needed to reinstall and lost all my cached maps, and now roadnav is completely useless because I can't get any maps. Is this an easy fix? Kyle |
From: Dustin S. <du...@vi...> - 2008-10-05 19:29:12
|
Steve Franks wrote: > > Personally, I'm all for any dependencies that get us more > functionality & code faster - at least bzip expat and boost are all > 'big name' projects with plenty of testers & patches, and I've used > boost on windows - I don't see how it would be any more diffucult than > installing and pointing to wx, even though I'm mostly a BSD guy of > late... > > Steve In our case, dependencies in Windows are annoying because for most libraries, there isn't a standard place to put them, so you have to integrate it into the project file.. so everyone has to change the project files when they use it. Which gets annoying. Of course, this is why I've changed all of the wx stuff to just point to c:\wxWidgets... lol. Dustin -- Innovation is just a problem away |
From: Steve F. <ste...@ie...> - 2008-10-05 19:21:05
|
On Sun, Oct 5, 2008 at 11:36 AM, Dustin Spicuzza <du...@vi...> wrote: > Hey, > > So after a bit of a hiatus, I'm working a bit more on improving > libroadnav (though, my time is still currently somewhat limited). Right > now, I'm starting work on recreating the backend for Roadnav to scale a > bit better, and be OpenStreetMap focused. Along the way, I've come > across some dependencies that I'm currently thinking about adding to > Roadnav, and I welcome any thoughts about this. I have listed the > libraries in order of importance. > > bzip2 (important): > > OSM distributes the planet.osm (for those not familiar, its a collection > of all OSM data) file in a 4GB bz2 file. While I plan to support > primarily the live API, it seems like it would be good to support > reading directly from the planet file if the user really wants to spend > a few days compiling maps from it. wxWidgets currently does not support > bzip files. > > expat (important): > > expat is used by wxWidgets internally to parse XML, and more importantly > it can parse XML files in a streaming fashion, which will be > particularly important for the planet.osm file... given its 90GB > uncompressed. The current OSM data importer uses a custom set of > operations to parse the XML file, but it seems to be that it could be a > good idea (and possibly less error-prone) to use expat to do this instead. > > STXXL (thinking about this): > > STXXL is an STL-like library designed/optimized for very large data sets > using external memory. There are a number of features from this library > that could potentially be really useful (the vector and map containers > in particular), depending on the performance of this library for smaller > data sets (hundreds of thousands to millions, which is the range Roadnav > uses). It has also occurred to me that adapting the map implementation > (its a btree, which is similar to an rtree) to use an R tree index (such > as the one I've implemented) could be a *huge* win, and save lots of > time. I've actually contacted the author about this idea to see if he > would be willing to accept some patches to that effect. > > Boost (semi-thinking about this, still a long way off): > > Currently roadnav has an implementation of routing algorithms > (Dijkstra's algorithm, in particular). However, one thing that is > particularly attractive to me is moving this to use the Boost Graph > Library, which not only has implementations for Dijkstra's, but other > routing-related algorithms too (which may help improve performance). > Interestingly enough, there are also some graph-related items in STXXL > also, so this may not be necessary. Of course, this is not really a > priority yet, but I figured that I would throw it out there... > > I realize that for Linux versions of roadnav, the dependencies aren't > quite as big of an issue, whereas for windows it can get trickier and so > we would probably have to import these external dependencies into the > project in their own set of directories or something. If anyone is > interested, I'm doing work on the backend in > libroadnav/branches/TestConcepts/Backend > > As I said, let me know your thoughts about any of this. For the most > part, I haven't actually made up my mind about it yet, just trying to > consider good ways to do this stuff. Thanks! > > 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 > Personally, I'm all for any dependencies that get us more functionality & code faster - at least bzip expat and boost are all 'big name' projects with plenty of testers & patches, and I've used boost on windows - I don't see how it would be any more diffucult than installing and pointing to wx, even though I'm mostly a BSD guy of late... Steve |
From: Dustin S. <du...@vi...> - 2008-10-05 18:37:44
|
Hey, So after a bit of a hiatus, I'm working a bit more on improving libroadnav (though, my time is still currently somewhat limited). Right now, I'm starting work on recreating the backend for Roadnav to scale a bit better, and be OpenStreetMap focused. Along the way, I've come across some dependencies that I'm currently thinking about adding to Roadnav, and I welcome any thoughts about this. I have listed the libraries in order of importance. bzip2 (important): OSM distributes the planet.osm (for those not familiar, its a collection of all OSM data) file in a 4GB bz2 file. While I plan to support primarily the live API, it seems like it would be good to support reading directly from the planet file if the user really wants to spend a few days compiling maps from it. wxWidgets currently does not support bzip files. expat (important): expat is used by wxWidgets internally to parse XML, and more importantly it can parse XML files in a streaming fashion, which will be particularly important for the planet.osm file... given its 90GB uncompressed. The current OSM data importer uses a custom set of operations to parse the XML file, but it seems to be that it could be a good idea (and possibly less error-prone) to use expat to do this instead. STXXL (thinking about this): STXXL is an STL-like library designed/optimized for very large data sets using external memory. There are a number of features from this library that could potentially be really useful (the vector and map containers in particular), depending on the performance of this library for smaller data sets (hundreds of thousands to millions, which is the range Roadnav uses). It has also occurred to me that adapting the map implementation (its a btree, which is similar to an rtree) to use an R tree index (such as the one I've implemented) could be a *huge* win, and save lots of time. I've actually contacted the author about this idea to see if he would be willing to accept some patches to that effect. Boost (semi-thinking about this, still a long way off): Currently roadnav has an implementation of routing algorithms (Dijkstra's algorithm, in particular). However, one thing that is particularly attractive to me is moving this to use the Boost Graph Library, which not only has implementations for Dijkstra's, but other routing-related algorithms too (which may help improve performance). Interestingly enough, there are also some graph-related items in STXXL also, so this may not be necessary. Of course, this is not really a priority yet, but I figured that I would throw it out there... I realize that for Linux versions of roadnav, the dependencies aren't quite as big of an issue, whereas for windows it can get trickier and so we would probably have to import these external dependencies into the project in their own set of directories or something. If anyone is interested, I'm doing work on the backend in libroadnav/branches/TestConcepts/Backend As I said, let me know your thoughts about any of this. For the most part, I haven't actually made up my mind about it yet, just trying to consider good ways to do this stuff. Thanks! Dustin -- Innovation is just a problem away |