Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
On 21/03/2019 07:13, Paul Norman via Talk-us wrote: As a maintainer of some of the projects listed, I find that you're misrepresenting the situation. On 2019-03-08 11:25 a.m., Kevin Kenny wrote: I've sounded out the maintainers of various of the OSM software, and get different assessments. osm2pgsql - Actively hostile to supporting what I need, contend that osm2pgsql is the wrong tool for the job. This is incorrect. Both maintainers have interest in adding functionality for propagating information from relations to ways - as opposed to from ways to relations, which is already supported. Neither of us have the free time to code it. If someone wanted to take this on, we'd help with the related issues like Lua API changes. Other people (at least me) have also looked at doing it, but it's not straightforward. I looked at it a while back to try and solve one of the issues that got merged into https://github.com/openstreetmap/osm2pgsql/issues/230 , but didn't get anywhere. If part of https://github.com/openstreetmap/osm2pgsql/issues/901 was to improve the documentation in the code about how what's in the code actually worked (even if it didn't add much extra functionality) it'd be a great step forward. Best Regards, Andy ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
As a maintainer of some of the projects listed, I find that you're misrepresenting the situation. On 2019-03-08 11:25 a.m., Kevin Kenny wrote: I've sounded out the maintainers of various of the OSM software, and get different assessments. osm2pgsql - Actively hostile to supporting what I need, contend that osm2pgsql is the wrong tool for the job. This is incorrect. Both maintainers have interest in adding functionality for propagating information from relations to ways - as opposed to from ways to relations, which is already supported. Neither of us have the free time to code it. If someone wanted to take this on, we'd help with the related issues like Lua API changes. OSM Carto - Little interest, but that's because of the emphasis on consistent rendering worldwide, and this is really a project specific to North America. Pictorial road shields require rendering ref from route relations, and that is not an easy problem to solve. I'm on record as doubting it can be solved given the technical and cartographic constraints the style faces. Allowing propagation of information from relations to ways would change that. It sucks to hear that it won't be implemented without someone stepping forward with pull requests, but that's the reality of the situation. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
On Fri, Mar 8, 2019 at 5:46 PM Phil! Gold wrote: > I started work last year on a better system that generates SVGs on the fly > from OSM data, so it doesn't need the pregeneration step. I got bogged > down with other things before I quite finished, but it's mostly there. It's really great hearing from you! I had tried to message you a few times through OSM and tried to find a working email for you, but never heard anything back. I definitely had things I wanted to pick your brain about! > (There are just a few Canadian routes left to convert; I was having > difficulty finding official specs for their signs.) I think that between Minh and me, we have the signs for all ten Canadian provinces, and a lot of Ontario counties. (The other provinces use a standard 'county highway' sign.) I'll have a look at your code, but frankly, we've diverged an awful lot at this point. I got kind of bogged down in the stored procedures, because the requirement that the PostgreSQL filesystem be visible at Mapnik's runtime was getting tangled up in the chroot jail on my server, and the fact that a stock Mapnik now makes a read-only connection to the database was also a stumbling block. (Even a trigger firing from a read-only connection cannot update the database.) Rather than running from forks, I wound up reworking things so that the SVG generation happens when osmosis runs, rather than when the tile is built, and that went a lot smoother. I also pretty much totally reworked the stored procedures for better readability, and to make them compatible with the GroupSymbolizer. (Your shield clusters are gorgeous, but I found them to be a bridge too far and decided to try out Mapnik's stock support.) Could I get your opinion of https://github.com/kennykb/osm-shields/blob/master/queryprocs.sql.in ? I think that might be a more maintainable starting point, and it also appears to be faster - it's pretty zippy at render time. > > I don't think this is really documented yet, but I now support four > different sign styles, passed as the `style` parameter to the Python > rendering functions: > > * "generic" uses a standard, generic style for every US state and county, >disregarding their individual styles. > * "guide" matches the styles used on highway guide signs. This is now >the default, since it seems most fitting to map rendering. > * "sign" looks like the roadside reassurance markers. > * "cutout" is a modification of the "sign" style to remove dark >background areas. This used to be the default with my old system. Sounds reasonable. I'm making more use of pictorial shields than I think you were, but in some cases that's a bad idea. I'd like to have the 'guide' style, for instance, in place of all the pictorial shields for the NY state parkways - the NY highway shield, but white-on-green instead of black and white, with the parkway's initials. > Anyway, the code is here: > > https://gitlab.com/asciiphil/osm-shields > > Hopefully at some point I'll find time to finish up my changes. (And, > ideally, merge in all of the extra shields you and Minh have put > together.) Thanks, I'll have a look! ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
* Phil! Gold [2019-03-08 17:44 -0500]: > https://gitlab.com/asciiphil/osm-shields Oops, that's the master branch, which doesn't have the changes. You need to look at the svg branch: https://gitlab.com/asciiphil/osm-shields/traa/svg -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- #if _FP_W_TYPE_SIZE < 32 #error "Here's a nickle kid. Go buy yourself a real computer." #endif -- linux/arch/sparc64/double.h --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
* Kevin Kenny [2019-03-08 14:25 -0500]: > On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel wrote: > > > > I agree that a local US OSM map with a *subtly* adapted rendering would be > > fantastic. Phil Gold did some interesting work years ago on rendering US > > style highway shields taking into account (sometimes crazy) route > > concurrency > > (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B > > - note that this is based on years-old data and probably pre-carto-switch > > stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more > > divergent from the main map style, but another great example of initiatives > > around custom map rendering coming out of the US community. > > I've borrowed ideas (and some limited amount of code) from both of > them in doing my experimental rendering [snip] > The chief roadblocks to scaleability are that the graphics are > generated in what amounts to a batch process, taking several minutes, [snip] > Then there's the issue that the graphics for individual shields are > being stored in PNG, which is rendered in a batch process that takes > typically several minutes (so could not cope with minutely updates). I started work last year on a better system that generates SVGs on the fly from OSM data, so it doesn't need the pregeneration step. I got bogged down with other things before I quite finished, but it's mostly there. (There are just a few Canadian routes left to convert; I was having difficulty finding official specs for their signs.) I don't think this is really documented yet, but I now support four different sign styles, passed as the `style` parameter to the Python rendering functions: * "generic" uses a standard, generic style for every US state and county, disregarding their individual styles. * "guide" matches the styles used on highway guide signs. This is now the default, since it seems most fitting to map rendering. * "sign" looks like the roadside reassurance markers. * "cutout" is a modification of the "sign" style to remove dark background areas. This used to be the default with my old system. Anyway, the code is here: https://gitlab.com/asciiphil/osm-shields Hopefully at some point I'll find time to finish up my changes. (And, ideally, merge in all of the extra shields you and Minh have put together.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- What computers do Daleks use? X-TERMINALS, X-TERMINALS! --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
Kevin — yes, I was talking about SOTM US. Please do stay tuned to this list and OSM US blog for announcements for community scholarships and other initiatives we will deploy to make it possible to have many more community members attend (and also present! on interesting topics like this one.) > On Mar 8, 2019, at 12:25 PM, Kevin Kenny wrote: > > Finding the time and money to attend a conference that my employer > doesn't sponsor is hard for me at the moment, particularly since I'm > already committed once or twice a year to conferences on another "free > time" (hah!) project. (Also, I presume you mean SOTM-US? An overseas > conference would add a whole other level of complexity to my getting > to go.) ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))
On Fri, Mar 8, 2019 at 11:37 AM Martijn van Exel wrote: > > I agree that a local US OSM map with a *subtly* adapted rendering would be > fantastic. Phil Gold did some interesting work years ago on rendering US > style highway shields taking into account (sometimes crazy) route concurrency > (http://elrond.aperiodic.net/shields/?zoom=13=39.75926=-86.02786=B > - note that this is based on years-old data and probably pre-carto-switch > stylesheet). Lars Ahlzen created the beautiful TopOSM which is a lot more > divergent from the main map style, but another great example of initiatives > around custom map rendering coming out of the US community. I've borrowed ideas (and some limited amount of code) from both of them in doing my experimental rendering at https://kbk.is-a-geek.net/catskills/test4.html. It has North American highway shields. I say 'North American' because it handles the Canadian and a few Mexican ones, with concurrences, also. It has a lot more than Phil! incorporated thanks to a yeoman effort by Minh Nguyen (sorry, Minh, no time to go hunting for Vietnamese diacritics to spell your name correctly!) It has scalability issues that are fixable, but imply ditching a fair piece of the toolchain. I'm tracking a project for it at https://github.com/kennykb/osm-shields/projects. I have a Kanban for it at https://github.com/kennykb/osm-shields/projects/1. The chief roadblocks to scaleability are that the graphics are generated in what amounts to a batch process, taking several minutes, triggered by the Osmosis update of the 'northamerica' export from geofabrik.de. If the process is to scale to minutely updates and the whole planet, it needs to do shield rendering incrementally in response to specific updates affecting it. The fact that osm2pgsql does not and will not ever support querying of relations at rendering time is a headache, and so the first job will have to be retooling everything to the table formats used by imposm3. (This is entirely doable; it's quite a lot of very routine programming that I've simply not had time to take on.) https://github.com/kennykb/osm-shields/issues/13 Then there's the issue that the graphics for individual shields are being stored in PNG, which is rendered in a batch process that takes typically several minutes (so could not cope with minutely updates). I have some sketches for how that could be accomplished, but again, I keep running out of time. https://github.com/kennykb/osm-shields/issues/5 Also, 'carto' does not have support for the GroupSymbolizer in Mapnik, needed for highway shield rendering, so I'm still stuck with defining the rendering in Mapnik XML. This isn't a problem for me, but others might demand better support. Finally, Mapnik itself would benefit from being able to render SVG's with template parameters substituted from objects in the database. I think that the pipeline could be implemented in a scalable fashion without this last task, but there would be more custom code about. I've sounded out the maintainers of various of the OSM software, and get different assessments. osm2pgsql - Actively hostile to supporting what I need, contend that osm2pgsql is the wrong tool for the job. imposm3 - Interested and helpful, and it appears that they wouldn't actually have to do anything (imposm3 may have everything needed 'right out of the box'). Phil Gold!'s 'highway shields' project - Moribund, but I've extracted from it what I think I need and put the code at https://github.com/kennykb/osm-shields/ TopOSM - Again, moribund, but I have working renderings derived from it that suit me and could serve as starting points for new development. Carto - Maintainers would be very interested in GroupSymbolizer support. OSM Carto - Little interest, but that's because of the emphasis on consistent rendering worldwide, and this is really a project specific to North America. Mapnik - I've not really needed to approach the Mapnik team yet - I've been treating it as a black box. So, it looks as if there's a path forward, but it involves a bunch more programming than I've had time to take on. I'm very good at programming, but my time is limited. I'm much less good at project management, and I'm terrible at recruiting, so I've been unable so far to form a team to tackle this. A better leader than I could probably make significant forward progress with my technical assistance. I may find this thrust upon me, but I hope to dodge any requests to lead open-source development efforts while I'm still in the paid workforce. (With luck, retirement is a couple or three years away.) > Perhaps something for a BoF session at the next SOTM! Finding the time and money to attend a conference that my employer doesn't sponsor is hard for me at the moment, particularly since I'm already committed once or twice a year to conferences on another "free time" (hah!) project. (Also, I presume you mean SOTM-US? An overseas conference would add a whole other level of complexity to
