Wikipedia Diskussion:WikiProjekt Georeferenzierung/Archiv1

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/Archiv1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiProjekt_Georeferenzierung/Archiv1#Thema_1

Fragen und Antworten zur "type"-Angabe

Vorgehen in besonderen Fällen

Es gibt ein paar Fälle, bei denen ich es wichtig fände, daß wir da einheitlich und überlegt vorgehen. Dazu würde mich Eure Meinung interessieren, auf welche Weise diese am besten gelöst werden könnten:

Welche Geokoordinate gibt man an bei

• einem linearen Objekt (z.B. Schönhauser Allee oder Isar) - die Mitte, die Endpunkte, eine Koordinatenschaar...?
• einem großen flächigen Objekt (z.B. Berlin, Binnenalster - die Mitte, mehrere begrenzende Koordinaten, die Mitte und einen ungefähren Radius...?
• verteilten Objekten (z.B. Staatsbibliothek_zu_Berlin mit zwei Standorten) - beide Koordinaten, welche werden angezeigt, wie löst man das mit der Vorlage?

Gruß Sansculotte - ? 02:11, 12. Mär 2005 (CET)

Für größere Städte würde ich entweder die Koordinaten des zentralen Platzes oder des Haupt-Verwaltungsgebäudes angeben. Bei Berlin wäre das z.B. Siegessäule, Brandenburger Tor oder noch besser das Rote Rathaus. --BLueFiSH ?! 18:03, 12. Mär 2005 (CET)

Von welchem Punkt gehen denn Navigationssysteme aus? --ST ○ 18:06, 12. Mär 2005 (CET)

das soll mal ein Fachmensch aufklären, denn es gibt pro Ort wohl genau einen Punkt, der als Referenz zählt - in Berlin ist der soweit ich weiß am Brandenburger Tor. Meistens ist es am Rathaus oder ähnlich -- Schusch 21:20, 12. Mär 2005 (CET)

Das Vorgehen bei flächigen Objekten ist mir auch gerade aufgefallen. Ich denke, hier sollte man auch an die beabsichtigte Verwendung denken. Wenn man Augmented Maps hat, in der bestimmte "Sehenswuerdigkeiten" mit Punkten markiert sind, dann sind Möglichkeiten wie "zentraler Bezugspunkt" eher kontraproduktiv. Da koennen dann voellig unsinnige "Meilensteine" viel groesserer Objekte in der Zoomsicht auftauchen - Brandenburger Tor belegt mit "hier ist Berlin". Oder irgendwo in Dtld "hier ist Deutschland". Nicht schön. Noch dazu sind viele Null-Meilensteine eines Transportnetzes beim besten Willen nicht mittig in einer Stadt. Dass koennte dann wieder zu Diskussion fuehren, wo man die zentrale Geokoordinate des Flaechenobjekts nun liegt.

Haette man ein bestimmtes Anwendungsmodell im Kopf, koennte man eine Loesung darauf anpassen. Bei Punktmarkierung in Kartenmaterial etwa eine Radiusangaben, die die Punktauszeichnung (als Ring) beeinflusst, und auch anderswo als Genauigkeitsangabe interpertiert werden kann, wo ein anderer "Geokoordinierer" eine Markierung haette setzen koennen, die trotzdem identisch fuer das eigentlichen Bezugsobjekt sind. (es gibt durchaus mehrere Staedte Berlin, aber nicht in direkter Umgebung des Landes Berlin). Guidod 11:35, 13. Mär 2005 (CET)

Sehe ich ähnlich, die undifferenzierte Kombination von 'Gebäudegeolinks' und 'Stadtgeolinks' entwertet beide gegenseitig. Der Ersteller der Spezialseite hat aber ein paar Parameter vorgesehen, die an die Spezialseite weitergegeben werden können und auch zur Unterscheidung herangezogen werden können. Wenn man eine Geokoordinate, die die gesamte Stadt umfaßt mit 'city' kennzeichnet, sollte eine spätere Unterscheidung bei der Nutzung problemlos möglich sein. Wie diese Parameter aber genau in die Vorlage eingebunden werden, ist mir nach der Lektüre der diversen Seiten noch unklar... -- Sansculotte - ? 18:12, 13. Mär 2005 (CET)

Über einen Querlink wurde auf en:London_Heathrow_Airport als Beispielangabe verweisen. Guidod 18:39, 13. Mär 2005 (CET)

Prima, danke. Das heißt, für Berlin wäre die entsprechende Geokoordinate dann

{{Geokoordinate|52_30_58_N_13_22_38_E_type:city|52° 30' 58" N 13° 22' 38" O}}

wobei mir das hier besser gefallen würde, aber leider nicht funktioniert, wenn der dritte Parameter leer bleibt:

{{Geokoordinate|52_30_58_N_13_22_38_E|52° 30' 58" N 13° 22' 38" O|city}}

Wichtig fände ich, daß der Katalog der Typen kurz und abgeschlossen bleibt, sonst gibts da bald dasselbe Chaos wie bei den Kategorien... -- Sansculotte - ? 18:56, 13. Mär 2005 (CET)

Das wird nicht einfach, ich werd heut abend mal auf meta:Geographical_data#City coordinates - non-US schauen, deren datasheet [[1]] scheint sich bewaehrt zu haben, und enthaelt neben "feature classification" angaben auch nachfolgend die administrativen codes sowie "dimension". Eigentlich wollte ich da mal draufschauen, wegen des vorstehenden "genauigkeits" abschnitts. Hast du das schonmal gemacht? Guidod 19:12, 13. Mär 2005 (CET)

wobei mir gerade einfaellt - dieser "type:" fuehrt wahrscheinlich auf augmented maps zur einzeichung der punktposition mit einem anderen symbol, womit sich auch im zomm wieder halbwegs eine verstaendlichkeit einstellt. Fehlende piktogramme kann man warscheinlich viel spaeter durch eine datenbanksuche nach dem "type:" herausfinden, und falsche notfalls spaeter umsetzen. Insofern, sollten wir kurzerhand ueberall an geo koordinaten einen "type:" ranschreiben, und man darf sich erstmal was ausdenken, wobei in dem allermeisten faellen der begriff eh klar sein duerfte. Zum teil ueberlappt das ja auch mit unseren kategorien. Guidod 19:20, 13. Mär 2005 (CET)

Also, wenn ich mal gucke, was es da für Type-Definitionen gibt, dann sind eigentlich alle ok und imo ausreichend:

von der Spezialseite unterstützte Parameter	GeoNet Names Server (GNS) Feature Classification
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates#type:T	http://earth-info.nga.mil/gns/html/gis_contryfiles.html
country (e.g. "type:country") state (Where applicable) adm1st (Administrative unit of country, 1st level (province, county)) adm2nd (Administrative unit of country, 2nd level) city(pop) (City, with specified population. Commas will be ignored in pop. There should be no blanks.) city (City, unspecified population. Not recommended.) airport mountain isle landmark (Cultural landmark, building of special interest, tourist attraction and other points of interest.)	A = Administrative region; P = Populated place; V = Vegetation; L = Locality or area; U = Undersea; R = Streets, highways, roads, or railroad; T = Hypsographic; H = Hydrographic; S = Spot feature.

--Sansculotte - ? 21:24, 13. Mär 2005 (CET)

Gilt das jetzt als eingeführt oder noch nicht? Noch fällt die Korrektur nicht so schwer, so viele Inseln hab ich noch nicht eingetragen. --BLueFiSH ?! 22:02, 13. Mär 2005 (CET)

'Offiziell' sind die ganzen Geokoordinaten noch nicht... sagen wir mal so, die Spezialseite unterstützt die Parameter in der linken Spalte, es spräche wohl nichts dagegen, sie einfach zukünftig zu verwenden... Vielleicht hat noch jemand eine Meinung dazu? Sansculotte - ? 22:05, 13. Mär 2005 (CET)

Unterstuetzt sie das wirklich? Mir will scheinen, dass sie es derzeit ignoriert. Diese adm1/adm2 passen auch herzlich wenig auf Stadtbezirke/Ortsteile, da ist die unterscheidung adminstritiv/populated place schon sinnvoller. Guidod 23:31, 13. Mär 2005 (CET)

Eines ist mir noch eingefallen: Wenn man die Koordinaten beispielsweise während einer Städtereise nutzen will, dann nutzt einem die Mitte eines Parks gar nichts, wenn man den Eingang nicht findet. Beispielsweise könnte ich mir bei Herrenhäuser Gärten daher vorstellen, dass man als Bezugspunkt den Eingang nimmt. Schwierig wird es natürlich, wenn es mehrere Eingänge gibt. Dann muss man vermutlich wieder die Mitte verwenden. Stern !? 01:19, 14. Mär 2005 (CET)

Also, die Spezialseite kann die type-Parameter wohl weitergeben, tut es aber noch nicht. Im Endeffekt dienen sie dazu, in einer Kartendarstellung das richtige Symbol anzuzeigen, sowie bei Anwendungen bestimmte Typen ausblenden zu können. Weder die erste noch die zweite Liste halte ich für wirklich befriedigend, deshalb hier mein Vorschlag:

• Verwaltungseinheit (evtl. mit Angabe Radius oder Fläche) (z.B. Staat, Bundesland, Landkreis)
• Ort (evtl. mit Angabe Radius oder Fläche) (z.B. Städte, Dörfer)
• Straße
• Bereich (evtl. mit Angabe Radius oder Fläche) (z.B. Park, Friedhof, Flughafen)
• Punkt (z.B. kulturelle Einrichtung, besondere Gebäude, Touristenattraktionen und andere Points of Interest)

• Insel (evtl. mit Angabe Radius oder Fläche)
• Berg (evtl. mit Angabe Radius Fläche, Höhe)
• Gewässer (evtl. mit Angabe Radius, Fläche, Länge)

Diese Typ-Angabe soll nicht die Kategorien ersetzen und deshalb auch bei möglichst wenigen, groben Typen bleiben. Sansculotte - ? 04:22, 15. Mär 2005 (CET)

Type-Definition

Können wir uns mal darauf verständigen welche Types für was zu verwenden sind? es macht kein Sinn, wenn die einen Personen z.B. "PPLX" verwenden und andere dagegen "city". Ich möchte jetzt bitte mal Klarheit welche Types (zumindest momentan) verwendet werden sollen. Oder ist das Motto "besser irgendein Type, als kein Type" die vorherrschende Meinung? --BLueFiSH ?! 16:28, 1. Apr 2005 (CEST)

ich bin durchaus fuer letzteres, wenn denn der typ exakt ist - den kann man dann eindeutig in eine andere skala abbilden, die von einem geo server zur visualisierung genutzt wird. Deshalb mal lieber nicht "irgendein" typ, sonder "irgendein passender" typ. Dass kann durchaus auch die uebliche deutsche bezeichnung sein. Speziell zu PPLX sein darauf hingewiesen, dass ich hier den typ aus dem GNS uebernommen habe, Feld DSG. Die grobe Klassifizierung des Feldes FC der GNS hatten wir oben schon mal angesprochen, was durch DSG aber nochmal unterteilt wird, wie ich spaeter erfuhr (Airport ist im DSG ausgewiesen, nicht im FC).

.. Grundsaetzlich gibt es zwei wege, (a) ich benutze ein lokales tool, um den GEOnet eintrag auf etwas grobere Skala umzusetzen, oder (b) ich schiebe den GEOnet eintrag auf den server, und das geo.wiki bildet es auf den typ ab, der von einem kartenserver genutzt wird. Bei der uebergabe an dritte server kann es zu ungenauigkeit aufgrund ueberlappender dimensionsraeume kommen, der bei einer kleinteiligeren urangabe des typs weniger auftritt. (dimensionsdivergenz ist ein typisches problem bei der integration von datenbanken). Daher habe ich mich aufgerafft, die GEOnet DSG direkt zu uebernehmen unter annahme, die abbildung auf den geo-wiki server (derzeit extern) zu legen.

.. Anzumerken ist weiterhin, dass wir das typische problem von standardisierung haben - beschraenkt man zu frueh, und merkt in der spaeteren anwendung, dass es nicht passt, dann muss man eintraege nochmal anschauen und anpassen. Erfahrung mit anwendung bekommt man jedoch erst, wenn man einen grundstock an eintraegen mit geo refs hat, um eben zu wissen, ob es passt oder was bestens passen wuerde. Ich hab in den letzten tage einige (> 100) eintraege mit den GEOnet refs versehen (Berliner Raum), sodass wir einen grundstock fuer das voranbringen des geo ref support haben.

.. Zusammengefasst - ich plaediere fuer "irgendeinen exakt passenden" typ (der typ wird erzeit ja eh nicht ausgewertet), und kuemmern uns um abbildungen spaeter. Eine Tabelle DSG zu FC (aehnlich tabelle weiter oben) ist leicht zu liefern (einzelne select-query). Guidod 17:11, 1. Apr 2005 (CEST)

Typen?

Im Lech-Wałęsa-Flughafen Danzig wurde die Vorlage heute ergäntz und sieht jetzt so aus: {{Geokoordinate|54°_22_N_18_27_E_type:airport|54° 22′ n. B. 18° 27′ ö. L.}} ... was bringt das und es sollte ggf. ein hinweis auf die hautpseite! . inkl. was für typen es gibt ...Sicherlich ^Post 10:21, 30. Jun 2005 (CEST)

der "type" dient der umgekehrten visualisierung - man hat eine karte, und laesst sich punkte anzeigen, zu denen es artikel gibt (statt in einem artikel auf die koordinate zu druecken, und eine karte zu bekommen). Was genau type macht, ist nicht raus, es gab dazu schonmal laengere diskussionen oben - hauptsache, man hat ueberhaupt einen type, zu dem wir uns spaeter ne clevere visualisierung ueberlegen. Im moment braucht es erstmal mehr artikel, die georeferenziert werden, damit sich der antrieb einstellt, ueberhaupt ueber eine geo-karte navigieren zu wollen - wenn man damit dann mal anfaengt, werden wir noch frueh genug herausbekommen, wie man die darstellung anpasst. Denn nunja, grundsaetzlich kann man ja auch die frage stellen, wozu ueberhaupt im geo-tag einen "type" angeben, wenn doch die artikel selbst schon eine kategorie haben. Da aber artikel mehrere kats existieren, die formell gleichrangig sind, waere es schon schoen, eine form herausheben, der zukuenftig in einer karte erscheint. Was fast auch beantwortet, was man so in den type reinschreiben sollte oder kann. GuidoD 19:06, 30. Jun 2005 (CEST)

hmm ich denke um das type wird man dann nicht herumkommen; zumindest wenn man Koordinate verwendet und nicht Geokoordinate (und beides in einem artikel find ich wertfrei) weil ja auch mehrere Koordinaten im Artikel genannt sein können!?! ... nur sollte man dann möglichst fix überlegen wie die types heißen sollen; denn ein ort mit 70.000 einwohnern; type:city oder type:town ? ...Sicherlich ^Post 2. Jul 2005 08:57 (CEST)

Wo hast du den "type:town" her? Bisher habe ich immer nur "type:city" gelesen für alle Orte ob Metropole oder Dorf. Durch die Einwohneranzahl lässt sich dann ja auch problemlos die entsprechende Einblendung machen. Also je näher man an die Erde ranzoomt, umso mehr bekommt man die kleineren Orte zu sehen. Bei dem "type:mountain" habe ich mir auch überlegt, das man dort genauso die Höhe über NN eingeben könnt, aber das dann als nicht sinnvoll angesehen, da ja im Flachenland schon ein 300m Berg was ist, wogegen man im Hochgebirge diesen weglassen würde. Beim "type:waterbodies" ist mir nix besseres eingefallen. Ich hab diesen neuen Typ auch auf der englischen Projektseite mal vorgeschlagen. Laut LEO ist das die Übersetzung von "Gewässer" vielleicht reicht aber auch nur "type:water" für alles was mit Wasser zu tun hat (Quelle, Fluß, Kanal, Wasserfall ...) -- sk 2. Jul 2005 10:06 (CEST)

wo habe ich die typen her? ... na wenn keine liste gibt habe ich sie mir selbst ausgedacht ;) ... das zeigt wohl, dass hier ein wenig klärungsbedarf ist; die bevölkerung kann man sicher im artikel finden; aber meist auch das Gründungsjahr usw. .. die Frage ist wie gut ist es zum einen maschinell auslesbar und zum anderen wie können die infos verknüpft werden ... ich habe davon keine ahnung ...Sicherlich ^Post 2. Jul 2005 11:00 (CEST)

Typen stehen z.B. weiter oben in der Tabelle. Die Werte bei "von der Spezialseite unterstützte Parameter" sind schon ganz in Ordnung. Mit type:isle liegt man bei Inseln ziemlich gut, für Sehenswürdigkeiten nehm ich type:landmark und type:city wurde ja schon erwähnt. --BLueFiSH ?! 2. Jul 2005 14:27 (CEST)

ah .. genau den hinweis habe ich am anfang gesucht ;) ...sk hat´s ja jetzt auch per überschrift deutlicher gemacht .. thx a lot .. (hmm und wo hatte ich jetzt das town verwendet .. na toll ;) ) ...Sicherlich ^Post 2. Jul 2005 18:28 (CEST)

Länder

Wie sollen Geokoordinaten für Länder und andere geographische Objekte, die sich nicht einfach auf einen Punkt reduzieren lassen, angegeben werden? --zeno 2. Jul 2005 10:09 (CEST)

Länder immer in der geographischen Mitte mit einer Koordinate versehen und dann den "type:country" vergeben. Flächenhaften Objekten immer den Mittelpunkt nehmen. Bei Punkthaften logischerweise den Standort un dbei linienhaften könnte man auch die bei der Hälfte der Streckenlänge auch die Mittelachse eine Koordinate setzen. -- sk 2. Jul 2005 10:45 (CEST)

Type-Liste

Wie ich oben unter #Type-Definition und #Typen? bereits, wuerde ich gerne wissen, welche types derzeit verwendet werden. Dazu braucht es eine SQL-abfrage (und ich hab die entsprechenden rechte nicht). Anschliessend mag man sich ueberlegen, was man da wie visualisieren will. Wieviele geokoo in artikeln gibt es bisher ueberhaupt? Und in welchen kategorien liegen diese artikel? Wieviele haben denn noch keinen type, und in welche kategorien finden sich diese hauptsaechlich? Fragen ueber fragen. GuidoD 3. Jul 2005 09:56 (CEST)

Hallo Guidod, derzeit haben ca. 2700 Artikel schon Koordinaten im richtigen Format (also verlinkt) und unzählige Stadtartikel haben schon Koordinateneinträge, müssen aber noch verlinkt werden. Die große Mehrheit der georeferenzierten Artikel (ca. 2000) insbesondere die verlinkten Städte haben keinen Typ zugewiesen bekommen. Welche Typen genutzt werden sollen, steht jetzt auch auf der Projektseite unter Typen. Also die gleichen wie im englischen Projekt. Hinzugefügt wurde nur der Typ "waterbodies", da der zum herausfiltern von Gewässern etc. sich gut eignet, welche sehr häufig vorkommen. Wenn du selber mal eine SQL-Abfrage machen möchtest, dann brauchst du keine besonderen Rechte. Unter http://www.wikisign.org/ kannst du problemlos deine eigene SQL-Abfrage starten. Deshalb habe ich den SQL-Befehl mal auf die Projektseite gesetzt. Derzeit gibt es rund um Berlin noch ein haufen unverständlicher Typen, "PPL" oder "LK" und soweiter. Diese sollten in nächster Zeit durch die Standardtypen ersetzt werden, was die Lesbarkeit und Verständlichkeit erhöht. Für neue Typen sehe ich derzeit noch keinen Bedarf, und wir können erstmal eine Zerfasserung durch zu viele Typen vermeiden. In Zukunft würde ich mir aber bei den Landmarken noch einiges Wünschen, weil dort derzeit der ganze Rest reinfällt. Hier wären z.B. Museen, Schulen oder Sportstätten noch möglich. Aber erst mal lassen wir es bei den Landmarken. -- sk 3. Jul 2005 10:32 (CEST)

Danke, da werd ich mal bei Gelegenheit Queries absetzen. Bei den Typen selbst, wie ich ja schon ein paarmal ausgefuehrt hab, hab ich die PPL/LK aus der GEOnet Datenbank direkt uebernommen. Die kennen sich mit getypter Georeferenzierung schon etwas laenger aus, und sind deutlich feiner gestaffelt. Ich sehe keinen technischen Grund, die hoehere Type-Genauigkeit vorzeitig zu opfern. RSTN (railway station) als type:landmark? Goaway. LK(lake) STM(stream) als type:waterbodies. So so. Ueber die bezeichung selbst kann man sich gern unterhalten, die GEOnet kuerzel sind halt nicht intuitiv, aber eben eindeutig, und genauer. GuidoD 3. Jul 2005 12:14 (CEST)

Ok, dann schreib aber bitte den Typen aus. Damit kann man schon eher etwas anfangen, als mit diesen unbekannten Abkürzungen. Versetzue dich immer in die Lage eines anderen Wikipedianeres, der diesen Text editiert, und dann plötzlich so ein komischen Type findet. -- sk 3. Jul 2005 13:30 (CEST)

Gerne, doch im Prinzip denke ich mir dann ja selbst was aus. Bei airport/AIRF klappt es eindeutig, bei anderen, nunja. Die uebernommen Eintraege sind jeweils mit einem Kommentar GEOnet gekennzeichnet, und ich von vom Artikel GEOnet erstmal einen Querlink auf Wikipedia:GEOnet Names Server/Liste der Typen gesetzt, wo ich ein paar der Kürzel zusammengetragen haben, die typisch Verwendung finden könnten. Wo wollen wir denn mal eine Zuordnung von Kürzeln zu Langformen dokumentieren, die ich dann übernehme (statt GEOnet/DSG durchzukopieren)?? GuidoD 3. Jul 2005 15:23 (CEST)

Was hälst du davon, den type folgendermassen aufzuschlüsseln "type:GEOnet-H-LK" für Seen (also H= HYdro und LK= Lake) oder "type:GEOnet-T-MT" für Berge (T=Terrain, MT=Mountain). So können wir bei der nächsten Datenbank-abfrage sehr schnell die GEOnet basierten Daten rausfiltern und zuordnen. Wichtig dabei ist immer diese erste Einordnung also T für Terrain etc. Dadurch muss ich nicht immer nachschauen, wo diese Untergruppe jetzt dazugehört. -- sk 3. Jul 2005 15:53 (CEST)

Okay, ich aendere meine Werkzeuge entsprechend. Allerdings kann ich mangels Breitband in diesem Monat keinen Bot drueberjagen, der die alten Eintraege entsprechend aendert. Abgesehen davon, lass uns doch das Schema verallgemeinern: neben einer Basistypisierung darf man Verfeinerungen auszeichnen, sofern diese durch Bindestrich abgetrennt sind. Ich denke, das bringt beides zusammen - man kann anfangs mit wenigen Basisklassen die neuen Geo-Schirme testen, und spaeter schrittweise verfeinern. GuidoD 3. Jul 2005 18:48 (CEST)

Soll man tatsächlich alle Bauwerke mit "type:landmark" kennzeichen – und nicht nur die besonders wichtigen (vgl. en:)? Also sowohl den Eiffelturm als auch das städtische Gymnasium von Bad Salzdetfurth? Das erscheint wirklich etwas komisch ... --kh80 •?!• 3. Jul 2005 12:29 (CEST)

Generell soll alles mögliche georeferenziert werden. Landmarken können wir ja später noch feiner über die schon vorhandenen Kategorien aufsplitten. Also erst mal überall "type:landmark" rein. -- sk 3. Jul 2005 13:30 (CEST)

Ah okay. Dann wäre es also auch in Ordnung, wenn Katastrophe von Tschernobyl unter den Landmarken erscheint? --kh80 •?!• 3. Jul 2005 13:35 (CEST)

Ja genau. Später kann man dann z.B. nach der Kategorie:Katastrophe abfragen und diese als extra Layer ausweisen. -- sk 3. Jul 2005 13:50 (CEST)

kleine frage/anmerkung .. bei type:city(12345) .. soll Sicherlich ohne Punkt oder Komma gearbeitet werden oder? ... wenn dem so ist wäre ein kleiner hinweis auf der hauptseite gut denke ich ...Sicherlich ^Post 3. Jul 2005 16:00 (CEST)

Ich denke mal, dass das gleiche gilt wie in En:Wikipedia:WikiProject_Geographical_coordinates#type:T:

Commas will be ignored in pop. There should be no blanks.

Also ist ganz ohne Punkt und Komma sicher der einfachste korrekte Weg. Gruss --Boris23 讨论 3. Jul 2005 16:31 (CEST)

type wirklich manuell nachpflegen?

hab ja gestern abend mal die abfrage bei wikisign.org gestartet, aber nur für Geokoordinate und da gabs schon 1000 Einträge nur bis Buchstabe R. Für Koordinate wird das sicherlich noch mehr sein, da dass ja meist in den Städtevorlagen mit drin steht. Kann man da nicht mal nen Bot ansetzen, der erstmal die einfachen Sachen einträgt, so z.B. für die Artikel, die nur in einer Ortskategorie drin stehen, also z.B. Ort in Niedersachsen? Das würd ja schonmal massenhaft erschlagen und nicht soviel Handarbeit erfordern... --BLueFiSH ?! 4. Jul 2005 20:30 (CEST)

Ja das wäre eine feine Sache. Hab leider gerade die nächsten Wochen keine Zeit für sowas. Interessant wäre auch eine automatische Überführung der Koordinaten aus der englischen Wikipedia in die deutschsprachige, bei den Artikeln wo das geht. Weiterhin könnte man mit einem Bot alle die Orte georeferenzieren, die zwar Koordinatenangeben haben, diese aber nicht mit der Vorlage eingetragen wurden und deshalb derzeit nicht viel nutzen. -- sk 5. Jul 2005 00:10 (CEST)

Type

Was würde man bei historischen Staaten und Landschaften als "type" eintragen? --Fuzzy 17:51, 10. Jul 2005 (CEST)

type:landmark -- sk 20:01, 10. Jul 2005 (CEST)

Noch ne Frage: was ist bei Inselgruppen? -- Fuzzy 18:27, 16. Jul 2005 (CEST)

type:isle -- sk 20:09, 24. Jul 2005 (CEST)

Kann man auch zwei Typen angeben? Also bei Inselgemeinden z.B. type:city(1151)_type:isle oder so? --Fuzzy 16:59, 13. Aug 2005 (CEST)

Siehe Wikipedia Diskussion:WikiProjekt Georeferenzierung#Doppelte Koordinaten im Artikel. Ich sprech es nochmal an. --BLueFiSH ?! 18:20, 13. Aug 2005 (CEST)

ALT-Text für Koordinaten?

Vielleicht habe ich ja etwas offensichtliches übersehen, aber mir fehlt irgendwie die Möglichkeit, eine Koordinate um Informationen anzureichern, *was* die Koordinate eigentlich darstellt. Das wäre doch gerade für einen Export der Daten wichtig. Klar, wenn die Koordinate an einen Artikel gebunden ist, ist klar auf was sie sich bezieht und ein Export der Daten in z.B. KML-Dateien für Google-Earth kann die Placemarks entsprechend benennen. Nur, was ist z.B. mit dem oben angegebenen Beispiel vom Untergang der Titanic. Ich kann zwar die Koordinate schön angeben und dem Leser des Wikipedia-Artikels kann man super Karten präsentieren, die Koordinaten sind jedoch für einen Export total nutzlos, weil man nicht automatisch einen beschreibenden Text zu dieser Koordinate extrahieren kann. Man bräuchte also sowas wie den ALT-Text zu einem Bild - Text der eindeutig der Koordinatenangabe zugeordnet wird, aber nicht im Artikel selbst erscheint. Oder gibts sowas schon? Benutzer:Simon Budig 01:45, 24. Jul 2005 (CEST)

type: ist die lösung soll wohl später vielleicht noch erweitert werden...Sicherlich ^Post 03:06, 24. Jul 2005 (CEST)

Doppelte Koordinaten im Artikel

Das Thema wurde oben bei #Fehler bei Geokoordinaten für Google Earth schon mal angesprochen. Aber ich will es nochmal aufrollen, der nächste Dump dürfte ja nicht mehr allzuweit in der Ferne liegen.:

Auch Sinn würde es machen bei Artikeln wie z.B. Borkum eine zweite Koordinate unterzubringen und aus dem DB-Dump zu extrahieren, weil Borkum erstens eine Insel und zweitens eine Stadt ist. Bei nur einer Koordinate muss man sich entscheiden welcher man Vorrang gibt. Trägt man statt dessen 2 Koordinaten ein, müssten auch beide extrahiert werden.
Oder man gibt für mehrdeutige Punkte auch mehrere Type an, also im vorliegenden Fall {{Koordinate|53_35_17_N_06_40_11_E_type:isle_type:city(5521)_region:DE-NI|...}}. Da ließe sich wahrscheinlich noch recht einfach aus dem Extrakt ein zweiter Punkt für Google Earth draus erstellen, denk ich mal. Fraglich ist dann eigentlich nur noch wie die Kompatibilität zu Kvaleberg und zur späteren Wikifunktionalität ist. Kvaleberg interpretiert nur die letztgenannte Type-Angabe (ausprobiert mit "isle" & "adm2st"). --BLueFiSH ?! 17:01, 27. Jul 2005 (CEST)

Ja, anderes Beispiel wäre Palenque. Die "Hauptkoordinate" habe ich für die antike Stätte angelegt und im Text noch eine für die etwas entfernt liegende Stadt. Beide Koordinaten sind relevant. Einen Teil des Artikels auslagern macht auch erstmal gar keinen Sinn. --Raymond 20:42, 27. Jul 2005 (CEST)

Derzeit werden von mir die Koordinaten per SQL extrahiert. Mir ist kein SQL Befehl bekannt, der zwei Angaben im Text auslesen würde. Wenn aber so oder so die Koordinaten die selben sind, dann wäre es vielleicht sinnvoller einen zweiten Typ mit reinzuschreiben (Habs noch nicht ausprobiert!). Bei Artikeln mit unterschiedlichen Koordinaten würde ich für die einfachere Variante der Zerlegung des Artikels plädieren, da dies mit jetzigen Mitteln problemlos geht. Übrigens der neue Dump wird von mir gerade für Google Earth aufbereitet, aber ich habe noch Probleme mit verschiedenen Sonderzeichen. -- sk 11:48, 14. Aug 2005 (CEST)

Bei Fehmarn, Pellworm, Borkum, Nordstand und Hooge habe ich mal beides eingetragen. kvaleberg macht damit jedenfalls keine Probleme. --Fuzzy 12:05, 14. Aug 2005 (CEST)

In meinem Beispiel mit "Palenque" sind die Koordinaten verschieden. Aber eine Zerlegung des Artikels halte ich momentan für unnötig, das würde nur einen Mini-mini-Stub für den Ort Palenque erzeugen. --Raymond 12:27, 14. Aug 2005 (CEST)

Wegem dem Extrahieren hab ich mir das so gedacht: Extrahiert wird ja per SQL erstmal alles. Im Anschluss daran muss noch ein (Perl)-Skript drüber gehen und gucken in welchen Zeilen zwei Type-Angaben vorhanden sind. diese Zeilen verdoppelt es dann und entfernt jeweils die eine type-Angabe. In der Theorie eigentlich recht simpel, in der Praxis durch Perl glaub ich recht einfach lösbar. (kann zwar kein Perl, aber habs schonmal gesehen ;-)) --BLueFiSH ?! 12:36, 14. Aug 2005 (CEST)

Neue type-variante oder?

haie ihrs, hier wurde jetzt auf type:city_scale:100000 geändert .. ich dachte bisher immer type:city(100000) ist das geändert? wenn nicht könnte jmd. vom fachpublikum den nutzer mal darauf hinweisen?! .. thx a lot ...Sicherlich ^Post 22:55, 30. Jul 2005 (CEST)

scale bezeichnet doch den Kartenmassstab? Die Zahl in Klammern bei city ist die Anzahl der Einwohner. --Fuzzy 23:33, 30. Jul 2005 (CEST)

ahso ... na denn ... wie auch immer .. ich werde es dann wohl einfach mal ignorieren ;) ..ihr werdet schon wissen was ihr tut ;) ...Sicherlich ^Post 23:40, 30. Jul 2005 (CEST)

