Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2009-II

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2009-II#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv/2009-II#Thema_1

1. April?

Vorlage:Georeferenzierungshinweis und dann noch nicht mal NPOV, heieiei! -- visi-on 19:20, 1. Apr. 2009 (CEST)

Tool Get Coordinate

Was ist mit dem schönen Tool los? Es startet zwar noch, gibt aber nichts mehr aus, zumindest bei mir (Firefox 3.0.8). --Martin Zeise ✉ 20:38, 1. Apr. 2009 (CEST)

Was auch immer war es geht wieder. -- visi-on 23:34, 1. Apr. 2009 (CEST)

Koordinaten Stadtteilartikel

Hallo, wo genau sollten idealerweise die Koordinaten zu den Dresdner Stadtteilen (Gemarkungen) platziert sein? Im alten Dorfkern oder besser in der Mitte der Gemarkung? Gleiche Frage bei den statistischen Stadtteilen (in der geographischen Mitte oder an recht zentral gelegenen, für den Stadtteil wichtigen Straßen/Plätzen?) und bei den Ortschaften/Ortsamtsbereichen (in der Mitte oder am Sitz des Ortsamts/der Ortschaftsverwaltung?). In allen Fällen geht es um Flächen mit Größen so etwa zwischen 1 und 50 Quadratkilometern. Viele Grüße! --MoToR 12:46, 8. Apr. 2009 (CEST)

Ich meine Kolossos hat dazu mal was geschrieben (finds aber nicht). Kurzfassung: Gefühltes Zentrum, aber kein spezielles Objekt (Platz, Kirche, Strassenkreuzung usw.). dazu gehören auch die Statuen an den geographischen Mittelpunkten. (Hintergrund: Falls die Koordinaten von mehreren Objekten zusammenfallen gibt das in der Auswertung Fehlerwarnungen. Bei statistischen Arealen darfs also schon ungefähr die Mitte treffen. -- visi-on 13:14, 8. Apr. 2009 (CEST)

Kolossos hatte ich unmittelbar zuvor auf seiner Disk gefragt. Er riet mir auch, die Koordinaten mittig anzusetzen sowie die Sache hier noch einmal anzusprechen, weil er das nicht für die Ideallösung zu halten scheint. Naja, ich werd's erst mal so machen. Danke. --MoToR 13:58, 8. Apr. 2009 (CEST)

Hagavatn

Kann jemand bitte mal nachgucken, was in genanntem Artikel gerade nicht funktioniert? Die Koordinaten werden nicht korrekt angezeigt, obwohl ich sie schlussendlich genauso angeführt habe, wie in einer vorherigen Version, in der sie korrekt angezeigt wurden. Danke und Grüße, --Polarlys 22:25, 9. Apr. 2009 (CEST)

Habs mal geändert. Die Koordinaten gehören in die Infobox, wenn eine da ist. Gruß --тнояsтеn ⇔ 22:50, 9. Apr. 2009 (CEST)

Danke für deine Hilfe! Ich hatte sie erst in der Infobox, nur im falschen Format :-( Grüße, --Polarlys 22:59, 9. Apr. 2009 (CEST)

Bei Vorlage:Infobox See gibt es auch ein ausgefülltes Beispiel. Die Koordinaten können entweder sexagesimal oder dezimal eingegeben werden, siehe hier. --тнояsтеn ⇔ 23:15, 9. Apr. 2009 (CEST)

Text in Positionskarte

Kann man bei der Positionskarte angeben, in welcher Richtung zum Punkt (links, rechts oben, unten) der Text auftauchen soll ? Wer weis, wie es geht, der könnte bei Kirkenes aktiv werden. Cäsium137 (D.) 09:55, 14. Apr. 2009 (CEST)

Erledigt. -- Spischot 11:31, 14. Apr. 2009 (CEST)

Anpassung des Projekts

Hallo. Ich wollte mal nachfragen, was hier so von einer Anpassung der Georeferenzierung gehalten wird. Meine Kritikpunkte sind:

1. Starke Zerteilung in einen Vorlagenbaum Nachteile: beansprucht Serverlast, erschwert den Durchblick
2. Nicht (mehr) ausgereifte Parameter. So sollten alle numerischen Werte dezimal vorliegen.

Da müsste man doch gewiss einiges verbessern können. Cäsium137 (D.) 11:15, 15. Apr. 2009 (CEST)

Flüsse / waterbodies

Ich finde es muss mal eindeutig geklärt werden, wie man mit Flüssen u.ä. umgehen soll (oder gibt es so eine Diskussion schon irgendwo?). Allein in in der Kategorie Geographische Lage gewünscht (waterbody) sind noch über 1600. Soll die Quelle oder die Mündung angegeben werden? Und was wenn es mehrere gibt? --Celph titled 08:29, 2. Apr. 2009 (CEST)

Die Vorlage:Infobox Fluss nimmt dir diesen Entscheid ab (Artikelkoordinate ist die Mündung) -- visi-on 08:45, 2. Apr. 2009 (CEST)

Alles klar, dann bau ich die ein. Danke--Celph titled 08:49, 2. Apr. 2009 (CEST)

übrigens resultieren viele der Lagewünsche aus der falschen Verwendung. Orientiere dich am Besten an Spezial:Beiträge/Herzi Pinki, der macht schon seit Tagen fast nichts anderes -- visi-on 08:54, 2. Apr. 2009 (CEST)

Entschuldigt, bitte, dass ich mich in Eure Diskussion einmische. Ich beschäftige mich hauptsächlich mit den französischen Flüssen und ermittle natürlich immer wieder die fehlenden Koordinaten. Das ist an sich mühsam genug, die Eintragung in die Artikel könnte aber erleichtert werden, wenn jemand einen BOT schreiben könnte, der die alten Infoboxen (ohne Möglichkeit der Koordinateneingabe) gegen die aktuellen einfach austauscht. Dann wäre der Aufwand für das Eintragen der Werte etwas geringer und die reine copy-paste Arbeit könnte ein Programm genau so gut erledigen.
Grüße --Skipper69 14:45, 24. Apr. 2009 (CEST)

Probier mal den Vorlagenmeister aus. -- visi-on 16:19, 24. Apr. 2009 (CEST)

Unterseite löschen

Die Unterseite Wikipedia:WikiProjekt Georeferenzierung/Artikel ohne Koordinate ist seit Einführung der neuen Vorlage überflüssig, da Artikel automatisch oder durch Vorlage in die Kategorie:Wikipedia:Lagewunsch einsortiert werden. Wenn niemand etwas dagegen einzuwenden hat, werde ich Links auf diese Unterseite entfernen und diese dann löschen lassen. --тнояsтеn ⇔ 23:42, 7. Apr. 2009 (CEST)

Das ist das gleiche Thema, wie ich es schon mal hier angesprochen habe.

Denke mal wir sollten die Seite noch ein bissel behalten. Denn (auch wenn si zur zeit nciht aktuell ist) können dort die Artikel ohne Koordinate und die damit nicht in der Kategorie:Wikipedia:Lagewunsch aufgelistet werden. Stefan Kühn hatte da mal vor längerer Zeit ein Skript geschrieben um diese zu finden. MfG Monsterxxl <°))))> 10:40, 8. Apr. 2009 (CEST)

Hat sich wohl erledigt: [1]. --тнояsтеn ⇔ 14:34, 15. Apr. 2009 (CEST)

Gelöscht. --92.229.185.82 00:30, 17. Apr. 2009 (CEST)

en:Template:gbmappingsmall

In UK betreffenden Artikeln findet sich in der EN:WP obige Vorlage, welche etwa {{gbmappingsmall|ST611717}} auf eine mir nicht nachvollziehbare Weise auf den Toolserver verlinkt und dann die üblichen Karten zur Verfügung stellt. Offenbar handelt es sich um so etwas ähnliches wie das UTM-Gitter, siehe en:British national grid reference system (das Gegenstück OSGB36 ist ungenügend) bzw. hier. Ich will hier keine Umsetzung den EN-Vorlage verlangen – wie aber die Geokoordinaten bestimmen? Einzeln in EN den Link aufrufen und durch C+P die Koordinaten übertragen ist eines anständigen WPners nicht würdig. Gibt es Alternativen? --Matthiasb 22:05, 30. Apr. 2009 (CEST)

Ehrlich gesagt, verstehe ich nicht so ganz das Problem. Falls es um die Umrechnung von Koordinaten in OSGB36 auf Länge/Breite in WGS84 (und umgekehrt) geht, empfehle ich http://www.movable-type.co.uk/scripts/latlong-gridref.html (wichtig: auf das geodätische Datum achten). Übrigens ist im GeoHack ein Fehler, wie ich weiter oben geschrieben habe. Keine Ahnung, ob das nur die de wp oder auch die en wp betrifft. --Telford 10:52, 3. Mai 2009 (CEST)

Mein Problem liegt in der Masse, ich übertrage derzeit Listen, da kommt das vierzig-, fünfzigfach vor. Seufz. Ist es halt doch Handarbeit. --Matthiasb 15:29, 5. Mai 2009 (CEST)

dieses mapping ist gar keine grosse Hexerei. Offensichtlich frisst der geohack auch OSGB36 Koordinaten. Telford ich hatte mir das OSGB36-Grid schon mal angesehen, müsste mich da aber wieder einarbeiten. Denn Fehler konnte ich nicht lokalisieren.-- visi-on 15:45, 5. Mai 2009 (CEST) Noch was besseres gefunden: http://www.dqts.net/files/wgsman24.pdf viel spass beim reinziehen. Damit sollte nun eine Lösung wie bei CH1903 möglich sein. -- visi-on 22:57, 5. Mai 2009 (CEST)

