We need to allow the following values as longitude and latitude:
- 22°42′55.4″S
- 22°42′S
- 22°S
Usage example: https://it.wikivoyage.org/wiki/Tematica:Parchi_nazionali_in_Africa
We need to allow the following values as longitude and latitude:
Usage example: https://it.wikivoyage.org/wiki/Tematica:Parchi_nazionali_in_Africa
Don't see a single example of human-readable coordinates being used as a parameter to geo-related templates.
The template in question - https://it.wikivoyage.org/wiki/Template:Marker - already converts to machine-readable format internally, using {{#deg2dd}}, we'd rather not duplicate this functionality.
For the sample map usage - https://en.wikivoyage.org/wiki/Central_Iowa, {{#property:P625|from=Q470273}} would pull the geo coordinates as 42°2'5"N, 93°37'12"W. We should have an easy way to convert Wikidata output into a parameter for the <mapframe> or <maplink>. @Lydia_Pintscher - any thoughts on this?
Lets keep it open until we figure out how to do this.
No particular thoughts from my side but like from the people I CC now. Thanks for the poke.
Wikibase/Wikidata supports coordinate input that uses degree/minute/second notation. The only limitation I can think of is that we currently only support the English language abbreviations for the hemispheres (N/S/E/W).
As to output generated by Wikibase/Wikidata when using {{#property:P625|from=Q470273}} notation: we should support output of a canonical machine readable plain text format. We also need this for date/time values, for further processing using parser function or other libraries. It might be sufficient to allow this via Lua, but even in Lua, we should make it simpler to do this kind of thing.
Lydia: what do you think of {{#property:P625|from=Q470273|format=raw}} that would output lossless plain text (instead of wikitext)? This would be similar with the format we use for pre-filling input boxes when editing values, except that the "raw" output should have a strong bias against localization, to make it easy to process.
Per IRC with @daniel : {{#property}} wouldn't work because it may return multiple values. We will still need a Lua value converter, which means we might as well stick with lat=NNN lon=NNN. Bummer.
According to @daniel, wikidata already supports all the different geo coordinate parsing that can be reused by other extensions. Daniel, could you point to the right code/provide a sample? Thx
@Yurik you can find the library for handling geo-coordinates here: https://github.com/DataValues/Geo
Have a look at https://github.com/DataValues/Geo/blob/master/src/Parsers/GeoCoordinateParser.php
I think creating a separate task for this request is redundant, but I spoke to an editor today. Their feedback was that there should be at least a way to view the current coordinates for the map in the visual editor dialog - perhaps even providing a way to open the same view in other services (similar to geohack).
@CKoerner_WMF this task is for <maplink lat="22°42′55.4″S" ...> style of entry, instead of <maplink lat=22.742342 ...>, not to show them. On the other hand, T128940#2205887 will add the needed values to the URL in the full screen mode. So when you browse the map, current zoom & location will be shown in URL and can be copied from there. See https://maps.wikimedia.org for example
@JGirault I think this is still valid, but requires us to agree on the"raw" data exchange format with wikidata, and wikidata to first be able to output it in that format.
Just a remark:
In de.WP we support two different formats for coordinates, decimal and degree/minutes/seconds (e.g. 22/42/55.4/S which is equivalent to 22°42′55.4″S.
Allowing only decimal at the interface, means we have to calculate the decimal value from the DMS value for existing coordinates. This is a bit expensive in template code and performance would largely improve, if such calculations are done in a server module.
Of course we can run a bot and convert only once. But this means, that users will get their values transformed and we will loose traceability to the original source of the coordinates.
For new coordinates users might be urged to convert manually (depending on the GIS they are using). My experience over the years is that such manual conversions quite often fails.
Thus I feel that preparing the interface for both types of values puts the necessary calculation to the best place and is less error prone.