You are right about design concepts from printed maps not being directly transferable to digital maps but i think you are wrong about the primary reason being different capabilities in color representation. This offers additional possibilities for digital maps (although designers often lack experience with color perception to put them to good use) but it does not prevent traditional techniques from printed maps to work on screens.

What makes many classical map design techniques unsuited for digital maps is the lower resolution of display devices. This problem is somewhat reduced with newer high resolution mobile devices but since hardly any map style is designed exclusively for those it is still a very widespread and fundamental problem. I discussed this in context of patterns some time ago but it also applies in many other areas, in particular with dense line features like contour lines, rock hachures etc.

So yes, blindly copying techniques known from printed maps to digital map styles with the hope they just work is a bad idea. But classical design can still offer a lot of useful ideas. And a limited color set map style can work very nicely in display use

http://taginfo.openstreetmap.org/tags/addr%3Ahousenumber=300 http://taginfo.openstreetmap.org/tags/maxspeed=300

Auch erwartet hab ich

http://taginfo.openstreetmap.org/keys/300

aber erfreulicherweise…

That looks like a good idea. In general waterway mapping in India is already pretty extensive but the big ones are generally poor in terms of riverbank mapping. This especially applies to the NW1 and NW2 here.

One big problem in India is that water levels and therefore the extent of the rivers varies enormously between dry season and monsoon season. Mappers need to be aware of this - otherwise you get results like here:

http://mc.bbbike.org/mc/?lon=94.710759&lat=27.337791&zoom=10&num=2&mt0=bing-satellite&mt1=mapnik

Yes, they are encouraged to map the features that MSF needs, but what MSF needs is simply base map data. We need roads, residential areas, admin divisions, health centres, schools, water points etc etc. I do not quite understand where the inferred conflict of interest lies….

It has been my observation that the failure to recognize that the interests and goals of their organizations and projects do not fully overlap with those of the OSM community is a reoccurring issue with many representatives of organizations in the field of humanitarian mapping. IMO realizing that while there certainly are common interests there are also always significant differences in goals is the key to a successful cooperation.

I think volunteer mapping projects organized from outside the OSM community like this should in many aspects be subject to the same considerations as paid mapping projects by companies, in particular there needs to be an organizational responsibility for the mapping activities of those who map under the instructions of these projects. This also touches the transparency issues brought up by @woodpeck and @SimonPoole since ultimately those who should be accountable are those who pay for these projects.

Side note: you should realize that the slogan putting the world’s vulnerable people on the map is quite ambivalent on a number of levels.

That is in line with the Active contributors per month on:

osm.wiki/Stats#Contributor_Stats

and No. of active members last 30 days on:

http://osmstats.neis-one.org/

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 - like with one week, 30 days, 3 month, six month, year. Data we have here right now is:

• one week: ~10k
• 30 days: ~25k
• year: ~150k with ~50k recurring

which indicates a significant number of users who contribute regularly but less often than monthly.

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.

Thanks for the replies.

I am aware that the work of the Mapbox data team is quite diverse and also consists of lower volume activities like fixing errors etc. The tool you introduced here however does not reflect this and showing the edit volume without differentiation could give the impression this is what counts most.

The only specific suggestion i would have regarding your data team work is to put weight on local knowledge, that means preferably let mappers work on areas they are familiar with and have them familiarize themselves sufficiently with areas that are less known to them.

One very basic thing Mapbox could do to better support community mapping is to provide capture date metadata with your satellite imagery. This has already been requested several times i think and would enormously improve ability of mappers to properly assess their image sources.

I wonder if this is your primary method to evaluate the work of your mappers and if not what your primary method is and what role this tool plays in your data team controlling.

The shown numbers in the order of 10k-20k changes per day are only achievable with fairly mechanical tracing work - in this case mostly buildings. If you do the math 15k changes in an 8 hour day gives an average of 2 seconds per change or 10 seconds for a simple rectangular building. This might not seem too bad but it essentially contains very little room for mapping any more complex semantic information or doing higher level verification work (like cross checking with different image sources).

In principle i think this kind of mapping work is somewhat questionable in its overall value. The primary data that would be required to automatically acquire this kind of information (high resolution orthoimagery or LIDAR data) might not be readily available right now and existing building outlines for the area might not be available as open data but having this building data in the OSM database - even if valuable for practical applications right now - has relatively little lasting value in the long term compared to classical on-the-ground mapping.

So to get back to the starting point - from the perspective of the OSM community it would be important to evaluate your data team mapping work w.r.t. the long term sustained value of the data for the project. It is perfectly understandable and legitimate if Mapbox also has short term data needs and tasks its mappers to fulfill these but you should always keep in mind that 10k features mapped in that context are of a different inherent value than 10k features mapped by a local mapper walking the streets and mapping addresses, trash bins, fire hydrants, addresses and all kinds of other stuff in addition to the plain building outlines.

Bei Messzügen gibt es übrigens wohl auch ‘ne hochwertigere Variante:

http://www.mermec.com/diagnostics/tunnel-inspection-/82/1/t%E2%80%A2sight-5000.php

;-)

Für die Aufnahme in seitlicher Richtung ließe sich die Bildqualität durch eine lichtstärkere Optik und entsprechend kürzere Belichtungszeiten vermutlich steigern, die Frage ist dabei natürlich in wie fern das für die manuelle Auswertung überhaupt einen Gewinn bringen würde, d.h. ob sich das mehr an Informationen mit vertretbarem Aufwand auswerten ließe.

I can’t say much about the visual inspection without knowing the exact procedure but there are a lot of things you can do wrong here and introduce bias. Since many countries do not have full high resolution satellite image coverage available i don’t even think random sampling is possible.

And you always have other systematic errors when doing assessment based on satellite images. For example in heavily forested areas (like Brazil, Canada, Russia) you underestimate the actual number of smaller roads in rural areas so you overestimate completeness.

Cases of probably quite significant overestimates are for example Libya and Chile.

Without knowing the details of the methods used not much can be said here but it seems unlikely you can make such estimates without pretty hairy assumptions regarding the distribution of roads in countries (both spatial and in terms of road types) or the pattern how roads are mapped in OSM.

That being said the results seem to overestimate completeness in many cases, especially for larger countries with limited and localized mapping, probably because you interpret saturation effects in urban road mapping as a sign for overall completeness.

The good thing about this is that overestimation of completeness is going to be much easier to falsify. So if you stay with the 90% completeness estimate you are likely to be proven wrong relatively soon…

The Import Guidelines already contain a remark concerning this:

osm.wiki/Import/Guidelines#Consider_simplifying

Of course CanVec - the scourge of OSM…

Yes, JOSM does it correctly, if you do it like JOSM you should be fine.

That is a very nice video, especially in the beginning where it explains the core of what OpenStreetMap is about, i.e. people mapping their environment and sharing their knowledge of the world with others.

I want to point out however that the narrative that both OSM and HOT are about creating “a free map of the world”, which also was mentioned several times in recent discussions in some form, is not really correct. For me as someone who has mapped primarily in those areas in OSM that are probably most distant from this potential goal this seems pretty clear. For OSM the map of the whole world would be the ultimate conclusion when everyone on earth has become a mapper and is contributing his/her knowledge to the OSM database. But this does not make it a goal of the project, OSM is about the process of collecting data and sharing knowledge.

And for HOT the map of the whole world seems to be no goal either, HOT is about generating free map data where map data is needed, either actutely in case of a desaster/crisis or prophylactically where it might be needed in the future. In any case HOT mapping is generally based on data needs by specific interested parties (that is mostly the aid organizations HOT cooperates with). And these parties generally do not have a need for a “map of the world”, there are huge parts of the world, both geographically and thematically, they have no interest in at all.

One problem of NHD as well as other waterbody imports is that river/stream classification is often either off or completely missing and this is often very difficult to assess properly from imagery alone.

Your observations re. accuracy comply with what i experienced with NHD data. This is very variable, both in terms of positional accuracy and age of the data. In some areas NHD data is clearly very old (probably 1950s-1960s).

With your ‘data efficiency analysis’ - make sure when you apply this worldwide you take into account projection distortion, otherwise you probably end up with very wrong results at high latitudes.

JOSM could by default offer a scale independent simplification (using the node density along the line to set the simplification threshold).

I suspect one major problem of your methodology is that quite a few mappers start off with either a remote mapping changeset (which does not necessarily have to be part of a HOT project etc.) or mapping in a location away from home (during vacation for example). This will probably not significantly affect numbers for countries like Germany or the USA but it will likely overestimate the number of mappers in countries with a low number of mappers.

There are two important things you analysis misses i think:

• In addition to Mapbox Streets there are also other styles that use preprocessing. Like OpenTopoMap In fact you could say through the coastlines all styles make some use of external data preprocessing that is based on additional code. This is of course the same for all styles.
• In addition code complexity is largely influenced by the feature set offered by the underlying software. Styles vary in what versions of the various tools they require for example and if they use custom extensions (like for PostGIS). Quite a lot of the code complexity in osm-carto is there to work around limitations of the capabilities of the software used.
• many styles use external non-osm data which often essentially means externalizing processing complexity.

Small recommendation: if you show images of non-urban areas for educative purposes it usually helps to include a scale bar.

In general node distance only tells one side of the story since there are fairly straight roads that require few nodes for accurate representation and curved roads that would be extremely inaccurate with the same node density. So it is usually best to also look at the average derivation angle at the nodes, see here for an example for that.

By the way - is that spherical/ellipsoidal distance or in mercator meters?

General roads look quite fine now. Would be even better with the brighter farmland of course. ;-)

The new pedestrian color you tried looks very close to landuse=residential.

I am worried about collision with water.

I don’t think that’s a problem as long as you keep it bright enough and on the reddish side of blue - water color is quite greenish.