Swept in from the pub

Can anyone tell me how I can find GPS coordinates (latitude, longitude)? RomanichthysValsanicola 18:52, 14 November 2016 (EET)

There are many online maps from which you can get coordinates by (right?) clicking (possibly after some setting change). I think Google maps and Open Street Map (OSM) are the most commonly used, but for specific regions other maps can be better. Also many paper maps have coordinates close enough to WGS84 (which is what GPS uses). And you could have a GPS with you while visiting and note the coordinates. If you click on the map icon at the top right corner on (nearly) any of our articles you should get an OSM based map for the place in question. Drag and zoom as necessary, right click on the point you want the coordinates for. --LPfi (talk) 17:19, 14 November 2016 (UTC)[reply]

If you click on the coordinates in the top right corner of many articles on Wikipedia, you get to the GeoHack page for the place, with an assortment of online maps that may be usable for the location. --LPfi (talk) 18:34, 14 November 2016 (UTC)[reply]

Probably recommend Open Street Maps over Google. Since our maps are use OSM the coordinates are going to be consistent. (Google Maps is sometimes different, for example with Chinese locations). --Andrewssi2 (talk) 22:38, 14 November 2016 (UTC)[reply]

Ok, I'll use OSM, but on this site how can I find the coordinates for a location? RomanichthysValsanicola 17:21, 16 November 2016 (EET)

@Romanichthys Valsanicola: URIs at OSM are in the form of "https://www.openstreetmap.org/#map=9/56.0659/-3.2726" or somesuch and those numbers at the end are your geo coordinates. —Justin (koavf)❤T☮C☺M☯ 15:47, 16 November 2016 (UTC)[reply]

Swept in from the pub

Hello! I was curious to know what others think of this idea. We could create a new "Maps" sub-section where maps go? Check out this edit for what I'm thinking. (There seems to be a software bug preventing the "See" title from being displayed, so pretend that works.) This could be helpful on other pages where we have both static and dynamic maps. I find both styles of map to (usually) be oddly sized, and they never seem to fit quite right into the text (IMHO). This would also free up space next to the "See" listings, prime real estate for some fantastic photography. This page in particular seems to cry out for a map section. Also people love maps, so why not have a link to them in the top banner thing? Thank you! --ButteBag (talk) 15:13, 7 February 2017 (UTC)[reply]

It would also standardize where maps go, sometimes they are under "Get in", sometimes under "See", etc. --ButteBag (talk) 15:33, 7 February 2017 (UTC)[reply]

I like the layout idea, but I'm not sure about putting the map in its own section. I guess maps benefit from wide screens, keeping to show more and in mobile is displayed normally as is today. --Zerabat (talk) 16:46, 7 February 2017 (UTC)[reply]

I thought that we had standardised on putting dynamic maps in "Get around". See Wikivoyage:How to use dynamic maps, although it is not very obvious: "It should usually be placed right underneath the "Get around" heading". I can see the benifit in having a separate section, but it would be a lot of work to update the whole site. AlasdairW (talk)

The best bit about the idea is expanding the dynamic map across the whole page. There's no reason why that still couldn't go in 'Get around', though. --ThunderingTyphoons! (talk) 20:06, 7 February 2017 (UTC)[reply]

Thank you for the feedback! Yes, I find the additional space for the dynamic map quite helpful. Wikivoyage:How to use dynamic maps may say to place maps under "Get around", but that section is missing on Wikivoyage:District_article_template, so where to put it there? Also the "Get around" rule is not used consistently. Maybe a "Maps" sub section could be optional? (like "Other destinations", "Learn", "Work", "Stay safe", "Stay healthy", "Respect", and "Cope"?) Thank you! --ButteBag (talk) 20:30, 7 February 2017 (UTC)[reply]

Or maybe the easiest solution is to repurpose "Get around" in district articles, optionally placing maps there? It would conform to preexisting policy, and not require the creation of a new sub section. Static and dynamic maps would be equally at home. Is that cool? --ButteBag (talk) 20:52, 7 February 2017 (UTC)[reply]

Exactly what I am thinking now --ButteBag (talk) 20:57, 7 February 2017 (UTC)[reply]

OK, I'm going to give this a shot on a few neighborhoods since it doesn't seem to be a big deal, and seems to conform to policy as near as I can figure. I haven't seen anyone else do this before, however, so opinions may abound. --ButteBag (talk) 15:06, 8 February 2017 (UTC)[reply]

Go for it. It will be interesting to see how it works on different articles with different map shapes. The map on that Boston district didn't quite work enlarged; the narrowness of the district - long and thin in a vertical line, so perpendicular to the horizontal width of the map - just looked odd, and wasn't a great use of space. But a map that was wider (maybe for a city rather than just a district) could fare better. --ThunderingTyphoons! (talk) 17:01, 8 February 2017 (UTC)[reply]

Thank you! Yes I selected that article in particular because I knew the "portrait" orientation would look a bit odd, the layout clearly works better for "landscape" articles. The "wasted" horizontal space will vary by screen width, but the vertical space (used by dynamic maps) remains the same. At minimum, a user could at least make out the shape of the neighborhood before scrolling down. And if the map is interacted with (eg.. click the plus once or twice), the additional real-estate becomes quite useful. Plus I think it might look a little odd at first because I'm not used to seeing the map presented like this. Anyway, I'm optimistic. --ButteBag (talk) 19:25, 8 February 2017 (UTC)[reply]

I agree with keeping the map in the Get around section since, for me, it makes the most sense there. I'm torn about the map being fully horizontal. I think it's pretty, but I'm not sure how much I like the idea of a map interrupting the flow of text. It might just be that I am not use to it yet. DethDestroyerOfWords (talk) 20:55, 9 February 2017 (UTC)[reply]

I don't think all people "love maps", but they are a vital part of a travel guide. I also don't think we need a standard separate maps subsection. In most cases that just crowds the menu. Get around seems perfectly fine for maps. I'm not necessarily against the broad display if people think it works better in terms of layout, but I agree with ThunderingTyphoons that on Boston/Roxbury and even on Boston/Back_Bay-Beacon_Hill the extra space is taken up by areas not covered, so the usability seems limited. It's fine to try it out on a couple of pages, but it's surely not our normal practice so before introducing it to too many pages there should probably be a consensus. JuliasTravels (talk) 21:12, 9 February 2017 (UTC)[reply]

