Overleg gebruiker:Erik Baas/Externekaartenscript

Positie coordinaten sjabloon

Hoi, ik draai momenteel 3 bots: 1 om te importeren, 1 om te corrigeren met nullen en 1 om te verplaatsen. Ik heb nog eens nagedacht en de locatie van het coordinaten sjabloon kan denk ik het beste ergens bij de categorieen en interwiki's staan. De positie helamaal boven een artikel (wat ik vroeger altijd deed) kan verwarrend zijn voor iemand die het artikel wil gaan bewerken. Op de.wikipedia zetten ze het sjabloon ook net boven de interwiki's. Michiel1972 8 jan 2007 01:32 (CET)

Oei, kan dat niet in één slag ? Wat de plek in de code betreft: is het niet logisch om het sjabloon bovenaan te plaatsen, omdat de tekst toch ook helemaal rechtsboven verschijnt ? P.S.: Er zitten erg veel fouten in de coordinaten en andere parameters, ook fouten die door het script op de toolserver niet geaccepteerd danwel genegeerd worden... :-( - Erik Baas 8 jan 2007 01:35 (CET)

Wat bedoel je met fouten? Ik zie soms nog wel eens een ? of | maar dat is in de tekstlabels die ik altijd nog kan corrigeren. Bij de parameters blijf ik hopen dat je server net zo flexibel is als de Duitse/Engelse. Of geef even wat links naar coordinatensjablonen niet volgens jouw niet zullen worden geaccepteerd, dan kan ik ze ook aanpassen. Michiel1972 8 jan 2007 01:41 (CET)

1. het opgeven van een type: én een scale: - werkt niet
2. scale:8000000 voor een schiereiland (net gedaan, ben de naam even kwijt) - slaat nergens op

• voorbeeld (net gedaan): Southamptoneiland, had "type:isle", dat is ook op de: niet getest (veel te grote zoomfactor).

Ik was aan de hand van deze pagina bezig, maar dat is geen doen (het zijn er teveel). Wat mijn script betreft: het formaat van graden/minuten/seconden/N of S, plus idem E of W, plus een schaal of type is heilig, verder maakt het niet veel uit. Als een schaal of type dubbel vermeld wordt zal de laatste genegeerd worden, dat wel. - Erik Baas 8 jan 2007 01:52 (CET)

Er zijn ook veel pagina's waar {{coordinaten}} nu twee keer op staat, zie je misschien kans dat vooraf te checken ? - Erik Baas

Als er zowel een type:, regio: en scale: aanwezig is, (in een willekeurige volgorde), is dat werkbaar? waarbij de scale maatgevend is" Michiel1972 8 jan 2007 01:57 (CET)

Naast type:xxx of scale:nnn of zoom:nn kan region:XX er ook bij, dat staat los van elkaar; "region:" blijkt alleen invloed te hebben op de te tonen extra opties (zoals links naar lokale, regionale of nationale) kaartservers, dat is in mijn script nog niet geïmplementeerd, maar dat komt nog. - Erik Baas 8 jan 2007 02:03 (CET)

Als type:, scale: of zoom: meer dan eens voorkomen wordt de laatste gebruikt, en de eerdere genegeerd. Tenzij er in totaal meer dan tien parameters zijn, de elfde etc. doen so-wie-so niets. - Erik Baas 8 jan 2007 02:05 (CET)

Echte dubbele coordinaten sjablonen worden verwijderd (circa 1%). Een infobox met coordinaten tel ik niet als dubbel. De link rechtsboven is een standaardopmaak, de inline sjablonen zie im als een extra. Michiel1972 8 jan 2007 02:01 (CET)

Ik heb er toch een paar gezien; maakt je bot onderscheid tussen "{Coordinaten}" en "{Coördinaten}" ? - Erik Baas 8 jan 2007 02:03 (CET)

Mapquest en meer andere kaartbronnen

Volgens mij moet het niet al te moeilijk zijn om ook een link op de Server te maken naar kaartmateriaal van Mapquest. Ik vind het een prettige kaart voor een snelle orientatie van een plaats ten opzichte van buurgemeenten/plaatsen, en heb deze destijds ook als directe externe link heb toegevoegd op de Franse gemeentes. Op sommige gebieden scoort de kaart beter dan Google Maps (bv. Mexico). Je doet me er een groot plezier mee :) Groet Michiel1972 9 jan 2007 01:55 (CET)

Is het ook, net als al die andere. ;-) Eerlijk gezegd: MapQuest was al enabled, maar er bleek in bepaalde gevallen een afrondingsfout op te treden, en ik heb tot nu toe geen rustig moment gevonden om dat eens grondig aan te pakken. Vandaag en morgen komt 't er ook weer niet van, dat weet ik al, maar ik hoop je binnenkort dat plezier (en meer) te kunnen doen. ;-) - Erik Baas 9 jan 2007 02:09 (CET)

Ik zou zelf een link-optie naar Google Earth wel heel makkelijk/nuttig vinden, vooral nu Google Maps nog geen "Open deze locatie in Google Earth" linkje bevat die er mogelijk wel aan zit te komen. Ik weet dat je het niet redt met een simpel scriptje dat de coordinaat omrekent naar een URL met dat coordinaat ergens als parameter erin, maar het moet te doen zijn. Het minimaal stukje XML inhoud voor een KML met alleen de coordinaat en omschrijving erin is zo gemaakt en een script dat dit via HTTP teruggeeft met de juiste KML MIME-type erbij is ook niet zo heel moeilijk. Denk je dat je daar misschien ook mogelijkheden voor kan vinden? Indien nodig wil ik best helpen als ik kan. - Jarno | Overleg 9 jan 2007 08:01 (CET)

Zie bijvoorbeeld de KML server info van Google zelf. De MIME-type is dus application/vnd.google-earth.kml+xml kml.

En volgens mij is (als voorbeeld voor Adam Air-vlucht 574) het volgende als minimale content genoeg:

<?xml version="1.0" encoding="UTF-8"?>

<kml xmlns="http://earth.google.com/kml/2.1"><Document><Placemark>

<name>Adam Air-vlucht 574</name>

<description>http://nl.wikipedia.org/wiki/Adam_Air-vlucht_574</description>

<Point><coordinates>119.1547222222222,-3.388919496300349</coordinates></Point>

</Placemark></Document></kml>

Dan zit je mogelijk nog met die scale optie (deze default zoomt misschien wel een beetje ver in in Google Earth), maar in ieder geval heb je de locatie dan wel precies. - Jarno | Overleg 9 jan 2007 08:35 (CET)

Een directe link naar Google Earth op basis van een klein kml-bestandje zou inderdaad ook leuk zijn :) Michiel1972 9 jan 2007 23:26 (CET)

Klopt het dat wanneer je geen enkele scale, type of region opgeeft er een fout optreedt? Zie Gebruiker:Michiel1972/test2. Michiel1972 9 jan 2007 23:24 (CET)

Niet meer: "region:" mocht je al weglaten, "scale:"/"type:"/"zoom:" nu ook, dan wordt de default (zoom:12) aangenomen. Google Earth zal ik later eens induiken, er zijn nog een paar andere dingen die ik eerst wil (nee, moet) aanpakken. - Erik Baas 10 jan 2007 00:01 (CET)

De link naar MapQuest is hersteld; blijkt via een andere ingang wél decimalen in de parameters te accepteren. :-) - Erik Baas 12 jan 2007 21:32 (CET)

Er is een experimentele link naar een een kml-bestandje toegevoegd (via de URL van sjabloon:kml), maar die kan ik zelf niet testen... - Erik Baas 12 jan 2007 21:43 (CET)

In het kml scriptje wordt wel een "schaal" (bij Google Earth wordt het een omgerekende hoogte) bepaalt op basis van de opgegeven schaal of type. Zou die 2 parameters kunnen doorsturen naar de kml-link? Dus &alt= invullen met de oorspronkelijke schaal/type data? Michiel1972 15 jan 2007 02:08 (CET)

Moet kunnen; het gebruik van "altitude" ken ik inmiddels, MSN Maps werkt er ook mee. Ik heb alleen geen idee wat voor waarden je aan Google Earth moet opgeven... Het script op WikiKML.brinkster.net lijkt niet op &alt= te reageren, of doe ik iets fout ? Lastig dat ik zelf Google Earth niet heb. :-( - Erik Baas 15 jan 2007 02:28 (CET)

Als je kijkt op Moskou in de infobox, de directe {kml}-link geeft wel een waarde mee met &alt=, de link via {coor} en de server 'verliest' die info. Vreemd? Michiel1972 16 jan 2007 01:23 (CET)

Nee, dat is niet zo vreemd: het externe script doet er gewoon niets mee. Dat komt doordat ik geen flauw idee heb welke waarde ik in welke parameter moet meegeven, vandaar ook mijn vraag van 15 jan 2007 02:28 (zie twee regels hierboven). Overigens: ik zie dat {{kml}} &alt=type:city(10126424) doorgeeft aan het script op brinkster, maar de inhoud van dat asp-bestand wordt daar niet door beïnvloed. Ik neem aan dat "range" en/of "altitude" afhankelijk zouden moeten zijn van de parameter "alt" ? Okee, even concreet:

1. Wat is de naam van de parameter in het script op brinkster waarin de schaal/zoomfactor/whatever opgegeven moet worden ?
2. Welke inhoud moet/kan die parameter hebben ?
3. Wat is de invloed daarvan op de inhoud van het resultaat (bestand kml.asp) ? Gaat het om range, altitude, of beide ?

- Erik Baas 16 jan 2007 01:47 (CET)

Op dit moment gelden de volgende 'regels': is &alt= "leeg" dan altitude 5000 meter. Bevat &alt een "scale:...", dan wordt deze scalewaarde 1 op 1 overgenomen als altitude. Bevat &alt "type:country" dan wordt er flink uitgezoomd. Verder uitbreiding/finetuning (bv type:city(xxx) en correcties in deze aannames kunnen natuurlijk nog plaatsvinden, maar in principe wil ik dat het script rekening houd met zowel het type en/of opgegeven scale in het sjabloon {coordinaten}. Vandaar het verzoek om gewoon alle beschikbare parameters (9e, 10e, 11e ?) mee te sturen die gegevens bevatten van type:.._scale:..._region:.. Goeienacht Erik. Moet om 9 uur weer naar m'n werk :) Michiel1972 16 jan 2007 02:12 (CET)

Aha, type: en scale:, daar heb ik nét iets over geschreven op jouw OP, vandaar ook dat je hier niet meteen antwoord kreeg. ;-) Morgen meer, ik zie het nu ook niet zo scherp meer... Truste. - Erik Baas 16 jan 2007 02:35 (CET)

Flickr, Google Earth en Wikipedia geintegreerd

Hoi Erik,

Graag hoor ik jouw reactie op deze toepassing: (voorbeeld:) Foto's van Amsterdam, op locatie geprojecteerd in Google Earth

Ik had voor mezelf allerlei foto's van Flickr die voorzien zijn van coordinaten in Google Earth gehangen; Later heb ik hier Wikipedia links aan toegevoegd, en er een domeinnaam aangehangen. Uit vele reacties begrijp ik dat deze combinatie errug gewaardeerd wordt, en opname verdient in Wikipedia.

Het idee is om de gebruikers mee te laten helpen om de beste en meest interessante foto's voorop te plaatsen, EN om nog veel meer foto's van coordinaten te voorzien, zodat uiteindelijk iedere straat ter wereld in beeld gebracht is. Een waardevolle toevoeging aan de Wikipedia pagina's!

Tips en trucs ter verbetering en hoe de koppeling met Wikipedia te leggen, zijn zeer welkom. Volgens mij is de combinatie van Google Earth, Flickr en Wikipedia heeeel interessant!

RonaldXperience 17 jan 2007 17:54 (CET)

Gaaf idee. :-) Maar, hoe wil je linken tussen WP en wereldkenner.nl ? - Erik Baas 19 jan 2007 00:16 (CET)

