Imagico.de

blog

Antarctic images for Mapping

March 18, 2024
by chris
0 comments

More Antarctic images for mapping

I processed another set of satellite images of the Antarctic for mapping in OpenStreetMap – further extending the fraction of the Antarctic for which up-to-date images are available to mappers.

As before – depending on how quick the editors are in adding the new images to their databases these might be soon available in your editor of choice – but you can also add them manually based on the links provided on my preview map.

A few highlights:

Representation of mappers in OSMF membership

February 4, 2024
by chris
0 comments

Representation of mappers in OSMF membership

As i have indicated in my pre-AGM comment end of last year i intend to look at developments in the OpenStreetMap Foundation less on an acute level and regarding current events and more focus on long term developments, trying to help people better understanding those. This is the first post i am writing under that paradigm.

In 2019 i last looked at the membership structure of the OSMF and how much it represents the active mappers in OpenStreetMap in their geographic distribution. Since then others have analyzed the numbers as well – but i thought that after nearly five years having a look along the same lines as back then might be useful.

Now there are people who dismiss this kind of analysis as irrelevant because it is just about mapper representation and does not consider non-mapping contributors to OpenStreetMap. But in most cases this argument seems primarily used to justify a continuation of the existing cultural dominance in the OSMF. Because, evidently, non-mapping contributions to OpenStreetMap typically much more than mapping require knowledge and familiarity with the English language. So in my eyes, basing the geographic representation in the OSMF on the geographic distribution of mapping would be as close as it practically could get to a balanced representation of the OSM community in that regard overall.

The numbers used are taken from recently published data. Unfortunately the OSMF still has no automated regular reporting of membership statistics and i did not want to take up time from the MWG volunteers by asking them for numbers specifically for me. Keep in mind that there are different concepts of membership that can be analyzed – either the paid up members (those who are hypothetically eligible to vote in a general meeting at the moment) and all formal members (including ones in grace – that means who have last renewed their membership between one and two years ago and who are therefore still considered formal members despite not being eligible to vote).

Like in 2019 i put the OSMF memberships per country of residence in relation to OSM mapping contributor statistics published by Pascal Neis. With those – keep in mind that they are based on where mappers are active, not where they are from (which is typically not known). And since Pascal meanwhile publishes also estimates how many of the active mappers are part of organized mapping activities, i did my analysis separately for either all mappers or only the non-organized mappers.

Otherwise, the columns are mostly identical to those in 2019:

  • OSMF members: number of OSMF members from that country (normal and associate, paid and active contributors) according to data provided by the MWG
  • Mappers/Day: average number of mappers from that country active per day according to Pascal’s statistics (averaged over the last 52 weeks)
  • expected: expected number of OSMF members from that country assuming proportional representation and same total member count (1929)
  • representation: percentage of actual representation compared to expected (100 indicates proportional representation)
  • mismatch: difference between expected and actual number of OSMF members, negative values indicate too few members for proportional representation

Because the total number of OSMF members has significantly increased since 2019 the absolute numbers are a bit difficult to compare, it is mostly the representation numbers that can be looked at in that regard.

What i included in addition this time is the other countries not on the list where there are mapping activities but from where there are no OSMF members at all. This is the gray line. Of course for these the representation is zero.

Here are the numbers, sorted by average active mappers/day:

Representation of mappers in OSMF membership - 2024

Representation of mappers in OSMF membership – 2024, link goes to larger version

Here a CSV file with the data from that table.

What i see when looking at the data is in particular:

  • The strength of the over-representation of the most strongly represented countries has, overall, substantially decreased. If we exclude the countries with very few mappers and <5 OSMF members (for which the representation calculation is extremely inaccurate) there is only one country now with more than 300% representation (Luxembourg, 413%/402%) and the two largest countries - both in terms of mapping and in terms of OSMF membership numbers (Germany and US) - have both decreased in their over-representation (the US very strongly, Germany somewhat less). The UK is on exactly the same level as in 2019 (254%) while the Netherlands have increased quite a bit (from 170% to 207%).
  • More importantly the representation of the most severely under-represented countries in 2019 (Poland, Indonesia and Russia) has increased substantially. This is most impressive for Poland (8% to 75%) but also for Indonesia (9% to 29%, 34% if you exclude the organized mapping activities). Russia went from 11% to 28%.
  • The most under-represented single countries with a large number of active mappers now are Russia, China and Iran. Japan has more or less retained its level of representation, but is still quite low among the more active countries with 41% representation.
  • The most important observation is the same as in 2019 – that the countries with relatively small mapping activity (the long tail) are collectively severely under-represented. This is most obvious in form of the line for ‘others’ – which represents all the countries with no member in the OSMF at all. These countries together, based on their mapping activities – would deserve about 150 seats in the OSMF membership based on their mapping activities.

The most significant factor that has influenced the representation in the past years is without doubts the active contributor memberships that remove the hurdle of needing to pay for being an OSMF member.

This just as a quick look, readers should do their own observations and draw their own conclusions of course. Feel welcome to comment with your thoughts below.

All of this is of course only on the subject of geographic representation. And even if this aspect is further improved and we’d ultimately achieve a proportional representation of the whole OSM community also in other aspects that is no guarantee for the OSMF being run according to the needs of the community.

A big issue, which i already hinted at by separating the organized mapping activities, is the over-representation of people with an OSM related business or career interest. Among mappers this is more or less equivalent to organized mapping – and although we have no fully reliable data on which mapping activities belong to that, thorough analysis of mapping behaviour can provide a good estimate. We do not, however, have any reliable information on which OSMF members have OSM related business or career interests. What we can see meanwhile is that among people active in the OSMF in a form visible to the outside observer (both volunteers out of their own initiative as well as among members of appointed bodies) the hobbyists are clearly in a minority now and their percentage is further decreasing. But if this can be extrapolated to the OSMF membership is not quite clear. If this is the case then that might be a more severe representation problem than the geographic distribution. If not the mismatch between the social structure of the OSMF members and people active in the OSMF is likely to create problems on its own.

3d view of the Pyrenees based on Musaicum EU-plus

January 15, 2024
by chris
1 Comment

Musaicum EU-plus – additional layers

Back in July i introduced the Musaicum EU-plus – a 10m resolution satellite image mosaic of Europe. I have now finalized two additional variants of this image that i would like to introduce here.

Both of them are fairly specialized data sets, therefore i did not so far list them in my products. I mostly produced these for my internal use in the production of my own higher level visualization products. But they are also available for external use on request.

Shading compensated image mosaic

I already provided a preview for this when introducing the standard mosaic in July. In addition to the standard surface reflectance image product, i am offering also a shading compensated version. This is not based on the very poor quality L2A data provided by ESA but uses a custom algorithm developed by me specifically for visualization applications.

Musaicum EU-plus shading compensated in the Western Alps

Musaicum EU-plus shading compensated in the Western Alps – click for larger version, original, not shading compensated for comparison

Musaicum EU-plus shading compensated in the Pyrenees

Musaicum EU-plus shading compensated in the Pyrenees – click for larger version, original, not shading compensated for comparison

This shading compensated version of the mosaic has now been produced and evaluated for the full coverage area of the Musaicum EU-plus.

Musaicum EU-plus shading compensated - coverage area

Musaicum EU-plus shading compensated – coverage area

Vegetation and water map

In addition to the visual color images i also produced a fractional landcover data set with the same grid specifications – comparable to similar data sets i had produced for regional mosaics before.

This data specifies the fractions of a pixel covered by

  • herbaceous vegetation
  • woody vegetation
  • water
  • bare ground

Visualized using different colors for the different landcover classes this looks like the following:

Fractional landcover data visualization - Western Alps

Fractional landcover data visualization – Western Alps

Fractional landcover data visualization - Pyrenees

Fractional landcover data visualization – Pyrenees

This data is likewise available for the full coverage area of the Musaicum EU-plus but should be regarded more experimental w.r.t. the herbaceous/woody vegetation, in particular at higher latitude where low sun angles and the resulting differences in illumination make a consistent classification difficult.

Application examples in maps

Here a few examples how this new data can be used in map production. These are in web mercator projection at z13 and z12.

Musaicum EU-plus image - click for larger area

