What about integrating a Wikidata ID parameter in the listings templates? The dynamic map could show pictures, auto descriptions, websites or other related information based on this mapping. It would be especially useful for sights. The map could also gain a multilingual feature based on the translations stored in Wikidata. What do you think? T.seppelt (talk) 12:27, 9 May 2016 (UTC)[reply]
A {{listing|wikidata=...}} parameter was suggested but (at least on en:) nothing was ever done about it. No one had given any thought to integrating it into the map. Interesting idea.
The question of whether {{listing}} could auto-lookup address, telephone number or other missing fields was raised. That could be done in a few ways: a listing editor which uses Wikidata to populate other fields (which would then be saved with the page), an automated "bot" script using the Wikidata link to look up and populate other fields in the listing or the listing template/module looking up the missing fields on-the-fly when the page is rendered. While it's now possible for a Lua module: to look up an arbitrary field from any arbitrary Wikidata entry, this lookup is "expensive" in server time. That may be one reason that no one has actually tried to use this. Some languages (fr: at least) do have a "wikidata" field in {{listing}} which generates a visible, clickable link but their current deployment implements no automated lookups based on the information.
Wikidata might be usable as a way of detecting that a change has to be applied to multiple language pages ("oh look, the Super 8 is now rubble, lets remove it from fr:Fort McMurray") if it gave the listings a unique identifier (such as a Wikidata Q-number) to identify them as the same venue. The downside is that every listing would need a Wikidata entry, which is a huge number of records to be created. We could try to identify a listing uniquely from a telephone number or other contact info, but that's risky as the listed number is often the franchise chain´s reservation desk. +1-800-800-8000 tells us the property was a Super 8, but doesn't tell us which Super 8. Contact info also is likely to be affected by franchise affiliation changes (so a Knights Inn becomes a Days Inn and the website or freephone numbers change, while the rest of the local info is the same).
Occasionally, we do translate entire articles from other languages: Amqui is a blatant ripoff of fr:user:Amqui's article on francophone Wikivoyage and Matane is just more of the same. A Wikidata link might get us the English-language name of an individual venue, but the description text would still need to be rewritten.
I suppose there are two key unanswered questions: (a) how do we get a Wikidata number for every listing in the first place? (b) how do we avoid this causing a lot of time-consuming lookups every time the server regenerates the page? Neither is unresolvable, but little has been done to pursue this as the odds of a site having a Wikidata Q-number listed in any-language Wikivoyage if the rest of the info is incomplete in the listing is low.
I'm also a bit unsure what you intend by "auto descriptions" on the map pop-up captions. There isn't much room in that bubble for anything more than a name and a thumbnail image. I suppose d:Q134883 could cause the cartoon caption style box to pop up when clicked with "w:CN Tower, www.cntower.ca" instead of just the name; until it's clicked, nothing happens so no huge change in server load? (We handled an image field that way, listing|image=...whatever... only displays when a map icon is clicked.) (Oddly, neither WP nor Wikidata has the telephone number for this building, but both know it is precisely 553.3±0.1 metres tall). K7L (talk) 18:12, 9 May 2016 (UTC)[reply]
I've been giving some thoughts to Wikidata integration for listings based on the discussion at Wikivoyage talk:External links#Revisit policy on linking to sister sites?. For places that have their own Wikipedia article (and thus an existing Wikidata item) I think this field could be very useful at least for lat/long, official link, and possibly link to Wikipedia, with the possibility of utilizing additional fields as time goes on. At least initially I'd suggest limiting this type of integration to only existing Wikidata items, and NOT create new items for places like the local Super 8 motel. Also, as K7L notes, performance would need to be investigated, and language differences would initially limit the number of fields that would be feasible for sharing. I haven't had time to pursue this integration yet, but I think it might not be too hard to add a Wikidata lookup to the listing editor, and it would then be easy enough to use that field to modify the listing templates to display lat/long and official link from Wikidata (if that info isn't explicitly included in the listing data). -- Ryan • (talk) • 18:30, 9 May 2016 (UTC)[reply]
I'm wondering if moving clickable icons into the pop-up cartoon bubble on the map (like we do for listing|image=... now) might be a possible compromise to keep this stuff out of the main text body? It'd appear (under the image) only if the map icon is clicked. There are fr:Modèle:Listing icons for everything from wheelchair access to wi-fi; moving these to the pop-up map bubble minimises clutter, at the expense of displaying only if valid (lat, long) are present.
The other possibility is that the wikidata= field is used only behind the scenes to do other lookups, and not displayed as a clickable link at all.
That still leaves the issue of how to get the Q number into the listings. Telephone number as unique identifier is more difficult than I expected, as too many records like d:Q1631006 seem to omit it (and that's a really famous number). Maybe we could use the phone number to match en: listings to listings in other-language WV editions, then see if those {{listing}}s contain Wikidata or WP links which an automated script could use to access useful or interesting information via Wikidata. K7L (talk) 19:58, 9 May 2016 (UTC)[reply]
New maps have been enabled on en-wikivoyage. Please add your comments here, or create Phabricator tickets. All layers code is at MediaWiki:Kartographer.js, so either experiment there or do pull requests at GitHub. Once the code is more stable, I will move it into a proper MW extension, so that it can be localized and shared for all other languages (please don't copy it to other langs just yet).
Done {{mapmask}} does not seem to be implemented for the new maps - see Culver City for an example of an article that should include a mask. Is there another way to implement this functionality with the new maps? -- Ryan • (talk) • 21:35, 8 June 2016 (UTC)[reply]
A new version of Kartographer was deployed today, and we forgot to add a config flag. Thanks for the heads up, it is now fixed. --Yurik (talk) 23:21, 8 June 2016 (UTC)[reply]
Done When editing Helsinki/South about an hour ago, I was wondering why someone has put a superfluous sleep price range box above the dynamic map. It doesn't show up anywhere in the article's wikicode either. Then I noticed the same thing in all other Helsinki district articles. And in every article with a mapframe from Nashville to Nuclear tourism. Perhaps it has something to do with the new map?
Technically the mapmask is incorrect because the last point has to be the same as first (at least according to my reading of the geojson spec). But it seems to work ok without it, so i removed the validation. --Yurik (talk) 15:17, 10 June 2016 (UTC)[reply]
Done Would you also consider adding a parameter to {{mapframe}} so that user can select which group(s) ie. |groups=go,sleep,do| go on a map as well? otherwise use default list? -- Matroc (talk) 16:19, 10 June 2016 (UTC)[reply]
I'm not sure if it's necessary to be able to switch on/off different types of labels individually. In the former version of the dynamic map it was possible to either see all POIs or no POIs and I didn't find it problematic. ϒpsilon (talk) 17:44, 10 June 2016 (UTC)[reply]
@Yurik: - I tested {{mapframe}} with parameter "show=see,do,city" and the result was only those 3 groups will show on a map and in layers dropdown - if you do not have a "show=" parameter in {{mapframe}} then the default list appears -- will leave a note in Template : mapframe talk page for this to be added when things quiet down a bit??? (nice to be aware of) -- Matroc (talk) 04:38, 12 June 2016 (UTC)[reply]
Done 169 pages with script errors - Lua error in Module:Map at line 89: Polygon's first and last points must be the same. (coordinates issue) -- Matroc (talk) 15:22, 10 June 2016 (UTC)[reply]
I suspect this was due to most mapmasks having non-standard coordinates. See my answer above. I removed the verification, so all of them should be gone. --Yurik (talk) 15:38, 10 June 2016 (UTC)[reply]
Done Some of the problems noted above can be resolved using <mapframe> and <maplink> directly. I see the process and issues of trying to pack (program) the functionality of these 2 into existing templates (which is probably preferable) than having to learn the Kartographer extension outright. -- Matroc (talk) 17:14, 10 June 2016 (UTC)[reply]
Done Itineraries are no longer numbered correctly. Previously a route would list POI in sequential numbers irrespective of type of listing. It now creates number sequences for each listing type. See for example Rheinsteig and Wales Coast Path. Not as easy to read. --Traveler100 (talk) 12:30, 10 June 2016 (UTC)[reply]
Thanks, should be relatively easy to fix with an extra param to use the same numbering group. I will have to think how to change the templates for that. --Yurik (talk) 15:47, 10 June 2016 (UTC)[reply]
I see you have added a counter parameter to listings. This is not going to work. I add a new listing in the middle of a route with 100 POIs, how many editors are going to manually edit all the existing listing to keep it sequential. This experiment that has been made active before fully testing has broken the listing numbering system of itineraries. --Traveler100 (talk) 14:18, 12 June 2016 (UTC)[reply]
Traveler100, you misunderstood the meaning of the word "counter". This is the "name" of the counter, not the "value". The new maps can do counting just fine on its own, but they need to know WHICH counter variable to use. So you can have multiple counters on a page. As long as all the items (see, go, listing, etc) have the same counter parameter, they will share the same sequence. In short, take a look at Rheinsteig. Itineraries are now done. --Yurik (talk) 14:47, 12 June 2016 (UTC)[reply]
Done A minor question (not a priority and may not be applicable for us) - listings and markers in general are numbered on an article page and show as such on a map .... in the future, will we also have the capability of outputing a letter (A-Z) (similar to using -letter in Kartographer. -- Matroc (talk) 01:35, 13 June 2016 (UTC)[reply]
Matroc, You already have that capability, exactly as you described -- with "-letter" or "-letter-<countername>" (same as with -number). Also, you can always just set it to the value you want, e.g. "x", or any number, e.g. "42". --Yurik (talk) 02:10, 13 June 2016 (UTC)[reply]
Yes, this is possible using <mapframe> or <maplink> directly -- what I was trying to ask: "Is there to be a parameter in {{listing}} (see,do,sleep,eat etc.) templates to accomplish this?" (perhaps a parameter "countertype=" with values of 'number' or 'letter' ).... Thanks! Matroc (talk) 03:17, 14 June 2016 (UTC)[reply]
The split map seems to be a problem related to the width/height parameters: the box around the map uses them, but the map in the box ignores them. This is also problematic when the width is so small that the control buttons on the left side get hidden: {{Mapframe|59.32502|18.07083|zoom=14|height=370|width=320|layer=|staticmap=|align=|name=}} Xsobev (talk) 14:43, 10 June 2016 (UTC)[reply]
@Ypsilon:, @Xsobev: I will look at width/height. The labels are missing because they have type=color, e.g. type=blue, and do not fall into one of the predefined groups: mask,around,buy,city,do,drink,eat,go,listing,other,see,sleep,vicinity,view. We could reduce the number of groups to make it easier to show in the layers picker, and simply add all others to "other" group. Would that work? Which groups do you think should stay? --Yurik (talk) 15:45, 10 June 2016 (UTC)[reply]
Pinging Yurik. I'm not sure if this issue has already been brought up, but it looks like there are some bugs when it comes to mapframes with custom dimensions. See screenshots at right. -- AndreCarrotflower (talk) 01:29, 13 June 2016 (UTC)[reply]
@Yurik: Out of several dozen map images for Valencia, three only now appear: those for the bus station and the two train stations. The map image for Estació de València Nord is the correct size; the other two are too large. –StellarD (talk) 09:03, 13 June 2016 (UTC)[reply]
Correction: when one clicks on the map icon in the upper right and opens the map in a new tab, the map images do appear and are the correct size. When clicking on the icons within the mapframe on the article page, the map images do not appear (except for the three mentioned above, two of which are sized incorrectly). –StellarD (talk) 09:56, 13 June 2016 (UTC)[reply]
@Yurik:, I think it is not completely done yet. Most of the images have the right size, but the red marker #1 (train station) in Valencia displays a much smaller image (not 300px). I see the same problem in other articles, where some images are smaller and some are bigger. Why? --Alexander (talk) 20:35, 13 June 2016 (UTC)[reply]
Done groups - in layers - is there a way not to have a select box for a group if that group does not have any any markers on the map? -- Matroc (talk) 03:31, 9 June 2016 (UTC)[reply]
DoneYurik, and one more thing, which is really strange. Mapframe behaves in a very weird way when placed inside a div environment. Check here, Открыть карту. Same bug happens when I remove the wrap/unwrap part but keep any kind of div around the mapframe command. --Alexander (talk) 20:22, 13 June 2016 (UTC)[reply]
Was seeing similar issue as I had a mapframe etc. within a collapsible div... Evidently some change has occurred fixing the issue - perhaps a .css or javascript refresh was added after the map is opened to insure height and width etc... I tried Atsirlin's Открыть карту (open map) and I could see it working - it also seems to do a (slight pause) refresh - just a passing note -- Matroc (talk) 00:59, 17 June 2016 (UTC)[reply]
@Wrh2:, I played with them a bit. I seriously doubt that we would want to invest into full GPX support at this point simply because I think it can be easily converted to GeoJson and hosted right here on the Wiki. See on the right. Yurik (talk) 04:59, 9 June 2016 (UTC) P.S. Btw, that GPX file contains an error it seems - it has 3 segments, but the first two only contain one point each, making it impossible to draw a line. I removed them. Also I used an online conversion tool and some simple regex to get this. Yurik (talk) 05:15, 9 June 2016 (UTC)[reply]
GPX routes no longer visible on the in page map style and option not available on the map you get when you click on a listing number icon. --Traveler100 (talk) 21:44, 10 June 2016 (UTC)[reply]
@Traveler100: Yes, GPX is broken at the moment. I could try to implement a GPX parser in Lua, but it might take considerable efforts, and I think it's a dead end technology - geojson has much more descriptive language for this data, so I think we should migrate to it (see an example above). --Yurik (talk) 02:07, 12 June 2016 (UTC)[reply]
So what is involved in migrating from GPX format. Not there are many tools to generate GPX and a number of web site offering such data. --Traveler100 (talk) 13:57, 12 June 2016 (UTC)[reply]
Traveler100, depends on how many there are. If English WV is the only wiki that uses them, I see there are about 20-30 of them, might not be worth writing an elaborate script (will take much longer, and can only be done by a developer, thus preventing that developer from doing something that community cannot do easily). I would suggest converting the data using this tool (make sure you select GPX in the dropdown), and copy/pasting the resulting geojson into one big wiki page somewhere, wrapping each geojson in <mapframe>. This way everyone can look at them easily, and move them to the needed artiles (or make templates out of them). Eventually I hope we will have a proper geojson storage on commons. --Yurik (talk) 14:59, 12 June 2016 (UTC)[reply]
Semi-done - all data has been converted, see User:Yurik/Sandbox/Gpx1 and User:Yurik/Sandbox/Gpx2. The task is tracked at phab:T137677. I suspect some of them were exported from OSM and stored as a page, which we shouldn't do - instead maps service should provide a way to export that data on the fly into the map that needs it. See phab:T134084 - a service to get an outline of a city, etc. --Yurik (talk) 01:01, 13 June 2016 (UTC)[reply]
Yurik, I need your comment on a related issue: this set of coordinates is geojson, isn't it? How can I integrate it into the new mapframe technology? Note that same boundaries will be used on multiple pages, so we need a way to store the boundaries somewhere, not on the page itself, as {{mapmask}} is currently doing. I believe that this requires some tweaks of Module:Map, but I am unable to do this myself (and I have no idea what you had in mind when writing Module:Map in the way it is written). --Alexander (talk) 13:49, 13 June 2016 (UTC)[reply]
Alexander, yes, they look like geojson coordinates, and in theory can easily added to the mapframe/maplink by simply doing a search/replace into a 59.4318956570169,24.736855030059814|59.43198295738759,24.737563133239746|... sequence (notice that lat/long order is reversed). Then the data can be used as {{mapframe|geotag=Polygon|data=values|59.43...}}. In the long run, my goal is to enable geojson storage on commons, similar to the tabular storage (phab:T120452). Those pages will store raw geojson, and will be accessible from maps (or Lua) everywhere (i already have it working on my machine). I wouldn't want geojson to be stored as wiki markup - not stable, breaks in many ways, cannot be easily previewed, and many other issues. This Wednesday there will be an RFC discussion about the tabular data, but most of the technology is the same. --Yurik (talk) 18:13, 13 June 2016 (UTC)[reply]
The style of the squares with numbers in the text is different - is there a reason why this was changed? Thanks again for all your work. Xsobev (talk) 17:23, 9 June 2016 (UTC)[reply]
You can see the difference if you compare an older WV page on archive.org with any current page (the changes are not page-specific). The main difference I could see is the grey border and the larger font size in the new version. In the old version, the border has the same color as the background of the box, and font size seems to be set to 0.85em. Obviously, this has low priority. Xsobev (talk)
Yurik, I am not sure what the outcome of phab:T136260 is. Your Module:Map has no style= parameter. Does it mean that we are not supposed to pass any style information to maplink, or how should it work? It would be awesome to adjust the in-text map marker using standard CSS styles. Note also that the current style of map markers is very different from what was used before. --Alexander (talk) 10:19, 13 June 2016 (UTC)[reply]
Alexander, <maplink> uses mw-kartographer-autostyled CSS class for all automatic links. I thought it was identical to how it used to be, but lets configure it in Common.css to the way it should look - I think someone else also commented about it above. (You can try it in your own css user file until you like it, tell me how it should be changed) I do not want to introduce "style=" attribute (mediawiki plans to remove it outright in other places), but maplink/mapframe do support "class=" parameter so that styling can be consistently controlled with the CSS. --Yurik (talk) 18:26, 13 June 2016 (UTC)[reply]
@Yurik: The style of the marker boxes is almost the same again. The only missing part is a 1px border in the same color as the background of the box, for example: "border: 1px solid forestgreen" for the general green "listings" type marker. Old examples of marker styles can be seen here for example. Thanks a lot for your time. Xsobev (talk) 14:02, 17 June 2016 (UTC)[reply]
Update: I spoke with our other engineers and our UI specialist, and it seems we need to slightly adjust these links. They might be okayish from the design perspective for desktop, but they may need to be adjusted for the mobile - they may be too small for the touch screen. I propose that we establish guidelines for these markers, and create a set of predefined classes that are global to all Wikivoyages (part of the maps code), and appear good on desktop and mobile. The community will then establish a set of additional classes, such as "kartographer-link-see" or "...-eat". Templates like {{see}} and {{eat}} will add corresponding classes. The classes will only modify the background color, and won't touch any other aspects. This allows us not to hardcode the color of the link, but instead use a much better CSS system, while also maintaining good UI and cross-language consistency. Thoughts? --Yurik (talk) 00:02, 16 June 2016 (UTC)[reply]
Does this then force wikivoyage to only use templates in order to create links/maps? Is the use of <mapframe> and <maplink> to be avoided when they may be used for some condition that the templates don't provide for (such as creation a different group, different color other than the default color for type other, or even the use of various marker icons)? Or will the changes in maps code apply to both situations. Just wondering! -- Matroc (talk) 01:11, 16 June 2016 (UTC)[reply]
@Matroc: well, its not forcing anything - because you can still have <maplink class="my-class-name" .../>. But templates make it more consistent. After all, the backend code only affects the <maplink> and <mapframe> tags, not anything done in templates or modules. That said, I think it is better to use classes defined in MediaWiki:Common.css - like create a maplink-eat (or whatever other name community wants) class. This provides for consistency across pages. --Yurik (talk) 01:21, 16 June 2016 (UTC)[reply]
I checked the mobile version and I don't see any problems with the markers. Do engineers want to make them bigger, or what?
From previous experience we know that getting something decided across all language versions of Wikivoyage is next to impossible, so I would at least keep the option of CSS customization in the same way as it works now. If someone thinks that defaults should be different, well, let's see how these new defaults look like, and whether they fit into Wikivoyage articles. --Alexander (talk) 07:46, 16 June 2016 (UTC)[reply]
Traveler100, Category:Pages with maps is a Special tracking category, automatically populated whenever you have a <mapframe> or <maplink> on a page. How is that different from the Category:Has_mapframe, which gets populated by the {{mapframe}}? If someone inserts a map via some other method, like directly using <mapframe>, it won't be in the old category, but it will still show up in the automatic one. Plus there is a page to track broken maps (something that you cannot do from wiki markup). --Yurik (talk) 12:59, 14 June 2016 (UTC)[reply]
Hi @Yurik:, I think you just explained it yourself, Category:Has_mapframe is a subset of Category:Pages with maps, which is indicated by 2000+ pages in one category and 7000+ pages in the other. Whether a maplink is sufficient, since it opens up a full screen map (not a big fan actually), or that a mapframe should be inserted into articles to make maps more obvious could be further discussed. -- torty3 (talk) 09:20, 15 June 2016 (UTC)[reply]
Or rather, I think map links are great for mobile phones, but not so much for desktop experiences. And the other way around for mapframes. Nice to see the progress on everything though, and thanks for that. -- torty3 (talk) 09:24, 15 June 2016 (UTC)[reply]
@torty3: that was my point - if you simply want to know "what links to the mapframe template", use this search - special page, if you want to find all maps, you can use the automatic tracking category. If you want two tracking categories - one for maps and one for links - create a task, and we can discuss it. But it makes no sense to me to have a category that duplicates "what links here". WRT full screen on link - that was the behaviour before - we simply made it much faster, more stable, and with some new features. If you think link click should do someting else, make a proposal and lets discuss. --Yurik (talk) 13:20, 15 June 2016 (UTC)[reply]
@Yurik:, the key is equivalent functionality. Perhaps if WhatLinksHere had an actual count and ability to be used in a tool such as CatScan, yet right now it does not. I'm not sure why it was decided not to have two different categories since they aren't the same in the first place. The speed and stability is definitely very much appreciated, but again opening full-screen maps is another use case that doesn't have equivalent functionality. Maplinks are not actually links that can be opened in a different tab/window. If I want to have the wiki page on one window and the map on another (and I didn't realise how much I used it in this manner), I have to do it in a roundabout fashion. I guess it's fairly minor in the scheme of things, but still irksome to me. -- torty3 (talk) 15:34, 15 June 2016 (UTC)[reply]
if the reason why it is needed can be solved with a better solution then sure we can discuss an alternative methods. It was initially introduced to provide readers with a POI map for a section of a long itinerary, for example in Trans-Canada Highway. We could not work out a method of displaying more than one map on a page at the same time. If you can work out a way to display more than one map in an article that would be an improvement. --Traveler100 (talk) 04:49, 16 June 2016 (UTC)[reply]
Symbol shape. The lack of distinctive shapes for each type of listing makes it more difficult interpret what the POI is unless you are very familiar with color scheme. --Traveler100 (talk) 12:33, 10 June 2016 (UTC)[reply]
Update: we could use some help on this one (no image designers on the team) - please create an SVG image for each of the needed icons just like these two files: [1] and [2]. The second one is for the shadow and an outline. Do not change the colors of the SVG - they are changed dynamically. Also, unless really needed, keep the same position of the images as in the examples. Please license the images under CC0. Thanks! --Yurik (talk) 18:26, 16 June 2016 (UTC)[reply]
This turns out slightly more complicated than anticipated. Apparently "pin" is hardcoded into the map, and might require some additional investigation. We are still investigating this one. --Yurik (talk) 10:57, 21 June 2016 (UTC)[reply]
@Yurik: When requesting a marker with a different style, for example "circle" instead of "pin", then the parameter gets accepted. The error seems to be returned only because there is no circle*.png image. So at least the makizushi code doesn't seem to contain any hardcoded values. Could you please give more details? Xsobev (talk) 13:50, 13 July 2016 (UTC)[reply]
Bug report: There seems to be an area below each pushpin (with a similar width & height as the pushpin itself) which reacts to a single click in the same was as if clicking on the pushpin, which means it shows the name of the listing. Expected behaviour: The label should only be shown if clicked on the pushpin, but not on its surrounding area. Xsobev (talk) 12:12, 20 June 2016 (UTC)[reply]
@Yurik: Ok, I found the answer to why this area below the pushpin exists on github: The pointy bit of the pushpin has to be the centre of the image, so that it is positioned correctly on the map, which seems like an unfortunate limitation. Luckily, if we can use the marker symbols previously used on wikivoyage (see example), where the centre of the image is also where the marker should be placed, then the empty area below the marker won't be necessary anymore. Xsobev (talk) 13:42, 13 July 2016 (UTC)[reply]
In the previous mapframe version, there was a button ("Map center - all markers") which allowed to zoom out & center the map so that all markers of a page are visible in the mapframe (with one click). Would it be possible to add this feature in the new version? Thanks a lot. Xsobev (talk) 17:23, 9 June 2016 (UTC)[reply]
If you look at the old map, for example here for Stockholm, you can see a button with four arrows (with a tooltip that says "Map center <-> all markers") in the top-left corner (in the new map this button is now used to show the map in full screen mode). If you click it once, the map zooms out so that all makers on that map are visible. If you click it again, the zoom level goes back to where it was before. (Feel free, to copy this description to a new Phabricator ticket.) Xsobev (talk) 14:33, 10 June 2016 (UTC)[reply]
I noticed that there are about 30 pages that use a color instead of the proper marker "type", for example California#See. Is that needed, or can we switch to named types? --Yurik (talk) 05:20, 10 June 2016 (UTC)[reply]
I would prefer to use named types everywhere - it will be confusing if someone decides to use the "eat" color scheme for "buy" listings, so rather than providing the ability to specify a color as a type value I think it would be better to add more types with distinct styles as needed. -- Ryan • (talk) • 15:28, 10 June 2016 (UTC)[reply]
This is a limitation of the labeling system - it can only create numbers 0..99 and letters A..Z, but in any color and 3 different sizes. Also for maps like that I think it makes sense to simply use some icon instead of numbering? Its not like anyone will be trying to locate a park number #42 on a map among 300 other markers. Also we could set different colors, one per state? --Yurik (talk) 15:32, 10 June 2016 (UTC)[reply]
I believe the numbers are needed as reference to numbered text on page... I believe marker doesn't have color or an icon option as parameters. -- Matroc (talk) 16:39, 10 June 2016 (UTC)[reply]
@Matroc: I really doubt anyone would look at a map with 500 markers, and try to find that index on the page. I think we should add all the relevant information about the mark into the mark itself - this way user can simply click on it and get a popup with everything. If you still insist on the numbers, lets differentiate numbers by some region colors (should be better than to pick a different color for each state) --Yurik (talk) 02:07, 12 June 2016 (UTC)[reply]
@Traveler100: I think Roman Empire map should be broken down into multiple maps - there is very little use to add all POIs to the same map while the actual item is far below on the page. Instead, I think it would be much better to have multiple maps, one for each region, with its own POIs. What do you think? --Yurik (talk) 10:02, 12 July 2016 (UTC)[reply]
You may have a good case for the Roman Empire article. But could you please point me in direction of documentation for the counter parameter. Made quick test at Roman Empire#England but does not achieve quite what I was expecting. Also still think numbers larger than 100 are going to be needed for long hiking trails. For example Wales Coast Path and Rheinsteig are still work in progress projects, listings are going to increase. --Traveler100 (talk) 11:07, 12 July 2016 (UTC)[reply]
@Traveler100: The main doc is at Kartographer help page (please help improving it). For WV, Module:Map has some docs, plus the {{listing}} & {{marker}}. More specifically, each listing has to be marked with the right group, plus the map itself should be set to only show that group. I think we will need to cleanup the marker & listing templates, because currently they accept the type, group, and show, arguments, but don't work too well with them. I will see what I can do in the next few days to clean it up. Or feel free to poke at it yourself. --Yurik (talk) 18:50, 12 July 2016 (UTC)[reply]
@Traveler100: from the <mapframe/maplink> perspective, counters and groups have no relation with each other. Any data marked with the same "group" value will be shown for all maps in that group, plus it will be shown whenever the group is listed in the "show" parameter.
{{marker}} sets two values that are used in the Module:map: marker-symbol=-number-{{{counter|{{{type|listing}}}}}} | group={{{type|listing}}}. The module does not modify either of these two params, it simply passes them to the <mapframe/maplink> tags. Also, I think it is a mistake to set any params in the {{marker}} because the module can pick up params from the template that uses {marker} - this way marker template could become much simpler, and templates like {{see}} and {{do}} can set all the needed arguments. --Yurik (talk) 18:40, 14 July 2016 (UTC)[reply]
sorry but that explanation has not helped. What do mean by "will be shown for all maps in that group"? Also where can you set the show parameter if you have other types or is this hardcoded? For example why is only the group listing being show in Roman Empire, how do you show different counter groups? --Traveler100 (talk) 18:52, 14 July 2016 (UTC)[reply]
@Traveler100:, first, take a look at help page - groups, I tried to explain it there (please help fix it if you have a better way to explain it). In WV maps mode, each map (either a link or a frame) could belong to a group. All maps with the same group name share their content (geojson). So if you have two maplinks with some geojson content (like a POI or some mask), and both maplinks have "group=magic" parameter, their geojson content gets combined, and clicking either of these links will show data from both. That same data can also be shown in other maplink or mapframe that belong to a different group - by simply setting their "show=magic" parameter (more than one group can be listed). All this is about the raw <maplink> and <mapframe> tags. But in WV land, we use templates that hide those tags. The tag itself is created by the Module:Map. Template {{marker}} calls it with some parameters. Templates like {{see}} and {{do}} use the marker template, also with some parameters. We should clean up these parameters to simplify the whole system. The counter and group and show parameters are being either passed as is, or set from the "type" parameter. I will try to clean it up a bit, to make it simpler (suggestions are welcome). --Yurik (talk) 20:40, 15 July 2016 (UTC)[reply]
Maybe we are going about this the wrong way. Rather than trying to explain mediawiki code and trying to get non programmers to understand the technical side. Maybe the development team should write a simple user guide? What functions are being delivered, what will not longer work, which parameters will be available and what options can be used and how they will appear on the maps? --Traveler100 (talk) 06:17, 16 July 2016 (UTC)[reply]
Done When I add geo coordinates via the listing editor and then click on the newly created marker in the text, the map opens, but the new marker is not shown on the map. After reloading the page, the marker then shows on the map. Xsobev (talk) 11:31, 10 June 2016 (UTC)[reply]
Yes, I think I saw this bug appearing somewhere. Could you add a Phabricator ticket (with the above link), and describe the exact steps to reproduce it? Thx! --Yurik (talk) 15:32, 10 June 2016 (UTC)[reply]
In the original examples like the one at start of this section there were all the display options such as Destinations (nearby articles) and Boundaries. These options are not on the articles style map only on click through and geo map styles. --Traveler100 (talk) 21:52, 10 June 2016 (UTC)[reply]
How do you get an icon marking the goe cordinates of other Wikivoyage articles onto the map? In previous map tool or in the tool you get when press the map icon top right on a page there is a tick option "Destination" this is useful when looking at high density areas were you want to see nearby suburbs or when working on Go next section. The Boundary option to display district, counties and so on is also very useful when working on region articles. --Traveler100 (talk) 14:03, 12 June 2016 (UTC)[reply]
In click through map style when you display destinations you have to proactively click on location tags to see the article thumbnail image, on previous style a mouse over was sufficient. --Traveler100 (talk) 22:03, 10 June 2016 (UTC)[reply]
I will use Wales Coast Path again as example. Click on the map icon top right to get the standard map function. Switch on POI destinations (left side icon or right hand option). Move mouse over destination markers, will see thumbnail if image on page or Wikivoyage icon if no image on page. Back on article page Click on a point of interesting listing number, you get the new style map. Click the Explore Nearby Destination icons. You need to proactively click on a location marker to see the image. --Traveler100 (talk) 14:14, 12 June 2016 (UTC)[reply]
If you click on a listing number in an article is only shows other POIs of the same type (i.e. see or go or ..) it is not possible to see or even switch on other POI types. --Traveler100 (talk) 09:30, 13 June 2016 (UTC)[reply]
This functionality would be quite important to have. For example if you plan a trip and read the listings in "see" and want to find out if there are (a) any restaurants or (b) anything else at all near the see listing you are interested in. Xsobev (talk) 12:24, 20 June 2016 (UTC)[reply]
If you add a mapframe to a page, all existing markers on that page should be shown on the map preview. Currently only the markers of the section where the mapframe is added are shown. Currently it is not possible to test a good geo coordinate setting with the preview, so that for example all existing markers are visible. It's even more problematic if the section (for example "Get around") where the mapframe is added doesn't have any markers yet, because then no markers are shown. Xsobev (talk) 13:13, 13 June 2016 (UTC)[reply]
Can the zoom level be shown on the new map. In the old map it is displayed on the top left corner. That way one can easily figure out what zoom level to the the zoom parameter to when adding a mapframe to a page. Xsobev (talk) 13:13, 13 June 2016 (UTC)[reply]
Yes, this is a todo. In the mean time, you can see both the zoom and lat/long by making the map full screen, and looking at the URL - it has both. --Yurik (talk) 19:28, 13 June 2016 (UTC)[reply]
Currently in the old map, when you right-click on any position, the geo coordinates are shown. That's useful for example to find a good set of geo coordinates when adding a mapframe to a page. It's even more important if you want to add geo coordinates to a listing. Xsobev (talk) 13:13, 13 June 2016 (UTC)[reply]
This is still under discussion - we want to cater to both readers and editors, so working on the design. In the mean time, you can see both the zoom and lat/long by making the map full screen, and looking at the URL - it has both. Also, Visual Editor allows an interactive adjustment of the map (granted that this is not applicable to templates) --Yurik (talk) 19:28, 13 June 2016 (UTC)[reply]
Why under discussion, this is a very useful functionality for adding or correcting coordinates of listings. Why make things difficult for editors? --Traveler100 (talk) 07:09, 16 June 2016 (UTC)[reply]
I too find it frustrating; without this functionality I've no idea how to add coordinates for new listings. Google maps, maybe? Luckily the old map is still accessible, by clicking on the icon in the upper right corner of the article. From there it's possible to get coordinates, just as earlier. ϒpsilon (talk) 08:32, 19 June 2016 (UTC)[reply]
I am aware of this, in fact it is on my main bookmarks. However it is easier to use the existing article map, particularly as for many locations the GeoMap method request a couple of attempts to find the correct location for a specific name. Yes there are other way to do this, was just highlighting a regression in the new map function. --Traveler100 (talk) 16:49, 19 June 2016 (UTC)[reply]
Well, I didn't remember that the GeoMap thing existed (it's more than a year since I used it), because I've got used to taking the coordinates from the article's dynamic map which is just one click away from the article. Guess I have to add it to my quick links right away. ϒpsilon (talk) 17:01, 19 June 2016 (UTC)[reply]
With the new map in a mapframe: if you double-click, the map changes to full-screen. In the old map it would zoom one level in, which is also the behaviour I would expect. Xsobev (talk) 13:13, 13 June 2016 (UTC)[reply]
I'm not yet sure about the best design for this. We will try to do some A/B tests on what behavior users tend to use more, and possibly allow for per-user customization. --Yurik (talk) 19:28, 13 June 2016 (UTC)[reply]
This seems to be the behaviour with embedded maps from Google and Bing: double-click zooms in. Since many people use these embedded maps, they probably expect a similar behaviour. Xsobev (talk) 14:39, 17 June 2016 (UTC)[reply]
The problem occurs on Russian Wikivoyage, but I am sure that it can happen here as well. The {{marker}} template adds linebreak after the map marker. Example here, check the section with the list of cities. A few listings on this page produce the same problem (for example, #8 in See). Those are the listings with the empty address= or name= parameter. --Alexander (talk) 12:26, 13 June 2016 (UTC)[reply]
Would like to have link in mapframe to open map in new browser tab. Yes you can on PC right mouse button to get option to open in new tab but I find doing this on mobile devices a little more tricky. Also when using mobile devices, particularly when download is slow or expensive, it is better to keep multiple tabs open (I sometimes keep tabs open when I have a network connection so I can use where no connection is available later in the day). --Traveler100 (talk) 05:09, 16 June 2016 (UTC)[reply]
When you edit a section of an article, the geo map symbol is no longer shown, so cannot check lat long values until you save the edit. --Traveler100 (talk) 07:03, 16 June 2016 (UTC)[reply]
Feature request: Zooming in with a double-click does not work if there are pushpins at the location where you double-click. It would be great if a double-click on any part of the map (with or without pushpin) zooms in. Xsobev (talk) 12:12, 20 June 2016 (UTC)[reply]
Not sure how related this is to the new map extension: Currently, when exporting a page to PDF, all the listings with geo information start with a "1". It might be better to show the actual geo coordinates, so that they can be used to find the location of the listing with for example the OsmAnd Openstreetmap app on your smartphone (or any other app/device that understands geo coordinates). Xsobev (talk) 12:36, 20 June 2016 (UTC)[reply]
I would like to propose deleting {{geo}} template. Or more specifically, moving it into some template that every location page uses, and pulling coordinate data from the associated Wikidata page. This way you will no longer need to add geo to every article, but instead simply update the Wikidata coordinates, and it will show up automatically. Magic! Is there a template that is used on every location page? --Yurik (talk) 01:30, 16 June 2016 (UTC)[reply]
there has been a general convention on this site not to complicate one template with too many different functions. Makes it a challenge for new contributors to understand what is going on. Wikidata particularly is not easy to understand from reading the contents of a page and if you are not familiarly with the concept not very discovered. Again making editing for insiders only. (Wikipedia can afford declining contributors, this site cannot). If was merged we would still want to keep maintenance categories for tracking things like which articles have all templates but no coordinates. I would also be a little concerned about simply taking Wikidata information, many have corrected coordinates here or sometimes the Wikipedia coordinated are not exactly what you want for this site. Propose a method but do not make changes for change sake. Do not touch a running system.--Traveler100 (talk) 04:58, 16 June 2016 (UTC)[reply]
I think that inexperienced users should not touch things like geo-coordinates of an article, so that's not an issue at all. The question is how the system understands geo-location of an article. For example, does tools.wmflabs.org/wikivoyage/w/data/en-articles.js retrieve up-to-date information from Wikidata? Or does it work from the dump, as PoiMap2 did? --Alexander (talk) 07:50, 16 June 2016 (UTC)[reply]
@Atsirlin: That is actually the biggest concern I have at the moment with the "show nearby" - the new maps still rely on wmflabs to get a list of all articles, which is problematic in many ways (stability/security/maintainablity/...). The way system is designed now is "okayish" for the near term, but it will break soon - currently the user downloads the entire list of all articles on click. As the number of articles grow, so will the data size. Imagine having the same system on Wikipedia - and downloading coordinates for 2 million articles - that's over 1GB of data. So yes, this is to be discussed. Who is maintaining that script? --Yurik (talk) 16:53, 16 June 2016 (UTC)[reply]
I have found some of the coordinates in Wikipedia inaccurate or off a bit and in a few cases, the envoy article is linked incorrectly to the wrong Wikidata item which in turn gives one coordinates that are also incorrect. In some cases, I know I have created {{geo}} for pages that don't have (and probably will never have) a corresponding Wikidata item or Wikipedia article. The concept of using Wikidata as a source for many things is a wonderful concept; however, it too is not quite ready for prime time players. (Just one of my minor pet peeves). -- Matroc (talk) 15:02, 16 June 2016 (UTC)[reply]
@Matroc:, @Traveler100:, @Atsirlin: I do not mean Wikivoyage MUST use Wikidata. Instead, I only propose that {{geo}} uses Wikidata coordinates by default unless coordinates have been specified by hand. This way if you are not happy with the value in Wikidata, you simply provide your own (like you do now). And if you are happy, simply don't provide any. And if there are no coordinates in Wikidata - it might make sense for a user or a bot to add them (by copying them from the article) - thus benefiting all other smaller language projects who might not have enough resources to manage their own coordinates. Also, if there is no corresponding item in Wikidata, easy enough to add it (possibly by bot). The benefit from this will be automatic coordinates for all articles in all languages without any manual work. Lastly, I think Wikidata community will be very happy to get direct contributions from all projects, so they might eventually even introduce some onsite coordinate editing (ability to edit Wikidata without switching to it). Oh, and don't forget that Wikidata will hopefully be synced up more with OSM database - only increasing the quality of data. --Yurik (talk) 16:41, 16 June 2016 (UTC)[reply]
@Yurik: - I will go along with that. I am NOT opposed to using Wikidata but just get concerned about missing and inaccurate data that has been corrected in wikivoyage. -- (Would there be string formatting of the coordinates to lets say 4 or 6 decimal places or will it just import as is in Wikidata?) -- Matroc (talk) 00:11, 17 June 2016 (UTC)[reply]
Geo template (link to map in the upper right corner) is the only major feature that has not yet been migrated. Please help us figure out the absolute must-haves (blockers) to enable this feature. Each item has to be very clearly defined and actionable. Also, please do not add "nice to haves" here - they are clearly important for your workflows, and might be a temporary inconvenience that I hope we can fix very quickly, but check if it is a blocker (like it no longer shows critical data) or if it is something that can be re-introduced soon thereafter (like some styling inconvenience). Thanks! --Yurik (talk) 14:48, 16 June 2016 (UTC)[reply]
when clicking on a listing need to be able to switch on all groups. For example I click on a see or do attraction, I want to see what places are to eat in the area. --Traveler100 (talk) 06:34, 12 July 2016 (UTC)[reply]
the current map function has a fit option, which zooms in or zooms out until all listing POIs are displayed. As well as being useful to see all attractions of interest it is also a good method of checking if coordinates have be entered correctly or if listing should be on another article. --Traveler100 (talk) 06:34, 12 July 2016 (UTC)[reply]
Printing a full page map with the new map (expanded from a mapmask) results in a 7 page printout - looks like seven identical copies of the same map, but get a one page map when printing the map from the geo template. AlasdairW (talk) 22:58, 12 July 2016 (UTC)[reply]
When printed in black and white different symbols are the same - eat and buy both are a mid-grey, sleep and drink are both black. We need to get the something like the symbols that the geo map has. (When I am printing at home I will generally print in colour, but in an internet cafe / hotel reception there can be a big difference in costs.) AlasdairW (talk) 22:58, 12 July 2016 (UTC)[reply]
Beginning to find the new maps inconvenient. The biggest issue is when you click on a location icon of a listing to get to the map (something I tend to do more on a mobile as the geo map icon is difficult to find). It only shows other listing of the same type. Not good when I click on the attraction I am at to see when restaurants are within walking distance. The project appears to have stalled are the open issues going to be addressed? --Traveler100 (talk) 07:54, 10 July 2016 (UTC)[reply]
We found the same behavior at WV/de. For a workaround, in the {{Marker}} template a show parameter is to be introduced having all possible values. To make this easier I proposed an additional show parameter for the Kartographer. --RolandUnger (talk) 14:00, 12 July 2016 (UTC)[reply]
I cannot seem to be able to display county and city boundaries on the maps any more. Am I missing some option somewhere? Making things more difficult to assign listings to the correct articles. --Traveler100 (talk) 11:48, 24 July 2016 (UTC)[reply]
Hi, there are a few missing options in the new dynamic map:
The map layer options (the ones that used to be on the right below the maximizse/close full screen button) are no longer shown on the new dynamic map? They were very useful to switch to the more detailed Mapnik tiles for example.
In full screen mode, the closing button alt text just says "<kartographer-fullscreen-close>".
There no longer is a button that shows nearby Wikivoyage articles.
The button on the left where you can zoom out to show all existing markers on the currently shown dynamic map is also missing.
They have been missing for several weeks! - I believe they are working on several issues at this time - frames, divs and icons among other things and hopefully they too will resolved soon -- Matroc (talk) 03:25, 30 August 2016 (UTC)[reply]
Hi all - thanks for your comments. I was referring to existing functionality in the new maps that disappeared in the last week or two. On the screenshot to the right you can see the buttons that I'm referring to: the button on the left below the +/- buttons, and the one on the right below the full screen button. 2A02:C7D:2E5B:9E00:807:CA0:38F0:F77122:15, 30 August 2016 (UTC)[reply]
I have written some Lua Module functions to draw circles, ellipses, boxes, triangles, stars, arrowhead style pointers, pentagons and hexagons to produce a maplink (mapframe may in the future) with all the necessary coordinates for display in a mapframe as well as the option to create a centered marker for these shapes. The most difficult (as I know nothing about trigonomety) was to draw fairly accurate circles (by fairly accurate I am within 40 meters) and account for Mercator distortions (isotropy) at higher and lower latitudes. The circle function may be added later to Module:Map as I already discussed the circle function with Yurik... or perhaps in a separate Module after further testing.
Whatamidoing (WMF) -- shared this with User:Yurik as there is no method to create circular shapes with Kartographer - Other functions were offshoots for learning GeoJSON with <mapframe> and <maplink>. Just basic experimentation from a slightly different perspective. Yurik, Roland, Ryan et al. should be commended for their exhausting work of implementing the new maps, modules, templates etc. -- Matroc (talk) 04:15, 3 December 2016 (UTC)[reply]
Hello! I was just reviewing some of the conversations below about dynamic/static maps and how they relate to star articles. It seemed like many strongly held opinions were expressed and no consensus was reached. This was back in 2013, so I was curious if any headway had been made in this area?
static map: Looks much better than dynamic maps. You don't have to fiddle with them, they just are. Uses human brainpower to make the most beautiful map possible. Low number of skilled editors make updates infrequent. Stays out of date longer, tedious to update.
dynamic map: Always as up to date as the content on the page. Allow for user customization, accessibility. Reduces maintenance workload on mapmakers. Access to crowdsourced data keeps maps current. Hooks novice users because it's fun to enter coords and see a pin appear. Often a bunch of pins are clustered in one spot, no way to toggle pin types, no intermediate zoom level (eg.. zoom=13.643), and other display issues.
I don't think there will be a consensus here, but how about responding to this one idea. For star status for regions, or other articles where there might be a WV imposed hierarchy of child pages, we should require a static map. The WV way of breaking things up may differ from the local political way, and there are unlikely to be many points of interest in need of constant updating. For star status for districts, or other articles with clearly defined boundaries we should allow a static or dynamic map. The reason being that these areas will have scores of listings that are changing frequently, and there may not be enough manpower to stay on top of them all.
Is that reasonable at all? I really don't want to be confrontational, both sides have good arguments. I just don't want to miss out on recognizing good articles from around the site due to this impasse. Thank you! --ButteBag (talk) 00:39, 1 December 2016 (UTC)[reply]
I appreciate your concerns and the balanced view you present here. I'm afraid that for me, the dynamic maps just aren't usable enough at the moment. Overlapping text and icons, and the rigidity of the presentation, mean that they simply don't achieve the main goal of a map, which is to convey complex geographical information intuitively and quickly. Powers(talk)00:34, 9 December 2016 (UTC)[reply]
I want to add to this that in my opinion the one major inconvenience of the dynamic map as they are currently used here is that they don't show train lines very clearly. I was recently travelling in Seoul and while the dynamic map on here for instance is great to find stuff because of the zoom-in capability, I found it a nightmare to coordinate which metro station to use. It usually involved using a different map, finding where the lines are and then comparing that to the WV map. As another illustration of this, have a look at Singapore/Riverside which has both a static and a dynamic map. On the static map, I can clearly see the two lines that go through the map, I see that City Hall and Raffles Place are on the same line and that Clarke Quay is a different line. On the dynamic map however, I can only see some of the stations indicated with the train symbol, to see City Hall I have to zoom in, at which point it also shows me all the bus stops and makes the train symbol very hard to see. Furthermore there is no way knowing which of the stations belong to which line unless I use the 'Mapnik' at which point the lines are there, but are quite lost in the total amount of information shown (with all the small roads shown). This is not very helpful, and in my opinion a useful guide book map should always show trains lines. I think that a map which doesn't even show such basic things as train lines and stops are clearly suboptimal.
As someone who often travels without buying a local sim card, I also find it important that the map is still useful once it's printed out or shown in the offline app, both of which are not possible with the current dynamic maps.
Of course as an editor I prefer the dynamic map, because it is so much easier to create and amend (The Singapore map in my example above is outdated by several years and I can't adapt it, because there's no svg file), so in my opinion the solution would be to adapt the dynamic map layout so that it is as informative and easy to read as the static one and maybe create a static image of the dynamic map for offline reader etc. But as of now I would strongly object allowing star articles with dynamic maps, as it just has so many flaws and inconveniences. Drat70 (talk) 05:26, 9 December 2016 (UTC)[reply]
There are a range of strongly held opinions on this subject, but unfortunately dynamic maps haven't progressed sufficiently since the original discussions that ButteBag linked to that it seems likely that any of those opinions have changed, thus leaving things at an impasse and stalling most star nominations. I applaud anyone willing to find an agreeable way to move forward, but don't hold out much hope of that happening anytime soon. -- Ryan • (talk) • 06:15, 9 December 2016 (UTC)[reply]
This might be a stupid question, but I have been looking everywhere and can't find any information on this.
There's a section on suggestion for different styles for the dynamic maps, which might better suit our format, and I believe that the style of the map is one of the reasons why dynamic maps aren't as useful as static maps yet. But how are those rendering layers created, and is there a place where they can be easily altered or tried out for testing purposes? I have been looking all over the OSM pages etc, but can't find any information on this which is not highly technical.
Thanks Drat70 (talk) 06:51, 21 March 2017 (UTC)[reply]
I noticed a number of upper level regions -- for example, Poland, Pacific Northwest, Oregon and Washington (state) -- now have both a WV-style region static map, and a dynamic map that highlights the cities and other destinations but doesn't show the region breakdown. Reading through the deployment guidelines in the Dynamic maps Expedition, using dynamic maps in this way breaks a couple of them (only deploy on bottom-level articles and don't deploy on a page with a static map), although usage of dynamic maps seems to have outgrown these guidelines. I'm inclined to say that these dynamic maps should be removed because (1) it's a region guide but the map doesn't show the regions (and the cities are already captured in the static map), plus (2) I'm not aware of any consensus to use both static and dynamic maps on the same page or to use dynamic maps on a non-bottom-level page -- but want to hear others' comments to see if opinions have changed. -Shaundd (talk) 05:33, 11 May 2017 (UTC)[reply]
I'm a big fan of dynamic maps, and I do see recent developments that are getting better at coloring in WV regions. I'm sure they will replace static maps one day.
That said, although I appreciate the effort going into creating these regional dynamic maps, they don't really add value above and beyond the existing static map. I'd agree to remove them for now. --Andrewssi2 (talk) 06:28, 11 May 2017 (UTC)[reply]
This came up before, in a couple of bottom-level NYS regions. Adirondacks had both, but ended up keeping the static map on-page with just a link to the dynamic map. NNY is a bottom-level region with just a dynamic map, which was left in place. The difference between the two? Adirondacks is a more complex region as it had one and a half dozen tiny villages scattered across a wide area which was otherwise forest and parkland. Those were grouped into 5±2 subsections on the same page, and presented on a static map.
The dynamic maps are improving. Sure, I'd prefer if the city markers looked a bit more like "● Newport" and less like "⓫" or some arbitrary number; I'd also like to be able to selectively turn off existing OSM labels for cities and POI's if they are extraneous or duplicate the content we're going to add to the map from the local article. We're not there yet.
Nonetheless, they are adequate for a simple bottom-level region -- even if that is use of "dynamic maps on a non-bottom-level page" as these regions have towns and villages under them. K7L (talk) 13:56, 11 May 2017 (UTC)[reply]
Dynamic maps are better than nothing for a region article, but if there's already a static map there's no need for a dynamic one. They should be removed. -- AndreCarrotflower (talk) 14:45, 11 May 2017 (UTC)[reply]
I would think it's got to be more of a case of what is most relevant to the region and what needs to be shown. I think in the Washington (state) the two different maps show different things. The nature of mapping is that different types of map are designed to show different features. So in Washington (state) the static map shows a traveller an overview of the regions but does not clearly show the major cities whereas the dynamic map does clearly show the cities and where they are in relation to each other. Each of the two maps serves different functions and both have their uses to travellers. So I'd think static, dynamic or both must depend what is useful to the wide range of users and that authors/contributors recognise that it is the nature of maps that different cartography always show different things. PsamatheM (talk) 14:18, 20 May 2017 (UTC)[reply]
I think it's a question of cartography and emphasis (and scaling). In the Washington (state) example the maps show very different things and thus have very different cartography. Look at the page on a small e.g. phone screen (as many travelling will be) and the static map shows very little detail (it still shows the regions fine but cities are hardly readable). Hence in that example, the different cartography and being handled differently on different sized screens means both maps are very useful serving different purposes. People use a wide range of devices and are seeking a wide range of different information. PsamatheM (talk) 21:37, 20 May 2017 (UTC)[reply]
I agree that static maps and dynamic maps can have different use cases, and for that reason, it would be ideal if there was a way to have both on a page provided it didn't look cluttered (which is how I think it looks now when one map is in the Regions section and the other in the Cities section). I was thinking one way around it would be to put maps into a box (or something similar) with a show/hide toggle so the reader could control which map(s) he/she sees. To keep it simple for editors, a template could be created so all that was needed was to enter the lat, long and zoom for the dynamic map, and the name of the static map, and the template would link with mapframe to do the rest. Templating is not my strong point, so I don't know how feasible it is, but just a thought. -Shaundd (talk) 06:39, 21 May 2017 (UTC)[reply]
I have a few suggestions for improving the layout of the maps on our articles.
1. When you click on a listing icon, the map now opens in a new tab or window. I think it would be better to open it in a small pop-up window hovering above the article, just like when you click on the globe next to the coordinates in the upper right corner of Wikipedia articles of places that are located somewhere. You could read the listing's content and watch it on a map at the same time.
2. And when we have the maps available to be viewed simultaneously with the article, we don't need to have the mapframe in its current form. In short articles the mapframe takes up quite a lot of space relative to the article's length (as discussed at Talk:Tempio_Pausania#Should_this_article_have_a_map.3F), but at the same time, I do think the mapframe could be bigger than it is now is to be more comfortable to use. On Russian WV they have a different way of displaying maps in the article; you can click on an icon ("Открыть карту"+map icon) between the lead section and Understand section to expand and close the map inside the article. I think this solution would be worth implementing here too.
I guess my assumption that having a map visible on the article was extremely useful to visitors was wrong :). I don't like the idea of (1) a pop out because of mobile devices and even laptops can be annoying.
For idea (2) have you tried manually changing the size of the map? It can be made smaller. I do like the idea of a (large) icon that expands into a map however. Andrewssi2 (talk) 21:34, 7 October 2017 (UTC)[reply]
Well, I think it could be handy to be able to read a listing and look at a map centered on that listing at the same time/in the same screen. When you now click on the listing icons, the map opens in a new fullscreen window. And of course, one doesn't have to click on the icons, if one doesn't want to :).
I used to adjust the size of the map manually with parameters, but two years ago there was a discussion that we should stop doing that and leave the mapframes standard sized unless there's a very important reason for doing so (long itineraries etc.). ϒpsilon (talk) 18:33, 8 October 2017 (UTC)[reply]
This subject has been lacking policy, probably because it was so obvious that maps help travelers. Now that this logic is being questioned ("Maps broke my page layout! Vandalism!") I have started to draft a short policy to clarify things here: Wikivoyage:Map and Wikivoyage_talk:MapAndrewssi2 (talk) 05:29, 9 October 2017 (UTC)[reply]
Dynamic map no longer indicating listings outside current visible area?[edit]
I adjusted the map on Bitola because there were a great deal of listings bunched together in the city because of 3 listings quite far away.
I remember that when a listing used to appear out of the view area, there used to be an indication at the edge of the map. How can we get that put back in? Andrewssi2 (talk) 21:34, 10 October 2017 (UTC)[reply]
Dynamic map for tracks works perfectly with Firefox but you can't zoom in/out in Chrome browsers[edit]
At the German Wikivoyage we observed a behavior that maps are not dynamic in Chrome and Opera browsers. So for instance, controls are missing and the map is "frozen". I added the task T197655 on Phabricator. Unfortunately there were no actions until today. I assume it is a resource-loader problem. If I am true then we will not find a simple fix. The maps are finished by a JavaScript adding markers, controls and so on "on complete load" (on ready). These scripts are in need of some parameters like the map server url which are delivered by a resource-loader script which is done too late. That's why we found a runtime error which gave us a hint what happens. The problem with JavaScript is the parallel operation of several scripts to save time. --RolandUnger (talk) 09:33, 21 June 2018 (UTC)[reply]
There are three ways to add tracks to maps. Firstly note the track into the article itself as a <maplink> tag as it was done for the Trans-Siberian Railway (at the end of the article). The syntax is GeoJSON. Secondly, you can store it at Wikimedia Commons or on OpenStreetMap. The first case is that way which most probably produces a track in Chrome. The other ways are more elegantly and can be used also for other projects. The problem is that a runtime error occurred earlier could stop drawing the tracks. But I hope that the programmers at the Wikimedia Foundation will find a solution to overcome the failures in Chrome. --RolandUnger (talk) 12:14, 21 June 2018 (UTC)[reply]
I think I've had issues with dynamic maps before and this problem might be only when certain computers use Chrome browser or it's an on/off problem. Nevertheless, I just tried the example and it worked. Selfie City (talk) 16:32, 21 June 2018 (UTC)[reply]
And I'm using Chrome. Sometimes, you have to click on the map first to get the zoom in/out to work, otherwise the computer thinks you're just scrolling down the page. Selfie City (talk) 16:32, 21 June 2018 (UTC)[reply]
Mapshapes/mapframes in country and continent articles[edit]
Ikan, can you please point me where exactly country maps were discussed? I just can't find it so easily. Is it when we were discussing what type of changes AndreeBot is allowed to perform?
I won't try to defend continent articles, as it's just 7 of them.
In case of country articles. It seems to me, dynamical maps in many cases are very helpful. Check for example Morocco and Denmark (I've chosen those two almost randomly). And in order for static maps to be unambiguously sufficient in those cases, they need to be redrawn. Morocco's article needs a completely new static map. Denmark's static map should at least be supplemented with the items from Other destinations list. So current static maps are not enough there. Do we need two maps on one page? I'd say, it depends on a static map present in an article. For intance, in case of Morocco I'd delete static one, but for Denmark both maps seem to be quite usefull. --Kiaora (talk) 22:03, 6 October 2018 (UTC)[reply]
If the static maps need edits, those should be done. I understand the argument for replacing all district or undistricted city maps with dynamic maps - it's based on the idea that businesses open and close often. No such issue obtains with static maps for larger areas. Unless we're just going to let inertia overwhelm everything. And we're discussing this here. Ikan Kekek (talk) 22:08, 6 October 2018 (UTC)[reply]
The need for dynamism is key here. The town of Aarhus in Denmark is unlikely to move its geographic location significantly for at least another 10,000 years, so we are safe in maintaining that on a static map, which is faster for web page rendering and easier for printing. Most of the WV community appreciates Dynamic Maps, but they are intended for local areas where listings can change on an annual basis. Andrewssi2 (talk) 22:37, 6 October 2018 (UTC)[reply]
Just checking so I don't do the same without realizing the rules: is the standard that continent and country articles only have static maps and not dynamic maps? --Comment by Selfie City (talk about my contributions) 22:44, 6 October 2018 (UTC)[reply]
Unless we plan to change our standard, I'd agree based on your provided links that country dynamic maps should go. Dynamic continent maps, especially for somewhere like Asia, would probably be much too distorted to be good maps.
Let me just say that most people who read our travel guides probably don't care much one way or another, but I definitely must say that static maps are a lot more artistic than dynamic maps. One that would help with dynamic maps would be smaller markers, IMO, but that's another issue altogether. For now I think we should stick with our current policy. --Comment by Selfie City (talk about my contributions) 16:57, 7 October 2018 (UTC)[reply]
Using the marker template you can display a smaller marker on a dynamic map - whoops I just opened another can of worms. Smaller points can also be accomplished with the maplink template with colors, maki symbols etc. - mmmmm - another foo bar.. Not so for listing templates .. Another 40 paragraph discussion is about to ensue, oh well -- Matroc (talk) 21:06, 7 October 2018 (UTC)[reply]
How about if we delete dynamic maps for countries that have good static maps, and keep dynamic maps for countires with subpar static ones? This way a dynamic map will be used only in cases when it can supplement a static one.
And related topic of discussion: what can be considered a good static map? I'd say, it should at least display all items from Cities and Other destinations.--Kiaora (talk) 20:13, 7 October 2018 (UTC)[reply]
I would agree on what a good static map is, but I would disagree that deficiencies in a static map automatically give license to insert a dynamic map. Country borders don't change often enough for a dynamic map to be required. Ikan Kekek (talk) 06:55, 10 October 2018 (UTC)[reply]
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I'd say a dynamic map is better than nothing if no static map is available, but otherwise, static maps make more sense for country articles (except maybe very small countries like the Vatican and Monaco). In general the locations of major cities do not change often enough to warrant a dynamic map. I highly doubt New York City is going to move away from the East Coast anytime soon. The dog2 (talk) 14:49, 10 October 2018 (UTC)[reply]
Even if the locations don't change, that doesn't stop some silly git from changing the name of Canada's capital Ottawa-Hull, as happened in 2002, or changing the boundaries of a territory, as happened in 1999. K7L (talk) 15:27, 10 October 2018 (UTC)[reply]
I was directed to the geomap tool from the listing editor for entering additional locations in a voyage, but the geomap.php loads an unsafe script (doesn't do so over https) so the browser blocks this. I could override the unsafe activity, but I'd rather just like to fix this instead. The solution is a very straightforward, but I'm not sure where the code resides or who maintains this to report. Can someone point me in the right direction? -Wolfgang8741 (talk) 23:46, 24 October 2018 (UTC)[reply]
Hi Yuriy kosygin, please have a look here: Wikidata items for dynamic map of Tainan. 2 districts are not colored so far (i.e. Eastern District - Q710281 (OSM) and North District - Q710206 (OSM)). Maybe somebody has an idea why? In the past the problem was related to Wikidata ID's, which were assigned to multiple OSM elements. But this does not seem to be the case here. Yuriy kosygin, maybe you want to try out the tool Wikivoyage districtifier to rapidly create a dynamic map of Tainan. You can message me anytime, if you have problems. --Renek78 (talk) 15:35, 29 October 2018 (UTC)[reply]
If I click on the map top right and then display destinations the markers do not appear to be updating. I have fix may in the last few months but they are not moving on the map display. For example Thari was corrected in May but zoom out and you see the marker is still over Ranipur. How does this data get updated? Assume we need to resync some server? --Traveler100 (talk) 12:53, 3 November 2018 (UTC)[reply]
Maybe there is something wrong on the corresponding Wikidata page. For example, sometimes if you change a pagebanner from a custom pagebanner to the default, it still shows the original custom banner even after you made the change. There are coordinates at the Wikidata entry at [3]. --Comment by Selfie City (talk | contributions) 14:39, 3 November 2018 (UTC)[reply]
The article and wikidata coordinates are (well were) correct! Te problem is with the geo map markers not moving when the coordinates are change in the geo template. --Traveler100 (talk) 14:59, 3 November 2018 (UTC)[reply]
Do you mean that [5] were the right coordinates? If so, I can revert my edit to the original. Because what I did is I found the Wikivoyage coordinates and changed the Wikidata coordinates to match them. Maybe I should have changed the Wikivoyage coordinates to match the Wikidata coordinates. Or are both of them right? The two different coordinate points are quite a long way from each other. --Comment by Selfie City (talk | contributions) 15:03, 3 November 2018 (UTC)[reply]
The problem I raised was about the geo coordinate database not updating. It never was instant, took about a month, but now does not update at all. --Traveler100 (talk) 16:10, 3 November 2018 (UTC)[reply]
I am not sure that the destination database is even part of the scripts on toolforge. Anyway, destinations are shown only via poimap2, which is outdated and should be basically replaced by the Kartographer maps. --Alexander (talk) 22:34, 3 November 2018 (UTC)[reply]
Since the marker template has been changed recently just note that if you use a wikidata parameter, they (markers) will not appear on a geo map but will on a mapframe. A marker will show up on a geo map if you use the lat/long parameters and not the wikidata parameter. On a mapframe the marker will appear but the coordinates appear to default to those found via the Wikidata id and not by any provided lat/long unless there is no wikidata parameter. present. The marker template in other words is attempting to fulfill 2 roles - working with geo and mapframe. I took the coordinates for Thari and made a marker type vicinity and it went to the correct location. I added the wikidata id and it no longer appeared on the geo map. I then changed the wikidata id to Q668 for India and the marker then appeared on a mapframe in the center of India and nowhere near Thari coordinates that were provided. I do not believe that the Destinations database has anything to do with whats discussed here. This is then what is called a conundrum (spelling) - Yes maybe 2 years ago it was discussed to get rid of the geo maps and replace them with Kartographer maps but because of funding etc. this never came to fruition. If this comes about, there should be a way to say USE the lat/long provided and not those found in Wikidata or vice versa. I have noticed some issues with opening a map and ending up somewhere different than what was intended. I believe this was corrected by some previous action by maintainers? - one solution was to change the zoom level which solved an issue I had in the past. I am not sure if the problem was caused by the tiling or not. -- just a quick note -- Matroc (talk) 04:50, 4 November 2018 (UTC)[reply]
Shouldn't the maps always prefer coordinates given in the marker/listing over those in Wikidata? If the coordinates differ there should be a reason, and even if not, ignoring the coordinates in some situations is very confusing for editors as well as for users affected. And even worse, a map without markers is dysfunctional. Should some functionality of the template be deactivated until the problem is solved? I suppose most coordinates for listings come from here, so not using Wikidata coordinates should not be much of a problem. --LPfi (talk) 08:25, 4 November 2018 (UTC)[reply]
As I often appear to come out of left-field; I apologize in advance. I think one would be surprised at the increase in the number of markers entered with just a wikidata ID - much simpler to do that as it is convenient and rightly so; however, it would be an interesting task to actually fill in those parameters (lat/long) on a more permanent basis in the template that are blank while doing the wikidata lookup for coordinates. This just might resolve some of these issues. One of the categories for Articles needing attention is Region markers without wikidata (2,026 P); each page having 1 to 5 or more markers needing a Wikidata ID. I have been looking at them and putting in the Wikidata ID. As I prgress slowly, I will be adding the coordinates (lat/long) if missing and available. Do we have a category for markers without coordinates (we do for listings) - might be useful to see how many of them exist. -- Cheers! -- Matroc (talk) 04:57, 5 November 2018 (UTC)[reply]
I think it's worth discussing whether we should be adding lat/long in addition to Wikidata. The downside of doing so is we no longer stay in sync with changes on Wikidata's end, meaning we won't benefit from corrections and adjustments, and many editors will forget to publish adjustments we make back to WD, to the detriment of other-language WVs and sister sites. The benefit is that markers will display on poimap2. However, poimap2 is outdated and basically deprecated, not to mention that viewing it requires clicking a link at the top of the page, something I doubt many people do (as opposed to just using the embedded map or clicking a number). In my opinion, having a wikidata ID and no lat/long defined is fine, and what we should be moving towards. ARR8 (talk) 05:13, 5 November 2018 (UTC)[reply]
I suppose the "corrections and adjustments" of coordinates on Wikidata often mean moving them from pointing to the front door or parking to pointing to the centre of the POI or the like. Having wrong sign, missing first digit or similar mistakes are easily noticed on Wikivoyage, while I suppose not that many people check the coordinates on other projects (there have been some projects, like the sv-wp ones on lakes in Sweden and Finland, where coordinates and map shapes where used, but I suppose those are not common). Rather I think use of Wikidata coordinates should be postponed until things work (there is no problem in copying then semi-automatically, when there is an editor checking them, but that is a different use case). --LPfi (talk) 05:52, 5 November 2018 (UTC)[reply]
You can override wikidata lat/long, or you can also put lat=NA|long=NA to disable it altogether. lat/long in the markers/listings have priority over the ones fetched from wikidata. Also, there's no issue with funding, german wv already switched to non-poimap2, It's just that around here, such bold action doesn't have enough support... -- andree.sk(talk) 07:24, 5 November 2018 (UTC)[reply]
To ARR8's point, I want to say it's important that local coordinates not be systematically removed in favor of Wikidata—as LPfi alluded to, the coordinates most useful in a travel guide are often for an entrance or starting point, whereas the coordinates on Wikidata are usually for the center or midpoint. Of course, in cases where the coordinates here are just wrong, they should be replaced—but when our coordinates differ from Wikidata's, there's sometimes a good reason for that. —Granger (talk·contribs) 14:05, 5 November 2018 (UTC)[reply]
Definitely not systemically; I was thinking more along the lines of, during the course of editing an individual listing, manually removing the locally defined coordinates if they match the Wikidata coordinates (and if they don't, making them match, then removing them). ARR8 (talk) 14:23, 5 November 2018 (UTC)[reply]
My point is that in some cases, they shouldn't match, because (for example) the Wikidata coordinates should be for the center of the POI whereas our coordinates should be for the entrance.
As Matroc suggests, using Wikidata coordinates is easier than to find and add them using other sources. This does not mean we shouldn't add coordinates in the listings: fetching the coordinates from Wikidata and verifying them (and adjusting where necessary) should be easy. I suppose later changes on Wikidata seldom are to our advantage, so using the verified ones is the best course of action. --LPfi (talk) 17:38, 5 November 2018 (UTC)[reply]
@Mx. Granger: I agree that, in these cases, we should leave coords defined. However, I've recently been comparing local coords with Wikidata coords in case of differences, and, generally, this isn't the case. Usually, the coords we have here aren't a specific point on the building, just some point within it, usually to unnecessary precision and slightly off-center, whereas the Wikidata coords are generally the center of the building. I think we both agree that, in this case, it's fine to change our coords to match Wikidata's. I am proposing that, in these cases, or in cases where our coords already perfectly match Wikidata's, or in cases where we change Wikidata's coordinates to match ours, we can just not define coords at all and let them be fetched dynamically.
I'd be interested to hear your opinion on this. As it happens, I was going to ask the community how they felt about this, anyway, for changes I'm working on to the Listing Editor. Now is as good a time as any. ARR8 (talk) 21:17, 5 November 2018 (UTC)[reply]
I would prefer WD values to only be used in listings after they have been copied over by an editor. There are many large sights (lakes, mountains rivers etc), where we want to have a marker a mile or more from the centre of the item. If we have a listing for a 500 mile long river, we want to show a convenient point near the city to walk along the bank. we don't want to have an edit war over which point on the Rhine is chosen. It is also straightforward to spot if somebody has changed a listing directly, but practically impossible to see if the change has been made on WD; the UK emergency phone number (999) was wrong for 3 months because a bot had made an incorrect change on WD and nobody had noticed. AlasdairW (talk) 21:55, 5 November 2018 (UTC)[reply]
What about unambiguous listings that aren't lakes, rivers, mountains, etc., where we could be expected to always have the same marker (e.g. small buildings)? Your point about the quality of WD is well-taken, but, since it sounded like you are more concerned with cases where having different sets of coordinates is possible, I wonder if your concern about Wikidata's quality outweighs other considerations in simple cases. ARR8 (talk) 22:26, 5 November 2018 (UTC)[reply]
[outdent]
When our coordinates are slightly off or given with ridiculous precision, that is not a problem (although copying better WD coordinates is OK). But are the cases where our coordinates are lots off and WD coordinates correct common? Otherwise I see no case for deleting local coordinates. The ones on WD pointing at a good place for us now doesn't mean they will forever. And adjusting them to point to the entrance is easier if they are already here. For small buildings it does not really matter, but having also them here avoids having exceptions for them. --LPfi (talk) 22:27, 5 November 2018 (UTC)[reply]
@LPfi: Thanks for the input. I've noticed that you always respond whenever I ask for an opinion. Also, I almost never reply, and I think it's worth mentioning that that's because you always have a reasoned argument and make your opinion clear, so I almost never have anything to follow up with.
Back to the subject at hand: as usual, you make good points. Though I would say that, even if our coordinates are never lots off, there is still a case for not keeping them here (albeit a case that is looking weaker by the minute) and that is that, assuming we copy coordinates from a WD entry, it is unlikely we will ever copy them again in case of small improvements to the coordinate value there. If you assume, as User:AlasdairW seems to, that changes on Wikidata are more likely to be vandalism than constructive (although that doesn't match my experience) then, yes, maybe the protection from vandalism that we get by keeping the coordinates here outweighs any benefit we get from potential improvements to coordinate values. Although, you are also correct in pointing out that minor inaccuracies are tolerable here. ARR8 (talk) 23:12, 5 November 2018 (UTC)[reply]
I don't think that edits on Wikidata are more likely to be vandalism. The problem is that vandalism or wrong good intentioned edits may not get noticed if they are done on WD. Problem edits are likely to be spotted and reverted if they are done here. I think that most occasional editors would not know how to change a value on WD. I would be happy to make full use of WD when an editor is seamlessly taken to the value to edit on WD, and when changes on WD which directly affect our articles (not any change to the related WD entry) show up on watchlists and Recent Changes. AlasdairW (talk) 23:49, 5 November 2018 (UTC)[reply]
That makes sense. I was a little surprised when I saw how, frankly, useless the Wikidata changes are in recent changes/watchlists. If I had to pick my biggest problem with WD, that would be it. Maybe that should be our community wishlist suggestion (showing changes to only relevant properties and for listings as well as pages)? ARR8 (talk) 00:01, 6 November 2018 (UTC)[reply]
"useless the Wikidata changes are in recent changes/watchlists" This is actually IMO the first constructive point of this discussion. We should push this with the same prio as the dynamic map improvements. Wikidata are big part of WV by now, whether some of us like it or not, so it would be great to have it integrated better. -- andree.sk(talk) 07:47, 6 November 2018 (UTC)[reply]
I found this discussion very useful for my own project and would actually like more of a consensus on keeping coordinates here vs not. But, I agree with you that this would be useful to have. The wishlist has a related proposal right now. All we need in addition to that proposal is displaying changes to hyperlinked Wikidata elements, and not just the main one for each page. Should we create a new proposal or try to add on to that one? I have no experience with this. Maybe User:WhatamIdoing can weigh in? ARR8 (talk) 15:04, 6 November 2018 (UTC)[reply]
Whether unnoticed vandalism is common on Wikidata is irrelevant for the original discussion as long as good edits on Wikidata may be bad for us. I suppose the most important scenario is a big outdoor museum with our entrance coordinates copied to WD, later verified to be identical with ours and removed from here, and later changed on WD to point at the central point instead. Monitoring such changes to reinsert them here after the fact is extra job, avoided if they were never removed. In the worst case the change is noticed by a novice WV editor (perhaps the guide author), which then gets involved in an edit war at WD with no clue about what is going on, perhaps using the WV talk page to explain their edits. I think some infrastructure for handling conflicts between WD editors and editors from other projects should be a priority for the WD project. --LPfi (talk) 17:23, 6 November 2018 (UTC)[reply]
Hi all, I took a shot at creating a districtifier web app. This tool should help to create dynamic district overview maps in less time than what is currently necessary. Please have a look, if you want:
I like it! Definitely a good idea that you can more-or-less draw your own districts. In the display, though, it starts at "District Zero". That seems a little counterintuitive. --Comment by Selfie City (talk | contributions) 01:13, 25 October 2018 (UTC)[reply]
Hi Selfie City, glad to hear! Shouldn't be a big problem to rename the first district. Gonna do it ASAP. But the idea is, that editors delete this placeholder name and enter a proper one. --Renek78 (talk) 19:26, 25 October 2018 (UTC)[reply]
Exactly, Selfie City! At the very bottom you can click on the word "help" to get some instructions on how to do it. I am trying to simplify the process of getting those district areas into the tool. --Renek78 (talk) 09:05, 26 October 2018 (UTC)[reply]
Thanks for reporting! Interestingly, it only happens to me when the map is in full-screen mode, not when embedded in the page. And it does not happen at all for article Fuji Five Lakes for instance. Syced (talk) 03:49, 10 December 2018 (UTC)[reply]
andree - I noted this in an edit sumary when I tried in November to see if I could correct Shenyang error: Some of the pieces for the mapshapes are identical and rest have nothing... claims is not nil but parts of it are... I had similar issue which I resolved using "pcall" to catch an error (similar to catch in c) -- will add snippet to discussion page for Mapshapes -- Matroc (talk) 07:16, 12 December 2018 (UTC)[reply]
Can the destination map of a Wikivoyage increase the functionality of the person's location?[edit]
Wikivoyage are about to become a travel guide for any traveler, and I think the destination map needs to add a person's location (like a Google Map) to help travelers find the places they want to visit.
At the moment there is no intention to implement this. These are user requests to the MediaWiki development team. If you think it is important you, and others, need to voice this on the pages linked above. --Traveler100 (talk) 19:15, 21 January 2019 (UTC)[reply]
Open a Point on the map and click on next or previous destination to navigate the Inca Trail... Idea is not to scroll the map but move to a new map from point to point. Though not exactly a typical Wikivoyage map; the concept may prove useful in special or limited circumstances... Cheers!
This kind of odd problems sometimes appear when you run out of memory (disk space, allowed memory use, whatever). --LPfi (talk) 21:44, 25 June 2019 (UTC)[reply]
I using is Yandex browser, and search engine is Google; by the way, the wikimedia map have fixed, display is normal, very thanks anyone to provide help and fix!--✈ IGOR ／ ✉ TALK?!．WIKIVOYAGER !17:21, 27 June 2019 (UTC)[reply]
Some of the current most prominent itinerary articles at Hebvoy (to which we link from the main page) are missing the actual route from the dynamic map.
The following articles are the ones which need the route added the most (just like we did this article).
In many cases routes actually exist in OSM. if I click on the "Hiking" layer for these articles at the dynamic maps in Hebvoy I can see that there exists a route.
Most of the dynamic maps where there are more than a few POIs appear to be not working for me - looks like the cause are {{mapshape}}s (regions, lines). Either I can't interact with the maps (the zoom buttons, pan function, clicking..), or the map shapes (regions, tracks etc.) are half rendered. Seems to be for a few days now, on multiple PCs, firefox and chrome... E.g. Tenerife works, but Madrid doesn't. What gives? -- andree.sk(talk) 10:54, 24 June 2019 (UTC)[reply]
Unlike the discussion right above, I've occasionally experienced things like that for several months. For me, the embedded maps are also often completely white with only the markers showing up. But more often than not, the maps work normally. --Ypsilon (talk) 11:05, 24 June 2019 (UTC)[reply]
Looks like it's really intermittent - Central_Spain didn't work before, now it works (for me). Must be some script execution time limit or something, somewhere :-/ -- andree.sk(talk) 11:50, 24 June 2019 (UTC)[reply]
Within the last days there were some problems with the map server(s) that temporarily do not deliver line and shape elements but failure codes 404 or 400. These elements are put in different layers above the map. This is combined with another software failure: the Kartographer map tools do not check the nonexistence of these elements and they crash. These crashes prevent any display of dynamic elements, and only a fallback background map image is shown. I hope that this problem is now solved. --RolandUnger (talk) 05:10, 27 June 2019 (UTC)[reply]
Using OSM data does not mean that these data are correct. In many cases polygons are not closed and cannot be used as an (inverse) shape but only as a line. I cannot say if there is a bug in the mapserver's tools or if an additional functionality for closing polygons is needed. --RolandUnger (talk) 05:47, 28 June 2019 (UTC)[reply]
I would say this is an urgent problem. I've been noticing Xinjiang missing from the China map for weeks, and because this region has an active independence movement, the misrendered map makes it look like Wikivoyage is taking a contentious political stand. —Granger (talk·contribs) 19:18, 28 June 2019 (UTC)[reply]
Who can fix Wikimedia maps #3 - Tile rendering style[edit]
I found something to complain about in the style for the Wikimedia layer. However, I have no idea where the stylesheets that control that layer are in order to ask about it or suggest a fix. Some google searching has gotten me nowhere. Any suggestions for where to look? --Bigpeteb (talk) 22:48, 24 October 2019 (UTC)[reply]
Styles can be fixed only by the Wikimedia programmer's team. Usually you have to announce them at the Phabricator. But can you explain what you want to fix? --RolandUnger (talk) 07:05, 25 October 2019 (UTC)[reply]
On Hartsfield–Jackson Atlanta International Airport, zoom in one or two clicks. There are roads all around the gates for baggage trucks and such to get to the airplanes. However, if you compare https://www.openstreetmap.org/way/557635004 and https://www.openstreetmap.org/way/737693812, you can see that the one marked access=private is drawn with a bigger line than the one without an access=* tag. I don't know what in the stylesheet is causing that, but it's clearly distracting in this case. (Compare that to OSM's standard layer, where they're the same width, but the private ones are filled with a dashed line. And similarly, on OSM, all of the service roads are drawn smaller than other types of roads (like this one), whereas the Wikimedia layer shows the ones marked private as the same width.) --Bigpeteb (talk) 16:52, 25 October 2019 (UTC)[reply]
I've had this problem before, but it's particularly annoying at Danxiashan. Open Street Map has good coverage of this park's hiking trails, but they don't show up on our dynamic map except at high zoom levels. Is there some way to make the hiking trails show up even at the default zoom level in the map on that page? —Granger (talk·contribs) 04:20, 6 November 2019 (UTC)[reply]
Create a relation in the OSM data for the path you want to show, add the needed roads/paths to that relation. Ideally, it should be some semi-official trail - "private" stuff is not welcome in OSM.
Create a wikidata entry and interlink it with the relation (technically, wikidata reference in the OSM relation is enough, but I recommend doing both)
Add mapshape referring the wikidata into your article.
That looks like what I need. I wonder if the relation already exists—I'm not looking to highlight a particular route, just to display all the hiking trails in the geopark. I'll poke around and see if I can figure it out. Thanks for the help! —Granger (talk·contribs) 13:57, 6 November 2019 (UTC)[reply]
@Andree.sk: I'm working on it, but because there are dozens of footpath features in the park, it's very tedious and I'm worried I might miss some. Is there any way to select an area and have OSM give me a list of all the footpath features in the area? —Granger (talk·contribs) 01:30, 7 November 2019 (UTC)[reply]
Also, this page makes it seem like relations aren't intended for this purpose. Again, I'm not trying to display one particular route, but rather all the hiking trails in the park. Should I make the relation anyway, or is there some other way to accomplish this? —Granger (talk·contribs) 02:17, 7 November 2019 (UTC)[reply]
If you really just want to show all paths and they are not something special on their own (stuff like Tatra Mountains main road), it's likely really not a way to go... It'd be ideal to show the mapnik map as the background by default (for this particular page), but I don't think kartographer can be configured to do this. Perhaps a good point for the wishlist, then... The only real solution I can think of right now would be exporting the paths as GeoJSON, put that into commons and then make it render on the map here as geolines. Not too trivial, though - and you'd have to sync it with new stuff in OSM once in a while. @Matroc: experiments with this geoshape/geoline stuff quite a lot, maybe he has some nice tools in the pocket? :) -- andree.sk(talk) 06:52, 7 November 2019 (UTC)[reply]
Thanks for the information. I guess I'll give up for now. It's unfortunate—this feels like it should be so straightforward. Maybe I'll add it to the wishlist. —Granger (talk·contribs) 14:23, 8 November 2019 (UTC)[reply]
A single Commons data file containing each set of trail coordinates is one consideration as a solution that I can think of at this time... - Matroc (talk) 03:29, 11 November 2019 (UTC)[reply]
Seeking advice out from experienced users proficient in adding dynamic maps, linking to Wikidata and KML-to-OSMimports (I find myself quite lost in all this OSM/KML/GPX etc. stuff, so not be doing it myself), as per Talk:Public transit in Israel#Zoning maps. Not sure though if the transit zoning mapshape layers are already in there (OSM and Wikidata), if they are, I propose referencing where relevant and inserting these 90-min and periodic pass maps, as it is easier to look in if they are layered on top of a normal proper map (such as the google mymaps refs added), than to try find out where a zone ends (if travelling on zone borders) when looking on schematic maps such as these on bottom of page. I think the data of these KMLs would also benefit in most Wikimedia articles cross-wiki, be it Wikivoyage (the Public transit in Israel guide (periodic passes and 90-min transfers) and "Get in/around" references in Israel locations guides) or Wikipedia (show transport zone id in infobox templates of locations) or Wikidata (queries such as "in which zone a given location is", fetching the data from mapshapes' tags, etc.) --Arseny1992 (talk) 04:08, 7 November 2019 (UTC)[reply]
icons into the pop-up cartoon bubble on the map (like we do for listing|image=... now) might be a possible compromise to keep this stuff out of the main text body? It'd appear (under the image) only if the map icon is clicked. There are fr:Modèle:Listing icons for everything from wheelchair access to wi-fi; moving these to the pop-up map bubble minimises clutter, at the expense of displaying only if valid (lat, long) are present.
Done {{mapmask}} does not seem to be implemented for the new maps - see Culver City for an example of an article that should include a mask. Is there another way to implement this functionality with the new maps? -- Ryan • (talk) • 21:35, 8 June 2016 (UTC)
![[1]](https://github.com/mapbox/makizushi/blob/master/markers-src/base/pin.svg){kind=link}
![[2]](https://github.com/mapbox/makizushi/blob/master/markers-src/mask/pin.svg){kind=link}
