Openstreetmap-carto: Add extender arrows for rich cartographic detail in dense places

Created on 16 Jun 2020  路  10Comments  路  Source: gravitystorm/openstreetmap-carto

P_20200616_161152_vHDR_On_1
With extender arrows, rich cartographic detail in dense areas would now be possible.

Here we even see how multiple floors in one building could be treated with a shared extender arrow:
P_20200616_160956_vHDR_On_1_1

Not only points of interest, but also regular street names could also be facilitated in areas of high road density:
P_20200616_161250_vHDR_On_1

Most helpful comment

This is not feasible for a real time updated tiled map at this time.

I am also not aware of any current tiled maps that practically use fully automated methods for that - this is a very hard task technically. Even basic labeling with alternative positions is hard to do in a tiled map and often done rather suboptimally - this would add a whole additional level of complexity to that. Examples of this being tried would be most welcome.

All 10 comments

The algorithm is simple: simply sweep around in 360 degrees looking for gaps. Do this with a wider and wider radius. Now compare all the gaps we found and simply choose the largest one to fill in our object name and then add the extender arrow pointing to the object!
if more than one object then simply compute the space is needed for two objects etc.

The example images I have posted above (from atlases of http://www.outdoorlife.com.tw/ ) are all relevant to city centers of small villages and towns.

In large cities with kilometers in kilometers of dense information, I'm afraid the above is not always 100% possible.

So the algorithm will need some safety checks. Give up if needing to go beyond X meters at Y zoom level etc.

This is not feasible for a real time updated tiled map at this time.

I am also not aware of any current tiled maps that practically use fully automated methods for that - this is a very hard task technically. Even basic labeling with alternative positions is hard to do in a tiled map and often done rather suboptimally - this would add a whole additional level of complexity to that. Examples of this being tried would be most welcome.

The examples are in the images I posted.

They are not necessarily generated by hand editing...

This was intended as a long-term wish list item.

There is no worry that editors could squeeze in too many points of interest that could not be placed on the maps. The only worry is automatic editors. This is because within JOSM or iD one couldn't stuff too many points in anyway without noticing the crowding.

We use mapnik as a rendering engine.
This software has to support this feature.
If not, this wish list item could never be fullfilled.

It would be right overthere in https://github.com/mapnik/mapnik but they have 550+ open items. I am not sure if they want to have such an long-term wish list item in there issue tracker.

The examples you showed are from a classical non-tiled, non-interactive not real time updated map and show plenty of evidence of manual label and symbol placement.

Tiles could be updated and cached upon closing edits, not later upon browsing requests.

Tiles could be updated and cached upon closing edits, not later upon browsing requests.

This would would change nothing concerning this issue (and result in horrible performance).
This is an operational idea not an idea for this repository.

IMO the solution is rendering POIs at z20. Doing so would solve a lot of these types of issues that keep popping up.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Tomasz-W picture Tomasz-W  路  4Comments

kocio-pl picture kocio-pl  路  4Comments

FTno picture FTno  路  4Comments

Thorwynn picture Thorwynn  路  3Comments

dktue picture dktue  路  4Comments