Wikipedia:SHEIC/Archief/2009-04

Coördinaten-probleem

Als je bij het artikel Port of Brisbane bij de infobox klikt op de coördinaten volgt een pagina met de melding:

Fout: 8e argument moet 'E' of 'W' zijn.

Iets soortgelijks speelde tot recent bij het artikel Otsegomeer wat ik toen opgelost heb met deze edit waarbij ik de seconde van de lengtegraad en breedtegraad op 0 gezet heb. Dat kan ik bij 'Port of Brisbane' natuurlijk ook doen, maar het lijkt me beter om het meer fundamenteel in de sjablonen op te lossen. Kan iemand daarbij helpen? - Alvast bedankt. - Robotje 3 apr 2009 10:13 (CEST)

Ik heb het op het hoogst mogelijke niveau, [1], opgelost, zodat nu overal minuten en seconden kunnen worden weggelaten. --LexTH 3 apr 2009 12:13 (CEST)

Ziet er goed uit, bedankt. - Robotje 3 apr 2009 12:32 (CEST)

Als je ook de minuten wegliet bleek er echter een foutmelding van sjabloon:Positiekaart te komen. Daarom heb ik daar een soortgelijke aanpassing gedaan. [2] --LexTH 3 apr 2009 13:10 (CEST)

Sjablonen in boeken

Het viel mij op dat de sjablonen Infobox Single en Infobox Muziekalbum het niet helemaal goed doen in boeken (zie hier). Ik weet niet wat er misgaat. Is het mogelijk dit (op een simpele manier) op te lossen? Stijn 5 apr 2009 18:17 (CEST)

Ik denk dat in het {{Infobox single}} dit stukje misgaat:

{{!}}-
{{!}} colspan="3" {{!}}
{{{Hitlijsten}}}
{{!}}-

Op te lossen zou het volgende misschien kunnen werken:

{{!}}-
{{!}} colspan="3" {{!}} {{{Hitlijsten}}}
{{!}}-

Maar deze wijziging zou neveneffecten kunnen hebben. Betere oplossing is in ieder geval dat de plugin die de pdf maakt aangepast wordt. ∼ Wimmel 5 apr 2009 22:14 (CEST)

Sjabloon {eenedit}

Mag ik ook hier even jullie aandacht vragen voor het sjabloon {{eenedit}}? Op de overlegpagina van het sjabloon plaatste ik dit verzoek al:

N.a.v. diverse verzoeken op OP's het volgende: Wanneer je nu {{SUBST:eenedit|artikelnaam}}~~~~ plaatst, komt op het betreffende overleg een hele stapel code terecht. Zie bijvoorbeeld deze bewerkingssamenvatting. Is hier iets aan/tegen te doen, zodat de gebruiker een "gewoon" bericht krijgt in plaats van ladingen codes?

Wellicht kunnen bezoekers van dit café me er een beter/sneller antwoord op geven... Graag antwoorden op de betreffende OP!

Dankjewel! Vriendelijke groeten, Erik'80 · 3 apr 2009 12:11 (CEST)

Ik heb de sjabloon zo gewijzigd dat de geproduceerde tekst er nu volledig als ingetypte tekst uitziet, mits de sjabloon gesubstitueerd wordt, zoals ook de bedoeling is. Maar als je dat vergeet krijg je een zwaar verminkte tekst. Als je subst: vergeet wordt je gewaarschuwd door een vette rode tekst, maar het probleem is dat de sjabloon 1700x als sjabloon geplaatst is. Daarom kan de bestaande sjabloon niet gewijzigd worden zolang er niet een bot langs geweest is om overal een subst: te plaatsen.

Maar voorlopig kan {{Eenedit1}} gebruikt worden. --LexTH 8 apr 2009 15:43 (CEST)

Nu ook weer {{Eenedit}}. --LexTH 8 apr 2009 23:09 (CEST)

Sjabloonprobleem op Burgers' Zoo pagina's

Voor wie tijd heeft om er naar te kijken: het sjabloon Sjabloon:Infobox ecodisplay veroorzaakt een probleem op de Burgers' Zoo en aanverwante pagina's in IE 7. Er is wel een oplossing voorgesteld maar dit werkt ook na purgen v.d. pagina niet. - Simeon 8 apr 2009 20:02 (CEST)

Zou je specifieker kunnen vertellen waar het probleem zit? Ik heb nu deze infobox bekeken in IE7, IE8 en chrome en het enige verschil dat ik kan vinden, is dat de ene browser beter omgaat met padding. IE8 (zonder compatiblemodus) geeft ook sommige tekstjes gecentreerd weer. Overigens stond het sjabloon niet op Burgers' Zoo ingevoegd, maar wel op al zijn subparken. Graag hoor ik antwoord, daarna wil ik er wel weer naar kijken. Sum U ^?rai8^{? Need a tool?}- 8 apr 2009 22:07 (CEST)

