@Jochen - we don’t know yet how this challenge was created so it is somewhat premature to draw far conclusions but obviously you cannot identify potentially misaligned islands without external data unless you simply put all islands in the challenge which does not seem to happen here. This makes it very different from tools like OSMI or Osmose which focus on internal inconsistencies in the data.

The primary problem is here definitely the person who created the challenge, instructing mappers to align the highlighted island to match imagery which is just a plain wrong instruction here misleading mappers into doing what they should not do (namely aligning the island to what they see in the images without knowing the area, the imagery or the previous mapping work done).

The secondary problem is that those running Maproulette have apparently no system in place to ensure even the most basic level of quality on the challenges posted. At the same time and in contrast to the wiki (which you mentioned for comparison) others have no way to fix problems with the challenges and remove misleading stuff.

And after that there is of course also the problem that some mappers let themselves be lured into following the faulty instructions given and damage the map in a misguided attempt to improve the map. But the responsibility lies with others, you cannot just put a mapper into the loop and then put all the blame on the mapper while you hide in anonymity.

It seems by the way this challenge has been flying under the radar in Maproulette - you don’t see it on the metrics or using the search function, you need the direct link. I wonder where all the people working on this got the info from…

It should be noted that what Bing offer is by far not the best available imagery here - even when ignoring the better black-and-white image offered by Mapbox in this case. Even though the classification of the road is not really identifiable from images, often not even when they are very high resolution, it is generally advisable to have some image as context when you map in an area where you lack recent first hand on-the-ground knowledge.

This is especially important for parts of the world where roads might be seasonal - like winter roads over a frozen lake - not really an issue in southern Sweden but definitely a possibility elsewhere in Scandinavia.

There is no universal recipe to fix this kind of problem. There are many different kinds of mistakes that occur in broken multipolygons and each of them requires a different approach.

Things that are helpful usually with with riverbank polygons:

• make the individual polygons small - don’t make the mistake of fixing things by merging everything into one big polygon.
• decide on which area your polygon is meant to cover along the river
• throw out all members outside this area
• throw out duplicate members (which are in the relation several times)
• assemble a closed outer ring, if necessary drawing new ways or splitting ways
• add all islands within as inner rings
• make sure all tags are on the relation and none are left on the member ways (unless they apply only to them)
• create additional polygons using members previously removed as necessary

This is all a matter of exercise and training but even with a lot of experience this is still tedious work.

But that is not a city in terms of the meaning of place=city in OSM.

In general having settlements of this size not mapped beyond a node is nothing rare in OSM. It was not rare in Europe 5-7 years back either.

Ich meinte das mit der Konvergenz für kurze Distanzen und nicht für lange. Das hängt natürlich dann auch davon ab, was für eine Interpolationsvorschrift man für die Höhenwerte verwendet.

Anstatt den Radius zu variieren könnte man übrigens auch die Höhendaten vorher filtern, hierdurch ließe sich der Einfluss von Rauschen und anderen Artefakten in den Daten vermutlich besser reduzieren als durch einen größeren Radius.

Ein anderer Ansatz wäre, nicht mit einem festen Radius zu arbeiten, sondern für jede Richtung so weit weg zu gehen, wie notwendig ist, um eine bestimmte Mindest-Höhendifferenz zu erreichen.

Hübsch.

Zwei Überlegungen dazu:

• man könnte versuchen, bei der Berechnung als Nebenprodukt auszugeben, welche Sattelpunkte vermutlich falsch platziert sind, also wo der Punkt im Relief deutlich erkennbar nicht an einem Sattelpunkt liegt.

• zur Maßstabsabhängigkeit: Wenn man die Richtung eines Sattels als Funktion des Abstands, in welchem die Richtung ermittelt wird, sieht, konvergiert diese Funktion bei eindeutigen Fällen (korrekt platzierter Punkt in Gegend mit starkem Relief und guten Daten) wohl im Allgemeinen für kleine Abstände gegen einen bestimmten Wert. Bei hohen Zoomstufen wäre es vermutlich sinnvoll, diesen Wert zu ermitteln und zu verwenden. Andersherum könnte man auf diese Weise auch erkennen, wo die Richtungsbestimmung sehr unzuverlässig ist (Wert der Funktion schwankt stark oder weist Diskontinuitäten auf).

Thanks for the writeup and the data.

To me with the two seats that were up for election an interesting observation is the frequency of the different combinations for first and second positions. Even though this is not how STV works (i.e. you do not have two votes for two seats) it still gives an impression what voters would consider the most desirable candidate pairs - or in other words: who would be elected if everyone voted like you.

