Am 19.03.2012 10:04, schrieb Tirkon:
Kolossos<tim.al...@s2002.tu-chemnitz.de> wrote:
Dieses Problem besteht darin, dass sich Nutzers des IE-Browsers
bei mir gemeldet haben, weil die Seite bei reinzoomen einschlafen
würde.
Wenn das Problem verbreitet sein sollte, könnte man das vielleicht dem
Herren melden, der bei Microsoft explizit als Verbindungsmann zur
OSM-Community eingestellt wurde: Steve Coast.
morgen soll das folgende Projekt in der deutschen Wikipedia live
geschalten werden:
http://wiki.openstreetmap.org/wiki/WIWOSM
Vielen Dank für das lange erwartete Feature. :-)
OpenStreetMap has different representations for objects. This means
a place can be represented by a node (a single point) or a
multipolygon (an area). We want the most complex representation
for this project. A single node brings us no additional information
on the map compared to the usual geocoding in Wikipedia. On the
other hand the place node for a city has a lot of additional data
so it would be nice to connect it with Wikipedia.
Spätestens jetzt könnte man bei Grenzen beispielsweise von Kommunen
und Ortsteilen darüber nachdenken, die Place Nodes mit den
entsprechenden Polygonen - sodenn vorhanden - zu verheiraten. Dies
könnte geschehen, indem man Erstere mit der Rolle "label" in die
Multipolygon-Grenz-Relation aufnimmt. So könnte man sowohl die Infos
aus dem Polygon als auch diejenigen aus dem Node nutzen. Gleichzeitig
könnte man damit das derzeit doppelte Rendern der Namen ausmerzen, der
dann nur noch am Ort des Labels stattfindet. Spräche etwas dagegen?
Grundsätzlich nicht. Ich habe mir mit Dieter/Martin (?) vor einiger
Zeit eine Debatte dazu geliefert. Bezogen auf dieses Problem bedeutet das:
Ab einer bestimmten Granularität verschwimmt in OSM die Differenzierung
zwischen politischen Grenzen und Landnutzungsgrenzen. Wir hatten das
damals anfänglich am Beispiel von Wohngebieten erörtert.
Um ein einfaches, nachvollziehbares Beispiel zu geben, weshalb die
"Heirat" von der Du sprichst, nicht immer 1:1 stattfinden kann:
für eine kleine Gemeinde, sagen wir Burgdorf, existiert 1 (ein)
place node, aber teils n (mehrere) Grenzen, z.B.
* die Landnutzungsgrenze des Siedlungsgebiets (salopp Häusergrenze)
- manche taggen das als (place=), andere als
(landuse=residential)
- manchmal fällt das zusammen, manchmal nicht (je nach
Größe der Gemeinde)
* die administrative Grenze der Gemeinde
- administrative=boundary
* evtl. historische Grenzen (z.B. Innenstadt / Stadtmauergrenze
o.ä.)
Deshalb war mein Vorschlag damals, place=* generell nur als node zu
erfassen und das dann, so wie jetzt von Dir und WIWOSM vorgeschlagen
über Relationen zu den entsprechenden Polygonen in Bezug zu setzen (die
natürlich dann nicht mit place=* getaggt werden, weil das bedeuten
würde, wahllos eine der genannten Grenzarten zu bevorzugen).
Gruß
Christian
Ist auch angedacht, die Datenbank mit den Links zwischen OSM-Objekt
und den Wikipedia-Artikelnamen in den diversen Sprachen auch für
Andere zur Verfügung zu stellen? Man könnte sich beispielsweise eine
darauf basierende GUI vorstellen - eventuell in Nominatim integriert,
die eine Verlinkung zur Linien-/Flächen-Objektkarte bei Eingabe des
Objektnamens leistet.
If you add a new Wikipedia-Tag and can not wait, you can
update with (URL:+"&action=purge").
Mir ist nicht klar, welche "URL" gemeint ist. Ist es im Beispielsfalle
von Düsseldorf die des Wikipedia Artikels
http://de.wikipedia.org/wiki/D%C3%BCsseldorf
oder die der Relation, in die ich das Tag eingetragen habe
http://www.openstreetmap.org/browse/relation/62539
und wie müsste diese "URL" in diesem Beispiel präzise lauten?
Der bevorzugte Wikipedia Tag sollte laut WIWOSM so aussehen:
"wikipedia=lang:article". Es reicht der Link in einer Sprache.
Schwierig wird es allerdings, wenn die Interlanguage Links
untereinander nicht eineindeutig sind und eine Reise durch
verschiedene Sprachen schlussendlich nicht am Ausgangspunkt landet?
Zum Beispiel kann eine Region andere Grenzen haben wie das
Naturschutzgebiet/See/Forst/etc gleichen Namens. So könnten die
Artikel de:Name (A), de:Name (B), it:Name (A+B umfassend), en:Name (A)
sowie fr:Name (B) existieren, so dass in Ermangelung des exakt
kongruenten Pendants in Wikipedia üblicherweise sinnähnlich aber aus
OSM-Sicht falsch verlinkt wird.
Kann man dann die Wikipedia Links für jede Sprache einzeln an das OSM
Objekt pappen und wird das dann auch beachtet? In diesem Fall müsste
man auch die "Leit"-Sprache für die Interlanguage-Links markieren
können. Alle anderen Sprachen wären dann explizit als Ausnahme zu
behandeln.
Was passiert, wenn ein Wikipedia Artikel verschoben oder gar der
Redirect durch Umverlinkung aufgelöst wird? Sinnvoll wäre es, die
Verlinkung nicht einfach nur verschwinden zu lassen, sondern den
Verlust eines ehemals gültigen Links zu markieren, so dass man nach
solch verlorenen Links fahnden könnte.
Was bedeutet "is parsed (also with https)"?
Der folgende Link funktioniert:
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=de&title=Bundesstra%C3%9Fe%201
Hingegen dieser Link funktioniert nicht, obwohl der Wikipedia Artikel
existiert:
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=de&title=Europastra%C3%9Fe%201
Kann man im Falle eines nicht funktionierenden Links immer davon
ausgehen, dass es diesen Wikipedia Tag in OSM noch nicht gibt oder
kann es auch andere Gründe geben?
In Wikipedia gibt es oft Karten, wie "Lage des Landkreises X im
Bundesland Y" als Illustrierung des Artikel "Landkreis X". Dabei sind
innerhalb des Bundeslandes alle Landkreise eingezeichnet und der
betroffene Landkreis eingefärbt. Ähnliches gilt für Städte mit deren
Bezirken und Ortsteilen. Theoretisch könnte eine solche Karte nun auch
automatisch eventuell unter Berücksichtigung des
http://de.wikipedia.org/wiki/Vier-Farben-Satz
aus dem Artikelnamen erzeugt werden. Vor dem Hintergrund, dass
Superrelationen nicht unterstützt werden, vermute ich aber, dass
solche Karten zu belastend für Server wären. Ist diese Einschätzung
richtig?
Das in Frage stehende Feature hat auch durchaus seinen Sinn. Die
derzeitigen Karten dieses Typs in Wikipedia sind in den meisten Fällen
aus nichtfreien Quellen entstanden, z.B. von den Homepages der
Kommunen übernommen.
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
