Template talk:Attached KML/Archive 1

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Neutrality of documentation

Reverts with edit summaries like "not yours to dictate" are unacceptable; as is a statement like "linear features… cannot be properly represented through a single set of coordinates:", when it is quite clear that there is no consneus that that is the case.

Similarly, the suggestion that we should mark the location of trains with a KML file (and not a point location) is ludicrous. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:11, 9 February 2012 (UTC)

You're right. We should use this on all articles and not just on ones where coord isn't working. Thank you for the revelation. - ʄɭoʏɗiaɲ ^τ _¢ 15:43, 9 February 2012 (UTC)

Use in file captions

The use at Nico Ditch demonstrates that the bullet points do not work when the template is transcluded within an image caption:

[[Image:Nico Ditch in Greater Manchester.png|thumb|center|Caption text here followed by template transclusion.{{AttachedKML}}]]

renders as:

Note the inline asterisks instead of list-item bullets as the wikitext is parsed as a single block within the caption.

This is a relatively minor issue, but I mention it here in case you think it can and should be fixed.

— Richardguk (talk) 13:27, 12 February 2012 (UTC)

I am not sure this is really a good use of the template, and not really what I had in mind for it—this template was designed mostly to live in the external links section to provide links to maps of the article subject. If there is a demand for a compressed output that could be used inline (and thus work in image captions) perhaps we could have someone code a parameter that would enable that. —Scott5114 ↗ [EXACT CHANGE ONLY] 14:43, 12 February 2012 (UTC)

I've fixed it so that it works now in both (but the dots are slightly smaller) - ʄɭoʏɗiaɲ ^τ _¢ 15:20, 12 February 2012 (UTC)

That's great, I wasn't sure whether it was fixable. But the revised version loses the "unnumbered list" semantic (and any CSS that might be intended for lists), so I experimented and found that you can use raw HTML for bulleted lists in wikitext, like this:

[[Image:Nico Ditch in Greater Manchester.png|thumb|center|Test caption. <ul><li>test1</li><li>test2</li></ul>]]

which gives:

So perhaps the template text could be further revised to replace