Obviously Frederik-Kate and Kate-Frederik were the most common combinations. The next most frequent combinations were

• Frederik-Guillaume (not far behind the two top combinations)
• Kate-Darafei (much less frequent)
• Frederik-Darafei
• Kate-Guillaume

The all new candidate combinations (Guillaume-Darafei and Darafei-Guillaume) were equally popular and together as frequent as the last two in the list above.

What you describe is probably in large parts an experience many people with a background in classic cartography share.

Regarding the purple boundaries - this is something a lot of people are dissatisfied with in the standard style, but it is not easy to change. But the good thing is of course that not all OSM based maps have purple boundaries so anyone who does not like them can easily find a map without these.

I don’t think in map design there is a clear division between conventional cartography and OSM regarding what works well design wise and what does not. The main difference are the circumstances - the lack of a central authority, the world wide coverage, the heterogeneity and generic nature of the data and the need for real time updates in rendering for example. In my experience much of the difficulty of conventional cartographers in ‘getting’ OSM is related to the difficulty to comprehend these differences and what they mean.

That looks interesting but if i understand it correctly you are inferring the hydrographic network from relief data at least initially without any confirmation that a waterway actually exists there.

May i advise a bit of caution here. If you cross check with imagery afterwards that is fine (and having a pre-generated network to start with is probably very useful). But without any visual confirmation this can lead to pretty large errors like here:

http://mc.bbbike.org/mc/?lon=142.895006&lat=52.311073&zoom=14&num=3&mt0=bing-satellite&mt1=mapnik&mt2=mapbox-satellite

Even in areas where no high resolution imagery exists this can be avoided by using available images.

World map projections with a split not at 180 degrees longitude - as BushmanK suggested - are a special difficulty - better to start with the basic version here. That should not be a problem - unless your rendering setup really sucks.

Regarding the map itself - looks like quite a clear case of regional bias. The extreme emphasis on sub-saharan Africa is most obvious - but even apart from that this is clearly not a map showing the most serious objective needs for mapping across the world in the past years.

@geri-oc

Der Normalfall im ländlichen ist halt, dass ein Zufahrtsweg zu einem Hof, oft asphaltiert und primär nicht landwirtschaftlich genutzt, daneben auch als Zugang zu angrenzenden Feldern und Wiesen dient. Das ist dann m.E. highway=service aber definitiv kein service=driveway.

Zu Flächen - nur weil eine Fläche asphaltiert ist und an eine Straße grenzt wird sie damit nicht zu einem highway=service. highway=* in OSM ist allgemein ein an der tatsächlichen Nutzung orientiertes Tag und keine Beschreibung des Oberflächenzustands.

Das liegt natürlich auch ein bisschen daran, dass es für solche Mehrzweck-/Abstell-/Lagerflächen keine etablierten Tags in OSM gibt - insbesondere für das Mikro-Mapping von Fabrik-/Betriebshöfen und Ähnlichem fehlt da ein strukturiertes Konzept.

Gute Punkte.

Bei service=driveway wäre daneben auch ein Ausschluss-Kriterium, wenn der Weg neben der Funktion als Zufahrt zu einem Grundstück auch als Zufahrt zu angrenzenden Nutzflächen wie Acker, Wiesen oder Waldstücke dient - selbst wenn es dafür keine weiteren Abzweigungen gibt.

Ein weiterer häufiger Missbrauch von highway=service liegt daneben bei der Verwendung auf Flächen mit area=yes vor. Dies wird verbreitet als allgemeines Tag für asphaltierte Flächen verwendet, ist dafür aber nicht da, sondern nur für Bereiche, die primär dem bewegten Verkehr dienen und nicht für Flächen, die hauptsächlich zum Parken, Abstellen oder zur Lagerung von Dingen dienen.

One thing that might make sense to consider in the long term how it can be better communicated that intensive organized users of the Overpass API need to set up their own instance or buy commercially run services for this - in a similar way as with the tile servers. You indicate that a large part of the load comes from small distributed users but likely lightening the load from volume users would probably improve the overall situations none the less.

One thing i noticed recently that a common use task i have for overpass (usually via overpass turbo) is querying occurrence of fairly rare tag combinations of tags with individually widespread use. This seems to be a fairly hard thing for overpass to do - i frequently get errors (something like out of memory IIRC).

And if there are limits to the growth of OpenStreetMap in sight, then these are most likley the size of mankind.

