Wikivoyage talk:Map Voyage Tips and guide

Contents

We never needed a Map policy before, because, well maps are so obviously useful to travellers that it is has never been a bone of contention before.

Now we have contributors getting quite upset about the presence of dynamic maps. Can we define a short policy that states our policy towards maps, including how we handle static and dynamic versions? Andrewssi2 (talk) 05:22, 9 October 2017 (UTC)Reply

Thanks, it is a good start. The sentence about static maps could be expanded. We should consider whether it is acceptable to have both a static and a dynamic map. I would suggest that any new static maps should use letters rather than numbers for POIs to avoid confusion with listing numbers / dynamic maps (maybe this should go elsewhere). AlasdairW (talk) 23:19, 9 October 2017 (UTC)Reply

The thing with the numbering on static maps vs listing numbers is a issue that I have been thinking about. I just started a discussion on that: Wikivoyage_talk:How_to_draw_static_maps#Static_maps_numbering_and_numbering_of_markers_for_dynamic_map. I think it probably should go there, as that's where I assume people will look before creating static maps. Drat70 (talk) 01:57, 10 October 2017 (UTC)Reply

Thanks for starting this. Regarding replacing static maps with a dynamic one, when the static map is not necessarily outdated, but just utter rubbish (like the one here and in some of its sub-regions), I propose it should be policy to put a dynamic map in its place, until such a time when there is a decent static map that imparts any worthwhile knowledge. As for who gets to decide which maps fit the criteria "utter rubbish", that should be discussed on a case-by-case basis and implemented when there is a consensus. --ThunderingTyphoons! (talk) 23:38, 9 October 2017 (UTC)Reply

Conversely, there are a couple of instances where it makes sense to use a static map instead of a dynamic one. One is article promotion to "Star" which still calls for "a tourist-style map, in Wikivoyage style with modifiable vector source, showing how to get around" a city. The other is an upper-level region (or country) where a static map is the clearest way to colour-code the individual subregions onto the land.

The same article having a static and a dynamic map existed at Adirondacks. I believe it was resolved by including the static map in-line but merely linking to the dynamic map. As far as I know, a parameter to "display this staticmap as alternate only where dynamic mapping breaks - such as printed hard copy, PDF, or web with Javascript disabled" used to be available before we switched to mw:extension:Kartographer but trying that now just displays both maps, cropping the static map if too wide instead of resizing it sensibly.

Removing a map entirely is reasonable if someone dropped a {{mapframe}} without providing any co-ordinates for any of the {{listing}}s. In that case, the dynamic map should be restored once we have any POI's to place on it. K7L (talk) 02:15, 10 October 2017 (UTC)Reply

Static maps should be favored over dynamic maps for all articles except bottom-level destinations (Huge City district articles and undistrictified cities), though dynamic maps are better than nothing in those cases. But in the case of bottom-level destinations, I would actually support proactively phasing out static maps in favor of dynamic ones, including in Star articles (whose prohibition on dynamic maps is long overdue for updating). Given the paucity of users who know how to edit static maps, and the propensity of businesses to open and close, for all intents and purposes a static map on a bottom-level destination article is outdated almost as soon as it's uploaded. -- AndreCarrotflower (talk) 03:02, 10 October 2017 (UTC)Reply

The traveller comes first. A map may be included when it is clearly useful to the traveller. If adding another map is clearly more useful to the traveller, then another map may be included. Sometimes one scale may be useful for context, and another for detail, and if one of these is static and the other is dynamic, then both types can be used. Other times some of the information may only be available on one type, and the rest on another. The map of North Wales mentioned by Thundering Typhoons above is an example of a map which is of almost no practical use at all. it gives almost no useful context, and about the same amount of practical detail. • • • Peter (Southwood) ^(talk): 05:48, 10 October 2017 (UTC)Reply

And yet, North Wales is a top level region within Wales, so if we make compulsory static maps on such articles a policy reality, then we have to either get more people creating better static maps, or we'll be largely stuck with what we've got. While I accept the arguments made that dynamic maps are not that great for showing regional divisions, at the very least it could be policy to add a dynamic map in addition to a poor static map, if not replacing. --ThunderingTyphoons! (talk) 09:24, 10 October 2017 (UTC)Reply

With some effort a half-way decent dynamic map (could be simplified somewhat) for North Wales can be created - I created one and put it on North Wales talk page. -- Matroc (talk) 04:11, 11 October 2017 (UTC)Reply

Future changes and embellishments for our use of Kartographer extension has been sort of put on hold because of WMF funding limitations and future requests etc. may not be addressed right away if considered at all. -- Matroc (talk)

"This is a draft policy." Please, no. Making this "policy" leaves it cast in stone and allows it to be used to impose a specific position in edit disputes. That inflexibility could become problematic as the capabilities of the various mapping tools evolve. Currently, it's possible to generate a dynamic map for a region article but these capabilities are limited and leave much to be desired. We therefore are prone to favour static maps for upper-level regions and "star"-level articles.

What happens if some subsequent version of the dynamic map software addresses these issues, and produces a usable region map? We will be stuck with policy which precludes their use. Instruction creep is difficult to roll back once it's been enshrined in policy. K7L (talk) 17:00, 10 October 2017 (UTC)Reply

What else would it be if not a policy? We don't just have random pages lying around in projectspace that don't describe either current, proposed, or outdated policies. Powers ^(talk) 19:54, 10 October 2017 (UTC)Reply

A policy also makes it clear where there is flexibility and where there is not. I hope the current wording makes it clear that there is a good deal of discretion in how you can use any kind of map. Where there is a preference for static maps in a particular article type then that guidance is fine. It doesn't set in stone that a Dynamic map may never be used in that article. Andrewssi2 (talk) 20:41, 10 October 2017 (UTC)Reply

WP tends to distinguish clearly between technical documentation and help pages (you can do something this way), essays (one person's opinion as to why to do it this way), jokes (we're only being sarcastic by saying to do it this way), guidelines (you should do it this way) and core policies (you must do it this way). The latter tend to be inflexible, and ignore core policy at your peril. Policy tends to be difficult to change once it's in place.

If we take a statement like "dynamic Maps allow you to specify an image to replace them with a static map when printing occurs" and enact it into binding core policy? That risks saying the editor must do things that particular way. Unfortunately, that statement is based on assumptions on the behaviour of the underlying software, which are wrong. The 'staticmap=' fallback does not display correctly so a policy requiring its use is creating issues, not resolving them. A help page at this point would be useful. A guideline? Depends on whether it's kept up to date. A binding policy? That could leave us bound to something which makes no sense as the mapping software evolves. At the moment, a dynamic map is enough for a small bottom-level region like Northern New York but not for something more complex like Atlantic Canada? If we make this "policy" today, will it still make sense tomorrow? K7L (talk) 12:44, 11 October 2017 (UTC)Reply

That point is correct. I'd like to make this short as possible, so such text should be removed if it rather belongs in a help page. Andrewssi2 (talk) 19:19, 11 October 2017 (UTC)Reply

I'm aware of WP's distinctions between different types of projectspace pages, but I don't see the relevance. WV has always had an intentionally simpler structure and hierarchy. Technically, we don't have any guidelines; we lump all sorts of advice and best-practices under "policy" for simplicity's sake. If K7L is suggesting we introduce a different type of page (such as "guideline") that's a major change to the site's administration and should be discussed widely. Powers ^(talk) 20:36, 11 October 2017 (UTC)Reply

Is there a good reason to capitalize "static map" and "dynamic map" in the article? I would say not, but I'm willing to consider counterarguments. Ikan Kekek (talk) 10:47, 10 October 2017 (UTC)Reply

There's certainly no grammatical reason. They're not proper nouns :-) --ThunderingTyphoons! (talk) 12:11, 10 October 2017 (UTC)Reply

Yes, that's my point of view, too. Ikan Kekek (talk) 19:56, 10 October 2017 (UTC)Reply

That must be the technical writer in me :) Static maps and dynamic maps are software components, therefore it made sense to me to capitalise. I don't have a problem to remove capitalisation though. Andrewssi2 (talk) 20:44, 10 October 2017 (UTC)Reply

Any other views on this? Ikan Kekek (talk) 21:27, 10 October 2017 (UTC)Reply

Not from me. Ibaman (talk) 23:02, 10 October 2017 (UTC)Reply

I don't care either way, as long as we're consistent in the usage. --Robkelk (talk) 14:32, 17 March 2018 (UTC)Reply

I'm not comfortable stating that dynamic maps are preferred for districts and non-districted cities. I understand the limitations of static maps, but at the moment they are the only way to get an aesthetically pleasing map that meets our guidelines for our best articles. Powers ^(talk) 20:39, 11 October 2017 (UTC)Reply

I think that a weaker statement that says that a dynamic map is fine would be better. How about "Suitable for a dynamic map". Which sort of map is better for these articles depends on the quality of the static map, and of the dynamic maps for that particular city. Generally I find that dynamic maps are technically better and more likely to be up to date, but I have found locations where the base map is poor and the text is only in the local alphabet. In a policy, we are probably best not to get too deep into the preference for static versus dynamic maps, except for countries having static maps. AlasdairW (talk) 22:28, 11 October 2017 (UTC)Reply

Agree both of you. Please change text accordingly. Andrewssi2 (talk) 23:13, 11 October 2017 (UTC)Reply

Strongly disagree. If anything, the original phrasing should be stronger, not weaker, and it's the "guidelines for our best articles" that need to be changed. See my comments above about static maps for bottom-level destinations being outdated as soon as uploaded. -- AndreCarrotflower (talk) 00:00, 12 October 2017 (UTC)Reply

I also think that static maps are much better at the moment. From my experiences traveling and using WV articles, I find it very hard to get around the current dynamic maps as they don't really show transport lines very clearly. Even at the highest zoom level I have trouble deciphering which station belongs to which line etc. and even getting the station name can be tricky. (See Seoul/Jongno for illustration). I've tried manually adding train lines and stations to a few articles (See Singapore/Riverside) which helps a bit in my opinion, but the effort to do that is not much less than updating an outdated static map. So for dynamic maps to be on par with static maps, at the very minimum we should find a way of including this kind of vital information.

Of course the advantages of dynamic maps are undisputed, and if in the long term we can bring them visually closer to what the static maps look now, then this is definitely the way to go. But as of now, even a 10 year old static map is in most cases much more useful to me than a dynamic map at the current state. So for now I agree, we should change the text as mentioned above. Drat70 (talk) 01:07, 12 October 2017 (UTC)Reply

Maps are used for more than just navigating around a city by public transit, and anyway it's a perfectly ordinary thing for a single article to have a dynamic map showing listings as well as a static one showing transport lines. (And for that matter, Commons has static maps of most municipal transit networks that can be readily uploaded here.) -- AndreCarrotflower (talk) 05:05, 12 October 2017 (UTC)Reply