Musaicum EU-plus image – click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading - click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading – click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading and contours - click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading and contours – click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer - click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer – click for larger area

Musaicum EU-plus image - click for larger area

Musaicum EU-plus image – click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading - click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading – click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading and contours - click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading and contours – click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer - click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer – click for larger area

Musaicum EU-plus image - click for larger area

Musaicum EU-plus image – click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading - click for larger area

Musaicum EU-plus shading compensated with artificial northwest shading – click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer - click for larger area

Landcover rendering based on Musaicum EU-plus fractional landcover layer – click for larger area

Application examples in 3d

One of the main uses of the shading compensated imagery is of course the production of 3d views with a freely adjustable lighting independent from the light direction when the images were taken. Here a demonstration of that.

Pyrenees with early morning lighting

Pyrenees with early morning lighting

Pyrenees with afternoon lighting

Pyrenees with afternoon lighting

Pyrenees with late afternoon lighting

Pyrenees with late afternoon lighting

Pyrenees with evening lighting

Pyrenees with evening lighting

And another example from the Alps – compare also to this older view.

Bernese and Uri Alps with afternoon lighting

Bernese and Uri Alps with afternoon lighting

Bernese and Uri Alps with morning lighting

Bernese and Uri Alps with morning lighting

Further 3d rendering examples:

Ordesa Valley, Pyrenees

Ordesa Valley, Pyrenees

Pennine Alps, Italy/Switzerland

Pennine Alps, Italy/Switzerland

Mt. Etna on Sicily, Italy

Mt. Etna on Sicily, Italy

Apart from the Musaicum EU-plus these visualizations are using data from: OpenStreetMap contributorsODbL, L’Institut national de l’information géographique et forestière (IGN) – Licence Ouverte 2.0, Istituto Nazionale di Geofisica e Vulcanologia (INGV) – CC-BY 4.0, Bundesamt für Landestopografie (swisstopo), Centro Nacional de Información Geográfica (CNIG)

Cycling/bus lanes and street lamps in Strasbourg at z19

December 27, 2023
by chris
0 comments

The world of parking #3 – some odds and ends

While working on the rendering of parking features that i discussed in the previous post i also came to implement some features and address some problems that are not strictly about parking but design wise related. And those i want to discuss here a bit.

More implicitly mapped features on roads

The introduction of rendering for street side parking required substantial modifications to the rendering of implicitly mapped sidewalks and cycleway tracks (originally discussed here) and embankments (here). Sidewalks and cycleway tracks are shown outside street side parkings so need to be shaped around those. And the embankments are now separately molded around the roads and their sidewalks and parkings on both sides of the road.

Implicitly mapped street-side parkings in combination with sidewalks on various road types at z18

Implicitly mapped street-side parkings in combination with sidewalks on various road types at z18 – click for double resolution rendering

The difficulty is that all of this needs to work in combination with all the different road types and at junctions between different roads

Handling of junctions between roads with implicitly mapped street-side parkings and sidewalks at z18

Handling of junctions between roads with implicitly mapped street-side parkings and sidewalks at z18 – click for double resolution rendering

The on-street parking lane rendering also called for rendering cycle and bus lanes on roads in a similar fashion. This is similarly tricky to make work reliably in different road topology contexts – and for the lanes there is still quite a bit of room for improvements in that regard – the code is already quite complex as is though.

Different road types with cycling lane and bus lane tagged

Different road types with cycling lane and bus lane tagged – click for double resolution rendering

Handling of road junctions with parking, bus and cycle lane rendering

Handling of road junctions with parking, bus and cycle lane rendering – click for double resolution rendering

In addition, tagging practice for cycle and bus lanes in some cases requires knowledge of the driving side of the roads – when cycleway=lane/busway=lane or cycleway=opposite_lane/busway=opposite_lane is tagged on a oneway road the side on which the lane in question is going to be located depends on the general driving side of the location in question.

Implicit bicycle lane/track tagging variants in a right side driving region

Implicit bicycle lane/track tagging variants in a right side driving region – click to see left side driving variant

Implicit bus lane tagging variants in a right side driving region

Implicit bus lane tagging variants in a right side driving region – click to see left side driving variant

Overall, in the AC-Style we now have the following variants of mapping dedicated cycling and bus infrastructure explicitly visualized:

Dedicated cycling path/road infrastructure variants in the AC-Style

Dedicated cycling path/road infrastructure variants in the AC-Style – click for double resolution rendering

Dedicated bus road infrastructure variants in the AC-Style

Dedicated bus road infrastructure variants in the AC-Style – click for double resolution rendering

Because all of this gets pretty colorful if you include the different types of access restriction dashing i have been contemplating to remove the colored rendering of the different non-pysical road classes at z18+. At the high zoom level this type of semantic differentiation becomes much less significant so it is worth considering not to apply it any more. I have not made a decision on that yet.

More regional differentiation

The driving side problem was solved using the same technique i previously introduced for name label rendering to determine the default language of an area. The polygons used to do that were supplemented with additional attributes for the driving side and for the locally used currency. I updated the shapefiles i produced accordingly. The information about currency is so far incomplete – as are currency symbol SVGs. But quite a lot of countries are covered.

The question if regional differentiation is advisable to have in a map style meant for global use and for mapper feedback has been a subject of discussion for a long time. For languages i think i have amply demonstrated the necessity when i discussed name labels some time ago. I think the situation for the driving side is obvious as well – if mappers have adopted a tagging system that depends on knowledge of the driving side for interpretation (and i see no good reason why mappers should not do so) it is natural that map styles need to source this information somehow to interpret this data accurately.

As for the currency symbols – this is obviously a design choice. But for visualizing the concept of money in a compact form an intuitively readable currency symbol is very useful. Some purists w.r.t. the idea of a globally uniform map might object to the idea that the same data will show up differently in the map depending on where the data is located. But this is already the case not only with the driving side and the language and script of labels but also simply because of the variable scale Mercator projection. Web maps in Mercator projection are fundamentally already regionally differentiated.

In my opinion establishing and using the ability to regionally differentiate map rendering rules is important to honor the idea of OpenStreetMap to value local knowledge. But it is of fundamental importance that such differentiations reflect well defined and clearly spatially delineated differences in the geographic reality. It is important not to use it to pave over and disguise regional differences in mapping practice because that would sabotage the goal of OpenStreetMap to collect local knowledge into a single database.

For the same reason i see the trend in maps available today to differentiate map styling not by region but by individual map viewer fairly critically. While this has been common practice in commercial maps for a long time, it is a whole other story when it comes to maps with a significant role in providing mapper feedback. The fact that all mappers – when evaluating their own and others’ work by looking at a real time updated map – see exactly the same thing when looking at the same map at the same location is pretty fundamental for the social cohesion in the OSM community. And the nonchalance with which some people contemplate throwing this completely out of the window is quite remarkable.

Extensions of Mapnik anchors

While working on the rendering of add-on symbols for parkings (see previous post) i noticed that when dealing with multiple add-on symbols it is useful to extend the feature of anchors i implemented in Mapnik (see here) to allow lists of anchors not only in anchor-cond, but also in allow-overlap-anchor and anchor-set. This extension is also available now.

Improvements of symbol and pattern processing

I also made some improvements to the scripts for symbol and pattern processing.

In the script for generating the unpaved road structure patterns i removed the dependency of the now unmaintained colormath python module. I also moved configuration to a separate yaml file.

In addition i extended the generation of contact sheets to the unpaved patterns and the add-on symbols – you can see those in the symbols readme.

Finally: I also introduced rendering of highway=street_lamp at z18+ in a design derived from the french style.

French design street lamp rendering at z19+

French design street lamp rendering at z19+

This subtle small footprint design allows precisely locating the lamp and can – like bollards – be rendered in a non-blocking fashion.

That wraps up this three post series on the world of parking in OpenStreetMap and automatically rendered maps.

Parkings in Portland at z18

December 24, 2023
by chris
0 comments

The world of parking #2 – new visualization ideas

In the previous post i introduced the basic concepts of how parking infrastructure is mapped in OpenStreetMap and how this is so far shown in most maps. I also discussed that there is an extensive spectrum of secondary tags used by mappers to characterize parking infrastructure in more detail. Here i want to introduce some new rendering concepts to visualize some of these.