Thanks! :-) Linken lijkt mij kunnen door externe links in Wikipedia artikelen en vanuit wereldkenner.nl per pagina een link naar de wikipedia artikelen? (vanuit Wereldkenner.nl staan die er uiteraard al) RonaldXperience 23 jan 2007 22:32 (CET)

Een externe link op Amsterdam leek mij wel een goed idee, maar daar is kennelijk niet iedereen even enthousiast over. En andere mogelijkheden zie ik eerlijk gezegd niet... - Erik Baas 24 jan 2007 01:01 (CET)

Erg leuk. Maar zoiets bestaat ook al: loc.alize.us. Foto's van flickr kunnen hier op een Google maps kaart worden gezet. Dit ziet er echt fantastisch uit! Dus waarom hier geen gebruik van maken?
Misschien is het ook mogelijk om die website op te nemen op je site: Wiki Maps
Josjojo 24 jan 2007 10:30 (CET)

Ha, een neefje van Panoramio, maar dan mooier (en helaas ook nóg trager). Ik zal 'm er bij zetten, bedankt voor de tip. :-) - Erik Baas 24 jan 2007 12:34 (CET)

Hoi Erik, De discussie over toevoegen van externe links naar Wereldkenner is niet echt 1duidig verlopen; wellicht beter om wereldkenner.nl toe te voegen aan jouw externe script? Ik zal iets inbouwen waardoor de pagina's ook via coordinaten te benaderen is; of nog beter, kan in jouw script ingebouwd worden welke WikiPedia pagina vandaan gelinkt wordt? dat is dan direct de link ook naar de betreffende wereldkenner pagina. RonaldXperience 26 jan 2007 12:26 (CET)

Ik vrees dat "wereldkenner" daar (nog ?) te klein en onbeduidend voor is, gezien het aantal foto's, maar ook het feit dat de zoekfunctie maar een paar steden vindt (b.v. Alkmaar en Utrecht zijn niet eens bekend !). Het idee voor die site is prima, maar niet om vanuit dit centrale script naar toe te linken (vind ik). Bedenk wel dat Wikipedia nu op circa 64000 pagina's een link naar dat script heeft, dat zou beteken dat de kijker een kans van 1 op pakweg 1000 heeft om inderdaad foto's aan te treffen. Het zou interessant kunnen zijn als "wereldkenner" via coördinaten te benaderen zou zijn, én alle foto's op Flickr (die met geo-data, uiteraard) langs deze weg getoond zouden worden. - Erik Baas 26 jan 2007 21:54 (CET)

Ik ben druk bezig de site idd ook via coordinaten benaderbaar te maken; en wat betreft de foto's: Ik heb nou juist NIET alle ge-geotagde foto's erin opgenomen (hetgeen simpel is), maar juist een selectie op basis van TAGS, om te voorkomen dat allerlei prive en nietszeggende foto's te zien zijn, maar dat vooral de highlights van de betreffende stad erop staan. Dat was wat mij vooral stoorde aan andere sites die Flickr foto's laten zien.

Enne, nu 250.000 foto's geselecteerd, is toch niet echt weinig ;-) Misschien toch een heroverweging waard? (als de coordinaten optie erin zit)? RonaldXperience 27 jan 2007 22:01 (CET)

Ik ben nog niet enthousiast. Goed, 250.000 is veel meer dan ik geschat had, maar tot nu toe vind ik ze alleen bij een paar plaatsnamen als Amsterdam en Londen, het is net of b.v. Bobeldijk en Utrecht niet bestaan. Links vanaf wereldkenner naar Wikipedia zulen dus ook wel zo gering in aantal zijn, maar je schermt er wel mee als aanbeveling...

Wat is trouwens je criterium voor de selectie van de tags ? Ik denk niet dat het goed is voor WP als één persoon bepaalt wat wel en wat niet wordt getoond. En waarom link je naar een kopie van Amsterdam in een veel te klein en kleurloos popup-venster, waarin de browser gekreupeld is (menu's, toolbars etc. zijn weg) en de links niet zichtbaar zijn (maar de URL's van de externe links juist weer wel) ? Waarom niet gewoon naar WP zelf ?

Verder is de opmaak van je site ook niet bepaald fraai te noemen. De code barst van de fouten (Firefox meldt er 15, alleen al in CSS en JS), en vraag ik me af waar "adcount.cgi" toe dient... En is de titel "wereldkenner" niet een beetje overdreven ?

Een koppeling tussen Wikipedia, Flickr en Google Maps is op zich een goed idee, maar dan moet het wel beter en meer neutraal uitgevoerd worden, en het moet geen eenrichtingsverkeer van WP naar wereldkenner worden... Maar goed, dat is mijn mening... [hint] - Erik Baas 27 jan 2007 22:50 (CET)

ViaMichelin

Ik zag dat je website ook linkt naar ViaMichelin aan de hand van de plaatsnaam. Echter doet die dat niet voor iedere plaats. Is daar een reden voor, of vergelijk je de plaatsnaam met een database? In principe kan je met iedere artikelnaam naar ViaMichelin linken, alleen de parameter strLocation is nodig. En dan het liefst zonder het eventuele deel tussen haakjes wat er achter staat. Komt de naam niet voor bij ViaMichelin of zijn er meerdere plaatsen met die naam, dan krijg je een keuzemenu te zien met eventueel plaatsnamen die er op lijken. Hans (JePe) 24 jan 2007 01:07 (CET)

De naam die aan ViaMichelin wordt doorgegeven is slechts de titel van het lemma, waarvan eventuele toevoegingen tussen haakjes (zie b.v. Hoorn (Noord-Holland)) worden verwijderd. Verder is meestal de regiocode bekend (b.v. NL of BE), en aan de hand daarvan wordt uit een tabel de landcode gelezen (b.v. NL=285). Ik weet dat het niet voor alle plaatsnamen werkt, dat zou een aanpassing van alle huidige sjablonen vergen (en per artikel moeten dan, speciaal voor ViaMichelin, de exacte plaatsnaam en regiocode, maar ook (als de naam meer dan eens voorkomt) de postcode worden ingevuld). Kortom, erg veel werk, en daar wilde ik eigenlijk nog maar even niet aan beginnen, vooral omdat er nog zoveel andere (en IMO belangrijker) dingen te doen zijn aan de sjablonen en het externe script... - Erik Baas 24 jan 2007 01:16 (CET)

Zoals ik al schreef is een landcode of postcode helemaal niet nodig. Alleen de plaatsnaam is nodig, en komt die meerdere keren voor dan krijg je een overzichtskaartje met de verschillende locaties waaruit je kunt kiezen. Dus je hoeft alleen maar de artikelnaam aan ViaMichelin door te geven, eenvoudiger kan het niet. Hans (JePe) 24 jan 2007 02:58 (CET)

Ja, klopt, maar ik had al verder gedacht en gekeken: als je de regio- en/of postcode opgeeft krijg je meteen de juiste plaats, zonder nog eens een keuze te moeten maken. Het maakt trouwens weinig verschil, in beide gevallen moeten er 12 sjablonen en ~64500 pagina's worden aangepast...  ;-) Of heb jij een beter idee ? Ik ben nu druk bezig met het script (net Yahoo! Maps toegevoegd), daarna moeten de sjablonen aangepakt worden (er zijn er veel te veel, en de werking is vaak onduidelijk), én ik ben halverwege een help-pagina voor de coördinaten, en ik vind ViaMichelin niet belangrijk genoeg om er nu extra aandacht aan te besteden (en de halve WP overhoop te halen), misschien later... - Erik Baas 24 jan 2007 03:39 (CET)

Er hoeft niets aangepast te worden binnen Wikipedia. Het sjabloon geeft de artikelnaam door aan jouw server. Die haalt vervolgens het eventuele deel tussen haakjes er af. Wat overblijft geef je met de parameter strLocation mee in de viamichelin url. Jouw serverscript hoeft alleen maar die parameter aan de url vast te plakken, ongeacht de locatie of het soort object. Andere parameters zoals strCountry zijn niet nodig en maken het alleen maar ingewikkeld.

Er zijn natuurlijk voor bepaalde locaties zoals buiten Europa of bouwwerken geen kaarten beschikbaar, maar dan geeft viamichelin een lijstje namen die er op lijken en kan de gebruiker zelf beslissen of hij het bekijkt, bijvoorbeeld Alcatraz.

Je kunt het natuurlijk onnodig gecompliceerd maken met nieuwe parameters in het sjabloon, maar ik denk dat niemand zin of tijd heeft voor duizenden sjablonen de juiste gegevens op te zoeken en die aan te passen. Dus waarom zou je het moeilijk doen als het simpel kan.

Sorry dat ik enkele woorden vet heb gemaakt, ;) ik probeer alleen maar hetgene wat ik hierboven al heb geschreven duidelijker te omschrijven. Hans (JePe) 24 jan 2007 14:26 (CET)

Maar... het script geeft die parameter al door (sinds versie 0.52, 18 januari), zie b.v. Hoorn (Noord-Holland). Begrijp ik nu goed dat dat niet voor alle pagina's werkt ? Dat zou kunnen komen doordat de link in een van de sjablonen niet compleet is; het script geeft stomweg de waarde in "src" door (na het verwijderen van het deel tussen haakjes). Heb je een voorbeeld voor me van een pagina waar het niet werkt ? - Erik Baas 24 jan 2007 14:36 (CET)