Hab vorher noch nirgendwo gesehen, dass der Kartenmaßstab mit angegeben wird. Das sollte auch die Type-Angabe von alleine übernehmen. Je nachdem was für ein Type wird ein bestimmter Kartenmaßstab gewählt. Bei city natürlich größer als bei isle. Wichtiger ist außerdem die region-Angabe. Habe das mal eben korrigiert. --BLueFiSH ?! 07:22, 31. Jul 2005 (CEST)

Samtgemeinden usw.

Der GeoBot hat die niedersächsischen Samtgemeinden als type:city eingeordnet. Korrekt wäre doch type:adm2st, oder irre ich mich? --Fuzzy 01:13, 9. Aug 2005 (CEST)

meiner Ansicht nach schon. Wenn es den type gibt, sollten wir ihn auch verwenden. Habe auch schon einige von dieser Sorte umgeändert. Ich vermute, er wurde nicht drauf programmiert zu erkennen ob es eine Gemeinde ist oder nicht. Ist ja auch nicht so einfach, wenn die Artikel in einer Kategorie:Ort enthalten sind. --BLueFiSH ?! 01:26, 9. Aug 2005 (CEST)

Ich fand den Begriff ulkig, aber aus einigen anderen Regionen waren mir die verschiedensten Begriffe fuer den Zusammenschluss von (unzusammenhaengenden) Ortschaften zu groesseren Gemeinden schon gelaeufig. Daher hatte ich dem bot das okay gegeben, das mit zu aendern. Nunja. Heisst also wohl doch eher was wie 'Bezirk'. GuidoD 09:26, 9. Aug 2005 (CEST)

type:airport(ICAO-Code)

Was soll die Änderung von der IP eben bedeuten: "type:airport(ICAO-Code) - Flughäfen, Luftwaffenstützpunkte (ICAO-Code gem. International Civil Aviation Organization)"? Kann man anhand des ICAO-Code die Flugplätze irgendwie filtern so wie bei "region:Staat-Bundesland"? Oder soll es einfach nur eingesetzt werden für welchen Sinn und Zweck auch immer.. Bitte begründen sonst kommen hier noch alle durcheinander. --BLueFiSH ?! 22:19, 13. Aug 2005 (CEST)

So, da habe ich nun mal kurz nicht aufgepasst, dass die ICAO-Änderung im Artikel nur von einer IP-Adresse kam und offensichtlich ohne brauchbaren Hintergrund ist. Da ich, nachdem ich das gelesen hatte (und es ja durchaus einen Sinn dahintergeben könnte), und danach auf den Artikel Flughafen Erfurt gestoßen bin, hatte ich das dort und bei den dort verlinkten Flughäfen auch gelich umgesetzt. Ich frage mich nun, ob ich das wieder rückgängig machen muss oder es doch eine sinnvolle Ergänzung ergeben könnte? Mazbln 23:01, 13. Aug 2005 (CEST)

also stören wird es sicherlich nicht, aber wenn es keine Funktion hat, wozu einbauen? Auf kvaleberg.com ist es mir nicht ersichtlich, dass es verwendet wird. ich glaub dafür lohnt der edit nicht um das rauszunehmen.. --BLueFiSH ?! 01:17, 14. Aug 2005 (CEST)

Idee bezüglich type:mountain

Wie wärs wenn wir für alles was größer als 1000 Meter ist, ähnlich wie bei type:city eine Klammeroption hinzufügen? also zum Beispiel "type:mountain(3686)". Wenn er kleiner als 1000 Meter ist, dann kann man die Option weg lassen. "type:mountain(666)" fällt dann in die gleiche Kategorie mit rein. Bin nämlich grad über eine Liste von Bergen in Österreich vom Bezirk Liezen gestoßen (Berge im Bezirk Liezen), die alle dortigen Berge über 2.000 Meter auflistet. In dieser sind über 400 ! Einträge enthalten. Wenn man sich dann vorstellt, dass es für andere Bezirke in Österreich ähnliche Listen gibt, dann kann man ganz schön schnell die 10.000er Grenze sprengen. Was haltet ihr von der Idee? --BLueFiSH ?! 04:35, 21. Aug 2005 (CEST)

finde die Idee Wirklich gut ! Ist Sinvoll und ich finde keine Nachteile. Wolfgangw 10:47, 21. Aug 2005 (CEST)

Ich halte die Idee auchfür sinnvoll, nur verstehe ich nicht ganz die beschränkung uaf Berge mit Höhen über 1000 m. Ich verstehe den Sinn der Angabe der Bevölkerungszahl bei Orten/Städten darin, dass man später einmal auf automatisch generierten Karten je nach Maßstab Eintragungen anzeigen oder ausblenden kann. Natürlich führt in eingen Gebieten von z.B. Österreich die Angabe von Höhenzahlen bei allen Bergen ab 1000 m zu einem Datenwust, wenn ich dann aber ein x-beliebiges deutsches Mittelgebirge habe, gibt es bei der genannten Beschränkung aber plötzlich überhaupt keine Höhenangaben mehr, obwohl auch da ein Berg leicht mal 500 m aus der (weiteren) Umgebung rausragen kann. Deshalb plädiere ich dafür, bei den Koordinaten in Bergartikeln grundsätzlich die Höhe in die type-Angabe mit aufzunehmen. --Mazbln 22:37, 23. Aug 2005 (CEST)

hatten wir ja schon beim Stammtisch gesprochen, die 1000 Meter waren von mir ja erstmal nur als Beispielzahl in den Raum geworfen. Als Unterteilung für eine spätere Filterung könnte man (z.B.!) bis 1500 m eine 250 m Einteilung, dann bis 4000 m eine 500 m Einteilung und bis 9000 m eine 1000 m Einteilung (das entspricht einer Aufteilung von 6:5:5 Stufen). Aber das ist ja eh erstmal nur theoretisch und noch lange nicht auf dem Tisch. Da müsste erstmal die Einteilung bei den Städten hinbekommen, dann kann man das hier realisieren.

Da es aber auch keinen Nachteil bringt, wenn man die Zahl dahinterschreibt und diese nur nicht verwendet wird, schreib ich das mal gleich auf die Hauptseite und such mal nen Portal, was darüber informiert werden müsste. --BLueFiSH ?! 23:13, 23. Aug 2005 (CEST)

Ich habe Heute auch dazu einen Gedanken gehabt - wie ist das mit den Marianengraben könnte dazu die Höhe als negative Zahl eingegeben werden? --Atamari … 23:28, 23. Aug 2005 (CEST)

ich denke eher nein, schließlich ist es kein Berg. Von daher erstmal als landmark. --BLueFiSH ?! 23:53, 23. Aug 2005 (CEST)

type

Welche type-Angabe soll denn verwendet werden für Anbaugebiete (Weinbaugebiete etc.), Landschaften und ähnliches? Keine der in der Liste aufgeführten Angaben scheint so richtig zu passen. --::Slomox:: >< 15:43, 21. Aug 2005 (CEST)

wenn nichts passt, dann erstmal type:landmark nehmen. über eine weitere Feingliederung mit z.B. type:building, oder type:street würd ich mich auch freuen, da müsste aber mal jemand mit kvaleberg in Verbindung treten, damit für diese types entsprechende größere Maßstäbe eingerichtet werden. Auch sollten wir uns (sofern möglich) an geltende Benennungen halten, Guidod hat da ja noch weitere types in Verwendung, die aber zum Teil ziemlich kompliziert anmuten.. --BLueFiSH ?! 03:25, 22. Aug 2005 (CEST)

Dann meine zweite (konkretere) Frage von Heute; einen Einschlagskrater, wie z.B. der Vélingara-Krater ist vom Typ eher landmark oder mountain? --Atamari … 23:28, 23. Aug 2005 (CEST)

"10 bis 20 m hoch" naja, also wohl auch kein Berg. landmark passt da schon ganz gut. Für Krater könnte ich mir auch noch einen neuen type:crater vorstellen, gibt ja ne ganze Menger Krater auf der Erde.. --BLueFiSH ?! 23:53, 23. Aug 2005 (CEST)

type:PPL, type:PPLX und type:RGN

Ich hab gerade mal ein paar Korrekturen bei einigen Koordinaten in der Wikipedia vorgenommen. Jetzt hab ich noch diese drei Typen, mit den ich nicht so richtig weiß wohin. z.B. Samtgemeinde Hagen (PPL), Berlin-Mahlsdorf (PPLX) und Barnim (RGN). Alle typen kommen mehrmal in der Wikipedia vor und ich würde sie mit dem Sk-Bot ersetzen, wenn ich wüsste was ich da für einen type hinschreiben soll. Vielleicht habt ihr ja eine Idee. -- sk 18:22, 14. Okt 2005 (CEST)

Samtgemeinden sollen unter type:adm2st einsortiert werden. --Fuzzy 19:56, 14. Okt 2005 (CEST)

type:adm2st wäre doch eher der Landkreis. Oder haben wir evt. type:adm3st für solche Samtgemeinden? -- sk 20:03, 14. Okt 2005 (CEST)

nebenbei: über adm2st hab ich mich letztens schon mal extremst gewundert. müsste es nicht adm2nd lauten? Analog zur englischen Zählweise 1st, 2nd und 3rd... Siehe auch mal google-Ergebnisse: adm2nd=1630 Hits gegen adm2st=8 Seiten und diese alle in der Wikipedia... das sollte man nochmal überdenken und korrigieren. Im Übrigen zählt für mich die nächstkleinere Ebene unter den Bundesländern dazu. Der Unterschied von PPL und PPLX hat sich mir auch noch nicht erschlossen. --BLueFiSH ?! 22:15, 14. Okt 2005 (CEST)

Gemeint war wohl in der 'deutschen' Übersetzung adm2nd. Diese Frage - zusammen mit den mit der Typisierung verbundenen Mühen - würde sich aber erübrigen, wenn man Variante 2 wählen würde. Frage an sk: Haben Sie schon einmal versucht, Koordinaten-Artikel anstelle mit type mit Kategorien zu extrahieren, um z.B. KML zu generieren? Bei einem Projekt rund um den Prototyp www.geometa.info hat's jedenfalls schon einmal funktioniert? -- Geonick 15. Okt. 2005 (CEST)

Antwort auf die Frage siehe Eintrag oben, von gerade eben. -- sk 13:49, 16. Okt 2005 (CEST)

Type-Kategorien (adm1st, adm2nd, city)

Die Kategorien anstelle type zu nutzen ist genau mein Vorschlag - aber offenbar will man nicht...? Ich bin auch ziemlich sicher, dass es mit type (und region) funktionieren wird - aber eben: möglicherweise zum Preis der Doppelspurigkeit (bzw. der Integritätsgefährdung) sowie auf Kosten der Mehrfachnutzung, weil type eine Art Oberkategorie ist, die nach bestimmten Kriterien gebildet wurden. Apropos "bestimmten Kriterien": Was sind eigentlich genau die Zuordnungen zu adm1st und adm2nd, etc.?

type-Kategorien	Def. gemäss Wikipedia	D	A	CH
type:country	für Länder	Deutschland	Österreich	Schweiz
type:state	für Staatengebilde, nicht-souveräne Staaten	-	-	-
type:adm1st	für Bundesländer, Kantone	Bundesland, Regierungsbezirk	Bundesland	Kanton, Halbkanton
type:adm2nd	für Landkreise, Verwaltungsgemeinde...	Landkreis, Samtgemeinde	Bezirk	Bezirk
type:city	für Orte	Stadt, Ort, alle Gemeindearten	Stadt, Ort, alle Gemeindearten	Stadt, Ort, alle Gemeindearten

