Add GeoJSON visual editor

[JeroenDeDauw]

https://leafletjs.com/examples/geojson/
https://openlayers.org/en/latest/examples/geojson.html
https://developers.google.com/maps/documentation/javascript/datalayer#load_geojson

Rather than having a whole custom syntax for defining elements to show on a map, we could use the GeoJSON standard.

Advantages:

• UX: Standard syntax rather than Title~Text~Border color~Opacity~Thickness~Color
• UX: visual map editing possible via existing tools, integration in the wiki possible
• Dev: way less code/complexity, hence less maintenance costs, development costs and bugs

A big question is how to do this in a backwards compatible way.

---

Approach 1: new tag extension

A <leaflet> tag function could be added that takes the GeoJSON in its body. A new tag function is needed since display_map already uses the tag body for locations and adding json as a parameter does not work. Example:

<leaflet width="442px">
[{
    "type": "LineString",
    "coordinates": [[-100, 40], [-105, 45], [-110, 55]]
}, {
    "type": "LineString",
    "coordinates": [[-105, 40], [-110, 45], [-115, 55]]
}]
</leaflet>

If other services add support they could get a dedicated tag function as well. These tag functions would have the same parameters as display_map does now for the respective services.

---

Approach 2: map namespace

Rather than having the GeoJson inline in a page, it would reside on a dedicated page in a special namespace. ie /wiki/Map:CoolPlacesInBerlin. Using the GeoJson would then be possible via a new parameter in display_map. Example:

{{#display_map:geojson=CoolPlacesInBerlin|width=442px}}

This approach makes it much more easy to create an integrated visual editing interface for the map data. Since the data is on a dedicated page, the editor automatically access it and save it back, without the user needing to do copy pasting (like with existing Special:MapEditor). And the dedicated map page would be a natural place for the editing UI. Hitting edit on the map page would give you the visual map editor rather than the JSON page content (like Wikidata).

[JeroenDeDauw]

@PeterTheOne @yaronkoren @kghbln @mwjames @pastakhov @netbrain @krabina

I'd love to hear your thoughts on this.

[krabina]

For creating static maps, approach 2 sounds very promising and is my preferred approach. The question is, how to handle dynamic points to be displayed (format=map).
I can imagine two ways.

1. an ask query like now with format=leaflet and the parameter geojson=CoolPlacesInBerlin
   This is nice, because you then could have a mix of a pre-defined, manually edited map of cool places in Berlin and on top of that have the result of an aks query displayed together with it (maybe also as a separate layer?)
2. put an ask query with format=geojson on the Map:CoolPlacesInBerlin page. This way, you could see and edit your map via the visual editing interface (like edit with forms in page forms) and edit the source code of the page (via edit source) and modify your aks query that adds additional geojson data to the page.

[JeroenDeDauw]

I actually did not think about the SMW side of things at all yet. Option 1 seems reasonable and easy to do. Option 2 is nice but is much more complex and difficult to create. In that case the map pages need to have SMW integration and they need to still work without SMW installed. The editor would also need to distinguish between pulled in data, which can not be edited, and elements the user added onto the map.

I'd start with just the "static maps" and then do the SMW integration. When doing sizable work on the SMW integration I'd also blow up the scope of investigation a bit. At present you can only store coordinates and only show those using markers. No support for shapes, and no export options besides KML (which I suspect is kinda broken anyway). Not clear what users actually need though. That might become more clear if there is better shapes support for "static maps".

[krabina]

yes, better shape support would be great.

As for approach 2 - maybe you should consider the Page Forms approach anyway: have "edit with form" (could even be called like that or "edit map") point to the visual editing interface, but still be able to "edit source" where you can see the GeoJSON on a regular editable wiki page. This way, you have the best of both worlds.

[JeroenDeDauw]

Yeah... I was going to ask you why you'd ever want to edit the JSON directly but already thought of some answers to that. You want to be able to import (snippets of) GeoJSON by pasting it into such a page. Also the visual editor might not support everything you want to do, in which case you again want to edit the JSON directly.

I think what makes most sense UX wise is to have the visual interface show when you click edit, and have another option to get to the actual JSON.

[krabina]

yes and with the mechanism already used by PageForms there is something in place, that others, e. g. skin designers are aware of and use. So the question of what happens when you click on edit can be customized in PageForms:
https://www.mediawiki.org/wiki/Extension:Page_Forms/The_%22edit_with_form%22_tab#Configuring_the_editing_tabs

[JeroenDeDauw]

My initial idea was to have these map pages show the map with some sensible default settings (such as width = 100%, height = 400 px or whatever) and then have the edit tab show a page with the map in edit mode.

Perhaps it is better to not have an edit tab at all, like on Wikidata. There could be an "edit" button on the map that changes it to edit mode. Or, since this page is there to hold and edit the data, not to display it, have the map be in edit mode when the page is loaded (for those with sufficient permissions). For either of the latter two cases there would still need to be a way to preview what the map looks like without edit mode, which should not be too hard to implement.

[krabina]

fine with me as long as it is still a regular wiki page. I guess the edit button then edits a section of the page?

Big advantage of having it as a regular wiki page is that the map page is then still part of the mediawiki versioning and that is a big advantage also for map creation and maintenance.

[JeroenDeDauw]

Yeah it would still be a wiki page, just like with Wikidata items. With the same history page, changes in special:recentchanges, etc. The page would only be able to hold GeoJSON and the UI would be changed as described.

[krabina]

while we're at it: maybe also allow wikitext that could be displayed above or below the map, so you could add descriptions. (or allowing transclusion of pages in the "Maps:" Namespace to other pages, so you can acheive this.)

[kghbln]

I believe you have covered a lot here. :) I personally prefer the second approach of moving the json out of the content pages to pages in a dedicated namespace. GeoJSON appears like the way to go and actually I do not dare asking if this would even integrate with the Kartographer extension. Probably not since I suspect WMF is on autopilot here.

[JeroenDeDauw]

Interesting. The Kartographer extension went with the GeoJSON approach and can do a bunch of stuff Maps can't do because of it. They went with approach 1 though. Even so that means you'd be able to easily transfer data between them, since Maps would no longer be using this weird custom wikitext format.

[kghbln]

Admittedly I never looked into that extension in detail but since I knew that they are using it the idea of making the data also usable for Maps in an easy way was the first thing that came into my mind. I still think approach 2 is better though. Since WMF went for 1 they will probably develop some means of editing for it if they have not done so already.

[krabina]

I was not aware of that extension at all! On the Maps page it says "Extension:Kartographer - Allows to add maps to pages as a frontend to Maps"
What does that mean? When would I be wanting to use both extensions? Isn't it more a choice between those two?

[kghbln]

I was not aware of that extension at all! On the Maps page it says "Extension:Kartographer - Allows to add maps to pages as a frontend to Maps"

I have any idea either. Thus is changed the wording on mw.o

When would I be wanting to use both extensions? Isn't it more a choice between those two?

Probably nobody would want to use both extensions at the same time. My question was about reusing data saved with one or the other extension.

[JeroenDeDauw]

The description there was very confusing. The "Maps" in that sentence reffered to a WMF project, not to the extension the page itself is about. Fixed that now. So the Kartographer extension has nothing to do with the Maps one.

[mwjames]

Approach 2: map namespace

I would go with approach 2 as it encapsulates the content and avoids spreading JSON within normal wiki text.

while we're at it: maybe also allow wikitext that could be displayed above or below the map, so you could add descriptions.

Keep the implementation simple, meaning that GeoJSON should only know GeoJSON and not be mixed with other content types. If you need to wrap content with other components then the embedding page should take care of it but not the GeoJSON unless you define a field in that JSON specification that can hold a wikitext notation.

[JeroenDeDauw]

Input wanted!

I am wondering about how to make the "map page with GeoJSON" approach user friendly. The content definition being on another page than where it is used created some problems. The main ones being the creation of the page and finding it when creating and editing the display_map call.

Say you have this

{{#display_map:geojson=...}} 

Now you need to know to go to the map GeoJson namespace and create a page there, and then put the page name in the display_map call. When you want to edit what is on the map you see on a page, you will just see the geojson=VegetarianRestaurantsInBerlin stuff and again need to know there is a special map page and then construct the URL yourself. Both of these are serious UX issues.

There also is an UX issue the other way round: when you are on the map page it is not obvious where the GeoJSON is used or what these maps actually look like (since they can use all kind of parameters). This seems like a less severe issue though still something worth addressing.

The later issue can be solved by having a list of pages that use the map definition. Not sure how to do that from a technical perspective but at least it is clear what to do there. For the former issue (creating/editing display_map) I'm not really sure what would be good UX wise and would still be realistically achievable.

Any suggestions on what good UX would look like? Even if you don't know if it would be possible to implement, just the idea might be useful in itself.

[mwjames]

just see the geojson=VegetarianRestaurantsInBerlin stuff and again need to know there is a special map page and then construct the URL yourself. Both of these are serious UX issues

In case the parser function uses a reference to a special content page, I would generate a tooltip with all the links you might want to provide to a user. The following may work as inspiration.

[JeroenDeDauw]

Where is that image from?

[kghbln]

I think something on the map like the icons for sooming in and out of a map or selecting a certain layer will be nice.

[JeroenDeDauw]

Maps 6.0.0 has the GeoJSON namesapce. It has previews on these pages but no visual editing yet. The Leaflet editing plugins I've seen so far only allow editing shapes and placing markers but not popups for these elements, which is important for the Maps usecase. See Leaflet/Leaflet.Editable#173

Contributions to allow visual editing on the GeoJSOn pages are very welcome.

[JeroenDeDauw]

Maps 7.5.0 comes with a visual editor for GeoJson pages:

As can be seen on the screenshot, the markers are not displayed correctly. This was already the case in earlier releases on the GeoJson pages. No idea what is causing this after 2h of debugging that. 50 EUR to whoever fixes this issue from hell.

[JeroenDeDauw]

https://github.com/JeroenDeDauw/Maps/projects/1