But navigating around a city by public transport is a very important and essential feature of a travel map. I my experience, in big cities I've visited (in Europe and Asia) most travelers don't drive and having a map illustrating public transportation in combination with at least the most important roads and sights in a certain area is really important. (Which doesn't work with a schematic map of the municipal transit network alone, as those rarely are to scale). If I have to use two maps, one with the listings and one of the transport system, that is really quite bothersome. In the above mentioned case of the Seoul map, I ended up getting so frustrated with trying to get around using the dynamic map that I discarded it and just mapped out the sights I wanted to see on a paper map before heading out in the morning. That is to me a sign that the map doesn't fulfil its purpose at all. Drat70 (talk) 05:36, 12 October 2017 (UTC)Reply

I think we can agree that different maps are more useful for different purposes. The dynamic maps are useful for interactive browsing and quick location of points of interest. But in my experience, those functions are better served by commercial software like Google Maps (or Bing or Mapquest or Apple Maps), since the quality of their maps far exceeds ours. Where we excel is in creating tourist-style maps that show everything the traveler needs to see in one image, being able to move markers and labels around as needed to produce a useful, aesthetically pleasing map. A dynamic map with a swarm of overlapping pointer-labels that obscure important elements of the base map just isn't as useful for most purposes. Powers ^(talk) 21:00, 12 October 2017 (UTC)Reply

For most cities I find that the dynamic map is fine. I like the way that I can zoom in on any street, and that it is much more likely to show current eat and sleep locations. I do use commercial maps, but I like that way that dynamic maps are integrated with the article. In a few cities we have good static maps which show the see and do listings well (as these don't change very often), but this is very much the exception. I have also found a few cities in China where I think it would be better to have a static map, as the openstreetmap coverage is poor. I would be happy to see articles having both static and dynamic maps, and in some cases these could be complimentary - a dynamic map which (initially) shows the whole city and a static map of the city centre (or other focus of interest). AlasdairW (talk) 22:46, 12 October 2017 (UTC)Reply

I have a strong preference to Dynamic maps, but do respect the opinion the static map camp. I'm happy to just leave this ambiguous, or as AlasdairW suggests just allow both. Andrewssi2 (talk) 22:54, 12 October 2017 (UTC)Reply

I agree with you on the way to go forward. As we probably won't be able to agree on which one is better and as there are arguments for and against either option, I think we should leave it up for each article to decide on whether a dynamic map, a static map or both works best. This still means we should remove the statement "Dynamic map preferred" from this page and put something which leaves both possibilities on an equal standing, maybe "no guidance" like for the park article. Drat70 (talk) 00:59, 13 October 2017 (UTC)Reply

I'd also like to add that I do use dynamic maps in region articles as well, e.g. Central_Coast_(New_South_Wales). A static map would work better, but until one is available it is a pretty good stop-gap. Andrewssi2 (talk) 02:28, 13 October 2017 (UTC)Reply

I have added "Consider creating a static map which complements the dynamic map, for instance showing the main central sights and is placed below the dynamic map." to 'Should I replace a dynamic map with a static map?'. I think we should also say (not sure where) "Using multiple dynamic maps is technically complex and is best only done after discussion on the articles talk page.". An example of multiple dynamic maps is Roman Empire. AlasdairW (talk) 13:05, 13 October 2017 (UTC)Reply

I think the way it has now changed to "suitable for a dynamic map" is good, that leaves it open to use static maps as well. Drat70 (talk) 13:55, 13 October 2017 (UTC)Reply

The traveller comes first. How many travellers want aesthetically pleasing maps, and how many want maps that are updated the same day that changes are made? (Obviously, it would be best to have both in the same map.) --Robkelk (talk) 14:34, 17 March 2018 (UTC)Reply

Swept in from the pub

It becomes a really bad practice that some of our fellow users, more importantly the admins, are damaging layout of this wiki pages by consistently adding {{mapframe}}s without any effort to adjust the parameters and checking how the result of their activity affects the layout of these pages.

It's usually just bare {{mapframe}} is thrown into there, usually into the "Get around" section. But in the most of the cases this changes make damage to the articles structure.

One particular example is the user @Ibaman:, so I wrote once a note at the User talk:Ibaman:

Hello @Ibaman:, the way you were adding mapframes recently to a few pages, in Sicily in particular (Special:Diff/3151032) simply damages their layout. These mapframes bump into another section, "See" in in this case, so if there are any photos in this section they are get pushed into irrelevant location causing also a "domino effect". So you're essentially damaging the work done by other people. That's why I was asking you to be more creative.

Please consider: mapframes are optional. It makes sense to have one at a page if it adds a value and improves readability of a page, not the opposite. So if you're adding one to an article please format and place it accordingly.

BTW If you read more carefully the page you posted a link to at your comment to Special:Diff/3151032 then you'll learn that "Static or dynamic maps are usually displayed in this (Understand) section, if present" Wikivoyage:Where_you_can_stick_it#Understand. Also note that this passage does not use a verb must. So again this is a reference to your creativity.

Hope this makes sense. --Vadim Shlyakhov (talk) 13:21, 16 February 2017 (UTC)

Ibaman didn't bother answering and continued meticulously throwing bare {{mapframe}} here and then.

Now @Andrewssi2: comes along:

Hi, just to say that we do require maps on destination articles. If you don't like the dynamic one, then feel free to create a static one instead. Thanks. Andrewssi2 (talk) 09:11, 7 October 2017 (UTC)

Note there is no any reference these, so without any grounds Andrewssi2 throws another mapframe and opens a discussion at the Talk:Tempio_Pausania:

User:Vadp seems to think that adding a map to this article is vandalising his/her work. This isn't how Wikivoyage works since everyone can contribute accurate and useful information. Additionally the status of each article will depend on having a map : Wikivoyage:City_guide_status so it isn't actually optional. Andrewssi2 (talk) 10:01, 7 October 2017 (UTC)

Strictly speaking, in Wikivoyage:City guide status the map is just mentioned at the Guide level: "preferably including a map", and it's only at Star level the map becomes mandatory. This article still needs a place where you can sleep before it's even Usable. Also, normal sized mapframes do in my opinion take up a disproportionately large space in short articles. ϒpsilon (talk) 10:32, 7 October 2017 (UTC)

But surely that is sufficient indication that maps belong on articles on Wikivoyage? --Andrewssi2 (talk) 10:34, 7 October 2017 (UTC)

Maps in the current form do unfortunately belong in the articles, but AFAIK they haven't so far been so important that we have required them for outline status. Otherwise they should maybe be included in the article templates.

If it was up to me, though, maps should be implemented in an expandable section like they've done in the Russian (and perhaps other language versions) WV and in addition be openable in small windows next to the icons in listings. ϒpsilon (talk) 10:58, 7 October 2017 (UTC)

For me @Ypsilon: is quite right there. In many cases mapframes are too obtrusive, especially if used without considering their placement and dimensions. More over they are also ininformative, see again Special:Diff/3292776: POIs make a formless swarm there each of them is indistinguishable from each other and they cover over the poor town's location, so you don't see a thing of it.

So how would you call that? It's a {{Mapframe}} vandalism!

I'm not against a "dynamic map" per se. You just need to be sure it is adding something to an article, not damaging it --Vadim Shlyakhov (talk) 13:21, 8 October 2017 (UTC)Reply

I can only recommend to follow the recipe of Russian Wikivoyage and place dynamic maps into the collapsible environment. Then they do not take place on the page and can be extended to the full page width. Additionally, a button can be used to open the map in the full-screen mode. Such a button is in fact available in the top right corner (across the breadcrumb navigation), but for some mysterious reason this button links to the old map interface (via tools.wmflabs.org), which does not support full functionality of the existing map templates.

Current usage of {{mapframe}} can be turned to optional. The in-line map has one major advantage of being visible, but it only makes sense in long articles, where maps do not break the formatting. --Alexander (talk) 15:18, 8 October 2017 (UTC)Reply

I think sticking the mapframe into the "get around" section simply follows Wikivoyage:How_to_use_dynamic_maps#Embed_a_dynamic_map, and a consistent location helps the traveler to easily find the dynamic map on the page. Also, dynamic maps (together with the listing coordinates) are one of the best features on wikivoyage, and shouldn't be hidden away. Regarding the structure of the page: as far as I understand image positions are floating and users with different screen sizes (mobile, wide-screen, etc.) will see them at different positions in the page anyway. Xsobev (talk) 16:51, 8 October 2017 (UTC)Reply

Yes, the images float, but they should not be too far away from their text. For example, this layout looks very untidy and simply unappealing. --Alexander (talk) 17:03, 8 October 2017 (UTC)Reply

I wouldn't call adding maps to the articles vandalism, after all they're standard things produced by the community, but I myself refrain from adding maps to articles that have little content. It's different with articles that actually have tens of listings. And yes, I would strongly support having the dynamic map laid out like in ru-WV (also see my comments here Wikivoyage_talk:Dynamic_maps_Expedition#Layout_of_maps). --ϒpsilon (talk) 18:25, 8 October 2017 (UTC)Reply

If you don't like Dynamic Maps, then by all means discuss them. You do not however own the layout of articles and Dynamic Maps are a completely valid component. Andrewssi2 (talk) 20:29, 8 October 2017 (UTC)Reply

The example Alexander gives above does look less than ideal, but IMO the solution is to move the misplaced photo of a ==See== listing out of the ==Get around== section, rather than to move (or remove) the map.

(I don't like collapsed content, which produces accessibility problems.) WhatamIdoing (talk) 00:27, 9 October 2017 (UTC)Reply

I think the principle of floating images we use in Wiki's makes it impossible to create a perfect page lay-out. Yes, SOMEONE can make it look perfect, but that is on on THAT SOMEONE'S computer with THAT SOMEONE'S graphical preferences, with THAT SOMEONE'S browser, with THAT SOMEONE'S browser preferences, and with THAT SOMEONE'S Wikivoyage preferences. In any other situation it can look quite different. So, creating a perfect lay-out is a waste of time, I think. Photo's and other images like a {{mapframe|...}} are best placed near the text that is relevant to that image. A <gallery> might be the only way to control the position of images in a page. --FredTC (talk) 01:47, 9 October 2017 (UTC)Reply

Yes, the problem with the layout (such as it is a problem) is that he tried to add too many photos against too little content and then decided having the map component didn't work for him. Basically add more content or prune some photos. Andrewssi2 (talk) 04:34, 9 October 2017 (UTC)Reply

Andrewssi2 simply is not able to admit that he's wrong. He was wrong from the start: for what ever reason he decided for himself of something and tried to force others to obey his orders. Many of the articles in this wiki looks clumsy and now I understand why: some of the admins are happy doing mechanical changes to the articles (User:Ibaman in particular, perhaps for the sake of raising their's edit ratings), but they don't care if a page looks messy.

This discussion misses one crucial point: it's not about where to put a mapframe but if a particular page needs it and if it does then how. None of the changes at the poor Temio's page is trying to play with size and the other parameters of this feature. It all looks untidy. My plea for creativity is simply missed.

By my own experience a good photo is quite important as it gives more information than many words. In many cases that's a good photo, not a map, which inspired me to go and see something. You've got an access to a map anyway -- it's just a click away --Vadim Shlyakhov (talk) 09:11, 9 October 2017 (UTC)Reply

It's not that mere adding a mapframe is wrong, but persistence in making a damage is vadnalism. --Vadim Shlyakhov (talk) 09:27, 9 October 2017 (UTC)Reply

Yet another thing. As I wrote earlier Wikivoyage:Where_you_can_stick_it#Understand suggests maps to go into the "Understand" section. It seems to be quite logic: that's where a reader is to find an overview of a destination --Vadim Shlyakhov (talk) 10:04, 9 October 2017 (UTC)Reply

I think "where you can stick it" should be changed as "get around" is a much more logical place to put a map. Hobbitschuster (talk) 12:02, 9 October 2017 (UTC)Reply

Yes, at the moment you want to go around in a city, you would like to se a streel level map. However, in the Understand section, you want to know where the destination is located inside a larger area (country, region, province, ...). So a locator map is best placed in the Understand section. And also not documented in Wikivoyage:Where_you_can_stick_it is the location of another type of map: a region map. --FredTC (talk) 12:19, 9 October 2017 (UTC)Reply

We don't usually use locator maps. Hobbitschuster (talk) 12:22, 9 October 2017 (UTC)Reply

Sorry, the example pages I looked at have them (several Sicily pages). --FredTC (talk) 12:47, 9 October 2017 (UTC)Reply

For bottom-level articles, it would be best to place maps in "Get in"/"Get around" to leave the space in "Understand" free for photographs. For regions (or huge cities which have districts under them) the map showing the subregions should be in the "Regions"/"Cities" or "Districts" section as appropriate. I think we've always done it that way for top-level regions (the region map is next to the region list for something like Atlantic Canada or New York State which has other regions under it); WYCSI should be revised to reflect this. K7L (talk) 19:45, 9 October 2017 (UTC)Reply

• For the record: In my opinion, any article in Wikivoyage without a map is incomplete. Maps have always been, since time immemorial, one of the most (if not THE most) useful tools for the traveler; traveling is about geography, about assessing and making decisions about options and distances and directions and possibilities: it's always best to have a map - even better to have one that can be zoomed in and out and shows POIs in different colors. I really like and stand by our beautiful feature of dynamic maps. I really don't like to see a well-edited article, full of POIs, without a dynamic map; it's INCOMPLETE. I care for the completeness and usefullness of our online travel guide; couldn't care less for my "ratings" (don't even know what are these). I don't and never did take "orders" from Andrewssi2 or any other Admin, it's just a matter of us having been Admins for a very long time, and sharing clear notions of Wikivoyage policy, consensuses achieved, visual style, page homogeneity, and so on. Ibaman (talk) 14:00, 9 October 2017 (UTC)Reply

Vadim Shlyakhov - you are the one who has been been wrong through this whole sorry discussion. You do not own any article on English Wikivoyage and you have insulted me and others throughout. You are trying to prevent the traveler from accessing useful information with maps - I recommend you cease now. Andrewssi2 (talk) 21:15, 9 October 2017 (UTC)Reply

* I reject the vandalism attribute altogether. Maps are a major feature for Wikivoyage as well as images. I usually don't put in a dynamic map until there are at least 5 or more POIs - where to place a mapframe is in all actuality an open question and generalized suggestions for me are acceptable (Understand or Get Around or Regions or Cities etc.) depending upon what you wish to convey and the various concerns such as type of article, amount of text, visual presentation etc. To make things more complicated - you can place multiple mapframes in an article as well if so desired. (ie. an added mapframe in a See section containing 20+ listings. The unique mapframe showing only those particular POIs or perhaps a separate mapframe for highway/train/route or hiking trail). I would suggest that one use Common Sense in its use and review (examine) the page when used. -- Matroc (talk) 21:45, 9 October 2017 (UTC)Reply

I think that maps are a great feature. I will generally add a map to a city article if I am editing it and two or more listings have lat/longs. Occasionally I will move the images after adding the map. I usually add maps to "Get around", as I thought that was the preferred position. As an experienced editor I know that I can also get a map from the icon above the banner, or by clicking on the number next a listing, but I know from observing others that most readers do not realise this - adding a visible map to the article is the best way to show that we have a map. AlasdairW (talk) 22:26, 9 October 2017 (UTC)Reply

Maps are essential to any serious travel guide, in order for travellers to visualise where the individual places our guide is talking about actually are, how far they are away from each other etc... it's pretty basic stuff. Given the desperately sorry state of many of our static maps and how difficult it is to create a decent one, compared to the few clicks it takes to insert a dynamic map that updates itself over time, dynamic maps have become an invaluable tool. Frankly, trying to remove valuable information for what seem to be purely aesthetic reasons shows misplaced priorities. We are here to serve the traveller; creating a beautiful-looking article should be a consideration, but it is not the primary concern. --ThunderingTyphoons! (talk) 23:00, 9 October 2017 (UTC)Reply

Look, we've come to a pretty clear-cut and overwhelming consensus on this issue; one whose result was, frankly, never in any serious doubt in the first place. Given that, I don't think it serves any real purpose for every last Wikivoyager to chime in on this thread with yet another variation of "WTF, of course I'm in favor of adding maps to articles", and neither is it probably necessary for Andrewssi2 to attempt to clarify a policy to spell out in black and white what should already be common sense. Instead, what we have here is one community member whose refusal to accept a consensus that disagrees with him has led to edit warring and borderline uncivil behavior. If that continues, it's likely a matter for Wikivoyage:User ban nominations, not the pub. But let's not get ahead of ourselves just yet: until we see such a continuation of behavior, let's just let the matter die here. -- AndreCarrotflower (talk) 01:17, 10 October 2017 (UTC)Reply

So please take an effort to read the following:

This is not about mapframes are good or bad. It's about mechanical adding it without taking care of a page content.

As to vandalism

It happened that quite often my edits in this wiki are quickly followed by User talk:Ibaman is adding unadjusted mapframes.

I've fixed a few of them, but then I'd asked User talk:Ibaman to take more care with this activity and consider placement and parameters of these mapframes as this activity is damaging the article's layout(see above). User talk:Ibaman seemingly didn't care and didn't make an attempt to discuss the issue.

So wrote that I'll keep reverting these edits until User talk:Ibaman put more thinking in this activity

The curious ones could check the logs.

Now Andrewssi2 comes with the same. So I've opened this discussion.

Another issue

is that Andrewssi2 wrote at User talk:Vadp:

Hi, just to say that we do require maps on destination articles. If you don't like the dynamic one, then feel free to create a static one instead. Thanks. Andrewssi2 (talk) 09:11, 7 October 2017 (UTC)

I've asked to give a reference to the relevant rule, but Andrewssi2 did not, but the statement is not true. I'll skip for the rest...

Any thoughts? --Vadim Shlyakhov (talk) 09:51, 10 October 2017 (UTC)Reply

I agree that the discussion went in a completely wrong direction. It also revealed a common misunderstanding that map is created by adding the {{mapframe}} template, and articles without such a template lack a map. They don't. In fact, map is already there when you add at least one listing with geo-coordinates. The map is immediately available by clicking on the colored square in front of that listing, or on the map icon at the top right corner of the page.

Making map prominent by embedding it through the {{mapframe}} template may work in some cases, but in many cases it does not, and Vadim tries to articulate that. First, maps in articles like Dublin are a mess of markers. Such maps are not particularly helpful at this low zoom level, and they are not helpful at all when you read through the article and want to understand where my POI #15 is. A prominent map button opening a full-screen map will achieve exactly the same result without taking a lot of space on the page and shrinking the text to a narrow column.

Another example are articles like Olbia where the big and prominent map takes place of images that are much smaller in size. In my opinion, this layout sets wrong priorities. Travel guide should lure the traveler to visit a destination. One travels to a destination because of nice images, not because of the map. On the other hand, if I am not going to travel, map is of no use for me anyway.

Page layout is a further concern. Even if it's hard to create a layout that would be equally good for all font sizes and screen widths, articles should look tidy, and with big mapframes they sometimes don't.

Altogether, throwing large mapframe on every page is not a good solution. There should be some flexibility behind using mapframes. --Alexander (talk) 12:04, 10 October 2017 (UTC)Reply

"A prominent map button"? Would this be something like the links to the individual region maps in Trans-Canada Highway? I think they were {{maplink}}. As for requiring maps in articles? They're not required for "usable" city status, but should exist in "guide" articles and must exist for a "star". K7L (talk)

Yes, kind of. In Russian Wikivoyage, we have two of such "buttons", one right after the banner (opens map in the new window) and the second one after the first paragraph, before Understand (collapsible map). --Alexander (talk) 15:16, 10 October 2017 (UTC)Reply

I think many of us would appreciate it if User:Vadp would stop the blame game. It does not help your arguments when you are singling out individual users and accusing them of vandalism, and furthermore threatening to edit war with said users. Above all, none of this makes other editors (such as myself) want to try and engage constructively with you. So that's all I'll say to you for now.

Alexander, I agree to an extent that to write a travel guide is to try and entice the traveller, but we have to remember that Wikivoyage is not just used by prospective travellers who are researching a destination from the comfort of home; we also cater to people on the ground, who are already travelling. I personally often use WV destination articles when I arrive somewhere; if there's no map embedded in that article, that's a serious problem. Photos must be able to fit around practical information such as listings, infoboxes and maps; if they don't fit in with the other essential stuff that our travel guide offers, then they should be the first thing to be removed.

That the map on Dublin is a "mess of markers" signals to me that Dublin should really be split into districts. It is not a reason to remove Dublin's map.

Despite saying all that, I am interested in this idea of yours: "A prominent map button opening a full-screen map will achieve exactly the same result without taking a lot of space on the page and shrinking the text to a narrow column." Other editors, is there a reason why we don't do this? The requirement for a printable article doesn't affect this, because dynamic maps don't work when printed anyway. As far as I can see, it's the same principle as on the mobile version, where each page section is closed by default until the reader chooses to open it -- ThunderingTyphoons! (talk) 12:37, 10 October 2017 (UTC)Reply

I personally often use WV destination articles when I arrive somewhere; if there's no map embedded in that article, that's a serious problem.

Why? Can't you click on any of the colored squares in front of the listings? --Alexander (talk) 13:09, 10 October 2017 (UTC)Reply

I can do that, yes. But I, as a Wikivoyage editor with close to five years' experience on this site, am not representative of the average reader, who (we must assume) does not edit here. How is someone supposed to know, unless they discover by chance, that clicking on one of the coloured numbers takes them to that place on the map? Furthermore, looking to see the precise place where a particular listing is located is not the only use for a map, but I think you know that already. --ThunderingTyphoons! (talk) 13:36, 10 October 2017 (UTC)Reply

Yes, and a prominent map button may help in this case. At least as an alternative to adding mapframes everywhere. --Alexander (talk) 13:49, 10 October 2017 (UTC)Reply

I use myself this wiki (and hence my frustration) in the field using a mobile or a tablet. For such a small screen you need a separate window with a map otherwise it's not possible to read an article.

mapframes could be useful to indicate a location of a destination. But if POI markers cover up the later one completely this feature becomes uninformative.

By the way, someone could be interested to have a look at another wiki where we do tend to have builtin map frames. They are located close to the top of a page, so they are less obstructive to rest of the page and these maps are stripped off the POI marks by default. While if a full window map is called up it does display the page's POIs. --Vadim Shlyakhov (talk) 09:07, 11 October 2017 (UTC)Reply

Someone should have look at the Bonifacio -- this is outrageous! --Vadim Shlyakhov (talk) 13:33, 11 October 2017 (UTC)Reply

It's only outrageous because someone input the wrong co-ordinates for the second 'do' listing. That's not the same as {{mapframe}} itself being in any way inherently broken. K7L (talk) 14:00, 11 October 2017 (UTC)Reply

Someone should check a preview before submitting a change --Vadim Shlyakhov (talk) 14:18, 11 October 2017 (UTC)Reply

Sure, but the failure to do so is not worthy of anyone's outrage. Powers ^(talk) 20:41, 11 October 2017 (UTC)Reply

Well, agree, perhaps not a correct word, but then that's done repeatedly over my edits, I felt, may I say, irritated. --Vadim Shlyakhov (talk) 09:33, 15 October 2017 (UTC)Reply

• Just for the record, Vadim, you don't own the edits, the community does. Get over this. It will make you happier and healthier. Ibaman (talk) 12:50, 19 October 2017 (UTC)Reply

I've just had a look at this page. It doesn't appear to resolve the issue. It doesn't say that:

• that's the one who's adding a map is responsible to make it fit to the page layout;
• the content of such a map must represent something meaningful, i.e. the map is readable: the reader can see the destination's features and the location of each POI marker clearly.

Apparently it will remain the same: someone puts a lot of effort to develop a page, then someone else adds {{mapframe}}, makes the page look messy and thinks that's a valuable contribution.

That's quite discouraging. Frankly speaking I don't see how I could continue with this --Vadim Shlyakhov (talk) 08:20, 19 October 2017 (UTC)Reply

• If it's any comfort, some years ago I spent a lot of time (weeks) fine-tuning the St. Petersburg article visually. It looked stunning on my screen. Then I went to a friend's house, to show off my Wiki-code skills. When we opened the page, it looked like crap, totally out of tune, showing several little glitches I had worked so hard on ironing out... It taught me a lesson: what really counts in the articles is the carefully collected/processed/redacted written information, this is the real precious content. Pics are secondary. Dynamic maps are very new, a work in progress and need of much programming, fine tuning, discussion and consensus-making until it will maybe start to look as polished and professional as Wikivoyage deserves. However, speaking now just for myself, I don't propose to be rid of them "in the meantime", as they are NOW so useful for the traveller and handy, and easy to use and zoom in and out, that these qualities overcome their "ugliness" and make them INDISPENSABLE to bottom-level destinations. Ibaman (talk) 12:50, 19 October 2017 (UTC)Reply

Thanks I do appreciate you answering back. Apparently we're not sharing the same taste, although that's not a reason to kill each other. But well, after what happened to my efforts at this wiki I'd better to seek for some other options for my passion -- travelling --Vadim Shlyakhov (talk) 09:32, 23 October 2017 (UTC)Reply

Just to make a point here: I share Vadim's view on the un-necessity of arbitrary dynamic mapframes, and I understand his frustration.

1. IMHO, adding a arbitrary dynamic map does not automatically make the article better. It clearly depends on the circumstances, and distribution of GPS markers.
2. Many people use non-browser based maps/apps anyhow, so they won't probably care are about a mapframe present or not in WikiVoyage articles.
3. Other people, I encountered, print out travel information instead of using the fancy online tools, WV has. Even more reason to have a (static) mapframe in place that shows something reasonable and understandable at first sight. Here is a quote from Wikivoyage:Map: Wikivoyage pages are designed for offline use, and therefore static maps are more useful in that regard.
4. The map frame does not work with PDF and book export. So, what are we talking about here regarding the necessity and usefulness of maps when not even fundamental functionality is given in the first place?
5. Maybe an arbitrary dynamic map makes an article more valuable, maybe not. But you know what makes an article definitely more valuable and even adds additional value? A readable and thoughtfully created mapframe.
6. What is confusing to me. Why is it that hard to invest 5 minutes to create a more valuable mapframe? Isn't that what we are really here for? Instead WV is sometimes filled with such quick and unthoughtful manifestations of unnecessary bureaucracy, destroying beauty and readability in the process, just for the sake of the contribution counter and personal laziness. (Something similar happened lately when the North Estonia article in three subsection was "spammed" with an ugly remark box that listings should not be used on region level. How is such blind and wild activism helpful for the traveller?)
7. I understand and already have often encountered at WV myself that even though one has a different point of view, it makes sense what the majority of active people think here, especially if it creates consistency. However, when it comes to something like this, which is not written in stone, I really believe, WV would do better to appreciate the effort of editors (especially newer ones) and be less punitive in its opinions. (Didn't we just lately discuss, how to less deter active and useful new editor?)

TFR, Ceever (talk) 11:20, 23 October 2017 (UTC)Reply

You're conflating at least 2 issues. The "movetocity" template is not useful to travellers per se, that's true. However, the result of having detailed listings in guides for specific localities instead of region articles, which flows from the placement of that template, is good for travellers. If I want to find things to see and do in Yonkers, I'm not going to look in the articles for Westchester County, Metro New York or New York State, and if there are specific listings in any of those articles, they should be moved. If you don't like the "movetocity" template, what is your alternative? Ikan Kekek (talk) 19:11, 23 October 2017 (UTC)Reply

The obvious alternative is for the editor who finds listings that should be elsewhere to just move them to the best place, instead of issuing demands via template. ThunderingTyphoons! (talk) 19:35, 23 October 2017 (UTC)Reply

Swept in from the pub

Now that we have established the (blindingly obvious) fact that adding maps to articles is of great benefit to travellers in destination articles, I am drafting a short policy around it here: Wikivoyage_talk:Map.

There seems to be some space to discuss exactly how maps are supposed to be used in articles, so please contribute any constructive comments. Andrewssi2 (talk) 23:02, 9 October 2017 (UTC)Reply

Swept in from the pub

I have created plenty of dynamic district overview maps and saved them in Commons. All of them are going to get deleted soon, because the district borders were traced using OpenStreetMap as a background image. OSM based files are apparently not allowed on Commons, since OSM has no CC0 license. This work took me lots of working hours. Is there anything we can do about it? Cities with those maps include Singapore, Madrid, Dubai, Munich, Kuala Lumpur, Amsterdam, Milan, Saint Petersburg and Copenhagen. If not then I'm out. Don't wanna waste my time on something, which gets deleted later on... --Renek78 (talk) 11:37, 12 October 2017 (UTC)Reply

It's such a common Commons scenario. I wrote a response there. Others should do it as well, preferrably along the same lines, and I really mean you should go and write, not sit here and wait until others do it for you. The more people voice their oppose, the less chances that the files will be deleted.

The ultimate solution is storing map boundaries outside Commons (even on Wikidata, which is 100 times more adequate than the Commons community and infinitely better organized), but I don't know how to talk WMF into making this possible. --Alexander (talk) 12:21, 12 October 2017 (UTC)Reply

@Renek78, a piece of personal advice, if I may. Every time you upload something on Commons, write it is your 'own work', unless it's explicitly done by others. Any additional remarks you leave will be used against you, sooner or later. That's Commons. --Alexander (talk) 12:21, 12 October 2017 (UTC)Reply

Hi Alexander, thanks for your support and hint. I already wrote at this location. Not sure where it's better.--Renek78 (talk) 14:29, 12 October 2017 (UTC)Reply

@Renek78, I advise that you create a backup version of your maps either here, in the user space on English Wikivoyage, or on your computer. If maps are eventually deleted, it will be difficult to get them back. --Alexander (talk) 17:10, 12 October 2017 (UTC)Reply

I saved all the maps now on my user page.--Renek78 (talk) 18:36, 12 October 2017 (UTC)Reply

"Every time you upload something on Commons, write it is your 'own work', unless it's explicitly done by others" isn't great advice. It's important to list all of your sources for copyright purposes. Powers ^(talk) 21:25, 12 October 2017 (UTC)Reply

Agreed. Hiding anything only makes problems appear later in a more dramatic way. Syced (talk) 06:52, 13 October 2017 (UTC)Reply

For the record, I do not encourage anyone to take someone else's work and upload it as your 'own work'. On the other hand, I think that attributions make sense only if they are verifiable.

For example, if you go for a walk with your friend, two of you have one camera and make shots together, but it perfectly makes sense to upload all photos as your 'own work', unless your friend really cares and wants to upload files himself. Otherwise, you will spend weeks on arguing, sending and re-sending OTRS permissions, all for nothing.

In the map case, it is not possible to say whether free OSM or non-free Google was used for tracing the boundary, or perhaps there is an algorithm that simply creates a boundary encompassing all POIs of a given Wikivoyage article. Therefore, I think it is better to refrain from any attribution. --Alexander (talk) 07:59, 13 October 2017 (UTC)Reply

The main issue here seems to be the difference between Commons and WMF in interpreting license rules for the numerical data. WMF sees all numerical data as CC-0 more or less by default (see also the compulsory CC-0 licensing on Wikidata), but not everyone agrees with this. I think there is a chance that the WMF staff will interfere in one way or another, either punching Commons idiots for their meaningless interpretations of the licenses, or enabling the CC-BY-SA licenses in the Data: namespace. However, it may also happen that the issue will be stalled. Then it will only be possible to store map boundaries locally. --Alexander (talk) 17:15, 12 October 2017 (UTC)Reply

We won't be punching anyone. We don't do that here. I've let the product folks at the foundation know about this issue and legal folks have also been contacted to see if we can help clarify some things. Personal opinion: It's very early in the discussion, but I don't think the deletion request will succeed. I think we can deescalate this from "will be deleted" to "may be deleted, but highly improbable". I do like your suggestion for folks also active on Commons to civilly join the conversation. When I get more info I'll let you all know. CKoerner (WMF) (talk) 21:46, 12 October 2017 (UTC)Reply

Does the link at the bottom of dynamic maps ( Map data © OpenStreetMap contributors) cover any of this? -- Matroc (talk) 03:15, 13 October 2017 (UTC)Reply

No, because it only appears when map boundary is displaced. The boundary itself (geoJSON) says it is under CC-0, not under CC-BY-SA-2.0. --Alexander (talk) 07:59, 13 October 2017 (UTC)Reply

@CKoerner (WMF), thank you for your response and participation. The problem here is that the Commons community chooses to start deletion requests and eventually delete useful files, instead of discussing such general issues in a proper setting before pressing the Delete button. Here we are talking about content, which is free and, clearly, can be used in WMF wikis. The whole problem is whether free license A should be used instead of free license B. Unimportant as it is, this discussion may easily end up in the free content being deleted. That's outrageous. --Alexander (talk) 07:59, 13 October 2017 (UTC)Reply

This discussion over at Commons is ridiculous. Some people have too much time on their hands.
A backup plan would be to implement the GeoJSON right into the article. Result is the same. Some new users might be overwhelmed by the huge amount of "weird code" in the Districts section of the article though. Example: User:Renek78/Sandbox/KL. This was a simple copy & paste from the GeoJSON at Commons. If I remove carriage returns in between the coordinates it gets a lot more compressed. What ya think? Shall we do it like this, if the maps get deleted at Commons? I'll go on a 3-days-cycling trip to enjoy the autumn. The guys at Commons should do something similar to come down a little... --Renek78 (talk) 08:45, 14 October 2017 (UTC)Reply

Renek78, I do not recommend to store huge pieces of data inside the articles. You can always put them on separate pages and transclude when needed. My original solution for Russian Wikivoyage was storing all boundaries as subpages of Template:Boundary, where map boundary for the article XXX would be stored under Template:Boundary/XXX. This makes it very easy to call such boundaries, you only need to know the article name. --Alexander (talk) 09:18, 14 October 2017 (UTC)Reply

Formerly boundaries and borders were put stored under Template:GPX, so I guess this is the place to put the data.

This discussion and the one in Commons should make it clear to everyone why critical data (boundaries, Main Page banners for featured articles etc.) should absolutely be stored here instead of at Commons. ϒpsilon (talk) 10:02, 14 October 2017 (UTC)Reply

Template:GPX has been used for tracks in GPX format. I would not mix it with geoJSON.

Otherwise, I agree that we should store map boundaries locally. Renek78, importing the OSM lines was by all means a bad decision, not for copyright reasons (which are vague at best), but because OSM lines typically contain too many points and will slow down everything here on Wikivoyage. At some point, I played with simplified polygons, cut parts of the OSM lines and stitched them together, but that's quite some work. I am still curious how you did it. Copied the numbers point by point?

If WMF allows CC-BY-SA licenses in the Data: namespace on Commons, the current problem will be resolved. However, it would not prevent similar issues in the future, because Commons deems anything traced from a map as inheriting this map's copyright. On the other hand, it is not possible to prove which map was used for tracing. They can always claim that you traced your boundary from Google and not from OSM, and the boundary will be deleted. Therefore, uploading map boundaries to Wikivoyage should be preferred. --Alexander (talk) 12:49, 14 October 2017 (UTC)Reply

Hi Alexander, JOSM offers an option to download a single element/relation by entering the OSM ID of that element. That's what I used to import it into the map. The problem regarding the big number of points can be solved by selecting the "Simplify way" function in JOSM. It removes excess points without changing the geometry of the polygon too much. If this wasn't enough I often recreated the polygon manually by snapping only to certain points of the original boundary. The largest district GeoJSON has about 70kb, average is like 40kb - quite reasonable, I would say. Sorry again for creating such a mess at Commons. It was a "white lie" ;) --Renek78 (talk) 09:39, 18 October 2017 (UTC)Reply

It won't be deleted just because someone claims it was traced from Google. They'd have to show evidence. Powers ^(talk) 20:39, 14 October 2017 (UTC)Reply

It may be deleted. As you have seen yourself, it took us two days, with at least five accusations toward Wikivoyage editors, before some evidence appeared. Nevertheless, several people voted 'Delete' well before this evidence was provided. Therefore, I would not encourage any usage of Commons data unless the rules are laid down strictly and unambiguously. I started a discussion at their Village Pump, and we can see where it goes, although I don't put any hopes on that. --Alexander (talk) 23:45, 14 October 2017 (UTC)Reply

@Ymblanter:, per your statement "I am a Wikivoyage administrator, and I am not aware of any copying going on" diff; data copied to Wikivoyage such as User:Renek78/Backup/Copenhagen are not correctly licensed. An examination of Renek78's recent contributions will provide a list of the others. I'm certain you can advise contributors here about which copyright policies apply and how to respect the legal requirement of attribution when Open Street Map data is being copied. Thanks --Fæ (talk) 11:52, 15 October 2017 (UTC)Reply

The boundaries of a province or state aren't inherently copyrightable, much like one can't copyright a fact, only copyright the wording and imagery used to express that fact. OSM didn't create the boundaries of any political entity, governments did. Soldiers then defended those boundaries by force of arms. If OSM were "inventing" borders out of imagination and whole cloth, then OSM would be factually wrong.

I believe we should stop storing anything on Commons, including map data. Demanding that users edit on three different wikis (the local Wikivoyage language, Wikidata, Wikicommons) just to create one article here makes life more difficult for users - including new users. Add to that the not-so-minor detail that, when you folks arbitrarily delete things, articles here break and the tiny advantage of being able to reuse Commons and Wikidata items across languages is not enough to counterbalance the cost to this project of having resources spread across multiple wikis. All too often, there's no notice on-wiki here that someone is trying to delete something there until it's too late. That's hurting the project. We need to bring everything local. Please? K7L (talk) 12:07, 15 October 2017 (UTC)Reply

The data and maps can be hosted here or on Commons, all that is being required is correct sourcing and meeting the legal licensing requirements of Open Street Map. Neither of these things is especially difficult. Even if the Commons:Data namespace stays CC0 only, this does not stop SVG or PNG format map files being created and used instead. --Fæ (talk) 12:14, 15 October 2017 (UTC)Reply

No, they need to be hosted here. I'm not OK with changing the licence of our content from CC-BY-SA to CC-0 through a sneaky back-door approach of moving our data off-wiki. That the external project (in this case, Commons) is deleting our content so that our articles break is only insult added to injury. The placement of this data on Commons should never have been done, and needs to be reversed immediately by the original contributors. Sorry. K7L (talk) 12:41, 15 October 2017 (UTC)Reply

I have never advocated moving everything to Commons. Even if local, the copyright restrictions of Open Street Map apply. --Fæ (talk) 12:50, 15 October 2017 (UTC)Reply

The question of who advocated moving the content to Commons is irrelevant, although it looks have gone wrong here: RolandUnger's comment Jan 10 2017, phab:T154908 "We should accept that all traces will be stored at Commons or OpenStreetMap. Traces cannot be copyrighted. Therefore I do not see causes to remove them with rationales as known for images. For this reason we must not store them locally."

If you're now proposing to copyright the legally-defined boundaries of provinces and nations, the reasoning which placed this data on Commons nine months ago is thereby broken and the mistake of placing this data there instead of on the local wiki now needs to be corrected. I couldn't care less who did this, it just needs to be fixed. K7L (talk) 13:02, 15 October 2017 (UTC)Reply

No one's proposing to copyright boundaries of provinces and nations. What's copyrightable is a particular map's representation of those boundaries. If we copy the data points from another map, that's a potential copyright violation. Powers ^(talk) 14:49, 15 October 2017 (UTC)Reply

I am not administrator here (I am administrator of the Russian Wikivoyage), but I do not see why the data should not be licensed as CC-BY-SA.--Ymblanter (talk) 16:28, 15 October 2017 (UTC)Reply

I've always thought facts themselves (such as coordinates) can never be copyrighted, only the way of representing them (e.g. showing borders by the means of purple lines like OSM does in the Mapnik layer). ϒpsilon (talk) 17:41, 15 October 2017 (UTC)Reply

Facts are not copyrighted, but, for example, making a database out of non-copyrightable facts creates copyright in Europe (not in the US as far as I understand). The question is then which jurisdiction applies (given that OSM is a British company) and what is the originality threshold.--Ymblanter (talk) 18:16, 15 October 2017 (UTC)Reply

While the facts that determine a political boundary are not copyrightable, the choice of coordinates that a mapmaker might use to represent that boundary *are*. Even a non-visual representation. Powers ^(talk) 01:40, 16 October 2017 (UTC)Reply

A phone number or the time of sunset are uncopyrightable facts, but when a person uses skill and judgment to add a feature to a map, that is not a fact or statistic or even independently repeatable, if it is, as in this case, captured down to a pair of unique coordinates to 7 decimals it is a representation of a legally meaningful creative work. --Fæ (talk) 10:34, 16 October 2017 (UTC)Reply

False precision in the seventh decimal place doesn't constitute "meaningful creative work" nor does it reflect "skill and judgement". It's just noise. K7L (talk) 12:36, 16 October 2017 (UTC)Reply

The technical detail of the way OSM works may or may not constitute false precision, but the law is clear. It makes no difference whether the creator is using a quill ink pen or a mouse and screen, if they are using their skill and judgement to draw points and lines by hand rather than publishing a an entirely computer generated scan with no possible variation introduced by human judgement, then the creator has a valid claim of copyright. --Fæ (talk) 09:38, 17 October 2017 (UTC)Reply

They're not using skill or judgement. They're merely tracing a line which was already drawn by governments years or even centuries earlier. This does not create a new, original creative work. K7L (talk) 12:04, 18 October 2017 (UTC)Reply

That is a different point. If the original data can be verified as public domain, then an attempt accurately to reproduce it may also be public domain. It would depend on the case as to whether the person doing the tracing added any significant creative judgements to the way it was presented. --Fæ (talk) 12:25, 18 October 2017 (UTC)Reply

For those interested in whether Wikimedia Commons policy for the Data namespace should allow for maps like exports from Open Street Map (which are already allowed in other formats), a proposal based on previous discussions has been created at c:Commons:Village_pump/Proposals#Proposal to include non-CC0 licenses for the Data namespace. --Fæ (talk) 12:25, 18 October 2017 (UTC)Reply

Swept in from the pub

Hi all, when clicking on one of the listing numbers to open the dynamic map, the button for the different map layers (Wikimedia, Mapnik, Relief, Groups, ...) is missing. It is shown correctly in mapframes (both original size and full screen). Does anyone know why and how it can be fixed? Thanks very much, Xsobev (talk) 12:27, 19 October 2017 (UTC)Reply

The problem seems with any dynamic map that is shown with the "maplink" template. A separate, but related issue: I propose to move the "layers button" (currently on the right below the "closing button") to the left below the existing buttons there. The reason for this is that in full screen mode, the "layers button" is hidden below the map details side pane, and therefore very difficult to find. Also, the default map tiles are not very useful, but this is a bigger issue probably. Xsobev (talk) 19:48, 24 October 2017 (UTC)Reply

Swept in from the pub

Hello Wikivoyagers!

I seem to recall reading recently somewhere on here that it is possible to have a dynamic map that only has markers for listings of a particular type (e.g. only see, but no 'do', 'go', 'sleep', etc.) This would allow for a map per section of an article, which would help to ease on the "mess of markers" that hinders readability. Unfortunately, I can't find the place this was mentioned; would anybody be able to confirm whether the above is a possible function of the dynamic map, and if so, how to make it work?

Thanks in advance, ThunderingTyphoons! (talk) 12:27, 9 November 2017 (UTC)Reply

I believe you're looking for Template:Mapframe, and more specifically the "layer" parameter. Using it is quite straightforward. I think the template documentation can do a decent job of explaining how it works.
-- Wauteurz (talk) 14:05, 9 November 2017 (UTC)Reply

Thanks for linking that. It seems a clear explanation, however by the looks of it the option is either to show all POIs or not show any, as opposed to showing one type of listing only. Is that right? --ThunderingTyphoons! (talk) 15:50, 9 November 2017 (UTC)Reply

In many larger cities the mapframe loses a lot of it's usefulness due to the vast numbers of markers (still worthwhile but not as effective as it should be). I read documentation about mapframe with the idea to try separate mapframes for different sections (e.g. one for See's, another mapframe for Do's, another for Eats's, etc.). It would take up more space but might make things a lot more user friendly where there are loads of listings. I could not work out how to do it so if it's allowed and there is an easy way please do point out how. PsamatheM (talk) 15:57, 9 November 2017 (UTC)Reply

Yep, that's basically what I want to know too. --ThunderingTyphoons! (talk) 16:44, 9 November 2017 (UTC)Reply

One example is Roman Empire. AlasdairW (talk) 00:00, 10 November 2017 (UTC)Reply

Add mapframe for each desired section and use the show parameter in each section mapframe. Test Example of Delhi/New Delhi. Scroll down page to see different maps. -- Matroc (talk) 09:18, 10 November 2017 (UTC)Reply

That's what I'm looking for, thank you Matroc! Thanks to everyone who chipped in. --ThunderingTyphoons! (talk) 10:22, 10 November 2017 (UTC)Reply

I left this policy alone for a while, given there were a lot of angry comments by people who felt that ownership of an article's layout belonged to individual contributors and not the community.

I believe the current text of the article is good, and also accomodate the view of those who prefer Dynamic maps and those who prefer static maps.

Can I request consensus to formally make this article policy? Andrewssi2 (talk) 21:49, 19 January 2018 (UTC)Reply

• Support with no objections. Ibaman (talk) 22:48, 19 January 2018 (UTC)Reply
• I'd still like to see a stronger stance taken against static maps in bottom-level destinations ("dynamic map preferred" at the very least, though my true preference would be to outright forbid static maps in any articles with POI listings). Also, it might be good to include a formal policy against articles having both static and dynamic maps that are redundant to each other - this is a phenomenon I've been noticing more and more lately. -- AndreCarrotflower (talk) 22:59, 19 January 2018 (UTC)Reply

• Support. I think that before we change the static / dynamic map balance in cities, we should address the requirement for Star cities to have static maps on Wikivoyage:City guide status. AlasdairW (talk) 23:27, 19 January 2018 (UTC)Reply

• I don't think we should cast this in stone. At the moment, dynamic map support for region-level articles is limited and WMF doesn't seem to be making maps a priority for development. The text reflects the current limitations. If the situation changes, a cast-in-stone policy just becomes an inflexible millstone weighting us down and limiting our margin of manoeuvre to adapt our maps to the new system. K7L (talk) 04:38, 20 January 2018 (UTC)Reply

• Support -Shaundd (talk) 05:56, 20 January 2018 (UTC)Reply

• Support I'm okay with the way it is now, with the bottom level changed to "suitable for dynamic map" as this does allow static maps in bottom level articles as per the discussion above. Drat70 (talk) 12:32, 20 January 2018 (UTC)Reply

People go on and on about how much better static maps look on the page, but when I ask how we're supposed to keep them from becoming outdated since so few of us know how to edit them, I get deafening silence as a response. I'm disappointed in those of us who would prioritize second-rate concerns like aesthetics or their own nitpicky personal preferences of what type of map they like, over the utility of our site for the reader. The number one goal of this site should be to provide accurate and complete information to the reader, and accordingly we need to make it as easy as possible for editors (again, only a tiny minority of whom know how to make and edit static maps) to provide readers with that accuracy and completeness. Given that, dynamic maps are obviously the superior choice for bottom-level destinations. I'm afraid I have to oppose this proposal unless and until an explicit preference (again, if not an outright requirement) for dynamic maps in bottom-level destinations is spelled out. -- AndreCarrotflower (talk) 18:54, 20 January 2018 (UTC)Reply

I think static maps are less and less easy to justify. First of all, most of our users will not be printing stuff out on paper any more, given - among other things - our offline enabled smartphone app (how often are datadumps updated there?) second of all even if they are, free maps (of widely varying quality) are now common even in low income countries. Third of all, most people who do not have the likes of offline enabled OSM or stuff on their phones will have the wherewithall to grab a paper map ahead of time. The only problem is that such maps may not contain all our listings, but neither do static maps; that is something only dynamic maps can do. Now if we could find an easy way to make dynamic maps printable, the whole issue would likely dissolve... Hobbitschuster (talk) 20:52, 20 January 2018 (UTC)Reply

And fourth of all, our preoccupation with "prioritizing offline users" becomes more and more unnecessary as wireless mobile Internet access penetrates deeper and deeper even into the developing world. That policy was written more than a decade ago; the difference in the landscape between then and now is like night and day. -- AndreCarrotflower (talk) 23:39, 20 January 2018 (UTC)Reply

True, mobile internet is more and more widespread, but roaming charges (with one laudable exception) can be insanely high... Hobbitschuster (talk) 23:41, 20 January 2018 (UTC)Reply

What you guys are saying is certainly true, though there are still places like long stretches of the Pacific Coast Highway where there is no reception. Ikan Kekek (talk) 02:32, 21 January 2018 (UTC)Reply

Given history of this discussion (static vs dynamic maps), I rather doubt we are going to achieve a satisfactory consensus. In any case, the Dynamic map has an attribute that allows a static map to be used instead Andrewssi2 (talk) 04:01, 21 January 2018 (UTC)Reply

Hobbitschuster The dynamic maps work on your smartphone app? I just tested it on my phone and it doesn't seem to work. Drat70 (talk) 07:11, 21 January 2018 (UTC)Reply

I'm fine with saying dynamic maps are preferred for bottom-level destinations. I agree with the point that they're the best way to maintain accurate and up-to-date maps. I wouldn't support forbidding them, though. I personally think a static map of downtown areas that highlight attractions and transit lines (but not necessarily restaurants and other listings that change frequently) would be a useful thing in our guides to complement the dynamic map. I haven't found roaming charges and mobile coverage sufficient yet to solely rely on my cell phone when travelling. -Shaundd (talk) 08:00, 21 January 2018 (UTC)Reply

If the dynamic map really does have "an attribute that allows a static map to be used instead", that IMO is the final death knell of any argument in favor of static ones. -- AndreCarrotflower (talk) 15:36, 22 January 2018 (UTC)Reply

Hi Andrewssi2, what do you mean by "the dynamic map has an attribute that allows a static map to be used instead"? Are you referring to the staticmap attribute that shows a static map below the dynamic map? -Shaundd (talk) 03:42, 23 January 2018 (UTC)Reply

The "staticmap" used to be able to (sort of) do what you describe - a fallback if a dynamic map couldn't be displayed - but that broke when the old map code was replaced by mw:extension:Kartographer. Trying the 'staticmap' parameter now just displays both, with the static map under the dynamic one, not scaled properly (so the static map is 1:1 scale and truncated to be the same width as the dynamic map - with just the left side visible). That broke pages like Trans-Labrador Highway which had both (and used the dynamic map as primary, over a lesser-quality static map). This is why we shouldn't cast our opinions of the current state of the dynamic maps into stone as policy - the software has limitations and our handling of maps reflects those limits, but the limits can change (better or worse) with each revision of the map code. K7L (talk) 13:01, 23 January 2018 (UTC)Reply

• I think perhaps that I would change the word policy to guideline instead. Static or dynamic, these maps have good and bad points no matter where they are used. I guess that is why we have Article Talk pages to discuss layout and their use on each page if need be. There should be other discussions somewhere else concerning how to improve static and dynamic maps in general; as well as, make an attempt to find solutions to dislikes, inadequacies and be a little more forward looking concerning possibilities and resolution. It is a conundrum, no maps at all, a static map and no dynamic map, a dynamic map and no static map or both or many. The selection lies in dealing with a myriad of factors such as page layout, usability etc. and no hard and fast rule will suffice; thus, I would prefer guideline and not policy. -- Matroc (talk) 03:33, 24 January 2018 (UTC)Reply

To Andre's point above about redundant static and dynamic maps on the same page, I also don't like it much. We could let it be, we could move to say it's one map style or the other. My observation though from watching dynamic vs static map discussions is that some people really like dynamic maps and some really like static maps -- so I was wondering if there was a way to put both on a page in a way that doesn't create map clutter. I've been trying to create collapsible maps as a way around this -- see User:Shaundd/Maps_Demo. The template isn't very user friendly at this point so I don't think it's ready for roll out, but if people think it's a good idea I can work at improving it. Thoughts? -Shaundd (talk) 06:07, 20 January 2018 (UTC)Reply

I think this is a very good idea. One issue that I noticed right now is that when I try to export the page as PDF, I only get a broken dynamic map and the static map stays collapsed. When I try to print the page, I get the dynamic map shown as static image, but that is not really useful as I can't zoom on a printed out version. I can print the static map, but I have to expand it first. I wonder is it possible to make the static map expand for printouts/pdf export automatically? If that's not possible, we should probably expand the static map by default instead of the dynamic map, so that the articles still work when exported/printed out. Drat70 (talk) 13:00, 20 January 2018 (UTC)Reply

The question is why do we need both types of map, if they contain the exact same information? -- AndreCarrotflower (talk) 18:49, 20 January 2018 (UTC)Reply

I think the problem is that they often don't contain the exact same information. Look for instance at Singapore/Marina_Bay, the information on the train lines is not in the dynamic map at all, if I want to find out which line to take, I have to go back to the Singapore article, find the MRT system map and then try to match that up with the district map. This is a real issue for Singapore, as very few tourists will drive and most travellers will actually have to take the train. It also has labels for features without which makes it easier to navigate, such as the floating platform or the Padang. These are functional issues and not aesthetic nitpicks. Furthermore this map is actually up to date. Drat70 (talk) 07:21, 21 January 2018 (UTC)Reply

(ec) I have a few reasons why I think showing both types of maps is a good idea:

1. Different users prefer different map types. If we have both a static map and a dynamic map for a guide, and we can display both in a way that doesn't detract from the page, why not provide both? It seems like a strength to me -- readers can use the type of map they prefer.
2. I don't agree that static and dynamic maps contain the exact same information. They also don't display it the same way and readers don't interact with it the same way. I find a static map is good for providing an all-in-one-spot quick overview; the dynamic map allows for a more detailed look because there's more information. Going back to my first point, my impression is some prefer the former and others prefer the latter.
3. I'm hoping it would minimize the number of discussions we have about static vs dynamic maps. The community has been butting heads on this for nearly five years now I think, I'm skeptical we're going to come to consensus now. At the end of the day, I'm trying to look at it in a different way to see if it can move us past these discussions. -Shaundd (talk) 07:32, 21 January 2018 (UTC)Reply

Sure, that sounds like a good idea to me. I don't think there's any strong reason against not showing both maps in a page. As you say, both maps have their advantages and I can understand that different people prefer either one or the other. Also in the spirit ttcf I think the benefit of having both maps outweighs the disadvantages of cluttering the page a bit. Drat70 (talk) 08:40, 21 January 2018 (UTC)Reply

The strong argument is that it's unnecessary clutter on a page, not to mention a graphics-heavy violation of our policy on minimal use of images that's cumbersome for those on slow Internet connections. Again, there are some things more important than a user's picayune personal perference of what type of map they like better. -- AndreCarrotflower (talk) 15:34, 22 January 2018 (UTC)Reply

For the Record I want to mention the case of Stavanger. Recently a static map of very high quality was uploaded to Commons. It was briefly deleted from the page for its un-WV style, but consensus was achieved that, for its quality, it must be kept. Right now there are both maps on this article. It's a situation worth debating at this point. I would even suggest study of said static map, by our mapmaking expert users, so our static map game can be upgraded and improved.Ibaman (talk) 23:37, 23 January 2018

I think there are situations where having both a static and dynamic map will be beneficial to the traveller and overall outweigh the fact that there are two similar maps on the one page. They would be exceptions to the general rule but I don't think we should rule it out altogether. Gizza ^(roam) 00:17, 24 January 2018 (UTC)Reply

I agree with DaGizza. If having just two maps makes an article "cluttered", then the article is missing a lot of content.

I'm not sure that the two maps would need to be "similar". It'd be easy enough to take an article such as Amana Colonies and put a static map for the villages at the top, with a dynamic map for the tourist locations lower on the page. For large cities, I can see the advantage of having one map that shows where the city is (in relationship to the surrounding area) and another that shows the districts. A dynamic map is also a good option for cities where most of the destinations are packed into a single, illegible area: make a good static map for the whole destination, and use the dynamic map to zoom in on the downtown/tourist area. I believe that having a "one map per destination" rule would produce inferior articles.

As for which type, it's not merely a matter of personal preferences: dynamic maps won't work for some users (e.g., if you don't have Javascript), but a static map can't show you all the alternate routes to reach your destination, or zoom out to show nearby towns. I think that the ideal situation for many well-developed articles is going to be both types. WhatamIdoing (talk) 23:31, 6 February 2018 (UTC)Reply

Swept in from the pub

I'm looking through Manhattan district articles today. Some of the static maps, once upon a time, could have merited replacement by dynamic maps, but I don't want to see both dynamic and static maps on a page for no good reason. If the static map is fine, my opinion is leave well enough alone and don't waste space, and I don't think there's been a policy change, just creep because of some unilateral actions. If any listings need to be changed in the static map, that can be requested, but I'd like to delete all the mapframes that are unnecessary duplicates. Your comments? Ikan Kekek (talk) 04:24, 30 September 2018 (UTC)Reply

Agreed about the undesirability of dual maps, but let's keep the mapframes and delete the static maps. Why make things difficult for the vast majority of Wikivoyagers who don't know how to edit static maps? -- AndreCarrotflower (talk) 04:27, 30 September 2018 (UTC)Reply

Because they're clearer and prettier and there are still people around who can edit them. You know I take this in a case-by-case basis, but when they're better, they're just better. Ikan Kekek (talk) 04:31, 30 September 2018 (UTC)Reply

And I think the policy has been to leave them unless there's something wrong with them. Ikan Kekek (talk) 04:32, 30 September 2018 (UTC)Reply

One option is to display the static map inline and display a templated link to the dynamic map; that compromise was used for Adirondacks and a later batch of edits which added {mapframe} inline was reverted. Of course, a city has different needs from a region article and the bottom-level articles are better suited for dynamic maps because POI's must be updated every time a venue closes. K7L (talk) 05:15, 30 September 2018 (UTC)Reply

I like that solution. It doesn't use as much space. I think that a good argument can be made for dynamic maps for district and undistricted city maps, generally, but when a good-looking, clear static map is already there, it would be better to request specific changes as long as someone is willing and able to make the changes. Ikan Kekek (talk) 05:54, 30 September 2018 (UTC)Reply

"As long as someone is willing and able to make the changes" is a big caveat. The reason why we introduced dynamic maps in the first place was to further democratize the process of adding or updating our content, so again, why impose an unnecessary impediment to that? Is user-unfriendliness and an exponentially higher chance of inaccurate or outdated information really a reasonable price to pay for something that in some users' subjective opinion looks prettier? -- AndreCarrotflower (talk) 06:08, 30 September 2018 (UTC)Reply

When has there been a consensus to delete all static maps from district and undistricted city articles? We ought to come to a new consensus on this before people plunge forward on their own to put mapshapes into articles that already have clear maps that might need a bit of updating. Ikan Kekek (talk) 06:29, 30 September 2018 (UTC)Reply

{{mapshape}}s or {{mapframe}}s? The mapshape draws an area onto an existing dynamic map – possibly greying out everything outside the city limits, like this. K7L (talk) 13:15, 30 September 2018 (UTC)Reply

Ikan, this conversation is not about going through articles one by one and "delet[ing] all static maps from district and undistricted city articles" (though if it were, I'd be arguing in favor of doing so). We're talking specifically about the articles you've mentioned that have dual maps. Editors should not be adding an additional map to articles that already have one, but now that we do have articles with dual maps, we have to choose which of the two to delete. -- AndreCarrotflower (talk) 13:31, 30 September 2018 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Actually, I like dynamic maps as long as the zoom and coordinates are done in such a way that the map looks attractive in relation to the placement of the markers. Dynamic maps have two advantages, the ease of editing marker placement and the ability to zoom/move them, which are very useful advantages. Also, if you see the dynamic maps I have used on the Motorcycle speedway article, you will notice how the map size and zoom was picked out carefully to look aesthetically pleasing. I prefer an aesthetically pleasing dynamic map to a static map for those reasons, although I would not oppose having an article with a static map and a link to a dynamic map. --Comment by Selfie City (talk about my contributions) 15:02, 30 September 2018 (UTC)Reply

AndreCarrotflower, if the result you want whenever any individual adds a mapframe to a district or undistricted city article is for the static map to be deleted, what you are supporting is a de facto policy of deleting all existing static maps for district and undistricted city articles. The obvious solution if we are not changing policy to support all such static maps to be deleted is that if one of the maps is deleted, it would be the new dynamic map. Otherwise, we might as well be honest and say a huge "To Hell with you!" to all such static maps and delete them all. Ikan Kekek (talk) 19:30, 30 September 2018 (UTC)Reply

One of the issues with dynamic maps is that they do not handle well for mobile use. Our offline apps apparently cannot deal with them at all and if one enters the site via the browser, the maps are not auto-zoomed like they are on the desktop version. I think the latter at least should be easy enough to fix, right? Hobbitschuster (talk) 15:19, 30 September 2018 (UTC)Reply

It's okay on mobile for me, but it probably depends on the device. But it makes me think, what is so terrible about dual maps? Maybe they are actually a good thing. --Comment by Selfie City (talk about my contributions) 16:11, 30 September 2018 (UTC)Reply

Waste of space and ugly. Ikan Kekek (talk) 19:30, 30 September 2018 (UTC)Reply

What if, however, we put them in very separate parts of the article? Absolutely I do not like dual maps on top of each other, but one towards the beginning of the article and another in "eat" might not be so bad. This wouldn't work so well in outline articles but in longer articles it could help with the dual maps problem. --Comment by Selfie City (talk about my contributions) 19:35, 30 September 2018 (UTC)Reply

I think if we're going to have 2 maps of the whole city/district, a solution similar to the one in Adirondacks or collapsing the maps some other way is better than showing both maps on the page. Many of these articles are relatively brief and would benefit more from another photo than a 2nd map. Ikan Kekek (talk) 19:42, 30 September 2018 (UTC)Reply

Maybe a case by case solution would be better. For example, on the Financial District dual maps I would say the static map looks nicer. In more suburban areas, however, it might be different. Rural/suburban areas would not so much be an issue with Manhattan but in other places might be an issue. --Comment by Selfie City (talk about my contributions) 20:36, 30 September 2018 (UTC)Reply

I have supported case-by-case decisions for a long time. I supported removing static maps from certain Manhattan district articles because they were so small as to be user-unfriendly. Ikan Kekek (talk) 21:24, 30 September 2018 (UTC)Reply

In a dense map (=lots of information to communicate), I disagree with the assertion that two maps are a waste of space. In such a case, I think that dual maps is preferable to one that's so crowded that you can't see what's where. Two maps with identical information (both with exactly the same cities marked in a region, or both with all the same districts marked) would indeed be a waste of space, but that situation appears to be very uncommon. (Did we ever find one example of that? I remember several examples of nearly identical maps being put forward (e.g., two maps showing cities, but the first listed cities #1 through #9, and the other listed cities #2 through #10), but I don't remember if we found an article with two maps that were actually identical.)

"Ugly" is not only in the eye of the beholder, but also going to vary with the aesthetic qualities of the map in question. The static map at Oklahoma City is never going to win any beauty prizes. WhatamIdoing (talk) 01:25, 1 October 2018 (UTC)Reply

I agree that in a long article with plenty of content, having two maps that show the city from two very different perspectives at a fair distance apart is a good option and not a waste of space. Gizza ^(roam) 13:12, 1 October 2018 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Back to Hobbitschuster's comment: What exactly are the mobile map problems? We put map improvements on the m:Community Wishlist last fall, and we won – first place winner. The new wishlist starts in a few weeks. I think it really helps to identify a reasonably specific task, and to have an official bug report/feature request filed (or found). What would be the most important improvement to maps? WhatamIdoing (talk) 15:30, 1 October 2018 (UTC)Reply

In addition to the two problems Hobbitschuster mentioned (not displaying on offline apps, not zoomed right), dynamic maps also don't show up at all when articles are downloaded as PDFs. Another useful feature would be for the map to display an icon indicating your current location when you view it on mobile. —Granger (talk · contribs) 00:59, 2 October 2018 (UTC)Reply

Who actually knows how to update static maps? And could one of you please go to Talk:Oklahoma City#Radical proposal on districts and make a new static map for the specified districts? I honestly think I'd have an easier time figuring out mapshape and replacing the districts with a dynamic map, but whether the replacement is dynamic or static, the old map needs to go. WhatamIdoing (talk) 00:47, 1 October 2018 (UTC)Reply

That's one of the problems with static maps. There is no one to update them or create new ones. I've tried asking people before and I haven't gotten an answer. --Comment by Selfie City (talk about my contributions) 01:03, 1 October 2018 (UTC)Reply

The fact that this question is even being asked cuts straight to the heart of the problem. A task as simple as updating a map should not involve such rigmarole, especially when we already have an easier way of doing it. -- AndreCarrotflower (talk) 01:05, 1 October 2018 (UTC)Reply

Since I know that most people won't bother clicking through to see the map – which I'm sure was created based on the best information available some years ago, with the goal of improving things later, so I think it would be entirely unfair to lay any fault whatsoever at the feet of the volunteer who graciously improved this article by adding something – let me outline a couple of problems with this map:

• The district map shows only part of the city, and none of its suburbs, some of which are important destinations in their own right.
• Most of what's shown in the map is outside any district.
• The gray area includes several other cities, which is okay, I guess, but they ought to be marked.
• It's a car-centric destination, but there are no highways shown.
• The only landmark shown is an unlabeled river that most travelers don't know about.
• The main airport, which many travelers would probably start at, isn't shown (and might not be in the part of the city shown on the map).

And: I can't fix it, because it's a static map. If we want a static map for that article, someone else has to do that. WhatamIdoing (talk) 01:39, 1 October 2018 (UTC)Reply

Make a new policy proposal at Wikivoyage talk:Maps and let's make a decision by consensus, not individual action and de facto after-the-fact reasoning. But keep in mind that, unless you are proposing to do away with static maps entirely, they will continue to be needed for articles at the districted city, region, country, group of countries and continent levels.

The answer, though, is that the expert mapmakers aren't here much, nowadays. Saqib, PerryPlanet and who else? But it seems like their skills are still needed, to at least some extent. Ikan Kekek (talk) 01:35, 1 October 2018 (UTC)Reply

I tried making a static map once but I don't remember the instructions being too helpful. Otherwise I would be prepared to help. --Comment by Selfie City (talk about my contributions) 02:33, 1 October 2018 (UTC)Reply

Yeah, all of that downloading from Openstreetmap was too much for me. If making static maps was easier it would be different. --Comment by Selfie City (talk about my contributions) 02:39, 1 October 2018 (UTC)Reply

@SelfieCity, Ikan Kekek: It may well be that I am one of the last people that make static maps (though my results are by no means equal or better than Saqib or Perry's maps), but I myself am moving away from static maps in favour of dynamic maps because drawing the maps is much more time-consuming. I've never bothered with importing OSM data either, but have always drawn them from scratch. I've given Oklahoma City's map a go, and you can find the result in the associated discussion. If you ever urgently need any more static maps drawn, then feel free to reach out to me and I'll see if I can squeeze it in my somewhere in my week :)
-- Wauteurz (talk) 17:18, 5 October 2018 (UTC)Reply

I just saw the static map and I have to say that you've done quite a good job. It's really nice and clear; you can see where all the important things are without having to go through millions of labels. Perhaps in future, we should try to make our static maps more basic so they are not as time-consuming.

On a related note, how long did it take you do create the map? --Comment by Selfie City (talk about my contributions) 22:53, 5 October 2018 (UTC)Reply

Thank you! The goal I try to achieve with static maps is to display districts and other subdivisions, as well as highlight key infrastructure. A proper city map would have listings for see, do, eat, drink and connect, but I'd rather not bother, since they are the key element that do not age well. Other elements currently lacking are district labels, which I left out since the discussions are still ongoing and the names didn't appear to be set in stone yet, as well as road labels, which I may still add later. All in all, I think I've spent about 2½ hours on this one, four if you count my initial map of the greater agglomeration that left the Centre way too small to be useful on the map. Anyway, this is one of the easier maps I've drawn. I've easily spent twelve hours if not more on the Luxembourgian district map, which I think is the map that I invested most time in. Working this map out with the labels described above, excluding listings, I'd spend another half or full hour on it, I'd say.
-- Wauteurz (talk) 00:41, 6 October 2018 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Let me clarify, mainly to others, that a basic or simple map in my opinion is not a bad thing. I know the fancier maps, like that one of Luxembourg, are superior, but that doesn't mean that a very simple map is a bad thing. Anyway, that 2.5 hours is useful information, but actually I have a couple more questions, not to sound like an interrogator, but it may help us more quickly add static maps to places like North Dakota where they would be useful: where did you spend most of that 2 and a half hours making the map — was it mostly on drawing the lines for roads, bodies of water/rivers, or district colors? Is there any way we could decrease those times in future so we can make maps more quickly? I'm not trying to criticize your work, but it would be great if we could have a way to quickly draw static maps so it didn't take so long. Thanks! --Comment by Selfie City (talk about my contributions) 00:51, 6 October 2018 (UTC)Reply

@SelfieCity: I don't mind the questions whatsoever. As for drawing the map, I can only give ballpark estimates, as different maps ask for different methods, if that makes sense. If you don't mind, I'd prefer to make a map for North Dakota, which you mentioned, and note down some timestamps so that I can give some more representative numbers. I'm pretty sure my ballpark estimates are way off in the first place. As for saving time: Using OSM data saves a lot of time that would be spent on drawing infrastructure, but as you pointed out before, that isn't exactly easy, and I for one don't bother with it. I hope to get back to you with some proper numbers later today or tomorrow. Also, if there is a request for one, I could give making a video tutorial or something along those lines a swing in order to make static map creation a bit more accessible, since the wall of text that is the written guide is what held me from plunging forward on static maps for about a year.
-- Wauteurz (talk) 13:51, 6 October 2018 (UTC)Reply

Got it. Those sound like a couple good ideas. I'm no artist but I would like to help out with static maps if it was easier to learn, simply because the number of people who have the talent of drawing Wikivoyage static maps is so limited — as you say, you're pretty much the only one now. --Comment by Selfie City (talk about my contributions) 13:57, 6 October 2018 (UTC)Reply

@SelfieCity: Almost made it in a day, but here are the SVG and PNG maps. Time spent is as follows:

• 15:51; Looking for source material (3 minutes)
• 15:54; Designing layers in Inkscape, general preparation work (1 minute)
• 15:55; Improving and stitching source material (14 minutes)
• 16:09; Mapping highways and Interstate routes (35 minutes)
• 16:44; Mapping waterways and lakes (33 minutes)
• 17:21; Labelling cities and highways (14 minutes)
• 17:35; Saving, interrupting for a break (4 hours, 25 minutes)
• 22:00; Continuing, mapping tertiary roads (34 minutes)
• 22:34; Drawing frame (1 minute)
• 22:35; Drawing regions (45 minutes)
• 23:20; Labelling unlabelled infrastructure (31 minutes)
• 23:51; First export and evaluation (2 minutes)
• 23:53; Annotating regions and frame elements (13 minutes)
• 00:06; First final export (3 minutes)
• 00:09; Files uploaded to Commons

This results in a total time of 3 hours and 49 minutes spent on the map. The drawing regions took longer than needed, since the source material did not include the county borders and I therefore had to estimate the region borders somewhat. Drawing elements takes by far the most time. As I said before, this time can be reduced by importing OSM data, but I generally don't bother. Labelling and annotating comes in second. I hope this is the answer you were looking for. I'll probably start work on a map for South Holland next, since its regions need revamping. I'll record it all so I can later edit that down into a tutorial video/videos. I haven't a clue as to when I can start on that.
-- Wauteurz (talk) 22:23, 6 October 2018 (UTC)Reply

Hi @SelfieCity, Wauteurz:, I’ve drawn a number of static maps and my experience is it takes about 3-10 hours to draw a static map. I don’t track the time, but probably 50-60% of my time is spent on details like colours, labels and making the map readable, 30-40% of my time is spent on making the regions, roads, railroads, city markers, etc, and 0-10% is spent looking for source data. The main driver is the amount of detail in the map — the more roads, railroads and labels I need to fiddle with, the more time it takes. Other things that can slow a map down is having to draw the regions if they don’t follow administrative boundaries and getting source data if I don’t already have it (I don’t import from OSM).

For example, the map I drew at Nevada only took about 3 hours. There’s lots of good data for the US, the regions largely follow county borders so they were simple to draw, there’s only a moderate number of roads, and there was lots of space for labels (e.g., I didn’t have to adjust labels much to avoid overlap with roads and other features). By comparison, the map at Scottish Highlands took 8-9 hours. These region shapes had a fair bit of customization, there are more roads, railroads and national parks, the base data I was working with wasn't as easy to use as data for US maps, and there was a largish number of labels that needed to be placed carefully to maximize readability.

In terms of what can be done to speed up drawing static maps, I think the biggest thing is to avoid adding too much detail — keep infrastructure to a minimum (e.g., main roads, airports and rail connections if needed) so the focus is on regions and key destinations. Cheers -Shaundd (talk) 06:36, 27 October 2018 (UTC)Reply

@Wauteurz: I am so, so, so sorry. I missed this completely! But thanks for the information. It is really appreciated. --Comment by Selfie City (talk | contributions) 13:57, 27 October 2018 (UTC)Reply

Swept in from the pub

This is probably been asked before, but thought to ask it again. What is preferred in 2019? A static Map or a Dynamic Map? --Joshlama1 (talk) 02:44, 21 February 2019 (UTC)Reply

This opens a can of worms. A short answer would be, that it depends on the situation. --Comment by Selfie City (talk | contributions) 03:09, 21 February 2019 (UTC)Reply

Joshlama1 - A longer answer would be that dynamic maps are strongly preferred for bottom-level destinations (undistricted cities and districts of Huge Cities), while static maps are preferred for all other destinations (but dynamic maps are better than nothing in those cases). -- AndreCarrotflower (talk) 15:57, 24 February 2019 (UTC)Reply

Swept in from the pub

I have long thought that our dynamic maps are quite deficient for parks. They can give some general understanding of the size of the park and of the locations of sights and services, but they tell little about the topography and other natural features. For Finland we do have access to real topographic maps, as raster versions and also the ortho-transformed aerial images, name database, hight information etc., to my understanding most or all of the underlying data.

As an example, for Hiidenportti National Park we have the dynamic map, but we could also use the topographic map. Should we use the latter? How would it be sensibly linked? The automatic thumbnails are of little use, as the features cannot be identified at that scale. One possibility is a thumbnail of a crop, which could be linked to the full-size version, the Commons page for the full-size version or something else.

Should we try to do svg versions? I suppose POIs etc. should be edited in anyway. There is also the Metsähallitus dynamic map. It is better maintained than our maps will be, and includes trails, sights and services, but by policy we prefer having as much as possible on our site, and the Metsähallitus map seems to get elements from third parties one might or might not want to trust regarding privacy. Using additional layers from OSM (which presumably uses the public data we would use) would also be possible, if they have chosen or would choose to include the information we want.

Suggestions?

--LPfi (talk) 15:25, 18 June 2019 (UTC)Reply

This is a side issue, but is it legally possible to take screenshots of OpenStreetMap dynamic maps and use those like static maps, if we give attribution? --Comment by Selfie City (talk | contributions) 15:59, 18 June 2019 (UTC)Reply

The OSM maps are under a free licence, which allows derivatives, so yes, there should be no legal problems. I do not remember the exact terms, which may require things beside attribution. --LPfi (talk) 16:33, 18 June 2019 (UTC)Reply

And the maps by Metsähallitus may not be commercially re-used, so I don't think we can use screenshots of them because if I'm not mistaken, Wikivoyage guides can also be commercially re-used if attribution is given. Ypsilon (talk) 16:40, 18 June 2019 (UTC)Reply

No, and there is no use using screenshots of the Metsähallitus maps. For static maps the Maanmittaushallitus maps (like the one I uploaded to Commons and linked above) are far better, at least if we add the POIs and trails. But as dynamic maps the Metsähallitus ones are far better than ours for visiting parks. --LPfi (talk) 17:05, 18 June 2019 (UTC)Reply

There are two problems - the renderrer and a few missing tags. The latter is not too surprising, when you are comparing a local website with a general-purpose one. You can always extend OSM... Regarding the renders, check e.g. opentopmap.org or mapy.cz, both come from OSM data. I think they are quite nice (more polished than the retkikartta, IMO). Perhaps we could add one of those into WV as a background layer too - and allow to use it as default instead of the Wikimedia one... ? -- andree.sk(talk) 06:31, 19 June 2019 (UTC)Reply

Having the default map for parks look more like the maps you linked would be very good. For the thumbnail area it seems Mapy has all information, but has optimized away some smoothness of curves, while Opentopomap is missing some features. Either would be much better as a default for parks than the current, but there may be privacy issues: I've understood Wikimedia fetches the default tiles in a way that hides the actual user, while information is leaked when using third-party layers. Extending what we use directly from OSM would probably be the best solution – but I have no idea how much work that would entail. --LPfi (talk) 09:51, 19 June 2019 (UTC)Reply

Swept in from the pub

Hello!

The Technical Wishes team from Wikimedia Germany is deploying an additional feature to Kartographer: soon it will be possible to automatically show nearby articles on a map in an article page.

Would English Wikivoyage like to be among the first wikis to test the show nearby feature?

It will be available on the first wikis presumably at the end of September or beginning of October. More information, also regarding Wikivoyage’s similar “Show nearby destinations” feature can be found on the project page, questions and discussions are welcome here.

Please let me know here if you are in favour.

Thanks a lot,

Timur for the TechWishes team Timur Vorkul (WMDE) (talk) 15:22, 8 September 2022 (UTC)Reply

Who might be interested in this? FredTC and Renek78 were asking about map problems a while ago, but who else? WhatamIdoing (talk) 16:06, 8 September 2022 (UTC)Reply

Ooh that seems fancy and useful. I'm definitely in favour of this new feature. SHB2000 (talk | contribs | meta) 00:45, 10 September 2022 (UTC)Reply

• Sounds and looks interesting to try out! - Matroc (talk) 04:28, 12 September 2022 (UTC)Reply

We already have this, see: here. But it seems that they will improve it. Right now it needs manual updating of a list/table somewhere (I don't know where). In the Venice article you can see that it needs to be updated, the sestieri San Marco and Castello have no markers using this function now. --FredTC (talk) 08:19, 13 September 2022 (UTC)Reply

Thanks for your reactions!

So I interpret the positive responses and the general excitement as a yes and have included enWikivoyage into the deployment ticket

Tracked in Phabricator ^(?)
Task T316782

. I will let you know the exact deployment date when it's set.

Thanks also for providing the example of Venice so we can keep an eye on once the new feature is available. Timur Vorkul (WMDE) (talk) 11:24, 14 September 2022 (UTC)Reply

@WhatamIdoing @FredTC @Renek78@SHB2000 @Matroc

The deployment of the feature is going to happen next week. The question now is how to proceed with the already existing “show nearby destinations feature”. Technically, both are not in conflict with each other and can exist in parallel for testing purposes.

• Should the existing feature already be turned off or should the old and the new co-exist during the testing?
• If turned off, would you like to do it or should the Technical Wishes team?

Thanks again for you input. Timur Vorkul (WMDE) (talk) 17:19, 27 September 2022 (UTC)Reply

I lean towards having both, but I don't feel strongly about it. WhatamIdoing (talk) 16:12, 29 September 2022 (UTC)Reply

The show nearby articles feature in Kartographer was just deployed to your wiki. Please don't hesitate to share your impressions or ask questions on the project's discussion page. Your input on the prepared feedback questions will help to improve the feature. Thanks! Timur Vorkul (WMDE) (talk) 15:30, 12 October 2022 (UTC)Reply

Swept in from the pub

Hello there))) Published vector maps of my production on WIKIMEDIA Maps of cities (streets, roads, water bodies), names - only cities and districts, road signboards.

LIST OF THE FREE CITY MAPS in SVG EDITABLE

https://commons.wikimedia.org/wiki/File:Aarhus_Denmark_Street_Map_vector_svg_free.svg

https://commons.wikimedia.org/wiki/File:Adelaide_Australia_Street_Map_SVG_free.svg

https://commons.wikimedia.org/wiki/File:Albany_New_York_US_Street_Map.svg

https://commons.wikimedia.org/wiki/File:Albuquerque_New_Mexico_US_Street_Map_SVG.svg

https://commons.wikimedia.org/wiki/File:Allentown_and_Easton_Pennsylvania_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Amsterdam_Netherlands_street_map.svg

https://commons.wikimedia.org/wiki/File:Antwerpen_Belgium_street_map.svg

https://commons.wikimedia.org/wiki/File:Athens_Greece_street_map_vector_gvl13_svg_free.svg

https://commons.wikimedia.org/wiki/File:Atlanta_Georgia_US_street_map_vector_editable_gvl13_svg_free.svg

https://commons.wikimedia.org/wiki/File:Auburn_and_Lewiston_Maine_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Auckland_New_Zealand_street_map.svg

https://commons.wikimedia.org/wiki/File:Austin_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Baku_Azerbaijan_street_map.svg

https://commons.wikimedia.org/wiki/File:Baltimore_Maryland_US_Street_map.svg

https://commons.wikimedia.org/wiki/File:Bangkok_Thailand_street_map.svg

https://commons.wikimedia.org/wiki/File:Basel_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Baton_Rouge_Louisiana_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Beijing_China_street_map.svg

https://commons.wikimedia.org/wiki/File:Belfast_Northern_Ireland_UK_street_map.svg

https://commons.wikimedia.org/wiki/File:Berlin_Germany_street_map.svg

https://commons.wikimedia.org/wiki/File:Bern_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Bismarck_North_Dakota_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Boston_Center_Massachusetts_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Boston_Massachusetts_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Boston_Massachusetts_US_Metro_Area_street_road_map.svg

https://commons.wikimedia.org/wiki/File:Brisbane_Australia_street_map.svg

https://commons.wikimedia.org/wiki/File:Burlington_Vermont_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Calgary_Alberta_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Canberra_Australia_street_map.svg

https://commons.wikimedia.org/wiki/File:Charleston_South_Carolina_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Chicago_Illinois_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Cincinnati_Ohio_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Cleveland_Ohio_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Cologne_Germany_street_map.svg

https://commons.wikimedia.org/wiki/File:Columbus_Ohio_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Copenhagen_Denmark_street_map.svg

https://commons.wikimedia.org/wiki/File:Dallas_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Darmstadt_Germany_street_map.svg

https://commons.wikimedia.org/wiki/File:Dayton_and_Springfield_Ohio_US_street_road_map.svg

https://commons.wikimedia.org/wiki/File:Delhi_India_street_map.svg

https://commons.wikimedia.org/wiki/File:Delray_Beach_Florida_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Denver_and_Boulder_Colorado_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Detroit_Michigan_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Dresden_Germany_street_map.svg

https://commons.wikimedia.org/wiki/File:Dublin_Ireland_street_map.svg

https://commons.wikimedia.org/wiki/File:Edmonton_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Essen_Germany_street_map.svg

https://commons.wikimedia.org/wiki/File:Fargo_North_Dakota_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Fort_Worth_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Fresno_California_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Gatineau_Quebec_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Genève_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Gisborne_New_Zealand_street_map.svg

https://commons.wikimedia.org/wiki/File:Hawaii_US_road_map.svg

https://commons.wikimedia.org/wiki/File:Heathrow_Airport_London_UK_street_road_map.svg

https://commons.wikimedia.org/wiki/File:Helsinki_Espoo_Vantaa_Finland_street_map.svg

https://commons.wikimedia.org/wiki/File:Hong_Kong_China_street_map.svg

https://commons.wikimedia.org/wiki/File:Honolulu_Hawaii_US_street_road_map.svg

https://commons.wikimedia.org/wiki/File:Houston_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Iceland_road_map.svg

https://commons.wikimedia.org/wiki/File:Indianapolis_Indiana_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Islamabad_and_Rawalpindi_Pakistan_street_map.svg

https://commons.wikimedia.org/wiki/File:Istanbul_Turkey_street_map.svg

https://commons.wikimedia.org/wiki/File:Jakarta_Indonesia_street_map.svg

https://commons.wikimedia.org/wiki/File:Kansas_City_Missouri_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Karachi_Pakistan_street_map.svg

https://commons.wikimedia.org/wiki/File:Kelowna_British_Columbia_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Kemi_and_Tornio_Finland_street_map.svg

https://commons.wikimedia.org/wiki/File:Kiev_Ukraine_street_map.svg

https://commons.wikimedia.org/wiki/File:Kuala_Lumpur_Malaysia_street_map.svg

https://commons.wikimedia.org/wiki/File:Kyoto_Japan_street_map.svg

https://commons.wikimedia.org/wiki/File:La_Paz_and_El_Alto_Bolivia_street_map.svg

https://commons.wikimedia.org/wiki/File:Lahore_Pakistan_street_map.svg

https://commons.wikimedia.org/wiki/File:Lakewood_Ohio_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Lancaster_Pennsylvania_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Las_Vegas_Nevada_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Lausanne_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Laval_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Liege_Belgium_street_map.svg

https://commons.wikimedia.org/wiki/File:Lille_France_street_map.svg

https://commons.wikimedia.org/wiki/File:Lincoln_Nebraska_US_street_map.svg

https://commons.wikimedia.org/wiki/File:London_Center_UK_street_map.svg

https://commons.wikimedia.org/wiki/File:London_Greater_UK_street_map.svg

https://commons.wikimedia.org/wiki/File:Los_Angeles_California_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Louisville_Kentucky_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Lugano_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Luxembourg_street_map.svg

https://commons.wikimedia.org/wiki/File:Luzern_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Lviv_Ukraine_street_map.svg

https://commons.wikimedia.org/wiki/File:Lyon_France_street_map.svg

https://commons.wikimedia.org/wiki/File:Macon_Georgia_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Manila_Philippines_street_map.svg

https://commons.wikimedia.org/wiki/File:Martha's_Vineyard_Massachusetts_US_street_road_map.svg

https://commons.wikimedia.org/wiki/File:Mashhad_Iran_street_map.svg

https://commons.wikimedia.org/wiki/File:Medellin_Colombia_street_map.svg

https://commons.wikimedia.org/wiki/File:Melbourne_Australia_street_map.svg

https://commons.wikimedia.org/wiki/File:Memphis_Tennessee_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Menlo_Park_Сalifornia_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Mexico_City_Mexico_street_map.svg

https://commons.wikimedia.org/wiki/File:Miami_Florida_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Milwaukee_Wisconsin_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Minneapolis_and_Sent_Paul_Minnesota_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Minsk_Belarus_street_map.svg

https://commons.wikimedia.org/wiki/File:Montpelier_Vermont_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Montreal_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Moscow_Russia_street_map.svg

https://commons.wikimedia.org/wiki/File:Mountain_View_California_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Napier_New_Zealand_street_map.svg

https://commons.wikimedia.org/wiki/File:New_Braunfels_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:New_Orleans_Louisiana_US_street_map.svg

https://commons.wikimedia.org/wiki/File:New_York_City_Greater_NY_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Olympia_Washington_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Orlando_Florida_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Osaka_Japan_street_map.svg

https://commons.wikimedia.org/wiki/File:Ottawa_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Paris_France_street_map.svg

https://commons.wikimedia.org/wiki/File:Perth_Australia_street_map.svg

https://commons.wikimedia.org/wiki/File:Philadelphia_Pennsylvania_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Phoenix_Arizona_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Pierre_South_Dakota_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Pittsburgh_Pennsylvania_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Port_Arthur_Texas_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Portland_Maine_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Portland_Oregon_and_Vancouver_Washington_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Porto_Portugal_street_map.svg

https://commons.wikimedia.org/wiki/File:Prague_Czech_Republic_street_map.svg

https://commons.wikimedia.org/wiki/File:Quebec_City_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Reading_Pennsylvania_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Reno_Nevada_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Reykjavik_Iceland_street_map.svg

https://commons.wikimedia.org/wiki/File:Richmond_Virginia_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Rio_de_Janeiro_Brazil_street_map.svg

https://commons.wikimedia.org/wiki/File:Rome_Italy_street_map.svg

https://commons.wikimedia.org/wiki/File:Rotterdam_Netherlands_street_map.svg

https://commons.wikimedia.org/wiki/File:Sacramento_California_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Saint_Petersburg_Russia_street_map.svg

https://commons.wikimedia.org/wiki/File:Salem_Oregon_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Salt_Lake_City_Utah_US_street_map.svg

https://commons.wikimedia.org/wiki/File:San_Francisco_and_Oakland_California_US_street_map.svg

https://commons.wikimedia.org/wiki/File:San_Juan_Puerto_Rico_street_map.svg

https://commons.wikimedia.org/wiki/File:São_Paulo_Brazil_street_map.svg

https://commons.wikimedia.org/wiki/File:Seattle_and_Bellevue_Washington_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Shanghai_China_street_map.svg

https://commons.wikimedia.org/wiki/File:Sioux_Falls_South_Dakota_US_street_map.svg

https://commons.wikimedia.org/wiki/File:St._Gallen_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Sydney_Australia_street_map.svg

https://commons.wikimedia.org/wiki/File:Tampa_Bay_Florida_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Tampere_Finland_street_map.svg

https://commons.wikimedia.org/wiki/File:Tauranga_New_Zealand_street_map.svg

https://commons.wikimedia.org/wiki/File:Tehran_Iran_street_map.svg

https://commons.wikimedia.org/wiki/File:Tel_Aviv_Yafo_Israel_street_map.svg

https://commons.wikimedia.org/wiki/File:Tokyo_Japan_street_map.svg

https://commons.wikimedia.org/wiki/File:Toronto_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Tulsa_Oklahoma_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Turku_Finland_street_map.svg

https://commons.wikimedia.org/wiki/File:Vancouver_Canada_street_map.svg

https://commons.wikimedia.org/wiki/File:Warsaw_Poland_street_map.svg

https://commons.wikimedia.org/wiki/File:Washington_DC_and_Baltimore_MD_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Washington_DC_US_street_map.svg

https://commons.wikimedia.org/wiki/File:Wellington_New_Zealand_street_map.svg

https://commons.wikimedia.org/wiki/File:Winterthur_Switzerland_street_map.svg

https://commons.wikimedia.org/wiki/File:Yokohama_Japan_street_map.svg

https://commons.wikimedia.org/wiki/File:Zurich_Switzerland_street_map.svg

Only SVG is listed here In all other formats - Illustrator, PDF, in layers - HERE: free vector city maps in Illustrator and PDF

Vectormapper (talk) 23:51, 27 June 2024 (UTC)Reply

Perhaps you will be interested.

I tried to publish my maps in regular Wikipedia, in an article about cities. City maps were instantly demolished. Here is a discussion about this (a very stupid discussion)

Short:

1. I'm bad because I have a nickname that speaks about my profession.

2. I'm bad because my maps have a tiny signature of my logo.

3. I'm bad because on my user page it says what I do - cartography. And it’s not written that I love cats and scuba diving.

4. Free vector maps of cities are not needed in articles about cities, because (sorry, I can’t think of a reason for this), and also because “most users don’t need them.”

Vectormapper (talk) 02:55, 28 June 2024 (UTC)Reply

@Vectormapper: These are some great maps and with some modification, I can see how this would be of great use to travellers. One thing, though: are you able to remove the watermarks? --SHB2000 (t | c | m) 04:43, 28 June 2024 (UTC)Reply

This is a vector SVG file, it can be easily edited in any vector editor - Illustrator, Corel, Inkscape))) In two clicks you can delete my logo (signature) Vectormapper (talk) 05:13, 28 June 2024 (UTC)Reply