Habe adm2nd verwendet und mir erlaubt, adm3rd hinzuzufügen - schliesslich gibts ja noch Gemeinden... Diese Tabelle könnte man noch erweitern durch diejenigen Länder, in denen ebenfalls deutsch gesprochen wird: F, B, I, PL, CZ. Ich würde gerne mal einen Test machen und fände diese Zuordnung dazu nützlich: Ich wäre daher froh um Verbesserungshinweise. -- Geonick 17. Okt. 2005 (CEST)

Gemeinden sind type:city. Die Frage ist nur, ob für Ämter, Samtgemeinden usw. noch ein Typ benötigt wird. --Fuzzy 22:28, 17. Okt 2005 (CEST)

Ok: adm2rd gelöscht und type:city eingefügt. Damit sind offenbar mit 'city' neben Gemeinden auch Städte, Orte und alle Gemeindearten gemeint. -- Geonick 17. Okt. 2005 (CEST)

Samtgemeinde ist gemäss Gemeindearten eine der "unterste(n) Stufe(n) im Verwaltungsaufbau eines föderalistischen Staates" und müssten konsquenterweise in city und nicht in adm2nd eingeordnet werden (falls Gemeinden tatsächlich zu city gehören) -- Geonick 17. Okt. 2005 (CEST)

Das ist falsch, steht im Artikel Gemeindearten aber auch gar nicht. Der Begriff Samtgemeinde wird dort nur einmal im Zusammenhang mit Einheitsgemeinden erwähnt. --Fuzzy 23:55, 17. Okt 2005 (CEST)

Gut; dann ergänze ich Samtgemeinde auf Stufe adm2nd und stelle sie damit neben Landkreis. -- Geonick 17. Okt. 2005 (CEST)

Wie ist ein Regierungsbezirk (z.B. Regierungsbezirk Freiburg) einzuordnen? 134.106.146.46 10:14, 18. Okt 2005 (CEST) (=Benutzer:Arcy)

Samtgemeinde ist eine "Gebietskörperschaft, die sich aus (...) Gemeinden desselben Landkreises zusammensetzt", also eine "Aggregierung" und wurde daher auf Stufe Landkreis gehoben. Die Beschreibung von Regierungsbezirk scheint ähnlich - nämlich eine Aggregierung von Kreisen desselben Bundeslandes. Demnach müsste man konsequenterweise Regierungsbezirk auf Stufe Bundesland einordnen - oder? -- Geonick 19.10.2005 (CEST)

@Geonick, wenn man wie du vorschlägt nur die Kategorien benutzen würde, hätten wir ein Verschlechterung der jetzigen Situation. Durch die Typangabe kann sehr effizent eine Grobklassifizierung vorgenommen werden, ohne sich auch nur die Kategorien anschauen zu müssen (was sehr aufwändig ist). Ein weiteres Problem bei der Nur-Kategorien-nutzen-Strategie ist die nicht in einer Baumstruktur organisierten Kategorien. Wäre dies der Fall, würde ich sofort deine Strategie umsetzen, aber die Kategorien sind vielfach auch einfach anders organisiert, so das man fast von einem Netz sprechen müsste, welches nur schwer zur Einordnung eines Artikels in eine Hierachrchie nutzbar ist. -- sk 09:12, 18. Okt 2005 (CEST)

sk: "Einordnung in eine Hierachie": Meinst Du damit eine Hierachie für eine bestimmte Software bzw. passt nicht in das "System Google".? -- 134.106.146.46 10:14, 18. Okt 2005 (CEST) (=Benutzer:Arcy)

Ich meine hierarchische Ordnung in Baumstruktur. In den meisten Softwarprodukten werden große Daten über eine Baumstruktur gegliedert. Ich meine nicht speziell Google Earth, aber dort sieht man es sehr gut. Man muss sich dort entscheiden in welchem Ast der Baustruktur man den Artikel einsortieren möchte. Wenn ich aber mehrere Kategorien in einem Artikel habe stehe ich wieder vor einem Entscheidungsdilema, welches nur durch eine grobe Vorsortierung gelöste werden kann. -- sk 11:01, 18. Okt 2005 (CEST)

Ich finde es sehr ungünstig, dass in der Wikipedia fast nicht zwischen Gemeinde und Ort getrennt wird. So landet für Deutschland beides munter durcheinander in Kategorie:Ort in Bundesland. Orte sind Orte, Gemeinden sind Verwaltungseinheiten die mitunter aus einem Ort, oft aber auch aus einer Vielzahl Orten bestehen können. Ich denke das sollte man schon trennen. Aktuell ist der Großteil der Wikipediaartikel hierzu auf Gemeinden zugeschnitten, aber es gibt ebenso auch zahlreiche Artikel zu Orten, die nur Gemeindeteile sind. Das type-System, das nur die Hierarchienummer der Gebietseinheiten erfasst (also Gebiet erster Ordnung unterhalb der Staatsebene etc.) ist auch leicht willkürlich, wenn man ein adm1st in China und ein adm1st in sagen wir Nauru vergleicht. Darüber sollte zumindest noch mal nachgedacht werden. --::Slomox:: >< 19:59, 18. Okt 2005 (CEST)

@sk: Nehmen wir das Beispiel "Zürich". Dies ist eine mehrdeutige Bezeichnung für Stadt, Gemeinde und Schweizer Kanton. Ohne weitere Angaben ist meist die Stadt gemeint. D.h. die Einstufung als type:city ist nicht falsch aber es ist nicht hinreichend. Dass type:city auch für Gemeinden verwendet wird, stellt Zürich demnach auf dieselbe Stufe wie Wiedenborstel (D) mit offenbar 6 Einwohnern... Noch 'schlimmer': Alle weiteren Charakterisierungen von Zürich (z.B. Hauptort) sind ausgeschlossen. Es ist nun nicht verwunderlich, dass ein Grossteil der Fragen zu type ein Gerangel um dessen Definitionen ist, denn es ist offensichtlich, dass eine einzige Einteilung von eigentlich mehreren Eigenschaften eines "Objektes" nie allen Bedürfnissen gerecht werden kann.

Auf der anderen Seite haben wir die Möglichkeit, mehrere Kategorien pro Artikel zu vergeben und diese je nach Kommunikationsziel (wie die Kartographen sagen) auszuwählen. Dank der echten Hierarchisierung von Kategorien (im Ggs. zu type, wo dies nur mit adm1 -> adm2 -> city der Fall ist) kann man diese sogar wenn nötig zusammenzufassen.

Mehrere Kategorien sind wie Attribute, die ein Objekt "Zürich" beschreiben. Das ist doch für die Erfassung eine Erleichterung und für die Darstellung (bzw. Auswahl) ein Vorteil! Wer nun mittels Kategorien (sinngemäss) z.B. alle Artikel mit Kategorie Stadt, Ort oder Gemeinde selektiert (wie die Datenbänkler sagen), sollte dasselbe erhalten wie mit type:city - mit dem Unterschied, dass derjenige, der nur Hauptstädte haben will, diese über eine entsprechende Kategorien-Abfrage ebenso erhält. Mit type ginge das umgekehrt nie - ausser jemand käme auf die verrückte Idee, die type-Angaben aller betroffenen Objekte je nach Zweck von Hand umzustellen...

Ich bin beileibe nicht begeistert von allen Kategorien, die in Wikipedia real existieren: diese müssen sicher noch verbessert werden. Genauso klar ist aber, dass eine parallele Kategorisierung, wie dies type darstellt, erst dann gewählt werden sollte, wenn Kategorien ihren Zweck nicht erfüllen. In dem Sinne finde ich obengenannte Tabelle nützlich und bin froh um jede sachdienlichen Hinweis oder Frage. -- Geonick 19.10.2005 (CEST)

type:landmark

Den Begriff landmark für alles was sonst nirgens reinpasst zu benutzten finde ich nicht sehr schlau. Landmarken sind besonders auffällige Punkte in der Landschaft und wichtig für die Orientierung. Eine Region, eine Gebäude unter vielen, etc. sind keine Landmarken. Auch Schwimmbäder, Sportanlagen sind oft nur Point_of_Interest aber keine Landmarken. Ließe sich nicht zusätzlich der type:other anlegen? --Langläufer 23:00, 29. Jan 2006 (CET)

zur Lektüre: Archiv1#Fragen und Antworten zur "type"-Angabe mindestens die ersten beiden Absätze. --BLueFiSH ? 03:32, 30. Jan 2006 (CET)

habe nichts gesehen was meine Frage beantwortet. Das man Landmark benuzten soll weis ich doch. Wie weit reichen den die ertsten beiden Absätze? --Langläufer 08:53, 30. Jan 2006 (CET)

Als ich damals die Koordinaten aus der englischsprachigen Wikipedia hier einführte, hab ich die type-Angaben nach dem englischen Vorbild übernommen und nur durch waterbody ergänzt. Im engern Sinne magst du recht haben, was die Landmarken betrifft, aber warum soll ein Schwimmbad nicht auch zur Orientierung dienen. Den 10m-Turm sehe ich meist auch über weite Entfernung und in einem Luftbild kann man die Freibäder besonders gut erkennen. Dagegen schwierig stelle ich mir die klare Unterscheidungsrichtlinien, wann ein POI eine Landmarke ist und wann nicht. Ich würde es so lassen, wie es derzeit ist. -- sk 09:21, 30. Jan 2006 (CET)

gerade auch im englischen ist Landmark für alles andere extrem unpassend. Es sugeriert Wahrzeichen und ich bekomme aber allen Müll - die tatsächlichen Landmarks gehen unter. Eine unscharf abgegrenzte Region kann ich auch nicht zur Orientierung gebrauchen. Eine vernünftige Weiterverwendung von Koordinaten mit dem type landmark ist so nicht möglich. Es wäre aus meiner Sicht besser das type-attribut bei unzutreffend einfach nicht anzugeben. --Langläufer 09:57, 30. Jan 2006 (CET)

Kann auch der Ableger der Post bei uns hier um die Ecke in die Wikipedia als Landmark übernommen werden? Arcy 17:57, 30. Jan 2006 (CET)

@Langläufer: Wenn wir den type:landmark weglassen, wie willst du dann die noch nicht mit "type:..." versehenen rausfiltern? Jetzt wissen wir wenigstens, das sie schon einen type haben, aber noch nicht feiner typisiert wurden. @Arcy: Wenn du einen anständigen Artikel über die den Ableger schreibst, dann kannst du dort auch eine Landmarke setzen. Solange du nicht so eine elende Liste mit Postfilialen erstellst wie Berge im Bezirk Liezen, sei dir alles erlaubt. -- sk 18:33, 30. Jan 2006 (CET)

finde das Argument zieht nicht so richtig. Ob die nun keine type-Angabe, oder eine falsche haben, ist doch egal. Oder kannst du jetzt automatisch feststellen, ob jemand einen falschen type gesetzt hat? Anderer Ausweg wäre type:other --Langläufer 19:20, 30. Jan 2006 (CET)

Die type-Angabe verstehe ich als technischer Kompromiss; sie dient primär der Darstellung auf orientierenden Kartendarstellungen. Kompromiss darum, weil type redundant zu Kategorien ist aber einfacher als diese aus der Koordinaten-Vorlage gelesen werden kann. Ich möchte an dieser Stelle den Berliner Fernsehturm in Erinnerung rufen, der zeigt, dass die Realität nun mal nach mehrfacher Kategorisierung verlangt. Diese bessere - notabene: ebenfalls vorhandene - Variante scheint noch nicht realistisch - mindestens solange die Qualität-(sicherung) der Kategorien so miserabel ist (Bemerkung: evtl. lohnt es sich doch einmal, dies zu probieren. Denn, wenn die Leute sehen, was mit Kategorien machbar wäre, könnte man evtl. einfacher Energien zur Verbesserung freisetzen...?).

Mein Votum: Laut LEO und meinem Webster's muss 'landmark' tatsächlich als Sehenswürdigkeit interpretiert werden. Die Lösung mit 'other', um landmarks im engeren Sinne von den übrigen (= other!) zu trennen, scheint mir am Sinnvollsten. Damit lassen sich wie gesagt auch die noch nicht mit type versehenen Artikel unterscheiden. --Geonick 22:02, 30. Jan 2006 (CET)

Zwei Type-Angaben

Die Artikel Nantucket, Fehmarn, Langeoog, Cudjoe Key, Juist, Tavernier, Key West, Big Coppitt Key, Poel, Duck Key, Borkum, Pellworm, Langeneß und Hooge haben alle zwei type-Angaben isle und city. Was können wir da machen? Eigentlich sollte jede Kooridnatenangabe nur einen Type haben? Irgendwelche Ideen? -- sk 20:44, 24. Jul 2006 (CEST)

Es wäre günstig wenn solche Koordinaten in der Ausgabe also quasi Google Earth gedoppelt werden könnten. Also einmal als Insel und einmal als City angezeigt werden. Wenn du das per Abfrage rausfiltern könntest, wär das super. Schade wärs, wenn eine der beiden untergehen würde. Bezüglich der Region-Angabe hab ich auch schon mal "region:DE-BE/BR" als Angabe gesehen, ich glaub, dass hast sogar du so eingetragen. Gruß --BLueFiSH ✉ (Klick mich!) 22:44, 24. Jul 2006 (CEST)

Bei den Regionen bitte immer kompletter ISO-Code also ncith "region:DE-BE/BR" sondern "region:DE-BE/DE-BR". Aber bei den Inseln und Städten bin ich mir nicht so sicher, das würde ich lieber trennen. Doppelungen mache ich bisher nicht, weil bei der gleichen Koordinate in Google Earth dann nur ein was angeklickt werden kann. -- sk 18:26, 25. Jul 2006 (CEST)

Na gut, dann wars halt "region:DE-BE/DE-BR" was ich gesehen hatte =) Wegen Google Earth gehts mir ja nur darum, dass man Langeoog auch noch sieht, wenn man die Städte nicht eingeblendet hat, nämlich als Insel, oder halt andersrum. Welcher der beiden gedoppelten Punkte nun konkret aufgerufen wird, ist ja egal, der Artikel ist ja in beiden Fällen der gleiche. Lässt sich das nicht irgendwie realisieren? Mehrfache Koordinaten in einem Artikel wertest du ja meines Wissen nach auch nicht aus, die sind nur verlinkte Optik und zum Kvaleberg-Anklicken. --BLueFiSH ✉ (Klick mich!) 19:01, 25. Jul 2006 (CEST)

Gebirgspässe, type

Es wird nun bei Passkoordinaten "type" von mountain in landmark geändert. Ich finde, Gebirgspässe haben viel mehr mit der Kategorie "Berge, Hügel ..." gemein als mit "Sehenswürdigkeiten ..." die von Pyramiden über Museen bis zu Freizeitparks reichen. Auch ist die Höhenangabe bei Pässen ein ziemlich wichtiges Merkmal. Ich halte es für wesentlich klüger und sachgerechter, die Pässe in die Kategorie "mountain" einzugliedern.--KaHe ^Disput 12:08, 1. Sep 2006 (CEST)

Ich finde das nicht, deswegen bin ich ja auch derjenige, der sie umändert, aber nicht gezielt, sondern im Zuge der Hinzufügung der Höhenmeter zu type:mountain. Aber find ich gut, dass du das hier thematisierst, meine Einstellung dazu ergab sich ja bereits aus den Editkommentaren. Mal hören was andere sagen. MfG. --BLueFiSH ✉ (Klick mich!) 12:34, 1. Sep 2006 (CEST)

Wenn schon Sehenswürdigkeit, dann für Berge und nicht die Lücken dazwischen. Arcy 12:43, 1. Sep 2006 (CEST)

Berge sind ganz klar mountain. Die Übersetzung Sehenswürdigkeit verwirrt hier doch nur. Ein Pass ist wohl eher ein besonderes Merkmal in einer Landschaft. Von daher volle Zustimmung für BLueFiSH. --Dschwen 20:20, 10. Sep 2006 (CEST)

Leider recht uneinheitich gelöst. V.a. Schweizer und Französische Pässe neigen zur Verwendung von mountain() für Pässe. Teilweise habe ich auch Koordinaten dahin geändert, da mir das logischer erscheint, dann aber bemerkt, dass dies tw. wieder zurückgeändert wird. Beispiele für Pässe mit type:mountain:

• Ofenpass
• Eagle Pass
• Col de Vars

Die Beschreibung der Werte für type auf Wikipedia:WikiProjekt Georeferenzierung ist leider nicht eindeutig (genug) und sollte am Ende dieser Diskussion präzisiert werden.

Die generelle Frage ist doch, wie und wofür dieser type ausgewertet wird (und das habe ich nirgendwo beschrieben gefunden):

• Falls die type Angabe nur zur Vorselektion eines Maßstabs verwendet wird, ist der konkrete Typ ziemlich wurscht, aber mountain würde eher passen als landmark.
• Natürlich ist ein Pass kein Berg (aber eine Gebirgskette auch nicht!)
• Bei Gebirgskarten mit den Berggipfeln würde ich mir auch die Pässe erwarten, da sie nicht nur den einfachsten Übergang zwischen zwei Tälern, sondern auch zwischen 2 Gipfeln vermitteln.
• Bei Straßenkarten ebenso, dort sind die Pässe wieder wichtiger als die Berge.
• Es gibt einen eigenen type:airport, warum wird bei Flughäfen nicht type:landmark verwendet? Vielleicht löst ein neuen type:mountainpass das Problem? Die Verwendung feingranularer Typen würde in Zukunft die feingranulare Auswertung erleichtern, mehrere Typen könnten noch immer zusammengefasst werden. Auch wenn es im Moment die Dinge komplizierter macht.
• Landmark erlaubt die wesentliche Angabe einer Höhe für Pässe nicht, insoferne würde ich entweder für mountain oder für mountainpass plädieren.

--Herzi Pinki 00:17, 20. Sep 2006 (CEST)

Hallo Herzi Pinki, also bitte kein neuen type erfinden. Die alten Typen wurden so aus der englischen übernommen und bei der Einführung mit dem type "waterbody" ergänzt. Derzeit sind 12 Passe mit landmark und 58 mit mountain versehen. Wenn unbedingt die Pässe auch die Höhenangabe haben sollen, dann würde ich weiterhin mountain empfehlen. Bevor ich die Statistik erstellt habe hätte ich landmark bevorzugt. Aber im Endeffekt kann ich mit beidem leben, da ich es aus beide brauchbar filtern kann. Aber bitte nix neues einführen. -- sk 17:54, 20. Sep 2006 (CEST)

type:city

Als ich mich in den letzten Tagen der Umkategorisierung von Ortsteilen gewidmet habe, habe ich mir ernsthaft überlegt, ob ein eigener type für Stadt- und Ortsteile nicht praktisch ist. In thematischen Darstellungen möchte man vielleicht nur alle eigenständigen Städte und Gemeinden haben, und nicht noch 40 Ortsteile um jede Stadt. Wenn man schon so was wie adm1 und adm2 hat, kann man hier die administrative Gliederung wiederspiegeln. type:city wäre dann ausschließlich für alle Orte in der Kategorie:Ort in Deutschland und ein neuer type:locality o.Ä. für alle Orte, die einer Gemeinde/Stadt angehören.--Eigntlich 17:52, 11. Jan. 2007 (CET)

types ändern ist nicht "einfach so" möglich. Bitte die früheren Diskussionen zur type-Angabe beachten. --BLueFiSH ✉ (Langeweile?) 06:59, 12. Jan. 2007 (CET)

Wäre IMHO keine Änderung sondern eine Ergänzung. "locality", wenn sinnvoll, könnte also sofort übernommen werden. --Arcy 08:26, 12. Jan. 2007 (CET)

Zumindest zu den Ortsteilen hab ich im Archiv nichts gefunden. Da müsste man natürlich einiges anpassen, vielleicht (?) auch per Bot über die Ortsteil-Kategorien. Was müsste denn konkret getan werden, wenn man einen type:locality ergänzt.--Eigntlich (re) 18:03, 12. Jan. 2007 (CET)

Mein Wörterbuch übersetzt Stadtteil mit "district". Da müßte man erstmal sehen was besser und unmißverständlicher ist. Ansonsten sollte es da nicht viel zu ändern geben, außer natürlich in einer Unmasse von Artikeln. Die Kategorien helfen uns in dem Fall auch nicht wirklich, bspw. ist der Prenzelberg ein Kategorie:Ort in Berlin. Wie will man den als Stadtteil erkennen? Ich kenne einige der alten Diskussionen, weiß das da viel gesagt wurde und diese dann doch im Sande verlaufen sind. Ggf. ist ein entschlossener Neuanfang für wenige Punkte das schnellste. Also meine Meinung: mehr Typen brauchen wir nicht, dieser wäre jedoch nicht schlecht. Kolossos 19:02, 12. Jan. 2007 (CET)

Die Frage muss zuerst lauten: Wie definiert sich Ortsteil? Berlin ist eine Stadt mit mehreren Ortsteilen, die jedoch alle Berlin sind. Manches Kaff nennt sich auch Ortsteil von Gemeinde XY, die sind dann aber nicht Ortsteile einer Stadt sondern eine Gemeinde... Die Abgrenzung ist nicht einfach vorzunehmen. Ich halte es für überflüssig. Reicht doch, wenn man nach Einwohnerzahlen filtern kann, das ist ne Zahl, die ist eindeutig. --BLueFiSH ✉ (Langeweile?) 19:34, 12. Jan. 2007 (CET)

Ich kenne auch so einige englische Bezeichnungen dafür ;-) (suburb, district, municipal district, locality). Aber "district" ist wohl zu sehr auf Stadt ausgerichtet und locality ist vielleicht hier am allgemeinsten. Oder eine weitere Form mit adm(xx)? Dein Beispiel mit Berlin stimmt, müsste man dann (neben anderen) manuell kategorisieren. Aber schau mal in die Kategorie:Ortsteil in Deutschland, da sind weit über tausend dabei, die evtl. per Bot gemacht werden könnten. Beteiligen würde ich mich aber gerne.--Eigntlich (re) 19:38, 12. Jan. 2007 (CET)

