User talk:AndreeBot

From Wikivoyage
Jump to navigation Jump to search

Is now large enough sample for feedback. --Traveler100 (talk) 12:15, 3 March 2018 (UTC)[reply]

Bot flag[edit]

You are doing a good job, but this is filling up my watchlist. Please could you set the bot flag so that these edits can be filtered out. In any case it would be good to space things out so that it took a week or two to cover the whole site. Thanks for the good work. AlasdairW (talk) 13:22, 3 March 2018 (UTC)[reply]

stop test[edit]

! Andree.sk (talk) 14:54, 3 March 2018 (UTC) !! Andree.sk (talk) 15:03, 3 March 2018 (UTC) ...[reply]

Edits not marked as "bot"[edit]

For some reason the edits are not marked as "bot". Is this on purpose? Hobbitschuster (talk) 18:57, 3 March 2018 (UTC)[reply]

If I'm not mistaken, the bot flag can only be added by a bureaucrat, such as User:Ikan Kekek or User:LtPowers. —Granger (talk · contribs) 19:04, 3 March 2018 (UTC)[reply]
Yup, I think so too... for now I'll stop the bot (mainly to not flood the log) and try out other stuff (region lists/city listings etc.). Andree.sk (talk) 19:28, 3 March 2018 (UTC)[reply]
I'm a new bureaucrat and don't know how to do this. Powers, please explain how this part of my role works. Ikan Kekek (talk) 08:23, 4 March 2018 (UTC)[reply]
Technically, I'd guess you just have to add AndreeBot to the Bots group? Dunno about the 'voting process' rules. Andree.sk (talk) 09:40, 4 March 2018 (UTC)[reply]
Ikan Kekek, I believe you can do it at Special:UserRights/AndreeBot. However, I would suggest that we wait until Andree.sk has a chance to run a sample of the other tasks (city lists and region lists) and get feedback before we turn on the bot flag. —Granger (talk · contribs) 16:36, 4 March 2018 (UTC)[reply]
I will. Ikan Kekek (talk) 21:17, 4 March 2018 (UTC)[reply]

Creating pages ?[edit]

Mistake or test?

--Traveler100 (talk) 18:48, 4 March 2018 (UTC)[reply]

Please delete those, it was a bug (kind of)... Thanks for the heads-up! Andree.sk (talk) 19:25, 4 March 2018 (UTC)[reply]

Wikidata links[edit]

Thanks for adding the Wikidata links to a load of articles. I thought that I would let you know that I have undone three of these on Kinlochbervie‎, Kelso (Scotland)‎ and Berneray‎. In these cases the listing was for a monument or museum about a person, but the Wikipedia article was about the person. I think that it is fine to have the link to WP in these cases, but we should only add the WD link if the WD topic is the monument or museum. (An extreme example might be a monument to a battle, which might be in a quite different location to the battlefield.) I would be interested in your thoughts on this - maybe I overreacted. AlasdairW (talk) 21:00, 25 April 2018 (UTC)[reply]

It seems to me, you acted properly. Ikan Kekek (talk) 04:40, 26 April 2018 (UTC)[reply]
The thing is, I don't see a way I could find this out automatically - all I can do is try to avoid your articles in the future... IMO the WP/WD links should be 1:1 (in the future, WP may be derived automagically from WD). And even more generally, WP/WD in listings should point to info about the subject, not some related stuff? If we want to do this (e.g. add a person WP link(s) for a statue), perhaps the better place for this discussion is Wikivoyage_talk:Links_to_Wikipedia#Time_to_revise_this_article? Andree.sk (talk) 05:45, 26 April 2018 (UTC)[reply]

Adding missing co-ordinates?[edit]

I see you list "Outlook of our work to be done: if a listing has wikipedia entry, add wikidata link + update fields; check how much the lat/long differs (if more than by few meters, skip it - maybe we are pointing to entrance, whereas wikidata to the object)." but what happens if we're missing the co-ordinates entirely?

Wikidata sometimes has co-ordinates we can use, for instance this edit was made by opening the listings editor and clicking the retrieve info from Wikidata link after your bot had obtained the WD link from WP. Perhaps this lookup could be automated as part of your process? K7L (talk) 18:11, 3 June 2018 (UTC)[reply]

Hi @K7L:! Actually, I think I'll reconsider this point in favor of Wikivoyage:Travellers'_pub#Marker/Listing_templates_with_wikidata_support. In short - the 'update from wikidata' thing won't be even needed, because the missing items will be filled automatically. The german WV already has such feature (and should/will be ported to EN WV eventually), I have implemented it also into our marker/listing template (for the time being) - just need some testing before putting it to operation... In the end, it would probably even make sense to remove the duplicate data from WV listings (if the same is in WD), but that idea might be too controversial for now :) Andree.sk (talk) 19:19, 3 June 2018 (UTC)[reply]

Mapframe[edit]

@Andree.sk: A lot of the maps being added are not zoomed in properly, and there are also some issues with where the {{mapframe}} wikicode is being placed (a good example of both of these is Central Russia). I know these can be fixed easily enough, but am just making sure you're aware of the issue, and wonder whether you can somehow prevent the bot from making these errors in the first place? Best wishes, ThunderingTyphoons! (talk) 14:13, 8 July 2018 (UTC)[reply]

@ThunderingTyphoons!: - Hi! The mapframes added are supposed to be automatical - basically they should show all markers+mapshapes in the article. If they do not, it's most likely this issue, reloading the page (Ctrl+Shift+R) should help... Regarding the placement, it's hard to decide how to do it automatically. Basically I go through the changes and adjust manually where it looks "strangely". E.g. like this. I was thinking about making this automatic, but each article has some nice specialty, it seems... :) I'll give it a second thought... Andree.sk (talk) 14:28, 8 July 2018 (UTC)[reply]

Duplicate maps[edit]

Swept in from the pub

User:Andree.sk and their bot have been adding dynamic maps to a large number of country and region articles. When the article doesn't already have a map, I think this is generally a good thing. But in many cases it results in the article having two maps showing basically the same information (see Green Spain and Great Plains for two examples). To me this seems like unnecessary clutter. What do other editors think? Is it desirable to have two maps in these articles? —Granger (talk · contribs) 00:49, 10 July 2018 (UTC)[reply]

