A happy 2018 to all readers – with two recent images from the last year.
From the southern hemisphere a Sentinel-3 OLCI image of the Falkland Islands
And from the north a Landsat winter image of southern Iceland
January 1, 2018
December 10, 2017
When i wrote about rendering of footways/cycleways in OpenStreetMap based maps recently i indicated there are other changes i made in the alternative-colors style that deserve some more detailed explanation and here i am going to introduce some of them related to waterbody rendering.
Waterbodies in the standard style (and similarlys in nearly all other OSM based maps) have always been rendered in a relatively simple, not to say crude way. Every water related feature is drawn in the same color, water areas traditionally starting at z6, river lines at z8 and streams and smaller artificial waterways at z13. The z8 and z13 thresholds are so firmly established that mappers often decide how to tag waterways specifically to accommodate these thresholds. Since the smaller artificial waterways (ditch and drain) are rendered slightly thinner than streams these tags are frequently abused to map smaller natural waterways. The only significant styling specialty in this traditional framework is that the small waterways starting at z13 get a bright casing so they are better visible on dark backgrounds.
Some time ago a change was introduced to render intermittent waterways with a dashed line. While this seems like a logical styling decision it turned out to work rather badly because of the problems of dashed line styles in combination with detailed geometries as i already explained in context of the footway rendering.
This is the situation that forms the basis of the changes i am going to write about here.
As indicated above traditionally the OSM standard style renders all water features in the same color. This color was changed some time ago but it is still one single color that is used for everything – from the ocean to the smallest streams and ditches.
This all one color scheme does not require mappers to think about how they map waterbodies specifically, they can just paint the map blue so to speak. In particular with water area tagging this has lead to a lot of arbitrariness and relatively low data quality in the more detailed, more specific information. As i pointed out in the context of waterbody data use the data cannot really be used for much else than for painting waterbodies in a uniform color. At the same time this makes life very easy for map designers of these relatively simple maps since you don’t have to worry about drawing order or other difficulties.
More specific information about waterbodies would however be very useful for data users so it makes sense to render it to encourage mappers to be more diligent with recording such information. And differentiating different types of waterbodies can help a lot creating a better readable map since what color and styling works best varies depending on the type of waterbody. And since blue color is widely reserved for water related features anyway differentiating by color is well possible.
The basic three types of waterbodies i am differentiating are:
Rivers use the strongest and darkest color so they are well visible even on strong and structured background while the ocean uses a brighter color not to be too dominating over land colors given that it covers a large area.
In addition to differentiating by physical type of waterbody for line features i also distinguish between natural and artificial waterways in a relatively subtle form using a slightly brighter blue centerline at the higher zoom levels.
Use of subtlety is of fundamental importance if you want to create a rich map that it still well readable. This distinction between natural and artificial waterways is strong enough to be clearly recognized by the keen observer but at the same time it is not adding a lot of noise that would affect the readability of the map otherwise.
As indicated above the standard style already differentiates intermittent waterways but not in a very good way. I tested various options and ultimately came up with the following approach
In addition for waterbodies with salt water (salt=yes) the ocean color is used in combination with a weak bright grain pattern. An abstract demo of all of these together here:
In addition to the more fundamental changes described above i also did a lot of tuning for the line widths and other rendering parameters for a more balanced relationship between the different feature types and a more continuous change in appearance when zooming in or out.
Not directly connected to the waterbody changes but still somewhat related – i added rendering of fords. These are shown in the standard style as POIs with an icon starting at z16 which is a fairly unfortunate way of rendering them because:
In other words: This kind of rendering in many situations does not really improve the map.
I used a different approach by rendering fords similar to bridges – after all a ford is a highway crossing a waterway without a bridge. The difficulty is that fords can be tagged on a node while bridges are by convention always mapped as ways. Rendering node based fords similar to bridges requires quite a bit of effort and i am afraid this significantly adds to the already complex road code. But i think the visual results make it worth it.
As you can see this is usually intuitively recognizable as a ford and the crossing geometry is not obscured by a big and distracting icon.
December 1, 2017
The OpenStreetMap Foundation tomorrow is going to open board elections for this year’s Annual General Meeting for two seats on the OSMF board. If you are a member of the OSMF i would strongly urge you to vote. If not you might want to consider becoming a member (which however will not allow you to participate in these elections – for that you have to be a member a month before the elections).
The reason why this is of particular importance this year is because this year’s candidates for the positions on the board offer in parts fairly contrasting positions on the direction on the OSMF and the OpenStreetMap project in general. You can get an idea of the ideas and views of the candidates in the Q&A on the OSM wiki but you also need to read between the lines because candidates have partly picked up the bad habit from big politics of talking much without saying anything of substance. Sometimes the way how the candidates deal with questions they do not like is more revealing than the actual answers.
Of course replacing two of seven board members will not immediately change the whole OSMF but due to the quite contrasting views and backgrounds of the candidates it will be a significant message in terms of what direction the members support and this way will probably weigh significantly also on the other board members.
Of course even a fundamental change in direction of the OSMF would not necessarily have much influence on the OpenStreetMap project as a whole. One of the most remarkable aspects of OpenStreetMap is how little it depends on central organization and management. But of course if the OSMF and the OSM community start diverging significantly in goals and direction this could create a lot of friction.
November 18, 2017
Here another view of the dust cloud from the previous post from a few days later as seen by Sentinel-2:
And another remarkable situation from the other side of Earth – an impressive assembly of big tabular icebergs near Elephant Island northeast of the Antarctic Peninsula – as seen by Sentinel-3.
November 15, 2017
I have a somewhat different satellite image than usual here:
This is a strip of nine Landsat scenes recording parts of Alaska in early Winter from a few days back. I rotated this to align roughly with the satellite recording direction and you need to scroll down to see the whole image. As you scoll down you move from the limit of the polar night at the northern end towards the southwest and towards the sun across about 1500km.
You will notice a slight bend in the image when doing that – this is because the image coordinate system is not actually aligned to the satellite orbit but a simple oblique mercator projection. Due to the satellite’s sun synchroneous orbit however the satellite ground path is not actually a great circle but kind of spirals around the earth following the sun.
The southern end of this image strip is defined by the end of the Landsat recording which does not extend over the open ocean (it is Landsat after all). The northern end is the limit of normal Landsat recordings at this time of year due to the low sun position.
Here a Sentinel-3 OLCI image from the same day (and this time with north up orientation – also allowing you to identify where exactly the first image is placed) showing a much tighter northern limit.
And for comparison here a false color infrared Sentinel-3 SLSTR image where no recording limit is imposed showing the actual limit of light – but of course not in natural colors.
The two Sentinel-3 images also show an impressive cloud of dust extending SSW from the delta of the Copper River in southern Alaska at the right side of the image. Here a larger view to show this better.
And finally two crops from the first image – the first one from the north showing how you can watch the rivers freezing over at this time of the year near Fort Yukon.
and the second from the south showing the indeed very windy yet sunny weather at Tugidak Island in the south.
November 10, 2017
Some news that might be of interest for some of my readers – without any attempt of completeness.
I updated my satellite sensor chart accordingly. Note i still could not get myself to specify a full coverage interval for the PlantScope satellites. They now show a decent monthly coverage of >90 percent between -60 and 75 degrees latitude for the combination of RapidEye and PlantScope but full coverage means full coverage for me. And demo or it did not happen.
November 1, 2017
About a year ago i wrote my report on the first year acquisitions of Sentinel-2 as well as for Landsat on a matching time frame. This was – and still is to my knowledge – the most detailed and accurate analysis of image data available from these satellites. Here is an update of this for a time frame from October 2016 to October 2017.
The October division is meant to include exactly one summer season of both the northern and the southern hemisphere. A calender year based division would always split the southern hemisphere summer season.
Here is the plot for the overall recording volume of all satellites:
Both Landsat satellites have operated during the last year without any notable incidents or interruptions of recordings. Landsat 7 had its last orbit maintainance maneuver in early 2017 and is now in a steadily declining orbit which means the recording time frame will move from the current about 10:15 to earlier times as it has happened for EO-1 previously.
Here are the coverage maps for Landsat 8 day time acquisitions:
The most notable difference to previous years is that Antarctic coverage was significantly reduced during the 2016-2017 summer (see the last year for comparison). You can see that in the line plot on top as a dip in the Landsat 8 line near the end of 2016 which differs significantly from the patterns of the previous years. To my knowledge there has so far not been a statement from the USGS as to why this change was made.
Otherwise not much has changed – we now get routine off-nadir acquisitions for northern Greenland and the Antarctic interior. In Greenland these always happen for the same path which means there is room for improvement by selecting the path dynamically based on weather in the target area. All 2017 northern Greenland off-nadir images are severely affected by clouds.
Also we still have the
two one gap in land area coverage at lower latitudes – Rockall and Iony Island (Edit: noticed there is actually one image for Rockall – though not regular coverage. Iony Island is actually the more meaningful omission)
For Sentinel-2A we are looking at the second year of operations and this might lead to expectations of an increased level of routine and therefore reliability. We also get the first images from Sentinel-2B. Here are the numbers for Sentinel-2A and Sentinel-2B separately:
And here the combined numbers with a different color scale.
I should emphasize that these are the images publicly available. As pointed out already in a previous report there are significant differences between the published acquisition plans and the actual recordings and furthermore publication of images is frequently incomplete. Here an example from Sentinel-2B from my detailed statistics page (which i also updated to the current state).
I have not determined precise numbers but it is clear that the volume of both images planned but not recorded and recorded but not published is significant. Especially the latter, in particular in its arbitrariness shown in the image above, seems quite embarrassing.
The acquisition patterns are nearly the same as last year and also the same for Sentinel-2A and Sentinel-2B apparently. To summarize: Most of Europe and Africa as well as Greenland are recorded at every opportunity – which means a ten days intervals for each satellite, the rest of the larger land masses except Antarctica only at every second opportunity except for some seemingly arbitrary small special interest areas where also a ten days interval is recorded. Smaller islands are fully missing. Antarctica has been covered during the 2016-2017 summer but mostly at a much lower frequency than the rest of Earth.
Apart from the spatial distribution of acquisitions (which quite clearly is a conscious political choice) the most striking difference to Landsat is that high latitude acquisitions in Greenland and European Arctic islands are not reduced due to the naturally larger overlap between recording opportunities. In northern Greenland this leads during summer to frequently more than one image per day. While this can be nice for data users interested in those areas and is also kind of compensatory for the otherwise low focus on these regions it is fairly wasteful in terms of recording resources and probably results from blindly sticking to the rule record Europe and Greenland at every opportunity decided on by bureaucrats who have no clue what this actually means in practice.
So overall not that much has changed since last year – which i guess is good news for Landsat and less good news for Sentinel-2 since the latter is still subject to the same problems and limitations as last year. But maybe we just need a few more years to get used to these problems…
Apart from the problems already mentioned Sentinel-2 operations continue to be plagued by delays in data processing and other incidents. While for Landsat you can fairly reliably predict when the next image will be recorded for a certain place on earth and that it will be available a few hours afterwards for Sentinel-2 this is still much less the case.
With all the beating on Sentinel-2 problems it should however be mentioned that with two satellites now operating at a more or less constant level Sentinel-2 now usually offers a higher recording frequency than Landsat 8 (which is a practically sensible comparison since use of data from Landsat 7 is often fairly difficult due to the SLC gaps) – even in the lower priority areas – except for the small islands and Antarctica of course. In other words: if you look for the most recent image from a certain point on Earth it is more likely you find it in the Sentinel-2 archive than from Landsat 8 – despite the fact that delays in processing, missing recordings and missing publications put Sentinel-2 at a significant disadvantage.
And another positive thing about Sentinel-2 – Availability of the download infrastructure has improved a lot in the past months. Longer unscheduled downtimes where no downloads are possible at all are now fairly rare.
Here for reference all the recording visualizations for this and the previous years:
|year||day||night||day pixel coverage|
|2016||LS8, LS7||LS8||LS8, S2A|
|2017||LS8, LS7||LS8||LS8, S2A, S2B, S2 (both)|
October 29, 2017
A few satellite image impressions from the last weeks showing islands in spring and autumn. First a view of southwest Iceland from just a few days ago:
Then a clear weather glimpse of South Georgia in spring – with a large iceberg to the northeast:
And finally an image of Onekotan Island in the northern Kuril Islands:
The first two are based on Copernicus Sentinel-2 data, the last is created from Landsat imagery.
October 26, 2017
Rendering lines in a map is something that at the first glance seems the simplest thing to do but in reality there are quite a number of things that need to be considered for lines in a map to be well readable. One thing in particular is that if you render a dashed or dotted line this is much more difficult to get right than a solid line.
The OSM standard style uses dashing to differentiate tracks by tracktype and footways/cycleways by surface. This works reasonably well at the high zoom levels but it degrades to the point of being completely unreadable as you zoom out in areas with a dense network of paths. Like in these examples:
Now you can try to vary the styling like by adding bright halos, increasing contrast or varying the line width but ultimately a dashed or dotted line always makes it more difficult to identify the paths as continuous lines in areas with a lot of detail. A fundamentally different and possibly better approach would be to only draw the most important ways at these scales. But for that you’d need an assessment of importance, which is not really something you can readily find in the data and which ultimately is quite subjective and likely would not be very intuitive in many situations. Some map users for example might find it helpful if only those paths are shown that are part of a long distance trail. A local map user might on the other hand consider a different path more important because it is the shortest, easiest and most frequently used connection between two villages in the area.
One solution for tracks and paths at z13/14 i had already quickly tested some time ago is to drop the dashing and use continuous lines at these scales. This severely limits the possibilities to distinguish between different classes of paths – you can essentially only use the line width and color to differentiate and at narrow line widths it becomes more and more difficult to distinguish different colors because all pixels contain a mixture of background and line color.
One thing that prevented implementing this approach was the fact that cycleways in the standard style are traditionally rendered in blue color and a solid blue line looks just too much like a water feature intuitively. The use of blue color for cycleways has always been a sore spot but attempts to change that in the past were always hampered by the lack of other options. In particular the use of purple for boundaries creates severe limitations. Since i got rid of the purple boundaries i have some more freedom in that matter now.
Finding the right balance in colors, line widths and – at the higher zoom levels – the dashing patterns is difficult but i think the results are quite agreeable. This modification puts a stronger emphasis on footways and cycleways in the map but that in my eyes is mainly compensation for the under-representation they have in the standard style at the moment.
At z13 all lines are solid, the tracks vary in width slightly to indicate the tracktype but this variation is not large enough to reliably identify the individual track types although you can usually distinguish grade1 from grade4. Footways and cycleways are the same color (red) which can be distinguished from the track brown in nearly all situations.
Overall the map image is much clearer and less noisy. You can better identify individual tracks and paths and their routes and connections, in particular in densely mapped areas although you loose the ability to differentiate between different types in not so densely mapped areas.
At z14 styling is very similar, the line width variation for tracks is somewhat stronger and i start using dashing for tracks without tracktype indicating to the mapper that important information is missing here.
At z15 a white casing is added like it is also done in the standard style. Tracks are the same as in the standard style but cycleways are purple now and both cycleways and footways are stronger and differentiate clearly by surface type with long dashing for paved, short dashing for unpaved and alternating long/short for unspecified surface.
I also considered differentiating out a third class of paths. The standard style some time ago removed that but this leads to the somewhat peculiar situation that
bicycle=designated is shown in cycleway color while
highway=path without foot or bicycle tags is shown in footway color. But unfortunately mapping is often very inconsistent in this matter so this would not necessarily improve usability that much. The meaning of the colors essentially is:
At higher zoom levels the line width is slowly increased just like for tracks and the dashing is also slightly enlarged for better readability.
The style modifications for this can be found here.
I hope this description gives a tiny bit of insight into how map style design works when you systematically analyze and address problems. The actual coding is not that much work but analyzing the map rendering and identifying the problems on the one hand and adjusting and testing the various parameters, observing how the results affect the map viewing experience and how the different colors interact with each other in different geographic settings at different latitudes and resulting scales on the other hand are those things that are hard work.
In case you wonder what you can do as a mapper to allow for better readable rendering of tracks/footways/cycleways:
bicycle=*as they apply.
sac_scale=*could be used to better differentiate rendering.
Tracks, footways and cycleways are not the only place where the standard style uses dashing and also not the only place where this leads to problems. Other situations where this leads to problems are administrative boundaries and intermittent waterways. There are already some improvement in these areas as well in the alternative-colors style. Maybe i will write about this in a future post.
October 19, 2017
I here introduce a new satellite image mosaic i produced of New Zealand.
This is based on Sentinel-2 images from 2015 to 2017 and otherwise shares many of the characteristics of my previous mosaics like the high level of cloud freeness, seamless ocean depiction and assembly with priority to snow minimum and vegetation maximum.
What’s new is there is a significant improvement to the atmosphere correction methodology which i here used for the first time on a larger project. This results in a more uniform and more balanced color rendering overall. It is also the first time i produced the matching vegetation map at the Sentinel-2 resolution of 10m.
Here a few sample crops, more can be found on the mosaic description page on services.imagico.de.
I also produced a few new 3d views based on this mosaic, here two examples:
More 3d views can be found in the catalog on services.imagico.de.
October 12, 2017
There has recently been some discussion in OpenStreetMap on names and labeling due to some people expressing the desire to abandon the geographically neutral labeling on the OpenStreetMap standard style. One of the things this discussion once again showed is a basic problem in the way names are recorded in OpenStreetMap which I here want to briefly discuss.
The OpenStreetMap naming system is based on the idea that features in the database can have a local name, the name predominantly used locally for the feature, as well as an arbitrary number of names in different languages, that is how non-locals or locals speaking a different language than most name it. The first is to be mapped in the name tag, the latter ones go into name:<language> tags where <language> usually it the two letter code of the language of the name. There are other name tags like alt_name (for an alternative local name) or old_name (for a historic name no more in active use).
The OpenStreetMap standard style renders the content of the name tag and this way is supposed to display the name locally used. This is one of the most characteristic aspects of the map and a highly visible demonstration of OpenStreetMap being based on local knowledge and valuing geographic and cultural diversity. That there are of course people who think it is more important to have another map (in addition to hundreds of commercial OSM based maps) where they can read the labels than at least a single map that can be read by any local mapper all over the world in their local area is obvious but this is not my topic here.
The problem with basing labels on a single name tag for the local name is that then local mappers are often in conflict between tagging the actual local name and tagging whatever they want to see on the map – which might be affected by the desire of uniformity in labeling or to make the map better readable for non-locals. As a result the name tag often contains compound strings containing names in multiple languages, in particular in regions where multiple languages are widely used by locals and there might not even be a single dominant local name.
The solution to this problem would lie in dropping the illusion that there is always a single local name that can be verifiably mapped. Instead you would tag the names in the different languages as it is done currently and add a format string indicating what the common form of displaying the names of this feature locally is. Separating the multilingual name data from the information on local name use is the key here.
The format string would normally not have to be specified for every feature individually since typically all features in an area would use the same format string. Instead you would have the individual features inherit the format strings of the administrative units they are located in.
For example in case of Germany the admin_level 2 boundary relation (51477) would get something like
language_format=$de – and there would be no need for further format strings locally except maybe for a few smaller areas with a local language or individual features with only a foreign language name. Switzerland (51701) would get
language_format=$de/$fr/$it/$rm and the different Cantons would get different format strings depending on the locally used languages.
The key and syntax for the format string are just an example of course to illustrate the idea – those could be different.
I think the advantages of this concept are obvious:
But i will also mention the main disadvantages of this idea:
Another possible point of critique is that the format string is non-verifiable. But obviously if the current name tag is verifiable so is the format string which just describes its structure in an abstract form.
October 5, 2017
It’s autumn and the leaves are starting to change colors – matching that here a few impressions from the autumn in the north from satellite perspective.
The first is from the Yukon River at the Alaska-Yukon border:
Here two magnified crops:
The second shows the southern slopes of the Verkhoyansk Range, Siberia around the Tompo River with early snow in the mountains. The area was also included in last year’s autumn colors mosaic.
Also for this two magnified crops:
Both of these images are based on Sentinel-2 data. The next image shows a late autumn view of western Svalbard around Isfjorden taken by Landsat 8. Despite the high latitude warm weather can last quite long into autumn in this area so snow which had already fallen in mid September thawed away again almost completely in this October 2 image.
And finally a larger area view of northwestern Canada based on Sentinel-3 OLCI data: