Re: [Talk-at] Relationen
Andreas Labres schrieb: > ACK. Relationen sind überhaupt nicht dazu da, Sammelmengen zu bilden. Sowas > läßt > sich mit "alle, die tag xy soundso haben" genauso abbilden. Richtig, wenn man die Gruppierung über ein Tag erledigen kann und die Gruppe selbst keine weiteren Informationen besitzt, sind Relationen sinnlos. > Andere Verwendungen von Relationen, über die ich schon gestolpert bin und die > ich für zweifelhaft halte: > * alle Hausnummern-Objekte mit der Straße in eine Relation setzen. Sowas läßt > sich mit dem Karlsruhe Schema wunderbar (und ohne Relation ;) abbilden. Das ist aber was anderes -- ein Straßenname ist nicht eindeutig, man kann also nicht einfach alle Objekte mit gleichem Straßennamenstag zusammenfassen. Hier wird dann als Kriterium Tag+Entfernung verwendet, was schon deutlich aufwendiger ist als der oben beschriebene allgemeine Fall. Man beachte auch, dass manche Fehlerquellen durch die Aufnahme der Entfernung in Randfällen unvermeidbar werden -- wenn ich z.B. einen Kartenausschnitt herunterlade, in dem zwar Hausnummern einer Straße, aber nicht die Straße selber drin sind, werden die Hausnummern an die nächste gleichnamige Straße geklebt. In der Praxis wird man die meisten solchen Fälle wohl per eigenmächtig definierter Maximalentfernung rauswerfen. Ist also handhabbar, trotzdem sollte das imo nicht mit den "Kategorien-Relations" in einen Topf geworfen werden. Tobias Knerr (Ich wohne so nah an Österreich dran, dass ich hier auch mitlese. ;-)) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Häufige Fehler...
Roland Spielhofer schrieb: > - Buildings, die einander berühren, haben oft nur drei Ränder, es muss > aber jedes building für sich ein geschlossener Linienzug sein. > [...] > - bei Parkplätzen direkt an Straßen anschließend muss auch straßenseitig > die Fläche mit einer Linie geschlossen werden, analog building. Wie groß ist der Anteil von JOSM-Schöpfungen unter diesen Fehlern? Das ist meiner Beobachtung nach nämlich zumindest teilweise ein JOSM-Interface-Problem: Nicht geschlossene Polygone mit Flächen werden trotzdem gefüllt gezeichnet (der Startknoten wird geradlinig mit dem Endknoten verbunden), so dass der Eindruck entsteht, die Fläche sei bereits korrekt gezeichnet. Vor allem dann, wenn der eine fehlende "Rand" durch etwas anderes, wie eine Straße oder andere Fläche, ergänzt wird. Ob Potlatch auf ähnliche Weise irreführend agiert, weiß ich nicht. Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Häufige Fehler...
> Norbert Wenzel wrote: >> Was genau ist das Problem an Buildings mit 3 Wänden und einer geteilten? >> Schafft er das nicht als Area aufzulösen oder wurde das nur als >> "unschön" eingestuft, obwohl es eh funktioniert? Das ist potentiell von Anwendung zu Anwendung verschieden. In manchen mag es "funktionieren", in anderen nicht. Es ist zumindest meines Wissens keine Situation, für die es ein definiertes Verhalten gäbe, die Anwendung kann also damit tun, was sie will (ganzes Objekt ignorieren, als Linie statt Fläche interpretieren, in irgendeiner Weise schließen). Wenn die Anwendung nicht für diesen Fall speziell robust erstellt wurde, können auch beliebige andere Fehler auftreten, selbst wenn die eigentliche Darstellung funktioniert -- etwa beim Hinzufügen von Icon oder Beschriftung, beim Berechnen von Flächen (JOSM-Measurement-Plugin ist z.B. betroffen) und so weiter. Auch die Darstellung wird definitiv nicht funktionieren, wenn das jeweilige Objekt auch als Linie vorkommen kann, was bei building zugegeben eher nicht der Fall ist. Roland Spielhofer schrieb: > Ich bin jetzt nicht der API-Kenner, aber bei einer area müssen Start- > und Endknoten ident sein - soweit ich weiß. Definition kennt vielleicht > das Wiki (?). Die Definition für "area" im Wiki ist "closed ways tagged with the appropriate keys are handled as areas" sowie "closed way is a way where the last and first node are identical"[1]. Tobias Knerr [1] http://wiki.openstreetmap.org/wiki/Data_Primitives#Area ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Bankomat im Spar
Florian Schweikert schrieb: > atm=yes > > scheint zwar das zu sein aber bei einem supermarkt auch nicht 100% passend. > > amenity=atm zum shop=supermarket wird vl den renderer verwirren > > wie würdet ihr das taggen? Meine Ansicht: Jedes Objekt einzeln, idealerweise sogar mit ungefährer Platzierung (bei dir wohl schwierig, aber bei Fahrkartenautomaten in Bahnhöfen o.ä. ohne weiteres möglich). Wenn Zugehörigkeit ausgedrückt werden soll -> Relation. Um "ist im Gebäude" auszudrücken ginge z.B. was wie http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings mit "contains"-Rolle. Die normalen Tags an einen einzigen Node/Way anzubringen halte ich für keine sinnvolle Lösung: Sie funktioniert ja doch nur, wenn die beiden Objekte zufällig unterschiedliche Keys haben, also braucht man für die anderen Sachen ohnehin eine andere Vorgehensweise. Dann kann man die andere auch gleich für alles nehmen und muss nur eine unterstützen. Ganz zu schweigen von Problemen mit Zusatztags (wozu gehören die dann?). Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gebäude Eingang eintragen
adry schrieb: > http://wiki.openstreetmap.org/wiki/Proposed_features/building_entrance > > ein node auf dem building polygon wird mit building=entrance getagged > ist aber bisher nur ein proposed feature Das Proposal widerspricht sich selbst (im Kasten steht "amenity=building_entrance"), aber das lässt sich sicher beheben, wenn klar ist, was gewollt ist. "building=entrance" hat das Problem, dass inzwischen üblich ist, als Wert von Building die Art des Gebäudes anzugeben, nach diesem Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/building was auch ziemlich verbreitet ist: http://tagwatch.stoecker.eu/Europe/En/keystats_building.html Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] maxspeed urban
Günther Zin. schrieb: > zum Jahresbeginn gab's da mal eine Diskussion zu "maxspeed=DE:urban" auf > der deutschen Liste. Ja, zu dem Thema gabs schon öfter Diskussionen, und laut einem Forum-Thread auch schon Edit-Wars (weil man nun mal nicht gleichzeitig "DE:urban" und "50" als Wert von maxspeed setzen kann...). Ich würde daher empfehlen, euch lieber an euren Nachbarn im Süden zu orientieren und das in Italien verbreitete source:maxspeed = XX:urban/rural [1] zu verwenden. Das vermeidet Konflikte und hat keine mir bekannten praktischen Nachteile. [1] http://wiki.openstreetmap.org/wiki/Key:source:maxspeed Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] GeoImage.at - Deutsche Gebiete
Hallo Nachbarn, man hört ja schon viel von eurer neuen Luftbildquelle. :) Darum hab ich sie mir natürlich auch mal angeschaut und dabei bemerkt, dass die Bilder recht großzügig zugeschnitten sind. Sprich: Es sind auch kleinere Gebiete auf der deutschen Seite der Grenze mit abgedeckt. Gibt es irgendeinen Punkt in den Nutzungsbedingungen, der die Gebiete jenseits der Grenze von der Freigabe ausschließt, oder können wir uns hier über den "Beifang" freuen? Grüße, Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] GeoImage.at - Deutsche Gebiete
Am 13.10.2010 08:59, schrieb Norbert Wenzel: > Die Bilder gehören GeoImage.at und sind > als solche explizit auch für OSM gedacht. Egal von welchem Staatsgebiet > die Fotos jetzt sind. Sehr schön. Dann hoffe ich mal, dass die letzten Details bald geklärt sind, und das Luftbildmappen dann anfangen kann. > Ich weiß nicht wie weit die über die Grenze gehen, aber was verfügbar > ist, kann imo auch zum Abmalen verwendet werden. Sind quadratische Gebiete - und alle Zellen, die auch nur mit einer Ecke in österreichischem Gebiet liegen, sind komplett dabei. Damit lässt sich durchaus etwas anfangen. Als Passauer habe ich's z.B. ganz gut getroffen. Tobias Knerr ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehsteigbreiten
Am 15.04.2011 18:24, schrieb Manuela Schmidt: > footway:left: <2, <2.5, >2.5 > footway:right: <2, <2.5, >2.5 > footway:both: <2, <2.5, >2.5 > (left und right in Richtung der Linie)(jeweils in Metern) > > Grund für diese Einteilung war ein Datenset, das wir von der Stadt > Salzburg für diesen Zweck bekommen haben; dort werden die Gehwege in > diese Kategorien eingeteilt. Generell haben die <>Werte den Vorteil, > dass sie einfacher zu erfassen sind, weil Gehwege ja nicht überall > gleich breit sind. Für das Problem im Allgemeinen würde ich spontan neben width noch ein Tag wie width:min/max - nur als Beispiel - erlauben, das die Breite der schmalsten/breitesten Stelle des Objekts angibt. (Bei Gehsteigen ist natürlich vor allem die schmalste Stelle praktisch relevant.) Ich finde das weniger missverständlich als etwa ein <2.5, das man ja auch als "keine Stelle ist breiter als 2.5 m" lesen könnte. Durch die Möglichkeit, beliebige Werte zu setzen, müsste auch keine Einteilung vorgegeben werden, sondern sie könnte dem jeweiligen Anwendungsfall überlassen bleiben. Für euren konkreten Fall ist das natürlich nicht ganz passend, da ihr ja (anders als wohl der Mapper vor Ort) die Breite der schmalsten Stelle gar nicht immer kennt. Manchmal wisst ihr ja nur, dass der Wert, den man für width:min setzen müsste, kleiner als 2m ist. Ich denke aber, dass man keine Lösung finden wird, die für euren und alle anderen bereits existierenden Datensätze genau passen kann. Wenn man eine Kategorie "<2m" unterstützt, hat man dann beim nächsten Import ein Problem, der nur "<1.8m" kennt. (Nebenbei bemerkt: Ich empfinde es allgemein nicht als ideale Lösung, Informationen über einen Gehsteig, die über die bloße Existenz hinausgehen, als Attribute an einem Haupt-Way zu erfassen. Daher auch das width:min=... in dem Beispiel oben. Ansonsten stünde dort natürlich footway:left:width:min=... o.ä.) Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] JOSM und CT-Hakerl
Am 09.08.2011 23:55, schrieb liberalerhuman...@gmx-topmail.de: > Angeblich steht dieses Häkchen dafür, dass du deine Bearbeitungen als unter > der Public Domain stehend betrachtest. Das graue Häkchen steht meines Wissens dafür, dass derjenige seinen Account erst angelegt hat, als man schon bei der Anmeldung zustimmen musste, also automatisch zugestimmt hat. Ob PD ausgewählt wurde, spielt für die Farbe des Häkchens keine Rolle. Gruß, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gehsteige (war: das 'new barrier types' proposal)
Am 04.09.2011 15:41, schrieb Boris Cornet: > Ich frage mich schon, warum man den komplizierten Weg gehen sollte, > wenn es einfach doch auch geht: > > highway=residential > sideway=left > cycleway:left=lane > cycleway:right=track > > Beschreibt eine Straße eindeutig, und benötigt nur eine Linie. Dein Beispiel drückt die Existenz von Fuß- und Radspuren sowie ihre Lage relativ zur Autofahrbahn aus. Wenn das alles wäre, was wir jemals benötigen, wären Tags natürlich eine geeignete Lösung. Aber was, wenn man eben doch zusätzliche Details hinzufügen will? Schon bei der Lage von Fuß- und Radweg zueinander hört es mit solchen Tags auf: Das kann man nur noch auf Grundlage seines Wissens über die lokalen Gepflogenheiten im Straßenbau entscheiden. Und wie trägst du ein Hindernis (z.B. Poller) ein, das sich nicht auf der Autofahrbahn, sondern auf dem Gehsteig befindet? > Nun eine Querungsstelle (ohne Querstraße): > - Im ersten Fall ein einzelner Knoten mit highway=crossing. > - Im zweiten Fall der eben erwähnte Knoten und zusätzlich ein neuer Weg. Und an dem neuen Weg kann man gleich noch nützliche Informationen wie einen nur einseitig abgesenkten Bordstein unterbringen, für die ein einziger Knoten weniger geeignet wäre. > Die Komplexität steigt also mit der dritten Potenz, ohne dass dem irgend > ein Informationsgewinn gegenüber stünde. In deinen Beispielen gibt es keinen Informationsgewinn, weil das, was man mit primitiven Tags nicht ausdrücken kann, gar nicht erst vorkommt. Es gibt natürlich große ungelöste praktische Probleme mit Linienbündeln. Es ist aber keine Lösung, die Informationen, die man ohne sie derzeit nicht gescheit mappen kann, zu ignorieren oder für irrelevant zu erklären. Offenbar gibt es ja Leute, die sich dafür interessieren. Gruß, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Öffnungszeiten und Umstellung auf OSM
Am 03.05.2012 17:31, schrieb Marijan Writz: > 1.) Wie führt man am einfachsten so einen Wechsel durch - das heißt > Kartenwechsel von GoogleMaps auf OSM? Es gibt dazu einige Hinweise auf http://switch2osm.org/ Ich habe auf der Website jetzt keine besonders komplexen Karten gesehen, eine Karte mit ein paar Markern sollte sich nach kurzem Experimentieren auch mit OpenLayers oder Leaflet umsetzen lassen. Die Apps kenne ich nicht. Die größere Herausforderung wäre aber sicher das Betreiben eines eigenen Servers für die Kacheln. Oder ist geplant, das an einen externen Dienstleister zu vergeben bzw. einen kostenlosen Tile-Server zu verwenden? > 2.) Umgekehrt habe ich auch nachgefragt, ob man die Öffnungszeiten in OSM > eintragen könnte. Ein einfaches Kopieren/Abschreiben ist nicht erlaubt. > Jedoch gäbe es die Möglichkeit einen Link auf die Öffnungszeiten des > entsprechenden Geschäfts zu setzen. Damit hätte die Website weiterhin > Besucher und könnte durch diese Werbeeinnahmen generieren. Und für uns heißt > das eine zusätzliche Information, die man weiterverwenden könte. > > Was meint ihr dazu - ist die Integration eines Links zu Öffnungszeiten in > unserem Sinne bzw. im Sinne von OSM? Im Sinne von OSM ist es, Öffnungszeiten unter einer freien Lizenz zu sammeln. Das tun wir derzeit durch das Eintragen der Öffnungszeiten direkt in OpenStreetMap. Nicht im Sinne von OSM ist es, proprietäre Datensammlungen zu fördern. Wenn eine solche Datensammlung zudem Crowdsourcing nutzt - wie es als bekanntes Beispiel etwa Google Map Maker und eben anscheinend auch öffnungszeitenbuch.de tut - konkurriert sie sogar mit freien Projekten wie uns um Beiträge. Für OSM fände ich solche Links also strategisch nicht sehr vorteilhaft. Auch unseren Nutzern täten wir damit wahrscheinlich keinen großen Gefallen. Im Gegensatz zu maschinenlesbaren Öffnungszeiten in der OSM-Datenbank kann ein Link z.B. nicht offline verwendet werden und nicht für Filter wie "route mich zur nächsten noch offenen Bäckerei" dienen. Gruß, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Open Time Table (war: Öffnungszeiten)
Am 04.05.2012 22:38, schrieb Rainer Fügenstein: > wie wärs mit einem "open time table" projekt? fahrpläne von der > community gewartet in einer freien datenbank. Es wäre schon cool, eine solche Datenbank zu haben. Allerdings bist du nicht der erste mit der Idee für so ein Projekt, SteveC hat's auch schon versucht. Ist leider nichts daraus geworden: http://wiki.openstreetmap.org/wiki/Transiki Ich weiß auch nicht, wie groß das Erfolgspotential wirklich wäre. Denn ich kenne zwar die Situation in Österreich nicht genau, aber die Fahrplan-Apps der Deutschen Bahn z.B. sind schon so gut (und kennen vielerorts auch Nahverkehrsmittel wie Busse und U-Bahnen), dass derzeit wahrscheinlich wenig Leidensdruck besteht. Will's dir natürlich nicht ausreden, wenn du es trotzdem probieren möchtest. Gruß, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Obstallmende
Am 19.08.2012 08:49, schrieb Martin Vonwald (Imagic): > Anders gesagt: solange wir in OSM ganz normale Bäume zu tausenden eintragen > haben auch frei zugängliche Obstbäume ihre Existenzberechtigung. Vor allem da > diese Information für Normalsterbliche einen deutlichen Mehrwert hat > gegenüber den "normalen" Bäumen die wir z.B. in Wien überall auf der Karte > sehen. Ja, aber halt als "natural=tree + species=malus domestica". Nicht als "schmackhaft, auch gut zum Trocknen" oder "Unser Garten - Haben ab Mitte Ende September Anfang Oktober von 2 Bäumen Äpfel". Der Clou bei Mundraub ist doch, dass es Empfehlungen sind. Und damit wie andere subjektive Sammlungen (z.B. "die schönsten Wanderwege Österreichs") oder Wertungen (z.B. Restaurant-Bewertungen) eben doch in einem externen Projekt besser aufgehoben. Gruß Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] WP-Tags an Nachbildungen im Minimundus
Am 11.04.2013 11:39, schrieb Holger Schöner: > Die Wikipedia-Links dienen doch eigentlich dem Zweck, zu einem in OSM > gemappten Objekt weitere Informationen abrufen zu können!? Sie werden seit längerem auch als eine Art ID zur Verknüpfung mit einem anderen freien Projekt verwendet, nicht bloß als "Einbahn"-Links von OSM nach Wikipedia. Mittlerweile verlassen sich die Karteneinblendungen in zahlreichen Wikipedia-Ausgaben darauf. > Dagegen ist nichts zu sagen, aber es lässt sich daraus nicht ableiten, > dass nur vom Ort der einem Artikel entspricht auf diesen Artikel > verlinkt werden darf. Aber aus der Dokumentation zu Key:wikipedia im Wiki (zumindest der maßgeblichen englischen Version) lässt sich das durchaus ableiten. Dort heißt es: "only provide links to articles which are 'about the feature'.", und als Beispiel für etwas, das man nicht tun soll, steht dort "a link from a bus depot to the company that operates it". Angegeben soll ein Wikipedia-Link also dann, wenn er konkret über das getaggte Objekt ist (also _diese spezielle_ Straße etc.), nicht über ein Thema, das damit in irgendeiner Weise zu tun hat. > Falls die zusätzlichen Links technische Probleme machen, sollte > vielleicht über alternative Tags oder -Ergänzungen für die Verortung der > Wikipedia Artikel nachgedacht werden? Derzeitiger auf Key:wikipedia im Wiki dokumentierter Vorschlag ist, Schlüsselvarianten wie * wikipedia:name - Wikipedia-Artikel über den Namensgeber * wikipedia:operator - Wikipedia-Artikel über den Betreiber * wikipedia:architect - Wikipedia-Artikel über den Architekten * wikipedia:subject - Wikipedia-Artikel über das von einer Statue o.ä. dargestellte Objekt zu verwenden. Letzteres - wikipedia:subject - klingt nach einer geeigneten Lösung für das hier diskutierte Problem. Gruß, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] JOSM-Plugin "turnlanes"
Am 09.10.2013 16:18, schrieb Christian Aigner | caigner: > Ich bin gerade über ein JOSM-Plugin gestolpert, das geradezu genial ist: > turnlanes Dieses JOSM-Plugin ist von der Benutzerschnittstelle schon sehr ansprechend. Es hat nur einen großen Nachteil: Es produziert Daten nicht nach dem akzeptierten Lanes-Tagschema¹, sondern über ein selbsterfundenes relationsbasierendes Konzept. Damit sind die Daten natürlich völlig inkompatibel mit allen Anwendungen, die auf *:lanes setzen. > Statt die Straße in zwei oder mehrere Fahrbahnen aufzusplitten, werden > lanes spezifiziert und die entsprechenden Abbiegeregeln gesetzt. Das ist ja auch bei *:lanes so. Man könnte zwar durchaus einige Ideen von dem Turnlanes-Relationsschema übernehmen, aber zwei komplett verschiedene Schemata nebeneinander wären keine gute Situation. Viele Grüße Tobias [1] http://wiki.openstreetmap.org/wiki/Lanes ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 25.02.2014 09:56, schrieb Martin Raifer: > Ich sehe auch nicht, was denn gegen das Gehsteig-Mapping spricht? Ich habe diese Beispiele zwar bereits in einem OSM-Blogkommentar verwendet, aber wiederhole sie hier gern: Wie soll der Router bei getrennt gemappten Gehsteigen noch wissen, dass ich eine verkehrsarme Straße an jedem Punkt überqueren kann? Wie soll er "folgen sie der X-Straße auf der rechten Seite" ansagen können? Wie soll der Renderer - 2D oder 3D - lückenlos an die Straße anschließende Gehsteige noch als solche darstellen können? Für diese Anwendungsfälle ist das Attribut-Mapping nicht nur "gut genug", sondern sogar besser. Meiner Meinung nach sollte geklärt sein, wie die o.g. Anwendungsfälle weiterhin funktionieren können, bevor man Separat-Mapping in Erwägung zieht. Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 25.02.2014 21:12, schrieb Holger Schöner: > Am 25.02.2014 20:32, schrieb Tobias Knerr: >> Wie soll der Router bei getrennt gemappten Gehsteigen noch wissen, dass >> ich eine verkehrsarme Straße an jedem Punkt überqueren kann? Wie soll er >> "folgen sie der X-Straße auf der rechten Seite" ansagen können? > > Das sollte bei geeigneter Vorverarbeitung (bei vermutlich etwas mehr > Aufwand als die Auswertung von sidewalk=... tags) durch die > Kennzeichnung der Gehsteige mit footway=sidewalk eigentlich für Router > kein Problem sein. Die Frage ist zwar, welche das ggf. jetzt schon > verwenden, aber prinzipiell sehe ich da kein Problem. Eine solche Vorverarbeitung ist eine sehr komplexe Aufgabe, das ist nur dann "kein Problem" wenn man es nicht selber machen muss. ;) Es kann dabei auch zu Uneindeutigkeiten kommen, vor allem bei den von dir gern als Beispiel genannten komplexeren Kreuzungssituationen. Da ist es meiner Einschätzung nach deutlich leichter, z.B. Rollstuhlrouting auf Attribut-Basis zu betreiben. Trotzdem nennst du das als eines deiner Argumente für separate Ways. Dasselbe gilt übrigens für die von dir vorgeschlagene Vorverarbeitung für Renderer. Sie ist in der Theorie möglich, aber eben so viel Aufwand, dass ich es nicht für realistisch halte, dass Renderer dies tun werden. >> Wie soll >> der Renderer - 2D oder 3D - lückenlos an die Straße anschließende >> Gehsteige noch als solche darstellen können? > > Das mag schon eher ein Problem sein, da der Renderer dafür auch die > jeweils richtige Straßenbreite kennen müsste (und zwar ziemlich genau). > Das wird sich vermutlich erst lösen lassen, wenn Straßen und Gehsteige > flächig gemappt werden (wird das einmal kommen?) ;-) Ich finde aber, > dieser Nachteil tritt gegenüber den Vorteilen in den Hintergrund. Ich halte die Vorteile nicht für stark genug, um die Nachteile auszugleichen. Der Vorteil der Intuition beim Mapping (deine Punkte 1 und 3) verschwindet schnell, wenn man dem Editor eine Straßenlayout-Ansicht für die Spur- und Gehsteig-Tags spendiert. Das hilft dann auch gleich bei den Spuren - man bedenke schließlich, dass wir uns auch dort für eine Attributslösung entschieden haben statt für getrennte Ways. Was nicht von der Hand zu weisen ist, ist die höhere Obergrenze bei der möglichen Präszision. Allerdings würde ich hier eine Lösung bevorzugen, bei der das Attribut an der Straße nicht ersetzt, sondern nur ergänzt wird - so dass nur Anwendungen, die die Präzision auch wirklich brauchen, auf die detailliertere Darstellung zugreifen müssen. Zum Vergleich: Bei den vorgeschlagenen Lösungen zum Eintragen von Straßenflächen lassen wir schließlich den zentralen Way nicht wegfallen, sondern ergänzen ihm um eine Fläche mit neu erfundenem Tag. Dafür habe ich noch keine fertige Lösung in der Schublade (und es ist nicht damit getan, einfach beides gleichzeitig zu verwenden), aber es wäre auf jeden Fall eine angenehmere Lösung, als diskutieren zu müssen, welches von mehreren praktischen Anwendungsszenarien wir opfern wollen. >> Für diese Anwendungsfälle ist das Attribut-Mapping nicht nur "gut >> genug", sondern sogar besser. Meiner Meinung nach sollte geklärt sein, >> wie die o.g. Anwendungsfälle weiterhin funktionieren können, bevor man >> Separat-Mapping in Erwägung zieht. > > Ich hoffe, dass meine Vorschläge dafür eine Anregung sein können! Deine Vorschläge sind in der Tat nicht schlecht, aber sie zeigen m.E. auch, dass das Aufbereiten von separaten Ways - auch dort, wo es prinzipiell möglich ist - mit komplexen, fehleranfälligen und rechenintensiven Operationen verbunden ist. Daher bin ich weiter nicht überzeugt, dass Separatmapping der richtige Weg ist. Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 25.02.2014 22:26, schrieb Michael Maier: > Das große Problem mit Attributen ist das Routen links/rechts entlang der > Straße - ein Router der das kann müsste erst einmal geschrieben werden. Ja, aber diese Funktionalität könnte für besseres Fußgänger-Routing zweitverwertet werden (das macht sie aus Sicht der Community insgesamt "preiswerter" und es produziert Extra-Motivation für Mapper zur Pflege solcher Daten). Sie ist auch konzeptionell nicht besonders komplex - ein Straßenstück, das auf beiden Seiten nutzbare Gehwege hat, muss dazu im Routing-Graphen schlicht zu zwei parallelen Kanten und Knoten werden. Rollstuhltaugliche Übergänge verbinden dann Knoten von beiden Straßenseiten miteinander. > Das herausmessen der Radien will ich dem durchschnittlichen iD-Nutzer > nicht zumuten - es ist vil einfacher den Gehweg extra einzuzeichnen! Du könntest sie auch die Straßenfläche (inkl. Gehsteigfläche) einzeichnen lassen. Diese Information ließe sich zusätzlich z.B. für detailliertes Rendering auf Zoom 19+ nutzen und produziert ebenfalls Information über die Radien der Gehsteige - unter der realistischen Annahme, dass diese außen an der Straße sind. > Das lanes-tagging bereitete mir schon Kopfzerbrechen genug - bevor's den > Stil von Martin Vonwald gab war das ein Horror, sich da nicht zu vertippen. Und genau solche Editing-Tools können auch in Zukunft das Mapping von Spur- und Gehsteigattributen vereinfachen. Da ist noch viel möglich. > Wir werden sie da als eigene Wege mappen, wo Kreuzungen vorkommen, und > es für Leute die mehr als 3cm Gehsteigkante nicht schaffen kompliziert > wird. Warum die Information über die Gehsteigkanten nicht an die Überwege setzen? Nicht jede Routinggraph-Kante muss im früheren Leben OSM-Way gewesen sein. Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Einladung nach Passau
Hallo miteinander, unser schönes Städtchen Passau liegt am Zusammenfluss von Donau und Inn, direkt an der deutsch-österreichischen Grenze. Traditionell findet bei uns zweimal im Jahr ein größeres, überregionales Mappertreffen statt. Daran nehmen bisher allerdings fast nur deutsche Mapper teil. Das möchten wir gerne ändern! Daher laden wir alle österreichischen Mapper und OSM-Interessierten dazu ein, uns in Passau zu besuchen. Der Termin: Montag, 14. Juli, ab 19 Uhr Cafe Kowalski, Karte: http://osm.org/go/0JODGPYF-?m= Mit Fragen zur Anreise, Parkplatzsorgen und anderen logistischen Problemen sind wir gerne behilflich! Viele Grüße Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Erinnerung: Überregionales Treffen in Passau
Nicht vergessen! Morgen findet in Passau das überregionale Mappertreffen statt. Noch einmal der Termin: Montag, 14. Juli, ab 19 Uhr Cafe Kowalski, Karte: http://osm.org/go/0JODGPYF-?m= Das Angebot zur Hilfe bei Parkplatzsorgen, Fragen zur Anreise und weiteren Schwierigkeiten gilt weiterhin! Viele Grüße Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging der abgeholzten Waldflächen
Am 26.04.2015 17:09, schrieb Stefan Tauner:
> Ja, das folgt aus der Definition von landuse=forest, denn dieses
> Tagging bezeichnet ganz allgemein wirtschaftlich genutzte
> Waldgebiete... was auch abgeholzte Flächen miteinschließt.
Das stimmt so nicht (mehr). Früher stand landuse=forest tatsächlich für
die forstwirtschaftliche Nutzung, aber inzwischen heißt es einfach nur
noch "Wald" - mit allen daran hängenden Assoziationen. Die entsprechende
Änderung wurde vor Jahren durchgedrückt ("Wieso taggen wir die Wälder
denn zweimal als Wald?!?") und mit großflächigen Edits zementiert.
> Das Problem dabei ist, dass die Renderer das als dunkelgrüne Fläche
> darstellen und
> wir das alle mit "Wald" gleichsetzen
Das hängt aber damit zusammen, dass sich die Bedeutung des Tags
mittlerweile verändert hat. Wenn man die Situation wirklich bereinigen
will, dann muss man sich m.E. ein neues Tag suchen (landuse=forestry
oder so) und das dann konsequent dokumentieren und nutzen. Sonst wird
das Chaos nur noch größer.
Viele Grüße,
Tobias
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kleingartenvereine
Am 14.05.2015 17:46, schrieb Wolfgang Schreiter: > Dazu gibt es noch mehrere Beispiele, z.B. FF (Freiwillige Feuerwehr), VS > (Volksschule), HS (Hauptschule). Es stellt sich grundsätzlich die Frage, ob > solche Abkürzungen in Namen verwendet werden sollten. Die Frage wird generell beantwortet mit: Nein, Abkürzungen in Namen sollten vermieden werden. Steht jedenfalls seit langem so im Wiki. Nun kann man bei extrem gängigen Abkürzungen noch über die Sinnhaftigkeit streiten (z.B. Dr vs. Doktor), aber bei den hier diskutierten Beispielen würde ich mich klar an die Regel halten. Es ist generell für Software wesentlich einfacher einen Begriff abzukürzen als den Begriff aus einer Abkürzung zu rekonstruieren. HS beispielsweise wird ja auch für Hochschule, High School und Haltestelle verwendet. Ich wäre daher für die Verwendung der ausgeschriebenen Form, plus short_name mit der Abkürzung. Damit ist dann auch die Suche nach dem ausgeschriebenen "Kleingartenverein" erfolgreich, was momentan nicht der Fall ist. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Adressdaten BEV
Am 20.07.2015 15:07, schrieb Thomas Rupprecht: > Wie es aussieht hat das BEV jetzt auch die Adressdaten für Österreich > veröffentlicht. Ich bin noch im Kontakt mit dem BEV ob wir eine exlusiv > Nutzung bzw doppel Lizenzierung mit ODbL für die Verwaltungsgrenzen und > Adressdaten bekommen. Wenn irgendwie möglich würde ich darum bitten, keine Daten unter ODbL zu importieren. Das bringt nur diverse Probleme mit sich, u.a. bei zukünftigen Anpassungen unserer eigenen Lizenz. Eine Institution, die Daten unter ODbL veröffentlichen würde, lässt sich womöglich auch auf andere Regelungen ein, z.B.: * Namensnennung durch OSM, aber nicht bei unseren Datennutzern * einfach ein "darf für OSM verwendet werden", ohne Einschränkung auf eine Lizenz Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Filialen von Dayli und Schlecker
Am 20.02.2016 18:42, schrieb Friedrich Volkmann: > On 20.02.2016 14:27, Markus Mayr wrote: >> Dem "shop=vacant" stehe ich skeptisch gegenüber. > > Ich nicht. Wir mappen, was da ist. Ein leeres Verkaufslokal ist nicht > , sondern ein leeres Verkaufslokal. Ein leeres Verkauflokal ist aber kein Ort, wo man etwas kaufen kann, d.h. es erfüllt die Definition des shop-Schlüssels nicht. Da man für den shop-Schlüssel beliebig viele Werte erfinden kann, muss sich ein Auswerter darauf verlassen können, dass alle Werte diese Mindestanforderungen erfüllen. > Leerstehende Lokale sind noch vorhanden (daher shop=*), aber man kriegt dort > keine Kleidung (darum nicht shop=clothes). Sie sind vorhanden, aber sie sind kein Ort zum Einkaufen (shop=*). Wenn man sie taggen will, muss man also einen neuen Schlüssel erfinden, wie eben disused:shop. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] FOSSGIS 2017 - CfP endet HEUTE
Zur Erinnerung: *Heute* endet die Vortragseinreichung für die FOSSGIS-Konferenz 2017 in Passau. Verlängern können wir die Frist diesmal leider nicht, also reicht schnell noch eure Ideen ein! Besonders aus Österreich vermissen wir noch Einreichungen, zumal die Konferenz doch quasi in eurem Vorgarten stattfindet – also, gebt euch einen Ruck! ;) https://www.fossgis-konferenz.de/2017/callforpapers/ Falls euch die Zeit nicht mehr ganz reicht, stellt heute zumindest die Basisinfos ein. Am Abstract dürft ihr dann noch die nächsten Tage feilen. Wer schon eingereicht hat: Danke für den Beitrag, das Programmkommittee wird sich nach Einreichungsschluss an die Arbeit machen und das Programm zusammenstellen. Wir haben nach dem aktuellen Stand schon viele interessante Vortragseinreichungen. :) Nichtsdestotrotz würden wir uns noch über weitere Vorträge aus dem OSM-Umfeld freuen! Gruß, Tobias On 01.01.2017 21:16, Peter Barth wrote: Hallo zusammen, ich bumpe hier nochmal den Thread zur Erinnerung, da der 6. Januar keine Woche mehr entfernt ist und wir noch nicht genug Einreichungen haben. Frederik hat das auf talk-de vor kurzem schon mal geschrieben (https://lists.openstreetmap.org/pipermail/talk-de/2016-December/113735.html) Ganz so schlimm sieht es nicht mehr aus, aber es ist noch zu wenig und es hat doch sicher jeder von euch etwas interessantes zu erzählen! Also los, nachdenken, einreichen und dann auf zur FOSSGIS-Konferenz 2017 in Passau. Da Passau ja zudem fast in Österreich liegt, ist das für viele von euch ein Katzensprung und z.B. die Linzer können da ja schon fast einen Spaziergang draus machen ;-) Und wo wir schon dabei sind könntet ihr euch auch gleich noch für den OSM-Samstag im Wiki eintragen: https://wiki.openstreetmap.org/wiki/FOSSGIS_2017/OSM-Events Das erleichtert uns dann die Planung bzgl. Räumlichkeiten und Verpflegung. Der OSM-Sonntag in Salzburg war wirklich genial; ich kann euch nur empfehlen auch den OSM-Samstag in diesem Jahr nicht zu verpassen! Bei Fragen einfach hier oder direkt an mich oder an das Programmkomitee. Ich freue mich über eure Einreichungen, Peda Peter Barth schrieb: Hallo zusammen, wie ihr vielleicht schon mitbekommen habt, haben wir doch noch einen Austragungsort für die FOSSGIS-Konferenz 2017 gefunden! Und zwar freue ich mich besonders, dass es die Dreiflüssestadt Passau, die zugleich mein langjähriger Wohnort ist, geworden ist. Veranstaltet wird die Konferenz vom FOSSGIS e.V. (http://fossgis.de) und der OpenStreetMap-Community mit Unterstützung der Universität Passau (http://www.uni-passau.de). Im Jahr 2017 findet die FOSSGIS vom 22. bis 25. März an der Universität Passau statt. Anläßlich des Erfolges im letzen Jahr wird es übrigens auch dieses Jahr einen dedizierten OSM-Tag geben: Den OSM-Samstag am 25. März, für alle, die es unter der Woche noch nicht zur Konferenz schaffen oder noch mehr OSM wollen. Themen und Vorträge für diesen Tag werden wir gesondert über das Wiki planen, mehr dazu später. Für alle anderen Vorträge läuft der Call for Papers bis zum 06. Januar 2017! Wir suchen: Deine Idee, Dein Projekt, Deinen Erfahrungsbericht, Dein Thema. Genauer gesagt, suchen wir Vorträge für Einsteiger und Fortgeschrittene, die spannende Themen behandeln und anregende Diskussionen auslösen. Vorträge zum Thema freie Geodaten, zum Beispiel OpenStreetMap oder Open Data sind ebenso möglich wie Beiträge zu Lösungen mit freier Software aus dem Bereich WebGIS, Desktop GIS, Geodatenbanken, Location-Based Services, etc. Vorgesehen sind drei verschiedene Vortragsformate: Es gibt 20-minütige *Vorträge*, in denen man über sein Projekt berichten kann, ein Taggingschema oder Mappingpraktiken vorstellen kann oder auch einfach nur über die eigene Aktivität als Mapper und z.B. die verwendeten Werkzeuge sprechen kann. Die Themen bestimmt Ihr und wir freuen uns über eine große Vielfalt an Themen, da genau diese Vielfalt auch den Reiz unserer Konferenz ausmacht. Für eher kleinere Themen oder wenn ihr euch keinen vollen Vortrag zutraut gibt es auch die sogenannten *Lightning Talks*, das sind kurze Vorträge von maximal 5 Minuten. Und wenn ihr anderen gerne etwas beibringt und euch in einem Thema besonders gut auskennt, gibt es noch die *Workshops*. Sie sollen in 90 Minuten den Teilnemern einen Mix aus Theorie und Praxis vermitteln. Bei einer Workshop-Einreichung ist es wichtig, darauf zu achten, dass erreichbare Lernziele und notwendige Vorkenntnisse der Teilnehmer beschrieben sind. Vor allem aber stellen Workshops auch eine wichtige Einnahmequelle für den FOSSGIS e.V. dar, da die Teilnahme kostenpflichtig ist. Wenn ihr euch mit einem angedachten Workshop also nicht sicher seid, kontaktiert uns, wir helfen gern. Bitte reicht euren Abstract ab sofort bis zum 06. Januar 2017 ein. Eine Fristverlängerung ist wegen der ohnehin straffen Zeitplanung *nicht* vorgesehen. Weitere Einreichungsdetails findet ihr auf unserer Konferenzseite (https://www.fossgis-konferenz.de/2017/callfo
[Talk-at] OSM-Events auf der FOSSGIS 2017
Hallo zusammen, lang ist's ja nicht mehr hin bis zur FOSSGIS in Passau. Daher zunächst mal die Erinnerung: Denkt daran, euch unter http://fossgis-konferenz.de/2017/anmeldung/ anzumelden! Wie ihr vielleicht schon gehört habt, wird es auf der FOSSGIS dieses Jahr zwei OSM-spezifische Events geben, die auch unabhängig vom Rest der Konferenz besucht werden können: Am Nachmittag des dritten Konferenztages richten wir eine Mappingparty aus, bei der gemeinsam die Daten in der Passauer Altstadt verbessert werden. Der Tag darauf steht dann als "OSM-Samstag" komplett im Zeichen von OSM – das Programm wird im Stil einer Unkonferenz von euch selbst gestaltet. Damit wir diese OSM-Events besser planen können, wäre es schön, wenn ihr euch bei Interesse vorher auf den entsprechenden Wikiseiten eintragt: http://wiki.osm.org/FOSSGIS_2017/Mappingparty http://wiki.osm.org/FOSSGIS_2017/OSM-Samstag Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
