<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<div><br></div><div><br></div><div><br></div><div>Nov 8, 2020, 05:31 by machyna@gmail.com:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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">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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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">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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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">https://wiki.openstreetmap.org/wiki/Donations</a> ). <br></div><div><br></div><div><a href="mailto:donations@openstreetmap.org">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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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 class="tutanota_quote" style="border-left: 1px solid #93A3B8; 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" class=""><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 target="_blank" href="mailto:anders@torger.se" rel="noopener noreferrer">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 target="_blank" rel="noopener noreferrer" href="http://openstreetmap.org/">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 target="_blank" rel="noopener noreferrer" href="http://openstreetmap.org/">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 target="_blank" rel="noopener noreferrer" href="https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/">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 target="_blank" rel="noopener noreferrer" href="http://topo.openmap.lt/">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 target="_blank" href="mailto:Tagging@openstreetmap.org" rel="noopener noreferrer">Tagging@openstreetmap.org<br></a>> <a target="_blank" rel="noopener noreferrer" href="https://lists.openstreetmap.org/listinfo/tagging">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> </body>
</html>