[Tagging] Basic cartography features missing, why?

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Nov 8 22:30:30 UTC 2020


This is a nice topographical map, but it isn't serving client-side vector

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 <machyna at 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 <anders at 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 at openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/tagging
>> >
>> --
>> Thanks,
>> Seth
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201108/ca5f65d6/attachment.htm>

More information about the Tagging mailing list