Re: [Talk-de] highway=abandoned
Hallo, ich meine, es gab schon einige Diskussionen darüber, ob man historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was vor Ort noch real existiert. (Ausnahmen gibt es vielleicht noch für Objekte, die im Bau oder geplant sind, also in absehbarer Zeit echte Objekte werden.) Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag daran hängen, das tut nicht weiter weh. Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein Neubaugebiet ist, sind das nur noch historische Daten. Mag sein, dass auch die interessant sind, aber das gehört IMHO dann nicht mehr in OSM. Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags, von wann bis wann das Objekt existierte... Grüße Michael On 21/08/13 13:30, tumsi wrote: Hallo zusammen, Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden. Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich finde das ganze etwas seltsam, vor allem, wenn man vor Ort nicht einmal mehr erkennen kann, dass dort irgendwann einmal Straßen existierten! Welchen Wert hat das ganze in der Datenbank? Ich mappe doch auch keine Gebäude, die abgerissen wurden und an deren Stelle nun neue Gebäude stehen... Wie seht ihr das? Viele Grüße, Constanze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autokennzeichen
On 09/08/13 21:57, Christian Hauer wrote: Am 09.08.2013 20:24, schrieb Martin Koppenhoefer: in Italien schon länger nicht mehr, da bedeuten die ersten beiden Stellen das Jahr der Erstzulassung Ok ok, ich nehm ja Italien schon zurück ;) Italien und Frankreich haben inzwischen das gleiche Schema: Nummern der Form AA 123 BB, die fortlaufend vergeben werden (so dass aus den ersten zwei Buchstaben auf das Zulassungsdatum geschlossen werden kann; in Italien wechseln die ersten zwei Buchstaben im Schnitt alle zwei Monate, in Frankreich geht es etwas schneller). Das Provinz- oder Départementkürzel (2 Buchstaben in Italien, 2 Ziffern in Frankreich) kann im rechten Streifen stehen, ist aber freiwillig und kann irgendeines sein, nicht notwendigerweise das eigene. Sowohl in Italien als auch in Frankreich werden diese Kürzel aber weiterhin benutzt, u.a. für Adressangaben. In Italien findet man in Anschriften z.B. häufig Ortsangaben wie 20094 Corsico (MI) (in dem Fall ein Ort in der Provinz Milano). In Frankreich sind die ersten zwei Ziffern der Postleitzahl mit der Départementnummer identisch, in Text findet man zur groben geographischen Einordnung zum Teil Ortsangaben wie Modane (73) (d.h. im Département Savoie, Nr. 73). Etwa ein Viertel der EU/EEA-Staaten hatte nie eine regionale Zuordnung der Autokennzeichen, ein weiteres Viertel hat sie mittlerweile abgeschafft bzw. denkt in einem Fall über eine Einführung nach, etwa die Hälfte hat es in Gebrauch, wobei es von Staat zu Staat Unterschiede gibt, ob bei Verkauf der Fahrzeugs oder Umzug das Kennzeichen gewechselt wird oder nicht. In den Staaten, die eine regionale Zuordnung haben oder früher hatten, werden die Kürzel oft auch anderweitig verwendet. Beispielsweise verwenden in Deutschland auch Tierärzte das Kreiskürzel in ihren Kennummern (Katzenbesitzer, schaut euch mal das Tattoo eurer Lieblinge an, sofern vorhanden). Der langen Rede kurzer Sinn: warum nehmen wir dieses Kürzel nicht einfach in den ref-Tag der jeweiligen Verwaltungseinheit auf? Die Litauer machen das schon (allerdings sind die Kürzel in OSM zweistellig und nicht mit denen im Kfz-Kennzeichen identisch). Die Amerikaner machen das gleiche mit den Kürzeln für ihre Bundesstaaten. In kleineren Zooms wird das dann auch gerendert und nimmt weniger Platz weg als der volle Name. Grüße Michael PS: Kfz-Kennzeichenschemata im einzelnen: Österreich: Bezirkskürzel (1-2 Buchstaben) am Anfang der Autonummer Bulgarien: Provinzkürzel (1-2 Buchstaben) am Anfang der Nummer Kroatien: Provinzkürzel (2 Buchstaben) am Anfang der Nummer Zypern: Autonummern ohne regionale Zuordnung Tschechien: 2. Zeichen (1 Buchstabe) der Nummer bezeichnet die Region (Kraj), z.B. 1A2-3456 für Prag (A) Estland: 1. Buchstabe bezeichnet die Region, z.B. 123 ABC für Tallinn (A) Finnland: heute keine regionale Zuordnung mehr, früher (1972-1989) bezeichnete der 1. Buchstabe die Region Griechenland: Präfekturkürzel (2 Buchstaben) am Anfang der Nummer Ungarn: heute keine regionale Zuordnung, aber es gibt Pläne, diese einzuführen Irland: Grafschaftskürzel (1-2 Buchstaben) zwischen den beiden Zifferngruppen Litauen: heute keine regionale Zuordnung mehr, bis 2003 gab der 2. Buchstabe die Region (Apskritis) an, z.B. CPN 183 für Panevėžys (P) Norwegen: die ersten zwei Stellen identifizieren die Stadt, meist mehrere Kürzel pro Stadt Polen: 2-3 Buchstaben Bezirkskürzel, von denen der erste die Woiwodschaft identifiziert, am Anfang der Nummer, z.B. SZY 1234 für Żywiec, Woiwodschaft Śląskie (S) Portugal: nur für Anhänger und Exportfahrzeuge, 1-2 Buchstaben für die Zulassungsstelle, z.B. VS-08-15 oder 08-15-VS für Viseu Rumänien: Bezirkskürzel (1-2 Buchstaben) am Anfang der Nummer Slowakei: Bezirkskürzel (2 Buchstaben) am Anfang der Nummer. Einige Städte bestehen aus mehreren Bezirken, vergeben aber nur eine Nummer (Ausnahme Bratislava, wo der Nummernvorrat für BA bereits ausgeschöpft ist und daher zusätzlich BL verwendet wird.) Slowenien; Bezirkskürzel (2 Buchstaben) am Anfang der Nummer Spanien; heute keine regionale Zuordnung mehr, vor 2000 Provinzkürzel (1-2 Buchstaben) am Anfang der Nummer Schweiz: Kantonskürzel (2 Buchstaben) am Anfang der Nummer UK: seit 2001 1. Buchstabe Region, 2. Buchstabe Zulassungsstelle. Der Regionsbuchstabe ist eineindeutig, Zulassungsstellen haben mehrere Kürzel. Z.B. LA51BCD und LB51FGH für Wimbledon (London), Belgien, Dänemark, Lettland, Liechtenstein, Luxemburg, Malta, Niederlande, Schweden: keine regionale Zuordnung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pseudonamen
On 30/06/13 13:39, Wilhelm Spickermann wrote: Spricht etwas dagegen, solche Texte von name nach description zu verschieben? Ja, so global schon (sprich: Nein, außer...) Für die Relationen legt die Beschreibung der Relationen die Bedeutung der Relationstags fest. So ist im Public Traffic Proposal für den Namen von Linienvarianten angegeben: verkehrsmittel nr doppelpunkt from doppelpfeil to also z.B. Bus 17: Paris =Pelkum Das sollte man nicht ändern, obwohl es ziemlich sicher so nicht woanders benutzt wird. Aber ansonsten bin ich sehr dafür. Im Prinzip ja... aber Erfahrung zeigt, dass Relationen in JOSM in der Relationen-Liste schwer wiederzufinden sind. Da hilft ein eindeutiger name-Tag (description wird in JOSM 5990 nicht ausgewertet). Zugegeben, das ist nur ein Workaround... besser wäre es, in JOSM die Darstellung der Relationen-Liste zu überarbeiten. Etwa so: - Icon für type und ggf. auch Untertyp (z.B. Bus-Icon für type=route; route=bus oder verschiedene Verkehrszeichen für verschiedene type=restriction) - Typ in Textform nur, wenn kein Icon definiert ist (spart Platz für bekannte Typen) - Geeignete Beschreibung. Im allgemeinen Fall eine Kombination aus ref und name; falls diese leer sind, description, ggf. noch weitere. Für einige Typen ist ein abweichendes Schema besser, etwa für Nahverkehrslinien name/from/to. Das ganze mit Styles anpassbar - damit würde sich der Use-Case für etliche solche Pseudonamen schon relativieren. Mit Pseudonamen an anderen Objekten wäre ich strenger... etwa München-Augsburg an einem Bahngleis oder Nummern von Tramlinien direkt am Gleis. Solche Informationen gehören eher in den description-Tag oder in eine route-Relation. Hier würde es evtl. helfen, wenn der Mapnik-Kartenstil nur noch für bestimmte Objekttypen (u.a. highway=*, place=*, building=* und alles, was ein POI-Icon hat) den Namen rendern würde - damit würde der Anreiz des Tagging für den Renderer wegfallen. Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie sinnvoll im Thread antworten? (Inhalticher Betreff: Open Data)
On 01/21/2013 03:37 PM, Bernd Wurst wrote: Hallo. Am 21.01.2013 15:18, schrieb Wolfgang Barth: kann man auf einen Einzelbeitrag hier in der Mailingliste antworten, auch wenn man nur die Zusammenfassungen bezieht? Nein, das geht prinzipbedingt nicht. Wenn diese Nachricht hier richtig in den Thread einsortiert wird, dann geht das. Die Zusammenfassung enthält alle Nachrichten als Attachment; einfach die passende Nachricht öffnen und mit reply to list darauf antworten. Das mache ich immer so, und wenn ich meine früheren Postings anschaue, hat das auch immer funktioniert. Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ODBL und bekannte Vandalen-Accounts
Hallo Liste, was passiert eigentlich im Zuge der ODBL-Umstellung mit den Daten, die von Vandalen à la lmaa-du-osm-korinthenkacker, hasse-osm-korinthenkacker usw. angefasst wurden? Soweit ich weiß, hat der ja gern ganze Kartenbereiche gelöscht und nahezu unverändert wieder eingefügt. Damit existiert jetzt ein Haufen gültiger, korrekter Objekte, die in V1 von ihm erstellt wurden. CT und ODBL hat er natürlich abgelehnt, und sowohl sein Verhalten als auch die Kommentare auf seinen Userseiten lassen nicht erwarten, dass er sie noch akzeptieren wird. Als Folge davon gibt es Bereiche auf der Karte, die komplett rot sind. Was passiert nach der Umstellung mit solchen Edits? Kann man für derartige Fälle pauschal davon ausgehen, dass die Daten nicht von ihm stammen und seine Edits als ODBL-clean markieren? Oder wie verhindern wir, dass durch derartigen Vandalismus ganze Gebiete von der Karte verschwinden? Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL und bekannte Vandalen-Accounts
SimonPoole wrote Am 09.03.2012 10:48, schrieb Falk Zscheile: Ich war der Meinung, dass hier auf der Liste mal davon die Rede war, dass die Edits dieses Users übernommen werden, weil sie nicht auf eigener Leistung des Mappers beruhen. Habe ich das falsch in Erinnerung? Ich hab diverse Sachen von ihm angeschaut und meiner Meinung nach ist das wohl kaum möglich. Er hat ja nicht nur Unsinn gemacht, also müsste man das alles händisch rausfiltern. Ob er wirklich irgendetwas Sinnvolles gemacht hat, dürfte schwer herauszufinden sein. Wie bereits erwähnt, hat er gern mal ganze Viertel gelöscht und wieder eingefügt, wohl, damit es auf den ersten Blick so aussieht, als wären seine Beiträge legitim. Ansonsten hat er gern mal Tags verbogen, etwa name=U-Bahn für U-Bahn-Stationen und dergleichen. Gibt es wirklich etwas, das auf seiner eigenen Leistung beruht? SimonPoole wrote Siehe http://cleanmap.poole.ch/?zoom=16lat=48.0854lon=11.50844layers=000B wenn ich in der Area auf Cleanmap gehe, schaut das ziemlich übel aus... die meisten Straßen fehlen. So, wie es auschaut, hat unser Freund wohl mehrere Accounts. Wenn er nun mit Account A Dinge gelöscht hat, die er danach mit Account B wieder angelegt hat, und für Account A die CTs akzeptiert, aber für Account B ablehnt, dann haben wir ein Problem... die Löschungen bleiben, die neuen Objekte nicht, im Endeffekt verlieren wir damit Daten. SimonPoole wrote einfach vom gelöschten remappen (lmaa* war ja die Hauptmotivation für den Layer). Warum übernehmen wir die Daten dann nicht einfach direkt? Urheberrechtlich kommt es auf das gleiche heraus, ob wir Daten beibehalten oder ob wir sie löschen, aber dann von den gelöschten Daten remappen. So oder so bilden lmaa*'s Daten die Grundlage und die neuen Daten erben damit jedwedes Urheberrecht von diesen. Das alles per Hand neu anzulegen, ist ein ziemlicher Aufwand - es ist mit Sicherheit einfacher, erstmal alles zu übernehmen und nur ungültige oder falsche Informationen zu korrigieren. Dieser Ansatz hat ja bislang auch funktioniert. Daher denke ich, wir sollten erst einmal klären, ob wir davon ausgehen können, dass dieser Benutzer Urheberrecht an seinen Edits beanspruchen kann (will heißen: eigene Leistung). Wenn nein: alle Changes als ODBL-clean betrachten. Wenn ja, können wir seine Edits nicht direkt übernehmen. Dann heißt es, überall dort, wo er Objekte angelegt hat, zu schauen, ob es dort alte Objekte gibt, die gelöscht wurden. (Möglicherweise unter einem anderen Account, der die CTs akzeptiert hat.) Dann sollten wir uns die dafür verwendeten Accounts genauer anschauen und schauen, was passiert, wenn wir diese Löschungen rückgängig machen. -- View this message in context: http://gis.19327.n5.nabble.com/ODBL-und-bekannte-Vandalen-Accounts-tp5550019p5550200.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] Ketten - wie taggen?
Martin Koppenhoefer wrote: Am 5. Oktober 2011 18:33 schrieb Gerritz0idb...@gmx.de: ich habe jetzt einige Filialen der Videothekenkette „World of Video“ hinzugefügt, mich dabei aber folgendes gefragt: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). neben operator käme evtl. auch brand in Frage. Im Prinzip ja, allerdings kann ein und derselbe operator mehrere brands betreiben. Beispielsweise führen viele Ketten kleinere Filialen unter eigenen Marken. Beispiel: operator=REWE, brand=REWE city oder brand=REWE Weitere Beispiele fallen mir derzeit nur außerhalb Deutschlands ein: operator=Maxima, brand=Maxima X oder brand=Maxima XX oder brand=Maxima XXX (dort gibt die Zahl der X die Größe des Geschäfts an) operator=Esselunga, name=Esselunga di Via Novara (Esselunga vergibt Orts- oder Straßennamen für seine Filialen) operator=iki, brand=iki oder brand=ikiukas (ikiukas sind kleinere Märkte mit eingeschränktem Angebot) Es hat also jeder der drei Tags operator, brand und name seine Berechtigung und eine eigene Bedeutung. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ketten - wie taggen?
Robert Kaiser wrote: Gerrit schrieb: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). AFAIK ist operator=o korrekt, aber genug Leute taggen für den Renderer, und der stellt es nur dar, wenn es (fälschlicherweise) im name=teht. Robert Kaiser siehe hierzu auch mein früheres Posting (habe Deins erst danach gesehen, sorry). Zum Rendering – am saubersten wäre es wohl, mit COALESCE(name, COALESCE(brand, operator)) zu arbeiten. Dann wird aus den Tags name, brand, operator der erste nicht-leere gerendert. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hinweis zum Mappen in Frankreich
Henning Scholland wrote: Am 24.08.2011 16:55, schrieb Chris66: Am 24.08.2011 16:33, schrieb Rainer Kluge: - Landuse ist in F überwiegend durch automatischen CORINE-Import erzeugt und weicht daher oft erheblich von der Realität ab. Wieso daher ? ;-) Weil CORINE, soweit ich weiß, per Satellit erfasst wird und damit die Auflösung begrenzt ist; auch kann bei der automatisierten Auswertung der Bilddaten auch mal der eine oder andere Fehler passieren. Mit GPS-Traces oder guten Luftbildern, die man dann von Hand abzeichnet, bekommt man bessere Ergebnisse. Ich habe mal einen Fall in Savoyen korrigiert, wo ein Stausee laut CORINE auch gleich die Straßen entlang der Ufer geflutet hat. Lage und Landuse waren zwar prinzipiell korrekt, aber die Kontur war sehr grob und die Fläche des Objekts war geschätzt doppelt so groß wie in Wirklichkeit. Wenn die Corine Daten so schlecht sind, wieso werden sie dann importiert ? ...weil eine bunte volle Karte schöner aussieht als eine weiße leere ;) Oder weil man mit deutlich weniger Aufwand eine einigermaßen passabel aussehende Karte bekommt – zumindest für bestimmte Objekte. Für niedrige Zoomstufen und zur groben Orientierung reicht die Präzision von CORINE ja. Aber da gehen die Meinungen auseinander: Als vor ein paar Monaten die Ergebnisse des CORINE-Imports in Rumänien Image of the Week waren, gab es bei uns in Italien auch die Diskussion, ob wir nachziehen sollten. Die Mehrheit war dagegen (nur Südtirol hat Daten importiert); das Ergebnis ist, dass in Italien deutlich weniger landuses gemappt sind als in Frankreich. Auch wird angeführt, dass Importe beim Aufbau einer Community eher hinderlich sind – auch hierfür gibt es in Frankreich einige Beispiele, wo Ortschaften zwar mit allen landcovers und Häusern erfasst sind, aber keine einzige Straße eingezeichnet ist... Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Android
Dimitri Junker wrote: Hallo, Nach vielem testen, googeln,... ist der Stand jetzt der: es gibt kein Navit.xml, man kann dies aber aus den apk extrahieren, da gibt es 3 je nach Bildschirmauflösung. Wenn ich dort den Pfad ändere und es nach sdcard/navit kopiere wird dies bei Download ignoriert. Aber zur Anzeige der Karte wird es wohl ausgewertet, aber so, daß bei mir keine Karte mehr angezeigt wird. Hmmm... versuche mal, irgendeinen Parameter in der navit.xml testweise zu ändern (z.B. ein OSD-Element deaktivieren) und schau, ob das in navit ausgewertet wird. Wenn ja, dann liegt zumindest schon mal die navit.xml an der richtigen Stelle. Wie der Download von Kartendaten direkt mit Navit funktioniert, habe ich noch nicht probiert... ich nutze den Navit Planet Extractor. Dort ein Recheck auswählen (testweise tut's ein kleines rund ums eigene Haus) und als navitmap.bin auf der SD-Karte abspeichern (im Navit-Verzeichnis, wo auch die xml-Datei liegt). Jetzt gilt es nur noch, den Pfad herauszufinden: Dazu brauchst Du einen Filemanager oder eine Kommandozeile auf dem Handy, per adb verbinden geht auch. Dann durch die Verzeichnistruktur hangeln, um den vollen Pfad zur bin-Datei herauszufinden. Bei mir ist das zum Beispiel /sdacrd/navit/navitmap.bin. Den Pfad dann in der XML-Datei entsprechend eintragen, das sollte ungefähr so aussehen: mapset map type=binfile enabled=yes data=/sdcard/navit/navitmap.bin / /mapset Vorsicht mit relativen Pfaden – keine Ahnung, zu was die relativ sind... zum Verzeichnis, in dem die navit.xml liegt, oder zu dem, in dem die Binaries liegen oder weiß der Himmel was... Hope it helps... und nicht verzagen, Navit hat zwar noch seine Ecken, aber in Sachen Entwicklung tut sich vieles, und was heute noch nicht funktioniert, kann schon bald besser werden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Android
Michael Zimmermann wrote: On Mon, 15 Aug 2011 02:04:14 +0200 Dimitri Junkero...@dimitri-junker.de wrote: Das erhöht den Aufwand für die Portierbarkeit auf andere Systeme... Wieso? Was meinst Du mit anderes System? Dieser fixe Pfad ist ja wohl ser Systemspeziefisch, also wäre eine Pfadauswahl doch wohl Systemunabhängiger. Und wenn da wirklich ein Programmierer Probleme hat eine Pfadauswahl einzubauen dann könnte man ja ein einfaches Konfigurationsfile nutzen. So ist es unbrauchbar! Die Karten samt Pfaden sind in der navit.xml hinterlegt, und die unterscheidet sich ohnehin schon von Plattform zu Plattform. Auf Windows CE ist beispielsweise ein Kartenausschnitt von München im Paket enthalten und konfiguriert... Hi, dann suche mal nach navit.xml (configfile) darin dann nach maps und passe dir den Pfad an hab aber keine Ahnung wo das auf einem Android liegt Im APK-File; soweit ich weiß, wird das irgendwohin extrahiert und dann diese Kopie benutzt (würde auf /data tippen). Ansonsten gibt es die Möglichkeit, eine eigene navit.xml auf der SD-Karte abzulegen, die dann Vorrang hat. Die muss auf der SD-Karte unter /navit/navit.xml liegen. In der kannst Du dann jeden beliebigen Pfad für die Kartendaten konfigurieren. Haken an der Sache: ob das mit der navit.xml auch funktioniert, wenn die SD-Karte nicht als /sdcard gemounted ist, weiß ich nicht... Im navit-Bugtracker sind zwei Tickets offen, um Navit auf SD installieren zu können [1] [2] und so auch ohne Rooting an die Konfigurationsdateien zu kommen. Wenn das alles nichts hilft, bleibt Dur nichts anderes, als noch ein Ticket aufzumachen und auf die Problematik hinzuweisen. Evtl. kann man ja, anstatt den Pfad /sdcard hart zu codieren, den tatsächlichen Pfad aus der Systemkonfiguration auslesen (z.B. aus der mtab). Irgendwie müssen ja auch andere Android-Apps mitbekommen, welchen Pfad die SD bzw. der integrierte Speicher hat, also muss das irgendwo hinterlegt sein... Michael [1] http://trac.navit-project.org/ticket/818 [2] http://trac.navit-project.org/ticket/918 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + alley?
Falk Zscheile wrote: Am 20. August 2011 10:41 schrieb yzemazeyzem...@gmx.net: On 20.08.2011 09:33, Peter wrote: Hi Gestern traf ich auf ein Eckchen wo recht viele kleine Zufahrtssträßchen liegen, Neubaugebiet. Ich würde denen gerne ein service=alley verpassen da das trifft, viel kleiner als normale Straßen. Die meisten Straßen dort sind auch normalbreit für eine Wohngegend. Nun ist das zum Teil aber auch verkehrsberuhigt, Spielstraße. Da beißt sich das da highway=living_street|service) sich ausschließt. Falsches Taggingschema? living_street hat IMHO mehr was richtung maxspeed. Naja. Also: highway=service , service=alley oder highway=living_street Im Moment taggte ich letzteres. Die schmalheit der Wege liesse sich mit width markieren, aber so genau wollte ich es auch nicht unbedingt, die klasse alley täte es eher. Weis einer ein passendes tagging ohne ein Faß von proposal aufzumachen? Moin, living_street=yes + traffic_sign=DE:325 ergänzen In Bamberg gibt es etliche ähnlich gelagerte Fälle, d. h. enge Gassen als verkehrsberuhigter Bereich (DE:325) ausgewiesen. Der hiesige Powermapper theophrastos hat die - vermutlich in Ermangelung eines besseren Schemas - samt und sonders als highway=service, service=alley, living_street=yes getaggt und noch eine note drangehängt, dass das so Absicht ist. Da mir bis dato auch nix besseres eingefallen ist (und ich auch ungern edit-wars starte ;)), habe ich erstmal die Finger davon gelassen, mal davon ausgehend, dass beispielsweise Routing-Anwendungen service und living_street ähnlich gewichten. Bei genauerer Überlegung sollte man sicherlich traffic_sign=DE:325 ergänzen. Die wiki-konforme (mir eher zusagende) Alternative hast du ja schon genannt. Was spräche gegen die Variante highway=living_street, living_street=alley um zu zeigen, dass der Weg kleiner als normalerweise ist? Natürlich ist auch das nicht wiki-konform und bisher wohl nicht praktiziert ... highway=living_street ist genau für Straßen gedacht, die als Spielstraße/verkehrsberuhigter Bereich, home zone etc. (je nach Land) markiert sind. Über die Breite sagt das an sich noch nichts aus. Siehe hierzu auch das Wiki [1]. highway=service ist eher für Einfahrten bzw. Zufahrten gedacht, etwa zu Parkplätzen, Tankstellen oder Grundstückseinfahrten. Das sagt auch nicht unbedingt was über die Größe aus; die Zufahrten zu Autobahnparkplätzen können ziemlich großzügig sein. [2] Meine Faustregel: wenn die Gemeinde Straßennamen verwendet und die Straße einen Namen hat, ist es kein service mehr. Für die beschriebenen Fälle: steht an der fraglichen Straße selbst das entsprechende Schild Spielstraße? Wenn ja, dann würde ich sagen: highway=living_street. Die Breite würde ich in der Tat in einem Zusatztag unterbringen, falls nötig. living_street=alley wäre von daher OK, ggf. könnte man das ja als Proposal einreichen. Wenn das allerdings Einfahrten sind, die nur zu je einem Grundstück führen (maximal zwei), selbst keine Straßennamen haben und selbst nicht als Spielstraße markiert sind (sondern z.B. von einer entsprechend markierten Straße abzweigen), dann würde ich highway=service vergeben. Nationale Tags wie traffic_sign=DE:325 würde ich so weit wie möglich meiden... wenn das auch woanders auf der Welt so gehandhabt wird, wird die Auswertung solcher Tags ein Alptraum, wenn sie denn auch grenzübergreifend funktionieren soll. In der Praxis werden solche Tags dann wohl weitgehend ignoriert, der Zusatznutzen geht also gegen Null. Aus dem gleichen Grund verwenden wir ja auch in Deutschland nicht highway=bundesstrasse, sondern highway=primary und dergleichen. [1] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street [2] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasd arf alles für OSM verwendet werden ?
Steffen Heinz wrote: gibt es irgendwo ne Stelle wo geschrieben steht was alles für OSM verwendet werden darf (wenn nicht wäre das sinnvoll) http://wiki.openstreetmap.org/wiki/Potential_Datasources Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Sven Geggus wrote: Henning Schollando...@aighes.de wrote: Die Hardware gibt es schon. Software ist auch reichlich verfügbar. Das gesuchte Gerät wäre Defy in einem Garmin-Gehäuse oder ein Garmin mit Android. Gibt es eigentlich Infos dazu welche Hardware in den Outdoorgeräten von Garmin drinsteckt und ob man da prinzipiell Linux drauf portieren könnte? Einige Nüvi basieren AFAIR ohnehin auf Linux. Aufwand diese seitens Garmin alternativ auch mit offenen OS anzubieten etwa eine Mannwoche oder so. Bei Garmin bin ich mir nicht sicher, aber Tomtom setzt (zumindest für einige Geräte) Linux ein. Gerätespezifische Sourcen bietet Tomtom zum Download an (wohl auf Grund von Verpflichtungen durch die GPL); es gibt schon ein Projekt [1], das sich mit weiteren Möglichkeiten auf der Plattform befasst. Ansonsten fällt mir der Openmoko Freerunner [2] oder dessen (noch in Entwicklung befindliche) Nachfolger GTA04 [3] ein. Der Freerunner war ein guter Ansatz, gefallen hat mir das (vor allem für ein Smartphone) recht präzise GPS – Referenzgeräte sind mein Mio 168 RS, Bj. 2005, und mein Geeksphone One, Bj. 2010; der Mio wird leicht, das Geeksphone sogar bei weitem übertroffen. Auch das Display mit 480x640 Pixel (knapp unter 300 ppi) war ein guter Ansatz. Negativpunkte waren: langsamer Grafikchip und der ARMv4-Prozessor. Die Openmoko-Distros haben mich nicht überzeugt, und Android kam erst später – die Hardware war dafür nie gedacht (Android ist für ARMv5 entwickelt). Daher läuft Android auf dem Freerunner nur sehr zäh. Der Nachfolger – wenn er denn kommt – könnte besser werden. Einschränkung bei dem Ganzen: outdoorfähig habe ich nichts von alle dem gesehen. Klar, bei Schönwetter funktioniert's, und den Freerunner habe ich auch schon bei Schneetreiben etliche Stunden im Stirnband meiner Skibrille spazieren gefahren, aber dafür ausgelegt ist er nicht wirklich... [1] http://opentom.org/Main_Page [2] http://www.openmoko.org [3] http://www.gta04.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder für JOSM
Frederik Ramm wrote: Da verkennst Du die Lage glaub ich ein bisschen. Diese Yahoo-Geschichte war noch nie was wirklich offizielles. Anders als Bing hat Yahoo nie irgendwas oeffentlich gesagt a la wir finden OSM toll und unterstuetzen die mit unseren Luftbildern. Yahoo hat lediglich auf Anfrage hin auf halb-privaten Kanaelen (ein OSMF-Vorstandsmitglied war frueher mal bei Yahoo) erklaert, dass sie nichts dagegen haben, wenn wir ihre Bilder abmalen. Trotz vieler Nachfragen haben wir das nie schwarz auf weiss bekommen, und vermutlich arbeitet inzwischen niemand von denen, mit denen wir damals geredet haben, mehr da. Wenn ich die Infos im Wiki richtig verstehe, dann war die Aussage von Yahoo seinerzeit eine derartige Nutzung ist mit unseren Lizenzbestimmungen kompatibel. Damit wäre ein gesondertes Agreement nicht erforderlich und im Prinzip könnten auch andere die Yahoo-Luftbilder für ihre Zwecke abmalen. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie Kartenbereich aus API-Export rendern
Hallo, sorry, dass ich mich erst jetzt einklinke. Wie man im Prinzip aus einem OSM-File (z.B. einem API-Export) mit Mapnik eine Karte rendert, ist im Wiki unter [1] dokumentiert. Prinzipiell ist es auch möglich, den OSM-Style so umzubiegen, dass Mapnik die Karte aus einem OSM-File statt aus PostgreSQL rendert. Das ist zwar mit einigen Einschränkungen verbunden, aber das Ergebnis dürfte der Karte von der OSM-Homepage recht nahe kommen. Zuerst wirst Du die ganzen Layers im Style durchgehen müssen: - Datasource anschauen: welche Tags werden gefiltert? - Datasource so umbauen, dass die Daten aus dem XML-File geholt werden - Alle Styles, die von dem jeweiligen Layers referenziert werden, anpassen: da die Filterregeln jetzt auf ALLE Objekte angewandt werden, müssen ggf. zuvor in der Datasource vorhandene Filterkriterien in die Filters der jeweiligen Rules wandern. - Achtung: falls ein Style von mehr als einem Layer referenziert wird (die dann höchstwahrscheinlich unterschiedliche Datasources haben und die Daten unterschiedlich filtern), wirst Du Diese Styles wahrscheinlich duplizieren müssen, weil Du jetzt für jedes Layer andere Filterregeln brauchst. Einschränkungen: Einige Features im Default-Style benutzen PostGIS-Funktionen: Beispielsweise werden turning_circles mit der Farbe gefüllt, die zur nächstliegenden Straße passt. Diese Features hast Du mit einem OSM-Datasource nicht zur Verfügung; hier ist Kreativität gefragt. (Beispielsweise nur die casings, sprich den grauen Rand, zu rendern und die Füllfarbe wegzulassen.) Ebenso wirst Du darauf verzichten müssen, Renderingregeln für Polygone erst ab einer bestimmten Fläche greifen zu lassen. Relationen werden von Mapnik überhaupt nicht unterstützt. Informationen, die in Relationen enthalten sind, können nicht gerendert werden. Speziell fällt mir dazu multipolygon ein – Gebäude mit Innenhöfen, Wälder mit Lichtungen usw. können so nicht wie auf der OSM-Homepage dargestellt werden. Es gibt keine Unterscheidung zwischen Nodes und Ways. Areas können halbwegs erraten werden, indem nach eindeutigen Tags gefiltert wird (area, building, landuse etc.), allerdings werden auf diese Weise auch Nodes als Areas behandelt, wenn sie eines dieser Tags besitzen. Außerdem scheint es noch ein paar Bugs zu geben – ich habe mal kleinere Bereiche ad-hoc auf diese Art gerendert, und in einzelnen Fällen musste ich feststellen, dass die Geometrie von Objekt A und Tags von Objekt B durcheinandergewürfelt wurden. Ich erinnere mich an einen Fall, in dem die Umrisse eines Gebäudes hartnäckig und reproduzierbar als Skipiste gerendert wurden... die Skipiste gab es tatsächlich, nur woanders... Um die Karte als Bitmap zu rendern, gibt es, wie schon vorher angesprochen, nik2img.py. Eine Alternative dazu könnte auch der Mapnik Viewer sein: den Code gibt es auf der Mapnik-Homepage zum Download; Binaries werden vom Projekt nicht angeboten. (Ubuntu bietet allerdings ein Package mapnik-viewer an.) Mit dem Viewer kannst Du Dir den gewünschten Kartenausschnitt auf dem Bildschirm heranholen und dann über die Export-Funktion in ein Bitmap exportieren. Einschränkung: es wird genau das exportiert, was Du auf dem Bildschirm siehst – gleicher Ausschnitt, gleicher Zoom. Wenn Du einen kleineren Ausschnitt brauchst, entweder Fenster vor dem Export verkleinern oder Bitmap hinterher zurechtschneiden. Der maximal exportierbare Kartenausschnitt ist etwas kleiner als Deine Bildschirmauflösung... Hope it helps Michael [1] http://wiki.openstreetmap.org/wiki/Mapnik:_Rendering_OSM_XML_data_directly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Performance-Steigerung durch Proxy-Server
Hallo, openmap.lt fährt eine Proxy-Konfiguration – Betreiber ist Ramas [User:Ieskok]. Im Detail kenne ich seine Konfiguration zwar nicht, Kern scheint aber ein Apache-Server mit Squid als Reverse Proxy zu sein. Ob das die Performance verbessert, hängt von ein paar Faktoren ab: Zum einen ist ein Performancegewinn erst dann möglich, wenn eine Anfrage aus dem Cache bedient werden kann – also frühestens ab der zweiten Anfrage pro Kachel. Das hängt also sehr davon ab, wie viel Traffic der Proxy bekommt und wie sich dieser auf die Tilesets verteilt. Je weniger Streuung, um so besser. Zum anderen bringt es auch nur dann etwas, wenn der Proxy die Anfragen schneller bedienen kann als der OSM-Server selbst – zum Beispiel wegen besserer Netzverbindung oder geringerer Auslastung von Server-Ressourcen (einschließlich Netzverbindung). Spontan fallen mir da Firmennetzwerke und dergleichen ein, wenn diese nur eine schmale und/oder stark ausgelastete Verbindung zur Außenwelt haben. Neben der Performance ist ein weiterer Bonus die Ausfallsicherheit: sollten die OSM-Server nicht erreichbar sein, hat der Proxy immer noch Daten im Cache. Wenn also viele User vorrangig die gleichen Gebiete anschauen, kann ein solcher Ausfall recht gut überbrückt werden. Zwei Probleme stellen sich: zunächst die Aktualität der Tiles. Idealerweise holt der Proxy die Kacheln nur dann neu vom Server, wenn sich dort etwas geändert hat, und beantwortet sonst alle Anfragen aus dem Cache. Möglich wäre hier eine Staffelung: wenn eine Kachel weniger als x Sekunden/Minuten alt ist, wird sie ohne Wenn und Aber aus dem Cache geliefert, ansonsten wird mit einem HEAD-Request an den OSM-Server überprüft, ob es dort eine neuere Version gibt – wenn ja, wird diese vom Server geholt, ansonsten wird der Request ebenfalls aus dem Cache beantwortet. Im schlimmsten Fall werden dann halt mal Kacheln zurückgeliefert, die seit maximal x Sekunden/Minuten veraltet sind. Auf openmap.lt sehe ich zwar öfter mal veraltete Kacheln in Bereichen, die ich kurz zuvor editiert habe, allerdings hilft da meist ein Refresh der betreffenden Kachel (auch bei sehr frischen Updates), kann also auch an meinem lokalen Browsercache liegen. Zum anderen, wie bereits erwähnt, die Tile Usage Policy: ein Proxy mit entsprechend Traffic kann hier schnell mal an die Grenzwerte stoßen und geblockt werden. Andererseits entlastet ein Proxy ja gerade die OSM-Server, so dass eine derartige Konfiguration durchaus im Sinne der Policy sein sollte – diese hat ja schließlich das Ziel, die Serverresourcen vor Überlastung zu schützen. Wenn jemand so etwas plant, würde ich empfehlen, einfach mal die Server-Admins anzuschreiben, denen das Vorhaben zu erklären – wenn das sauber gemacht wird, sollte es eigentlich im Sinne von OSM sein. my 2 cents Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Haltestellen-Namen
Hallo zusammen, Hallo Steffen, hallo @talk-de, / da nebenan eine heftige Diskussion um Namenszusätze im Gange ist, // wurde ich an ein Problem erinnert, dem ich vor einigen Tagen gegen- // überstand: Haltestellennamen für Bushaltestellen von Überlandlinien. // Auf den Haltestellentafeln in der Stadt steht (natürlich) nicht der // Name der Stadt (also Lindengarten und nicht Wismar Lindengarten, // Ausnahme Wismar ZOB). Außerhalb der Stadtgrenzen heißt es dann schon // Groß Strömkendorf Dorf oder Hof Redentin Abzweig. // In den Online-Fahrplänen steht (natürlich?) Wismar Lindengarten, // wenigstens nicht Hansestadt Wismar Lindengarten, denn das könnten die // wenigsten Schriftanzeiger in den Bussen auch darstellen. // Wie verfährt man in diesem Fall am saubersten? /das ist in der Tat ein ziemlich hartnäckiges Problem, auch außerhalb von OSM. In Vorarlberg habe ich etliche Haltestellen gesehen, die wohl aus einem Import stammen und z.B. mit name=Feldkirch, Zollamt getaggt sind. In Italien stoße ich öfter auf name=Via Dante (Cormano) - beides gefällt mir allerdings nicht sonderlich. Das Problem ließe sich recht einfach und elegant durch einen Zusatztag lösen. Beispielsweise is_in, oder ein anderer (noch zu benennender) Tag. Im obigen Beispiel wäre das dann: name=Lindengarten is_in=Wismar Dann kann sich jeder Renderer daraus den für sich passenden Namen zusammenbauen. Für eine topographische Karte kann man is_in getrost ignorieren (in welcher Stadt die Haltestelle ist, sieht man dort meist deutlich). Für Liniendiagramme und dergl. kann man is_in auswerten und z.B. nur für die Linien rendern, die Haltestellen mit unterschiedlichen is_in-Tags bedienen. Die Art der Darstellung bleibt dem Renderer überlassen: Wismar, Lindengarten oder Lindengarten (Wismar) oder WISMAR Lindengarten A-Straße B-Straße GROSS STRÖMKENDORF Dorf usw. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
