My interpretation of that stated goal would consider not only current mappers. But also potential and future ones. Enabling people to contribute, where it was in some way blocked before is a good thing.

Ok, but my question still would be: Is that your personal stance or do you have the impression that this is a guiding principle for the project in total? Because from my perspective this makes a fairly huge difference, especially if you go beyond just enabling people to contribute in principle towards enabling people to accurately document their local geographic knowledge.

And affirmative action was meant simply to describe any proactive measure taken to counter a systemic bias or discrimination, it is not limited to specific criteria of discrimination. If that is good or not can be debated. I was just interested if iD development in general considers this part of their approach to making decisions about tagging presets or not.

Right now I am struggling to find cases where these two metrics would conflict.

Well - if you go via numbers, especially under the stated premise of

Our primary aim is to serve the needs of iD mappers

then the utilitarian target would be to create presents that can be most widely used by the demographics de facto using iD at the moment in the geographic and cultural context where they map.

If, OTOH, the goal is to serve the OpenStreetMap project as a whole, to create a world wide collection of local geographic knowledge, the relevant demographics would be the potential world wide mappers, not the (currently very non-representative) subset of those currently mapping with iD.

Concrete example would be tower:type=minaret vs. tower:type=bell_tower. These are both in iD presets, but by most of the criteria documented by iD the arguments in support for tower:type=bell_tower are much stronger than for tower:type=minaret.

The point in your PR of how often it could be used touches that matter - but it leaves it unclear to what extent this is meant to endorse affirmative action and to what extent that is actually practically guiding decisions.

To be clear: My comment was not meant as a critique of iDs decision making practice. Doing that in a meaningful way would require a more in depth look than what can be done in a diary discussion. I was mainly interested in learning about your impression on the topic.

Thanks for the report.

I am wondering if you could share your impressions of the de facto decison making principles in iD regarding support for certain tagging ideas and regarding how tags are framed to the user.

The documentation lists a number of criteria, but there are clearly cases where these are not the primary basis of decisions. And there are also criteria and goals that are notably missing from the documentation - like the support for geographic and cultural diversity as opposed to just summarily maximizing data quality in an utilitarian sense.

Given you have now made such decisions in quite a few cases and interacted with decisions of others in many cases as well you are in a unique position to look at how iD works in that regard and i would be very much interested in how you perceive that.

If you just want to vent hate, then please take it somewhere else.

@Mxdanger - I am going to make sure you get you money back.

OSM-Carto is a volunteer project. Work only gets done when someone invests their time into it based on their priorities. Telling all the OSM-Carto contributors collectively that their priorities are messed up is - to put it mildly - self defeating.

Might be of interest: I wrote more extensively on the current state of coastal mapping in OSM and how it came to be the way it is in 2023.

Are these going to be (and did you get for Namibia) full map sheet scans?

This might not seem overly relevant for OSM use but for the value of such data as a record of cartographic history the information on the map sheet rims (like data sources used, specification of map sheet edition etc.) is of immense value.

You have not even mentioned the more fundamental issue with comparison of different classification systems - that they always re-cast one classification into another and this way create an inherent bias. And when comparing OSM data it is always the OSM classification that gets re-cast into the other one - with the inevitable losses in semantic accuracy.

W.r.t. ground truth sampling as the gold standard for quality assessment - that is only the case if you actually use true unbiased random sampling. And i have yet to find a single such study that does this. Most studies do not even document the method of selecting sampling locations and hence qualify as pseudo-science (for global analysis for example: picking a uniformly distributed set of random sampling locations is non-trivial - not to mention that ground checking a truly random set of sampling locations is very expensive). By manipulating the sampling, even in a subtle way, you can essentially freely modify the results of such a study.

There are two persistent urban myths w.r.t. boundaries:

• Boundaries are universally defined in some abstract coordinate space and stay there irrespective of changes in the physical world.
• Boundary data sets published by public authorities invariably represent objective truth about boundaries.

Both of these are wrong.

Many (if not most) boundary data sets published by authorities are generalized approximations.

Most international boundaries world wide that follow a physical geography feature (either a river or a watershed divide) are legally (by agreement between the countries involved) tied to that element (Using formulations like: From A to B follows the course/centerline/left side/right side of the river X). Often a more explicit specification of the boundary is done (and demarcated) by a boundary commission, sometimes subject to regular revisions.

What counts in OSM is of course in any case only the line of de facto administration - which is usually well verifiable for international (admin_level 2) boundaries but increasingly non-verifiable for the higher admin levels.

In my experience most mappers treat higher level administrative boundaries as abstract artefacts and ignore them when editing other data and do not connect them to other geometries even if they are functionally tied to them.

While it is nice to see practical instructions involving basic mathematics are given, this is, unfortunately, so wrong on the mathematics that i don’t want to let this stand uncommented.

Drawing an accurate circle on a map is hard - others have struggled that before. Turf.js does it right but the code shown here does not and does not provide meter-accuracy in the general case.