Fair enough, and thank you for your feedback! I agree maps should definitely go in the "Get around" section, no need for a new section. I also agree about watching the overall map height, the layout will break if the map gets too tall (if anything I'd like it shorter). I am really liking that you can put an image next to the "See" listing. That just makes more sense to me (personally) than seeing a map there. Pushing the map slightly further up the page doesn't bother me, since the map is usually long gone by the time a user scrolls down to "Do". I'm not convinced the greyed out areas to the left and right is "wasted" space, you at least get a sense of location and context. If a static map were ever created for Roxbury (for example) they could live in 50% columns side by side. Ha, even if there was consensus I would not update this style on other pages, don't worry! Thank you again! --ButteBag (talk) 21:44, 9 February 2017 (UTC)[reply]

Swept in from the pub

Free Website for Printing Detailed Topographical Maps, for the US only. We almost certainly cannot use their material here for copyright reasons, but it seems like a resource we should link to. Pashley (talk) 08:02, 23 March 2017 (UTC)[reply]

Thanks, that's a good resource. Some maps have a rather nostalgic feel, reminding me what this or that place looked like 10-15 years ago... -- Vmenkov (talk) 02:18, 24 March 2017 (UTC)[reply]

NGS is claiming copyright on their modified maps but the original USGS maps should be public domain. (They're also way out of date in my local case; about 40 years so.) Powers ^(talk) 01:28, 28 March 2017 (UTC)[reply]

Swept in from the pub

Hello,

I am Paul Norman, a contractor working with the Maps team on Discovery at improving the Wikimedia map styles, infrastructure, and other map-related tasks. My background is as an OpenStreetMap developer, and I am a maintainer of the OpenStreetMap Carto style, the default on osm.org, as well as many other components in a standard OSM map rendering setup.

As part of https://phabricator.wikimedia.org/T153282 a new style for Wikimedia maps is being developed, and I've loaded the whole planet on one of my servers as a test and demo.

The demo is available at http://legolas.paulnorman.ca:6789/, and through "Compare" on the right-hand side of the interface you can compare it with the current Wikimedia style, OpenStreetMap Carto, and lots of others. Some other things to be aware of when comparing are:

• The map is displayed with Kosmtik, a design tool with minimal caching, and it might be restarted while I'm working on it
• Even though the server is faster than production, it may appear slower because it doesn't have everything cached
• The OSM data on the server is normally within a day of the latest data

Some of the more noticeable style changes are

• Road colours are different, helping view the overall layout of the city
• There are fewer cases of subtly different shades of green.
• Bridges and multi-level road constructions are now handled properly, which should make some areas easier to figure out

I am particularly interested in feedback on

• the overall colour darkness and intensity,
• which of city, region, and country labels are most important: https://phabricator.wikimedia.org/T163503

Feedback is welcome, either here, through phab tickets, or by IRC in #wikimedia-interactive on freenode.

Pnorman (talk) 23:23, 4 May 2017 (UTC)[reply]

It looks good but the renderer seems to give too much prominence to expressway on- and off-ramps. They show up at a much lower zoom level (lower meaning more zoomed-out) than before, and that makes the expressways look "bumpy". Powers ^(talk) 01:50, 5 May 2017 (UTC)[reply]

At zoom 9, there isn't enough contrast between motorway and primary roads. Perhaps it's because they're rendered with borders/outlines, instead of just a solid fill. Zoom levels 10-12 are better, and 13 is even better still; 9 is definitely the worst. In general, I'd prefer more contrast at all levels; the difference between "dark orange" and "light orange" is too close. --Bigpeteb (talk) 17:49, 5 May 2017 (UTC)[reply]

I agree with there not being enough contrast. I prefer the old road colour scheme where the highways/motorways were orange and arterial city streets were yellow. Some other things I noticed:

• I like how non-motorway highways are better differentiated from arterial city streets at zoom levels 12 and lower
• I like how the side streets are more muted at zoom levels 12-14
• I find the bridges are sometimes emphasized too much, particularly on zoom level 12
• I like that fewer city labels are displayed at zoom levels 10 and above (i.e., 1-10), and seems to be doing a pretty good job at picking the most important ones
• I much prefer the old multi-hued green scheme for forests and parks. The new scheme emphasizes forest cover too much and covers over designated parks. From a travel guide perspective, those parks can be objects of interest, whereas forest cover usually isn't. A second reason for not liking the new scheme is, where I'm located (Vancouver/southern BC), the coverage is very patchy -- there are blocks of green and white depending on whether OSM has ground cover info or not. It doesn't look good. -Shaundd (talk) 22:52, 5 May 2017 (UTC)[reply]

• Bumpy roads where ramps are is a side-effect of the choices in phabricator:T156330.
• Created phabricator:T166902 for the z9 contrast issues.
• Are you mainly seeing the excessive bridge contrast with secondary and primary? I find it fine for z12 motorway bridges
• A meeting is scheduled for the shades of green and national parks

Pnorman (talk) 20:00, 2 June 2017 (UTC)[reply]

Thanks for the follow up comments. Looking at it again, I agree motorway bridges at z12 (and higher resolutions) look fine. It's the city streets with long bridges where the black/dark grey is most noticeable. For state/provincial highways, it's hit and miss (some look OK and other times the bridge really stands out). -Shaundd (talk) 04:03, 4 June 2017 (UTC)[reply]

We've addressed most of the issues in a few ways

• Minimum zooms for a few transportation-related features were adjusted
• Greens adjusted
• Towns displayed sooner
• National parks and nature reserves are displayed with an outline and a label

Pnorman (talk) 00:09, 7 June 2017 (UTC)[reply]

Thanks. The bridges look better. I'm still not a fan of the forest cover (I'd prefer it to be a separate layer that could be toggled on and off), but that's just personal preference. The parks are a big improvement with the outline and label. -Shaundd (talk) 05:50, 7 June 2017 (UTC)[reply]

Paging @Pnorman:; just making sure you see this feedback. Powers ^(talk) 00:25, 9 May 2017 (UTC)[reply]

I have not been looking into these issues, but one thing I often find dissatisfying with the dynamic maps is that one has to resort to an external source to get the topography. For many parks, topography (and vegetation – also lacking) is one of the most important things you want to see. Also for other places were outdoors activities are important, topography and vegetation would be very nice to have. OSM seems to have topography on the biking map. --LPfi (talk) 06:45, 9 May 2017 (UTC)[reply]

To what extent is the issue of relief one where the layer= parameter seems to have no effect (presumably because of the privacy considerations for using externally hosted mapping). I agree that wider flexibility of prominent aspects (i.e. relevant to the page the map is being used on) would be a great enhancement. The current system shows where specific points referenced in the text are but in some situations more is wanted of a map (e.g. a ski resort where terrain would enhance the map or an area with national parks where vegetation ...). I don't know what options can be done with rendering with the mapping data Wikimedia hold and what additional data that it could access. Or, could some way round user privacy where non-Wikimedia hosted mapping is used (e.g. proxy through Wikimedia) PsamatheM (talk) 14:35, 20 May 2017 (UTC)[reply]

Swept in from the pub

Hello all of you. As a Belgian and someone who knows Brussels pretty well I would like to work on this page in the near future. Tons of interesting places in the city are missing in this article. With great pleasure I would like to add these, but I feel the need to introduce districts to keep it all comprehensible. As I do not have (deep) knowledge on making maps and Wiki techniques, I gave it a try on the User:Podrozniczek/Test page, which went pretty well until I got to the center. The problem is that the area that administratively is the center of Brussels, more logically for Wikivoyage would be split up in 4 parts (the northern leg joining the neighboring municipalities, the historical pentagon separately, as well as the European Quarter, and the Louise Avenue stripe on the south joining Ixelles. Since this is no official administrative border I can not find anything usable on Wikidata. Is there any way to solve this problem? Thank you in advance? Podrozniczek (talk) 16:42, 25 May 2017 (UTC)[reply]

Hi Podrozniczek, in situations like that, we'll have draw it ourselves. Commons now has the Data namespace where you can create mapshapes and then add them to a dynamic map in a couple of ways. The data files have to be in GeoJSON, but the code can be obtained at geojson.io -- just draw the shape on the map and the box on the right side of the screen produces the code, which can be copied to the Data page in Commons. There are a couple of help pages that explain how the Data pages work (certain things need to be included besides the GeoJSON code) -- mw:Help:Extension:Kartographer#Map_data_from_Commons and mw:Help:Map Data -- if you want to give it a try. I've been testing it a bit so you can look at c:Data:Sandbox/Shaundd/Northern Oregon Coast.map and User:Shaundd/Dynamic_Region_Map#Commons_Data_page_test to see some working examples. If you run into problems or don't want to deal with the code, let me know and I can try building the mapshapes if you don't mind waiting a few days. -Shaundd (talk) 05:06, 26 May 2017 (UTC)[reply]

What's to stop us losing data stored on Commons without notice? We just lost a static map at c:Commons:Deletion requests/File:Kimberley map.png for no good reason; first anyone here noticed was when an automated script pulled the link out of the destination article. K7L (talk) 11:09, 26 May 2017 (UTC)[reply]

As long as we use open sources and properly document it on the Commons page, there shouldn't be much danger in losing maps or data stored on Commons. According to the link, the map was deleted because the source was described as own work but it looked like a derived work (e.g., it was traced from another map). Looking at the original map on WT, I feel that's a reasonable assessment. A map traced from OSM is fine because it's CC-licensed; a map traced from Google Maps is a copyright violation -- but we don't know if the author doesn't state it. Anyone uploading to Commons just needs to take a couple of minutes to note the source and provide a link if there is one and this problem largely goes away. -Shaundd (talk) 15:39, 26 May 2017 (UTC)[reply]

I stumbled upon your testing page yesterday night, User talk:Shaundd, and it helped me out a lot. Thanks ;) Podrozniczek (talk) 16:02, 26 May 2017 (UTC)[reply]

Glad it was helpful! -Shaundd (talk) 19:07, 26 May 2017 (UTC)[reply]

Just wanted to add something, that I have just leant: When creating a polygon with help of geojson.io the output has plenty of line breaks, which makes the code extremely lenghty. I was able to remove the breaks with Notepad++ and this little tutorial. Hope this helps someone. On a more general note: A how-to for creating overview maps would be great. If it was easier more people would make them. --Renek78 (talk) 21:01, 30 May 2017 (UTC)[reply]

Hi Renek78, what do you mean by "plenty of line breaks" and was it causing a problem? I've just been copying the code directly from the site to the Commons Data page and haven't had any issues, but if you've had a different experience it would be good to capture that in a how-to page. -Shaundd (talk) 05:51, 1 June 2017 (UTC)[reply]

If the map is called from Commons the line breaks do not matter. But if you implement the polygon coordinates right in the Wikivoyage article all those line breaks are not acceptable, I would say. --Renek78 (talk) 06:50, 1 June 2017 (UTC)[reply]

Thanks, that's good to know. -Shaundd (talk) 13:15, 1 June 2017 (UTC)[reply]

Line breaks are ok as I use them without any problems - especially when I have a lots of coordinates and group them for readability ie. 4 or 5 coordinates per line - without line breaks is ok as well -- Matroc (talk) 18:39, 1 June 2017 (UTC)[reply]

Losing data is a posibility, see Wikivoyage talk:Cooperating with Wikidata#Deleted listings on Wikidata for another recent instance. K7L (talk) 16:43, 26 May 2017 (UTC)[reply]

Yes, it's a possibility, but I think it's unlikely if we take the simple precaution of making sure the data complies with the license requirements and the source is noted. Commons has created a Data namespace specifically for maps and Wikidata has created a geoshape property (P3896) to reference those Commons Data pages. To me, it looks like they want that kind of data to be stored there. It's a trade-off, we have less control over data stored in Commons and OSM, but it's more shareable and the infrastructure is being designed for integration with dynamic maps. Anyway, that's just my opinion, the community will need to discuss and decide a direction to go in when the tools are more polished. -Shaundd (talk) 19:07, 26 May 2017 (UTC)[reply]

Shaundd, it depends on whom you call they. The Commons community knows nothing about the Data: namespace, I think they were even against creating it at some point. But technical staff of the WMF chose to store such "long data" on Commons (as opposed to "short data" = individual statements on Wikidata), which is a bit disappointing for reasons mentioned by K7L. The Commons community is notorious for their ignorance to other projects and for mistreating the content that does not belong to them. On the other hand, map boundaries should have a higher chance of survival compared to images, which we store on Commons anyway. --Alexander (talk) 20:36, 26 May 2017 (UTC)[reply]

K7L, that's a serious concern indeed, but the same concern applies to page banners and regular photos. We lose many useful photos because of the unreasonable, ignorant, and hostile approach of the Commons community. Nevertheless, I think that map data are relatively safe for at least 2 reasons: i) you can always write "source=own work" and "license=cc-0", which will raise all typical Commons issues; ii) the Data: namespace is not frequented by any of the Commons users.

Our long-term experience with page banners, including those that do not satisfy all the stringent Commons criteria, tells me that files on Commons are quite safe when they are uploaded by experienced users and stored in a separate tree of categories, which mostly does not overlap with the main tree. Then the chance that anyone stumbles upon such files is minor, and the chance of deletion is minor as well.

Since we are interested in sharing map boundaries between different language versions, storing them on Commons would be great. But we have to decide how to organize such data. Ideally, we should organize them in such a way that people not affiliated with Wikivoyage will not put their nose into it. This should eliminate most of the risks. --Alexander (talk) 20:36, 26 May 2017 (UTC)[reply]

Discussing and deciding how to organize the data is a good idea. Not only for the reasons you mentioned but also to make it as easy as possible for Wikivoyagers to find it. Do you have any thoughts? I was thinking any region boundaries should be clearly labelled, maybe like "Data:Wikivoyage/region name.map". Roads and other tracks I'm not sure about as other projects (e.g., Wikipedia) could use them too. -Shaundd (talk) 20:59, 26 May 2017 (UTC)[reply]

I believe that Wikivoyagers can find everything via Wikivoyage, i.e., by copying a template from another language version and modifying it where necessary. The data file may include the word 'Wikivoyage' indeed, but I am not so sure about the 'region name', which is ambiguous, especially for regions that do not exist in English Wikivoyage yet (Moscow districts would be one example). I thought of using Wikidata IDs, which are unambiguous and essentially prevent anyone from looking into the files. --Alexander (talk) 21:24, 26 May 2017 (UTC)[reply]

Wikidata IDs are a good idea. There's a link to the ID from the WV page (provided a WD id has been set up) so it should be easy to find in most cases and it's easy to describe in a help page. I just did a quick search and found some district articles aren't set up in WD yet, but I guess those can be created as needed. -Shaundd (talk) 21:48, 26 May 2017 (UTC)[reply]

Swept in from the pub

Hello,

I made a map based wiki website which seems to be what Dynamic maps Expedition wants.

Problem this website and probably Dynamic maps Expedition want to solve is the disconnection between information and their location. Traditionally, travel articles are organized by place names, and planning bigger trips involves going back and forth between the article and Google Maps, wasting quite some time. Furthermore, articles can't have too many listings in them or else it becomes a bloated ugly yellow page.

My solution is to attach info to the map as snippets which will appear or disappear based on zoom level with optional popups for extra info. Only 'interesting enough' snippets will show up as you zoom to prevent clutter. Listings of business can be made to hide in high zoom level, allowing more listings without bloat. You can zoom in to Amherst, MA or NYC (worse option as not much info is added) to see how it works.

If interested, the website is impressionmap.org; use default user whoisthefairest password memememe to edit if you don't bother registering. By the way, the website doesn't work on IE and renders a bit ugly on browsers released before March 2017. Tell me if something else if wrong!

Asking for thoughts, opinions and advice! I want more content and wikivoyage wants a good map, maybe this will work^_^

Hopefully it's ok to do this introduction here. Made a similar one on Wikitravel a week ago but it seems that they aren't that active. Found wikivoyage after some effort, don't want to get banned Wkenmomo (talk) 17:42, 5 June 2017 (UTC)[reply]

I can see the benefits of such a system for specialist sites. But I think that on WikiTravel it becomes a lot harder to define what is more or less important or interesting. A family with children will find different things "interesting" or "important" than a backpacker who loves clubbing and partying or a somebody cycle touring or a businessperson with a few free days in Miami ... So what snippets are given prominence would depend on the interests of the user. PsamatheM (talk) 10:01, 6 June 2017 (UTC)[reply]

Thanks for your comment! Problem with the whole hiding snippet thing comes from map congestion when zoom out. PoiMap2 hides everything and replace them with number of markers hidden which isn't very helpful, my approach is to hide the unimportant ones and show a summary of that area. As you said, importance is hard to define. My current definition is ability to motivate someone living on the corner of current map with general travel intention to come solely for this thing. If wikivoyage ever wants to show 'POIs of other articles' (from Dynamic Maps Expedition), the congestion while zoomed out/hiding stuff problem has to be solved somehow. As I'm not familiar with how stuff works here, is there any user's attention I need to draw? Like is there a group of users working on that map expedition? Wkenmomo (talk) 17:01, 6 June 2017 (UTC)[reply]

In my opinion on a site like WikiVoyage "importance" is impossible to define because different users will have very different interests. What is important for a party/clubbing "let you hair down" youngster will be totally different from "important" for a natural history enthusiast seeking tranquility both of which have totally different "important" from a family with kids in their caravan, etc. I think other sites may have narrower interests and thus can define "importance" (e.g. bird watching site or a windsurfing site, etc.) PsamatheM (talk) 18:56, 6 June 2017 (UTC)[reply]

Wikivoyage already uses some "importance" since it uses a hierarchy. For example in United States of America, there is no mention of hang gliding parks or the Emily Dickinson Museum in Amherst, MA. Somehow both are deemed not important and unworthy of mentioning. Furthermore, current map demo map and art map hides everything when zoomed out. Those numbers and '+' aren't helpful.Wkenmomo (talk) 04:12, 7 June 2017 (UTC)[reply]

On Wikivoyage maps it might be useful to be able to select only some categories of listings. If I have zoomed right out on a map, I may not be interested in places to eat or drink, or if I am looking for somewhere to stay, I might be interested in only seeing the sleep listings on a map. I think that this kind of decluttering could be more useful than having orange crosses (that are on full screen maps, but not mapframes). AlasdairW (talk) 22:21, 7 June 2017 (UTC)[reply]

That's exactly what I'm proposing. For categories, in my opinion, custom icons can do the job without layers. Some lodging, bar icon was added on imp map, check them to see if it's effective for your eyes. The central proposal of impression map is indeed the ability to hide places when you zoom out and put an area description rather than orange cross/cram everything in one place. Wkenmomo (talk) 01:44, 8 June 2017 (UTC)[reply]

I am sorry that demo really doesn't work for me. I start seeing a bar icon with "Vodka for the motherland", but when I zoom in to see where it is it disappears. Whilst removing bars as I zoom out is desirable, what I want is a set of checkboxes to select which listings are shown (the defaults could vary with zoom), so if I am planning a night out I can see all the drink listings, but none of the see ones. AlasdairW (talk) 21:38, 8 June 2017 (UTC)[reply]

Probably didn't explain myself clear enough.

• Checkboxes are the "inferior" solution, in my opinion. Relative context is lost if you uncheck, say you want a hotel that is close to attraction and has bars and massage nearby. I put my money on different icons for different type. With quality icons, everything seems easy to distinguish and no need to uncheck anything. It's up to debate which one is better, while both are easy technically.
• For the disappearing bar, it's because every "thing" on the map has its own zoom range, very customizable. Setting Groups to disappear and appear at certain level are too uniform. Some bar are better than others, and Niagara falls is way better than my local one. There is a default zoom, set at the zoom it's created in. For the disappearing bar, I created it at zoom 3 and didn't change the zoom range, too lazy my bad. More demo are added to NYC, zoom in and see. If nothing, clear cache and reload.
• You are very welcome to try to set zoom range, icons and random stuff, the map is a wiki and very easy to use/undo. Username is whoisthefairest, password is memememe.

Wkenmomo (talk) 23:45, 8 June 2017 (UTC)[reply]

My thoughts and notes

• Our dynamic maps I believe are by definition a Slippy Map.
• Emily Dickinson Museum in Amherst, MA doesn't show up simply because that listing in the Amherst article does not have coordinates for it.
• One option to see specific listings such as drink and not the others - uncheck various other groups in mapframe (under more details) that you don't wish to see.
• Multiple mapframes can be used on an article page for each section/type, through the use of group and show parameters as well as a main mapframe showing all.
• Marker icons can usually be clicked and information (usually name, an image and/or a description) pops up). Mouse over the marker icon and a name popup shows.
• We generally rely on numbered markers that appear on maps; however, with some extra work, one can actually overlay the number on a mapframe with an appropriate icon such as a zoo, museum or something else. Putting those icons in a separate group which unchecked can disappear and the numbers will show for reference with matching entry on an article page.
• The geo map - I would expect to disappear in the future with something else replacing it.
• Markers with + symbol etc. don't bother me in the least. I normally do not look at maps covering large areas where this would normally occur. (ie. I don't think I would try to find a bar in Boston and one in Los Angeles at the same viewing)
• Maps can contain more than what is listed on an article page by using maplinks which could have class=no-icon and text="" as parameters - with some other kind of icon being drawn.
• More entries (listings) can be added to a map through transclusion from another page as well.
• Important places can be accentuated on a map by placing a filled in colored star beneath/underneath the marker icon or stand alone.
• Places on a map that show no label can also have text drawn on the map.
• and probably other realities/possibilities...
• Shouldn't all these discussions on maps etc. be somewhere else?