Möglicherweise berechnet auch die Vorlage aus den britischen Koordinaten Länge und Breite und gibt die an den GeoHack weiter, der seinerseits dann wieder auf OSGB36 umrechnet. Und den Fehler im GeoHack habe ich jetzt bestimmt ein Dutzend mal beobachtet. Vorgehen: Koordinaten für eine klar identifizierbare Landmarke in Get-a-map des britischen OS ermitteln, über den von mir genannten Konverter jagen und in einen Artikel einbauen. Wenn man sich das dann im GeoHack anzeigen läßt, ist GoogleEarth maximal 20 Meter daneben, Get-a-map aber jedesmal um gut 100 Meter Richtung westnordwest. (Nicht auf Augenmaß verlassen, sondern abmessen!) Das ist eindeutig der Unterschied im Geodätischen Datum. – In beiden Fragen würden wir nur weiterkommen, wenn wir mit den Programmierern vom GeoHack reden; die scheinen hier aber nicht mitzulesen, und ich habe auch keine Ahnung, wie man die kontaktieren kann. --Telford 17:43, 5. Mai 2009 (CEST)

(BK) Wenn jemand mal mit der Maus über die brit. Koordinaten geht, erkennt er, dass der Link nicht direkt an den Geohack geht, sondern an http://rhaworth.com/os Das dortige Skript macht dann die Umwandlung und eine Weiterleitung. Die Seite gehört dem Wikipedianer en:User:RHaworth und die Software hat er unter GFDL lizenzsiert, du müßtest Ihn also mal fragen wo der Source-code ist.

@Telford: Auf die zugrundeliegende Formel im Geohack habe ich Zugriff, vielleicht stammt die ja noch aus Zeiten der Rechenschieber.--Kolossos 18:03, 5. Mai 2009 (CEST)

(Mail an RHaworth ist raus.)--Kolossos 18:31, 5. Mai 2009 (CEST)

Danke für den Hinweis auf die RHaworth! Ich habe auch noch was gefunden: http://en.wikipedia.org/wiki/Template_talk:Oscoor#datum. Die Beiträge sind ja schon etwas älter, bestätigen aber genau meine Beobachtung. --Telford 18:42, 5. Mai 2009 (CEST)

Nachtrag zu den Formeln: unter http://www.movable-type.co.uk/scripts/latlong-gridref.html ist der Quellcode in JavaScript angegeben. Besonders wichtig ist der Abschnitt I have written some separate notes on converting between OSGB-36 & WGS-84: genau diese Transformation fehlt nämlich im GeoHack. --Telford 19:04, 5. Mai 2009 (CEST)

jetzt weiss ich wieder warum ich das nicht weiter verfolgt hatte. Ich hatte nichts vernünftiges gefunden um die Iteration zu elliminieren. Grundvoraussetzung um etwas mit Vorlagen Programierung zu machen. -- visi-on 19:48, 5. Mai 2009 (CEST)

Ich verstehe das Problem. Aber so bleiben kann das wohl auch nicht. Kommen wir irgendwie an die Programmierer vom GeoHack ran? --Telford 19:59, 5. Mai 2009 (CEST)

Kolossos macht das ;-)

Das problem ist, dass wir in der WP nur WGS84 haben wollen. Aber dem Laien eine Umrechnung (geh auf Seire sowieso tip ein und schreib ab) nicht zumutbar ist. aber die Moloddensky Transformation könnte eine alternative sein. Die CH1903 umwandlung passiert ja auch so ähnlich. Theretisch müsste das auch auf einen Meter genau machbar sein. Habs aber noch nicht verifiziert. -- visi-on 20:14, 5. Mai 2009 (CEST)

Jaja, laut Toolserver-Wiki gehöre ich wohl zu den Geohack-Pflegern.

Meine Bedenken an einer Umrechnung von X-beliebigen-Koord.-systemen in WGS84 im Geohack sind, dass die Verlinkung auf den Geohack immer mehr zur Geodatenextraktion genutzt wird. Und auch wenn man die Dumps zur Extraktion nutzt, müßte jeder der die Daten haben will, die Funktionen nachbilden. Also halte ich eine Einbindung für nicht sinnvoll. Andererseits, kann es mit der externen Skripteinbindung vielleicht auch nicht so weitergehen. Insgesamt wird das Koordinatensystem ungefähr 50.000 mal verwendet, diese Koordinaten dürften wohl bis jetzt in jeder Extraktion fehlen. Zudem stellt sich die Frage, wie man das jetzt "diplomatisch" angeht ;-). --Kolossos 21:39, 5. Mai 2009 (CEST)

Der Deal mit den Schweizer Landeskoordinaten geht doch auch. Theorretisch müsste es für jedes Koordinatensystem möglich sein solche geschlossenen Formeln anzugeben (s. o.) -- visi-on 22:40, 5. Mai 2009 (CEST)

Gefunden! Multiple Regression Equation Appendix E für die eiligen. -- visi-on 23:05, 5. Mai 2009 (CEST)

Ich fasse zusammen:

• Der GeoHack erwartet als Eingabe Länge und Breite in WGS84. Wenn Koordinaten in anderen Systemen vorliegen, muß man sie vorher konvertieren.
• Die in der en wp bereitgestellten Vorlagen oscoor, gbmappingsmall usw. liefern dem GeoHack einen falschen Input, weil die Transformation des Geodätischen Datums fehlt.
• Der Geohack liefert als Ausgabe
  • Länge und Breite im Bezugssysstem WGS84 (logisch, ist ja sein eigenes Bezugssystem)
  • UTM-Koordinaten
  • Koordinaten im British National Grid (systematisch falsch, weil der datum shift fehlt!)
  • Schweizer Landeskoordinaten (soweit ich bisher beobachten konnte, korrekt)
  • Koordinaten für Neuseeland (datum shift nicht erforderlich, da NZGD2000 sehr nahe an WGS84)

Was folgt daraus:

• In jedem Fall sollte die Ausgabe der britischen Koordinaten korrekt sein. Dazu bedarf es einer Transformation des Geodätischen Datums von WGS84 nach OSGB36, die üblicherweise per Helmert-Transformation erledigt wird. Falls der GeoHack in einer "richtigen" Programmiersprache erstellt worden ist, was man hoffentlich annehmen darf, ist das überhaupt kein Problem. Die erforderliche Formeln finden sich z.B. unter http://www.movable-type.co.uk/scripts/latlong-convert-coords.html .
• Ob der GeoHack auch Eingaben in anderen Koordinatensystemen akzeptieren soll, ist weniger eine Frage des Programmieraufwands als der "Diplomatie", insofern ack Kolossos.

--Telford 08:18, 6. Mai 2009 (CEST)

Der Diplomatie kannst du mit «Multipler Regression» nachhelfen ;-) -- visi-on 09:39, 6. Mai 2009 (CEST)

Die Methode soll ja bei GPS-Geräten weite Anwendung gefunden haben. Die Helmert-Transformation scheint eher von theoretisch didaktischem Wert zu sein. -- visi-on 09:42, 6. Mai 2009 (CEST)

Ich hatte Kolossos so verstanden, daß bei Eingriffen in den GeoHack natürlich internationaler Konsens bestehen sollte, und nicht, daß er sich auf das Berechnungsverfahren bezog. Falls man die Helmert-Transformation im GeoHack realisieren kann, erscheint sie mir viel einfacher als dieses Regressionsverfahren (welches ich leider nicht verstehe). Übrigens läßt sich Iteration bei Umrechnung britischer Koordinaten auf WGS84 prinzipiell nicht vermeiden: die britische Kartenprojektion ist eine transversale Mercatorprojektion, und die Transformation von Mercator-Koordinaten auf Länge/Breite geht m.W. nur iterativ. (In der Gegenrichtung geht das wohl ohne Iteration, und die interessiert mich erst mal mehr.) --Telford 10:01, 6. Mai 2009 (CEST)

Die "Diplomatie" bezog sich auf ein eventuelles Einmischen in engl. Vorlagen, wir können diese wohl nicht ohne weiteres auf WGS84 umstellen, auch wenn das vielleicht das sinnvollste wäre.

Im Geohack können wir nahezu nach belieben Verbesserungen einführen. Es gibt dort die Funktion LatLon2OSGB36 () in PHP umgesetzt. Wir müssten also raus bekommen wo da der Fehler steckt. Ich glaube dabei noch nicht, dass wir es überall mit einer gleichmäßigen Drift zu tuen haben, das wäre zu einfach. Was ist die max. Genauigkeit, der Umrechnung? Bzw. wie groß ist der Unterschied zwischen dieser Helmert-Transformation und "Multipler Regression"? Wenn darüber Einigkeit besteht und jemand die obige Funktion umgestrickt kann ich die neue Funktion gerne einspielen. --Kolossos 12:31, 6. Mai 2009 (CEST)

Du glaubst das also nicht, so so. Kannst Du mir noch den Quellcode für die Funktion LatLonOrigin2TM zugänglich machen? Dort findet nämlich die eigentliche Berechnung statt. – Die Genauigkeit der Helmert-Transformation beträgt angeblich 4 bis 5 Meter, ist für unsere Zwecke also völlig ausreichend. <Gebetsmühle ein> Die Ungenauigkeit kommt daher, daß im GeoHack überhaupt keine Transformation des Geodätischen Datums stattfindet. Und wenn man lat/long in WGS84 eingibt, kann man nicht erwarten, daß Mercator bezogen auf Airy1830 herauskommt. <Gebetsmühle aus> --Telford 13:11, 6. Mai 2009 (CEST)

Hab die gewünschte Funktion bei LatLon2OSGB36 () mit hinten rangehangen. Also über London aufgerufen, gibt mir der Geohack so was aus: "UK Ordnance Survey: TQ3056780672 Airy 1830". Irgendwas macht er also schon, nur was? --Kolossos 14:04, 6. Mai 2009 (CEST)

(quetsch) LatLon2OSGB36() legt folgende Parameter fest:

