Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Dass ansonsten noch Farben drin sind, kann nicht sein, denn das style-File wird automatisch aus dem mapnik-Style generiert. Gibt es das Script irgendwo öffentlich? Es würde mich interessieren, wie Du das gemacht hast. Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 02.11.2010 23:36, schrieb Johann H. Addicks: Am 02.11.2010 20:37, schrieb Kay Drangmeister: Nach einigen Diskussionen wie man Karten mit Layern ansprechender gestalten Danke. Auch wenn der Ausschnitt natürlich willkürlich gewählt wurde, ich sehe da gerade, wie das Dach des Sony-Centers mit seinen eingespannten Sonnensegeln nachgemalt wurde. Mag ja im Mapnik toll ausschauen, aber das ist kein Mapping, das ist Malen... Ich sehe in diesem Fall das Problem nicht. Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen. Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal begegnet) ist es einfach etwas detaillierter gemappt; und soweit ich das mit Satellitenbildern von Yahoo und Google vergleiche, eigentlich ziemlich richtig. Wo also ist das Problem, und wieso ist das Malen statt Mappen? Gruß Peter -jha- ___ 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] Neu: Ein schwarz/weißer Base-Layer
Am 02.11.2010 22:43, schrieb Thomas Ineichen: BTW: Irgendwer 'ne Idee, was man für die Fahrradschlauchverkaufsauto- maten für ein Icon verwenden könnte? Wie wäre es mit nem schwarzen Ring für den Schlauch und innen drin ein paar Münzen für den Automaten? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 01:11 schrieb Garrygarr...@gmx.de: Gefährdungen gehen von allem möglichen aus. Boden-Luftübergänge sind keineswegs zwangsläufig das einzige Kriterium für einen Flughafen. Es Das habe ich auch nicht behauptet, aber es ist der gemeinsame Nenner der für alles gilt. ... Diese Einteilung mag für eine POI-Einteilung sinnvoll sein um im Navi den Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Irgendein Wohnzimmer Extremist findet sich halt immer, der die Diskussion hier in die Ergebnislosigkeit führt. Diesmal bist es halt nicht du ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi Stephan, Stephan Olbrich schrieb: style-File wird automatisch aus dem mapnik-Style generiert. Gibt es das Script irgendwo öffentlich? Es würde mich interessieren, wie Du das gemacht hast. Sagen wir halb-öffentlich, es ist weder aufgeräumt noch sonstwie vorbildlich: http://svn.openstreetmap.org/applications/rendering/parking/mapnik/ Es wird im Kontext meiner Parkkarte (http://parking.openstreetmap.de) verwendet werden, deshalb der seltsame Pfad. Technik: Python, pxdom, ImageMagick für die Icons. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 03.11.2010 08:13, schrieb Peter Wendorff: Ich sehe in diesem Fall das Problem nicht. Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen. Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal begegnet) ist es einfach etwas detaillierter gemappt; Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel hängen. siehe z.B. http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat das wenig zu tun. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 03.11.2010 09:05, schrieb Johann H. Addicks: Am 03.11.2010 08:13, schrieb Peter Wendorff: Ich sehe in diesem Fall das Problem nicht. Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen. Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal begegnet) ist es einfach etwas detaillierter gemappt; Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel hängen. siehe z.B. http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG okay, dann nehme ich alles zurück ;) Falls aber jemand vom Yahoo-WMS abgezeichnet hat, kann ich das aber gut verstehen, da sah es sehr korrekt aus. sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat das wenig zu tun. Wie gesagt: in Yahoo nicht zu sehen, danach korrekt abgezeichnet (wenn das die Quelle war), also mit lokalem Fachwissen korrigieren ;) (obwohl das rendering so eigentlich sehr schön ist... - ich würd die Sonnenegel vielleicht umtaggen, aber drinlassen, falls es jemand rendern möchte) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenverzeichnis Neustadt - in Hols tein
Hi ! SvenA hat uns das Straßenverzeichnis für Neustadt IN HOLSTEIN [1] eingerichtet. Danke dafür. Frage in diesem Zusammenhang - die Übersichtsseite im Wiki [2] ist schon sehr lang. Sollten wird diese Bundesländerweise aufsplitten und die Anfragen zentral belassen ?? Gruß Jan :-) [1] http://svenanders.openstreetmap.de/SV-stat/Schleswig-Holstein/Neustadt_Holstein/ [2] http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 08:21 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: deshalb sind wir beim letzten Mal schon nicht weitergekommen... Irgendein Wohnzimmer Extremist findet sich halt immer, der die Diskussion hier in die Ergebnislosigkeit führt. Diesmal bist es halt nicht du ;-) Beispiele? Ich gebe zu, dass ich einer der Vielschreiber auf der ML bin, aber ich sehe mich eigentlich nicht als Wohnzimmer Extremist, ich bin durchaus draußen zum mappen, und meine Beiträge hier sind m.E. ergebnisorientiert und entstehen nicht mit dem Ziel der puren Diskussion. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 3. November 2010 09:05 schrieb Johann H. Addicks addi...@gmx.net: Am 03.11.2010 08:13, schrieb Peter Wendorff: Ich sehe in diesem Fall das Problem nicht. Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen. Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal begegnet) ist es einfach etwas detaillierter gemappt; Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel hängen. siehe z.B. http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat das wenig zu tun. Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben, daher der hohe Wiedererkennungseffekt. Mit Building=roof ist das eine brauchbare Beschreibung. Klar, es ist eine eher großmaßstäbliche (kl. Zoom) Abstraktion, der räumliche Fachwerkträger wurde z.B. nicht in allen Details wiedergegeben ;-). Wenn man das weglassen würde, wäre m.E. die Darstellung schlechter, d.h. weniger gut zu erkennen und dem realen Raum weniger angemessen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Justizminister wollen Auflagen für Geoda tendienste
Die Justizminister von Bund und Ländern fordern von der Bundesregierung, Geodatendienste wie Google Street View möglichst rasch mit einem speziellen Datenschutzgesetz in die Schranken zu weisen. http://www.heise.de/newsticker/meldung/Justizminister-wollen-Auflagen-fuer-Geodatendienste-1129627.html Das bedeutet anscheinend neuen Ärger auch für OpenStreetMap. Genaueres ist noch nicht bekannt. Meine Meinung dazu: Lobbyismus starten, auch und gerade für OpenStreetMap! Gruß, Philip FreeLotto - das kostenlose Lotto von freenet! Jeden Tag die Chance auf 2 Millionen Euro nutzen. Jetzt gratis Lotto spielen auf http://freelotto.freenet.de! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 3. November 2010 02:02 schrieb Walter Nordmann walter.nordm...@web.de: wenn das doch nur soo einfach wäre. aber HIER steht die realität: http://de.wikipedia.org/wiki/Postleitzahl_%28Deutschland%29#Postleitzahlenarten Zitat: Die Postleitzahlen lassen sich in verschiedene Kategorien einteilen. Die häufigste Art ist die Hauszustellungspostleitzahl, gefolgt von der Postfachpostleitzahl. Großempfänger erhalten von der Post entweder eine eigene Postleitzahl oder teilen sich diese mit weiteren Großempfängern. also vier möglichkeiten und nicht nur zwei. p.s. ich habs auch erst nicht glauben wollen. das ist soweit ja alles längst klar. Die Frage war, wie bzw. was wir davon in OSM übernehmen. Im addr:postcode (oder wie das heisst, nehme bei addr immer ein preset) sollte m.E. grundsätzlich die Hauszustellungs-PLZ eingetragen werden. Für Postfachpostleitzahl und Großkunden- bzw. Großkundensammelplz reicht m.E. ein weiterer key aus. Kann man sowieso nicht so ohne weiteres erkennen, was es ist, und mehrere davon wird ein Adressat nicht haben, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Justizminister wollen Auflagen für Geoda tendienste
Am 3. November 2010 09:47 schrieb Philip Gillißen gue...@freenet.de: Die Justizminister von Bund und Ländern fordern von der Bundesregierung, Geodatendienste wie Google Street View möglichst rasch mit einem speziellen Datenschutzgesetz in die Schranken zu weisen. http://www.heise.de/newsticker/meldung/Justizminister-wollen-Auflagen-fuer-Geodatendienste-1129627.html Das bedeutet anscheinend neuen Ärger auch für OpenStreetMap. Genaueres ist noch nicht bekannt. Meine Meinung dazu: Lobbyismus starten, auch und gerade für OpenStreetMap! Klage vor dem Bunderverfassungsgericht, der öffentliche Raum muss öffentlich bleiben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
M∡rtin Koppenhoefer wrote: Im addr:postcode (oder wie das heisst, nehme bei addr immer ein preset) sollte m.E. grundsätzlich die Hauszustellungs-PLZ eingetragen werden. Für Postfachpostleitzahl und Großkunden- bzw. Großkundensammelplz reicht m.E. ein weiterer key aus. Kann man sowieso nicht so ohne weiteres erkennen, was es ist, und mehrere davon wird ein Adressat nicht haben, oder? genau so sehe ich es inzwischen auch. ob nun ein großkunde an verschiedenen stadtorten (der welt!) verschiedene eigene plz hat oder nicht, ist mir eigentlich egal. hauptsache, es wird endlich festgelegt, was sich hinter addr:postcode=* verbirgt. - die, und nur die, hauszustellungs-plz. mein wiki-zitat sollte ja auch nur dazu dienen, die sache auf die spitze zu treiben um die absurdität dieser diskussion darzustellen. gruss walter - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5700563.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
[Talk-de] JOSM Sortierung der Eigenschaften
Kann man in JOSM die Reihenfolge der Eigenschaften beeinflussen? In Holland zB. stehen die AND Sachen (Import_level etc.) ganz oben, so dass man zu den wichtigen Tags (highway, etc.) immer runterscrollen muss. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] bereits über 150 TeilnehmerInnen habe n beim OSM-Fragebogen mitgemacht
Hallo und vielen Dank an alle die bereits an meinem Fragebogen zu OpenStreetMap teilgenommen haben. Ich habe mir die Mühe gemacht in einer kleinen Kartenanwendung den aktuellen Stand der Beteiligung am Fragebogen nach PLZ aufgeschlüsselt (aggregiert auf die erste und die ersten beiden Stellen) zu visualisieren. Wer's mal anschauen möchte (aber nicht alle gleichzeitig ;-): http://geeste.geographie.uni-freiburg.de/OSMmaps/ Ansonsten freue ich mich weiterhin über jedeN der/die am Fragebogen teilnimmt (ja es haben auch schon Frauen mitgemacht, wenn auch in überschaubarer Zahl): http://geeste.geographie.uni-freiburg.de/OSMfb/ Gerne kann die Information über den Fragebogen auch in den lokalen OSM-Gruppen oder ???-Telefonlawine verbreitet werden. Es ist sehr schwierig den Otto-Normal-Mapper anzusprechen, der nicht in einer der Email-Listen unterwegs ist, ohne SPAM zu produzieren indem man eine Rundmail an alle registrierten OSMler schickt (wofür es gute Gründe geben mag, ein Fragebogen gehört aber nicht dazu). Oh, bevor es gleich wieder Schimpfe gibt: Die PLZ-Visualisierung für Österreich fehlt noch, da mir einfach die PLZ-Polygone gerne auch in generalisierter Form fehlen. Falls hier jemand eine freie Quelle kennt, wäre ich für einen kleinen Hinweis dankbar. Viele Grüße aus dem Schwarzwald Marco Lechner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki: Haltestellen-Chaos
Hallo, im deutschen Wiki highway=bus_stop gibt es zur Zeit ein Chaos. Die Seite widerspricht sich mehrfach selbst. Vielleicht kann jemand aus der ÖPNV-Riege hier mal aufräumen, damit auch Leute ohne ÖPNV-Spezialausbildung in etwa verstehen, was jetzt gelten soll. Konkret (Auszug): highway=bus_stop (erforderlich) an der Stelle, an der der Mast steht highway=bus_stop, Verwendung: immer, Bezeichnet den Haltepunkt auf der Straße (auf dem Way und nicht daneben). Im ÖVPN-Schema von Oxomoa ist das Tag highway=bus_stop nicht mehr vorgesehen. Aus Kompatibilitätsgründen wird highway=bus_stop aber üblicherweise zusätzlich bei einem Node mit public_transport=stop_position verwendet und mit denselben Attributen versehen wie bei unified_stoparea. Für vom Weg getrennte Nodes gilt es, highway=bus_stop mit highway=platform zu ersetzen highway=bus_stop (erforderlich) In dieser Reihenfolge. Ich bin ein paar Jahre dabei, aber wenn ihr nicht sauber definieren könnt, was eigentlich getaggt werden soll, werde ich mich um Bushaltestellen überhaupt nicht mehr kümmern. Anfänger sollte man nicht sein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi Thomas, Auf meiner Karte findet man ab den schwarz/weiss-Stil daher ab sofort auch: http://osm.t-i.ch/bicycle/map/ Ja, sieht gut aus. Besonders, weil die farbigen Linien selbst etwas transparent sind und man z.B. die Straßennamen noch lesen kann. BTW: Irgendwer 'ne Idee, was man für die Fahrradschlauchverkaufsauto- maten für ein Icon verwenden könnte? Vielleicht so ein typisches Fahrradventil? Einen Schlauch kann man sicher schlecht erkennen. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 03.11.2010 12:04, Wolfgang: Hallo, im deutschen Wiki highway=bus_stop gibt es zur Zeit ein Chaos. Die Seite widerspricht sich mehrfach selbst. Vielleicht kann jemand aus der ÖPNV-Riege hier mal aufräumen, damit auch Leute ohne ÖPNV-Spezialausbildung in etwa verstehen, was jetzt gelten soll. Konkret (Auszug): highway=bus_stop (erforderlich) an der Stelle, an der der Mast steht highway=bus_stop, Verwendung: immer, Bezeichnet den Haltepunkt auf der Straße (auf dem Way und nicht daneben). Im ÖVPN-Schema von Oxomoa ist das Tag highway=bus_stop nicht mehr vorgesehen. Aus Kompatibilitätsgründen wird highway=bus_stop aber üblicherweise zusätzlich bei einem Node mit public_transport=stop_position verwendet und mit denselben Attributen versehen wie bei unified_stoparea. Für vom Weg getrennte Nodes gilt es, highway=bus_stop mit highway=platform zu ersetzen highway=bus_stop (erforderlich) In dieser Reihenfolge. Ich bin ein paar Jahre dabei, aber wenn ihr nicht sauber definieren könnt, was eigentlich getaggt werden soll, werde ich mich um Bushaltestellen überhaupt nicht mehr kümmern. Anfänger sollte man nicht sein. Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. Da es da aber immer noch keinen Konsens gibt (und sich nicht einmal einer abzeichnet, da die transit-Liste nicht zu Potte kommt) werde ich das Wiki zu bus_stop nicht verändern. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:04 schrieb Wolfgang wolfg...@ivkasogis.de: In dieser Reihenfolge. Ich bin ein paar Jahre dabei, aber wenn ihr nicht sauber definieren könnt, was eigentlich getaggt werden soll, werde ich mich um Bushaltestellen überhaupt nicht mehr kümmern. Wenn Du ein paar Jahre dabei bist, dann schreibe nicht ihr, sondern wir ;-) M.E. gibt es einen Konsens, highway=bus_stop neben den Weg an die Stelle des Mastes zu setzen. Für die Redundanzen die Oxomoa vorschlägt (bus=yes etc.) gibt es m.E. keinen Konsens und auch keine Erfordernis. Wegen mir könnte man das aber auch alles vereinheitlichen, sofern das an allen (den meisten) Stellen wie Editoren, Wiki und Daten geschieht, und es dafür international einen Konsens gibt. (d.h. ich hänge nicht unbedingt daran, Bushaltestellen im Highway-namespace zu führen, aber wenn eine Hälfte es so macht, und die andere anders, finde ich das schlechter). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:13 schrieb Claudius claudiu...@gmx.de: Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. damit bist Du einer derjenigen, die highway=bus_stop auf den Weg setzen, wogegen seit längerem die Wiki-Definition steht, und was auch hier AFAIK die Mindermeinung darstellt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Am 2. November 2010 20:37 schrieb Kay Drangmeister k...@drangmeister.net: Hi Nach einigen Diskussionen wie man Karten mit Layern ansprechender gestalten könne, kommt hier eine einfache Lösung: eine Mapnik-Karte in Graustufen. Weiterhin gibt es eine no icons-Version mit nochmals reduzierter Grund- information. Zwar nicht schwarz-weiss, aber auch schön und dezent als Hintergrund ist der style, den Melchior in seiner ÖPNV-Karte verwendet. http://www.öpnvkarte.de/?zoom=11lat=51.97562lon=8.27014layers=BT Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Sortierung der Eigenschaften
Am 3. November 2010 10:38 schrieb Chris66 chris66...@gmx.de: Kann man in JOSM die Reihenfolge der Eigenschaften beeinflussen? In Holland zB. stehen die AND Sachen (Import_level etc.) ganz oben, so dass man zu den wichtigen Tags (highway, etc.) immer runterscrollen muss. AFAIK ist das alphabetisch, wenn Du das Fenster ausklinkst kannst Du es auch bei kleinen Bildschirmen vertikal groß genug stellen, dann erübrigt sich das Problem bei unter 20-30 Tags an einem Objekt eigentlich ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Auch wenn es immer heißt, wir mappen nicht für die Renderer, finde ich das tag highway=bus_stop am Mast besser, da dann auch auf der Karte ersichtlich ist, für welche Fahrtrichtung die Haltestelle ist... MfG Andreas -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 03.11.2010 12:18, M∡rtin Koppenhoefer: Am 3. November 2010 12:13 schrieb Claudiusclaudiu...@gmx.de: Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. damit bist Du einer derjenigen, die highway=bus_stop auf den Weg setzen, wogegen seit längerem die Wiki-Definition steht, und was auch hier AFAIK die Mindermeinung darstellt. Ich halte mich da an den Zusatz zur Empfehlung neben dem Way zu Taggen. Zitat: however this has been the subject of some debate, because it has the disadvantage of not explicitly associating the bus stop with the way (a headache for routing software) [1] und das in meinen Augen sinnige unified_stoparea proposal [2]. Claudius [1] http://wiki.openstreetmap.org/wiki/Bus_stop [2] http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:31 schrieb Claudius claudiu...@gmx.de: Am 03.11.2010 12:18, M∡rtin Koppenhoefer: Am 3. November 2010 12:13 schrieb Claudiusclaudiu...@gmx.de: Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. damit bist Du einer derjenigen, die highway=bus_stop auf den Weg setzen, wogegen seit längerem die Wiki-Definition steht, und was auch hier AFAIK die Mindermeinung darstellt. Ich halte mich da an den Zusatz zur Empfehlung neben dem Way zu Taggen. Zitat: however this has been the subject of some debate, because it has the disadvantage of not explicitly associating the bus stop with the way (a headache for routing software) [1] und das in meinen Augen sinnige unified_stoparea proposal [2]. kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso nochmal extra einträgst? 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 03.11.2010 09:32, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 08:21 schrieb Ulf Lampingulf.lamp...@googlemail.com: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: deshalb sind wir beim letzten Mal schon nicht weitergekommen... Irgendein Wohnzimmer Extremist findet sich halt immer, der die Diskussion hier in die Ergebnislosigkeit führt. Diesmal bist es halt nicht du ;-) Beispiele? Ich gebe zu, dass ich einer der Vielschreiber auf der ML bin, aber ich sehe mich eigentlich nicht als Wohnzimmer Extremist, ich bin durchaus draußen zum mappen, und meine Beiträge hier sind m.E. ergebnisorientiert und entstehen nicht mit dem Ziel der puren Diskussion. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Alle Mann abkühlen!!! Als derjenige, der diesen Thread so zu sagen ein zweites Mal entflammt hat, möchte ich doch sehr bitten! Es muss doch irgend eine Lösung zu finden sein, die beide Welten miteinander vereint. Meine und wahrscheinlich auch die von Ulf, also die Routersicht, und die der Mapper. Die Kernfrage ist doch, was kann ich aus den OSM-Daten machen. Egal ob Routing oder Briefkastensuche. Mir persönlich wichtig ist dabei nur, dass die Daten auch ohne Heuristiken verarbeitbar bleiben und dafür ein herkömmlicher Computer ausreicht. Sonst wird's exklusiv und es werden Abhängigkeiten zu Anbietern geschaffen, die dann irgendwann den Laden zu machen. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 03.11.10 12:30, schrieb Andreas Neumann: Auch wenn es immer heißt, wir mappen nicht für die Renderer, finde ich das tag highway=bus_stop am Mast besser, da dann auch auf der Karte ersichtlich ist, für welche Fahrtrichtung die Haltestelle ist... ebend. Und am besten noch reinschreiben, welche Linien mit welchem Ziel dort abfahren. Wenn man dafür keine Relation anlegen möchte, ins note- oder route-tag, aber bitte nicht ref, weil das ist die Haltestellennummer, nicht die Liniennummer. Wer sich in josm an den weißen Quadraten für public_transport=* stört: Hier: http://wiki.openstreetmap.org/wiki/User:Ajoessen/JOSM hab ich im unteren Teil mal ne Anleitung zusammengestellt, wie man da schäne gelb-grüne Haltescholder draus macht. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Justizminister wollen Auflagen für Geoda tendienste
Philip Gillißen gue...@freenet.de wrote: Das bedeutet anscheinend neuen Ärger auch für OpenStreetMap. Na ja Joachim hatte da ja eigentlich schon Entwarnung gegeben: http://blog.openstreetmap.de/2010/09/spitzengesprach-digitalisierung-von-stadt-und-land-im-bmi/ Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /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] Neu: Ein schwarz/weißer Base-Layer
Hi, Am 03.11.2010, 12:18 Uhr, schrieb Torsten Breda torst...@gmail.com: Zwar nicht schwarz-weiss, aber auch schön und dezent als Hintergrund ist der style, den Melchior in seiner ÖPNV-Karte verwendet. http://www.öpnvkarte.de/?zoom=11lat=51.97562lon=8.27014layers=BT Ja, der gefällt mir auch sehr gut, er lässt auch deutlich mehr weg als mein bw-noicons style, aber so weit ich weiß ist er nicht als Baselayer verfügbar. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tongrube taggen
Hallo *, wie würdet Ihr eine Tongrube taggen? Dazu kann ich bisher nichts vergleichbares finden. landuse=clay_pit ? Gruß Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Hi, Am 03.11.2010, 12:31 Uhr, schrieb Claudius claudiu...@gmx.de: Zitat: however this has been the subject of some debate, because it has the disadvantage of not explicitly associating the bus stop with the way (a headache for routing software) Sorry, dass ich so deutlich bin, aber das ist doch hanebüchener Unsinn. Wenn eine Routingsoftware damit Kopfschmerzen hat könnte sie zu keiner einzigen Hausnummer routen! Und das war IMHO das *einzige* Pro-Argument für bus_stop auf highways. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 03.11.2010 13:14, schrieb Carsten Schönert: wie würdet Ihr eine Tongrube taggen? Dazu kann ich bisher nichts vergleichbares finden. landuse=clay_pit ? Ist eine Tongrube nicht einfach ein Sonderfall eines Steinbruchs? Zumindest [1] stimmt mir da zu. Bei landuse=quarry kannst du auch die abgebaute Resource angeben [2]. Also mein Vorschlag: landuse=quarry ressource=clay Gruß, Markus [1] http://dict.leo.org/ende?lp=endelang=desearchLoc=0cmpType=relaxedsectHdr=onspellToler=search=tongrube [2] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dquarry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Dead Drops, Wie taggen?
Es gibt ein neues Projekt namens Dead Drops, USB Sticks in Mauerritzen zu betonieren (vgl. [1], [2]) Wie taggt man denn sowas? Vielleicht sollte man gleich Werbung für OSM machen bevor deren Datenbank online geht? amenity=dead_drops dead_drops:interface=usb1 dead_drops:size=4GB dead_drops:mounted=wall operator=? und evtl. opening_hours (wenn nicht immer zugänglich) disused=yes (wenn kaputt) webpage= (ein Webseite mit weiterer Beschreibung) Weitere Vorschläge? Gruß Sven [1] http://www.golem.de/1011/79080.html [2] http://deaddrops.com/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Taggen wir nicht nur Dinge, die länger als sechs Monate Bestand haben? ;-) SCNR Also mal davon ausgegangen, dass das nicht nur ein kurzlebiges Kunstprojekt ist: Am 03.11.2010 13:30, schrieb Sven Anders: amenity=dead_drops dead_drops:interface=usb1 Spielt die USB-Version eine Rolle? Dann würd ich eher erfassen, ob man ein Kabel braucht, um da dranzukommen: dead_drops:access=direct/cable dead_drops:size=4GB dead_drops:mounted=wall operator=? opening_hours (wenn nicht immer zugänglich) disused=yes (wenn kaputt) webpage= (ein Webseite mit weiterer Beschreibung) website=* ist etabliert, das würde ich statt webpage benutzen. Falls vorhanden, würde ich noch ref=* aufnehmen. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Am 03.11.2010 13:30, schrieb Sven Anders: Wie taggt man denn sowas? Da es fraglich sein sollte, ob dieses Projekt länger halten sollte (Kapazität der USB-Sticks zu begrenzt, USB-Sticks zu leicht zerstörbar), sollte man überlegen, ob sowas überhaupt in die OSM-Datenbank gehört. Man könnte es auch extern speichern und auf einer Webseite auf einer OSM-Karte Marker setzen. amenity=dead_drops dead_drops:interface=usb1 dead_drops:size=4GB dead_drops:mounted=wall operator=? Wenn du sowieso schon eigene Keys erfinden willst, warum denn dann noch amenity=* nutzen? Und wieso Plural? Es wird noch normalerweise ein einziger USB Stick sein, den du jeweils mappen willst. Und du solltest daran denken, dass „dead drop“ allgemein „toter Briefkasten“ heißt. Es sollte also ggf. auch die Möglichkeit von Nicht-USB-toten-Briefkästen umfassen. webpage= (ein Webseite mit weiterer Beschreibung) website=* (!) Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Alle Mann abkühlen!!! Fieberthermometer sagt 36,7°, ich hoffe, das ist okay ;) Als derjenige, der diesen Thread so zu sagen ein zweites Mal entflammt hat, möchte ich doch sehr bitten! Es muss doch irgend eine Lösung zu finden sein, die beide Welten miteinander vereint. Meine und wahrscheinlich auch die von Ulf, also die Routersicht, und die der Mapper. Die Kernfrage ist doch, was kann ich aus den OSM-Daten machen. Egal ob Routing oder Briefkastensuche. Mir persönlich wichtig ist dabei nur, dass die Daten auch ohne Heuristiken verarbeitbar bleiben und dafür ein herkömmlicher Computer ausreicht. Sonst wird's exklusiv und es werden Abhängigkeiten zu Anbietern geschaffen, die dann irgendwann den Laden zu machen. +1, und einen Vorschlag biete ich gleich dazu: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Das Routing-Gewicht dessen lässt sich als ganzes vergeben, die Route ist sowieso festgelegt; und trotzdem können die Details/service-Wege als solche korrekt gemappt werden. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Kay Drangmeister wrote: Am 03.11.2010, 12:18 Uhr, schrieb Torsten Breda torst...@gmail.com: Zwar nicht schwarz-weiss, aber auch schön und dezent als Hintergrund ist der style, den Melchior in seiner ÖPNV-Karte verwendet. http://www.öpnvkarte.de/?zoom=11lat=51.97562lon=8.27014layers=BT Ja, der gefällt mir auch sehr gut, er lässt auch deutlich mehr weg als mein bw-noicons style, aber so weit ich weiß ist er nicht als Baselayer verfügbar. Nicht direkt, aber ich hatte mal angefangen das umzusetzen: http://www.öpnvkarte.de/testing.php?zoom=12lat=50.76678lon=6.06961layers=000TB Die tiles werden dabei vom deutschen OSM-Server ausgeliefert, so dass die Tiles im Gegensatz zu den ÖPNV-Tiles aktuell sein sollten: http://tile.openstreetmap.de/tiles/background/ Vielleicht hat ja jemand Intresse das weiter zu entwickeln... Gruß, Melchior -- View this message in context: http://gis.638310.n2.nabble.com/Neu-Ein-schwarz-wei-er-Base-Layer-tp5698843p5701206.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] Dead Drops, Wie taggen?
Sven Anders wrote: Es gibt ein neues Projekt namens Dead Drops, USB Sticks in Mauerritzen zu betonieren ...und dein Abfall landet dann auch auf ner Müllbetonie??? ;) lg walter - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/Dead-Drops-Wie-taggen-tp5701107p5701229.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] Tongrube taggen
Hi, Am 03.11.2010 13:20, schrieb olvagor: Ist eine Tongrube nicht einfach ein Sonderfall eines Steinbruchs? Zumindest [1] stimmt mir da zu. Bei landuse=quarry kannst du auch die abgebaute Resource angeben [2]. Also mein Vorschlag: landuse=quarry ressource=clay Kann ich nachvollziehen, Danke! Gruß, Markus [1] http://dict.leo.org/ende?lp=endelang=desearchLoc=0cmpType=relaxedsectHdr=onspellToler=search=tongrube [2] http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dquarry ___ 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] AIO - Routing über Fähren
Am 03.11.2010 00:44, schrieb M∡rtin Koppenhoefer: Es gab da vor einiger Zeit mal eine ellenlange Diskussion über den Sinn / Unsinn dieser Unterscheidung, da eine Abgrenzung nicht möglich sei. Ich kenne mich da nicht aus. glaube ich ehrlich gesagt nicht (dass man die nicht abgrenzen kann), andere Karten schaffen das ja auch. Bei einem Segelfluggelände wird man hauptsächlich Segelflugzeuge finden, die gibt es auf einem Flughafen z.B. nicht. Gibt es sehr wohl, beispielsweise in Friedrichshafen! Modellflug-gelände / -startplatz habe ich auch noch nie mit einem regulären Flugplatz zusammen gesehen. Es werden Beispiele dafür gab es in der letzten Diskussion. Durch entsprechende zeitliche Regelungen ist das möglich. Wenn es wirklich keine offizielle Unterscheidung gibt, bzw. diejenigen die sich da auskennen (ein paar Flieger haben wir ja bei OSM auch an Bord) sich da raushalten wollen (was ich mir eigentlich auch nicht denken kann), dann müssten halt die Laien sich das mal ansehen. Soweit ich die letzte Unterhaltung dazu in Erinnerung habe, gab es ein paar wenige, die lautstark reklamiert hatten, dass auch RC-Fluggelände wie Flugplätze zu taggen seien (mindestens die Landebahnen), und aufgrund dieser Diskussion dann das Thema insgesamt nicht geklärt werden konnte. Es wird doch sonst in OSM immer ganz gross geschrieben dass zu taggen was vorhanden ist, wo ist jetzt hier das Problem? Sämtliche Eigenschaften der Landebahn beschreiben und gut ist. Wenn jemand einen Flugplatz sucht dann wird er nicht drumherum kommen nach Eigenschaften zu filtern, fürs normale Autonavi kann man ihm die Arbeit schon abnehmen in dem man dort Passagierterminals listet. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Es hat sich schon beim letzten mal gezeigt dass es keinen Sinn macht irgendwelche künstlichen Einteilungen für etwas zu machen das fliessende Übergänge hat. Einfach dazutaggen was tatsächlich vorhanden ist beschreibt die Situation am besten. Luftverkehrsseitig die Angaben über die Landebahn und flugsicherungstechnischen Einrichtungen, Passagierseitig Angaben wie Linienflüge, Charterflüge, Taxi-Flüge, Rundflüge,... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Moin, Carsten Schönert schrieb: Hallo *, wie würdet Ihr eine Tongrube taggen? Dazu kann ich bisher nichts vergleichbares finden. landuse=clay_pit ? es scheint so, als sollte landuse=quarry mit resource=* allgemein für die oberflächliche Resourcenentnahme verwendet werden. Halte ich durchaus für sinnvoll - bin aber nicht so bewandern, was ein Muttersprachler dazu sagen würde - schon mal auf Tagging gesucht? Aber vielleicht wollte das auch nur jemand ... Jedenfalls driften das englische (früher da) und das deutsche (später da) Wiki mal wieder auseinander - und ich bezweifle, dass der Tag 'quarry' erst seit Dezember 2009 verwendet wird - und weiß nicht, wie er ursprünglich mal gedacht war. 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 03.11.2010 13:58, schrieb Peter Wendorff: Alle Mann abkühlen!!! Fieberthermometer sagt 36,7°, ich hoffe, das ist okay ;) Als derjenige, der diesen Thread so zu sagen ein zweites Mal entflammt hat, möchte ich doch sehr bitten! Es muss doch irgend eine Lösung zu finden sein, die beide Welten miteinander vereint. Meine und wahrscheinlich auch die von Ulf, also die Routersicht, und die der Mapper. Die Kernfrage ist doch, was kann ich aus den OSM-Daten machen. Egal ob Routing oder Briefkastensuche. Mir persönlich wichtig ist dabei nur, dass die Daten auch ohne Heuristiken verarbeitbar bleiben und dafür ein herkömmlicher Computer ausreicht. Sonst wird's exklusiv und es werden Abhängigkeiten zu Anbietern geschaffen, die dann irgendwann den Laden zu machen. +1, und einen Vorschlag biete ich gleich dazu: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße, Schiene, oder Wasser müssen nur irgendwie verbunden sein. Dann funktionieren alle Router. Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation). Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist lediglich bei der Aufbereitung der Infos für ein Routing relevant: Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Das Routing-Gewicht dessen lässt sich als ganzes vergeben, die Route ist sowieso festgelegt; und trotzdem können die Details/service-Wege als solche korrekt gemappt werden. Gruß Peter ___ 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] AIO - Routing über Fähren
Am 03.11.2010 13:58, schrieb Peter Wendorff: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich glaube nicht dass es für's Routing wichtig ist ob die Zufahrtswege als service oder höher eingestuft sind. Falls es die einzige Verbindung ist, ist es völlig Schnuppe. Dann muss der Router da drüber oder 'ne Fehlermeldung bringen, wenn man das Routing über Fähren im Navi abgeschaltet hat. Und falls nicht, bestimmt hauptsächlich die Geschwindigkeit der Fähre den Zeitbedarf. Wenn man also eine halbe Stunde auf der Fähre ist, macht es keinen großen Unterschied wenn der Router für den 100m Zufahrtsbereich mit 5 km/h oder mit 50 km/h rechnet. Ein Problem gibt es nur wenn man eine Anliegerbeschränkung für service impliziert. Sollte man halt nicht machen. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 14:36, schrieb Carsten Moeller: Am 03.11.2010 13:58, schrieb Peter Wendorff: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße, Schiene, oder Wasser müssen nur irgendwie verbunden sein. Dann funktionieren alle Router. gut ;) Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) Ich rede von einer Relation, ja; und ich halte das nicht für unbeherrschbar, sondern im Gegenteil für eine Vereinfachung des Routings (zumindest des Navigationsgraphen). Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation). Abbiegevorschriften sind was anderes; dabei werden Beschränkungen eingebaut. Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als abkürzende Wegstücke eingebaut werden können. Eine Relation vom Typ ferry|car_train, die zwei nodes mit role=entrypoint (völlig willkürlich und nicht über die Formulierung nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1 nach entrypoint2 und Gewicht n betrachten. Abfragen kann man diese Routen recht einfach: Relationen mit type=ferry|car_train abzufragen ist nicht schwieriger als highways mit type=secondary. Wenn man dafür bei vollständigem tagging die Service-Wege außer acht lassen kann, die ja von den Routing-Fetischisten hier als so böse betrachtet worden sind, finde ich, ist das ein recht guter Kompromiss. Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist lediglich bei der Aufbereitung der Infos für ein Routing relevant: Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Eben: Du willst service wegwerfen, und ich bietet dir hier einen Kompromiss, der durchaus sinnvoll ist; weil auch die Gewichtung von service-wegen an den Zustiegspunkten einer Fährroute eine andere ist als bei service=alley oder sowas. Die Alternative ist, für den Router falsch zu taggen (aber wenn ich Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher vs. das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum ausgebaut) 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 03.11.2010 15:04, schrieb Chris66: Am 03.11.2010 13:58, schrieb Peter Wendorff: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich glaube nicht dass es für's Routing wichtig ist ob die Zufahrtswege als service oder höher eingestuft sind. Ich beziehe mich dabei auf die Mail von Gary in diesem Thread: Am 29.10.2010 01:20, schrieb Garry: Am 28.10.2010 22:55, schrieb Chris66: 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. Aus Router-Sicht ist das halt schlecht. In Start- und Zielnähe kann er 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... Am 03.11.2010 15:04, schrieb Chris66: Falls es die einzige Verbindung ist, ist es völlig Schnuppe. Dann muss der Router da drüber oder 'ne Fehlermeldung bringen, wenn man das Routing über Fähren im Navi abgeschaltet hat. Tut er aber eben auch bei aktivierten Fährverbindungen nicht, wenn er zur Optimierung service innerhalb der Strecke gar nicht mehr berücksichtigt (vgl. Garry) Und falls nicht, bestimmt hauptsächlich die Geschwindigkeit der Fähre den Zeitbedarf. Wenn man also eine halbe Stunde auf der Fähre ist, macht es keinen großen Unterschied wenn der Router für den 100m Zufahrtsbereich mit 5 km/h oder mit 50 km/h rechnet. Um die Gewichtung direkt aus den Daten heraus ging es mir gar nicht, sondern um das vollständige Routing-Netz auch ohne komplexem Preprocessing, das erforderlich wird, wenn hier service-wege je nach ihrer Bedeutung im Gesamtsystem unterschieden werden müssen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte - Neuigkeiten?
Gernot Hillier wrote: Auf der Webseite selbst steht auch Stand September. Zur Zeit keine Updates. Weiß jemand mehr darüber und wann es wieder Updates gibt? Ist Melchior nur einfach im Urlaub oder ist hier längerfristig mit Problemen zu rechnen? Kennt jemand eine schöne Alternative? Wir waren nämlich eigentlich gerade dabei, unser ÖPNV-Netz in Landshut zu erfassen - und da ist eine schön gerenderte Karte natürlich ein guter Ansporn... :-) Das Problem ist, dass der Server mit den Datenmengen nicht mehr klarkommt. Da ich momentan mit OSM etwas kürzer fahre, bin ich aber auch noch nicht ernsthaft dazu gekommen das zu beheben... Als alternative bietet sich wie schon erwähnt der OSM Inspektor oder OSMTransport an (http://3liz.fr/public/osmtransport/). Gruß, Melchior -- View this message in context: http://gis.638310.n2.nabble.com/OPNVKarte-Neuigkeiten-tp5693725p5701605.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
[Talk-de] Fahrrad-Schließfach
hi ! ich habe in der letzten Zeit mehrfach schon so Boxen für Fahrräder (Art Schließfach) gesehen - Velobox habe ich als Bezeichnung schon einmal dazu gelesen. Hat einer diese schon einmal erfaßt. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 3. November 2010 13:20 schrieb olvagor o...@terbrueggen.net: Am 03.11.2010 13:14, schrieb Carsten Schönert: wie würdet Ihr eine Tongrube taggen? Dazu kann ich bisher nichts vergleichbares finden. landuse=clay_pit ? Ist eine Tongrube nicht einfach ein Sonderfall eines Steinbruchs? nein, ein Steinbruch ist es definitiv nicht, das gilt nur für die Förderung von Festgestein , Tagebau gilt hingegen schon, Bergbau passt auch. ___Das engl. Wort quarry passt ;-) ___ Mal wieder ein gutes Beispiel, dass man beim Übersetzen von Tags höllisch aufpassen muss, bzw. de:Wort=en:Wort nicht funktioniert. Es kommt jeweils auf die genaue Bedeutung an. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 3. November 2010 14:37 schrieb Georg Feddern ne...@bavarianmallet.de: es scheint so, als sollte landuse=quarry mit resource=* allgemein für die oberflächliche Resourcenentnahme verwendet werden. Halte ich durchaus für sinnvoll - bin aber nicht so bewandern, was ein Muttersprachler dazu sagen würde - schon mal auf Tagging gesucht? Aber vielleicht wollte das auch nur jemand ... Wikipedia:en sagt dazu: Open-pit mines that produce building materials and dimension stone are commonly referred to as quarries. People are unlikely to make a distinction between an open-pit mine and other types of open-cast mines,[citation needed] such as quarries, borrows, placers, and strip mines. das kommt aus dem Tagebau-Artikel: http://en.wikipedia.org/wiki/Open-pit_mining Es scheint also durchaus im engl. auch eine Reihe von differenzierenden Fachwörtern zu geben. Wie immer kommt es da auch auf die Perspektive an, z.B. passen sowohl http://en.wikipedia.org/wiki/Borrow_pit als auch clay_pit . Letzteres ist spezifischer, ersteres bezieht sich nicht auf das Material an sich, wohl aber auf die Verwendung an anderer Stelle. Hier gibts auch noch mal ne Menge Differenzierungen: http://en.wikipedia.org/wiki/Surface_mining Das Problem ist, wenn Du auf tagging fragst, bekommst Du oft auch eine Wald-und-Wiesen-Antwort, die bei weiterer Recherche oft nicht trägt, genauso wie Du auch auf Deutsch nicht erwarten kannst, dass Du fachlich korrekte Antworten zu Spezialthemen von jedermann bekommen kannst. Bevor jetzt der allgemeine Aufschrei kommt, das könnten die Mapper sowieso hinterher nicht auseinanderhalten, und man solle es nicht zu kompliziert machen: m.E. geht das durchaus, man (jemand, der das Fachwissen hat, ich bin das bei diesem Thema auch nicht) müsste nur detailliert beschreiben, wie sich die einzelnen Arten voneinander abgrenzen, und schon kann in fast allen Fällen auch der Laie den richtigen Tag vergeben. Eins der Probleme bei OSM ist gelegentlich, dass als Haupttag erstmal ein spezifischer Spezialfall eingeführt wird (z.B. village_green, arts_centre, etc.), und dann alles ähnliche auch damit versehen wird, weil es am ehesten passt. Ob das bei quarry auch der Fall ist, kann ich nicht beurteilen, aber es wäre m.E. nicht schlecht, wenn der Haupttag (landuse) was möglichst allgemeines bedeuten würde (Abbau von Mineralien), wo man Sandgrube, Kiesgrube, Tongrube (die sich jeweils nur in der Korngröße des abgebauten Materials unterscheiden) genauso wie Steinbrüche alles in einen Topf schmeissen kann, und die Details dann mit Subtags geklärt werden. 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 3. November 2010 14:22 schrieb Garry garr...@gmx.de: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Es hat sich schon beim letzten mal gezeigt dass es keinen Sinn macht irgendwelche künstlichen Einteilungen für etwas zu machen das fliessende Übergänge hat. Quatsch, fliessende Übergänge gibt es praktisch überall, ob das jetzt bei Flüssen (SCNR, hier im vgl. zu Bächen), Dörfern/Städten, oder Straßenkategorien ist. Das ist kein Grund, bei Flughäfen so was nciht zu machen. Es gibt ja z.B. auch sprachlich die div. Unterscheidungen wie Flughafen, Flugplatz, etc., die da ein Beispiel sind. Einfach dazutaggen was tatsächlich vorhanden ist beschreibt die Situation am besten. das ist immer gut, hier lenkt dieses Argument m.E. allerdings nur davon ab, dass man zusätzlich auch eine Hierarchie der Gesamtanlage Flughafen/platz haben könnte. Könnte z.B. auch eine site-relation sein, die einem da etwas bei der Auswertung hilft. Luftverkehrsseitig die Angaben über die Landebahn und flugsicherungstechnischen Einrichtungen, Passagierseitig Angaben wie Linienflüge, Charterflüge, Taxi-Flüge, Rundflüge,... jaja, ist ja alles gut und richtig. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fluggelände was: AIO - Routing üb er Fähren
Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 01:11 schrieb Garrygarr...@gmx.de: Gefährdungen gehen von allem möglichen aus. Boden-Luftübergänge sind keineswegs zwangsläufig das einzige Kriterium für einen Flughafen. Es Das habe ich auch nicht behauptet, aber es ist der gemeinsame Nenner der für alles gilt. ... Diese Einteilung mag für eine POI-Einteilung sinnvoll sein um im Navi den Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Mit Deinem Standpunkt aus der Tongrube stimme ich doch überein: Eins der Probleme bei OSM ist gelegentlich, dass als Haupttag erstmal ein spezifischer Spezialfall eingeführt wird (z.B. village_green, arts_centre, etc.), und dann alles ähnliche auch damit versehen wird, weil es am ehesten passt. Ob das bei quarry auch der Fall ist, kann ich nicht beurteilen, aber es wäre m.E. nicht schlecht, wenn der Haupttag (landuse) was möglichst allgemeines bedeuten würde (Abbau von Mineralien), wo man Sandgrube, Kiesgrube, Tongrube (die sich jeweils nur in der Korngröße des abgebauten Materials unterscheiden) genauso wie Steinbrüche alles in einen Topf schmeissen kann, und die Details dann mit Subtags geklärt werden. Von daher verstehe ich nicht warum Du es hier anderst gelöst haben willst? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 14:21 schrieb Garry garr...@gmx.de: Am 03.11.2010 00:44, schrieb M∡rtin Koppenhoefer: Modellflug-gelände / -startplatz habe ich auch noch nie mit einem regulären Flugplatz zusammen gesehen. Es werden Beispiele dafür gab es in der letzten Diskussion. Durch entsprechende zeitliche Regelungen ist das möglich. OK, es ist alles möglich, aber nur weil nachts (oder sonst wann) Modellflieger ein Fluggelände nutzen können, heisst das ja nicht, dass sich an der grundsätzlichen Einstufung etwas ändert. Genauso wie auch die Tatsache, dass es auf dem Friedrichshafener Verkehrsflughafen auch Segelflugzeuge gibt nichts daran ändert, dass es sich um einen Verkehrsflughafen handelt. Ich will die Segelflieger ja nicht unterschlagen, aber für die Bedeutung eines Fluggeländes ist eher das größte starten/landen könnende Verkehrsmittel entscheidend, als das kleinste. Es wird doch sonst in OSM immer ganz gross geschrieben dass zu taggen was vorhanden ist, wo ist jetzt hier das Problem? Sämtliche Eigenschaften der Landebahn beschreiben und gut ist. damit muss es eben noch nicht gut sein. Man könnte auch ein Taggingschema haben, wo man nichtmal eine Landebahn zu mappen braucht, um schonmal ne grobe Ahnung davon zu vermitteln, um welche Art Flughafen es sich handelt. 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 3. November 2010 14:36 schrieb Carsten Moeller cmindivid...@gmx.de: Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) das ist einzig vom Router und dessen preprocessing abhängig, der routet ja sowieso nicht auf OSM-Daten, ohne die vorher fürs Routing schonmal zu bearbeiten. Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Wenn Du damit meinst, dass man auf die Gleise taggen soll, ob da ein Autozug fährt: m.E. eher nicht. Das ist klar eine Eigenschaft der route, nicht der Gleise. Autozüge können auf allen Gleisen (naja) fahren. 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 3. November 2010 15:08 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als abkürzende Wegstücke eingebaut werden können. Eine Relation vom Typ ferry|car_train, die zwei nodes mit role=entrypoint (völlig willkürlich und nicht über die Formulierung nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1 nach entrypoint2 und Gewicht n betrachten. Abfragen kann man diese Routen recht einfach: Relationen mit type=ferry|car_train abzufragen ist nicht schwieriger als highways mit type=secondary. sehe ich auch so. Man könnte auch noch die Fahrtzeit (en) angeben mit einem Tag in der Route. Die Alternative ist, für den Router falsch zu taggen (aber wenn ich Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher vs. das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum ausgebaut) ein Parkplatz ist es m.E. nicht, eher ein Wartebereich. Und dem eine niedrige Verkehrsbedeutung zuzumessen ist relativ (wenn man die Fähre benutzen will, ist die Bedeutung enorm, andererseits ist vermutlich nicht allzu viel Verkehr dort verglichen mit einer Autobahn, andererseits sicher mehr als auf einer unclassified im ländlichen Raum. Klar, jeder Supermarkparkplatz hat auch eine hohe Frequenz an Fahrzeugen --- nur dass die dort in eine Sackgasse einfahren, es ist dort im Ggs. zum Fährterminal keine Durchgangsstation sondern ein hin und zurück, d.h. Bedeutung für den Durchgangsverkehr gleich null, daher service.). Der Ausbauzustand hat mehr mit den möglichen Geschwindigkeiten als mit der Verkehrsbedeutung zu tun (bzw. würde ich hier argumentieren: da man sowieso nicht schneller als Schrittgeschwindigkeit (oder 20 oder was auch immer) fahren darf, braucht das auch nicht autobahnähnlich ausgebaut zu werden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fluggelände was: AIO - Routing üb er Fähren
Am 3. November 2010 17:40 schrieb Garry garr...@gmx.de: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Mit Deinem Standpunkt aus der Tongrube stimme ich doch überein: Von daher verstehe ich nicht warum Du es hier anderst gelöst haben willst? will ich ja gar nicht. Die Kunst ist so spezifisch wie nötig aber so generisch wie möglich zu taggen. Wenn Modellflugplätze und Großflughäfen denselben Haupttag erhalten, vermischt man m.E. 2 völlig unterschiedliche Dinge miteinander (Personbeförderung und Freizeitspaß) und das kann niemandem dienen. Das wäre noch nichtmal so, wenn Autobahnen und Feldwege erstmal denselben Tag erhielten, und man dann an den Abständen der Seitenpfosten und Vorhandensein von Leitplanken ableiten sollte, was was ist, sondern sogar noch eine Stufe härter. Klar, es gibt Gemeinsamkeiten (Starten und Landen von Fluggeräten, potentielle Gefährdung, etc.), aber die Unterschiede sind --- zumindest in meinen Augen --- deutlich größer. Ich würde Tongruben und Kiesgruben, auch Steinbrüche erstmal in eine Kategorie packen, aber Misthäufen würde ich da z.B. nicht reintun. Oder Bodenverfüllungen. 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 03.11.2010 17:46, schrieb M∡rtin Koppenhoefer: das ist einzig vom Router und dessen preprocessing abhängig, der routet ja sowieso nicht auf OSM-Daten, ohne die vorher fürs Routing schonmal zu bearbeiten. Zumindest muss man das preprocessing nicht unnötig aufwendig machen. Wenn Du damit meinst, dass man auf die Gleise taggen soll, ob da ein Autozug fährt: m.E. eher nicht. Das ist klar eine Eigenschaft der route, nicht der Gleise. Autozüge können auf allen Gleisen (naja) fahren. In den Fällen in denen die Schiene die Strasse quasi alternativfrei als rollende Landstrasse ersetzt mach das schon Sinn. Es werden dort meist spezielle Züge eingesetzt die nur für diese eine Verbindung da sind. Garr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:50 schrieb Claudius claudiu...@gmx.de: kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso nochmal extra einträgst? Könnte mir, aber da ich mich selber auch schon mit der Auswertung beschäftigt habe, konnte ich den Vorteil der Platzierung auf dem Weg erkennen. Die Information zum Haltestellenstandort steckt ja im platform-Tag. Klar, man kann diese Argumentation auch umdrehen, was bleibt ist dass Du ein tag (highway=bus_stop) absichtlich entgegen dem allgemeinen (AFAIK lang und breit ausdiskuttierten) Konsens verwendest, obwohl Du sowieso Redundanzen anlegst. Ist in meinen Augen respektlos gegenüber der Community. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Sat, 30 Oct 2010 09:45:42 +0200 Von: Jochen Topf joc...@remote.org An: Jonas Stein n...@jonasstein.de CC: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? Das ist keine Anarchie. Nein, das ist keine Anarchie, das ist die natürliche Entwicklung eines Systems, das weitgehend sich selbst überlassen ist. Es verliert Struktur und verfettet. Kennt jeder irgenwie vom deutschen Steuerrecht oder manche von uns von endlosen Projektsitzungen bei denen immer nur ein schaler Kompromiss herauskommt. OSM ist hier nicht herrausragend, weder in die eine, noch in die andere Richtung. Ein Konzept wie das OSM-Taggingschema kann an seinen Selbstreinigungskräften gemessen werden. Wie gross sind die Chancen, dass Altlasten, die sich nicht bewährt haben, abgeworfen werden oder wird alles zusammenaggregiert und verwurschtelt? Aber es funktioniert. Es kommt darauf an, was man unter 'funktionieren' versteht. Ja, es stimmt, das OSM Datenmodell schleppt sich gemächlich über die Jahre ohne eine echte Entwicklunsperspektive zu haben. Langfristig setzt sich so nämlich die Mehrheit der an einem Thema interessierten durch. Na ja, meistens setzt sich das durch, was der Editor als Mehrheitsbeschaffer vorgibt ;) Aber auch wenn nicht, Mehrheiten erzeugen keine Tiefe und vermitteln auch keine Selbstreinigungskräfte. Das wird besonders deutlich, wenn sich zwei Lager bilden, von denen jede Seite genug Einfluss hat, um ihre Wahrheit in Teilbereichen durchzusetzen. dann muss man das nicht in einem speziellen (selbsternannten) Gremium durchsetzen. Der gute alte Buhmann - das Gremium, das über die Köpfe der Anwender hinweg bestimmt. Was ist, wenn dieses Gremium nur Vorschläge macht und die Anwenderschaft darüber abstimmt, ob sie diesen Vorschlag für Vrteilhaft hält? Aber im heutigen OSM ist das undenkbar - es gibt nur die primitive Abstimmung mit der Macht der Einträge über tagwatch oder einsame diktatorische Entscheidungen hinter verschlossnen Türen, die man als Mapper gefälligst zu akzeptieren hat. Oder es hat diese Macht, dann werden sich alle Mapper, die der Meinung des Gremiums nicht zustimmen, von OSM abwenden. Huhuuu, noch so ein Horrorszenario. Ein pöses machtgeiles Gremium vertreibt die Mapper. Warum immer diese dummen Polarisierungen, die jeden Mittelweg als ungangbar brandmarken? In den ganzen Jahren gab es so gut wie niemanden. der ein so machtvolles Gremium gefordert hat, aber jeder gut gemeinte Ansatz wurde mit Pauschalargumenten wie diesem hier in Grund und Boden geschrieben. Was hingegen immer wieder viele Mapper gefordert haben, war eine Richtschnur, die ihnen das Mappingleben erleichtert. OSM verwendet schon das richtige Verfahren. Sonst wäre das Projekt nicht so weit gekommen. Es ist wie es ist und weil es so ist, ist es gut? Diese Aussage ist in dieser Pauschalität einfach nur Unsinn. Keiner von uns hat eine Glaskugel, die das 'was wäre wenn' beantworten kann, aber einige von uns kennen noch die alten Zeiten (vor Mitte 2007), in denen durchaus kreativ an den Tags gearbeitet wurde und zusammen das Schema verbessert wurde - ganz ohne Tagwatch Co. die Welt, die nunmal sehr komplex ist, in ein simples Schema zu pressen. Und deshalb versucht man bei OSM diese Komplexität noch zu übertreffen, indem man über ein primitives Basisschema eine quasi unendliche Vielfalt an Taggingvariationen stülpt die alles oder nichts aussagen? es geht darum, etwas praktisch nutzbares zu entwickeln. Und genau hier hätte ich weniger fromme Sprüche erwartet, sondern eine ernsthafte Abhandlung darüber, ob OSM in der praktischen Nutzbarkeit wirklich so überlegen ist. Also etwas Modelltheorie, die sich mit Redundanzen und der maximal erreichbaren Komplexität (nicht nur schreibend, auch lesend) befasst. Schon eine so simple Sache wie Abbiegeverbote hat OSM schon oft an seine Grenzen gebracht oder bringt es sie noch? -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Am 3. November 2010 13:30 schrieb Sven Anders s...@anders-hamburg.de: Es gibt ein neues Projekt namens Dead Drops, USB Sticks in Mauerritzen zu betonieren (vgl. [1], [2]) Wie taggt man denn sowas? Vielleicht sollte man gleich Werbung für OSM machen bevor deren Datenbank online geht? amenity=dead_drops einen Tag für tote Briefkästen finde ich gar nicht schlecht. Aber muss das auch noch in amenity landen? Ich würde dann erstmal grundsätzlich einen Tag für den Typ (hier deponierter USB-Stick) machen, und die u.g. Attribute darauf beziehen. dead_drops:interface=usb1 dead_drops:size=4GB das ist allerdings nicht die physische Größe, (und auch nicht die des toten Briefkastens, s.o.). Bei USB-Sticks wäre evtl. das Filesystem interessant. dead_drops:mounted=wall operator=? und evtl. opening_hours (wenn nicht immer zugänglich) disused=yes (wenn kaputt) disused wäre wieder auf den toten Briefkasten bezogen und nicht auf den Zustand des Sticks m.E., wenn man nicht die Auffassung vertritt, der Stick an sich sei der tote Briefkasten. webpage= (ein Webseite mit weiterer Beschreibung) AFAIK nutzt man dafür überwiegend url. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Am 03.11.2010 18:29, schrieb M∡rtin Koppenhoefer: AFAIK nutzt man dafür überwiegend url. website=* wie schon zweimal geschrieben. Ich frage mich wo der Sinn sein sollte so etwas in der OSM-Datenbank zu speichern. Falls jemand z.B. eine Webseite mit einer Übersicht der Dead Drops betreiben will, müsste er eine eigene OSM-Datenbank + Mapnik betreiben, wenn ich nicht irre. Und er könnte sich nicht mal auf die Konsistenz der Informationen zu den Dead Drops verlassen. (Benutzt auch jeder die vorgeschlagene Syntax?) Eine separate Datenbank für die Dead Drops zu betreiben wäre wesentlich weniger Aufwand und man kann natürlich dafür sorgen, dass die Daten zumindest formal korrekt sind. Beim Endnutzer wird es so oder so via OpenLayers angezeigt. Nach wenigen Monaten werden die Leute eh das Interesse daran verlieren und die Infos dazu in der OSM-Datenbank sind dann Datenmüll, der voraussichtlich für immer bleibt (oder mühsam beseitigt werden muss). Weiterentwicklung wäre dann vmtl. die Neuerfindung der BBS. Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
2010/11/3 Élisée Reclus elisee.rec...@arcor.de: Am 03.11.2010 18:29, schrieb M∡rtin Koppenhoefer: AFAIK nutzt man dafür überwiegend url. website=* wie schon zweimal geschrieben. das kannst Du schreiben so oft Du willst, es sind 3,5x (26 zu 66800) so viele url in der db wie websites. Wenn man es gleichziehen wollte, würde man daher ziemlich sicher url verwenden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 03.11.2010 12:30, schrieb Andreas Neumann: Auch wenn es immer heißt, wir mappen nicht für die Renderer, finde ich das tag highway=bus_stop am Mast besser, da dann auch auf der Karte ersichtlich ist, für welche Fahrtrichtung die Haltestelle ist... Zusätzlich setze ich immer noch ein traffic_sign=DE:224 an die Mastposition. Dann ist klar, was gemappt wurde. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bereits über 150 TeilnehmerInnen habe n beim OSM-Fragebogen mitgemacht
... angeschaut - aber ausser, dass der screen immer grüner wurde, ist visuell nix passiert .. mmh. ne kleiner tipp wäre nett. thx s Am 03.11.2010 11:38, schrieb Marco Lechner - FOSSGIS e.V.: Hallo und vielen Dank an alle die bereits an meinem Fragebogen zu OpenStreetMap teilgenommen haben. Ich habe mir die Mühe gemacht in einer kleinen Kartenanwendung den aktuellen Stand der Beteiligung am Fragebogen nach PLZ aufgeschlüsselt (aggregiert auf die erste und die ersten beiden Stellen) zu visualisieren. Wer's mal anschauen möchte (aber nicht alle gleichzeitig ;-): http://geeste.geographie.uni-freiburg.de/OSMmaps/ Ansonsten freue ich mich weiterhin über jedeN der/die am Fragebogen teilnimmt (ja es haben auch schon Frauen mitgemacht, wenn auch in überschaubarer Zahl): http://geeste.geographie.uni-freiburg.de/OSMfb/ Gerne kann die Information über den Fragebogen auch in den lokalen OSM-Gruppen oder ???-Telefonlawine verbreitet werden. Es ist sehr schwierig den Otto-Normal-Mapper anzusprechen, der nicht in einer der Email-Listen unterwegs ist, ohne SPAM zu produzieren indem man eine Rundmail an alle registrierten OSMler schickt (wofür es gute Gründe geben mag, ein Fragebogen gehört aber nicht dazu). Oh, bevor es gleich wieder Schimpfe gibt: Die PLZ-Visualisierung für Österreich fehlt noch, da mir einfach die PLZ-Polygone gerne auch in generalisierter Form fehlen. Falls hier jemand eine freie Quelle kennt, wäre ich für einen kleinen Hinweis dankbar. Viele Grüße aus dem Schwarzwald Marco Lechner ___ 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] Dead Drops, Wie taggen?
Am 03.11.2010 18:57, schrieb M∡rtin Koppenhoefer: das kannst Du schreiben so oft Du willst, es sind 3,5x (26 zu 66800) so viele url in der db wie websites. Wenn man es gleichziehen wollte, würde man daher ziemlich sicher url verwenden. Was in den Map Features steht ist dann vmtl. auch egal? Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 15:08, schrieb Peter Wendorff: Am 03.11.2010 14:36, schrieb Carsten Moeller: Am 03.11.2010 13:58, schrieb Peter Wendorff: Aufhänger dieses Threads waren Fährverbindungen, dazugekommen sind Autozüge. In beiden Fällen geht es darum, dass die Zubringer eigentlich eben keine Hauptverkehrsadern sind; die Routing-Fraktion aber die entsprechende Verkehrsbedeutung betrachtet haben möchte. Ich bin mir nicht sicher, ob das überall möglich ist, aber kann man nicht die Route entsprechend anpassen? Ich glaube schon, dass das möglich ist. Die Wege, egal ob Straße, Schiene, oder Wasser müssen nur irgendwie verbunden sein. Dann funktionieren alle Router. gut ;) Die Fährroute läuft eben nicht von Ufer zu Ufer, sondern von Straßenabzweig, einschließlich aller service-highways, warteplätze/schlangen und Co. Warum dann nicht eine fähr/schiffsstrecke und eine Fähr-Route, die die Schiffsstrecke enthält? Letztere kann am Zubringer der Bundesstraße anfangen und aufhören und bekommt ein Gesamtgewicht. Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) Ich rede von einer Relation, ja; und ich halte das nicht für unbeherrschbar, sondern im Gegenteil für eine Vereinfachung des Routings (zumindest des Navigationsgraphen). Dies betrifft auch die Topologie-Erstellung. Es ist schon ein halber Beinbruch, überhaupt die Abbiegevorschriften hinzukriegen (Relation). Abbiegevorschriften sind was anderes; dabei werden Beschränkungen eingebaut. Abbiegevorschriften sind technisch das Gleiche. Das sind auch nur Relationen mit einer Menge anderer Verweise, in diesem Fall meistens FromWay, ViaNode und ToWay. Ob nun noch zusätzlich ein no_left_turn oder no_right_turn folgt ist Hupe. Eine andere Vorschrift oder Zusatzinfo könnte genau so grün, blau, Weltkulturerbestraße Russland-Atlantis oder eben Fährverbinder heißen. Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als abkürzende Wegstücke eingebaut werden können. Eine Relation vom Typ ferry|car_train, die zwei nodes mit role=entrypoint (völlig willkürlich und nicht über die Formulierung nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1 nach entrypoint2 und Gewicht n betrachten. Abfragen kann man diese Routen recht einfach: Relationen mit type=ferry|car_train abzufragen ist nicht schwieriger als highways mit type=secondary. Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. Ein herkömmlicher Rechner wird dies kaum leisten können, es sei denn er liest den Datenstrom zyklisch so lange, bis alles aufgelöst ist. Eine Datenbank (z.B. PostGIS) ist hier übrigens auch nicht schneller oder besser. Das sind alles Läufe, die nicht mehr in Stunden, sondern im 0,5-Tages-Intervall zu messen sind. Wenn man dafür bei vollständigem tagging die Service-Wege außer acht lassen kann, die ja von den Routing-Fetischisten hier als so böse betrachtet worden sind, finde ich, ist das ein recht guter Kompromiss. Das Routing über die service-Wege dazwischen ist vermutlich sowieso nicht ohne weiteres möglich, weil das meiner Erfahrung nach oft über Plätze und gesteuert von Einweisern geschieht. Dem Algorithmus ist das Hupe, der fährt auf allem was da ist. Es ist lediglich bei der Aufbereitung der Infos für ein Routing relevant: Also nehm ich den Weg oder werfe ich ihn von vornherein weg. Dafür müssen halt die Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Eben: Du willst service wegwerfen, und ich bietet dir hier einen Kompromiss, der durchaus sinnvoll ist; weil auch die Gewichtung von service-wegen an den Zustiegspunkten einer Fährroute eine andere ist als bei service=alley oder sowas. Nein, ich will nicht Service wegwerfen, um Himmels Willen, ..., nur es muss was her, das a) entweder Services grundsätzlich ausschließt oder b) explizit einschließt. a) ist Gott sei Dank häufig anzutreffen und wird auch fleißig mittels der access-Tags restriktiert. Nur für b) gibt faktisch keine Vorschrift. Hier fehlt die Umkehrlogik, damit ich weiß, dass hier was Wichtiges zu berücksichtigen ist. Die Alternative ist, für den Router falsch zu taggen (aber wenn ich Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher vs. das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum ausgebaut) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de
Re: [Talk-de] Fahrrad-Schließfach
Hallo Jan, ich habe in der letzten Zeit mehrfach schon so Boxen für Fahrräder (Art Schließfach) gesehen - Velobox habe ich als Bezeichnung schon einmal dazu gelesen. amenity=bicycle_parking bicycle_parking=lockers capacity=* http://wiki.openstreetmap.org/wiki/Key:bicycle_parking Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
2010/11/3 Élisée Reclus elisee.rec...@arcor.de: Am 03.11.2010 18:57, schrieb M∡rtin Koppenhoefer: das kannst Du schreiben so oft Du willst, es sind 3,5x (26 zu 66800) so viele url in der db wie websites. Wenn man es gleichziehen wollte, würde man daher ziemlich sicher url verwenden. Was in den Map Features steht ist dann vmtl. auch egal? da steht, man solle url nicht benutzen und es ist durchgestrichen. Gabs dazu eine Diskussion oder Abstimmung oder so was, oder wie kommt das? 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 3. November 2010 19:31 schrieb Carsten Moeller cmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Mit welchem Programm routest Du denn? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 03.11.2010 18:16, M∡rtin Koppenhoefer: Am 3. November 2010 12:50 schrieb Claudiusclaudiu...@gmx.de: kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso nochmal extra einträgst? Könnte mir, aber da ich mich selber auch schon mit der Auswertung beschäftigt habe, konnte ich den Vorteil der Platzierung auf dem Weg erkennen. Die Information zum Haltestellenstandort steckt ja im platform-Tag. Klar, man kann diese Argumentation auch umdrehen, was bleibt ist dass Du ein tag (highway=bus_stop) absichtlich entgegen dem allgemeinen (AFAIK lang und breit ausdiskuttierten) Konsens verwendest, obwohl Du sowieso Redundanzen anlegst. Ist in meinen Augen respektlos gegenüber der Community. Nein, da habe ich mich missverständlich ausgedrückt. Ich setze kein gesondertes highway=bus_stop, ich belasse aber vorhandene auf dem Weg und tagge die nicht an den Knoten auf der Warteposition um. Könnte ich wohl machen, wenn das einigen hier so wichtig ist. Bei Haltestellen die ich neu erfasse packe ich gar kein bus_stop mehr dran, sondern ausschliesslich public_transport-Tags Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. Mit welchem Programm routest Du denn? Gruß 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] Gebäude-Mapping
wendo...@uni-paderborn.de (Peter Wendorff) am 03.11.10: Wo also ist das Problem, und wieso ist das Malen statt Mappen? Ich sehe dort in Mapnik ein kreisrundes Gebäude, speichenartig umgeben von 24 etwa spitzdreieckigen Gebäuden, wiederum umgeben von einem halbkreisförmigen Gebäude. Wenn da mal nicht explizit für den Renderer getaggt wurde, damit es schick aussieht. Btw: Wie mapt man sowas? Haben wir freie, hochauflösende Luftbilder davon? Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 20:01 schrieb Carsten Moeller cmindivid...@gmx.de: Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? 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 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:01 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. Ich will jetzt nicht sagen unlösbar, aber ob sich da schon mal jemand dran versucht hat, wage ich zu bezweifeln. Wie ich schon erwähnte, alleine die Restriktionen mit einzubehiehen hat mich fast an den Rand des Wahnsinns getrieben. ... Aber ich bin ja noch da ;-) Gruß 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] AIO - Routing über Fähren
Am 3. November 2010 20:43 schrieb Carsten Moeller cmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi, On 02.11.2010 20:37, Kay Drangmeister wrote: Hi Nach einigen Diskussionen wie man Karten mit Layern ansprechender gestalten könne, kommt hier eine einfache Lösung: eine Mapnik-Karte in Graustufen. Weiterhin gibt es eine no icons-Version mit nochmals reduzierter Grund- information. gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, weniger Farben (im Sinne von Helligkeitswerten) und eine geänderte Darstellung derjeniger Objekte, die sich mangels Farbe nicht mehr unterscheiden lassen (z.B. footway vs. bridleway = rot vs. grün). Dann hätte der Style einen echten Mehrwert sowohl für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. Grüße ant Hier ein Beispiel: Original-Mapnik: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=00B0F0FFF0FF00 S/W wie Mapnik: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=F0FFF0FFB0 S/W ohne Icons: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=F0FFF0FF0B Ein Komplettbeispiel mit hillshading und Bicycle-Layer: http://toolserver.org/~osm/styles/?zoom=15lat=47.6322lon=13.00511layers=F0FTF0TF0B Die Tiles findet ihr hier, bitte probiert es mit euren Karten aus: http://toolserver.org/tiles/bw-mapnik/13/4400/2686.png http://toolserver.org/tiles/bw-noicons/13/4400/2686.png Viele Grüße, Kay Drangmeister ___ 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] AIO - Routing über Fähren
Am 03.11.2010 20:47, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:43 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Ansatzweise korrekt. Problem: Jetzt müssen die Wege rekonstruiert werden. Die beteiligten OSM-Ids der Wege kennen wir aus der Relation. Allerdings kann es passieren, dass der Segmentierungsprozess diese Wege zerhackstückt hat. Die OSM-Id ist also in einer Routing-Topologie niemals eindeutig! Gruß, Carsten Gruß 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] bereits über 150 TeilnehmerInnen habe n beim OSM-Fragebogen mitgemacht
Am 03.11.2010 11:38, schrieb Marco Lechner - FOSSGIS e.V.: http://geeste.geographie.uni-freiburg.de/OSMmaps/ Am 03.11.2010 19:01, Stefan Sandrock: ... angeschaut - aber ausser, dass der screen immer grüner wurde, ist visuell nix passiert .. mmh. ne kleiner tipp wäre nett. thx s Zoomen :) Musste bei mir auch erst mit den Kartenbedienelementen oben links zoomen, damit die Gebiete erschienen. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Élisée Reclus wrote: Ich frage mich wo der Sinn sein sollte so etwas in der OSM-Datenbank zu speichern. Falls jemand z.B. eine Webseite mit einer Übersicht der Dead Drops betreiben will, müsste er eine eigene OSM-Datenbank + Mapnik betreiben, wenn ich nicht irre. Falsch. Ein etwas besserer Webspace reicht aus. Tiles kann man direkt von openstreetmap.org nehmen. Der Rest ist ein Layer, der mit XAPI erstellt werden kann. Sinnvoll wäre dann noch ein Cache der relevanten Daten auf dem eigenen Server, denn XAPI ist immer mal wieder weg. Und er könnte sich nicht mal auf die Konsistenz der Informationen zu den Dead Drops verlassen. (Benutzt auch jeder die vorgeschlagene Syntax?) Derjenige, der die Daten braucht, könnte die für ihn relevante Info ggf. selber berichtigen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 03.11.2010 20:59, schrieb Carsten Moeller: Am 03.11.2010 20:47, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 20:43 schrieb Carsten Moellercmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Ansatzweise korrekt. Problem: Jetzt müssen die Wege rekonstruiert werden. Die beteiligten OSM-Ids der Wege kennen wir aus der Relation. Allerdings kann es passieren, dass der Segmentierungsprozess diese Wege zerhackstückt hat. Die OSM-Id ist also in einer Routing-Topologie niemals eindeutig! Zusatz: Zugegeben, auch das ließe sich noch in den Griff bekommen. Aber es wird doch hier ersichtlich, dass ein einfaches Tag ala service=wichtig die komplette Kuh mit einer einfachen, pragmatischen Aussage vom Eis kriegt. Gruß, Carsten Gruß 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tags für Wüstengebiete
Hallo, gibt es schon tags für Landschaften in der Wüste (z. B. Sahara). Für Dünen (Erg) habe ich in den Map Features nur natural=sand und für Stein-Geröll-Gebiete (Hamada) nur natural=stone gefunden. Was kann man für Gebiete mit vulkanischen Gestein (Asche) benutzen? natural=vulcano bezeichnet wohl eher nur den Vulkan und nicht die umliegenden Lava- und Aschegebiete. MfG Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sesamstrasse wird gerade gemappt ;)
http://www.openstreetmap.org/?lat=-40.3181lon=-9.9353zoom=12layers=O Jacques ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Was passiert bei splitten oder ändern eines node/way/relation mit der ID?
Hallo, ich finde leider im Wiki nichts zu der Frage. Was passiert wenn ich eine/n Node/Way/Relation ändere oder aufteile mit der ID davon? Bei nodes dürfte der Fall unproblematisch sein, da man ihn nicht teilen kann, sodass Bedarf für eine neue ID besteht. Unklar ist mir jedoch was bei löschen eines nodes mit den ways und relations passiert die auf ihn Verweisen? Ebenso ist mir unklar was passiert, wenn ich einen Way z.B. weil ich für einen Teil des Ways ein lanes=4 eintragen möchte und für den anderen Teil nicht. Dann werden aus einem Way zwei. Was passiert hier mit den relations die auf den Way verweisen und behält ein Teil die alte ID oder bekommen beide eine neue? Danke Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für Wüstengebiete
Hallo Dieter, gibt es schon tags für Landschaften in der Wüste (z. B. Sahara). so eine Einteilung habe ich noch nicht gesehen - man könnte mal die tags der Wüstenländer durchforsten: http://tagwatch.stoecker.eu/world.html es gibt (nur) natural = scree, sand, mud, rocks, ... Für Dünen (Erg) habe ich in den Map Features nur natural=sand und =beach ... :) M.E. könnte ein Dünenbegriff eingeführt werden natural=dune ggf. noch unterscheiden natural=inlanddune oder natural=seadune und für Stein-Geröll-Gebiete (Hamada) nur natural=stone gefunden. für (Geröll), Schuttflächen, ggf. Blockhalden natural=scree http://wiki.openstreetmap.org/wiki/Tag:natural%3Dscree und als Zusatztag das Material: surface=sand surface=lava ... Material-Key gibt es glaube ich nicht(?) (surface ist m.E. zu oberflächlich) Was kann man für Gebiete mit vulkanischen Gestein (Asche) benutzen? natural=vulcano bezeichnet wohl eher nur den Vulkan und nicht die umliegenden Lava- und Aschegebiete. feine pudrige Sedimente wie Asche oder Schluff/Flysch vielleicht ein natural= oder surface=slag? + surface=* sonst noch: natural=steppe wenn genutzt würde ich landuse=steppe landuse=savanna ggf. auch dominierende Pflanzennamen name=Birke genus=Betula species=pubescense Trocken-Bachbett waterway=temporary (diese führen selten, alle paar Jahre mal Wasser. Das kann man an Treibselhaufen sehen) (hist.) trockenes Flussbett (in Wüsten) waterway=wadi viele Grüße, t. ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was passiert bei splitten oder ändern ei nes node/way/relation mit der ID?
Hallo, wenn du einen Weg teilst behält ein Stück die alte ID und das andere Stück bekommt eine neue ID zugewiesen. Relationen kann man in dem Sinne nicht teilen, da es sowas wie ein Eimer ist, in dem bestimmte Ways und/oder Nodes drin sind. Man kann aber einen zweiten Eimer nehmen und den Inhalt verteilen. Neuer Eimer=neue ID Wenn du einen Node löschst, wird dieser auch in dem Way gelöscht. Die ID des Ways bleibt davon unberührt. Sind alle Nodes eines Ways gelöscht, sollte der Editor auch den Weg selber löschen. Viele Grüße aighes -- View this message in context: http://gis.638310.n2.nabble.com/Was-passiert-bei-splitten-oder-andern-eines-node-way-relation-mit-der-ID-tp5703416p5703451.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] Was passiert bei splitten oder ändern ei nes node/way/relation mit der ID?
Tom Müller-2 wrote: Unklar ist mir jedoch was bei löschen eines nodes mit den ways und relations passiert die auf ihn Verweisen? nix, die verweisen nur halt nicht mehr auf den node - wie denn auch? Ebenso ist mir unklar was passiert, wenn ich einen Way z.B. weil ich für einen Teil des Ways ein lanes=4 eintragen möchte und für den anderen Teil nicht. Dann werden aus einem Way zwei. Was passiert hier mit den relations die auf den Way verweisen und behält ein Teil die alte ID oder bekommen beide eine neue? Es wird a) ein neuer node angelegt, b) ein neuer way mit allen eigenschaften des ursprung-weges beide wege sind danach in allen relationen drin, in denen das original war. danach kannst du den neuen weg anpassen. gruss walter - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/Was-passiert-bei-splitten-oder-andern-eines-node-way-relation-mit-der-ID-tp5703416p5703456.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] Tags für Dünen
Am 03.11.2010 23:23, tshrub: Für Dünen (Erg) habe ich in den Map Features nur natural=sand und =beach ... :) M.E. könnte ein Dünenbegriff eingeführt werden natural=dune ggf. noch unterscheiden natural=inlanddune oder natural=seadune Dünen selbst würde ich nicht versuchen zu taggen, da sie häufig nicht all zu stationär sind. Dünengebiete mit natural=dune zu bezeichnen finde ich nicht unbedingt daneben, problematisch sehe ich nur die große Überschneidung mit natural=sand - Eine Lösung habe ich aber nicht parat. Die Abgrenzung ist wohl einfach etwas unscharf. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was passiert bei splitten oder ändern ei nes node/way/relation mit der ID?
Am 03.11.2010 23:28, schrieb Walter Nordmann: beide wege sind danach in allen relationen drin, in denen das original war. und was passiert z.B. bei den restrictions? Werden dann z.B. zwei member mit role=to angelegt? Ist das alles Sache des Editors? Oder prüft die API z.B. auch, ob alle ways auf die eine relation verweist vorhanden sind? Kann man das Verhalten irgendwo nachlesen? Ist das dokumentiert? Oder ist das nur learning by doing-Wissen? Danke Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tags für gesprengte Häuser?
Angesichts der Dünen: Wie tagt man Ansammlungen von Betonteilen, wenn z.B. 5-stöckige Plattenbauten gesprengt, aber seit 5 Jahren nicht abtransportiert wurden? Sind das Dünen aus Beton? Oder basted buildings? Oder doch nur Brownfields? Beispiel: http://www.addicks.net/gallery/osm/DSCF3173 (ehemalis baugleiches Gebäude direkt daneben: http://www.addicks.net/gallery/GeoCaching/DSCF3208 ) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Moin, ich hatte in den letzten Tagen sehr wenig Zeit und antworte daher erst so spät. Am 31.10.2010 09:19, schrieb Jochen Topf: On Sat, Oct 30, 2010 at 10:49:31PM +0200, Stephan Wolff wrote: Dieses Verfahren funktioniert recht gut, wenn man neue Tags einführt um bislang nicht erfasste Objekte oder Eigenschaften zu beschreiben. Das Verfahren funktioniert nicht, wenn man etablierte Tags vor einer Umdeutung schützen will (z.B. Verwendung von natural=beach für Sandbunker auf dem Golfplatz) oder mehrere inkompatible Definitionen hat, die sich in den Daten nicht unterscheiden lassen (z.B. width-Tag für Straßen). Also das mit dem Sandbunker auf dem Golfplatz, der als natural=beach getagged ist, lassen wir mal weg. Das ist kein echtes Problem. Die paar Stellen, wo es das auf der Welt gibt, sind ein Witz. Ja, das kein wirklich bedeutendes Problem. Solange das Tag nur zum Erstellen von Karten benutzt wird, ist es irrelevant. Falls jemand eine Anwendung mit OSM-Daten erstellen will, die den Weg zum nächsten Strand ermittelt, wird er merken, dass in einigen Gegenden die Routen zum Golfplatz führen. Leider gibt es in OSM viele solcher kleiner Probleme. Beim width-Tag für Straßen sehe ich das Problem schon eher. Vielleicht tue ich da jemandem Unrecht, aber ich habe bisher keine Anwendunge gesehen, die diese Daten auch nutzen. Und solange die keiner nutzt, ist es eben nicht ganz klar, was es bedeutet. M. E. muss erst eine sinnvolle Definition erfolgen, bevor man die Daten danach erfassen und am Ende gemäß der Definition auswerten kann. Man kann nicht eine Anwendung schreiben und die Mapper aufzufordern, für diese Anwendung width als Fahrbahnbreite einzugeben. Sobald die Bedeutung von width klar ist, könnte man enge Straßen in der Karte schmaler zeichnen. Osmarender wertet width für Flüsse aus. Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann man es nicht nutzen. Letztlich ist jede Definition eines Tags, die sich *nicht* auf eine Nutzung stützt, völlig beliebig. Und vorallem auch immer wieder verfeinerbar. Selbst wenn wir die Straßenbreite genau definieren, z.B. als den Innenabstand zwischen den weißen Linien am Straßenrand, dann haben wir nur eine Teildefinition, weil es auch Straßen gibt, die keine weißen Linien am Rand haben. Eine Definition wird nicht perfekt sein. Gegenüber der jetzigen Situation wäre eine Beschreibung wie width bei Straßen: mittlere Breite der Fahrbahn als Innenabstand zwischen den weißen Linien am Straßenrand (sofern vorhanden) sonst als Abstand zwischen den Kantsteinen, sonst als Breite der Asphalt-, Beton- oder Schotterfläche. ein großer Fortschritt. Angenommen, das Gremium hätte die Macht, den ersten Absatz des Wikis aller in den Map_Features genannten Tags zu setzen und gegen Änderungen Dritter zu schützen. Falls das Gremium nach Abwägung der Vor- und Nachteile definiert width beschreibt bei Straßen die Breite der Fahrbahn, würden sich dann die Befürworter einer anderen Definition von OSM abwenden? Wenn ich wirklich davon ausgehen kann, dass das Gremium bessere Entscheidungen trifft als sich durch unsere sogenannte Anarchie herausbilden, dann wäre ich sofort für so ein Gremium. Aber das bezweifle ich doch sehr. Wo nehmen die ihre Kompetenz her? Warum wissen die besser, welche Definiton der Straßenbreite so wichtig ist, dass sie das width-Tag bekommt während die andere sich mit width_defined_by_stvo_1234 begnügen muss? Es ist doch nicht wichtig, welche Definition durch das Wort width und welche durch ein anderes Wort wie fullwidth in der Datenbank intern repräsentiert wird. Falls die Mapper die zweite Definition sinnvoller finden, setzten sie eben nur den Wert für fullwidth. Trotzdem sind Mehrdeutigkeiten damit vermieden. Es gibt sicherlich komplexe Objekte, die nicht einfach in OSM korrekt abzubilden sind. Aber wir scheitern schon an einfachen Dingen. Eine Tankstelle für Autos und eine für Boote kann in der Realität jedes Kind unterscheiden. Aus den OSM-Daten kann man den Unterschied oft nicht erkennen. Auch hier liegt das Problem wieder an dem ontologischen Ansatz. Wenn man sich überlegt, dass eine Tankstelle für Boote in erster Linie eigentlich eine Tankstelle ist, dann verwendet man das gleiche Tag. Wenn man sich beim Taggen aber gleich sagt: Ok, ich will hier eine Bootstankstelle taggen. Dafür gibts noch keinen Tag. Welchen nehme ich jetzt? Soll ich den normalen Tankstellentag nehmen? Hm, vielleicht nicht so gut, weil der ist bisher nur definiert für Auto-Tankstellen. Vielleicht hat da schon jemand eine Karte aller Tankstellen gemacht oder eine Routing-Software kann die nächste Tankstelle finden. Das könnte zu Verwirrungen führen. Also nehme ich da mal einen neuen Tag für. Dann wäre das Problem keines gewesen. Ein Mapper sagt: Ich möchte, dass meine Bootstankstelle in der Karte erscheint. In der
