[Talk-de] OSM-Straßenlistenauswertung: landesweite Updates zentrale Listen Baden-Württemberg und Thüringen
Hallo, in der OSM-Straßenlistenauswertung [1] habe ich gestern zwei große Datenaktualisierungen vorgenommen und seit heute früh stehen für diese auch neue Auswertungen bereit. Für die Bundesländer Baden-Württemberg und Thüringen stehen zentale Straßenlistendateien zur Auswertung zur Verfügung. Diese habe ich gestern im Straßenlisten-Wiki [2] aktualisiert, wenn die vorherigen Listen nicht zwischenzeitlich durch Wiki-User verändert wurden. Die Listen für Baden-Württemberg sind zum Teil noch von schlechter Qualität, daher bitte die Auswertung für Eure Gemeinden prüfen und ggfs. im Wiki die vorherige reaktivieren, wenn diese offensichtlich besser die Straßen in der jeweiligen Gemeinde abbilden. Für die Bundesländer Mecklenburg-Vorpommern und Rheinland-Pfalz stehen auch zentrale Listen zur Verfügung. Diese werde ich in den nächsten Tagen im Wiki aktualisieren. Zu den beiden Datenupdates hier noch Details: Baden-Württemberg Die Liste wird vom Landesamt für Geoinformation und Landentwicklung LGL [3] bereitgestellt, in diesem Fall ist der Datenstand 2.1.2014. * 1017 Straßenlisten wurden aktualisiert. Darin gab es in 417 Straßenlisten inhaltlich Änderungen, 700 Listen sind also inhaltlich unverändert. Trotzdem wurden auch die 700 aktualisiert, damit der Stand der Listen erkennbar ist. Davon habe ich 9 Listen im nachhinein zurückgesetzt, weil die Listen offenbar qualitativ schlechter waren als die vorhandenen. Dazu habe ich bei den neuen Auswertungen die Listen mit den größten Verlusten [4], nämlich mind. 10 Straßen weniger als vorher, händisch überprüft. * 71 Straßenlisten wurden nicht aktualisiert, weil sie von einem Wiki-User zwischenzeitlich geändert worden waren. Für diese stelle ich in den nächsten Tagen weitere Infos bereit, damit Interessierte den aktuellen Stand im Wiki mit der neuen offiziellen Version abgleichen können * von 19 Gemeinden gab es keine zentale Listen. Thüringen == Die Liste wird vom Landesamt für Vermessung und Geoinformation [5] bereitgestellt, der Datenstand ist 14.10.2013. * 836 Straßenlisten wurden aktualisiert. Darin gab es in 257 Listen inhaltiche Änderungen, 579 Listen waren also unverändert. Alle wurden aktualisiert. * 42 Straßenlisten wurden nicht aktualisiert wg. Änderungen durch Wiki-User. Zum Abgleich durch Interessierte stelle ich weitere Daten in einigen Tagen zur Verfügung. * Die zentrale Liste umfasste alle Gemeinden des Landes. viele Grüße Dietmar aka okilimu [1] http://regio-osm.de/listofstreets/ [2] http://regio-osm.de/listofstreets/wiki/index.php/Hauptseite [3] https://www.lgl-bw.de/lgl-internet/opencms/de/07_Produkte_und_Dienstleistungen/Open_Data_Initiative/index.html [4] http://regio-osm.de:/listofstreets/ticker?eval_old=12.01.2014eval_new=13.01.2014area=*Baden-W%C3%BCrttemberg* [5] http://www.geoportal-th.de/de-de/downloadbereiche/downloadkataloge.aspx ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
On Sat, Jan 11, 2014 at 08:33:06PM +0100, Norbert Kück wrote: Blindes Übernehmen von Daten lehne ich ab - auch bei ALK. Wenn ich Unstimmigkeiten sehe sage ich nicht alles Sch..., sondern spreche die Quelle an. Das geht hier gut, weil es um Einzelobjekte geht und nicht um flächendeckendes Abmalen. ALK und Luftbilder haben einen gravierenden Unterschied: Vermessungsdaten sind hinreichend genau und richtig, wenn nach dem Stand der Technik gearbeitet wird. Nope - Sorry - Ich habe vor 3 jahren ein altes Haus gekauft. Das war komplett anders im ALK drin. Nach der Einmessung sind jetzt auch (genehmigte) Gebaeudeteile aus den 70er und 90er Jahren mal eingetragen worden, die fehlten bis dahin komplett. Luftbilder haben systematische Nachteile, die durch die Nachbearbeitung nicht oder nur unvollkommen ausgeglichen werden können. Siehe oben. Ich bin ja eher im Aussenbereich unterwegs und da wird so viel um und aus und drangebaut und teilweise auch mal gerne ohne Baugenehmigung oder Bauabnahme - Da steht dann nach 100 Jahren ein komplett andere Bausubstanz. ALK uebernehmen wäre dort einfach nur Müll importieren. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Kurz vorweg: Sorry für mögliche doppelte Antwort. Am 12.01.2014 20:29, schrieb Martin Koppenhoefer: ja, da stand ja auch zum Beispiel, mit dem building-key sollte man (m.E.) ausser der Überdachung nichts taggen, sondern ggf. die Dachfläche (bzw. das Dach mit Neigung und Überständen etc.) im 3D-Mapping, und definiert als Teil des Gebäudes (über den key). Grundriss bezeichnet normalerweise den Plan einer Etage und hat hier m.E. nichts in der Diskussion zu suchen. Sorry für die Frage. Ich sehe gerade, dass das im deutschen Wiki auch teilweise beantwortet ist. http://wiki.openstreetmap.org/wiki/DE:Buildings#Umriss Trotzdem bleiben meinerseits Fragen offen: So wie ich das nun verstehe gibt es da in OSM eine Coexistenz zweier Umrisserfassungsmöglichkeiten. Einmal die Erfassung der Außenwand am Boden und dann die Grundrisslinie. Ich würde es für sinnvoll halten zu Gebäuden nach Möglichkeit beide Flächen in der OSM zu haben. Der einfachste Weg wäre wahrscheinlich eine neue Rolle in der building-Relation. Aber welche soll schließlich den Building-Tag tragen? Ich finde, dass das wiki dazu eine Aussage treffen sollte. Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden gemeint ist. Beispiele: Die Portale des Bremer Doms schneiden zum Beispiel in den Grundriss, den das LfD bereitstellt, eine Aussparung, die nur am Boden existiert. Das heißt über dieser Fläche, die dort ausgespart ist befindet sich zum Beispiel Mauer oder übrige Gebäudeteile wie teilweise die Türme. Hier die Aussparung, die bei der Erfassung der Mauer am Boden nicht zum Umriss gehören würde. http://www.openstreetmap.org/way/211749964 Hier ein Link zu der Karte beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%200314 Es gibt auch Beispiele bei denen nahezu das gesamte Gebäude verschwindet, wenn man die Mauer am Boden als Gebäudeweg erfasst: http://194.95.254.61/denkmalpflege/jpg1/1009a05.jpg Hier der Link zur Seite beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%201009 Die freistehenden Gebäudeteile wie Dächer etc sind hier mit einem X durchgestrichen. BTW: Wer sich die Bilder ansieht, wird vielleicht bemerken, dass das so nicht ganz richtig sein kann - abgesehen davon ein valides Beispiel für mein Problem. So wie ich nun die Grundrisslinie verstanden habe, ist in OSM alles soweit nach Grundrisslinie getagt. Nun wäre es aber auch sinnvoll das Gebäude nach Mauer am Boden zu taggen und mappen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 11:43, schrieb cracklinrain: Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden gemeint ist. Unser Simple-3D-Modell ist mit dem Konzept building=Grundfläche leider nicht ganz kompatibel. Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Auslegungssache. Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: [talk-ch] [OKFN-CH] First Meeting of the OpenGLAM CH Working Group
Weitergeleitet von talk-ch Original-Nachricht Dear * Stumbled upon this email once again. Might be interesting for OSM as well. - Keywords: KGS-Nummer (Kulturgüterschutz Nummer, Schweiz. PCP reference number in wikidata) wikidata, wikipedia https://lists.okfn.org/pipermail/okfn-ch/2013-December/15.html But maybe it's to late to participate, no idea. cheeers, hugi PS To give you some feeling: Schweizerische Nationalbibliothek - www.openstreetmap.org/way/40859920 Swiss National Library - https://www.wikidata.org/wiki/Q201787 Klick and look for buildings: http://de.wikipedia.org/wiki/Liste_der_Kulturg%C3%BCter_in_Bern -- Andreas Bürki abue...@anidor.com S/MIME certificate - SHA1 fingerprint: ED:A5:F3:60:70:8B:4C:16:44:18:96:AE:67:B9:CA:77:AE:DA:83:11 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227 ___ talk-ch mailing list talk...@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erinnerung OSM-Hackweekend Berlin
Hallo, am 25./26.01. findet in Berlin wieder ein OSM-Hackweekend statt. Details (Ort, Zeit, ...) findet ihr im OSM-Wiki [1]. Dort sieht man auch wer sich bereits angemeldet hat und woran gearbeitet werden soll. Es ist auch noch Platz in der Liste. Am Vorabend (Freitag, 24.01) wird es ein Kennenlerntreffen geben. Das Lokal wird auf der Wikiseite ergänzt, sobald es feststeht. Viele Grüße Lars [1] http://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_Januar_2014 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 12:29, schrieb Ronnie Soak: Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Auslegungssache. Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Wenn ich an Dächer Denke, ist das derzeit aber nicht Praxis. Man müsste dann die Dachstützen statt der Dachfläche mappen. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Das hat mit dem Renderer nichts zu tun. Wenn die Frage für mich klar wäre, was erfasst wird, würde ich den Anwender/Renderer darauf hinweisen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 12:29, schrieb Ronnie Soak: Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 14:52, schrieb Tobias Knerr: Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. Wobei man beim 3D-Mapping tendenziell ohnehin alle Infos braucht. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. +1 Aber beim 3D-Modellieren könnte man zur Not doch auch das Modell so ändern, dass neben der Mauer am Boden auch die größte Fläche, die das Gebäude beschreibt gemapt wird (nicht unbedingt mit dem building-Tag) - das würde ich dort zumindest als wünschenswertes Ziel sehen. Das heißt: Eigentlich motiviert das 3D-Modellieren erstmalig das Mappen der Mauer am Boden. Bisher sehe ich da nur Tags wie tunnel=building_passage oder covered=yes, die suggerieren, dass es nicht um die Mauer am Boden geht. Trotzdem: Aus meiner Sicht gibt es derzeit keine Saubere Definition der building-Fläche im Wiki. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer
hallo, eigentlich wollte ich nur offensichtlich falsche Straßennamen berichtigen, aber nun artet es in mehr als das aus. Hier http://osm.org/go/0C10td1eE- sind Namen zusammengeschrieben, die bestimmt in zwei Worten geschrieben werden müssen: Pommerschestraße Schlesischestraße Danzigerstraße Breslauerstraße Stettinerstraße Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde ich den Buslinienplan. http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf Darin stehen die Straßen Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete. Würde das als Quelle reichen oder welche andere Quelle wäre nötig? Und außerdem sehe ich, dass die angebliche Linie 4 http://www.öpnvkarte.de/?lat=47.74785lon=8.85827zoom=16layers=TBTTT wohl Linie 6 ist: http://www.stadtwerke-singen.de/pdfs/linie6_2014.pdf So, mit meinen guten Absichten, hier Fehler zu berichtigen, bin ich nun unsicher: Kann ich einfach die Haltestellen-Einträge mit ändern (Danzigerstraße - Danziger Straße) oder bringe ich damit ungewollt Fahrpläne u.ä. durcheinander? Ist vielleicht jemand näher dran als ich, der sich dort auskennt? Grüße Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Singen (Hohentwiel): Straßennamen und Busliniennummer
Am 13. Januar 2014 18:41 schrieb Andreas Schmidt schmidt-postf...@freenet.de: Wenn ich nach einer Quelle für die richtige Schreibweise suche, finde ich den Buslinienplan. http://www.stadtwerke-singen.de/pdfs/buslinien_2013.pdf Darin stehen die Straßen Danziger Str. und Breslauer Str. so geschrieben, wie ich es erwartete. Würde das als Quelle reichen oder welche andere Quelle wäre nötig? am besten ist immer hinfahren und nachsehen. Von anderen Quellen darf man Daten nur dann übernehmen, wenn das ausdrücklich gestattet ist, und selbst dann bleibt immer das Problem, dass alle Quellen Fehler haben. Ob man das auch so streng sehen will, wenn es nur um Rechtschreibfehler geht, muss man sehen ;-) wobei Namen eben Namen sind, und sich nicht unbedingt an die Rechtschreibung halten müssen. Die richtige Quelle für Straßennamen ist normalerweise das kommunale Archiv (Rathaus o.ä.), wo man die entsprechende Widmung aus den Protokollen der Gemeinderatssitzungen in mühseliger Kleinarbeit zu finden versuchen kann. Im konkreten Fall von Singen sind die Protokolle (zumindest die letzten) zwar im Internet, aber schön hinter einem login gesichert, damit nicht Hinz und Kunz einfach anonym nachsieht, was die so treiben ;-) https://singen.allris-online.de/ri/logon.asp Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
Am Montag, den 13.01.2014, 00:38 +0100 schrieb Wolfgang Hinsch: Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch: Du nennst es voreilig. Konstruktive Vorschläge für die schrittweise Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll gewesen, in welchen Schritten? Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall wesentlich größer sein. OSBs sind zu 80% entweder leicht zu beheben oder aber wurden schon behoben. Hätte man alle nach Notes übernommen, dann müsste man die Fehler ja immer noch bearbeiten -- sehr viel unnütze Fehlereinträge in Notes. Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de: Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett daherkommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On 12.01.2014 12:31, Florian Lohoff wrote: ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne Kommentar einfach zu. Mittlerweile sind 30 Bugs von mir im Umkreis Guetersloh/Rheda-Wiedenbrück geschlossen worde. ICH MUSS KOTZEN ! Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym zu löschen bedeutet planlosen Datenverlust und geht gar nicht. Hier um Paderborn versuche ich gerade, die gerade geschlossenen, mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'. Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme nach den NRW Atlas Daten auch schon zu klären. Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda ist/war die Bugdichte auch um ein Vielfaches grösser. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de: Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. was allerdings gravierende Nachteile für alle die hätte, die sich die Welt nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist (aussen drum herum). Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. wobei dafür die (Aussen-)Räume gut wiedergegeben sind. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren, und wie man das am besten unter einen Hut bekommen kann. Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei nur um überirdische Stockwerke handele, dafür aber nichtexistierende Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute, wobei ich das für extrem fehlerträchtig und unintuitiv halte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On 13.01.2014 19:20, Martin Koppenhoefer wrote: Am 13. Januar 2014 20:08 schrieb Werner Hoch werner...@gmx.de: Die Bearbeitung von OSBs ist ja prinzipiell gleich aufwändig wie in Notes. Die Übertragung von sinnvollen Bugs kann mit einem Mausclick erfolgen. Ein Mehraufwand existiert meiner Meinung nach nicht. s. https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#Tools Der Mehraufwand besteht darin, dass ich die OSB erstmal suchen muss (deren Webseite etc.), während die Notes mir über osm.org auf einem Silbertablett daherkommen. Zugegeben, das JOSM-Plugin würde vielleicht ein bischen früh abgeschaltet, allerdings besteht immernoch die Möglichkeit es manuell vom SVN herunterzuladen und zu installieren. Optimal wäre wohl an Version ohne Möglichkeit neue Bugs zu erstellen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Highway Shields (Strassennummern)
Hallo, in Nordamerika sind sie ganz wild darauf, richtige highway shields zu zeichnen. Bei denen hat ein- und dieselbe Strasse manchmal 8 verschiedene Nummern, die noch dazu jeweils in unterschiedlichen Arten von Kaestchen zu zeichnen sind. http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0 ist ein schoenes Beispiel, und hier http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68097487 ein Talk von Phil Gold, in dem er erklaert, wie er mit Hilfe von Python und fiesen Hacks mit planet_osm_rels solche komplizierten Shields bastelt. Bei uns hingegen scheint diese Thematik niemand hinter dem Ofen hervorzulocken. Ich bin da jetzt kein Experte, aber dieses Stueck Autobahn in der Bildmitte hier http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige Nummern, und daher kommt hier gar nix ;) Hat sich jemand schonmal Gedanken gemacht, wie man das loesen sollte - sollen wir einfach auch auf den amerikanischen Zug mit aufspringen, oder waere das fuer D-A-CH-Verhaeltnisse mit Kanonen auf Spatzen geschossen? (Ich poste das hier auch mal ins Forum, weil ich weiss, dass da ein paar Routenspezialisten unterwegs sind.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi! Am 13. Januar 2014 20:05 schrieb Frederik Ramm frede...@remote.org: Ich bin da jetzt kein Experte, aber dieses Stueck Autobahn in der Bildmitte hier http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige Nummern, und daher kommt hier gar nix ;) Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 19:35, schrieb Martin Koppenhoefer: Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de: Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. was allerdings gravierende Nachteile für alle die hätte, die sich die Welt nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist (aussen drum herum). Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich sollte das doch der Renderer entscheiden können. Vor allem sollten die Positionen aber nicht als Gegenposition verstanden werden, weil wie gesagt für die 3D-Modelle alle Daten wichtig sind. Zuletzt liegt es aber auch nicht an den 3D-Tags, dass ein Gebäude, durch das eine Einfahrt verläuft, in OSM als eine durchgehende Fläche gemapt wird. wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren, und wie man das am besten unter einen Hut bekommen kann. Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei nur um überirdische Stockwerke handele, dafür aber nichtexistierende Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute, wobei ich das für extrem fehlerträchtig und unintuitiv halte. +1. Ich benutze das zwar häufig, aber vom intuitiven Verständnis würde jeder vermuten, dass dieser Key die Gesamtstockwerkezahl des Gebäudes beschreibt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi, On 13.01.2014 20:13, Martin Vonwald wrote: Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Oder man geht komplett vom ref weg, zumindest bei Autobahnen und Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13. Januar 2014 20:22 schrieb cracklinrain cra_klinr...@gmx.de: Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich sollte das doch der Renderer entscheiden können. Vor allem sollten die Positionen aber nicht als Gegenposition verstanden werden, weil wie gesagt für die 3D-Modelle alle Daten wichtig sind. ja, sicherlich sind alle Daten wichtig. Wobei eine Einigung schon sinnvoll wäre, ob man mit building nun den Teil mappt, der auf dem Boden steht, oder ob es der Umriss aller Bauteile und Stockwerke ist, also auch der schwebenden --- wobei die 3D-Leute wahrscheinlich gern den unterirdischen Teil unterschlagen wollen, zumindest bis jemand eine Anwendung herausbringt, mit der man Geländeschnitte generieren kann ;-) Prinzipiell denke ich, dass die 2. Variante ohne Zusatzinformationen niemandem was bringt (auch wer ein 3D-Modell bauen will, braucht ja die einzelnen Teile und der Gesamtumriss bringt nichts ausser dass man damit abschätzen kann, welche Teile vermutlich zu einem Gebäude gehören, wobei das auch nicht in allen Fällen gut geht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSBs schliessen ohne Kommentar und Username
On Mon, Jan 13, 2014 at 07:26:38PM +0100, Peter Czaja wrote: Geht mir genau so. Das Vorgehen, die Bugs kommentarlos anonym zu löschen bedeutet planlosen Datenverlust und geht gar nicht. Hier um Paderborn versuche ich gerade, die gerade geschlossenen, mir für wichtig erscheinenden Bugs nach OSM Notes 'rüberzuretten'. Bei der Gelegenheit sind als netter Nebeneffekt ein paar Probleme nach den NRW Atlas Daten auch schon zu klären. Nach dem Motto Not-Tugend oder so ähnlich. Aber rund um Rheda ist/war die Bugdichte auch um ein Vielfaches grösser. Ich habe da selber meine Arbeit mit koordiniert. Alles was ich als unstimmig im Augenwinkel wahrgenommen habe oder wo dinge nicht so offentlich nach meiner erinnerung fehlte. RhWd ist auch Adresstechnisch im Begriff komplettiert zu werden und auch da habe ich bugs gesetzt wo es unstimmigkeiten in den Hausnummern gab. Quasi alles hops gegangen ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bamberg = hsb:Babin?
Hi, das hier ist mir neulich aufgefallen - http://www.openstreetmap.org/node/1646638496/history als Obersorbischer name für Bamberg ist hier Babin eingetragen was laut meinem Sprachgefühl und einem Online-Wörterbuch falsch wäre. Babin hat laut Wörterbuch irgendwas mit Hebammen oder alten Weibern zu tun. Bin trotzdem vorsichtig es so einfach ohne Rückfrage zu löschen. Die History ist leider wenig hilfreich weil der hsb:Babin anscheinend vor der Lizenzänderung eingetragen wurde und damit nicht sichtbar ist wie es hingekommen ist:( Kann sich jemand zufällig erinnern oder hat eine Idee? Richard --- Name and OpenPGP keys available from pgp key servers ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Highway Shields (Strassennummern)
Hi, jetzt fängst du aber mit Ausweichtaktiken an. Es fehlt doch offensichtlich ganz generell an der Softwareunterstützung für mehrwertige Tags, da ist ref doch bei weitem kein Einzelfall, oder hat sich das mittlerweile so stark gewandelt? Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: amenity=parking;fuel (4523, wobei viele davon vom AND-Import kommen) amenity=restaurant;cafe (44) amenity=restaurant; pension amenity=pub;restaurant;bar amenity=hospital; univeristy amenity=fast_food;cafe cuisine=italian;ice_cream amenity=fuel; garage amenity=fuel;compressed_air amenity=pharmacy;post_office;vending_machine amenity=bank;atm amenity=restaurant;bistro amenity=bench;shelter amenity=drinking_water; waste_disposal amenity=bank;post_office amenity=post_office;bank amenity=parcel_box;post_box amenity=cafe;pub;restaurant amenity=post_box; telphone amenity=restaurant;biergarten amenity=vending_machine;waste_basket amenity=hospital; pharmacy amenity=fitness_center;sauna amenity=restaurant;pub amenity=pub;restaurant amenity=restaurant; hotel tourism=guest_house; hotel amenity=nightclub;pub amenity=cafe;post_office amenity=theatre;cinema amenity=theatre; school amenity=cafe;arts_centre shop=kiosk;car_repair amenity=doctors; dentist amenity=recycling;waste_container amenity=language_school;something else (!!! ;) ) amenity=doctors; pharmacy amenity=fuel;compressed_air;car_wash amenity=bar;restaurant (71) amenity=public_building; toilets amenity=waste_basket;bench amenity=waste_basket;recycling (170) amenity=place_of_worship;graveyard amenity=cafe;pub;nightclub amenity=restaurant;guest_house amenity=bench;fountain amenity=public_building; social_facility amenity=college;education_centre cuisine=pizza;kebab amenity=bar;community_centre amenity=restaurant;ice_cream amenity=bar;nightclub amenity=kindergarten;school amenity=bar;casino amenity=charging_station;bicycle_parking amenity=toilets;shower amenity=swimming_pool;sauna;gym amenity=school;place_of_worship (88) amenity=parking;restaurant;fuel (50) highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Das sind offensichtlich gar nicht so viele, aber ich will nicht wissen, wie oft eins von beidem weggelassen wird, weil es eben keine Unterstützung für die Kombitags gibt, oder wie oft eine Einrichtung aus demselben Grund doppelt in OSM auftaucht. Hotel/Restaurant ist häufig kombiniert, und oft lässt es sich eigentlich nicht sinnvoll räumlich trennen. Cafe/Restaurant dürfte noch ähnlich oft vorkommen. weitere Kombinationen, die bestimmt häufig sind: Sauna und Schwimmbad Sauna und Fitness-Studio Mülleimer und Straßenlaterne (auch wenn beides oft nicht eingetragen wird) Und ich finde die Situation eigentlich unbefriedigend, dass ich einen Laden, der mittags warme Küche hat, abends als Kneipe läuft und spät abends bzw. am Wochenende zur Disco mutiert, nicht gleichzeitig als alles taggen kann. Sollen wir jetzt zusätzliche Tags für gängige Kombinationen finden? Ich bin mir nicht sicher, ob das wirklich die bessere Lösung wäre Gruß Peter Am 13.01.2014 20:30, schrieb Frederik Ramm: Hi, On 13.01.2014 20:13, Martin Vonwald wrote: Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Oder man geht komplett vom ref weg, zumindest bei Autobahnen und Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Dass das Problem nicht trivial ist, ist mir klar. Die automatisch erzeugten Werte von JOSM beim verbinden von Wegen sind da ein Problem, ja. Aber die von mir angesprochenen Kombinationen sind eben durchaus auch üblich und tatsächlich ein Grenzfall. Was Jochen unter But of course in this case it only means that somebody couldn’t make up their mind whether to use lake or pond and chose the worst: both. beschreibt. Nur ist das nur das Schlechteste, solange es nicht genutzt und interpretiert wird. Was mache ich denn mit dem erwähnten Restaurant/Cafe oder Hotel/Restaurant, Begriffen, die ja sogar fast in die allgemeine Sprache aufgenommen ist so als Doppelworte? Was mache ich mit einem Autohaus mit Werkstatt (shop=car, shop=car_repair), bei dem beides nicht sinnvoll voneinander trennbar ist? Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Immer wieder beschweren sich gerade neue Mapper, das Mappen sei so komplex, man könne eigentlich keinen Weg mehr unterteilen, ohne zig Relationen kaputtzumachen bzw. reparieren zu müssen; und das zum Teil zu Recht, wie ich finde. Bisher sind es nur Buslinien und große Rad/Wanderrouten, die großflächig als Relationen eingetragen sind; bei Autobahnen, Bundesstraßen etc. ist das meines Erachtens viel zu häufig, aber das hält sich in Grenzen. Wenn wir jetzt bei Kreisstraßen, Landstraßen etc. weitermachen, alles in Relationen zu verpacken, nur weil es eine zusammenfassende Nummer hat, wächst sich das wieder zu einem Ungetüm aus. Dann können wir demnächst auch nur noch ungetaggte Ways nutzen, und alle Tags auf Relationen übertragen, wie das tendentiell schon bei Multipolygonen passiert. Aber wer sich hinterher über untagged-ways beschwert, ist dann selbst Schuld, wenn jetzt das Gegenteil gefordert wird. Ob ich die A30 als Relation zusammenfasse oder die E27, die Buslinie 7 oder die Goethestraße, das ist im Prinzip alles das gleiche, und wenn wir ref=7;10, ref=B55;E27 etc. nicht haben wollen, wird uns nichts anderes übrigbleiben, als eben wirklich alles in die Relationen zu verschieben. Ob das die bessere Lösung ist, bezweifle ich aber erstmal. Gruß Peter Am 13.01.2014 22:35, schrieb Stephan Knauss: On 13.01.2014 22:12, Peter Wendorff wrote: jetzt fängst du aber mit Ausweichtaktiken an. Ich glaube eher Du wechselst gerade das Thema. Ich habe den Betreff dahingehend angepasst. Die ursprüngliche Frage war ja ganz speziell auf Highway Shields ausgerichtet. Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten: highway=residential;unclassified (134x laut taginfo) highway=path;track (68x laut taginfo) highway=traffic_signals;crossing (62x) highway=unclassified;residential (44) highway=residential;track (43) Schon mal mit JOSM Wege oder andere Elemente verbunden? Der Default ist (oder war?) dass im Tag dann alle bisherigen Werte stehen, eben mit einem Semikolon getrennt. Ich denke das allermeiste dieser Stellen sind solche Fälle bei denen der Anwender das nicht gemerkt und korrigiert hat. Jochen Topf hatte vor einiger Zeit eine recht umfangreiche Untersuchung gemacht was die Verwendung von Semikolon angeht. Ganz trivial ist die Lösung des Problems nicht. http://blog.jochentopf.com/2013-09-23-semicolons-in-osm-tags.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Hi, On 13.01.2014 23:10, Peter Wendorff wrote: Sicher: Das Semikolon immer als Doppelwert zu interpretieren, und das an jedem Tag einfach so, wird schiefgehen; die Beispiele in Jochens Artikel machen deutlich dass das Semikolon auch anderes meinen kann. Aber es gibt die Doppelwerte, und ref=*, worum es hier ursprünglich ging, ist meines Erachtens auch ein gutes Beispiel. Allerdings eins, bei dem Relationen eine ganz gute oder zumindest funktionierende Loesung sind; bei Hotel-Restaurants hingegen wird man damit nicht weit kommen. Bis zu API 0.3 uebrigens (oder wars sogar 0.4) konnte ein Objekt in OSM uebrigens tatsaechlich mehrere Tags desselben Keys haben. Wir haben das dann abgeschafft, weil fast keine damals gaengige Software das auch unterstuetzt hat - einmal ein Objekt mit so einem Doppeltag mit JOSM bearbeitet, schon wurde zufaellig einer der beiden Tags gewaehlt... Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir * alle Tags ausser die in einer bestimmten Negativliste (note, comment, ...) am Semikolon aufsplitten? * nur Tags aus einer bestimmten Positivliste (amenity, ref, ...) am Semikolon aufsplitten? Wenn ja - wie verteilen wir diese Listen zwischen allen Programmen? * Tags nur dann aufsplitten, wenn sie einer bestimmten Form genuegen (z.B.: wenn der Value mit einem Semikolon *beginnt*)? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Am 14.01.2014 00:40, schrieb Stephan Knauss: On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die Bojen-Farben: value-type: List Bei Lanes: List Bei amenity: Set Bei name: String etc. Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation entsprechend behandelt werden (als eine ungeordnete Menge), beim name als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte. Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - Renderer, Router, ... Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft dafür, dass Mapper großflächig Daten beisteuern und vor allem korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann wieder funktioniert. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Softwareunterstützung für Semikolon getrennte Tags
Eine Set würde ich in API 0.7 bevorzugen, denn so könnte man bspw. die Unterschiedlichen Öffnungszeiten kenntlich machen. key=name value=Zum Goldenen Löwen / set key=amenity value=restaurant / key=opening_hours value=Mo-Su 11:00-21:00 /set set key=tourism value=hotel / key=opening_hours value=24/7 /set set key=amenity value=cafe / key=opening_hours value=Sa,Su 14:00-17:00 /set Am 14. Januar 2014 08:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 14.01.2014 00:40, schrieb Stephan Knauss: On 13.01.2014 23:40, Frederik Ramm wrote: Du hast schon recht, es waere wuenschenswert, wenn Software das automatisch richtig machen wuerde, aber puh, das wird ein langer und steiniger Weg. Am Anfang stuende die Frage: Sollen wir eventuell helfen dann doch weitere Datentypen in der API. Also nicht nur key=value Paare, sondern noch etwas mehr. Eine Idee für Api 0.7 Geordnete Listen: Ein Datentyp bei dem 1..n Values in einer definierten Reihenfolge nacheinander kommen. Doppelte Values sind erlaubt. Sets: Aufzählungen von 1..n Values. Die Reihenfolge spielt keine Rolle, doppelte Values sind verboten. Wäre eine größere Änderung, dürfte aber viele der bisherigen Verwendungen vom Semikolon abdecken. Bisherige Werte in der Datenbank blieben als value erhalten bis es jemand von Hand (oder script) konvertiert. ABER: Das ist eine recht große Änderung die eine Modifikation an jeder Software erfordern würde die die Daten verarbeiten will. Um kompatibel zu bleiben müsste es eventuell einen Konverter geben der den API 0.7 output wieder zusammenmergen kann in einen einzelnen value mit Semikolon für nicht angepasste alte Software. Oder die API wird tatsächlich mit der Dokumentation im Wiki verzahnt und dieser Typ kann im Wiki angegeben werden, also z.B. im Wiki für die Bojen-Farben: value-type: List Bei Lanes: List Bei amenity: Set Bei name: String etc. Dann kann der bestehende Wert (amenity=bar;restaurant) der Dokumentation entsprechend behandelt werden (als eine ungeordnete Menge), beim name als ein einzelner Wert, selbst wenn ein Semikolon vorkommen sollte. Das kann natürlich auch Teil der API sein, aber selbst wenn nicht ließe sich das vermutlich umsetzen. Die größte Hürde sehe ich in der Software, die die OSM-Daten anwendet, denn die muss mehrere Werte unterstützen - Renderer, Router, ... Wir mappen zwar nicht für [Anwendungsimplementierung X], aber viele Anwendungen, gerade Mapnik, OSRM etc. sind eben doch treibende Kraft dafür, dass Mapper großflächig Daten beisteuern und vor allem korrigieren; notfalls korrigieren in dem Sinne, dass [Anwendung X] dann wieder funktioniert. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
