https://www.freemap.sk/?map=14/48.930467/19.094570&layers=X
This is a nice topographical map, but it isn't serving client-side vector tiles. The tiles are jpegs, you can see jpg compression artifacts when zooming in. Perhaps vector tiles are used on the server side, I haven't looked into all of the code. -- Joseph Eisenberg On Sat, Nov 7, 2020 at 8:36 PM Martin Machyna <mach...@gmail.com> wrote: > I absolutely agree with Seth, OSM should switch to vector tiles ASAP. 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. > > As an example, a small community in Slovakia used to render low zoom tiles > on their server and high zoom tiles on volunteers' home computers and the > update time was quite long. After they switched to vector tiles, all is > rendered on the server only and instead of 1 country now they render 16+ > countries with fast refresh and on-demand rendering. > > And I personally think the result looks pretty good: > https://www.freemap.sk/?map=14/48.930467/19.094570&layers=X > > Their code is all on github so no need to reinvent the wheel and I think > this could be easily modified for OSM purposes. > https://github.com/FreemapSlovakia > > If there is nobody who can or is willing to do it then let's hire someone > who can. Or let a company like Mapbox do it. I would be willing to do > regular monthly donations for someone's salary if that makes OSM better and > more attractive. > > 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. 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? > > Martin > > > >> Date: Sat, 7 Nov 2020 08:36:52 -0600 From: Seth Deegan >> >> I actually just found that article about OSM’s problems. >> One of the major topics mentioned, the fact that OSM acts as a database >> and >> not a map, and that this acts as a hinderance to the expansion and >> development of the project, is very true. >> As a result, I’ve came to think that implementing Vector tiles should be >> OSM’s #1 development priority right now. If people who find OSM realize >> that there’s a lot more data than just the raster images displayed by the >> standard tile layer, than they will be more likely to contribute and grow >> the OSM community. >> We’re all here complaining about computational needs required by rendering >> servers, but there are some great vector tile implementations that require >> way less computational needs. >> Moral of the story: We need Vector tiles. >> El El sáb, nov. 7, 2020 a la(s) 05:24, Anders Torger <and...@torger.se> >> escribió: >> > This is great information, I didn't know about your project, very very >> > interesting. I have recently come to understand the OSM-Carto technical >> > challenges recently. I haven't given it much of a thought as a casual >> > mapper for the past two years, just been a bit disappointed with how it >> > looks. >> > >> > I am a programmer in profession though so when taking a deeper look and >> > though about it I see these challenges. >> > >> > However, and this is a big however, I think that the face of >> > openstreetmap really need to be a cartographic sound map. It's not right >> > that a style seemingly designed mainly for speedy diagnosis should be >> > the face of OSM. How many of our mappers are so technical that they >> > understand this? And howcome did I not even know about this cartographic >> > project of yours? If there are great styles out there but noone knows >> > about them that's a problem. >> > >> > And even if we let the not-so-good-cartography be the first map we see >> > on openstreetmap.org (which makes no sense), some of the other layers >> > presented there should be one which focus on good cartography, and all >> > that are there now have many of the same issues as the main style. >> > >> > I assume that many, perhaps most, casual mappers use the web editor. I'm >> > really impressed with the web editor, it's great and is mostly >> > user-friendly, you don't need to be a technical person to map, and that >> > is how I think it should be. One thing with the web editor though is >> > that unless you are technical enough to turn off caching (which >> > essentially means putting the browser in development mode), you won't >> > see the rendered results for a long time, even if reloading the page, >> > you still get cached data. Thus it wouldn't matter if the rendering >> > wasn't updated for a couple of hours or even more, the casual mapper >> > won't see it anyway. >> > >> > I think that direct feedback is desirable of course, but compared to >> > other goals I think it's less important, and one can work with the user >> > interface in the web editor to mitigate this issue. Perhaps just have a >> > way to probe the server so it can deliver some render status. The >> > biggest problem today with the web editor regarding feedback is that to >> > a casual mapper it may not be obvious that the map needs to be rendered >> > at all and that can take time, and together with the web caching and >> > different zoom levels it gets even more confusing. Many of us more >> > experienced mappers know exactly how OSM works and renders, and we go >> > blind for how a new user will experience it. >> > >> > One way to mitigate this could be to turn on some render info view in >> > the web interface to show render status of tiles, maybe even estimated >> > time left, and then a way to refresh the tiles without having to resort >> > to putting the web browser in development mode with disabled cache. >> > >> > And now to the most important point, whether one likes it or not, >> > OSM-Carto as being the face of OSM and the most commonly used style, is >> > the de-facto reference and driver of features and tagging. If OSM-Carto >> > doesn't support basic cartography features many mappers won't be >> > motivated to tag for that, and then the cartographic styles will have >> > less information than they need to make good maps. OSM-Carto due to its >> > limited rendering capabilities also make casual mappers tempted to "tag >> > for the renderer" just to get results, which for example can mean that >> > villages are upped, and thus the cartographic style will get fed with >> > incorrect information. >> > >> > In summary I think there are *very* strong arguments for that the main >> > style shown at openstreetmap.org and the main style used for editors >> > should be focused on providing great cartography (with the extension >> > that it should probably present more features than a usual map, >> > alternatively we need to split into several styles, all cartographic >> > sound), and we must allow it to be be more computationally expensive and >> > come up with smart ways to mitigate that in the tools. We can't >> > stubbornly hold on to principles and use the same arguments that held up >> > and worked well back in 2004, there are things that need to be revised. >> > And one of these things is that we need to understand that good >> > cartography needs priority, and good (online) cartography today has much >> > tougher competition and therefore expectations than it had back in 2004. >> > >> > While searching the web for what's happening inside OSM I found this >> > blog post from 2018 written by a longtime OSM contributor, where some of >> > these issues are discussed: >> > https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/ >> > >> > but it seems that not much has happened since, which makes me somewhat >> > worried about the project's future. I don't think we need a revolution >> > or something, but there are some things that need to start moving, and >> > for some of these things the old processes no longer work. >> > >> > /Anders >> > >> > On 2020-11-07 07:52, Tomas Straupis wrote: >> > > 2020-11-07, št, 00:41 Anders Torger rašė: >> > >> However, how important is it that update of the map is immediate for >> > >> every database update? <...> >> > > >> > > OSM-Carto is a style whose purpose is to visualise OSM data to >> > > MAPPERS, do it quickly (fast feedback is essential). OSM-Carto also >> > > has a requirement to be easily deployable by almost anybody on any >> > > hardware. This means that pre-processing of data is impossible as per >> > > requirements (not a design decision). And without pre-processing it is >> > > impossible to have a cartographically sound map. So even while the >> > > OSM-Carto team is doing a terrific job and they do have people with >> > > good cartographic knowledge (like Christopher), but OSM-Carto does not >> > > have such a purpose - cartography. >> > > >> > > We're playing around with a small project striving to comply with >> > > cartographic rules - topo.openmap.lt - some data is updated daily, >> > > generalisation is done weekly. But you already get generalised roads, >> > > buildings, smart lines for waterbody labels as well as text size and >> > > letter spacing. This should get cartographic simplification for >> > > waterways this coming spring (not DP or VW, but Wang-Müller). So this >> > > can be done, but OSM-Carto is not the place to do it. >> > > >> > > Therefore if you want to have a cartographically sound map - you >> > > will need a separate project - separate rendering and stuff. You're >> > > totally right - for general (not mapper) use, minutely update is less >> > > important than cartographically correct representation. And also not >> > > everything has to be generalised, some parts could be updated very >> > > fast, some could be updated weekly or even monthly. Segmentation of >> > > data could also get more attention (re-calculating only the parts >> > > which need re-creation). Such tasks could even push forward topics >> > > which are currently the target of generalisation and multiple >> > > representation group of International cartographic association - I >> > > really think OpenStreetMap has people and capabilities to have a say >> > > there. >> > >> > _______________________________________________ >> > Tagging mailing list >> > Tagging@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/tagging >> > >> -- >> Thanks, >> Seth > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