En dat komt Sumurai doordat ik het al op de pagina's aangepast heb. De lelijke weergave is dus opgelost. Al ben ik niet echt blij met de oplossingen (heb er 2 toegepast), aangezien dit probleem op veel meer pagina's kan voorkomen en ik niet echt weet wat de exacte oorzaker is dat IE7 hiermee op tilt slaat en de rest niet en zie met IE7 de versies van de verschillende pagina's (zie het sjabloon) voordat ik ze aangepast heb om het te zien wat ik bedoel. Groetjes - Romaine (overleg) 8 apr 2009 22:37 (CEST)

Sjabloon-probleem bij berekening inwonerdichtheid

Bij o.a. Marcq-en-Ostrevent (maar nog veel meer soortgelijke artikelen) gaat er iets fout bij het berekenen van de inwonerdichtheid omdat het aantal inwoners niet ingevuld is. Er staat nu met koeienletters in het artikel: Fout in uitdrukking: niet verwachte operator / . Kan iemand daar even naar kijken? Alvast bedankt. - Robotje 9 apr 2009 07:15 (CEST)

Ik vermoed dat de fout zit in sjabloon:Inwonertal Franse gemeente. Nadere informatie volgt (hoop ik).. Als ik zo kijk, dan zou het inwonertal aldaar 2566 moeten zijn....Sum U ^?rai8^{? Need a tool?}- 9 apr 2009 09:55 (CEST)

Zorg eerst maar dat de code is ingevuld in de infobox in het artikel, dat scheelt denk ik al. Je moet daarvoor de Insee-code hebben zoals die op de Franse versies te vinden is. Misschien botmatig nalopen waar dit verkeerd gaat en dan invullen? Groetjes - Romaine (overleg) 9 apr 2009 15:29 (CEST)

Opgelost dus. Wie wil er een bot draaien? Romaine (overleg) 9 apr 2009 15:30 (CEST)

Voor deze ene gemeente is het nu opgelost door het inwonertal in te voeren, en dat is natuurlijk heel mooi, maar er zijn volgens Google een stuk of 40 [3] artikelen over Franse gemeentes met hetzelfde probleem. Dan lijkt het me toch wenselijk dat dat sjabloon wordt aangepast. Zeker als het probleem in een algemeen sjabloon zit wat ook bij gemeentes van andere landen gebruikt wordt, want ook daar kan het dus (nu al, of in de toekomst bij nieuwe artikelen) fout gaan. - Robotje 9 apr 2009 15:38 (CEST)

Euhm, waarom? De infobox is niet volledig verkeerd ingevuld, en dat kan, als dit gesignaleerd wordt, eenvoudig worden opgelost door het wel in te vullen. Nu is er duidelijk dat er iets mis gaat, dit wordt gemeld, en dan kan het opgelost worden. Ik heb in ieder geval om een botopdracht verzocht om alle pagina's te inventariseren. groetjes - Romaine (overleg) 9 apr 2009 15:44 (CEST)

Ik snap je punt wel, maar het hoort niet zo te zijn dat als een veld niet wordt ingevuld (bijv. omdat de gegevens onbekend zijn) dat er dan in het artikel een zeer opvallende foutmelding wordt getoond aan iedere bezoeker van die pagina. Natuurlijk is het wenselijk dat de ontbrekende velden ingevuld worden, maar als het sjabloon in de toekomst ook gebruikt gaat worden in artikelen over, ik noem maar wat, Moldavische, Pakistaanse of Nepalese gemeentes, dan komt dat probleem dus weer net zo hard terug. Bij de Franse gemeentes kunnen die aantallen misschien nog relatief eenvoudig gevonden worden, maar bij sommige gemeentes in andere landen zou het wel eens een stuk moeilijker kunnen zijn om die informatie te achterhalen (als het bij het lokale bestuur al uberhaupt bekend is). - Robotje 9 apr 2009 15:57 (CEST)

Het lijkt er op dat het in dit geval de fout ontstaat op alleen Franse gemeentes omdat er Franstalige gemeentetabellen worden gebruikt (en die worden natuurlijk niet op Moldavische, etc gebruikt). Maar desondanks kan er wellicht toch iemand naar kijken. Ondertussen loop ik via de zoekopdracht al deze pagina's af en voeg de ontbrekende parameter toe. Groetjes - Romaine (overleg) 9 apr 2009 16:32 (CEST)