• Radius = große Halbachse des Ellipsoids Airy 1830
• Eccentricity = Quadrat der Exzentrizität
• Scale = Verkleinerungsfaktor, damit zwei Meridiane mit exakter Länge entstehen (wie bei UTM)
• latitude_origin und longitude_origin geben den Nullpunkt der Projektion als Länge und Breite an
• Easting_Offset und Northing_Offset geben den Nullpunkt der Projektion in Landeskoordinaten an
• NorthingOffsetSouth wird hier nicht benötigt; ist nur drin, weil LatLonOrigin2TM() auch für die Umrechnung in UTM gebraucht wird.

Der Sinn von Easting_Offset und Northing_Offset ist folgender: der Zentralmeridian der Projektion liegt mitten auf der britischen Insel, um die Verzerrungen klein zu halten. Damit entstehen natürlich negative Koordinaten westlich vom Zentralmeridian. Durch diesen Offset werden diese Koordinaten künstlich positiv gemacht. (Wozu Northing_Offset nötig ist, weiß ich leider nicht; selbst die Kanalinseln liegen ja nördlich 49 Grad.)

Aus diesen Werten berechnet LatLonOrigin2TM() die tranversalen Mercator-Koordinaten, also Easting und Northing im britischen Koordinatensystem.

Was danach kommt, ist die Umwandlung von reinen Zahlenwerten in ein Buchstabenpaar zur eindeutigen Identifizierung eines 100-km-Quadrats und kürzen der Zahlenangaben auf Werte relativ zum Nullpunkt dieses Quadrats. Einzelheiten sind unter en:British national grid reference system beschrieben.Da gibt es übrigens auch einen hochinteressanten Abschnitt über datum shift.

--Telford 15:45, 6. Mai 2009 (CEST)

Also dem code ist relativ einfach anzzusehen, dass die Helmerttransformation fehlt. Die Multiple Regession ist einfach ausgedrückt ein Näherungsverfahren über möglichst viele Punkte mit dem Ziel die Transformation in einem Polynom abzubilden. Die Stärke liegt darin, dass damit auch lokale Anomalitäten ausgeglichen werden. Man nimmt sozusagen die Iteration vorweg. Die Helmert Transformation ist theoretisch sehr genau, deren Unzulänglichkeit liegt aber in der beschränkten Rechengenauigkeit und der Kumulation von Fehlern in der Iteration. Ich bin grad am überlegen ob wir erfolgsaussichten haben wenn wir das OSGB um die Koeffizienten bitten (Zielgenauigkeit ~1m). Man könnte ja drauf hinweisen, dass die Schweizerische Landestopographie ebenfalls solche Formeln veröffentlicht hat. Ich kann zwar das Verfahren der Multiplen Regression anwenden, mir fehlen aber die genauen Koordinaten (im Quell- uns Zielsystem) und in aussreichender Menge sowieso. Ich würde die Frage offen formulieren, dass denen auch die Möglichkeit bleibt Vorschläge zu machen. -- visi-on 14:42, 6. Mai 2009 (CEST)

Ist schon komisch: vor zehn Wochen habe ich auf einen (damals von mir nur vermuteten) systematischen Fehler in der Größenordnung von 100 m hingewiesen, und niemand hat sich die Mühe gemacht, daß mal nachzuprüfen. Und jetzt soll ein zufälliger Fehler von maximal 4 bis 5 m ein Problem sein? Ich denke, daß ich beim Georeferenzieren wirklich sorgfältig vorgehe, aber eine Genauigkeit von weniger als 20 m bei Kartengrundlage 1:50.000 und weniger als 10 m bei 1:25.000 halte ich für illusorisch. Wozu dann bei der Datumskonversion – die bisher außer mir niemand vermisst hat – derart pingelig sein? --Telford 16:04, 6. Mai 2009 (CEST)

Na wenn das so ist lass ich in der WP den Molodensky zu ehren kommen ... Es würde dann analog Vorlage:CH1903-WGS84 und Vorlage:WGS84-CH1903, Vorlage:OSGB36-WGS84 und Vorlage:WGS84-OSGB36 geben. -- visi-on 16:14, 6. Mai 2009 (CEST)

Das klingt sehr interessant :-)) und Matthias wird sich freuen. Trotzdem noch mal die Frage: Du hattest weiter oben geschrieben, daß Iteration bei der Vorlagenprogrammierung nicht geht und Du deshalb frühere Versuche in dieser Sache aufgegeben hast. Diese Klippe besteht m.E. noch immer, nämlich bei der Konversion von Easting und Northing in Länge und Breite. --Telford 17:46, 6. Mai 2009 (CEST)

hmm man müsste halt alle algorithmen im kopf haben ... -- visi-on 18:38, 6. Mai 2009 (CEST)

Frage an Kolossos: hat RHaworth auf Deine Mail geantwortet? Wenn ja, was meint er? --Telford 20:42, 11. Mai 2009 (CEST)

Orte finden

Zur Zeit werden im Wikipedia-Layer nur Orte angezeigt, für die ein eigener Artikel exisitert.

Frage: was ist mit Koordinaten, die in einem Artikel eingebettet sind?

Beispiel Tütberg: Redirect auf Hauptartikel eingerichtet, zusätzlich mit Koordinaten versehen; wenn ich Koordinaten an erste Stelle platziere, funktioniert das Redirect nicht mehr.

Zeitan 21:32, 8. Mai 2009 (CEST)

Doch seit heute (siehe unten) klappt das: Google Maps Layer. Klappt sogar doppelt, einmal ein "Tütberg" und einmal "Königsforst#Tütberg". Dabei würde ich allerdings die erste Variante bei der die Koordinate in einem REDIRECT steckt gerne wieder gestrichen sehen, das verwirrt doch mehr als es nützt, wenn der Leser im verlinkten Artikel keine Informationen findet, weil es den Artikel an sich garnicht gibt. --Kolossos 19:30, 11. Mai 2009 (CEST)

Vielen Dank für die Antwort. Wo erfahre ich mehr dazu?

Den Abschnitt "Königsforst#Tütberg" gibt es gar nicht. Folglich sollte wohl zu jeder Koordinatenangabe im Text eine Überschrift erstellt werden.

Der OSM-Layer funktioniert nicht mehr?

Zeitan 20:25, 11. Mai 2009 (CEST)

Siehe unten, da gibt es mehr Infos (War vorhins etwas zeitnäher von mir geplant).

Die Sache mit dem #-Anchor ist die einzigste Möglichkeit in einem Artikel eine Bestimmte Stelle anzuspringen. Deshalb nutze ich sie. Ich will es den Artikelschreibern aber nicht aufzwingen ihre Artikelstruktur an die Geokoordinaten anzupassen. Wenn es klappt ist es gut, wenn nicht, versteht der Leser so aber wohl auch noch am ehesten, dass es sich um eine Untereinheit des Artikelobjektes handelt. --Kolossos 22:23, 11. Mai 2009 (CEST)

D.h. alle Geolinks in einem Artikel werden ausgewertet; der Anker wird gesetzt, auch wenn keine Überschrift zum Anspringen vorhanden ist, richtig?

So werde ich in Zukunft mich bemühen, zu jedem Geotag im Text auch eine Überschrift einzufügen, die genauso heißt wie der Geotag-Name.

Zeitan 17:35, 12. Mai 2009 (CEST)

neue Geokoordinaten Auswertung

Alles neu macht der Mai:
Die Geokoordinaten-Extraktion der /Wikipedia-World wurde nach langer Zeit heute endlich mal wieder erneuert. Basis sind jetzt nicht mehr die Dumps und die darin befindlichen unzähligen Vorlagen, sondern die Links zum Geohack wie sie in der Datenbank stehen. Diese Daten werden dankbarer Weise von Dispenser im Tagesrythmus extrahiert und auf dem Toolserver bereitgestellt. Blieb mir noch die Aufgabe die verschiedenen Sprachen miteinander zu verschmelzen und das für die Kartendarstellung wichtige Relevanzkriterium einzupflegen (Buchstabenanzahl des Artikels/Anzahl der enthaltenen Geokoordinaten). Die Anzahl der Geokoordinaten hat sich von 264.288 von 677.434 Einträge erhöht und damit mehr als verdoppelt.

Was gibt es noch zu erledigen:

• Ich würde euch bitten, euch den Layer mal anzuschauen und bescheid zu sagen, wenn wichtige Dinge fehlen oder unwichtiges allzu dominant dargestellt ist. Für weitere Anregungen wäre ich auch dankbar.
• Die Verbindung zu den exotischeren Sprach ist noch nicht angepasst, ich denke das mache ich morgen.
• Es fehlt auf jeden Fall noch die genauere Differentiation der Typen (Kirchen, Höhlen,...), diese Unterscheidung wurde von Stefan Kühn immer anhand der Kategorien vorgenommen.
• Ich würde gerne noch die Relevanzkriterien umstellen, weg von der Buchstabenanzahl, hin zu den mittlerweile verfügbaren Zahlen wieviele Leute sich eine Artikel angeschaut haben. Ich habe die Daten schon in einer Datenbank nur ist das Verschmelzen beider Datenbanken aus für mich unerklärlichen Gründen sehr langsam.
• Wichtig wird in Zukunft also sein, dass alle wichtigen Parameter an den Geohack übergeben werden, diese trifft besonders auf die Region, dim und dem "name"-Parameter zu.
• Der Verein hat einen neuen Datenbankserver bestellt, ich hoffe, damit geht es in Zukunft etwas flüssiger und stabiler.

--Kolossos 22:16, 11. Mai 2009 (CEST)

Googlemaps-Layer funktioniert gut!

Layer auf OSM macht bei mir Probleme: nach Verschieben der Karte verschwanden allle Fähnchen. Nun erscheinen sie gar nicht mehr. Eine Auflistung am linken Rand ist nicht mehr vorgesehen?

Werden die Geodaten automatisch täglich aktualisiert? Woran liegt es, wenn manche Einträge nicht gezeigt werden?

Zeitan 17:29, 12. Mai 2009 (CEST)

