Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv/2009-II

message: und dann noch nicht mal NPOV, heieiei! -- visi-on 19:20, 1. Apr. 2009 (CEST)
thread_title:  1. April? 

message: 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)
replies: text: Was auch immer war es geht wieder. -- visi-on 23:34, 1. Apr. 2009 (CEST)
thread_title:  Tool Get Coordinate 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Koordinaten Stadtteilartikel 

message: 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)
replies: text: Habs mal geändert. Die Koordinaten gehören in die Infobox, wenn eine da ist. Gruß --тнояsтеn ⇔ 22:50, 9. Apr. 2009 (CEST)
replies: text: 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)
replies: text: 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)
thread_title:  [[Hagavatn]] 

message: 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)
replies: text: Erledigt. -- Spischot 11:31, 14. Apr. 2009 (CEST)
thread_title:  Text in Positionskarte 

message: Hallo. Ich wollte mal nachfragen, was hier so von einer Anpassung der Georeferenzierung gehalten wird. Meine Kritikpunkte sind:
# Starke Zerteilung in einen Vorlagenbaum Nachteile: beansprucht Serverlast, erschwert den Durchblick
# 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)
thread_title:  Anpassung des Projekts 

message: 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)
replies: text: Die Vorlage:Infobox Fluss nimmt dir diesen Entscheid ab (Artikelkoordinate ist die Mündung) -- visi-on 08:45, 2. Apr. 2009 (CEST)
replies: text: Alles klar, dann bau ich die ein. Danke--Celph titled 08:49, 2. Apr. 2009 (CEST)
replies: text: ü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)

text: Probier mal den Vorlagenmeister aus. -- visi-on 16:19, 24. Apr. 2009 (CEST)
thread_title:  Flüsse / waterbodies 

message: 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)
replies: text: 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)
replies: text: Super, danke. War doch etwas spät gestern ;-) --тнояsтеn ⇔ 12:23, 23. Mai 2009 (CEST)
thread_title:  Infobox Berg 

message: Die WP-Buchfunktion wird gestört, falls bereits Geodaten im Artikel hinterlegt sind. Zumeist wird lediglich " (http://stable.toolserver.org/geohack/geohack.php?pagename=XXX&language=de¶ms=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)
replies: text: Kannst du noch den zu druckenden Artikel nennen, dass es nachvollziehbar ist? -- visi-on 18:05, 28. Mai 2009 (CEST)
replies: text: 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)
replies: text: Da war nur mal ein überflüssiger Lagewunsch ... -- visi-on 18:39, 28. Mai 2009 (CEST)
replies: text: Das ist korrekt, der wurde jedoch in der Form  eingetragen. Ich schätze, dass doppelte Vorlagen das eigentliche Problem sind. Wie siehst du das? -- Mark Wolf 11:53, 2. Jun. 2009 (CEST)
replies: text: Hatte schon Artikel mit mehreren Koordinaten als PDF erstellt und keine Fehldarstellungen bemerkt. -- visi-on 12:17, 2. Jun. 2009 (CEST)
replies: text: Darauf kann ich mir wirklich keinen Reim bilden... -- Mark Wolf 16:16, 2. Jun. 2009 (CEST)
thread_title:  Probleme bei PDF-Erstellung 

message: Beim Artikel Theodor-Storm-Schule Husum hab ich die Koordinaten gesetzt. Wollte dann die Vorlage  oder  rausnehmen; hab aber nichts gefunden. Könnt ihr mal kucken? --JLeng 20:59, 3. Jun. 2009 (CEST)
replies: text: Der Lagewunsch kam von der Infobox. Da müssen die Koordinaten eingetragen werden. NNW 21:03, 3. Jun. 2009 (CEST)
replies: text: Mann, ging das fix. Ich war noch gar nicht fertig mit schreiben. Danke! --JLeng 21:06, 3. Jun. 2009 (CEST)
thread_title:  Koordinaten fehlen (nicht). 

message: Siehe http://commons.wikimedia.org/wiki/Template:Coordinate bzw Commons:Deletion requests/Template:Coordinate
: FYI, GuidoD 00:34, 9. Jun. 2009 (CEST)
thread_title:  template:coordinate löschantrag 

message: 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)
replies: text: Da war noch ne Koordinate im Fließtext. Habs gefixt. --тнояsтеn ⇔ 15:49, 14. Jun. 2009 (CEST)
replies: text: Ah ja, danke. Habe ich echt übersehen. --Sebastian Hornbostel 21:52, 14. Jun. 2009 (CEST)
thread_title:  Koordinaten doppelt 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: Wenn sie sich beim vom Ross fallen nicht zu sehr weh tun ... ;-) -- visi-on 09:09, 4. Jun. 2009 (CEST)
replies: text: Habe eben noch ein paar Schönheitskorrekturen angebracht. --Telford 18:07, 23. Jun. 2009 (CEST)