I think we should pick one or the other. Having two maps is redundant. The dog2 (talk) 01:23, 10 July 2018 (UTC)[reply]
Agreed with Granger and The dog2. I've been reverting the bot edits for articles that already have up-to-date static maps. -- AndreCarrotflower (talk) 01:55, 10 July 2018 (UTC)[reply]
I disagree Dynamic and static maps just serve two different purposes. The dynamic maps do not look as good in print, which is important. Obviously, if we're going to have one or the other, have dynamic but virtually any guide is long enough to accommodate both. —Justin (koavf)TCM 02:01, 10 July 2018 (UTC)[reply]
I recall this issue has arisen before at Talk:Adirondacks#Maps. I believe the resolution was to link to the dynamic map with {{PoiMap2detail}} and display the static map inline? K7L (talk) 02:42, 10 July 2018 (UTC)[reply]
@Koavf: What's the benefit of adding a dynamic map to a region article when it already has an up-to-date static map? —Granger (talk · contribs) 04:03, 10 July 2018 (UTC)[reply]
@Mx. Granger: Scrolling/panning/zooming. —Justin (koavf)TCM 04:44, 10 July 2018 (UTC)[reply]
The dynamic maps can be zoomed to get additional info (like roads, gas stations or hotels). Thanks to the wikidata, some 60-80% of the city listings show image on clicking (which is good for me, if I want to decide where to go in that region, without reading all the NN city articles). The wmflabs maps don't seem to work so nicely... Unfortunately the inline dynamic maps can't be currently shown offline - which is where the static one comes handy. In the end, I thought that's the whole point of {{mapframe}} param staticmap... So I'd much rather have both maps - as it was said above, there's enough space and the maps serve different purposes. Andree.sk (talk) 05:07, 10 July 2018 (UTC)[reply]
Another related topic - the maps and wikidata show that many articles refer to cities in wrong regions, or even countries (Minas in Cuba) :) Or duplicate region usage, or incomplete region coverage Latin America.... Andree.sk (talk) 05:07, 10 July 2018 (UTC)[reply]
Yes as an aside this is an issue that was brought up earlier concerning and verifying coordinates. Wikidata has 2 entries for Minas (same title) -- probably should be Minas (Uruguay) and Minas (Cuba) - have to do some scrunge work to get the correct ID and coordinates. -- Matroc (talk) 01:45, 15 July 2018 (UTC)[reply]
Static maps are being defended with the argument that dynamic maps don't print well on paper, but do we have actual statistics on how many users still print articles and/or maps? Dynamic maps are so much more convenient: they are zoomable, they show thumbnail pictures with POIs to make them easier to find, and clicking on a listing marker shows its location on the map straight away. They also update automatically when listings are added or their order modified, whereas static maps require a lot of manual labor.
Static maps seem a relic from the time when we didn't have dynamic map functionality embedded yet. However, I do want to emphasize that the one condition for switching to dynamic maps completely should be that they also work perfectly in offline mode, so that articles with dynamic maps can be saved as HTML files and consulted on a laptop/tablet/smartphone in areas where there is no interent access. ArticCynda (talk) 08:02, 10 July 2018 (UTC)[reply]
"the one condition for switching to dynamic maps completely should be that they also work perfectly in offline mode". I don't think this will happen at all due to the nature of dynamic maps as an online beast... Sort of like having an html file with a link to the home page of 'The Statue of Liberty' and being offline trying to connect and view it. -- Matroc (talk) 01:53, 15 July 2018 (UTC)[reply]
  • (indent) The regional dynamic maps are eye-sores. They're so blobby and unattractive; Look at Chugoku. The static map is way better looking. I think for countries and regions, the static maps are far superior. These articles aren't meant for you to zoom into a city; you're supposed to click the city for that. People should use the dynamic maps on the city articles to zoom in/out. It's much more useful there. If there are reasons to use the regional article for zooming, the coloring makes it really difficult to read. The dynamic maps are definitely more user-friendly (as they don't require any knowledge or skill to add/update), but the static maps are so much more professional-looking and welcoming in the regional format. ChubbyWimbus (talk) 11:21, 10 July 2018 (UTC)[reply]
Chugoku map is a bit ugly. Appears that water area has been included in OSM. Does need more work. I remember a similar issue with Monaco that reaches out into the Med... -- Matroc (talk) 02:03, 15 July 2018 (UTC)[reply]
  • Pages which may be printed and carried for travel are among the stated goals of the project. The dynamic maps still have a long way to improve before they can replace static maps for upper level regions. The code needs to change to label cities with city names instead of numbers, to turn off extraneous details from the base map (so that we're not showing both our markers and OSM's points of interest) and to properly label the various shaded regions. We still have no way to change the icons based on POI type and the numbering won't go past 99. They also need to work properly in hard copy, as well as in the various e-book formats (.epub, .mobi, .pdf) and third-party apps. We're not there yet and, if WMF has disbanded the maps team which had been working on fixing mw:Extension:Kartographer, this won't change in the foreseeable future. Dynamic maps are good for handling things that change often (such as individual city-level POI's) but perform poorly for anything more than a bottom-level region. K7L (talk) 14:13, 10 July 2018 (UTC)[reply]
The kicker is that even if all the issues with dynamic maps were magically fixed tomorrow, those that depict countries and regions will still, by definition, never be more than equally as good as static ones. The advantage of dynamic maps are that they are far easier to edit than static ones, which makes them preferable in bottom-level destinations because they cover things that are transient - i.e. businesses which open and close on a constant basis - and thus need to be updated frequently. By contrast, how often do national borders change? The names of cities? The trajectories of roads or railways? The location of mountains or other geological features? Not never, but infrequently enough that our few static mapmakers have never had trouble keeping up with the workload, and indeed our site still has many static country and region maps that have never been edited since being uploaded and yet are still perfectly up to date. There is no information on dynamic country or region maps that static maps don’t have, and there is no functionality relevant to country or region articles that dynamic maps have and static ones don’t. I think having a bot make these unnecessary edits that basically do nothing more than clutter up pages with extraneous visual cruft while providing no real gain to the reader was an ill-conceived idea, and these edits all need to be undone. — AndreCarrotflower (talk) 17:19, 10 July 2018 (UTC)[reply]
I absolutely agree with you on that one, AndreCarrotflower. Could we agree to have static maps for articles that do not include volatile POIs like museums, restaurants, or hotels? Following that logic, can we agree to remove the static map requirement for upgrade to Star nominations? ArticCynda (talk) 17:57, 10 July 2018 (UTC)[reply]
I'm happy with that suggestion. I think we should use static maps for anything above the city level, as well as at the city level for cities that have been district articles. Country level maps should most certainly be static because administrative divisions of a country generally don't change very often, the exception of course being very small countries like the Vatican City, where the entire country is basically the size of a city neighbourhood elsewhere. The dog2 (talk) 18:01, 10 July 2018 (UTC)[reply]
Dynamic maps for country and region articles are better than no maps at all. What I object to on such articles are dynamic maps replacing, or existing side-by-side with, static maps. Regarding attaining Star status, I have long said that the static-map requirement should be eliminated across the board, for both country/region articles and bottom-level destinations alike, but I see that as a separate issue. -- AndreCarrotflower (talk) 18:04, 10 July 2018 (UTC)[reply]
I agree that dynamic maps are not desirable for countries and regions with good static maps. They're harder to read and ugly, and unfortunately the bot is not very good at deciding where to place them in articles. The proposal to remove the static map requirement for star status should be discussed at Wikivoyage talk:Star articles. ThunderingTyphoons! (talk) 19:36, 10 July 2018 (UTC)[reply]
Guys...
  • A picture is worth a thousand words. You can write a walls of text (like I did below), but trip planners will show you a page of pictures and you know what to do- without spending half a day reading through.
  • You can't interact with the static maps. Also, there are ~3500 region articles, are there static maps for at least 10% of them? And then, these are mostly only the country-level + bigger region maps (like states in USA, or counties of Italy). Often I have found maps like in Adirondacks - which use the same color hue for all regions, so it's really unpleasant to use. Even more than the above mentioned Chugoku (which could be probably polished a bit, but I don't have the energy/time to do it for all 3500 articles, obviously ;-) ). There are consistency issues with the static maps designs, let's not go there now...
  • (IMO) most/all region articles should function as a kind of 'preview' of the region. Is that agreed? It should summarize the most interesting POIs there - esp. cities/see/do (though currently, only cities and national parks are usually included). We don't have any 'ratings' nor a way to show e.g. 'region heatmap' of the places with most listings. This is no match for tripadvisor or even travel.sygic.com. I started adding the dynamic maps to add something useful on top of what WT already has. Otherwise, what's the point of coming here - if you say that the base regions are +/- the same? ;-) Adding the dynamic maps into most of the regions will help the visitor, esp. if we slowly modify them to look like e.g. Prague, Paris or Central Slovakia. You can click the POIs and get a feeling if there's something around for you... OTOH, check Viti_Levu or Zambales. What good is this for? How is this better than just googling "CityXYZ travel guide" (and thus 99% not ever getting to WV)?