Der Layer auf OSM (wenn du wp-on-osm.php meinst) ist eigentlich das selbe wie der Google-Maps Layer, nur das andere Kacheln im Hintergrund liegen. Probleme macht hin und wieder der Datenbank-Server, der an seiner Kotzgrenze arbeitet und nun bald ersetzt wird. Andere Erklärungen habe ich erstmal nicht.

Was die Aktualisierung angeht, so denke ich eher an Wochen- oder Monatsrythmus. Das Aufbereiten der Daten dauert doch ein paar Stunden. Ziel ist jedenfalls das vollautomatisch zu machen, es kann aber doch sinnvoll sein noch mal einen Blick drauf zu werfen. --Kolossos 23:40, 13. Mai 2009 (CEST)

Infobox Berg

Gerade ist mir bei Mount Cleveland (Alaska) aufgefallen, dass die Koordinate nicht rechts oben auf der Seite angezeigt wird. Habe auf die Schnelle den Fehler nicht gefunden oder ist das gewollt? --тнояsтеn ⇔ 03:08, 23. Mai 2009 (CEST)

Hab das mal gefixt...Lag an dem parameter NEBENBOX. Der ist dafür da mehrfach auftretende Ausgaben außerhalb der Box (Die Artikelkordinate) zu unterdrücken. Steht auch schön in der Vorlagenbeschreibung drinne. :)) MfG Monsterxxl <°))))> 07:43, 23. Mai 2009 (CEST)

Super, danke. War doch etwas spät gestern ;-) --тнояsтеn ⇔ 12:23, 23. Mai 2009 (CEST)

Probleme bei PDF-Erstellung

Die WP-Buchfunktion wird gestört, falls bereits Geodaten im Artikel hinterlegt sind. Zumeist wird lediglich "{{Coordinate|XYZ}} (http://stable.toolserver.org/geohack/geohack.php?pagename=XXX&language=de&params=0_N_0_E_region:DE-BW_type:landmark" angezeigt, gelegentlich überlagert die Vorlage aber auch ganze Abschnitte. Einfachste Lösung: "Kategorie:Vom Druck ausschließen" hinzufügen - aber es ist ja wohl nicht gewünscht, dass solche Probleme schnell und "unbürokratisch" gelöst werden ;-) -- Mark Wolf 18:00, 28. Mai 2009 (CEST)

Kannst du noch den zu druckenden Artikel nennen, dass es nachvollziehbar ist? -- visi-on 18:05, 28. Mai 2009 (CEST)

Das Problem ist bei einer alten Fassung von Johanneum Tübingen aufgetreten, hier besonders interessant, weil der in der alten Fassung zwei Geo-Einträge hatte. In der jetzigen Form sind zumindest momentan keine Probleme sichtbar. -- Mark Wolf 18:14, 28. Mai 2009 (CEST)

Da war nur mal ein überflüssiger Lagewunsch ... -- visi-on 18:39, 28. Mai 2009 (CEST)

Das ist korrekt, der wurde jedoch in der Form {{Coordinate |NS= |EW= |type= |region= }} eingetragen. Ich schätze, dass doppelte Vorlagen das eigentliche Problem sind. Wie siehst du das? -- Mark Wolf 11:53, 2. Jun. 2009 (CEST)

Hatte schon Artikel mit mehreren Koordinaten als PDF erstellt und keine Fehldarstellungen bemerkt. -- visi-on 12:17, 2. Jun. 2009 (CEST)

Darauf kann ich mir wirklich keinen Reim bilden... -- Mark Wolf 16:16, 2. Jun. 2009 (CEST)

Koordinaten fehlen (nicht).

Beim Artikel Theodor-Storm-Schule Husum hab ich die Koordinaten gesetzt. Wollte dann die Vorlage {{Lagewunsch}} oder {{coordinate}} rausnehmen; hab aber nichts gefunden. Könnt ihr mal kucken? --JLeng 20:59, 3. Jun. 2009 (CEST) Achso, oben bei den Koordinaten steht immer noch "Koordinaten fehlen".

Der Lagewunsch kam von der Infobox. Da müssen die Koordinaten eingetragen werden. NNW 21:03, 3. Jun. 2009 (CEST)

Mann, ging das fix. Ich war noch gar nicht fertig mit schreiben. Danke! --JLeng 21:06, 3. Jun. 2009 (CEST)

template:coordinate löschantrag

Siehe http://commons.wikimedia.org/wiki/Template:Coordinate bzw Commons:Deletion requests/Template:Coordinate

FYI, GuidoD 00:34, 9. Jun. 2009 (CEST)

Koordinaten doppelt

Siehe z.B. Vöhrum: Weiß jemand, woher die Dopplung kommt? Vorlage + Coordinate-Template im Fließtext. Verhalten muss neu sein. --Sebastian Hornbostel 15:35, 14. Jun. 2009 (CEST)

Da war noch ne Koordinate im Fließtext. Habs gefixt. --тнояsтеn ⇔ 15:49, 14. Jun. 2009 (CEST)

Ah ja, danke. Habe ich echt übersehen. --Sebastian Hornbostel 21:52, 14. Jun. 2009 (CEST)

Eine Implementierung der Helmert-Transformation für den GeoHack

Ausgehend von der Diskussion eins drüber habe ich ein PHP-Skipt zur Umrechnung geografischer Koordinaten von WGS84 nach OSGB36 geschrieben:

    /**
     * datum shift using Helmert transformation
     * parameters for transformation WGS84 --> OSGB36 hard coded
     * possibility to implement other parameters should be evident
     *
     * height above the ellipsoid is ignored
     * latitude and longitude must be given in decimal degrees
     *
     * no transformation if abs(latitude)>89 or abs(longitude)>89
     * (lifting this restriction requires some more lines of code)
     */
    function HelmertDatumShift ( $latitude , $longitude )
    {
        /* return if latitude or longitude out of range */

        if ( abs($latitude) > 89. OR abs($longitude) > 89. )
           return array ( $latitude, $longitude );

        /* parameters for transformation WGS84 --> OSGB36 */

        $a1 = 6378137.0;
        $b1 = 6356752.3141;

        $a2 = 6377563.396;
        $b2 = 6356256.910;

        $tx = -446.448;
        $ty = +125.157;
        $tz = -542.060;
        $s0 = 1.0000204894;
        $rx = deg2rad ( -.1502/3600. );
        $ry = deg2rad ( -.2470/3600. );
        $rz = deg2rad ( -.8241/3600. );

        /* convert latitude and longitude to cartesian coordinates */

        $phi = deg2rad ( $latitude );
        $lambda = deg2rad ( $longitude );

        $cosphi = cos ( $phi );
        $sinphi = sin ( $phi );
        $coslambda = cos ( $lambda );
        $sinlambda = sin ( $lambda );

        $aq = $a1 * $a1;
        $e1 = ( $aq - $b1 * $b1 ) / $aq;
        
        $ny = $a1 / sqrt ( 1. - $e1*$sinphi*$sinphi );

        $x1 = $ny * $cosphi * $coslambda;
        $y1 = $ny * $cosphi * $sinlambda;
        $z1 = $ny * ( 1. - $e1 ) * $sinphi;

        /* the helmert transformation proper */
         
        $x2 = $tx + ( $s0 * $x1 - $rz * $y1 + $ry * $z1 );
        $y2 = $ty + ( $rz * $x1 + $s0 * $y1 - $rx * $z1 );
        $z2 = $tz + ( -$ry *$x1 + $rx * $y1 + $s0 * $z1 );

        /* convert cartesian coordinates to latitude and longitude */

        $aq = $a2 * $a2;
        $e2 = ( $aq - $b2 * $b2 ) / $aq;
        
        $lambda = atan2 ( $y2 , $x2 );

        $p2 = sqrt ( $x2*$x2 + $y2*$y2 );
        $phi = atan2 ( $z2 , $p2*(1.-$e2) );

        $grenze = 1. / $b2;
        $n0 = 11;

        do
        {
            $phi_alt = $phi;
            $ny = $a2 / sqrt ( 1. - $e2 * sin($phi) * sin($phi) );
            $phi = atan2 ( $z2 + $e2 * $ny * sin($phi) , $p2 );
            $n0 -= 1;
        } while ( abs ( $phi - $phi_alt ) > $grenze AND $n0 > 0 );

        return array ( rad2deg($phi), rad2deg($lambda) );
    }

Aufgerufen wird es an geeigneter Stelle durch:

    list ($latitude,$longitude) = HelmertDatumShift ( $latitude , $longitude );

Dazu ein paar Bemerkungen:

• Die Umrechnung Länge/Breite in Landeskoordinaten muß anschließend gesondert erfolgen
• Als Quelle für die Formeln und die Parameter habe ich http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/guidecontents/guide6.html mit den Anhängen A und B verwendet
• Eine Erweiterung auf andere Transformationen beliebiger Systeme ist durch Bereitstellung weiterer Parametersätze problemlos möglich; dann braucht die Funktion einen weiteren Übergabeparameter, der die Auswahl steuert
• Es werden derzeit Koordinaten in Westeuropa erwartet (wird hier nicht geprüft)
• Wegen der Mehrdeutigkeit des Arcustangens funktioniert der Algorithmus nur für Werte unter etwa 89 Grad
• Eine Erweiterung für beliebige Winkel oder eine Prüfung, daß die Eingabewerte in den erlaubten Grenzen liegen, ist relativ einfach möglich
• Mit der Rückgabe der Ergebnisse bin ich nicht recht glücklich: lieber wäre mir BOOLEAN als Wert der Funktion, aber wie kann ich dann das Ergebnis der erfolgreichen Berechnung übergeben?
• Die Iteration konvergiert nach ein bis zwei Schritten, was mir sehr schnell vorkommt: ist die Grenze sinnvoll gewählt?

--Telford 12:49, 27. Mai 2009 (CEST)

Iteration: ja der Grenzwert ist vernünftig (Bezug zu Halbachse des Elipsoid). Bei kleineren Grenzwerten könnte es zu Oszilationen kommen und folglich die Iteration nie endet. -- visi-on 13:19, 27. Mai 2009 (CEST)

