<div dir="ltr"><div dir="auto">Thank you for the explanation Joseph Isenberg. Now I can see why that's so hard to implement. <br><br>Also, could someone please add descriptions/organize the projects listed in the Wiki page for Vector Tiles? </div><div dir="auto">As a relative newcomer to the OSM development space, it seems that implementing vector tiles for OSM-carto is currently the most centralized and focused effort (though little progress) in the OSM community, yet it's all the way down in the Server section of the article?</div><div>I'm also confused as to what the TODO section is.</div><div>The whole article is confusing at first.</div><div><a href="https://wiki.openstreetmap.org/wiki/Vector_tiles">https://wiki.openstreetmap.org/wiki/Vector_tiles</a> <br></div><div><br></div></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El El dom, nov. 8, 2020 a la(s) 11:54, Joseph Eisenberg <<a href="mailto:joseph.eisenberg@gmail.com" target="_blank">joseph.eisenberg@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="auto">Re: "Vector tiles could allow for instant client-side switching of map styles, the ability to customize the base layer, and allow users to make custom maps themselves"</div><div dir="auto"><br></div><div>This is often claimed as a benefit of client-side vector tiles, but in practice it is not possible. </div><div><br></div><div>The reason is that at mid zoom levels there is far too much data in the database for it all to be made available in a vector tile format so that the map is fully customizable. </div><div><br></div><div>If we were to include all features on the vector tile data, the rendering would be too slow or would crash for many users, especially those who have mobile phones, or lower-powered tablets, or even current low-end laptops. </div><div><br></div><div>Practical client-side vector tiles have to significantly simplify the data and remove a number of nodes and features to make the rendering practical. While some customization is possible (like hiding some icons and labels, or changing the script or language of the text labels), you are not going to get a custom rendering from one set of vector tiles.</div><div><br></div><div>User pnorman and several others had been working on a demonstration which re-implements the current OpenStreetMap Carto style in server-side vector tiles (the first step), but it is quite difficult to achieve a good result with currently available open source tools, and there will have to be some compromises which worsen the cartography in some cases. </div><div><br></div><div>I have not heard an update on this project in the past few months, so it may be stalled. </div></div></div><div dir="ltr"><div dir="ltr"><div><br></div><div>-- Joseph Eisenberg</div><div dir="auto"><br></div></div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 8, 2020 at 8:48 AM Seth Deegan <<a href="mailto:jayandseth@gmail.com" target="_blank">jayandseth@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="color:rgb(80,0,80)"><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And there should be several specialized layers: general car navigation map, sport map for hiking/cycling/skiing, transportation. All of that would be possible with vector tiles which are less computationally demanding to create.</blockquote></div></blockquote></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We already have multiple map styles.</blockquote><div><br></div><div>What they mean is that the current map styles run by other providers will not be necessary if we switch to vector tiles. </div><div><br></div><div>Vector tiles could allow for instant client-side switching of map styles, the ability to customize the base layer, and allow users to make custom maps themselves (this is extremely powerful). </div><div><br></div><div>This is pretty self explanatory, but I wanted to note earlier that vector tiles allow for the clickability/interactivity of every element on the map. </div><div>Most new users who come to <a href="http://osm.org" target="_blank">osm.org</a> don't even know what the Query Tool does or that it exists. It's also pretty inconvenient and slow. </div><div>Making everything clickable allows features to be explored with a possible beautiful UI like Google Maps.  </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 8, 2020 at 1:46 AM Mateusz Konieczny via Tagging <<a href="mailto:tagging@openstreetmap.org" target="_blank">tagging@openstreetmap.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
<div><br></div><div><br></div><div><br></div><div>Nov 8, 2020, 05:31 by <a href="mailto:machyna@gmail.com" target="_blank">machyna@gmail.com</a>:<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>I absolutely agree with Seth, OSM should switch to vector tiles ASAP. <br></div></div></blockquote><div>Note that OSM would not switch to vector tiles. At most one more rendering would switch<br></div><div>to vector tiles.<br></div><div><br></div><div>For OSM Carto see <a href="https://github.com/gravitystorm/openstreetmap-carto/issues/3201" target="_blank">https://github.com/gravitystorm/openstreetmap-carto/issues/3201</a><br></div><div>(not sure what is the state and what is the current blocker)<br></div><div><br></div><div>(sorry if that is overly pedantic)<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>And there should be several specialized layers: general car navigation map, sport map for hiking/cycling/skiing, transportation. All of that would be possible with vector tiles which are less computationally demanding to create.<br></div></div></blockquote><div>We already have multiple map styles.<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>Their code is all on github so no need to reinvent the wheel and I think this could be easily modified for OSM purposes.<br></div><div><a href="https://github.com/FreemapSlovakia" rel="noopener noreferrer" target="_blank">https://github.com/FreemapSlovakia</a><br></div></div></blockquote><div>Is there somewhere description/summary of their software stack?<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>If there is nobody who can or is willing to do it then let's hire someone who can. <br></div><div><br></div><div>Or let a company like Mapbox do it.<br></div></div></blockquote><div>If someone, anyone is willing to sponsor hosting they can propose to add<br></div><div>their tiles to OSM main site (see <br></div><div><a href="https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers" target="_blank">https://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers</a><br></div><div>)<br></div><div><br></div><div>Though as business of Mapbox is to offer paid hosting of OSM data it is dubious that they<br></div><div>would put special effort into competing with themself. Even free tier of their products<br></div><div>requires giving credit card details.<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div> I would be willing to do regular monthly donations for someone's salary if that makes OSM better and more attractive.<br></div></div></blockquote><div>I am not sure how one may donate for specific target of vector tiles<br></div><div>(it is also not mentioned at <a href="https://wiki.openstreetmap.org/wiki/Donations" target="_blank">https://wiki.openstreetmap.org/wiki/Donations</a> ). <br></div><div><br></div><div><a href="mailto:donations@openstreetmap.org" target="_blank">donations@openstreetmap.org</a> is appearing on the page, maybe asking there is<br></div><div>there such possibility would be useful<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>I also fully agree with Anders. OSM needs change. There should be some sort of committee with a clear vision that would enforce a unified style of mapping.<br></div></div></blockquote><div>While central power may be useful and offer some benefits, it is really poor place for it.<br></div><div><br></div><div>Either some agreement can be reached and such committee is not needed or they<br></div><div>would make decisions where large part of community disagrees with it.<br></div><div><br></div><div>Except cases where this is absolutely needed, such entity would do more damage<br></div><div>than benefit.<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div>It is absolutely ridiculous that we have features that are mapped in 2 or more different ways simultaneously e.g. riverbanks or sidewalks... Who is supposed to use and rely on such data?<br></div></div></blockquote><div>Duplicate tags are mildly irritating while processing, but it is not a serious or main problem for<br></div><div>data consumers. <br></div><div><br></div><div>(and it is from person who put a lot of effort into tagging improvements, wikifiddling, <br></div><div>deprecating some unwanted values, deduplication and validator-related work and has<br></div><div>some experience from data consumer side)<br></div><blockquote style="border-left:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div dir="ltr"><div><br></div><div>Martin<br></div><div> <br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan<br></div><div><br></div><div>I actually just found that article about OSM’s problems.<br></div><div>One of the major topics mentioned, the fact that OSM acts as a database and<br></div><div>not a map, and that this acts as a hinderance to the expansion and<br></div><div>development of the project, is very true.<br></div><div>As a result, I’ve came to think that implementing Vector tiles should be<br></div><div>OSM’s #1 development priority right now. If people who find OSM realize<br></div><div>that there’s a lot more data than just the raster images displayed by the<br></div><div>standard tile layer, than they will be more likely to contribute and grow<br></div><div>the OSM community.<br></div><div>We’re all here complaining about computational needs required by rendering<br></div><div>servers, but there are some great vector tile implementations that require<br></div><div>way less computational needs.<br></div><div>Moral of the story: We need Vector tiles.<br></div><div>El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger <<a href="mailto:anders@torger.se" rel="noopener noreferrer" target="_blank">anders@torger.se</a>><br></div><div>escribió:<br></div><div>> This is great information, I didn't know about your project, very very<br></div><div>> interesting. I have recently come to understand the OSM-Carto technical<br></div><div>> challenges recently. I haven't given it much of a thought as a casual<br></div><div>> mapper for the past two years, just been a bit disappointed with how it<br></div><div>> looks.<br></div><div>><br></div><div>> I am a programmer in profession though so when taking a deeper look and<br></div><div>> though about it I see these challenges.<br></div><div>><br></div><div>> However, and this is a big however, I think that the face of<br></div><div>> openstreetmap really need to be a cartographic sound map. It's not right<br></div><div>> that a style seemingly designed mainly for speedy diagnosis should be<br></div><div>> the face of OSM. How many of our mappers are so technical that they<br></div><div>> understand this? And howcome did I not even know about this cartographic<br></div><div>> project of yours? If there are great styles out there but noone knows<br></div><div>> about them that's a problem.<br></div><div>><br></div><div>> And even if we let the not-so-good-cartography be the first map we see<br></div><div>> on <a rel="noopener noreferrer" href="http://openstreetmap.org/" target="_blank">openstreetmap.org</a> (which makes no sense), some of the other layers<br></div><div>> presented there should be one which focus on good cartography, and all<br></div><div>> that are there now have many of the same issues as the main style.<br></div><div>><br></div><div>> I assume that many, perhaps most, casual mappers use the web editor. I'm<br></div><div>> really impressed with the web editor, it's great and is mostly<br></div><div>> user-friendly, you don't need to be a technical person to map, and that<br></div><div>> is how I think it should be. One thing with the web editor though is<br></div><div>> that unless you are technical enough to turn off caching (which<br></div><div>> essentially means putting the browser in development mode), you won't<br></div><div>> see the rendered results for a long time, even if reloading the page,<br></div><div>> you still get cached data. Thus it wouldn't matter if the rendering<br></div><div>> wasn't updated for a couple of hours or even more, the casual mapper<br></div><div>> won't see it anyway.<br></div><div>><br></div><div>> I think that direct feedback is desirable of course, but compared to<br></div><div>> other goals I think it's less important, and one can work with the user<br></div><div>> interface in the web editor to mitigate this issue. Perhaps just have a<br></div><div>> way to probe the server so it can deliver some render status. The<br></div><div>> biggest problem today with the web editor regarding feedback is that to<br></div><div>> a casual mapper it may not be obvious that the map needs to be rendered<br></div><div>> at all and that can take time, and together with the web caching and<br></div><div>> different zoom levels it gets even more confusing. Many of us more<br></div><div>> experienced mappers know exactly how OSM works and renders, and we go<br></div><div>> blind for how a new user will experience it.<br></div><div>><br></div><div>> One way to mitigate this could be to turn on some render info view in<br></div><div>> the web interface to show render status of tiles, maybe even estimated<br></div><div>> time left, and then a way to refresh the tiles without having to resort<br></div><div>> to putting the web browser in development mode with disabled cache.<br></div><div>><br></div><div>> And now to the most important point, whether one likes it or not,<br></div><div>> OSM-Carto as being the face of OSM and the most commonly used style, is<br></div><div>> the de-facto reference and driver of features and tagging. If OSM-Carto<br></div><div>> doesn't support basic cartography features many mappers won't be<br></div><div>> motivated to tag for that, and then the cartographic styles will have<br></div><div>> less information than they need to make good maps. OSM-Carto due to its<br></div><div>> limited rendering capabilities also make casual mappers tempted to "tag<br></div><div>> for the renderer" just to get results, which for example can mean that<br></div><div>> villages are upped, and thus the cartographic style will get fed with<br></div><div>> incorrect information.<br></div><div>><br></div><div>> In summary I think there are *very* strong arguments for that the main<br></div><div>> style shown at <a rel="noopener noreferrer" href="http://openstreetmap.org/" target="_blank">openstreetmap.org</a> and the main style used for editors<br></div><div>> should be focused on providing great cartography (with the extension<br></div><div>> that it should probably present more features than a usual map,<br></div><div>> alternatively we need to split into several styles, all cartographic<br></div><div>> sound), and we must allow it to be be more computationally expensive and<br></div><div>> come up with smart ways to mitigate that in the tools. We can't<br></div><div>> stubbornly hold on to principles and use the same arguments that held up<br></div><div>> and worked well back in 2004, there are things that need to be revised.<br></div><div>> And one of these things is that we need to understand that good<br></div><div>> cartography needs priority, and good (online) cartography today has much<br></div><div>> tougher competition and therefore expectations than it had back in 2004.<br></div><div>><br></div><div>> While searching the web for what's happening inside OSM I found this<br></div><div>> blog post from 2018 written by a longtime OSM contributor, where some of<br></div><div>> these issues are discussed:<br></div><div>> <a rel="noopener noreferrer" href="https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/" target="_blank">https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/<br></a>></div><div>> but it seems that not much has happened since, which makes me somewhat<br></div><div>> worried about the project's future. I don't think we need a revolution<br></div><div>> or something, but there are some things that need to start moving, and<br></div><div>> for some of these things the old processes no longer work.<br></div><div>><br></div><div>> /Anders<br></div><div>><br></div><div>> On 2020-11-07 07:52, Tomas Straupis wrote:<br></div><div>> > 2020-11-07, št, 00:41 Anders Torger rašė:<br></div><div>> >> However, how important is it that update of the map is immediate for<br></div><div>> >> every database update? <...><br></div><div>> ><br></div><div>> >   OSM-Carto is a style whose purpose is to visualise OSM data to<br></div><div>> > MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also<br></div><div>> > has a requirement to be easily deployable by almost anybody on any<br></div><div>> > hardware. This means that pre-processing of data is impossible as per<br></div><div>> > requirements (not a design decision). And without pre-processing it is<br></div><div>> > impossible to have a cartographically sound map. So even while the<br></div><div>> > OSM-Carto team is doing a terrific job and they do have people with<br></div><div>> > good cartographic knowledge (like Christopher), but OSM-Carto does not<br></div><div>> > have such a purpose - cartography.<br></div><div>> ><br></div><div>> >   We're playing around with a small project striving to comply with<br></div><div>> > cartographic rules - <a rel="noopener noreferrer" href="http://topo.openmap.lt/" target="_blank">topo.openmap.lt</a> - some data is updated daily,<br></div><div>> > generalisation is done weekly. But you already get generalised roads,<br></div><div>> > buildings, smart lines for waterbody labels as well as text size and<br></div><div>> > letter spacing. This should get cartographic simplification for<br></div><div>> > waterways this coming spring (not DP or VW, but Wang-Müller). So this<br></div><div>> > can be done, but OSM-Carto is not the place to do it.<br></div><div>> ><br></div><div>> >   Therefore if you want to have a cartographically sound map - you<br></div><div>> > will need a separate project - separate rendering and stuff. You're<br></div><div>> > totally right - for general (not mapper) use, minutely update is less<br></div><div>> > important than cartographically correct representation. And also not<br></div><div>> > everything has to be generalised, some parts could be updated very<br></div><div>> > fast, some could be updated weekly or even monthly. Segmentation of<br></div><div>> > data could also get more attention (re-calculating only the parts<br></div><div>> > which need re-creation). Such tasks could even push forward topics<br></div><div>> > which are currently the target of generalisation and multiple<br></div><div>> > representation group of International cartographic association - I<br></div><div>> > really think OpenStreetMap has people and capabilities to have a say<br></div><div>> > there.<br></div><div>><br></div><div>> _______________________________________________<br></div><div>> Tagging mailing list<br></div><div>> <a href="mailto:Tagging@openstreetmap.org" rel="noopener noreferrer" target="_blank">Tagging@openstreetmap.org<br></a>> <a rel="noopener noreferrer" href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank">https://lists.openstreetmap.org/listinfo/tagging<br></a>></div><div>--<br></div><div>Thanks,<br></div><div>Seth<br></div></blockquote></div></blockquote><div><br></div>  </div>

_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Thanks,<div>Seth</div></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div></div>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org" target="_blank">Tagging@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/tagging" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/tagging</a><br>
</blockquote></div></div>