Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2010-II
Irgendwas ist da falsch, alle Verwendungen liegen außerhalb. Bitte anschauen. lg --Herzi Pinki 01:15, 22. Mär. 2010 (CET)
- Gut ist es noch nicht, aber außerhalb sind sie nicht mehr. --Entlinkt 02:51, 22. Mär. 2010 (CET)
- danke, ging ja flott. lg --Herzi Pinki 19:53, 22. Mär. 2010 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: --тнояsтеn ⇔ 09:40, 21. Apr. 2010 (CEST)
Neuer Vektor-Skin
Im Mono-Skin haben die Koordianten einen exponierten Platz rechts oben. Bei Vektor werden sie an Ort und Stelle wie im Wikitext eingefügt (vgl. Porta Nigra). Hierfür sollte eine bessere gefunden werden. Gruß -- Biezl ✉ 16:22, 27. Mär. 2010 (CET)
- Seit kurzem erledigt -- Biezl ✉ 15:47, 10. Apr. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --тнояsтеn ⇔ 09:40, 21. Apr. 2010 (CEST)
Antrag KOORD-Zufügung: Emirates Road
Hi, etwas für Euch Spezialisten:
Könntet Ihr mal -> Diskussion:Emirates_Road sichten und die Koordinaten in den Artikel zufügen (ich brauche dafür bestimmt min. 4 Stunden, Ihr sicher nur 4 Minuten).
Danke vorab und viele Grüße,
-Wolli- --82.113.121.248 03:05, 21. Apr. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --тнояsтеn ⇔ 09:40, 21. Apr. 2010 (CEST)
Bevor ich was falsch mache: im Kopf d. neuen Artikels sind die Koordinaten hinterlegt. Die Höhe ist = Meeresspiegel. --Gerbil 23:01, 30. Apr. 2010 (CEST)
- done -- visi-on 23:46, 30. Apr. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: danke, Gerbil 11:24, 1. Mai 2010 (CEST)
Hier hat eine IP 2x Koordinaten eingetragen, offenbar auch im engl. Artikel, dort mit der Bitte, sie ordentlich zu maniküren. Beim ersten Mal hatte ich sie gelöscht, weil ich in den mir zugänglichen Publikationen keine Daten gefunden hatte, aber möglicherweise stimmen die Daten ja: Bitte mal nachschauen, ob sie mit den von mir in den Artikel eingetragenen km-Angaben zu mehreren Orten konform gehen. Gerbil 11:33, 8. Mai 2010 (CEST)
- Die Kilometer-Angaben kommen hin, in Google Earth werden dort bzw. in naher Umgebung Panoramio-Fotos von der Höhle eingebunden. Selbst wenn die Koordinaten nicht 100%ig stimmen, dann zumindest im Großen und Ganzen. NNW 20:26, 8. Mai 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: Gerbil 13:08, 10. Mai 2010 (CEST) - und vielen Dank. --Gerbil 13:08, 10. Mai 2010 (CEST)
Hier [1] ist die Lage dieser paläoanthropologischen Fundstelle eingezeichnet - kann jmd. die Lage in Geokoordinaten übersetzen für einen im Entstehen begriffenen Artikel? Die Daten könnten eingetragen werden unter Benutzer Diskussion:Bupleurum/Peştera Muierilor. --Gerbil 13:12, 10. Mai 2010 (CEST)
- Ich habe die Koordinaten mal als Kommentar eingetragen. Gruß-- Spuki Séance 13:24, 10. Mai 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: Gerbil 14:32, 10. Mai 2010 (CEST) - und besten Dank! --Gerbil 14:32, 10. Mai 2010 (CEST)
Link "LiveDemo"
Der Link "LiveDemo" (http://toolserver.org/%7Edschwen/wikiminiatlas) im Abschnitt WikiMiniAtlas scheint nicht mehr aktuell zu sein. Bei mir erscheint beim Aufrufen ein 404-Fehler. -- Jonas 23:14, 14. Mai 2010 (CEST)
- Hab den Link mal umgelegt, in der Anwendung muß man dann halt noch umschalten.--Kolossos 11:01, 16. Mai 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: --Kolossos 11:01, 16. Mai 2010 (CEST)
Koordinaten Südamerika, welches Datum?
Experten für geodätische Referenzsysteme bitte mal hier vorbeischauen: Wikipedia:Auskunft#Koordinatenproblem (GIS/Brasilien) --тнояsтеn ⇔ 14:38, 3. Mär. 2010 (CET)
- Ist mittlerweile archiviert: Wikipedia:Auskunft/Archiv/2010/Woche 09#Koordinatenproblem (GIS/Brasilien) --тнояsтеn ⇔ 10:40, 12. Mär. 2010 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: 188.174.1.72 12:28, 17. Mai 2010 (CEST)
Hey Leute schaut bitte mal bei dieser Löschdiskussion vorbei. Die ursprüngliche Diskussion findet Ihr hier. MfG Monsterxxl <°))))>< 14:03, 21. Mär. 2010 (CET)
- Archivierung dieses Abschnittes wurde gewünscht von: 188.174.1.72 12:29, 17. Mai 2010 (CEST)
Kanäle
Gibts irgendwo eine Regel zur Referenzierung? Anfang/Mitte/Ende. Nach Angucken zweier Beispiele vermute ich die Mitte.Das Archiv habe ich schon mal durchsucht-nach Kanal und Fluß-offensichtlich ist dort noch nichts festgelegt!? Würde ich aber mal tun mti Kanalanfang, weil:auffindbar, eindeutig beschrieben, genausso verläßlich wie Ende und nicht so ungenau wie Mitte. --CeGe Diskussion 09:14, 5. Mai 2010 (CEST)
- Die Mitte ist für die Artikelkoordinate aus meiner Sicht schonmal richtig. Mittels Parameter "name" lassen sich dann auch das Ende und der Anfang im Artikeltext unterbringen. --Kolossos 11:06, 5. Mai 2010 (CEST)
- Sagst du mir, warum die Mitte aus deiner Sicht richtig ist? Denn praktisch setzt dies die Arbeit voraus
- Berechnung Anfang bis Ende.
- Kanalverlauf ausmessen
- Georeferenzierung bestimmen
- Bei Anfang wäre das einfacher, da z.B. Zufahrten in der Seefahrt oft als Wegepunkte vorliegen. Und wenn verläßlich definiert ist, was die Koordinate bedeutet, finde ich alles Georeferenzierte gut. Aber vielleicht habe ich etwas übersehen oder es gibt da logischere Ansichten. Gruß --CeGe Diskussion 11:28, 5. Mai 2010 (CEST)
- Sagst du mir, warum die Mitte aus deiner Sicht richtig ist? Denn praktisch setzt dies die Arbeit voraus
- Mit Mitte meine ich etwas per Augenmaß hingeworfenes. Es muss nicht exakt sein. Der Grund für die Mitte ist der, dass das bei der Beschriftung von Karten auch eher so gemacht wird. Der Kanalname kommt in die Gewässermitte.
- Ich bin kein Kanalexperte, aber ich hatte jetzt sowas wie den Mittellandkanal im Sinn, wo ich mich schwer tue zu definieren was Anfang und was Ende ist. Wenn jetzt nur die eine Seite bezeichnet wird, fragt sich der Leser, "Warum nicht die andere Seite?". Der dritte Grund für die Mitte ist, dass es an den Enden immer ein anderes Objekte gibt somit also Verwechslungsgefahr besteht. Der vierte Grund ist der, das mit der Koordinate immer Karten aufgerufen werden, wo die Koordinate sich in Bildschirmmitte befinden. Wenn man nun die Mitte angibt, steigt die Wahrscheinlichkeit, dass der ganze Kanal auf dem Bildschirm dargestellt wird. Ich denke das reicht an Gründen.
- Wir können mit unserer Georeferenzierung nur schlecht längliche Objekte referenzieren, wir sind eher ein hilfreicher Fingerzeig auf eine Karte mit den Worten "Da ist das.". --Kolossos 15:28, 5. Mai 2010 (CEST)
Also-Kanäle beginnen bei Km 0 ;-) Nein, im Ernst, deine Argumentation ist schlüssig, nachvollziehbar und kann für nachfolgende Generationen archiviert werden. Dann machen wir das mal so --CeGe Diskussion 09:52, 6. Mai 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 188.174.1.72 12:31, 17. Mai 2010 (CEST)
Im Kopf habe ich die Koordinaten versteckt, bitte korrekt codieren. --Gerbil 15:19, 6. Jun. 2010 (CEST)
- Done--Spischot 17:50, 6. Jun. 2010 (CEST)
- Danke! --Gerbil 18:08, 6. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 11:12, 21. Jun. 2010 (CEST)
Shapefiles darstellen
Wer kennt sich aus mit Programmen zur Dastellung von Shapefiles? Bitte bei Wikipedia:Auskunft#Shapefiles darstellen vorbeischauen. Danke --188.174.6.169 12:03, 16. Jun. 2010 (CEST)
- Jetzt im Archiv: Wikipedia:Auskunft/Archiv/2010/Woche 24#Shapefiles darstellen --тнояsтеn ⇔ 11:12, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: тнояsтеn ⇔ 11:12, 21. Jun. 2010 (CEST)
Koordinaten erscheinen nicht upgedatet....?
In dem Artikel Westheim (Knetzgau) hab ich die Koordinaten verändert, so das jetzt das Kaff in Google auch angezeigt wird. Aber im Artikel selbst, rechts oben wo die Koordinaten stehen ist immer noch der alte Wert zu sehen. Ich verstehe nicht woran das liegt. Kann das jemand erklären bitte und am besten auch gleich Abhilfe schaffen? Gruß --Eρβε 15:37, 28. Mai 2010 (CEST)
- Liegt einfach daran, dass auf Bogenminuten gerundet wird in der Anzeige. Klick drauf und du wirst sehen, dass deine exakten Koordinaten mit Sekundenangabe "hinterlegt" sind. Passt also alles so. --тнояsтеn ⇔ 16:39, 28. Mai 2010 (CEST)
- Und damit die Bogensekunden auch im Artikel angezeigt werden, kann man den Parameter "dim" mit einem sinnvollen Wert belegen. Damit wird dann auch gleich der Zoomfaktor bei OpenStreetMap oder Google gesteuert. Die Angabe von Sekundenbruchteilen bringt bei solchen Objekten übrigens nix: bitte bedenken, daß eine Bogensekunde in Deutschland etwa 30 m in Nord-Süd-Richtung und etwa 20 m in Ost-West-Richtung ist – noch genauer kann man ein Ortszentrum ganz sicher nicht georeferenzieren. --Telford 18:12, 28. Mai 2010 (CEST)
- Alles klar. Danke für die Aufklärung. --Eρβε 18:02, 30. Mai 2010 (CEST)
- Und damit die Bogensekunden auch im Artikel angezeigt werden, kann man den Parameter "dim" mit einem sinnvollen Wert belegen. Damit wird dann auch gleich der Zoomfaktor bei OpenStreetMap oder Google gesteuert. Die Angabe von Sekundenbruchteilen bringt bei solchen Objekten übrigens nix: bitte bedenken, daß eine Bogensekunde in Deutschland etwa 30 m in Nord-Süd-Richtung und etwa 20 m in Ost-West-Richtung ist – noch genauer kann man ein Ortszentrum ganz sicher nicht georeferenzieren. --Telford 18:12, 28. Mai 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 93.104.172.76 15:37, 28. Jun. 2010 (CEST)
Geogr. Lage gewünscht
Habe mal spasseshalber ein paar abgearbeitet. Dabei fiel mir auf, das in den Unterkategorien Einträge auftauchen, die durchaus mit Koordinaten versehen sind. Entgeht mir da was, oder müssen die manuell aus der Kat. gelöscht werden? Gruss, --G-41614 13:49, 21. Jun. 2010 (CEST) Bspw. hier [2].
- Du meinst wohl die Links in Kategorie:Geographische Lage gewünscht (DE-BE). Diese sind veraltet (die Vorlage für Koordinaten wurde erneuert)... ich hab es mal korrigiert. Danke für den Hinweis. --тнояsтеn ⇔ 14:05, 21. Jun. 2010 (CEST)
- Danke ... äh, findet sich dann ggf. irgendwo eine aktuelle Liste? --G-41614 14:23, 21. Jun. 2010 (CEST)
- Die Artikel mit Lagewunsch sind in der Kategorie:Geographische Lage gewünscht (DE-BE) gelistet (aktuell nur ein Artikel). Artikel ohne Koordinate in entsprechenden Kategorien findest du dort über die Links auf Catscan (die Zahlen in eckigen Klammern). Beispielsweise Bauwerke in Berlin: [3]. --тнояsтеn ⇔ 14:36, 21. Jun. 2010 (CEST)
- Ah, so geht das mit dem CatScan - danke für die Hilfe. --G-41614 15:02, 21. Jun. 2010 (CEST)
- Die Artikel mit Lagewunsch sind in der Kategorie:Geographische Lage gewünscht (DE-BE) gelistet (aktuell nur ein Artikel). Artikel ohne Koordinate in entsprechenden Kategorien findest du dort über die Links auf Catscan (die Zahlen in eckigen Klammern). Beispielsweise Bauwerke in Berlin: [3]. --тнояsтеn ⇔ 14:36, 21. Jun. 2010 (CEST)
- Danke ... äh, findet sich dann ggf. irgendwo eine aktuelle Liste? --G-41614 14:23, 21. Jun. 2010 (CEST)
- Archivierung dieses Abschnittes wurde gewünscht von: 93.104.172.76 15:38, 28. Jun. 2010 (CEST)
Komplette Überarbeitung der Koordinaten-Extraktion
Ich habe letzten Tage mal genutzt, um mit den Wikipedia-Koordinaten von MySQL auf PostGIS umzuziehen. Dadurch ändern sich folgende Dinge:
- Die Performance für den GoogleEarth/GoogleMaps-Layer sollte deutlich besser sein. Es wird jetzt ein spatial-Index genutzt und vor allem gibt es 3 zusätzliche Tabellen mit stufenweise auf wesentliche Artikel reduzierten Datensätzen, dadurch wird die aufwändige Sortierung/Filterung reduziert.
- Ich nutze alle Extrakte von User:Dispenser, welcher 42 Sprachversionen der Wikipedia extraiert, über die Interwikilinks werden alle 273 Sprachen erschlossen. Somit kommt man auf ca. 1.3 Mio unabhängige Datensätze.
- Man kann bei der marks.php auf die Angabe der Sprache ganz verzichten, dann wird die Sprachversion für jeden Artikel angezeigt, welche es geschafft hat zu einem Objekt den längsten Artikel zu schreiben. Ob man den Artikel dann lesen kann, sei dahingestellt, interessant ist es allemal.
- Der Google-Maps-Layer läuft jetzt deutlich stabiler, deshalb habe ich ihn mal wieder in den Geohack aufgenomen.
Durch PostGIS entstehen neue Möglichkeiten der Transformation und Abfrage, bspw. "gib mir alle Koordinaten in eine Bundesland...". Einbindungen Qgis oder andere Programme, wie in nebenstehendem Bild sind ebenso möglich. Auf dem Toolserver (Server:Ptolemy) steht auch eine Datenbank auch mit allen redundanten Koordinaten zur Verfügung (ca. 2.6 Mio. Datensätze), man könnte diese mal nutzen um bei durch Interwikilinks verbundene Artikel die Koordinaten abzugleichen.
Zu tuen gäbe es noch die Doku der /Wikipedia-World und derren Dumps zu aktualisieren und die Reihe an anderen Tools auf die neue Datenbank umzustellen, diese ist aber mit etwas Aufwand verbunden. Ich bin erstmal auf eure Testberichte gespannt, bevor ich die Mitteilung einem größeren Kreis bekannt mache. --Kolossos 21:55, 15. Apr. 2010 (CEST)
- Umzug auf PostGIS... das sind ja gute Neuigkeiten. Ich hatte letztes WE auch mal etwas Zeit mich mit OpenLayers zwecks POI-Layer etc zu beschäftigen. Auf Basis von PostGIS funktioniert das eigentlich recht flott für kleinere Ausschnitte. Zoomt man sich weiter raus, muss man schauen, wie man die Datenmenge Schritt für Schritt reduzieren kann. So wie ich das verstehe, hast Du da bereits eine Partitionierung in 3 Tabellen gemacht? Das ist gut.
- Der eigentliche Service, der zu einer BBOX die Daten (als GeoJSON-Format ..relativ kompakt) liefert, ist vrmtl. nicht sonderlich kompliziert. Könntest Du sicher auch relativ problemlos in das bestehende marks.php mit einbauen - bzw nach dem selben Muster ein zweites Skript machen. Interessanter ist der Client-Teil, also die JavaScripts für OpenLayers - da hab ich aber jetzt schon ganz brauchbare erste Egebnisse. Es gibt noch ein paar Details wie Tooltips, Popupfenster. Den Inhalt des Popups versuche ich noch über einen separaten Service On-Demand (beim Anklicken) nachzuladen - sonst wird das zuviel Overhead, wenn man für alle Punkte im Ausschnitt auch noch gleich die Beschreibung mit überträgt. Zunächst ist es vlt aber auch erstmal OK, wenn man nur den Link zum Artikel im Popup anzeigt.
- Wenn ich mit dem JS-Client über den Berg bin, hast Du eine Idee, wie wir da weiter machen können? Zunächst wäre es vlt gut, wenn der Server-seitige Teil steht. Ich könnte zwecks Umsetzung in PHP Dir mein Java-Schnippsel samt Beschreibung der Eingangsparameter und des GeoJSON-Formats zusenden. Damit könnte man schonmal erste Performance-Tests machen. Als nächstes stünde dann die Einbindung in den Geohack an. Vlt kannst Du für mich auch einen Toolserver-Zugang legen/legen lassen, dass ich da bei Bedarf mal selbst Hand anlegen kann. Gruß, --alexrk 12:16, 17. Apr. 2010 (CEST)
- Hallo, JSON stelle ich für die MySQL Daten schonmal bereit, weil sich das mal jemand gewünscht hatten und das dafür nötige Skript schrieb.
- Quelltext unter:http://toolserver.org/~kolossos/geoworld/marks-json-source.php
- Beispielausgabe:http://toolserver.org/~kolossos/geoworld/marks-json.php?lang=de&bbox=10,50,10.1,50.1
- Trifft das schon in etwa deine Vorstellungen? Ansonsten schreib mir einfach, was rein und was raus gehen soll.
- Eine Datenbank Anfrage sollte in Postgres dann ca. 0.02 Sekunden auf dem Server dauern, geliefert werden immer maximal 80 Elemente.
- Den Toolserver-Zugang mußt du schon selbst gemäß https://wiki.toolserver.org/view/Account_approval_process beantragen, ich kann Ihn dann nur beschleunigt durchwinken. Das für den Accountantrag nötige Jira läuft allerdings erst nächste Woche wieder (Der isländische Vulkan ist daran unschuldig). --Kolossos 01:02, 18. Apr. 2010 (CEST)
- Achso, schau mal bitte ob du statt einer Icon Darstellung auch einen Weg siehst die Artikelnamen auf die Karte zu bringen. Statt der kleinen Karte im Geohack sehe ich den ersten Einsatz eher im OSM-Gadget von Magnus Manske, man braucht einfach etwas Platz.--Kolossos 13:12, 18. Apr. 2010 (CEST)
Vielleicht von Interesse ...
Um mal ein wenig Hobby (=Wikipedia) und Beruf (=Wissenschaft) miteinander zu verbinden, hab ich unter www.morewiki.de eine Webseite geschaffen, die ein Empfehlungssystem für Wikipedia-Artikel in Abhängigkeit vom Standort des Benutzers enthält. In Abhängigkeit von angeklickten und "abgewählten" Artikeln werden die angezeigten Artikel im Laufe der Zeit dann an die Interessen des Nutzers angepasst. Vor allem sollte sowas für iPhone-Nutzer oder Nutzer sonstiger Mobilgeräte interessant sein, es funktioniert zwar auch bei fester Position, aber dann wird es recht schnell langweilig. ;)
Da die Grundlage u.a. die hier gesammelten Daten sind, denke ich mal, dass Ihr Euch für diese Art der Weiternutzung interessieren könntet. Wenn ich's schaffe, lege ich hier in meinem BNR auch nochmal eine Seite zur Erläuterung des ganzen an, bis dahin sei erstmal auf die "Information" auf der Webseite selbst verwiesen. Vieles ist auch noch "Work in Progress", u.a. wird momentan noch nicht ausgewertet, ob der Browser die verwendete Geolocation-API überhaupt unterstützt. Gucken dürft ihr natürlich trotzdem schon - würde mich über Feedback freuen. :-) --Carstor|?|ʘ| 14:24, 19. Apr. 2010 (CEST)
- Spannender Ansatz, schöne Idee. Was ich aber auch nach mehrmaligen Lesen nicht begreife: Die Anwendung speichert angeblich keine anwenderbezogenen Informationen wie IP oder Benutzername, behauptet aber dennoch über längere Zeit ein auf mich personalisiertes Angebot vorzuschlagen. Das erscheint mir wiedersprüchlich. --Spischot 14:44, 19. Apr. 2010 (CEST)
- IP-Adressen werden nicht gespeichert, die Zuordnung zurückliegender Daten erfolgt über Cookies, später dann über das Login. Sobald diese Funktionalität mit implementiert ist, wird natürlich auch der Benutzername mit einer "Bewertung" verbunden. Das mit den Benutzernamen bezieht sich auf die Weitergabe an Dritte. D.h. wenn beispielsweise mal eine studentische Arbeit zur Weiterentwicklung der Algorithmen mit den Daten laufen sollte, dann wird es da höchstens noch IDs in den Datensätzen geben, die aber nicht mehr auf konkrete Benutzernamen zurückzuführen sind. Gruss, --Carstor|?|ʘ| 14:53, 19. Apr. 2010 (CEST)
Hinweis
Hallo, liest dort überhaupt noch jemand mit? Die meisten Nutzer weden wohl über die Links von der Vorlagen(diskussions)seite dorthin geleitet. Sollte man diese vielleicht umbiegen, evtl. sogar einen Redirect erstellen? -- ✓ Bergi 20:27, 2. Mai 2010 (CEST)
♁
Ich schreibe mal hier - vielleicht bin ich hier halbwegs richtig. ;)
Wieso kommt ♁ statt dem Globus-Bild bei Koordinatenangaben im Text bei aktiviertem Kartenhelferlein? Bäh! ♁ verbinde ich eindeutig mit Kirche. So ist es ja auf klassischen Papierkarten verwendet. Gut, das Globus-Bild hätte auch etwas unauffälliger sein können - aber dieses Symbol wirkt komisch. Viele Grüße --Saibo (Δ) 02:23, 3. Mai 2010 (CEST)
- Weil das das Schriftzeichen für die Erde ist und es kein Bild sein soll. -- visi-on 02:32, 3. Mai 2010 (CEST)
- Schon klar - gibt es nicht ein anderes Zeichen, was nicht ein homonymes Zeichen ist und nicht gleichzeitig als Kartenzeichen Kirche bezeichnet (steht ja auch so im Artikel ♁)? Nur vom Aussehen her: wie wäre es mit ◯ oder ○ oder gar ◎? --Saibo (Δ) 02:59, 3. Mai 2010 (CEST)
- Und nun ist wieder da. --Saibo (Δ) 15:48, 3. Mai 2010 (CEST)
- Bei mir nicht... bzw. nur in der Kopfzeile, aber nicht im Fließtext. --тнояsтеn ⇔ 17:38, 3. Mai 2010 (CEST)
- Komisch. Bei mir kommt das Weltkugelbild von ihm auch bei Textkoordinaten: Position Punkt 0 --Saibo (Δ) 18:26, 3. Mai 2010 (CEST)
- Hmm, bei mir steht da ♁ Position Punkt 0, nur eben als Link. --тнояsтеn ⇔ 22:54, 3. Mai 2010 (CEST)
- Komisch. Bei mir kommt das Weltkugelbild von ihm auch bei Textkoordinaten: Position Punkt 0 --Saibo (Δ) 18:26, 3. Mai 2010 (CEST)
- Bei mir nicht... bzw. nur in der Kopfzeile, aber nicht im Fließtext. --тнояsтеn ⇔ 17:38, 3. Mai 2010 (CEST)
Prüfung auf doppelte Artikelkoordinaten?
Hallo, gibt es irgendeine Auswertung auf Artikel mit mehr als einer Artikelkoordinate? Vielfach wird beim Einfügen einer Infobox vergessen, die übernommenen Koordinaten aus dem Artikel zu löschen. lg --Herzi Pinki 15:00, 9. Mai 2010 (CEST)
- Das ganze ist schwieriger als gedacht. Habe jetzt zwei Stunden in der Datenbank gesucht, weil ich dachte die Info müßte sich ganz einfach rausholen lassen. Die Gründe sind Erstens: ist es ja durchaus üblich mehrfach auf den Geohack zu verlinken (im Fließtext und in der Ecke rechts oben), diese Verlinkungen dienen der Auswertung von Dispenser, können aber nicht genutzt werden. Zweitens, hatte ich Hoffnung, dass sich in der Datenbanktabelle "templatelinks" diese Dopplungen aufdecken ließen, aber da wird pro Artikel immer nur ein Vorlagenaufruf pro Vorlage gespeichert. Es wird also wohl erstmal so gehen müssen, es sei denn jemand hat eine gute Idee. --Kolossos 23:05, 9. Mai 2010 (CEST)
- trotzdem danke für deine Versuche. --Herzi Pinki 23:08, 9. Mai 2010 (CEST)
Die Vorlage:Infobox Stadtteil von Düsseldorf hat anstelle einzelner Parameter für Breiten- und Längengrad einen Parameter {{{Geographische Lage}}}, der eine vollständige Einbindung der Vorlage:Coordinate enthält. Einwohnerzahl und Höhe werden auf diese Weise nicht an die Koordinatenvorlage durchgereicht. Handlungsbedarf? --Entlinkt 03:05, 20. Apr. 2010 (CEST)
- Ja schon aber nicht dringlich ... -- visi-on 13:14, 20. Apr. 2010 (CEST)
- Ebenso: Parameter {{{GeoRef}}} in Vorlage:Infobox Golfplatz. Gibt es eine Möglichkeit, systematisch nach solchen Kandidaten zu suchen? --Entlinkt 04:53, 24. Apr. 2010 (CEST)
- Vorlage:Infobox Golfplatz kann man mi Sicherheit nach kurzem Gespräch auf der Disk per Hand machen. Sind ja nicht mal 20 Seiten. MfG Monsterxxl <>< 19:28, 25. Apr. 2010 (CEST)
- Düsseldorf erledigt, bis auf Höhenbereiche in Gerresheim, Hubbelrath und Unterbach. Die Golfplätze sind nicht so einfach, weil teils mehrere Koordinaten eingegeben wurden. --Entlinkt 23:30, 11. Mai 2010 (CEST)
- Vorlage:Infobox Golfplatz kann man mi Sicherheit nach kurzem Gespräch auf der Disk per Hand machen. Sind ja nicht mal 20 Seiten. MfG Monsterxxl <>< 19:28, 25. Apr. 2010 (CEST)
- Ebenso: Parameter {{{GeoRef}}} in Vorlage:Infobox Golfplatz. Gibt es eine Möglichkeit, systematisch nach solchen Kandidaten zu suchen? --Entlinkt 04:53, 24. Apr. 2010 (CEST)
GeoTemplate
„Anwendungen für diese Region“ (Österreich) funktionieren nicht. Gruß, -- Hans Koberger 20:14, 15. Mai 2010 (CEST)
- Bei Wien klappt es bei mir [4], direkt unter den globalen Anwendungen kommen die 2 Regionalen. Wo genau trat dein Problem auf? --Kolossos 21:48, 15. Mai 2010 (CEST)
- Bei AMAP öffnet sich nur eine Übersichtskarte 1:3 Millionen, bei Geoland öffnet sich nur eine Übersichtskarte 1:5 Millionen. Einen Bezug zur vorgegebene Koordinate finde ich nicht. -- Hans Koberger 23:34, 15. Mai 2010 (CEST)
- Problembeschreibung: Diese Dienste erlauben entweder keine Direktverlinkung über die Koordinate oder nur über ein nicht unterstütztes System (der Geohack unterstützt nur WGS84, UTM und ein paar länderspezifische, aber keines für Österreich) oder die Direktverlinkung ist nicht implementiert. Deshalb steht „FIX ME“ dahinter. Lösungsvorschlag: Kartendienste mit und ohne Direktverlinkung deutlicher unterscheiden. --Entlinkt 23:44, 15. Mai 2010 (CEST)
- Lösungsvorschlag 2: Kartendienste ohne Direktverlinkung entfernen. -- Hans Koberger 13:22, 17. Mai 2010 (CEST)
- Nee, das ist gar nicht gut. Es gibt da etliche sehr gute bis exzellente, auch wenn man den Ort erst noch von Hand suchen muss. --188.174.1.72 13:27, 17. Mai 2010 (CEST)
- Das Problem ist, dass von 1000 Lesern vielleicht einer, etwas mit den „exotischen“ Diensten anfangen kann. Die anderen 999 werden durch die lange Dienste-Liste, und die Dienste selbst, überfordert. -- Hans Koberger 14:09, 17. Mai 2010 (CEST)
- (ohne mir die Links jetzt angesehen zu haben) Wenn diese Dienste tatsächlich so „exotisch“ und vielleicht auch kompliziert zu handhaben sind, plädiere ich da ebenfalls für eine Löschung, da diese Dienste dann kein Gewinn sind. Gruß-- Spuki Séance 15:37, 17. Mai 2010 (CEST)
- Für die "uninteressierten" Nutzer gibt es an vorderster Front OpenStreetMap, Google Maps, Bing Maps, Google Earth. Mehr braucht man im Normalfall nicht. Für "Spezialanwendungen" sind dann die ganzen anderen Dienste da. Beispiel: der DeutschlandViewer bietet keine Direktverlinkung, ist etwas umständlich zu bedienen, aber die angebotenen topografischen Karten der Landesvermessungsämter für Deutschland sind exzellent! --188.174.1.72 16:44, 17. Mai 2010 (CEST)
- (ohne mir die Links jetzt angesehen zu haben) Wenn diese Dienste tatsächlich so „exotisch“ und vielleicht auch kompliziert zu handhaben sind, plädiere ich da ebenfalls für eine Löschung, da diese Dienste dann kein Gewinn sind. Gruß-- Spuki Séance 15:37, 17. Mai 2010 (CEST)
- Das Problem ist, dass von 1000 Lesern vielleicht einer, etwas mit den „exotischen“ Diensten anfangen kann. Die anderen 999 werden durch die lange Dienste-Liste, und die Dienste selbst, überfordert. -- Hans Koberger 14:09, 17. Mai 2010 (CEST)
- Nee, das ist gar nicht gut. Es gibt da etliche sehr gute bis exzellente, auch wenn man den Ort erst noch von Hand suchen muss. --188.174.1.72 13:27, 17. Mai 2010 (CEST)
- Lösungsvorschlag 2: Kartendienste ohne Direktverlinkung entfernen. -- Hans Koberger 13:22, 17. Mai 2010 (CEST)
- Problembeschreibung: Diese Dienste erlauben entweder keine Direktverlinkung über die Koordinate oder nur über ein nicht unterstütztes System (der Geohack unterstützt nur WGS84, UTM und ein paar länderspezifische, aber keines für Österreich) oder die Direktverlinkung ist nicht implementiert. Deshalb steht „FIX ME“ dahinter. Lösungsvorschlag: Kartendienste mit und ohne Direktverlinkung deutlicher unterscheiden. --Entlinkt 23:44, 15. Mai 2010 (CEST)
- Bei AMAP öffnet sich nur eine Übersichtskarte 1:3 Millionen, bei Geoland öffnet sich nur eine Übersichtskarte 1:5 Millionen. Einen Bezug zur vorgegebene Koordinate finde ich nicht. -- Hans Koberger 23:34, 15. Mai 2010 (CEST)
Bing Maps
Bei der Funktion „Zeige alle Koordinaten“ zeigt Bing Maps nur 200 an. Könnt ihr das ändern/beeinflussen? -- Hans Koberger 14:16, 17. Mai 2010 (CEST)
- Nöö, die Daten gehen (wie bei GoogleMaps auch) den Umweg über Mircosoft, was die dort mit den Daten veranstalten können wir nicht beeinflußen. Irgendwo müssen die Leute bei Bing ein Limit ziehen, um weder ihre eigenen Server zu gefährden noch ältere Clients zum Einschlafen zu bringen. Lösungsmöglichkeit wäre nur eine eigene Lösung auf OpenLayers/OSM Basis. --Kolossos 20:35, 17. Mai 2010 (CEST)
Sinn von Geokoordinaten in Listen
(verschoben von /Wikipedia-World)
Mir passiert es nun häufiger, dass man in Karten-Anwendungen sinnloser Weise Einträge hat Liste von .. und gleichzeitig dort aber auch der tatsächliche Artikel angezeigt wird. Wären Geokoordinaten in Listen nicht eigentlich (nur) dann sinnvoll, wenn es keinen georeferenzierten Artikel zum Objekt gibt?--Olaf2 22:20, 19. Mai 2010 (CEST)
- Danke, dass du es ansprichst. Wenn wir nicht einen zusätzlichen Parameter wie "extraction=no" für solche Fälle einführen, habe ich keine Idee die es mir ermöglichen würde, solche Fälle automatisiert aus dem Datenbestand rauszufiltern.
- Ein anderer Fall ist, wenn wie bei U-20-Fußball-Weltmeisterschaft_der_Frauen_2010 über eine Positionskarte mehrere Links auf den Geohack generiert werden, landen solche Artikel auf der Karte. Was ich auch für grenzwertig halte. Hat jemand eine Idee bezüglich dieser doppelten Koordinaten? --Kolossos 23:21, 19. Mai 2010 (CEST)
- Aehaem, im WikiMiniAtlas filtere ich solche Koordinaten schon laengst raus. Den "extraction=no" Parameter halte ich daher fuer nicht notwendig :-). --Dschwen 00:59, 20. Mai 2010 (CEST)
- Beispielsweise, halte ich die Koordinaten von Liste_der_Sakralbauten_in_Dresden für wertvoll und möchte diese nur ungern rausfiltern nur weil einige Koordinaten doppelt sind. Ich gebe den Koordinaten aus solchen Listen allerding immer eine recht geringe Wertung, indem ich die Artikellänge durch die Anzahl der Koordinaten im Artikel teile. --Kolossos 07:16, 20. Mai 2010 (CEST)
ISO 3166-2:GM 5 Jahre alter Bug?
Die Ganze Referenzierung wird zum Teil durch die ISO 3166-2-Codes getragen, ich glaube wir haben in der Tabelle ISO 3166-2:GM einen Bug. Und dies schon seit der 1. Version vom 5. Okt. 2005. Dort ist für die Central River Division GM-C eingetragen, in der englischen Wiki (und andere) steht aber GM-M (für den alten Namen MacCarthy Island). Auch andere Quellen geben Indiz für "M". An ursprüngliche Quelle komme ich nicht heran, weil die kostenpflichtig ist. Wie siehts aus? Ich habe mich fleißig an dem "C" gehalten. --Atamari 07:05, 27. Mai 2010 (CEST)
- Da hast du wohl leider recht. Ich habe die ISO 3166-2 Ausgabe April 2001 vorliegen. Dort steht drinne: MacCarthy Island - GM-M. Hier und auch in den ausgegebenen Newslettern ist keine Änderung zu finden. MfG Monsterxxl <>< 08:53, 27. Mai 2010 (CEST)
- Eigentlichg habe ich (weitere) Hinweise gesucht, dass sie ihr vor rund zwei Jahren System geändert haben. Aus 5 Divisionen nun 5 Regionen + 2 "Municipalities". Mit http://www.statoids.com/ hatte ich auch schon Kontakt aufgenommen, er hatte bislang auch nur Indizien gefunden. --Atamari 13:46, 27. Mai 2010 (CEST)
- Naja, die ISO hängt den aktuellen Gegebenheiten ja bekanntlich immer ein bissel hinterher. Soweit ich weiß werden die Daten erst veröffentlicht, wenn staatliche Änderungen international anerkannt wurden. Von daher kann es durchaus noch ein bissel dauern, bis da was offizielles kommt. MfG Monsterxxl <>< 14:53, 27. Mai 2010 (CEST)
- Naja... so habe ich bislang auch gewartet um die Artikel zu aktualisieren (Division -> Region). Aber den Buchstaben sollten wir schon ändern? Dies geht wohl nur mit einer Gemeinschaftsaktion. Erster Entwurf: ändern ISO 3166-2:GM, verschieben/änderen Vorlage:Info ISO-3166-2:GM-C, per Bot alle Einbindungen von GM-C auf GM-M ändern. --Atamari 16:30, 27. Mai 2010 (CEST)
- Wieso ist dann in der Koordinate von en:Central River Division GM-C drin? --тнояsтеn ⇔ 17:08, 27. Mai 2010 (CEST)
- Vielleicht haben die aus deutschen Wiki kopiert? ;-) Der gambische Themenbreich ist in der DE-Wiki deutlich umfangreicher als in der englischen Wiki. --Atamari 17:13, 27. Mai 2010 (CEST)
- Atamari, ja da stimme ich dir zu. Die Originaldaten sagen es eindeutig, es gilt GM-M! Wir wollen ja hier auch die Gegenwart abbilden und keine Weissagungen über die ISO. Bei Änderungen sollten wir uns erst mal an die Gegebenheiten halten und etwas ändern, wenn es offiziell ist. MfG Monsterxxl <>< 18:32, 29. Mai 2010 (CEST)
- Vielleicht haben die aus deutschen Wiki kopiert? ;-) Der gambische Themenbreich ist in der DE-Wiki deutlich umfangreicher als in der englischen Wiki. --Atamari 17:13, 27. Mai 2010 (CEST)
- Wieso ist dann in der Koordinate von en:Central River Division GM-C drin? --тнояsтеn ⇔ 17:08, 27. Mai 2010 (CEST)
- Also: ändern bzw. korrigieren? Wie; wer betreibt einen Bot. Lohnt sich ein Bot? --Atamari 20:07, 29. Mai 2010 (CEST)
- Nun alles per Hand geändert. --Atamari 22:49, 29. Mai 2010 (CEST)
Umbenennung Kategorie:Vorlage mit Koordinate nach Kategorie:Vorlage:mit Koordinate
Zur Anpassung der Systematik der in Kategorie:Vorlage:nach Eigenschaft enthaltenden Unterkategorien, sollte man ihr ein Doppelpunkt spendieren. Findet jemand, das etwas dagegen spricht? Vielen Dank. Der Umherirrende 19:39, 28. Mai 2010 (CEST)
Parameter "dim" in Vorlage:Coordinate
Beim Georeferenzieren der Obelisken in Rom ist mir aufgefallen, daß bei Aufruf von Google Earth über den Geohack der Parameter "dim" nicht ausgewertet wird. In der englischen Wikipedia funktioniert das wie gewünscht (auch wenn "dim" dort etwas anders definiert ist als bei uns). --Telford 12:54, 30. Mai 2010 (CEST)
Probleme bei Mobil-Version mit Koordinaten
siehe Wikipedia:Fragen_zur_Wikipedia#Probleme_bei_Mobil-Version_mit_Koordinaten:
Die Koordinaten bei der Mobil-Version für Handys werden unterhalb eines Bildes in Klarschrift angezeigt, einfach eine lange Nummer, mit der man nichts anfangen kann. Ein Beispiel. Ist dieses Problem schon bekannt? Habe es getestet mit FF, IE und Safari. --KurtR 12:28, 5. Jun. 2010 (CEST) Herzi Pinki 13:04, 5. Jun. 2010 (CEST)
Serverauslastung/Timeouts bei mehrfacher Coordinate-Vorlageverwendung
Bei Artikeln (Listen) welche mehrfach (>50) die Coordinate-Vorlage einbinden, wie Liste der Schaltanlagen im Höchstspannungsnetz in Deutschland, kommt es wiederholt zu serverseitigen Problemen: Je nach Cache/Proxy-Zustand geht das normale Laden gleich oder führt nach rund 1 Minute zu Fehlern (Timeouts) bis hin zu SQL-Abfragefehler (siehe hier). Dürfte von der Serverauslastung, Tageszeit und Pegelstand der Donau abhängen. Jedenfalls treten ähnliche Probleme beim Sichten (Versionsvergleiche) und auch beim Editieren wiederholt und über längere Zeiträume auf.
- Gibt es Empfehlungen/Vorschläge/Regeln wie die Coordindate-Vorlage in Artikeln bei mehrfacher (bis hunderfachter) Einbindung handzuhaben ist ohne dabei Serverprobleme/Timeouts/SQL-Fehler oder andere Fehler und lange Wartezeiten zu ergeben?
- Gibt es vielleicht eine "abgespeckte" Version dieser Vorlage mit geringerer Serverlast für solche Listen? (hab da leider nichts gefunden)
- Wenn die hundertfache Vorlagenverwendung pro Artikel, aus technischen Gründen dzt. nicht sinnvoll ist, ist es dann angebracht diese Vorlagen nicht zu verwenden? (ggf bis die Server umgestellt sind und das technisch funktioniert).
- Wäre da eine vorläufige "Dummy"-Vorlage sinnvoll welche zunächst mal nur den Text 1:1 der Koordindaten ausgibt/durchreicht und später mal erweitert werden kann? Damit müssten die Artikeln nicht umeditiert werden.
--wdwd 10:23, 12. Jun. 2010 (CEST)
- Hallo Wdwd, da bist Du nicht allein. Das wurde schon öfters angesprochen. Was die Performance der Vorlagenumsetzung angeht, kann ich nicht viel sagen. Mich würde das aber auch mal interessieren, ob es nur an der Schwergewichtigkeit der Koordinaten-Vorlage liegt oder man mit einer Vorlage CoordinateSimple eine großartige Verbesserung erreichen könnte (rein theoretisch).
- OK, nun ein paar grundsätzliche Gedanken: IMHO muss man bei solchen Listen überlegen, ob das überhaupt noch in Wikipedia sinnvoll umzusetzen ist oder ob hier nicht OpenStreetMap als "Geodaten-Wiki" der geeignetere Platz ist. Das hat nichts mit Relevanz o.ä. zu tun sondern ist lediglich eine Frage der technischen Möglichkeiten. Wenn ich lediglich eine Liste von zig Schaltanlagen mit einheitlichen Attributen und Geokoordinaten machen möchte, dann sind das für mich nur noch reine Geodaten, die besser in OSM aufgehoben sind. Wir können ja durchaus weiterhin hier in WP eine Liste von Umspannwerken machen; nur für die Geodaten fände ich es dann sinnvoller, einfach auf einen Link nach OSM zu verweisen, der eine entsprechend gefilterte Liste anzeigt - also im Endeffekt genau diese Liste, die Du jetzt gebaut hast.
- Ich weiß nicht, ob es so eine Funktion gibt: zeige mir eine Liste von "power=station, voltage=380000|400000". Das wäre jedenfalls mE sehr hilfreich um in Zukunft genau solche Vorhaben umzusetzen. Und zwar nicht nur für Punktobjekte, sondern zB auch für Straßen, Nationalparkflächen etc. (wäre natürlich schön, wenn die Anzeige der Geodaten in so einer Liste dann wie Geohack auch in GoogleMaps, Bing, Yahoo etc erfolgen könnte) --alexrk 16:12, 12. Jun. 2010 (CEST)
- >50 ist bescheiden, es sind mindestens 300 Koordinaten. Pegelstand der Donau kannst du ausschließen, die Server stehen in Florida. Und es gibt derzeit keine Vorschläge, wie mit hundertfacher Einbindung (geht leidlich) oder gar 300 facher Einbindung umzugehen ist. Es ist allerdings so, dass das Problem eher den Editor, als den Leser trifft, der eher auf einen gefüllten Cache hoffen darf. Eine Umstellung der Vorlage auf eine serverseitige Implementierung statt der beschränkten Vorlagenexpansion ist bereits angedacht. Momentan gibt es nur Geduld (auch wenn der Timeout kommt, der Server legt die Seite im Cache ab und eine Minute später ist sie dann da, gilt auch beim Speichern) oder Verzicht (auf solche Koordinatenlisten). Noch hat der Server allerdings Reserven:
<!-- NewPP limit report Preprocessor node count: 408622/1000000 Post-expand include size: 1265948/2048000 bytes Template argument size: 644165/2048000 bytes Expensive parser function count: 0/500 -->
kleines Problem Geohack, #expr, diverse Infoboxen
Bin über folgendes Problem gestolpert: In Infoboxen wird oft die dim für die Vorlage:Coordinate berechnet (z.B. Vorlage:Infobox Halbinsel) und dabei #expr: verwende, das manchmal (nicht immer nachvollziehbar) Exponentialdarstellung erzeugt. Dieses Ergebnis wiederum versteht der Geohack nicht korrekt. Das tritt nach der momentanen Implementierung in den Infoboxen nur bei großen Objekten und daher auch selten auf, z.B. Kamtschatka, wo derzeit statt dim=1200000 (Meter) dim=1.2E+6 (ab einem Ergebnis > 1e6 Meter) erzeugt wird. Das ist zwar mathematisch nicht falsch, wird aber vom Geohack nicht verstanden und auch in diesem Tool als Fehler angemeckert. (Insgesamt geht es derzeit um 4 georeferenzierte Artikel mit 3 verschiedenen Infoboxen)
Geohack interpretiert den erzeugten Link http://toolserver.org/~geohack/geohack.php?pagename={{PAGENAMEE}}&language=de¶ms=57_N_160_E_dim:1.2E+6_region:RU-KAM_type:landmark mit scale=1:12, während der mathematisch gleichwertige Link http://toolserver.org/~geohack/geohack.php?pagename={{PAGENAMEE}}&language=de¶ms=57_N_160_E_dim:1.2E6_region:RU-KAM_type:landmark (ohne + vor dem E) mit scale=1:12000000 richtig interpretiert wird.
Folgende Lösungsmöglichkeiten:
- man zwingt #expr immer eine Nicht-Exponentialdarstellung zu liefern. Allerdings ist mir keine Möglichkeit bekannt, das zu erzwingen. Ja das Ergebnis war früher sogar noch von der zufälligen Servermaschine abhängig, die die Berechnung durchgeführt hat (ob das jetzt noch so ist, weiß ich nicht)
- geohack lernt dim=1.2E+6 so zu interpretieren, wie er das jetzt schon mit dim=1.2E6 macht. (Und Dispensers File-Viewer lernt diesen Fall nicht mehr als Fehler zu werten) - das wäre die von mir bevorzugte Lösung, die ich allerdings nicht umsetzen kann, also auf Hilfe angewiesen bin.
- die Berechnung von dim wird in mehreren Infoboxen so umbestellt, dass dieses Problem nicht mehr auftritt. Betroffene Infoboxen sind aktuell Vorlage:Infobox Insel, Vorlage:Infobox Halbinsel, Vorlage:Infobox See (Kaspisches Meer). Das Grundproblem tritt bei flächigen Objekten auf (Länge mal Breite), wo aus dem Maximum von Länge und Breite dim berechnet wird. Dazu erfolgt noch eine Umrechnung von km auf Meter.
- Derzeitige problematische Grundformel ist die folgende:
dim={{#expr:{{max|0{{{LAENGE|}}}|0{{{BREITE|}}}}}*1000}}
d.h. das Maximum der beiden Dimensionen wird auf Meter umgerechnet. Die führenden Nullen fangen hier nur fehlende Parameterwerte ab. #expr: dient auch dazu, ungültige Werte (keine Zahlen) abzufangen, da diese Funktion dann Fehler liefert. Die Multiplikation mit 1000 erlaubt auch Nachkommastellen in Länge und Breite. - am Beispiel Kamtschatka liefert die Formel: dim={{#expr:{{max|0{{{LAENGE|}}}|0{{{BREITE|}}}}}*1000}} → dim=1200000
- es scheint so zu sein, dass die Formel:dim={{#expr: trunc ({{max|0{{{LAENGE|}}}|0{{{BREITE|}}}}}*1000)}} → dim=1200000 das richtige liefert.
- Derzeitige problematische Grundformel ist die folgende:
Ich werde mal Lösung 3 umsetzen (3 Boxen, 6 Stellen). --Herzi Pinki 16:54, 9. Mai 2010 (CEST)
- Kamtschatka ist immer noch nicht gelöst. Bist du noch dran? --188.174.1.72 12:31, 17. Mai 2010 (CEST)
- Bei mir ist es korrekt... Uwe Dedering 13:42, 17. Mai 2010 (CEST)
- Die IP meinte wohl, dass der Artikel hier noch gelistet ist: http://toolserver.org/~dispenser/view/File_viewer#log:coord-dewiki.log --тнояsтеn ⇔ 10:49, 19. Mai 2010 (CEST)
- Ich bin noch dran, aber auch für Hilfe dankbar. lg --Herzi Pinki 17:37, 19. Jun. 2010 (CEST)
- ich bin ein Trottel, den Fehler habe ich beim Beschreiben des Fehlers hierher dupliziert. ... jetzt erledigt. --Herzi Pinki 18:09, 19. Jun. 2010 (CEST)
- Ich bin noch dran, aber auch für Hilfe dankbar. lg --Herzi Pinki 17:37, 19. Jun. 2010 (CEST)
- Die IP meinte wohl, dass der Artikel hier noch gelistet ist: http://toolserver.org/~dispenser/view/File_viewer#log:coord-dewiki.log --тнояsтеn ⇔ 10:49, 19. Mai 2010 (CEST)
- Bei mir ist es korrekt... Uwe Dedering 13:42, 17. Mai 2010 (CEST)
RFC 5870 ist fertiggestellt worden und definiert ein Uniform Resource Identifier für geographische Ortsangaben (geo-URI). Könnte so etwas hier eine Rolle spielen? --Fomafix 20:38, 17. Jun. 2010 (CEST)
- Sollte im Geohack leicht umzusetzen sein, ob es mehr Zukunft hat als das Geo-microformat, wird die Zuknft zeigen. Danke für den Link. Kolossos 22:38, 17. Jun. 2010 (CEST)
- Umgekehrt wäre vielleicht Browser-Addon's sinnvoll die bei eine "geo"-URI auf den Geohack verlinken. --Kolossos 12:29, 21. Jun. 2010 (CEST)
Fehler mit Eigenbau-Vorlage
1) Weiter oben ging es auch schonmal um die Vorlage:Koordinate Weltkugel. Sie wird jetzt z.B. in der Liste der Landschaftsschutzgebiete in der Steiermark verwendet und erzeugt eine Fehlermeldung auf [5]. Woran liegts?
2) Sind Koordinaten ohne region-Angabe wirklich im Sinne der Wikipedia-Georeferenzierung? --188.174.72.128 10:31, 1. Jun. 2010 (CEST)
- Man sollte die Frage grundsätzlicher stellen: macht eine Vorlage Sinn, die sich von der Vorlage:Coordinate mit dem Parameter "text=" nur dadurch unterscheidet, daß im Text statt der Koordinaten ein Symbol ausgegeben wird? Ich denke, nein! Falls man dieses Symbol tatsächlich braucht, sollte man Vorlage:Coordinate entsprechend aufbohren. Man betrachte jedoch Benutzer:Karl_Gruber/Kulturdenkmäler_in_Hardegg: was spricht dagegen, statt der Symbole "ausgeschriebene" Koordinaten zu verwenden? Platz genug gibt es. In jedem Fall bitte keine universell nutzbaren neuen Vorlagen ohne vorherigen Konsens schaffen! --Telford 10:44, 5. Jun. 2010 (CEST)
- ACK, siehe hier und hier, bisher wenig Resonanz. lg --Herzi Pinki 11:01, 5. Jun. 2010 (CEST)
- Schade. Woran liegt es? --93.104.172.76 15:38, 28. Jun. 2010 (CEST)
- AGF: Hier prallen zwei gegensätzliche Standpunkte aufeinander, keiner bewegt sich, und die von mir vorgeschlagene Umsetzung ist nicht ganz so einfach. Das liegt daran, dass Bilder, die nicht standardmäßig auf die Bilddatei verlinken, nur über imagemap verlinkt werden können, was dazu führt, dass die Vorlage Coordinate beinahe doppelt aufgerufen wird. Dies verschärft dann ein Problem für den Parser. Aber dein Schade versteh ich hier nicht, was ist schade? lg --Herzi Pinki 00:31, 29. Jun. 2010 (CEST)
- Das bezog sich darauf, dass es bisher wenig Resonanz gab. --188.174.29.204 09:45, 29. Jun. 2010 (CEST)
- AGF: Hier prallen zwei gegensätzliche Standpunkte aufeinander, keiner bewegt sich, und die von mir vorgeschlagene Umsetzung ist nicht ganz so einfach. Das liegt daran, dass Bilder, die nicht standardmäßig auf die Bilddatei verlinken, nur über imagemap verlinkt werden können, was dazu führt, dass die Vorlage Coordinate beinahe doppelt aufgerufen wird. Dies verschärft dann ein Problem für den Parser. Aber dein Schade versteh ich hier nicht, was ist schade? lg --Herzi Pinki 00:31, 29. Jun. 2010 (CEST)
- Schade. Woran liegt es? --93.104.172.76 15:38, 28. Jun. 2010 (CEST)
- ACK, siehe hier und hier, bisher wenig Resonanz. lg --Herzi Pinki 11:01, 5. Jun. 2010 (CEST)