Eben habe ich den Code noch ein klein wenig überarbeitet. Jetzt führen Eingabewerte außerhalb des Gültigkeitsbereichs des Algorithmus nicht mehr zu Unsinn, sondern nur zu keiner Transformation (weiterhin ohne Fehlermeldung). – RHaworth hat bisher auf keine Ansprache reagiert, obwohl er durchaus aktiv ist. Ich denke, wir sollten die Umrechnung für die Ausgabe jetzt in den GeoHack einbauen: wetten, daß dann sehr schnell einige in der en wp aufwachen werden? --Telford 07:17, 4. Jun. 2009 (CEST)

Wenn sie sich beim vom Ross fallen nicht zu sehr weh tun ... ;-) -- visi-on 09:09, 4. Jun. 2009 (CEST)

Habe eben noch ein paar Schönheitskorrekturen angebracht. --Telford 18:07, 23. Jun. 2009 (CEST)

Using the Helmert transform

Apologies for writing in English. It took me a long time to realise that for converting OSGB grid refs back to lat/long there is no need to mess about with the Helmert transform. The solution is ridiculously simple:

function OS2LL_bwt( $Easting, $Northing )
{
        require_once('http_get.php');	

        $pg=http_get("http://streetmap.co.uk/gct.srf?x=$Easting&y=$Northing&to=1");
        # or use file_get_contents() if your server supports it for external files
        for ($j=0; $j<2; $j++) {
            $pg=substr($pg,strpos($pg,'WGS')+6);
            $res[$j]=(float)substr($pg,strpos($pg,'(')+1);
        }
	return $res;
}

The 'bwt' in the name stands for bandwidth theft! It works. But seriously, here is a routine:

require_once ('transversemercator.php');

function OSGB2LL( $e, $n )
{
	$osgb36 = new transversemercator;
	$n2deg=0.000009;	// degrees lat per metre
	$lat=54.328158; $lon=-2.721893;
        $osgb36->Easting=353150; $osgb36->Northing=492750;
	/* arbitrary starting point roughly near the centre of gravity of GB -
 	   actually it is the house where RHaworth spent most of his youth. */
	while (true) {
	    $ndiff=$n - $osgb36->Northing; $ediff=$e - $osgb36->Easting;
	if (abs($ndiff)<0.5 && abs($ediff)<0.5) break;
	    $lat += $n2deg * $ndiff;
	    $lon += $n2deg * $ediff / cos(M_PI*$lat/180);
	    $osgb36->WGS2OSGB($lat,$lon);
	}
	return array( $lat, $lon );
}

It requires: this new version of transversemercator.php and helm_gb.php. — RHaworth 02:56, 15. Jun. 2009 (CEST)

For Kolossos: in OSGB2LL() RHaworth has replaced LatLon2OSGB36() by WGS2OSGB(). This function calls my HelmertDatumShift() befor it calls LatLon2OSGB36(). Question at RHaworth: where do your functions run - on the toolserver or elsewhere? --Telford 08:20, 15. Jun. 2009 (CEST)

Die Woche sieht es zeitlich etwas eng bei mir aus. --Kolossos 19:22, 15. Jun. 2009 (CEST)

Da ich seit rund vier Monaten an dieser Sache dran bin, fasse ich mich in Geduld. Schön ist jedenfalls, daß sich eine Lösung deutlich abzeichnet! --Telford 20:10, 15. Jun. 2009 (CEST)

Von RHaworth bekam ich heute Antwort und wurde auf http://meta.wikimedia.org/wiki/User:RHaworth/oscoor verwiesen. Wäre schön, wenn sich das mal einer anschauen könnte. --Kolossos 21:28, 22. Jun. 2009 (CEST)

Grundsätzlich wird das wohl funktionieren. Allerdings finde ich die Aufteilung der benötigten Funktionen auf die Klassen mapsources und transversemercator gelinde gesagt etwas merkwürdig: der datum shift hat nix mit Mercator zu tun und gehört daher dort auch nicht rein! Außerdem geht alles viel einfacher, wenn man den Aufruf der Helmert-Transformation gleich in mapsources macht. Kannst Du mir bitte mal mapsources.php zur Verfügung stellen (nur für den Fall, daß Rogers Version nicht auf dem neuesten Stand sein sollte)? --Telford 17:34, 23. Jun. 2009 (CEST)

Klar: http://toolserver.org/~kolossos/georef/mapsources-source.php --Kolossos 21:53, 23. Jun. 2009 (CEST)

Und bei http://toolserver.org/~kolossos/georef/geohack.zip alles zusammen. --Kolossos 22:00, 23. Jun. 2009 (CEST)

Danke für "alles zusammen"! Damit ist einiges von dem hinfällig, was ich weiter oben geschrieben habe. Derzeitiger Vorschlag unter http://meta.wikimedia.org/wiki/User_talk:RHaworth/oscoor. – Mir ist aufgefallen, daß der GeoHack ziemlich objektorientiert geschrieben worden ist. Da schwebt eine einzelne Funktion also etwas frei im Raum. Es wird vermutlich trotzdem funktionieren, aber evtl. sollte man HelmertDatumShift() als Funktion innerhalb der Klasse map_sources definieren. Dann kann auch das require_once() entfallen. --Telford 08:34, 24. Jun. 2009 (CEST)

Nachtrag: Falls oscoor.php auf dem Toolserver laufen soll, relativiert sich diese Aussage. Rogers Vorschlag ist, daß OSGB2LL() über ein Objekt der Klasse transversemercator indirekt meine Helmert-Transformation aufruft. Das geht natürlich nicht mehr, wenn diese Funktion nicht mehr zu dieser Klasse gehört. Kann man so lösen, daß OSGB2LL() die Helmert-Transformation direkt aufruft, aber dazu muß sie natürlich zur Verfügung stehen, was wieder für eine separate Datei und Verwendung von require() spricht. Aber egal wie man es macht: ich bin jedenfalls strikt dagegen, Kuddelmuddel in den Klassendefinitionen in Kauf zu nehmen, nur damit ein Hack wie oscoor() funktioniert. --Telford 16:02, 24. Jun. 2009 (CEST)

Auf der en wp gibt es neue Nachrichten. --Telford 19:42, 26. Jun. 2009 (CEST)

Pinnacle-Point-Mensch

Im Kopf des Artikel habe ich die Koordinaten der Fundstelle verdeckt vermerkt; ich habe die Anleitung hier leider nicht kapiert. --Gerbil 16:36, 7. Jun. 2009 (CEST)

Hab's umgesetzt. NNW 16:44, 7. Jun. 2009 (CEST)

Danke. --Gerbil 17:11, 7. Jun. 2009 (CEST)

Ähm, ich behaupte mal, der Breitengrad stimmt nicht. Die Koordinate liegt jetzt im Meer. Pinnacle-Point ist hier. --тнояsтеn ⇔ 17:21, 7. Jun. 2009 (CEST)

richtig behauptet... - ich hatte mich vertippt, statt 35 muss es 34 Grad S heißen. Danke für den Hinweis. --Gerbil 10:03, 8. Jun. 2009 (CEST)

Ist aber immer noch 500 Meter vor der Küste. Stammen die Koordinaten tatsächlich aus "Nature"? Dann bitte noch mal prüfen! Ich halte eine Verwechslung der Dimension für denkbar (Zahlenwerte als Grad und Dezimalminuten würden z.B. gut passen). --Telford 15:08, 8. Jun. 2009 (CEST)

Die Daten stehen so in Nature; ich habe den Hauptautor eben angeschrieben und frage nach, ob da ein Tippfehler drin ist. --Gerbil 15:29, 8. Jun. 2009 (CEST)

Korrektur nötig

Die Antwort von Prof. Curtis Marean lautet: "The lat/long that we quoted in the paper was the one on file with the antiquities authorities here, and was from the original survey in 1997 by (...). He used a poor gps unit, and as you have discovered (and we have as well), all his measurements are substantially off." (...) "I pulled a position for PP13B on the north wall and it is: SurveyCoordinates: SouthingSAGrid: -3787084.972; EastingSAGrid: -83922.05581; ElevationOrtho: 18.448."

Bitte entsprechend ändern. --Gerbil 17:06, 24. Jun. 2009 (CEST)

SAgrid -- visi-on 17:26, 24. Jun. 2009 (CEST)nicht weiterführend -- visi-on 18:10, 24. Jun. 2009 (CEST)

Hartbeesthoek 94, The New South Africa Datum from Google Cache -- visi-on 19:44, 24. Jun. 2009 (CEST)