Cheers! -- Matroc (talk) 07:42, 11 June 2017 (UTC)[reply]

Hello Matroc, you are the expert! I see that Kartographer is powerful and suits wikivoyage well. Didn't know that from trying to edit. And I agree that this discussion should be somewhere else. Wkenmomo (talk) 18:35, 11 June 2017 (UTC)[reply]

Wkenmomo - I am in no way the expert!; far from it! There are lots of issues that have not been resolved and some nuances exist about using Kartographer that can make one's stomach churn. I plug away at map issues to see if some problem could be resolved. Unfortunately; at this present time, one would have to do actual coding to resolve them (some of which is neither elegant nor simple). In no way would I expect users/editors to do lots of coding in Wikivoyage; which a basic reason why we use templates, Visual editor, listing editor, extensions, modules etc., thus hiding the multiple complexities that are under the covers (under the hood so to speak) and allowing time for more valuable editorial content input. -- Matroc (talk) 20:13, 11 June 2017 (UTC)[reply]

I have created my very first self-made district map and saved it in my sandbox on Wikimedia Commons. I am quite happy with the result now and it is already used on the Kuala Lumpur article. So is there a proper place to save it in Commons? In the example they use a subfolder called neighbourhoods. Maybe there? Thanks! --Renek78 (talk) 07:21, 6 June 2017 (UTC)[reply]