The attributes i chose to interpret are generally among the more widely used secondary tags for parking features in OSM. But of course there is also some subjective choice in that.

So let us get started…

General design concept

I maintained the principal design concept from OSM-Carto to show large parking polygons from early zoom levels depending on size while showing all parkings from z16. But i reduced the symbol sizes at the lower zoom levels, in particular reducing the visual weight of amenity=bicycle_parking/motorcycle_parking at z16 and lower. Here is the full zoom level sequence illustrating that:

amenity=parking/bicycle_parking/motorcycle_parking at different zoom levels

amenity=parking/bicycle_parking/motorcycle_parking at different zoom levels – click for double resolution rendering

Surface depiction

As you can see in these already, there is a fill pattern shown on polygons at the highest zoom levels (z18+). I use a subtle structure pattern to visualize the surface – in a similar fashion as it is already done for roads. And i introduced a distinct pattern to depict parkings with unspecified surface – which is what you see in the previous illustration. This results in a system of three design variations shown below.

Three variant surface rendering on parking polygons

Three variant surface rendering on parking polygons – click for double resolution rendering

The lack of a third unknown variant in surface tag depiction on roads has been a point of critique on OSM-Carto in the past. I have not tested if the pattern shown here is also viable for use on roads. It might be for the highest zoom levels on roads with a wider line signature. It works reasonably well on parkings i think.

Parking space details and garages

I ported rendering of amenity=parking_space from OSM-Carto and in addition also illustrate various secondary tags on those at z19+ with a subtle single symbol non-blocking pattern.

Single symbol patterns i introduced on leisure=pitch in a previous post. These are implemented using raster compositioning. Like with pitches i increase the size of the symbol shown if the polygon is larger for better readability – though for normal sized parking spaces at low to moderate latitudes this will only be practically used at z20+. And the same technique is used also to indicate buildings of the types building=garage/garages/carport – with building=carport in addition using the dashed outline that is already in use for building=roof.

Parking spaces with secondary tags and parking related buildings at different sizes

Parking spaces with secondary tags and parking related buildings at different sizes – click for double resolution rendering

If surface is tagged on amenity=parking_space this is rendered distinctly if tagged. If surface is not tagged the parking space inherits the surface from the amenity=parking it is located within.

Surface tagging on parking spaces with inheritance from enclosing parking

Surface tagging on parking spaces with inheritance from enclosing parking – click for double resolution rendering

The combination of single symbol pattern and inherited fill pattern needs to use an explicit query to determine the surface of the surrounding parking because it is not possible to render the single symbol pattern without a background fill color, i.e. transparently. Hence i need to re-fill it explicitly with the fill pattern of the parking area in those cases.

Note a color neutral casing is drawn around the symbols to improve readability in combination with the structure patterns. Practically the combination of an unpaved parking space with a specific function is, however, probably quite rare.

Implicitly mapped parking lanes and street-side parking

As i have shown in the first part of this blog post series the implicit mapping of parkings at the side of or on the side of roads through secondary tags on roads is not that widespread in numbers in OpenStreetMap so far. But this style of parking is very widespread in reality. In many parts of the world, urban residential areas make extensive use of parking on the side of roads and a large percentage of the overall urban parking space for cars is made up from this kind of parking along the side of roads. While in theory this could all be mapped explicitly with amenity=parking, using secondary tagging on roads is often a much more efficient and maintenance friendly way to map this. While it would be important for map styles with a mapper feedback function to support this style of mapping, only very few specialized maps do so.

I have now added support in the AC-Style for both implicit mapping variants. How this looks like in principle can be seen here.

Implicitly mapped parking lanes and street-side parking on residential roads

Implicitly mapped parking lanes and street-side parking on residential roads – click for double resolution rendering

The parking:*=street_side visualization is done together with the rendering of implicitly mapped sidewalks. Both can be used in combination and this also can be combined with implicitly mapped embankments.

Rendering of implicitly mapped street-side parkings (parking:*=street_side) in combination with implicitly mapped sidewalks and embankments

Rendering of implicitly mapped street-side parkings (parking:*=street_side) in combination with implicitly mapped sidewalks and embankments – click for double resolution rendering

Secondary attributes on parkings

The most significant enhancement in rendering of parkings i want to introduce here is the visualization of secondary tags on amenity=parking, amenity=bicycle_parking and amenity=motorcycle_parking. As mentioned in the first part these secondary attributes on parkings constitute one of the most extensive and most widely applied schemes of secondary tags in OpenStreetMap – and that despite these tags being only interpreted by very few maps so far.

The difficulty is that there are a lot of different tags for documenting different aspects of a parking area. The approach i took is using the technique of symbol augmentation that i discussed already in a previous blog post. In the previous use cases, symbol augmentation was used to visualize a single additional property in a flexible and context dependent way. Here i am taking this technique a step further to visualize a whole bunch of secondary attributes.

But before i get to the details of that i want to mention that i completely removed the rendering of name labels for amenity=parking. Name tags are only used on about 6 percent of all parkings and are rarely used for proper names, they typically contain either descriptions, reference numbers or names of other features the parking belongs to. And not rendering name labels for parkings makes space for showing more meaningful and more diligently and consistently applied tags.

I will start with an extension of the rendering of access restrictions on parkings. As shown in the first part, depicting access restricted parkings with a lighter symbol and label has been done in OSM-Carto for a long time. But it has also been bothersome that aggregating access=no/private and access=customers into a common styling is fairly non-ideal and you could even argue that in many cases a parking with access=customers is closer in meaning for the map user to a unrestricted access parking than to a private parking. I now tried to resolve this issue by visualizing customer parkings with an add-on symbol (a shopping basket) and not with a changed symbol and label color.

Fully access restricted (access=no/private) and customer parkings (access=customers)

Fully access restricted (access=no/private) and customer parkings (access=customers) – click for double resolution rendering

In addition i show a bunch of other commonly applied secondary tags.

Visualizations of different secondary tags with symbol augmentation on amenity=parking

Visualizations of different secondary tags with symbol augmentation on amenity=parking – click for double resolution rendering

Visualizations of different secondary tags with symbol augmentation on amenity=bicycle_parking

Visualizations of different secondary tags with symbol augmentation on amenity=bicycle_parking – click for double resolution rendering

Visualizations of different secondary tags with symbol augmentation on amenity=motorcycle_parking

Visualizations of different secondary tags with symbol augmentation on amenity=motorcycle_parking – click for double resolution rendering

So far, so simple – this is how a single add-on tag is shown. It gets more interesting if you combine several of these

Combinations of different add-on symbols on parkings at z19

Combinations of different add-on symbols on parkings at z19 – click for double resolution rendering

When all the different add-on symbols are used together it kind of drowns the main parking symbol. But keep in mind that a single parking will rarely feature all of the secondary tags in combination.

What i have shown so far is still in principle also feasible with symbol variations. You could generate a distinct SVG file for every combination of secondary tags and use that as symbol. This is what Andy Townsend for example does in his AJT style in a somewhat more abstract fashion for pubs.

Rendering variations for pubs in the AJT-Style based on different secondary tags

Rendering variations for pubs in the AJT-Style based on different secondary tags

The big advantage of symbol augmentations compared to that is that they are rendered independently from the base symbol. That means they can be blocked by other symbols with higher priority (which means all independent features in this case) individually. Furthermore, you can define fallback positions where add-on symbols can be placed when placing them at the preferred location fails.

Dynamic adjustment of add-on symbols to blocking feature symbols nearby

Dynamic adjustment of add-on symbols to blocking feature symbols nearby – click for double resolution rendering

I want to mention that this style of augmentation in a dense cluster of supplemental symbols around the base symbols is only one possible arrangement. Other, more structured configurations can be considered as well. Like a dynamic stack of symbols next to the base symbol.

Alternative arrangement of add-on symbols in a dynamic stack next to the base symbol

Alternative arrangement of add-on symbols in a dynamic stack next to the base symbol – click for double resolution rendering

The problem with any such non-compact arrangement is that if a different feature blocks parts of the secondary symbols the rest might not be intuitively readable as belonging to the base symbol they are meant for. And preventing such cases would require a relatively complex logic.

