Re: [OSM-talk] OpenStreetMap Carto design
On Friday 29 June 2018, Frederik Ramm wrote: > [...] > > So the ease of participating or customising has more or less already > gone down the drain; what's still good about OSM Carto is that at > least you can easily install it as-is on your own infrastructure (I > regularly do that for business clients), but I fear it is only a > matter of time until this aspect of usability, too, will be > abandoned, and you will have to run massive pre-computation jobs in > order to even get your map off the ground... I think this is unlikely to happen. Pre-computation is essential for good quality maps at low to mid zoom levels but OSM-Carto was never particularly predestined for a leadership role in this field. In the past year or so many decisions have been made that define a fairly tight framework pointing away from using pre-computation. It is doubtful that even the move to water polygons for the coastlines, i.e. a small change in the way pre-computation is employed, will happen since there are design choices incompatible with this. There are other open map design projects which are more open to pre-computation techniques, in particular OpenTopoMap. Regarding splitting OSM-Carto into two styles - i have my doubts about this - both regarding if this makes sense and if it would work. But i think it would be very good to have this discussion on a more abstract level, i.e. what kind of map style or styles should the OSMF render on its infrastructure. The OSMF should obviously not try to initiate or manage map design projects themselves but existing or new independent projects might be interested in what it takes to have a chance to be supported by the OSMF in this form. We have guidelines for layers on osm.org hosted elsewhere: https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers but we don't have any sort of policy or guideline regarding what is rendered on OSMF servers. As long as OSM-Carto is set for this and considered 'alternativlos' this is a non-issue but since it is clear that this will not necessarily be the case in all eternity and the idea is floated to maybe even render more than one style this becomes a relevant question. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
sent from a phone > On 29. Jun 2018, at 11:39, Frederik Ramm wrote: > > I would love it if OSM Carto > could be split into a "bread and butter" style that is easy to work > with, easy on the eye and easy to render, and a "cartography > navel-gazing" add-on where we show off how we can render different track > patterns depending on the pebble size. We could then offer both on > openstreetmap.org (where the bread-and-butter style would be the default). sounds great, I’m sure a lot of people would love this. I would put the sophisticated style as default on osm.org though, it is mainly for the mappers, people that only use the data mostly see it through third party like mapbox, maps.me etc. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
W dniu 29.06.2018 o 11:06, Christoph Hormann pisze: > I did not make any assumptions on avant-garde being a positive thing > here. In fact for a long time i have clearly said that i think that > OSM map design should become more pluralistic. It is now and it does not go away, so I still see no crossroad - just more or less active. > But historically > OSM-Carto has been and has meant to be avant-garde, in particular also > to justify being rendered on OSMF infrastructure. It's very interesting, could you tell more about it? I'm not aware of such comments and I'm not sure what "avant-garde" meant in this context. I suspect it could be map richness, which is rather simple, but might be seen as avant-garde. Also the act of collective design in itself might be seen as ground breaking. But I wouldn't call it like that. > You are making the wrong assumption here that code complexity and > cartographic sophistication always need to go together. But they > don't. There are plenty of examples of cartographic sophistication > being implemented without additional code complexity as well as code > complexity being added which was cartographically a step back. You're right, I used simplification. We deployed some simple code for borders simplification for example and I was happy with that. Here I talk only about avant-garde which currently requires workarounds. > You are > also making the wrong implicit assumption that code complexity is the > only major factor that negatively affects developers' ability to > implement changes. What are other factors then? > about this. And the unpaved roads rendering is not the problem here, > the problem is the complexity of roads rendering in general. In my opinion there are two problems which add up - current road complexity and surface code being Mapnik workaround too. > Right now OSM-Carto is in the position of a quasi-monopoly in what it > does. A potential competitor would need to mobilize a tile serving > infrastructure at least roughly on the same level as that of the OSMF > to seriously challenge it. And this is quite a big hurdle. This > creates a pretty stable comfort zone where OSM-Carto can rest idly even > if the world of digital cartography is progressing around it. What do you define as the "serious competitor"? How do you measure it, because there are a lot of styles using OSM data - including Wikimedia maps style. Are they serious for you? For me it's not the main problem, rather internal complexity which is hard to avoid. No matter if the competitor exists or not, we're bound by the tools and environment we're using, for example: - https://github.com/gravitystorm/openstreetmap-carto/issues/2452 - problem with lack of variables in YAML and/or CartoCSS parsing big lists in SQL queries - https://github.com/mapnik/mapnik/issues/3763 - lack of em measure in Mapnik - https://github.com/openstreetmap/chef/issues/155 - smarter label placement has been implemented in mainstream Mapnik after I talked with developers, but it's still not deployed on OSMF servers ...and so on. The competitor would have to reimplement all of it or find better toolchain, but OSM Carto could also use them if available, so it's still the same problem. But for rich map I see no such ready tools. Do you know any of them? -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
W dniu 29.06.2018 o 12:57, James pisze: > But they say CartoCSS is dead, what is the intended replacement(if > it's dead it's because there's a newer better thing?)? just a data > structure that contains data/styling? Being "dead" means it's no longer in development, but it's still perfectly usable. It could be another "translator" from CartoCSS language into Mapnik XML configuration, but it's not ready to be replacement at the moment, see here: https://github.com/omniscale/magnacarto/issues/7#issuecomment-399771053 If you can help with development of any of them, that would be helpful. Otherwise we're just limited with what we have, which means CartoCSS 1.0.0. -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
W dniu 29.06.2018 o 13:02, Christoph Hormann pisze: > But the surface rendering from Lucas is something you could fairly well > re-integrate into a reworked road rendering framework afterwards - and > this is probably also the way i would approach it. > How to implement something like that in an actual renderer is of course > not a trivial task. That is core of the problem for me - not the approach, but deciding in non-trivial cases, which is a lot of cases anyway... My first choice would be to make road code cleanup - but that was just started, then Paul stopped the work permanently: https://github.com/gravitystorm/openstreetmap-carto/issues/2869 With rendering surface - there was another implementation idea and code attempt, but that has stopped too: https://github.com/gravitystorm/openstreetmap-carto/pull/3083 And the ultimate choice would be to first implement Mapnik features for what the Lucas wants, so his code would be cleaner. Currently we're back to the ground zero - Lucas code has been reverted and we can check the options again. But please, let be realistic, because I can give you much more "proper" ideas, but I don't, because they would not be useful. And it's not only the surface rendering issue, but it's a great example that talking is cheap and at the end of the day it matters more what can and will be done. -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
W dniu 29.06.2018 o 11:39, Frederik Ramm pisze: > Hi, > >without going into the finer details, I'd like to offer an outsider's > view of OSM Carto development. Thanks, Frederik! I lack such insights (we know our ideas inside the team quite well), so I appreciate your comments a lot. I would be happy to hear more voices of the OSM Carto users (not only developers) community. > But after a > while this small team has started milking the toolchain for all it's > got, and meanwhile the SQL queries are so complex that they threaten to > nullify any effort that has gone into making the style accessible to new > participants (or people who want to customise it). I believe this is mainly due to performance reasons which I mentioned. I would be happy to transform them into styling decisions (MSS files), but most probably that would hurt the hardware resources OSMF has. So this is what I take as a hard limit that can't be fixed. For me this is part of a deal to stay being default style - there is default deployment one has to consider. > So the ease of participating or customising has more or less already > gone down the drain; what's still good about OSM Carto is that at least > you can easily install it as-is on your own infrastructure (I regularly > do that for business clients), but I fear it is only a matter of time > until this aspect of usability, too, will be abandoned, and you will > have to run massive pre-computation jobs in order to even get your map > off the ground... I understand that is what you're afraid of, but I don't expect any of that. I like the simplicity and we're cautious even with external dependencies on pre-computed data. IIRC, there was no discussion about adding any new pre-requisites. > Personally speaking, the OSM Carto map has been good enough for me and > all my use cases for years now. If anything, I found the inflation of > icons and special cases a bit irritating. I would love it if OSM Carto > could be split into a "bread and butter" style that is easy to work > with, easy on the eye and easy to render, and a "cartography > navel-gazing" add-on where we show off how we can render different track > patterns depending on the pebble size. We could then offer both on > openstreetmap.org (where the bread-and-butter style would be the default). Personally lack of shop icons was the deciding factor that pulled me into developing OSM Carto... It's much easier to create small utility script that removes unwanted icons or turn them into simple dots than to add new icon (as you have noticed it might take months or even years). Maybe deployment community needs such customizing tools? As of now we have localization tool from German fork, but maybe "modders" could make more such tools. I would be all for creating such ecosystem. Feel free to contact me for details, I'm ready to help to bootstrap it. I also like the idea of simple and extended version, but I see two problems with that: 1. Where to draw the line and who would decide what is "standard" and what is "extra"? 2. It's again the hardware problem that is haunting us. If OSMF admins would be ready, I could have multiple OSM Carto versions already, for example with different languages. Of course anybody else could support OSMF or run their own environment, but the hardware requirements are quite heavy, and you already know it well: https://help.openstreetmap.org/questions/64405/tile-server-hardware-requirements What are your propositions regarding that? -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
On Friday 29 June 2018, Paul Norman wrote: > > I had a go at fixing the roads code with > https://github.com/gravitystorm/openstreetmap-carto/pull/2869, but > didn't have free time. Based on that work, I'd estimate that the > roads code is twice the size and complexity of what it needs to be. > > With the surface code merged, I would be unwilling to tackle a > cleanup like that. I like the surface code as a technical demo, but > find it's too much complexity for the style in a part of the style > which is already difficult to understand. But the surface rendering from Lucas is something you could fairly well re-integrate into a reworked road rendering framework afterwards - and this is probably also the way i would approach it. By the way roads rendering would be a really good test case for designing a rendering framework that would allow addressing the fundamental needs of rendering (in particular getting everything drawn in the right order and combining polygon and line features) with little complexity and at the same time allow flexibility in design (with casings, patterned fills, additional center lines etc.) I have the impression that giving up the idea of fixed layers and database queries being directly attached to them in favour of a free modularization of how the data is queried and defining how it is drawn in what order independent of that could make this significantly easier and more intuitive. How to implement something like that in an actual renderer is of course not a trivial task. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
But they say CartoCSS is dead, what is the intended replacement(if it's dead it's because there's a newer better thing?)? just a data structure that contains data/styling? On Fri, Jun 29, 2018, 6:49 AM Paul Norman, wrote: > On 2018-06-29 2:48 AM, James wrote: > > So what is intended to replace CartoCSS? Vector tiles? > > CartoCSS is a styling language, vector tiles is an architecture choice. > You can use CartoCSS with vector tiles, as the Cycle Map and Transport > Map layers on osm.org do, or you can use CartoCSS with just conventional > Mapnik, like the Standard and Humanitarian layers do. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
Rendering (unpaved) surface is a real need. Judging from the map notes users don't get the distinction and conflate track symbol with unpaved. Mappers do it too. In Poland (and maybe somewhere else) wrongly tagged tracks (what should be residential+unpaved) are a big problem, almost intractable in scale. We have more tracks by length than any other highway type. The road pattern was a solution conceived AFAIR because we have tons of other decorations in place. Tunnels, embankments, and so on. If we can develop alternative solution to render unpaved roads, that's fine too. pt., 29 cze 2018, 12:00 użytkownik Paul Norman napisał: > I've been involved in OpenStreetMap Carto less and less, partially > because I work with CartoCSS setups enough for work. > > > On 2018-06-29 2:06 AM, Christoph Hormann wrote: > > And you are wrong that "nobody seems to be even noticing" complexity of > > the roads code. At least Lucas, Paul and me have a very good idea > > about this. And the unpaved roads rendering is not the problem here, > > the problem is the complexity of roads rendering in general. > > I had a go at fixing the roads code with > https://github.com/gravitystorm/openstreetmap-carto/pull/2869, but > didn't have free time. Based on that work, I'd estimate that the roads > code is twice the size and complexity of what it needs to be. > > With the surface code merged, I would be unwilling to tackle a cleanup > like that. I like the surface code as a technical demo, but find it's > too much complexity for the style in a part of the style which is > already difficult to understand. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
On 2018-06-29 2:48 AM, James wrote: So what is intended to replace CartoCSS? Vector tiles? CartoCSS is a styling language, vector tiles is an architecture choice. You can use CartoCSS with vector tiles, as the Cycle Map and Transport Map layers on osm.org do, or you can use CartoCSS with just conventional Mapnik, like the Standard and Humanitarian layers do. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
I've been involved in OpenStreetMap Carto less and less, partially because I work with CartoCSS setups enough for work. On 2018-06-29 2:06 AM, Christoph Hormann wrote: And you are wrong that "nobody seems to be even noticing" complexity of the roads code. At least Lucas, Paul and me have a very good idea about this. And the unpaved roads rendering is not the problem here, the problem is the complexity of roads rendering in general. I had a go at fixing the roads code with https://github.com/gravitystorm/openstreetmap-carto/pull/2869, but didn't have free time. Based on that work, I'd estimate that the roads code is twice the size and complexity of what it needs to be. With the surface code merged, I would be unwilling to tackle a cleanup like that. I like the surface code as a technical demo, but find it's too much complexity for the style in a part of the style which is already difficult to understand. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
So what is intended to replace CartoCSS? Vector tiles? On Fri, Jun 29, 2018, 5:42 AM Frederik Ramm, wrote: > Hi, > >without going into the finer details, I'd like to offer an outsider's > view of OSM Carto development. > > When Andy first created OSM Carto, he set out a road map that has long > been superseded but thanks to version control we can still look at it: > > https://github.com/gravitystorm/openstreetmap-carto/blob/v1.0.0/README.md > > Essentially it was: > > v1.0 - re-implement existing stuff in carto > v2.0 - make it more suitable for further development and customisation > v3.0 - tackle the ticket backlog > > What has happened instead is that the easier-to-handle v2.0 was > reasonably successful in attracting volunteers, and now we have a small > team instead of one person doing the style, which is great. But after a > while this small team has started milking the toolchain for all it's > got, and meanwhile the SQL queries are so complex that they threaten to > nullify any effort that has gone into making the style accessible to new > participants (or people who want to customise it). > > So the ease of participating or customising has more or less already > gone down the drain; what's still good about OSM Carto is that at least > you can easily install it as-is on your own infrastructure (I regularly > do that for business clients), but I fear it is only a matter of time > until this aspect of usability, too, will be abandoned, and you will > have to run massive pre-computation jobs in order to even get your map > off the ground... > > Personally speaking, the OSM Carto map has been good enough for me and > all my use cases for years now. If anything, I found the inflation of > icons and special cases a bit irritating. I would love it if OSM Carto > could be split into a "bread and butter" style that is easy to work > with, easy on the eye and easy to render, and a "cartography > navel-gazing" add-on where we show off how we can render different track > patterns depending on the pebble size. We could then offer both on > openstreetmap.org (where the bread-and-butter style would be the default). > > But I'm not involved in OSM Carto development and I won't tell people > how to do their job. Occasionally when I look at OSM Carto tickets I am > in awe about how much work goes into seemingly minor things - how > details are diligently discussed, tried, tested, discarded, done > differently, until they finally come to fruition in a release one year > later. It is great to see this much work and enthusiasm invested in OSM > Carto, and if the price for that is complicated SQL queries then so be > it - the "bread and butter" style I was thinking of could be made by > someone else too. > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
Hi, without going into the finer details, I'd like to offer an outsider's view of OSM Carto development. When Andy first created OSM Carto, he set out a road map that has long been superseded but thanks to version control we can still look at it: https://github.com/gravitystorm/openstreetmap-carto/blob/v1.0.0/README.md Essentially it was: v1.0 - re-implement existing stuff in carto v2.0 - make it more suitable for further development and customisation v3.0 - tackle the ticket backlog What has happened instead is that the easier-to-handle v2.0 was reasonably successful in attracting volunteers, and now we have a small team instead of one person doing the style, which is great. But after a while this small team has started milking the toolchain for all it's got, and meanwhile the SQL queries are so complex that they threaten to nullify any effort that has gone into making the style accessible to new participants (or people who want to customise it). So the ease of participating or customising has more or less already gone down the drain; what's still good about OSM Carto is that at least you can easily install it as-is on your own infrastructure (I regularly do that for business clients), but I fear it is only a matter of time until this aspect of usability, too, will be abandoned, and you will have to run massive pre-computation jobs in order to even get your map off the ground... Personally speaking, the OSM Carto map has been good enough for me and all my use cases for years now. If anything, I found the inflation of icons and special cases a bit irritating. I would love it if OSM Carto could be split into a "bread and butter" style that is easy to work with, easy on the eye and easy to render, and a "cartography navel-gazing" add-on where we show off how we can render different track patterns depending on the pebble size. We could then offer both on openstreetmap.org (where the bread-and-butter style would be the default). But I'm not involved in OSM Carto development and I won't tell people how to do their job. Occasionally when I look at OSM Carto tickets I am in awe about how much work goes into seemingly minor things - how details are diligently discussed, tried, tested, discarded, done differently, until they finally come to fruition in a release one year later. It is great to see this much work and enthusiasm invested in OSM Carto, and if the price for that is complicated SQL queries then so be it - the "bread and butter" style I was thinking of could be made by someone else too. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto design
On Friday 29 June 2018, Daniel Koc4� wrote: > > All in all this is a good example for OSM-Carto being at a > > crossroads (and having been for quite some time) between staying > > avant-garde and pushing the boundaries of cartographic design and > > technology or being satisfied with shuffling the options offered by > > the cartographic mainstream within the technological framework used > > - and which, due to Mapnik and CartoCSS being essentially > > unmaintained, becomes more narrow and limiting every year. > > I don't see a crossroad here: being avant-garde in cartographical > sense might sound cool, proud and tempting, I did not make any assumptions on avant-garde being a positive thing here. In fact for a long time i have clearly said that i think that OSM map design should become more pluralistic. But historically OSM-Carto has been and has meant to be avant-garde, in particular also to justify being rendered on OSMF infrastructure. > This style codebase is large and that might sound like causing a > problem with maintenance, but adding more features is far less > challenging than something as sophisticated as for example "new" road > code - and nobody seems to be even noticing how complicated it > became. You are making the wrong assumption here that code complexity and cartographic sophistication always need to go together. But they don't. There are plenty of examples of cartographic sophistication being implemented without additional code complexity as well as code complexity being added which was cartographically a step back. You are also making the wrong implicit assumption that code complexity is the only major factor that negatively affects developers' ability to implement changes. A huge part of the code complexity in OSM-Carto has been for a log time in workarounds for limitations in Mapnik and CartoCSS. And you are wrong that "nobody seems to be even noticing" complexity of the roads code. At least Lucas, Paul and me have a very good idea about this. And the unpaved roads rendering is not the problem here, the problem is the complexity of roads rendering in general. Right now OSM-Carto is in the position of a quasi-monopoly in what it does. A potential competitor would need to mobilize a tile serving infrastructure at least roughly on the same level as that of the OSMF to seriously challenge it. And this is quite a big hurdle. This creates a pretty stable comfort zone where OSM-Carto can rest idly even if the world of digital cartography is progressing around it. Ultimately this is not the question on what is the right development model for an open map design project. This is about the almost complete lack of competitive pressure to make sure whatever development model is used it is challenged to deliver the best results (or be abandoned because it is unable to do so) - which is not happening for OSM-Carto right now. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap Carto design
(Taken from dev list, because this is wider problem.) W dniu 23.06.2018 o 10:55, Christoph Hormann pisze: > All in all this is a good example for OSM-Carto being at a crossroads > (and having been for quite some time) between staying avant-garde and > pushing the boundaries of cartographic design and technology or being > satisfied with shuffling the options offered by the cartographic > mainstream within the technological framework used - and which, due to > Mapnik and CartoCSS being essentially unmaintained, becomes more narrow > and limiting every year. I don't see a crossroad here: being avant-garde in cartographical sense might sound cool, proud and tempting, but that comes at the high price - maintainability and team work problems. This style codebase is large and that might sound like causing a problem with maintenance, but adding more features is far less challenging than something as sophisticated as for example "new" road code - and nobody seems to be even noticing how complicated it became. Now, I'm happy with the road system look in osm-carto and it was probably worth the hassle, because it's essential element of the generic map. I also think that support for paved/unpaved roads is important, because many people seem to care about this feature for a long time (I hope Lucas can fix the performance problem, so it could be merged again). But probably some more naive rendering with simpler code would be better - it just hasn't been done. So from time to time some fine tuning might be good, but it usually means stretching the code in dangerous ways. It's already hard because of a performance factor - we push some design choices into scary giant SQL queries, but that is needed because of the growing database size and not so fast growing hardware capabilities. Your own fork looks to me like a typical prototype: expressing some interesting ideas, but not really ready for wider usage. Bolder style seems to be another prototype, with more technical than cartographical ideas, and more radical - going from zero with a new software stack. It's good to have some prototypes around, but I'm pretty sure that standard map should stay mainstream. This way or another we rely on other software, especially Mapnik. The generic style is not a place to try cartographic innovations if it makes the code even more complicated. Expressing ideas in a more or less standard way is very important, so it won't end up as too hard to maintain by a group of people, not just one clever designer. -- "My method is uncertain/ It's a mess but it's working" [F. Apple] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