Und noch ein Link zum Thema. Der erklärt nach meinem Verständnis aber auch nicht diese angebliche Lage 500 Meter südlich der Küste. Etwas besseres habe ich leider nicht finden können :-(( . --Telford 20:45, 24. Jun. 2009 (CEST)

Nur damit keine Missverständnisse aufkommen: die Koordinate bei Pinnacle-Point-Mensch (vor der Küste) ist die from the original survey in 1997. Eine neue Koordinate an Land soll nun SouthingSAGrid: -3787084.972; EastingSAGrid: -83922.05581 sein, diese müsste umgerechnet werden in WGS84. Telford, wenn du das auch sowieso so verstanden hast, vergiss meinen Beitrag. Hatte irgendwie das Gefühl, es wird von zwei verschiedenen Dingen ausgegangen hier. --тнояsтеn ⇔ 21:02, 24. Jun. 2009 (CEST)

Da ich persönlich angesprochen wurde, muß ich mich outen: ich habe leider nicht die geringste Ahnung, warum das hier schief läuft, und ebenso keinen Lösungsvorschlag. --Telford 21:57, 24. Jun. 2009 (CEST)

WEnn ich das richtig sehe sind X_LO=-3787084.972 und Y_LO=-83922.05581 im SAgrid (Gauss Conform Projection) die Werte bevor/nach Helmert. Da du ja die Iterations-Algorithmen impleniert hast sollte jetzt mit diesen Werten etwas brauchbares rauskommen. Koordinatennullpunkt ist 0°N, 25°E -- visi-on 23:09, 24. Jun. 2009 (CEST)

Die SAgrid Koordinaten basieren bereits auf WGS84 es muss nur noch auf geographische Koordinaten unmgerechnet werden-- visi-on 23:14, 24. Jun. 2009 (CEST)

Das ist jetzt wirklich stochern im Nebel. Wo hast Du die "Gauss Conform Projection" (was auch immer das sein mag) und diesen Koordinatennullpunkt gefunden? --Telford 07:02, 25. Jun. 2009 (CEST)

Es war gestern zu spät: «Here the equator will project as a straight line, at right angles to the central meridian (Lo.), but all other meridians and parallels will project as curved lines. The equator and the Lo. are the origins of the YLo and XLo axes of our plane rectangular co-ordinate system. The figure, above, shows the relationship between plane (Lo.) co-ordinates and geographical co-ordinates.In the South African plane co-ordinate system only the area within one degree of longitude on either side of the central meridian is projected. The width of each segment, often referred to as a belt, is thus two degrees of longitude and is referred to the central meridian of that belt.» Das ist eine Gauss-Krüger-Projektion mit 2°-Meridianstreifen. Beim LO-Meridian hab ich mich vertan es it der 23ste. Das nun umgerechnet ergibt (Irrtum vorbehalten): 34° 2′ 53,2″ S, 21° 40′ 41,4″ O-34.04810560762921.678173235413 Bitte nachrechnen -- visi-on 08:58, 25. Jun. 2009 (CEST)

Da ich nicht die geringste Ahnung habe wie Du das berechnet hast, kann ich das leider auch nicht nachrechnen. Das Ergebnis liegt jetzt allerdings rund 40 Kilometer landeinwärts und ist daher vermutlich falsch. --Telford 09:13, 25. Jun. 2009 (CEST)

Stimmt. Aber hier ist die Höhle auf dem Satelitenbild eingezeichnet. -- visi-on 10:18, 25. Jun. 2009 (CEST)

Pinnacle Point 2 = 13B? -- visi-on 10:29, 25. Jun. 2009 (CEST)

Tja, das überzeugt sogar mich: Identifizierung einwandfrei, Quellen im Artikel genannt – sehr schön! (Was mit den Koordinaten in Nature ist wissen wir zwar immer noch nicht, aber das braucht auch nicht unbedingt unser Problem zu sein.) --Telford 21:07, 25. Jun. 2009 (CEST)

170'000

Man kann fasst zugucken wie die Koordinaten rein kommen -- visi-on 02:22, 19. Jun. 2009 (CEST)

Tagebaurestlöcher

Ich habe heute bei der Durchsicht des Portals Bergbau eine hohe Anzahl von Tagebaurestlöchern gefunden, bei denen Lagewunsch gesetzt war. Da ich mich damit halbwegs auskenne, wollte ich die abarbeiten. Ohne mich jetzt hier zu tief reinzuarbeiten: auf den ersten, zweiten und dritten Blick sah die Infobox soweit okay aus. Koordinaten neubestimmen und einfügen brachte nichts. Also: wieso stehen die in der Kategorie Parameterfehler? Bitte mal am Bsp. Kulkwitzer See zeigen. TIA,-- Glückauf! Benutzer:Markscheider Disk 16:53, 23. Jun. 2009 (CEST)

Liegt an der Vorlage:Höhe in der Infobox. Bitte stattdessen den Parameter HÖHE-BEZUG verwenden. --Entlinkt 17:07, 23. Jun. 2009 (CEST)

[x]done.thx, -- Glückauf! Benutzer:Markscheider Disk 18:03, 23. Jun. 2009 (CEST)

Qualitätssicherung: Infoboxen mit Koordinaten

→Wikipedia:WikiProjekt Georeferenzierung/Qualitätssicherung: Infoboxen mit Koordinaten Wir haben jetzt zwar nur noch eine Koordinatenvorlage, aber bei den Infoboxen liegt noch manches im Argen. -- visi-on 14:36, 24. Jun. 2009 (CEST)

Gehört da dies auch dazu? Dieser Artikel (gibt viele davon, insbesonders bei Seen) ist unter der Kategorie:Parameterfehler eingeordnet, obwohl ich keinen Fehler sehen kann. –– Bwag @ 22:07, 28. Jun. 2009 (CEST)

nicht wirklich Zur konkreten Frage siehe diese Änderung. Habe für die Seen bereits eine Botanfrage gestellt. Lohnt händisch nicht. lg --Herzi Pinki 22:24, 28. Jun. 2009 (CEST)

Ah danke. Habe mich mit fehlenden Koordinaten beschäftigt und da kam mir auch die Parameterfehlermeldung unter und in meiner geistigen Umnachtung habe ich den Parameterfehler nur bei den Koordinaten gesucht. –– Bwag @ 22:36, 28. Jun. 2009 (CEST)

Parameterfehler

Gleich mal zwei Anfragen:

• Dögginger Tunnel: Wo ist hier der Parameterfehler? Hat es was mit den fehlenden Parametern Portal-elevation zu tun?
• Castle Lake (Siskiyou County, Kalifornien): Gibt es eine Möglichkeit, die bei der Höhe angegebene Referenz einzubinden, ohne einen Parameterfehler zu erhalten?

--тнояsтеn ⇔ 23:21, 28. Jun. 2009 (CEST)

• Es lag an der Vorlage:Infobox Tunnel und hatte was mit Portal-elevation zu tun (jetzt aber nicht mehr).
• direkte Antwort: nein. Aber gelegentlich lassen sich solche Referenzen in den Text verschieben, falls die Zahlwerte dort auch auftauchen, was hier nicht der Fall ist. Oder siehe analoges Problem bei den Flüssen, Lösungsvorschlag / diskussion hier.

--Herzi Pinki 23:55, 28. Jun. 2009 (CEST)

Danke schonmal. Das zweite Problem taucht öfter auf, man sollte eine Lösung – wie bei den Flüssen – auch für andere Objekte suchen (weitere Beispiele: Fischbach (Bad Schwalbach), Haidensee). --тнояsтеn ⇔ 00:30, 29. Jun. 2009 (CEST)

Infobox Tunnel

Noch was ist mir aufgefallen: Könnte man bei Tunneln eine der Portal-Koordinaten aus der Infobox auch rechts oben auf der Seite anzeigen? Oder ist das Vorgehen wie z. B. bei Grenztunnel Füssen richtig, indem die Vorlage Coordinate nochmals separat eingebunden wird? --тнояsтеn ⇔ 23:56, 28. Jun. 2009 (CEST)

→ Vorlage Diskussion:Infobox Tunnel#Artikel-Koordinaten läuft zu diesem Thema. -- visi-on 09:55, 2. Jul. 2009 (CEST)

Danke für den Link. --тнояsтеn ⇔ 10:34, 2. Jul. 2009 (CEST)

und bitte Senf abgeben, dass das mal noch zu einem Abschluss kommt ;-) -- visi-on 10:46, 2. Jul. 2009 (CEST)

region in Positionskarten

In den meisten Vorlage:Positionskarten fehlen noch die neu hinzugekommenen Parameter.

 <!-- Coordinates Koordinaten -->
|type       = <!-- Typ                                   →Vorlage:Coordinate#type -->
|pop        = <!-- Einwohner                             →Vorlage:Coordinate#pop -->
|elevation  = <!-- Höhe                                  →Vorlage:Coordinate#elevation -->
|dim        = <!-- Dimension                             →Vorlage:Coordinate#dim -->
|region     = <!-- ISO 3166-1/2 Code                     →Vorlage:Coordinate#EW -->
|name       = <!-- Name des Objekts                      →Vorlage:Coordinate#EW -->

Fehlende ISO-Codes werden nun hier gelistet. Bitte auch gleich die andern Parameter ergänzen und die "historische" Dreifaltigkeit

|lat_deg    = |lat_min= |lat_sec= |lat_dir= 
|lon_deg    = |lon_min= |lon_sec= |lon_dir= 

durch

|lat        =  <!-- Breitengrad in Dezimalwert oder D/M/S →Vorlage:Coordinate#NS -->
|long       =  <!-- Längengrad  in Dezimalwert oder D/M/S →Vorlage:Coordinate#EW -->

ersetzen. Dann kann man die Vorlage irgendwann mal abspecken. Artikel mit diesem veralteten aufruf finden sich hier.

Eventuell kann die Positionskarte auch durch Vorlage:Coordinate mit map-Option ersetzt werden. -- visi-on 17:53, 20. Jun. 2009 (CEST)

Letzteres ist generell zu empfehlen und zu prüfen und würde helfen, die meist vorhandene Redundanz zwischen Poskarte und Coordinate zu entfernen, Datenfehler miteingeschlossen. Als Beispiel siehe etwa den mexikanischen Ort Arriaga. --Herzi Pinki 20:36, 20. Jun. 2009 (CEST)

Würde ich auch unterstützen. Nur ist diese Zusammenführung wohl zu komplex für einen Bot (Position der Karte, evtl. Einbindung in einer Tabelle, Verwendung in Infoboxen, Vorlage:Coordinate zusätzlich vorhanden oder nicht, ...). --тнояsтеn ⇔ 00:18, 19. Jul. 2009 (CEST)

Höhenangaben in Stadtartikeln

Moin.
Ich hab gestern bei einer ganzen Reihe Städte, die in Kategorie:Parameterfehler auftauchten, den Dreiviertelstrich und andere "bis"-Angaben in den Höhenangaben durch ein einfaches Minus ersetzt. Dies ist wohl so nicht richtig.
Wie muss es denn richtig sein? Denn ich würde schon gerne die Parameterfehler-Kategorie abarbeiten, aber das macht keinen Sinn, wenn jemand hinter mir herstiefeln und alles nochmal machen muss.
Die Antwort bitte dann auch auf der entsprechenden Kategorie-Seite vermerken, damit keiner nach mir in dieselbe Falle tappt. Danke :-) --Lambdacore 08:52, 14. Apr. 2009 (CEST)

