(I apologize in advance to the tile-serving community if this message is inappropriate. I see that traffic on that list is largely limited to highly specific technical discussions, but couldn't see a more appropriate forum.)
For several years now, I've been using the support code for shaped shields in OSM, originally developed by Phil! Gold and Richard Weait, to render North American-style maps. A typical example can be found at https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143&lo=-74.4233&z=14 In that view, you can see distinct shields for Interstate, US, New York, and county routes, and at least one concurrence (New York 17M aligned with US 6). Incidentally, Phil's is the only renderer that I've seen that can make sense of cases like West Virginia's bizarre double route numbers, as seen in https://kbk.is-a-geek.net/catskills/test4.html?la=41.4143&lo=-74.4233&z=14 . The visual distinction among highway shields is really necessary in North America, where there are so many different route networks overlaid. In the course of working with the code, I've made a number of changes and become seriously out of sync with the main development line, which appears to be moribund. (Phil! and Richard have not answered recent queries; I suspect that I have obsolete contact information, but the messages also have not been returned undelivered.) Accordingly, I've (quite reluctantly) created my own repository - https://github.com/kennykb/osm-shields - with material from the project. The shield templates to be found there are mostly those of Phil! (I added only a handful), but the code to manage shields is almost entirely new. Some significant changes are: The list of shields to be rendered is obtained from the database itself, rather than being predetermined by a configuration file for each network. This has the disadvantage that refs that are known to be problematic may be rendered (but in most cases they ought to be unsigned_ref). On the other hand, it has the distinct advantage that as mappers continue to create the route relations, the corresponding shields appear virtually automatically. The composition of shield clusters, rather than being handled by a stored procedure in the database, is done using a GroupSymbolizer in Mapnik. I suspect, given the dearth of discussion that I find in a Google query, that I'm the first user to attempt to use GroupSymbolizer with actual open-ended shield clusters, and therefore that I've trodden new ground in the path from database to renderer. I encourage developers who are interested in the GroupSymbolizer to read at least https://github.com/kennykb/osm-shields/wiki/Using-the-GroupSymbolizer - it has a number of tricks to structure the results in a way that the GroupSymbolizer can consume and that renders well. The disadvantage to using the GroupSymbolizer is that Phil!'s shield clusters were rather more attractive visually, since they were aligned to lie in the direction of a way. The advantage is that the current approach can run on an unpatched Mapnik, as opposed to Phil!'s original, which requires at least patching Mapnik to use a read/write connection to the database. Managing, reliably, the association between ways and the routes in which they participate requires a couple of database tables that a stock osm2pgsql does not produce. I would very much appreciate any commentary from developers of osm2pgsql and Mapnik, particularly, about the issues discussed in https://github.com/kennykb/osm-shields/wiki/Maintaining-the-association-between-ways-and-routes What I'm currently doing works well for my own use, which is driven by daily updates to extracts at Geofabrik, but will obviously not scale to a whole planet and minutely updates. Finally, I'd really like to invite anyone with the necessary SVG skills to contribute shield graphics for the missing networks. If you're also a programmer and want to take a whack at the rest of the procedure in https://github.com/kennykb/osm-shields/wiki/Adding-new-networks, and give me a pull request or ask for help, that would be even better, but even the artwork would be a time-saver. If you've got this far in reading, thanks! I know this was a long message, and I hope that I've not wasted too much of anyone's time. _______________________________________________ Talk-us mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-us