Neither Viti_Levu nor Zambales have a dynamic map. I would imagine if a dynamic map was added and coordinates for the cities and other destinations (POIs) were added it might improve somewhat. -- Matroc (talk) 02:13, 15 July 2018 (UTC)[reply]
  • Same with the city static-vs-dynamic map talk. Check Paris - the static map is OK, probably ok-ish for orientation, but you will have no idea where to go. Once you check the map with "See" POIs - voila, you will likely spend most of the time in the 1st arr. Without the top-level markers/hints, you can go have fun and spend 1/2 day figuring out where is what. I'd rather just use TripAdvisor. The same with reverted Bay Area.
  • Obviously, this is manual work for many years. But if we don't use the dynamic maps, WF won't have a reason to allocate resources to improve the maps etc. Chicken-egg problem, I guess? ;) We have to work with what we have, hope for the best in the future (many things to be fixed though, like User:K7L said), IMO... I won't run the bot on the second 1/2 of the regions until this is resolved - but for the love of God, don't go on a revert rampage, just for the sake of "good old ways" or whatever :-/ The bot is not perfect, it's meant to do the repetitive work. Obviously, it cannot fix random issues. Andree.sk (talk) 20:22, 10 July 2018 (UTC)[reply]
Someone wrote, "[dynamic maps] that depict countries and regions will still, by definition, never be more than equally as good as static ones". I disagree with that claim. Shall we maybe compare definitions?
My current definition of a good region map is one that lets me determine whether a city or (US) county is present in a given region. So here's a hand-crafted region map: File:Iowa regions map.png. Please let me know if you can figure out which of Iowa's 99 counties are in which of these eight regions. I have looked for a list and been unable to find one. Do the Amana Colonies fall into the green bit or the orange bit? The top-rated college is in Grinnell; which region is that? Pella is an important tourist destination, especially for people with Dutch connections. Where's that on this map? Does it help if I tell you that it's south of Marshalltown, right where the line divides between the purple and light-green regions? The Grotto of the Redemption attracts Catholic pilgrims to a tiny town. Maquoketa Caves is somewhere in Iowa. The Field of Dreams is in Dyersville, population 4,000. Can you figure out which region any of those attractions are in, with this region map?
I could go on, but I think you get my point: this is a perfectly good region map, and it is still wildly deficient – wildly deficient by design – if you are trying to figure out which region contains the attraction that you want to visit. All else being equal, a dynamic map that shows you the regions (which Iowa doesn't have) and then lets you zoom in to verify that the thing you want is in the orange bit instead of the green bit is preferable to a static map that leaves you guessing. WhatamIdoing (talk) 21:05, 10 July 2018 (UTC)[reply]
If you want to know which Iowa region the Amana Colonies fall into, simply go to the Amana Colonies article and the breadcrumb tree directly above the pagebanner will tell you. That's a far simpler solution than zooming in on Iowa's dynamic map and clicking and dragging around until you find the needle in the haystack. -- AndreCarrotflower (talk) 21:48, 10 July 2018 (UTC)[reply]
Which works if your destination is a city that we have an article about and you know about the breadcrumb trail. That method works poorly if you're looking for Dyersville, even if you have a general idea of where the famous baseball diamond is located. That example is not hypothetical: figuring out where to put some of the Iowa attractions has taken me far longer than it should have, simply because there was no way to figure out what locations were included in each region of that static map. Field of Dreams, BTW, has been added to two of the region articles, so presumably I'm not the only person who has trouble figuring out where it belongs. I personally believe that it's three miles east of the region border, but how could anyone find out for certain? WhatamIdoing (talk) 00:19, 11 July 2018 (UTC)[reply]

────────────────────────────────────────────────────────────────────────────────────────────────────Summarizing the discussion so far, in an attempt to integrate everyone's thoughts:

  1. Dynamic maps are the preferred map type for city/district level articles: ability to update automatically when listings change; they allow interaction (zooming, show POI images, switching on/off map layers etc.); better maintenance overview for us. (from Andree.sk, ArticCynda)
  2. Dynamic maps should be improved on the software side to improve offline viewing and rendering in prints. (from Justin, ArticCynda, Andree.sk, K7L)
  3. Static maps are generally preferred for country/region articles with little or no dynamic content. (from ChubbyWimbus, AndreCarrotflower, The dog2, ThunderingTyphoons!)
  4. Any map is better than having no map at all. (from Granger, AndreCarrotflower, ArticCynda)
  5. Articles should only have one map type (a static is preferred at country/region level, and a dynamic one at city/district level). (from Granger, The dog2, AndreCarrotflower)

From which a few follow-up questions arise:

  • Do we need better tools to speed up the creation of static maps or modify their template to make them more attractive?
  • What do we do with city/district articles that already have a crude static map (keep as legacy, or remove in favor of a dynamic one)?
  • How do we coordinate/implement/push technical improvements to dynamic maps?

Most of us agree that the implementation of neither the static nor the dynamic maps is perfect, and both require technical improvements, but IMHO that shouldn't prevent us from reaching a compromise on in which direction we want the WV map system to evolve. Waiting for technical improvements that may or may not be implemented some time in the distant future de facto stalls WV into a state of inconsistency, which I dislike. ArticCynda (talk) 08:56, 11 July 2018 (UTC)[reply]

All the numbered points of ArticCynda's excellent summary seem to logically cohere, and I think they are all reasonable and desirable.
One thing I would add that's not quite right with one of Cynda's questions is this: even if there is no dynamic mapframe included in the article, clicking on the POI number opens a map showing the clicked POI and those of the surroundings.
As an answer to one of the other questions, my opinion is that a crude static map on a city article would be best replaced by a dynamic map. ThunderingTyphoons! (talk) 11:16, 11 July 2018 (UTC)[reply]
I wasn't aware that clicking on markers opens up a map even if there is no map frame on the page, thanks for pointing that out ThunderingTyphoons!! I've removed that question from the summary accordingly. ArticCynda (talk) 12:29, 11 July 2018 (UTC)[reply]
Unfortunately, you cannot change the background layer for those maps, it seems... :-( Andree.sk (talk) 13:23, 12 July 2018 (UTC)[reply]
I'm not sure that one map is always the best answer. California has a static map in the main place, followed by a dynamic map under ==Cities==, and, at least for larger articles, I think that might be a valuable combination (easy way to see the overall picture, followed by an easy way to find where that particular listing is). WhatamIdoing (talk) 19:19, 11 July 2018 (UTC)[reply]
If California's static map doesn't include everything listed in the "Cities" and "Other destinations" section, that's a reason to update the static map (which, again is a need that comes up infrequently enough that we've never had a problem keeping on top of it), not a reason to clutter up the screen with two maps that are mostly redundant to each other. We have a policy of minimal use of images, and I think a reasonable reading of that policy would hold maps to be equivalent to images for such purposes - if anything, it requires more bandwidth, and is more of an impediment to those on slow-speed connections, to display a dynamic map than a static image thumbnail. -- AndreCarrotflower (talk) 20:31, 11 July 2018 (UTC)[reply]
Wikivoyage:Map#Should I replace a dynamic map with a static map? does permit both a static and dynamic map "Consider creating a static map which complements the dynamic map, for instance showing the main central sights and is placed below the dynamic map." I think that in the case of regions, a good comprimise would be to choose only one map to be large and make the other a small thumbnail. There are many regions where the static maps have not been updated to show every village that now has an article, but the static map still gives a clear overview of most places in the region. My preferred approach for bottom level regions would be to use a mapmask to show the region borders and then use the destinations layer to automatically show everywhere that has an article, but unfortunately the layer parameter is disabled in mapframe. This would mean that cities would always show on the map even if they were only created last month and haven't been added to the article yet (destinations take a few days to appear after adding geo to the article). AlasdairW (talk) 23:12, 11 July 2018 (UTC)[reply]
Except in the case of second-from-the-bottom-level destinations, static region maps should not show literally "every village that now has an article". They should show subregions, if applicable, and the 7±2 destinations listed in "Cities" and "Other destinations". I'm sorry, but I'm simply not going to be convinced that it's ever appropriate or consistent with our policy on minimal use of images for an article to have both a static and a dynamic map. If Wikivoyage:Map says differently, then that page needs to be brought into line with the rest of our policy and with the consensus that's quickly emerging out of this discussion. -- AndreCarrotflower (talk) 03:50, 12 July 2018 (UTC)[reply]
"consensus that's quickly emerging" - where do you see it? :) Anywho, just to prove the point - I randomly checked static maps of Italy, Spain, Russia (UK looks ok, TBF), arguably quite high-ranking countries. Go check how many of the markers are actually in the static map, and if some of those maps were updated in the past 5 years. The point is - there are very few editors who even semi-regularly update those. If you want to do it, by all means let's just have static maps. Otherwise, the static maps are really only good for general overview and for print, but using them for any real decision making (as was shown above by WhatamIdoing) or for navigation through our site is mostly self-torture. Andree.sk (talk) 06:23, 12 July 2018 (UTC)[reply]
Central Slovakia is an interesting case study. Both the dynamic and static maps do some things better than the other. The dynamic map gives you quick snapshot of where the interesting things are (generally the northern part of Central Slovakia has more points of interest than the southern part). You can zoom in and out to get a deeper sense of distance and direction. You can click on the number and see an image relating to that destination (a kind of cool preview). The dynamic also provides a marginally better indicator of the topography of the region. On the other hand, the static map colour-codes the subregions. The names on the map for the cities and regions can be written flexibly, like Horehronie on an angle, to fit within the map which means that from a far zoom, there are many more words and descriptions on the map about Central Slovakia's geography, even including the names of the rivers and bordering countries. And the font is much more beautiful. The best map would combine all of these features into one. Both maps are about equal in terms of the road networks shown. Gizza (roam) 09:59, 12 July 2018 (UTC)[reply]
Actually, adding those colorcoded regions (for dynamicmap) in this particular page is probably a question of ~5 minutes... I just didn't find the time to do it yet :) Andree.sk (talk) 11:46, 12 July 2018 (UTC)[reply]
Hi Andree.sk, I wonder how you do that in 5 minutes. My approach was to open this map to get the names of the districts and enter them in Wikidata to get their respective ID. Takes forever and is quite cumbersome. Do you have an easier way of doing this?--Renek78 (talk) 15:57, 12 July 2018 (UTC)[reply]
I generally lookup the admin units
Banská Bystrica Region: Q183640 (388270) lat: 48.729722 long: 19.149167 - wv: Slovakia---wv: ----
Bratislava Region: Q183498 (none) lat: 48.143889 long: 17.109722 - wv: Slovakia---wv: ----
Košice Region: Q186295 (none) lat: 48.716111 long: 21.863056 - wv: Slovakia---wv: ----
Nitra Region: Q184548 (none) lat: 48.306944 long: 18.086389 - wv: Slovakia---wv: Nitra (region)
Prešov Region: Q189001 (none) lat: 49.001667 long: 21.239444 - wv: Slovakia---wv: ----
Trenčín Region: Q183139 (388267) lat: 49.222778 long: 18.739444 - wv: Slovakia---wv: ----
Trnava Region: Q181342 (none) lat: 48.377500 long: 17.588333 - wv: Slovakia---wv: ----
Žilina Region: Q184228 (none) lat: 49.222778 long: 18.739444 - wv: Slovakia---wv: ----
then each region ie. Zilina to get more info...
Bytča District: Q668333 (none) lat: 49.223056 long: 18.558611 - wv: -------wv: ----
Dolný Kubín District: Q665066 (none) lat: 49.208889 long: 19.295278 - wv: -------wv: ----
Kysucké Nové Mesto District: Q762646 (none) lat: 49.301944 long: 18.786667 - wv: -------wv: ----
Liptovský Mikuláš District: Q545302 (none) lat: 49.080556 long: 19.622222 - wv: -------wv: ----
Martin District: Q756665 (none) lat: 49.062778 long: 18.921944 - wv: -------wv: ----
Námestovo District: Q388888 (none) lat: 49.406389 long: 19.483889 - wv: -------wv: ----
Ružomberok District: Q655156 (none) lat: 49.081667 long: 19.304444 - wv: -------wv: ----
Turčianske Teplice District: Q548293 (none) lat: 48.863600 long: 18.863300 - wv: -------wv: ----
Tvrdošín District: Q756899 (none) lat: 49.333611 long: 19.555000 - wv: -------wv: ----
Čadca District: Q836173 (none) lat: 49.438056 long: 18.789722 - wv: -------wv: ----
Žilina District: Q836201 (none) lat: 49.220833 long: 18.740556 - wv: -------wv: ----
You can also retrieve a Wikidata ID of any wv article directly by name if it exists in wv. ie. The Wikidata ID for Central Slovakia is: Q1541057 (wikibase command?) (One could I imagine use an api or query etc.) -- Matroc (talk) 03:15, 15 July 2018 (UTC)[reply]
Renek78, yep, that's basically it... Last time I tried to prepare this in OSM, most of the regions matched 1:1 with groups of current regions (but it doesn't work, because the relations would have to contain the boundary ways... {{mapshape}} cannot work with these super-relations, which just group other relations like Liptov above). Anywya, AFAIR mostly the western-south regions were crossing middle of current regions. Maybe 5 minutes is too little, but definitely 10-20x less than it would take me to prepare the static map :) Andree.sk (talk) 16:28, 12 July 2018 (UTC)[reply]
I would also like to know how to draw up static maps so easily. I've never made a static map, and like many other Wikivoyagers, I'm interested in learning the fastest way to do it. The documentation page is quite confusing, in that matter. ArticCynda (talk) 16:14, 12 July 2018 (UTC)[reply]
  • This discussion was taken off the shelf again, dusted off and revisited. I thought the question was about duplicate maps until I started to read further. Yes there are problems but not necessarily with dynamic maps but as a result of underlying issues with Wikidata, OSM etc. Cherry picking one or two articles with a dynamic map is not in my opinion indicative or truly representative for every article. The question I would ask myself would be "Can I fix it? How? and Where can I get help to do so?". -- Matroc (talk) 02:44, 15 July 2018 (UTC)[reply]
  • Yup, I think a week later we moved nowhere... So unless there's a big opposition, I'll just finish the last 1/3-1/2 of the pages to make it all uniform - and we can discuss in the meantime, if there's something more to be said. OK? Andree.sk (talk) 19:12, 16 July 2018 (UTC)[reply]