Dat laatste is heel aardig. Bedankt. - Robotje 9 apr 2009 16:41 (CEST)

Sjablonen

In sjablonen wordt gebruik gemaakt van <noinclude> en <includeonly>. Ik snap dat <noinclude> nodig is om gedoe met categoriën te voorkomen, maar waar dient <includeonly> voor? Stijn 13 apr 2009 16:36 (CEST)

<Noinclude> dient niet alleen voor de categoriën, maar zorgt ervoor dat alles wat ertussen staat niet op de aanroepende pagina gezet wordt. Bijvoorbeeld ook de gebruiksaanwijzing die je wel te zien krijgt als je de sjabloonpagina zelf bekijkt, maar niet als je de aanroepende pagina bekijkt. "Include" slaat op het plaatsen op die pagina.

<Includeonly> is het tegengestelde: het komt wel op de aanroepende pagina, maar niet op de sjabloonpagina zelf. Het wordt wel gebruikt als de sjabloon parameters nodig heeft. Als je de pagina zelf bekijkt zijn die niet gedefinieerd, en dat kan foutmeldingen geven. Nadeel hiervan is dat ook foutmeldingen die samenhangen met programmeerfouten onderdrukt worden; het is dus moeilijker om de code te ontwikkelen. Tijdens de ontwikkeling kun je de <includeonly> even weghalen. Beter is het alle parameters die bij ontbreken foutmeldingen geven van verstekwaarden te voorzien, zodat ook op de sjabloonpagina een redelijke uitvoer getoond wordt. Bij codeerfouten krijg je de bijbehorende foutmeldingen dan ook te zien. Soms zet men <includeonly> om de code heen, en roept in het <noinclude>-gedeelte de sjabloon aan, met parameters. Dan krijg je wel het resultaat te zien, maar het nadeel is dat de "toon bewerking ter controle"-knop niet werkt, en je na opslaan het resultaat van de vorige bewerking te zien krijgt. Je moet dan nogmaals opslaan om het werkelijke resultaat te kunnen zien. -- LexTH overleg  13 apr 2009 17:19 (CEST)

Vlek op afbeelding

250 pixels breed	350 pixels breed (origineel)	370 px breed

Met mijn browser (Firefox) zie ik op het linker er rechter plaatje een zwarte rechthoek aan de linker kant terwijl het met het middelste plaatje wel goed gaat. Dit probleem doet zich ook voor op de pagina Eiffeltoren. Is de file corrupt of gaat er wat mis in m'n browser? Iemand een idee? - Robotje 28 apr 2009 16:35 (CEST)

Het is niet alleen met Firefox, ook met IE. En de afmeting hoeft maar 1 pixel af te wijken van de 350 van het origineel. Ook met thumb verschijnt de vlek. Ik heb trouwens geen enkel idee waar het aan kan liggen. -- LexTH overleg  28 apr 2009 17:09 (CEST)

Volgens mij is het nu opgelost. Er stond een "flowRoot" in de SVG die blijkbaar dit probleem veroorzaakte.

Na even zoeken zie ik dat hetzelfde probeem bijvoorbeeld ook optrad bij File:Pentominos.svg, maar het daar 2 jaar geleden al aangepast is. Dus dit probleem bestond al veel langer. ∼ Wimmel 28 apr 2009 18:33 (CEST)

Bedankt Wimmel voor het oplossen van dit probleem. - Robotje 29 apr 2009 07:30 (CEST)

Coördinaten route

Beste technici. Een volgend "probleem" is ontstaan: Een gebruiker wil zijn database met informatie omtrent hellingen beschikbaar stellen voor Wikipedia. Deze database bevat gegevens van een beginpunt van een helling en de top die onder meer wordt gehanteerd bij wielrennen. De informatie wordt nu toegevoegd door middel van een link naar Google Maps, waarop door middel van de routebeschrijvingsfunctie het begin en eindpunt worden aangegeven. (Zie voorbeeld Abeelstraat, bij Links) De coördinatenfunctie van Wikipedia kan naar mijn weten niet exact de locatie van iets aangeven, laat staan twee punten, op 1 kaart. Mijn vraag is dus: zie ik een functie over het hoofd of is dit met de huidige functionaliteiten echt niet mogelijk. En als dit er dus niet is, zou zo iets gemaakt kunnen worden met betrekking tot de coördinaten? De coördinaten hebben als voordeel dat ze niet afhankelijk hoeven te zijn van Google Maps. Als dit alles niet mogelijk is (of te verwachten is dat dit wordt ontwikkeld), dan zie ik nog een oplossing om een link te verwerken in Sjabloon:Infobox beklimming wielrennen. Maar ik hoor graag jullie reacties/ideeën. Pompidom 16 apr 2009 22:10 (CEST)

