sounds cool. have a screenshot?

thank you, that's interesting. maybe long stretches could include dashes in the sketch?

Nice idea. I like that.

@DennisOSRM the more general commits should be moved upstream. I want to keep the surface area of this branch as small as possible, so it won't be a big burden in the future.

Would be cool if you could take a look at the DP commit that uses iterators instead of indices. If you are okay with the general idea, I will do some benchmarking to make sure we don't get performance regressions.

Yep, will do on Monday.

Am 04.10.2014 um 15:50 schrieb Patrick Niklaus notifications@github.com:

@DennisOSRM the more general commits should be moved upstream. I want to keep the surface area of this branch as small as possible, so it won't be a big burden in the future.

Would be cool if you could take a look at the DP commit that uses iterators instead of indices. If you are okay with the general idea, I will do some benchmarking to make sure we don't get performance regressions.

—
Reply to this email directly or view it on GitHub.

We can start moving these changes upstream. This should be possible by cherry-picking the commits into a separate branch. It does make sense to add facade methods to DP to keep the number of breaking changes small, e.g. similar to this:

void DouglasPeucker::Run(std::vector<SegmentInformation> &input_geometry, const unsigned zoom_level)
{
  Run(std::begin(input_geometry), std::end(input_geometry), zoom_level);
}

Please do not forget to add #include<numeric> to fix std::iota errors on Windows :)

The Windows build fix that worked for me: alex85k@28e6e90 (see below)

There are warnings about class/struct mismatch in forward declaration like this:

d:\build_r2\osrm_libs\osrm-backend\algorithms\monotone_decomposition.hpp(6): warning C4099: 'SymbolicCoordinate' : type name first seen using 'struct' now seen using 'class' [D:\build_r2\osrm_libs\osrm-backend\build\algorithm-tests.vcxproj]
d:\build_r2\osrm_libs\osrm-backend\algorithms\monotone_decomposition.hpp(7): warning C4099: 'SubPath' : type name first seen using 'struct' now seen using 'class' [D:\build_r2\osrm_libs\osrm-backend\build\algorithm-tests.vcxproj]

So there is a simpler fix: alex85k@99a5b9b . Is it better to fix all such warnings (and potential errors) by using struct in all other forward declarations of SymbolicCoordinate / SubPath? alex85k@4224764

There are also some double-to-int conversion warnings:

d:\build_r2\osrm_libs\osrm-backend\algorithms\../DataStructures/SymbolicCoordinate.h(70): warning C4244: 'argument' : conversion from 'const SymbolicCoordinate::ScalarT' to 'int', possible loss of data [D:\build_r2\osrm_libs\osrm-backend\build\OSRM.vcxproj]
d:\build_r2\osrm_libs\osrm-backend\algorithms\../DataStructures/SymbolicCoordinate.h(70): warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data [D:\build_r2\osrm_libs\osrm-backend\build\OSRM.vcxproj]
d:\build_r2\osrm_libs\osrm-backend\algorithms\../DataStructures/SchematizedPlane.h(39): warning C4244: 'argument' : conversion from 'double' to 'const float', possible loss of data [D:\build_r2\osrm_libs\osrm-backend\build\OSRM.vcxproj]

Interesting. Makes me think of LineDrive.