Assuming it is your own work and you are happy to provide it with a creative commons license you can just upload it. No questions asked :)

There are no folders as such in Commons, but categories. Have a look at Category:Kuala_Lumpur and see if any are suited to your map. --Andrewssi2 (talk) 07:28, 6 June 2017 (UTC)[reply]

Thanks Andrewssi2! Moved the map now to c:Data:Kuala_Lumpur_Districts.map and tried to add it to the category Maps_of_Kuala_Lumpur with help of the little plus button at the bottom of the page. But then I get a syntax error ("Cannot add wikitext to Map.JsonConfig").--Renek78 (talk) 10:42, 6 June 2017 (UTC)[reply]

Seems that is because it is data. The media (images etc.) have a separate description page where you can add the category, which the data pages seem not to have. I suppose there is some other mechanism for organising this kind of pages, but I do not know it. --LPfi (talk) 16:51, 6 June 2017 (UTC)[reply]

I haven't seen any way to organize data pages yet. There was some discussion at Wikivoyage:Travellers'_pub#Wikivoyage_district_maps_using_Wikidata above about using Wikidata ids and/or including Wikivoyage in the name. Wikidata id's are easier for cross-language use (names can change from language to language but the id's won't). Including "Wikivoyage" makes it more clear that it was created for this project. But it would be good to hear more opinions on this. -Shaundd (talk) 05:27, 7 June 2017 (UTC)[reply]

I don't really understand the wikidata id thing. So you mean use the wikidata id in the title? or add the file to the wikidata element? And in the example above, which wikidata id? The one linked to the Kuala Lumpur city article?

I am having the same problem as I have created a map, that I would like to add to some of the Singapore maps with the train lines (c:Data:Sandbox/Drat70/mrt_singapore.map) but I'm not sure under what to save it. Drat70 (talk) 06:58, 7 June 2017 (UTC)[reply]

But in order to get Wikidata ID's we have to draw the outlines in OpenStreetMap, Shaundd. In case of Kuala Lumpur that does not make sense, because the official boundaries are for sure different. So it is useless information in OSM. We really have to draw the outlines manually in situations like that, I suppose. I understand your concern with the links, though (Drat70, in the KL map, if you click on the coloured surfaces, you get the hyperlink to the article). They will unfortunately only work for the English Wikivoyage page.--Renek78 (talk) 08:19, 7 June 2017 (UTC)[reply]

Sorry, I should have been more clear. I meant include the wikidata ID in the name (title) of map -- for example, Kuala Lumpur has a wikidata ID of Q1865, so the data page name could be "Wikivoyage Q1865.map". But there hasn't been much discussion about how to name and organize the files on Commons, so if you agree/disagree/have other ideas, it would be good to hear. For things like train/rapid transit lines, I'm not sure. There still might be a Wikidata ID but it could be hard to find. Maybe it's better to go with a descriptive name like Singapore MRTmap or Wikivoyage Singapore MRT.map?

Your point about the hyperlinks is a good one. To me, it would be ideal if the commons map just held the coordinates for the shape, and then colours, links, etc. are added on each wiki (like we do with shapes that come from OSM). It doesn't seem to work like that right now. -Shaundd (talk) 04:26, 8 June 2017 (UTC)[reply]

You could compromise on both: "Wikivoyage Q1865 Kuala Lumpur.map" WhatamIdoing (talk) 16:14, 8 June 2017 (UTC)[reply]

@Renek78, Drat70, Shaundd, WhatamIdoing:

I am against storing complete maps like c:Data:Kuala_Lumpur_Districts.map on Commons. First, it would not allow us to customize styles (boundaries, colors) on Wikivoyage. Second, district boundaries are needed in two contexts, i) map of the whole city with its breakdown into districts; ii) map masks in individual district articles. If the whole map is stored as a single data file, it becomes very difficult to access boundaries of individual districts.

In Russian Wikivoyage, I developed the following scheme that is essentially based on three tools:

• i) Module that retrieves information from Commons and trims all the styling, thus leaving only the map boundary in GeoJSON format
• ii) Template:Geo that generates maps for individual district articles. It uses the boundary= parameter that can be either Wikidata ID, or Commons Data file, or even map boundary stored locally
• iii) Template:Regionlist generates city map with all districts shown at the same time. District boundaries can be specified using same three methods (Wikidata ID, Commons Data file, local storage).

If you need an example, check the Prague article.

I believe that this way is more natural and efficient than what Renek78 did recently for some of the city articles here (Munich, Moscow, etc)

Regarding the names of Data files on Commons, I am strongly opposed to names like c:Data:Kuala_Lumpur_Districts.map, because such maps will be scattered all over the place, and they have no obvious connection to Wikivoyage. Sooner or later someone will try to re-draw such maps saying that administractive districts should look differently. Therefore, 'Wikivoyage' prefix must be in the name. As a test, I created c:Data:Wikivoyage-Q616334_Prague-Vysehrad.map, as proposed above, but I don't like this name for two reasons. First, spaces, hyphens, and underscores are always confusing, and even a single editor can never use them systematically, so long names are better avoided. Second, there are lots of spelling ambiguities, and at some point someone will surely try to rename Prague into Praha or something like that. Since we rely on these filenames in our templates, we should make sure that they are as robust and unambiguous as posslbe.

Altogether, I will go for the simplest naming scheme, Data:Wikivoyage/Q616334.map. If we do it this way, all Wikivoyage-related files can be easily retrieved using the 'Wikivoyage/' prefix, they will form a well-defined 'manifold' of Wikivoyage-related data files, and Wikidata ID is something that nobody can dispute. After all, this is Data, not image or article. You do not ask why Wikidata item is called simply Q616334 and not 'Q616334-Prague-Vysehrad-administrative-district', right? --Alexander (talk) 09:44, 27 July 2017 (UTC)[reply]

I see where you are coming from. However, I don't fully agree with your naming scheme. Sometimes I have maps with regions which don't have their own article yet, or simply don't need it (not enough cities inside), but I'll still want to add them to the map. In this case, they won't have a wikidata element. Furthermore I really think that if we go with the wikidata ID in the name, we should still add a readable name, if not it will be a hassle to find specific maps. Drat70 (talk) 13:15, 27 July 2017 (UTC)[reply]

So, we have Wikidata items named like Q12345, and we do not have problems finding them, because they are linked to Wikipedia or Wikivoyage articles, and because each item has a description field. Same here. Each data file on Commons is a map of something in Wikivoyage, so it can be (and should be) found via Wikivoyage. Additionally, each data file should contain a description. If you want to find something by name, simply search through the descriptions. This page will give you an idea of what searching through page names looks like. It works when you have 100 pages, but with thousands of pages it becomes a mess.

