Template talk:Mapshape

Note

1. Old thing about group name popped up again.
2. Mapshape template - if you use type=geoshape you will get geomask default. Cheers! -- Matroc (talk) 08:23, 3 December 2016 (UTC)

Sorry, I didn't see this message earlier. I've tweaked the template - it looks like template substitution inside of #tag was wonky - and it now renders the geoshape in User:Wrh2/Maps correctly. Does this change fix the issue you were seeing? -- Ryan • (talk) • 03:58, 6 December 2016 (UTC)

Appears to have fixed it - just thought you might have wanted to know about it since I guess its probably being used in other wikis - Thanks! -- Matroc (talk) 04:05, 6 December 2016 (UTC)

Stroke

Would it be possible to add a parameter "stroke" in order to change the color of mapshapes? Ar2332 (talk) 12:16, 16 January 2018 (UTC)

Hi Ar2332, I've added a "stroke" parameter so line colours can be changed. An example is the dynamic map at Vancouver/City Centre. Cheers, -Shaundd (talk) 04:15, 17 January 2018 (UTC)

Amazing, thanks! Ar2332 (talk) 08:13, 17 January 2018 (UTC)

Support for OSM super-relations

Would it be possible to support OSM super-relations, like Q99702? The mapshape works fine for e.g Q99691, but that's a normal relation with ways and nodes... Or this is work for some wikidata-osm sync code/kartographer? But it seems that https://query.wikidata.org works fine with both... Andree.sk (talk) 19:36, 7 February 2018 (UTC)

It should work. I noted:

