Wikidata:Property proposal/OSM zoom level

From Wikidata
Jump to navigation Jump to search

OSM zoom level

[edit]

Originally proposed at Wikidata:Property proposal/Creative work

Descriptionzoom level that would be requested for 512 x 512 pixel OSM map that could contain the boundaries of this map
Representsrelated topic: Web Mercator (Q18155718)
Data typeString
Template parameter"zoom" in c:Template:Map
Domainmap (Q4006)
Allowed values"\d\d?"; in practice 0 -> 23 (perhaps 24)
Allowed unitsnone
Example 1Amerique Meridionale (Q56759862) → 3
Example 2John Speed's map of Wales (Q22912348) → 7
Example 3c:File:Plan of Dudley Castle (1897).jpg → 18
Example 4world map (Q653848) → 0
SourceGiven by the calculation

$zoom = int((-log ($range / 360) / log(2)) + 1), where

$range = MAX ( ($east - $west), ((180/$pi) * ( log(tan(45 + $north/2)) - log(tan(45 + $south/2)) )))
Planned useI'm currently working on items for some C18 engravings and maps. The property will also be very useful when Structured Data for Commons arrives, to feed c:Template:Map

Motivation

[edit]

OSM zoom level gives a convenient logarithmic scale for the extent of a map, giving a useful set of integer bins to allow maps depicting subjects of a similar real-world size to be easily extracted from a larger set.

I have used it extensively to analyse and organise the 50,000 maps in the BL C19 map georeferencing project on Flickr and Commons, and would similarly intend to use it for the 17th and 18th-century maps I am currently working on. It is very useful to be able to specify that one exclusively wants to look at maps in a particular set of zoom-numbers; also, to the compare the zoom numbers to the features that the maps are said to depict, to spot anomalies.

The zoom level is a straightforward enough function to find given the bounding-box of the map; however it is well beyond the capabilities of the WDQS query service (particularly the step of Mercatorising the north-south extent), given that SPARQL does not offer trigonometric functions, or even logarithms.

In any case, what SPARQL is most efficient at is indexed lookups. By storing the zoom value as a pre-calculated integer, SPARQL can then extract relevant items (and only relevant items) directly, without calculation, and without having to load the full set and filter it.

The definition above, in terms of the tile level required to fit the maps within a 512 x 512 pixel OSM map, seems to work well in practice. It allows one to specify by fiat that whole world maps should have zoom level 0, separated from slightly smaller maps of not-quite the whole world with zoom level 1.

I have requested datatype "string" since "number" gives 'not available yet', and integers may anyway be better indexed as strings than as reals. Jheald (talk) 23:43, 30 September 2018 (UTC)[reply]

Discussion

[edit]
@Shisma: Not easy to access from WDQS. Also, there are/will be map items that don't have Commons images. Also, one of the main points of Wikidata and the forthcoming CommonsData is to avoid having to scrape data out of templates, to use properties and statements instead. See eg this query: tinyurl.com/ybhrl9wm for what can be done with bounding box data on Wikidata, as opposed to stuck in a template on Commons. Being able to make zoom-level data similarly accessible to WDQS to allow selectivity would similarly be very useful. Jheald (talk) 09:52, 1 October 2018 (UTC)[reply]