imagico has commented on the following diary entries

Post When Comment
The number of the month: 74.9 percent 5 days ago

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.

Some comments about the OpenStreetMap Awards 18 days ago

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.

Visualizing's Map Views about 2 months ago

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?

Status der OpenTopoMap 2 months ago

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

Deriving centerlines from riverbanks without. 3 months ago

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.

The map is a fractal 3 months ago

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.

Up-to-date open data imagery - it is available, use it! 3 months ago

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.

Up-to-date open data imagery - it is available, use it! 3 months ago

@BushmanK - yes, there is a lot written about processing satellite data. Science papers are usually only of limited use though since they tend to not mention the practical problems and limitations but concentrate on presenting something as 'nice in theory'. There is a lot of practical material available as well of course, starting with the GDAL documentation and the satellite data specifications:

Most practical tutorials present very specific workflows based on specific tools but can also serve as sources for general information. Like:

@Skippern - my images are in the OSM Editor Layer Index but i do not manage to keep them completely up-to-date there so you either have to enter the layers manually or wait until an update is made.

For JOSM i recommend using

in addition to the Editor Layer Index - this way you have the individual layers and an up-to-date version of the aggregate of all layers.

Experimental publishing of Sentinel 2 satellite data 3 months ago

There is nothing wrong with looking for and asking for instructions but of course for a faceted topic like satellite image processing there is not one single way to do things and what works well for someone processing satellite data professionally rarely works equally well for beginners. So when i write specific instructions (like here) i tend to do this based on a workflow specifically designed for the task in question which is usually not what i use myself routinely. You can try to follow such instructions step by step to do very specific things or you can try to learn more generic matters from them but you cannot expect develop a fundamental understanding that enables you to do new things and make qualified decisions just by reading and following a specific tutorial.

And the accusation of "rude smart ass professionals" is not that far fetched with regards to Sentinel-2 - there is a strong tendency within ESA and related companies towards elitist, non-transparent work and a distinct culture of non-openness, the SNAP/Sentinel toolboxes system is just one example for this. The open data nature of the Sentinel program is very new to most of the people working in that environment.

Experimental publishing of Sentinel 2 satellite data 3 months ago

@SimonPoole - the "best" classification is not well suited since it is a binary onedimensional and whole source classification relative to other constantly changing sources. For a real improvement editors would need to detect where Bing/Mapbox have poor imagery (as said easy with Bing based on the date metadata) and suggest other imagery there.

@Zverik - in my experience the problem with processing satellite images is not the technical side. GDAL meanwhile has also support to directly read from Sentinel-2 packages so this is relatively easy. The problem is more the difficulties of the matter itself - choosing a well suited image and processing it for a consistent and well readable appearance. This requires experience which you can not substitute through clever tools and documented workflows. Still there are a lot of things that make Sentinel-2 more difficult than Landsat - i have written about those in my blog quite extensively.

Since i have started the OSMIM i have always said requests for images are welcome but there have been very few and i don't think this is because mappers are shy but because of lack of awareness and lack of appreciation for relatively low resolution but very up-to-date imagery. Many mappers these days have never learned how to extract meaningful information from lower resolution imagery.

comparing openstreemap-carto to other map styles 3 months ago

Regarding relief rendering - this is not feasible to do with shading in combination with the current extensive and highly differentiated area coloring.

In addition Mapnik and similar tools AFAIK are currently not capable to produce high quality shading. Mapzen has recently showed a demo illustrating some very basic techniques for shaded relief - which is already far beyond what Mapnik can do.

By the way BushmanK recently pointed to an interesting new data source for relief data which however also requires significant processing to be useful on a global level.

Regarding point features at low zooms - i think this is usually well doable purely from OSM data, the question is more if it can be done on-the-fly or requires preprocessing.

OSMF board meeting report 3 months ago

Regarding "the organization holding the rights on the OSM data" - i understand the OSMF to be the holder of the database rights of the OSM database as a whole, the individual mapper only has rights to his contributions and in the contributor terms waives his rights "to assert against OSMF or its licensees any moral rights that You may have in the Contents". Therefore the OSMF standpoint on interpretation of the license has particular weight.

Apart from that on the one hand you emphasize the communicative, inter-personal aspect of such meetings (which i agree is important), on the other hand you don't think giving context to decisions during those meetings is necessary or even desirable. Of course there is no need to recap in detail the whole process that lead to the guideline but I don't think the outlook for the next steps regarding community guidelines, what board and LWG might have planned or expect to be the next steps, is something that can be read up somewhere else.

Don't get me wrong i don't think this is a serious omission in any way, just an observation of what i missed, no big deal IMO.

FOSSGIS-Konferenz 2016 3 months ago

Der Raum war denkbar ungünstig für was anderes als 'Frontalunterricht' und außer dem Flur und Terrasse hatten wir nichts anderes, wo man sich mal in Gruppen zusammensetzen konnte.

Die meisten Themen wären durchaus geeignet gewesen, um da offen dran zu arbeiten, am Ende hat jedoch im Wesentlichen jeweils einer was präsentiert und es kam wenig echter Dialog zustande. War natürlich trotzdem interessant aber halt nicht optimal.