-) Andree.sk (talk) 19:23, 16 July 2018 (UTC)[reply]
We have a status quo bias on this site, and a clear majority who are against having duplicate maps in articles (myself, Granger, The dog2, ArticCynda, ChubbyWimbus, and ThunderingTyphoons vs. only you, Justin, and WhatamIdoing in favor; other editors have commented in various ways but have not taken a clear stand one way or the other). No, a majority is not a consensus, but in a case where said majority is in favor of a preexisting status quo, that's a pretty clear indication that you need to hold your horses. -- AndreCarrotflower (talk) 19:28, 16 July 2018 (UTC)[reply]
I am also in favour of dynamic maps when they are useful, and see no problem with having both static and dynamic maps in the same article providing that each must serve a useful purpose to the traveller. • • • Peter (Southwood) (talk): 19:47, 16 July 2018 (UTC)[reply]
Peter, we're talking about dynamic and static maps that each contain the same information, and specifically about region maps with little or no dynamic content (i.e. national borders, geographic features, and other things that never or rarely change as opposed to "Buy", "Eat", "Drink" and "Sleep" listings that are prone to go out of business, and new ones to open). -- AndreCarrotflower (talk) 19:54, 16 July 2018 (UTC)[reply]
If this is your only issue, I'll skip pages with static maps. I'm looking forward to you updating them, making them clickable etc.! .-) Andree.sk (talk) 20:48, 16 July 2018 (UTC)[reply]
Andre, I haven't seen an example of a page yet that has "dynamic and static maps that each contain the same information". Green Spain has similar information, but the list of cities on the two maps don't match. In Great Plains, the dynamic map has almost twice as many points marked. WhatamIdoing (talk) 05:54, 17 July 2018 (UTC)[reply]
Funny, Green Spain also shows the issue I mentioned above - Santa Lucía is categorized in the wrong region... anyway, time to shine for the local static-mappers :-P *drops mic* Andree.sk (talk) 07:18, 17 July 2018 (UTC)[reply]
Marker Santa Lucia moved to Central Spain (Region) - a clerical error yes, easily fixed YES! -- Matroc (talk) 05:08, 18 July 2018 (UTC)[reply]
The differences that strike me are things like the static map has Lugo, but not Muros, whereas the dynamic has Muros but not Lugo. WhatamIdoing (talk) 17:04, 17 July 2018 (UTC)[reply]
Lugo marker added - edit to remove - see below -- Matroc (talk) 05:08, 18 July 2018 (UTC)[reply]
Cities and Other Destinations are limited by convention to 9 important entries each (avoiding the dreaded long lists) - thus you will only see a limited number of markers on a dynamic region map... You want to see more cities etc. - use zoom to see labels on dynamic map which are not found on a static map... In addition, there is also a way to add more markers without them appearing in these lists on the article page. So for the most part, dynamic maps and static maps in Regions are not identical... Cheers! -- Matroc (talk) 05:08, 18 July 2018 (UTC)[reply]
Rather than making snarky comments, the thing to do if you want to build consensus behind the idea of duplicate maps is to argue your case in a way that addresses the specific objections of those who are against the idea. I have yet to be swayed by any of the arguments subsequent to when I came out against the idea; maybe you'll have better luck with some of the other folks I pinged in my comment above. -- AndreCarrotflower (talk) 17:11, 17 July 2018 (UTC)[reply]
I would opt for dynamic, static or both - depending upon their usefulness in Region articles. As far as individual articles with See, Drink, Do etc. I think dynamic maps are better suited. On the other hand, some articles make much more sense if they use both to provide specific information that is not supplied by any single map. (ie. certain topic sytle articles etc.) -- Matroc (talk) 05:08, 18 July 2018 (UTC)[reply]
I see this discussion has spilled over to a user talk page at User_talk:AndreCarrotflower#Why?. Perhaps that discussion should move here to keep this easier to follow? K7L (talk) 19:00, 19 July 2018 (UTC)[reply]
I think the policy that we should only have one map per page needs revisiting and become a little bit more flexible. Sure, when there is significant overlap they become redundant to each other but when the dynamic and static maps show two very different perspectives of the destination then the traveller will benefit from having both of them there. Gizza (roam) 01:08, 20 July 2018 (UTC)[reply]
I agree there should be flexibility—on a case-by-case basis, there may be articles where it's worth having both types of maps. My feeling is that that isn't the case in, for instance, Green Spain or East China, though I recognize there are good arguments on both sides. —Granger (talk · contribs) 01:25, 20 July 2018 (UTC)[reply]