Er is nog iets anders aan de hand: omdat ViaMichelin alleen maar kaarten leek te geven voor NL en BE, checkt het script nu op "region" en schakelt ViaMichelin alleen in voor die twee regiocodes. Is dat soms wat jij bedoelt ? In elk geval is het tijdelijk, zodra alle regiocodes bekend zijn kan VM voor heel Europa geactiveerd worden. - Erik Baas 24 jan 2007 15:03 (CET)

Of zal ik het omdraaien: VM kan altijd aangeklikt worden, als de regiocode bekend is en binnen Europa valt geeft het script 'm door, en anders wordt alleen strLocation doorgegeven (en mag de kijker zelf kiezen) ? - Erik Baas 24 jan 2007 15:08 (CET)

Ja, dat zou prima zijn. Ik heb de afgelopen tijd al op heel wat Nederlandse plaatsen en andere locaties coördinaten toegevoegd, maar met alleen de zoomfactor erbij, zonder parameters die de regio of soort locatie aanduiden. Hans (JePe) 24 jan 2007 15:31 (CET)

Het zit er (op proef) in, bevalt me tot nu toe wel (na een paar steekproeven). 't Is niet echt wat ik voor ogen had, maar dit lijkt me het best mogelijke resultaat, gezien de data van WP en de mogelijkheden van VM. - Erik Baas 24 jan 2007 16:26 (CET)

Explore Our Planet

Als ik de Explore Our Planet link naar een plaats als Geervliet open vanuit http://www.nsesoftware.nl/wiki/maps.asp?params=51_51_40_N_4_15_44_E_type:city_zoom:15_region:NL&src=Geervliet krijg ik heel Zuid-Holland te zien. Is dat wel nuttig? GeoNL 26 jan 2007 22:30 (CET)

Ja en nee: ik heb aangenomen dat die site niet gebruikt zal gaan worden om b.v. het fietspad tussen Geervliet en (vulmaarin) op te zoeken, maar meer voor satellietbeelden van NASA met actuele info over bewolking en stormen etc., en dan is inzoomen op een stad of dorp juist niet handig. (Hm, deze zou dus eigenlijk onder "Andere links" moeten staan...) P.S.: Ook dat externe script is nog volop in ontwikkeling, en deze link is pas gister (of eergister) toegevoegd. - Erik Baas 26 jan 2007 22:38 (CET)

En als ik http://loc.alize.us/#/geo:51.86111,4.26222,15,k/ open , Geervliet, zie ik allemaal babyfoto's. Is dat nuttig? GeoNL 26 jan 2007 22:33 (CET)

Neen. ;-) - Erik Baas 26 jan 2007 22:38 (CET)

Maar serieus: voor veel andere plaatsen geeft loc.alize.us foto's van b.v. de omgeving van en gebouwen in de betreffende plaats, en dat kan soms weer wel interessant zijn. - Erik Baas 26 jan 2007 23:02 (CET)

Coördinaten in een tab

Ik ben wat met javascript aan het knutselen geweest, met als resultaat de coördinaten in een tab (in het rijtje overleg - bewerk - geschiedenis). Met het onderstaande stukje script in je monobook.js verschijnt in een artikel een extra tab en worden de coördinaten op de normale plaats weggehaald als er coördinaten in een artikel staan:

// verplaats de coördinaten in een artikel naar een tab
function coordinatesInTab()
{
   if (wgNamespaceNumber != 0) return; // alleen artikelen
   var node = document.getElementById("coordinates");
   if (!node) return;
   var url = node.getElementsByTagName('a')[0].href;
   if (!url) return;
   if (url.search(/wikipedia.org/) != -1) return; // het moet een externe link zijn
   var tooltip = node.getElementsByTagName('a')[0].innerHTML;
   tooltip = tooltip.replace(/&nbsp\;/ig," "); // nbsp; vervangen door gewone spatie
   tooltip = tooltip + " - kaarten en satellietfoto's";
   addPortletLink("p-cactions",url,"coördinaten","ca-coordinates",tooltip);
   node.parentNode.removeChild(node); // coördinaten op normale plaats verwijderen 
}
addOnloadHook(coordinatesInTab);

Hans (JePe) 30 jan 2007 13:28 (CET)

Gaaf idee, ik ga het zeker proberen ! :-) - Erik Baas 31 jan 2007 00:23 (CET)

Gave truc, werkt prima, dank je ! Het wordt alleen wel even wennen... ;-) - Erik Baas 31 jan 2007 02:04 (CET)

Tja, het is wel wennen, ik kwam vandaag nog op een artikel en vroeg me af waar de coördinaten gebleven waren totdat ik me even later realiseerde dat ze er vlak boven in een tab stonden ;). Je zou ze ook in de zijbalk kunnen plaatsen, dan heb je wat meer ruimte voor een wat langere en duidelijker tekst, bijvoorbeeld een link met de tekst "Kaarten en satellietfoto's".

Helaas, ik kijk/grijp te vaak mis, ga de oude toestand weer herstellen. Jammer van het idee en het werk, sorry... - Erik Baas 1 feb 2007 22:18 (CET)

Nog wat anders, ik ontdekte vandaag bij Google maps dat als je de parameter ll vervangt door q dan krijg je een foto over de gehele breedte van het venster. Daarbij kun je ook nog tussen twee haakjes een omschrijving meegeven, bijvoorbeeld de artikelnaam:

http://maps.google.nl/maps?q=52.3666666666667,4.9+(Amsterdam)&z=13&hl=nl&t=k

Hans (JePe) 31 jan 2007 21:57 (CET)

