Re: [Talk-de] Geofabrik-Downloads jetzt als Binaerformat
Hallo, On 10/28/2010 09:13 PM, Carsten Moeller wrote: Ich halte bpf für eine Alternative, nicht jedoch für eine wirklich gute Lösung. Die Annahme, dass alles da draußen auf osmosis aufsetzen wolle oder mal eben ganze Importstrukturen umkippen wird, um sich dem doch eher gruseligen Binärgefriggel-Format anzuschlie~_en, halte ich für gewagt. Uebertreibst Du da nicht ein bisschen? Ok, einige benutzen vielleicht wirklich irgendeine bz2-Lese-Library, aber die meisten, die nicht direkt Osmosis oder osm2pgsql einsetzen, werden doch derzeit in irgendeiner Form ein bunzip2 extract.osm.bz2 | meintollesprogramm machen. Und die machen halt kuenftig pbf2osm extract.osm.pbf | meintollesprogramm. Wobei sich die Laufzeit natuerlich drastisch reduzieren laesst, wenn man dem meintollesprogramm das Binaer-Lesen direkt beibringt, damit spart man naemlich das XML-Parsen. Eine 30%ige Reduzierung der Transportmengen wäre durchaus auch anders zu erreichen. Nicht jeder benötigt immer alles. Als gutes Beispiel sehe ich hier die Cloudmade-Philosophie Extrakte für verschiedene Anwendungsfälle bereitzustellen. Da ist ein europa-highways.osm plötzlich nur noch ein Drittel so gro~_ wie das Original. Ich finde, da ergaenzen sich die Geofabrik- und die Cloudmade-Dienste praechtig. Wem die Highways reichen, der kann sich die ja dort runterladen. Analog wäre z.B. auch denkbar, die ganzen Meta-Infos wie Autor, TimeStamp, etc. aus den Tags rauszulassen und nur reine Nutzdaten zu komprimieren. Wette, das geht dann auch auf 30% runter! In der Tat hat das neue Binaerformat eine Option, mit der man diese ganzen Metadaten rauskicken kann. Das spart ca. 15% von der komprimierten Datei. Es gibt eine weitere Option, mit der man die Genauigkeit der Koordinaten auf 1.1m oder besser reduzieren kann, das spart erneut rund 15%. Das sind beides sinnvolle Optionen fuer reine Daten-Konsumenten, also z.B. fuer eine Routing-Applikation auf dem Handy oder sowas. Allerdings richte ich mich mit den Geofabrik-Extrakten eher an die Community - an diejenigen, die die Daten irgendwie auf eine von mir nicht vorbestimmte Art weiterverarbeiten. Deswegen biete ich diese verlustbehafteten Optionen nicht an, weil das die Daten fuer einige Zwecke untauglich machen wuerde. Ich habe mitbekommen, dass mehr und mehr Leute die Geofabrik-Downloadlinks in ihre Applikationen einbauen und damit also den Endbenutzer diese Dateien herunterladen lassen (oft alles so automatisiert, dass der Benutzer nicht mal sieht, woher er die Datei holt). Das ist mir nicht recht - wie gesagt, das ganze ist von mir als ein Service fuer die Community gedacht und nicht als allgemeiner OSM-Downloadserver fuer die breite Masse. Wer den Anwendern seiner Software sowas anbieten will, der sollte selbst Extrakte berechnen und dabei eben auch die oben erwaehnte Filterung unnoetiger Daten einbauen. Auf keinen Fall sollte Software an Endanwender verteilt werden, in die irgendwelche Geofabrik-Downloadlinks fest eingebaut sind, denn es kann durchaus sein, dass ich die Pfad-Struktur oder die Datenformate aendere. Es kann sogar sein, dass ich das voellig unnoetig und absichtlich mal mache ;) Ich weiß nicht wie viele XMLs ich bereits analysiert habe und so ganz schnell auf kleine aber nicht unwichtige Dinge und Fehlerchen aufmerksam geworden bin. Diese Option wird es dann ja in Zukunft nicht mehr geben. Diese Aussage verstehe ich nicht. Die kleinen Fehlerchen, die es bislang gab, waren entweder Fehler im Transportformat (z.B. falsches escaping bei einem Unicode-Zeichen) oder in den Daten. Fehler im Transportformat mag es beim Binaerformat genauso geben, aber sie sind natuerlich anderer Art als Fehler im XML und es bedarf anderer Mechanismen, sie zu debuggen (bislang hast Du Dich auch blind darauf verlassen, dass bunzip2 schon richtig funktionieren wird und Dich nicht beschwert, dass es schwierig ist, Fehler im komprimierten Datenstrom zu debuggen). Fehler oder Unregelmaessigkeiten in den Daten gibt es jetzt genauso wie frueher, und wer sie sucht, findet sie auch genauso. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osmosis-bug in Geofabrik-Extrakten?
Hallo, auf folgendes Problem bin ich gerade gestoßen: Die line-relation gemäß oxomoa-Schema für die Aachener Buslinie 1 sieht in der api so aus: osm version=0.6 generator=OpenStreetMap server relation id=969861 visible=true timestamp=2010-07-12T13:13:26Z version=4 changeset=5198960 user=wonk uid=79958 member type=relation ref=969505 role=/ member type=relation ref=86812 role=/ member type=relation ref=1066454 role=/ member type=relation ref=1066614 role=/ member type=relation ref=1066633 role=/ tag k=line v=bus/ tag k=name v=Bus 1/ tag k=network v=AVV/ tag k=operator v=ASEAG/ tag k=ref v=1/ tag k=type v=line/ /relation /osm Im Extrakt der Geofabrik sieht sie dagegen so aus: relation id=969861 version=4 timestamp=1969-12-20T21:22:32Z uid=79958 user=wonk changeset=5198960 member type=relation ref=969505 role=/ member type=relation ref=86812 role=/ tag k=line v=bus/ tag k=name v=Bus 1/ tag k=network v=AVV/ tag k=operator v=ASEAG/ tag k=ref v=1/ tag k=type v=line/ /relation Irgendwie fehlen da drei Relationen. Sie sind zwar selber im Extrakt drin, aber nicht in der Line-Relation. Die fehlenden kreuzen auch nicht die Grenzen des Extrakts. Nun weiß ich ja, dass Relationen in Relationen nicht gern gesehen werden, aber Oxomoa hats nun mal so gewollt. Wenn alle oder keine Relationen drin wären könnte ich dass ja verstehen, aber warum nur zwei von fünf? Hat jemand ne Erklärung oder Lösung? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All In One
Hab den Fehler zz auch nicht gefunden .. und ab heute 3 Wochen im Urlaub ;-) Dirk Am 28. Oktober 2010 10:19 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Elchtreiber elchtrei...@gmx.net wrote: Kann da bitte mal wer nach dem Rechten schauen? Das kann im Normalfall nur genau ein einziger nämlich Christoph. Ich kann als devserver Admin zwar ins logfile schaun , was ich bereits gestern gemacht habe, bin aber nicht draus schlau geworden. Eventuell kann auch Flacus helfen, der ist neuerdings ebenfalls bei der AIO aktiv. Auf der devserver Liste hat Christoph am Sonntag geschrieben, dass er seinen Buildprozess auf das neue pbf Binärformat umgestellt hat: http://lists.openstreetmap.de/pipermail/devserver/2010-October/001629.html Da ist dann wohl was schiefgelaufen :( Gruss Sven -- Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit Office nicht kompatibles Bürosoftwarepaket einzuführen. (Florian Weimer in de.alt.sysadmin.recovery) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 07:36, schrieb Carsten Moeller: ja prüfen ob die Verwendung eines highway=service sinnvoll ist, aber bei langen Strecken jeden service abzuklappern ob er nicht doch an eine geeigneten Transportlösung anbindet dürfte aufwendig werden... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er Und wenn der Service genau in der Mitte der Strecke liegt? Das wäre der Worst-Case! Ich meine in allen Fällen in denen service nicht Anfang und/oder Ende der Strecke ist. Unter Umständen ist das Service-Stück ja auch noch entgegengesetzt zur Zielrichtung. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads jetzt als Binaerformat
Am Freitag 29 Oktober 2010, 08:28:55 schrieb Frederik Ramm: Uebertreibst Du da nicht ein bisschen? Ok, einige benutzen vielleicht wirklich irgendeine bz2-Lese-Library, aber die meisten, die nicht direkt Osmosis oder osm2pgsql einsetzen, werden doch derzeit in irgendeiner Form ein bunzip2 extract.osm.bz2 | meintollesprogramm machen. Und die machen halt kuenftig pbf2osm extract.osm.pbf | meintollesprogramm. Wobei sich die Laufzeit natuerlich drastisch reduzieren laesst, wenn man dem meintollesprogramm das Binaer-Lesen direkt beibringt, damit spart man naemlich das XML-Parsen. Ich steh zwar auch nicht so auf Binaerformate, aber wenn dadurch die Verarbeitungsgeschwindigkeit inkl. Datentransfer signifikant zunimmt, ist das sicher eine gute Sache - grade bei den Mengen an Daten, die bei OSM anfallen. Ausserdem ist das Format im Gegensatz zu vielen anderen binaeren Formaten dokumentiert und frei erhaeltlich. Allerdings richte ich mich mit den Geofabrik-Extrakten eher an die Community - an diejenigen, die die Daten irgendwie auf eine von mir nicht vorbestimmte Art weiterverarbeiten. Deswegen biete ich diese verlustbehafteten Optionen nicht an, weil das die Daten fuer einige Zwecke untauglich machen wuerde. Eine zweite gestrippte Version bereitzustellen waere wohl zuviel verlangt, oder ;-) Das ist mir nicht recht - wie gesagt, das ganze ist von mir als ein Service fuer die Community gedacht und nicht als allgemeiner OSM-Downloadserver fuer die breite Masse. Wer den Anwendern seiner Software sowas anbieten will, der sollte selbst Extrakte berechnen und dabei eben auch die oben erwaehnte Filterung unnoetiger Daten einbauen. +1 Danke uebrigens, dass du die Daten ueberhaupt in der Form zur Verfuegung stellst! Auf keinen Fall sollte Software an Endanwender verteilt werden, in die irgendwelche Geofabrik-Downloadlinks fest eingebaut sind, denn es kann durchaus sein, dass ich die Pfad-Struktur oder die Datenformate aendere. Es kann sogar sein, dass ich das voellig unnoetig und absichtlich mal mache ;) Es waere aber nett, wenn du das fuer den Fall des Falles wenigstens auf der dev-Liste ankuendigst - waere ja schade, wenn durch nicht mehr funktionierende Nichtendanwendersoftware die Nutzung von OSM-Daten behindert wuerde ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PotM November - Hotels und andere Unterk ünfte
Moin, M∡rtin Koppenhoefer schrieb: Am 28. Oktober 2010 13:32 schrieb Andreas Neumann andr-neum...@gmx.net: Statt url=* sollte eher website=* verwendet werden... wieso? url wird 236.000 mal verwendet, website gerade mal 65.600 mal. tja, ein Objekt muss halt erstmal eine offizielle Homepage haben - beliebige Verweise kann man dagegen oft angeben. Frei nach Wiki-Description ... ;-) Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 08:56, schrieb Garry: Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er Und wenn der Service genau in der Mitte der Strecke liegt? Das wäre der Worst-Case! Ich meine in allen Fällen in denen service nicht Anfang und/oder Ende der Strecke ist. Unter Umständen ist das Service-Stück ja auch noch entgegengesetzt zur Zielrichtung. Mir ist bekannt dass Garmin ein Problem mit niederklassifizierten Straßen in der Mitte der Route hat, aber ich dachte die modernen A-Star etc. Algos kämen damit klar. Eine bessere Lösung als deswegen die Zufahrtswege als primary zu taggen wäre eine Annotationstag wie mkgmap:routing_class=+3 oder so... Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 28.10.2010 22:48, schrieb Chris66: Ergänzende Frage: warum malt JOSM die PLZ Gebiete 46399 http://www.openstreetmap.org/browse/relation/1246638 und 46397 http://www.openstreetmap.org/browse/relation/1246643 grün ? Wobei ich hier (wie im Wiki empfohlen) eine Straße in die Rela gepackt habe. Eventuell ist die Advanced Multipolygon Erkennung in JOSM da etwas buggy Wenn ich die grünen hw=pedestrian Rela-Mitglieder in JOSM zu tertiary ändere, dann verschwindet die Färbung. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.10 09:40, schrieb Chris66: Wobei ich hier (wie im Wiki empfohlen) eine Straße in die Rela gepackt habe. Eventuell ist die Advanced Multipolygon Erkennung in JOSM da etwas buggy Wenn ich die grünen hw=pedestrian Rela-Mitglieder in JOSM zu tertiary ändere, dann verschwindet die Färbung. Wird natürlich toll, wenn der nächste aus den Fußgängerzonen Flächen machen will und deine Linien rauslöscht :-( Übrigens würde ich die Bocholter Aa als Grenze annehmen, nicht 30m südlich davon. Gruß, Ansdé Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 10:02, schrieb André Joost: Wobei ich hier (wie im Wiki empfohlen) eine Straße in die Rela gepackt habe. Eventuell ist die Advanced Multipolygon Erkennung in JOSM da etwas buggy Wenn ich die grünen hw=pedestrian Rela-Mitglieder in JOSM zu tertiary ändere, dann verschwindet die Färbung. Wird natürlich toll, wenn der nächste aus den Fußgängerzonen Flächen machen will und deine Linien rauslöscht :-( Ja, deshalb ist es vllt doch besser mit einer separaten boundary=postal_code Linie zu arbeiten. Dann lässt es sich auch vil besser mit dem JOSM-Filter arbeiten. ;-) Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Chris66 chris66...@gmx.de wrote: ??? Aus meiner Sicht ist highway=service korrekt. Eben, wüsste nicht was besser passt, classified ja wohl kaum. Warum ein Router service _nicht_ berücksichtigen sollte müsste Carsten erst mal erklären. Für größere Parkplätze möchte man das beispielsweise ohnehin haben. Meine Rheinfähre hat jedenfalls Servicewege: http://osm.org/go/0DP7TJddE-- Gruss Sven -- Software patents are the software project equivalent of land mines: Each design decision carries a risk of stepping on a patent, which can destroy your project. (Richard M. Stallman) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Chris66 schrieb am 28.10.2010 15:28: Die ehemaligen Ostgebiete sind noch Sorgenkinder. ;-) Ähm wie jetzt; Ostpreußen und Schlesien? ;) Alex -- http://de.wikipedia.org/wiki/Benutzer:Alexrk2 http://de.wikipedia.org/wiki/Wikipedia:Kartenwerkstatt/Blog ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.10 10:18, schrieb Chris66: Ja, deshalb ist es vllt doch besser mit einer separaten boundary=postal_code Linie zu arbeiten. Dann lässt es sich auch vil besser mit dem JOSM-Filter arbeiten. ;-) wieso? Ich würde das boundary=postal_code auch an alle benutzten Straßen hängen. Wird doch bei Stadtteilgrenzen auch gemacht. Oder: Filter mit child postal_code=46399 nehmen. Zuerst um die Elemente auszugrauen, und zum Schluß mit allen Haken, um die Integrität zu kontrollieren. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 10:24, schrieb Sven Geggus: Chris66chris66...@gmx.de wrote: ??? Aus meiner Sicht ist highway=service korrekt. Eben, wüsste nicht was besser passt, classified ja wohl kaum. Warum ein Router service _nicht_ berücksichtigen sollte müsste Carsten erst mal erklären. Für größere Parkplätze möchte man das beispielsweise ohnehin haben. Ich möchte aber auch nicht unbedingt während der Fahrt über irgendwelche Supermarkt Parkplätze geroutet werden, weil man dabei ein paar Meter sparen kann ;-) Meine Rheinfähre hat jedenfalls Servicewege: http://osm.org/go/0DP7TJddE-- Ich sehe highway=service tendenziell als Zufahrt zu irgendetwas. Wenn man das also als Zufahrt zu einer Fähre sieht wäre ein service ja auch gut - aber dort endet die Fahrt ja (meist) nicht. Wenn man daher den Zufahrtsweg zusammen mit der Fähre als Verbindung von A nach B ansieht - und darum geht es hier ja - paßt service auf einmal viel weniger. Dann ist es nämlich keine schnöde Zufahrt mehr, sondern Teil einer Verbindung - und da paßt ein unclassified dann schon wieder viel eher. Es sollte die Fähre der bestimmende Faktor des Routings sein (ich will möglichst nicht über Fähren geroutet werden) und nicht der Zufahrtsweg die Route von vornherein herabstufen ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 01:29, Robert S. schrieb: Ich kenne nur 48128 Münster - das wird auch immer schön ins nirgendwo gerendert [1]. Das sollte man Mapnik vlt. mal abgewöhnen. Dafür! Ich brauche auch den Gemeindenamen aus der Grenzrelation nicht auf der Hauptkarte. Das sieht nicht schön aus und sorgt regelmäßig für Verwirrung (Warum steht der Ortsname irgendwo in der Pampa?, Warum taucht der mehrfach in der Karte auf?) Diejenigen, die sich mit dem Thema Grenzen/PLZ beschäftigen nehmen sowieso spezielle Karten bzw. Overlays zur Unterstützung ihrer Arbeit und nicht das Mapnik-Rendering. Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelne Nodes für Bus und Bahnhaltestel len?
Am 28.10.2010 22:06, schrieb Claudius: Am 28.10.2010 19:20, M∡rtin Koppenhoefer: Am 28. Oktober 2010 15:15 schrieb Peter Wendorffwendo...@uni-paderborn.de: Am 28.10.2010 13:06, schrieb Claudius: Das würde ich mit einem public_transport=stop_position auf dem Straßenweg und einem seperaten Knoten public_transport=platform jeweils mit bus=yes auf der Position des mittleren Masten taggen :) ich habe mal 3 Haltestellen gemacht, halten ja jeweils unterschiedliche Busse ;-) Aber alle drei Linien halten doch an derselben Haltestelle. Auch, wenn ich meiner Aussage von vorher widerspreche: Nein. Wenn (wie Martin schreibt) an den drei Haltestellenschildern drei unterschiedliche Busse halten, ist das eine andere Information als dass an der Gesamthaltestelle insgesamt diese drei Busse halten. Ich weiß, dass tagging für Blinde bei vielen als Sonderfall angesehen, als zu feingranular kritisiert oder sonstwas wird, aber: Wenn ein Navi auswerten kann: hier sind drei Haltestellen-Punkte, du musst das rechte Haltestellenschild finden, da steht Bus Linie 42, dann ist das erheblich mehr wert als irgendwo an dieser Haltestelle hält Bus 42, aber eben auch drei andere. Hier in Deutschland kann man sowas meist vergessen; Haltepositionen von Bussen werden sowieso nicht eingehalten (Ausnahmen sind selten). Wenn das aber möglich ist, ja, dann sind das drei Haltestellen. Dann doch gleich public_transport=platform auf einen Weg vom ersten zum letzten Mast. M.E. gibt's da überhaupt keine platform, lediglich 3 Masten. public_transport=platform steht laut ÖPNV-Schema für den Wartebereich der ÖPNV-Nutzer. Ob das jetzt ein Wartehäuschen oder etwas zusammengetrampelter Seitenstreifen neben der Landstraße ist, ist dabei egal. +1 Wenn sich eine Haltestelle einfach über eine nennenswerte Strecke entlang der Straße erstreckt, bin ich auch weiterhin für platform, selbst wenn da keine bauliche Plattform existiert. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 28. Oktober 2010 21:36 schrieb Carsten Moeller cmindivid...@gmx.de: Am 26.08.2010 13:44, schrieb M∡rtin Koppenhoefer: Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Du meinst damit aber nicht, motorcar=yes an die Schienen zu taggen, oder? Das hielte ich für extrem falsch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29. Oktober 2010 10:56 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Ich sehe highway=service tendenziell als Zufahrt zu irgendetwas. +1 Wenn man daher den Zufahrtsweg zusammen mit der Fähre als Verbindung von A nach B ansieht - und darum geht es hier ja - paßt service auf einmal viel weniger. Dann ist es nämlich keine schnöde Zufahrt mehr, sondern Teil einer Verbindung - und da paßt ein unclassified dann schon wieder viel eher. +1, nur dass ich dann in vielen Fällen unclassified auch wieder viel zu wenig finde. Viele Fährverbindungen (nicht unbedingt Rheinfähren o.dgl., aber welche übers Meer) gehören zu den Hauptachsen des Verkehrs und können daher m.E. auch problemlos höher eingestuft werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelne Nodes für Bus und Bahnhaltestel len?
Am 28. Oktober 2010 22:06 schrieb Claudius claudiu...@gmx.de: Am 28.10.2010 19:20, M∡rtin Koppenhoefer: Am 28. Oktober 2010 15:15 schrieb Peter Wendorffwendo...@uni-paderborn.de: Am 28.10.2010 13:06, schrieb Claudius: ich habe mal 3 Haltestellen gemacht, halten ja jeweils unterschiedliche Busse ;-) Aber alle drei Linien halten doch an derselben Haltestelle. ja, aber an 3 unterschiedlichen Stellen. 3 Linien sind es übrigens nicht, sondern ca. 10. M.E. gibt's da überhaupt keine platform, lediglich 3 Masten. public_transport=platform steht laut ÖPNV-Schema für den Wartebereich der ÖPNV-Nutzer. Ob das jetzt ein Wartehäuschen oder etwas zusammengetrampelter Seitenstreifen neben der Landstraße ist, ist dabei egal. schon klar, aber wenn es keinen Wartebereich gibt? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Viele Fährverbindungen (nicht unbedingt Rheinfähren o.dgl., aber welche übers Meer) gehören zu den Hauptachsen des Verkehrs und können daher m.E. auch problemlos höher eingestuft werden. Das ist schon deshalb nicht notwendig weil es sich in solchen Fällen fast immer um den einzig möglichen Weg handelt, den ein Routingalgorithmus überhaupt finden kann. Vor Jahren gab es mal eine Kettenmail, die sich extrem schnell im netz verbreitet hatte. Das war ein Routing link irgendwo in Norwegen. Dort wurde man für die Städteverbindung mal schnell mit zwei Fähren über England geschickt. War AFAIR noch vor der Google Maps Zeit. Gruss Sven -- Das Einzige, wovor wir Angst haben sollten, ist die Angst selbst (Franklin D. Roosevelt) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PotM November - Hotels und andere Unterk ünfte
Am 29. Oktober 2010 09:29 schrieb Georg Feddern ne...@bavarianmallet.de: wieso? url wird 236.000 mal verwendet, website gerade mal 65.600 mal. tja, ein Objekt muss halt erstmal eine offizielle Homepage haben - beliebige Verweise kann man dagegen oft angeben. Frei nach Wiki-Description ... ;-) Bisschen sehr frei: url: The url=* tag can be applied to any node. The idea is to point to e.g. the homepage of a given amenity. This tag is being used for very different types of content - official websites of an amenity or its operator, ... website: The website=* tag can be applied to any object. The idea is to point to e.g. the homepage of a given item. es gibt auch noch contact:website im Wiki. Wenn jemand Lust zum Aufräumen hat, IMHO wäre das so ein Fall... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 10:47, schrieb André Joost: Am 29.10.10 10:18, schrieb Chris66: Ja, deshalb ist es vllt doch besser mit einer separaten boundary=postal_code Linie zu arbeiten. Dann lässt es sich auch vil besser mit dem JOSM-Filter arbeiten. ;-) wieso? Ich würde das boundary=postal_code auch an alle benutzten Straßen hängen. Wird doch bei Stadtteilgrenzen auch gemacht. Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Wenn die Straße dann in die boundary kommt, passt das eigentlich nicht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.10 12:20, schrieb Peter Wendorff: Am 29.10.2010 10:47, schrieb André Joost: Am 29.10.10 10:18, schrieb Chris66: Ja, deshalb ist es vllt doch besser mit einer separaten boundary=postal_code Linie zu arbeiten. Dann lässt es sich auch vil besser mit dem JOSM-Filter arbeiten. ;-) wieso? Ich würde das boundary=postal_code auch an alle benutzten Straßen hängen. Wird doch bei Stadtteilgrenzen auch gemacht. Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Also beim Heelweg in Suderwick würde ich das glatt verneinen. Die Häuser auf der anderen Seite gehören nämlich schon zum niederländischen Dinxperlo. In anderen Fällen (Grenzstraße in Moers, Siepenstraße in Oberhausen) wäre ich mir da auch nicht so unbedingt sicher. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 12:29, schrieb André Joost: Am 29.10.10 12:20, schrieb Peter Wendorff: Am 29.10.2010 10:47, schrieb André Joost: Am 29.10.10 10:18, schrieb Chris66: Ja, deshalb ist es vllt doch besser mit einer separaten boundary=postal_code Linie zu arbeiten. Dann lässt es sich auch vil besser mit dem JOSM-Filter arbeiten. ;-) wieso? Ich würde das boundary=postal_code auch an alle benutzten Straßen hängen. Wird doch bei Stadtteilgrenzen auch gemacht. Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Also beim Heelweg in Suderwick würde ich das glatt verneinen. Die Häuser auf der anderen Seite gehören nämlich schon zum niederländischen Dinxperlo. In anderen Fällen (Grenzstraße in Moers, Siepenstraße in Oberhausen) wäre ich mir da auch nicht so unbedingt sicher. Ausnahmen bestätigen die Regel, aber auch in deinem Beispiel ist das vermutlich nicht falsch, was ich sage. Ich vermute, bei allen kundenunfreundlichen Entscheidungen der deutschen Post würde auch ein Brief an eine Adresse ankommen, wenn Heelweg Nummer x, *, D draufsteht, obwohl das die falsche Straßenseite ist. Außerdem: ich sage ja nicht, dass die extra-Grenze IMMER abseits der Straße liegen muss. Es gibt Ausnahmefälle. Aber das zeigt ja eher genau das Gegenteil: Ich kann nicht annehmen, dass die Häuser beider Seiten zum PLZ-Gebiet gehören, wenn die Straße als Grenzlinie genutzt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelne Nodes für Bus und Bahnhaltestel len?
Wolfgang-4 wrote: Eigentlich hätte ich ja erwartet, dass derjenige, der daneben haut, das auch wieder repariert. danke, wolfgang ab und zu bin ich auch mal verhindert. es gibt auch noch ein leben neben osm ich hoffe, dass sich die wogen langsam wieder glätten und es in drei jahren nicht heisst: du bist doch der gewesen, der damals in berlin das licht ausgeschaltet hast? ;) lg walter - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/Einzelne-Nodes-fur-Bus-und-Bahnhaltestellen-tp5670007p5685972.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.10 12:45, schrieb Peter Wendorff: Außerdem: ich sage ja nicht, dass die extra-Grenze IMMER abseits der Straße liegen muss. Es gibt Ausnahmefälle. Aber das zeigt ja eher genau das Gegenteil: Ich kann nicht annehmen, dass die Häuser beider Seiten zum PLZ-Gebiet gehören, wenn die Straße als Grenzlinie genutzt wird. Nur gehören zu jeder PLZ-Grenze gewöhnlich 2 PLZ-Gebiete. Auf welcher Seite der Straße du nun deine Linie neben die Straße setzt, eine Häuserreihe ist dann immer flashc einsortiert. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 13:00, schrieb André Joost: Am 29.10.10 12:45, schrieb Peter Wendorff: Außerdem: ich sage ja nicht, dass die extra-Grenze IMMER abseits der Straße liegen muss. Es gibt Ausnahmefälle. Aber das zeigt ja eher genau das Gegenteil: Ich kann nicht annehmen, dass die Häuser beider Seiten zum PLZ-Gebiet gehören, wenn die Straße als Grenzlinie genutzt wird. Nur gehören zu jeder PLZ-Grenze gewöhnlich 2 PLZ-Gebiete. Auf welcher Seite der Straße du nun deine Linie neben die Straße setzt, eine Häuserreihe ist dann immer flashc einsortiert. Nein, wieso? die Straße selbst hat eigentlich keine Postleitzahl; das wird nur für die einfachere Verwendung so angenommen, um alle Häuser der Straße in einem Satz zu beschreiben. Wenn die Gebietsgrenzen nun genau zwischen den Straßenseiten trennt, ist die Straße eine sinnvolle und richtige Grenzlinie. Gehört aber eine Straße mit allen anliegenden Häusern beider Straßenseiten zur PLZ-Region, dann ist die Straße selbst nicht die Grenzlinie, sondern die Gebäude/Grundstücksrückseite oder so. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Hallo, am 29.10.2010 12:20 schrieb Peter Wendorff: denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Falsch! In einer Vielzahl von Fällen gehören die beiden Straßenseiten zu unterschiedlichen Postleitzahlgebieten. Einzelfall beachten! Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 13:26, schrieb Norbert Kück: Hallo, am 29.10.2010 12:20 schrieb Peter Wendorff: denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Falsch! In einer Vielzahl von Fällen gehören die beiden Straßenseiten zu unterschiedlichen Postleitzahlgebieten. Einzelfall beachten! Klar: +10 Ich wollte darauf hinaus, dass die Straße als Grenze deshalb eben nicht funktioniert. Deine Ausnahmefälle sind keine mehr, wenn man alle Straßen betrachtet (dann ist dasx der absolute Normalfall), aber es gibt eben beide Seiten, deshalb sollte die Grenze genau das umfassen, was im PLZ-Gebiet enthalten ist: also neben den Straßen vor allem die Häuser bzw. Briefkästen - BEI BEDARF beidseitig der Straße. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Hallo, On 10/29/10 12:20, Peter Wendorff wrote: Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Nein, dieser Ansicht bin ich nicht, siehe detaillierte Abbildung auf http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 Ich empfehle dort explizit (mit Abbildung!), eine Strasse in die Boundary aufzunehmen, wenn Haeuser auf der einen Seite zum einen und auf der anderen Seite zum anderen Gebiet gehoeren. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ol-buisnessanwendung - tiles cachen
mit einem bekannten wird gerade über eine buisness-lösung auf basis von openlayer-karten mit osm-daten nachgedacht. nun ist das ja so das im falle eines server-ausfalls die karten nicht verfügbar sind. gibt es da etwas diese zwischenzulagern - oder ist das unzulässig? mir war so als wenn darüber schon einmal diskuttiert worden ist. ein eigener tile-server ist mir aber ehrlich zu hoch gegriffen. kann jemand weiterhelfen ?? gruß Jan :-)Überprüft mit AntiVir MailGuard v10.0.1.27 AVE 8.2.4.86 VDF 7.10.13.60___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29. Oktober 2010 14:18 schrieb Frederik Ramm frede...@remote.org: Hallo, On 10/29/10 12:20, Peter Wendorff wrote: Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Nein, dieser Ansicht bin ich nicht, siehe detaillierte Abbildung auf http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 Ich empfehle dort explizit (mit Abbildung!), eine Strasse in die Boundary aufzunehmen, wenn Haeuser auf der einen Seite zum einen und auf der anderen Seite zum anderen Gebiet gehoeren. Hatten wir nicht vor einiger Zeit hier mal einen Konsens, der besagte, daß Postleitzahlengebiete, da sie sich (scheinbar?) nur aus Zusammenballungen von Adressen mit gleichen Postleitzahlen ergeben und keine konkret festgelegten Grenzverläufe zu haben scheinen (und nicht immer exisiterende Grenzverläufe zur Einteilung genutzt wurden), lieber durch die Gesamtheit der eingetragenen Adressnodes repräsentiert und Polygone bei Bedarf hieraus errechnet werden sollten? Wenn ja, wann hat sich das gedreht und weshalb? Es war ja vor nicht all zu langer Zeit noch so, daß selbst konkret definierte politische und administrative Grenzen von einigen abgelehnt wurden, weil sie nicht physisch genug seien. (ganz zu schweigen von Verkehrsverbund-Grenzen als Polygon, Reichweiten von TV-Sendern als Polygon, Auslieferungsradius von Pizzabuden oder die Grenzen, innerhalb deren kein Kölsch, kein Alt, nur Kölsch, nur Alt (urgs!) oder keines von beiden ausgeschenkt werden, etc. ;-) ) Die Informationen unter http://arnulf.us/PLZ sagen ja nun auch, daß PLZ-Gebiete nur gedacht existieren, wenn man PLZ zusammenfasst und daß die Nutzung dieser Daten in Grenzgebieten mit Vorsicht zu genießen sei. Ich will keinen Flamewar lostreten, das ist lediglich eine Frage (da mich PLZ eigentlich nicht interessieren). Schönes Wochenende, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online-Befragung der OSM-community - community-Daten zu gewinnen!
Glück ist die Zahl der OSM-Aktiven so hoch und damit eine Dichte erreicht bei der die PLZ nun wahrlich nicht auf das Individuum schließen lässt. Nur mit der Postleitzahl oft nicht, in der erfassten Kombination aber mit Sicherheit. Wenn ich mir diverse Gebiete auf dem platten Land angucke, dann kann ich DIESER Aussage jedenfalls nicht zustimmen. Sicher kann da jemand, der Böses will dahinterkommen wer du bist bzw. vermutlich bist, aber wie oft hält der Großteil der Bevölkerung bei Ihren Einkäufen bereitwillig eine Karte bereit, mit der das gesamte Kaufverhalten einer Person analysiert werden kann. Es ist kein Argument, dass sich die breite Masse u. U. nicht um ihre personenbezogenen Daten schert, welches ein Individuum dazu bringen kann (oder sollte) auf die Kontrolle der eigenen Daten zu verzichten. Oder noch besser, der Zeitungsartikel wo sich Hauseigentümer in der lokalen Presse damit rühmen dem StreetView-Bild Ihres Hausen widersprochen zu haben, aber im Zeitungsartikel mit vollem Namen und voller Adresse abgedruckt werden. Was tun manche Individuen nicht alles für Publicity? Aber das Beispiel ist gut im Hinblick auf Konsequenten Umgang mit seiner Persönlichkeit. Kann ich da vielleicht die Referenz haben, ich würde das gern in meiner Vorlesung verwenden. Davon mal abgesehen, wie willst du aus PLZ und Nickname herausfinden wer das ist. Das ist schlichtweg fast unmöglich. Oh, solange NUR Postleitzahl und Nickname vorhanden sind ist eine Gefährdung sicherlich weitgehend auszuschliessen. Aber es ging ja gerade darum, dass mehr Informationen verfügbar sind. Und das Thema Datenaggregation ist ein sehr interessantes Forschungsgebiet und jeder namhafte SW-Hersteller hält ja schon mehr oder weniger gute Business-Warehouse Pakete (wenn auch für eine etwas andere Themenstellung) für seine Kunden parat. Es darf nicht vergessen werden, dass die zeitlich auseinander liegenden Abgaben kleinerer personenbezogener Informationen dank der heutigen Möglichkeiten der IT ggf. zusammengeführt und ausgewertet werden können. Und gerade um diese Möglichkeiten der gemeinsamen Auswertung der Häppchen geht es meines Verständnisses nach dem Originalposter. So wie er es hier formuliert hat, gibt es viele potentielle Teilnehmer. Manche lassen sich abhalten von der Teilnahme, andere nicht. Ich hätte es als sehr sinnvoll erachtet, wenn der Fragebogen bei den Fragen die Möglichkeit enthalten hätte, die eine oder andere Antwort deutlich gekennzeichnet nicht zu beantworten. Manche, die sich gegen eine Teilnahme entschieden haben, bzw. das Ausfüllen abgebrochen haben, wären dann vielleicht dabei geblieben. Aber es kann sogar noch schlimmer sein, vielleicht hat sich der eine oder andere Teilnehmer infolge seiner Bedenken sogar dazu hinreissen lassen, falsche Antworten zu geben, um damit den Rückschluss auf sich auszuschliessen. So gesehen wäre ein wenig mehr Sensibilität beim Umgang mit dem Thema Schutz personenbezogener Daten der Aktion sicherlich hilfreich gewesen. Ich fürchte Marco hat sich dadurch den Teilnehmerkreis ungewollt zusammengestrichen. Allerdings möchte ich noch anmerken, ich halte seine Untersuchung für sinnvoll und habe ebenfalls an der Abfrage teilgenommen.. Dem war aber ein Abwägen der Situation vorausgegangen. Mein persönlicher Standard im Hinblick auf personenbezogene Daten sieht deutlich anders aus. Mit besten Grüssen Marten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ol-buisnessanwendung - tiles cachen
Am 29.10.2010 14:53, schrieb Jan Tappenbeck: mit einem bekannten wird gerade über eine buisness-lösung auf basis von openlayer-karten mit osm-daten nachgedacht. nun ist das ja so das im falle eines server-ausfalls die karten nicht verfügbar sind. gibt es da etwas diese zwischenzulagern - oder ist das unzulässig? mir war so als wenn darüber schon einmal diskuttiert worden ist. ein eigener tile-server ist mir aber ehrlich zu hoch gegriffen. kann jemand weiterhelfen ?? Man kann einen Proxy bzw. Cache einsetzen. Der speichert die Kacheln zwischen und man muss nicht selbst rendern. Benutzt werden könnte hier mod_proxy, Tilecache, Mapproxy. Somit kann der OSM-Server ausfallen, bereits zwischengespeicherte Kacheln können weiterhin ausgeliefert werden. Wenn allerdings der Server der Openlayers-Anwendung ausfällt hilft das noch nicht weiter. Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 29.10.2010 15:08, schrieb Martin Simon: Am 29. Oktober 2010 14:18 schrieb Frederik Rammfrede...@remote.org: Hallo, On 10/29/10 12:20, Peter Wendorff wrote: Find ich in beiden Fällen aber nicht gut, denn zur Postleitzahlregion gehören normalerweise zumindest noch die Häuser BEIDSEITIG der Grenzstraße. Nein, dieser Ansicht bin ich nicht, siehe detaillierte Abbildung auf http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 Ich empfehle dort explizit (mit Abbildung!), eine Strasse in die Boundary aufzunehmen, wenn Haeuser auf der einen Seite zum einen und auf der anderen Seite zum anderen Gebiet gehoeren. Hatten wir nicht vor einiger Zeit hier mal einen Konsens, der besagte, daß Postleitzahlengebiete, da sie sich (scheinbar?) nur aus Zusammenballungen von Adressen mit gleichen Postleitzahlen ergeben und keine konkret festgelegten Grenzverläufe zu haben scheinen (und nicht immer exisiterende Grenzverläufe zur Einteilung genutzt wurden), lieber durch die Gesamtheit der eingetragenen Adressnodes repräsentiert und Polygone bei Bedarf hieraus errechnet werden sollten? Wenn ja, wann hat sich das gedreht und weshalb? Es war ja vor nicht all zu langer Zeit noch so, daß selbst konkret definierte politische und administrative Grenzen von einigen abgelehnt wurden, weil sie nicht physisch genug seien. (ganz zu schweigen von Verkehrsverbund-Grenzen als Polygon, Reichweiten von TV-Sendern als Polygon, Auslieferungsradius von Pizzabuden oder die Grenzen, innerhalb deren kein Kölsch, kein Alt, nur Kölsch, nur Alt (urgs!) oder keines von beiden ausgeschenkt werden, etc. ;-) ) Die Informationen unter http://arnulf.us/PLZ sagen ja nun auch, daß PLZ-Gebiete nur gedacht existieren, wenn man PLZ zusammenfasst und daß die Nutzung dieser Daten in Grenzgebieten mit Vorsicht zu genießen sei. Ich will keinen Flamewar lostreten, das ist lediglich eine Frage (da mich PLZ eigentlich nicht interessieren). Wär IMHO die saubere Lösung, ja. Gruß Peter Schönes Wochenende, Martin ___ 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
Re: [Talk-de] PLZ Import
Hallo, On 10/29/10 15:08, Martin Simon wrote: Hatten wir nicht vor einiger Zeit hier mal einen Konsens, der besagte, daß Postleitzahlengebiete, da sie sich (scheinbar?) nur aus Zusammenballungen von Adressen mit gleichen Postleitzahlen ergeben und keine konkret festgelegten Grenzverläufe zu haben scheinen (und nicht immer exisiterende Grenzverläufe zur Einteilung genutzt wurden), lieber durch die Gesamtheit der eingetragenen Adressnodes repräsentiert und Polygone bei Bedarf hieraus errechnet werden sollten? Kann mich nicht erinnern. Aber niemand *muss* diese PLZ-Grenzen verwenden - wer lieber Grenzen aus der Gesamtheit der eingetragenen Adressnodes ermitteln moechte, dem steht das frei. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ol-buisnessanwendung - tiles cachen
Am 29. Oktober 2010 14:53 schrieb Jan Tappenbeck o...@tappenbeck.net: mit einem bekannten wird gerade über eine buisness-lösung auf basis von openlayer-karten mit osm-daten nachgedacht. nun ist das ja so das im falle eines server-ausfalls die karten nicht verfügbar sind. gibt es da etwas diese zwischenzulagern - oder ist das unzulässig? mir war so als wenn darüber schon einmal diskuttiert worden ist. ein eigener tile-server ist mir aber ehrlich zu hoch gegriffen. kann jemand weiterhelfen ?? Ach so, Du meinst wenn der OSM-Server ausfällt, ich dachte zunächst, Du sprichst von Deinem eigenen. Für Business-Projekte sollte man nach Möglichkeit nciht den Tileserver des Projekts belasten, im Einzelfall kommt es natürlich auf die Zugriffsraten an, aber sobald eine gewisse Grenze überschritten ist wird man geblockt. Das Cachen der Tiles wird daher in jedem Fall erwartet und ist natürlich auch nicht verboten. Für Mapnik gilt das hier: http://wiki.openstreetmap.org/wiki/Tile_usage_policy Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ol-buisnessanwendung - tiles cachen
Am 29.10.2010 14:53, schrieb Jan Tappenbeck: gibt es da etwas diese zwischenzulagern - oder ist das unzulässig? mir war so als wenn darüber schon einmal diskuttiert worden ist. ein eigener tile-server ist mir aber ehrlich zu hoch gegriffen. Es ist sogar notwendig. Der Kachelserver unter tile.osm.org ist eine Einrichtung für die Community, auch eine Nutzung auf der Vereinsseite des TSV Buxtehude ist noch toleriert aber eine kommerzielle Nutzung im großen Maßstab ist nicht erlaubt und kann mit einem IP-Block oä. geahndet werden. Ein Proxy-Cache mittels der von Lars genannten Techniken ist notwendig. Eine ausführliche Anleitung zum Einrichten eines eigenen Tile-Servers ist auch verfügbar: http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore http://wiki.openstreetmap.org/wiki/DE:HowTo_Mapnik_%26_Tirex für Fragen stehen wir gerne zur Verfügung. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Wenn die Häuser einigermassen dicht mit addr:postcode getaggt sind, kann das funkionieren. Aber das ist oft nicht der Fall: in allen Freiburger (Breisgau) PLZ Gebieten gibt es maximal 8 addr:postcode getaggte Gebäude. Bevor sich da was tut, ist es wesentlich einfacher, die Grenze zu zeichnen. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5686705.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PotM November - Hotels und andere Unter künfte
Am 28.10.2010 09:03, schrieb Jan Tappenbeck: habe gerade die internationale Seite entdeckt und mal eben eine deutschsprachige erstellt. http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/november Die Idee gefällt mir. Aber ich vermisse Ferienwohnungen. Möchten wir die aus irgendwelchen Gründen (welche) nicht erfassen oder sind sie vergessen worden? Könntest du das evtl. noch aufnehmen? Hab im Wiki leider nichts passendes gefunden. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PotM November - Hotels und andere Unter künfte
Am 29.10.2010 17:05, schrieb olvagor: Am 28.10.2010 09:03, schrieb Jan Tappenbeck: habe gerade die internationale Seite entdeckt und mal eben eine deutschsprachige erstellt. http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/november Die Idee gefällt mir. Aber ich vermisse Ferienwohnungen. Möchten wir die aus irgendwelchen Gründen (welche) nicht erfassen oder sind sie vergessen worden? Könntest du das evtl. noch aufnehmen? Hab im Wiki leider nichts passendes gefunden. Gruß, Markus guest_house war versehentlich nicht ausgewertet !!! läuft gerade ! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads jetzt als Binaerformat
Guenther Meyer wrote: Allerdings richte ich mich mit den Geofabrik-Extrakten eher an die Community - an diejenigen, die die Daten irgendwie auf eine von mir nicht vorbestimmte Art weiterverarbeiten. Deswegen biete ich diese verlustbehafteten Optionen nicht an, weil das die Daten fuer einige Zwecke untauglich machen wuerde. Eine zweite gestrippte Version bereitzustellen waere wohl zuviel verlangt, oder ;-) Dadurch sinkt evtl. das Downloadvolumen, was sich aber wohl kaum bemerkbar machen dürfte. Allerdings steigt die Last beim Erstellen der ganzen Dateien auf ungefähr das doppelte. Ich glaub das ist ineffektiv ;) @Frederik: Wäre es möglich, die polygone-Files der Kontinente irgendwie öffentlich zu verlinken? Die Dateien für die Länder sind in der Readme.html verlinkt, allerdings gibt es dort keine Kontinente. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Downloads-jetzt-als-Binaerformat-tp5560595p5686967.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Ulf Lamping wrote: Wenn man daher den Zufahrtsweg zusammen mit der Fähre als Verbindung von A nach B ansieht - und darum geht es hier ja - paßt service auf einmal viel weniger. Dann ist es nämlich keine schnöde Zufahrt mehr, sondern Teil einer Verbindung - und da paßt ein unclassified dann schon wieder viel eher. Es kommt wie immer auf die Art der Fähre an. Wenn die Fähre eine reguläre Straße ersetzt, dann geht bspw. auch der trunk bis an die Fähre. Gibt es in Norwegen recht häufig. In dem Fall ist es dann keine Zufahrt. Wenn die Bundes-, Land- oder was-auch-immer Straße bis an die Fähre oder den Zug führt, dann sollte auch der highway-Wert erhalten bleiben. Wenn es aber eine normale Hafenzufahrt (Bspw. Hirsthals in Dänemark oder der Fährhafen in Rostock) ist, dann ist ein service schon gerechtfertigt. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/AIO-Routing-uber-Fahren-tp5452303p5687003.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einzelne Nodes für Bus und Bahnhaltestel len?
Am 29.10.2010 11:00, schrieb Peter Wendorff: Wenn sich eine Haltestelle einfach über eine nennenswerte Strecke entlang der Straße erstreckt, bin ich auch weiterhin für platform, selbst wenn da keine bauliche Plattform existiert. Als Kompromiss kann man ja (wenn denn das Beispielfoto aus D wäre) ein traffic_sign=DE:224 setzen. Das mache ich immer, um zu verdeutlichen, daß es sich um eine Mastposition handelt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PotM November - Hotels und andere Unterk ünfte
Am Donnerstag 28 Oktober 2010 schrieb Jan Tappenbeck: Am 28.10.2010 10:14, schrieb Stefan Dettenhofer (StefanDausR): Am 28.10.2010 09:38, schrieb Jan Tappenbeck: habe ich es gleich allgemein geschrieben und hinter ... kann sich vieles verbergen. Gut! Danke, Stefan hier ist nun auch eine karte zu finden: http://www.tappenbeck.net/osm/maps/deu/index.php?id=1030 gruß Jan :-) Hallo Jan, bei uns fehlen einige Pensionen, bisher mit tourism=guest_house gataggt. Wie in http://wiki.openstreetmap.org/wiki/DE:Map_Features. Ist vielleicht Deine Auswerting nicht ganz korrekt? Heinz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmosis-bug in Geofabrik-Extrakten?
On Fri, Oct 29, 2010 at 08:36:37AM +0200, André Joost wrote: Hallo, auf folgendes Problem bin ich gerade gestoßen: Die line-relation gemäß oxomoa-Schema für die Aachener Buslinie 1 sieht in der api so aus: osm version=0.6 generator=OpenStreetMap server relation id=969861 visible=true timestamp=2010-07-12T13:13:26Z version=4 changeset=5198960 user=wonk uid=79958 member type=relation ref=969505 role=/ member type=relation ref=86812 role=/ member type=relation ref=1066454 role=/ member type=relation ref=1066614 role=/ member type=relation ref=1066633 role=/ tag k=line v=bus/ tag k=name v=Bus 1/ tag k=network v=AVV/ tag k=operator v=ASEAG/ tag k=ref v=1/ tag k=type v=line/ /relation /osm Im Extrakt der Geofabrik sieht sie dagegen so aus: relation id=969861 version=4 timestamp=1969-12-20T21:22:32Z uid=79958 user=wonk changeset=5198960 member type=relation ref=969505 role=/ member type=relation ref=86812 role=/ tag k=line v=bus/ tag k=name v=Bus 1/ tag k=network v=AVV/ tag k=operator v=ASEAG/ tag k=ref v=1/ tag k=type v=line/ /relation Irgendwie fehlen da drei Relationen. Sie sind zwar selber im Extrakt drin, aber nicht in der Line-Relation. Die fehlenden kreuzen auch nicht die Grenzen des Extrakts. Nun weiß ich ja, dass Relationen in Relationen nicht gern gesehen werden, aber Oxomoa hats nun mal so gewollt. Wenn alle oder keine Relationen drin wären könnte ich dass ja verstehen, aber warum nur zwei von fünf? Hat jemand ne Erklärung oder Lösung? Das liegt daran, dass osmosis die Eingabedatei nur einmal durchparst beim Ausschneiden. Wenn es nun bei verschachtelten Relationen vorbeikommt, übernimmt es nur die Relationen, von denen es bereits weiss, dass sie im auszuschneidenden Gebiet enthalten sind. Anders gesagt, du findest alle Relationen, die eine kleinere OSM-ID haben, aber die mit grösserer OSM-ID fehlen. Ob das ein Bug oder Feature von osmosis ist, da kann man sich streiten. Die andere Möglichkeit, die osmosis hätte, wäre alle Unterrelationen ohne Check zu übernehmen. Aber dann kann es passieren, dass nicht vorhandene Relationen referenziert werden und das ist manchmal auch nicht gewollt. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 28.10.2010 22:55, schrieb Chris66: Am 28.10.2010 21:36, schrieb Carsten Moeller: Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Ein chaotisches Beispiel ist da der Hindenburdamm nach Sylt. Mal kommt man rüber dann wieder nicht, weil irgendwer per GPS alles verschlimmbessert hat. Der ist als route=shuttle_train eingetragen Und dann sind da noch die level_crossings. Ja, wer die vergisst, der wird fast jeden Router von der Straße auf die Schiene kriegen. Egal wo ;-( Deshalb hatte ich die Route NUR an den Endpunkten mit dem Straßennetz verbunden. Stimme übgrigens damit überein, die Anschlüsse zu Fähren und Autozügen NICHT als service zu taggen. Dies würde bedeuten, dass jede Routing-Topologie sämtliche services berücksichtigen müsste. ??? Aus meiner Sicht ist highway=service korrekt. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich stimme mit Dir in allen Punkten überein. a) es ist ein Service b) route=shuttle_train ist exakt! Nur leider habe ich route=shuttle_train nur ganz selten in den XMLs gesehen. Die Tendenz war doch eher railway=rail und motorcar=yes. Ferner ist es für Konvertierer ganz schwer vorherzusagen, ob ein Service nun eine hohe Prioriät geniesst oder nur zur nächsten Milchkanne führt. Folglich muss eine Router solche Wege immer mit durchforsten. Es sei denn man könnte noch ein weiteres Hinweis-Tag an dieser Stelle setzen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 09:30, schrieb Chris66: Am 29.10.2010 08:56, schrieb Garry: Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er Und wenn der Service genau in der Mitte der Strecke liegt? Das wäre der Worst-Case! Ich meine in allen Fällen in denen service nicht Anfang und/oder Ende der Strecke ist. Unter Umständen ist das Service-Stück ja auch noch entgegengesetzt zur Zielrichtung. Mir ist bekannt dass Garmin ein Problem mit niederklassifizierten Straßen in der Mitte der Route hat, aber ich dachte die modernen A-Star etc. Algos kämen damit klar. Eine bessere Lösung als deswegen die Zufahrtswege als primary zu taggen wäre eine Annotationstag wie mkgmap:routing_class=+3 oder so... Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ja, diese Art Tags wären SUUUPER! Nur leider sehe da jetzt kaum noch eine Chance, das nachträglich irgenwie in die Daten hineinzuoperieren. Einfacher wäre es doch, eine Mischaussage ala highway=wichtige_zufahrt oder so einzuführen. mkmap:routing_class=+3 halte ich für wenig durchsetzungsfähig - weil irgenwie kryptisch bzw. spezifisch klingend. Aber irgendwas muss man da mal in Angriff nehmen. Hier fehlt in OSM eindeutig eine wichtige Info für einen doch durchaus wichtigen Anwendungsfall, nämlich das Routing. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 10:24, schrieb Sven Geggus: Chris66chris66...@gmx.de wrote: ??? Aus meiner Sicht ist highway=service korrekt. Eben, wüsste nicht was besser passt, classified ja wohl kaum. Warum ein Router service _nicht_ berücksichtigen sollte müsste Carsten erst mal erklären. Für größere Parkplätze möchte man das beispielsweise ohnehin haben. Meine Rheinfähre hat jedenfalls Servicewege: http://osm.org/go/0DP7TJddE-- Gruss Sven Hallo Chris, natürlich ist highway=service korrekt. Aber eben nicht ausreichend. Siehe meinen Kommentar oben. Ich will nur kurz ein paar Daten liefern: Um ein vernünftiges Routing über Europa aufzubauen, braucht man in etwa 650MByte an segmentierten OSM-Wegen. Das sind dann faktisch nur die Start- und End-Punkte und ein paar zusätzliche Infos wie Kosten etc. Das ist noch einigermaßen schlank, wären aber nur die Highways. Würde man jetzt noch alle Services und, welche ich für wichtiger erachte: Tracks und Pedestrians, mit aufnehmen, wäre das schon eine beträchtliche Menge an Daten (ca. 1 Gig) - ok - immer noch verarbeitbar - jedoch jetzt mit services angefüttert, die zu 95% uninteressant sind. Ferner müsste ein Router diese jedes Mal mit abklappern. Zur Zeit ergeben sich aus den osm-Daten für Europa ca. 10 Mio. Vertices (WorstCase-Routing). Diese schafft mein Rechner (olle Kiste) in ca. 30 Sekunden. Entsprechend würde sich ein Routing stark verlangsamen, wenn auch noch unwichtige Verbindungen hinzukämen. Des Pudels Kern eines Aufbaus einer solchen Topologie und eines späteren Routings liegt aber in bestimmten Voraussagen. Ein AStar ist davon genau so betroffen wie ein doofer Dijkstra. Der Algo ist also nicht der geeignete Schlüssel OSM-Daten diesbezüglich einigermaßen nutzen zu können. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Carsten Möller wrote: Ja, diese Art Tags wären SUUUPER! Nur leider sehe da jetzt kaum noch eine Chance, das nachträglich irgenwie in die Daten hineinzuoperieren. Einfacher wäre es doch, eine Mischaussage ala highway=wichtige_zufahrt oder so einzuführen. mkmap:routing_class=+3 halte ich für wenig durchsetzungsfähig - weil irgenwie kryptisch bzw. spezifisch klingend. Aber irgendwas muss man da mal in Angriff nehmen. Hier fehlt in OSM eindeutig eine wichtige Info für einen doch durchaus wichtigen Anwendungsfall, nämlich das Routing. dickes - Ein subjektives taggen einer Routing-class ist völlig unnütz. Zum einen schätzt jeder Router die Wege völlig anders ein, zum anderen macht dies auch jeder Mapper. Sinnvoller wäre es allgemein den Weg besser zu beschreiben. Bei highway=service gibt es bspw. den Key service=*, den man als Router auswerten kann und darüber Zufahrten herausfiltern kann und ihnen die benötigte Road_Class zuweisen. In die Daten gehört eine möglichst genaue Beschriebung der Realität. Die Interpretation muss die Anwendung liefern. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/AIO-Routing-uber-Fahren-tp5452303p5687649.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 29.10.2010 11:35, schrieb M∡rtin Koppenhoefer: Am 28. Oktober 2010 21:36 schrieb Carsten Moellercmindivid...@gmx.de: Am 26.08.2010 13:44, schrieb M∡rtin Koppenhoefer: Ein ähnliches Problem tritt z.B. auch beim Routing über Autozüge auf! Hier bitte auch railway=rail + motorcar=yes ! Du meinst damit aber nicht, motorcar=yes an die Schienen zu taggen, oder? Das hielte ich für extrem falsch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Martin, Deiner Kommentarstrecke nach zu urteilen, verstehst du was von Routing. Das ist schön. - Nein, das ist jetzt ernst gemeint. :-) Natürlich ist railway=rail + motorcar=yes Mist. Hab das aber jetzt so häufig gesehen, dass ich mich schon drauf eingestellt habe und dies entsprechend berücksichtige. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmosis-bug in Geofabrik-Extrakten?
Hallo Am 29.10.2010 19:45, schrieb Sarah Hoffmann: Ob das ein Bug oder Feature von osmosis ist, da kann man sich streiten. Für mich ist das ein Bug. Ein Feature wäre es, geschachtelte Relationen überhaupt nicht zu behandeln. Aber manche zu behandeln und andere nicht, nur weil sie in der XMLDatei weiter hinten stehen, das ist Quatsch. Die andere Möglichkeit, die osmosis hätte, wäre alle Unterrelationen ohne Check zu übernehmen. Aber dann kann es passieren, dass nicht vorhandene Relationen referenziert werden und das ist manchmal auch nicht gewollt. Es gibt noch andere Möglichkeiten. Ich hatte dieses Problem bei meinem Perl-Skript für das Extrahieren von realtionen aus OSM-Dateien auch. Ich habe die Holzhammermethode gewählt und durchlaufe die Relationen in der OSM-Datei mehrmals, solange bis alle benutzten Relationen eingelesen sind. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Hallo, Am Freitag 29 Oktober 2010 00:42:01 schrieb Stephan Wolff: Manchmal muss man nur die Gemeinderelation als PLZ-Relation kopieren. In größeren Städten gibt es oft innere Grenzen der PLZ-Gebiete, die nicht mit den politischen Grenzen übereinstimmen. Ich habe für Neumünster und die Hälfte von Kiel die PLZ-Relationen angelegt und dafür einige Stunden benötigt. Gerade in den Großstädten (Berlin, Hamburg, Köln, Ruhrpott) fehlen die Daten fast ganz. Die Hamburger Mapper hatten so stolz gemeldet, alle Straßen erfasst zu haben und schwächeln jetzt bei den PLZ. ;-) Die Hamburger Mapper stehen vor dem Problem, dass schon die Stadtteilgrenzen nur so nach Hörensagen eingezeichnet wurden. Jetzt kommt Frederik mit seinen PLZ-Grenzen, die nirgends passen. Die Häuser in den einzelnen Straßen gehören teilweise zu einem, zu 2 oder zu noch mehr PLZ-Zonen. Dabei sind die Hausnummern vielfach noch nicht erfasst. Das wird noch dauern. Ein Dorf in eine PLZ-Zone schieben ist etwas einfacher. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlechtest Wertung für OSM im Kartenver gleich
Am 24.10.2010 18:42, schrieb Felix Hartmann: Ohne hier irgendjemand persoenlich attackieren zu wollen, frag ich mich schon, warum Frederik sich so vehemenent dafuer einsetzt, ein beschissenes Rendering zu verteidigen. Fuer mich kann da eigentlich nur der Schluss kommen, dass Geofabrik hier selber bessere Karten vermarkten/verkaufen moechte. [Kopfschüttel] über so ein Argument! Arbeite mal mit Frederik und Jochen zusammen und Du wirst sie in einem anderen Licht sehen = die Beiden sind mehr als fair zum Projekt und zur Community! Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Moin, die meisten OSM-Tags sind nicht eindeutig definiert. Regelmäßig werden hier, im Forum und im Wiki Fragen zur Verwendung der Tags diskutiert, wie z.B.: - Umfasst landuse=residential/industrial/retail nur die entsprechend genutzten Privatgrundstücke oder auch die dazwischenliegenden Straßen? - Gibt width bei Straßen die Breite der Fahrbahn oder die Gesamtbreite inklusive Parkstreifen, Grünstreifen und Gehweg an? - Gilt amenity=fuel nur für öffentliche KfZ-Tankstellen oder auch für Tankstellen für Schiffe, Flugzeuge und Schienenfahrzeuge? - Wird ein Friedhofsweg für Besucher und Fahrzeuge der Friedhofsgärtner als path, footway, track oder service eingegeben? - Kennzeichnet natural=tree nur besondere oder jeden beliebigen Baum? - Werden auch Modellflugplätze als aeroway=aerodrome getaggt? Bei den meisten Diskussionen mit mehr als drei Teilnehmern gibt es am Ende keinen Konsens. Oftmals zeigt sich nicht einmal die Bereitschaft, die Argumente der anderen aufzunehmen und eine pragmatische Lösung zu finden. Als Folge gibt es Unsicherheit bei neuen Usern, lokale Editwars, uneinheitliche Kartendarstellungen und Fehlinterpretationen bei der Datennutzung. Manche Tags sind gar nicht auswertbar, wenn man die benutzte Definition nicht kennt. Ich habe den Eindruck, dass viele Mapper unter der gegenwärtigen Situation leiden und klarere Definitionen bevorzugen würden. Daher möchte ich einmal die Metafrage stellen: Wie können wir zu eindeutigen Definitionen der Tags kommen? Mögliche Ansätze und Probleme: Abwarten, welche Interpretation sich durchsetzt (Anarchie) - bei vielen Fragen keine Konvergenz erkennbar - Unsicherheit und Fehlinterpretationen bleiben für lange Zeit de facto Festlegung einzelner durch massive Datenänderung (z.B User Kraftfahrstraßen), Wikiänderungen ohne Konsens oder Editorvoreinstellungen (Despotie) - undemokratisch - meist keine dauerhafte Lösung Abstimmungen im Wiki (Basisdemokratie) - oft schwache Beteiligung, geringe demokratische Legitimation - kaum Schutz gegen Mehrfachstimmabgabe Wahl eines Gremiums, das verbindliche Regeln festlegt (repräsentative Demokratie) - schwierige Wahlverfahren - geringe Akzeptanz bei vielen Mappern Dazu kommt natürlich das Problem, dass viele Fragen nur international gelöst werden können, aber auch OSM-Teilnehmer, die nur wenig Englisch beherrschen, nicht ausgegrenzt werden sollten. Ich kenne keine Ideallösung. Als vage Idee könnte ich mir eine Gruppe von Moderatoren vorstellen, die die wichtigsten Fragen identifizieren, zu konkreten Alternativen zusammenstellen, Übersetzungen koordinieren und in regelmäßigen Abständen zur Abstimmung über diese Fragen aufrufen (moderierte Basisdemokratie). Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlechtest Wertung für OSM im Kartenver gleich
Hallo, Felix Hartmann wrote: Ohne hier irgendjemand persoenlich attackieren zu wollen, frag ich mich schon, warum Frederik sich so vehemenent dafuer einsetzt, ein beschissenes Rendering zu verteidigen. Fuer mich kann da eigentlich nur der Schluss kommen, dass Geofabrik hier selber bessere Karten vermarkten/verkaufen moechte. Da muss ich schon Luft holen. Du unterstellst mir, ich wuerde mir hier irgendwelche Argumente aus den Fingern saugen, um dahinter den wahren Grund zu verstecken (naemlich dass ich moeglichst viel Geld mit einem besseren Rendering verdienen will) - dass ich also konsequent, monatelanglang, ohne rot zu werden, hier die 931 Abonnenten dieser Mailingliste plus alle, die das ganze irgendwo im Web lesen, anluege. Und das ist fuer Dich eine kleine Sache, die man mal so eben ohne jemanden persoenlich attackieren zu wollen auf eine Mailingliste schreibt. Entschuldige mal, aber GEHTS NOCH? Das ist doch so ziemlich die schlimmste Anschuldigung, die man ueberhaupt gegenueber einem Mailinglistenteilnehmer erheben kann (der meint in Wahrheit was anderes und verschaukelt uns alle). Ich weiss ja nicht, in was fuer einem sozialen Umfeld Du dich so bewegst, aber wenn man da mal eben behaupten kann, jemand anders waere ja ein mieser Luegner, und das ganze keine persoenliche Attacke ist, dann wundert mich nichts mehr - dann ist es natuerlich auch selbstverstaendlich, dass beschissen ein ganz normales Adjektiv ist fuer einen Kartenstil, in den wesentlich mehr freiwillige Arbeit geflossen ist als in Deine eigenen kartographischen Produkte, die Du selbst ja offenbar fuer das beste seit geschnittenem Brot haeltst. d) wir schieben die Schuld an sauschlechten Karten weiter auf die Renderer, und sagen so wie Frederik, dass gute Karten nicht der Sinn von Openstreetmap.org sind. Koennen ja andere kommerziell ausbeuten, dass die Openstreetmap Community hier ganz einfach versagt. Also entweder kann man aus OSM gute Karten machen - dann kann man das gewerblich oder auch als Hobby. Oder man kann es nicht - dann kann es weder der gewerbliche Anwender noch der Hobbyist. OSM soll ein Datensatz sein, aus dem man gute Karten machen kann. Bloss sollte unser Hauptaugenmerk dem gelten, diesen Datensatz zu pflegen, und nicht, schoene Webseiten zu gestalten, auf denen man eine hieraus errechnete Karte komfortabel nutzen kann. Das koennen andere tun - und zwar von mir aus sehr gern auch gewerbliche Anbieter, das spart uns schon die Serverkosten. Ich verstehe wirklich nicht, in was fuer einer verqueren Denke Du da drin steckst. So gern Du das vielleicht haettest - es gibt hier keine Zielkonflikte zwischen gewerblichen Anbietern und OSM. Im Gegenteil. Schau dir Mapquest an: Die haben einen schoenen Stil entwickeln lassen, haben sogar einem altgedienten OSMer Geld dafuer gegeben, dass er seinen Sachverstand fuer sie einsetzt, bieten nun die Kartentiles fuer jeden zur freien Nutzung an *und* die Styles auch (uebrigens unter einer BSD-Lizenz, sprich also wesentlich freier als CC-BY-SA). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Großdeutschland?!
Hallo zusammen, die Mapnik Karte hat keien deutsche Grenze mehr! Hat die jemand gelöscht? http://osm.org/go/0JDJ9 Gruss Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online-Befragung der OSM-community - community-Daten zu gewinnen!
Oder noch besser, der Zeitungsartikel wo sich Hauseigentümer in der lokalen Presse damit rühmen dem StreetView-Bild Ihres Hausen widersprochen zu haben, aber im Zeitungsartikel mit vollem Namen und voller Adresse abgedruckt werden. Was tun manche Individuen nicht alles für Publicity? Aber das Beispiel ist gut im Hinblick auf Konsequenten Umgang mit seiner Persönlichkeit. Kann ich da vielleicht die Referenz haben, ich würde das gern in meiner Vorlesung verwenden. ich bin der Meinung ich hätte das hier auf der ML gelesen, kann es aber gerade nicht finden. Wenn es mir noch unterkommt, melde ich mich. -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online-Befragung der OSM-community - community-Daten zu gewinnen!
Am 30. Oktober 2010 01:03 schrieb geo.osm geo@googlemail.com: Oder noch besser, der Zeitungsartikel wo sich Hauseigentümer in der lokalen Presse damit rühmen dem StreetView-Bild Ihres Hausen widersprochen zu haben, aber im Zeitungsartikel mit vollem Namen und voller Adresse abgedruckt werden. Was tun manche Individuen nicht alles für Publicity? Aber das Beispiel ist gut im Hinblick auf Konsequenten Umgang mit seiner Persönlichkeit. Kann ich da vielleicht die Referenz haben, ich würde das gern in meiner Vorlesung verwenden. ich bin der Meinung ich hätte das hier auf der ML gelesen, kann es aber gerade nicht finden. Wenn es mir noch unterkommt, melde ich mich. War es das hier?: http://blog.fefe.de/?ts=b29afd7d Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
die meisten OSM-Tags sind nicht eindeutig definiert. [..] Ich habe den Eindruck, dass viele Mapper unter der gegenwärtigen Situation leiden und klarere Definitionen bevorzugen würden. Daher möchte ich einmal die Metafrage stellen: +1 Wie können wir zu eindeutigen Definitionen der Tags kommen? Mögliche Ansätze und Probleme: Abwarten, welche Interpretation sich durchsetzt (Anarchie) Individual mappers have every right to tag things differently from what is stated in the Wiki [1] Das bedeutet mit anderen Worten der Autor des Wikiartikels wuenscht Anarchie. - bei vielen Fragen keine Konvergenz erkennbar - Unsicherheit und Fehlinterpretationen bleiben für lange Zeit - die beste Chance, Glaubenskriege zu fuehren Wahl eines Gremiums, das verbindliche Regeln festlegt (repräsentative Demokratie) - schwierige Wahlverfahren - geringe Akzeptanz bei vielen Mappern Ich glaube nicht, dass die Akzeptanz ein Problem waere. Unterm Strich gaebe es weniger Frust, als mit den von Dir sehr treffend beschriebenen aktuellen Problemen. Das Gremium koennte (sollte?) doch ein Teil der OSMF sein, aber die OSMF moechte sich offiziell nicht in die Inhalte einmischen. Wenn sie es selbst nicht moechte, werden die sicher nicht auf ein Gremium gewartet haben, dass administrativ bestimmt was auf dem OSM Speicher passiert und was nicht. Konkret zu Deiner Frage: Ich wuerde mir auch klarere Regeln wuenschen. Ein Gremium halte ich dafuer sehr geeignet. Wenn dies gewuenscht wird ist die Wahl das kleinste Problem. Eher aktive freiwillige zu finden vgl. [2] [1] http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct [2] http://www.mail-archive.com/t...@openstreetmap.org/msg32223.html -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