Here's a list of two/triple-map regions, if someone wants to do cleanup or whatever (I'd say about 1/2 was added by me, before this discussion started)... Andree.sk (talk) 11:07, 21 July 2018 (UTC)[reply]

AndreeBot blocked[edit]

One of the admins feels like I need a lesson, or (s)he fears that I suddenly go on WV destruction rampage (4500 contribs, 1.5 years of following rules and waiting for discussion outcomes ain't enough?; also I don't hide my identity around here, so I'd publicly shame myself that way?!), or changed their mind on whether the stuff done is right. Don't know which option is worse.

Either the changes I'm doing are wanted (I assume they were), or I should stop immediately and the bots work of the past 2 weeks should be reverted - I can accept both. But 2 weeks ban changes nothing (afterwards I'd just continue what I started accepting the above discussion outcome, like I always did). Please sign here whether I should continue or not:

  • Support or Oppose

If the outcome is "yes", I request the responsible admin to remove the ban until the end of this week. Otherwise he can pick the bot source code and finish, because I shure as hell won't ever again. Peace out! Andree.sk (talk) 18:23, 19 July 2018 (UTC)[reply]

I think this whole situation between you two has escalated far beyond what the situation actually warrants and both have attacked the other personally which I think does not make this easier. I think there should be some sort of mediation, but I am certainly not the person to mediate, given my own hot-headedness and whatnot. Would either of you be willing to propose somebody whom you both trust? I think we should really find some sort of amicable resolution and not do a whole "the community must chose sides on this" thing.... Hobbitschuster (talk) 23:12, 19 July 2018 (UTC)[reply]
I'm going to be brief about this because I have a 4AM shift at work tomorrow and need to get to sleep. Yes, I blocked AndreeBot, and the proceedings here on the pub as well as on my talk page provide an acceptable rationale as to why. To recap: a user questioned the desirability of having a bot insert dynamic maps into articles that already had static ones, and as the discussion progressed, a clear majority of participants were of the opinion that articles other than bottom-level destinations should have one or the other type of map, preferably a static one, but not both. After the discussion began to wind down, User:Andree.sk proposed to continue with the edits because "a week later we moved nowhere", whereupon I reminded him/her that, in fact, most people who commented were against the idea. Evidently s/he ignored my admonition and restarted the bot anyway; I caught and reverted one of the edits leading to the above-linked exchange on my talk page wherein Andree.sk indicated an intention to continue running the bot ("What do I care, I'll just leave the bot finish") despite my having reminded him/her yet again of our policies on consensus and status quo bias. At that point, I was contemplating nominating Andree.sk for a user block, which IMO would have been justified given the circumstances, but I decided instead to take a less confrontational route and block only the bot. Please see Wikivoyage:Script policy which indicates that "[bots] should be in accordance with our policies and guidelines" and those that don't "comply to these requirements will be blocked from reading or editing Wikivoyage pages – even if they're not doing any actual harm", so mine was the requisite course of action per policy.
Furthermore, I reject the idea that mediation is necessary or that I ever attacked Andree.sk personally. As self-serving as it may sound, I feel that to suggest that we are somehow equally in the wrong is a false equivalency. My original intention, before the situation escalated, was to let the discussion on the pub play itself out and see if a consensus in favor of duplicate maps might develop after all. In fact, I explicitly indicated a willingness to do exactly that, despite the fact that I personally would have preferred the opposite conclusion. However, faced with a user who clearly had no intention of waiting for such a consensus to coalesce or addressing the concerns of opponents of his/her proposal before forging ahead in defiance of policy, who had acted in a reckless and provocative manner and who made a clear threat to continue such actions, I feel that I did what needed to be done in accordance with the consensus-based way this website is governed. In point of fact, I think the way I went about it - blocking the bot rather than proposing a user ban for Andree.sk him/herself; ignoring sarcastic remarks and attempts at provocation and keeping my comments focused on the substance of the issue - showed a commendable level of coolheadedness and restraint.
-- AndreCarrotflower (talk) 00:26, 20 July 2018 (UTC)[reply]
For the 3rd time. I accepted the current decision and made the bot not add dynamic maps where static already exist. I added one map manually because there it seemed appropriate. Andree.sk (talk) 04:57, 20 July 2018 (UTC)[reply]
I took a look at the last couple dozen edits that the bot made, and I found that it was a very enlightening exercise. Most of the edits inserted a dynamic map into articles that did not have any kind of map. A couple of them inserted a dynamic map into an article, such as Northeast High Country and Northeast Ohio, that contained a static map that didn't name any cities. In a few cases, the bot added the marker template but no map to, e.g., Northeast New Mexico, Northeast (Brazil), and North West England (all of which already had static maps that name cities).
I have so far found only one case, Northeast Missouri, in which the bot inserted a dynamic map into an article that already contained a static map that actually named any cities. This last item is presumably an unwanted edit, and may simply have been a case of overlooking the recent addition of the map to the otherwise nearly empty article. All of the others seem to be basically in compliance with the discussion above: Everyone supports having a map, and I don't think it is too much of a stretch to say that, by "a map", we mean not just any old map, but specifically a map that shows where at least a couple of the main ==Cities== (or other key attractions) for that location are.
For me, then, the question largely becomes whether an 'error rate' in the 3% range is an acceptable 'cost' for getting maps and markers added to a lot of articles that have either no maps at all or that have very limited maps (e.g., showing the location of the region but not the location of anything inside the region). Personally, I'm willing to tolerate a ~3% error rate. Anyone who thinks that those occasional duplicates make the article worse can revert those ~3% of edits, or perhaps preferably remove the mapframe template while leaving the marker templates in place. The bot made 190 edits before being blocked today, so presumably there are something on the order of 10 such cases in the list. That doesn't sound like an unreasonable level of things to process by hand. I might even go see if I can find a few to do myself in a bit. WhatamIdoing (talk) 05:07, 20 July 2018 (UTC)[reply]
The base problem is that the pages use almost 'human language', with many exceptions. Static maps can be added by File/Image tags, they can have name 'southwest nowhere map.png", some 'Ohio counties.png'... It's hard to cover all cases, and so I apparently missed a few (though I tried to be 'generous' and avoid most), so I'd just add more exceptions. Thanks for the review in any case! Andree.sk (talk) 06:22, 20 July 2018 (UTC)[reply]
I don't know what "For the 3rd time" is all about (Plug: previous 2 times: "If this is your only issue, I'll skip pages with static maps."; "I'll just leave the bot finish (only non-AndreCarrotflower-iritating changes (tm))" Andree.sk (talk) 19:22, 20 July 2018 (UTC)); this is the first I'm hearing of the bot being reconfigured to avoid duplicate maps. In any case, that's irrelevant to the edit to Niagara Frontier that I reverted. The consensus is "no duplicate maps anywhere", not "duplicate maps only where it seems appropriate" or "duplicate maps where the static map is out of date and there are no regions drawn".[reply]
I also frankly am very frustrated that none of the people I pinged above who came out early against duplicate maps have returned to give their two cents on the latest developments on this front. Well and good not to want to sound like a broken record if one's opinion hasn't changed from the outset, but we have an administrator whose use of the sysop tools is being called into question, and I feel that there's a silent majority here whose perspective on the situation is not being heard.
-- AndreCarrotflower (talk) 18:59, 20 July 2018 (UTC)[reply]

