Change 556305 had a related patch set uploaded (by Matthias Mullie; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Allow users to input coordinates using map UI

https://gerrit.wikimedia.org/r/556305

Change 559831 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Add a (default) collapsed version for globecoordinate input

https://gerrit.wikimedia.org/r/559831

There are currently two patches which are ready or near-ready that address this issue. Currently the UX for "enhanced" coordinate input looks like this:

Map collapsed, "read" state

Map collapsed, "edit" state

Map expanded

Map expanded with point selected

Map re-collapses once a coordinate is added

The idea here is that users can expand the map when needed, but it's not always there (which could be kind of distracting, especially if they aren't planning to interact with the property in question at all).

Once coordinates have been input (either manually or via the map), the user must still explicitly click the "add" button and then "publish" their changes – the same as any other structured data edit.

Once the map has been expanded, there is no UI to close it (except by just re-loading the page) – this may or may not be something we need to add.

I wanted to provide this snapshot of how things currently work before the patches get merged – please let me know if something here needs to change.

@egardner how does it work on mobile? 😉

@Ramsey-WMF the map itself works OK on mobile, but we could probably stack the compact row elements a little more nicely. I'll take a stab at that next.

I think once the mobile tweaks are done, it'll be ready. I have some mild concerns about turning the map off by default, but let's give it a go.

@Ramsey-WMF if you want, we can merge the first patch (that enables the map feature at all) and then wait to merge the second one (which hides it by default and consolidates the input fields to a single row), adding further tweaks if necessary.

In that case, the map is always-visible and the UI looks like this:

Read state

Edit State

In T227116#5780120, @Ramsey-WMF wrote:

I think once the mobile tweaks are done, it'll be ready. I have some mild concerns about turning the map off by default, but let's give it a go.

