Cool work! There is a question, what is the proper way to tag rivers going through waterbodies. With name tag or without, with some addidtional tag or without. There are several schols of thougt there… Bwt, Lithuanian basins: https://openmap.lt/baseinai.html And if you look at our river map https://upes.openmap.lt, rivers through waterbodies are symbolised with dashes (because this is river routing map)

This is what I’m pointing out: check out if mikrosoft has extracted building geometry from a good imagery (they have a record of not using/providing a good imagery) - otherwise adjust it before importing or simply do not import it at all.

Yes, Maxar is also misaligned.

In Lithuania we provide (transform/proxy) official government ortoimagery which is precisely aligned (used by all government institutions as well as professional surveyors). Therefore we can surely trust it :-)

Oh, that’s how newsly works. Yes indeed, newsly did look strange as had a number of very different and very specific topics. Was brought up to me by google alert.

Thank you, I’ve changed the link.

Well, my whole point is that there ARE people (not only me) who would LOVE to add cartography and other knowledge/solutions to OSM (and have already tried to do that), but we CANNOT do that because of the barriers described above.

Could you be more specific as what should I and others have to understand about vector tiles? Given our sandbox https://topo.openmap.lt with all code for this openly on github and a pile of ideas on future improvements. What steps/knowledge of the process do you think are we missing?

And if that is too much to expect - because of programming knowhow (Lua, SQL) - then I would be happy with a contribution on a scientific map generalization workshop or an ICC paper :-).

Sorry, I did not get that. Are you suggesting to write a paper to ICC, or should I (and others) add credit to OSM in our ICC papers/presentations? What’s the deal? :-)

P.S. Writing code is always the least of the problem. Lack of ideas/knowledge/algorithms is a problem.

Again, I’m talking about data SCHEMA and the strategy and rules for SCHEMA, not data. Declaration of schema being random because “world is random” is simply trying to declare a bug as a feature - excuse to do nothing. Creating SCHEMA rules would not mean prohibition of adding new tags or changing existing ones, it should control how/when/which existing tags are changed, where new tags are placed in the topological hierarchy (say landuse=education or landuse=residential+residential=education or landcover=education or whatever)

Exactly. And that’s because OSM has a key-value schema, which you typically want to convert it into a tabular (GIS) form.

This is a technical and irrelevant detail. These two types of representation can coexist and have no influence. You would have to convert osm key-value schema to a usable tabular OR key-value schema to be used professionally.

Neither tabular nor key-value is a “GIS form”. Both can be used for GIS (f.e. PostGIS).

This seems to be a good place to engage yourself. And that what I meant when I said that I’d wish NMA and cartographers could do more.

It is impossible to build something on top of random, unstable schema which lacks any direction, which can and is changing to worse. If we have ETL between OSM data and cartography, then it is no longer OSM and OSM can then easily be replaced with other data with more stable and logical data schema. And if we remove emotions and attachments there would be no practical sense to use OSM for base data (landuse, forests, building, places etc.).

OSM is a “scaleless” database, not a “cartographic” database. Automated generalization like you are looking for does not belong in OSM database. That is something downstream. When I say post-pocessing, I mean that OSM data must always be (post-)processed: first to tabular GIS data, then to further purposes like a (generalized) base map.

Well, that is what I am saying from the very beginning - OSM is currently limited to JUST DATA with no QA for schema.

What is in fact could be enhanced in OSM are tools and map (visualizations) that indicate e.g. completeness. Here’s a shy attempt from some of my students https://eprints.ost.ch/id/eprint/940/ .

Thank you - very interesting and well written article. It would be nice to try it on Lithuania. I wonder if the results would be different if ortophoto would be removed altogether. As other data like landuse, buildings in my opinion should correlate with shop count much stronger than ortophoto data (together with building height mentioned in the article and not mentioned some classes of ways).

However this is all about data which we seem not to have any disagreement. My post was about cartographic research and innovation and what influences that - data schema management.

It tells us, that the OSM data schema is as diverse as reality