────────────────────────────────────────────────────────────────────────────────────────────────────I'm not going to say too much, because I don't want to find myself caught in the middle of a debate where one block has already occurred. I'll make clear that I don't strongly agree with either side, and I don't think the bot is actually causing any harm. I don't think there has ever been consensus for either side. I think there are two options; either we

  • Let the bot continue to operate, and not worry too much about duplicate maps, or we
  • Put an indefinite ban on the bot, not ban Andree.sk unless he/she causes significant problems, and we all hopefully continue to use the website peacefully.

I don't think it matters greatly which option we choose. That's just my opinion, I'm of course not the final judge of this. Selfie City (talk) 22:53, 20 July 2018 (UTC)[reply]

SelfieCity - According to our policy on status quo bias, if a discussion about a change to policy doesn’t end in consensus, the previous status quo (in this case, one map per article) remains in effect. -- AndreCarrotflower (talk) 09:05, 21 July 2018 (UTC)[reply]
I disagree with User:AndreCarrotflower's claim that "the previous status quo (in this case, one map per article) remains in effect" as there is no existing policy precluding two or more different maps on a page. We sometimes do need different maps to convey different information (for instance, the multiple links to individual regional maps on the 8,050 km (5,000 mi) Trans-Canada Highway). Conversely, I would suggest that Adirondacks (the first article on your list) be reverted at once as you've replaced a carefully hashed-out compromise (which included a static map inline and a link to a dynamic map, see Talk:Adirondacks#Maps) with a link to a dynamic map, followed by that same map inline, followed by a static map... all of which convey very similar information.
While a robot script might be able to detect that there are two maps on the page, it isn't going to be able to detect whether the maps overlap in content - or by how much. That makes this a task more suited for human intervention than for automation. K7L (talk) 16:00, 21 July 2018 (UTC)[reply]
K7L - yes, but let's distinguish between "duplicate maps" and "multiple maps" (and mea culpa for the clumsy wording of what you quoted from me). There are several valid reasons why an article might have multiple maps. For instance, Underground Railroad is an itinerary article with six different dynamic maps covering various portions of the route plus a seventh one covering the whole route. As another example, Calgary has a dynamic map showing POIs, a static map showing neighborhoods, and another static map showing the light rail system. Those are both fine. The issue here is multiple maps per article showing the same information (and I don't buy that swapping one city out for another on an otherwise identical region map qualifies as "different information"). There may be no written policy against it, but the "one map per information set per article" principle was universal and regarded as common sense on our site before this spate of map duplication began. This all is aside from the fact that the articles targeted by the bot are exclusively region articles, whose maps don't (or shouldn't, according to policy) contain much if any dynamic content. The mere fact that we can now create dynamic region maps with the mapshape feature does not mean dynamic region maps are inherently superior to static ones; in point of fact, for the time being they're inherently inferior to static ones due to the limitations of our current dynamic map technology. -- AndreCarrotflower (talk) 16:47, 21 July 2018 (UTC)[reply]
The question of whether a pair of maps for the same location differ enough to be useful to the voyager is an editorial decision, which needs to be made by human editors on a case-by-case basis. While I don't see these judgement calls as a good task for a robot script, creating additional policy (where instruction creep can be just as arbitrary and just as inflexible) is just as unlikely to be helpful. K7L (talk) 18:33, 22 July 2018 (UTC)[reply]
This dispute has escalated beyond reasonable proportions, and blocking AndreeBot seems an overreaction to a few unfortunate edits (3%) in a huge amount of useful work that would have cost manual editing days or weeks of repetitive page editing. The bots task at evaluating pages is relatively complex, and I acknowledge it added a lot of good maps and dynamic listings to articles that didn't have any map before. So I'd rather spend time on correcting the 3% errors than manually editing the remaining 97%.
That said, Andree.sk, it should be pointed out that a week is not enough time to come to a strong consensus on this kind of high impact issues. I have the feeling the large majority of Wikivoyagers only reads the pub once every few weeks or less on average, so pushing forward changes so fast doesn't give the majority the chance to have their opinions heard. The argument that "the discussion wasn't going anywhere after a week" is therefore a weak motivation to have the bot continue its work while the debate is ongoing. ArticCynda (talk) 11:28, 23 July 2018 (UTC)[reply]