Keen observers will have noticed that the symbol for fee=yes is a coin shape with a currency symbol. The choice of currency symbol is subject to regional differentiation – the one shown here is the one for Yuan – which is due to the fact that my default location for abstract sample rendering is 100 degrees east, 40 degrees north – which is located in China. More details on this regional differentiation in the next post.

Real world examples

Here a few examples of how these changes look like with real world data. You can find further samples of the AC-Style in the sample gallery

Street side parkings in Strasbourg

Street side parkings in Strasbourg, tagged without parking=street_side, so with large symbols, partly with fee=yes, at z19

Street side parkings, bicycle parking and parking space for disabled people in Strasbourg at z19

Street side parkings, bicycle parking and parking space for disabled people in Strasbourg at z19

Supermarket parking lot in Strasbourg

Supermarket parking lot in Strasbourg at z19 with parking spaces somewhat redundantly individually tagged access=curstomers. Note the parking spaces for disabled people.

Parking lot in Strasbourg

Larger parking lot in Strasbourg with various secondary tags at z19

Motorcycle and car parkings in Sirmione, Italy

Motorcycle and car parkings in Sirmione, Italy

Various covered parkings in Strasbourg at z18

Parkings in Heidelberg at z19

Parkings in Heidelberg at z19

Various parkings in Portland at z18

Various parkings in Portland at z18

Parkings and implicitly mapped parking lanes on roads at z19 in Portland

Parkings and implicitly mapped parking lanes on roads at z19 in Portland

Implicitly mapped Street side parking and parking lane in Freiburg at z19

Implicitly mapped Street side parking and parking lane in Freiburg at z19

building=garage and building=garages in Freiburg at z19

building=garage and building=garages in Freiburg at z19

Discussion and Conclusions

Based on a specific thematic domain (parking) i tried demonstrating here how you can improve the information depth available in a map. I like to point out that i did not introduce the rendering of any new features here that were not already shown in either the AC-Style or OSM-Carto before. This is purely based on visualization of secondary tags and differentiation of features previously rendered in a uniform design.

The design techniques used are not new but were previously shown in the AC-Style and OSM-Carto. In particular

  • the use of structure patterns to differentiate rendering of polygons fills beyond what is possible with uniform colors.
  • the use of pictorial single symbol patterns to visualize semantic differences between features of a similar size in a subtle way without blocking other design elements.
  • the use of geometry processing to generate secondary linework around roads to visualize implicitly mapped properties in a way that automatically adjusts to the surrounding road network topology.
  • varying the symbol size and weight with zoom level to better be able to gradually adjust the visual weight of a certain type of feature in the map.
  • the use of Mapnik anchors to render aggregate symbols in a dynamic fashion.
  • the use of lookup polygons to spatially differentiate design, in this case currency symbols.

I want to address an argument that is likely going to be brought up against this idea of specifically increasing the depth of information in a map (i.e. more differentiation of features shown and display of additional properties of these features) in contrast to increasing breadth (i.e. rendering additional features so far not shown).

That argument is that in digital maps such information can be better provided on explicit inquiry by the user through an interactive interface and should not be part of the map, which should focus on breadth (the existence of features and their basic classification) rather than depth.

Although i acknowledge the value of interactive extensions of maps, i very strongly disagree with the idea of restricting the sophistication in map design and the depth of information communicated in maps based on the idea that this is being replaced by information provided only on active request by the user. From an attention-economical standpoint this makes total sense of course. But i think it fails to recognize that one of the fundamental ideas of cartography and one of the main reasons why maps have fascinated and attracted so many people throughout human history is that they are a source of information on the geography that is fully accessible by passive observation. If you degrade the map to a UI background of an interactive geo-database query application you essentially remove this key aspect of maps that has historically been essentially universal to all general purpose maps ever produced.

Why is this aspect of maps – to be able to access the full information content of the map through passive visual observation – so important for the ergonomics of map use? Largely because it resembles the process how we learn about our environment in reality. We do not have to tap on a street sign to be able to see the name of the street. We do not normally have to knock on the door of a convenience store for it to reveal itself as such to us. And we do not typically have to enter a parking lot to be able to see that it has parking spaces reserved for disabled people. As humans, learning about and mentally mapping our environment through visual observation is an ability we develop and train from a very young age. The ability to permanently manifest such mental mapping in physical form and to share this with others and to allow them to acquire this geographic knowledge through equally passive visual observation but without the need to be at the place in question physically is what map making is ultimately all about.

Being able to visually access all the information of a rich map does not only provide an intuitive low effort way to this information, I also learn much more about the geography of the area i am observing in passing without specifically looking for it – including in particular learning about things i am not aware up front that they even exist. And this casual learning even taps substantially into the subconscious – when studying a map we tend to learn things about the geography without even being aware of seeing them.

You would be cut off from all of these things when geographic information is accessible only on explicit user action from an interactive application.

Of course selecting and filtering information, deciding on what to show and what not to show, is still fundamentally necessary when you design maps. And if the information i introduced visualization techniques for here is something good to include in a general purpose map is a valid topic of discussion. Personally, as someone who does not own a car and who relatively rarely drives a car these days, i do not put a strong emphasis on parking infrastructure. But i recognize (and the numbers of mapping in OSM i have shown support this) that this is a subject of substantial interest for many people in many parts of the world.

So much on my recent parking related work on the AC map style. In the third part of this series of blog posts i am going to discuss a few things not directly related to parking that came up during development of these changes.

Aerial image of parking spaces

December 23, 2023
by chris
1 Comment

The world of parking

Parking of vehicles that are not in use is one of the most peculiar aspect of our present day societies dominated by individually owned automobile transport. Typical numbers quoted for the time cars – on average – spend in parking are 23 hours per day or 95 percent of the time. Studies on surface area use show something around 5 percent of urban areas are used for parking in the US (detailed stats for the US per county can be found here).

At the same time, awareness of this significance of automobile parking is not that high in our society. And this is also reflected in cartographic practice. Roads, that is structures for moving automobiles (where the average car spends around five percent of its time), are typically very prominent in maps while parking infrastructure is frequently marginalized.

Explicit mapping of parking infrastructure in OpenStreetMap

OpenStreetMap is no exception here – though relative to other maps and map databases parking structures have a higher weight in OSM. They are still under-represented relative to their significance in urban geography, but they are less marginalized than in traditional maps.

The most important tag to explicitly represent parking infrastructure is amenity=parking. This tag is essentially used for any place where two-tracked automobiles are parked on a regular basis. This ranges from a few small parking spaces in front of a shop over a strip along the side of a road where cars are routinely parked to a big parking lot with hundreds of spaces. amenity=parking is used more than five million times in OpenStreetMap, that is within the top 30 most commonly mapped feature types – within the top 15 if you aggregate the different variants of roads and buildings into a single feature type.

As said amenity=parking is for two-tracked automobile parkings, for bicycles and motorcycles there are separate primary tags (amenity=bicycle_parking and amenity=motorcycle_parking). And while amenity=parking is predominantly used on polygons, the latter two are predominantly mapped with nodes.

Other primary tags used for infrastructure for parking vehicles are:

  • amenity=parking_space is used for mapping the specific area where cars are parked within an amenity=parking
  • amenity=parking_entrance is used for mapping an entrance to an underground or multi storey parking facility
  • landuse=garages is used for areas with privately operated buildings in which cars are parked (garages)
  • building=garage is used to map individual privately operated buildings in which a single car is parked
  • building=garages is used to map buildings with separately accessible individual parking spaces for cars
  • building=carport is used to map weather protection roofs above individual parking spaces

Here the use numbers of these tags in the OSM database:

tag total polygons nodes
amenity=parking 5.2M 4.8M 393k
amenity=bicycle_parking 618k 525k 93k
amenity=motorcycle_parking 34k 22k 12k
amenity=parking_space 2.3M 2.2M 116k
amenity=parking_entrance 186k 631 185k
landuse=garages 82k 82k 36
building=garage 6.6M 6.6M 2k
building=garages 875k 874k 492
building=carport 196k 196k 48

Implicit mapping of parking in OpenStreetMap