As for the second comment, I do object creating boundaries for regions that do not exist. First make sure that region or district are meaningful, then start an article, then draw the boundary. --Alexander (talk) 17:09, 27 July 2017 (UTC)[reply]

Alexander, let me explain a bit more about what I meant with that second comment. I believe, it doesn't make sense to create empty articles just for the sake of having them. For instance I have been working on the regions of Switzerland, and it makes sense to split up the articles into regions. See for instance Western Switzerland or Northwestern Switzerland. Some of those regions have just one or two destination, and the region article itself doesn't have much content, so I strongly object creating another layer of hierarchy for this, as this will just lead to more empty region articles. In due course some of those might get their own subregions (as in the example of Western Switzerland, I do think they are needed) but in others they might never be needed or make sense (as I think is the case with Northwestern Switzerland). In either way creating new subregions as articles at this point is in my opinion counterproductive. However, it is still useful to mention the different subregions (for instance political subdivision or geographical subdivisions) in the region, as this will make it easier for the traveler to orientate within the region.

So I'm not against using the wikidata ID in the name (which will make the naming clearer of course), I am just concerned what to do about this kind of cases. Drat70 (talk) 00:52, 28 July 2017 (UTC)[reply]

I still do not understand. Do you mean that a region article will have the {{regionlist}} template with some sub-regions but without links to any of them? I don't think this was common here, and I am not sure it is really needed. When we have a different cultural region, it merits its own article. On the other hand, formal administrative boundaries (e.g., those within Switzerland) are of little relevance to traveling.

Anyway, as long as we are talking about administrative regions or some other official things, they may not have their articles in Wikivoyage, but they do have articles in Wikipedia and thus Wikidata items as well. Therefore, no problem about them. Moreover, such regions have their boundaries on OSM, and all you have to do is connecting to OSM via Wikidata. You won't need a separate data file on Commons. Just provide the Wikidata ID, and the region will appear on the map.

Commons data files are needed only for those regions that we "invent" ourselves based on the pure traveler's perspective. Do we plan to invent regions and not write articles about them? Isn't it too much? --Alexander (talk) 07:58, 28 July 2017 (UTC)[reply]

I think having regions on the regionlist without having links can still be useful to the traveler. It can make the article more organised, and also allows the travelers to see which cities are close by. Look for instance on what I did in Valais. The subregions are not administrative ones, so I won't find the shape on OSM. Now I would argue it's still useful to have those regions, there are small differences between the regions (language for one, but also landscape etc) and between the east and the west the distance is roughly 150 km, so it is in my opinion useful to have those 'subregions' just to know what's nearby. Also those are regions used by the locals (and not just made up ones) and while going there, those are names that one is very likely to encounter. However, I don't think I would create articles on each of those regions, as that would make the hierarchy unnecessarily convoluted and as there would be a lot of repetition throughout the three articles.

Another place were I had issues with using OSM provided shapes is when I had to draw regions made up of several districts or such. Look at Region Berne for instance. Since the regions consists of several districts, lines get shown inside the region, whereas I only want the outer perimeter. But maybe that one is just me not properly understanding the technical stuff and there is a solution to this? Drat70 (talk) 08:26, 28 July 2017 (UTC)[reply]

Thanks for explaining! I see the point. But there are a few things I should mention. Let's take Region Berne as example.

First, since your sub-regions belong to Region Berne (and do not belong anywhere else), I would associate all of them to Q14206487, perhaps with a suffix, like Q14206487-1.map or Q14206487-region1.map, or something like that. Or you could use names, and maybe it's not a problem in multi-lingual Switzerland, but in multi-lingual parts of the former Soviet Univion there are endless discussions of whether Kiev should be Kyiv, Gomel should be Homel, and so on. And there are different English spellings of non-Latin characters. I had so much trouble with that...

Second, the lines inside the region are a problem indeed. There is no easy solution, but there is a workaround. You can reduce the stroke-width or even remove the lines completely (see Central Moscow and Prague for examples), and maps will look better. An ultimate solution is merging several polyhedra into one, but I have not seen any automatic tools for doing that. Writing one should not be too difficult, but it still takes time and requires some mathematical thinking.

Third (and it is more conceptual than the map issue), I very much appreciate your way of organizing the regions with these smaller subregions, it is miles better than creating lots of stub articles, but I am not sure it is the best way. For example, what does East Fribourg stand for, and why are there no points inside? Suppose I want to travel to this sub-region, where do I get info beyond the blurb in the {{regionlist}}?

It is in fact a much broader question of how to organize regional articles. I think that constructing regions based on the number of existing articles is not a good idea. If you know the region, it is better to think ahead and decide which articles will be potentially needed for a decent coverage. And let them stay as red links. In Russian Wikivoyage, we do it a bit differently, because we provide descriptions of individual cities in regional articles. Check, for example, the Usti district of Czech Republic. It's all red links, but there is plenty of useful content for anyone who wants to travel there. In English Wikivoyage, same area is organized into North Bohemia with loosely defined borders and two sub-parts, Usti district and Liberec district. You can, of course, draw these two districts on the map without creating their articles, but why not creating the articles and removing North Bohemia as redundant?

So, coming back to the Region Berne, I am sure there are more than 4 places to visit and write about. If you make a list of all places that deserve an article, it may turn out that creating 2-3 sub-regions articles, or even restructuring the whole thing, makes a lot of sense. And East Fribourg could be an article of its own, not a region but a sort of bottom-level article covering a certain area. --Alexander (talk) 10:59, 28 July 2017 (UTC)[reply]

Thanks for your reply! Keeping the ID of the parent region with a index is indeed a good solution I didn't think of. That would definitely be a solution to the problem I mentioned

As you say the whole subregion thing is not really that much related to this, and as such we probably shouldn't go too much into this here. If it is a problem down the road, we can discuss it at a different place, maybe in Wikivoyage:Geographical_hierarchy.

As you noticed a lot of the regions in Switzerland are far from done, and the example of East Fribourg you state is a good one. The subregions are mostly by state borders. The specific state (Fribourg) has been split up into two regions because of the language border which goes through it, hence we get the a bit weird East and West Fribourg. This is all work in progress, and one of the main reason of mapping out the regions the way I did is to allow me (or other contributors) to come along and see where there is places where there are destinations still missing. If after looking more into it, there are indeed only 4 destinations in the whole Region Berne, then I'm going to remove the subregions as there won't be a point to having them.

But to illustrate my point about subregions not necessarily needing their own page, you can look at Valais. I've put much more work into this region, as it's my home region and I would say that it's now at a point where most of the major destinations have an article and are on the map. The subregions don't need their own subregion page, because there is not much more information specific to that region than what is already said in the main Valais article, but I also wouldn't want to take out the subregions, because they help structure the destinations list. If they are not there, it's just going to be one big list, which in my opinion is much inferior aesthetically and from a readability point of view to the way it is presented now.

Also thanks for your input on the problem with the lines in the regions, I'll play around with the stroke widths as you suggested. Drat70 (talk) 13:57, 28 July 2017 (UTC)[reply]

Yes, sorry, I forgot to say that Valais is a very good example of a regional article, where such split of destinations makes perfect sense. --Alexander (talk) 19:33, 28 July 2017 (UTC)[reply]

Hi Alexander, your way to create maps might be better, but it is too sophisticated for me. Could you give us a step-by-step explanation?

Styles like surface and line colors can still be changed by editing the GeoJSON on Commons. Changing the contours is not so straightforward, though. But hopefully in the near future an editor similar to http://geojson.io will be introduced right in Commons.

I don't have an opinion on the naming convention. Don't really mind, to be honest. --Renek78 (talk) 15:53, 27 July 2017 (UTC)[reply]

Which part is unclear? One module and two templates should be copied to English Wikivoyage. Then you have to specify the boundary= parameter as boundary=Q12345 (Wikidata) or boundary=Wikivoyage/xxx.map (Commons). That's all, I think. --Alexander (talk) 17:09, 27 July 2017 (UTC)[reply]

Understood it now. But I think neither your nor "my" way are perfect solutions. Example: Drat70 and I were recently iterating the districts of Singapore. Two of the district borders were extended in size, a third one reduced by the same amount. According to your approach you had to go in each of the 3 separate district shapes and update them separately without being able to see the border of the neighbouring district. How can you make sure, that they are properly aligned?

I am talking about storing and retrieving district boundaries, not about drawing them. If you want to match boundaries of several districts, you should draw them all together using geojson.io or a similar service. An even better way is drawing lines instead of polygons, and then merging the lines into a district boundary. This way, two adjacent regions will have exactly the same joint boundary. I did this for Central Moscow, but it's a more lengthy procedure. --Alexander (talk) 23:52, 27 July 2017 (UTC)[reply]

