Library for exporting routes to PDF?

[hersle]

Hi!

I enjoy using brouter-web to plan routes for bike tours. Moreover, I prefer to print my routes on paper and bring them with me, as I like the feeling of navigating "analogly", find it easier to discuss the route with others when it is in a physical format, my map does not run on battery, and I think it's fun to keep my favorite, completed and worn paper routes as a "trophy". 😄

It is a tedious and repetitive task to create such a print manually, for example using services that allow printing one map rectangle at the time. To automate the task, I have developed the Leaflet library leaflet-route-print. It lets the user choose a desired map scale, paper size, orientation and margin and zoom the map to the desired level of detail. Then it computes the most effective way of covering the route with a sequence of rectangles of the corresponding size. Next, using the leaflet-image plugin, these map rectangles are effectively "screenshotted" and finally joined into a PDF document with jsPDF, which is suitable for printing. Most of the time is spent downloading the necessary tiles, and everything happens on the client's side. The philosophy is to provide a one-to-one WYSIWYG representation of the digital route in PDF and on paper. If you wish, play around with the demo to get an idea of how it works.

Would you be interested in adding this library to the brouter-web interface? Perhaps it could be incorporated into the "Export" menu somehow? The library is in a functioning state, but still a little rough around the edges. Targeting brouter-web as a reference implementation would motivate me to polish it to the necessary level, and I would attempt to take any special requirements into account during the process.

If you are interested, I have some further ideas to share and challenges I would appreciate any input on.

Best, Herman 😃

[nrenner]

Thanks for the suggestion!

I guess this could be useful for some, although I'm not aware of any requests for such a feature so far. Any opinions?

What I'm a bit worried about is the potential mass downloading of tiles (the demo fails with "maxRect is undefined" when changing scale), we're already at the top end of tile usage.

[hersle]

My vision with this library is to provide an alternative to obtaining paper maps for routes. Instead of purchasing maps of predetermined areas that may or may not cover a desired route ("the traditional approach"), I think it should be possible to generate a map that covers the route from any map tile provider ("the modern approach"). The same idea could be applied for generating a map that covers some given polygon, for example. The Norwegian Mapping Authority provides a service for printing map tiles for a rectangular region of their maps (click MAKE MAP), and this is what inspired me to generalize this to routes and arbitrary tile providers.

The library is still a little rough, and I am still working to handle some edge cases that can occur for some combinations of settings that produce line segments that are parallell to some of the rectangles edges, for example. For now, perturbing the settings slightly when errors arise usually generates error-free rectangle sequences.

I fully understand your concerns about tile usage. For example, the OpenStreetMap tile usage policy forbids downloading an area of over 250 tiles at zoom level 13 or higher for offline or later usage, and I think zoom levels 11-13 would be common candidates for printing. On the other hand, the Norweigan Mapping Authority encourages downloading of maps with a service of their own (albeit the service has some restrictions that they control). Of course, this library is in no way tied to OpenStreetMap or any other tile provider, but some usage restrictions are common. I suppose one could take several stances to enforcing them, neither of which is perfect:

1. Do not expose the library to users at all.
2. Technically disallow printing of routes that would violate tile usage policies, by implementing (and maintaining) rules for all tile providers (that one wishes to support) and checking whether the required tiles for the map that is to be printed violates them.
3. Make it the user's responsibility to adhere to tile usage policies.

[nrenner]

3. Make it the user's responsibility to adhere to tile usage policies.

I think that's not an option. Some users won't care and might cause getting the whole app blocked.

There should at least be some general way to limit zoom levels available for printing and/or number of tiles needed. Probably there should be a conservative automatic suggestion for the zoom to use, maybe with an option (and warning) to override (I found the freedom to choose the zoom just as confusing as the reporter of leaflet-route-print#1).