It tells us that OSM data schema is random/unstable/illogical and is getting worse. It is as diverse as people changing that schema without any common goal or strategy.

You ALWAYS have to convert it into something usable. Probably a good business case for the likes of geofabrik for raw data ;-)

Another interesting challenge would be to typify, as you suggested.

Typification is one of generalisation operators where you take a number of features (usually of one type) and replace them with one or few to represent the TYPICAL situation in that area as it is impossible because of lack of space to represent all real geometries.

For example to represent an area of small houses (say 50) on a smaller scale you simply display say 10 squares distributed in the same area (displaced from roads, oriented towards the road). Or instead of displaying 100 trees you display 20. Etc.

It is one of generalisation operations which it would be completely impractical to do as a post-processing of data from vector tile on client side. The same with most other generalisation operators, especially the ones requiring knowledge of the surroundings: displacement, road-network-pruning, amalgamation/aggregation etc.

Yes, Eiim, you’re right, there is some amalgamation done.

original:

generalised:

Smaller buildings removed and those close enough grouped (amalgamated) into larger ones. And some apparently non building-specific simplification was used (as square edges have not been preserved?).

Good. But still no typification - the reason I point to typification specifically is that typification although looks simple, is much heavier than simplification because it needs to look at neighbouring objects on different layers (buildings and roads) - which is harder to do with vector tiles as you might need data from neighbouring tiles, you need distance search which needs indexes etc.

P.S. This should NOT be taken as a critique of OpenMapTiles - it is a marvellous product. Generalisation I write about is complex and requires a lot of resources which without some additional research would rise costs more than users would want to pay for such an improvement.

You speak of minimal distances to maintain readabiliy at a certain scale? That is entirely part of cartographic postprocessing.

This is one specific map quality criteria. In that particular paragraph I was talking about whole schema consistency, schema working as a whole not as millions of separate incompatible fractions. Also about goal, strategy, change rules. All of that is missing.

By tags and postprocessed attributes like “class” and “type” (or so) in OpenMapTiles.

I see no building generalisation on OpenMapTiles (on zoom 12 some (detached?) buildings are removed). No building typification and even no building simplification. Maybe I’m looking at some wrong place (https://www.maptiler.com/maps/#topo//vector/13.17/25.35044/54.71288)? And actually… no generalisation of any data (besides DP and SnapToGrid), what am I missing?

My main point is really not to bash NMAs but to say: Don’t expect more from OSM community than what the cartography did not achieve.

Summarising: you’re saying OSM is not for cartography. OSM data is chaotic, unstable but that is fine - c’est la vie. One must do some kind of ETL/transforming to good schema (thus isolate from the chaos of OSM schema) and then do all cartography outside of OSM, maybe with NMA, maybe with non-OSM cartographers/scientists. Well, this is what we currently have anyway and that is the reason for this post in the first place.

For thoughts: to my knowledge most (all?) uses of OSM in professional way are transforming OSM data to some proper schema and then doing serious clean-up/postprocessing (and that is BEFORE doing any generalisation). What does that say about OSM data schema?

When I talk about lack of QA, I’m not talking about technical tools: those do exist and are pretty easy to implement locally. I’m talking about QA on a higher level: there is currently no QA on the changes of tagging schema - schema is changed by a tiny group of people most of whom have absolutely no understanding of the subject matter, no long term goals or strategies. Cost/benefit of change of schema is not analysed which allows changes with high cost and low benefit to go through. This makes tagging schema not only unstable, but inconsistent and at times moving to being less useful from cartographic perspective.

Cartography is pretty sensitive to proper/logic tagging schema - everything is interconnected: say for building typification on small scales we have to turn the building symbol towards the closest way - what is the distance to look for the way? can that be a QA rule for how far a building must be from the road? what type of the building? what type of the road? what is the hierarchy of the road classification? This is just to give an idea of how things are interconnected. You CAN make all those rules work and this makes the schema consistent as a whole, not some heterogenic small pieces through here and there.

Waterbody tagging: large bodies like lakes/reservoirs are symbolysed in a totally different way than rivers and also in a different ways than small waterbodies (basins, ponds and the like). Why are they being lumped up into one pile when they have been correctly separated for years from the very beginning of OSM?

These are just examples, no need to discuss in details here.

Regarding NMA, maybe you have some bad experience. In my experience they understand very clearly that OSM data is already too saturated to simply “dump” ANY data into it. The advantage is using OSM and NMA (or any other) datasets as a complex in a process of updating and QA’ing of BOTH datasets but separately.

“You seem to underestimate the visualization possibilities of Vector Tiles.” - can you give a short description of idea: how do you typify buildings coming in a vector tile? how are you going to FIT that amount of building data in vector tiles in the first place (without typification) say on zoom level 12 in large cities? In my experiments 3-5 years ago pretty decent phones (nexus at that time) were crashing on tiles with 3-5Mb of data.

“Did any presentation of the ICC 2021 or a previous ICC have Vector Tiles as a topic (except “swisstopo Vector Tiles”)?” - yes of course. Vector tiles is not a new technology. New kid on that block is varioscale maps (I’ve only seed one practical implementation of that). Comparing to raster, vector tiles add possibility to adjust symbolisation and switch on/off some layers, they also increase the importance of generalisation (simple DP and snapping to grid which is done because of technicality of VT is far from being enough). Generalisation work stays the same regardless of VT.

Even such slow moving behemoths as ESRI have already implemented vector tiles in their technology and even stopped presenting them on conferences because well… it is not “new” any more.

BTW: it looks we have a very different understanding what “cartographic generalisation” is. I’ve made a new post today with a link to a pretty good (and kind of short) description of generalisation - https://newsly.org/en/Cartographic_generalization-8042826286.

Mateusz, if you create a crappy program it is still programming, but you do not call yourself a “programmer” then. The same with cartography. There might be a problem with information bubble regarding cartography in OSM community. That is why it is good to get out of the bubble: read books or visit conferences (talk to people out of the bubble).

QA is a pretty complex thing and in order to understand it you need at least some experience in IT/GIS which you obviously do not have :-)

