OpenStreetMap

imagico has commented on the following diary entries

Post When Comment
The invalid areas of the map 5 days ago

The most important measure to reduce the number of broken multipolygons would probably be to have the standard map style not render broken MPs, at least not those with serious errors. Of course if the editors do not complain and refuse to upload and the map does not render this is very confusing and frustrating for mappers so editors would also need to be diligent. Since JOSM allows editing multipolygons without downloading them in full (and it needs to - otherwise you could not edit some of the larger MPs) this would be difficult.

The error map also nicely shows my favorite

http://osmlab.github.io/fixing-polygons-in-osm/map/#10/18.9464/32.2650

probably the most broken MP existing. Here (and in quite a few other cases as well) it is fairly pointless to actually fix all the errors since newly mapping the feature in question is not much more effort and will also improve the map. Lots of errors frequently go hand in hand with poor mapping.

Layout Managers and Trigonometry 9 days ago

I was referring to the consistency in colors. On a very precise level this would require calculating diffuse radiative transfer but on a more basic level this is only about direct lighting. Since everything - at least in a daylight situation - is illuminated by the same light source, the sun, there are certain constraints on how surfaces can appear relative to each other. In typical osm2world renders surfaces frequently appear under different lighting conditions and relative to each other in ways that would be clearly impossible for a real world material. I don't know the osm2world internals so i am not sure if this is just the material definitions being off or if there is something wrong on a more basic level in the rendering pipeline (like in converting the calculated radiances into pixel colors of the final image).

Google Summer of Code 2016 - improving openstreetmap-carto 12 days ago

As you know z5-10 is fairly hard to significantly improve without preprocessing data.

Regarding print maps for comparison - you can find a lot of historic maps on

http://www.lib.utexas.edu/maps/historical/index.html

Good contemporary general purpose maps at these scales are quite rare - some atlases might provide fairly good examples although there is not much progress in technical aspects and overall quality in the last 20 years or so in those.

The range of scales we are talking about here is from about 1:20M (z5 at the equator) to about 1:200k (z10 at about 70 degrees) - towards the latter you will also find a lot of examples among national mapping services.

But keep in mind that not everything that works well in print is equally suited for a digital map.

What's up with the Rann of Kutch? 17 days ago
  1. I would tag as natural=water + seasonal=yes/intermittent=yes areas that are water covered on a regular basis for a significant part of the year. Areas with flooding only for a short time (a few weeks after heavy monsoon rain or during storms near the coast) should probably not be tagged this way. I would tag as wetland other areas that are neither flooded (standing water) nor dry for a significant time of the year. If they are also dry for parts of the year seasonal=yes seems appropriate (that is probably always the case in this area except for the tidal wetlands). I would tag as wetland=saltmarsh those of these wetland areas which have at least some vegetation cover (i.e. not completely bare mud flats) and which are a salty environment during the time they are wet. Lacking local knowledge in the area i cannot really say to what extent this applies but it seems to me there is significant local differentiation here. In lack of further information i would probably tag what appears in bright cyan in my false color images natural=water + seasonal=yes. I am unsure if it makes sense to have combined mapping (natural=water + seasonal=yes overlapping natural=wetland + seasonal=yes) but in principle that would be a valid statement.

  2. Coastline in the north as Ben mapped it is quite OK i think. In the south the coast should probably be closed a few km above the NH27 bridge around here

I am unsure how far the seawater reaches into the Rann during monsoon storms - however for coastline mapping this is not important since this only considers regular tidal variations and not seasonal storms.

What's up with the Rann of Kutch? 23 days ago

I added a small demostration of how the eastern Indus river delta area can be mapped in http://www.openstreetmap.org/changeset/39796363. Requires a coastline update to be properly rendered of course.

For reliable mapping of the extent of the tidal area you need imagery taken at low and high tidal levels - for example

for low tide:

http://earthexplorer.usgs.gov/metadata/4923/LC81510442016033LGN00/

for high tide:

http://earthexplorer.usgs.gov/metadata/4923/LC81510442016113LGN00/

In addition you have in this area extensive seasonal flooding during summer storms that goes much further:

http://earthexplorer.usgs.gov/metadata/4923/LC81510442013232LGN00/

The effects of this on the landscape can be easily misinterpreted as tidal effects leading to a wrong estimation of the coastline (which is what happened in the PGS data).

What's up with the Rann of Kutch? 23 days ago

Much of this is not really a wetland in the sense that it is waterlogged soil for most of the year but an area of seasonal water cover - water during and after monsoon, dry during the dry season and wetland only during a short time in between. The false color infrared satellite images i put up are meant to approximately catch the average water cover - the area that could probably be tagged natural=water + seasonal=yes. It seems except for the tidal zones these are largely not or only very sparsely vegetated so i am not sure if wetland=saltmarsh really applies.

The last larger coastline edits there were made by Ben Discoe.

What you show later is the eastern end of the Indus River delta with its mangrove forests (which are less dense than typical tropical mangroves in this climate and in serious decline in the last decades - see wikipedia) Significant parts of this are above the high water line.

The whole area is pretty well covered with high resolution images but muddy water and bare ground - both wet and dry - are often quite difficult to distinguish in these.

Layout Managers and Trigonometry 24 days ago

For consistent visual appearance the most important thing and where osm2world currently lacks most is radiometric consistency. For the overall impression this is much more important that sophisticated stuff like reflections.

Improving the OSM map - why don't we? (13) about 1 month ago

W.r.t. the standard map style - there are already open issues regarding a number of the things you point out here:

https://github.com/gravitystorm/openstreetmap-carto/issues/59

https://github.com/gravitystorm/openstreetmap-carto/issues/1391

https://github.com/gravitystorm/openstreetmap-carto/issues/1448

Beyond that current map rendering engines are simply fairly bad at labeling. This is partly because good map labeling is hard and next to impossible to do on the fly during tile based rendering.

Why copying visual style of paper maps is not a good idea about 1 month ago

I am sorry if i misunderstood your focus - you wrote mostly about the subject of colors so i assumed you consider this the most important difference.

As i said to my knowledge there are no digital map styles developed exclusively for high resolution devices - in other words: all digital map styles so far take into account the specific limitation of low resolution display devices. In his recommendations for contour lines Eduard Imhof specifies line widths down to 0.03mm by the way and specifically discusses the difference in results between reducing line with and varying the line color. These nuanced possibilities do not exist with digital displays if the line width approaches or even drops below the pixel size.

It will however indeed be interesting to see how high resolution displays will extend the design possibilities of digital maps.

Why copying visual style of paper maps is not a good idea about 1 month ago

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

300 .... 2 months ago

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...

National Waterways in India 3 months ago

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

Welcome to the new Missing Maps 4 months ago

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.

OpenStreetMap active users 6 months ago

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

http://wiki.openstreetmap.org/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.

A new version of the OSM Edit Report is here! 6 months ago

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.

A new version of the OSM Edit Report is here! 7 months ago

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.

Georeferenzierte Bilder aus Videos extrahieren – Low-Cost VIS 7 months ago

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.

The history and completeness of OSM 7 months ago

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.

The history and completeness of OSM 7 months ago

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 most inefficient way in North America 7 months ago

The Import Guidelines already contain a remark concerning this:

https://wiki.openstreetmap.org/wiki/Import/Guidelines#Consider_simplifying

Of course CanVec - the scourge of OSM...