da gibts ja erstmal weit wichtigeres zu tun, als den type zu ändern. Ihn überhaupt erstmal einfügen wär mal ne sinnvolle Maßnahme: bei denen hier zum Beispiel. Oder fehlende Regionen ergänzen: gibts auch ne ganze Menge. Nur mal so, falls Langeweile bestehen sollte.. --BLueFiSH ✉ (Langeweile?) 19:42, 12. Jan. 2007 (CET)

BK: Ja nu, jeder Ortsteil ist Berlin? Klar. Aber es sind eben Ortsteile (localities), Berlin ist vor allem eine selbstständige Stadt. Und die Unterscheidung Stadt/Gemeinde hat sehr, sehr wenig zu sagen. Städte sind einfach nur Gemeinden mit einem Sondertitel ohne weitere Eigenheiten (und haben häufig sogar weniger Einwohner als Gemeinden) und Stadtteile sind Ortsteile, genauso wie Stadtbezirke/Ortsbezirke/Wohnplätze/Einschichten/Flecken etc. auch alles Ortsteile sind. Wichtig ist nur, dass es Orte sind, die einem anderen Ort angehören.

Diese Listen da kenne ich. Aber wenn wir deshalb sowas nicht machen, weil anderes zu tun ist (und das kommt doch eigentlich sehr gut voran). Da könnte man auch eine Sperre für neue Artikel (ich weiß, dass das manche wollen) machen, da noch so viele zu überarbeiten und erweitern sind...--Eigntlich (re) 19:52, 12. Jan. 2007 (CET)

Da kommt gar nix voran. --BLueFiSH ✉ (Langeweile?) 20:16, 12. Jan. 2007 (CET)

Och, [2] [3]. Aber das meine ich gar nicht: Von den deutschen Städten/Gemeinden und Ortsteilen haben mit Sicherheit fast alle vollständige type-Angaben und dann könnte man diese Änderung ja vornehmen, da dort momentan kaum noch was zu verbessern ist.--Eigntlich (re) 20:26, 12. Jan. 2007 (CET)

@BLueFiSH: Wenn deine Listen abgearbeitet sind, werde ich das Thema erneut ansprechen… Das ist wohl doch erstmal wichtiger als so ein neuer type.--Eigntlich (re) 18:13, 13. Jan. 2007 (CET)

Es macht IMHO durchaus Sinn neue type-Kategorien frühzeitig zu verwenden.

• Bei der Abarbeitung von Listen können diese - insbesondere bei Neueinträgen - frühzeitig eingearbeitet werden.
• Schon vorhandene Georeferenzierungen können bei Änderungen hinsichtlich des types On-The-Fly mit verändert werden.
• Eine nachträgliche Änderung (=Doppelbearbeitung) entfällt.
• Mehrarbeit wird vermieden.

--Arcy 18:39, 13. Jan. 2007 (CET)

Bitte nicht die Reglung mit den wenigen Typ-Arten aufweichen, solange wir das mit ein paar Kategorien einfach lösen können. Alle Systeme müssten ansonsten angepasst werden und international würde wieder Wildwuchs entstehen. Ich sehe die derzeitige Nutzung der wenigen Typen sehr positiv. Sie dient als erste Grobsortierung. Wer die Koordinaten feiner sortieren möchte, sollte so oder so auf die Kategorien zugreifen. Wenn wir von dem Prinzip abweichen, müssen wir alles doppelt eintragen (Stichwort Redundanz (Information)). Also bitte keine neuen typ:xyz. -- sk 23:16, 13. Jan. 2007 (CET)

• Grobsortierung heist dann doch, dass eine Feinsortierung folgt und alle Artikel (auch die, die noch nicht georeferenziert wurden) im nachinhein einer nochmaligen Feinsortierung unterliegen. Das ist doch eine unnötige doppelte Bearbeitung der man frühzeitig begegnen kann. Man sollte sich bewusst sein, das es sich bei diesem Projekt um ca 100.000 Datensätze/Artikel (55.000in der WP.de) handelt, die nachbearbeitet werden müssen -> Man schaue sich aber mal die vielen Regionen auf der Karte von Kolossos an, die noch nicht bearbeitet wurden. Da macht es durchaus Sinn, sich frühzeitig über korrekte und sinnvolle Typen Gedanken zu machen.
• Redundanz (Information)). Redundant wird bereits seit den Anfängen des Projekts gearbeitet. Typangabe (Typ = Gattung, Teil einer Kategorie, ...)und Wikipediakategorien werden gleichzeitig gepflegt.
• Wildwuchs: Mir ist nicht bekannt, dass es weltweit einheitliche Vorlagen für die Koordinateneinbindung in der WP gibt.

--Arcy 11:47, 14. Jan. 2007 (CET)

Die Grobsortierung ist für viele Anwendung ausreichend, wenn nicht sogar vorteilhaft. Die Feinsortierung geht sehr fix (Mein Perl Programm braucht mit anderen Bearbeitungsschritten keine 2 Minuten dafür.). Der Vorteil der Grobsortierung ist, dass sie wie eine Übergeordnete Kategorisierung wirkt, die auch oft einfacher zu vergeben ist, als eine Feinsortierung. Man kann damit sehr schnell mal alle Berge rausfiltern. Wenn man es noch feiner haben möchte, z.B. alle Freilichttheater, dann muss man halt wirklich af die Kategorien zugreifen. Schwieriger erscheint mir die Grobsortierung, wenn wir nur feinsortiertes hätten. - Mit der Redundanz magst du recht haben, aber wir sollten sie nicht noch ausbauen. - Mit dem Wildwuchs meinte ich die typ-Angaben, nicht die Vorlagen, und die Typ-Angaben sind weltweit derzeit noch einheitlicht. -- sk 22:53, 14. Jan. 2007 (CET)

Glücklicherweise haben viele Artikel mittlerweile eine die Koordinate einbeziehende Infobox (wie die Infobox Ort in Deutschland. Da gibt es dann keine Redundanz mehr und man könnte den type:city einfach ändern. Mittlerweile bin ich von meinem Vorschlag auch nicht mehr ganz so überzeugt, aber der Name type:city ist für Ortsteile definitiv falsch. Cities sind eigentlich per Defintion Großstädte (!) und keine Weiler mit 15 Einwohnern, die diesen type auch haben. Aber vielleicht sollte man mit sowas ja warten, bis es eine Datenbank für alle Wikipedias gibt.--Eigntlich (re) 13:23, 14. Jan. 2007 (CET)

Dann haben wir wohl ein Problem mit der Vorlage:Infobox Ort in Deutschland: <snip>....type:{{#switch: | Amt |Gemeindeverwaltungsverband| Samtgemeinde| Verbandsgemeinde| Verwaltungsgemeinschaft| Verwaltungsverband = adm2nd| #default = city</snap>
Per Voreinstellung (default = city) sind alle Orte einfach mal Citys oder - @Eigntlich - vielleicht sogar Großstädte! ;-). --Arcy 19:35, 14. Jan. 2007 (CET)

Da selbst der "Antragsteller" (Eigntlich) Abstand nimmt, und wir das Problem zum Großteil auch später über die Kategorien und einen Bot lösen können, könnten wir die Disk. eigentlich erstmal abschließen und vielleicht in einem Jahr nochmal aufrollen. Danke.

Was die Vorlage:Infobox Ort in Deutschland angeht, so sind city(Einwohnerzahlen) besser zu verarbeiten(EDV) als Cities, Town, Villages... Kolossos 08:45, 16. Jan. 2007 (CET)

Wir habe nur das Problem, dass 70-80-90 % (?) aller Ort durch die Vorbelegung City schlichtweg falsch definiert werden. Jedes kleine Fleckchen wird als City definiert. --Arcy 10:05, 16. Jan. 2007 (CET)

Übersetze city einfach mit "menschliche Siedlung" und dann klappt es wieder. "city" ist halt schön kurz und das Wort kennen auch viele leute, die kein englisch können. -- sk 10:25, 16. Jan. 2007 (CET)

Ick küm vom dörp. --Arcy 10:50, 16. Jan. 2007 (CET)

Zum Glück kann die EDV den Unterschied von city(3000000) zu city(17) sehr gut verarbeiten. --BLueFiSH ✉ (Langeweile?) 12:07, 16. Jan. 2007 (CET)

-Kann die EDV das? Stadt: "Je nach Größe, Bedeutung oder Funktion einer Stadt unterscheidet man Landstädte, Kleinstädte, Mittelstädte, Großstädte, Millionenstädte, Weltstädte, Stadtregionen oder Ballungsräume, Trabantenstädte und Satellitenstädte. Während etwa in Dänemark die Untergrenze der Bevölkerungszahl bei einer städtischen Siedlung bei 200 Einwohnern liegt, sind es in Deutschland und Frankreich 2.000, in der Schweiz 10.000 und in Japan 50.000 Einwohner.".
Auch ist beispielsweise Berlin-Kreuzberg mit 146.300 Einwohnern keine Stadt.

Ich bin jetzt mal mit BLueFiSHs Liste beschäftigt bzw. gehe zum Beispiel alles hier und hier durch. Dabei sind viele Orte, die eine Infobox haben, wo man der Region-type und die Einwohneranzahl theoretisch automatisch rausgezogen werden könnte, wie bei der Infobox Ort in Deutschland. Auch die durchgängig unterschiedlichen Einwohnerzahlen (bei der Aktualisierung wird die Koord. oft vergessen) wäre damit gelöst sowie die noch durchgängig fehlende Die ISO 3166-2, die man noch extra raussuchen muss. Sollte man in den Fällen nicht in den jeweiligen Infoboxen darauf dringen, dasselbe wie bei der Vorlage zu machen? Das spart viel Zeit und Mühe.--Eigntlich (re) 17:34, 17. Jan. 2007 (CET)

Fragen und Antworten zur "region"-Angabe

Probleme

Hallo Stefan,

in zwei meiner Artikel habe ich deine Geokoordinaten-Vorlage verwendet. Da in der KML-Datei der Artikelname in dem die Koordinaten enthalten sind verwendet werden ergeben sich einige unschönen Dinge.

Im Artikel zu Franz Köhl sind die Koordinaten zu einem Turm gespeichert, der den Namen des besagten Mannes trägt. In Google Earth steht nun auch nur Franz Köhl, obwohl hier Franz Köhl Turm besser wäre.

Im Artikel Sandachse Franken sind die Koordinaten einer Binnendünen gespeichert, die man auch sehr schön in Google Earth sehen kann. Nun ist aber die Sandachse Franken ein Gebiet und nicht nur dieser Punkt

Daher wäre es schon, wenn man zu den Geokoordinaten auch noch einen zusätzlichen Text angeben könnte, der die Geodaten ordentlich benennt.

Gruß --AndreasH 4. Jul 2005 19:44 (CEST) Von meiner Benutzerseite hierher kopiert. --sk 5. Jul 2005 08:33 (CEST)

Sicherlich wird das Problem häufiger auftreten. Da muss eine Lösung her. Bei dem Artikel Geografische Koordinaten hab ich die verlinkten Beispiele (München, San Francisco) mit dem "type:Beispiel" versehen, damit man diese Koordinaten rausfiltern kann. In den oben geschilderten Beispielen müsste man noch sowas wie eine Kurzbeschreibung mit einbringen. Hatt jemand eine Idee? Mir ist sowas auch bei Sperenberg aufgefallen, wo die Koordinate für den Flughafen im Stadtartikel steht. -- sk 5. Jul 2005 08:33 (CEST)

Als schneller Workaround würde sich beim Franz Köhl Turm ja ein kleiner Stub anbieten. ;-) knappe 3 Sätze hat Franz Köhl dazu ja zu bieten.. --BLueFiSH ?! 5. Jul 2005 08:48 (CEST)

Das mit dem Stub für den Frank Köhl Turm habe ich mir auch überlegt. Würde vielleicht auch Sinn machen, da es im Lexikon auch häufig so gehandhabt wird. Aber wie sieht es mit der Sandachse aus, da wirds schon schwieriger mit den eigenen Stub. Finde es gerade interessant die Düne, die man auf den Foto sehen kann mal von oben zu betrachten. Was spricht für eine Erweiterung der Geokoordinaten-Vorlage der Form {{Koordinate|49_32_41_N_11_03_24_E_type:landmark|Franz Köhl Turm|49° 32′ 74" N, 11° 03′ 24" O}}. Ein weitere Vorteil wäre, dass damit auch gleich der Typ Landmarke bessere definiert wäre; da eine topographies Karte schon sehr viele verschiedene Landmarken kennt. Würde den Informationsgehalt weiter erhöhen.

Noch besser wäre eine eigene Geokoordinaten Datenbank/Wiki auf das man sich beziehen könnte; z.B.: über eine ID. Würde auch die Schreibweise vereinfachen. Aber ich beginne zu Träumen.... --AndreasH 5. Jul 2005 10:04 (CEST)

Ich bin für eine Angleichung der englischen Wikipedia an die hiesigen Geokoordinaten.

http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates#Implementation_details

Hat außer type: auch noch region:DE was ich gerne benutzen würde. Nur wenn es nicht die Vorlagen unbrauchbar macht oder leicht anpassbar ist. Wann kann man übrigens <geo>48 46 36 N 121 48 51 W</geo> benutzen ? Das Wikimedia Plugin ist anscheinened schon geschrieben. --Mononoke 5. Jul 2005 10:48 (CEST)

"region:DE" kannst du auch jetzt bereits schon verwenden. Einfach mit dazu eintragen und feddisch. Ich finds eigentlich auch recht sinnvoll, grade weil dadurch auf dem kvaleberg-dingsda dann nur noch die relevanten Kartendienste angezeigt werden. Also für "region:DE" kein Kartendienst, der nur USA anbietet. --BLueFiSH ?! 5. Jul 2005 16:47 (CEST)

Fehler bei Geokoordinaten für Google Earth

Hi Leute, ich hab mir heute Google Earth und die Daten aus der Wikipedia von Stefan installiert. Allerdings ist mir bei München der Punkt Geografische Koordinaten untergekommen. So sollten die Beispiele ja nicht funktionieren, da sollte man die Vorlage am Besten gar nicht benützen oder? Das zweite Beispiel mit San Fransisco kommt bei Google Earth nicht vor. --ElRakı ?! 7. Jul 2005 20:30 (CEST)

Die haben beide das "type:Beispiel" drin, was dann beim Export ignoriert werden soll. Hat Stefan hier irgendwo auch schon mal geschrieben (siehe ein paar Absätze höher bei "Probleme"). In diesem Zusammenhang stell ich mir grad die Frage, ob auch mehrere Koordinaten in einem Artikel ausgewertet werden. Z.B. bei diesem könnten ja München und SF je eine Koordinate bekommen, aufgrund der SQL-Abfrage wird aber wohl nur die erste extrahiert. Kann man die so ändern, dass auch mehrere Koordinaten extrahiert werden? --BLueFiSH ?! 7. Jul 2005 21:32 (CEST)

Bei meiner Vorgehensweise, ziehe ich mir zuerst alle Koordinaten aus der Datenbank und sortiere sie nach dem "type". Da einige Artikel zwei Koordinatenangaben besitzen, filtere ich das zweite Auftauchen eines Artikelnamens heraus. Im Artikel Geografische Koordinaten werden zwei Koordinatenbeispiele genannt, und der erste Punkt für München wurde übernommen. Da beim zweiten Beispiel zu San Fransisco der Artikelname "Geografische Koordinaten" gefunden wurde, wurde dieser nicht mehr in die KML Datei eingebaut. Als ich im nachhinein diesen Punkt bei München in Google Earth entdeckte, habe ich im Artikel Geografische Koordinaten den beiden Beispielen den "type=Beispiel" gegeben, damit wir sie beim nächsten Mal gleich rausfiltern können. -- sk 8. Jul 2005 10:08 (CEST)

Eine zweite Koordinate auch notfalls mit dem gleichen Artikelnamen würde aber Sinn machen, wenn sie abweichend von der ersten ist. Wenn die zweite Koordinate natürlich exakt der ersten entspricht, dann ists unnütz, das stimmt. --BLueFiSH ?! 8. Jul 2005 12:01 (CEST)

Mir ist bisher kein Fall untergekommen, wo eine zweite Koordinate, notwändig gewesen wäre. Insbesondere bei zwei verschiedenen Koordinaten würde ich davon ausgehen, dass eine falsch ist. -- sk 9. Jul 2005 10:08 (CEST)

In Havel hab ich gesehen, dass eine zweite, auskommentierte Koordinate vorhanden ist. In ein paar anderen Berlin-Artikeln ist es mir auch noch aufgefallen. Für Alexanderplatz (Berlin) wäre es auch schön, wenn man Koordinaten für die einzelnen Gebäude einfügen kann. Wobei ich grad auf die Idee gekommen bin, diese Koordinate einfach bei dem Redirect-Artikel einzutragen. Notfalls auch auskommentiert. Für den Export dürfte das dann ja auch funktionieren und der Redir müsste trotzdem noch funktionieren.. Dann könnte man z.B. auch Untere Havel oder Haus des Lehrers mit einer eigenen Koordinate versehen... --BLueFiSH ?! 01:02, 11. Jul 2005 (CEST)

Gibt es eine Chance auf eine neue Version der KML Datei ? Ich hab jede Menge neue Koordinaten in den Artikeln gesehen z.B. Abschlussdeich (ok das hab ich selbst gemacht :) --Brutha 23:29, 10. Jul 2005 (CEST)

Sobald der neue Datenbank-Dump bei Wikisign.de zur Verfügung steht, werde ich ein neue KML-Datei erstellen. -- sk

Fehler (?) auf kvaleberg bei Angabe von "region"

Im Artikel Glasgow habe ich die Geokoordinaten um "type:city(580000)" und "region:GB-GLG" ergänzt. Es funktioniert auch, kvaleberg liefert GB-spezifische Dienste, siehe hier.

Aber es fehlt der Link auf Googlemaps. Kann man dies nachtragen? --Raymond 8. Jul 2005 09:08 (CEST)

Man darf die entsprechenden Vorlagen wiki-editieren - die DE Uebersetzung hab ich mal beigesteuert. Allerdings musste ich mich da auch durch einige Seiten durchhangeln. Versuch mal http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/GB ... cheers, GuidoD 8. Jul 2005 09:32 (CEST)

Ahh danke, schon wieder was gelernt :) Habe GB um Google ergänzt. --Raymond 8. Jul 2005 09:39 (CEST)

Lustig, ich hab mal bei Google (Web)Maps reingeschaut - es scheint die gleichen Satellitenbilder als Grundlage zu haben, wie ich sie schon bei Terraserver gesehen habe. Das ist auch dadurch deutlich, dass Berlin-Adlershof im hochaufloesenden Bild nur halb auf dem Satellitenbild war - Google Maps zeigt mir zu den Koordinaten nun ein Bild, dass links hochaufloesend braeunlich gezeichnet ist, und rechts verschwommen gruenlich gezeichnet ist (wenn man entsprechend heranzoomt). Fuer etwaige Augenfehler fragen Sie ihren Arzt oder... GuidoD 8. Jul 2005 09:56 (CEST)

Problem mit region:-Informationen

ich weiß nicht, ob da was falsch ist, aber ich habe die vermutung, dass es nix nützt, wenn ich bei einigen artikel die region dazu schreibe, insbesondere bei ländern, die sich außerhalb der EU befinden, wie z.b. türkei. ich habe bei Istanbul region:TR eingeben, aber es erscheinen hier auch links zu karten in den Vereingten Staaten. (und nebenbei, type funktioniert an dieser stelle auch nicht so recht) Schaengel89 @me 23:46, 22. Jul 2005 (CEST)

Type ist meines Wissens auf Kvaleberg dafür da, die entsprechende "Höhe über dem Ort" zu justieren. für Region muss/kann jeweils eine eigene Unterseite angelegt werden, auf der dann nur die relevanten Kartendienste angezeigt werden. Im Endeffekt machen wir das mit Type+Region aber nicht für Kvaleberg sondern wohl eher für Anwendungen wie Google Earth. --BLueFiSH ?! 23:56, 22. Jul 2005 (CEST)

Etwas verklausuliert aber richtig. Der Kvaleberg server ist auch ein Wiki, man kann sich eine beliebige region-Seite anlegen. Die DE-Seite bearbeitet man unter http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/DE , und wenn man das Endungs-DE gegen TR austauscht (etwa http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/TR), kommt eine Seite, die noch nicht angelegt ist. GuidoD 00:24, 23. Jul 2005 (CEST)

Dient die Angabe von region nicht auch dazu, eine Filterung zu ermöglichen? Unabhängig von Kategorien direkt (irgendwann) mal zu sagen, "gib mir alle Inseln (type:isle) der Bahamas (region:BS) aus"? Oder alle Landmarks von Baden-Württemberg (region:DE-BW)? Oder habe ich da was falsch verstanden? --Raymond 00:51, 23. Jul 2005 (CEST)

so hab ich das auch verstanden. Mal sehen ob es beim nächsten Update der Koordinaten für Google Earth bereits möglich ist. (ich kann mir da nicht so recht vorstellen wie das funktionieren soll) --BLueFiSH ?! 01:24, 23. Jul 2005 (CEST)

Die Filterung der zahlreichen Koordinaten in der letzten KML-Datei von mir erfolgte nur über den "type", da in diesem Datenbank-Dump nur sehr sehr wenige "region" Einträge drinne waren. Da alle in den letzten Tagen so fleißig waren, wird bei der nächsten KML-Datei dieser Eintrag "region" mitgenutzt. Die Frage ist dort eigentlich nur, wie soll das hierarchisch aufgebaut werden. Also welchen Ordner möchtet ihr erst einschalten

• de.wikipedia --> Landmark --> Europa --> DE --> DE-BW (Landmarken in Badenwürttemberg)
• de.wikipedia --> Europa --> DE --> DE-BW --> Landmark (Landmarken in Badenwürttemberg)