This is probably right as far as growth is concerned but i think maintaining the data and keeping it up-to-date is a different story because it does not necessarily scale with the number of people involved but more with the intensity of their involvement. See also the musings of Alan McConchie on the matter.

As indicated the language problem is hard, esp. for subjects like writing, community building etc. It might be an option to include local chapters in it - like having a global nomination process but also allow the local chapters to additionally nominate a number of candidates.

If selection is made by a committee it would likewise be an option to put together this committee at least partially from local representatives.

Since the problem of comparing activities in different languages and from different cultural backgrounds is often inherently unsolvable it might also be an option to make the awards non-competitive across languages - meaning each category would have a winner for every language there are nominations in. This of course would only work for categories where a language can be clearly identified for each nominee like writing - mapping for example can be but does not need to be language specific.

The ‘comet tail’ effect - could it be that this has something to do with the order in which map frameworks requests the tiles as you change the view?

Übrigens enden Höhenlinien auf professionellen Karten durchaus auch mal im Nichts, wenn zwischen Detailgraden gewechselt wird.

Um da mal wieder Eduard Imhof zu zitieren:

Trotz dieser Vorzüge sind solch ineinandergeschachtelte Kurvensysteme nicht zu empfehlen. Sie sind zu schwer lesbar, zu wenig anschaulich. Alle Geländeteile, ob steil oder flach, erscheinen in solchen Karten fast gleichmäßig mit Höhenkurven gefüllt.

Was eher geht, ist in flachen Gebieten einzelne Zwischenkurven einzufügen, die man in steileren Bereichen weglässt. Auch das geht aber nur, wenn diese in der Darstellung deutlich abgegrenzt und dadurch auf den ersten Blick identifizierbar sind, zum Beispiel durch Strichelung - Verwendet ist dieser Ansatz zum Beispiel hier.

Eine gute Auswahl der Gebiete, wo man Zwichenkurven darstellt und wo nicht ist aber ziemlich schwierig (zumindest wenn das irgendwie auch performant sein soll). Und das ganze kann auch sehr schnell unübersichtlich werden.

Wenn ich mir die Höhenlinien bei euch anschaue sehe ich Einsparpotential eigentlich eher im Flachland, wo vermutlich mindestens 2/3 der Datenmenge Rauschen ist wie hier. Aber natürlich ist die Hauptmenge der Daten im Gebirge und letztendlich sind die 10m-Intervalle dort bei SRTM-Datenbasis weitgehend redundant (d.h. könnten im Prinzip aus den 20m-Linien fast perfekt interpoliert werden).

Im Grunde ist ja auch das Speichern der Höhenlinien in einer PostGIS-Datenbank ziemlich sinnlos, denn sowohl produziert als auch verwendet werden sie ja immer in Kachelform.

Not sure if you do this as a helper tool for mapping or for data use.

For mapping this works nicely - have done this as well a few times for long and winded riverbank polygons because i was too lazy to draw the centerline by hand. Would be useful as a JOSM plugin by the way.

For data use as a preprocessing step for missing data? Forget it if you want to process things globally - unless you have a real lot of computing power to spare. Skeleton algorithms generally scale poorly with polygon complexity, generating skeletons for big polygons is slow.

Be careful here not to confuse progressive data representation and mapping strategies with fractals.

Fractals are characterized by self similarity and fractal shapes in physical reality are commonly the results of a self-organization process. This is widespread for natural shapes but is very rare for human generated structures. What you describe above is a progressive approach to mapping things, starting with a crude representation, both semantically and geometrically and refining it step by step. There is nothing fractal about this, there is commonly no similarity between either tags or geometric forms between different levels of refinement.

And it is not the fact that the coastline is longer when measured on a finer scale that makes it fractal-like, it is the fact that the relationship between scale and measured length has a simple form (power law) across a wide range of scales that causes this - see here.

I think i made it pretty clear that the primary purpose of this is to increase awareness that such imagery exists and can be used in the hope that this prevents mappers from wasting their time with 15 year old images in Bing and Mapbox. This happens to apply mostly to remote areas. The availability of up-to-date open data satellite imagery however is not limited to those areas.

Another advantage is to have up-to-date imagery for every part of the world, up-to-date here usually meaning a few weeks old, in difficult cases sometimes a few months. Age of high resolution imagery in Bing, Mapbox or from local government sources is usually at least about 2-3 years. I think i demonstrated this quite clearly with the Panama and Vostochny images.

And yes, most use of maps and most mapping takes place in crowded areas but where maps are most needed are usually the less crowded parts of the world. Or in other words - in a European or North American city a map is a luxury, in the remote parts of the world it is frequently a necessity.