In addition to the tags discussed so far, OpenStreetMap also quite extensively maps parking infrastructure implicitly on roads. This is most commonly done through

tag use
parking:both=lane 27k
parking:both=street_side 6.4k
parking:left=lane 13k
parking:left=street_side 7k
parking:right=lane 18k
parking:right=street_side 9k

As you can see, this method is much less commonly used than the explicit mapping methods overall. The numbers are, however, not insignificant, and for parking lanes on the road this method is at least similarly widespread compared to explicit mapping.

Rendering in OpenStreetMap Carto

OSM-Carto, like nearly all other map styles, so far only renders explicit forms of mapping parkings. Here is how this looks like at the highest zoom levels:

Parking infrastructure rendering in OSM-Carto and in the current version (right) as well as version 1 (left)

In the early days of OpenStreetMap, amenity=parking was shown significantly more prominently than it is today. While the yellow used was similar to both tertiary roads and natural=beach, it typically allowed for a fairly good identification of areas covered with parking lots in an urban environment. The current generic gray color, however, is much less identifiable and identical to the color used for living streets. Most other OSM map styles use a similarly muted (or even weaker) coloring for parking polygons – though they vary significantly in the weight of point symbols used.

In the AC-Style i have struggled for some time with selecting a suitable color for parkings during my color reorganization work. Ultimately i chose a bright, low saturation orange with a stronger orange outline. This – in combination with the violet used for transportation symbols – produces a very distinct look for parking features while also harmonically integrating with the color scheme for roads.

Parking infrastructure rendering in the AC-Style until now

As you can also see, i had not yet ported the more recent additions of rendering of amenity=parking_space and amenity=parking_entrance in OSM-Carto to my style.

Secondary Tags

The really interesting thing about mapping of parking infrastructure in OpenStreetMap is, however, the wealth of secondary tags that are used for further characterizing parking features – both on the parking infrastructure features listed above and on roads for implicit mapping of street side parking.

Mappers in OSM have not only developed detailed tagging schemes for these (in particular here) – some of these secondary tags are also applied in remarkable numbers despite being shown on hardly any maps. In that regard parking infrastructure mapping competes with road characteristics (where secondary tags are, however, also used for routing purposes) and natural=tree (where i introduced a detailed rendering system for secondary tags some time ago).

The only secondary tags for parking infratructure that are so far interpreted by OSM-Carto are access tags indicating restricted access (which have been shown with a different symbol and label color already in version 1) and the parking=* tags – which are used to display a smaller symbol for parking=lane and parking=street_side and for differentiating amenity=parking_entrance in underground and multi-storey parkings.

In the next post i am therefore going to introduce some new rendering concepts for visualizing other secondary attributes on parking infrastructure that are commonly mapped in OpenStreetMap and well as concepts for visualizing implicitly mapped parking infrastructure.

Source of header image: Swiss Bundesamt für Landestopografie swisstopo.

No OSMF analysis this year

November 16, 2023
by chris
0 comments

No OSMF analysis this year

The annual general meeting of the OpenStreetMap Foundation is approaching and some readers probably expect me to write about the last year in the OSMF and present an outlook on future developments. I do not plan to do so this year though and i want to explain a bit the background of this.

It is not that nothing i could write about happened in the OSMF in the past year – on the contrary, there were plenty of remarkable decisions made that would deserve a more elaborate discussion. But as the year went on and my collection of material on the matter grew i noticed that – while the way the OSMF is developing as an organization and sociologically remained fascinating – the perspective to write publicly about it in autumn in the form of an overall yearly review and lookout before the AGM seemed increasingly unattractive. This has led me to reflect a bit on why i write about these things.

I will start with a concrete example: In last year’s analysis i described an incident were a money spending decision was made in explicit and ostentatious disregard of the conflict of interest of one board member and i was struggling to understand how this happened without any of the other board members raising concerns. Of particular interest was the question if the board members were collectively unaware of the problem or if they noticed it but rationalized for themselves that there is no need to act on that problem. As a result of that i carefully observed similar cases this year of money spending decisions being made with board members subject to conflicts of interest. And based on that i now think i have a much better understanding about the social dynamics and the mindset of board members in such situations.

Me writing about these kind of observations here on the blog would probably quite significantly increase awareness of these matters from just a handful of people actively observing the OSMF to maybe a few hundred. But that is not enough to affect meaningful change in the OSMF – even if all of these would roughly share my concerns and ideas for improvements. And this is not a matter of limited reach but a matter of lack of interest.

Generally speaking, i do not mind writing for a small audience – if i did you would not see posts about map design and other things here. The difference is that these things have real world significance way beyond the circle of readers they reach at the moment. Commentary on the organizational developments and governance of the OSMF, however, only has relevance within the small world of the OSMF – unless of course you are looking at it from a organizational sociology standpoint with the OSMF as a case study. But i am not a sociologist. While intellectual curiosity about the social dynamics in an organization like the OSMF is one of the things that motivates me to observe the OSMF, i do not have the ambition to systematically publish my observations.

This does not mean i am going to completely stop writing about the OSMF. But as i previously have moved from real time commentary on acute OSMF matters to aggregate yearly analysis a few years back i am probably going to further move to focus on discussing long term developments with a multi-year horizon on a case-by-case basis. With that i would also pretty much adjust to the mode of discussion prevalent in the OSM community at large regarding the OSMF these days. Discussion on acute OSMF topics on channels with a public record has essentially ceased, so has meaningful pre-election discussion before the AGM. But there have been valuable irregular comments from others who – like me – keep an eye on and analyze OSMF politics. Like, for example, recently the insightful comments from Ilya and Simon.

This is the level on which meaningful discourse in the OSM community on OSMF matters tends to happen these days and where a valuable exchange of different views and perspectives is possible.

One other decision i have made in context of this is that this year i applied for active contributor membership in the OSMF. I had been struggling for quite some time with the moral implications of contributing to the OSMF finances – even if only on a very small scale – in light of the OSMF money spending habits and oversight mechanisms being massively at odds with what i deem minimally necessary. The active contributor membership gives me a way out of that dilemma. I am aware that this of course does not absolve me from the responsibility resulting from legitimizing the OSMF’s actions simply by being a member.

But i don’t want to create the impression here that everything is bad about the OSMF these days – no, there are both positive and negative developments in the past and there is potential for positive and negative developments in the future. And as far as bad decisions are concerned – these are not exclusively the fault of those making them originally, they are just as much a problem of the failure of the OSMF members to exercise responsible oversight and control.

To not leave the readers without anything of substance actually on the OSMF – here a short comment to wrap up this post.

Ilya in the comments linked to above diagnoses a communicative disconnect between the OSMF and the Overture Consortium and i would say a similar, probably even more fundamental, disconnect exists between the OSMF on one hand and the OSMF membership and the OSM community on the other. Like in the OSMF-OMF case this disconnect cannot be fully blamed on one side, it is a two-sided lack of understanding of each other and a lack awareness and acknowledgement of their problems and interdependencies.

But the key point here is that the big corporations the Overture consortium is composed of and the OSM community at large can much better afford to ignore other actors in the field communication wise. For big corporations this is simply the way they are used to. And for the OSM community being self sufficient was, back in the days when OpenStreetMap started, simply a necessity to emancipate itself from traditional geodata production. The OSMF on the other hand absolutely cannot afford a communicative disconnect with either the OSM community or their commercial environment (or even misunderstanding economic developments in its neighborhood – like the OMF or HOT). Yet, what the OSMF largely seems to be doing for the last years is digging itself in more and more with the small circle of people whose work we know and enjoy. And even though some people in the OSMF seem to start to realize how disastrous this is, the ideas to address this problem seem to go towards more corporate style PR and community management (i.e. trying to actively shape how others see them) rather than trying to understand their larger social and economic environment as it is.

Coastal geomorphology for mappers in OpenStreetMap

October 24, 2023
by chris
6 Comments

Coastal geography for mappers in OpenStreetMap

I have written about the mapping of the physical geography of coasts in OpenStreetMap before several times. However, when i see people discussing coastal mapping these days and editing the OpenStreetMap wiki i still frequently get the impression that – while discussion contributions are usually well intended – they unfortunately all too frequently seem to be – well – fairly uninformed. Discussions often lack relevant background equally in terms of present day mapping practice (a matter which i also discussed more in depth in broader terms), the history of mapping in OpenStreetMap and concerning actual geography.