Im ersten Fall kann man sehr schnell welteit alle Landmarken einschalten, muss aber wenn man z.B. nur in DE-BW Landmarken und Airports haben möchte die beiden entsprechenden Hierarchebäume sehr tief runter gehen. Bei dem zweiten Fall kann das für z.B. DE-BW sehr schnell machen, dafür aber weltweit nur alle Landmarken und Airports einzuschalten ist sehr mühsam. Was möchtet ihr lieber haben? -- sk 09:17, 23. Jul 2005 (CEST)

Ich wäre für beide Optionen. Wobei mir das Bundesland-dingens vorerst noch egal wäre. Das hieße zwar, dass die Daten doppelt in der Datei drin stehen, aber.. wär das so schlimm? --BLueFiSH ?! 11:39, 23. Jul 2005 (CEST)

Ja, da dann an der selben Koordinate zwei Punkte beschriftet werden. -- sk 14:37, 24. Jul 2005 (CEST)

Norwegen

Sobald man region:NO einfügt, wird Google Maps in den "Map sources" nicht aufgelistet.--KaHe 14:40, 5. Sep 2005 (CEST)

habs hinzugefügt. Fürs Selbermachen nächstes mal: Auf der Seite fast ganz oben steht "NOTE: This is an experimental service, currently implemented as a proof-of-concept on an off-site server. It will later be included in Wikipedia proper. You may edit this list on Wiki:Map_sources/NO.". Über die Seite Wiki:Map_sources/NO kann man die Seite der Region NO bearbeiten und überflüssiges entfernen oder fehlendes hinzufügen. --BLueFiSH ?! 19:34, 5. Sep 2005 (CEST)

Was man alles nicht machen kann ... Danke --KaHe 20:19, 5. Sep 2005 (CEST)

_region:XX_ und Sprach(aus)wahl

Mein Versuch für eine Georeferenzierung einer Lokation in Paris (Frankreich) unter "region" das (korrekte) ISO-Kürzel (+Département) "FR-75" einzugeben führte zu dem (unerwünschten) Ergebnis, dass die referenzierte "Abfrageseite" in Französich kam.
Wie kann ich erreichen, dass trotz Wiki-gerechter Notation die Abfrage in Deutsch bleibt? Etwa: _region:DE/FR_ ??? --
hd 14:14, 31. Jul 2006 (CEST)

Gar nicht, das soll so. --BLueFiSH ✉ (Klick mich!) 14:26, 31. Jul 2006 (CEST)

AFAIK überhaupt nicht, da die Ausgabeseite kvaleberg.com nur eine Übergangslösung darstellt und keine Sprachauswahl kennt. „Zum Ausgleich“ erhält jeder, der einen deutschen Ort auswählt, eine deutschsprachige Seite präsentiert ;-) Sobald das Feature direkt in die Wikipedia integriert ist (Wann? Keine Ahnung!) wird auch die Sprachpräferenz berücksichtigt. Die von dir vorgeschlagene Lösung führt jedoch in die Irre, da dann keine Selektion der reinen Koordinaten nach Ländern mehr möglich wird. --Raymond ^Disk. 14:30, 31. Jul 2006 (CEST)

Das ist ein Fehler der Ausgabeseite. Die nutzt diese Region-Angabe um sich für eine Sprache zu entscheiden. Also bei Koordinaten in Deutschland kommt immer die Seite mit deutschen Quellen in deutscher Sprache. Bei einer Koordinate in Frankreich kommt immer die Seite mit den französischen Kartenquellen und leider auch in Franzzösisch. -- sk 14:32, 31. Jul 2006 (CEST)

Die Kvaleberg-Seiten sind ein Wiki. Wir könnte die deutschen und franz. Seiten also auch ins Englische übersetzen. Wäre das eine Lösung? Kolossos 09:22, 1. Aug 2006 (CEST)

Grundsätzlich ja, da hätte man alle (?) Seiten einheitlich auf Englisch. Wobei ich gestern Schwierigkeiten hatte, auf die Edit-Seite zu kommen. Kamen ziemlich komische Fehlermeldungen. --Raymond ^Disk. 10:10, 1. Aug 2006 (CEST)

Frage zu Parameter 'region'

Hi ihr. Sorry falls die Frage schon durchgekaut wurde (dann bitte nicht schlagen;-): Der Parameter 'region' soll ja laut Doku dafür sorgen, daß nur für die Region sinnvolle Kartenquellen angezeigt werden. Jetzt habe ich mal beim Viaduc de Millau auf den Link geklickt und siehe da: Die sich öffnende Seite ist auf französisch. Da sollte doch eine Trennung von Kartenquellen und Sprache erfolgen, vulgo: Die Kartenquellen sollten in deutsch beschrieben werden. Ist das u.U. sogar schon in Arbeit? Beste Grüsse, --Gnu1742 09:36, 2. Sep 2006 (CEST)

Das soll so und darauf haben wir keinen Einfluss. Guidod schrieb dazu mal das hier. Und außerdem: siehe etwas höher bei _region:XX_ und Sprach(aus)wahl --BLueFiSH ✉ (Klick mich!) 15:50, 2. Sep 2006 (CEST)

*reibt sich tomaten von den Augen* OK, danke (ich nehme an, guidod ist geonick?). Ist m.E. unschön, aber gut... --Gnu1742 15:56, 2. Sep 2006 (CEST)

Häh? Guidod ist Guidod und Geonick ist Geonick. --BLueFiSH ✉ (Klick mich!) 15:57, 2. Sep 2006 (CEST)

Achso, sorry, hab mich verguckt/verschrieben. --BLueFiSH ✉ (Klick mich!) 15:58, 2. Sep 2006 (CEST)

ISO-Code bei Italien und Frankreich

Bei Italien (ISO 3166-2:IT) und bei Frankreich (ISO 3166-2:FR) gibt es ISO-Codes für die 1. und 2. Ebene der administrative Einheiten also Regionen/Provinzen bzw. Regionen/Départements. In den Ortsartikeln von italienischen und französzischen Gemeinden werden aber beide genutzt. Meiner Meinung nach sollten wir das einheitlich für alle machen, also wie in Deutschland, Österreich oder anderswo, nur die oberste administrative Einheit nutzen. Was meint ihr dazu? -- sk 16:23, 11. Aug 2006 (CEST)

Recht hast Du. Es sollte auf jeden Fall einheitlich sein um ein allgemein auszuwertendes "Bild" zu schaffen. Nur bin ich mir nicht sicher, ob es wirklich die oberste Ebene sein soll. Wenn wir die kleineren Einheiten nutzen (trotz der Mehrarbeit) gibt es die Möglichkeit das ganze spezifischer auszuwerten und zugänglich zu machen. -- Monsterxxl <°))))> 16:57, 11. Aug 2006 (CEST)

Warum? Wenn im jeweiligen Artikel der Code für das Départements genutzt wird, ist das genauso richtig (oder sogar noch richtiger) als wenn nur die Region angegeben ist. Das ist dann halt beim ISO 3166-2 für FR so. In den Artikeln alles auf die jeweilige Region zu ändern, halte ich für falsch. Muss man halt die Software anpassen, wenn man statt 95 + auf nur 22 + klicken will. meine 4 Pfennig. --BLueFiSH ✉ (Klick mich!) 01:59, 15. Aug 2006 (CEST)

Einheitlichkeit nutzt dir gar nix. Bei Statistiken kommt es immer darauf an was du untersuchen willst. Entsprechend sind die Rohdaten aufzubereiten. Vergleiche sind meist nur innerhalb eines Landes sinnvoll möglich, weil die Struktur dieser Einheiten eben landspezifisch ist. Was soll bitte ein Vergleich eines deutschen Bundeslandes mit einem Schweizer Kanton bringen, ausser, dass Gegensätze noch mehr betont werden? Der Vergleich mit einer französischen Region ist da schon besser. Aber ein Vergkeich der Bundesländer Baden-Württemberg und Bayern mit der Schweiz ist auf jedenfall ausssagekräftiger als mit einem einzelnen Kanton. Wenn es zwei Ebenen gibt, sollten beide, mindestens aber die unterste angegeben sein. Die höhere Ebene ist dann wenigstens noch ableitbar. -- visi-on TWW 09:17, 15. Dez. 2006 (CET)

ISO 3166-2

Bei einigen Staaten gibt es Codes für mehrere administrative Untergliederungen, wie bei der ISO 3166-2:PH. Sollte man hier die genauere Einteilung nutzen, in dem Fall also die Provinzen oder die Bezirke?--Eigntlich (re) 13:28, 20. Jan. 2007 (CET)

Jup. Ist schon richtig. Ist auch so in Italien, wenn ich mich recht entsinne auch in Frankreich. Das sollte aber kein Problem sein, wenn alle Artikel (Koordinaten) schon die Codes für die keinere Verwaltungsebene intus haben, ist doch logisch, das sie zu der Übergeordneten dazugehören... -- Monsterxxl <°))))> 19:56, 20. Jan. 2007 (CET)

Aktuell: LA gegen die ISO-3166-2-Artikel

Nur zur Info, falls es jemand noch nicht mitbekommen hat. Ein "Experte" hat jetzt sämtliche Artikel mit den ISO-Normen 3166-2 zur Löschung vorgeschlagen. Vielleicht möchte jemand aus dem Projekt auch mal was dazu sagen, bevor die doch noch gelöscht werden: Wikipedia:Löschkandidaten/27._Januar_2007#Diverse_Artikel_zur_Norm_ISO_3166-2 --NickKnatterton – !? 19:10, 27. Jan. 2007 (CET)

ein Berg zwei Staaten

Hallo!

Ich habe beim chilenisch-argentinischen Berg El Muerto, bei Region "region:AR/CL" angegeben. Ist dies so korrekt? --ALE! ¿…? 00:22, 21. Feb. 2007 (CET)

Sofern die Bergspitze und damit die Koordinate auf der Grenze liegt ist der Fall nicht genau deffiniert und durch die Software nicht exakt auswertbar. Soll heißen lass vorerst mal die region Angabe weg und ergänze nur die Koordinate, bis dies geregelt ist. MfG Monsterxxl <°))))> 00:48, 21. Feb. 2007 (CET)

Falsch ist "region:AR/CL" nicht und Stefan wertet sowas bereits seit langem aus, also viel besser so als gar nicht. --BLueFiSH ✉ (Klick mich!) 02:23, 21. Feb. 2007 (CET)

Ui. Das ist neu für mich. Aber gut zu wissen für die nächsten Edits. MfG Monsterxxl <°))))> 09:16, 21. Feb. 2007 (CET)

Da ich bei der Auswertung ja dann den Berg einem Staat zuordnen muss, nehme ich immer den ersten von den Staaten, die angegeben wurden. Bisher hat sich darüber noch niemand beschwert. Ein Verdoppelung wäre technisch möglich, aber praktisch sinnlos, da der Berg ja dann zwar in beiden Ordnern der Staaten vorkommt, aber im Kartenbild zweimal an der selben Stelle eingezeichnet wird. -- sk 09:36, 21. Feb. 2007 (CET)

Macht doch nichts, wenn der Berg zwei Mal an der gleichen Stelle eingezeichnet wird. Das merkt man bei Google Earth doch erst, wenn man auf das Markierungs-Icon klickt. Ich halte es auf jeden Fall für besser, solche Ort in beiden Ordner aufzuführen. --ALE! ¿…? 10:06, 21. Feb. 2007 (CET)

Fragen und Antworten zur "Scale"-Angabe

Scale-Angabe

In der Beschreibung kommt die Scale-Angabe ja etwas zu kurz. Bei einigen Einträgen der Geokoordinaten habe ich festgestellt, dass für eine optimale Skalierung von Google-maps und den Ortskarten dieser Wert erforderlich ist. Den Maßstab habe ich empirisch ermittelt, aber irgendwo schon mal eine Tabelle gesehen. Weiß jemand wo ich die finde? - Godewind 15:21, 3. Nov 2005 (CET)

Ich verstehe das Bedürfnis (und bin gespannt, was das für eine Tabelle sein mag) möchte aber beliebt machen, die Scale-Angabe gänzlich abzuschaffen! Der Grund liegt darin, dass Scale eine Angabe ist, die *nicht* zur Koordinate, bzw. zum Artikel/Text, gehört und nur ganz bestimmten Anwendungen dient. Die eigentliche Information, die hier - z.B. bei Gebirge - Sinn macht, ist wenn schon die maximale Ausdehnung in Nord-Süd- oder Ost-West-Richtung (z.B. in Km). Damit kann dann jedes darstellende System zusammen mit dem aktuellen Ausschnitt den notwendigen de:Massstab selber berechnen. Noch 'objektorientierter' wäre es, wenn die Ausdehnung des Gebirges mitgegeben werden könnte - ich glaube aber, dass wir uns hier mal auf Koordiaten konzentrieren sollten. Geonick 23:18, 3. Nov 2005 (CET)

Die Tabelle war nur eine Auflistung von Massstäben, vielleicht auch gar nicht auf Google-maps bezogen. Aber Scale abschaffen? Die Aufnahmen von Google-maps haben unterschiedliche Auflösung und die Objekte unterschiedliche Ausdehnung. Inseln, Seen, Landmarks, Städte sind mit dem vorgegebenen Massstab nicht immer korrekt darzustellen. Hier zwei Beispiel für landmarks, die vergleichbare Größe haben, aber in Google-maps in unterschiedlicher Auflösung zur Verfügung stehen (Schulschiff Deutschland,Leuchtturm (Travemünde)). -- Godewind 08:44, 4. Nov 2005 (CET)

Ich kann mich den Äusserungen Geonicks nur anschliessen. Also abschaffen und durch Ausdehnung (Länge / Breite) ersetzen. Arcy 10:59, 4. Nov 2005 (CET)

Mag ja alles richtig sein, ich sehe das im Moment von der praktischen Seite. Die Abmessung eines Schiffes oder Gebäudes kann man vielleicht noch schätzen, aber ist nicht für die Maps eher die Angabe Maßstab geeigneter? Oder wie würde ich das für die o.g. Beispiele umsetzen? -- Godewind 13:09, 4. Nov 2005 (CET)

Schließe mich Geonick ebenfalls an. fragwürdig ?! 19:51, 6. Nov 2005 (CET)

Ich kann mit der scale-Angabe auch nicht viel anfangen. Ich könnte mir vorstellen, daß es z. B. leichter wäre, optional den Radius des Kreises anzugeben, der dargestellt werden soll. Die interpretierende Software müßte das dann in einen passenden Google-Maßstab umrechnen. Damit wäre auch klar, daß die Geokoordinate den geometrischen Mittelpunkt des Objektes meint. Insgesamt wäre das die bequeme und sozuagen theoretisch saubere Variante. Aus praktischen Gründen könnte es aber sinnvoll sein, daß man vorerst (?) die scale-Angabe weiterhin (optional) zuläßt. Die Ursache des Problems liegt wahrscheinlich darin, daß man ein Objekt mit räumlicher Ausdehnung nicht vollständig durch Angabe einer Punktkoordinate beschreiben kann. Wie geht das z. B. mit dem Amazonas? Deshalb gibt es in GIS-Systemen ja auch Punkt, Linien und 2D-Elemente. --Roland2 21:52, 6. Nov 2005 (CET)

Eine Koordinate gibt einen Punkt an, ist daher 0-dimensional. Eine Objekt ist immer 3-dimensional, die Darstellung auf einer Karte 2-dimensional. Eine Koordinate kann daher niemals eine Ausdehnung beschreiben. Die theoretischen Überlegungen und Ideen, welche zusätzlichen Informationen zu einer geeigneten Beschreibung führen, müssen erst einmal umgesetzt werden. Um bis dahin den Lesern unserer Artikel maximale Information zur Verfügung zu stellen, ist die Verwendung von scale ein äußerst wirkungsvolles Mittel. Bei richtiger Wahl wird das Objekt in etwa bildschirmfüllend dargestellt. Mit ein wenig Übung ist es nicht schwer den besten Maßstab zu wählen. Wem dies zu mühsam ist, muss das ja nicht machen. Ärgerlich finde ich jedenfalls, bereits bestehende scale-Angaben zu entfernen, wie z.B. hier geschehen. Kwerdenker 15:24, 17. Nov 2005 (CET)

Lieber Kwerdenker, bitte führe evtl. meine obigen Ausführungen nochmals zu Gemüte. Wir beschreiben hier Objekte (Artikel, Texte) der realen Welt mit Attributen, wovon die Lage eines davon ist. Deine Forderung nach maximaler Information würde bedeuten, die Objekte mit mehreren Attrituten (hier: Kategorien) und mehreren Geometrien zu beschreiben. Soweit sind wir hier im Projekt noch nicht. Ein Kompromiss wäre wie gesagt, die Ausdehnung (z.B. in realen Km) noch anzugeben. Massstabsangaben gehören nicht zu den Objekten, sondern zum darstellenden System; der hängt u.a. vom darzustellenden Perimeter und vom Bildausschnitt ab (vgl. Massstab im Wikipedia)! --Geonick 10:51, 18. Nov 2005 (CET)

Lieber Geonick, ich glaube wir sind mit unseren Ansichten nicht weit auseinander. Mir ist schon klar, dass die Maßstabsangabe keine Eigenschaft des Objektes ist. Mir geht es darum dem Leser jetzt möglichst viel Information bereit zu stellen. Dafür möchte ich bestehende Möglichkeiten voll ausnützen. Wenn ich der Koordinatenangabe folge, bekomme ich ein relativ umfangreiches Angebot an Kartendiensten. Hier sofort zu der, für dieses Objekt ideale Darstellung geführt zu werden, halte ich für einen großen Komfort. Dem Leser ist es dabei letzlich egal, ob das durch Angabe eines Maßstabes oder durch einer km-Angabe der Ausdehnung erfolgt. Insgesamt gesehen ist es natürlich richtig die Größe (Ausdehnung) durch zusätzliche Eigenschaften zu beschreiben. Daraus könnte natürlich automatisch die ideale Darstellung ermittelt werden. Bis dahin denke ich, ist aber scale eine durchaus vernünftige Übergangslösung. Kwerdenker 12:25, 18. Nov 2005 (CET)

Da stimme ich zu. Solange es keinen besseren Ersatz für die scale-Angabe gibt, sollte sie erhalten bleiben, weil sie auch einen Laien (wie mich) in die Lage versetzt einen Artikel mit Geokoordinaten zu versehen und das anhand von Google-Maps und Mapquest zu überprüfen. Für diese Anwendung benötigt man ja nur eine Positionsangabe als Mittelpunkt und einen Darstellungsbereich, z.B einen Kreisdurchmesser wie - siehe oben - von Benutzer:Roland2 vorgeschlagen. Aber auch dieser Wert ist von den zur Verfügung stehenden Karten abhängig und somit zu einem guten Teil willkürlich. -- Godewind 18:22, 18. Nov 2005 (CET)

Vorhandene Scale-Angaben jetzt zu löschen, fände ich unsinnig. Besser wäre es, erst einen Ersatz schaffen und dann die scale-Information (in welcher Form auch immer) in das neue System (welches?) übernehmen. --Roland2 19:01, 18. Nov 2005 (CET)

Ich möchte für Berge der Größenordnung des Mount Everest gerne eine Scale-Angabe einfügen, damit diese Berge auf meinem Bildschirm optimiert dagestellt werden. Ich benutze diverse GIS-Programme Google-Earth und World-Wind. Welche Scale-Angabe, bspw. für den Mount Everest könnt ihr da empfehlen? 84.137.234.89 19:53, 18. Nov 2005 (CET)

scale:50000 könnte passen, möglicherweise auch 25000. Mit 100000 wird es schon etwas klein. Am besten über die Vorschau ausprobieren. Kwerdenker 23:02, 18. Nov 2005 (CET)

Wir sind tatsächlich mit unseren Ansichten nicht weit auseinander, besonders mit dem Ziel, "dem Leser jetzt möglichst viel Information bereit zu stellen.". Offenbar liegt einzig die Kvaleberg-Seite oder ein ähnlicher Dienst dazwischen... Darum hier nochmals mein Vorschlag: Artikel werden mit Ausdehnung als Kreisradius oder als Nord-Süd und West-Ost-Ausdehnung 'angereichert' (in Km). Diese Angabe kann auch Earth-Benutzer zugemutet werden (allenfalls mit Multimap den Massstab prüfen und mit GeaBios die Ausdehnung). Beim Generieren der Google Maps-Links zu Spanien wird dessen Ausdehnung von 800 Km genommen und mit der Konstante 6250 multipliziert. Diese Konstante würde konkret zur kvalevberg-Seite gehören und muss für jeden Dienst von Spezialisten einmal(!) ermittelt werden. Daraus ergibt sich für Google Maps und Spanien ein Massstab von ca. 1:5'000'000 - also genau der, welcher jetzt im Artikel enthalten ist. Bei Google Earth könnte die Konstante kleiner sein (weil das Zoomen so schön Spass macht...), und für einen Handy-MMS-Dienst wäre die Konstante grösser... etc.; für jedes Programm und für jede angenommene 'typische' Bildschirmgrösse also eine andere! -- Geonick 01:11, 21. Nov 2005 (CET)

scale

Eine vernünftige automatische Maßstabssteuerung ist bei Vermischung von punkt-, linen- und flächenförmigen Objekten nicht möglich. Ob man ein Berg oder ein Gebirge, Einen Teich, eine Fluss, oder ein Meer angibt ist aus den Attributen nicht erkennbar. Die Darstellung, dass das Scale-Attribut eigentlich nicht gebraucht wird ist nicht richtig. --Langläufer 23:00, 29. Jan 2006 (CET)

it's a wiki. --BLueFiSH ? 03:32, 30. Jan 2006 (CET)

in den projekten will ich aber nicht mal schnell rumfuschen. die diskussion kann man ja nicht mehr nachvollziehen bei der Länge. --Langläufer 08:51, 30. Jan 2006 (CET)