And the topic of this post was about lack of cartographic research/science/innovation. You do not go to the conference just to show yet another X, you go to the conference to show something NEW. There is nothing wrong being simply an cheap earth digger, but personally I would like something more.

OSM and NMA data have different purposes, strengths and weaknesses. Combining them can create a great thing. But that is a different (interesting) topic.

Editing OSM is getting harder as you notice that it is a moving target. It is part of the problem which I’ve raised: there is a small number of people who do not understand cartography and are systematically (I’m sure unknowingly) destroying data value (because of a total lack of any QA) which is very demotivating and if you have access to stable data it is hard to convince to contribute to OSM anything more than thematic/specific data. (I personally am contemplating stopping contributing to OSM basemap features in favour of stable and nicely classified NMA data).

Regarding open source projects: have you heard about CartAGen? Open source generalisation package. Made by Guillaume Touya (IGN France), chair of generalisation commission.

Regarding contribution to OSM-Carto. The reason is very simple: OSM-Carto never had a purpose to be a cartographic map (very misguiding name chosen) - and for very well understandable reasons. Kudos to it’s creators - OSM-Carto is a very well made data visualisation for mappers. In order to convert it to cartographic map and thus attract cartographers to contribute - you would have to:

• stabilise the base dataset (remove pointless and sometimes harmful schema changes or introduce some kind of ETL/View to be able to ignore most of schema changes)
• add preparation stage(s) for data generalisation
• (maybe add topology rules)

And regarding the last one - “or to publish a professional map style based on known vector tiles” - I think the magic part of cartography happens while creating those vector tiles, not while colouring them ;-)

I had some contacts with swisstopo regarding their lightbase map. Had an idea of joining their expertise in making the famous SwissTopo map with today’s technologies used in lightbase map, but that direction kind of stalled. And integration of that experience is essential, without it it is just another openmaptiles map. There is much more in cartography than choosing colours. For me any map where smaller scales have not been at least partially generalised are not cartographically sound maps.