Which is why i feel like it might be a good idea to provide a solid background on the very basics of coastal physical geography mapping in OpenStreetMap – which i am going to attempt doing here.

Current coastal mapping conventions in OpenStreetMap

I will start with describing what the currently most widespread mapping practice is in OpenStreetMap for mapping and tagging basic coastal features. And i will use the rendering from the Alternative-Colors style here for illustration because it is more descriptive for coastal features. You can see the OSM-Carto variant when clicking on the images. Of course there is a large variety of different coastal settings with dozens of different tags, in particular if you include vegetated coasts. So i will only cover the very basics here. First, lets look at a setting with a relatively low tidal range, strong waves and a relatively steep slope of the coast:

Wave dominated sandy coastal setting

Wave dominated sandy coastal setting

As most mappers will know, the coastline is placed at the high water mark (that is the highest level of water regularly reached during the tidal cycle). In the map examples shown this is the line between the bluish parts on the left and the yellow/gray areas on the right. The low water mark (lowest level of water regularly reached during the tidal cycle) is not necessarily explicitly mapped because it is practically not well verifiable – but for clarity i marked it here in the illustrations with an administrative boundary (which in many jurisdictions happens to be located at the low water mark).

What we have here is a wave dominated setting and a sandy beach. This is mapped in OpenStreetMap with natural=beach and surface=sand – which does not imply recreational use, it is purely a physical geography characterization. What is tagged natural=beach is the whole range covered by loose material that is shaped primarily by waves. In such a setting that range extends from slightly below the low water mark to slightly above the high water mark. Any area of loose sand above the high water mark that is not primarily shaped by water waves but by wind is by current conventions in OpenStreetMap not tagged natural=beach but natural=sand. Some mappers split the mapping of the beach at the coastline and tag the lower part in addition with tidal=yes. This does not provide any additional information, but it does not hurt either.

Practically, when mappers map remotely based on aerial/satellite imagery, the beach is often mapped downward only to the waterline of the moment as depicted in the image – and in case mapping is coarse or the image quality is insufficient for more precise placement, the coastline is also placed at this (typically too low) location. Still current mapper consensus about how things should be mapped ideally is clearly as described.

Sand areas below the low water mark that are permanently covered by water are typically tagged (as far as mappers have knowledge of that) with natural=reef + reef=sand.

The same scenario is of course also possible with the beach composed of coarser material – like surface=gravel or surface=shingle.

How do things look like in a more tidally dominated setting (more gentle slope of the coast overall, stronger tides and less strong waves)?

Tide dominated sandy coastal setting

Tide dominated sandy coastal setting

In this scenario you typically still have a beach at the upper end of the tidal range – but it tends to be fairly narrow – or even can be fully absent in cases where waves are negligible or the coast is vegetated. Below that, in the tidal range, you can typically find a tidal flat, an area with very gentle slope consisting of fine grained loose material (mud or sand) that is shaped primarily by the tidal currents rather than waves. This area is by current convention tagged natural=wetland + wetland=tidalflat, sometimes with an additional surface tag (surface=sand or surface=mud).

In case of rocky coasts there is no distinction between above and below the high water mark in terms of primary tagging – natural=bare_rock is used in the tidal range just like on land.

Rocky coastal setting

Rocky coastal setting

History of coastal tagging

What i have described above is the currently most widespread practice of mapping coastal physical geography in OpenStreetMap. Most mappers evidently find this suitable for the most part, but there is quite a bit of variation and edits on the OSM wiki and comments made in various settings also indicate that some mappers find this practice undesirable or confusing. To understand this it is helpful to look at the history of tagging in OSM – because what i sketched above has not always been how coastal land forms are mapped in OpenStreetMap.

As most people know, OpenStreetMap started in the United Kingdom and in the UK the traditional cartographic conventions for representation of coastal forms distinguish not between different geo-morphological settings but exclusively between different surface materials. Tidal areas are classified as either sand or mud – as you can see here in the map keys of two different Ordnance Survey maps:

Legend from Ordnance Survey map 1:25k from 1966

Legend from Ordnance Survey map 1:25k from 1966

Legend of contemporary Ordnance Survey map 1:50k

Legend of contemporary Ordnance Survey map 1:50k

This concept was reproduced in the very early mapping practice in OpenStreetMap with natural=beach and natural=mud. Of the tags discussed these were the most widespread in use until about 2011. These two tags were, for use in the tidal range, in particular also promoted by the standard map style, which showed them both with a regular dot grid pattern.

natural=beach/natural=mud rendering in OSM-Carto version 1

natural=beach/natural=mud rendering in OSM-Carto version 1

Use of other tags, in particular natural=wetland + wetland=tidalflat and natural=sand became popular only somewhat later. Coastal mapping outside the UK almost exclusively used natural=wetland + wetland=tidalflat for both sandy and muddy tidal flats and natural=beach was not adopted significantly as a general tag for sandy areas in the tidal range outside the UK but was more strictly limited to beaches in the geo-morphological sense (as well as artificially created sand stretches at the shorelines of lakes and the sea). In the UK, use of natural=beach for larger flat areas in the tidal range was disputed quite early as well with some mappers preferring to adopt the continental European practice of using natural=wetland + wetland=tidalflat in general while others pushed for maintaining the mud-sand duality from Ordnance Survey maps on the level of primary tagging and to use natural=wetland only for muddy tidal flats while using natural=sand for sandy flat areas in the tidal range.

The use of natural=sand in the tidal range stayed a niche exotic use outside the UK so far despite some wiki-fiddlers trying to push this as the universal ought-to-be tagging. It gained some adoptions in regions with a mixture of sandy and rocky tidal areas, because – as described above – on rocky coasts mapping consensus is to use natural=bare_rock both in the tidal range and for dry rock above the high water mark and it can seem plausible to use natural=sand in analogy. Most mappers, however, seem to consider it better not to use the same primary tag for the geo-morphologically fairly contrasting settings of coastal dunes and sandy tidal flats and consider natural=wetland + wetland=tidalflat a suitable tagging for sandy tidal flats – with the option to specify that via surface=sand.

Practical examples

So far, i have discussed coastal mapping here on a fairly abstract level. So i will provide a few practical examples to illustrate what i explained above and to show in how far practical mapping in OSM consistently follows these conventions and where it sometimes diverges.

All examples are shown with a photo – linked to a larger version on an external site – and a map screenshot from OSM-Carto showing the current mapping in OpenStreetMap and linked to osm.org where you can inspect it in more detail. Be aware that the direction of view in the photos is not universally northwards so the photo and the map typically have different orientation.

First a classical wave dominated beach:

by Bin im Garten - CC-BY-SA 3.0

by Bin im Garten – CC-BY-SA 3.0

This example is a bit special because the sand is artificially groomed for recreational use, making it difficult to identify the upper end of the beach and the high water mark. The mapping correctly represents the existence of wind shaped stretch of loose sand above the beach. It does not extend the beach mapping below the high water mark, which is quite common though, as already mentioned above.

OSM-Carto map screenshot

Next example is equally a wave dominated beach:

by dronepicr - CC-BY 2.0

by dronepicr – CC-BY 2.0

Here mapping and tagging are based on imported data and therefore do not match manual mapping conventions in OpenStreetMap that well. The natural=beach mapping includes the non-vegetated parts of the coastal dunes. On the other side the beach ends at the high water line and the tidal part of the beach is mapped with natural=wetland + wetland=tidalflat – though the image shows quite clearly a wave formed beach, at least down to the water level shown in the photo.

OSM-Carto map screenshot

The next two examples are more edge cases between a wave shaped beach and a tidal flat shaped by tidal currents.

by UK Environment Agency - OGL 3.0

by UK Environment Agency - OGL 3.0 by UK Environment Agency – OGL 3.0

OSM-Carto map screenshot
OSM-Carto map screenshot