@Langläufer: Wenn ich dich richtig verstehe, meinst du, wir sollten mehr das scale-Attribut einsetzten. Oder meinst du dass das scale-Attribut generell unbrauchbar ist. Bei erstem Fall kann ich nur raten, warte noch ein wenig, z.B. das Attribut type und region wurden auch am Anfang sehr selten benutzt, bis es dann doch jemand eingefügt hat. Bei zweitem Fall, welche andere Lösung schlägst du vor? -- sk 09:25, 30. Jan 2006 (CET)

ich meinte es wird zu selten benutzt. Die Anleitung klang ja auch so, als ob es überflüssig sei. Eine Richtlinie für die passende Maßstabswahl wäre noch gut: Wieviel Umland sollte sichtbar sein? Ich Orientiere mich derzeit an Google-Maps. Bei anderen Anbietern führen die Maßstabsangaben allerding leider zu ganz anderen Ergebnissen. --Langläufer 09:50, 30. Jan 2006 (CET)

Eine Scale-Angabe macht imho nur dann Sinn, wenn sie einen Bezug zur realen welt hat. Dies kann z.B. der Maßstab sein, bei dem ein Objekt bei einer 10 x 10 cm großen Darstellung optimal sichtbar ist. Wahllos undefinierte "massstabslose" Zahlen von 1-10 machen da wenig Sinn. Auch kann man sich dabei nicht grundsätzlich an einem Anbieter orientieren. Arcy 18:10, 30. Jan 2006 (CET)

? Das ist ja wohl keine Frage, sinnlos sollte die Wahl nicht sein! Nehmen wir mal z.B: an wir haben ein Land. Soll der in den Ausschnitt bei Google-Maps passen (so dass man die Stadtteile besser erkennt) oder lieber nur z.B. 1/9 der Bildfläche einnehmen, damit man auch das Umland sieht. Wie ist es dann bei einem Briefkasten (z.B.) ? Da interessiert mich doch wahrscheinlich die Umgebung viel mehr? --Langläufer 19:29, 30. Jan 2006 (CET)

"Die Google Map" gibt es nicht. Eine Google-Map bzw. jede Karte hat eine Größe, z.B. 400x400 Pixel oder 10x10 cm. Nehmen wir mal an, ein Objekt muß innerhalb eines Kartenrahmens von 400x400 Pixel darstellbar sein. Der Maßstab (scale) bei dem dieses Objekt noch vollständig sichtbar ist ergibt sich +/- automatisch daraus. Dazu packt man noch eine Portion gesunden Menschenverstand und eine Prise Geschmack und fertig ist die Massstabsangabe bzw. die Scaleangabe. Dann klappts auch mit dem Briefkasten. Arcy 16:14, 31. Jan 2006 (CET)

Und da sind die Probleme! 1. Wie groß (wie viele Pixel) ist die Karte wirklich? (Google, Map...) 2. Wie groß ist ein Pixel? - das hängt von der Auflösung des Monitors ab meist 96dpi). Meine ursprüngliche Frage war ja, ob man den guten Geschmack gesunden Menschenverstand ein wenig eingrenzen kann. Davon nehme ich erstmal Abstand - solange die technischen Fragen noch nicht geklärt sind.

Es ist imho weniger eine technische Frage (Dreisatz) sondern Frage der Normsetzung und der Praktikabilität. Ansonsten ist eine 10x10 cm große Karte über Google-Maps genauso groß wie eine 10x10 cm große Karte im Atlas auf Papier bei gleichem Maßßstab und gleichem Ausschnitt "gleich" groß. Arcy 17:14, 31. Jan 2006 (CET)

Der gleiche Maßstab ist nur gewährleistest, wenn immer schön die Bildauflösung mitgeführt und angepasst wird. Dazu muss der Browser die Bildschirmauflösung (dpi) kennen (kann man bei Mozilla einstellen, bei IE nicht). Ist aber auch egal, für den Ausschnitt ist die Größe (pixel) und nicht der Auflösung (dpi) entscheidend. --Langläufer 17:30, 31. Jan 2006 (CET)

Ohne scale-Angabe kommt man nicht aus, weil in der type-Angabe eben nur ein typischer Maßstab definiert ist. Ich prüfe einen scale-Wert mit Google Maps und Mapquest, damit habe ich die besten Erfahrungen gemacht. Ich kenne aus früheren Diskussionen die Meinung Einzelner, dass man scale nicht benötigt, aber eine vernünftige Alternative haben die nicht nennen können. -- Godewind 19:59, 30. Jan 2006 (CET)

Die Scale-Angabe ist nicht nachnutzbar: Sie ist immer nur für einen einzigen Dienst richtig und auch das nur, wenn dieser den Bildausschnitt beibehält. Der bevorzugte Dienst scheint zurzeit Google Maps zu sein. Ich zitiere gerne meinen Alternativvorschlag aus Archiv1: "Artikel werden mit Ausdehnung als Kreisradius oder als Nord-Süd und West-Ost-Ausdehnung 'angereichert' (in Km).". Am sinnvollsten wäre hier also so etwas wie eine 'Bounding Box'. Wer mehr über den Zusammenhang von "Massstab", "Bild-/Kartenausschnitt" und "dargestellte Fläche in der Realität" wissen will, verweise ich auf das Rostocker GIS-Lexikon sowie auf die einschlägige Literatur der digitalen Kartographie, bzw. der graphischen Bildverarbeitung. --Geonick 22:25, 30. Jan 2006 (CET)

Sehe ich auch so, ein Radius wäre besser! Aber sollte er das Objekt minimal einkreisen oder lieber etwas größer gewählt werden? Das hängt evtl. von der Art des Objektes ab. Aber vielleicht sollte man das lieber nicht festschreiben, sondern dem Editor überlassen.--Langläufer 23:02, 30. Jan 2006 (CET)

Wichtig ist doch nicht, wie das Kind heißt, sondern was es bewirkt. Ich gebe jetzt bei scale einen (Erfahrungs-)Wert ein und schaue was Goggle-maps, mapquest oder map24 darstellen. Wenn google für ein landmark keine Darstellung hat, nehme ich einen größeren scale-Wert. Ich denke dem Betrachter ist es egal wie Bild/Kartenauschnitt zustande kommen, es ist aber lästig, wenn Google-maps nur leere Kästchen zeigt, oder ein See (z.B. Titicaca) nur als schwarze Fläche dargestellt wird, weil er nun mal größer als der Bodensee ist und Orte sind mal kreisförmig, mal langgezogen, das Bildseitenverhältnis der Darstellung bleibt aber. Mit anderen Worten: Nennt den Parameter wie ihr wollt, ums probieren wird man doch nicht rumkommen und an die vielen bereits vorhandenen scale-Werte muß man auch denken, die kann ein Bot zwar umbenennen, aber mit umrechnen wird das nicht funktionieren. Und ob man den zitierten Briefkasten pur oder mit 10m Umkreis definiert wird an der Darstellung nichts ändern. -- Godewind 10:21, 31. Jan 2006 (CET)

Ich gebe dir dar insofern recht, dass das für den Benutzer egal ist. Man will doch eigentlich gewährleisten, dass das Objket vollständig, aber nicht zu klein dargestellt wird. Um das zu erreichen, muss ich zwei Dinge kennen: die Ausdehnung des Objektes (r) und die Ausdehnung des Bildes (r'). daraus kann man dann den passenden Maßstab (M) bestimmen (M=r'/r). Ein Radius wäre somit zunächst mal die sauberste Lösung, wenn die Bildfläche variiert. Aber auch mit einem Maßstab könnte man arbeiten. Dazu müsste man eine Ausdehnung für das Bild festlegen. Damit unterschiedliche Systeme hinterher trotz abweichender Ausdehnung des Bildes das komplette Bild anzeigen, muss das Skript, welches den Maßstab weitergibt, diesen für das entsprechende System anpassen (wenn es dort nur ein kleineres Bild gibt, halt kleinerer Maßstab u. andersrum). Problematisch ist allerdings, wenn die Bildgröße des Ausgabesystems nicht bekannt ist, z.B. je nach Fenstergröße variiert. Hiefür gibt es keine Lösung. --Langläufer 10:43, 31. Jan 2006 (CET)

Wie du selbst dargelegt hast, sind unser jetziger Massstab und ein Radius äqvivalent, man muss also nur mit einer Formel M errechnen und alles kann beim alten bleiben. Ich komme bei einem Maßstab von 1:15000 auf ein Objekt vom ungefähr 1 km. Also ist unser scale X=15000*r [r in km]. Für andere Programme als GoogleMaps sollte sich dieser Wert auf Kvalenberg entsprechend umrechnen lassen. Kolossos 11:27, 31. Jan 2006 (CET)

Zur Erläuterung warum Skale (zumindest begrifflich) nicht geeignet ist um den Bildausschnitt einzustellen. --Langläufer 14:10, 31. Jan 2006 (CET)

Aquivalent, wenn man die Ausgabebildgröße fest definiert ist. Diese variiert aber in Realität je nach Kartenanbieter, Monitorauflösung, etc. Was ich erreiche will ist der gleiche Ausschnit, bzw. den gleichen Radius sehen, was ich angebe heißt aber Maßstab. Einfache, aber begrifflich nicht ganz saubere Lösung ist: Man könnte z.B. Google-Maps einfach als Standard annehmen. Für alle anderen Systeme sollte "Kvalenberg" den Maßstab so anpassen, dass etwa der gleiche Bildausschnitt wie in Google-Maps gezeigt wird. --Langläufer 12:29, 31. Jan 2006 (CET)

Die Google-Map-Scale-Angabe ist nicht portierbar. Die Scaleangabe bezieht sich auf eine durchschnittliche Ausdehnung in Meter pro Pixel. Zu den Polen und zum Äquator hin wird bei gleicher Scale-Angabe eine unterschiedlich großes Objekt dargestellt. Bei einer Scale-Angabe von "10": Am Äquator 100 km = 2,5 cm, Nordgrönland: 10 km = 1,5 cm. (auf meinem Bildschirm). Man überzeuge sich hier. Die Google-Map-Scale-Angabe ist somit auch nur für Google-Maps brauchbar und nur mit Angabe der Längen- und Breitengerade auch portierbar. Arcy 16:51, 31. Jan 2006 (CET)

Das scheint mir ein Problem der Kartenprojektion. Der Maßstab gilt nur an den Berührstellen (bzw. -kreisen). Damit muss sich "Kvalenberg" rumärgern. Breitenangabe ist aber bei der Koordinate immer dabei, sollte also eine automatische Korrektur möglich sein. Dein Vorschlag ist 400px, 10cm als Normgröße ist o.k. Lösung ist ein guter Kompromiss. Das begrifflicher Problem sollte aber langfristig berücksichtigt werden. --Langläufer 17:20, 31. Jan 2006 (CET)

Vorschläge

A

Als Ausgangspunkt der Scale-Angabe dient ein Kartenfenster von 10 cm (ca. 400 x 400 Pixel).

• Dieses Kartenfenster ist auf einem DINA4-Blatt darstellbar
• Nahezu jeder Bildschirm stellt solch ein Fenster (ca. 400x400 Pixel) vollständig sichtbar dar.
• 10 cm sind eine runde Zahl um damit zu rechnen.
• Die Scaleangabe erfogt in klassischer Weise als Maßstab im 1 : XXXX Modus.

Diese Variante hat den Nachteil, das man den Wert XXXX erst errechnen muss oder mit einem bestimmten Tool bestimmen muss.

B

• Es wird nur die reale maximale Ausdehnung eines Objektes genannt (Länge und Breite oder Radius eines Umkreises). Um alles weitere kümmert sich "die Software". Vorteil dieser Lösung ist, dass dem einfachen Nutzer gleichzeitig Informationen zur Objektausdehnung mitgeliefert werden.

Bin nach wie vor eindeutig für B. Begründung: Daten mit Raumbezug - um die es hier geht - sind 'massstabslos' (vgl. Rostocker Glossar)! Das Attribut könnte extension, circumcircle oder diameter heissen, falls wir uns auf den Radius des Umkreises einigen. Vergesst dabei nicht die Einheit und Nachkommastellen anzugeben; ich schlage vor Kilometer mit Meter-Auflösung. Das ergibt einen Wertebereich von 0.001 km bis maximal 99'999.999 km. -- Geonick 08:48, 1. Feb 2006 (CET)

Ist doch ganz einfach. Die Lösung heisst "size". Vielleicht würde sogar der Exponent auf der Basis von Metern reichen, 0 = 1 m, 1 = 10, 2 = 100 m, 3 = 1 km, 4 = 10 km, 5 = 100 km usw. oder die Grösse des Objekts in Metern eben.

Ich würde jedenfalls mit solchen Werten arbeiten, die sich auf das Objekt beziehen, und nicht auf irgendeine Software. -- Simplicius 15:45, 3. Feb 2006 (CET)

Dies bedeutet allerding auch zusäzliche Rechnerei für den einzelnen. Und bei 50m habe ich schon Entscheidungsschwierigkeiten. Arcy 18:39, 9. Feb 2006 (CET)

keinen Exponenten - so einfach wie möglich, alse radius in m bwz. km! --Langläufer 17:08, 22. Feb 2006 (CET)

C

verschoben nach E.II

D

Dezimale Angabe von Länge und Breite in Kilometern

Die Angabe von Länge und Breite begegnet optimal allen Fragen der Darstellung eines Objektes. Arcy 18:44, 9. Feb 2006 (CET)

was ist bei dir Höhe? meinst du vielleicht Länge und Breite? dezimal ist ok - ist aber teil von vorschlag B. --Langläufer 17:10, 22. Feb 2006 (CET)

Stimmt, danke. Arcy 17:58, 22. Feb 2006 (CET)

E

Google-Maps like Scaleangaben

Die Daten sollten schon auf die Objekte bezogen sein ("Datenebene", "Primärdaten") und nicht auf irgendein Programm ("Präsentationsebene"), von dem man unter anderem auch nicht weiss, ob es nicht mal später Geld kosten wird.

Ich wäre daher dafür, eine Ergänzung mit dem Durchmesser oder Radius zu machen, wenn es überhaupt erforderlich ist, da was zu machen.

Zum Bleistift gibt es bei Google Earth ja auch verschiedene Auflösungen, und die könnte man formelmässig bei der Umrechnung berücksichtigen, so dass man am Ende gar nur mit einer diskreten Anzahl von Scale-Angaben fahren könnte. -- Simplicius 23:53, 8. Feb 2006 (CET)

Es ist aus fachlicher Sicht vielleicht richtig die Objekte auf "Datenebene" (wie ich es verstehe also in realen Abmessungen) zu bewerten, als Laie kann ich aber nur über die "Präsentationsebene" der angebotenen Programme (Google maps, mapquest, usw.) einen Wert ermitteln und nur diese Darstellungen werden wohl für die meisten Nutzer der WP interessant sein. @Kolossos: Wenn Du die scale-Angabe noch nie benutzt (und vermißt) hast, dann lag das entweder an den ausgewählten Objekten, die günstig in das Raster der Type-Angabe fielen, oder Du hast auf der "Präsentationsebene" ein unbefriedigendes Ergebnis hinterlassen. Beispiele für erforderliche scale-Angaben (wie immer man das Kind auch nennen will) habe ich in der Diskussion schon genannt, bringe sie aber bei Bedarf gerne noch mal. Mein Fazit: Die Koordinatenangabe ist für die "Präsentationsebene" interessant und da wird eine Angabe zum "Kartenauschnitt" benötigt. Präzise Angaben auf "Datenebene" können ergänzend rein oder in den Artikel einfließen. -- Godewind 10:16, 9. Feb 2006 (CET)

Ich hab meine Aussage oben etwas ergänzt. Um es noch mal anders zu formulieren: angenommen ein Objekt ist 500 m groß, dann sind das 500. Damit kann jeder was anfangen.

Um daraus irgendeine andere Zahl zu machen, dafür gibts Formeln, also soll das doch die Formel machen. Das muss nicht immer heissen, dass ein Scale "berechnet" wird, sondern kann auch bedeuten, dass pro Objekt in einer Fallunterscheidung geprüft wird, welcher scale "am zweckmässigsten" ist - auch in Abhängigkeit der Anwendung Google Earth, NASA World Wind und was in Zukunft kommt. -- Simplicius 12:40, 9. Feb 2006 (CET)

Den Ansatz verstehe ich ja und finde ihn auch vernünftig, weil die hohen scale-Werte ja auch keinen Sinn machen es sei denn ich könnte auf der "Präsentationsebene" etwas mit einem Wert "1" anfangen. Kann ich aber nicht, werde ich auch nicht mit einer Objektgröße von 1m können, aber das spricht ja nicht gegen Deine Dimensionierung. Nun die Praxis, Beispiel 1: Schulschiff Deutschland, das Teil ist rund 100m lang, liegt diagonal im Bild und Google maps bringt bei scale:2000 ein gutes Bild. Beispiel 2: Ein (flächenmäßig) kleineres Objekt der Leuchtturm (Travemünde), da ist schon ein scale:20000 erforderlich, weil Google in dem Bereich keine höher auflösenden Bilder anbietet. Spricht ja auch nicht gegen Deine Skalierung, das Schiff hätte vielleicht den Wert 200, der Leuchtturm müßte aber schon 2000 bekommen und das nur wegen Google. Deshalb erlaube mir einen Vorschlag: Einen Parameter für die Objektgröße, die dann auf den Straßenkarten auch etwa so dargestellt wird und einen Parameter für Google maps, der mit der dortigen Skala korrespondiert (~ 1..20). Klingt redundant, die Fachleute werden vielleicht die Stirn runzeln, aber ich sehe keine andere Möglichkeit die "Datenebene" und die "Präsentationsebene" mit einem Parameter adäquat darzustellen. -- Godewind 15:56, 9. Feb 2006 (CET)

Das sind interessante Fragen, ein Schiff könnte auch hochkant im Bild stehen (ich meine jetzt nicht sinkend), das Objekt könnte aber auch in einem Bildbereich liegen, der hochauflösend gezeigt wird oder im Meer, das samt Inseln meist sehr schlecht gezeigt wird.

Grundsätzlich wäre es aber gut, in die Artikel nur die Primärdaten reinzutun, und kvaleberg.org erzeugt dann per Formel einen optimierten Ausschnitt für den klickenden Benutzer.

Auch so erschiene im Ausschnitt dann ganz Spanien, ganz Madrid, oder gegebenenfalls ein kleineres Fenster, das vor dem Hintergrund der Auflösungsstufen nicht zu klein gewählt sein sollte. Für die Koordinatensammlungen sollte äquivalent auch eine Fallunterscheidung möglich sein (in bestimmten Bereichen per Formel, in bestimmten Bereichen Festangabe eines scales).

Habe ich aber schon irgendwelche festen Zahlen in den Artikeln nur auf die Google-Ansicht bezogen, sind diese Betrachtungen für produktabhängige Differenzierungen in einem anderen Produkt sozusagen für'n Popo. -- Simplicius 17:13, 9. Feb 2006 (CET)

• zu: "weil Google in dem Bereich keine höher auflösenden Bilder anbietet": Fürn popo ist es auch den gerade in deutschland angebotenen googlemaps hinterherzulaufen und dann scale neuen un detailierteren karten anzupasseen.
• zu: "einen Parameter für Google maps, der mit der dortigen Skala korrespondiert (~ 1..20).": korrespondiert heisst Google-Scale heißt festlegung auf google-maps
  Die Google-Map-Scale-Angabe korrespondiert nicht mit der Größe eines Objektes sondern ist zusätzlich abhängig vom Längen- und Breitengerade. Die Scaleangabe bezieht sich auf eine durchschnittliche Ausdehnung in Meter pro Pixel. Zu den Polen und zum Äquator hin wird bei gleicher Scale-Angabe eine unterschiedlich großes Objekt dargestellt. Bei einer Scale-Angabe von "10": Am Äquator 100 km = 2,5 cm, Nordgrönland: 10 km = 1,5 cm. (auf meinem Bildschirm). Man überzeuge sich hier. Die Google-Map-Scale-Angabe ist somit auch nur für Google-Maps brauchbar und nur mit Angabe der Längen- und Breitengerade auch portierbar.In entsprechender Weise sind komplizierte Umrechnungen erforderlich um mittels Höhe, Breite sowie Breiten- und Längengrad einen Google-Map-Scale zu berechnen, der zusätzlich für ein definiertes Bildschirmfensterchen gelten muss. 18:27, 9. Feb 2006 (CET)-- Arcy 18:29, 9. Feb 2006 (CET)

Ist mir aus den unendlichen Diskussionen ja schon bekannt, aber gibt es eine Alternative zu Google maps? Wenn nicht wäre mir ein eigener Parameter dafür lieber als eine irgendwie berechnete aber unbefriedigende Bildansicht. Und für die Primärdaten kann man einen neuen Parameter wählen. Vielleicht ist das der Preis, den man in einer proprietären Phase zahlen muß, aber er wäre mir nicht zu hoch. -- Godewind 19:17, 9. Feb 2006 (CET)

Gute Satellitenbilder präsentiert auch NASA World Wind, wobei ich nicht zu denen gehöre, die sich mit der speziellen Ansteuerung des Programms auskennen. Aber es macht beim Programmieren sicher keinen Spaß mehr, Google-Earth-Scale-Werte in Nasa-World-Wind-Scale-Werte umzurechnen.

Deswegen sagt man heutzutage vor allem im GIS-Bereich: lass Daten mal Daten sein und Programme mal Programme. Es sind unterschiedliche Schichten.

Scale-Angaben in einer KML-Datei sind sicher sinnvoll, weil für Google Earth gedacht, aber diese komische Mathematik eines kommerziellen Programms sollte kein Standard für Einträge in der Wikipedia als GNU/FDL-Projekt werden. Ich persönlich ziehe den Durchmesser vor. Für den Rest kann man Formeln entwickeln (EVA = Eingabe=Durchmesser, Verarbeitung per case-Anweisung, Ausgabe=scale für kml). -- Simplicius 19:40, 9. Feb 2006 (CET)