I have serious concerns about showing the map by default.
The map is used for input only. As soon as there is a property of geo-coordinate datatype, this input field will be displayed (and once one coordinate has been added, it's relatively unlikely that another will have to be for that property)
The maps are a massive distraction from everything else on the page, and there is no information in that map: it's only for input.
Its only use is for the <0.1% of page loads that intend to add geo-coordinate statements - displaying by default is undesirable for virtually all page views.

It might make sense to display it by default in the "add property" scenario, in which case it wouldn't show up immediately and adding a property makes it clear that users will want to input coordinates (though it makes things slightly less consistent)

I'm in agreement with @matthiasmullie that the map is very prominent by default, probably too much so. It will also cause a bunch of image tiles to be loaded which is a consideration for bandwidth.

I'll see if I can get the "open when adding the property but otherwise default to collapsed" behavior working shortly.

This turned out so well! I agree that hiding the map by default is better than showing it all the time, and could go either way on displaying it once the user is adding a new coordinate. I don't think it's totally necessary but it would be a nice feature.

For mobile, in addition to stacking the inputs in a one-column layout, we should address the input labels for qualifiers, which aren't positioned well. If you don't have time to address this during this patch, we can open a separate ticket.

Another UX improvement would be to move the "select on map" button to the top for qualifiers. It's a bit confusing to click on it then have the map appear at the top, and I think it'd be better to keep the order of the items consistent between top-level statements and qualifiers. It's a bit tricky to figure out the best design, but something like this would probably work:

👏 Awesome work on this!

Ok, I've updated the design a bit of the expanded/collapsed map. Here are some new screenshots:

Statement/top-level input
"Expand map" button is full-width regardless of size; this makes adapting for mobile a little more straightforward.
All other elements line up on a single row.

Toggling the panel to edit-mode doesn't impact the expanded/collapsed state of map.

The expanded map occupies the same location as the expand button did previously, so it hopefully won't be too jarring for the user.

Clicking on the map works the same as before

Adding a new value (by clicking the "add" button) re-collapses the map.

Qualifier-level
Things basically work the same here, except the lat/long/precision inputs have been stacked in multiple rows now.

Quoting @matthiasmullie

The map is used for input only.

So, here's the source of my original mild concern - on Wikidata, the map is shown by default during "read", and it provides a visual guide to the location of the coordinate in question. This is particularly useful for the use case of someone editing a value they didn't originally enter (where the hell is this location? how do I know if it's right or not if I can't see it on a map?). This is immensely useful in the Wikidata usage patterns.

The question is: do we need that sort of functional parity on Commons. This is harder to answer because we're not really sure what the usage on Commons will be, but it will probably be different and/or less frequent than Wikidata. There's no question that it's a nice-to-have (as an editor I can spot-check the accuracy of the coordinates fairly easily), but it's not 100% required because there are other ways users can confirm the coordinates (a quick copy-paste into Google, for instance).

For the sake of an MVP, this approach is fine. But if we're choosing not to do this now because of time/labor constraints (understandable), we might have to revisit later.

@Ramsey-WMF we don't currently support a lot of edit-in-place functionality anywhere in the SDC UI – users are encouraged to just add new values or delete old ones. Compare with cases where a string or URL field is entered – if a user sees a typo in a URL, they can't just edit that value; they need to delete the old one and add a new one. I think that this is all a legacy around the initial designs assuming item-types and dropdown inputs everywhere. (Qualifiers do allow edit-in-place functionality however – so we are inconsistent in our inconsistencies).

I think that your concern about inconsistencies with Wikidata applies to all areas of the SDC UI unfortunately. Give that, I'd say we try to address that problem at another point. This would probably entail changing the way the Item elements (rows stacked under the input field in a statement panel) look and behave.

Regardless of edit in place, even if I'm just deleting an old coordinate, it would remove a step from my workflow if I could see a map of that location right on the page so I know immediately it needs needs deleting 🌐

It's the equivalent of only showing Q numbers on entity values instead of their labels 🙂

Right now I can think of two ways to try to support the use-case you are describing (make it easier for the user to visually see previously-entered coordinates on a map):

1. Show some embedded map view above/next to every item that exists within the panel (perhaps only in edit mode, to not be too overwhelming). But that's still a lot of maps – any given panel could contain an arbitrary number of them. Presumably these maps would not allow changing of the coordinates, just deletion of the entire item if it was wrong.
2. Wire up some new functionality so that clicking on an existing coordinate item inside a globe-coordinates-type statement panel expands the one map we have already, and displays the appropriate location. This might be a little less obtrusive but it may not be as obvious to users. Also, right now ItemWidgets behave the same way regardless of datatype and this would be a departure from that.

Not to beat a dead horse, but #1 is how Wikidata does it (arbitrary number of maps and all)😄

The Commons community could of course limit this via property constraints or AbuseFilter settings (only one value for coordinate location statement please). But I think it'll be rare that images will have any coordinate values to begin with ("coordinates of the point of view" is the main culprit for geocoordinates on commons, but the location property [which is just an item] is much more likely), and multiple coordinate values on a file is probably an edge case.

So, for a solid start, I'd vote #1 with no changing/editing, just display.

Also I don't think the map needs to be so big 🐳

In that case, I think the best way forward would be to introduce this functionality in a new patch that builds on top of the two previous ones. I can start on that tomorrow.

Here are some new screenshots representing the approach described above:

Read mode: All map elements are collapsed

Edit mode: Items representing previously-added coordinates get maps showing the location; users cannot change these values but they can delete the entire item.

We are operating under the assumption that any given "globecoordinates" panel will not have a ton of values, because one map will appear for each value that is present in edit mode.

Change 562939 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Allow users to see locations of existing coordinates on map

https://gerrit.wikimedia.org/r/562939

Change 556305 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Allow users to input coordinates using map UI

https://gerrit.wikimedia.org/r/556305

Change 559831 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add a (default) collapsed version for globecoordinate input

https://gerrit.wikimedia.org/r/559831

@egardner One minor comment on your latest patch: can we add some visual separation between the statement input and the map for the first existing statement? It sort of looks like the map is more connected to the statement input than the existing statement. I realize this might be kind of difficult because this will cause the design for geocoordinate statement panels to diverge from other datatypes...happy to discuss this more!

@AnneT this was bugging me a little bit too. The problem is that ItemWidgets appear directly beneath their statement input widget in all other cases. If the map is part of the ItemWidget, it will appear flush with the input (leading to confusion about which map relates to which element).

I considered placing the map below the grey row box of the ItemWidget instead, but this might impact how Qualifiers fit in.

Finally, we could move away from the "full-bleed" map here entirely and make Item-level maps appear inside the grey row to clearly separate them. But that might look kind of cluttered...

Oof, yeah, this is a tough one. I'm fine merging as-is and reevaluating when we have a designer to consult.

A few comments:

• in all your examples the name of the property is Geolocation, on SDC we will use this to store coordinates of the camera and the name of the property is coordinates of the point of view (P1259) so we should use that term
• coordinates of the point of view (P1259) will likely be the only geolocation property a file will have and that one has single value constraint, so it is unlikely we will encounter cases with multiple values (although they still have to be handled)
• most of the time coordinates are copied from somewhere, so a single window for latitude and longitude, like the one used on Wikidata is preferable over two windows because it takes a single copy-and-paste not two (suggested by user:Ayack)
• The GUI used for over a decade to help people choose geolocation can be found at http://tools.freeside.sk/geolocator/geolocator.html it allows you to pick camera location and heading. On SDC heading should be stored using heading (P7787) qualifier. It would be nice if the new GUI allowed the same capabilities as the old one.
• The precision is stored in degrees, while the value is usually suggested in degrees, arc minutes arc seconds and their fractions. A more useful measure would be to provide it in meters, km and cm as people more easily can relate to those (suggested by User:bjh21). Perhaps we could expand the list of suggestions.
• We do have some files with coordinates on other globes, like files in Category:Media_with_Mars_locations, The way Wikidata stores coordinates, there is a globe field that can be set to something else than "earth". We should make it accessible, so we can geotag other globes

Two more points:

• for properties with single value constraint we do not need "Mark as Prominent" flag
• In order to correctly choose camera location we usually need to get oriented by the on the ground features, that is why the old GUI provided a lot of details at the highest zoom level see for example the GUI zoomed to Washington Monument. I do not know if we would be allowed to use satellite images, but the more details provided the better

I just noticed that there is nothing in the original description that constraints this task to Structured Data on Commons (SDC), and the enhancements could also apply to Wikidata. My comments above were meant mostly for SDC, although some could be applied to Wikidata as well, like providing precision in meters (which is than converted to arc degrees), or more intuitive way to pick a globe for locations on other planets. Could someone clarify if the scope is SDC or SDC+Wikidata?

The scope right now is just for SDC.

In T227116#5792850, @Jarekt wrote:

I just noticed that there is nothing in the original description that constraints this task to Structured Data on Commons (SDC), and the enhancements could also apply to Wikidata. My comments above were meant mostly for SDC, although some could be applied to Wikidata as well, like providing precision in meters (which is than converted to arc degrees), or more intuitive way to pick a globe for locations on other planets. Could someone clarify if the scope is SDC or SDC+Wikidata?

Hey, just some quick points a I currently don't have the time to go any deeper:

1. Please have a look at XKCD #2170 "Coordinate Precision" and take a moment to consider how many decimals make sense to be displayed/stored. In one of the pictures where decimal degrees were used as imput I counted 13 decimal places. Half of that would be plenty to point to a specific letter on your Keyboard. In the same screenshot, the coordinate precision is given a +/- 0.1 degree. In any case, more than 7 decimal places would be ridiculous. For DMS coordinates, with 2 decimal places for arcseconds, your're already on the scale of centimeters; more than 3 would certainly not be needed. Not only does it look strange and take up valuable space on the screen, it also suggests a level of precision that is not possible to achieve with geocoordinates of this type (because we live on a potato). In other words: a) The number of decimal places stored (or at least displayed) for a set of coordinates should correspond to the precision setting (which should optionally be available in km, m etc.) and b) the maximum allowable precision should not be finer than maybe 10cm.

2. Please, please, pleeease: If you absolutely insist on displaying DMS by default, provide an option to switch to decimal degrees somewhere in the user settings. They're just so much more useful if you actually want to work with them.

3. I'd like to echo the call for including camera heading (and estimation of precision) into the GUI and display. That's something the locator tool at wmflabs still does not manage to accomplish - http://tools.freeside.sk/geolocator/geolocator.html is indeed the reference to go for here.

4. Make sure to provide a map layer with the default OSM theme. The "Wikimedia Maps" rendering looks pretty, but has by far not enough detail and is close to useless for geotagging images.

I just tried to use the current GUI to add "coordinates of the point of view" property to one of my photographs (File:Seneca_Rocks_climbing_-_13.jpg), and it does not work very well, we really need Wikidata like interface with a single input window.

• I tried to copy "38°50'4.319"N" into latitude and "79°21'59.461"W " into longitude but the system did not recognized the notation. That is a big step back as the wikidata wan take coordinates in either decimal and DMS notations. {{Location}} template can also parse either notation.
• I finally managed to convert my coordinates to decimal degrees than I added heading qualifier, but I am not able to add the units to the qualifier, which are required. Adding heading qualifier on Wikidata works just fine.
• After I copied my location I would like to see it on the map, but there is no obvious way to do it.

Thanks for the feedback about real-world use-cases here, it's useful.

I'm going to look into a follow up patch about consolidating the text fields into a single input which supports copy-paste of coordinates, since this is something that folks have asked for in multiple places. Will also look at changing the default precision values.

RE: seeing existing locations on the map, I have a patch which adds this functionality that is mostly ready; this should be added soon. There are some screenshots displaying how this functionality works in an earlier post to this thread (see here).

Some things like camera angle, etc. are probably better handled by qualifiers; right now we're concentrating on supporting all of the basic Wikidata data-types themselves (globe-coordinate, time values, etc) rather than something specific to an individual property.

In T227116#5820710, @egardner wrote:

I'm going to look into a follow up patch about consolidating the text fields into a single input which supports copy-paste of coordinates, since this is something that folks have asked for in multiple places. Will also look at changing the default precision values.

Thank you that would be great.

RE: seeing existing locations on the map, I have a patch which adds this functionality that is mostly ready; this should be added soon. There are some screenshots displaying how this functionality works in an earlier post to this thread (see here).

By other locations I mean other other geotagged images. See for example here. We have that functionality for over a decade (originally with Google Maps) and we are quite used to it. Other nearby images help you get better idea of what the place looks like and help you better position you image.

Some things like camera angle, etc. are probably better handled by qualifiers;

That makes sense and heading is stored as a qualifier. However in the context of SDC I can think of mostly one "Geographic coordinates" property: camera coordinates and if you have a GUI to help you add camera coordinates (aka "coordinates of the point of view") then it would make sense if it also captures camera heading the way the tools you are replacing, like did for over a decade. However I can imagine some other SDC "Geographic coordinates" properties, like anchor points in aerial photographs where you assign geocoordinates to specific pixels of the image and we need to support them too.

right now we're concentrating on supporting all of the basic Wikidata data-types themselves (globe-coordinate, time values, etc) rather than something specific to an individual property

I am still quite confused why do you have to "concentrate on supporting all of the basic Wikidata data-types", since wikidata already does it very well, and in most cases I do not see a need to change the way we support them. That is why I asked at T240093 for a way to stick to more wikidata-like GUI. For example, I think it is confusing that once I add "coordinates of the point of view" to an image, like at File:Seneca_Rocks_climbing_-_13.jpg I see

Where the coordinates are hard to spot somewhere in line 4. and the main focus is on empty latitude/longitude fields, which is strange since I only expect a single "coordinates of the point of view" per image (it has single value constraint). So once a geolocation is added we should not encourage people to add another one, at least not without removing the other one first. Compare it with the same property at Q64015956

Where we have nice map, coordinates are almost the only writing and heading forces you to pick units (I did not find a way to add units to heading angle on SDC).

GUI for geocoordinates is not perfect on Wikidata: precision is shown in arc angles not meters and I am not sure how to change globe from earth to other planets, but in my opinion it is more clear.

Change 569674 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Update coordinate input appearance and behavior

https://gerrit.wikimedia.org/r/569674

Change 572371 had a related patch set uploaded (by Eric Gardner; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Use a single input for lat/lng coordinates and make it smarter

https://gerrit.wikimedia.org/r/572371

Change 562939 abandoned by Eric Gardner:
Allow users to see locations of existing coordinates on map

Reason:
This patch has been abandoned in favor of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /574603

https://gerrit.wikimedia.org/r/562939

Change 569674 abandoned by Eric Gardner:
Update coordinate input appearance and behavior

Reason:
This patch has been abandoned in favor of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /574603

https://gerrit.wikimedia.org/r/569674

Change 572371 abandoned by Eric Gardner:
Use a single input for lat/lng coordinates and make it smarter

Reason:
This patch has been abandoned in favor of https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/ /574603

https://gerrit.wikimedia.org/r/572371

Change 574603 had a related patch set uploaded (by Matthias Mullie; owner: Eric Gardner):
[mediawiki/extensions/WikibaseMediaInfo@master] Improved globecoordinate input and display

https://gerrit.wikimedia.org/r/574603

Change 574603 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Improved globecoordinate input and display

https://gerrit.wikimedia.org/r/574603

Does this work with ExternalData as wanted in T188291?