Both are mapped with natural=beach – above and below the high water line. A good argument can be made though that this is more fitting for natural=wetland + wetland=tidalflat + surface=sand as you can see substantial structuring of the surface due to tidal currents. In addition, the coastline in the second of these two samples is placed too low, significantly below the high water line, probably because it was mapped from images based on the water level of the moment as shown in those. In the first case the mapping of the beach reaches too far upwards into the vegetated areas.

Much more clearly a tidal flat setting can be found here:

by UK Environment Agency - OGL 3.0

by UK Environment Agency – OGL 3.0

which mapping accurately represents with natural=wetland + wetland=tidalflat + surface=sand.

OSM-Carto map screenshot

An even clearer case is this example

by Bundesanstalt für Wasserbau - CC-BY 2.0

by Bundesanstalt für Wasserbau – CC-BY 2.0

which directly matches the tidally dominated setting sketched above – though the mapping here conflates the lower end of the beach and the beginning of the tidal flat with the high water mark. The photo, however, clearly shows that the transit from the wave shaped beach to the tidally shaped flat is significantly below the high water line.

OSM-Carto map screenshot

Another somewhat different example is here – where the (unmapped) beach is very narrow and cut short at the upper end by a constructed dyke:

by Bermicourt - CC-BY-SA 3.0

by Bermicourt – CC-BY-SA 3.0

OSM-Carto map screenshot

So far these were ground level or oblique aerial photos. I want to close with an orthophoto example, providing some hints how the delineation between a wave shaped beach and a tide shaped tidal flat can be practically made when mapping from imagery.

by IGN France

by IGN France

The beach here is currently not mapped but can be well seen on the image. Typically, waves create structures parallel to the coast while tidal currents produce structures orthogonal to the coast roughly in direction of the coastal slope. Also beaches with their stronger slope often drain water faster at low tide and do not remain waterlogged as much as tidal flats at low tide – which will often lead to different coloring on images. The most reliable source of information is, of course, always observation on the ground.

OSM-Carto map screenshot

Conclusions

The obvious question some will probably ask is why does the OSM community not adopt the Ordnance Survey convention to distinguish by surface material only and not by some fairly specialized geo-morphological classification? There are several reasons that probably play a role here:

  • Most mappers consider the distinction between different geo-morphological forms (beaches, tidal flats, coastal dunes etc.) as more meaningful than the distinction between different surface materials.
  • In remote mapping from aerial/satellite imagery, the distinction between beaches and tidal flats as geo-morphological forms can often be made with careful observation of the images while the distinction by surface material cannot.
  • In most regions on Earth, sand and a mixture of sand and finer material are more common as surface material of tidal flats than mud, making the geo-morphological classification simply the only meaningful distinction that can be made.

The more relevant point i am trying to make here is, however, that this example illustrates well how developing globally uniform tagging conventions in OpenStreetMap is hard, in particular because of pre-existing diverging cartographic conventions in different parts of the world. Although OpenStreetMap has a free form tagging system and deliberately is not based on institutional data models and classifications, those still tend to color tagging ideas in the project. I hope this example shows how not sticking to a specific cartographic tradition but opening up to more diverse mapping and tagging ideas from all over the world, developed by people based on how they perceive the local geography, helps to develop a more differentiated way to see and document the diverse global geography.

And i also hope that the desire for simplicity and the prioritization of data volume over data depth, that is understandably felt and expressed by many mappers these days, does not lead to a rolling back of these substantial achievements in the name of ‘modernization’ – as we have unfortunately seen all too often already in OpenStreetMap.

Augmented symbols for bus stops with shelters

October 9, 2023
by chris
4 Comments

Symbols and labels #3 – augmenting symbols

In the previous post i discussed how a relatively simple feature addition to Mapnik called anchors, which allows conditionally connecting the rendering of some visual elements to that of other elements in the map in a freely customizable way, can help solving the basic dilemma of combined symbol and label visualizations of point features.

But these anchors are useful for more than that – among other things for augmenting symbols.

I have already demonstrated augmented symbols in the past in a very rudimentary fashion for water features with a drinking water attribute. The technique as shown there was rather limited and essentially this was just a basic proof of concept for the visual design idea.

rendering of water sources introduced back in 2018

Augmenting symbols with anchors

The idea of symbol augmentation is that you have a pictorial/geometric symbol in the map visualizing a certain point of interest and that you add a supplementary design element to that symbol to illustrate either additional attributes of the feature in question or to provide information about other data in the geometric context.

The difference to a symbol variation, where you vary the symbol used from a common base design – like it is shown for example in the example above for intermittent and hot springs – is, that symbol augmentations are optional, they are rendered only when there is space for them and the non-augmented symbol, while providing less information, still illustrates the fundamental nature of the feature in question.

The idea with the water POIs is to indicate that a spring/well/fountain provides drinking water with a supplemental beaker symbol, as it is used also for the generic primary tag amenity=drinking_water (see above).

In many cases the design of base symbol and augmentation allow for a number of different relative placements – which can be prioritized based on where other symbols block space – as shown here:

or based on other geometric context – like in case of connected springs:

Augmentation of springs connected to streams at z19

Augmentation of springs connected to streams at z18

Augmentation of springs connected to streams at z17

Augmentation of springs connected to streams at z16

Augmentation of springs connected to streams at z15

Augmentation of springs connected to streams at z14

Technically, a number of things are necessary to make this work well and be flexible in terms of symbol design:

  • Priority of the augmentation needs to be adjustable independent of the base symbol.
  • Overlap of the augmentation and base symbol needs to be possible without blocking.
  • It needs to be possible to specify the relative placement of the augmentation in all the variants precisely.
  • It needs to be possible to use different symbol designs in different relative placements.

Existing possibilities in Mapnik do not provide the means for this. How anchors can be used to accomplish that i will show in the following.

Like with the symbols and labels rendering, the base symbol is rendered with

marker-anchor-set: '[osm_id]';

The rendering of the beaker symbol in a separate lower priority layer naturally in the first placement variant gets the already known

marker-anchor-cond: '[osm_id]';

but in addition also

marker-allow-overlap-anchor: '[osm_id]';
marker-anchor-set: "'dw_'+[osm_id]";

marker-allow-overlap-anchor is a selective allow-overlap, meaning that rendering allows overlaps of this symbol with any already rendered symbols with the specified anchor. The second line sets another anchor for the augmentation symbol. This is then used as a condition in subsequent placement variants:

dir2/marker-anchor-cond: "[osm_id]+',!dw_'+[osm_id]";
dir2/marker-allow-overlap-anchor: '[osm_id]';
dir2/marker-anchor-set: "'dw_'+[osm_id]";

This means that rendering of this second placement variant is conditional to (a) the successful rendering of the base symbol and (b) the first placement variant of the augmentation symbol not having been successfully placed.

In addition, for connected spring rendering, the SQL query sorts the different placement variants in priority based on the direction of the connecting waterway – resulting in the behavior illustrated above.

Here a few real data examples illustrating how this looks practically:

Well at z19

Well at z19

Well at z18

Well at z18

Connected spring at z19

Connected spring at z19

Fountain at z19

Fountain at z19

Aggregating features with augmented symbols

That was how symbol augmentation can be implemented with anchors in the very simple case that the augmentation visualizes exclusively a certain secondary tagging on the features in question (amenity=drinking_water or drinking_water=yes on natural=spring/man_made=water_well/amenity=fountain). I will now show and explain how this concept can be extended to aggregate different close-by and semantically connected features.

The case i want to demonstrate this on is bus stops and shelters. Bus stops in OpenStreetMap are tagged with highway=bus_stop. If the bus stop has a shelter for protection of waiting passengers against the weather this can be tagged with

  • a separate feature (node or polygon) representing the shelter tagged amenity=shelter (optionally with shelter_type=public_transport)
  • or a secondary tag shelter=yes on the highway=bus_stop node
  • or both

In many cases the bus stop and the shelter are very close to each other so there is no room at the lower zoom levels to render both with a dedicated symbol without displacement of either. In OSM-Carto in addition amenity=shelter has priority over highway=bus_stop in rendering so you see a lot of shelters but not a lot of bus stops at z16/z17.

A viable solution is again to use symbol augmentation. Here is how this looks like at z16:

Bus stops and shelters at z16

