[OSM-dev] Algorithm for extracting nodes/edges from gps-tracklogs
jbglaw at lug-owl.de
Sat Mar 3 21:44:06 GMT 2007
On Sat, 2007-03-03 15:35:39 +0100, Stefan de Konink <skinkie at xs4all.nl> wrote:
> Jan-Benedict Glaw wrote:
> > On Sat, 2007-03-03 14:35:05 +0100, Stefan de Konink <skinkie at xs4all.nl> wrote:
> > > Jan-Benedict Glaw wrote:
> > > > On Thu, 2007-03-01 22:51:30 +0000, SteveC <steve at asklater.com> wrote:
> > > > > Stefan de Konink wrote:
> > > > > > http://mapgeneration.berlios.de/ ?
> > > > The GPS parser is quite dumb, loads of bugs, wonky license, the UI
> > > > will crash faster than you can see (at least on SMP, due to broken
> > > > locking.)
> > > Yes, the powerpc compile was much more stable than my AMD64 X2 is now.
> > > (I should read howto run the program only only on one processor?)
> > Either your system us UP, or it is SMP. There's currently no easy way
> > to run a given multi-threaded application on only one core.
> > > I noticed the Academic Free License, why is that wonky?
> > Not GPL compatible. For me, that's pain in the ass since I cannot put
> > parts of mapgeneration into any of my other code (which is purely
> > GPL), nor can I sanely put own GPL code into mapgeneration (since I
> > would need to dual-license, which I dislike, especially in this
> > direction.)
> > I had contact with those two developers. Mapgeneration was written for
> > a thesis, not to be put into the Free Software Community in the first
> > place. That's why the code quality is so "poor". It only had to run
> > one time in a highly controlled environment.
> > When I pumped in a dozend traces in parallel, it immediately died.
> > Even pumping them in serialized may make it die, since processing of
> > one trace may extend into importing the next one...
> On my iBook I had a version of a year ago that contains most traces of
> Norway a user sent my and all my traces of The Netherlands. It is
> surprisingly stable.
Maybe due to not being a SMP machine?
> > Though that's all mostly fixable. Just some locking (and maybe
> > decoupling). But the license distracts me from doing that.
> It isn't possible to get the authors to relicense it? Otherwise one
> could reimplement their thesis algorithm for combining traces.
Technically, that would be possible, but when I contacted them, they
didn't seem to be willing to do that.
> > > Quality traces: if the nmea input has a better quality than the
> > > previous, ignore the previous and update the path to the new one.
> > Averaging a number of lower-quality traces /may/ give a better result
> > than relying on a single "higher-quality" trace that's totally broken
> > due to an undetected receiver problem... Choosing a source of
> > information is quite a hard task :)
> True, but if I drive a road twice and my second trace has 1.2 and my
> first one has 5.0 then I thing the algorithm should think 'mmmmm, lets
> use the second one'. But a GUI showing the changes would be nice. Or
> only show the route and not *all* the other information.
> > > Path locking: if someone did a manual trace it should have something als
> > > a ultimate quality, which can be override in case of better trace methods.
> > >
> > > Bezier paths: curved roads not stored as lines, but as curved paths.
> > > Here segment reducing.
> > I don't see number of segments as an ultimate problem, but bezier
> > curves may indeed lead to less overall segments and more eye-candy
> > without extra prices...
> > > ps. If someone wants to start with this... I want to help.
I think a key issue would be to make it work with the rest of the OSM
infrastructure. Quite some effort had been done to get all the worthy
data in, tag it, making segments and ways out of it etc. But overall,
something like mapgeneration could help to cut down a lot of manual
Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
Signature of: Träume nicht von Dein Leben: Lebe Deinen Traum!
the second :
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the dev