Die optie kende ik, en die heb ik er (in de tijd dat nog naar maps.google.com verwezen werd) om een goede reden uitgehaald; en ik weet niet meer waarom... ;-) - Erik Baas 1 feb 2007 22:18 (CET)

Google toont de kaart waarvan in "q=" de coördinaten opgegeven zijn, maar gaat ook zoeken naar de plaatsnaam (!) die er achter staat, en dat geeft (vanaf WP) vaak een foutmelding als "niet gevonden" of de vraag "bedoelde u [...] ?". - Erik Baas 3 feb 2007 01:49 (CET)

Sjabloon:MapsServerSRC

Ik denk dat dit sjabloon beter weg kan, destijds geintroduceerd om backwards compatible te kunnen zijn met de oude mapserver, die zoiets niet kent. Is verwijdering ok? Michiel1972 12 feb 2007 02:12 (CET)

Ja, zeker ! Eigenlijk moet de toevoeging {{PAGENAMEE}} in {{MapsServer}} komen, want op dit moment geven niet alle coördinatensjablonen de pagename door. Dat is nogal een ombouwactie, die pak ik een dezer dagen op een rustig moment aan. En het gebruik van MapsServerSRC is niet echt zinvol, want het script op de toolserver negeert die waarde toch. P.S.: Ik heb net {{Coördinaten dec}} gemaakt, waarmee de invoer nog gemakkelijker wordt (decimale waarden !). En: het externe script linkt nu ook naar Wikimapia, ken je die site ? - Erik Baas 12 feb 2007 02:19 (CET)

Wikimapia, ja die ken ik...maar ik was niet geheel enthousiast bij nader inzien Overleg_gebruiker:Erik_Baas/Archief_2006_4e_kwartaal#Coordinaten.2Fmaps_server.

Nou moe... Kennelijk vond er ik toen niks aan (en was ik dat inmiddels vergeten), maar vanmiddag zag ik toch een paar leuke dingen op die site. Enfin, het script biedt de mogelijkheid, de keuze is aan de gebruiker. Wat vind jij ?

Morgen hoop ik trouwens een Google Earth bestand van alle (directe) coordinaten op de nl.wiikipedia te publiceren. Dan wordt het surfen op GE een echt feest van geografisch Wikipedia-artikelen kiezen en bewerken. (Nouja, voor de liefhebbers dan..). Dat is tevens een min-puntje voor alle afgeleide/incapsulated coordinatensjablonen (en waarom ik afgelopen dagen bezig was om veel coordinaten te verplaatsen buiten een infobox): deze zijn niet leesbaar door een "extract"-tool. Michiel1972 12 feb 2007 02:39 (CET)

Aha. Dan moet ik toch ook maar eens aan GE; het probleem is dat mijn beestje dat eigenlijk niet aankan... - Erik Baas 12 feb 2007 02:47 (CET)

Ik vroeg me al af waarom je geen GE op je comp hebt, dat is toch het 'heaven' van de geo-coords-liefhebbers :P ? (Naast Wikipedia, DE uitvinding/vernieuwing van de 21e eeuw) Nouja, het heeft me aardig wat tijd gekost, maar ik heb een GE condensatie van nl.wikipedia (download) gemaakt, en ben daar wel blij mee. Enkele leermomenten samengevat: 1) er waren nog een aantal 'rotte' coordinaten-sjablonen aanwezig (b.v Grad Min Sec bij NB, maar alleen Grad bij OL, en allerlei combinaties daarop). De meeste heb ik nu wel aangepast voor de volgende update. 2) Een groot deel van de sjablonen had geen region parameter, waardoor het niet mogelijk was ze in een subfolder naar land in te delen (NL, BE, US, AT etc), wel jammer, ik houd van categorisering, ook in GE 3) Artikelen met een & erin geven veel probleem, een kml bestand met zoiets erin geeft errors in GE. Kwam alleen 4x voor op 58.000, maar kostte me wel 2 uur om te ontdekken. 4) Niet vastgelegde type-parameters heb ik moeten skippen (area, nature, village). 5) Bij zoveel coordinaten per 100km2 is het niet meer acceptabel ze allemaal tegelijk te laten zien, vandaar het gebruik van een gevoeligheid LevelOfdetail parameter om coordianten te tonen bij een zekere hoogte. Is redelijk gelukt, maar kan nog beter denk ik. Landmarks zijn pas zichtbaar als men tot op 10km inzoomt, plaatsen zijn zichtbaar bij 25 km hoogte. 6) van een antal landen (Bolivia, estalnd) zijn wel coordinaten beschikbaar in een infobox, ook getoond als coordinaten, maar nog niet als coordinaten-sjabloon op het artikel zelf (en daarom niet meegenomen in deze update). Staat op mijn ToDo-lijst. (En nu neem ik als beloning een week wiki-pauze.) Groet, en werk ze! Michiel1972 12 feb 2007 22:13 (CET)

Ik wil wel hoor, maar ik weet al dat ik er dan weer veel te veel tijd in ga steken (ik ken mezelf)... ;-) Fouten: ik kom ze nog af en toe tegen (in het log van mijn webserver) en zet ze meteen even recht, maar ik heb niet de illusie dat we dit ooit 100% perfect krijgen. Hetzelfde geldt voor de region, maar elke fix is meegenomen (en dat doe ik dan ook, als ik ze tegenkom). Neem het er even lekker van, gezien de onwijze hoeveelheid werk die je er aan gedaan hebt heb je het wel verdiend. :-) - Erik Baas 12 feb 2007 22:47 (CET)