Sorry for missing this conversation, I've been travelling and not paying much attention to WV. I agree with Alexander, in both the naming convention and keeping maps to a single district (or region). A reason I prefer this approach is if there are separate city maps and mapmasks, it means you'd need to change the boundary definition twice if the boundary ever changes (which they do!). People move on or forget there is a second map and so it increases the chances the maps aren't the same over time. I wasn't aware you could style the shapes saved to Commons the same way you can style OSM shapes, so that is good to know.

Alexander, with the regionlist template you linked to above, how does that work with static maps? If I follow the logic, if a static map is input for the map name, then it displays the static map, otherwise it looks for data for a dynamic map -- is that correct? -Shaundd (talk) 04:55, 1 August 2017 (UTC)[reply]

Yes, it's correct. --Alexander (talk) 07:56, 1 August 2017 (UTC)[reply]

Swept in from the pub

Hi all, I would like to use a map saved on Commons to mask everything outside the district boundary. For example this map - C:Data:Sandbox/Renek78/test.map. Everything, which is outside of the green polygon should be greyed out, i.e. the map should look like in this example. The green part should be a "normal", transparent map. In the documentation for the map module there seems to be a parameter called "data", which seems to do exactly that. But I don't know how to use it. Anybody has an idea?--Renek78 (talk) 12:27, 2 July 2017 (UTC)[reply]

The answer to your question is here, but you will have to call data page from Commons instead of the map boundary stored under {{Boundary/{{FULLPAGENAME}}}}. --Alexander (talk) 19:27, 2 July 2017 (UTC)[reply]

Swept in from the pub

In this map I noticed the caption "Tom" and "Kelly" which I am quite sure shouldn't be there. (you can only see these captions only by displaying the map with the Mapnik or Relief map layers)

How can we remove those captions? ויקיג'אנקי (talk) 03:15, 12 July 2017 (UTC)[reply]

The maps are from OpenStreetMap and anyone can edit them on that site. I'm not sure how often the Wikimedia server is updated from OSM. K7L (talk) 03:56, 12 July 2017 (UTC)[reply]

I would be careful with that. Are you from that region and know for sure that these hills (and yes indeed there are two hills) are not named like that? I imagine there are various examples out there where you would think they are vandalism. Words create reality, who is going to judge? Ceever (talk) 11:07, 12 July 2017 (UTC)[reply]

This article currently includes a map of all of Downtown Shanghai but would be better with a map of just the district. Anyone care to volunteer? Pashley (talk) 15:55, 20 November 2017 (UTC)[reply]

Our article covers what is shown in green on the current map. The official administrative Huangpu District includes that plus Shanghai/Old City which gets its own article plus Luwan (just to the west) which we cover in Shanghai/French Concession. I'm not sure how that might best be handled on a map. Ignore the official boundary since the text covers that? Show Luwan & Old City in another colour? Pashley (talk) 16:02, 20 November 2017 (UTC)[reply]

Swept in from the pub

Yesterday the voting process to select the most important community wishes started. You can help to bring the Kartographer improvement into a good position by your own vote for Kartographer. I hope that we will have enough votes to continue the work on the Kartographer. --RolandUnger (talk) 07:32, 28 November 2017 (UTC)[reply]

Thanks, Roland, for taking care of this. Let me emphasize that Wikimedia Foundation stopped the development of Kartographer. This vote is our only chance to change their decision and draw attention to the technical features that are relevant to Wikivoyage. Every editor who reads this, should go to meta and vote. If you think this is something unrelated to you, maps will never improve. To compete with bigger projects pushing forward their favorite features, the full support of the whole Wikivoyage community is needed. --Alexander (talk) 08:43, 28 November 2017 (UTC)[reply]

Hi everyone, I'm the Product Manager for the Community Tech team. I'm really glad that you all are excited about voting for this on the Community Wishlist Survey; this is definitely the kind of thing the Wishlist Survey is for.

I want to make sure that the folks here know what the survey can do. The Community Tech team is responsible for investigating and addressing the top 10 wishes in 2018. If the Kartographer proposal is in the top 10 at the end -- and it's got a strong early lead :) -- that means it'll be one of the 10 projects that our team works on next year. We'll investigate all of the feature requests and bugs that are listed in the proposal and in the discussion, and we'll report back on which pieces we'll be able to work on this year. It won't be just a couple of bugs; we'll want to do something substantial.

But I want to make sure folks know: this vote is not going to bring back a dedicated Maps product team. Roland suggested that this work might take a year or two, and that's beyond the scope of what the Community Tech team can do. I don't want to discourage people from voting, because we'll definitely be able to help; I just want to make sure folks won't expect a full-time dev team working on Kartographer. Let me know if you've got any questions. Thanks! -- DannyH (WMF) (talk) 00:16, 29 November 2017 (UTC)[reply]

Swept in from the pub

The aforementioned article has a mapshape that looks interesting, certainly, but is of little help to travelers. User:ThunderingTyphoons! has tried to fix it - to no avail. I therefore call on the collective brainpower of my fellow wikivoyagers to solve this issue! Hobbitschuster (talk) 13:55, 30 November 2017 (UTC)[reply]

I challenge anyone to give it a better go than I just did. It just can't be done. --ThunderingTyphoons! (talk) 14:31, 30 November 2017 (UTC)[reply]

Looking at the mapmask, I saw a big jump "37.7280,127.5617 |38.0141,128.0299", and looking at the picture, I expect that there are others. There also appear to be some duplicates. AlasdairW (talk) 15:39, 30 November 2017 (UTC)[reply]

I will check my old files on my PC but I think I provided a new set of coordinates for someone for Chuncheon in the Spring of 2017 (took several hours to correct). Was previously mentioned on an older Travellers' Pub page. -- Matroc (talk) 21:41, 30 November 2017 (UTC)[reply]

Checked notes - not exactly sure but I believe OSM was asked to check Chuncheon coordinates or wait a bit as sometimes an OSM update might fix the issue. Can use <mapframe> directly with "type": "ExternalData", "service": "geoshape" and "ids": "Q42148" OR the mapframe template with geomask and wikidata parameters as Drat70 has already done. -- Matroc (talk) 01:57, 1 December 2017 (UTC)[reply]

New note - I retrieved the coordinates from OSM for Chuncheon and created formatted (1200+) coordinates for use with {{Mapmask}}. I placed that info on the Chuncheon Talk Page -- Matroc (talk) 09:04, 1 December 2017 (UTC)[reply]

As a temporary fix I added a new mapshape, which refers to the wikidata element of Chuncheon. On a first glance it looks identical to the one previously in the article, but we can of course go back to listing the coordinates in the article once somebody manages to fix them. Drat70 (talk) 00:53, 1 December 2017 (UTC)[reply]

Actually, usage of wikidata for this is quite a great solution in my eyes! I'll definitely use it in future (unless it "violates" some rules, similar to the one disallowing inline wikipedia links), much better than trying to re-invent the geo-boundaries... Would be great if the listings would support gathering image+coords from wikidata, too. Andree.sk (talk) 08:34, 5 December 2017 (UTC)[reply]

Have you seen the "update shared fields from Wikidata" button in the listing editor? Hobbitschuster (talk) 16:54, 5 December 2017 (UTC)[reply]

Actually, I rarely use the listing editor, so I didn't - thanks for the hint! But in any case, my idea was that it would suffice to enter something like { {listing|wikidata=XYZ} } (instead of copying the data). Andree.sk (talk) 08:06, 6 December 2017 (UTC)[reply]

There are actually some arguments against doing this (if you search for it, I think there has been previous suggestions along those lines) for instance that the coordinates on wikidata are not always correct and even if they are, there might be different needs here. For instance if it's a big park or something, wikidata will probably show the centre whereas for the traveler it might make more sense to know where the entrance is.Drat70 (talk) 09:30, 6 December 2017 (UTC)[reply]

Should this page have a banner? Hobbitschuster (talk) 19:02, 16 January 2018 (UTC)[reply]

Why not. Have added one but people are welcome to find something better. --Traveler100 (talk) 19:17, 16 January 2018 (UTC)[reply]

Would anyone be able to help with a map of host cities in this article? The map imported from Wikipedia doesn't work. Thank you. Ground Zero (talk) 13:50, 20 March 2018 (UTC)[reply]

Swept in from the pub

• Recently I have been working on a template and module that allows one to create a single mapframe or a single maplink that actually draws a shape such as a cirle, cog, cross, star, boxframe etc. of varying colors and sizes to be displayed on a map.- This builds Kartographer code and does not replace any of our existing excellent templates and intended only to add to working with maps. These shapes can be output as a polygon or line in GeoJSON. In addition, there is the capability to place a Maki icon (GeoJSON Point - pick your color and symbol) on a map using maplink. One can also create a maplink that does not appear on an article page and is hidden though its marker (Maki icon with image and description) will appear on map. One can create a mapshape from OSM using a wikidata id or bring in a page from Commons. This also uses the group and show parameters (Helps keep things together). See: User_talk:Matroc/Mapdraw2 if interested. -- Matroc (talk) 00:30, 15 January 2018 (UTC)[reply]