Wikidata coords[edit]

On the whole adding wikidata number to markers has been useful but I am not the only one coming across incorrect entries regarding coordinates. Would it be possible to create a report of when the coordinates on the region page city list, the geo coords on the city page itself and the coordinated in wikidata differ from each other by, say, more than 1km? --Traveler100 (talk) 05:31, 25 July 2018 (UTC)[reply]

Yeah, I also already noticed that sometimes it's quite off, and weirdly in my observations almost always the source of the coords in wikidata was the russian wikipedia...  :-D In any case, I also had a similar idea, so I'll try to put some script like that together and get back here (but I don't expect I'll have time for it until the end of this week). Unless someone else would like to improve their wiki-fu :-) Andree.sk (talk) 06:26, 25 July 2018 (UTC)[reply]
Had another idea on this. Can edit {{geo}} so that it checks the values give against what is in wikidata and if more than 1 km away will add the article to a maintenance category. Have created templated to do the calculations. Will work on the geo update later. Is 1 km (0.62 mi) a good check distance or should it be larger? --Traveler100 (talk) 18:07, 25 July 2018 (UTC)[reply]
There are currently 452 city articles with wikidata coordinated more than 10 km away from the article's geo coordinates. --Traveler100 (talk) 18:09, 27 July 2018 (UTC)[reply]
First random click - Banjul... completely wrong WV geo coords :-) Thanks for preparing this! Andree.sk (talk) 19:34, 27 July 2018 (UTC)[reply]