De huidige Google maps link opnemen naar een traject lijkt me prima; dergelijke link zal ik (en ik hoop anderen) niet verwijderen. Er staan diverse links naar specifieke Google maps op wikipedia, ook van bv een verzameling wolkenkrabbers in Eindhoven, zie de link onderaan De Admirant en trajecten van Franse wegen, zie bv N113 (Frankrijk).) Kortom, de link is een meerwaarde, en niet eenvoudig door een wiki-sjabloon of in 1 enkele coordinaat te vervangen en dus laten staan. Michiel1972 16 apr 2009 22:28 (CEST)

Hierdoor wordt de informatie wel afhankelijk van Google Maps. De vraag is of dat wenselijk is. Pompidom 16 apr 2009 22:39 (CEST)

Liever niet.. Maar een soort routeplanner-server maken voor verschillende kaartenaanbieders lijkt me vrij lastig. (En de gebruiker die huidige 1-punt-server onderhoud, Erik Baas, is helaas niet echt actief meer op wikipedia). Op termijn is het misschien wel een optie, en dan kunnen de externe google maps links alsnog worden omgezet naar een universele link naar meerdere aanbieders. Michiel1972 16 apr 2009 23:02 (CEST)

Oke. Bedankt voor je antwoord. Dan ga ik wel even kijken of het evt. mooi ingebed kan worden in het bovengenoemde sjabloon. Groet, Pompidom 16 apr 2009 23:07 (CEST)

Voor de toekomst zal er een goede integratie met OpenStreetMap komen. Wikimedia Deutschland investeert 15.000 Euro voor een pilot. Zie m:OpenStreetMap. Hoe dat er exact uit gaat zien weet ik nog niet. Misschien is het wel handig om voor die linkjes naar google maps een sjabloon te gebruiken, zodat makkelijk terug te vinden is waar die gebruikt worden, zodat die eventueel in de toekomst omgezet kunnen worden naar OpenStreetMap.

Ik kan wel een alternatief geven hoe je informatie op een kaart kunt zetten. Ik heb eens op wikipedia een KML bestand gezet (Gebruiker:Wimmel/Molens.kml). Zie dit voorbeeld hoe dat in google maps eruit ziet. Dit voorbeeld bevat alleen 5 posities, maar lijntjes kunnen zo ook tussen gezet worden. ∼ Wimmel 16 apr 2009 23:22 (CEST)

Zolang kml een standdaard is die vrijwel alleen door Google earth/maps te gebruiken is, schiet je er niet veel mee op om de gebruiker een minder monopolistische keuze aan te bieden. Michiel1972 16 apr 2009 23:45 (CEST)

Het is natuurlijk beter als er alternatieven zijn, maar beter één mogelijkheid dan geen mogelijkheid. -- LexTH overleg  17 apr 2009 00:16 (CEST)

KML kende ik nog niet, ik zal dat wel eens bekijken. Bedankt voor de informatie. Pompidom 17 apr 2009 15:23 (CEST)

Ondertussen is het mij ook gelukt om zo'n kml-bestand te maken voor de Abeelstraat. Zie hier voor de uitwerking, hier voor het kml-bestand. Nu nog even bedenken hoe dit dan mooi geïntegreerd kan worden. Pompidom 17 apr 2009 15:57 (CEST)

KML is wel een open standaard: http://www.opengeospatial.org/standards/kml/ en is blijkbaar buiten google ondergebracht. Lijkt me dus opzich wel een optie om een op kml gebaseerde oplossing te bedenken. Akoopal _overleg 18 apr 2009 00:18 (CEST)

Ik zie toevallig dat er al diverse kml files op commons staan, bijvoorbeeld te zien op Tongeren - Gembloux.svg. Daar staat een linkje dat Commons:File:Tongeren - Gembloux.svg/overlay.kml via de toolserver download, en dat is dan direct in google earth te laden. En in google maps ziet dit er zo uit: [4]. Zie ook Commons:Geocoding/Overlay. ∼ Wimmel 21 mei 2009 00:07 (CEST)

Dat is ook een interessante mogelijkheid, zeker bij routes die langer zijn dan 1 straat (zoals het geval was bij de Abeelstraat). Ik zal het eens later goed bestuderen. Bedankt voor het melden. Pompidom 21 mei 2009 00:10 (CEST)

Jammer dat dit google earth gebruikt, dan is het afhankelijk van op de computer geïnstalleerde software, via google maps zou handiger zijn. Akoopal _overleg 21 mei 2009 09:44 (CEST)