Very interesting. I think one of the common use cases for this will be to overlay a map with lines (metro lines or key roads), and it will be best to do this via OpenStreetMap data directly rather than generating a custom file each time (as you did for Israel Highway 1). Could you put together an example where this is done? Ar2332 (talk) 07:38, 15 January 2018 (UTC)[reply]

We don't access OSM directly but rather through Wikidata using an id to find an entry. In the Wikidata entry the OpenStreetMap Relation identifier is used to access OSM. No Wikidata entry found by id or no OSM Relation identifier in the Wikidata entry then basically out of luck. (I doubt very seriously that one would find many metro lines or key roads available in Wikidata; even fewer with an OpenStreeMap Relation id). I did manage to find one instance (after searching wikidata)Trans-Siberian Railroad which is not really inadequate for the Trans-Siberian Railroad article in Wikivoyage. We had used at first GPX files and then the idea came about to create data files in Commons to produce GeoJSON needed and usable by many. (I think even this may now be under some contention?). In some cases, users have created the data needed and entered/coded them within a particular article page by hand. To check out streets and roads closer, there are external maps available that might assist as well. -- Matroc (talk) 06:24, 16 January 2018 (UTC)[reply]

Metro lines might be doable. I checked OSM and it had the Wikidata IDs for Vancouver's three rapid transit lines. Using {{mapshape}} and type=geoline, I was able to add the two lines that pass through downtown Vancouver to the Vancouver/City Centre map. But yeah, it requires the OSM Relation identifier for the metro line (or highway) to have the corresponding Wikidata ID entered in OSM, so it may not work very often.

GeoJSON data files can be stored on Commons, but the source of the data needs to be in the public domain... which is hard as OSM data is licensed under the Open Database License and most countries (other than the United States) license their data under an Open Government License. -Shaundd (talk) 06:52, 16 January 2018 (UTC) -- Thanks Shaundd - Matroc (talk) 09:01, 16 January 2018 (UTC)[reply]

Works great! Most metro lines in the world do seem to have Wikidata IDs and OSM paths already, and the two can be linked where necessary.

Is there a way to change the color of the line? Stroke and fill attributes didn't seem to work... Ar2332 (talk) 07:31, 16 January 2018 (UTC)[reply]

I would leave a note on the Talk page for Template:Mapshape and ask if parameter stroke' could be added. -- Matroc (talk) 09:01, 16 January 2018 (UTC)[reply]

Swept in from the pub

What's up with this map that has popped up in articles like rail travel in the US lately. It seems like a partial copy from Google Maps has a pretty low resolution and some weird artifacts. Should it be kept, improved or removed? Hobbitschuster (talk) 16:55, 20 January 2018 (UTC)[reply]

The file seems to be a screenshot of this page, which is directly referenced in the item description. Copyright is most likely not an issue: WikiVoyage, Wikidata and Wikipedia are the referenced sources and the site itself seems to be a tool linking to Wikimedia data. I'd rather see the page itself linked to and the screenshot made into a proper map file if the author is okay with that. The author posted an announcement on their facebook page four hours ago for this project, and I therefore assume the uploader of the screenshot (User:Jkan997) is them.
-- Wauteurz (talk) 17:33, 20 January 2018 (UTC)[reply]

Hi folks - Wauteurz - are right, the map is preview of the interactive map with content on CC licenses ( + OSM background). It has nothing to do with Google Maps. Regarding the look - I am open to suggestions what to change - the idea of the map is to give impression what use will able to find on interactive map. Nevertheless there are elements of the map that even without going to interactive map - Alaska Railways, some minor systems (ie. Metrolink in LA) and in case of longer relations it possible to read relation by color code from map (ie. California Zephyr, Southwest Chief, Sunset limited). If there is no better map I suggest this one to be left on the article.

--Jkan997 (talk) 20:08, 20 January 2018 (UTC)[reply]

The original map found under the link is useful. The screenshot less so, as it is too general for the shorter range systems and contains too many unexplained symbols (including no meaning for the colors being given) for an overview. Maybe the whole thing could be transformed into a WV style dynamic map? Hobbitschuster (talk) 20:58, 20 January 2018 (UTC)[reply]

Thanks for feedback Hobbitschuster, Wauteurz - from technical perspective it is not possible to include interactive map to article (too big dataset). Also right now map has train list, but it will also include features like filtering byt train type (sleeper, intercity, commuter, toursist). Generaly ShareMap Traveler site is intended to be what ShareMap is for wikipedia - geospatial enviroment. Maps contains a lot of Wikivoyage data and links user back to Wikivoyage so it can be treated as just different way of displaying Wikivoyage. I agree you that the map itself does not contains too much value without description. So I can suggest two solutions

Use direct interwiki link with thumbnail

PROS: user see what he will see after clicking

CONS: user can be little misleaded that he will redirected from WV site (however because this is inter wiki not external link this is permitted from Wiki rules perspective)

Use textual link

Interactive map of Trains in North America

PROS: small, non intrusive

CONS: Can be easily skipped and user will not see informations.

Use image with Interwiki link in description

PROS: user see what he will see after clicking

CONS: after clicking on image (not link) user will see the enlarged image that is not very useful.

Waiting for your comments. --Jkan997 (talk) 11:49, 21 January 2018 (UTC)[reply]

I tend to agree with Hobbit. As you might know, we have our own dynamic maps here on Wikivoyage, and I think that I speak on behalf of most of us when I say that it's better to work the information given into one of those maps and leave a link to the ShareMap in Rail travel in the United States. Placing a link to the ShareMap on every article in the US that has a rail connection is very much unnecessary. If you must link to it, give the articles of cities and towns along the lines a Routebox and link Rail travel in the United States from there. Information about the running stock and whatnot can be listed in there as well, as is the case in Rail travel in the Netherlands#Trains and rolling stock. The biggest stations can be listed as {{marker|type=go|}} to give the reader a sense of location. I think the best option is to simply link the ShareMap in Rail travel in the United States#Further reading.

Also, a small sidenote: redirecting from enWikivoyage or any WMF site for that matter to ShareMap as you describe in your first stated option is not an interwiki link. Interwiki links refer to links between WMF projects, so enWikivoyage to nlWikivoyage or enWikipedia to deWikiquote.
-- Wauteurz (talk) 19:07, 21 January 2018 (UTC)[reply]

Thanks for your comment Wauteurz - for clarification ShareMap is interwiki (there are two types of inter wikis foundation and non foundation sites). There was long acceptance process to include it interwiki list. Regarding Netherland map - the thing that is missing on for me on NL map are lines, I know that they can added on dynamic maps - and this can work for smaller countries, but for US the shape will be too complex. Also I agree for you that including map in every city with rail station will not make sense--Jkan997 (talk) 21:15, 21 January 2018 (UTC).[reply]

Alright, I am not saying that Rail travel in the Netherlands needs a likewise dynamic map. It might be a good addition, but it is by no means necessary. What I meant was:

• The information on the ShareMap is best to be included in a dynamic map on Rail travel in the United States. Here, you can leave a link to the ShareMap under #Further reading.
• Information about the trains in service can be included in that article as well, in a new section called Rail travel in the United States#Trains and running stock. An example of which can be found on Rail travel in the Netherlands#Trains and rolling stock.

I hope this clarifies.
-- Wauteurz (talk) 09:25, 22 January 2018 (UTC)[reply]

Yes this clarifies a lot - thanks Wauteurz for your feedback --Jkan997 (talk) 10:45, 22 January 2018 (UTC)[reply]

Swept in from the pub

I noticed that the map markers disappear from the mapframe window after a short time, when using MS IE (version 11.0.51). No problems in Chrome and Firefox. --FredTC (talk) 11:10, 4 March 2018 (UTC)[reply]

There are still people who use Internet Explorer? Hobbitschuster (talk) 21:51, 4 March 2018 (UTC)[reply]

Now the problem has disappeared. There is a recent change in the way the contents of the mapframe window are shown. It now goes in two phases, where for some time in IE the second phase made the markers disappear. So the change was introduced without proper testing with all browsers. --FredTC (talk) 08:07, 5 March 2018 (UTC)[reply]

Swept in from the pub

Over the next four months, the WMF Collaboration team will be making improvements to the mapping program Kartographer and related functions. The team’s engagement with maps was prompted in part by the overwhelming support the maps community gave the 2017 Community Wishlist proposal "Kartographer Improvements". The project, which we’re calling Map Improvements 2018, is focused mainly on making mapping software easier to maintain and, of course, on the main "wishes" in the Wishlist proposal. Please visit the project page on MediaWiki.org to learn more and share your ideas or questions. JMatazzoni (WMF) (talk) 01:03, 15 March 2018 (UTC)[reply]

Swept in from the pub

After a few days I will shutdown our maps.wikivoyage-ev.org server. We used it to support map development since December 2012. But most of the map tools developed by Mey2008 are no longer used and were substituted by the Kartographer tool set. There are several reasons for this decision: The operation of this server takes a lot of money we haven't any longer. That's why the members of the Wikivoyage association demanded to switch off the server and to use that money for other purposes. The other reason is that we have no programmers and administrators except me to support these tools. My time is limited, and Mey2008 and others stopped their collaboration in our project. But all the scripts will be saved.