Sure. If you don't mind me asking, what application did you use to create these maps? --SHB2000 (t | c | m) 08:49, 30 June 2024 (UTC)Reply

Adobe Illustrator Vectormapper (talk) 18:04, 30 June 2024 (UTC)Reply

These maps look very cool and I've been looking for an excuse to dive into creating maps (like district maps for some of our cities). I can use one of these files as a starting point on my learning trail.....thanks! Mrkstvns (talk) 15:49, 28 June 2024 (UTC)Reply

Thank you for your kind words. I am very glad that my cards were useful to you Vectormapper (talk) 18:16, 28 June 2024 (UTC)Reply

I'm so glad you are here. We really need more people who understand maps.

You might also be interested in these pages, too:

• Wikivoyage:Requests for maps
• Wikivoyage:Mapmaking Expedition
• Wikivoyage:Regions map Expedition
• Wikivoyage:Map

For these pages and their talk pages (separately), if you look in the "More" menu, you should see a "Subscribe" link. If you click that, any time someone posts a signed comment on these pages, you'll get a notification, even if you're at Wikipedia instead of here. WhatamIdoing (talk) 04:58, 30 June 2024 (UTC)Reply

Thanks))) It's so interesting))) I hope, I can help somebody with maps))) Vectormapper (talk) 05:35, 30 June 2024 (UTC)Reply

I went to this link Wikivoyage:Requests for maps - I have almost all of these cards that are requested here in more or less finished form. Something is ready and published on Wikimedia (for example, Zurich, Canberra, Edmonton). I did not understand how to answer the request on this page. My answer should probably just be a link to a Wikimedia-published map of a city or region? But there is no "reply" button on the page? Or did I misunderstand something? Vectormapper (talk) 05:51, 30 June 2024 (UTC)Reply

It looks like most of the requests are unsigned. Feel free to use the [Edit] or [Edit source] button for each section. You'll have to manually add a signature by typing ~~~~ at the end of your message.

Or (I think) you can add the maps directly to the listed articles, and then remove the request from the page. WhatamIdoing (talk) 22:40, 30 June 2024 (UTC)Reply

Hmmm I will try Vectormapper (talk) 02:48, 1 July 2024 (UTC)Reply

https://commons.wikimedia.org/wiki/File:Charlottesville_Virginia_US_street_map.svg Vectormapper (talk) 21:35, 28 June 2024 (UTC)Reply

Saint Petersburg, Russia street map https://commons.wikimedia.org/wiki/File:Saint_Petersburg_Russia_street_map.svg Vectormapper (talk) 05:31, 3 July 2024 (UTC)Reply