Komen type's als area, nature en village veel voor, en is het misschien zinvol om die in het externe script op te nemen ? - Erik Baas 13 feb 2007 00:11 (CET)

Inzoomfactor bij type:landmark

hallo, klopt het dat de tool bij een type:landmark altijd een zoomfactor van 15 kiest? Zou je dat kunnen aanpassen naar zoom:17, want het gaat dan om gebouwen en een maximaal gewenst niveau van detail? En/of indien een zoom/scale aanwezig die als doorslaggevend te gebruiken?. (Zie ook een vraag op mijn overleg) GeoNL 14 feb 2007 16:46 (CET)

1: Die waarde van 15 werd ook op het oude ext. script al gebruikt, en om ook compatibel te blijven met het script op de toolserver verander ik die liever niet. 2: Het is nu zo dat de laatst opgegeven waarde voor zoom/scale/type (die nu dus nog gelijkwaardig zijn) prioriteit heeft boven evt. eerder opgegeven waarden, maar ik ben er achter gekomen dat "type" meer mogelijkheden biedt (m.n. in de interface naar Google Earth) en ik wil ze van elkaar gaan loskoppelen; scale of zoom zal dan altijd boven type gaan (Help:Externe kaarten is op dit punt ook nog niet duidelijk, sorry). Dus: ja, nee en ja. ;-) - Erik Baas 14 feb 2007 16:56 (CET)

Is gebeurd: zoom of scale heeft nu prioriteit boven type; type wordt alleen gebruikt om de zoomfactor te bepalen als beide andere waarden ontbreken (en dat is niet aan te bevelen), en de volgorde is niet meeer van belang. - Erik Baas 14 feb 2007 17:45 (CET)

Explore Our Planet