There is a working copy of maps.wikivoyage-ev.org tools at tools.wmflabs.org/wikivoyage. That's why I changed today these URLs in MediaWiki:Gadget-ListingEditor.js‎ and {{GPX indicator‎}}. I will do the same at the other wikis. The wmflabs tool server is managed by Nicolas1981 and I hope that he will give some support. Please update the pages named in Link search.

I like to thank May2008, Nicolas1981, the members of our association and the WMF programmers who support Wikivoyage and the map tools. Now we take care of further development of the Kartographer tools. For instance, since a few days the zoom level 19 is available. And I thank you for your understanding. --RolandUnger (talk) 07:00, 23 March 2018 (UTC)[reply]

When you upload the source code, please let us know where, it could be useful Thanks! :-) I haven't touched this "wmflabs tool server" since years, and I am pretty sure the machine has been deleted. Syced (talk) 09:14, 27 March 2018 (UTC)[reply]

Swept in from the pub

When I click on "Edit listing", then a form shows up, I click on "find on map", but then no map shows up, the page is blank. Is it a bug or just my computer? Where should I report it? --Micru (talk) 09:07, 29 April 2018 (UTC)[reply]

I can confirm this, it also happens to me. Xsobev (talk) 09:54, 29 April 2018 (UTC)[reply]

Likewise. Multiple browsers, multiple OS, multiple computers, so the problem isn't at my end. --Robkelk (talk) 01:53, 6 May 2018 (UTC)[reply]

Swept in from the pub

As of today, interactive (Kartographer) maps no longer display in the language of the territory mapped; instead, you’ll read them in the content language of the wiki where they appear—or in the language their authors specify (subject to availability of multilingual data). In addition, mapframe, the feature that automatically embeds dynamic maps right on a wiki page, is now live on most Wikipedias that lacked the feature. (Not included in the mapframe launch are nine Wikipedias that use the stricter version of Flagged Revisions).

If you you’re new to mapframe, this Kartographer help page shows how to get started putting dynamic maps on your pages.  If you’d like to read more about map internationalization: this Special Update explains the feature and its limitations; this post and this one describe the uses of the new parameter, lang=”xx”, which  lets you specify a map’s language. And here are some example maps, to illustrate the new capabilities.

These features could not have been created without the generous programming contributions and advice of map-loving volunteers, including Yurik, Framawiki, Naveenpf, TheDJ, Milu92, Atsirlin, Evad37, Pigsonthewing, Mike Peel, Eran Roz, Gareth and Abbe98. My apologies to anyone I’ve missed.

The Collaboration team's Map Improvements 2018 project wraps up at the end of June, so please give internationalized maps and mapframe a try soon and give us your feedback on the project talk page. We’re listening. —JMatazzoni (WMF) (talk) 20:59, 9 May 2018 (UTC)[reply]

Swept in from the pub

As we here use w:Mercator Projection, polar regions are comparatively extremely distorted, which makes region articles like Antarctic Islands unwieldy. Is there some crutch to fix that with dynamic maps or do we have to draw static maps to avoid the issue? Hobbitschuster (talk) 00:56, 18 June 2018 (UTC)[reply]

Hobbitschuster, the best way to solve this is to increase the width of the map and decreasing the height of it. Check out the map on Antarctic Islands now, and you can see that it's much better than it used to be. Selfie City (talk) 16:35, 18 June 2018 (UTC)[reply]

It's conceivable that one may want to centre a map of Antartica on the South Pole. Only way to do that is change the projection, so in this case a static map would be entirely justified. K7L (talk) 17:10, 18 June 2018 (UTC)[reply]

Can't we just do a map thingy that automatically distorts other regions and keeps the poles undistorted? Hobbitschuster (talk) 21:34, 18 June 2018 (UTC)[reply]

No, not really. People have tried for hundreds of years to create a map projection that kept all the parts equal, and the only one that has truly worked is the globe, and that's 3D and for obvious reasons wouldn't fit on a webpage. Selfie City (talk) 23:54, 18 June 2018 (UTC)[reply]

I think the current map in Antarctic Islands is pretty dreadful—as Hobbitschuster says, it's extremely distorted. I think a map using a different projection, centered on the South Pole, would be better, which probably means a static map (like the one used in Antarctica). The Islands of the Arctic Ocean map has the same problem. —Granger (talk · contribs) 00:11, 19 June 2018 (UTC)[reply]

Well, the problem with that static map for Antarctica is that I need a mapmaker to change the coloring. Still, if you think you can improve Antarctic Islands, go ahead; I think for an OpenStreetMap there's nothing better that can be done. Selfie City (talk) 00:18, 19 June 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I know all maps distort. Which is why I say that we should use a map for the Poles that distorts the polar region the least. Such a map would obviously horribly distort the tropical region and the opposite polar region, but that doesn't matter for a polar map. Sorry for being a bit unclear earlier. Hobbitschuster (talk) 01:31, 19 June 2018 (UTC)[reply]

No, I don't think you were unclear, I'm just having a trouble envisioning that kind of map; I think static maps are a better choice, particularly for West Antarctica and East Antarctica. Selfie City (talk) 02:14, 19 June 2018 (UTC)[reply]

There are projections that work well for the polar region, just look in any atlas (OK, those are static). The question is whether our mechanisms for creating maps can use those projections. Is the Mercator Projection hard-coded? I suppose for polar regions you have to use truly polar coordinates, while it is easier to pretend the coordinates are Cartesian when you have a Mercator projection. Which, depending on implementation, means a dynamic map suiting the polar regions needs a lot of new code. You can still pretend you are using Cartesian coordinates, but instead of just changing offset and scale you have to transform the coordinates with trigonometrical expressions. --LPfi (talk) 18:31, 19 June 2018 (UTC)[reply]

Can we use a transversal mercator projection with a strip around the pole in the center? Hobbitschuster (talk) 18:48, 19 June 2018 (UTC)[reply]

De-facto online standard nowadays is the mercator projection - the tile server (used by Extension:Kartographer) 99% only renders those tiles, and the relatead scripts probably expect that as well. I'm no wikimedia guru nor spokesman, but I have a feeling that chances of spinning up non-mercator map service are practically zero. I suggest to just use or whatever... Andree.sk (talk) 21:29, 19 June 2018 (UTC)[reply]

Swept in from the pub

Just wanted to suggest considering implementing something we are implementing these days at the Hebrew Wikivoyage - there are currently over 200 mapmasks at hebvoy and they are all going to be moved from the main space to "map:" (מפה:) space. We decided this is necessary because they take up a lot of space and make it harder to spot articles that don't have a lot of text yet. ויקיג'אנקי (talk) 13:14, 19 June 2018 (UTC)[reply]

Swept in from the pub

The find on map of article Listing can not use, when I input coordinate to listing, and try click in find on map, but the Wikivoyage-GeoMap can not find!(Example)--Yuriy kosygin (talk) 05:21, 28 June 2018 (UTC)[reply]

One possible reason is the listing has an error. Most common one is using uppercase and not lowercase. For example change {{See for {{see. Although listing looks OK on page it will not work correctly in maps.--Traveler100 (talk) 05:27, 28 June 2018 (UTC)[reply]

@Traveler100: Also did not improve! Is it Wikivoyage-GeoMap damage?--Yuriy kosygin (talk) 03:24, 29 June 2018 (UTC)[reply]

Ok now I see the problem. On the article page clicking on the map top right shows the location. On the article page clicking on a listing number shows the location on a map. But editing a listing with the listing editor and pressing find on map in the editor does not work. I am not very familiar with the tool, maybe someone else can look at it. --Traveler100 (talk) 05:15, 29 June 2018 (UTC)[reply]

Perhaps one of the maintainers. @Atsirlin: looks to be active around here... :-) Andree.sk (talk) 07:21, 29 June 2018 (UTC)[reply]

Unfortunately, I have no idea how it worked before and thus can't really help here. --Alexander (talk) 10:23, 29 June 2018 (UTC)[reply]

I think the page= of URL have problem (No add page is normal display, but add page can not display)!--Yuriy kosygin (talk) 07:22, 30 June 2018 (UTC)[reply]

If this is an issue with the Wikimedia Maps service I'm happy to help file a task. Unfortunately I can't discern if that's the case at the moment. Zhuyifei1999, as a maintainer of the tool, do you have a moment to help look into this? CKoerner (WMF) (talk) 15:21, 2 July 2018 (UTC)[reply]

I see Blocked loading mixed active content “http://nominatim.openstreetmap.org/?q=Jiufen&format=xml” in the console. The tool on toolforge does nothing other than periodically updating its code from Wikivoyage e.V., so unfortunately I don't know how the map work exactly either, and why it has to load resources from OSM. @Mey2008: Could you look into this? --Zhuyifei1999 (talk) 15:52, 2 July 2018 (UTC)[reply]