F

Nehmt nach meiner obigen Formel die reale Ausdehnung in Metern mal den Faktor 10 (15) und nennt das ganze, weil es egal ist wie es heißt, scale. Damit kommt man der Variante B sehr nahe jedoch können die Formatvorlage, die Tools wie hjl_get_Coor und die bereits getätigten Eingaben erhalten bleiben. Kolossos 21:33, 3. Feb 2006 (CET)

Weist Du, wieviele Eingaben es bisher bei "Scale" gibt ? Arcy 18:03, 9. Feb 2006 (CET)

Frag bitte sk, er ist meines Wissens nach der einzigste der das im Moment halbwegs genau beantworten könnte. Kolossos 21:44, 9. Feb 2006 (CET)

Zu deinen Anmerkungen zur Variante B und hjl_get_Coor. Im tool hjl_get_Coor wird mom. die Scale-Angabe immer noch als Google-Map-Scale angegeben bzw. von der Google-Map ausgelesen. Die Angabe hat aber mit der realen Ausdehnung der Karte erstmal nichts zu tun (man beobachte die Veränderungen in der Massstabsleiste bei Verschiebung des Kartenausschnittes bei gleicher Scale-Angabe zu den Polen oder zum Äquator hin). Dein Faktor 10 (wieso erwähnst du 15) hilft da auch nicht weiter. Arcy 22:09, 9. Feb 2006 (CET)

Ok ich habs gemerkt, die scale Angaben von hjl_getCoor mit GoogleMaps taugen nicht viel. Wenn man danach die Kvaleberg-Testseite aufruft und darin GoogleMaps dann stimmt schon nix mehr. Den Faktor 15 hatte ich für Deutschland oben schonmal ermittelt, mit Faktor 10 ließe sich einfacher rechnen. Die Abweichung hin zum Aquator halte ich für vertretbar und an den Polen haben wir nur sehr wenige Einträge. Kolossos 23:24, 9. Feb 2006 (CET)

Es sind die original Scaleangaben von Google. Der Grund warum die Scaleangabe nicht funktionieren sind die unterschiedlichen Größen der Kartenfensters. Arcy 00:08, 10. Feb 2006 (CET)

Auf welche Kartengröße beziehst Du dich? Arcy 23:52, 9. Feb 2006 (CET)

Dein System geht imho auch von realen Größen aus (sein es nun cm, m oder km). Mal 10 genommen wird ja eigentlich nur ne "andere Maßeinheit" daraus, weshalb es keinen Sinn macht die Originalmaßeinheit nicht zu verwenden. Das x 10 nehmen kriegt die Kvaleberg schon hin.Arcy 00:08, 10. Feb 2006 (CET)

Mein System basiert auf der Abmessung in Metern mal 10. Was ist daran so schwierig zu verstehen? Wenn man Google-Maps über den Kvaleberg-server damit aufruft ist das bei mir Auflösungsunabhängig, ein halbwegs quadratisches Fenster mal vorrausgesetzt. Da ich persönlich eine Abweichung von +/- 40% für vertretbar halte, gilt mein Vorschlag für den ganzen Erdball. Hast du schon mal versucht mit Egil Kvaleberg in Kontakt zutreten, ob er seine Software ändert. Es ist nähmlich schwer da eine Antwort, geschweige denn eine Programmänderung, zu bekommen. Deshalb ist mein Vorschlag zwar ungenau aber er funktioniert. Ist euch eigentlich schon aufgefallen, dass Kvaleberg mit der Type-Angabe arbeitet so werden Städte im brauchbaren Maßstab 1:100.000 angezeigt, Landmarks jedoch im Maßstab 1:10.000. Es geht also auch so. Kolossos 20:30, 10. Feb 2006 (CET)

Ich stimme Kolossos zu. "Scale" ist laut Handbuch Google Earth die "Entfernung" zur Erdoberfläche, sprich zum Beispiel 10.000 m. Letztendlich heisst das ohne definierten Winkel nicht viel. Aber es geht hier ja um zwei Sachen a) Aufruf über kvaleberg b) Aufruf über die kml-Dateien. Der Typ "city" kann ja grösser gewählt werden, der Typ "landmark" feiner. In der Regel wird man damit schon hinkommen. Alles Weitere ist auf lange Sicht möglicherweise nur Datenmüll. -- Simplicius 21:30, 10. Feb 2006 (CET)

Weiteres Verfahren

Wie soll - um zu einer Entscheidung zu kommen - bezüglich der Scale-Angabe weiter Verfahren werden?

• besteht weiterer Diskussionsbedarf ?
• Wollen wir hier drüber abstimmen?
• Soll diesbezüglich ein Wikipedia:Meinungsbild initiert werden?

-- Arcy 17:50, 3. Feb 2006 (CET)

Um ehrlich zu sein hab ich auf ein Meinungsbild dazu keine Lust, weil ich die Scale-Angabe noch nie benutzt habe, sorry. Kolossos 21:35, 3. Feb 2006 (CET)

hier abstimmen! --Langläufer 23:42, 9. Mär 2006 (CET)

Alles zur Notation der Parameter im Ausgabenteil (Grad-Zeichen, Zeilenumbrüche etc.)

Lesbarkeit

Ohne irgendeine Abtrennung zwischen Breite und Länge finde ich das zu schwer lesbar. Wäre nicht so etwas besser: 40° 30' N, 20° 15' O? --Langec ☎ 16:01, 9. Mär 2005 (CET)

Fänd ich auch ganz gut. --rdb? 16:31, 9. Mär 2005 (CET)

Parameter

Warum muss man denn die Angaben doppelt machen? Kann das nicht so gelöst werden, dass man bloß die Gradangaben (mit °, ' und ") als Parameter angibt und dann auf der externen Seite das entsprechend ausgewertet wird? Das wäre wesentlich weniger Aufwand. --::Slomox:: >< 03:53, 10. Mär 2005 (CET)

Soweit ich das aus der englischen Seite sehe, soll es auch möglich sein Angaben in UTM und anderen Koordinatensystemen anzugeben. Dort wäre die Gradzeichen unpassend. --sk 09:24, 10. Mär 2005 (CET)

E (East) oder O (Osten)

• Bei Deutsches Technikmuseum findet man die Vorlage:Geokoordinate mit "O". Es ist nicht einleuchtend, warum bei Wikipedia:WikiProjekt Georeferenzierung "E" als Beispiel / in allen Beispielen verwendet wird. Gangleri | Th | T 14:19, 20. Mär 2005 (CET)

Das liegt wohl daran, dass das "E" als Übergabeparameter herhalten muss. Das E ist also für das Erstellen der Vorlage einfacher, das O sollte aber im angezeigten Text anstelle dessen verwendet werden, da hast du Recht. Ich bin mal so frei und ändere dies um. --BLueFiSH ?! 14:47, 20. Mär 2005 (CET)

Danke! Gangleri | Th | T 15:10, 20. Mär 2005 (CET)

E ist Standard, nicht O! Siehe weiter unten: "Notation"! Leonach 00:46, 23. Jul 2005 (CEST)

• Habe mir noch einige Beispiele bei Spezial:Whatlinkshere/Vorlage:Koordinate angeschaut: Wuppertal, Mount Elgon, Biały Bór. Persönlich halte ich "s. Br." / "n. Br." bzw. "w. L." / "ö. L." für die geeignesten Abkürzungen. Sobald Konsensus darüber besteht, sollte ein Bot dies "vereinheitlichen". Gruß Gangleri | Th | T 15:22, 20. Mär 2005 (CET)

Dezimaltrennzeichen

Konsequent wäre die Verwendung des Komma als Dezimaltrennzeichen, insbesondere in den Beispielen ... (sonst müssen wir doch die ganze de-WP auf den Punkt umstellen :-) ich wäre ja dabei, aber das ist aussichtslos) -- Schusch 14:31, 20. Mär 2005 (CET)

Hab ich gleich mal mit geändert, also Komma jetzt im dritten Teil des Vorlagenbeispiels. Problematisch war es aber mit dem Komma als Abtrennung von N- und O-Angabe, ich habe diese jetzt mit einem "-" voneinander abgetrennt. (ich verwende aber die Dezimalschreibweise sowieso nicht, weil ich die Parameter recht einfach umrechnen kann) --BLueFiSH ?! 14:54, 20. Mär 2005 (CET)

Ich würde dann aber eher – statt - nehmen. Letzteres ist ja der Bindestrich. Noch besser wäre doch das Semikolon. Stern !? 02:18, 29. Mär 2005 (CEST)

Notation

Es ist leider noch eine Krankheit, dass wir im deutschsprachigen Bereich keine internationale Schreibweise haben. Wir wollen natürlich lieber O statt E, dann brauchen wir natürlich auch ein "," statt einem "." als Dezimaltrennzeichen und als Tausendertrennzeichen ein "." statt einem "," und die Geodäten rechnen (nur in Deutschland) natürlich in "gon" statt "Altgrad". Demzufolge können die Angaben nicht einfach für einen anderssprachigen Artikel 1:1 übertragen werden.
Es wäre aber schön, wenn man sich vor Beginn der Umsetzung auf das Format einigen könnte, damit man sich nicht jede Arbeit doppelt und dreifach macht (wie bei den Kategorien). -- Simplicius ☺ 13:37, 4. Apr 2005 (CEST)

Zur Genauigkeit, hat es schon mal jemand ausgerechnet? Eine Angabe der geographischen Breite ergibt auf Grad gerundet: ± 55,6 km, auf Minute gerundet ± 926 m, auf die Sekunde gerundet ± 15 m. -- Simplicius ☺ 13:49, 4. Apr 2005 (CEST)

yepp.

Ich hab mir bei meinen letzte geo-ref orgien vom geo wiki einige gps dezimalnotationen vom in DMS (grad, minuten, sekunden) umrechnen lassen. Es ist das einfachste, den text dort zu kopieren und als sichttext zu verwenden. Dessen format kann man ja nochmal leicht editieren, aber von meiner urspruenglichen intuition (n.Br. ö.L.) bin ich dann doch abgekommen, das ist einfach zuviel aufwand, und ein typischer leser versteht (x N y O) problemlos. Das eine E in O zu tauschen ist fix gemacht. Immer an die verstaendlichkeit halten.

Was ich allerdings auch viel gemacht hab, ist einige leerzeichen herauszukuerzen, also 5° 20' zu 5°20'. Das sieht in meinen augen eh gefaelliger aus, und faellt bei {Koo} angaben auch nicht so schnell dem zeilenumbruch zum opfer. Egal wie, vielleicht man den kvaleberg geo wiki meister kontakten, fuer refs vom de.wiki ein ansprechendes format zu verwenden, dann wird sich m.E. ein gemeinsamer standard der artikel automatisch einstellen?!! Guidod 22:12, 4. Apr 2005 (CEST)

Wobei man das anpassen kann - probiert mal , die eine Angabe "region:DE" enthält. Zur Anschauung habe ich die Kvaleberg Seite ins deutsche übersetzt, sodass die Angabe region:DE bewirkt, dass ein Klick auf die Koordinate zu deutschen Hinweisen führt. Dort kann man sich auch etwas austoben, welche Kartenquellen man nach oben schieben möchte. *g* Guidod 00:28, 5. Apr 2005 (CEST)

nur damit ihr nicht denkt, eure Meinung ist die einzige - selbstverständlich bin ich für die korrekten Leerzeichen (also: 5° 20') - bisher machen wir eigentlich typographisch so ziemlich alles richtig, da kriegen wir das auch noch hin. Und wenn einer das halt schludrig ohne Leerzeichen einträgt, soll mir das auch egal sein, solange niemand die Leerzeichen absichtlich wieder entfernt! Das wäre dann ein Edit mit absichtlicher Veränderung zu einer Falschschreibung und das fände ich gar nicht gut. Gruß, -- Schusch 23:06, 5. Apr 2005 (CEST)

uiuiui, verweis auf typographisch als autoritaetsbeweis. Da gibt es nur ein paar probleme, erstens scheint es eine solche fixe typographische regelung nicht zu geben, und zweitens neigen klassische verwendungen von geokoordinaten im buchdruck sogar zur langform - "und liegt bei 20° 20' östlicher Länge", woraus dann der usus enstanden ist, bei häufiger verwendung von koordinaten in einem abschnitt dieses zu "ö.L." abzukürzen, was einen jedoch nicht entbinden sollte, es wenigstens einmal in langform zu schreiben.

(zur ergänzung sei erwähnt, dass "°" als logograph gewertet werden kann, also als ein "wortzeichen", sodass strenggenommen auch zwischen zahl und logogramm ein nbsp leerraum gehoert. Es hat sich jedoch scheinbar ueber die Jahre eingebuergert, logogramme mit zahlen zu koppeln, also "§20" statt "§ 20" und "20%" statt "20 %" zu schreiben - mir duenkt, viele logotypen sind im schriftsatz heute so gestaltet, dass sie engstehend gut lesbar sind).

Bei der verwendung in wikipedia haben wir es jedoch weitgehend mit einer annotation zu tun. Zu moeglichen verwendungen ein paar beispiele.

(a) die einbettung in kasten unter dem stichwort "geographische lage" beziehungs zwei stichworten "laenge / breite". Da die Schreibung mit leerzeichen und "ö.L." immer noch recht lang ist, braucht es zwei zeilen. Statt autoformatierung mit "51°&nbsp;20'&nbsp;n.Br. 12°&nbsp;23'&nbsp;ö.L." ist es üblich geworden, mittels der quellenschreibung "51° 20' n. Br. <br /> 12° 23'" den satz von zwei zeilen zu erzwingen. Natürlich mit der intuition, dass gradangaben und richtung als eine zusammengesetzte angabe behandelt werden sollten, die nicht getrennt gehoeren. (bspw. Leipzig)

(b) arbeitet man dagegen mit kurzformen, wie "N" und "O" für die richtung und zusammenschreibung, dann kann man solche angaben auch in ein feld des uebersichtskastens schreiben. Vermittels nur einer zeile, etwa in der form "51°46' N 14°20' O". Durch den verweis auf "geographische Lage" ist hier "N" und "O" erklaert, obwohl im deutschen ein "Northing" und "Easting" wert eher unublich sind (ausser natuerlich im militaerischen sprachgebrauch). Die kompakte Schreibweise macht hier durchaus sinn (bspw. Cottbus).

(c) zusätzlich sind kompakte formen günstig bei der annotation von listenformen, in denen die koordinaten dazugetragen werden. (mea culpa), statt [1] steht dann wenigstens eine grundangabe der koordinate [51°46' N;14°20' O], sodass auch bei einem buchsatz sich ein hinreichender verweis auf die kartenangabe findet. (bspw. Seddin).

Meine eigene intuition neigt dazu, die geokoordinate als zusammengesetzes wort zu betrachten, in der das "°"-symbol die rolle eines trennzeichens aehnlich dezimaltrenner oder tausendertrenners spielt. (vor zeiten war typographisch mal angesagt, als tausendertrenner ein nbsp zu verwenden, also "12 345,67"). Die schreibung als "20°12'" ist in meinen augen gefaellig, doch bekanntlich laesst sich ueber geschmack streiten.

Abschliessend ist zu sagen, dass bei verwendung von {Koordinate} man sehr leicht einen bot schreiben kann, der die sichtnotation anpassen kann (der geht dann ueber "whatlinkshere"). Das schliesst auch die moeglichkeit ein, dass der bot einfache oder fehlende leerzeichen durch "nbsp" zeichen ersetzen kann. Bis dahin gilt halt erstmal jene notation in den texten, die von jenen eingetragen wird, die sich um die koordinaten annotation arbeitsmaessig kuemmern. (auch solche dinge wie in Chemnitz).

Bleibt zu klaeren, welche notation denn nun bevorzugt wird bzw. welche varianten man denn sanktionieren moechte. Das kann man hier oder spaeter tun - die anpassung per bot ist schnell gemacht, die anpassung der artikel auf {Koordinate} ist erstmal nicht so einfach, da man die in texte enthaltenen koordinaten erstmal semantisch eindeutig maschinenlesbar aufbereiten muss, bis man einen bot drueberjagen kann. Guidod 14:15, 6. Apr 2005 (CEST)

bei so viel Fachwissen bin ich als Laie mal ganz schnell ruhig :-) Gegen N, O, S und W habe ich nicht das geringste einzuwenden, kurz soll es ja sein. Wenn über die Jahrzehnte die Logotypische konotative Typographie (ja, schlagt mich :-) durch Schreibmaschinen und 40-x-80-Zeichen-Bildschirme leicht "verkommen" ist, müssen wir das ja nicht mitmachen ... aber ich wollte nur mal ein kleine Gegengewicht in die Waagschale werfen, mehr nicht ;-) -- Schusch 21:46, 6. Apr 2005 (CEST)

*lach* yepp, mein DTP prof hat sich auch bitterlich beschwert, wie die jahrhunderte der erfahrungen des buchdrucks weggewischt werden. Dazu muss man bloss in eine uebliche tageszeitung schauen, wieviele worte falsch getrennt werden, weil niemand aber auch wirklich niemand eine schlusslesung vor dem druck (mehr) macht. Aus dieser schnelligkeit vom eintippen zur automatischen formatieren resultiert dann auch, dass sich kaum jemand um varianten von leerzeichen und verbindungsstrichen schert (obwohl die Webtypografie das meiste bereitstellen wuerde).

Ich bin ja auch ein fan von schoener typografie, aber aus purer technischer bequemlichkeit tendiere ich denn doch dazu, eine vereinfachte variante zu bevorzugen, die in der praxis hinreichend gut funktioniert. Und schlag mich, ich werd nicht behaupten, dass es das wuenschenswert beste waere. Ueber eine saubere brauchbare notation sollten wir uns aber schon gedanken machen. Ich nehme mal an, NOSW ist aus rein praktischen gruenden schon fast beschlossene sache, bleibt halt noch der "rest". *g* Guidod 23:58, 6. Apr 2005 (CEST)

Wir haben in Deutschland eine einheitliche Schreibweise, nämlich die, die in der Navigation verwendet wird. Nachzulesen in DIN 13312. Danach werden Koordinaten in folgendem Format geschrieben:
XX° XX,XX' N/S
XXX° XX,XX' W/E
Nicht O! Breitengrade immer zweistellig, Längengrade immer dreistellig, Bogenminuten dezimal unterteilt. Dieses Format sollte auch bevorzugt werden. Leonach 00:43, 23. Jul 2005 (CEST)

Symbole für Bogenminute und -sekunde

Im Abschnitt Nutzung der Vorlagen wird als Beispiel genannt: 59° 55′ 10" N. – Sind das die korrekten Zeichen?
In Bogenminute heißt es nur, das Symbol würde einem Apostroph ähneln (59° 55’ N? 59° 55' N?). Entsprechend soll das Symbol für die Bogensekunde dem Anführungszeichen ähneln. --kh80 •?!• 23:13, 29. Mai 2005 (CEST)

korrekt für.... was? --Guidod 23:30, 29. Mai 2005

Für den Gebrauch in der Wikipedia. Oder worauf willst du hinaus?

Das Minutensymbol im Beispiel wird von meinem Internet Explorer sehr unschön dargestellt: Es sieht so aus, als seien hinter dem Symbol zwei Leerzeichen anstelle von einem. Meine Frage war also kein Nitpicking ... Auf der externen Spezialseite wird übrigens auch ein anderes Sekundenzeichen (″) verwendet. --kh80 •?!• 00:01, 30. Mai 2005 (CEST)

Also geht es um Windows-Explorer-Installations-Probleme. Aha. Die kann ich natuerlich nicht nachvollziehen. Die Frage Dich mich bewegt ist eher, was Du damit anfangen willst? Willst Du bestimmte Zeichen verbieten? Willst alle Artikel durchgehen, in die die schlecht-darstellbaren Zeichen auftreten? Worauf zielst du? GuidoD 00:12, 30. Mai 2005 (CEST)

Hab ich Dich mit der Frage irgendwie auf dem falschen Fuß erwischt? Deine Antwort klingt recht grantig ...

Ich wollte einfach nur in ein paar Artikeln die Vorlage verwende und dabei gerne auch die richtigen™ Symbole gebrauchen. Weder will ich meine Editzahl pushen, indem ich alle Artikel durchgehe, noch will ich irgendwem irgendwas verbieten. --kh80 •?!• 00:46, 30. Mai 2005 (CEST)

Neee, die einzig richtigen™ Symbole gibt es hier nicht. Ganz simpler hintergrund: es gibt keine speziellen unicodes dafuer, die fuer ein "nachgestelltes einfaches apostroph" und "nachgestelltes doppeltes apostroph" gelten wuerden. Insoweit kann man sich nur der historischen papiernen typographie annaehern (so man das ueberhaupt will). Über angeschraegt oder nicht braucht man sich da noch nichtmal unterhalten - die diskussionen koennen ewig lang werden. Bei Wikipedia:Typografie#Weitere_Zeichen tendiert man zu den geraden ascii apostroph '/". Das macht auch am wenigsten probleme mit existen schriftschnitten. (auch weil im englischen sprachraum genau diese zeichen lange als zollzeichen herhalten mussten). Sowas wie ’/” koennen viele an ihrer tastatur gar nicht eingeben, und die zeichenfolge 00’00” hat bei mir im monospace einen (korrekten) drall nach links an der zahl, im helvetica-aehnlichen standardschnitt aber ein kerning nach rechts, das mittel-apostroph liegt glattweg über dem linken oberen bogen der dritten null. Tatsaechlich kann dir der typographische kram voellig egal sein, solange du ein einstrich/doppelstrich-aehnliches zeichen nimmst, und die georef angabe mittels einem semantischen markup {koordinate|x} ummantelst. Bei einer drucklegung koennen dann aufgrund der semantischen auszeichnung alle verschiedenheiten der zeichen in der quelle uebergebuegelt werden. Und wenn ich etwas grantig klinge: fass mir ja nicht tausend artikel an, und aendere die apostroph. Was immer irgendwie nach einem einfachapostroph oder doppelapostroph aussieht, sollte erstmal okay sein. GuidoD 01:34, 30. Mai 2005 (CEST)

Die tausend Artikel lass ich in Ruhe, versprochen. ;-) Vielen Dank für Deine ausführliche Auskunft. :-) --kh80 •?!• 03:30, 30. Mai 2005 (CEST)

