Ideally such stats should also include users who contributed only in changeset discussions and with notes - it would be especially interesting to know if these are primarily a domain of otherwise active mappers or if there is a distinct group of users who primarily engage in discussion only and do not perform edits themselves.

I’ve got the discussion data in the same DB, so it would be easy to run. My impression is that discussions won’t make a big difference, but there are more note-only contributors. Unfortunately, I don’t have notes in a PostgreSQL DB so can’t check this.

Paul did you remove zero-edit changesets?

No. I’d have actually preferred to generate a graph based on user logins or other activity, but for obvious reasons this isn’t possible.

In principle although the choice of a 30 days window is perfectly reasonable as a you have to pick one solution it would be nice to have a more detailed spectrum of the contributor activity w.r.t. frequency

I’d suggest using tms[19] instead of tms[99]. You don’t want JOSM to request the imagery for silly-high zoom levels.

I’d be interested in how the growth of active contributors is per country. This is influenced by both the rate that people join, and the rate they leave. There’s a few ways to define an active contributor, but the contributor terms includes a reasonable one

a natural person (whether using a single or multiple accounts) who has edited the Project in any three calendar months from the last 12 months [and is contactable for a request to vote]

We can’t easily look at a natural person, but having changesets in at least three months over the last 12 months is the type of criteria that’s easily evaluated.

Overall, the growth is linear in the last few years

More specifically, it’s 232 additional active contributors per month, R^2=0.996.

The problem I had when I tried to break it down was

• People who are active contributors overall, but not in any one country
• People who are active contributors in multiple countries
• Migration of mappers

Maybe these don’t matter and you could just use current location estimates for each active mapper, and then break down the list each month.

In addition to Mapbox Streets there are also other styles that use preprocessing. Like OpenTopoMap

I hadn’t counted those lines, but there’s only about 50 there. And of those, only about 10 lines seem to be ones you should run, the rest are a SQL statement that doesn’t seem to do anything.

CartoDB basemaps also use some preprocessing, but not trigger-based like Mapbox streets.

3k lines of preprocessing triggers and other SQL is, in my experience, unique.

In fact you could say through the coastlines all styles make some use of external data preprocessing that is based on additional code

None of them are maintaining their own coastline code, except perhaps to import coastlines into PostgreSQL. I think I counted it where they’re doing that but shouldn’t have, because I didn’t count osm-carto get-shapfiles.sh which is also probably longer than other styles.

Quite a lot of the code complexity in osm-carto is there to work around limitations of the capabilities of the software used

All the styles use PostgreSQL, PostGIS, and Mapnik. I don’t think any of them are making any assumptions about versions, unless they happen to create databases and use the CREATE EXTENSION syntax. I guess some of the CartoCSS styles would also work with Mapserver and magnacarto instead of Mapnik and carto, but no one is targeting that.

many styles use external non-osm data which often essentially means externalizing processing complexity

With the possible exception of CartoDB, they’re not editing the external sources. If they don’t have to edit them, it doesn’t add to the maintenance burden.

I think referring to the workload spread as “unfair” is misleading. “Inequality”, although probably correct from a statistics point of view, is also a word that is associated with discrimination.

I’m not surprised to see power-law distributions. When I looked at overall contributor stats, changeset size, API reply size and several other measures, I saw power laws coming up.

So, it’s basically an editor that just shows you only features with some natural and similar tags?

It’s interesting to call forest grass-covered, since neither natural=wood or landuse=forest implies the presence of grass.

Neighborhood has a formal administrative meaning.

The place tags are for geographic places, not administrative divisions. Sometimes these are the same, sometimes not. For example, a town nearby, Langley, is composed of part of the City of Langley and Township of Langley, which are both administratively cities. A mistake that sometimes happens in the US is to call any incorporated area a place=city.

If we wanted to avoid using British English in tags, we could encode all tags as arbitrary numbers or strings. Except, to someone not working in English, that’s already what we do, because they should see a translation for the presets.

I truly believe that my edits were slowly improving content and they are supported

With repeated requests to permanently ban you after your 3 month ban expired, this is clearly not the view of many others.

Doing a way simplification with a threshold of 0 is unlikely yield any practical speed improvements.

It takes about one to two days to import the planet with osm2pgsql, assuming reasonable hardware. The node parsing stage takes about 15 minutes. It’s unlikely to speed up multipolygon-related computations, the slowest part of the import. It won’t speed up clustering or rendering table index creation.

My guess is that there would be no detectable speed increase.

What area did you use for testing your command, and how long did it take?

Did you load in either the linestring or bbox columns?

What speed drives do you have?

What would be interesting is counts of exit_to without destination and destination without exit_to.

But harder to query.

To see what people would map themselves, we can look at how mapping has progressed in OSM, and how mapping progresses as a new area puts itself on the map without distortions from imports or organized non-local mapping.

From this, we can see residential areas (landuse=residential) and comprehensive building coverage are some of the lowest priorities, but these are regularly the main focus of humanitarian mapping.

There is one sensible way of dealing with highway=path, and that’s to use Lua processing (available in osm2pgsql as well as other tools such as OSRM and tilemaker)

I wouldn’t rule out dealing with it in SQL. It might even be sane, compared to doing z_order in SQL and some of the other constructs.

Just to note, this message was a couple weeks late in getting up.

City and County would like to leverage OSM excellence, yet OSM licensing restrictions make it not feasible for us to use these OSM shapes as our own public reference set

Just to clarify, it is city and county licensing policy and would likely impact any foreseeable license.

Is switching from blue motorways necessary? I realize that blue doesn’t cleanly fit into a yellow orange red scheme, but it’s unfortunate to lose a color which currently doesn’t conflict.

It might be worth looking at http://colorbrewer2.org/?type=sequential&scheme=YlOrRd&n=5 and other options, though blue fits more naturally at the end of a YlOrBr scheme.

California needs a lot of import attention. But the attention it needs is not more imports, it’s cleanup of existing imports, particularly landuse imports.

Having looked at other projects, our conversion and retention rates are reasonable. That doesn’t mean we shouldn’t strive to improve it, after all, many of the accounts belong to people who have shown some interest in OSM, but it’s a fact of life that people sign up for online accounts then disappear.

Mateusz, it is now. With the new CT, everyone agrees to further relicensing without individual agreements.

Yes - and no. It depends on the license. In the case of a switch to public domain, I estimated at one point that >20% of data would need to be removed - basically most non-US imports. There are additional complications with PD, but they’re not worth going into since the chances of a license change removing ~10x the data that was removed in the original license change are approximately zero.

In the case of a switch to an attribution license or different share-alike license, it depends what license. There are many attribution licenses used by third-party sources, and I expect some of them are incompatible with licenses we might consider moving to.

Thirdly, third-party ODbL-licensed data can be imported or used as an external source. This data would need to be removed with any change to the license.

What the CTs mean is that everyone has agreed to a license change process for their contributions.

if they’re modifying OSM data, rendering in into a produced work (e.g. a map) and publicly distributing produced work they have to make the modified database available*. Looking at the NGA atlases they appear to be layering OSM data with other data, not modifying OSM data. There are some minor attribution problems where they’ve mangled the OpenStreetMap name slightly and haven’t provided license information or a link to it.

The same is probably the case with the Sochi maps, but I’m less sure without comparing geometries.

Using ODbL data within a company or government and not releasing anything publicly is allowed by the license. The share-alike obligations only come into play if something is released publicly.

• Or other similar options under ODbL 4.6