From left to right: (1) amenity=shelter (2) amenity=shelter + shelter_type=public_transport (3) highway=bus_stop (4) highway=bus_stop with either shelter=yes or separate amenity=shelter nearby

and at z17 and above:

Bus stops and shelters at z17

Bus stop rendering with augmented symbols at z17 and above – see text for detailed explanation

From left to right this shows:

  • amenity=shelter
  • amenity=shelter + shelter_type=public_transport
  • highway=bus_stop
  • highway=bus_stop with separate node tagged amenity=shelter nearby
  • highway=bus_stop with separate node tagged amenity=shelter + shelter_type=public_transport nearby
  • highway=bus_stop with separate node tagged amenity=shelter + shelter_type=public_transport nearby and nearby other symbol blocking default placement of symbol augmentation
  • highway=bus_stop with secondary tag shelter=yes and with separate node tagged amenity=shelter + shelter_type=public_transport nearby

The last four are shown on top with the shelter node so close that there is no space for both symbols, hence resulting in the augmented symbol rendering, and on bottom with the shelter node far enough away for a separate rendering. In the last variant on the right this version shows the non-augmented bus stop symbol because the shelter is close enough to be recognized as the shelter of this bus stop explicitly representing the implicitly tagged shelter=yes – while in the third variant below, the shelter node is so far away that it is no more recognized as belonging to the bus stop – hence the shelter=yes leads to the augmentation.

Implementing this with anchors in Mapnik requires the query for the add-on symbols to provide both the osm_id of the bus stop and that of the closest nearby shelter (as osm_id_shelter). This is then used for the first placement variant of the augmentation symbol like

marker-anchor-cond: "[osm_id]+',!'+[osm_id_shelter]";
marker-allow-overlap-anchor: '[osm_id]';
marker-anchor-set: "[osm_id]+'_'+[osm_id_shelter]";

meaning to

  • only render the augmentation symbol if the base symbol has been successfully rendered and if the standalone symbol for the shelter has not. For only implicitly mapped shelters, osm_id_shelter is set to zero so this second condition is always met in those cases if no explicitly mapped shelter is nearby.
  • Allow the augmentation symbol to overlap with the base symbol.
  • Set a new anchor concatenating the bus stop id and the shelter id.

For the second placement variant (augmentation on the right) the anchor condition is then obviously extended to

alt/marker-anchor-cond: 
  "[osm_id]+',!'+[osm_id_shelter]+',!'+[osm_id]+'_'+[osm_id_shelter]";

meaning that this marker is only rendered if

  • the corresponding base symbol has been successfully rendered,
  • the shelter has not been successfully rendered as a standalone symbol,
  • the previous placement variant(s) have been non-successful

Why do we include both the bus stop id and the shelter id in the anchor? Because we want the same shelter to potentially serve for several bus stops and they need to have different anchors in both augmentations for that to work. For bus stops this is practically not a common arrangement but for tram stops and railway halts this is quite common when both directions of transport share a common platform with a single shelter (the 2+1 variant below).

Augmented symbols for railway halts and tram stops

Augmented symbols for railway halts and tram stops

And here finally a few example of how this looks like with real world data.

Bus and tram stops in Strasbourg at z16

Bus and tram stops in Strasbourg at z16

Bus and tram stops in Strasbourg at z17

Bus and tram stops in Strasbourg at z17

Bus stops in Strasbourg at z18

Bus stops in Strasbourg at z18

Conclusion

What i showed here is how symbol augmentation can be used as a technique to transport additional information in a map in an intuitive way in cases where space is scarce and there is not enough room to depict everything through atomic and static point symbols. Doing this in a proper way requires support from the rendering tools and i demonstrated how the low level feature of anchors i added to Mapnik can help with that.

As mentioned in the previous post already these anchors implement only part of point 5 in my list of features map design would like to have from the tools it uses. At the same time what i showed in this and the previous blog post barely scratches the surface of what can be done with this relatively minor additional feature. This should give you a bit of an idea how we are in automated rule based map design – figuratively speaking – barely at the threshold towards the Neolithic.

Symbols and labels #2 – making a connection

October 7, 2023
by chris
0 comments

Symbols and labels #2 – making a connection

I could not be at the Karlsruhe Hack Weekend this time, but i did some hacking work during that and the following week i wanted to write about here. Back in May i discussed in depth the problem of visualizing points of interest in automated rule based maps with symbols and labels in combination. I want to revisit that problem now.

In a nutshell – what i discussed back then was, that you can approach the problem primarily in two ways:

  • separately rendering the symbols and labels, typically with the symbols having higher priority than the labels.
  • connecting the label and the symbol for every feature and render them with the same priority (typically via shield symbolizer in Mapnik)

Both approaches have advantages and disadvantages – as discussed and demonstrated in that post. The bottom line is – quoting what i wrote back then:

What we would really like instead is rendering the symbols as in the first approach but then render the labels only for those features for which a symbol has been successfully rendered. This, however, is not possible with the current tools.

I have tried to work on this dilemma now by extending Mapnik with the possibility to connect two different independently rendered elements in the map – making the rendering of an element (like a label or a marker) conditional in some form on if other elements have been (or have not been) successfully placed before.

Introducing anchors

The reason why this kind of functionality is not available in Mapnik so far is probably because Mapnik mostly aims to provide higher level features to connect different elements in the form of what is called group and shield symbolizers (to tie several elements to be either rendered together or not at all) and placements (to try several alternative labeling/symbol placement options). But those are practically severely limited in the level of control they provide to the map designer and they do not allow connecting elements independent of their priorities.

Mapnik’s internal design is fairly complicated and very sparsely documented so what i implemented is surely not very elegant and in many ways not how it should be done. Be that as it may – i will try to explain the feature and how it works in its CartoCSS syntax. For setting up Carto with the new feature you also need an updated mapnik-reference.

The feature is called an anchor – which is a string you can assign to any blocking element you render (point, marker and text symbolizers) – either statically or based on data properties via expressions. With an osm2pgsql PostGIS database the most straight away attribute to use is the osm_id.

So with the separately rendered POI symbols and labels the symbols get something like

marker-anchor-set: '[osm_id]';

which means: When this marker is successfully placed (i.e nothing previously rendered is blocking it) record its osm_id attribute in the list of elements successfully placed. osm_id of course has to be added to the SQL query for the layer.

When you later, after having placed all the symbols, want to place the matching offset labels as far as there is space left and want to avoid placing labels for features for which no symbol has been successfully placed you use

text-anchor-cond: '[osm_id]';

which means: Only place this label if its osm_id attribute is in the list of anchors of elements successfully placed before. If you want to – in case no symbol could be placed – try to render a centered non-offset label for the feature in question you use

textonly/text-anchor-cond: "'!'+[osm_id]";

which means: Only place this label if its osm_id attribute is not in the list of anchors successfully placed before.

Practical results

As you can see this is pretty simple to use – and it solved our symbol and label rendering dilemma quite nicely. For reference here the two variants offered by the AC-style so far – first the symbol and label separate version (similar to OSM-Carto, but with consistent priorities):

AC-Style with separately rendered symbols and labels

AC-Style with separately rendered symbols and labels AC-Style with separately rendered symbols and labels

and in the combined version:

AC-Style with combined symbol and label placement

AC-Style with combined symbol and label placement AC-Style with combined symbol and label placement

which has the main disadvantage that the labels of high priority features block the symbols for lower priority features – hence no shelters on the right side in the second sample image.

With the help of the new Mapnik feature the separate version combines the benefits of both:

separately rendered symbols and labels connected via anchors

separately rendered symbols and labels connected via anchors separately rendered symbols and labels connected via anchors

On the very right you can see that the higher priority wilderness hut does not prevent the shelter symbol from showing because its label is not rendered together with the symbol but placed later with lower priority. At the same time it avoids the problem of stray offset labels without a corresponding symbol as it happened previously when rendering symbols and labels separately.

That’s it essentially – a relatively simple extension of Mapnik solves the dilemma of combined point symbols and labels that bugged OSM-Carto for almost exactly ten years now.

In terms of the list of desirable features of map design tools i published recently this implements parts of point 5 by the way.

But of course the concept of anchors in Mapnik and making the rendering of elements conditional on one another in a freely definable way can be used for other things as well. More on that in the next post.