MATSim Code

removed, as it was nowhere used, and does basically the same thing as org.matsim.plans.algorithms.PersonFilterSelectedPlan.

- renamed MGC.Coordinate2Coord() to MGC.coordinate2Coord() to be consistent with the other methods as well as with the Naming Conventions.
- fixed several JavaDoc errors
- simplified MGC.coord2Point()

delete an empty package.

moved org.matsim.filters.* to playground.marcel.filters.*

RoadPricingScoringFunction no longer extends CharyparNagelScoringFunction, but takes another ScoringFunction as Delegate. This allows the RoadPricingScoringFunction to be used with any ScoringFunction, not just the CharyparNagelScoringFunction. This required changes to RoadPricingScoringFunctionFactory and all places, where this class was instantiated.
CharyparNagelScoringFunction no longer writes the score into the plan in finish(), because that would have meant that every ScoringFunction would have to do this... instead, EventsToScore does this now, so that is a general solution that works for any ScoringFunction. Improved JavaDoc in ScoringFunction.java to make this clear.

extended the test cases:
- new test the constructor and getMin/MaxNorthing/Easting.
- new test get(area, collection)
- new test clear()
- new test execute()
- improved test for values(), test if we really get an UnsupportedOperationException on values().iterater().remove().
- improved test for serialization

Changes and Bugfixes to QuadTree:
- clear() now resets size to 0, sets hasChilds to false, increases modCount by 1
- added method get(double minX, double minY, double maxX, double maxY, Collection<T> values) to get all elements within the specified area.
- added methods get{Min,Max}{Easting,Northing}() to get the extend specified in the constructor.
- made QuadTree.Executor a static inner class, which requires thus again the Generic T (--> influence on other classes using the Executor)
- javadoc improvements

make sure tests runs also without internet connection to get local dtd's.

added JavaDoc to loadConfig()

Simplified the code in split() a little bit after the code coverage analysis showed than one if-condition always yielded true (and that could be theoretically be proved as well).