I remember the first time I was told that official map data come in different scales, I thought that it is a waste of time and resources - you can calculate everything from the largest scale! But years of reading papers, analysing maps, making maps and talking to other cartographers proved the necessity of data in multiple scales. Well at least to me personally :-) And ironically new technologies like vector tiles are increasing the need of proper generalisation. And this is a different topic anyway…

Well I did mentioned that OSM is used (and mentioned) as a data source in quite a lot of presentations (in general as well as in ICC2021). But that is the problem - OSM is JUST a data source with expected data quality much higher than it really is and I’ve mentioned some reasons for that (as I see it).

But my whole point is that besides data there is nothing being created, invented in OSM which you could present in Cartography conference. There have been some occasional results: Frederiks student(?) has written a paper on collapsing dual carriageway (interestingly coming to opposite conclusion than I did several years before that:-), but again I’m not sure we can count that as “OSM”.

Regarding what cartographers are or are not doing with OSM. Besides the data there is currently no group(s) doing cartography research/inventions in OSM which cartographers could get involved into. I participate in discussions of a commission of generalisation and multiple representation. That group alone is entirely concentrated on automated digital map production. Budgets of national mapping agencies are going down everywhere (well except Switzerland?:-) so all of them are very much interested in automating as much of digital map production as possible. And there are advances in technical implementation (of generalisation operators) as well as theoretical part (my favourite is vario scale maps). There is a discussion of how much quality you want to retain while going to auto mode as algorithms are still lagging behind what human cartographers could do (maybe that is why say SwissTopo main map is being updated manually after automated notification of where and what changes have happened on the ground). But in general cartographers are very much keen on automating more and more of their map production. Currently that stands by different estimates at 60-90%. It is not 100% not because cartographers are “afraid” of automation, but because they have to comply with very specific quality requirements.

If this is the only example you can present, then it proves my point very well.

OpenStreetMap-Americana is just another simple style… Simply changing colours is not cartography. You cannot show this map to cartographers as it is full of standard errors, just as most simple maps (even with it’s very restricted set of object classes being displayed - mainly high level roads - which makes the task much easier).

Mateusz, it is the second message you write claiming that there is something done by OSM on Cartography, but fail to provide SPECIFIC examples. I could be wrong, there might be something hidden in the dark corner, so please shed some light on it. (Credentials are irrelevant, knowledge and effort is essential)

Amanda, you’re missing a point here. We CAN and ARE doing special QA for our country (Lithuania) - no problem with that. What I’m saying is that without a change in the way QA is done in OSM as such, it will remain in the outskirts of GIS as a cheap, temporary and unreliable DATA source without ANY innovation in Carto/GIS. And even data part is endangered with the rise of INSPIRE in Europe and Natural earth globally.

My impressions from ICC is a way to get out of OSM information bubble.

Some papers have been published/discussed in science list, Frederik’s student(?) has published interesting work on parallel road collapsing. But those were just momentary pops. And that’s it, nothing came from that (at least in OSM).

“QA” done by people who have no experience in Carto/GIS/IT is a joke. Can one do a QA of surgeons work? I guess no, even if one has red something about it on the internet but has no experience with it. One cannot READ experience. Number of posts one makes on every possible topic is not experience. Why would that “one” then think that he can do QA for Carto/GIS/IT things?

Can you give examples of what is OSM doing on cartography front?

Yes, procedure of data schema modification does not have any QA. I’ve proposed possible solutions:

1. Commission of REAL professionals with EXPERIENCE declaring a direction/guidelines/QA rules after consultation with community.
2. Then one of:

• commission approves any changes
• commission approves important changes (say does not do anything on bench colour tags)
• commission simply observes compliance with the rules

Main problem here is how to pick the professional commission. Waving certificates or professional experience does not sound feasible.

I’ve mentioned some ICA commissions in original post, but you can find a full list here: https://icaci.org/commissions/

P.S. “wiki proposal” process is a joke. 10-20 random people voting on some wiki is just absurd. It is not professional, it is not quality work, it is not representative. There is no point of even mentioning it.