Dass das Ganze vor der Konferenz stattfand war vermutlich auch nicht ideal. Insbesondere zu den Themen Routing und Rendering gab es ja im Hauptprogramm dann auch noch Vorträge und die Vortragenden waren am Sonntag teils noch garnicht da - was die Sache sicherlich nicht verbessert hat.

Aus dem Themenbereich war auch kaum etwas eingereicht worden. Vielleicht einfach das Konferenz-unter-der-Woche-Problem?

Das ist ein Henne-und-Ei-Problem, nur wer zur Veranstaltung kommen möchte, reicht auch was ein und ob man kommen möchte hängt vor allem auch davon ab, ob einen die Themen interessieren.

Eine klare Verschiebung der Themenschwerpunkte erreicht man nur dann, wenn man von Anfang an die Absicht kommuniziert, den Charakter der Veranstaltung zu ändern.

Experimental publishing of Sentinel 2 satellite data 3 months ago

It all depends on what you want to use the images for. CLAHE and similar techniques will work out details at the cost of large scale consistency, what color a certain area appears in depends not only on this area itself but also on its surrounding.

By stretching contrast the way you do you also inevitable loose information in the darkest and brightest parts (like mountain slopes facing away from the sun and cloud shadows) - which can for example be a problem at high latitudes where the sun is low even in summer.


for example you can very well see the limits of the forested areas but nuances in the dark forests and in the bright parts (like snow-clouds and rock-ice distinction) are fairly difficult to recognize.

Experimental publishing of Sentinel 2 satellite data 3 months ago

Yes, there are good reasons for using infrared image data, especially if water and wetlands are concerned. You really need to know how to interpret what you see then though.

Color processing can be difficult, producing a color rendering that shows well articulated bright areas but also shadows and that at the same time is consistent with the color impression you get on the ground is a challenge.

Experimental publishing of Sentinel 2 satellite data 3 months ago

Yes, it is indeed important to show and demonstrate that up-to-date imagery these days is not a big issue any more and that there is no good reason to waste time mapping based on 15 year old images as they still can be found in Bing/Mapbox for large parts of the Earth. It is fairly frustrating if you see mappers spending a lot of time and energy on tracing from these when you know significantly better data is available. It would be really good if editors (JOSM, iD) would start actively suggesting to use other sources in areas where the standard image sources are poor. At least for Bing this is easy to determine from the tile metadata.

There are also a few Sentinel-2 images on the OSM images for mapping - like the Panama Canal, Glaciers in Peru and Antarctic islands.

In general i would recommend not using false color combination or unrealistically stretched contrast functions unless you have specific reasons for that for mapping certain stuff since it makes recognizing things in the images more difficult - especially if mappers have no or very limited on-the-ground knowledge of the area.

For Landsat by the way the USGS offers on demand WMS services for individual images but only in false color and without pansharpening - this can be useful if you quickly want an up-to-date image for verification but is not really useful if you want to get most out of the data.

Regarding attribution - what is written on the contributors page should be sufficient - for the changeset source tag it would be important to specify the scene ID or the image date.

FOSSGIS-Konferenz 2016 3 months ago

Dass die Vorträge interessant und ein recht vielfältiger Mix waren dem kann ich zustimmen - wenngleich wie üblich recht wenig zu praktischen Mapping-Themen dabei war.

Ich denke aber, dass von OSM-Seite das Format durchaus eine Menge Verbesserungspotential hat. Sowohl was dem OSM-Sonntag betrifft (der sowohl von den Räumlichkeiten als auch von der Programmgestaltung meiner Meinung nach nicht ganz ideal war - gab zu wenig Raum für vertiefende Gespräche und Diskussionen) als auch im Hauptprogramm, wo wir meiner Meinung nach zu wenig eigene Schwerpunkte setzen und zu sehr am durch die übrige FOSSGIS gesteckten Rahmen kleben.

Für das Haupt-Treffen der deutschsprachigen OSM-Community würde ich mir im Grunde mindestens einen Tag für praktisches (Hack-Day und praktische Mapping-Sachen) wünschen und im Konferenz-Teil weniger Frontal-Programm, mehr Raum für Diskussionen, mehr kommunikative Programmpunkte wie Podiums-Diskussionen usw. Wenn für einen Vortrag jeweils nur fünf Minuten Diskussion vorgesehen sind, dann plant der Vortragende eher nichts ein, was zu vertiefenden Gesprächen führt und es bleibt am Ende kaum Raum für mehr als ein paar Verständnisfragen. Und dann geht der nächsten Vortrag los und man muss entweder den Raum verlassen oder sich dem nächsten Thema widmen, was einen offenen Austausch zu den einzelnen Themen stark erschwert. Wenn man das später in den Pausen oder am Abend noch mal zu den Themen ins Gespräch kommt dann meist mit nur einer oder wenigen Personen und nicht mit allen Interessierten, wie es direkt nach einem Vortrag der Fall wäre.

Damit ein zeitlich weniger gedrängtes Programm nicht auf Kosten der Themenvielfalt geht müsste man dann natürlich zwei OSM-Tracks parallel haben.

OSM Node Density – 2016 Update 4 months ago

Very nice.

The difference layers are somewhat confusing color wise - showing a color scale there would be helpful.

The invalid areas of the map 4 months 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

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 4 months 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).