{{*}}[http://maps.google.com/maps?q=http://en.wikipedia.org/w/index.php?title=Talk:{{PAGENAMEE}}%2FKML%26action%3Draw Display on Google Maps]
{{*}}[http://www.bing.com/maps/default.aspx?mapurl=http://en.wikipedia.org/w/index.php?title=Talk:{{PAGENAMEE}}/KML&action=raw Display on Bing Maps]

with:

<ul><li>[http://maps.google.com/maps?q=http://en.wikipedia.org/w/index.php?title=Talk:{{PAGENAMEE}}%2FKML%26action%3Draw Display on Google Maps]</li><li>[http://www.bing.com/maps/default.aspx?mapurl=http://en.wikipedia.org/w/index.php?title=Talk:{{PAGENAMEE}}/KML&action=raw Display on Bing Maps]</li></ul>

Sorry for not proposing this at the same time as raising the problem; the workaround only just occurred to me.

— Richardguk (talk) 17:25, 12 February 2012 (UTC)

That works. It's the same as what Mediawiki does with a new line that begins with an asterisk, but gets rid of the first character rule. - ʄɭoʏɗiaɲ ^τ _¢ 17:33, 12 February 2012 (UTC)

Integrating KML with Wikipedia

Further to the discussion at Wikipedia talk:WikiProject Highways#Parsing KML:

Brilliant work producing such a useful template (and thank you for rising above the intemperate remarks by other editors at Wikipedia talk:WikiProject Highways#RFC on coordinates in highway articles).

I assume that you're using the Talk namespace because article namespace is configured not to allow subpages. But that means there is no talk page for anyone wanting to comment specifically on the KML subpage, and also the KML text does not display well when the subpage is viewed (note that the MediaWiki software automatically formats *.css and *.js subpages to display with code formatting, but *.kml pages are not currently covered).

Would File namespace be more appropriate? A convention could be established that, by default, KML files were named consistently with the article name, or redirects could be used so that the KML file could be linked via the article name. This would also make it easier (in exceptional cases) to specify names to link to more than one KML file per article, and to share a single KML file with multiple articles. Instead of using the "raw" parameter to pass the code to external sites, the file URL could be passed instead using the filepath: magic word. (At present, the only permitted file types on enwiki and Commons are: png, gif, jpg, jpeg, xcf, pdf [enwiki only], mid, ogg, ogv, svg, djvu, tiff, tif, oga.)

More trivially: The template name would be more conventional if it had a space in: {{Attached KML}}, so it might best to rename it before it becomes widely known. Or, once the prototype is agreed, would it be simpler for editors if the new KML functionality is accessed via additional parameters in {{Coord}}? In some cases, if not all, editors will want to embed both types of data, and you have already experience problems with the two templates overlapping, so a joint template might be best once the initial template code here is stable.

Whether the templates remain separate or are combined, I would suggest retaining at least Coord mid-point data in all articles for the time being, because this is how Google Maps and similar services are locating the articles and readers will lose out if the existing method ceases to be used.

— Richardguk (talk) 23:18, 7 February 2012 (UTC)

{{Coord}} can already be used to generate KML; see any page using it with {{GeoGroup}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:57, 9 February 2012 (UTC)

{{coord}} is limited to 200 coords on Bing, and cannot be placed in the title in place of some arbitrarily chosen point. - ʄɭoʏɗiaɲ ^τ _¢ 15:44, 9 February 2012 (UTC)

There is no limit to the number of KML PoIs which can be generated by using multiple instances of {{Coord}}, except for the maximum number of template transclusions. I have yet to see a case of anyone suggesting using that number of instances for PoIs on an article. no doubt you will let us know if you have. {{Coord}} has a title display which can be used to centre the linked maps on any point on the globe. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 9 February 2012 (UTC)

Bot-related discussion of issues such as appropriate namespaces for KML code: Wikipedia:Bots/Requests for approval/DschwenBot. — Richardguk (talk) 22:23, 29 February 2012 (UTC)

KML pagenames

Proposal moved from Wikipedia:Bots/Requests for approval/DschwenBot#Further discussion:

Having agreed that Template subpages are currently better than File pages and uploads, should the subpage name include ".kml" at the end? This might help downloaders assign an appropriate file extension (or mime type). It might also make KML pages easier to identify by a simple rule independent of the template (similar to the way .css and .js pages are currently treated specially in certain namespaces by virtue of the pagename). At present, the subpages are all named identically to the mainspace articles. But {{Attached KML}} could easily be modified to append ".kml" to the name of the template subpage used in the external links. We could change this now before there are very many subpages to move.

In other words, should we move each existing "Template:Article KML/articletitle" to "Template:Article KML/articletitle.kml"?

At the moment, the /doc subpage is the only exception to the rule that the template subpages correspond to the KML files:

( {pagename} is KML code ) ↔ ( {pagename} LIKE "Template:Attached KML/%" AND {pagename} != "Template:Attached KML/doc" )

but this is less robust and adaptable than keeping the pages as subpages of the current template but appending ".kml":

( {pagename} is KML code ) ↔ ( {pagename} LIKE "%.kml" AND {namespace} IN {some as-yet-undetermined-but-flexible subset of namespaces} )

(Apologies for not proposing this before the move from "Talk:Articletitle/KML" to the present location, but the move proceeded before there was much time for reflection. I think a further change now could save considerable disruption later on.)

— Richardguk (talk) 03:00, 6 March 2012 (UTC)

Well, I'm a bit indifferent about this proposal. One one hand it wouldn't hurt, so if you are willing to do the work go ahead by all means. On the other hand I don't see a big benefit from it. The .js and .css cases you mentioned are a bit different, because you will find those files all over the place and they will not be in a clear majority in their respective subpage-trees. The KML data however is thightly contained in the subpage tree of the AttachedKML template, with only one exception, the doc page (which is a clearly identifiable standard page). So I do not see much room for confusion. --Dschwen 15:16, 6 March 2012 (UTC)

I don't see why it would be necessary. All the KMLs are organized as subpages of the template, and we are not downloading or executing them on-wiki. - ʄɭoʏɗiaɲ ^τ _¢ 20:59, 7 March 2012 (UTC)

For now, as long as the names are consistently named, I don't see the need. If we were to get KML files accepted in the file: namespace, then we should use the suffix. Since they aren't there yet, what we have now is fine. If we get the chance to move them to file space, we can append the suffix when the pages are moved. Imzadi 1979 → 23:11, 7 March 2012 (UTC)

At present, .js and .css files exist in MediaWiki and User space, and the parser renders them specially so that the code is prettyprinted instead of treated as wikitext (and the namespaces and pagename extensions are language-independent, unlike the template name); so the pagename extension is relevant even without a move to File space.

But the discussion above clearly favours the status quo; so apologies for the diversion, and I'm happy to support the botrun with the current naming convention (unless anyone has changed their mind after the previous sentence!).

— Richardguk (talk) 20:10, 8 March 2012 (UTC)

Sources

One of the common questions asked, if necessary, at FAC and other forums about the maps created for highway articles is what the source data was used to create the map. Before we get too crazy with creating and adding KMLs, we really need to get support for direct KML file uploads. Why? Then the file description page can be used to note what source was used to create the KML file. We can't do that with the current talk subpage system. We can't also attribute who created the file nor when the file was created if that information differs from the page history. (They won't always be the same. The file could have been created in 2008 for all we know.) It's great that we have tested and developed this using the resources at hand, but before we have too many items to switch, let's get the better system in place. Imzadi 1979 → 01:34, 13 February 2012 (UTC)

Let's create a good framework (I think the river above, Highway 401 and Deansgate would make good examples) and take it to the village pump and get community support to upload them. Then a developer can do their thang. - ʄɭoʏɗiaɲ ^τ _¢ 02:28, 13 February 2012 (UTC)

In the interim I'd suggest that we should add an informal XML comment to the file giving a very brief description of the data source, with a URL for where to find it if possible eg.

These could later be converted into appropriate file page metadata by a bot. -- The Anome (talk) 01:30, 8 March 2012 (UTC)

On a similar note, there is an article on a cog railway that has a short and linear track, such that only two coords are probably needed. Would this still need a source? Chris857 (talk) 22:55, 7 April 2012 (UTC)

hdr parameter

I have added an optional parameter hdr= to add a title within the side box, as demonstrated in Stour Valley Line (where I have cobbled together two KML's into one to show two lines). Hopefully this will not affect existing uses. Oosoom ^Talk 13:45, 14 May 2012 (UTC)

The parameter should probably be spelled out as header before it gains much more use. hdr may not be obvious to all users. —Scott5114 ↗ [EXACT CHANGE ONLY] 14:37, 14 May 2012 (UTC)

I fully agree. Why didn't I choose that? Will change. Oosoom ^Talk 16:05, 14 May 2012 (UTC)

While we're on the subject, a few days ago, I added |title= for when "Route map:" isn't the best choice for map links in the title. You can see it in action on Des Moines, Iowa. –Fredddie ™ 22:52, 14 May 2012 (UTC)

I tried using Attached KML title along with COORD display=title and they displayed over each other. Presumably you can't use both together. Oosoom ^Talk 09:12, 15 May 2012 (UTC)

Unfortunately not. KML is meant to supersede the title coordinates, providing a map of the whole route instead of a single representative point. - ʄɭoʏɗiaɲ ^τ _¢ 10:36, 15 May 2012 (UTC)

Editnotice

I've added a group editnotice for all the KML subpages. It may need slighly better wording though, so if anyone has any comments, then I can make some changes. -- WOSlinker (talk) 22:37, 8 June 2012 (UTC)

I like it. Good thinking to add it. –Fredddie ™ 04:00, 9 June 2012 (UTC)

Agreed... I also see what you mean about the wording. I'll tag a look at it in the morning when my head isn't in the fog. - ʄɭoʏɗiaɲ ^τ _¢ 04:29, 9 June 2012 (UTC)

Opera 12.01 Build 1532 for Linux i386 issues

I sometimes use Opera when viewing Wikipedia pages and when this template is set to display links in the title it interferes with the WikiMiniAtlas sending the map to the bottom of the page. Is this a problem with this template or should I report this elsewhere? – Allen4names (IPv6 contributions) 18:53, 15 August 2012 (UTC)

This may be a WikiMiniAtlas problem. Do you have an example page where I can try to reproduce the bug? --Dschwen 12:45, 16 August 2012 (UTC)

Try this link. The map appears just above the KML links near the bottom of the page. – Allen4names (IPv6 contributions) 04:37, 17 August 2012 (UTC)

Keep it simple...

I have started to copy all templates to Wiki-en (Welsh language Wikipedia), for this page. After 30 minutes I had enough. Can we not put them on a communal server - for all languages! Why do I have to reinvent the wheel every time I see an Infobox? My attempt of copying the page is on my home Wiki here. Can we simplify thing, for the sake of the other 284 languages please? Llywelyn2000 (talk) 12:30, 30 September 2012 (UTC)

It is actually impossible to upload this to Commons, because the File namespace will not accept KML files because of a flaw in the MediaWiki software. --Rs chen 7754 16:56, 30 September 2012 (UTC)

All flaws can be rectified (says me!), so it's a matter of time? Llywelyn2000 (talk) 17:14, 30 September 2012 (UTC)

No, unfortunately; the developers have practically refused to fix the issue. --Rs chen 7754 17:16, 30 September 2012 (UTC)

Because it may cause issues with the 3% of the world (mostly China, which blocks the English Wikipedia) due to an IE 6 problem. - Floydian ^τ _¢ 03:49, 1 October 2012 (UTC)

Note, its not because it wouldn't work for 3% of users, it is because it would allow an evil person to take over the accounts of 3% of the users and use these accounts to do mass vandalism (in theory). There's a bit of a difference. Bawolff (talk) 21:51, 5 November 2012 (UTC)

Thanks both for quick answers. Is there another way of drawing / geotagging paths? Llywelyn2000 (talk) 07:25, 1 October 2012 (UTC)

You could use a series of {{coord}} instances to include a number of individual points. However, this approach is obviously rather limited for most paths, thus why this template was invented. —Scott5114 ↗ [EXACT CHANGE ONLY] 08:02, 1 October 2012 (UTC)

Llywelyn, this sounds like a job for a bot, not a human being! --Dschwen 14:11, 1 October 2012 (UTC)

Couldn't you modify the template on Welsh to link to the KML files on enwp? --Rs chen 7754 14:12, 1 October 2012 (UTC)

That is not such a good idea for technical reasons. The files would then be stored on a different domain, making them way harder to access from mapping scripts. --Dschwen 14:38, 1 October 2012 (UTC)

Not being a specialist in this area gives me a seagull overlook on things! It looks so simple to me: use a series of {{coord}} instances to include a number of individual points as suggested by Scott5114, done by a Bot (as suggested by Dschwen. THEN: draw a line from one to another! Even a dotted line, using text! (If only life was as simple!) Llywelyn2000 (talk) 11:47, 2 October 2012 (UTC)

Who is going to draw the line? What semantics encapsulate line-forming coords vs. regular coords. No, sorry, I don't see that being a solution. --Dschwen 22:42, 5 November 2012 (UTC)

"from" article parameter

{{Attached KML|from=Roman Empire}}

Hey guys, I propose adding a parameter to specify a different article's KML file. For example at the page on Julius Caesar it could be useful to embed the KML of the Roman Republic or Roman Empire. --Dschwen 14:30, 17 July 2012 (UTC)

Guess I missed this when it went by on my watchlist. I think this is a great idea! - ʄɭoʏɗiaɲ ^τ _¢ 18:01, 7 August 2012 (UTC)

If so, please make it so that the box displays what article's KML is being displayed. Imzadi 1979 → 23:21, 7 August 2012 (UTC)

Done - Report back if there are any issues with borked URLs. - ʄɭoʏɗiaɲ ^τ _¢ 00:59, 8 August 2012 (UTC)

I reverted. The changes borked the links to Google and Bing, see Wikipedia:Featured article candidates/U.S. Route 41 Business (Marquette, Michigan)/archive1. Imzadi 1979 → 03:53, 8 August 2012 (UTC)

Rather than using

{{anchorencode:{{{from|{{PAGENAMEE}}}}}}}

it would be better to use

{{#if:{{{from|}}}|{{PAGENAMEE:{{{from}}}}}|{{PAGENAMEE}}}}

I've put those changes in the sandbox for further testing. -- WOSlinker (talk) 06:07, 8 August 2012 (UTC)

Can we revive this parameter? I have two articles I want to merge, and the one that's going bye-bye has a KML. —Scott5114 ↗ [EXACT CHANGE ONLY] 09:49, 16 February 2013 (UTC)

Done I've copied over the code from the sandbox -- WOSlinker (talk) 11:15, 16 February 2013 (UTC)

Many thanks. I have just used this on BCN Main Line to include the KML map from Stour Valley Line. Just what I wanted. Oosoom ^Talk 15:07, 16 February 2013 (UTC)

Great. --Dschwen 16:01, 16 February 2013 (UTC)

KML Categorisation discussion

I would probably be best to separate this out from the original discussion so... your ideas go here... --- Nbound (talk)

Having totally missed the above debate, why don't you just stick categories on the talk page like we do with WikiProject banners? That saves you the trouble of mucking with the KML, and still provides a clear categorization system. Legoktm (talk) 05:54, 12 June 2013 (UTC)

I don't think that using the talk page would be wise. Bidgee (talk) 06:58, 12 June 2013 (UTC)

I've tried a few things but it breaks the KML (can't be read). Just a suggestion, make be we should look at the code used at Template:Infobox Australian road/KML? It would mean that the KML route for roads in Australia would need to be placed at Template:Attached KML/Australia/Name of Road. Bidgee (talk) 07:15, 12 June 2013 (UTC)

Take a look at the ExtendedData method by WOSlinker - that seems to be functional. --Rs chen 7754 07:17, 12 June 2013 (UTC)

Possibly fork-ish...thing...going on

Template:Infobox Australian road/KML appears to also be building up a repository of KMLs. This strikes me as a bad idea, but I don't want to engage them directly because I don't care to be accused of being some sort of American imperial steamroll artist or whatever as other people have been in the past. Thoughts from others? —Scott5114 ↗ [EXACT CHANGE ONLY] 04:38, 6 June 2013 (UTC)

Just another reason to try to get KML data into Wikidata. –Fredddie ™ 11:55, 6 June 2013 (UTC)

Moving the KML data is preferable to placing it in a subpage of any template. Use of KML data was raised at an RfC but when I looked, {{Attached KML}} only included 38 KML files for the 498 Australian road articles. Of course it was almost impossible to find those 38 maps in amongst the more than 4,000 other KML files. The Attached KML box sits at the bottom of the page, while some editors claim this information is important for readers. For this reason the functionality was included in the infobox, where it is prominently displayed, and the KML files were included as subpages to provide for easy management. Australia has location maps and KML files available for some roads, but by no means anything approaching a majority of them. The current version of the infobox provides for KML data, location map files, locator maps and simple coordinates. Together these provide for all Australian road articles, not just the few that were previously catered for. At Template talk:Infobox Australian road Scott5114 talked about Google reusing the data provided by this template tbut his is Wikipedia, not Googlepedia, and we should be writing for our readers, not Google's. The best option would be to get the information to Wikidata, where all the data could be in one place. At the moment, the way that KML data is stored by this template, without any organisation that makes it possible for editors to easily find the information, is really unnaceptable. --AussieLegend (✉) 16:58, 8 June 2013 (UTC)

The information is very easy to find, but its a list of raw coordinate pairs, so its not exactly something that can be easily edited in a text format. However, it is easily loaded into Google Earth or Google Maps to be manipulated. Regardless, the Australian fork is still using the same data format, its just placing them in a different subpage hierarchy. This together with the text at {{infobox australian road}} recommending users convert any articles using infobox road are only going to add further degrees of separation between Australian roads, and roads in every other part of the world. - Floydian ^τ _¢ 17:23, 8 June 2013 (UTC)

Much better to keep all the KML files in one easy to find location rather than spreadout all over the place. Just think what it would be like if every template used KML files stored in different locations. KML files are not just used for roads, there's also rivers and railway lines to mention a couple of other uses. -- WOSlinker (talk) 18:21, 8 June 2013 (UTC)

Nobody said it was difficult to create KML files. As I've said elsewhere, I can just hop in the car, drive along a road and then export the track file as a KML from my mapping software without even touching Google. I've already done that several times. Australian government departments are making downloadable data available in formats that can easily be converted to KML with just a few mouse clicks. Ideally, KML files should not be be in a subpage of any template, including this one. We should be able to call on the files as we do for images but that's not an option, so until the files are available from Wikidata, we just have to live with a compromise situation. If that means individual templates managing their own data, then so be it. Remember {{Attached KML}} doesn't own the files. --AussieLegend (✉) 19:17, 8 June 2013 (UTC)

Yeah, template is not the ideal solution, but it is what we can get now. Please do not create a second template. This is mega-retarded. There are scripts that help visualize the KML data already in place. Having to support yet another template, when we have a perfectly fine one is a waste of time. It be really nice if we could just skip over the drama of hurt feelings yada yada and just rectify this by converting everything to attached kml. --Dschwen 21:46, 8 June 2013 (UTC)

It's not another template. It's just a couple of links from this template incorporated into an existing, 7-year-old, recently updated infobox using KML data located somewhere else. There's nothing to support. There's no point having two templates in an article when one will do. --AussieLegend (✉) 22:07, 8 June 2013 (UTC)

Except external links to other non-official sites are supposed to go in the External links section, not the infobox. FAC does not like having such links in the infobox. That's why we can't put the {{commonscat}} in an infobox either. Believe me, we tried it in Infobox road and they did not like that. --Rs chen 7754 22:56, 8 June 2013 (UTC)

Then you've got a problem with this template as it places external links in the title bar, which is most definitely not the external links section. The only thing this template should be placing in the title bar is the mini-atlas link. --AussieLegend (✉) 23:10, 8 June 2013 (UTC)

That is the only exception, as the coordinates templates do that too. --Rs chen 7754 23:11, 8 June 2013 (UTC)

In that case this template needs to be fixed. --AussieLegend (✉) 23:36, 8 June 2013 (UTC)

No, because plenty of FAs have either {{coord}} or {{Attached KML}}, and we've never had any problems with external links in either. --Rs chen 7754 23:53, 8 June 2013 (UTC)

Theres no FA criterion stating external links have to go in the external links section, though they should of course be used appropriately. War against Nabis is an FA and has an {{external media}} template right in the middle of the article. AL may have to rename the section to more accurately reflect the fact that the links are external. -- Nbound (talk) 07:18, 9 June 2013 (UTC)

Of course not, but articles have to follow MOS. --Rs chen 7754 07:20, 9 June 2013 (UTC)

The MOS doesnt cover media links, though there is some coverage at: Wikipedia:ELPOINTS.

"External links should not normally be used in the body of an article.[1] Instead, include appropriate external links in an "External links" section at the end of the article, and in the appropriate location within an infobox, if applicable."

As can be seen there is nothing against using external links in the infobox.

Now I dont mind chatting about infobox design issues, but that should take place at {{infobox Australian road}}. Can we get back to the KML thing now? (which should really be discussed there too, but whatever! :) ) -- Nbound (talk) 07:35, 9 June 2013 (UTC)

What is your opinion about the forking issue? --Rs chen 7754 07:48, 9 June 2013 (UTC)

The fork is potentially a necessary evil, until a centralised source is set up. It should be noted that WP:AURD hasnt formalised any usage guidelines in regards to this as yet. It may not be used on all that many roads at the end of the day anyway. Its not something we are placing on every infobox at this stage (as stated theres only a limited number of KML files available at this stage). -- Nbound (talk) 07:56, 9 June 2013 (UTC)

And that's what I don't really get - is there any reason why IAR can't use the KML subpages under {{Attached KML}}? Currently Mitchell Freeway has 2 KMLs, one under IAR, and one under Attached KML - I sure hope it doesn't get rerouted soon... --Rs chen 7754 07:58, 9 June 2013 (UTC)

I've already explained this at the IAR talk page. --AussieLegend (✉) 08:44, 9 June 2013 (UTC)

And you've already been refuted at the same page. Having a list of the Australian KMLs is completely useless - having a list of the ones that are missing is more useful, and that's what talk page tagging is for. Wikipedia is written for the user, not the editor - data reuse through Attached KML is more important, regardless. --Rs chen 7754 08:56, 9 June 2013 (UTC)

and the refutation has been refuted. --AussieLegend (✉) 10:08, 9 June 2013 (UTC)

←(edit conflict) It would be rather simple to have the Australian project tag automatically check to see if a KML exists as an Attached KML subpage. If it does, it can categorize the talk page into a "has KML" category (or likewise it can put it in a "needs KML" category). I know this is possible because the USRD project tag already does it. How would this not solve the KML administration issues that the Australian WikiProject faces? —Scott5114 ↗ [EXACT CHANGE ONLY] 09:08, 9 June 2013 (UTC)

Done. It may take some time before the changes propagate through to the tracking categories - Evad37 (talk) 09:41, 9 June 2013 (UTC)

I've already explained why talk page tagging is not an ideal solution. --AussieLegend (✉) 10:08, 9 June 2013 (UTC)

Would you mind restating your reasoning on that topic? The posts over at the other thread were rather long and I don't want to excerpt part of your response and miss out on part of your argument. Thanks in advance. —Scott5114 ↗ [EXACT CHANGE ONLY] 10:40, 9 June 2013 (UTC)

"Because of the way that our roads are named, they are scattered randomly throughout the list of files so they are almost impossible to find, while the US has a better ordered structure because of the way roads seem to be named. Using |kml=yes is useless if you don't know the file exists. There's no guarantee that the uploader has modified the article talk page, so keeping them in a smaller group makes management much easier. Effectively {{Attached KML}} (which doesn't own the files) has 4,200 files in a single "category", which is unworkable. With any other file, we'd categorise them by country and then by state/province but, since we can't do that, we need some other option. The system implemented for this template is more easily manageable. Individual file talk pages don't need the project banner added as they're in a subpage of the main template and there are clear directions on how to find the files. So yes, there was a lot of thought for the consequences, despite your assertion. "When" KML data is migrated to Wikidata we will revisit the way we manage the files but, until then, this seems the best option." --AussieLegend (✉) 10:47, 9 June 2013 (UTC)

All right, thanks. It looks like Evad37 has modified the project template to automatically see if there is a KML file present for the article it is attached to, and categorize the article accordingly, meaning that adding kml=yes to the template manually is would no longer be required. The way I read your rationale, that's one of the main problems you have with using the project tag to keep track of KMLs. Does this development change your view of using tags? —Scott5114 ↗ [EXACT CHANGE ONLY] 10:52, 9 June 2013 (UTC)

The tagging is but one problem. That's obviously fixed but categorisation is still an issue, as is WP:OWN. --AussieLegend (✉) 16:03, 10 June 2013 (UTC)

Formal proposal

I formally propose moving all subpages of Template:Infobox Australian road/KML to Template:Attached KML to undo the forking issues. --Rs chen 7754 09:05, 9 June 2013 (UTC)

This nomination is flawed as there is no forking. Another template is using a different set of data to link to two websites. Is this template taking control of any links to Bing and Google maps? --AussieLegend (✉) 16:07, 10 June 2013 (UTC)

Support as proposer. --Rs chen 7754 09:06, 9 June 2013 (UTC)
Support, the present situation is technically inferior to the prior arrangement, and this has ramifications beyond Australia. —Scott5114 ↗ [EXACT CHANGE ONLY] 09:08, 9 June 2013 (UTC)
Support—at the very least, the page moves will leave behind redirects from the old names which retains the desired utility of placing them under another template. This will eliminate the potential for duplicate files when the day comes that the KMLs can moved to Commons or Wikidata. Moving forward, for tracking purposes, the AURD talk page template could be modified, if necessary, to automatically mark which article have or need KML created, much the same way the USRD banner categorizes articles without a KML. Additionally, the appropriate subpages could be tagged on their individual talk pages to "assess" them as part of AURD, which is another method of tracking without forking. Imzadi 1979 → 09:14, 9 June 2013 (UTC)
Support - talk page tagging is suitable for tracking. Also, I believe that KML files should be in a KML subspace, not infobox subspace. Not all articles with KML files have infoboxes. Harryboyles 09:17, 9 June 2013 (UTC)

Yes KML files should be in a separate space, not under this template. --AussieLegend (✉) 09:54, 9 June 2013 (UTC)

Well they should be on Wikidata (and I'm still begging the devs to do it). But in the meantime, the solution isn't scattering them around willy-nilly all over the English Wikipedia so they can't be found come moving day. --Rs chen 7754 09:58, 9 June 2013 (UTC)

The solution isn't locking them all under one template either, --AussieLegend (✉) 10:10, 9 June 2013 (UTC)

How is this locking them all under one template? Locking them all under one template would be not allowing Infobox Australian road to use the data at all. --Rs chen 7754 17:33, 9 June 2013 (UTC)

You're forcing all users of KML data to store their information under your template whether they use your template or not, which you don't have the right to do. That's WP:OWN unless it has wide community consensus, which it doesn't. --AussieLegend (✉) 16:03, 10 June 2013 (UTC)

Considering that no uninvolved admins have responded on ANI, I don't think anyone agrees with you. --Rs chen 7754 17:18, 10 June 2013 (UTC)

That would be a very sad state and would require further escalation. Can you explain why this is not WP:OWN instead of just saying that it isn't? --AussieLegend (✉) 19:40, 10 June 2013 (UTC)

Because you don't own it either, and right now a heck of a lot more editors involved with KML have decried your perceived ownership of what has to this point been a very agreed-upon convention. Stop stirring up the sand! - Floydian ^τ _¢ 19:47, 10 June 2013 (UTC)

The difference here is that I'm not trying to force anyone using this template to use KML files located elsewhere. I haven't deleted, redirected or even proposed moving KML files from this template. I'm not asserting ownership over the files, you are by insisting that they all be kept here and nowhere else. This "very agreed-upon convention" is only very agreed upon in a very small corner of Wikipedia. --AussieLegend (✉) 20:36, 10 June 2013 (UTC)

You are asserting ownership over these new KMLs. We're trying to keep something organized using these arcane concepts we call rules and procedures. If the agreed-upon convention isn't to your agreement, then find the other three corners of the rhetorical room to tell this lonesome corner that KML data can be wherever the lamblast we want it to be! - Floydian ^τ _¢ 12:20, 11 June 2013 (UTC)

No I am not doing that at all. Anyone is free to edit, use and redistribute any of the KML files. Most of these files are not new, they're copies of data held here, used as permitted by policy. You can quite happily copy any of the information. However, you do not have the same opinion. Yes, we can use it but you don't want anyone to copy it. That's the very essence of WP:OWN. --AussieLegend (✉) 12:35, 11 June 2013 (UTC)

Oppose Nothing you do here can force action on another template. This template doesn't own KML data. --AussieLegend (✉) 09:34, 9 June 2013 (UTC)
Support - regardless of whether KML is used in an infobox or not, all the files should be kept together, and not duplicated in a second location - Evad37 (talk) 09:41, 9 June 2013 (UTC)
Conditional Support - As long as it works via redirects per Imzadi1979, or another mechanism -- Nbound (talk) 10:21, 9 June 2013 (UTC)

I would like to redirect people to AussieLegend's vote, and also remind them this is temporary, and isnt going to be hard to merge back together once Wikidata is up and running... Storm in a teacup? -- Nbound (talk) 10:25, 9 June 2013 (UTC)

You haven't responded to the forking concerns, and shapefiles is not on the short list of datatypes that the Wikidata team is prioritizing, so it could be a very long time. --Rs chen 7754 10:29, 9 June 2013 (UTC)

We're in no hurry. --AussieLegend (✉) 10:32, 9 June 2013 (UTC)

Note - I have raised the issue of this apparent breach of WP:OWN at WP:ANI.[1] --AussieLegend (✉) 10:27, 9 June 2013 (UTC)
Support, and then lets look to concepts to improve the issue at hand: Categorizing. Can we not add a hidden category into the template triggered by and using a variable for the location? - Floydian ^τ _¢ 15:42, 9 June 2013 (UTC)
- Just wondering if it's possible to add a category inside an ExtendedData tag into the kml pages, just before the </Document> tag. WOSlinker (talk) 17:55, 9 June 2013 (UTC)

<ExtendedData><Data name="category"><value>[[Category:Road KML files]]</value></Data></ExtendedData>

Why couldn't we just add a category within noinclude tags like we do for the {{Jct}} subtemplates which are still under {{Infobox road}}? (Template:Infobox road/IA/link IA, for instance) –Fredddie ™ 02:50, 10 June 2013 (UTC)

I suspect that noinclude would cause an issue with other applications; I think we're stuck with working within the KML specification, which is why I suspect that ExtendedData may be the way to go. --Rs chen 7754 02:53, 10 June 2013 (UTC)

I am testing it out with Iowa Highway 1. My suggestion of noincluded categories did not work at all, so I am trying out the extendeddata now. It appears to work with Bing, but Google has some caching issues that Bing does not, so I'm waiting for that. –Fredddie ™ 03:25, 10 June 2013 (UTC)
And right after I hit enter, I discovered that the Google map is working as intended. Any volunteers for testing it on other KML files? [2]–Fredddie ™ 03:29, 10 June 2013 (UTC)

I've just created Template:Attached KML/Yass Valley Way from scratch, which works with the category (see Google and Bing). Harryboyles 04:28, 10 June 2013 (UTC)

Support - I'm a little late, aren't I? Sometimes a wikibreak is best left not taken. T C N7JM 04:33, 10 June 2013 (UTC)
Oppose: I'm not yet convinced that {{Attached KML}} is suitable and {{Infobox Australian road/KML}} is rather simple to use and navigate. Whether the KML should belong in the {{Infobox Australian road}} or not [ie: should it be in the article, such as the See also subsection], that issue should be discussed on the relevant template or project. Sorry to say but there does seem to be some template own issues going in here and is getting out of control. Bidgee (talk) 12:14, 11 June 2013 (UTC)
The Australian Road infobox can still use and control the display of KML info how its editors see fit. However, the data its using should be kept together with all KML data so that when we can move it to wikiData, the transfer is seamless and comprehensive. - Floydian ^τ _¢ 12:32, 11 June 2013 (UTC)

Keeping a data set at Infobox Australian road is not going to stop it being moved to Wikidata ,when that eventually happens, if the data is appropriately categorised. --AussieLegend (✉) 12:37, 11 June 2013 (UTC)

(ec)I may not have made myself clear enough in my original comment, one of the thing I was getting to was that {{Infobox Australian road/KML}} lists the roads with KML but {{Attached KML}} doesn't list them as of yet (as far as I can tell). Also, does WikiData allow anyone to make changes? Bidgee (talk) 12:41, 11 June 2013 (UTC)
Oppose The current setup appears to be a simple, logical way to manage the issue in one place and may even assist later migration to Wikidata if necessary. "Needle in a haystack" management doesn't work. Orderinchaos 00:55, 12 June 2013 (UTC)

It works, now what?

OK, before we get too crazy with this, we should decide how we want to categorize. Here is what I'm thinking:

KML files
Road KML files
Road KML files by country
Road KML files by state/province/etc.

Then Iowa Highway 1's KML would go into Category:Iowa road KML files or some such. Rivers and other KML uses would have similar top–down hierarchies. –Fredddie ™ 04:40, 10 June 2013 (UTC)

My only concern is to ensure that everything is done in a standard way so that these can be stripped out whenever they're moved to Wikidata. —Scott5114 ↗ [EXACT CHANGE ONLY] 17:43, 10 June 2013 (UTC)

Sometimes we have to compromise to achieve an appropriate result. With appropriate categorisation it really doesn't matter where the files are located as they'll be findable through the category tree, which is a lot better than having thousands of files all in one pseudo-category as they are now. --AussieLegend (✉) 20:41, 10 June 2013 (UTC)

Inappropriate canvassing

Please note that inappropriate canvassing has taken place: [3][4][5][6][7][8] --Rs chen 7754 11:49, 11 June 2013 (UTC)

Now you're being quite ridiculous. The move proposal instigated by Attached KML editors directly affects Infobox Australian road, which is managed by Wikipedia:WikiProject Australian Roads. I've merely notified the members of WikiProject Australian Roads listed at Wikipedia:WikiProject Australian Roads#Participants. That's more than appropriate. The notice identified exactly what was happening in as neutral a manner as possible, and directed editors to all three related discussions. Attached KML doesn't have a thing to do with Infobox Australian road yet a discussion was opened here for the the express purpose of asserting control over data used by Infobox Australian road. By discussing the matter here you've stacked the votes in your favour. To accuse me of vote-stacking, given the ownership issues and that vote-satcking is reprehensible. --AussieLegend (✉) 12:13, 11 June 2013 (UTC)

I call bullshite. None of the people you have notified even participated in the discussion that led to KML being implemented in the infobox. You're calling in backup by alerting a... small corner of wikipedia. - Floydian ^τ _¢ 12:30, 11 June 2013 (UTC)

Time for both sides to stop the bad faith and uncivil comments. The way this saga is going, it will end up at ArbCom. Bidgee (talk) 12:34, 11 June 2013 (UTC)

"None of the people you have notified even participated in the discussion that led to KML being implemented in the infobox." I was the one who implemented KML in Infobox Australian road and I certainly participated in the discussion that lead to that. --AussieLegend (✉)

The thing which is very sad here is that the AURD template and associated work is the product of months of good faith work between two groups of editors who have historically fought about everything due to previously irreconcilable views and approaches and occasional bad faith conduct, and is a tribute to the triumph of common sense and pragmatism over a mindlessly rule-based approach. Nature abhors a vacuum and now a third group have joined the fray. If something works, talk it out, steamrolling it to agree with inflexible rules which have no status in policy only causes division and conflict. Orderinchaos 01:00, 12 June 2013 (UTC)

Break

WP:AURD has dropped KML from its template, I would suggest we close this discussion -- Nbound (talk) 03:12, 12 June 2013 (UTC)

Agreed. --Rs chen 7754 03:15, 12 June 2013 (UTC)

Parts at least. Let's make sure that we A) copy the KML data from Template:Infobox Australian road/KML over to Attached KML, and B) brainstorm solutions to the real issues (i.e. not the "ownership issues") so that (mostly) everyone is happy. - Floydian ^τ _¢ 05:16, 12 June 2013 (UTC)

Sounds fair enough. Considering we no longer have the need for the KML data, it should be fine for someone to do a BOLD move of it back to attached KML. -- Nbound (talk) 05:22, 12 June 2013 (UTC)

@Floydian - Apart from a couple of files uploaded by Harryboyles, there was nothing to copy as the data was simply a copy of what was already here. Your edits have left a series of pointless redirects that now need to be deleted. --AussieLegend (✉) 07:48, 12 June 2013 (UTC)

I only left them in case they were being called from some page. They can all be deleted rather quickly by a willing admin now that we've taken care of whatever loose ends there were or weren't. - Floydian ^τ _¢ 16:54, 12 June 2013 (UTC)

Attached KML and ShareMap

Hello, I am a member of ShareMap.org development tool. ShareMap is web gis portal that allow social creation of maps using multiple data sources:

OSM via wizard
OSM via pure XAPI query
Natural Earth (->example)
Tracing old raster maps (->example)

There is a lot of SVG maps created with ShareMap on Wikipedia, but recently we added KML export feature so we can leverage this template. For me results are promising.

I created video screencast with entire process of creation KML map of Amtrak train route with ShareMap - please consider that this is in the real time so entire creation took me 12 minutes.

Here you can find:

In case of any questions or comments I'll be glad to answer.

--Jkan997 (talk) 08:56, 25 June 2013 (UTC)

Mobile browser issue

I tried to view a KML from my mobile device and discovered that the neither the Google nor Bing link worked as it should. The Google link opened up the Maps app while the Bing link centered over Seattle. I was looking at Iowa Highway 44, so I know it was wrong. What can we do to fix this? –Fredddie ™ 03:46, 6 October 2013 (UTC)

I just tried the Iowa Highway 44 links from my iPhone, and can confirm that Bing just brings up a map centred on Seattle. The Google links, however, worked fine. In Safari, it loaded a page suggesting the Google maps app, but after clicking on the "No thanks" links, the map loaded, with the red KML line over Iowa Highway 44. In Chrome, it loaded the map straight away, with a box down the bottom suggesting the app (with an X to close that box). - Evad37 (talk) 04:59, 6 October 2013 (UTC)

I should note I was using a Galaxy S4. –Fredddie ™ 05:14, 6 October 2013 (UTC)

Download link not working

When I click on the "KML File" download link, my browser (Firefox 26.0) tries to download the index.php file, not the KML. It would probably be best if that got fixed. Also, it would be nice to be able to view on google earth as well as google and bing maps. Van Isaac_{WS Vex}^contribs 13:07, 10 January 2014 (UTC)

Have you actually downloaded the file and looked at the contents? It is the KML file. -- WOSlinker (talk) 14:16, 10 January 2014 (UTC)

You just have to change the file extension when you're saving it. T C N7JM 22:48, 10 January 2014 (UTC)

Template-protected edit request on 22 March 2014

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Add interwikilink to sv:Mall:KML. Edaen (talk) 09:11, 22 March 2014 (UTC)

Not done Interwiki links are now handled on Wikidata, and I have edited d:Q6690822 accordingly. --Rs chen 7754 09:15, 22 March 2014 (UTC)

OK. Thanks! Edaen (talk) 09:25, 22 March 2014 (UTC)

Any way to transclude?

There are articles Interstate 95 in Florida, Interstate 95 in Georgia, and so on, as well as Interstate 95. Is there any way to transclude the former KML files into the latter, so an edit to improve one of the former is automatically made to the latter? --NE2 02:52, 5 July 2014 (UTC)

Interesting idea. Theoretically, it should work with <onlyinclude></onlyinclude> inserted in the right locations. Compile the transclusions into an I-95 kml file and go. The final layout would be similar to a KML with more than one line like Template:Attached KML/U.S. Route 20 in Iowa, which was created using the Google Earth folder method. –Fredddie ™ 03:45, 5 July 2014 (UTC)

However, adding onlyinclude tags breaks the KML. –Fredddie ™ 03:51, 5 July 2014 (UTC)

I tried transcluding subpages that lack the outer wrapper but no luck. I think it's feeding the code with curly brackets as the KML file. --NE2 03:58, 5 July 2014 (UTC)

Lowertown Historic District (Saint Paul, Minnesota)

Could anyone help out a noob? I'm really interested in using KLM templates for historic districts, so I put together Template:Attached KML/Lowertown Historic District (Saint Paul, Minnesota) but something is just not working. I would really appreciate some expert help to troubleshoot this. -McGhiever (talk) 00:42, 11 September 2014 (UTC)

I downloaded the file at first and wasn't able to open it in Google Earth. So, I removed the gap at the beginning of the file and was subsequently able to view it. So, that could have been all it needed. I'll wait until the Google Maps cache clears so I can view it in Google Maps to be sure. –Fredddie ™ 00:50, 11 September 2014 (UTC)

It works fine for me when I just tried to view it, assuming that it should be a punch of points labelling places in the historic district. It seems Fredddie's change worked. I've noticed a similar problem when trying to load KMLs that Rcsprinter made with that program into Google Earth (but not maps). Also, as a suggestion, if the district has defined boundaries, perhaps have a semi-transparent polygon outline the shape. - Floydian ^τ _¢ 00:52, 11 September 2014 (UTC)

Thank you both; that's all it took! District boundaries may be step two, though in National Register practice "districts" usually are just collections of buildings rather than a limned area. -McGhiever (talk) 01:00, 11 September 2014 (UTC)

Google/Bing links near the featured star icon at the top of the page

Hi. This template apparently adds Google/Bing links at the top of article near the featured star icon (sometimes?). You can see it in action here: Pulaski Skyway. That page is using the code {{Attached KML|display=title,inline}}.

I'm really not hot about the idea of us putting such prominent links to two search engines at the top of the page like this. What are options for addressing this? --MZMcBride (talk) 23:47, 27 April 2013 (UTC)

In this case they are not being used as search engines, they are being used as mapping providers. --Rs chen 7754 00:37, 28 April 2013 (UTC)

Yes, I understand their functionality. I don't like us including the words "Google" and "Bing" at the top of the article like this. Is there a way we can address this? --MZMcBride (talk) 00:55, 28 April 2013 (UTC)

I don't see what the problem is - it provides a quick way to view the related object in the space where the coordinates would go for an object that can be represented by a point. --Rs chen 7754 01:03, 28 April 2013 (UTC)

Well, we're a free encyclopedia, so putting external links to two corporate behemoths at the top of certain articles makes me feel a little weird. I understand that there are likely constraints regarding who can provide this service to readers. I think we also have to consider, at least somewhat, that the Wikimedia Foundation (which many people view as "Wikipedia") has received millions of dollars from Google. If I'm the only one who feels weird about these links at the top of the article, I can accept that. But I think we should discuss whether the current implementation could be better. --MZMcBride (talk) 05:16, 28 April 2013 (UTC)

If you drop the "display=title,inline" from the code, the link vanishes. The links are duplicated at the bottom of the article in the KML box—would it be more palatable for the link text to be something like [mapping options], which, when clicked, jumps to the mapping options in the KML box? —Scott5114 ↗ [EXACT CHANGE ONLY] 04:17, 28 April 2013 (UTC)

Yeah, I think that would be better. It could even use a CSS pseudo-selector to highlight the box when jumping down, if we wanted to do that (in a similar way that references are highlighted when clicked). Rschen7754: your thoughts? --MZMcBride (talk) 05:16, 28 April 2013 (UTC)

Well, the ideal solution would be to have something on Toolserver (or Labs I suppose) like geohack for coordinates, but unfortunately we don't. I guess what I'm getting at is more or less the convenience of having the link right there. Thus I'd strongly prefer to leave the links as is, but I wouldn't be absolutely opposed to this solution. --Rs chen 7754 05:23, 28 April 2013 (UTC)

GeoHack is something to consider. Or I thought of Special:BookSources, which is what the automagical IBSN links use. If we can come up with a clear idea of how this should behave, it will be much easier to get implemented. If it's just a basic Toolserver/Labs tool that's needed to provide an index of route map options, that should be fairly simple to implement. If it has to provide the same functionality using maps and reading the KML file... well, that gets really tricky. :-) That said, perhaps the OpenStreetMap people or others have worked on this. Or perhaps it's not too difficult to read the KML and put something nice together (where to get the map is the real killer here, I think?). I don't know too much about this world. My concern was a weird feeling I got by seeing "Google"/"Bing" links at the top of the page. Maybe I'm just being silly. --MZMcBride (talk) 06:30, 28 April 2013 (UTC)

As far as I'm aware, Google and Bing Maps are the only online mapping sources that support overlaying an arbitrary KML onto their maps. Yahoo! Maps didn't, last I checked (they may have added it since then). There are a few tools that purport to do the same with OSM, but some screwing around with them leads me to believe they don't work (one tool simply didn't do anything, the other refuses to accept any KMLs whose URLs do not end with ".kml", which ours don't, since they are stored on a wikipage). A GeoHack-type page seems like overkill for only having two services that are known to work. —Scott5114 ↗ [EXACT CHANGE ONLY] 06:39, 28 April 2013 (UTC)

Depending on how strict the input validation is, you could maybe use a link like <https://en.wikipedia.org/w/index.php?title=Template:Attached_KML/Akoni_Pule_Highway&action=raw&hello=.kml>. I like your suggestion for changing this to something like "routing maps" with a link to the box at the end of the page. This seems more scalable as well. --MZMcBride (talk) 07:25, 28 April 2013 (UTC)

Here is a starting point, made possible because of some recent activity (give it several seconds to load etc.): https://umap.openstreetmap.fr/map/new?dataUrl=https%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DTemplate%3AAttached_KML%2FAllegheny_County_belt_system%26action%3Draw&dataFormat=kml&dataProxy=true. See [9] and [10] for a bit more info. --Hhm8 (talk) 03:47, 19 September 2014 (UTC)

That may be doable, but I didn't really bother messing with it for all that much longer, because I tried downloading a KML (the specific one I tried was from Creek Turnpike) and uploading it to an external server with a proper .kml extension, and it still choked on it for some reason. Perhaps someone more familiar with the OSM project knows of a more suitable tool or how to get the ones I messed with working, but that's some beyond the remit of this discussion. —Scott5114 ↗ [EXACT CHANGE ONLY] 07:43, 28 April 2013 (UTC)

A few months ago I asked the ACME Mapper developer to add KML: He said it should be pretty easy and would get around to it eventually—which I took to mean perhaps sometime this year. —EncMstr (talk) 05:16, 29 April 2013 (UTC)

So I spent sometime chatting with a guy in the #osm channel, and using the url https://en.wikipedia.org/w/index.php?title=Template:Attached_KML/Akoni_Pule_Highway&action=raw&.kml on maps.burningsilicon.net (direct link to example) works. The source code wasn't that complicated, so it might be possible to replicate this on labs using OpenLayers. Legoktm (talk) 09:44, 28 April 2013 (UTC)

Bing replaced

Everyone knows that Bing maps is kinda bad (it is Bing) so what is the reason for that to be one of the links of this template? I think it should be replaced by something such as OpenStreetMap (abbreviate OSM) which is far more comprehensive, recognisable, and actually promotes the idea of wikis a little because anyone can edit it. Why not get it changed? OSM is the only strong competitor to Google Maps anyway, so anybody using Attached KML is going to click on Google unless Bing is taken away. Rcsprinter₁₂₃ (whisper) @ 18:18, 11 June 2014 (UTC)

OSM doesn't support overlaying an external kml onto its maps the way we can with Google and Bing. If they can get that fixed up I'd be in favour of adding or switching it in. - Floydian ^τ _¢ 19:45, 11 June 2014 (UTC)

In a perfect world, the KML link would go through GeoHack and overlay onto any of those services. But unicorns will poop rainbows before that happens. –Fredddie ™ 20:42, 11 June 2014 (UTC)

This may be doable without too much effort - see my post from a few minutes ago concerning using uMap. --Hhm8 (talk) 03:52, 19 September 2014 (UTC)

Viewing KML data in Google Maps

I just linked to a Google Map from an {{Attached KML}} and got this. Quoting; After February 2015, you will no longer able to view custom KML content in the classic version of Google Maps. End of an era? Bleakcomb (talk) 01:19, 27 November 2014 (UTC)

Related discussions: Wikipedia talk:WikiProject U.S. Roads/Archive 21#Google Maps KML change coming, meta:Tech/Archives/2014#Google Maps changes --NE2 01:38, 27 November 2014 (UTC)

See related discussion: Template talk:GeoGroup#Viewing KML data in Google Maps. --Edgars2007 (talk/contribs) 14:46, 26 February 2015 (UTC)

I'm cross-posting this to both threads. I suggest we get in contact with OSM and try and do away with providing any service to Google. Let's work with a fellow open-source service that would actually be appreciative of a mutual arrangement. - Floydian ^τ _¢ 16:55, 26 February 2015 (UTC)

OSM doesn't get along with us because we refudiate database copyrights on collections of facts, allowing us to use Google Maps as a source. --NE2 17:25, 26 February 2015 (UTC)

Is it not possible to import KMLs for roads into Google My Maps and link to those maps? That is what it suggests on the Google support page. Rcsprinter₁₂₃ (chew) @ 18:26, 26 February 2015 (UTC)
- It's possible, but relies on a single editor to do this and update it when the Wikipedia-hosted KML changes. --NE2 18:40, 26 February 2015 (UTC)
  - You could have a shared WikiProject Highways Google account with password available on request only to trusted users. Rcsprinter₁₂₃ (engage) @ 23:23, 26 February 2015 (UTC)
    - That would violate the spirit of being an "encyclopedia anyone can edit" though. Also, it would become a maintenance nightmare as anyone could upload a KML file, but only trusted users could transfer it to Google Maps. Also, not all KMLs are used on HWY articles; there are uses and applications for them in other topic areas. Imzadi 1979 → 23:37, 26 February 2015 (UTC)

We can just kill the Google link and send everyone to Bing Maps. If they want the traffic from us, Google can unbreak their app. —Scott5114 ↗ [EXACT CHANGE ONLY] 04:06, 27 February 2015 (UTC)

The Google Maps link currently still works, so we shouldn't be killing anything just yet. However, when Google Maps goes out completely, I'd be inclined to agree with you. We have multiple working backups which wouldn't require much tweaking to the template, so I don't see a good reason to put extra effort into including GMaps if it's broken. The only thing I might be able to argue the other way is that GMaps is one of the most familiar, recognizable online map databases, and more people would know how to navigate that than they would Bing Maps or the WikiMiniAtlas, but, honestly, it shouldn't be that hard to adjust. T C N7JM 05:54, 27 February 2015 (UTC)

+1. I mean, I suppose we could always try talking to someone with contacts (maybe Denny who worked for Wikidata and now for Google?) but it's a long shot. --Rs chen 7754 06:02, 27 February 2015 (UTC)

Might it be possible to use javascript to display KML on Google maps? https://developers.google.com/maps/documentation/javascript/examples/layer-kml shows a custom KML file displaying on a (new version) Google maps background using javascipt. If it could be made to work, then a gadget could be developed, and be turned on by default. - Evad37 [talk] 04:49, 27 February 2015 (UTC)

That doesn't sound too different from the current WikiAtlas implementation, though of course someone would have to implement it. (JavaScript isn't exactly my thing; while I suppose I could pick it up, since it's not my strength, it probably wouldn't get done for a while). --Rs chen 7754 05:53, 27 February 2015 (UTC)

Well, it looks like it's gone out again. Clicking Google links now sends me to a redirect loop. I pinged User:Fredddie about this a couple days ago, but he said he didn't know how to fix it this time. Anyone else wanna give it a shot or is it time to bite the bullet? T C N7JM 14:40, 5 March 2015 (UTC)

Dschwen is the WMA guru, maybe he can give us some guidance. It would be great if we had some integration with Geohack, as in, clicking a KML link would take you to the Geohack page (like this one). The trouble is that it's a whole lot easier to plot a single point on a map than it is to draw a line. –Fredddie ™ 23:45, 5 March 2015 (UTC)

I still believe (despite NE2's downplaying) that our best bet is OSM. It was originally our choice of one of the providers when KML implementation was discovered. Although we have different sourcing policies, I see no reason why they wouldn't agree to work with us to implement, at the very least, a basic iporting of KML implementation. Does anybody know who we would talk to in such situations? - Floydian ^τ _¢ 00:00, 6 March 2015 (UTC)

I agree with that, but I think it would unify the enduser geodata experience if KML went through Geohack. –Fredddie ™ 03:40, 6 March 2015 (UTC)

User:Aude maybe? --Rs chen 7754 05:55, 6 March 2015 (UTC)

Well, it's dead, now what?

And there doesn't seem to be any suitable replacement (yet). Should we just remove the link to Google, leaving "Route map: Bing " at the top of articles, or should we replace it with a direct link to the KML – ie "Route map: Download KML / Display on Bing " ? - Evad37 [talk] 02:24, 20 March 2015 (UTC)

When I prematurely removed the link earlier, I just got rid of the Google links. That's what I'd do again. –Fredddie ™ 02:28, 20 March 2015 (UTC)

OSM ?

Seeing this, maybe Google Maps can be replaced with OSM. Jack ma (talk) 06:44, 5 April 2015 (UTC)

Actually employing the offered .kml data.

If one clicks on the "Attached kml" blue link, one does not obtain a .kml file. Instead a file Index.php arrives. This file is ignored by Google Earth, and if its icon is dragged&dropped into a Google Earth window, nothing happens. However, should the file be renamed to (say) Index.kml, then everything works. I've tried this on different windows systems, so it is not just me. Note that many windows systems have as their default setting to not display the "file type" part of a file name, and many work-based installations have the ability to change this setting made unavailable, thus confusion is easy. I don't have a non-windows system to hand to test their behaviour, but presumably something similar happens. This is not in accordance with effortless click and instant gratification.

Is there some trick in the usage of the template whereby one might specify the name of the file resulting from the download (as distinct from specifying the source of the kml data), possibly as an undocumented option? Or is the production of a file Index.php deemed good? If so, ought there not be some description of what to do? NickyMcLean (talk) 11:40, 16 June 2015 (UTC)

@NickyMcLean: when this template was originally developed, it was hoped that we could upload KML files directly, but there are technical reasons related to an old, but still-supported, version of Internet Explorer that prevent us from doing so. As a result, we have to add the KML files to the server in the manner currently used, without the ".kml" file type in the file name.

In web browsers on my computer, and I use a Mac, I can right-click on the link and select "Download file as..." or a similar option. That allows me to specify the name of the file that will be saved, which also allows me to override the file extension type when I rename the file. Imzadi 1979 → 12:14, 16 June 2015 (UTC)

Tracked in Phabricator
Task T28059

See the box at right for the technical discussion regarding support for KML/KMZ filetypes – apparently the security issues might not be too complicated. I have suggested support for KML as a possible project for the new WMF Community Tech team at meta:Community Tech project ideas#Support KML files in Commons (additional comments welcome there) - Evad37 [talk] 12:48, 16 June 2015 (UTC)

Also of note, internet explorer 6 just dropped below 1% usage, ie7 is already there, so it may be possible to convince our tech overlords now. - Floydian ^τ _¢ 14:22, 16 June 2015 (UTC)

I also recall reading something recently that Microsoft is forcing people to upgrade to newer versions of IE. A quick search online, and I see that MS will require users running Windows 7 or 8 to upgrade to IE11 by next January. They've already stopped supporting XP, so it's only a matter of time. Imzadi 1979 → 00:02, 17 June 2015 (UTC)

Unturnut Uxplurur. Ugh. Contrary to the relatively helpful Mac experience, on a windows system via Firefox, right-clicking merely offers an option to open another tab/window and still one is faced only with the monologue "Opening index.php. You have chosen to open index.php What should Firefox do... etc." and there is no opportunity to rename the incoming file to say Index.kml, merely to save the file, or "Open With", except that Google Earth will ignore the file Index.php when presented to it. I tried an alternate startup to Linux ("Mint") and it too offers index.php, though I don't recall the new detail as to whether it offers a file rename. That was using Linux/Firefox, so that detail may be due to Firefox's interface. To test this, I've just tried IE8 and am presented with two monologue boxes, not one. Again, index.php is named as the incoming file, but this time there is a "save" option presented and if selected, I get a chance to rename the incoming file. This would be less than clear for those whose systems do not reveal the "file type" appendage, but is more workable.

I fully support the notion of having .kml (and .kmz) file types recognised by W. as are other files such as for images, but have no understanding of the collateral damage that may thereby ensue. I don't think much of file type usage/protection being guessed by "sniffing" file content as although the usual 80% or so of problems may be reduced, 20% remain and may be exacerbated. I thought the MIME-type protocol was to be systematic about this, but that's more non-involvement speaking.

In the absence of such ease, I propose therefore that the documentation for the "Attached KML" scheme be augmented with some discussion of these details because the point&click user cheerfully perusing an article may otherwise be perplexed by the non-appearance of any KML file as is mentioned in the enticement on screen, and if such a user gives over browsing and fights their way to that documentation, they deserve a reward. Indeed, if "KML file" is clicked on, having some hint that Index.php should be renamed to Index.kml may well reduce perplexity (especially for non-Mac users), but of course I have no idea as to the workings of the template feature that might enable that. NickyMcLean (talk) 10:20, 17 June 2015 (UTC)

Just rename the file and be sure to give it a .kml extension. The file that is saved is a valid KML file regardless if it's called foo.kml or index.php. –Fredddie ™ 10:36, 17 June 2015 (UTC)

New help page

Following on from the above disucssion, I've created a help page at Help:Attached KML. Is there any objection to add a help link pointing there? (see sandbox) - Evad37 [talk] 04:24, 24 June 2015 (UTC)

+1 Looks good to me. Imzadi 1979 → 05:02, 24 June 2015 (UTC)

Like Would the KML creation tutorial be better suited in the Help namespace as well? –Fredddie ™ 03:55, 25 June 2015 (UTC)

Probably makes sense to move it to something like Help:KML tutorial – the range of articles that do or could have an attached KML file is much greater than the scope of USRD, HWY, or any individual wikiproject - Evad37 [talk] 08:33, 25 June 2015 (UTC)

Note: idea raised at WT:USRD#KML tutorial - Evad37 [talk] 02:15, 27 June 2015 (UTC)

Added link to the template - Evad37 [talk] 02:03, 27 June 2015 (UTC)

Google maps working?

After noticing a Google maps link on a German Wikipedia article, I had a look, and they seem to have KML overlays working on some sort of Google maps instance on tools.wmflabs.org. I've added code to the sandbox and it seems to work on the articles I tried. If someone else can test it on a few pages, and see that it works, then I think we can add Google maps back into the main template. - Evad37 [talk] 01:12, 10 September 2015 (UTC)

Iowa Highway 333
Louisiana Highway 1035
Texas Farm to Market Road 1905
California State Route 107
- Looks good to me. The only thing I see is that the title links are missing in the sandboxed version. –Fredddie™ 01:18, 10 September 2015 (UTC)
  - Title links should be working now - Evad37 [talk] 01:46, 10 September 2015 (UTC)
    - Confirmed –Fredddie ™ 01:53, 10 September 2015 (UTC)

Done Template updated from sandbox - Evad37 [talk] 04:40, 10 September 2015 (UTC)

Editnotices/Group/Template:Attached KML

In case no one is watching the Template:Editnotices/Group/Template:Attached KML, I've placed an edit request to switch out the Google Maps URL link in the preview page. —Mr. Matté (^Talk/_Contrib) 23:39, 5 November 2015 (UTC)

2015 Community Wishlist Survey – proposal for KML support on Commons

See m:2015 Community Wishlist Survey#Support_KML_files_in_Commons, leave a comment and/or an {{endorsement}} if you agree with the idea - Evad37 [talk] 02:52, 12 November 2015 (UTC)

Bing Maps link update

The links to the Bing Maps defaults to the new viewer which doesn't display the KML information. The links in the main template and Editnotice/Group/ should be changed to http://www.bing.com/maps/?mapurl=http://en.wikipedia.org/w/index.php?title=Template:Attached_KML/*****NAME******&action=raw (example: http://www.bing.com/maps/?mapurl=http://en.wikipedia.org/w/index.php?title=Template:Attached_KML/Pennsylvania_Route_869&action=raw. —Mr. Matté (^Talk/_Contrib) 01:18, 26 November 2015 (UTC)

I updated the links accordingly, but I had to opt out of the "new" Bing "maps" before KML links would work. YMMV. –Fredddie ™ 01:31, 26 November 2015 (UTC)

Adding OSM

Basing on this example : http://osm.quelltextlich.at/viewer-js.html?kml_url=http://www.gras-linz.at/images/planb/gras-plan-b.kml

and from this form, I tried http://en.wikipedia.org/wiki/Template:Attached_KML/Wall_Street which gives : http://osm.quelltextlich.at/viewer-automatic.html?kml_url=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTemplate%3AAttached_KML%2FWall_Street

unfortunately, it gives nothing.

Jack ma (talk) 07:10, 20 December 2015 (UTC)

The actual url of the raw kml file is https://en.wikipedia.org/w/index.php?title=Template:Attached_KML/Wall_Street&action=raw (the one you used is in a wiki page format), but the form you linked to doesn't like that url. Displaying KML on OSM might be possible once the mw:Maps project is further developed. - Evad37 [talk] 08:59, 20 December 2015 (UTC)

Page moves

Often times pages with an attached KML gets moved and due to the way the template works, the links on the article (new name) will not work until the associated Template:Attached KML/[old article] gets moved as well. Is there a way to create some kind of backlog in a hidden category where articles with {{Attached KML}} is present but there is no associated file are listed? —Mr. Matté (^Talk/_Contrib) 18:45, 14 June 2016 (UTC)

So the logic should be something like {#ifexist:Template:Attached KML/{PAGENAME}|<no behavior if true>|Category:Attached KML errors}? –Fredddie ™ 21:39, 14 June 2016 (UTC)

That's pretty much what I was thinking but thank you for creating such a category before I got a chance to respond. :) —Mr. Matté (^Talk/_Contrib) 03:11, 15 June 2016 (UTC)

I began cleaning up the category. I took it from 215 pages down to 190. Most were caused by article moves so I just moved the associated KML to match. Two pages never had a KML so I commented out {{Attached KML}} in those articles.

Most of the entries in the exception category are userspace pages. Not sure what to do with those.... —EncMstr (talk) 04:13, 15 June 2016 (UTC)

I was trying to figure out a way to skip the userspace, but I didn't see anything obvious. But I also didn't look very hard. –Fredddie ™ 11:18, 15 June 2016 (UTC)

Wikidata property proposal

There is a KML-related Wikidata property at d:Wikidata:Property proposal/Sister projects#Wikimedia_KML_file, please leave a comment and/or a {{support}} if you agree with the idea. Thanks, Evad37 [talk] 08:36, 15 August 2016 (UTC)

Proposal: Use Wikidata and new module

I'm proposing that this template be update to make use of Wikidata, through Module:Attached KML – see sandbox.

The template would function in much the same way, but with the following differences:

Current template	Proposed (sandbox)
If `\|from=` is specified, uses KML from that `Template:Attached KML/` subpage Otherwise uses KML from `Template:Attached KML/{{PAGENAME}}`	If `\|from=` is specified, uses KML from that `Template:Attached KML/` subpage without checking Wikidata Otherwise if `\|wikidata=` is set to a wikidata item id (Q-number), uses KML linked from that item Otherwise checks page's Wikidata item for KML file (P3096), and uses KML linked from there Otherwise uses KML from `Template:Attached KML/{{PAGENAME}}`
Page move break the links (e.g. if `PAGEA` is moved to `PAGEB` without `Template:Attached KML/PAGEA` being moved to `Template:Attached KML/PAGEB`)	Page moves do not break links, unless `\|from=` is used
Can only access KML files on English Wikipedia	Can access KML files from any wiki linked to Wikidata
Errors reported through a tracking category only	Errors reported through messages on the page as well as through a tracking category

When getting KML from Wikidata, English Wikipedia is the first choice if there are multiple KML files linked to the item.

You can test out {{Attached KML/sandbox}} on the testcases page, on Special:ExpandTemplates (allows a page name to specified), or by previewing in an article. - Evad37 [talk] 08:25, 24 August 2016 (UTC)

Notified WT:HWY[11], WT:USRD[12], WT:GEO[13], Help talk:Attached KML[14] - Evad37 [talk] 12:39, 24 August 2016 (UTC)

Support. --Rs chen 7754 18:21, 24 August 2016 (UTC)
Support—and if we could get a bot task to copy the information over, that would be even better! Imzadi 1979 → 00:57, 25 August 2016 (UTC)
- Evad's already done it for enwiki. --Rs chen 7754 01:10, 25 August 2016 (UTC)
Support -- very much need. -- naveenpf (talk) 03:52, 28 August 2016 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

Per the above, please copy the sandbox version into the main template. - Evad37 [talk] 23:41, 1 September 2016 (UTC)
Yes, I am a template editor and could make the edit myself, but I would prefer if this could be done by the book, i.e. by an un-involved editor. Plus it doesn't hurt to have another set of eyes look over the code, especially given the high number of transclusions. - Evad37 [talk] 23:41, 1 September 2016 (UTC)

Done. There would be no problem with you making this edit supported with clear consensus. — Martin (MSGJ · talk) 12:02, 2 September 2016 (UTC)

Draftspace issue

Before the Lua migration, articles in the Draftspace were able to upload KMLs to the future articles KML location. Example: Draft:U.S. Route 160 in New Mexico has a KML file located at Template:Attached KML/U.S. Route 160 in New Mexico. Now after the migration, it is looking for the KML at Template:Attached KML/Draft:U.S. Route 160 in New Mexico. I thought of the previous behavior as a feature and not a bug, so was this "fixed" intentionally? –Fredddie ™ 23:43, 4 September 2016 (UTC)

No, not intentional. Should other namespaces similarly be ignored, so articles can be drafted in userspace or on talk pages without showing errors? - Evad37 [talk] 01:47, 5 September 2016 (UTC)

I think the Userspace was ignored previously; you can see all the UK postal code pages that are in the error cat now that were not there before. The Draftspace was not ignored, it worked as if the article was in the Mainspace. It's like the coding now is looking for {{FULLPAGENAME}} instead of {{PAGENAME}}. –Fredddie ™ 02:12, 5 September 2016 (UTC)

That's basically the issue (except with the Lua equivalents instead of magic words) – I've got a fix in the sandbox that removes all namespaces from titles. Perhaps the error category should be restricted to mainspace and draftspace. Or maybe just mainsapce? - Evad37 [talk] 03:16, 5 September 2016 (UTC)

@Fredddie:

Fixed - Evad37 [talk] 02:57, 6 September 2016 (UTC)

Google Maps problems

The link to Google Maps, as implemented here after the direct support went in February 2015, does not seem to work properly any more. Clicking the link gives you this: [15]. So can somebody find what's wrong, or do we just need to remove Google and leave only Bing (which is soon withdrawing its KML support) and WikiMiniAtlas? Rcsprinter₁₂₃ (jive) 11:47, 16 October 2016 (UTC)

This seems to happen with some files and not others – e.g. on Interstate 5 and Great Eastern Highway the Google link work fine for me. I have had cases where that weirdness occurs the first time I visit the link, but not for subsequent visits. There issue may also vary with different browsers/systems, see Help talk:Attached KML#Data_display. - Evad37 [talk] 13:20, 16 October 2016 (UTC)

I've found that middle clicking the link (as to open the map in a new tab) gets around this issue for me. I wonder forcing a new window when you click on a link would alleviate this. –Fredddie ™ 21:43, 16 October 2016 (UTC)

To reinforce the above points: The Bing links are non-functional, their continued inclusion would seem to be entirely pointless. The Google links work as apparently intended only on some pages. Where they don't they give images such as that linked by Rcsprinter₁₂₃ — on one I looked at this morning the local overlay marked all motorways in the area but didn't distinguish the one relevant to the page. As Fredddie notes a middle-click does display what one would expect but curiously what should be equivalent 'open in new tab' Ctrl-click doesn't.

Personal opinion: it's sufficiently broken that it shouldn't be withdrawn from use until fixed. In practical terms simple Geohack coördinates would be more useful. NB I don't have anything like a comprehensive test suit but I have checked that the behaviour is consistent in Firefox/Chrome on Linux and IE/FF/Chrome on Windows7 (no link appears in mobile version Safari/IOS). Calmeilles (talk) 10:33, 6 December 2016 (UTC)

Not to restart a years-old argument, but Geohack coordinates simply won't work for a large number of roads project memebers. tl;dr: how do you decide what point is representative of the whole route? Instead we should work at getting better KML integration with Geohack. It already works with WikiMapAtlas. I'd love to have a dynamic map that displays the KML in the infobox. Then we would not need this template for the most part. –Fredddie ™ 04:01, 7 December 2016 (UTC)

+1 I was going to say something to this effect, but my words were going to be harsher, so I decided against it. T C N7JM 04:09, 7 December 2016 (UTC)

And it's not just road articles that have benefitted from KML integration. Other linear features, like rail lines, canals and rivers have the same issue where single points, even collections of them, don't convey the locations of the subjects with enough context. Imzadi 1979 → 04:14, 7 December 2016 (UTC)

None of the links in this template work anymore

Bing changed their layout, which broke the raw KML displayer, and Google has that strange bug which you seem to know about already. Will anybody do anything about this? Phil roc^{My contribs} 20:01, 9 January 2017 (UTC)

I found what was causing the Google map problem, informed the maintainer of the page on Tool Labs which this template uses (Kolossos), and he has fixed it. Try the Google map links again :) Yeryry (talk) 23:01, 9 January 2017 (UTC)

+1 Each link that I have tried in the last few minutes has worked beautifully. –Fredddie ™ 23:07, 9 January 2017 (UTC)

Bing Maps links are broken.

Example: New York City Subway. -fireattack (talk) 08:34, 24 May 2017 (UTC)

I've removed the Bing links, since they haven't worked for awhile now - Evad37 [talk] 01:58, 4 June 2017 (UTC)

WikiMiniAtlas link not displaying in some articles

I noticed that in some articles like NYC Ferry, the WikiMiniAtlas link does not display anymore, only the Bing Maps and Google Maps links. The KML has multiple elements. Other articles like BMT Broadway Line have the WMA link enabled, and that KML also has multiple elements. Is the exclusion of WikiMiniAtlas on some articles intentional? epicgenius (talk) 15:54, 30 April 2017 (UTC)

Also, the Bing Maps KML link doesn't seem to work either. epicgenius (talk) 16:06, 30 April 2017 (UTC)

@Epicgenius: Fixed. Only some articles were affected because the problem was in the section of code that handles KML files not found through Wikidata, which per Template:Attached_KML#Tracking_categories is only a small proportion. - Evad37 [talk] 00:22, 7 June 2017 (UTC)

KML files for city borders?

Is it possible to use this template to map out city limits? As in, attach a KML file to, for example, Dallas, Texas, mapping out its city limits. Just a suggestion The Egg of Reason | (Talk) 03:39, 11 November 2017 (UTC)

Absolutely. I did it for Des Moines, Iowa. –Fredddie ™ 04:00, 11 November 2017 (UTC)

Question: Wiki Mini Atlas from Attached KML doesn't show up correctly

On the List of New York State Historic Markers in Ulster County, New York page we've mapped the historic markers in Google, dumped that into a KML and uploaded that as a map on the page. It's all good. Except that the map (a) is in German, (b) is centered on Uzbekistan and (c) has a red dot in the Gulf of Guinea off the coast of West Africa. How do I get it to be in English and centered on Ulster County, NY. Thanks. -- HighAtop94 (talk) 16:39, 26 February 2018 (UTC)

Error

Attached KML template not working! :( Error message: 404, Page not found --B.Zsolt (talk) 20:01, 19 August 2018 (UTC)

The tool that takes the KML and displays it over a Google Map (wp-world) is no longer working. –Fredddie ™ 20:05, 19 August 2018 (UTC)

Deprecated?

So it seems that our KML tools no longer work with either Google Maps or Bing Maps. The topicon map does seem to still work for older KML files but creating new ones still seems to be broken (there's some wmflabs tool to parse them which seems to be broken), which also breaks updates to older maps. And if you try to use this template inline, the best you can do is get a text dump of the raw KML file. Is it time to deprecate KML support on Wikipedia? Ivanvector (^Talk/_Edits) 13:50, 31 August 2018 (UTC)

It depends what you mean by deprecation. New data probably should just be generated as, or converted to, geoJSON format map data (either locally, or preferably on Commons) rather than KML, as such data can then be used in {{mapframe}} maps. But the existing KML files can still be useful, as they work with WikiMiniAtlas (mostly, if not entirely), can be used in compatible geospatial software (as described at Help:Attached KML), and can be used as a source for producing geoJSON files (as discussed at Template talk:Infobox road#Mapframe maps). So the template itself shouldn't be removed from articles, but it might be time to remove the nonfunctional Google/wp-world link. - Evad37 [talk] 14:46, 31 August 2018 (UTC)

Okay, I get what you're saying, and this is the first I've heard of geoJSON. Just after posting this I posted another idea at WP:VPT about doing something different inline with these maps, you might be interested in commenting there. Ivanvector (^Talk/_Edits) 15:12, 31 August 2018 (UTC)

This edit request to Module:Attached KML has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

externalLinks[1] = {
	short = "Google",
	long  = "Display on Google Maps",
	link  = "https://tools.wmflabs.org/wp-world/googlmaps-proxy.php?page=__KML_URL_E__&output=classic"
}

Please comment out the above code, as per the above discussion. TheDragonFire (talk) 06:08, 28 September 2018 (UTC)

Done. Is there any reason not to just remove the code? — Martin (MSGJ · talk) 19:17, 28 September 2018 (UTC)

Template overlapping

@MSGJ, TheDragonFire, Ivanvector, Evad37, Ivanvector, Imzadi1979, HighAtop94, Fredddie, B.Zsolt, Frietjes, and Jonesey95: Recent editors to the two affected templates: Greetings and felicitations. The article "Washington Street (Boston)" uses both {{Coord}} and {{Attached KML}} in the title position. The result is that the templates overlap each other. Any solutions to fix this? (Posted to "Attached KML" because its Talk page is more active.) —DocWatson42 (talk) 06:39, 11 April 2019 (UTC)

@DocWatson42: the article should not be using both templates, at least not in this fashion. Given the apparent length of the street in question, many would question the concept of picking a single set of coordinates to specify a long linear object such as this. That's why the KML template was developed in the first place. In any event, only one or the other, but not both, should have the title attribute activated, and the other should not. Imzadi 1979 → 06:54, 11 April 2019 (UTC)

User requesting help

There's a user with a {{help me}} request about this template that's been languishing, likely due to the technical knowledge required to answer it. Please check out User_talk:TerraFrost#Help_me! and help out if you can. Primefac (talk) 20:36, 1 September 2021 (UTC)

Question: Wiki Mini Atlas from Attached KML doesn't show up correctly

On the List of New York State Historic Markers in Ulster County, New York page we've mapped the historic markers in Google, dumped that into a KML and uploaded that as a map on the page. It's all good. Except that the map (a) is in German, (b) is centered on Uzbekistan and (c) has a red dot in the Gulf of Guinea off the coast of West Africa. How do I get it to be in English and centered on Ulster County, NY. Thanks. -- HighAtop94 (talk) 16:39, 26 February 2018 (UTC)

User requesting help

There's a user with a {{help me}} request about this template that's been languishing, likely due to the technical knowledge required to answer it. Please check out User_talk:TerraFrost#Help_me! and help out if you can. Primefac (talk) 20:36, 1 September 2021 (UTC)

Attached KML uses display none to hide metadata

This template uses display:none to hide certain content (meta information) that it adds. When the template is placed at the top, this causes this meta-content to show up in Google snippets, because ... well we used display:none, which is not a reliable way to insert hidden data (use html data attributes instead).

Specifically on Wilshire Boulevard, google listed for the snippet: "Template:Attached KML/Willshore Boulevard KML is from Wikidata". I'm wondering if anyone knows:

WHY this metadata is there
IF a tool relies on this metadata

This will help determine if it can be removed, refactored etc. —TheDJ (talk • contribs) 13:53, 23 February 2023 (UTC)

It seems to me that the tracking text that Evad37 added is no longer needed. The first part of the metadata seems to be generated by the makeKmldataDiv function. Not sure what software uses that data. Perhaps wikiminiatlas ? —TheDJ (talk • contribs) 14:27, 23 February 2023 (UTC)

As far as I can tell, wikiminiatlas relies on the title attribute on the kmldata element, so it does not require the contents —TheDJ (talk • contribs) 14:32, 23 February 2023 (UTC)

Recording sub-template pages as transclusions

KML subpages are linked to and not transcluded, which leads to them appearing in unused lists. While ignoring them as a whole is possible, it makes detecting any truly unused pages hard. For example, Template:Attached KML/Arkansas Highway 13 appears as unused but is used on the correct page. A possible solution would be to use getContent() at around line 287 (or really anywhere) as according to the documentation, that call will be recorded as a transclusion. Gonnym (talk) 16:56, 19 June 2023 (UTC)

Gonnym, could we exclude pages like this one? maybe only do this if the page exists, since we already issue an error when it doesn't exist? Frietjes (talk) 15:06, 21 June 2023 (UTC)

@Frietjes It now checks if the template page exists before transcluding it. Let me know if you find any other issues. Gonnym (talk) 15:22, 21 June 2023 (UTC)

thank you. Frietjes (talk) 17:28, 21 June 2023 (UTC)

Auto generation?

Is there a way to bulk-create some of these? I'd like to create, for example: Template:Attached KML/List of stock exchanges and others 92.71.60.61 (talk) 15:00, 18 July 2023 (UTC)