{{mapframe | width=300 | height=300 | zoom=11 | 52.4703 | 13.2950 | name = Berlin tubes}}
{{Mapshape|wikidata=Q99702|type=geoline|stroke-width=5}}<!-- U3 -->
{{Mapshape|wikidata=Q99691|type=geoline|stroke=#ff0000}}<!-- U1 -->

--RolandUnger (talk) 09:47, 9 February 2018 (UTC)

After entering the Wikidata id in OSM (this is necessary) it takes a few days until it is working on Wikimedia maps.

Maybe, Q99702 is not a super-relation. So we had to check another example. --RolandUnger (talk) 10:03, 9 February 2018 (UTC)

I hope I found a better example. And it seems that this is an API problem of the Wikimedia map server (by the way, super-relations do not work on the OSM web site)

• https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q99691 (working example)
• https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q1375670 (not working)

The map features which where fetched from OSM relations will be added by a JavaScript via an API call of the map server. The calls are noted in the html document header.

I do not know if this problem can be solved and who should do it. The map team was suspended. I will open a phabricator task. --RolandUnger (talk) 12:59, 9 February 2018 (UTC)

There are two examples - Q99702 and Q99720, both are super-relations unless I overlooked something (they have sub-relations containing A-to-B and B-to-A tracks). The difference is that Q99702 has the wikidata link on one of the sub-relations (in addition to the super-relation having it). I'll try to check if this is "it" by adding the wikidata link to Q99720 too, we'll see if it helps. If yes, perhaps it's a good-enough workaround for now - and it doesn't "damage" OSM data, IMO. The missing wikimedia support is unfortunate though, we could have made wikivoyage more visually pleasing with better features... :-( Andree.sk (talk) 14:57, 9 February 2018 (UTC)

The test with Q99720 supports my theory, the workaround is working :) User:Andree.sk now shows the U6 line... Andree.sk (talk) 18:29, 10 February 2018 (UTC)

How can one add colored metro lines using Wikidata to dynamic maps?

Swept in from the pub

I have seen this done in various articles like this one. The wiki code only the wikidata entry Q190271 with no info about color.... and therefore, when I copy it to the Hebrew Wikivoyage it comes out as only black. How would I go about copying the colored metro lines to the dynamic maps on Hebvoy? ויקיג'אנקי (talk) 11:34, 19 June 2018 (UTC)

@ויקיג'אנקי: Generally speaking, you add one wikidata entry using {{Mapshapes}}. The item consists of several lines that are linked under P527 (has part). All of these individual lines link to an OSM Relation ID (P402) and optionally an sRGB color hex triplet (P465). The latter of these defines the colour in which this one line is displayed, and is most likely what you'll need to fill out to get this to work. If you have, then consider waiting a few days. The synchronisation sometimes takes a while and I do not know of a way to force it to sync.
-- Wauteurz (talk) 12:26, 19 June 2018 (UTC)

Just a note (well, my observation...) - only the OSM-wikidata sync takes a few days. And actually, it seems the OSM->WD link is what's needed (so, the OSM relations need to be edited to contain the WD reference), WD->OSM not really. The changes in wikidata are basically immediate, you just need to force "re-rendering" of the WV page. Or wait... Andree.sk (talk) 12:40, 19 June 2018 (UTC)

I added the metro mapshape to this article. It should show up in color in a few days? ויקיג'אנקי (talk) 13:09, 19 June 2018 (UTC)

This looks to me like some bug in the Kartographer or one of your other templates, as it is glitching quite a bit when moving the map around. The module:mapshapes there seems to work ok (I tried via the module debugger manually), it grabs the color from WD - but the template:mapshape doesn't show it. I tried to add there, and it just used the gray color for some reason (whereas here on EN WV, it shows in red, as expected). Andree.sk (talk) 14:47, 19 June 2018 (UTC)

Your Template:Mapshape/Inner was out of date, so I resynced it... Now the colors show up correctly ;-) Andree.sk (talk) 19:12, 19 June 2018 (UTC)

Thanks! ויקיג'אנקי (talk) 19:55, 19 June 2018 (UTC)

Mapshape and small cities/rural areas

Swept in from the pub

I'm wondering if randomly adding {{mapshape}} to small city articles is doing more harm than good, as the boundaries of the Wikivoyage article rarely match the boundaries of the incorporated municipality on Wikipedia or Wikidata. Our small-community articles are normally drawn so that one ends where the next begins, even if that means lumping huge, sparsely-populated rural areas into the nearest town or grouping them into larger, arbitrary entities.

For instance, https://en.wikivoyage.org/w/index.php?title=Brigham_City&oldid=3560241 superimposes a very tight, narrow boundary around the town itself, but the article extends out at least far enough to include Promontory Summit, a rural point near Corinne, Utah which is only notable as the "last spike" in US rail history.

Do we want the municipal boundary displayed on the map if it doesn't match the boundary of the article's coverage at all? K7L (talk) 17:27, 24 July 2018 (UTC)

I think that mapshapes should normally only be used on regions and city districts. The reader still wants to read the map to get to attractions which are out of town. I would also say that the full boundary co-ordinates should appear in the article, so that they can be adjusted for our use. AlasdairW (talk) 18:33, 24 July 2018 (UTC)

I don't think we should display a mapshape that doesn't match what is covered in the corresponding travel guide, regardless of where it falls in the geographical heirarchy. It's probably going to confuse readers and editors alike. Where I've come across inaccurate mapshapes placed by the bot, I've been commenting them out.

I'm not a fan of storing boundary coordinates in the article. A boundary could appear in more than one article (mapmask in the bottom-level and region/district shape in the next one up) so it increases the chances of errors if it needs to be maintained in more than one place. It also makes it more difficult to share across language versions. Unfortunately, the WMF made a mess of implementing shared map data in Commons, so I'm not sure there's a better option at this point. -Shaundd (talk) 18:54, 24 July 2018 (UTC)

Not all countries draw municipal boundaries in a way as to only include small surface areas. Have a look at San Carlos (Nicaragua) for one example... Hobbitschuster (talk) 21:57, 24 July 2018 (UTC)

San Carlos? That looks tiny; I could fit forty-eight of that into the Caniapiscau municipal limits with room to spare. Nonetheless, if we blindly import any boundary of anything from Wikidata, there is a need to manually check whether the result makes sense in the destination article. The case where our bottom-level article boundaries don't match the official boundaries of a single municipality (with the small-town municipal limits more often being smaller than the corresponding WV destination, jokes about 2760km cross-town car trips in northern Québec aside) is one example. Another is the subregion boundaries, as displayed in a region article. It's entirely possible that some of the subregions have boundaries on Wikidata which can be imported, while others in the same parent region do not - giving weird maps like https://en.wikivoyage.org/w/index.php?title=Southwestern_Quebec&oldid=3563397 where three of the subregions are shaded on the map and the rest are not. We occasionally use incorporated counties as bottom-level regions, but that's the exception rather than the rule. Usually, a county is too large to be a bottom-level municipality and too small to be a region in Wikivoyage, so we create our own divisions into arbitrary chunks like "Seaway Region" that contain a manageable number of cities - but have no official definition outside WV. K7L (talk) 03:20, 25 July 2018 (UTC)

And it has a delightful amount of exclaves without even the Vaduz (only capital village in Europe) excuse of feudalism and centuries of history... Hobbitschuster (talk) 03:26, 25 July 2018 (UTC)

Mapshape doesn't work

Swept in from the pub

Does anybody know why the Mapshape for Fort George doesn't work? If "geoline" is changed to "geoshape" nothing is shown on the map. The relation in OSM seems to be clean. Thanks for your help. --Renek78 (talk) 10:53, 2 August 2018 (UTC)

THe coordinates from OSM is correct - I built a geoshape on my homepage using <maplink> directly with those very same coords and there were no issues. (Note: I put in all the geo coordinates rather than use external) I noticed that in your example when I refreshed screen the mapframe showed a geoshape then map flashed and was overlayed with the geoline. Yes there evidently is something awry. (Someone may have recently changed something that is causing the slight malfunction you have noticed - I do not believe you are the first to mention this!) -- Best wishes -- Matroc (talk) 22:14, 2 August 2018 (UTC)

Just tried external with <mapframe> and <maplink> which does not work either for Q1426707 - other external geoshapes tested ok - ( Still have not found cause except I noted that Fort George (Q1426707) is an 18th-century fortress built in the Scottish Highlands in the aftermath of the Jacobite Rising of 1745 - and not in New York = perhaps some confusion with wikidata id is happening) -- Matroc (talk) 02:30, 4 August 2018 (UTC)

Thanks, Matroc. The wrong Wikidata ID could be the reason. Just changed it in OSM. Let's see whether it shows up correctly here in a few days... --Renek78 (talk) 22:23, 8 August 2018 (UTC)

Looks like it works now -- Matroc (talk) 03:15, 9 August 2018 (UTC)

You're right. So it seems to be important to apply the correct Wikidata ID! Thanks again, Matroc --Renek78 (talk) 09:38, 10 August 2018 (UTC)

Mapshape of NoHo not identical with the one in OpenStreetMap

Swept in from the pub

Another funny issue: The mapshape of NoHo/Manhattan looks differently here than on OSM. How's that possible again?--Renek78 (talk) 09:54, 10 August 2018 (UTC)

Looks like the NoHo wikidata ID is used by two areas actually: way/482797187 and relation/8398111. So I guess Kartographer just merges those? Andree.sk (talk) 10:16, 10 August 2018 (UTC)

Thanks Andree.sk! That was the reason for both boundaries! I cleaned them up in OSM. --Renek78 (talk) 11:49, 10 August 2018 (UTC)

Update: Same goes for Upper West Side. Is there any other place than OSM where Wikidata could get the shapes?--Renek78 (talk) 10:06, 10 August 2018 (UTC)

This is quite a wide-ranging problem; most of the mapshapes for English counties are also wrong, because the Wikidata item uses the modern administrative county, which has different boundaries to those of the ceremonial counties we use on WV. How would one go about changing this? Somehow, the WV article needs to link to the Wikidata item for the ceremonial counties.

With respect to the NYC neighbourhoods issue, is it possible there's a similar problem of there being multiple definitions of which areas exactly places like the Upper West Side and NoHo encompass? --ThunderingTyphoons! (talk) 11:29, 10 August 2018 (UTC)

One thought is to create a Data file and put it in Commons thus avoiding the use of defined OSM boundaries... This would be an external file with page parameter. May require some extra work, but I think that might work -- Matroc (talk) 21:41, 10 August 2018 (UTC)

Sorry for delayed response, @Matroc:; this must have got buried. To be honest, and forgive me, I don't understand your comment, because my technical expertise is limited. But if you think that would work, whoever decided to take it on would have my full support. --ThunderingTyphoons! (talk) 10:58, 16 August 2018 (UTC)

Issues with certain geoshapes

Swept in from the pub

Realized, that some geoshapes coming from OSM are not showing up correctly:

• Arganzuela. Relation in OSM for this district seems to be okay.
• Southern Ridges Walk. Missing segments in track. The OSM relation again is a clean, continuous path.

Anybody knows what's wrong? --Renek78 (talk) 11:17, 30 May 2019 (UTC)

It's difficult to find the cause. The only answer I can give is that the mapserver of the Wikimedia Foundation returns an almost empty GeoJSON result. You can try it for Madrid/Arganzuela:

https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q2000929

The empty answer:

{"type":"FeatureCollection","features":[]}

You can make a test with a correct dataset:

https://maps.wikimedia.org/geoshape?getgeojson=1&ids=Q335216

I tried in case of Madrid/Arganzuela to get a geoline instead of a geoshape. It was working. It means that the way/shape is maybe not closed. As a rule geoline is not working if the way/relation is closed but geoshape does; and vice versa.

In case of Southern Ridges Walk the map server returns a GeoJSON result, but the multi-line string consists of line parts which are some times not connected/closed.

Both the OpenStreetMap database and the conversion tool are stored on Wikimedia Foundation's map server. Either the relations are corrupt (maybe not completely closed) or too complex or the conversion tools is not working properly. Unfortunately I cannot make any further investigations. It should be done by the programmers of the foundation. --RolandUnger (talk) 14:31, 6 June 2019 (UTC)

Maybe OpenStreetMap is using auto-closing procedures. We should ask people from OSM for this prior to add a task on Phabricator. --RolandUnger (talk) 14:48, 6 June 2019 (UTC)

Some background information on OpenStreetMap as I understood: The main problem of OSM is to do not distinguish between line/multiline (usually not closed) and polygon/area (always closed). All elements are ways (or relations). A semantic information like building or administrative border makes an (unclosed) way to an area but a closed roundabout is a line but not an area. I assume that the conversion tools on WMF's mapserver check if a way/relation is closed or not and make it a polygon or line, respectively. And they will not add line parts to close a line or polygon. --RolandUnger (talk) 15:17, 6 June 2019 (UTC)

Thank you, RolandUnger. Since the relations in OSM are okay, it must be related to the conversion tool. --Renek78 (talk) 16:12, 11 June 2019 (UTC)

Why do many mapshapes stop showing the boundries after a while?

Swept in from the pub

Currently going over the entire Hebrew Wikivoyage and finding out that many of those stop working after a while. A good example for this here in the English Wikivoyage is in the article Galicia - as you can see, the dynamic map is currently all grayed out with no boundries, although it wasn't like that always. Is it because someone changed something on Wikidata? If so, it might be better to create the map boundries as a Mapmask with JOSM instead of letting wikidata fetch the boundries that later on might disapear. Any thoughts? ויקיג'אנקי (talk) 08:51, 11 June 2019 (UTC)

Must be a bug either in the OSM data (there were some edits to the relation recently), or incompatibility with Kartographer. I guess if you have multiple samples that used to work but don't anymore, post it here... Maybe there'll be some pattern obvious. -- andree.sk(talk) 09:02, 11 June 2019 (UTC)

There was also the mapshape for Russia on Hebvoy. For that one, becuase it is one of our most sought after articles, I decided to create my own boundries using a mapmask I made with JOSM and store it locally on Hebvoy. We had a bunch of other similar instances... I'll post them here when I remember which ones it happend to. ויקיג'אנקי (talk) 09:15, 11 June 2019 (UTC)

It is now only working with the type geoline. I do not why. Maybe the polygon is not closed. A similar problem was described above. --RolandUnger (talk) 16:07, 11 June 2019 (UTC)

Was edited about 19 days ago - saw note that duplicate nodes and other validation took place - I wonder if this had anything to do with issue at hand? Possible reason polygon might not be closed. -- Matroc (talk) 23:20, 11 June 2019 (UTC)

The island of Ios is completely under water according to it's Wikivoyage dynamic map

Swept in from the pub

Tracked in Phabricator ^(?)
Task T225592

How do we fix that? ויקיג'אנקי (talk) 07:46, 12 June 2019 (UTC)

I made a workaround but we cannot fix this. This is an error of the tilerator, the WMF's own tile server. The island exists in the OSM database. --RolandUnger (talk) 08:25, 12 June 2019 (UTC)

Isn't there anyone in charge of the WMF's tile server whom we could contact about issues like that? ויקיג'אנקי (talk) 09:26, 12 June 2019 (UTC)

Right; it's working fine on OpenStreetMap. --Comment by Selfie City (talk | contributions) 13:21, 12 June 2019 (UTC)

Phew... seemed like global warming got fast. /Yvwv (talk) 01:50, 14 June 2019 (UTC)

Georgia country boundaries not working

Can someone help with the mapshape not being displayed for Georgia. All the necessary conditions for the functionality seem to be met ... still.

The https://commons.wikimedia.org/wiki/Data:Georgia.map seems proper and is linked in the wikidata page.

Cheers, Ceever (talk) 06:34, 19 September 2019 (UTC)

AFAIK, the .map files from commons are not used for rendering mapshapes (only the OSM relations. But they are present and tagged by wikidata ID, so I'd say this is the usual case of wikimedia map/relation processing bug). If you really want the .map file, check the documentation, parameters type=page and wikicommons=.... -- andree.sk(talk) 20:17, 21 September 2019 (UTC)

Where does mapshape come from?

Swept in from the pub

On dynamic maps, when a mapshape is present, how is it generated. Many of the English counties' mapshapes are completely wrong, omitting parts of the counties, and it would be nice to get them fixed.--ThunderingTyphoons! (talk) 21:20, 25 March 2020 (UTC)

My understanding is that sometimes it comes from OpenStreetMap, sometimes from Commons, and sometimes from code in the page itself. OpenStreetMap data occasionally develops substantial errors, which usually seem to go away in a few days or weeks. Others may know more than I do. —Granger (talk · contribs) 22:58, 25 March 2020 (UTC)

I think it's from Openstreetmap via Wikidata. Not sure if adding code to articles is possible nowadays, or if code added here is overridden by anything from WD. --Ypsilon (talk) 07:05, 26 March 2020 (UTC)

Depends - in {{mapshape}}, you can either use wikidata ID (in which case it will be from OSM), or specify the commons GeoJSON. Usually, if OSM data are completely wrong, there's either a kartographer error (AFAIK it doesn't like e.g. incorrectly closed shapes - they render normally on OSM, but incorrectly on wikipedia), or some wikidata tagging problem (missing wikidata for some areas), or e.g. local OSM editors have different opinion on what a country is than WV (e.g. Japan regions also extend to sea, which some local editors don't like; Taiwan has it differently). -- andree.sk(talk) 10:19, 31 March 2020 (UTC)

Thanks for the answers, all. The ones I'm referring to - e.g. Hampshire, Dorset, East Sussex, Lincolnshire - just have {{mapshape}} in the article, so the shape obviously comes from one of the external sources, WD OSM etc. Any way of knowing which?

Andree has got it right, I think, with "local OSM editors have different opinion on what a country is than WV", as the mapshapes seem to show the administrative counties, which is not what we use on Wikivoyage (we use the ceremonial counties).

I looked on Wikidata's entry for Lincolnshire, and noticed they had the wrong OSM relation ID, associating with the administrative county rather than the ceremonial county. I changed it to the right one about two hours ago, hoping that this would change the mapshape on WV's Lincolnshire article, though so far nothing has changed. Even taking into account that changes to Wikidata can sometimes take a while to filter through to WV, this is taking its sweet time, if indeed anything is going to happen.--ThunderingTyphoons! (talk) 13:45, 31 March 2020 (UTC)

If it just has {{mapshape}}, then it's finding the Wikidata item associated with that WV article (you can see this yourself in the sidebar with the "Wikidata item" link under "Tools"). From there, I'm uncertain whether it finds that WD item's OSM relation, or whether it looks for an OSM relation tagged with that WD item.

The relationships work in both directions to some degree, and I'm not sure changing it only on WD is sufficient. The administrative boundary on OSM has the tag wikidata=Q23090, so that may take precedence somewhat. Given the awkwardly-placed note in Q23090's description, I think what ought to be done is edit OSM relation 78312 to have wikidata=Q21269047, and edit OSM relation 1916530 to have wikidata=Q23090. Having made similar edits for rail lines, I think within a couple of days that change will get pulled into the Wikidata entries by some automated process, which will then make things show up as desired here. --Bigpeteb (talk) 17:02, 31 March 2020 (UTC)

Indeed, for the stuff to work, it has to be mainly in OSM database - I think whatever is OSM relation is written in WD isn't really taken into account. Once you update the OSM relation (to refer to the "correct wikidata"), it takes about a day or two to show up on WV... -- andree.sk(talk) 19:18, 31 March 2020 (UTC)

So I updated the OSM relation field on Wikidata yesterday before posting my previous comment, but haven't yet changed anything on OSM itself. I just made an account on OSM, and can't work out how to edit the Wikidata field there. There must be a way, but I can't find it. Will post on the help forum over there.--ThunderingTyphoons! (talk) 16:28, 1 April 2020 (UTC)

Posted.--ThunderingTyphoons! (talk) 16:51, 1 April 2020 (UTC)

ThunderingTyphoons!: Another option, albeit labor-intensive and time-consuming, is to dispense with Mapshape entirely and enter coordinates manually using Template:Mapmask. See any of the new-school Buffalo district articles in my userspace, e.g. User:AndreCarrotflower/Allentown, for an example (click to the "Edit" screen and scroll all the way down). -- AndreCarrotflower (talk) 16:54, 1 April 2020 (UTC)

Tis a nice idea, and certainly one I'd consider, but would have to be a last resort. We in Europe don't have the luxury of straight borders, so inputting all the coordinates to make a polygon complex enough to be an accurate representation of even one county will take forever. I had briefly thought that OSM might already have a list of the coordinates, but they use something called "nodes" instead. Bugger.--ThunderingTyphoons! (talk) 17:03, 1 April 2020 (UTC)

• Or one can directly code using <maplink> or <mapframe>: This method is a bit more complicated or specialized to accomplish. Use this type of coding perhpas if all else fails. I took coordinates from mapshape mentioned above as an example. (also added a hidden marker) and used group and show parameters.. 1. Allentown with mapmask Polygon 2. Allentown as filled Polygon 3. Allentown as LineString Coding would provide basis for crating a map file in Commons. Note: Simpler and easier with existing Templates and to best use them as much as possible. -- Matroc (talk) 03:23, 2 April 2020 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Whatever benefits OSM brings to the world, "easy editing" is not one of them. Unlike the loosely-structured text we work with in wikis, geographical data is much more structured; editing it first requires you to understand the structure (which for OSM also means understanding its massive, complex, and sometimes problematic set of tags) and also learning how to use the editors, which is also not very easy. Although the OSM forums are the right place to ask (well, one of the places, if perhaps not the best one), I'll try to explain it here as it may be helpful for other WV editors.

The manual way of selecting things and editing is the one you probably think of first. You navigate around on the map looking for what you want to edit.

1. Zoom to an area where you can see the things you want to edit. Given the two relations I wanted to edit (78312 and 1916530) I went to this bit of coastline where I can pick them out separately.
2. Click the "Edit" button to open the in-browser "iD" editor. From here, you can do it the manual way or the easy way.
3. Given where I started, I got a message that I need to zoom in. Zoom in slowly towards that coastline until the message disappears and it loads shapes.
4. Click one of the lines (in OSM terms, a "way") to select it. Click on the line, not the yellow highlighting (which would select the "beach" area rather than the line). It will select that line (way) and display all its attributes in the edit pane on the left.
5. In the edit pane on the left, scroll down. There's a section for "All relations" which lists the "relations" that this line (way) is part of. Unfortunately, they're only given by type and name, not ID. I clicked the line in the southeast quadrant, so it has three that may be relevant based on their names:
   • Administrative Boundary - Lincolnshire
   • Boundary - Lincolnshire
   • Boundary - Lincolnshire
6. For this example, let's take the from bottom to top. (It ends up being educational that way.) Click the last one, "Boundary - Lincolnshire", to select it.
7. We need to figure out if this is the relation we were looking for. In the status bar at the bottom of the edit pane on the left, there's a "View on openstreetmap.org" link. Hover over that (or Ctrl-click it to open in a new window/tab), and we can see from the URL that it's relation 8483972. Oops, that's not one we wanted. And at the top of the edit pane, we can see this boundary is of type "traditional"; that's not the one we were looking for. Let's try again.
8. Click that same line (way) to select it again. Go to the "All relations" list.
9. This time, pick a different relation. Moving up the list from the bottom, let's try the second from bottom, which is also labeled "Boundary - Lincolnshire".
10. This one has type "ceremonial", and hovering over the "View on openstreetmap.org" link we can see its ID is 1916530; that's one of the ones what we wanted.
11. Looking under the "All fields" section near the top, it doesn't have a Wikidata field, so let's add one. At the bottom of that section, there's an "Add field" box. Start typing "wiki", and you'll get "Wikidata" as one of the possible fields. Click it.
12. In the Wikidata field, type "Lincolnshire". Unfortunately, there are quite a few to choose from! You need to match up the correct Wikidata ID, or you could simply paste that ID into the box instead (Q23090). In either case, click the correct "Lincolnshire" from the list (even if there's only one) to select it. That will fill in some read-only fields so you can verify it's linked to the correct Wikidata ID.
13. Now you can save your edit, or you can edit the other county and save both of them in one edit. Let's do that, slightly differently this time.
14. Click the line (way) to select it again. This time we'll pick the remaining "Administrative Boundary - Lincolnshire" relation near the top of the list. As before, check that this is the relation we want (relation 78312, and its type is "administrative").
15. This time, scroll down to the "All tags" section in the middle of the edit pane. Instead of using the friendly editor, we'll just edit the tag manually.
16. This has 8 tags, and wikidata is one of them. For some tags, you might have to know what format the value needs to be in, which is documented on the OSM wiki, but fortunately Key:wikidata is an easy one: it should just be the Wikidata ID, nothing more.
    • If it didn't have the tag we need, we could easily add it. Click the "+" button to add a tag. Type "wikidata" in the left column; it will autofill. Then paste the Wikidata ID we want (Q21269047) in the right column.
    • Since it does have a tag, we just need to change the value. Edit the value for the wikidata tag in the right column and paste the Wikidata ID we want (Q21269047).
17. In either case, you can check your work by scrolling back up to the "All fields" section and see if the correct data in the Wikidata section has appeared. (Not all tags get represented this way, but many common ones do.)
18. Finally, save your edits. In the far top right, there's a "Save" button. It should show "2", indicating that you've made 2 edits (or edits to 2 items, whatever). Click it, write a change summary, and save.

The easier way goes like this:

1. Instead of moving around on the map, just put yourself anywhere and click the "Edit" button.
2. Using the search box on the left pane, paste the ID of the thing you want to edit, such as 78312.
3. It turns out there's a node, a way, and a relation all with the ID 78312. They're not related to each other; IDs are not unique between the different types of objects, so you have to know which you want. We want to edit relation 78312, so click it.
4. After a couple seconds, it will finish loading and you'll see it highlighted in the map.
5. Follow other instructions from above to add or edit the Wikidata field/tag.
6. You can click the X at the top of the edit pane to unselect that item, which will bring you back to the search box.
7. Search for the other relation, edit as above, and finally save.

Whew. It's not as complicated as it sounds once you're familiar with it, but it definitely takes some learning. I'm obviously trying to dumb it down to be as explicit as possible, but it's clearly more like editing Wikidata than WV, and harder still because you have to think and operate more (geo)graphically. --Bigpeteb (talk) 19:05, 1 April 2020 (UTC)

Wow, @Bigpeteb: thank you for the detailed explanations! I will attempt to read and understand them tomorrow, when I'm fresh (and supposed to be working, but mehhh.) Regards, ThunderingTyphoons! (talk) 20:49, 1 April 2020 (UTC)

Using your detailed guidance and the advice I got on the forum, I have today been able to correct all of the OSM-WD relations that affect English county articles here. Now we play the waiting game to see if, when the various systems update, my changes affect what we can see on WV. --ThunderingTyphoons! (talk) 21:57, 2 April 2020 (UTC)

ThunderingTyphoons! Just a note that all OSM relations of Wikimedia are currently out of date because we are not syncing with OSM (since late january or early feb). This is because the server ran out of harddisk space. Some new hardware is being prepared for this, but with all the covid19 stuff happening it's a bit delayed. TheDJ (talk) 22:26, 11 April 2020 (UTC)

Ah, that'll be why the maps haven't updated over here. Thanks for sharing that info =) --ThunderingTyphoons! (talk) 22:30, 11 April 2020 (UTC)

Mapshape malfunction detected

Swept in from the pub

Tracked in Phabricator ^(?)
Task T267296

As I was tweaking earlier today (here and here), I happened to notice that markers are not showing on dynamic maps that have the Mapshape template. The mapshape itself does not show either. However, once the template is removed, the markers reappear on the map. I don't understand the code so the best I can do is report this issue. Ibaman (talk) 11:38, 30 October 2020 (UTC)

I see both the maphape masks and markers in both cases (e.g. here), so perhaps some local/temporary issue...? -- andree.sk(talk) 14:58, 31 October 2020 (UTC)

I have the same issues as Ibaman (and don't know how to sign on mobile view...)

It seems that the WFM's mapserver is now stable and working. --RolandUnger (talk) 09:16, 7 November 2020 (UTC)

Spelling mistake

title: (Optional) Title to be shown when the mapshap is clicked (can contain a reference too, for example). - this should say "mapshape". 82.3.185.12 13:08, 5 June 2021 (UTC)

Default Colour

Swept in from the pub

What is the colour than covers our mapframe if no mapshapes are applied and what is its colour code. Tai123.123 (talk) 05:12, 9 November 2021 (UTC)

I don't think there's a default colour for our mapframes if there's no mapshape applied, but not too sure. SHB2000 (talk | contribs | meta.wikimedia) 06:39, 9 November 2021 (UTC)

Mapshape problems

Swept in from the pub

When colors are missing, the map center also changes

At Venice#Get around the Mapshape does not work very well. The colors of several areas do not show. Clicking the refresh button of the browser makes the colors show for less than a second. The format of those Mapshapes is:

• {{Mapshape|type=geoshape|group=map1|wikidata=...|fill=...|title=...}}

It is not constant, this morning the shapes that were not there were different from what I see now, some hours later. FredTC (talk) 11:03, 27 July 2022 (UTC)

Opening the page now (10 minutes later) again, and there is no problem. --FredTC (talk) 11:17, 27 July 2022 (UTC)

Opening the page now (next day) again, and the problem is back. --FredTC (talk) 01:47, 28 July 2022 (UTC)

@FredTC: This issue has been a recurring issue for some time that LPfi and I have noticed. When I made a detailed dynamic map for New South Wales last November, every single mapshape appeared. Eventually the mapshape for Narrabri Shire disappeared, never to be seen again (even though there was nothing wrong on OSM). A few months later, Tweed Shire and Griffith City Council disappeared, never to be seen again. There have been a few other recent cases too. Here are my suggestions for the time being:

• For city districts and small regions, manually trace the districts yourself using geojson.io
• For larger region articles, revert back to using traditional, old static maps.

Static maps aren't perfect though. The dynamic map in Greater Brisbane was clearly superior to the static map (that's overly crowded) and some of the colour scheme for regions is basically calling this. I'll need to adjust the colours soon, but in the case for Venice, I think manually tracing out the route using geojson.io is a much better alternative to using static maps (I'll help you with tracing the route if needed) SHB2000 (talk | contribs | meta.wikimedia) 09:52, 28 July 2022 (UTC)

I am not sure this is the same problem. I haven't noticed the mapshapes appearing for a moment, and that also does not make sense for the description of the bug on Phabricator. The bug we discussed earlier meant, if memory serves, that the database lost mapshapes over time, and the problem was cured for that shape only when it was fetched again, which I think is about weeks rather than hours or minutes. Something disappearing soon after loading a page sounds like a Javacript problem (as Javascript is executed after page load and can change the appearance). –LPfi (talk) 12:23, 28 July 2022 (UTC)

I guess we need to open a task in Phabricator. Maybe in a year someone will have a look at it... --Renek78 (talk) 10:44, 30 July 2022 (UTC)

Noticed this again on Blue River Provincial Park. Never before have I been so grateful for the mapmask-geojson converter you made. SHB2000 (talk | contribs | meta.wikimedia) 09:24, 31 July 2022 (UTC)

And again in Tongariro Northern Circuit. SHB2000 (talk | contribs | meta) 01:22, 12 August 2022 (UTC)

I added an image that also shows a changing map center when colors are missing. This might be useful for problem analysis. --FredTC (talk) 12:07, 19 August 2022 (UTC)

"class=no-icon" no longer works

Swept in from the pub

Tracked in Phabricator ^(?)
Task T328739

An example of this issue on Hobart#Get around

See Hobart#Get around or Sorell#Get around for some examples of this issue. I think this issue originates from Template:Mapshape, though I have no clue how to fix this. --SHB2000 (talk | contribs | meta) 09:48, 3 February 2023 (UTC)

I should also point out that it gets even worse with region articles – see Tasmania#Regions, for example. --SHB2000 (talk | contribs | meta) 09:52, 3 February 2023 (UTC)

This is a bug of the Kartographer map team. Today's morning I created a Phabricator task. --RolandUnger (talk) 18:34, 3 February 2023 (UTC)

The bug was resolved. --RolandUnger (talk) 06:57, 14 February 2023 (UTC)

Yay!!!! Ikan Kekek (talk) 08:11, 14 February 2023 (UTC)

@RolandUnger: thank you for handling this issue! SHB2000 (talk | contribs | meta) 08:40, 14 February 2023 (UTC)

District section crazy coordinate strings

Tracked in Phabricator ^(?)
Task T328739

What on earth is going on with the District sections in articles like Madrid and Beijing. I see a bunch of crazy coordinates at the top of the sections. Appears on both Chrome and Firefox. Is it just me who is seeing this? Brycehughes (talk) 11:36, 3 February 2023 (UTC)

@Brycehughes: did you read the thread above this? SHB2000 (talk | contribs | meta) 11:48, 3 February 2023 (UTC)

@SHB2000: Ah, I did, casually. And I didn't realise it was related. Thanks. Brycehughes (talk) 12:25, 3 February 2023 (UTC)

I saw that thing this morning (about 9 hours ago) in Japan#Regions and #Cities but didn't think much of it. --Ypsilon (talk) 15:33, 3 February 2023 (UTC)

Popped up for me too (in several other articles). Has some template recently been changed or is the culprit Mediawiki-side? ––LPfi (talk) 15:46, 3 February 2023 (UTC)

As I noted in the task above this is a big programming failure of the Kartographer map team. I ask them to revert the last changes. This is the second serious failure within the last two weeks. --RolandUnger (talk) 18:38, 3 February 2023 (UTC)

@Johanna Strodt (WMDE): seems to be responsible for the programmeer's team. --RolandUnger (talk) 19:00, 3 February 2023 (UTC)

I do feel like there's some larger issue with the WM development team where Wikipedia gets all the attention (and QA) while Wikivoyage gets kind of ignored. E.g. I've been waiting on this bug for years. Brycehughes (talk) 17:36, 4 February 2023 (UTC)

I agree; it's not just Wikivoyage, though. At times, I sometimes feel the development team does not give a shit about all its non-Wikipedia content projects (including Commons and Wikidata), and this is another example of why. SHB2000 (talk | contribs | meta) 20:30, 4 February 2023 (UTC)

Yeah. Anyway, this one is pretty embarrassing. I wonder how long it takes them to merge to production and deploy. I've never really understood that gerritbot helper they have over there. Brycehughes (talk) 01:40, 5 February 2023 (UTC)

Assuming that it passed code review (which normally requires two humans to approve it), or that it will do so before the cutoff on Tuesday, then it will probably appear here on Wednesday. If you are interested in the schedule, it's at wikitech:Deployments. The Wikivoyages are part of Group1 (the three groups are named 0, 1, and 2). WhatamIdoing (talk) 22:31, 5 February 2023 (UTC)

Another instance at Beijing/Forbidden_City#Understand. Pashley (talk) 02:09, 5 February 2023 (UTC)

Hello everyone, thanks for your messages. I am Johanna, your contact person for Wikimedia Deutschland’s Technical Wishes team (I‘m not responsible for the programmers, by the way). Firstly, thanks for reporting this bug. Our team started working on it directly on Friday, but there is a no-deploy policy from Friday to Sunday. Now, the fix has been deployed. To quote my colleague on the Phabricator ticket, “It might be that due to caching some links are still visible. They will vanish over time as the cache gets invalidated, or by updating the page with an edit.”

As a team, we understand the frustration that things are breaking here on Wikivoyage. In the past months, we have improved lots of different aspects of Kartographer, also many things in the backend and the underlying server infrastructure to make Kartographer more sustainable. It is very unfortunate that now, at the end of our work in this focus area, two issues have popped up. (T328739, T327151)

In this particular case (T328739), we wanted to clean up the code, and we found something that very much looked like a bug. We fixed it, not knowing that this code was used to hide maplinks that add markers to groups. Because it so clearly looked like a bug to us, and our unit tests didn’t produce any errors, we didn’t think about reaching out to you all before we deployed this change.

While we understand where the sentiment is coming from, we don’t agree that this was “a big programming failure”. The two recent issues were certainly unfortunate. But they were not severe bugs that broke something permanently, and we fixed them as soon as we could. Unfortunately, mistakes can always happen, especially in a complex system such as the Wikimedia technical sphere. But we are here to quickly fix any issues that we have caused.

As I have said, we are basically finished working with Kartographer, and are shifting our work to our new focus area “Reusing references”. Before that fully happens, there are smaller Kartographer things that we are still working on:

• T308227: clustering markers in the new “show articles nearby” feature
• T328760: a long-standing bug in the backend that we hope we can fix

If you spot something in there that might affect your gadgets etc., please let us know on the tickets.

Last but not least, despite all the unpleasantness, there is something to be learned here: As we are diving into the new focus area, we want to find ways to integrate members of all communities into our processes better and earlier. If you have any thoughts on this, I would be more than happy to hear about it. – Thanks, Johanna Strodt (WMDE) (talk) 13:19, 6 February 2023 (UTC)

Johanna, thanks for updating us on your progress. Ikan Kekek (talk) 00:02, 7 February 2023 (UTC)

Mapshape template broken?

The {{mapshape}} template seems to be even more broken? In articles like Hokkaido#Regions, it's just printing out "0°0′0″N 0°0′0″E" instead of actually drawing shapes on the map. See also Template talk:Mapshape. Jpatokal (talk) 00:37, 6 February 2023 (UTC)

See also #District_section_crazy_coordinate_strings above. Pashley (talk) 01:17, 6 February 2023 (UTC)

Same problem on Austin and Austin district articles. Ikan Kekek (talk) 01:28, 6 February 2023 (UTC)

See Special:WhatLinksHere/Template:Mapshape for more examples and maybe see another pattern than "has mapshape". --FredTC (talk) 01:52, 6 February 2023 (UTC)

Appreciate this discussion, but in future, can you please not start a brand new discussion that's already being discussed twice? Having the same discussion being discussed in three different places is just difficult to keep things in one place. SHB2000 (talk | contribs | meta) 05:42, 6 February 2023 (UTC)

Many dynamic maps broken

Dynamic district overview maps which get their boundaries from OpenStreetMap via Wikidata id's are broken all over the site, e.g. Paris or Tokyo. This is the error message in the browser console:

Failed to load resource: the server responded with a status of 404 (https://maps.wikimedia.org/geoline?getgeojson=1&ids=Q1083349)

The issues with imported OSM elements like boundaries or public transport lines are going on for months, if not 1-2 years already. Really a pity because those dynamic maps could be so useful for the traveller. Renek78 (talk) 10:22, 30 July 2022 (UTC)

Didn't see the discussion above ("Mapshape problems"). Same thing.--Renek78 (talk) 10:42, 30 July 2022 (UTC)

This is even more broken now: not only are the shapes not being drawn, but the template is printing out "0°0′0″N 0°0′0″E" every time it's invoked. See eg Hokkaido#Regions. Jpatokal (talk) 00:39, 6 February 2023 (UTC)

The map text coordinates bug returns?

Swept in from the pub

@SHB2000, RolandUnger: I'm still seeing the map text coordinates bug beside the map under the Cities section at Lake Sevan Region. Are you? Has it returned or is this something new? Brycehughes (talk) 07:58, 19 February 2023 (UTC)

After a refresh (null edit) it is gone. --RolandUnger (talk) 08:10, 19 February 2023 (UTC)

I haven't seen anything since it was resolved. SHB2000 (talk | contribs | meta) 08:12, 19 February 2023 (UTC)

Ah, well I guess the null edit script I'm working on with the WM dev team will fix these hanger-ons too. Thanks, Brycehughes (talk) 12:12, 19 February 2023 (UTC)

Colored rectangles caused by mapshapes

Tracked in Phabricator ^(?)
Task T355044

Recently I noticed colored rectangles in sections where template:mapshapes is used, like in the top of the See section of the Bangkok/Khao San Road article. FredTC (talk) 13:03, 11 January 2024 (UTC)

This usually happens with errors in making points in the map. First off, I do not see this problem on this article. Secondly, it seems like there are two virtually identical dynamic maps on this page. Which one seems to have this problem? —Justin (koavf)❤T☮C☺M☯ 17:13, 11 January 2024 (UTC)

@User:Koavf: I was looking at the two identical maps and what to do with them, when I noticed these rectangles. At first I thought that I created them by some changes I was testing but not saving. And then I looked at the original version and saw the problem was there too. My idea about the identical maps was moving the second map to the top of the eat section and let it show only eat, drink and sleep and let the first map not show these items. --FredTC (talk) 11:32, 12 January 2024 (UTC)

Ah, I see the boxes mentioned below now. —Justin (koavf)❤T☮C☺M☯ 11:41, 12 January 2024 (UTC)

It's visible right under the "See" heading, a bunch of green boxes. -- andree 21:10, 11 January 2024 (UTC)

I see this on Fiordland National Park but not on Southland – is this only affecting a select few articles? --SHB2000 (talk | contribs | meta) 11:59, 12 January 2024 (UTC)

Southland has no mapshapes. FredTC (talk) 12:07, 12 January 2024 (UTC)

Yes it does. SHB2000 (talk | contribs | meta) 12:16, 12 January 2024 (UTC)

But that is template:mapshape, not template:mapshapes. FredTC (talk) 12:22, 12 January 2024 (UTC)

Nuh uh, Fiordland National Park uses {{mapshape}} and has the same issue. SHB2000 (talk | contribs | meta) 12:27, 12 January 2024 (UTC)

Yes, after testing more than 5-6 articles from the "What links here" list of both templates, I found out that both templates can have and can not have the problem. FredTC (talk) 13:05, 12 January 2024 (UTC)

No recent changes to either, so likely some kartographer fluke, as usual... it seems to generate some strange <a> tags... -- andree 19:35, 12 January 2024 (UTC)

The problem occurs when there are listings like {{listing ...}}, {{see ...}}, {{do ...}}, etc. and also {{marker ...}} before the {{mapshape ...}}/{{mapshapes}}.--FredTC (talk) 06:54, 13 January 2024 (UTC)

It happens also at other languages like in the Italian article about Lisbon. --FredTC (talk) 01:51, 15 January 2024 (UTC)

Can someone explain what the article and the templates are SUPPOSED to do ? Because it's difficult to investigate a problem like this if I'm not sure what I'm looking for and these templates all have a bazillion options. TheDJ (talk) 13:38, 17 January 2024 (UTC)

The colored rectangle btw is a link to open a map. But this link has no textual contents (its text attribute is empty), so you only see the coloured background of the padding surrounding the link. TheDJ (talk) 13:48, 17 January 2024 (UTC)

@TheDJ: These articles have a map generated by Template:Mapframe. The templates Template:Mapshapes and Template:Mapshape are intended to show shapes on that map, such as train lines and the shapes of regions. In the article Fiordland National Park, the mapshape template seems to be doing this correctly (you can see the outline of the region on the map), but it is also creating the undesired green box with a link. These colored boxes were not appearing until recently. —Granger (talk · contribs) 14:25, 17 January 2024 (UTC)

The fix for this will roll out next week. Thank you for reporting ! TheDJ (talk) 12:09, 18 January 2024 (UTC)

This is now fixed, but affected pages may require a manual purge to get rid of the cached (bad) result from before the fix. TheDJ (talk) 09:35, 30 January 2024 (UTC)

(New) Feature on Kartographer: Adding geopoints via QID

Since September 2022, it is possible to create geopoints using a QID. Many wiki contributors have asked for this feature, but it is not being used much. Therefore, we would like to remind you about it. More information can be found on the project page. If you have any comments, please let us know on the talk page. – Best regards, the team of Technical Wishes at Wikimedia Deutschland

Thereza Mengs (WMDE) 12:31, 13 December 2023 (UTC)

I believe our project uses geopoints extensively in our articles. OhanaUnited^{Talk page} 14:28, 13 December 2023 (UTC)

So a huge thanks to German Wikimedia eh? I remember being like wtf all this stuff is on the map now but I wasn't sure why. This has been one of the best tech improvements for Wikivoyage (rare!) in a few years. (Assuming this is what actually caused those point to get on the maps, I'm pretty dumb.) Brycehughes (talk) 17:35, 13 December 2023 (UTC)

Shameless plug! DE had it actually before EN, and nowadays we use module from @Andyrom75. But 5 years ago, "we" invented our own wikidata fetcher, in parallel :-P But back then, hardly anyone used WD, so it didn't lift off that fast... :-) -- andree 20:45, 13 December 2023 (UTC)

It's really good. I guess the original post was just a copy-paste message re the "not being used much" (that's why i was/am confused about whether we are actually using that system), but it's been a huge help. There was an article I read a while back about Wikidata and the people who spend hours/days/months just inputting (for the hell of it!)... it's amazing work. Brycehughes (talk) 08:26, 14 December 2023 (UTC)