Agreed. I think it's really nice to have active thinking and work around this. The key is to get the rendering stack people involved. Perhaps Paul Norman can function as a liaison?
Martijn Sent from my iPhone > On Aug 24, 2018, at 12:06, Evin Fairchild <evindf...@gmail.com> wrote: > > Really glad to see that someone is reviving this and actually taking the step > to get it rendered. Frankly, I never understood why Phil didn't do this in > the first place. I even mentioned this to him at the time (can't remember his > response though). > > -Evin (compdude) > >> On Wed, Aug 22, 2018, 2:21 PM Kevin Kenny <kevin.b.ke...@gmail.com> wrote: >> (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 >> Talk-us@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-us > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us