Also, so wie ich [4] lese, ist ’ das „einzig korrekte“ Zeichen für Bogenminuten. --::Slomox:: >< 02:59, 21. Jul 2005 (CEST)

BR und NBSP und Browser

Durch unglueckliche Umstaende wander ich derzeit des oefteren mit dem Microsoft Explorer 6.0.x durch die Wikipedia Bestaende. Dabei fiel mir eine Unart ins Auge - der bricht die Koordinaten nach scheinbar wilden Regeln. Ein kleiner Test auf der Wikipedia:Spielwiese erhellte meinen Geist. Lasst mich berichten.

Zuerst mal, es ist in einigen Orts-Artikeln schon voellig ueblich, die Koordinate mittels hartem <br> anzugeben - womit die Angabe immer zweizeilig wurde obwohl die Koordinate in den sehr vielen Faellen auch auf eine Zeile passt. Aber man geht falschen Umbrueche aus dem Wege, wenn da Leerzeichen zwischen X° und Y' steht. Nun gut, ich hab da einfach mal auf die &nbsp; Schreibung umgestellt, und oftmals die Grad/Sekunden zusammengeschrieben. Was durchaus korrekt ist - aber...

Wenn der Microsoft Explorer 6.0.x folgendes sieht:
..... 52°00'00"&nbsp;N 10°00'00"&nbsp;O
dann laesst er es durchaus zu, nach dem 10° einen Umbruch einzufuegen. Das sieht dann voellig haesslich so aus:
52°00'00" N 10°
00'00" O

Aber irgendwie macht er das nicht immer. Wenn man naemlich nach dem Grad-Zeichen noch einen Hardspace einfuehrt, dann wird er nicht mehr nach dem Grad-Zeichen trennen wollen. Also, eine Schreibung der Form
..... 52°&nbsp;00'&nbsp;00"&nbsp;N 10°&nbsp;00'&nbsp;00"&nbsp;O
wird immer das richtige ergeben, naemlichst
52° 00' 00" N
10° 00' 00" O

Diese Unart duerfte damit die beste Schreibung fuer Koordinaten fixieren: zwischen die Grad-Zeichen, Sekunden-Zeichen usw gehoert jeweils ein Leerraum, und zwar ein Hardspace &nbsp; gesetzt. Dann wird bei mangelndem Platz auch tatsaechlich zwischen den beiden Koordinatenhaelften umgebrochen. Und zwar nur dann, wenn mangelnder Platz. GuidoD 6. Jul 2005 18:46 (CEST)

Was genau ist der Gedanke hinter den ungleichen Abständen zwischen Grad und Minute (nbsp)und Minute und Sekunde (Leerzeichen + nbsp)? Das sieht gar nicht gut aus! Auch zwischen Sekunde und Himmelsrichtung steht Leerzeichen + nbsp, was meiner Meinung nach zu viel des guten ist. fragwürdig ?! 08:05, 13. Okt 2005 (CEST)

Ich versteh die Frage nicht. nbsp folgt hinter Grad, Minute und Sekunde. Zwischen der Ziffer und nbsp folgt das Einheitenzeichen. Denk nochmal über deine Frage nach. --BLueFiSH ?! 22:25, 13. Okt 2005 (CEST)

Vielleicht auch einfach mal vorne in der Hauptseite gucken, da steht geschrieben wie es aktuell gemacht wird: Wikipedia:WikiProjekt_Georeferenzierung#Vorlagen-Ausgabetext --BLueFiSH ?! 22:29, 13. Okt 2005 (CEST)

Denk du bitte lieber über deinen Ton nach. Ich bin doch nicht blöd und schreibe sowas aus Jux und Dollerei. Der Abstand nach Minuten- und Sekundenzeichen war definitiv größer als nach dem Gradzeichen. fragwürdig ?! 22:42, 13. Okt 2005 (CEST)

Ich denke... kein Fehlverhalten erkannt. Ums nochmal auf den Punkt zu bringen: wahrscheinlich hast du eine schlecht formatiertes Koordinate gesehen, denn so wie es aktuell eingefügt wird, entspricht es nicht dem von dir geschilderten Aussehen. Wenn du nen Link anbringst, kann man sich davon auch ein Bild machen. --BLueFiSH ?! 00:21, 14. Okt 2005 (CEST)

Gerne: Paldiski, allerdings offensichtlich nur im IE6.0 bei mir auf Arbeit. Genauer besehen scheint das Problem zu sein, daß die Sekunden- und Minutenzeichen beim benutzten Font fast so aussehen als ob ein Leerzeichen hinten dran hängt. Ich habe jetzt keine Zeit zum Hochladen, aber am Montag oder Dienstag könnte ich mal einen Screenshot präsentieren. fragwürdig ?! 08:37, 14. Okt 2005 (CEST)

In Paldiski wird ein &nbsp; als Trennzeichen der Koordinatenausgabe gar nicht verwendet. Habs aber jetzt mal angepasst. --BLueFiSH ?! 08:44, 14. Okt 2005 (CEST)

Es sieht leider immer noch falsch aus. Wie gesagt, es scheint ein Problem der Sekunden- und Minutenzeichen zu sein und nicht des &nbsp;. Hier ein Beispiel:

-- fragwürdig ?! 14:29, 14. Okt 2005 (CEST)

ja, so sollte es natürlich nicht aussehen, aber bei meinem Firefox 0.8 und IE 6 (SP1) sieht es nicht so aus wie bei dir. Ist das denn die Regel oder nur eine Ausnahme bei diesem speziellen Artikel? --BLueFiSH ?! 14:46, 14. Okt 2005 (CEST)

Leider die Regel (stichprobenartig getestet) im IE 6.0 SP2. Ich werde das aber später noch mal bei mir zuhause im IE testen. fragwürdig ?! 15:19, 14. Okt 2005 (CEST)

Erstaunlich, die Energie, welche hier in doppelte Information gesteckt wird. Was spricht dagegen, wenn man sich auf Dezimalangaben konzentrieren könnte? Im Archiv habe ich bisher keine Argumente dagegen gefunden, lasse mich aber gerne belehren. Die DIN-Norm jedenfalls wird hier ja auch nicht eingehalten! Habe zudem an anderer Stelle schon darauf hingewiesen, dass man die Koordinaten-Angaben nur einmal eintragen sollte; diese Angaben können im Wikitext dann automatisch formattiert werden (und zwar für das ganze Wiki einmal definiert und zentral abgelegt - da kann man dann die Darstellung so lange ändern, bis sie allen gefällt...) -- Geonick 15. Okt. 2005 (CEST)

Es werden schräge statt gerader Ticks verwendet. Die Stichprobe ist fragwürdig, da ich es selbst nie verwende. Ich hab das im Ursprungsposting auch nie empfohlen, die Anzeige des "Sekundenzeichens" war mir verschiedentlich zu grausam. Tatsächlich ist, von mir leider bisher unbemerkt, die Verwendung des schrägen Sekundenzeichens statt gerader Apostroph/Gänsefüsschen auf die Hauptseite dieses Artikels gekommen, und wird in der copy-n-paste Vorlage auf kvaleberg vorgegeben. Ich betrachte das als groben Fehler. GuidoD 02:23, 31. Okt 2005 (CET)

Apostrophierung

Ich wuerde gern die Artikelseite und die kvaleberg copy-n-paste Vorlage auf gerade Apostroph/Gänsefüsschen anpassen - die Sekundenzeichen sind typographisch korrekter, aber in der Browserdarstellung viel zu uneinheitlich. Die Ascii-Striche haben dagegen über die Jahrzehnte eine sinnvolle Darstellung gefunden, und sind in der Verwendung an Stelle der speziellen Minuten/Sekundenzeichen schon längst verbreitet.

Eine verwandte Diskussion gibt es in Wikipedia Diskussion:WikiProjekt_Georeferenzierung/Archiv1#Symbole für Bogenminute und -sekunde, wobei damals noch typisch ohne dazwischenliegendem Extra-Leerraum gearbeitet wurde - Zitat:

die einzig richtigen™ Symbole gibt es hier nicht. Ganz simpler hintergrund: es gibt keine speziellen unicodes dafuer, die fuer ein "nachgestelltes einfaches apostroph" und "nachgestelltes doppeltes apostroph" gelten wuerden. Insoweit kann man sich nur der historischen papiernen typographie annaehern (so man das ueberhaupt will). Über angeschraegt oder nicht braucht man sich da noch nichtmal unterhalten - die diskussionen koennen ewig lang werden. Bei Wikipedia:Typografie#Weitere_Zeichen tendiert man zu den geraden ascii apostroph '/". Das macht auch am wenigsten probleme mit existen schriftschnitten. (auch weil im englischen sprachraum genau diese zeichen lange als zollzeichen herhalten mussten). Sowas wie ’/” koennen viele an ihrer tastatur gar nicht eingeben, und die zeichenfolge 00’00” hat bei mir im monospace einen (korrekten) drall nach links an der zahl, im helvetica-aehnlichen standardschnitt aber ein kerning nach rechts, das mittel-apostroph liegt glattweg über dem linken oberen bogen der dritten null. Tatsaechlich kann dir der typographische kram voellig egal sein, solange du ein einstrich/doppelstrich-aehnliches zeichen nimmst, und die georef angabe mittels einem semantischen markup {koordinate|x} ummantelst. Bei einer drucklegung koennen dann aufgrund der semantischen auszeichnung alle verschiedenheiten der zeichen in der quelle uebergebuegelt werden. Und wenn ich etwas grantig klinge: fass mir ja nicht tausend artikel an, und aendere die apostroph. Was immer irgendwie nach einem einfachapostroph oder doppelapostroph aussieht, sollte erstmal okay sein. GuidoD 01:34, 30. Mai 2005 (CEST)

Umstellung auf gerade Apostroph?

•  Pro GuidoD 20:10, 31. Okt 2005 (CET)
• bin da leidenschaftslos, der schräge Apostroph hat sich halt so eingebürgert, dass das " in diesem Zusammenhang auch der falsche Strich ist, hab ich bisher gar nicht mitbekommen. Was ich als Abart schon mehrfach gesehen habe, war, dass der " mit '' (also zwei mal ') und manchmal sogar als <nowiki>''</nowiki> geschrieben wurde, weil er ja kursiv macht ;-) Das leichtere Eintippen wär natürlich schon von Vorteil. Auf den ' ändern tu ich es auch nur wenn ich sowieso was im Artikel ändere, sonst juckt es mich nicht. Aufgrund von Wikipedia:Typographie#Weitere Zeichen bleib ich aber neutral in dieser Frage. --BLueFiSH ?! 22:06, 31. Okt 2005 (CET)
• Neutral bis  Pro Habe mir die Argumente durchgelesen und denke man kann/soll Erfassung und Darstellung strikt trennen (wird auch mehrmals hervorgehoben). Erfassung: bequem erfaßbar, Code gut lesbar, Mehrdeutigkeiten sollten egal sein (sofern durch Software kompensierbar). Darstellung: mir persönlich in diesem Fall egal, soferne es nicht "optimiert" für MS Internet Explorer ist. ;-) Roland2 22:34, 31. Okt 2005 (CET)
•  Pro --Zubi 11:31, 30. Nov 2005 (CET)
• Im Prinzip  Pro – ' und " sind jedenfalls besser (und außerhalb Wikipedias gebräuchlicher) als die Varianten ' und ? aus den Tiefen der Unicode-Spezifikation, die in der Darstellung (jedenfalls auf Windows-Systemen mit Standardschriftarten) zu horriblen Ergebnissen führen (zumal sie den vorgesehenen Leerabstand nach dem Minuten- und Sekundenzeichen bereits enthalten, was in den Georeferenzierungsrichtlinien allerdings ignoriert wird). Am besten finde ich aber die typographisch korrekten Zeichen – ’ (Alt + 146) und ” (Alt + 148) –, die ich selbst auch immer verwende. (Ich habe hier die jeweiligen Sonderzeichen bewusst in größerer Schrift eingefügt, um die Unterschiede zu verdeutlichen.) --Alib 11:02, 2. Dez 2005 (CET)

It's a wiki. Da keine Ablehnungen auf die "Auf jeder Tastatur zu findenden"-Standard-Striche kommen, "erlaube" ich der Pro-Fraktion die Änderung in vorstehender Seite und einigen Formatvorlagen. ;-) --BLueFiSH ?! 22:00, 2. Dez 2005 (CET)

Typographische korrekte Zeichen für Bogenminute und Bogensekunde

Die typografisch korrekten Zeichen für Bogenminute und Bogensekunde sind ′ und ″ (Wikipedia:Typografie#Weitere Zeichen). Laut Wikipedia:WikiProjekt Georeferenzierung#Vorlagen-Ausgabetext sollen diese Zeichen für Probleme bei der Darstellung sorgen. Als Alternative sollen die Zeichen ' und " verwendet werden. Derzeit finde ich häufig neue Koordinateneinträge, bei denen ein Mix verwendet wird: ′ für Bogenminute und " für Bogensekunde [5]. Gibt es dafür eine Begründung? Sollte in Zukunft nicht besser einheitlich die typografisch korrekten Zeichen verwendet werden und die Anleitungen entsprechend angepasst werden? --Fomafix 20:39, 16. Aug 2006 (CEST)

In Zukunft sollte es nicht möglich sein, dass Benutzer sich darüber noch den Kopf zerbrechen müssen. Siehe obige Seitenlange Diskussionen. --BLueFiSH ✉ (Klick mich!) 21:09, 16. Aug 2006 (CEST)

Vereinheitlichung des Ausgabetextes

Sollte man nicht die Ausgabe der Koordinaten bezüglich der Längen- und Breitengrade vereinheitlichen? Ist das Verwenden von „N“ und „O“ besser als das von „n. Br.“ und „w. L.“? Momentan existieren beide Versionen, auch auf der Seite des Wikiprojekts werden beide Möglichkeiten angegeben.--Borheinsieg 16:15, 25. Aug 2006 (CEST)

Ich verwende nur noch „N“ und „O“ und finde diese Version auch am besten. Die Ausdrücke „n. Br.“ und „w. L.“ sind meiner Meinung nach zu lang. Bei einigen Artikeln habe ich diese Abkürzungen sogar schon ausgeschrieben gesehen! Zumindest auf der Projektseite sollte man sich auf eine Version einigen, um bei Neueinsteigern ein Kopfzerbrechen zu vermeiden. Auch ich habe mich als Neuling vor noch nicht allzu langer Zeit über diesen Widerspruch gewundert. -- Roemer 11:19, 26. Aug 2006 (CEST)

Mir persönlich gefällt die Version „n. Br.“, „ö. L.“ usw. besser, denke aber auf jeden Fall, dass es eine Einheitlichkeit geben sollte. Stefan Kühn, der ja sicherlich ein Hauptinitiator des Projektes ist, verwendet jedenfalls die Version mit n. Br. und ö. L. Daher hatte ich auch gedacht, diese Version wäre richtig, aber scheinbar gibt es ja (noch) keine einheitliche Regelung.--Borheinsieg

Das größte Problem das N/O haben, ist das das O gerne mal aks Null geschrieben wird. Bei ö.L. geht das schlecht. Aber letztendlich ist es Geschmackssache. Frage: Warum muss es einheitlich sein? Beides ist doch verständlich. Wenn ihr sowas Wikiweit ändern möchtet, dann macht doch einfach ein kleines Meinungsbild. So, jetzt geh ich erst mal in Urlaub! :-) -- sk 22:18, 26. Aug 2006 (CEST)

Es muss nicht unbedingt einheitlich sein, schöner wäre es schon. Aber so wichtig ist mir die Sache auch nicht, um deshalb ein Meinungsbild anzuleiern. Beides ist ja verständlich.--Borheinsieg 10:55, 27. Aug 2006 (CEST)

w.i.m.r.e. ist "ö.L." halt einfach die historische Angabe, und im Fließtext kann es ja auch schon mal zu Verwechslungen mit Richtungsangaben (NNW) kommen. Bei der Integration in Tabellen würde ich immer zu N/O zuraten, aber bei Fließtext eher abraten - im Gegenteil, ich find es da mit ö.L. ansehnlicher, aber N/O ist modernerweise ja doch recht bekannt, kann man aber muss man nicht machen. Insofern, mal nix vereinheitlichen - wenn es zu Verwirrungen in der WP:GEO Beschreibung kommt, müssen wir uns dafür halt was einfallen lassen. Gruß, GuidoD 12:49, 27. Aug 2006 (CEST)

Dezimalgrad

Es hat hier wahrscheinlich schon Diskussionen darüber gegeben, ich habe aber auch im Archiv nichts wirklich aufschlußreiches gefunden - nur Anspielungen: Warum schlagen wir uns hier eigentlich mit Minuten und Sekunden herum? Dezimalgrad sind doch viel praktischer, alle Gis-Software arbeitet mit Dezimalgrad, auch GoogleEarth, GoYellow verlangen Dezimalgrad und geben sie auch so aus. Die dauernde Umrechnerei ist nicht nur nervig sondern auch sehr fehleranfällig, sogar diverse Tools leisten sich da Ausrutscher. Und was kann man dan mit den Minuten und Sekunden anfangen? Kann sich wirklich jemand unter 50°31'29,6"N, 6°53'0,8"E mehr vorstellen als unter 50.52489°N, 6.88357°E ? Und dann noch die Sache mit der Typographie - jeder hätte gern andere Striche und wenn man die Koordinaten über die Zwischenablage einer anderen Anwendung zum Fraß vorwerfen will muß man auch Glück haben daß sie sie nicht gleich wieder ausspuckt weil die Formatierung im Hals kratzt - bei Dezimalgrad mindestens ein viel geringeres Problem (da muß man höchstens mal das Gradzeichen abstreifen). Nicht zuletzt werden auch die Benutzer verwirrt, jedenfalls hat einer namens 88.64.151.104 im Artikel Radioteleskop Effelsberg den Koordinatenbaustein verschlimmbessert in {{Koordinate Text Artikel|50.52489_N_6.88357_E_type:landmark_region:DE-NW|(50,312937°N, 6,53100°O)}} Der Link stimmt ja zum Glück noch. Elsaxo 15:46, 26. Jan. 2007 (CET)

Der Screenshot zeigt, dass Google Earth auch GG MM SS,SS anzeigt. Das hat also irgendwie seine Berechtigung. Selbst mein GPS-Empfänger zickt über das NMEA-Protokoll Grad und Minuten-Angaben. Außerdem sind wohl 95 % unserer Koordinaten mit Minuten/Sekunden-Angaben versehen, davon kommen wir nicht so schnell los. (Und ich will es auch nicht.) Intern arbeiten wir bei fast allen Auswerteskripten natürlich mit Dezimalwerten. Kolossos 16:46, 26. Jan. 2007 (CET)

Anzeige und Eingabe sind IMHO zwei verschiedene Paar Schuhe. Die Anzeige als GG MM SS,SS hat einen netten traditionellen geo-romantischen Charakter. Ich halte persöhnlich eine dezimale Angabe auch für praktischer. Umrechnereien, sollten - wo möglich - vermieden werden.--Arcy 17:07, 26. Jan. 2007 (CET)

Mir persönlich gefallen die GG-MM-SS-Werte besser. Sie bieten eine bessere Übersicht, als die langen Dezimalzahlenkolonnen. Es ist auch leichter (auf einen Blick) abzuschätzen, welcher Ort - bei kleiner Differenz - bspw. nördlicher liegt. -- Netnet @ 17:23, 26. Jan. 2007 (CET)

Man mag es Nostalgie nennen oder Romantik, aber mit 10 Fingern zählt der Mensch dezimal und nicht binär, selbst wenn fast die ganze Welt vom Computer beeinflusst ist. Ergo: Sobald die Zeitanzeige (hoffentlich nicht!) auf Dezimalbrüche umgestellt wird, kann oder sollte man die Georeferenzierungen anpassen, vorher besteht kein Bedarf. Gruß --Zollwurf 23:03, 30. Jan. 2007 (CET)

Na, die Finger wären ja eher ein Beispiel für das Dezimalsystem als für das Sexagenitalsystem äh Sexagesimalsystem - aber wie auch immer: so lange brav Vorlagen verwendet werden, kann man das ja jederzeit umrechnen (und vielleicht eines Tages auch den Benutzereinstellungen überlassen). Unausgegorene Vorlagen wie Vorlage:Infobox Ort in der Schweiz (ich glaube, die österreichische ist noch schlimmer) sind da natürlich kontraproduktiv. Und die Standard-Koordinatenvorlage ist eigentlich auch nicht so ganz der letzte Schrei der Vorlagenprogrammierung ... --Reinhard Kraasch 01:03, 31. Jan. 2007 (CET)

Hallo Elsaxo, du hast schon recht, mit reinen Dezimalwerten läßt sich (programmtechnisch) einfacher arbeiten. Das Problem sehe ich in alten Datenbeständen, bei denen Koordinaten nur mit einer Genauigkeit von Grad° und Minuten' verfügbar waren (entweder hatte man nichts genaueres oder wollte es nicht frei rausrücken ;-). Mit solchen Daten kann man schnell 2km daneben liegen. Wenn man solche Koordinaten ins dezimale Format umwandelt, "sieht" ein Bearbeiter nicht mehr, ob es sich um eine genau georeferenzierte oder alte, ungenaue Koordinate handelt - wandel doch zum Beispiel 51°13'32" N, 006°46'58" O sowie 51°13 N, 006°47' O ins Dezimalformat um... Deshalb plädiere ich hier in dieser textbasierte Plattform für die "nostalgische" Schreibform Grad°Minuten'Sekunden". Gruss --Glg 17:58, 16. Feb. 2007 (CET)