Re: [Talk-de] Mal wieder einiges in den Map Features erg änzt
Ulf Lamping wrote: An die bestehenden Einträge habe ich folgendes hinzugefügt: barrier=fence wood_fence (~1400) und wire_fence (~1200) Ja, aber eben 1400 barrier=wood_fence von einem einzigen Mapper. Ich sehe das nicht als Indiz dafür, dass sich dieses Tag durchgesetzt hat - und damit auch nicht als guten Grund, das in die Map Features zu befördern. Das wäre mir ja egal, wenn das Tag was taugen würde. Ich finde es aber eine ziemlich unsinnige Idee, ein Zusatzattribut (Material), das fast alle Anwendungen erst mal nicht interessieren wird, mit in den barrier-Wert zu packen. Oder wollen wir demnächst auch auf highway=pebblestone_footway umstellen? Tobias Knerr PS: Teste gerade dieses Nabble-ML-Webfrontend - ich hoffe, es funktioniert alles... -- View this message in context: http://n2.nabble.com/Mal-wieder-einiges-in-den-Map-Features-erganzt-tp4424438p4426474.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] Wege in einem Privatwald
Karl schrieb: Natürlich könnte ich die Wege jetzt löschen, aber irgendjemand wird sie irgendwann wieder einpflegen. Allerdings kann ich dem Waldeigentümer verstehen, seit die Wege in OSM stehen ist dort vermehrt Verkehr von Zweiräder (mit und ohne Motor), leider nicht nur auf den Wegen. Wie gehen wir mit solchen Wünschen um? Wenn die Wege korrekt als privat gekennzeichnet sind, sind wir als Datensammler meiner Ansicht nach nicht für die missbräuchliche Verwendung verantwortlich. Renderings, die bei solchen Wegen keine erkennbare Darstellung als privat vornehmen, könnte man allerdings sehr wohl kritisieren, das sollte auf einer für die Öffentlichkeit bestimmten Karte nicht sein. Für die Daten an sich gilt aber in jedem Fall: Die Realität wird abgebildet. Das ist die einzige saubere Trennlinie, die man ziehen kann. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ergebnis Workshop Linienbündel
Sascha Silbe schrieb: Kann vll. jemand eine kurze Zusammenfassung geben, was das Ergebnis vom Linienbündel-Workshop war? Da ist im Wiki ja leider nichts zu finden. Ich habe mal eine schnelle Zusammenfassung im Wiki versucht. Man möge mich bitte korrigieren, wenn mein Eindruck nicht der Auffassung anderer Teilnehmer entspricht. Im Rahmen des Workshops gelang es nicht, eine definitive Empfehlung zum Tagging von Linienbündeln auszuarbeiten. Es bestand am Ende weitgehende Einigkeit unter den Teilnehmern, dass es möglich sein müsse, bei entsprechenden lokalen Gegebenheiten auch nichtparallele Linienverläufe einzuzeichnen. Den meisten Anklang fand ein Konzept, die Linien als eigene Ways zu taggen und mit einer geeigneten Relation an die eigentliche Straße zu binden. Die Linien würden dabei mit beschreibenden Tags analog zu Straßen versehen (access etc.), als Haupt-Tag für die zusätzlichen Ways würde zur Unterscheidung von Straßen jedoch nicht highway=*, sondern etwa lane=*, mit möglicherweise eigenen Values, zum Einsatz kommen. Persönliches Statement noch: Ich für meinen Teil bin (im Gegensatz zu allen übrigen Workshop-Teilnehmern ;-)) weiterhin der Ansicht, dass die 90 % der Spuren, die schlicht parallel laufen, keine eigenen Geoinformationen haben sollten, und deshalb als Relation besser modelliert wären als als Way. Das Parallelhalten der zusätzlichen Ways würde das Pflegen m.E. stärker erschweren als die Verwendung von Relations, gerade deshalb, weil in großem Stil Spuren ohnehin unter Verwendung spezialisierter Editing-Tools eingetragen werden dürften. Ich sehe diesen Einwand allerdings nur als Ergänzung zum Workshop-Resultat. Ways mit Tagging wie dort beschrieben würde ich als eine Darstellungsform von Spuren bzw. begleitenden Wegen voll akzeptieren. Für eine Einsatzfähigkeit des Konzepts ist noch eine geeignete Tagtabelle für die Spuren und eine exakte Definition der verbindenden Relation (eine geordnete Relation hielte ich hier etwa für extrem hilfreich für die Auswertung) erforderlich. Sobald ich Zeit finde, werde ich -- wenn mir niemand zuvorkommt -- einen Vorschlag dazu aufstellen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] barrier=gate
Nic Roets schrieb: According to the wiki redirects, barrier=gate is replacing highway=gate. According to tagwatch, the latter is 10 times more popular than the former. Is the community OK with this ? If yes, why aren't we running a bot to perform the changes ? Because we cannot tell whether the community is ok with this without watching how tagwatch numbers will develop in the future. So far, we can only tell that most of those who have bothered to vote in the wiki are ok with this. Personally, I'd agree if my contributions were bot-changed in cases like this, but there are people who wouldn't. Maybe it is possible to set up an opt-in bot that only updates tagging of those users who have put themselves on a list (wiki page/category or other solution). Bot runs should also be announced early, so those who disagree with a particular retagging can remove themselves from the list in time. Can we agree that a barrier=gate node implies that no traffic is allowed through unless it's enabled with tags like access=yes and foot=yes ? The wiki page for Key:barrier states By default access=no is implied . so tag who can pass the node. The wiki template also says Implies: access=no. So this currently applies to all barriers, including gate. Assuming that an unspecified barrier blocks traffic is the only thing that makes sense for me. Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Mapnik Update
Tobias Wendorff schrieb: Nein, ob wir die vorhandenen work-arounds á la highway = footpath an die path-Sache anpassen. Das sind meiner Auffassung nach (ich bin generell path-freundlich) keine work-arounds, sondern shortcuts mit klar definierter Bedeutung -- ganz abgesehen natürlich von ihrer historischen Bedeutung und Verbreitung. Generell befürworte ich Konzepte, die auch seltene Fälle und ungewöhnliche Kombinationen darstellen können -- etwa durch access-Tags in beliebiger Zusammenstellung. Der Preis für so etwas ist meist, dass es für den Mapper in einigen Fällen aufwändiger wäre, das Schema pur zu verwenden. Hier helfen dokumentierte Implikationen (erfreulicherweise sogar in den Wiki-Templates vorgesehen), Default-Werte -- und eben eigene Tags für diese Standardsituationen. Solange diese Information per einfachem wenn Tag x vorhanden, setze Tags y und z auf das ausführliche Schema abbildbar ist, halte ich das für durchaus von Datenverwertern handhabbar. Zumal das eigentlich immer der gleiche Code sein kann, der eben nur mit einer Liste all dieser Regeln gefüttert werden muss. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl von Stellplätzen
Martin Koppenhoefer schrieb: dieser Thread erinnert mich auch an eine weitere Imperfektion, die wir mit Parkplätzen und ~häusern noch haben: sie werden nicht differenziert. Im Kartenicon leider noch nicht, Fürs Tagging gab es ein erfolgreiches Proposal (siehe [1]) zu parking = multi-storey (Parkhaus) und parking = underground (Tiefgarage) als Zusatztags zu amenity=parking. Dieser Key ist im Wiki dokumentiert und hat laut Tagwatch in Europa bereits über 1000 Verwendungen mit den Werten surface (457, wäre eigentlich default), multi-storey (409), underground (400). Tordanik [1] http://wiki.openstreetmap.org/index.php/Approved_features/Parking ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl von Stellplätzen
Georg schrieb: Wie gebt ihr die Anzahl der Stellplätze in einem Parkhaus bzw. auf einem Parklpatz an? Eine Möglichkeit ist die Angabe über -name=1.700- Das ist eine Möglichkeit, den Namen eines Parkhauses anzugeben, das 1.700 heißt. Weitere Ideen? Die Wiki-Seite zu amenity=parking [1] kennt disabled_spaces, dem man neben yes/no auch einen numerischen Wert zur Angabe der Anzahl der Behindertenstellplätze geben kann. Warum dann nicht analog ein spaces=Anzahl für die Anzahl aller Stellplätze verwenden? Tordanik [1] http://wiki.openstreetmap.org/index.php/Tag:amenity%3Dparking ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl von Stellplätzen
Markus schrieb: Ich habe noch nie verstanden, warum man schreiben soll: amenity=parking + parking=multi-storey viel einfacher wäre doch: parking=multi-storey Weil parking=multi-storey eine Zusatzinformation ist, die zu Beginn noch nicht vorgesehen war und von Anwendungen ignoriert werden kann, ohne gleich die komplette Information (hier kann man parken) zu ignorieren. Auch die Zusatztags (fee, disabled_spaces ...) sind unabhängig vom Wert von parking und sogar ganz ohne ein solches Tag verwendbar. Würde man die Parking-Tags jetzt neu ausdenken, könnte man problemlos parking=yes wie amenity=parking und parking=x wie amenity=parking + parking=x interpretieren (ähnlich wie shop, building etc.), Ich sehe momentan keinen anderen Grund als den Wunsch, nicht mit dem bestehenden Tagging zu brechen. Was ich auch noch nicht verstanden habe: Wann muss ein Objekt mit building=yes ergänzt werden und wann nicht? Ein Parkhaus ist doch bereits ein bulding? (genauso wie Kirche, Schulhaus, Rathaus, etc) In vielen Fällen ist das so. Aber schon bei mehreren Einrichtungen in einem Gebäude kann man nicht mehr zwangsläufig auf ein separates Building verzichten, und die Fläche jeder einzelnen Einrichtung im Gebäude sollte nach Möglichkeit nicht als zusätzliches Gebäude angesehen/gezeichnet werden (was sie würde, wenn sie automatisch als Gebäude aufzufassen wäre). Dann gibt es theoretisch auch Ausnahmen in die andere Richtung (Schulen eetc. sind ja nicht überall auf der Welt immer in soliden Gebäuden untergebracht). Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradroute über einen Platz
Bernd Wurst schrieb: Entweder ein geeigneter Weg lässt sich algorithmisch finden oder nicht. Ich finde es ist möglich, also muss man keine Fake-Lösungen einbauen. Nebenbei: Hat das schon mal jemand algorithmisch gemacht? Ein paar Schwierigkeiten, die ich sehe, sind: 1. Flächen mit Delle. __ || || | || | |s__||__z| 2. Flächen mit Multipolygon. ___ | _| |s | | | ||_| z| | | |__| 3. zwei Flächen, die mit Seitenkanten aneinandergrenzen: ___ |s | | | | | | | | | | | |___|_z| Das ganze in beliebiger Kombination. Ich halte das schon für eine herausfordernde Aufgabe … Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Links presented on openstreetmap.org
Hi talk, currently, the http://openstreetmap.org/ page contains direct links to * Help Wiki * News blog * Shop * Map key I consider the first and last link to be well chosen, but I do not believe that the other two are really helpful for most users – the shop will not be relevant for anyone except enthusiasts, really. The blog, well ... updates are rare and it's really not what a new user will likely look for, imo. Instead, I'd suggest to add direct links to online communication channels (IRC, ML, forum) -- these are very hard to find now. If that's considered too much, it could be useful to at least link http://wiki.openstreetmap.org/index.php/Additional_Help Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Links presented on openstreetmap.org
Hi talk, currently, the http://openstreetmap.org/ page contains direct links to * Help Wiki * News blog * Shop * Map key I consider the first and last link to be well chosen, but I do not believe that the other two are really helpful for most users – the shop will not be relevant for anyone except enthusiasts, really. The blog, well ... updates are rare and it's really not what a new user will likely look for, imo. Instead, I'd suggest to add direct links to online communication channels (IRC, ML, forum) -- these are very hard to find now. If that's considered too much, it could be useful to at least link http://wiki.openstreetmap.org/index.php/Additional_Help Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Links presented on openstreetmap.org
Sorry Leute, war die falsche Liste. (Kennt vielleicht jemand ein Thunderbird-Plugin o.ä., das mich davon abhält, englischsprachige Texte an bestimmte Adressaten zu schicken …? Ich hab schon brain 0.9 beta probiert, aber das ist buggy. ;-)) Tordanik schrieb: Hi talk, currently, the http://openstreetmap.org/ page contains direct links to * Help Wiki * News blog * Shop * Map key I consider the first and last link to be well chosen, but I do not believe that the other two are really helpful for most users – the shop will not be relevant for anyone except enthusiasts, really. The blog, well ... updates are rare and it's really not what a new user will likely look for, imo. Instead, I'd suggest to add direct links to online communication channels (IRC, ML, forum) -- these are very hard to find now. If that's considered too much, it could be useful to at least link http://wiki.openstreetmap.org/index.php/Additional_Help Tordanik ___ 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] weitere maxspeed-Values brauchen wir!
Garry schrieb: Ich weiss nicht wie ich es Dir noch erklären soll... Default-Werte nützen rein gar nichts und machen den ganzen Tag wertlos weil man nicht unterscheiden kann ob der Default-Wert gültig ist oder ein geringerer Wert vorgeschrieben ist der eben nur nicht getaggt ist! Was soll dein Navi denn machen, wenn kein Wert dasteht und es einen „hier kein Wert“-Wert gäbe? Die fehlerhafte Straße umfahren? Noch etwas. Explizites Tagging nur für Höchstgeschwindigkeiten gewünscht oder auch maxweight=none maxheight=none minspeed ... etc. ? Überleg Dir was passieren kann wenn Du z.B. ein Tempo60 Schild übersiehst und Dein Navi Dir auch ein Default von 100km/h signalisiert weil das Schild noch nicht eingetragen wurde! Ein Navi, das einen Fahrer anweist, wegen OSM-Daten schneller zu fahren, ist gemeingefährlich. Umgekehrt mags ja angehen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Spam on Diaries
There has been an increasing amount of link spam on user diaries recently, such as these entries: http://openstreetmap.org/user/festivalplus/diary/3689 http://openstreetmap.org/user/allfuckthem/diary/3686 http://openstreetmap.org/user/allfuckthem/diary/3688 Is anyone working on countermeasures? Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] RFC - Key:Railway
Tobias Wendorff schrieb: Tordanik schrieb: Weil ich es nicht an die Nodes schreiben würde, sondern an den Way? Ich wäre nicht mal auf die Idee gekommen, die Information bei linienförmigen Features an die Nodes zu schreiben. Schonmal dran gedacht, dass POIs auch gebaut werden könnten? :-) Gebäude, Baustellen etc. Dein Beispiel („z.B. eine Straße und einen Park“) legte Ways nahe. Wenn ein Node aber ein POI ist, dann wird er hoffentlich nur genau einen POI darstellen, womit wieder die Eindeutigkeit gewährleistet wäre. Hab ich das richtig verstanden? Du würdest einen way mit railway=rail taggen und dann dessen _Nodes_ mit der construction-Information versehen? Alle oder nur bestimmte? Und … warum? Kommt mir wie ein ziemlicher Nachteil für die Auswertung vor, normalerweise braucht (bis auf vielleicht barriers) Node-Tags bei einem Way ja gar nicht beachten. Ich neige dazu, Keys stark zu verallgemeinern, damit man sie auf möglichst viele Situationen anwenden kann. Der einzige Gewinn an Allgemeinheit ergibt sich dann, wenn man mehrere Features als Tags auf das gleiche OSM-Objekt packt. Das würde ich aber halt nur generell nie tun, schon weil es sich in der Regel auch in der Realität nicht um ein Objekt, sondern bestenfalls zwei am gleichen Ort handeln wird. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz - je nach Uhrzeit
Martin Koppenhoefer schrieb: Wundert mich eigentlich ein bisschen, dass bisher niemand einen Tag für Parkhaus vorgeschlagen hat. Es gibt amenity = parking + parking = multi-storey Das wurde vorgeschlagen, in einer Abstimmung „approved“ (http://wiki.openstreetmap.org/index.php/Approved_features/Parking) steht ganz „offiziell“ auf http://wiki.openstreetmap.org/index.php/Tag:amenity%3Dparking und wird laut Tagwatch derzeit 400+ mal verwendet. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Voting process (was: Re: Map Features, maxspeed and maplint)
Shaun McDonald schrieb: In my opinion the voting process is broken, as it can potentially vote in proposals that will break backwards compatibility and require extensively more complex processing of the data. Take for example: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Yes, proposals can break backwards compatiblity. I do not believe this is a bad thing at all – if a new concept is better than an old one, then maintaining b.c. is the last thing I want, especially in a project with as random and insufficient “standards” as ours. That is not to say that b.c. isn't desirable, but it should by no means be required for new ideas. Moreover, the possibility to break b.c. is not limited to proposals – the competing concepts of “just add it to the wiki” and “just use it” can break b.c. as well, if not easier. I readily admit that voting has its flaws. Looking at the quoted proposal, you'll find that two of those who voted against it (Nibblenibble and Basemonkey) have only a single contribution in the wiki – the vote –[1], have created their accounts the same day they voted[2] and have cast their votes within 30 minutes from each other. Also, at the time of this writing, no OSM accounts exist whose names correspond to these wiki accounts. The two still might be legit voters (and when in doubt, it's probably fair to assume they are), but it's impossible to tell. But even this doesn't mean that voting is useless. The RFC+voting serves as a way to initiate discussion, collect ideas and encourage sufficient documentation. We are not talking about legally binding decisions here, it's just a tool for these purposes. And if someone has better tools to offer, I will prefer these, of course. It's just that this hasn't happened yet. Tordanik [1] http://wiki.openstreetmap.org/index.php/Special:Contributions/Nibblenibble http://wiki.openstreetmap.org/index.php/Special:Contributions/Basemonkey [2] http://wiki.openstreetmap.org/index.php?title=Special:Loguser=Nibblenibble http://wiki.openstreetmap.org/index.php?title=Special:Loguser=Nibblenibble ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Garry schrieb: Mario Salvini schrieb: maxspeed=walk (in livingstreets in Deutschland oder z.B. auf für Radfahrer freigegebenen Fußwegen gilt kein konkretes Limit, sondern nur Schrittgeschwindigkeit) Nein! Dagegen! Brauchen wir nicht! Wenigstens ist dein Standpunkt klar... 7km/h als Synonym für Schrittgeschwindigkeit reicht vollkommend! Irgendwie gefällt mir überhaupt nicht, den Wert einer Konstanten direkt in die Daten zu schreiben. ;) Ein maxspeed=walk hielte ich für ganz vertretbar, denn a) wird man im Ausland mit seinem „Schritt = 7km/h“ mit hoher Wahrscheinlichkeit falsche Daten produzieren b) ist die Rückwärtsabbildung kaum möglich, da es ja auch mal irgendwo ein echtes (7)-Schild geben könnte, und vielleicht will ja eine Software gerade nicht „7“, sondern „Schrittgeschwindigkeit“ anzeigen c) könnte sich die Interpretation von „Schrittgeschwindigkeit“ auch mal ändern d) ist die Definition schon jetzt keineswegs klar. zu c) und d) auch ein kleines Wikipedia-Zitat: Der Begriff Schrittgeschwindigkeit ist in der Rechtsprechung nicht genau definiert. Sie liegt nach Urteilen verschiedener deutscher Obergerichte zwischen 4 und 10 km/h. Der deutsche Bundesgerichtshof spricht davon, dass sie „deutlich unter 20 km/h“ liegen muss. Der österreichische Oberste Gerichtshof setzt in einem Spruch die Schrittgeschwindigkeit mit um die 5 km/h an. (http://de.wikipedia.org/wiki/Schritttempo) Für die handvoll Radfahrer die innerorts erheblicher schneller als 50km/h fahren brauchen wir auch keine Sonderregelung. Due erzeugst einen immensen Pflege- und Programmieraufwand für nichts! Immenser Aufwand, so. Bei einem gewissen Qualitätsanspruch ist es auf längere Sicht für Routing- oder andere Software, die mit maxspeeds umgeht, ohnehin kaum zu vermeiden, landestypische Implikationen/Defaults in ihren Daten zu ergänzen, wenn wir nicht alle defaults explizit taggen wollen (und das hielte ich definitiv für einen Fehler, daher halte ich derzeit auch maxspeed=none nicht für sinnvoll). Da sollte bei halbwegs generalisierter Implementierung die Übersetzung von maxspeed=walk in maxspeed=[numerischer Wert mit regionaler Interpretation der Schrittgeschwindigkeit] trivial sein. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC - Key:Railway
Tobias Wendorff schrieb: Könnte man das nicht einfach so lösen? railway = rail condition:railway = construction condition:railway:start = 2008 condition:railway:end = 2009 Und wo ist jetzt noch mal der Vorteil im Vergleich zu railway = rail condition = construction condition:start = 2008 condition:end = 2009 ? Da du den Way ja hoffentlich nur für ein Feature benutzt, ist die Zuordnung doch ohnehin eindeutig. Und das oft verlangte Rausfiltern wird durch unterschiedliche Keys auch nicht grad einfacher. Das wäre zwar mehr zu schreiben, aber man kann es normalisieren, es in Baumstrukturen schieben und alles andere. Irgendwie vermag ich da die Vorzüge noch nicht zu entdecken. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Garry schrieb: Tordanik schrieb: Ein maxspeed=walk hielte ich für ganz vertretbar, denn a) wird man im Ausland mit seinem „Schritt = 7km/h“ mit hoher Wahrscheinlichkeit falsche Daten produzieren Die Wahrscheinlichkeit ist viel höher Schrittgeschwindigkeit als nicht fest eingetragener Wert fehl zu interpretieren wenn die Navi-Software nicht in dem Land geschrieben wurde in dem man sich aufhält. Das ist mit einmaliger Definition eines Regelsatzes erledigt, und ein Fehler kann durch dessen einmalige Anpassung für alle Straßen behoben werden. Jedem einzelnen Mapper die Details beizubringen, stelle ich mir weit schwieriger vor, zumal damit noch lange nicht rückwirkend alle Fehler beseitigen kann. b) ist die Rückwärtsabbildung kaum möglich, da es ja auch mal irgendwo ein echtes (7)-Schild geben könnte, und vielleicht will ja eine Software gerade nicht „7“, sondern „Schrittgeschwindigkeit“ anzeigen Und wo ist dabei das Problem? In beiden Fällen wirst Du in Deutschland bei deutlich mehr als 15km/h mit Problemen rechnen können... […] Mit 7km/ als Anzeigewert wirst Du immer auf der sicheren Seite liegen. Selbst wenn mal nur 3km/h erlaubt werden würden. […] Was auch deutlich unter 20km/h ist... und mit 7km/h Dir auch kein Problem verursachen wird - ausser Du schubst einen Fussgänger von der Strasse - egal ob mit 5,7 oder 10km/h Ich will kein „der Mapper hat geglaubt, dass ich mit x km/h kein Problem haben werde“, sondern „hier gilt Schrittgeschwindigkeit“ – die Abwägungen überlass bitte mal mir. Sonst kommt der nächste und meint, dass man die 30er-Zone ruhig als 50 taggen darf, weil da eh nie kontrolliert wird, oder so was. […] landestypische Implikationen/Defaults […] Das wird Probleme geben weil sich die Software dann für jedes Land die Werte holen muss die erstmal defniert sein müssen. Trägt man die Werte explizit ein kommt jede Software sofort in jedem Land klar. Du willst an jede einzelne Straße die Höchstgeschwindigkeit und die Liste der zulässigen Verkehrsmittel rankleben? Ich nicht. Wenn auf einer Autobahn keine zusätzlichen Verkehrszeichen stehen, dann sollte auch der Mapper nicht mehr tun müssen, als ein „dies ist eine Autobahn“ hinzuschreiben. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Garry schrieb: Mario Salvini schrieb: und die StVO kennt nunmal neben fixen Geschwindigkeitsbegrenzungen auch Werte sie - Schrittgeschwindigkeit - mäßige Geschwindigkeit - keine Geschwinidkeitsbegrenzung diesen Begriffen willkürliche fixe Werte zuordnen ist einfach inkorrekt. Es ist kleinlich wenn man sie überkorrekt erfassen möchte und der Sache nicht dienlich ist. Du trägst doch auch auf deutschen (zumindes in BW)Autobahnen bei erlaubten 120km/h nicht 134km/h ein weil das noch toleriert wird? Warum bitte denkst du eigentlich immer in „wird toleriert“? Wenn da ein Schild mit „120“ steht, dann ist ein maxspeed=120 die präzisestmögliche Angabe, ein maxspeed=134 wäre schlichtweg falsch. Das ist dann ein tolerated_speed oder was auch immer. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Michael Kugelmann schrieb: Tordanik schrieb: Irgendwie gefällt mir überhaupt nicht, den Wert einer Konstanten direkt in die Daten zu schreiben. ;) die 7km/h sind der seit mehr als 1,5 Jahren gelebte Praxis. Warum meinst Du alles was sich bewährt hat über den Haufen zu werfen? Hey, das war nicht mein Proposal, und ich habe nicht einmal abgestimmt. Im Übrigen pflege ich unvoreingenommen an eine Frage heranzugehen und einem bestehenden Workaround keinen Nostalgiebonus einzuräumen. Wie dir hoffentlich nicht entgangen ist, habe ich im Rest meiner Mail recht ausführlich meine Überlegungen – keine entschiedene Meinung, sondern ein Denkansatz, auf den ich gerne inhaltlich begründete Erwiderungen sehen würde – dargelegt, wieso mir ein maxspeed=walk so unsinnig nicht erscheint. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Tordanik schrieb: Michael Kugelmann schrieb: Tordanik schrieb: Irgendwie gefällt mir überhaupt nicht, den Wert einer Konstanten direkt in die Daten zu schreiben. ;) die 7km/h sind der seit mehr als 1,5 Jahren gelebte Praxis. Warum meinst Du alles was sich bewährt hat über den Haufen zu werfen? Hey, das war nicht mein Proposal, und ich habe nicht einmal abgestimmt. Ähm, sorry, da hab ich was verwechselt. Bevor mich also hier jemand der Unwahrheit bezichtigt: Doch, ich habe abgestimmt. Das ändert aber nichts daran, dass meine Haltung in dieser Frage kein Dogma ist, sondern einfach nur ein Resultat dessen, dass ich den Aufwand für geringer als den Nutzen halte. Im Übrigen pflege ich unvoreingenommen an eine Frage heranzugehen und einem bestehenden Workaround keinen Nostalgiebonus einzuräumen. Wie dir hoffentlich nicht entgangen ist, habe ich im Rest meiner Mail recht ausführlich meine Überlegungen – keine entschiedene Meinung, sondern ein Denkansatz, auf den ich gerne inhaltlich begründete Erwiderungen sehen würde – dargelegt, wieso mir ein maxspeed=walk so unsinnig nicht erscheint. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC - Key:Railway
Tobias Wendorff schrieb: Tordanik schrieb: Und wo ist jetzt noch mal der Vorteil im Vergleich zu railway = rail condition = construction condition:start = 2008 condition:end = 2009 ? Ganz einfach: Es gibt Nodes, die mehr als eine Information haben, z.B. eine Straße und einen Park. Woher soll nun jemand wissen, ob Du railway oder leisure meinst? Weil ich es nicht an die Nodes schreiben würde, sondern an den Way? Ich wäre nicht mal auf die Idee gekommen, die Information bei linienförmigen Features an die Nodes zu schreiben. Hab ich das richtig verstanden? Du würdest einen way mit railway=rail taggen und dann dessen _Nodes_ mit der construction-Information versehen? Alle oder nur bestimmte? Und … warum? Kommt mir wie ein ziemlicher Nachteil für die Auswertung vor, normalerweise braucht (bis auf vielleicht barriers) Node-Tags bei einem Way ja gar nicht beachten. Verwirrte Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Begriffsfrage life_cycle (was: Re: RFC - Key:Railway)
Garry schrieb: Tordanik schrieb: Garry wrote: Tordanik schrieb: Liegt dir sehr am Begriff „operation_state“? Ansonsten könntest du das durch Unterstützung des „life_cycle“-Proposals[1] gleich für alle Features inklusive Eisenbahn auf die richtige Spur bringen. Erst mal nur mit disused und construction, aber Werte ergänzen ist ja leicht möglich. [1] http://wiki.openstreetmap.org/index.php/Proposed_Features/Status Tordanik Gegenfrage: Liegt Dir sehr am Begriff life_cycle? :-) Nein, der Begriff wäre mir völlig egal gewesen. Ich habe aber u.a. auf der Diskussionsseite des Proposals gefragt, ob jemanden ein anderer Begriff lieber wäre, auch auf der ML darauf hingewiesen. Trotz dieses Versuchs, Anregungen einzuholen, und trotz einer über 2 Monate dauernden Ich hatte Dich spätestens am 15.09. schon darauf hingewiesen... Ich weiß leider nicht genau, auf welche Mail du dich beziehst. Deine eine Aussage vom 14.09., die ich gefunden habe („Ob das jetzt construction oder life_cycle heisst spielt nicht wirklich eine Rolle, hauptsache es etabliert sich - wobei ich beide Namensvarianten nicht als besonders gelungen empfinde.“[1]) klang jedenfalls noch weit weniger entschieden als dein heutiges Votum („No for this name! A correct form could be operating_state but never life cycle!“). Am 15. gabs dann noch den Vorschlag „construction_state“, was ich für zu eng gefasst hielt und halte – ich glaubte, dies auch zum Ausdruck gebracht zu haben, das Archiv gibt mir hier aber Unrecht. Nichtsdestotrotz habe ich das Thema später auf der Diskussionsseite – erfolglos – angesprochen. [1] http://lists.openstreetmap.org/pipermail/talk-de/2008-September/022992.html und ebenfalls auf talk-de und talk angekündigten RFC-Phase hat sich vor Beginn der Abstimmung keiner mehr zu dem Thema geäußert. Jetzt, wo über das Tag gerade abgestimmt wird, kann man nicht mal eben den Namen ändern. Sorry, aber life cycle ist einfach der falsche Begriff bei dem jeder nicht Eingeweihte ehr eine Datumseingabe für eine Lebensdauer erwarten würde als einen Betriebsstatus für eine Strasse, Eisenbahnbrücke oder sonstiges Bauwerk. Von diesen Abstimmungsprozesse an denen ehr OSM-Laien teilnehmen und unter den OSM-Fachleuten ziemlich umstritten ist halte ich nicht besonders viel, die Ergebniss sind nicht selten ziemlich daneben. Was nützt Dir eine gewonnen Abstimmung, die nicht bindenden ist und weiterhin viel Konflikpotential mit sich bringt bzw. nicht angenommen wird weil der Begriff einfach falsch ist! Ich fürchte, du wirst mit keinem Vorschlag in diesem Bereich eine Lösung ohne viel Konfliktpotential bekommen. Die einen wollen ein einfaches Tag, das entsprechend den üblichen Gepflogenheiten eingetragen und ausgewertet werden kann und keine Sonderbehandlung braucht, die anderen möchten, dass auch die doofste Anwendung die Tags nicht missverstehen kann. Eine Ablehnung auf Grund des _Namens_ hat außer dir noch keiner zum Ausdruck gebracht. Daher werde ich die Abstimmung nicht abbrechen – ich fühle mich auch gar nicht berechtigt dazu. Das ist schließlich nicht mein Privatvergnügen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC - Key:Railway
Garry wrote: Tordanik schrieb: Garry schrieb: 7. operation_state = - disused - abandoned - construction - rebuild ... Liegt dir sehr am Begriff „operation_state“? Ansonsten könntest du das durch Unterstützung des „life_cycle“-Proposals[1] gleich für alle Features inklusive Eisenbahn auf die richtige Spur bringen. Erst mal nur mit disused und construction, aber Werte ergänzen ist ja leicht möglich. [1] http://wiki.openstreetmap.org/index.php/Proposed_Features/Status Tordanik Gegenfrage: Liegt Dir sehr am Begriff life_cycle? :-) Nein, der Begriff wäre mir völlig egal gewesen. Ich habe aber u.a. auf der Diskussionsseite des Proposals gefragt, ob jemanden ein anderer Begriff lieber wäre, auch auf der ML darauf hingewiesen. Trotz dieses Versuchs, Anregungen einzuholen, und trotz einer über 2 Monate dauernden und ebenfalls auf talk-de und talk angekündigten RFC-Phase hat sich vor Beginn der Abstimmung keiner mehr zu dem Thema geäußert. Jetzt, wo über das Tag gerade abgestimmt wird, kann man nicht mal eben den Namen ändern. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC - Key:Railway
Garry schrieb: 7. operation_state = - disused - abandoned - construction - rebuild ... Liegt dir sehr am Begriff „operation_state“? Ansonsten könntest du das durch Unterstützung des „life_cycle“-Proposals[1] gleich für alle Features inklusive Eisenbahn auf die richtige Spur bringen. Erst mal nur mit disused und construction, aber Werte ergänzen ist ja leicht möglich. [1] http://wiki.openstreetmap.org/index.php/Proposed_Features/Status Tordanik /Abstimmungswerbung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse übereinander
Markus schrieb: Für mich als Laie sieht das ganz einfach aus: die kleinere Fläche /überdeckt/ die Grössere. […] Dadurch könnte man sich doch die ganzen Konstrukte mit inner/outer und +1/-1 ersparen? Das würde die OSM-Struktur für alle einfacher machen: für Datensammler, für Renderer, für Anwendungsprogrammierer? Es gibt aber gerade bei landuse oft den Fall, dass eine kleinere Fläche das landuse nicht ersetzt, sondern ergänzt – ein Parkplatz ist kein Loch im Gewerbegebiet, sondern Teil davon. Gilt auch für viele andere Dinge, nicht zuletzt auch für Gebäude. Natürlich gibt es andererseits aber auch echte Löcher in landuses, so dass man ohne Hilfe des menschlichen Bearbeiters wohl kaum eine zuverlässige Entscheidung treffen kann. Auch ohne diese Erwägung könnte man sich die beiden genannten Konstrukte wohl sich nicht ersparen. Layer braucht man immer noch für (zumindest manche) Brückenkonstruktionen o.ä. – dafür sind sie nämlich eigentlich da, nicht für Landuse-Render-Hacks –, Multipolygon zumindest für den Fall, dass man ein Loch in einem Objekt hat, das selbst keine Information trägt. Für Renderer- und Anwendungsprogrammierer bedeutet das: Die Regeln müssen trotzdem implementiert werden, nur eben die zusätzliche Einschlussprüfung auch noch. 3 Konstrukte statt 2 klingt nicht einfacher. Ich halte solche generellen „Liegt Polygon A in Polygon B“-Tests über alle potentiell in Frage kommenden Polygone auch (ohne es bisher programmiert zu haben) für weit aufwändiger als eine Relation, bei der ich die Teilnehmer bereits kenne, und daher weit weniger Objekte prüfen muss. Datensammler, die mit den komplexeren Fällen in Berührung kommen, müssen ebenfalls alle drei Techniken kennen, sie sparen sich natürlich ein wenig Tipp- und Klickarbeit bei den einfachen Fällen. Diejenigen, die wirklich profitieren könnten, sind Datensammler, die nur einfachere Informationen einbauen (also nicht mit komplexeren Fällen in Berührung kommen) und sich auch nicht mit der Struktur der von ihnen erzeugten Daten auseinandersetzen wollen. So etwas wäre aber m.E. wegen der zusätzlichen Lasten für Anwendungen sowieso nicht im Datenmodell richtig aufgehoben, sondern in den Editoren. Die können gerne die Fähigkeit haben, etwa automatisch Mulipolygon-Relationen zu erzeugen, wenn du oder jemand anderes das ergonomisch hinbekommst. Das verschiebt den Aufwand von Anwendungen auf Editoren, was angesichts dessen wünschenswert ist, dass hoffentlich weit mehr Anwendungen als Editoren geschrieben werden – ansonsten machen wir irgendwas falsch. ;-) Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Öffnungszeiten
Stefan Leupers schrieb: gibt es ein Tag um einem Objekt Öffnungszeiten anzuhängen? Öffnungszeiten halte ich nur sehr bedingt für eine geo-information, Im Prinzip nicht, aber es wäre schon mega-genial, wenn man seinem OSM-basiertem Navi sagen würde Führ mich zum nächsten Aldi und das Navi antwortet mit Gern, aber der Aldi hat sei 30 Minuten geschlossen. Es wäre auch toll, wenn ich auf eine Sehenswürdigkeit in meiner Karte klicken könnte und dann eine Beschreibung und Bilder dazu bekäme. Ich schlage das Tagging „article=[Seitenweise Text hier]“ vor. Die Bilder packen wir mit Keys wie „image:1“, „image:2“ usw. in Base64-Codierung dazu. ;-) Natürlich könnten wir auch Wikipedia oder Stadtwikis dafür nehmen, dann ließen sich die Infos sogar brauchbar ablegen, außerhalb von OSM leichter einsetzen und von Autoren ohne OSM-Kenntnisse mit für die Textarbeit optimierten Werkzeugen pflegen. Und ähnlich das gilt eigentlich auch für andere Dinge, die zwar mit OSM ausgezeichnet kombiniert werden können, aber vom Charakter her keine zumindest halbwegs dauerhafte Geoinformation darstellen, etwa Staumeldungen, Restaurantführer, Fahrpläne öffentlicher Verkehrsmittel – und eben „Branchenbuchinfos“ (Öffnungszeiten, Kontaktadressen, Telefonnummern, Webseiten …). Also: Nur, dass man etwas gerne mit OSM verbunden anwenden möchte, ist meiner Ansicht nach noch kein Grund, dass es in dasselbe Format und dieselbe Datenbank gezwängt werden muss. Solange es ein solches spezialisiertes Projekt nicht gibt, kann man natürlich OSM als Notizzettel nehmen, aber jeder, der diesem Mangel abhelfen will, hätte meine volle Unterstützung. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [tagging] Feature Proposal - Voting - life_cycle=*
Hallo talk-de, ich habe jetzt die Abstimmung für den life_cycle-Vorschlag eröffnet. Es geht dabei um ein neues Konzept zum Taggen von nicht mehr verwendeten (life_cycle=disused) und im Bau befindlichen (life_cycle=construction) Dingen. In diesem Bereich gibt es bereits einige konkurrierende Ideen, etwa verschiedene Werte von highway und railway, aber auch eigene Tags wie disused=yes. life_cycle vereint meiner Ansicht nach die Vorzüge der beiden Konzepte. Es * ist nicht auf Straßen und Schienen beschränkt, sondern auf alle denkbaren Objekte anwendbar * ist leicht zu verwenden, da keine Modifikation an den übrigen Tags nötig ist * erlaubt anders als disused=yes und co, bereits am Key (life_cycle) zu erkennen, um welchen Typ von Information es sich handelt, was die Probleme mit Anwendungskompatibilität so weit reduziert, wie es mit separaten Tags möglich ist. Nicht Gegenstand der Abstimmung sind erst einmal weitere mögliche Werte wie planned, preserved und abandoned, da diese für sich genommen genug Stoff zur Diskussion bieten. Ins Schema passen würden sie auf jeden Fall problemlos. Den Vorschlag samt Abstimmungsmöglichkeit findet ihr im Wiki: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Für einen Vergleich mit anderen Konzepten auf diesem Gebiet, den ich kürzlich mal erstellt habe, siehe hier: http://wiki.openstreetmap.org/index.php/Comparison_of_life_cycle_concepts Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Öffnungszeiten
Florian Heer schrieb: Tordanik schrieb: [Ironie entsorgt] Schade, dabei hab ich mir doch so viel Mühe gegeben, meinen Vergleich zum Hinken zu bringen. *g* Also: Nur, dass man etwas gerne mit OSM verbunden anwenden möchte, ist meiner Ansicht nach noch kein Grund, dass es in dasselbe Format und dieselbe Datenbank gezwängt werden muss. Naja, ich bin ja der Meinung, dass wir mappen sollten, was sichtbar ist. Öffnungszeiten kann man im Vorbeilaufen aufschreiben (ebenso wie den Inhaber, das möchten scheinbar auch einige gern als Info haben). Die Geschichte eines POIs ist da entweder nicht im Vorbeilaufen mit-mapbar, oder sie hängt in urheberrechtlich geschützter Form rum. Kein schlechtes Kriterium, zugegeben. Ich zumindest sehe da schon einen Unterschied, ansonsten könnten wir direkt das volle Gegentum machen und nur Straßen und Gebäude eintragen, alle Zusatzinfos gehören dann in eine externe Datenbank, auch, ob es ein Restaurant ist, ob da ein Briefkasten ist etc. Richtig, es ist ein Unterschied. Man muss eben irgendwo für sich eine Grenze ziehen, weder „wir fügen alle Informationen in die Datenbank, die irgendwas mit dem Ort zu tun haben“ noch „wir packen nur noch Koordinaten und Ways in unsere DB und lagern alle Infos in externe DB aus“ halte ich für der Weisheit letzten Schluss. Ganz scharfe Kriterien sind da m.E. schwer zu definieren, für sprächen aber etwa folgende Punkte für eine eigene Unterbringung: * die Information lässt sich auch ohne OSM nutzbringend einsetzen - ist bei Dingen wie „Branchenbuch“ und „Fahrplan“ m.E. gegeben, die gibts ja nicht umsonst auch schon extra * die Information lässt sich mit OSM-Datenstrukturen schwer abbilden - gilt wohl bei Öffnungszeiten durchaus auch, da ich bis jetzt noch keine Lösung gefunden habe, die halbwegs ohne kompliziertes Parsing schwer lesbarer Strings auskommt * es könnten auch Leute mitarbeiten wollen, die nicht Mapper sind - halte ich auch für gegeben, da die technische Einstiegshürde bei einer Öffnungszeitenmaske wohl geringer ist, als es detailliertere OSM-Edits je sein werden Letztlich ist es natürlich Ansichtssache, und solange ich nicht selber eine Öffnungszeiten-DB baue, muss ich mir ja an die eigene Nase fassen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder aus Wikipedia
Raimond Spekking schrieb: Tordanik schrieb: Unabhängig von der technischen Machbarkeit: Ist das konform mit den Bestimmungen der Commons? In den dortigen FAQs findet man: „For media files, don't hotlink. Please copy them to your own server.“ Erik Möller, seines Zeichens Deputy Director der Wikimedia Foundation [1], hat in seinem Blog die technische Anleitung gegeben [2], um über die API Dateien direkt in eigene Wikis einzubinden. […] Das Verbot von Hotlinking bezieht sich vor allem auf die Unart, fertige Thumbs direkt einzubinden, ohne dass man einen Link auf die Bildbeschreibungsseite erhält. Was wiederrum idR ein Lizenzverstoß wäre. [1] http://wikimediafoundation.org/wiki/Staff [2] http://intelligentdesigns.net/blog/?p=91 Ok, das „Please copy them to your own server.“ hatte mich doch irritiert. Der Blogeintrag legt allerdings eindeutig nahe, dass die Verwendung des Features in der geplanten Weise erwünscht ist. Danke für den klarstellenden Link. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bilder aus Wikipedia
Raimond Spekking schrieb: Dann kann man mit einem einfachen Eintrag in der LocalSettings.php alle Bilder von Wikimedia Commons über eine API live einbinden. Beim Klick auf das Bild wird die Bildbeschreibungsseite von Commons gezeigt. Unabhängig von der Lizenzproblematik erspart man sich auch das Hochladen in das lokale MediaWiki. Einfach über 3 Millionen Dateien von Commons nutzen :) Unabhängig von der technischen Machbarkeit: Ist das konform mit den Bestimmungen der Commons? In den dortigen FAQs findet man[1]: „For media files, don't hotlink. Please copy them to your own server.“ Tordanik [1] http://commons.wikimedia.org/wiki/Commons:Reusing_content_outside_Wikimedia#Hotlinking ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgeschriebene Fahrtrichtung
Detlef Reichl schrieb: Im JOSM werden diese Restriktionen in keiner Weise angezeigt. Das macht es schwer für eine Kreuzung zu kontrollieren ob diese schon eingetragen sind. Wenn man sich dann die passende Relation im Relationseditor aufgemacht hat, sollten die Einzelnen Punkte/Strecken die unter Mitglieder aufgeführt sind, sobald man sie anklickt in der Karte hervorgehoben (z.B. blinkend) werden. Du kannst im Relationseditor ein Mitglied per „Select” auswählen und bei Bedarf per 3 zur Auswahl zoomen (für letzteres muss erstmal das Hauptfenster wieder den Fokus bekommen haben). Ist zwar nicht so elegant wie Blinken, aber erfüllt seinen Zweck. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgeschriebene Fahrtrichtung
Detlef Reichl schrieb: Um jetzt eine Straße so zu kennzeichnen, das man z.B. nur grade aus fahren darf, wird eine Relation angelegt. Hier werden type=restriction gesetzt und restiction=only_one_way gesetzt. Dann werden Nodes von vor, hinter und auf der Kreuzung hinzugefügt. Der vor der Kreuzung erhält die Rolle from, der hinter der Kreuzung die Rolle to und der auf der Kreuzung die Rolle via. Sollte ich hier totalen Blödsinn geschrieben haben, möge man mich verbessern. Verbesserungen: 1. Du fügst in den Rollen „from“ und „to“ keine Nodes vor und hinter der Kreuzung hinzu, sondern vielmehr die Ways selber. Das was du beschrieben hast, wäre der Alternativvorschlag „xrestriction“[1]. 2. „only_one_way“ ist keiner der gelisteten Werte auf der Originalseite[2]. Bei nur geradeaus würde wohl „only_straight_on“ passen. Tordanik [1] http://wiki.openstreetmap.org/index.php/Relation:xrestriction [2] http://wiki.openstreetmap.org/index.php/Relation:restriction ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorgeschriebene Fahrtrichtung
Ulf Möller schrieb: Detlef Reichl schrieb: Das heist aber, dass ich dafür den Weg. wie es vorhin Johann geschrieben hat splitten muss Nein. Du gibst zwei Ways an (from, to) und den Node, in dem die restriction gilt (via). Es gibt leider Fälle, in denen Splitten notwendig ist: * Nehmen wir an, wir haben A-Straße, die Nord-Süd verläuft, und B-Straße, die West-Ost verläuft. Die beiden sind jeweils als einziger Way gezeichnet und haben in der Mitte einen gemeinsamen Node als Kreuzung. * Wenn ich auf der A-Straße von Süd komme, darf ich nicht nach links (nach Westen) auf die B-Straße abbiegen. Das möchte ich modellieren. * Ich füge A-Straße als from, B-Straße als to und den Kreuzungsnode als via in eine restriction-Relation ein. * Ergebnis: Die restriction verbietet, von Süd nach West abzubiegen. Sie verbietet aber auch, von Süd nach Ost, von Nord nach Ost und von Nord nach West abzubiegen – in jedem dieser Fälle würde ich nämlich _von_ der A-Straße _in_ die B-Straße _über_ den Kreuzungsnode fahren. = Einziger Ausweg: Beide Straßen an der Kreuzung splitten. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler auf www.openstreetmap.org
Andreas Labres schrieb: Sven Rautenberg wrote: Das Problem ist, dass sich die Layeroptionen mit der Zeit geändert haben, und alte Bookmarks nicht mehr kompatibel sind, bzw. unerwartet den Maplint-Layer einschalten. Dann sollte man das fixen. Was aber bedeutet, dass man wiederum solche Permalinks verbiegt, die _nach_ der Änderung entstanden sind, oder? Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler auf www.openstreetmap.org
Till Maas schrieb: Tordanik wrote: Andreas Labres schrieb: Sven Rautenberg wrote: Das Problem ist, dass sich die Layeroptionen mit der Zeit geändert haben, und alte Bookmarks nicht mehr kompatibel sind, bzw. unerwartet den Maplint-Layer einschalten. Dann sollte man das fixen. Was aber bedeutet, dass man wiederum solche Permalinks verbiegt, die _nach_ der Änderung entstanden sind, oder? Wenn dies aber nur diejenigen betrifft, die innerhalb der letzten zwei Wochen erzeugt wurden, sind das sicherlich weniger, als alle zuvor gespeicherten Permalinks. Ich hatte halt nur den Eindruck, dass es schon länger als zwei Wochen her ist – oder dass so was ähnliches vorher schon einmal vorgekommen ist. Kann mich natürlich täuschen, genau weiß das wohl nur derjenige, der die Umstellung vorgenommen hat. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler auf www.openstreetmap.org
Johann H. Addicks schrieb: Tordanik schrieb: Dann sollte man das fixen. Was aber bedeutet, dass man wiederum solche Permalinks verbiegt, die _nach_ der Änderung entstanden sind, oder? Nein. Abgesehen vielleicht von Leuten, die tatsächlich Permanentlinks auf den Error-Layer erzeugt haben in den letzten Wochen und sich zukünftig wundern, dass es keine Fehler mehr gibt ;-) „Nein, abgesehen von …“ = „ja“. ;-) Auch wenn wir die Links auf die Error-Layer jetzt mal ausklammern, erfordert eine Vermeidung der Beeinträchtigung neuer Links, dass man zukünftig beide Layer-Parameterwerte erkennt – und nicht nur den früheren Zustand wiederherstellt. Nicht unmöglich, muss aber zusätzlich bedacht werden. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bild von Strommast gesucht (war: Bil d von Trafohaus für Mapfeatures gesucht)
John07 schrieb: Wo wir gerade dabei sind, hat jemand zufällig ein schöneres Bild für power=tower ? Also so einen schönen großen Strommast, in etwa so: http://de.wikipedia.org/w/index.php?title=Bild:Freileitung400.jpgfiletimestamp=20060616193126 Wieso nimmst du nicht einfach das Bild, das du als Beispiel verlinkt hast? (Wenns wegen der Lizenz ist, kannst du den Wikipedianer ja immer noch um Freigabe unter passender Lizenz bitten, sollte doch sicher klappen.) Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesetzeswahnsinn
André Reichelt schrieb: Philipp Klaus Krause schrieb: Das ist wie bei anderen Prjekten, deren Ziel es ist, ein freies X zu erstellen: Wenn man sich keine Gedanken zur rechtlichen Situation macht, war man vieleicht da, um eine freies X zu erstellen, hat aber dann ein nichtfreies X erstellt. Oder ein freies X, das der Lizenz wegen nicht mit freien Y und Z kompatibel ist, so daß niemand das freie X verwenden kann und die ganze Arbeit nochmal gemacht werden muß. Und genau dieser rechtliche Wahn(sinn) gehört bekämpft. Wenn du das tun willst, indem du dich selbst möglichen juristischen Konsequenzen aussetzt, kannst du das gerne machen. Aber unsere Nutzer würde ich doch ganz gerne aus der Schusslinie halten – das und nichts anderes soll diese ganze Lizenzgeschichte leisten. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnhaus mit Geschäft
Hallo Markus, Markus schrieb: mehrere Geschäfte in einem Haus geht mit hierarchischen Schlüsseln: building=yes + addr:street=* + addr:housenumber=# + layer=0 ++ office=* ++ office=* + layer=1 ++ office=* ++ office=* Das geht auch mit Relationen. Spontan würde ich mir so etwas wie eine in_building-Relation vorstellen, die die Nodes (evtl. auch Areas, die den belegten Teil des Gebäudes beschreiben?) für die Geschäfte und sonstigen Einrichtungen (user-Role, auch mehrere Member dieser Role) und die Gebäude-Area (building-Role) enthält. Bei Bedarf noch ein Stockwerk-Tag in die Relation, gerne auch von-bis für kompliziertere Fälle. Vorteile: * Geschäftsnode und Gebäude werden auch von Renderern dargestellt, die die Relation nicht kennen * Geschäfte im Gebäude sind nicht nur Tags, sondern haben eigene IDs, können also gegebenenfalls noch in anderen Relationen Member sein * wäre mit derzeitiger Datenstruktur umsetzbar Nur ein schneller Entwurf, diese Relation existiert natürlich bislang ebenso wenig wie deine hierarchischen Schlüssel und müsste in einem Proposal ausgearbeitet werden, aber vielleicht kann die Idee ja als Denkanstoß dienen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnhaus mit Geschäft
René Falk schrieb: Ich habe das hier gefunden: http://wiki.openstreetmap.org/index.php/Relations/Proposed/Buildings Ob man das wohl da mit einbauen könnte? Würde ja thematisch passen. Mit dem verlinkten Vorschlag passt das m.E. nicht so gut zusammen, weil es doch einen Unterschied macht, ob ich andere Objekte _außerhalb_ eines Gebäudes (die auch immer ganz normal außerhalb eingetragen und gerendert würden) diesem zuordnen will, oder ob ich darstellen will, dass sich etwas _in_ einem Gebäude befindet. Zumal man von der verlinkten Relation immer nur eine bräuchte, die dann auch entsprechend den Namen des Gebäudes enthalten könnte. Von meiner vorgeschlagenen Relation bräuchte man u.U. mehrere pro Gebäude (allerdings nur dann, wenn man auch die Stockwerksinfo haben will). Überlegen kann man es sich mal, aber ich halte das jetzt erst einmal für einen zu deutlichen Unterschied, um das mit einer generellen „Gebäude-Relation“ abzudecken. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google bringt Google Transit
Birgit Nietsch schrieb: Zumindest in einem Punkt kann Google uns nicht überholen: Die Google Kartendaten sind nicht gemeinfrei. Unsere Daten sind aber leider ebenfalls nicht gemeinfrei, sondern stehen unter einer viralen Lizenz, bei der keiner so genau sagen kann, wozu ich bei Weiterverwendung eigentlich verpflichtet bin – was eine solche Weiterverwendung recht unattraktiv macht. Da das Lizenzproblem zwar schon ewig immer mal wieder diskutiert wird, es aber zu keinerlei Ergebnissen kommt, kann man uns in diesem Punkt sogar sehr leicht überholen … Google wird das freilich kaum tun. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von kurzen Straßenstüc ken steuern
löscht und nicht mit der entsprechenden Datenbank verbunden ist. Informationsverluste durch „Unwissende“ kann man aber auch in einer einzigen Datenbank nur lösen, indem man dem Mapper auferlegt, bei Änderungen (Verschiebungen etwa) die Auswirkungen auf sämtliche anwendungsspezifischen Tags zu prüfen, sonst werden die Informationen bei Bearbeitungen auch unbrauchbar. Deshalb gilt unabhängig von der DB-Lösung: nicht mit Handarbeit übertreiben. Ortsprioritäten oder die auf talk vorgeschlagene Kennzeichnung unerwarteter Nicht-Einbahnstraßen dürften durchaus einen Wert haben und recht wenig Aufwand verursachen. Straßenverschiebungen (auch renderspezifische) für bessere Darstellung halte ich für übertrieben und den Wartungsaufwand bei Bearbeitungen andere Nutzer nicht wert. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von kurzen Straßenstüc ken steuern
Friedhelm Schmidt schrieb: Dem Router sage ich, dass man hier nicht links abbiegen darf; dem Renderer, dass es sich nicht lohnt hier den Straßennahmen zu wiederholen. Da ist doch nichts dabei. Dir fällt nicht auf, dass das eine völlig andere Sache ist? Dass der Router die Information niemals selbst ermitteln könnte, der Renderer mit einer guten Programmierung aber sehr wohl selbst erkennen könnte, wo für Namen genug Platz ist und wo nicht? Dass ein Abbiegeverbot eine Abbildung der Realität ist (es gibt schließlich ein Schild o.ä.), ein „hier bitte keinen Namen hinschreiben“ dagegen mit einer Abbildung der Realität nichts zu tun hat? Dass jeder denkbare Router die Abbiegeinfo brauchen kann, aber das optimale Rendering von Renderer, Zeichendicke, Schriftart … abhängt? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von kurzen Straßenstüc ken steuern
Hallo, Frederik Ramm schrieb: Wir, mit unserem Crowdsourcing-Ansatz, haetten hier die Chance, das beste beider Welten miteinander zu vereinen. Unsere automatischen Renderer koennten das Gros der Arbeit tun, aber ueberall dort, wo wir Menschen sehen, dass die Resultate suboptimal sind, koennten wir geeignete Hints einbauen: Hier muss man bei Zoomstufen x-y etwas schummeln und diese Strasse um 500m nach rechts verschieben oder so. Mit solchen Tools koennte es uns gelingen, kartographisch ansprechende Werke zu erzeugen, die dem, was irgendwelche Software aus Standarddaten automatisch berechnet, haushoch ueberlegen ist. Das ist im Ansatz richtig und in der Tat ein potentieller Vorteil für unseren Mapping-Ansatz, insofern erst einmal Dank für die neue Perspektive, die ich in dieser Form noch nirgends ausgedrückt gesehen habe. Allerdings hat der anwendungsorientierte Optimierungsansatz unter Umständen ebenfalls Nachteile, so ist der Aufwand dann auch teilweise abhängig von der Anzahl der unterstützten Anwendungen. Das ist insofern ein wichtiger Punkt, als ein wesentlicher und oft herausgestellter Vorzug von OSM darin besteht, dass mit der Verfügbarkeit von Rohdaten eine Vielzahl kreativer Anwendungen möglich sein soll – und das ist um so eher denkbar, je mehr Probleme mit universellen statt anwendungsspezifischen Konzepten gelöst wurden. Es ist nicht zu vernachlässigen, dass mit dem Vorhandensein einer Lösung für die Lieblingsanwendung des Mappers der Anreiz fehlt, Zeit in eine Lösung zu investieren, die allen Anwendungen zugute käme. Gleicher Effekt bei den Anwendungsprogrammierern: Populäre Anwendungen werden sich dann vielleicht – im Wissen, dass für sie optimiert wird – nicht die Mühe machen, solche Lösungen zu implementieren, die universeller wären (ich nenn das mal das „Internet-Explorer-Problem“). Für eine Verwendung anwendungsspezifischer Hints spricht daher für mich, wenn möglichst viele der folgenden Punkte erfüllt sind: * Die Hints lassen sich für eine ganze Gruppe von Anwendungen einsetzen etwa für die meisten oder gar alle Renderer/Router/… * Das Problem lässt sich nicht oder nur schwer algorithmisch lösen. * Das Problem liegt an bestimmten örtlichen Besonderheiten und ist nicht der „Normalfall“. Beim konkreten Beispiel „osmarender:renderName“ – das aber inhaltlich nicht Hauptanliegen dieser Mail sein soll – trifft all dies in den vielen Anwendungsfällen kaum zu. Ich folgere daraus nicht, dass ich die hints noch vor Lösung des Problems löschen würde – nicht einmal, dass das Tag in jedem Einzelfall überflüssig sind –, aber halte den Relation-Ansatz mit autonomer Verteilung der Labels durch die Software klar für die bessere Lösung. Zum Schluss noch: Die Vorteile ließen sich ebenso erzielen, würden die anwendungsspezifischen Tags in eigenen Datenbanken gespeichert. Man kann Editoren so anpassen, dass sie nur interessante Tags anzeigen, ja. Man kann sie aber auch anpassen, dass sie Daten aus mehreren Quellen entnehmen und auch passend wieder hochladen. Verzichtet man auf die Speicherung in der Hauptdatenbank, hätte man für diesen Bereich auch ein für allemal das Problem aus der Welt geschafft, ob es irgendwelche Einschränkungen (Umfang der Daten, „Relevanz“ der Anwendung – de.WP lässt grüßen) dafür geben soll, was für anwendungsspezifische Daten „erlaubt“ sein sollen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen auf gleicher Höhe
Bernd Wurst schrieb: Neben die Straße setzen: - Bushaltestellen sind in den meisten Fällen am Straßenrand oder neben der Straße Das ist leider kein objektiv eindeutiger Vorteil, weil besonders hier ja die Auffassungen auseinander gehen. Unser Straßen-way repräsentiert eine Straße mit sämtlichen Spuren sowie angrenzenden Rad- und Fußwegen. Der Bus hält i.d.R. zwischen Fußweg und Fahrspuren, also innerhalb des vom Way repräsentierten Bereichs. Damit ist es durchaus nicht unlogisch, den node auf den way zu setzen. Wird die Busspur mit einem service-way dargestellt, wäre das ohne weitere Tags streng genommen so zu interpretieren, dass der Bus zur Anfahrt an die Haltestelle den Bürgersteig überquert. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen auf gleicher Höhe
Hallo, Unser Straßen-way repräsentiert eine Straße mit sämtlichen Spuren sowie angrenzenden Rad- und Fußwegen. Letzteres ist eine parallele Diskussion, in der ich nicht die Meinung der am aggressivsten schreibenden Fraktion vertrete. Unterscheide bitte zwischen Tatsachen in der Realität (Bushaltestelle ist (oft) neben der Straße), Tatsachen bei OSM (Straßen sind nur abstrakt als Mittellinie erfasst) und Dingen, die Auslegungs- und Diskussionssache sind (Fahrradwege gehören als Eigenschaft zur Straße). Mir ging es eigentlich vor allem darum, dass du in deiner ansonsten sehr sachlichen Auflistung praktischer Vorzüge der einzelnen Lösungen einen Punkt angeführt hast („Bushaltestellen sind in den meisten Fällen am Straßenrand oder neben der Straße“), der bereits Ausdruck einer bestimmten Interpretation der Realität ist: Wenn man die Bushaltestelle als die Stelle betrachtet, an dem die Fußgänger/das H-Schild stehen, dann ist er am Rand bzw. neben der Straße. Wenn man die Bushaltestelle als die Stelle betrachtet, wo der Bus hält, dann ist sie meistens auf der Straße – zumindest wenn man sämtliche Spuren der Straße als deren Teil sieht. Daher auch das „nicht unlogisch“ (was nicht im Umkehrschluss den gegensätzlichen Ansatz die „Logik“ absprechen sollte!): Führt man nur für eine Seite die zugrundeliegende Interpretation der Realität an, für die andere aber lediglich praktische Gründe, so erweckt man den m.E. unzutreffenden Eindruck, nur erstere Seite stelle die Realität „logisch“ dar. Wird die Busspur mit einem service-way dargestellt, wäre das ohne weitere Tags streng genommen so zu interpretieren, dass der Bus zur Anfahrt an die Haltestelle den Bürgersteig überquert. Das ist auch korrekt. Ich kenne solche Bushaltestellen, insbesondere an einer Schule bzw. Kindergarten gibt es die. Gerade da es diesen Fall in der Realität gibt, würde ich ungern alle Haltestellen – wie von manchen vorgeschlagen – so (per Zusatznode + service-Way) taggen, da der Fall sonst nicht mehr explizit ausgedrückt werden kann. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen auf gleicher Höhe
René Falk schrieb: Wie sieht es denn mit Briefkästen, Telefonen, Abfalleimern und ähnlichem aus, die oft auf Bürgersteigen stehen? Folgt man deiner Argumentation, könnte man auf den Trichter kommen zu sagen, das diese Dinge, weil sie sich auf dem Bürgersteig befinden, mit zur Straße gehören, und einen Node auf auf den way setzen. Dabei geht dann die Information verloren, auf welcher Straßenseite sich das Ding befindet. Ich habe hier häufiger die Situation, das sich an/auf der Bushaltestelle noch ein oder mehrere der oben genannten POI befinden. Wie würdest Du das mit welcher Begründung taggen? Eine zugegeben berechtigte Frage. Meine bisherige Vorgehensweise ist folgende: 1. Objekte, die sich außerhalb der zentralen Fahrbahn und sämtlicher begleitenden Wege* befinden, werden definitiv außerhalb eingezeichnet. Das gälte etwa für ein Gebäude an der Straße. (* Bürgersteige, Radwege etc. – hier und im Folgenden nur gemeint, wenn_nicht als separate Ways vorhanden) 2. Objekte, die sich außerhalb der zentralen Fahrbahn, aber auf den begleitenden Wegen befinden und nicht der Regelung des Verkehrs auf der Fahrbahn dienen, werden ebenfalls außerhalb eingezeichnet. Prinzipiell können diese Objekte per Relation dem Way zugeordnet werden, das habe ich bislang allerdings – anders als bei 1 – nicht getan. Dies gilt für die genannten Briefkästen, Telefone u.a. POIs. Zugrundeliegende Überlegungen: - diese Kategorie von Objekten ist konzeptionell unabhängig von einer Straße. Sie stehen eben an einer, aber wären auch auf der grünen Wiese, in einem Haus oder sonstwo vorstellbar. Das ist bei Dingen aus 3 nicht der Fall. - ob sich das Objekt nun auf oder neben etwa einem Gehweg befindet, ist wenig relevant für die Zugänglichkeit durch dessen Benutzer - es lässt sich leichter bearbeiten (erspart das Straßenseitenproblem, man hat nicht viele Nodes im Way, man kann sie unabhängig verschieben …) 3. Objekte, die sich a) auf der zentralen Fahrbahn befinden oder b) der Regelung des Verkehrs auf der zentralen Fahrbahn dienen, werden als Nodes des Wegs gezeichnet. Hierunter fallen etwa Barrieren, crossings wie Zebrastreifen, Ampeln, und bei der von mir bevorzugten Interpretation Bushaltestelle=Stelle_auf_der_der_Bus_hält (anders als bei Bhs=Stelle_wo_das_Schild_steht) eben auch Bushaltestellen. Das Beispiel würde ich also per bus_stop als Node im Way (ggf. mit left/right-Angabe) und Node neben dem Way für z.B. die an der Bushaltestelle stehende Bank darstellen. Mir ist völlig klar, dass man mit guten Gründen auch anders vorgehen kann. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so kompl iziert?
Guenther Meyer schrieb: Abgesehen davon finde ich limit.access[weight7.5]=* besser, weil man durch verschiedene Vergleiche mehr Möglichkeiten hat. bei verboten wegen gewicht, breite, hoehe, geschwindigkeit usw. geht es praktisch immer um groessergleich. deshalb habe ich fuer diesen standardfall das zeichen weggelassen, was das ganze einfacher, schneller eingebbar und lesbarer macht. sollte mal was anderes vorkommen, kann man's immer noch hinschreiben. Das Größer(-gleich)-Zeichen weglassen ist nicht lesbarer, sondern führt im Gegenteil zu unnötigen Unklarheiten. Ich hätte nicht sagen können, ob du damit jetzt ein oder oder = oder = meinst. (Spontan hätte ich ja auf = getippt, aber da spricht natürlich die Sinnhaftigkeit dagegen). Ein Zeichen weniger zu tippen fällt so gut wie nicht ins Gewicht und ist m. E. die möglichen Missverständnisse nicht wert. Außerdem ist bei Verwendung von eher klar, dass man auch schreiben kann, wo es nötig ist. Das spart den Leuten einmal Nachschlagen im Wiki. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] [tagging] Feature Proposal - Voting - Number of steps
step_count gives the number of individual steps for a way tagged with highway=steps. http://wiki.openstreetmap.org/index.php/Proposed_features/Number_of_steps ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] [tagging] Feature Proposal - RFC - (maxspeed = none)
Gerrit Lammert schrieb: Müsste dann nicht maxspeed=none auch für alle nicht beschilderten Straßen angewendet werden? Woher weiß ich sonst, ob der Bereich tatsächlich unbeschildert ist (und damit die gesetzliche Max-Geschwindigkeit für diesen Straßentyp gilt) oder jemand nur das Schild vergessen hat? Das Proposal sagt klar und deutlich, dass maxspeed=none nicht „hier steht kein Schild“ bedeuten soll, sondern „hier darf man so schnell fahren, wie man will.“ (Zitat aus dem Proposal-Text: „This is not intended to be used on highways where is a default speed limit if there is no sign (local law applies). This is only to be user where really no speed limit at all is valid.“) Bei einer „normalen“ Straße erkennt man die Information, dass es jemand geprüft hat, daran, dass in diesem Fall ein maxspeed=50 (oder was auch immer die Standardgeschwindigkeit ist) hingeschrieben ist. Sprich: Das Proposal geht von der (m.E. in dieser Form nicht idealen) Idee aus, dass wir – aus Gründen der Vollständigkeitskontrolle und zur Vermeidung der Notwendigkeit, Routern die Verkehrsregeln jedes Landes und eine entsprechende Landesgrenzenerkennung beizubringen – keine impliziten maxspeeds haben sollten. Für alle Straßen, die eine gesetzlich festgelegte Maximalgeschwindigkeit haben, geht das bereits jetzt. Nur für „unbegrenzte Geschwindigkeit“ konnte man bisher noch keinen Wert eintragen. Das offensichtliche Beispiel sind hier natürlich Autobahnen, aber es handelt sich keineswegs um eine Autobahn-Sonderregelung, der Wert kann – wie ebenfalls aus dem Proposal-Text hervorgeht – für einen beliebigen „highway“-Typ vergeben werden. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVGs im Wiki?
Johann H. Addicks schrieb: Das ist -wie der Vorposter schrieb- eine Frage der localsettings.php (und natürlich der Version von Mediawiki und imagemagick, was aber kein Problem sein dürfte) […] Das Rendern von SVGs in PNG lange nicht so teuer wie z.B. das Skalieren von JPGs. (Zumindest nicht bei dem was wir hier so an PNGs haben. Also weder 2000+ Nodes noch massenhaft Farbverläufe.) Klingt ja noch unproblematischer, als ich gehofft hatte. Dann braucht es ja nur noch jemanden mit den passenden Berechtigungen, der das auch durchführt. Hat hier jemand einen Tipp, wer an den notwendigen Hebeln sitzt? Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SVGs im Wiki?
Hallo, habe gerade beim Versuch, das etwas schlecht aufgelöste Verkehrszeichen auf Key:maxspeed (http://wiki.openstreetmap.org/index.php?title=Key:maxspeedoldid=136308) durch eine Vektorgrafik zu ersetzen, festgestellt, dass unser Wiki keine SVGs unterstützt. („Permitted file types are png, gif, jpg, jpeg, doc, pdf.“) Ist das Absicht? Ich würde das Format schon ganz praktisch finden, zumal ein Großteil unserer Verkehrszeichen von Wikimedia Commons „geklaut“ ist, wo sie eh als SVG vorlägen – eine Qualitätsreduzierung beim Import finde ich nicht so sinnvoll. Man könnte dann vielleicht auch ein Renderer-Icon im SVG-Format besser mal ins Wiki packen, falls sich die Notwendigkeit ergibt. Mangels Kenntnis eines thematisch engeren Kommunikationskanals für Wiki-Themen frag ich mal talk-de um Meinungen … Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Einstieg geschafft! :-D
Steffen Voß schrieb: 1. Zoomen geht am einfachsten per Mouse-Rad. 2. Karte verschieben geht mit gehaltener rechter(!) Mouse-Taste. Wäre für mich persönlich beides das, was ich intuitiv ausprobierte. Hängt wohl davon ab, was man erwartet. In welcher Form hättest du diese Info als JOSM-Einsteiger am liebsten präsentiert bekommen? 5. Um Nodes zu verschieben muss man das Tool wechseln. IMHO ist das relativ unpraktisch. Ist eigentlich nur Aufwand, wenn man nicht die Tastaturbefehle verwendet. Die Tastaturhand hat sonst doch eh kaum was zu tun. Bei zu viel kontextsensitiver Intelligenz (was macht er jetzt? Karte verschieben? Node verschieben? Way verschieben? Node erstellen?) habe ich immer das Gefühl, die Software nicht wirklich unter Kontrolle zu haben. Mit Modus ist es klarer. Das Modus-Konzept finde ich auch recht vertraut – in Aufbaustrategiespielen gibts auch oft einen Bau- und einen Auswahlmodus. Und was ist OSM schon anderes als ein großer Städtebaukasten? ;-) Das wird hier aber zugegeben schon sehr subjektiv … Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sachen finden im Wiki (was: Re: T aggen einer Einbahnstraße , Rad entgegengesetzt erla ubt?)
Florian Heer schrieb: Gehts eigentlich nur mir so, dass ich solche sachen im OSM-Wiki einfach nicht finde? Versuchs doch auch mal auf der Seite http://wiki.openstreetmap.org/index.php/De:Howto_Map_A Ist zwar recht neu und unvollständig, aber das cycleway=opposite aus dem Originalthread hätte sich wahrscheinlich finden lassen. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Einstieg geschafft! :-D
Steffen Voß schrieb: Es ist eine 20 Jahre alte Erkenntnis, dass Tastaturbedienung weniger effizient ist als Mouse-Bedienung: http://asktog.com/TOI/toi06KeyboardVMouse1.html Der Link zeigt mir eigentlich nur: Es gibt seit 20 Jahren Menschen, die der Meinung sind, Tastaturbedienung sei weniger effizient als Mouse-Bedienung. (Und dass Appelianer mit Tastaturbedienung nicht … ach nee, das lass ich lieber ;-)) Im Allgemeinen widerspricht das in einem so hohen Maß meinem empirischen Eindruck (nicht nur beim Selberarbeiten, sondern auch bei der Beobachtung anderer), dass mich das nicht überzeugen kann. Der Unterschied ist nämlich, dass man bei der Bedienung der Mouse nicht darüber nachdenken muss, was man macht. Selbst wenn Du Deine Tastenkürzel gut kennst, musst Du Deinen Gedanken unterbrechen und kurz überlegen, welche Funktion Du brauchst und dann das passende Kürzel dazu rauskramen und dann planen, wie Deine Finger die Tastenkombination greifen kann. Ähm, für eine Funktion muss ich mich auch bei der Maus entscheiden. Und was am Suchen des richtigen Buttons auf dem Bildschirm weniger Aufwand sein soll als das Suchen der richtigen Taste auf der Tastatur, ist mir auch nicht so klar. Interessant ist doch: Wieso geben wir Text nicht mit der Maus ein? Nun, weil die Eingabe von Text zwei Eigenschaften hat: 1. Es gibt zu jedem Zeitpunkt sehr viele mögliche Aktionen (mehr, als sinnvoll auf die Maustasten oder selbst in ein Kontextmenü passen). 2. Ein erfahrener Nutzer kann ohne Nachdenken die richtigen Tasten finden (schau dir mal ’ne gute Sekretärin an). Das zeigt dann auch, wozu man die Tastatur brauchen kann: Wenn eine Aufgabe komplex genug ist, dass es relativ viele, jeweils nicht allzu selten eingesetzte Aktionen gibt, die man ohne Zwischenschritte erreichen will. Natürlich: Wenn ein Programm so wenig unterschiedliche Aktionen hat, dass die Maustasten dafür völlig ausreichen, ohne dass man Buttons, Menüs usw. braucht, dann ist die Maus schneller. Ansonsten kann man unter Zuhilfenahme der Tastatur immer noch effizienter arbeiten. Ob OSM-Editing nun das eine oder das andere ist – Ansichtssache. Ich finde, es liegt schon ein wenig auf der Seite, wo man von Tastaturbefehlen profitiert. Ob das auch auf den konkreten Fall (Verschieben von Nodes) zutreffen muss, ist eine andere Frage, die ich nicht entschieden mit „nein“ beantworten würde – ich finde den nötigen Tastendruck nur nicht weiter störend. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Slippy map not working in Firefox
Hi, I happen to experience problems with openstreetmap.org and Firefox (3) on Linux, too. I’m not sure whether it is related, but the symptoms sound similar. No clue what’s causing it. Behavior: When opening openstreetmap.org, the general page displays properly, including zoom display, ruler, permalink and layer selector. The map, however, remains plain white. No errors in javascript console, cursor indicates loading activity, but there is no visible result for minutes. Status bar announces data transfer from www.paypal.com, apparently that “Make A Donation”-button was the last thing it received. When I use the layer selector to switch to Osmarender, I get a visible map almost instantly. Strangely, switching back to Mapnik after a while can cause the Mapnik layer to work (but not always). Once it has started working, it zooms and scrolls flawlessly. I can reproduce this behavior even with a fresh Firefox config without extensions (new user on local computer), informationfreeway.org does not cause this problem. It behaves like the Osmarender layer on openstreetmap.org. System and browser info: Ubuntu 8.04 Linux xxx 2.6.24-19-generic #1 SMP Fri Jul 11 21:01:46 UTC 2008 x86_64 GNU/Linux Firefox 3 (version as displayed by Synaptic: 3.0+nobinonly-0ubuntu0.8.04.1) Tests with other software: Firefox 3.0.1 on Windows XP _works_ Firefox 2 on Ubuntu does _not_ work Konqueror 3.5.9 on Ubuntu _works_ Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Nur nach dem Vorschlag von Tordanik müssten *alle* Altanwendungen geändert werden, um nicht plötzlich Alt- und Plan-Daten als Ist-Zustand misszuverstehen. Sie müssten ein einziges Mal geändert werden, die Einführung weiterer Werte etwa hätte keine zwangsläufige Anpassung mehr zur Folge – damit ist der Vorschlag sogar bewusst so gestaltet, dass er auf längere Sicht pflegeleichter ist als etwa das Konzept disused=yes/no, abandoned=yes/no etc. Einfach status != in_use = nicht verwenden. Und dass ab und zu Updates nötig sind, halte ich für unausweichlich. Sonst wären auch Dinge wie access=destination nicht möglich – wenn der Router das noch nicht kennt, wird erbarmungslos durchgeroutet. Übrigens hätte dann auch niemals disused=yes eingeführt werden dürfen, eines der Tags, das dieses Proposal ablösen will. Generell: Du bekommst kein vernünftiges Datenmodell hin, wenn alle Daten auch mit dauerhaft nicht mehr gepflegten Anwendungen unmissverständlich nutzbar sein müssen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[OSM-talk] [tagging] Feature Proposal - RFC - Status (disused objects and objects under construction)
Hi, I’ve created a proposal for objects under construction and disused/abandoned objects: http://wiki.openstreetmap.org/index.php/Proposed_features/Status The proposal would make it possible to tag such objects as status=construction/disused/abandoned/preserved Examples: * disused railway: railway=[railway type] status=disused (Note that it is possible to specify the type of railway as usual – unlike the railway=disused solution.) * motorway under construction highway=motorway status=construction * nuclear power plant under construction: power=generator power_source=nuclear status=construction Most importantly, the “status” tag could be applied to everything on the map – including buildings, airfields, military bases etc. Thus, it would be an easy and universal solution – until now we only have covered a few cases with highway=construction and railway=disused/abandoned/preserved. The proposal is in RFC status, so comments and suggestions are welcome. Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Beispiele: Nicht mehr genutzte Schienen: railway=[Railway-Typ] status=disused (Man beachte, dass – im Gegensatz zu railway=disused – die Art der Schiene wie gewohnt angegeben werden kann.) Im Bau befindliche Autobahn: highway=motorway status=construction Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Vor allem wäre das status-Tag explizit dafür gedacht, auf alles anwendbar zu sein – also auch Gebäude, Flugplätze, Militäranlagen etc. Damit hätten wir eine übersichtliche, einheitliche Lösung zu dem Thema – bisher existieren ja nur Insellösungen für highway und railway. Der Vorschlag ist ab heute in der RFC-Phase („Proposed“), Einwände und Verbesserungen sind also erwünscht. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Johann H. Addicks schrieb: Zumindest ein Datumstag wäre auch nicht schlecht. Also wann der Statuswechsel stattgefunden hat (bie disused) bzw wann er voraussichtlich stattfinden wird (bei construction). Ja, das wäre in diesem Zusammenhang brauchbare (und teils sogar in gedruckten Karten übliche) Information. Ich hatte auch daran gedacht, so etwas gleich mit im Proposal aufzunehmen, das dann aber bleiben lassen, da a) die Statusinformationen auch allein schon verwendet werden können und der Datumseintrag ohnehin in einem eigenen Tag am besten aufgehoben ist b) bei umfangreicheren Vorschlägen oft solche „Ich bin für X, aber Y lehne ich ab, falls Z durchkommt“-Abstimmungen entstehen (vgl. Proposal zu highway=path …) c) das Zeitformat wohl noch einiger Diskussion bedarf und tagübergreifend relevant ist. Insofern wäre dieses Feature ein gutes Folgeproposal. Nur dann müsste man sich auch noch Gedanken über das Zeitformat machen, damit dort nicht später x-mal nachgebessert werden muss falls Leute anfangen, den Verkehrsfunk abzubilden ;-). Also vielleicht gleich ISO in beliebiger Präzision in GMT? Also 200807201158? ISO wäre auch mein Favorit. Man könnte ggf. in Erwägung ziehen, Trennzeichen einzusetzen um die Lesbarkeit zu erhöhen, in dem Punkt bin ich aber eher unentschieden. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Tordanik wrote: Nicht mehr genutzte Schienen: railway=[Railway-Typ] status=disused (Man beachte, dass – im Gegensatz zu railway=disused – die Art der Schiene wie gewohnt angegeben werden kann.) Man beachte aber auch, dass an einer mit railway=art beschriebenen Stelle, nach deinem Vorschlag gar keine Schiene mehr liegt. Die derzeit gültige Vorschrift stellt die Realität besser dar. Bei status=disused liegt ebenso wie beim derzeitigen railway=disused sehr wohl noch eine Schiene, sie ist lediglich nicht mehr genutzt, daher i.d.R. überwuchert usw. Nichtsdestotrotz ist sie real existent und kann auch eindeutig einem der Typen zugeordnet werden. Hier ist die Definition des Proposals auch nahezu wörtlich identisch mit der Dokumentation von railway. Für „abandoned“ kommt dein Einwand eher zum Tragen. Ich sehe aber nicht wirklich einen Unterschied in der Darstellung der Realität, ob ich eine ehemalige Straßenbahnschine als „abandoned railway“ beschreibe oder als einen „tram-railway, der im abandoned-Status ist“. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry schrieb: Steht preserved für geplant? Ansonsten sollte das unbedingt mit berücksichtigt werden. „preserved“ = „konserviert“. Das Objekt ist also nicht mehr wirklich in Benutzung im Sinne des ursprünglichen Zwecks; es wird aber nicht abgerissen, sondern aktiv vor dem Verfall bewahrt, etwa aus historischem oder touristischem Interesse. Hab ich in dieser Form von railway übernommen. Für „geplant“ ist zwar noch nichts vorgesehen. Es spricht aber vom Konzept her absolut nichts dagegen, da ein „status=planned“ zu nehmen. Für das derzeitige Proposal habe ich mich halt lediglich auf Werte beschränkt, die in irgendeiner Form schon existieren, um die Entscheidung über Tagging-Struktur (da scheint es ja sehr wohl Diskussionsbedarf zu geben, wenn ich mir die ML so ansehe) und die Einführung neuer Werte getrennt zu halten. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. Deinen konzeptionellen Einwand verstehe ich voll und ganz. Ich bin die Fragestellung eben von folgendem Ausgangspunkt her angegangen: 1. Man sollte im Bau befindliche, aufgegebene etc. Versionen von _jedem_ Objekt, das wir in OSM taggen können, eintragen können, auch wenn man Zusatztags hat (wie power_source=nuclear). 2. Dies sollte für jedes Objekt in gleicher Weise möglich sein, alles andere erhöht den Lern- und Dokumentationsaufwand. Gerade Punkt 1 kann eben am einfachsten gelöst werden, wenn man einfach eine zusätzliche Information zu den bestehenden hinzufügt und wird (ebenso wie 2) von den bisherigen highway- und railway-spezifischen Ansätzen nicht geleistet. Hast du einen speziellen Gegenvorschlag? Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm schrieb: Ich bin die Fragestellung eben von folgendem Ausgangspunkt her angegangen: 1. Man sollte im Bau befindliche, aufgegebene etc. Versionen von _jedem_ Objekt, das wir in OSM taggen können, eintragen können, Aber mein Punkt war ja gerade, dass es solang es sich in Bau befindet eben noch gar keine Version von einem Objekt ist. Schön, dann formulieren wir es anders. Ich finde es sinnvoll, wenn man zu jeder Baustelle die Information hinzufügen kann, was da gebaut wird. Und dazu sollte man der Einfachheit halber das gleiche Tagging verwenden können, wie man es für fertiggestellte Dinge tut. Eine note ist keine echte Alternative, da nicht maschinell (etwa fürs Rendering) auswertbar. Ich möchte gerne die Baustelle des Atomkraftwerks anders darstellen können als die der U-Bahn. Wuerde Dein Vorschalg konsequent umgesetzt, so waere es nicht moeglich, eine Baustelle zu taggen, ohne dass man weiss, was da gebaut wird (something=anything, status=construction?) Es dürfte wohl kaum vorkommen, dass man nicht zumindest eine ganz grobe Klasse erkennt, z.B. ein Gebäude („building=yes, status=construction“) oder irgendeine Straße („highway=road, status=construction“). Prinzipiell hast du recht, dass ein reines „status=construction“ vom Modell her unschön ist, ich hatte auch nicht an eine Baustelle, sondern eben an objektbezogene Information gedacht, wie sie derzeit vereinzelt schon existiert. Verstehe ich richtig, dass du das Tagging, wie es derzeit im Einsatz ist (Straßenbaustelle als highway des Typs construction) aus dem gleichen Grund ablehnst? Ach ja, und hierzu: Eine Baustelle ist eine Baustelle und kein Kernkraftwerk. Ich wuerde eine Baustelle mit power=nucelar taggen, wenn wenn die Baufahrzeuge nuklear angetrieben sind. Das war einer der Gründe, weshalb ich die Semantik „Objekt im Zustand X“ gewählt habe, und nicht die Semantik „Baustelle von Objekt“ – eben damit sich die Zusatztags wie power_source=nuclear weiterhin klar auf das Objekt, und nicht auf die Baustelle beziehen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Zu jedem Objekttyp wäre doch eine Erfasung analog zu highway und rail möglich: power=construction construction=generator power-source=nuclear Ja, ich hatte erwartet, dass der Vorschlag kommt. :) Das ist m.E. eine der drei prinzipiellen Möglichkeiten (#3 wäre abandoned=yes/no, disused=yes/no, construction=yes/no etc.). Dieser von dir ins Spiel gebrachte Ansatz hat mir aus folgenden Gründen nicht so gut gefallen: * Welcher Tag wird ersetzt? Warum etwa heißt es nicht power=generator construction=nuclear power-source=power=construction – ok, weil power das „Haupt-Tag“ ist. Ist das immer klar erkennbar? Ich hab schon Dinge wie building=yes, amenity=... gesehen – ist dann building oder amenity das „Haupt-Tag“, dessen Wert mit construction auszutauschen ist? Und kann man das irgendwie allegemeingültig (d.h. nicht für jedes Paar von Tags extra) festlegen? * Erfinden eigener Werte Mit status=blah kann ich mir beliebige blahs ausdenken, beim objektkey=blah, blah=objektwert bin ich dagegen schon mal auf blahs beschränkt, die nicht selbst schon irgendein Key oder irgendein Value sind. Natürlich wird wohl niemand auf die Idee kommen, einen Status „primary“ einzuführen, aber ich wär mir nicht so sicher, alle Keys und alle Werte aller Keys zu kennen, wenn ich einen Status erfinde. * Erfinden eigener Werte 2: Softwareunterstützung Wenn ich diesen Wert blah nicht kenne, weiß ich außerdem nicht, ob es sich dabei jetzt um einen Status handelt oder um einen eigenen Wert. Das kann für alles mögliche nett sein zu wissen. Beispiel: Ich will mir eine Validatorsoftware schreiben, die festlegt, dass highway=stop_sign nur auf Nodes verwendet wird, highway=motorway dagegen nur auf Ways. Wenn ich jetzt einen Node mit so etwas highway=occupied_by_aliens occupied_by_aliens=motorway finde, kann ich nicht mehr validieren, weil ich nicht weiß, ob occupied_by_aliens ein highway-Typ oder ein Status ist. Bei einem highway=motorway status=occupied_by_aliens geht es dagegen problemlos. * Verständlichkeit Ich halte das Konzept power=construction construction=generator für absolut nicht intuitiv lesbar („power=construction ?“). Ein normales Objekttagging mit status=foobar lässt sich dagegen leicht als „aha, ein Objekt xy, das sich in foobarem Status befindet“ erkennen. * Dokumentation An sich handelt es sich hier ja um Werte von power, highway und letztlich jedem einzelnen anderen Tag. Die wird man aber dann nicht – wie es jetzt noch der Fall ist – bei jedem Key, wo sie möglich sind, (das wären nämlich schlicht alle) hineinschreiben wollen. Das passt nicht so ganz in unser derzeitiges Dokumentationsschema. Könnte man natürlich prinzipiell ändern, aber ich weiß erstmal nicht, wie. * Baustellen unbekannten Typs Daran hatte ich vorher nicht gedacht, aber da es ja einer von Frederiks Einwänden war … status=construction ohne sonstige Information ist sehr unschön, aber bei dem objekttyp=construction-Vorschlag ist eine Baustelle mit unbekanntem Objekttyp nicht nur unschön, sondern unmöglich. Puh, etwas lang geworden … *g* Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Heiko Jacobs schrieb: Dann ginge auch highway=cycleyway former=rail Ok, war ein highway=pedestrian area=yes former=residential dann früher mal ein Wohngebiet (landuse=residential) oder eine Wohnstraße (highway=residential)? Kurz, der Ansatz setzt voraus, dass man implizit weiß, zu welchem Key „rail“ gehört. Oder sollte dann da noch ein landuse=former oder landuse=abandoned stehen? construction=primary/residential/... wird ja tw. schon verwendet... Die generellen Nachteile dieser Idee siehe in meiner Antwort auf Norberts Mail. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hello again, Ich möchte gerne die Baustelle des Atomkraftwerks anders darstellen können als die der U-Bahn. Wir taggen im allgemeinen das, was in der physischen Welt sichtbar ist. Wenn jetzt zwei Baugruben nebeneinander ausgehoben werden, die eine soll mal ein Kernkraftwerk werden und die andre ein Schweinestall, dann gibt es in meinen Augen wenig Rechtfertigung dafuer, dies auf der Karte unterschiedlich zu modellieren. und wenn dann auf der einen Baustelle schon Kühltürme, Reaktoranlagen usw. stehen …? Dann unterscheidet sich das Objekt doch schon wesentlich stärker von einer Schweinestallbaustelle als von einem fertigen Atomkraftwerk. Ja, in der Phase „großes Loch“ stellt sich das etwas anders dar: Da macht äußerlich nur die Bautafel (und die Frage, ob Atomkraftgegner oder Tierschützer gegen das Projekt demonstrieren) den Unterschied. Mehr als ein Schild trennt aber auch Fuß- und Radweg nicht voneinander. Da aber nun – trotz der fehlenden Rechtfertigung – auf Karten üblicherweise nicht nur Fuß- und Radwege unterschieden werden, sondern ich auch schon im Bau befindliche U-Bahn-Linien und ähnliches in Stadtplänen gefunden habe, sehe ich durchaus einen praktischen Bedarf für solche Information. Das soll natürlich keinen daran hindern, sich alles mit status=construction undifferenziert als braune Baugrube rendern zu lassen. Aber wenn dies nun zum Anlass genommen wird, zu postulieren, dass man generell alle Objekte so taggen sollte, als ob sie schon existierten, und dann einfach noch ein status=construction dranhaengt, dann wuerde ich dagegenhalten und kuenftig eine Strassenbaustelle als landuse=construction_site mit note=Nordtangente Karlsruhe, Fertigstellung 2018 taggen ;-) Ich tagge oft Straßen, als ob sie jeder benutzen könnte, und hänge dann noch ein access=private dran. Irgendwie glaube ich aber nicht, dass wir uns da heute einig werden. ;-) Gute Nacht erstmal … Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schreibfehler im Wiki
Hi, Wenn du dich mit dem Thema auskennen, kannst du selbst die Seite „map“ verfassen. Bei openstreetmap.org erhalte ich: Search results From OpenStreetMap […] Von welchem Wiki sprichst also Du? MediaWiki erlaubt dem Nutzer, die Sprache der Oberfläche einzustellen, und zwar in den „my preferences“ rechts oben. Ich kann den Schreibfehler dann auch bestätigen. Da wir die Texte aber garantiert nicht selbst in alle die dort gelisteten Sprachen übersetzt haben, schätze ich mal, dass die Meldung schon in dieser Form mit dem MediaWiki geliefert wurde und vermutlich am besten dort korrigiert würde. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] General tagging strategy
Strategy 1: Legal status. (e.g. there's sign saying it's a cycleway) This is the most useful and most important one. It should be easy to find out, and it is objective information. It is also what people expect to find on their maps. The other things will probably only appear on specialist maps or be used for routing. Strategy 2: Common usage. (e.g. people are riding their bikes there, even if it may be forbidden -or- even though it's allowed to ride a bike here, it is a really bad (suicidal) idea to do so) That’s the worst strategy in my opinion, because common usage depends on 1 and 3/4 – why would people cycle illegally on unusable roads, and if they do, why should I care? It’s also rather subjective information, unless you actually provide some statistics. Strategy 3: Physical properties (e.g. gravel with a average corn size of 1/8th inch and an average of 3 bump holes between 2 and 4 inches in diameter and 1 to 2 inches deep per meter) In theory, this would be #2 on my list, because legal status and physical properties determine usability for all types of transport. (Which means that we could provide usability information for small data user communities. Imagine, for example, that we manage to get many cyclists enter data about cycleability into OSM. We then can provide good routing for cyclists, but have only vague estimates for inline skaters – unless the cyclists have provided us with actual physical properties from which the information about usability for inline skating can be derived). That being said, it is – unfortunately – extremely hard to a) find good tags that allow to enter all the relevant information b) enable software (routing apps etc.) to use the gravel corn size and bump holes in their algorithms and generate usable results in the process c) collect the data. Still, if someone succeeds at a), I’d encourage c). Strategy 4: Interpreted usability (e.g. usability for bikes is 2 on a scale from 1 to 5) Subjective, unpleasant from a modeling view (different kinds of information all stuffed into one, almost as bad as that highway tag) – but the only realistic way to get appropriate routing in all but very long terms. We’ll have to go for this, I guess. (We might want to discuss the numbers vs. descriptive values issue, though.) It won’t stop us from using the highly detailed strategy 3 data where it is available. In short, enter data from categories 1, 3, 4, with priority on 1. Tordanik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[Talk-de] Tag-Redundanz bei Multipolygon-Relation
Hallo, seit einer Weile ist die Wiki-Seite zur Multipolygon-Relation (http://wiki.openstreetmap.org/index.php/Relation:multipolygon) ja auf dem Stand, dass die Tags, die bereits auf outer stehen, auf inner wiederholt werden sollen. Mir erschließt sich nur nicht ganz, wo bei dieser Modellierung der Vorteil liegt. Meist will man ja das Loch mit etwas füllen – dafür braucht man dann einen eigenen Way. Außerdem hat man natürlich die Tags zweimal drinstehen, was keinen Informationsgewinn bringt, aber bei einer Änderung leicht zu widersprüchlichen Daten führt. Warum also diese redundante Wiederholung auf dem inner way – würde es nicht am outer allein (oder auch an der Relation selbst) reichen? (Nur um entsprechende Antworten zu vermeiden: Dass bestimmte Software das so haben will, ist kein Grund, die Modellierung anzupassen, sondern ggf. ein Grund, die Software anzupassen.) Grüße, Tordanik PS: Die in http://wiki.openstreetmap.org/index.php/Elements#Area beschriebene Methode für Areas mit Loch per C-Form ist durch multipolygon doch inzwischen überholt, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