Here a python code verifying the accuracy of the circle by calculating the distances of its outline points to the center - with the inaccurate version in projected coordinates shown here and the more accurate version based on what turf.js does.

#!/usr/bin/env python3

from math import *

lon = 12
lat = 50

earthRadius = 6378137

radiusInMeters = 100000

steps = 64

# https://stackoverflow.com/questions/4913349/haversine-formula-in-python-bearing-and-distance-between-two-gps-points

def haversine(lon1, lat1, lon2, lat2):
    """
    Calculate the great circle distance in kilometers between two points 
    on the earth (specified in decimal degrees)
    """
    # convert decimal degrees to radians 
    lon1, lat1, lon2, lat2 = map(radians, [lon1, lat1, lon2, lat2])

    # haversine formula 
    dlon = lon2 - lon1 
    dlat = lat2 - lat1 
    a = sin(dlat/2)**2 + cos(lat1) * cos(lat2) * sin(dlon/2)**2
    c = 2 * asin(sqrt(a)) 
    r = earthRadius
    return c * r

print ('== incorrect ==')

for i in range(steps):

    angle = (((i * 360.0) / steps) * pi) / 180

    dx = radiusInMeters * cos(angle);
    dy = radiusInMeters * sin(angle);

    newLon = lon + (dx / (earthRadius * cos((lat * pi) / 180))) * (180 / pi)
    newLat = lat + (dy / earthRadius) * (180 / pi);

    print (haversine(lon, lat, newLon, newLat))


print ('== correct ==')

for i in range(steps):

    angle = (((i * 360.0) / steps) * pi) / 180
    
    drad = radiusInMeters/earthRadius
    lat_rad = lat * pi / 180
    lon_rad = lon * pi / 180

    newLat = asin(sin(lat_rad) * cos(drad) + cos(lat_rad) * sin(drad) * cos(angle))
    newLon = lon_rad + atan2( sin(angle) * sin(drad) * cos(lat_rad), cos(drad) - sin(lat_rad) * sin(newLat) )

    newLat = newLat * (180 / pi)
    newLon = newLon * (180 / pi)

    print (haversine(lon, lat, newLon, newLat))

Yes, that is one example where this change is important. Note, however, that vehicle=destination and access=destination + foot=yes are semantically very similar. The important point is that mappers should be free to choose the tagging variant that is either more convenient or more accurately describes the situation on the ground, OSM-Carto should not try to nudge them in one direction or the other. With this change we got a lot closer to accomplishing that.

You should note that all of the tags you mention (except for place=farm) have been discussed on the OSM-Carto issue tracker in some form in the past. You can find the issues where this happened/happens by searching for the tags there.

You make some good points why introducing people to mapping in OSM initially through in-the-field surveying is the best approach and i would also say that this is the most natural and intuitive approach that also best communicates what OSM is primarily about (local knowledge, in particular the stuff you can’t see on imagery).

But i think there is also some disadvantage to a mobile device only approach.

Connecting to the wider OSM ecosystem - communication channels, documentation, data sources of various kinds, maps - tends to be much less natural and convenient on a mobile device than on a larger screen with keyboard and mouse.

Regarding multilingual diary entries - i think having all in one is the more inclusive approach here - otherwise discussions in different languages will get segregated - which is not of benefit.

What do you think is the reason for that? It’s a bit strange for me, because the emptiness of the standard map style is the problem which all are complaining about since OSM appearing.

I think the reasons are complex and consist of OSM specific reasons and ones that more broadly originate in social mechanisms in FOSS development in general.

OSM-Carto has the additional difficultly that it wants to be real time updated - which puts substantial additional constraints on the methods that can be used.

Just a question, maybe you know the answer. Can the Discreet Isolation algorithm work on global datasets by itself?

I have not looked in more depth into optimization of these methods. This depends a lot on the exact use case and the method used. If you are practically ok with limiting the maximum distance to consider you can use spatial indexing to limit the number of pair relationships to analyze. Specialized tree structures combining the spatial dimensions and the semantic dimension (like elevation, population) could be even better.

But also keep in mind that distance calculation is relatively cheap - so 10^12 of these is not necessarily a reason to invest a lot of effort into setting up complex algorithms and data structures for optimization.

Been there, done that (in 2015):

https://imagico.de/map/osm_populated_en.php https://imagico.de/maps/#map=5/54.111/46.538&lang=en&l=veg&r=pplaces&o=3&ui=8

The resonance for innovative map design related methodology development receives in the OSM community is often very limited. The most substantial public recognition the above received was from outside OpenStreetMap:

https://link.springer.com/article/10.1007/s42489-021-00079-y