Hi Lambdacore, in den Städteartikeln dürfen gar keine "von-bis" Angaben bei der Höhe stehen. Die Fehler treten nicht mehr auf, wenn nur einzelne Zahlen in der Vorlage stehen. Diese Zahlen dürfen kein Tausendertrennzeichen haben und als Komma ist der "." (Punkt) zu nutzen. Hoffe das hilf dir weiter. Bei weiteren Fragen kannst dich auch gerne direkt auf meiner Disk melden. MfG Monsterxxl <°))))> 12:48, 14. Apr. 2009 (CEST)

Dann würde ich vorschlagen, das allgemein kundzutun, denn genau das hätte z.B. Spurzem gerne ;-) - Zumindest lese ich das so aus seinen Beiträgen auf meiner Diskussionsseite. Ich fürchte, das wird ein längeres Thema. Da ich mich dazu raushalten möchte, würde ich dich oder die "Hauptmitarbeiter" in WP:GEO bitten, sich der Sache anzunehmen und das klarzustellen. Wenn ich mir so anschaue, was so in der Kategorie:Parameterfehler alles an Orten mit von-bis Angaben steht, besteht da offensichtlich Klärungsbedarf ;-) --Lambdacore 14:04, 14. Apr. 2009 (CEST)

Also für die Infobox Ort in Deutschland ist das hier geregelt. Im großen und ganzen sind da noch Fehler aus der "Anfangszeit" der Vorlage:Coordinate. MfG Monsterxxl <°))))> 14:14, 14. Apr. 2009 (CEST)

Hallo… Möchte dazu auch gerne meinen Senf dazugeben. „Geregelt“ ist in der Infobox bzw. in der Doku dazu irgendwie leider gar nichts. Es nützt offenbar leider nichts, nur einen Wert zu erwarten oder zu erlauben, wenn sich ein Ort nun tatsächlich über einen gewissen Höhenbereich erstreckt. Ich meine, bei 10 bis 20 m wird das sicher niemanden interessieren, aber bei 100 Höhenmeter Unterschied ist das schon relevant, man schaue nur mal in die Gebirgsregionen. Ich sehe auf die Schnelle zwei Lösungsmöglichkeiten: Entweder die betreffenden Infoboxen ähnlich wie in der Vorlage:Infobox Gemeinde in Frankreich mit zwei Parameterwerten anpassen, oder temporär die Übergabe des Höhenwertes and die Koordinatenvorlage in den Infoboxen ausknipsen, bis vielleicht eine bessere Lösung gefunden ist. Okay, eine dritte Variante wäre, die Parameterfehler zu ignorieren, aber das kann es doch letztlich irgendwie nicht sein… Leider habe ich selbst keine Ahnung von der Vorlagenprogrammierung, sonst würde ich vielleicht selbst mit Hand anlegen. So bleibt mir nur, diesen Vorschlag zu unterbreiten…Gruß-- Spuki ^Seance 16:39, 14. Apr. 2009 (CEST)

Zu dem, was ich gern hätte und was nicht: Es war keine Rede davon, dass ich Tausendertrennzeichen in den Höhenangaben haben will, allerdings auch keinen Punkt anstelle eines Kommas. Was ich aber auf jeden Fall gern hätte, das sind Angaben „von … bis …“, wenn der Ort an einem Hang oder in hügeligem Gelände liegt, und zwar in der Kurzangabe mit korrektem Bis-Strich bzw. Halbgeviertstrich. Dass diese Schreibweise in der Infolbox bislang als Fehler erkannt aus ausgewiesen wird, wundert mich als Laien. Viele Grüße -- Lothar Spurzem 14:45, 14. Apr. 2009 (CEST)

Sollte kein Angriff auf dich sein. Wenn es so rübergekommen ist, tut es mir leid. Ich sehe auch, dass es jede Menge Orte oder Gemeinden gibt, die nicht auf einer planen Fläche liegen, sondern die "von bis" Höhenangaben haben. Nur wie bekommt man das mit der Formatvorlage unter einen Hut, die nur eine Höhenangabe mag? Ich meine, dass ich in einer anderen Infobox mal ein Feld "HöheBis" gesehen hätte, dass, wenn ausgefüllt, die Maximalhöhe enthält. Würde sowas die Lösung für das Problem sein?--Lambdacore 16:06, 14. Apr. 2009 (CEST)

Ich habe mich keineswegs angegriffen gefühlt. – Aber noch mal zum Thema: In der Wikipedia-Gemeinde gibt es bestimmt Programmierer, die das Problem lösen könnten. Die Frage ist nur: Wie kommt man an sie heran? -- Lothar Spurzem 16:10, 14. Apr. 2009 (CEST)

Das zu Progarmmieren sollte kein Problem darstellen. Das würd ich mir sogar noch selbst zutrauen. Aber die Frage ist ob es gewünscht ist... Ich denke dahingehend sollten wir auf den entsprechenden Vorlagenseiten weiterdiskutieren, um das für Orte/Städte/Geimeinden anzupassen.

Ganz allgemein gesehen ist eine Koordinate ein Punkt und hat deswegen auch nur eine Höhe. Von daher, dass Städte flächig ausgebreitet haben sie gibt es natürlich auch Höhenunterschiede. Die Koordinate soll aber nur einen Punkt (den ungefähren Stadtmittelpunkt gebe ich immer an) hervorheben. Und eben dieser hat nur eine Höhe und dafür reicht m.M.n auch ein gemmittelter oder zumindest angenährter Höhenwert aus. MfG Monsterxxl <°))))> 17:05, 14. Apr. 2009 (CEST)

Nun ist es aber so, dass die Infoboxen nicht diesen einen Punkt betreffen, sondern eben Städte, Gemeinden, Orte usw…. Insofern haben die Höhenbereichsangaben also durchaus einen Sinn, denke ich… Gruß-- Spuki ^Seance 17:18, 14. Apr. 2009 (CEST)

Wo wir wieder bei den Infoboxen wären. Natürlich gibt es diese Höhenunterschiede und damit sind auch Höhenbereisangaben möglich/(nötig). Aber das ist m.M.n. etwas was nicht in die Vorlage:Coordinate gehört. Da sie ja nur einen Punkt beschreibt. Wenn ein Ort an einem Berg liegt und daher große Höhenunterschiede aufweist sollte das in Infobox angegeben werden. z.B. mit diesen Parametern.

|BreitengradNord=
|LängengradNord=
|HöheNord=
|BreitengradSüd=
|LängengradSüd=
|HöheSüd=
|BreitengradOst=
|LängengradOst=
|HöheOst=
|BreitengradWest=
|LängengradWest=
|HöheWest=
|BreitengradMitte=
|LängengradMitte=
|HöheMitte=

Also das in Bezug auf die Höhe verschiedene Punkte (Stadtgrenzen und der Mittelpunkt) angegeben werden und diese dann auch in der Höhe referenziert werden. Ich denke aber das der dadurch entstehende Aufwand beim Referenzieren nicht wirklich gerechtfertig ist. Schon ganz simpel von dem Standpunkt her, das wir die WP ja nicht unbedingt zu einer Geographischen Datenbank machen wollen. Wenn jemand Interesse an diesen Daten hat lassen diese sich auch ganz einfach in Google Earth nachschauen. Hoffe ich war jetzt damit nicht zu direkt. MfG Monsterxxl <°))))> 10:32, 15. Apr. 2009 (CEST)

Das würde ja dann auf einen meiner Vorschläge weiter oben hinauslaufen, also die Höhenangaben in diesen Infoboxen gar nicht erst an die Koordinatenvorlage übergeben…? Gruß -- Spuki ^Seance 14:13, 15. Apr. 2009 (CEST)

Im Grunde ist dies das gleiche Problem wie etwas weiter oben die Koordinaten Stadteilartikel: wir haben ausgedehnte Objekte, aber derzeit nur 1 Zahlenangabe, was als unbefriedigend empfunden wird. Daraus ergeben sich drei Fragen: 1) Brauchen wir mehrere Koordinaten und Höhen, oder genügt eine Angabe? 2) Wenn man nur eine Angabe hat, soll die sich z.B. auf das Rathaus, den Marktplatz o.ä. beziehen (hat den Vorteil, daß klar identifizierbar) oder auf die gefühlte geometrische Mitte? c) Wollen wir nur besiedelte Flächen berücksichtigen, oder zählt für die Höhe auch ein bewaldeter Berg, der sich zufällig auf der Gemarkung befindet. Meine persönliche Auffassung: in der Infobox genügt eine Koordinatenangbe (Länge/Breite/Höhe); weitere Angaben dann im Fließtext. --Telford 14:45, 15. Apr. 2009 (CEST)

Anmerkung: Ich habe mal einen entsprechenden Warnhinweis in die Kategorie gepackt, da gestern wohl jemand die Vorkommen in den Orten B-D bearbeitet hat. Ich fürchte, das wird noch eine sucherei werden, die bearbeiteten wieder zu finden :-/ . --Lambdacore 15:37, 15. Apr. 2009 (CEST)

Ich versuche zusammenzufassen:

1. eine Höhenangabe (passend zur Koordinate), das ist die semantisch korrekte Höhe aus der Sicht der Koordinate. Höhenbereiche sind nicht zulässig und dürfen weder typographisch korrekt (Höhe wäre keine Zahl) noch mit Bindestrich (als mathematisches minus interpretiert, Ausdruck entsprechend ausgewertet) angegeben werden. Das ist die bei Vorlage:Infobox Gemeinde in Deutschland spezifizierte Lösung. Für die Vorlage:Infobox Ortsteil einer Gemeinde gilt wohl analog dasselbe.
2. Etwaige Bedürfnisse nach Höhenbereichsangaben in der Box sind über zusätzliche Parameter zu befriedigen. Hier könnte ein Bot die alten Bereiche retten, aber da die Höhe zur Koordinate ohnehin neu bestimmt werden muss (und nicht etwa als Mittel des Bereichs angenommen werden kann), muss jeder Artikel mit Höhenbereich angegriffen werden und dabei kann der Bereich in einen neuen Parameter gerettet werden. (dazu ist aber eine Erweiterung und Diskussion bei den entsprechenden Infoboxen notwendig).
   1. Dazu ist die von Vorlage:Infobox Gemeinde in Frankreich gewählte Parameterkonstellation mit drei Höhenangaben (min, mittlere, max) n.m.M. die günstigste, da dann der Halbgeviertstrich von der Box an zentraler Stelle erzeugt werden kann.
   2. Alternativ zur Angabe von komplizierten topografischen Strukturen in der Box kann deren Angabe immer auch im Text erfolgen...
3. Das Problem betrifft mehrere Infoboxen, u.a. Vorlage:Infobox Ort in Kasachstan, Vorlage:Infobox Ort in Russland, ... nur kommen dort weniger Bereiche vor, da Daten nicht so üppig verfügbar sind.
4. Eine Unterdrückung der Fehlermeldung Parameterfehler ist möglich, löst aber kein Problem, sondern lässt die falschen Daten weiterbestehen.
5. Komma und Tausenderpunkt sind generell als Eingabeformate nicht zulässig, da damit keine Zahl bzw. eine viel zu kleine Zahl im Sinne der Vorlagenmathematik interpretiert wird. Statt dessen sollte die Formatierung der Zahlen auch der Box überlassen werden.

Dem Vorschlag von Monsterxxl mit nunmehr 5 Koordinatenangaben kann ich wenig abgewinnen, ich hoffe, der war nicht ganz ernst gemeint. Außerdem würde er das Bereichsproblem nur lösen, wenn der höchste und der tiefste Punkt mit einem der geografischen Extrempunkte in den vier Himmelsrichtungen zusammenfallen würde. lg --Herzi Pinki 22:31, 15. Apr. 2009 (CEST)

Da kann ich als Laie nur ironisch fragen: Warum einfach, wenn's auch umständlich geht? Warum soll oder muss die Höhen(bereichs)angabe mit den Koordinaten gekoppelt sein, die – für jeden verständlich – nur einen bestimmten Punkt in einem Ort betreffen? Der Leser will in der Infobox unter anderem auf einen Blick sehen, ob die Stadt weitestgehend im Flachland liegt oder ob es Höhenunterschiede gibt. Die ganzen technischen und wissenschaftlichen Überlegungen, die oben angestellt sind, interessieren ihn nicht. -- Lothar Spurzem 22:48, 15. Apr. 2009 (CEST)

weil im Dreidimensionalen ein Punkt erst definiert ist wenn auch seine Höhe bekannt ist ;-) -- visi-on 23:32, 15. Apr. 2009 (CEST)

Ausgerechnet wenn es bergiger wird versagt aber eine Bereichangabe völlig und sagt nichts mehr über den Ort aus (zB. Zermatt über 3000m Differenz). Aus der Infobox möcht ich erfahren wo und auf welcher Höhe sich das Siedlungszentrum befindet, mehr nicht. -- visi-on 11:41, 16. Apr. 2009 (CEST)

Die Vorlage bis ist schon lange in meinem Benutzernamensraum (Benutzer:Visi-on/bis) vorbereitet. Es müsste sich nur mal einer bequemen die Höhenbereichsangabe bei Orten richtig zu definieren und in der Vorlage auch entsprechend dokumentieren. -- visi-on 23:32, 15. Apr. 2009 (CEST)

Ich denke, richtig definieren ist genau das, was wir als erstes tun sollten, und da sind natürlich auch die Laien gefragt. Auch wenn ich mich jetzt wiederhole: die Frage ist doch, was soll(en) die Höhenangabe(n) ausdrücken. Wenn das nicht klar ist, nützt eine Erweiterung der Vorlage auch nichts. Derzeit sind drei Modelle denkbar: 1) eine Angabe, z.B. a) das Rathaus, b) der gefühlte Mittelwert, c) der gefühlte Schwerpunkt; 2) zwei Angaben: Minimum und Maximum; 3) drei Angaben: Minimum, gefühlter Schwerpunkt und Maximum. Dabei sollte man sich auf besiedelte Gebiete beschränken, damit nicht z.B. das Matterhorn (weil zufällig auf der Gemarkung gelegen) mitzählt. Ich denke darüber hinaus, daß einzelne Häuser ebenfalls nicht zählen sollten, sondern nur Ortsteile mit einer gewissen Größe (die noch festzulegen wäre). Wenn dann klar ist, was wir wollen, kann man über die Programmierung sprechen. Eine Bemerkung zum Schluß: ein objektiv richtig gibt es leider nicht. Ich persönlich halte in der Infobox eine einzige Höhenangabe für den gefühlten Schwerpunkt für sinnvoll, kann aber problemlos mit jeder anderen klar definierten Lösung leben. --Telford 16:29, 16. Apr. 2009 (CEST)

Wahrscheinlich ist das Hauptproblem. dass zwischen Gemeinde (Hoheitsgebiet) und Ort nicht genügend differenziert wird. Nach dem Fusionitis besteht eine Gemeinde in der Regel aus Orten, die sich wiederum aus Ortsteilen (mit eigenen Zentren) zusammensetzen. Wenn man eine Gemeinde sodann als Netz solcher Knotenpunkte versteht treten Bereichsangaben bereits stark in den Hintergrund. Die Superlativen der Gemeinde erwartet wohl niemand in der Infobox. Nach der Definition kommt dann noch das Erhebungsproblem. Der Bebaute Wohnbereich (Abgrenzung zu Industrie und Gewerbezonen?) ist schneller ausgesprochen als klar umrissen. Es ist auch zu bedenken, dass nur vergleichbare Angaben nützlich sind. Da stehen uns dann bereits unterschiedliche nationale und subnationale Erhebungsrichtlinien im Weg. -- visi-on 17:25, 16. Apr. 2009 (CEST)

Völlig einverstanden, aber was ergibt sich daraus für unser weiteres Vorgehen? --Telford 17:33, 16. Apr. 2009 (CEST)

Hier erst mal Grundlagenarbeit :-) Ich sehe erstmal den Bedarf die Koordinaten Typen (→Vorlage:Coordinate#type/en:template:Coord#type:T) in zwei Klassen (landmark/landscape) zu scheiden. Unter Landmarken würden auch Orte fallen (Punkt mit Umfeld). Berlin hätte dann als Stadtstaat z.B type=adm1st/city. Für Landmarken (mit beschränkter Fläche) würde ich keine Bereiche zulassen (oder aber, wenn in den IBs zulässig arithmetisch mitteln). Für landscape müssten wir in jeglicher Beziehung Koordinatenbereiche definieren. Für Gemeinden (adm3rd gibt es bei uns in der de:WP noch nicht) wären das dann die Gemarkungsmin/-max Höhen. Aus obigem Statement ist mein Unwohlsein hierin leicht ersichtlich. Für type=state/country/adm1st/adm2nd haben wir (WP:GEO) uns bisher darum gedrückt ;-) -- visi-on 19:02, 16. Apr. 2009 (CEST)

Da es nun einige Zeit ruhig war - wie sieht es mit diesem Thema aus? Wird noch an einer anderen Stelle hierzu diskutiert? Wie gehts weiter? --Lambdacore 10:42, 24. Apr. 2009 (CEST)

die disk ist hier konzentriert. ich habe keine weiteren schauplätze gesehen. -- visi-on 13:00, 24. Apr. 2009 (CEST)

Mein Vorschlag ist es das Typenkonzept

• mit den anderen WPs abzugleichen
• zu überarbeiten
• mehrfachtypisierungen zulassen (zB.: adm1st/city)
• zu klassifizieren (Punktkoordinaten / "Flächen"-Koordinaten)
• für die Werteinterpretation zu nutzen

ohne Konsens werde ich aber in dieser Richtung nicht aktiv. -- visi-on 13:10, 24. Apr. 2009 (CEST)

In US-Ortsartikeln braucht man das jedenfalls nicht, da im Geographical Names Information System Höhe und Geokoordinaten von Orten und anderen Geoobjekten hinterlegt sind. --Matthiasb 15:36, 5. Mai 2009 (CEST)

*nochmal vorsichtig das Thema anstups* Wie sieht es aus? Wer fühlt sich berufen, sich daum zu kümmern? --Lambdacore 13:02, 29. Jun. 2009 (CEST)

*Anstups 2* Wird ein Konsens nicht gewünscht oder woran liegts? --тнояsтеn ⇔ 13:14, 19. Jul. 2009 (CEST)

frag ich mich auch ;-) -- visi-on 17:50, 3. Aug. 2009 (CEST)

Wie soll das hier nun weitergehen? Anlass der Frage ist die Vorlage:Infobox Ortsgliederung. Diese Infobox hat einen Parameter HÖHE, dessen Wert immer an die Koordinatenvorlage weitergegeben wird (also kann damit aus Sicht der Koordinatenvorlage nur die Höhe am Schnittpunkt gemeint sein). Außerdem hat sie einen Parameter HÖHE-BIS, der, wenn nicht leer, zusammen mit HÖHE einen Höhenbereich formatiert (also muss mit HÖHE aus Sicht des Lesers das Höhenminimum gemeint sein, wenn HÖHE-BIS nicht leer ist). Diese Parameterumdeutung kann ja wohl nicht richtig sein. Wie soll das (halbwegs kurzfristig) gelöst werden: HÖHE-BIS abschaffen oder HÖHE-VON neu einführen? Höhenbereiche werden übrigens doch relativ häufig genutzt (exemplarisch: Kategorie:Stadtgliederung (Dresden)). --Entlinkt 00:06, 9. Sep. 2009 (CEST)