Status Update

[Franz]

Hi,

just wanted to drop a note about current refactorings.
I'm currently slimming down the main TrafficminingGUI class:
- I added a new ui package and moved all ui related code there (except the main ui).
- I wrapped all the map stuff into a MapWrapper
- I began isolating the components of the gui by separating the NodeList into separate classes (to be found in ui.nodelist), the other components like resultlist and simplex will follow soon.
  - nodes can now be set by doubleclicking on the map
  - nodes can be removed from the list by selecting+del or double clicking the entries in the list
(most of the cahnes are done in https://code.google.com/p/trafficmining/source/detail?r=2608da6e46b2159bc8fb33caf255e9d38c369ba2# )

Bugs fixed
- if selected the most recent graph now loads again (Issue #20)
- fixed a path painting bug

Plans:
- I am toying with the idea of chaning the repository from Mercurial to GIT as Git grew much more popular
- I am trying to separate the gui even further to slim down the main class
- refactor the evil clustering code :-/
- new algorithms would be cool like bidirectional dijkstra or hierarchical highways etc! - anyone interested! :-)
- motivate myself to continue ...

Regards
Franz

[Karussell]

Hi Franz,

I'm developing algorithm stuff for routing on OSM in Java** (already with bidir. dijkstra and for sure HH or CH later on), but would like to have better UI, clustering, community etc.

But not sure how hard an integration of GraphHopper into trafficmining would be. The advantage of GraphHopper over trafficmining (as I can read from a too quick look) would be a more memory efficient implementation (~1.5GB for full Germany).

Quick question regarding performance: How fast is trafficmining for shortest path of ~150km paths? I was using unterfranken.osm and got response times of ~0.1s with a star (still tons of things on my TODO list to improve this)

Regards,
Peter.

**
https://github.com/karussell/GraphHopper

[Franz Graf]

Hi Peter,

I'll try to check it at the weekend.
But actually I'm in doupt that the comparison is very valid if we just
compare our runtimes of our runs as we will probably have different
hardware specs ;-)

But I wouldn't be surprised if your impl is not only more memory
efficient but also faster as I/we didn't tune towards speed. The aim was
to provide implementations and compare the amount of visited nodes (well
that's what counts in science).

Your project looks really quite interesting! Can you give a brief
description how you manage to be more memory efficient? I guess you have
some data base for storage?

I'll really try to get a glimps on the project - maybe there is a
possibility to combine the projects in a reasonable way.

regards
Franz

--
Homepage: http://www.Locked.de
G+: https://plus.google.com/u/0/107945158062341260943

[Karussell]

hi, a bit late my response ... 

> Can you give a brief description how you manage to be more memory efficient?

> I guess you have some data base for storage? 

Yes something like this. It is either a memory mapped 'array' or an in-memory array. See e.g. the RAMDataAccess implementation

Also graphhopper is able to route with a memory friendly (and fast!) algorithm called contraction hierarchies, 

which needs to traverse only a subset of nodes compared to a normal (bidirectional) A*.

> maybe there is a possibility to combine the projects in a reasonable way. 

yeah, already got some folks who were working on a similar traffic application and are using graphhopper for that now.

Regards,

Peter.