Still trying to understand your overall tag interpretation reasoning: It seems to me that your aim is ultimately to interpret all combinations of tags as what they most likely are meant to indicate within the classification model of your style, independent of how rare they are and how much more common a different tag combination is to indicate the same thing. That is surely a valid approach to map rendering. It, however, to me seems (a) difficult to understand for the map user, because the meaning of a certain design (like the pattern for natural=sand + wetland=tidalflat) is not documented anywhere and the aggregation of very different tag combinations into a common design is not always intuitive and (b) pretty hopeless to maintain, because the number of two tag combinations (and even more if you also interpret three tags together - which you do in some cases i think) with at least 22 occurrences in the database is quite exorbitant.

Regarding your numbers and interpretations - i assume these are for your map coverage area (UK and Ireland). Globally wetland=swamp and wetland=mangrove have a much higher significance (in numbers, but especially also in area covered). wetland=tidalflat might mostly be mud in the UK - but globally it is not. As i explained recently natural=wetland + wetland=tidalflat is by most mappers considered predominantly a geomorphological classification.

Your interpretation of different wetland tags also does not seem to fully be as indicated. Example: osm.org/relation/5320809 - the tag combination in question, wetland=saltmarsh + surface=mud has world wide 48 occurrences.

I am often wondering about your reasoning for the tag interpretation you use. For example you are now endorsing the tag combination natural=sand + wetland=tidalflat - see for example osm.org/way/249534182 - which has 22 uses world wide, with a rendering distinct from both natural=sand and natural=wetland + wetland=tidalflat while you do not support in a similar fashion the substantially more widespread (but of course equally semantically weird and quite definitely non-consensus) combinations natural=grassland + wetland=wet_meadow (68 uses world wide) and natural=grassland + wetland=marsh (69 uses world wide).

Another note on your drawing of rivers in “the actual width of a small river” at high zoom levels: Be aware that even within the limits of the UK (~50-60 degrees latitude) the drawing width you use at z20 varies between about 3.35m and 4.31m. This is relatively easy to avoid by calculating the scale factor within SQL and using that to determine the drawing width. A generic way to do this can be found in

https://github.com/imagico/osm-carto-alternative-colors/blob/master/sql/map_functions.sql#L40

If you are fine with being limited to mercator projection maps you can of course also do this analytically (which is much simpler and also likely faster).

Tagging consistency of wetland=bog is also a serious issue by the way - it is widely used as a generic peat producing wetland tag rather than specifically for low nutrient acidic rain fed wetlands.

It seems to me for example what is imported in Norway as wetland=bog (which comes from a generic ‘mire’ classification in the source data) includes both fens and blanket bogs.

My guess is also that blanket bogs are likely to be frequently tagged natural=grassland because grass is often a significant (and visually dominating) component of the vegetation. And this practically can even be a more meaningful characterization in OSM because many of these will be perfectly walkable (as you’s expect from natural=grassland) while natural=wetland + wetland=bog often is not.

Very interesting read.

I am not too sure about the idea of supporting the extension of natural=heath beyond woody vegetation (i.e. using it for blanket bogs and other habitats with predominantly non-woody plants). I know this is pretty widespread practice - also outside the UK (see for example here) - but it kind of reduces the natural=heath alone to a rather insignificant meaning.

This is of course partly because the alternative in many cases (like for bracken) would be using natural=grassland + grassland=* - which in case of non-grass vegetation does not feel right to many mappers either.

So ultimately your approach might be the right one - just pick a reasonably intuitive secondary tag for the primary tag that happens to be most commonly used for the feature in question anyway (for whatever reason that might be) and establish that as the tagging to use. But in that case it would be important to have secondary tags for the full range of uses of the primary tag, in this case heath=* values for the common cases of heath in the strict sense, i.e. dwarf scrub habitats. Unfortunately neither for natural=heath nor natural=grassland secondary tags are well established so far.

Well - evidently OSM-Carto has a huge part in encouraging (ab)use of the name tag as a generic label tag by labeling the tagged name (any in many cases only the tagged name) on almost everything no matter if it is common for the type of feature to have a name in the strict sense.

But at least for amenity=atm OSM-Carto is not at fault (because it has been labeling ‘operator’ since adding ATMs in 2015).

Regarding cultural bias - i have made the experience that the distinction between the abstract concepts of a name, a brand, an operator or a description and the broader concept of a label is difficult for many to make. We (as technically minded western Europeans) think of the name as a more or less unique identifier for a specific individual feature (unique at least on a regional level, in many cases beyond that - and if not we like to add additional qualifiers, like Freiburg im Breisgau). But for many the name is just what we use language-wise to refer to a specific feature, like I visited place X and i stayed at the Holiday Inn or I will go buy some stuff at Lidl - which we would classify as a label. In principle i think a good solution might be to actually have a label=* tag meant broadly for any string that is used locally to refer to the feature in question while the more specific existing tags retain their more specific meaning for any mapper who wants to and is able to tag in a more differentiated fashion. This would allow data users to select the most specific form of information they need available but have the less specific data as a fallback.

Regarding landuse=residential - it is a fairly common practice to tag landuse=residential + place=* + name=* for smaller settlements or suburbs/neighborhoods. See https://taginfo.openstreetmap.org/tags/landuse=residential#combinations