text: 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)
replies: text: Die Woche sieht es zeitlich etwas eng bei mir aus. --Kolossos 19:22, 15. Jun. 2009 (CEST)
replies: text: 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)

text: 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)
replies: text: Klar: http://toolserver.org/~kolossos/georef/mapsources-source.php --Kolossos 21:53, 23. Jun. 2009 (CEST)

text: Und bei http://toolserver.org/~kolossos/georef/geohack.zip alles zusammen. --Kolossos 22:00, 23. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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)
thread_title:  Eine Implementierung der Helmert-Transformation für den GeoHack 

message: 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)
replies: text: 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)
replies: text: Die Woche sieht es zeitlich etwas eng bei mir aus. --Kolossos 19:22, 15. Jun. 2009 (CEST)
replies: text: 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)

text: 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)
replies: text: Klar: http://toolserver.org/~kolossos/georef/mapsources-source.php --Kolossos 21:53, 23. Jun. 2009 (CEST)

text: Und bei http://toolserver.org/~kolossos/georef/geohack.zip alles zusammen. --Kolossos 22:00, 23. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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)
thread_title:  Using the Helmert transform 

message: 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)
replies: text: Hab's umgesetzt. NNW 16:44, 7. Jun. 2009 (CEST)
replies: text: Danke. --Gerbil 17:11, 7. Jun. 2009 (CEST)
replies: text: Ä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)
replies: text: 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)
replies: text: 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)

text: 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)

text: SAgrid -- visi-on 17:26, 24. Jun. 2009 (CEST)

text: Hartbeesthoek 94, The New South Africa Datum from Google Cache -- visi-on 19:44, 24. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: WEnn ich das richtig sehe sind XLO=-3787084.972 und YLO=-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)

text: Die SAgrid Koordinaten basieren bereits auf WGS84 es muss nur noch auf geographische Koordinaten unmgerechnet werden-- visi-on 23:14, 24. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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):  Bitte nachrechnen -- visi-on 08:58, 25. Jun. 2009 (CEST)
replies: text: 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)
replies: text: Stimmt. Aber hier ist die Höhle auf dem Satelitenbild eingezeichnet. -- visi-on 10:18, 25. Jun. 2009 (CEST)

text: Pinnacle Point 2 = 13B? -- visi-on 10:29, 25. Jun. 2009 (CEST)
replies: text: 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)
thread_title:  [[Pinnacle-Point-Mensch]] 

message: 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)
replies: text: SAgrid -- visi-on 17:26, 24. Jun. 2009 (CEST)

text: Hartbeesthoek 94, The New South Africa Datum from Google Cache -- visi-on 19:44, 24. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: WEnn ich das richtig sehe sind XLO=-3787084.972 und YLO=-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)

text: Die SAgrid Koordinaten basieren bereits auf WGS84 es muss nur noch auf geographische Koordinaten unmgerechnet werden-- visi-on 23:14, 24. Jun. 2009 (CEST)
replies: text: 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)
replies: text: 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):  Bitte nachrechnen -- visi-on 08:58, 25. Jun. 2009 (CEST)
replies: text: 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)
replies: text: Stimmt. Aber hier ist die Höhle auf dem Satelitenbild eingezeichnet. -- visi-on 10:18, 25. Jun. 2009 (CEST)

text: Pinnacle Point 2 = 13B? -- visi-on 10:29, 25. Jun. 2009 (CEST)
replies: text: 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)
thread_title:  Korrektur nötig 

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

message: 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)
replies: text: Liegt an der Vorlage:Höhe in der Infobox. Bitte stattdessen den Parameter HÖHE-BEZUG verwenden. --Entlinkt 17:07, 23. Jun. 2009 (CEST)
replies: text: [x]done.thx, -- Glückauf! Benutzer:Markscheider Disk 18:03, 23. Jun. 2009 (CEST)
thread_title:  [[Tagebaurestsee|Tagebaurestlöcher]] 

message: →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)
replies: text: 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)
replies: text:  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)
replies: text: 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)
thread_title:  Qualitätssicherung: Infoboxen mit Koordinaten 

message: 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)
replies: text: 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)
thread_title:  Parameterfehler 

message: 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)
replies: text: → Vorlage Diskussion:Infobox Tunnel#Artikel-Koordinaten läuft zu diesem Thema. -- visi-on 09:55, 2. Jul. 2009 (CEST)
replies: text: Danke für den Link. --тнояsтеn ⇔ 10:34, 2. Jul. 2009 (CEST)
replies: text: und bitte Senf abgeben, dass das mal noch zu einem Abschluss kommt ;-) -- visi-on 10:46, 2. Jul. 2009 (CEST)
thread_title:  Infobox Tunnel 

message: In den meisten Vorlage:Positionskarten fehlen noch die neu hinzugekommenen Parameter.
  
 |type       = 
 |pop        = 
 |elevation  = 
 |dim        = 
 |region     = 
 |name       = 
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        =  
 |long       =  
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)
replies: text: 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)
replies: text: 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)
thread_title:  region in Positionskarten