De Explore Our Planet-link staat nu bovenaan, maar is de minst interesante link voor iemand die een duidelijke kaart/satellietbeeld zoekt zonder zelf te hoeven in te zoomen. Ik denk dat deze beter onder het kopje "andere links" past. Ook het verschil tussen 'online' / 'locaal' moest ik even over nadenken. NASA en GE zijn ook alleen online te bekijken, maar met een apart programma. Misschien is 'weblink'/ 'locaal' een beter onderscheid. Enne..het begint al een hele lijst te worden zeg..misschien tijd voor een nieuwe layout (met logo's ofzo). Nog een idee: misschien de volgorde tonen op basis van populariteit (aantal hits per week oid). Michiel1972 21 feb 2007 00:41 (CET)

Opmaak / weggestopte link luchtfoto's

Beste Erik,

Leuk dat jij of jou bot pagina's professionaliseert / standaardiseert met een werldbolletje / coordinaten. Jammer is (m.i.) dat daarmee het doel van een link (namelijk; het direct laten zien van een luchtfoto van een bepaald gebied) wegvalt. De lezer van de pagina ziet ten eerste niet wat het luchtbolletje betekent. OK, daar zal hij snel aan wennen, en misschien valt dit wel mee. Maar erger is volgens mij de tabel die dan te zien is, met een woud aan mogelijkheden. Iemand die snel een luchtfoto van een gemeente had willen zien, moet nu maar weten wat al die nasa-bronnen e.d. allemaal te bieden hebben. Sommige werken zolangzaam, dat bij twee klikken, je maar niet meer probeert, en dus terug gaat naar de gemeente / oorspronkelijke site, en jou tabel (met ongetwijfeld zinvolle links) links laat liggen. Voorstel: zet de betekenis van de links in je tabel niet rechts, maar links. Dat een bron nasa o.i.d. is, is van secundair belang, zet die dus rechts. Daarnaast; volgens mij gebruik je de tabel voor zoveel toepassingen. Vanuit allerlei gemeente/wijk sites is die tabel misschien ook te uitgebreid. Zet voor die sites óf de link naar de luchtfoto (wikimapia is mijn onbetwiste favoriet) boven aan; de rest er onder of maak 'm minder uitgebreid. Aan het overzicht / opmaak zijn m.i. nog meer verbeteringen te destilleren. Houd het i.i.g. zou simpel mogelijk. In een encyclopedie zoekt een gebruiker z.s.m. naar een antwoord, niet naar (te) veel / verschillende opties die hij niet kent. Je wilt de gebruiker niet een vertakt woud aan zoekmogelijkhedenbieden bieden, maar hem iets laten vinden. Ben benieuwd wat je er van vind / wat je er mee kan. Succes!--TjeerdN 25 feb 2007 09:32 (CET)

Gezien het aantal links dat we nu hebben (natuurlijk bedankt daarvoor:), is enige reorganisatie wel gewenst (denk ik), zoals mijn vorige post ook al aangaf. Erik, hoe makkelijk is het om de opmaak aan te passen; is het onderdeel van een script, of kunnen we bv een "voorstel opmaak html pagina " voorleggen zodat de huidige kan worden vervangen? Ik wil best wat energie stoppen in een (gelikte maar gebruiksvriendelijke) opmaak. Heb je overigens logo's of afbeeldingen weggelaten vanwege serverbelasting, of is dat geen probleem? Michiel1972 26 feb 2007 01:07 (CET)

Het zijn er inmiddels wel veel, maar dat komt mede doordat er destijds (terecht) gesteld is dat de gebruiker zelf een keuze moest kunnen maken, en directe links naar b.v. Google Maps en ViaMichelin niet meer mochten. Ik denk niet dat het er er te veel zijn, maar het overzicht is wel een beetje weg... De opmaak is gemakkelijk te veranderen, maar ik heb zelf geen idee hoe het moet worden, dus een duidelijk plan is welkom. Het is een script met HTML en VB-script (ASP). Logo's er bij is geen probleem. - Erik Baas 26 feb 2007 02:03 (CET)

Deze aanpak lijkt mij een goeie. Ik heb zelf - helaas - te weinig tijd om (anders dan mijn bovenstaande voorstellen) zoiets echt handen en voeten te geven, maar mocht over een aantal weken er geen opzet zijn, dan wil ik wel een voorstel doen, maar ik denk dat er genoeg wiki-kenners/experts zin die het sneller en beter kunnen. Zou ik een voorstel maken, dan is dat een lay-out voorstel, zónder wikipedia/taal-achtergrond. Op flora / gemeente pagina's staan in de rechter bovenhoek vaak aardige formatjes, ook simpel en klein. Zoiets simpels zou het kunnen zijn.... Ik hoop er snel meer van te horen. Sowieso een goed initiatief. Hoe mooier, hoe meer pagina's er gebruik van zullen en willen maken!--TjeerdN 27 feb 2007 20:03 (CET)

De mapserver (daar hebben we het toch over, niet het icoontje/coordinaten-linkje rechtsboven neem ik aan) is geen wiki, dus een expert daar in zijn maakt niet zoveel uit. Ik ben niet zo goed in het maken van websites, maar hier heb ik een voorbeeld geschetst hoe ik het me kan voorstellen dat de interface gebruiksvriendelijker zou kunnen zijn. Groet Michiel1972 27 feb 2007 21:25 (CET)

Leuk voorbeeld, maar gewoon regels, van links naar rechts en kleine icoontjes lijkt mij dan beter. Maar daarnaast; iconen zijn er alleen voor als je al eenmaal geweest bent op zo'n site, om snel door te klikken. Maar voor de eerste gebruiker zijn die iconen iets van tweede belang. Ik stel daarom voor: maak een (niet te hoge!) regel, met daarin een zeer korte, heldere, algemene beschrijving met waar je naar doorklikt. Dus bv: luchtfoto Tweede kolom: icoon. Derde kolom: uitleg Bron (bv: Wikimapia / googlemaps, nasa, enz) 4e kolom uitleg/beperkingen. Een tweede regel is dan bv luchtfoto incl wegen Tweede kolom: icoon. Derde kolom: uitleg Bron (bv: Wikimapia / googlemaps, nasa, enz) 4e kolom wegen alleen bij schaal>1:1000.000 etc. Met een mooi grijs randje er omheen, lekker strak, maar je een aantrekkelijke doorverwijspagina, en schrik je eerste gebruikers/dummies niet af. Resultaat: je site/sjabloon blijft gebruikt worden, en zal door anderen ook gebruikt willen worden. Zonder dergelijke aanpassingen zijn er denk ik velen die denken dat hun oorspornkelijke link ("luchtfoto van dit gebied x") nu niet alleen onaantrekkelijker is geworden, maar ook een extra klik met zich meebrengt. Die extra klik is alléén gerechtvaardigd, als je dan goedbeschreven en op een aantrekkelijke pagina ziet naar welke link je moet klikken bij een bepaalde interesse, en als je ziet welke mogelijkheden er nog meer zijn (meerwaarde!). Overigens de regels: zet die om volgorde van meeste gebruik, met een lichte voorkeur voor de (wiki/open) domeinen. Dus start bv met wikimapia-regels (luctfoto's met en zonder wegen), daarna de andere regels. En specials: rubriceer die onderaan. Tot zover mijn bescheiden ideeen om dit gebr.vriendelijker te maken. Ik wil wel sterren uitdelen voor degene(n) die hier voor zorgen! Wikipedia zou hier heel wat in hebben. Helaas kan ik het zelf niet...--TjeerdN 28 feb 2007 09:25 (CET)

Sjabloon Coördinaten

Hoi Erik,

Ik heb geprobeerd jouw sjabloon Coördinaten ook op de friese wikipedie te gebruiken. Nu lukt dat op zichzelf prima, alleen ik kan het niet op dezelfde positie krijgen als op :nl. Ik heb wel een stukje uit de monobook.css gekopiëerd maar dan werkt het noch niet. Zou je als je eens even tijd hebt willen kijken wat ik ben vergeten? Theun 1 mrt 2007 22:54 (CET)

Sorry, ik heb geen idee. - Erik Baas 3 mrt 2007 01:11 (CET)

Jammer, ik zal eens kijken of ik iemand anders kan vinden die mij hierbij kan helpen, als je een idee hebt wie ik daarvoor het beste voor kan benaderen graag. In ieder geval bedankt voor de moeite. Theun 3 mrt 2007 08:52 (CET)

Eigenlijk vind ik het helemaal niet erg dat het niet bovenaan in de hoek komt. In ieder geval stonden de coördinaten de eerste keer dat ik dat sjabloon gezien heb dwars door de fondswerving heen, en dat vond ik eigenlijk niet zo'n mooi gevolg. Maar misschien is dit intussen verbeterd. Mysha

maps.asp

Hallo, wat een handig script. Denk je dat het gemakkelijk te vertalen is zodat de Friese Wikipedia het ook kan gebruiken? Of is er misschien een argument taal om dat op te lossen? Mysha

Ja, nee, nee. - Erik Baas 8 mrt 2007 03:50 (CET)