Bot speed[edit]

As a practical matter, do you all think that it would be easier to review the map changes if the bot ran at a slower rate (e.g., 50 or 100 per day, for however long it takes), or would it be better to get it over with in one big push? WhatamIdoing (talk) 20:59, 23 July 2018 (UTC)[reply]

I think the bot got quite reliable, and the only thing it likes to destroy are region lists. But there were only a few of those, so I reviewed/fixed them already. If you see some other systematic issue, let me know - maybe I can mass-correct such thing. In any case, all regions were now "visited". I have some TODOs left:
  • all the cities/other destinations sections, where all the lines weren't in format '* \[\[City\]\] - description' (e.g. if there was some descriptive text)
  • I'd like to do another pass and add markers for the 'see' attractions (where easily doable)
  • I'd like to process the countries (so far only region articles were)
  • a very hard task - add markers where wikidata exist with the same name, but we don't have an article (or at least link), like this. This would require big amount of manual checks (so, for example, 'Paris' in France isn't matched as Paris in USA), so it'd be probably best to create some kind of 'expedition' for this? But I don't know if anyone is interested in this kind of work (and thus if it makes sense to even consider this task; I for sure cannot review it all by myself)...
    • This could help in future, so we can find articles with missing links, which refer to the same POIs (e.g. if some article refers to 'Eiffel tower' without a link to Paris/7th_arrondissement#Q243). Cross-links are likely good for SEO :-)
    • But perhaps this isn't a good idea, e.g. in Île-de-France it would just add duplicate markers (though I could make the script avoid adding such stuff)...
Andree.sk (talk) 08:10, 25 July 2018 (UTC)[reply]
I would prefer all bots to be limited to 1000 edits per day, with exceptions only made for serous urgent issues like complying with legal instructions. This would allow the whole site to be covered in a month. A bot edit fills watchlists, and it is easy to miss edits that need review when swamped. In this case the bot's edits are more likely to need review so a slower rate would be desirable. I also wish the bot had added the actual lat/longs as well as the wikidata ids, as the markers don't appear on full page maps (see "Wikidata lat/longs" immediately above). AlasdairW (talk) 22:52, 25 July 2018 (UTC)[reply]
Actually, most of the regions is already done, so I don't expect more than 100-200 edits once in a few days (if I find some class of previously missed articles). Adding lat/long isn't a problem, but then it wouldn't be too obvious which coords are copied in, and which are manually checked/added. Of course, we could add something like 'prefer-wikidata=true' parameter for the markers/listings (this would 'mark' markers imported from WD), but... I'd say in the long run it would be best to rather fix the script creating the "full page maps". From my point of view, it's hugely convenient to be able to just add wikidata and have both coords and picture for the attraction. without further copy-pasting or whatever. Andree.sk (talk) 12:38, 26 July 2018 (UTC)[reply]
Count me as someone who prefers a slower bot speed. The bot has created a fair bit of cleanup work when it covers articles on my watchlist.
Regarding the to-do list, I have a couple of comments:
  • Adding See listings to the region maps will potentially obscure smaller region shapes and city markers (e.g., in France and Ile de France, one of Paris and the Eiffel Tower will be visible and the other hidden). The various listing layers can be turned off, although I find this isn't consistent from one article to the next for some reason, and it requires the user intervention. It seems like something that should be tested on a small number of articles to see what the impact is and whether people agree with it.
  • If a bot task is going to require a lot of manual reviewing because it's potentially going to introduce errors or duplicate markers then I'd advise it's not a good idea to run it unless there is a clear consensus supporting it and many people are willing to do cleanup. We're all volunteering our time and have things we want to get done, so cleaning up someone else's errors may not be the highest priority. From your description of the last bullet, it also sounds like it could create long lists that look like yellow pages (violataions of site policies), plus redlinks have been contentious in the past, so I don't see much value in doing it at this point. -Shaundd (talk) 13:51, 26 July 2018 (UTC)[reply]
No, no, don't worry... I made the bot to get rid of manual work. So the idea with the last point was the other way - if we were to do it, I'd probably need a group of people, who'd sign for 'guarding'. And the bot could even run on their request (more ideal would be if the people could use the script themselves, but I realize that probably not many people around here are programmers). Regarding the 'see' listings, I had something like recent Paris stuff in mind. IMO, if we already have those listings in the regions, then adding a marker for them shouldn't be a bad thing, right? Otherwise, the listings maybe shouldn't be there in the first place. But anyway, I don't intend to do this before providing samples, or perhaps we should start a discussion of how an ideal region article should look like (in terms of markers etc.). I have other plans for the following weeks/months, so I might give everyone some slack :-) Andree.sk (talk) 14:29, 26 July 2018 (UTC)[reply]

Wikidata for Snæfellsjökull National Park[edit]

In this edit you changed Wikidata ID for Snæfellsjökull National Park from Q738103 (the park) to Q1315012 (the mountain or glacier). Was that a conscious decision or something about the bot's logic? In the former case you might want to revert my revert (and explain), in the latter the logic may need some tinkering. Regardless, the edit summary gave no hint such a change was made. --LPfi (talk) 15:54, 8 August 2018 (UTC)[reply]

Hi! Unfortunately, there was a bug that did this, always setting the wikidata ID to that of the target article. I tried to manually revert such cases, but obviously I missed some. Fortunately there were not too many markers with wikidata, previously :) I don't really plan to run the bot anymore (at least not regarding this topic, and not so massively), but if I will, I'll surely fix this bug... Andree.sk (talk) 16:07, 8 August 2018 (UTC)[reply]
OK. I changed the couplings on Wikidata for this article. --LPfi (talk) 07:33, 9 August 2018 (UTC)[reply]

Marker without type[edit]

I just noted that the bot does not add any marker type, and worse drops the existing one. Is this intended? See here: Patagonia (Argentina).

Now, the markers under destinations are wildly colored without consistency.

Cheers, Ceever (talk) 20:30, 16 September 2018 (UTC)[reply]

do you have some examples where it removed the types? I only added type=city when it was certain... in the cases like above, I often saw villages and such in the "subtopics"... -- andree.sk(talk) 05:38, 17 September 2018 (UTC)[reply]
Aaahhh, sorry. It did indeed not drop the type, but did not add one. A village still gets a city type though, like articles: city, region, country ... Cheers Ceever (talk) 08:52, 15 October 2018 (UTC)[reply]