Wikidata:Property proposal/OSM zoom level

OSM zoom level

Originally proposed at Wikidata:Property proposal/Creative work

   Done: OpenStreetMap zoom level (P6592) (Talk and documentation)

Description	zoom level that would be requested for 512 x 512 pixel OSM map that could contain the boundaries of this map
Represents	related topic: Web Mercator (Q18155718)
Data type	String
Template parameter	"zoom" in c:Template:Map
Domain	map (Q4006)
Allowed values	"\d\d?"; in practice 0 -> 23 (perhaps 24)
Allowed units	none
Example 1	Amerique Meridionale (Q56759862) → 3
Example 2	John Speed's map of Wales (Q22912348) → 7
Example 3	c:File:Plan of Dudley Castle (1897).jpg → 18
Example 4	world map (Q653848) → 0
Source	Given 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 use	I'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

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)

Discussion

• Proposed. Jheald (talk) 23:43, 30 September 2018 (UTC)
•  Support David (talk) 08:07, 1 October 2018 (UTC)
• can't you use the bbox? That information is already stored in the commons. It is very common, it is independent of a specific service or screen resolution and it is a string. 😉 --Shisma (talk) 09:02, 1 October 2018 (UTC)

@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)

•  Comment Better express the maximum extent of the map with data type Quantity, e.g. 250 km instead. This implies zoom level and can be used for other calculations as well, e.g. together with scale (P1752) it gives you the rough size of the map unfolded. See also Wikidata:Property proposal/bounding box which could be build on. -- JakobVoss (talk) 21:35, 29 October 2018 (UTC)
•  Oppose as per JakobVoss--Shisma (talk) 21:43, 13 November 2018 (UTC)
  • @JacobVoss, Shisma: To take the second part of JakobVoss's comment first, a bounding box isn't a substitute. Amerique Meridionale (Q56759862) effectively already specifies a bounding box, using coordinates of easternmost point (P1334), coordinates of northernmost point (P1332), etc. But SPARQL doesn't have the computational abilities to turn that into either a zoom level or a maximum extent, still less make those things rapidly searchable. The size of the map unfolded is already given by height (P2048) and width (P2049). Maximum extent could possibly be given by radius (P2120), but I would prefer not to use that for things which are not circular or spherical. Also how would one define it? From the centre to the corner of the bounding box? But the map may not extend to the corner of the bounding box. From the centre to the furthest-away side? Perhaps. And yes, it might be a useful number to have. But the zoom-level is also a useful number to have, giving a convenient logrithmic scale of buckets from zoom 0 to zoom 20+ that conveniently groups maps together. Moreover, zoom-level is what is being used by the Commons template. By your !vote, you prevent this number being stored in Wikidata or CommonsData, so you prevent it being moved out of the template text. Is that really what you want to do? And as Wikidata users, do you have the standing to prevent the better structuring of data on Commons, eg on CommonsData? Jheald (talk) 16:39, 14 November 2018 (UTC)
•  Support NMaia (talk) 02:52, 26 January 2019 (UTC)
•  Support Ederporto (talk) 02:53, 26 January 2019 (UTC)
•  Support Sturm (talk) 02:13, 6 March 2019 (UTC)
• @Jheald, ديفيد عادل وهبة خليل 2, NMaia, Ederporto, Sturm: please make good use of it. --- Jura 12:33, 10 March 2019 (UTC)