[Talk-de] amazing surprise
Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8" SGV5ISANCg0KSSd2ZSBnb3QgbmV3cyBmb3IgeW91IHRoYXQgZ29pbmcgdG8gc3VycHJpc2UgeW91 IGEgZ3JlYXQgZGVhbCwganVzdCByZWFkIHRoYXQgaW5mbyBodHRwOi8vd3d3LmNhcmFjY2lkZW50 bGVnYWxueS5jb20vbGFib3IucGhwP1VFOTBZV3hyTFdSbFFHOXdaVzV6ZEhKbFpYUnRZWEF1YjNK bg0KDQpTcGVhayB0byB5b3UgbGF0ZXIsIE1hcnRpbiBWb253YWxkDQoNCg== ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ☢some new stuff
Hey, I've got some new stuff for you, you'll definitely love it, take a look at https://is.gd/6g9eJn Yours sincerely, Martin Vonwald From: Openstreetmap allgemeines in Deutsch [mailto:talk-de@openstreetmap.org] Sent: Tuesday, August 08, 2017 10:25 AM To: matth...@regiert.org Subject: NAILED IT No he fucking doesn't. If you had any clue you'd know that autotune reacts very obviously to people who cannot hit the notes correctly, there's a "searching" warble that is indicative of someone who does not have pitch control. When autotune is used "because he fucking wants to" it is a simple slide into the note. Not a fucking wararhghsdgfskldgsdhjl around the note its supposed to be. Sent from Mail for Windows 10 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ❣what do you think about that?
Hi friend! I just wanted to show you my last article and to ask your opinion about it, please read it here http://persecute.lacefielddoor.com Thx, Martin Vonwald ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ✈Re: surprise!
Hi, I've got something awesome that is going to surprise you, just take a look http://www.gentlegiantsrescue-dogue-de-bordeaux-french-mastiffs.com/distance.php?e6e7 Sincerely yours, Martin Vonwald ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] wpt_symbol, wpt_description
2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Brückennummern
Da du ja auf das Wiki verweist, möchte ich dies ebenso machen: http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge Kurz zusammengefasst extra für dich: * bridge=yes - Attribut auf einem Weg, z.B. eine Straße(!), welche über(!) eine Brücke führt erhält zusätzlich bridge=yes * man_made=bridge - die Brücke selbst, also ein geschlossener Weg, welcher den Umriß der Brücke beschreibt. Beide Taggings ergänzen sich, d.h. bei größeren Brücken erhält jeder Weg der über die Brücke führt ein bridge=yes und mittels man_made=bridge wird der Umriß definiert und gleichzeitig festgelegt, welche Features alle zu dieser einen Brücke gehören. Am 7. April 2015 um 18:50 schrieb martin ringer martinrin...@hotmail.com: Typisch OSM, warum zwei Tagging Varianten für Brücke? man_made=bridge bridge=yes Ich kenn mich nicht mehr aus. Im Wiki steht zu eurer Diskussion: Für die Bauwerksnummer nutzen die meisten Kartierer das Attribut bridge_ref https://wiki.openstreetmap.org/w/index.php?title=DE:Key:bridge_refaction=editredlink=1 =*#*, da ref https://wiki.openstreetmap.org/wiki/DE:Key:ref= für die Nummer der Straße benutzt wird. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Maxspeed für 7.5t
Hi! Ich empfehle das hier: http://wiki.openstreetmap.org/wiki/Conditional_restrictions maxspeed:conditional=30 @ (weight=7.5) bg, Martin Am 8. April 2015 um 13:13 schrieb C.Brause chr_bra...@gmx.de: Hallo, ich habe hier die Situation, dass allgemein maxspeed=50 gilt. Zusätzlich gilt aber Tempo 30 für 7,5 t. Ich wäre über einen Taggingvorschlag dankbar. Im Moment habe ich mal maxspeed:hgv=30 verwendet. Das kommt dem zumindest am nächsten. Leider ist es nicht richtig, weil hgv meines Wissens 3.5t impliziert. Taginfo hat mir da leider auch nicht helfen können. Habt ihr Ideen? Viele Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] JOSM - Java Fehler bei Import
Hi! Am 7. April 2015 um 01:32 schrieb Paul Wölfel p...@woelfel.at: JOSM unterstützt zur Zeit nur Java 7, du hast jedoch 8 in Verwendung: Java version: 1.8.0_05, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM Funktioniert problemlos hier: Identification: JOSM/1.5 (8109 de) Linux openSUSE 13.1 (Bottle) (x86_64) Memory Usage: 165 MB / 1769 MB (78 MB allocated, but free) Java version: 1.8.0_05, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM VM arguments: [-DproxySet=xxx, -DproxyHost=xxx, -DproxyPort=xxx] Was mich allerdings stutzig macht: │VM arguments: [-Djava.library.path=/lib:/usr/lib]│ Wieso denn das? bg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Brückennummern
Am 6. April 2015 um 15:18 schrieb Friedrich Volkmann b...@volki.at: Ich finde, man sollte diese Nummern entweder einheitlich (bridge:ref=* oder man_made=bridge und darauf ref=*) mappen oder gar nicht. Meinungen? Genau wie du sagst: * Wenn nur bridge=yes direkt an der Straße erfasst ist, dann bridge:ref, denn bei ref weiß man dann nicht wofür das gilt. * Wenn die Brücke explizit erfasst ist, dann als ref zu man_made=bridge dazu. bg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Am 25. März 2015 um 16:19 schrieb Kevin Kofler kevin.kof...@chello.at: (bzw. sogar, ob überhaupt ein Widerspruch vorliegt). Es ist klar, dass kein(!) Widerspruch vorliegt. Die Tags surface und tracktype sind unabhängig von einander. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Heutige Massenedits der tracktype=* im DACH-Bereich
Am 23. März 2015 um 15:25 schrieb Friedrich Volkmann b...@volki.at: Bin für einen schnellen Revert. +1 Selbe Meinung. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 17. März 2015 um 11:03 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 17. März 2015 um 10:50 schrieb chris66 chris66...@gmx.de: Wenn also KFZ-Router tracks aus Performancegründen gar nicht mit aufnehmen in ihren Graphen dann sehe ich das nicht als Fehler an. das kann jeder so machen, wie er denkt, klar spart man damit sehr viel Platz und gewinnt Performance, nur halt für den Preis, dass das Netzwerk unvollständig ist, und manche Adressen daher nicht erreichbar, auch wenn die Daten in OSM korrekt sind. Eigentlich will man das nicht, aber wenn der Router anders nicht klarkommt, oder die Entwickler entscheiden, dass es wichtiger ist, Ressourcen zu schonen als auch die letzten 0,x % Anwender richtig zu bedienen, dann ist das deren gutes Recht. Wenn ich nur über eine solche Situation erreichbar wäre, würde ich das allerdings auch als Fehler bezeichnen. Wenn KFZ-Router alle Wege verwerfen, welche mit highway=track ohne weitere Access-Tags gekennzeichnet sind, würde ich dies als korrekt ansehen. Wenn sie allerdings auch z.B. einen Weg mit highway=track und vehicle=destination verwerfen, ist dies mEn ein klarer Fehler. Fakt bleibt aber auch: wofür sich die Entwickler auch entscheiden, es ist ihr gutes Recht. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Am 19. Februar 2015 um 23:06 schrieb Garry garr...@gmx.de: Am 19.02.2015 um 11:31 schrieb Martin Vonwald: Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal Woher hat er die Information? Aus dem Preprocessing, Tags oder schaut er sich jedesmal den Verlauf an? Letzteres könnte langwierig werden, oder? Aus dem Preprocessing wo auch der Streckenverlauf ausgewertet wird. Tags wären völlig sinnlos, denn wofür sollen sie gelten: den Fußgänger, das Fahrrad, den Kombi, den Kleinlaster oder den Sattelschlepper? Nur falls das nicht offensichtlich ist: auf ein Fahrrad haben enge Kurven deutlich weniger Auswirkung als auf einen Sattelschlepper und einem Fußgänger ist es völlig egal. Auch das Höhenprofil wirkt sich unterschiedlich aus. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] heise berichtet ueber osm.org-Routing integration
Hi! Am 19. Februar 2015 um 10:46 schrieb Eifelhunde eifelhu...@gmx.de: Sehe ich weniger problematisch, oder werden kurvenreiche Strecken auch berücksichtigt? Häufig sind doch diese nicht beschränkt, erlauben aber wegen der vielen Kurven nur geringe Geschwindigkeiten ??? es gilt in jedem Land ein generelles Maxspeed (in D außer Autobahnen) Ich versteh die Anmerkung nicht, es besteht doch nicht die Pflicht so schnell zu fahren - selbst wenn Schilder die Geschwindigkeit weiter beschränken ist die Geschwindigkeit keine Pflicht Kein professioneller Router geht davon aus, dass man die maximal erlaubte Geschwindigkeit auch tatsächlich fahren kann. Je nach Verlauf der Straße werden deutlich niedrigere Geschwindigkeiten angenommen. Auf einer völlig geraden Autobahn im ebenen Gebiet nimmt ein guter Router eine Geschwindigkeit nahe der erlaubten an, idR ca. 5%-10% darunter. Auf einer Passstraße, wo sich eine Serpentine an die nächste reiht, interessiert einen professionellen Router die maximal erlaubte Geschwindigkeit nur noch am Rande und es werden so Geschwindigkeiten z.B. im Bereich von 20-50km/h unterstellt, selbst wenn dort 100km/h erlaubt ist. Diese Geschwindigkeiten werden dann für die Routenfindung verwendet. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzfrage: Zuarbeit für Papierkarte
Am 27. Januar 2015 um 11:29 schrieb Erik Heinz eh1110-...@42net.de: Wir werden also wohl oder übel die Arbeit nochmal machen müssen. Frage: wäre es denn besser, wenn (jeder) Kartenverlag seine eigenen Daten einfach mit OSM-Daten verbessern dürfte ohne irgendetwas zurückzugeben und das ganze dann (teuer?) verkauft? Alles kann man nicht haben: wenn man sich Geld sparen und OSM-Daten zum Verbessern der eigenen Daten verwenden will, muss man eben etwas zurückgeben. Ist das unfair? Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzfrage: Zuarbeit für Papierkarte
Hi! Am 26. Januar 2015 um 13:00 schrieb Erik Heinz e...@iks-jena.de: Natürlich ohne dass die komplette Karte (die ja letzlich eine abgeleitete Datenbank darstellen würde) unter ODbL gestellt werden muss. Wäre sie das? Inwieweit sollte eine Papierkarte eine abgeleitet Datenbank sein? Ich nehme an, du meinst eigentlich die Daten hinter der Papierkarte? Wenn wir davon ausgehen, dass sie über eine bestehende Straßenkarte nur einen Layer mit Radwegen drüber legen, wäre nur die Daten(!) dieses Layer eine abgeleitete Datenbank. Wenn dieser Radwege-Layer 1:1 aus OSM-Daten besteht, sollte eine Nennung auf der Papierkarte ausreichen. Aber - und jetzt kommen wir zurück zur abgeleiteten Datenbank - wenn der Verlag Daten aus OSM entnimmt, diese mit bestehenden Daten vermischt und daraus den Radwege-Layer macht, dann wäre das eine abgeleitete Datenbank und diese wäre unter der ODbL zu veröffentlichen. So verstehe ich die Lizenz. Das ist für den Verlag natürlich keine Option, denn die OSM-Daten wären nur ein kleiner Teil der gesamten Kartendaten und nicht zuletzt müssen andere Lizenzvereinbarungen beachtet werden. Die anderen Lizenzvereinbarungen sind nicht wichtiger oder unwichtiger als die ODbL ;-) Die Rechercheergebnisse des Vereins zu veröffentlichen, wäre dagegen kein Problem - wenn sie nicht ohnehin in OSM eingepflegt werden. Ich denke das wird nicht reichen. Wenn der Verlag Daten des Radwegenetzes entnimmt und mit eigenen Daten vermischt, dann muss er das Gesamtergebnis (d.h. das gesamte Radwegenetz) auch unter der ODbL veröffentlichen. Könnte man alternativ die Zustimmung der betreffenden Bearbeiter einholen? Theoretisch ja, praktisch nein. Denn es gibt nicht den einen Bearbeiter einer Radroute. Diese basiert ja auf den Wegen und Straßen von vielen anderen Beitragenden. Natürlich kann man aber z.B. die GPS-Tracks oder sonstigen Aufzeichnungen von einzelnen Beitragenden sammeln. Über kompetente Aussagen würde ich mich sehr freuen. Ob sie kompetent ist, weiß ich nicht. Es ist auf jeden Fall meine Aussage, ich hoffe sie hilft. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Wohnpark als Relation
Am 26. Januar 2015 um 21:19 schrieb Friedrich Volkmann b...@volki.at: On 26.01.2015 20:23, Stephan Bösch-Plepelits wrote: Wär das nicht ein typischer Fall für eine site-relation? http://wiki.openstreetmap.org/wiki/Relation:site Nein, denn It is not necessary or appropriate to use a relation when all the elements contained within the boundary of the site belong to the site, and no elements beyond that boundary do belong. +1 Wenn alles innerhalb eines zusammenhängenden Gebietes liegt, reicht eine einfache Fläche. Keep it simple! Wenn etwas auf mehrere Gebiete verteilt ist, kann die site-Relation Sinn machen - vorausgesetzt es gibt keine andere Möglichkeit die Zusammengehörigkeit der Teilgebiete festzulegen bzw. zu erkennen. bg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Entscheidungsfindung und Toleranz bei OSM
Hi! Am 25. Januar 2015 um 18:12 schrieb Stephan Wolff s.wo...@web.de: Mich erschreckt die fehlende Toleranz und der fehlende Respekt vor den Daten anderer Mapper. Ich hoffe, dass die Entscheidungsfindung durch Löschen von Daten nicht zur Regel in OSM wird. Obwohl ich auch für dafür bin, diese Relation als veraltet zu kennzeichnen, bin ich strikt dagegen sie zu löschen. In OSM gilt noch immer der Grundsatz, dass jeder alles eintragen darf, solange damit nicht anderen auf die eine oder andere Art geschadet wird. Wenn jemand diese Relation eintragen will, soll er das tun. Wenn jemand diese Relation auswerten will, soll er das tun. Wenn jemand das Gegenteil will, soll er das genau so tun. Daten die mich nicht interessieren, ignoriere ich. Mein Hirn ist durchaus in der Lage diese unglaubliche geistige Leistung des Ignorierens zu bewältigen. Ich bin mir sicher, dass all jene die jetzt groß zur Löschorgie aufrufen, dies auch schaffen würden. Ignorance is bliss. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deprecation von associatedStreet-Relationen
Am 22. Januar 2015 um 09:27 schrieb chris66 chris66...@gmx.de: welcher (separat gemappte) Bürgersteig Für einige könnte das ein Hauptgrund sein, die street-Relation loszuwerden... Ich werde mich da aber eher heraus halten und anderen den Feldzug überlassen ;-) Have fun, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Hi! Da die Nutzung von maxspeed:variable kontinuierlich ansteigt, möchte ich euch nochmals auf das entsprechende Proposal hinweisen: https://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich überlegen, da es nicht nur die Information liefert, dass das Geschwindigkeitslimit variabel ist, sondern zusätzlich: * das höchste mögliche(!) Geschwindigkeitslimit * den Grund(!) für das variable Limit Ich halte beides für potentiell wertvolle Information für Datenkonsumenten. Beispiel: Auf Autobahnen in Österreich gilt üblicherweise ein Geschwindigkeitslimit von 130 km/h. Autobahnen, welche größere Städte durchqueren, verfügen jedoch häufig über ein variables Limit und recht häufig ist das maximale Limit 80km/h. 130km/h oder 80 km/h ist ein ziemlicher Unterschied. Wenn wir nur die Information liefern, dass das Limit variabel ist, welches Limit soll ein Datenkonsument annehmen? Vielleicht ist es schneller die Stadt zu umfahren, da dort normalerweise 130 km/h gilt? Ich möchte vorschlagen die Empfehlung zu maxspeed=signals aus dem Wiki zu entfernen und stattdessen auf maxspeed:variable=Grund + maxspeed=maximal mögliches Limit zu verweisen. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Am 19. Dezember 2014 um 11:44 schrieb Friedrich Volkmann b...@volki.at: maxspeed=signals wird über 5000x verwendet, ist also in use und muss daher im Wiki dokumentiert bleiben. Wo habe ich das Gegenteil behauptet? Es liegt ungefähr gleich auf mit maxspeed:variable=*, und vermutlich stammt ein guter Teil dessen von dir... Nette Unterstellung. Leider mappe ich schon seit ewigen Zeiten praktisch nichts, trotzdem steigen die Zahlen kontinuierlich. Die neuen Zahlen habe ich heute auf meiner Watchlist entdeckt. Wenn du das Proposal gut findest, solltest du den Autor dazu bewegen, es einer Abstimmung zuzuführen. Schleißlich gibt es seit etwa 1 Jahr keine Veränderung oder Diskussion mehr an diesem Proposal. Ich glaube nicht an Abstimmungen, wo 10-20 Leute meinen, darüber entscheiden zu können, was tausende Mapper zu tun oder zu lassen haben. Was der Autor machen will oder nicht, sei ihm überlassen. Ich finde, dass weder die eine noch die andere Möglichkeit optimal ist. maxspeed=signals allein fehlt die Information über die Maximal- bzw. Normalgeschwindigkeit, und maxspeed:variable=* fehlt die Information, wie die Geschwindigkeit angezeigt wird. Durch ein Zusatztag jederzeit zu ergänzen. Du darfst gerne eines vorschlagen. Die Werte von maxspeed:variable=* taugen mir ebenfalls nicht. Ausgezeichnetes Argument. Gut begründet und umfangreiche Lösungsvorschläge. Ursprünglich war nur =yes vorgesehen, und solche Tags weisen immer darauf hin, dass der Key besser ein Value sein sollte. Ursprünglich = Vergangenheit. Den Grund (peak_traffic usw.) anzugeben ist Kaffeesudleserei. Nirgends ist ersichtlich, in welchen Fällen die Geschwindigkeit herabgesetzt wird. Mapper vor Ort sollten den Hauptgrund wissen. Bitte dem Grundsatz we map what we see treu bleiben. Auf der A2 und der Südosttangente wird die Geschwindigeit mittels Anzeigen oft bei viel Verkehr herabgesetzt, aber auch bei Baustellen, Unfällen, Geisterfahrern... No na net! Da fällt mir jetzt nur die Signatur von jemandem aus dem Forum ein: Kopf - Tisch - bumms. Und wenn ein UFO dort landet, dann wird die A2 sogar komplett gesperrt! Mir würde besser gefallen: maxspeed=80 + maxspeed:type=signals Der Wert signals impliziert schon, dass sich die Anzeige ändern kann. Niemand hindert dich daran, dieses Zusatztag zu verwenden. Auch maxspeed=signals ließe sich reparieren, indem man mit einem Zusatztag eine konkrete Zahl angibt, z.B. maxspeed=signals + max_maxspeed=80. max_maxspeed? ... Aber das neue Tag müsste dann halt den Routern beigebracht werden. Man könnte natürlich auch auf die komplett abwegige Idee kommen, ein Tag einfach immer für das selbe zu verwenden. Danke für deinen Beitrag. Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Need help to fix? osm data in german
Offensichtlich meint er, dass das website-Tag hier nicht hingehört. Und
wenn ich mir das so ansehe, würde ich ihm auch eher zustimmen.
2014-12-17 12:08 GMT+01:00 Jochen Topf joc...@remote.org:
Keine Ahnung, warum der an mich geschrieben hat und was er will. Wenn
jemand
sich berufen fühlt...
Jochen
- Forwarded message from Yves Pratter yves.prat...@gmail.com -
Date: Wed, 17 Dec 2014 11:16:18 +0100
From: Yves Pratter yves.prat...@gmail.com
To: Jochen Topf joc...@remote.org
Subject: Need help to fix? osm data in german
Hi,
I send you this message because I don’t understand your language. I see a
lot of objects with the same website and I check only one, but this is a
wayside cross.
I don’t think there is really a web server for one cross ;D
It’s probably a source:website. Could you talk to the user or send this to
the german community ?
Thanks,
—
Yves
Wegekreuz https://www.openstreetmap.org/node/391458035/history
{
type: node,
id: 391458035,
lat: 50.9439267,
lon: 6.0990637,
tags: {
addr:city: Übach - Palenberg,
addr:postcode: 52531,
addr:street: Wurmstraße / Heckstraße,
description: Werksteinkreuz mit Korpus, Korrektur Sockel in
Kunststein mit Marmorplatte und Inschrift wohl Anfang 20. Jahrhundert,
heritage: yes,
historic: wayside_cross,
image:
https://upload.wikimedia.org/wikipedia/commons/0/0f/%C3%9Cbach-Palenberg-Frelenberg_Denkmal-Nr._3%2C_Wurmstra%C3%9Fe%2C_Heckstra%C3%9Fe_%284944%29.jpg
,
name: Wegekreuz,
note: 50° 56' 37,5\ N 06° 05' 56,7\ O,
start_date: 1900,
website: www.limburg-bernd.de,
wikipedia: de:Liste der Baudenkmäler in Übach-Palenberg
}
},
http://overpass-turbo.eu/s/6zk http://overpass-turbo.eu/s/6zk
/*
This has been generated by the overpass-turbo wizard.
The original search was:
“website=www.limburg-bernd.de global”
*/
[out:json][timeout:25];
// gather results
(
// query part for: “website=www.limburg-bernd.de”
node[website=www.limburg-bernd.de];
way[website=www.limburg-bernd.de];
relation[website=www.limburg-bernd.de];
);
// print results
out body;
;
out skel qt;
- End forwarded message -
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/
+49-173-7019282
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Need help to fix? osm data in german
2014-12-17 12:41 GMT+01:00 Mark Obrembalski m...@obrembalski.de: On 17.12.2014 12:13, Martin Vonwald wrote: Offensichtlich meint er, dass das website-Tag hier nicht hingehört. Und wenn ich mir das so ansehe, würde ich ihm auch eher zustimmen. Die Einzelseite zu dem Kreuz ist offenbar http://www.limburg-bernd.de/DenkUeb/Nr.%203.htm Von der angegebenen Hauptseite kommt man da nur mit ein wenig Suchen hin. So gesehen könnten wir auf jedes Objekt website=www.google.com draufgeben, oder? Mal abgesehen davon, dass der direkte Link gesetzt sein sollte, bin ich mir nicht so sicher ob unbedingt eine private Sammelwebseite verlinkenswert ist. Ist aber nicht meine Baustelle, daher nur als Denkanstoß gedacht. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Need help to fix? osm data in german
Auszug aus dem Impressum von www.limburg-bernd.de: Der Urheber räumt Ihnen ganz konkret kein Nutzungsrecht ein, um sich eine private Kopie für persönliche Zwecke anzufertigen. Ich meine, dass es so eine Seite definitiv nicht wert ist irgendwo verlinkt zu werden. Martin Am 17. Dezember 2014 um 12:48 schrieb Martin Vonwald imagic@gmail.com: 2014-12-17 12:41 GMT+01:00 Mark Obrembalski m...@obrembalski.de: On 17.12.2014 12:13, Martin Vonwald wrote: Offensichtlich meint er, dass das website-Tag hier nicht hingehört. Und wenn ich mir das so ansehe, würde ich ihm auch eher zustimmen. Die Einzelseite zu dem Kreuz ist offenbar http://www.limburg-bernd.de/DenkUeb/Nr.%203.htm Von der angegebenen Hauptseite kommt man da nur mit ein wenig Suchen hin. So gesehen könnten wir auf jedes Objekt website=www.google.com draufgeben, oder? Mal abgesehen davon, dass der direkte Link gesetzt sein sollte, bin ich mir nicht so sicher ob unbedingt eine private Sammelwebseite verlinkenswert ist. Ist aber nicht meine Baustelle, daher nur als Denkanstoß gedacht. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] lanes=x vs. xxx:lanes=a|b|c
Ich kann mich noch halbwegs an die endlose Diskussion erinnern. Das Hauptproblem damals war, dass nicht einmal die unterschiedlichen Sprachversionen annähernd gleich waren. Hier stand das, dort stand was anderes. Also habe ich mal versucht etwas Ordnung reinzubringen. Das Ergebnis ist natürlich erwartungsgemäß, um nicht OSM-gemäß zu sagen: zuerst schreien die einen, dann jammern die anderen und am Ende macht sowieso jeder was er will. Ist prinzipiell ja auch nicht (ganz) schlecht, so funktioniert nun mal OSM und nicht über Votings und Approvals und Wiki-fiddling-at-its-best. Aber nicht mal da sind sich alle einig ;-) Am Ende hat man halt das Problem, dass aus dem ganzen Datenwust irgendjemand etwas Sinnvolles herauszaubern soll. Und zaubern ist hier das richtige Wort, denn ohne klare und vor allem gleichbleibende Definitionen, tut sich jeder Datenkonsument schwer. Ich kann mich noch erinnern, als viele geschrien haben Nein, nein, Abbiegespuren auf Autobahnen können wir bei lanes nicht zählen. Unmöglich. Da müssen wir ja ständig splitten.. Wenigstens das hat sich nicht durchgesetzt. Jetzt jammert natürlich das andere Ende, dass lanes keine Fahrradspuren mitzählt... Und das Beste an dem Ganzen ist, dass es im konkrete Fall völlig egal ist ob xxx:lanes und lanes=x die selben Spuren betrachten oder nicht. Wenn ein Datenkonsument xxx:lanes unterstützt, hat er keinen Grund sich lanes=x anzusehen, er hat schon alle Informationen. Wenn es xxx:lanes nicht gibt, sieht man sich halt lanes=x an. Und wenn es das auch nicht gibt, dann rät man halt gut. Insofern ist es aus Konsumentensicht völlig egal, was xxx:lanes berücksichtigt und was lanes=x, Hauptsache es ist klar definiert. Der Ruf, die Bedeutung von lanes so abzuändern, dass einfach alle Spuren gezählt werden, hat ja nur einen Grund: die Mapper wollen Kontrollmöglichkeiten haben. Ich glaube, man kann mir nicht vorwerfen, gegen Mapper-freundliche Taggingschemen zu sein. Im konkreten Fall reicht es aber, wenn man zur Kontrolle eine Visualisierung der Spuren hat. Daran wird ja auch von verschiedenen Seiten gearbeitet. Zusätzliche Kontrolle wie z.B. das die Anzahl der spurabhängigen Werte für alle Tags identisch sein muss, gibt es ja vereinzelt bereits und diese werden sicher auch mehr mit der Zeit. Langfristig(!) kann man sich auch überlegen, ob man lanes=x überhaupt in Kombination mit xxx:lanes haben will oder in so einem Fall nicht lanes=x einfach entfernt wird. Alle Informationen, die lanes=x in diesem Fall enthält, hat man ja auch in den xxx:lanes-Schlüsseln. Und bevor man mir jetzt alles mögliche an den Kopf wirft, bitte ich darum, nochmals das erste Wort dieses Absatzes zu lesen, das vor dem Rufzeichen ;-) Beste Grüße, Martin Am 15. Dezember 2014 um 17:51 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 15. Dezember 2014 um 14:04 schrieb Martin Vonwald imagic@gmail.com : I möchte festhalten, dass ich selbst nicht glücklich über die Definition des lanes-Schlüssel bin. Aber die Definition ist so seit Urzeiten und ich werde sicher nicht versuchen sie zu ändern (aktuell 4,5 Mio mal in Verwendung) ich kann mich ehrlich gesagt nicht erinnern, dass solche Ausnahmeexzesse wie temporäre Standstreifen (die normalerweise nicht für den Verkehr frei sind) werden bei den lanes mit eingerechnet und Abbiegespuren können beim lanes-Zählen weggelassen werden seit Urzeiten in der lanes-Definition sein sollen. Die Urzeiten-Definition ist sowas wie lanes gibt die Anzahl der Fahrspuren wieder. Bis vor 2-3 Jahren war die Wikiseite auch gar nicht dermaßen gefüllt mit Sonderregeln, bei denen z.T. der Verdacht besteht, dass sie sich eingeschlichen haben, ohne dass je ein Proposal dazu gemacht wurde, oder es allgemeiner, verbreiteter Konsens gewesen wäre. Du bist allerdings der letzte, dem man einen Vorwurf machen könnte, hast Du doch eine entsprechende Diskussion auf tagging angestoßen (mit großer Beteiligung damals) http://lists.openstreetmap.org/pipermail/tagging/2012-April/009783.html und das Ergebnis im Wiki dokumentiert: http://wiki.openstreetmap.org/w/index.php?title=Key%3Alanesdiff=766082oldid=759416 Ich würde das aber trotzdem nicht als heilige Kühe sehen, und wenn bestimmte Regeln aus heutiger Sicht unsinning erscheinen, kann man das vielleicht schon noch korrigieren. Lanes-tagging ist ausserhalb der Kern-OSM-Länder noch eher nicht so etabliert. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] lanes=x vs. xxx:lanes=a|b|c
Hi! Da ich in letzter Zeit häufig Anfragen diesbezüglich bekam, möchte ich aufmerksam machen auf eine Eigenheit in Bezug die Werte des lanes-Schlüssel und die Anzahl von spurabhängigen Werten in beliebigen xxx:lanes-Schlüsseln. * Die Anzahl von spur-abhängigen Werten innerhalb eines beliebigen xxx:lanes-Schlüssel ist gleich der Anzahl von Fahrspuren auf der Straße, unabhängig deren Breite und unabhängig welchen Fahrzeugen diese gewidmet sind. [1] * Der Wert des lanes-Schlüssel ist gleich der Anzahl von Fahrspuren voller Breite, welche für den motorisierten Verkehr verfügbar sind. Es gibt noch weitere Ausnahmen, für Details siehe [2]. Daher muss der Wert des lanes-Schlüssels gleich oder kleiner(!) sein als die Anzahl der Werte in einem beliebigen xxx:lanes-Schlüssel. Beispiel: lanes=2 turn:lanes=through|through|right - drei Werte bicycle:lanes=yes|designated|yes - drei Werte Dieses Beispiel ist korrekt, da es nur zwei Fahrspuren gibt für den motorisierten Verkehr. I möchte festhalten, dass ich selbst nicht glücklich über die Definition des lanes-Schlüssel bin. Aber die Definition ist so seit Urzeiten und ich werde sicher nicht versuchen sie zu ändern (aktuell 4,5 Mio mal in Verwendung) Daher möchte ich alle bitten davon abzusehen mich aufzufordern den JOSM-Stil [3] anzupassen um in obigem Beispiel oder einer ähnlichen Situation einen Fehler anzuzeigen. Es ist sehr schwer die access-Restriktionen innerhalb eines Stiles auszuwerten, daher kann ich nicht alle interpretieren und daher zeigt der Stil nur dann einen Fehler, wenn der Wert des lanes-Schlüssels größer als die Anzahl der spurabhängigen Werte ist. Danke, Martin P.S: Wenn jemand die Definition des lanes-Schlüssel ändern will und einen weltweiten Konsens darüber erzielt, werde ich den Stil selbstverständlich innerhalb einer Minute anpassen. [1] http://wiki.openstreetmap.org/wiki/DE:Lanes [2] http://wiki.openstreetmap.org/wiki/DE:Key:lanes [3] http://josm.openstreetmap.de/wiki/De%3AStyles/Lane_and_Road_Attributes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Am 11. Dezember 2014 um 15:06 schrieb fly lowfligh...@googlemail.com: Bei Mehrzweckspur: lanes=3 + lanes:both_ways=1 + (optional falls irgendwie ersichtlich) turn:both_ways=left turn:both_ways=left;merge_to_right ? Guter Punkt! Für's Einfädeln passt das merge_to_right . ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Einfachste Lösung wäre wohl: Bei Grüninseln: lanes=2 + traffic_calming=island Bei Mehrzweckspur: lanes=3 + lanes:both_ways=1 + (optional falls irgendwie ersichtlich) turn:both_ways=left Am 9. Dezember 2014 um 00:44 schrieb Tirkon tirko...@yahoo.de: Moin, in einer Ortsdurchfahrt sind die beiden gegenläufigen Richtungsfahrspuren mehr oder weniger in der Mitte durch eine sogenannte Mehrzweckspur getrennt. Den Begriff hat die Verkehrsbehörde über die Presse verbreiten lassen. Diese mittlere Spur unterscheidet sich von den beiden Richtungsfahrbahnen durch einen leicht helleren Asphalt. Sie wird immer wieder durch bepflanzte Verkehrinseln unterbrochen, wobei teilweise eine Überquerungshilfe für Fu0gänger/Radfahrer eingebettet ist. Die Inseln sorgen dafür, dass die mittlere Mehrzweckspur - wie beabsichtigt - nicht vom fließenden Durchgangsverkehr befahren wird. Die Mehrzweckspur dient laut Presse zum Ein- und Ausfädeln von Linksabbiegern auf/von Grundstückseinfahrten und kleinen Nebenstraßen sowie zum gelegentlichen Überholen. Nur an wenigen Stellen ist die Mittelspur durch weiße Streifen von den durchgehenden Richtungsfahrspuren getrennt, nämlich wenn sie beampelt zur echten Linksabbiegespur auf größere Straßen mit Richtungspfeilen auf der Fahrbahn wird. Momentan ist die Straße bei OSM als zwei getrennte Richtungswege eingetragen, was dem funktionalen Charakter entspräche. Wollte man sie streng nach den Regeln mappen, müsste man sie suboptimalerweise wegen der vielen Inseln ständig verzweigen und zusammenführen. Gibt es da eine bessere Möglichkeit? ergänzende Info: Unmittelbar neben der Straße verläuft noch eine Güterzugstrecke mit zig Bahnübergängen durch den Ort. Bisweilen sind Bushaltestellen zwischen Bahn und Straße eingefügt. Dieses ganze Paket wird beidseitig von abgesetzen Fuß-/Radwegen eingerahmt, wobei einer keine entsprechende Beschilderung aufweist. Seit die Straße mit der Mehrzweckspur versehen wurde, läuft der Verkehr deutlich reibungsloser. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Am 8. Dezember 2014 um 11:55 schrieb 715371 osmu715...@gmx.de: Am 07.12.2014 um 19:26 schrieb Martin Vonwald: Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. Weil sich cycleway:width auf den Radweg bezieht Es ist ein highway=cycleway. und width sich auf den gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde). Mein Informationsstand ist, dass sich width bei Fahrbahnen immer auf die Fahrbahn bezieht und den Gehsteig nicht miteinbezieht. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 5. Dezember 2014 um 16:10 schrieb Tobias Knerr o...@tobias-knerr.de: Am 05.12.2014 13:19, schrieb Martin Vonwald: Vom Prinzip her ist bicycle:lanes=...|designated|... und cycleway:lanes=|lane| identisch. Welche Variante besser ist, kann ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes. Ich sehe hier einige Probleme: * Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre als forward/backward: Wie mappe ich Radwege, die in beide Richtungen nutzbar sind? Gute Frage, aber noch keine Antwort. Wobei ich mir hier gar keine Meinung zutraue ohne viele Beispiele gesehen zu haben. Solche Radwege ohne bauliche Trennung sind ja nicht so häufig. Daher sollten wir uns erstmal ansehen wann diese vorkommen um eine Idee vom Konzept dahinter zu bekommen. * Können auch Parkspuren und Gehsteige in die lane-Liste eingebaut werden? Wenn ja, wie? Parkspuren theoretisch ja, auch wenn ich kein Freund davon bin. Gehsteige würde ich nein sagen, da es ja keine Spuren für irgendwas sind. Bei Gehsteigen würde ich bei dem bewährten Konzept mit den sidewalk-Tags (inkl. Sub-Tags und ohne separate Wege) bleiben. * Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders? Jeder der mit xxx:lanes-Tags arbeitet, sollte sich vorstellen, dass er nur die eine Spur sieht und gedanklich alle andere ausblenden und alle xxx:lanes-Tags zu xxx reduzieren. In deinem Beispiel bleibt dann ein Weg übrig, welcher nur für Radfahrer zulässig ist. Welche Breite würdest du annehmen für einen Weg, welcher nur für Radfahrer erlaubt ist? Das elegante an der :lanes-Erweiterung ist, das wir eigentlich keine neuen Schlüssel haben mir neuen Bedeutungen. Analog zu :forward/:backward definieren wir nur, dass der Wert eben nicht für den ganzen Weg. Der Suffix :forward/:backward ändert ja auch nicht die Bedeutung des Hauptschlüssels, sondern nur wofür er gilt. Bei :lanes ist es erst einmal das selbe (der einzelne(!) Wert gilt nur für eine Spur) mit der Erweiterung, dass wir die einzelnen Werte der einzelnen Spuren alle zusammen in den Wert des xxx:lanes-Schlüssels packen. Deshalb bin ich auch der Meinung, dass es keine Sonderbehandlung für xxx:lanes-Schlüssel geben sollte. Man muss nur die Werte auf die einzelnen Spuren zuweisen und dabei die xxx:lanes-Tags zu xxx reduzieren. Datenkonsumenten können dann die einzelnen Spuren ähnlich zu individuellen Wegen verarbeiten. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 6. Dezember 2014 um 02:04 schrieb 715371 osmu715...@gmx.de: Was ist eigentlich mit solch einem Problem: https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg turn:lanes=left|through|cycleway:through|right ? Bitte fangt nicht an, die Bedeutung von turn zu verändern. Im Beispiel wäre es turn:lanes=left|through|through|right + bicylce:lanes=...|...|designated|yes Würdet ihr Barrieren wie Zäune, die zwischen Fahrbahn und Radweg (cycleway=track) stehen, als eigene Wege oder Knoten erfassen oder irgendwie anders? Ich gehe davon aus, dass cycleway=track gemappt ist. Als Wege. Ich verstehe deine Frage nicht wirklich: wie sonst? Einen Zaun haben wir schon immer als Weg erfasst. Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei einem stinknormalen Radweg die Breite taggen? Gibt es. Z. B. hier: https://www.openstreetmap.org/way/293395597 Ok. Warum man hier cycleway:width und nicht einfach width verwendet, verstehe ich zwar nicht, aber wenn es so sein soll - bitte. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 6. Dezember 2014 um 10:36 schrieb Tom Pfeifer t.pfei...@computer.org: turn:lanes=left|through|cycleway:through|right ? Auch ein guter Vorschlag, hier kann der Renderer sich auf die Bezeichner konzentrieren die er kennt, und alle Spuren ignorieren, die ihm unbekannt sind, insbesondere müssen nicht vorher alle access-Matrizen geparst werden. Nein, ganz im Gegenteil, das ist ein sehr schlechter Vorschlag. Und die access-Tags müssen sowieso geparst werden. Wenn man das alles einheitlich und konsistent erfasst, ist es auch in der Verarbeitung keine Zauberei mehr. Wenn man natürlich hier und dort und da Sonder-Tags und Ausnahmen und Spezial-Reglen macht, dann und erst dann wird es so richtig lustig. Bitte! Ja, bitte: Haltet die Werte sauber. Sonst wird das nichts. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Nur zum Verständnis: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). Aber an der Definition von lanes können wir jetzt nichts mehr ändern. Um genau diese Unklarheiten zu vermeiden werden bei xxx:lanes-Schlüsseln alle Spuren betrachtet. Ausnahmslos. Was man sieht, das mappt man. Dann gibt es keine Unklarheiten und hoffentlich weniger Fehler. Übrigens sehe ich auch nicht die Notwendigkeit irgendwie die lanes=x Angaben mit jenen der xxx:lanes-Angaben in Verbindung zu bringen. Je nach dem was ich benötige und was vorhanden ist, kann ich das eine oder das andere Auswerten. Eine Notwendigkeit beides gleichzeitig auszuwerten sehe ich nicht. Wenn ich an einen Spurassistenten denke, dann würde ich zuerst die xxx:lanes-Angaben verwenden und wenn es diese nicht gibt die lanes=x Angaben (mit zusätzlichen Annahmen) und wenn es diese auch nicht gibt, dann eben nur sinnvolle Annahmen treffen. Wozu xxx:lanes und lanes=x gleichzeitig auswerten? Die einzige Anwendung dafür sehe ich bei Prüfprogrammen, z.B. lanes=x kann nicht größer sein als die Anzahl der Werte eines xxx:lanes-Schlüssels. bg, Martin P.S. Ich unterstelle, dass die lanes=x und xxx:lanes-Angaben vollständig sind. Wenn man z.B. nur turn:lanes=left|through|right hat und lanes=2, dann stimmt etwas nicht, denn es fehlt die Angabe welche Spur nicht für den motorisierten Verkehr ist. Aber dies ist ein unvollständiges Tagging und kein Mangel des Taggingschemas. Ich würde in so einem Fall übrigens davon ausgehen, dass lanes=2 falsch ist, da diese Angaben so wie sie aktuell in der Datenbank sind, gerade in Kreuzungs- und Ab/Auffahrtsbereichen oft inkonsistent sind, da bis vor kurzem noch kaum jemand einen Weg extra aufsplittete, nur weil hier kurz mal ein Verzögerungsstreifen o.ä. ist. Diese Situation bessert sich erst seit kurzem, vor allem seit wir auch ein Schema haben um erlaubte Spurwechsel anzugeben. Am 4. Dezember 2014 um 16:53 schrieb chris66 chris66...@gmx.de: Am 04.12.2014 13:44, schrieb Martin Vonwald: Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. korrekt, so steht's auch im ursprünglichen Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Hi! Am 5. Dezember 2014 um 12:38 schrieb Tom Pfeifer t.pfei...@computer.org: Martin Vonwald wrote on 2014-12-05 09:05: Nur zum Verständnis: ich finde es extrem unglücklich, dass der lanes-Schlüssel nicht einfach alle Spuren zählt und man mit Unterschlüsseln konsequent weiter aufsplittet, z.B. lanes=3 + lanes:bicycle=1 + lanes:psv=1. So wie es beim lanes-Schlüssel definiert ist, ist es wenig intuitiv und fehleranfällig (Bsp: werden Spuren die nur manchmal befahrbar sind mitgezählt oder nicht? Weiß das jeder auswendig? Manche Spuren werden mitgezählt und extra ausgewiesen, manche nicht - inkonsistent!). Ja gut, dann sind wir uns ja doch einig. Die von Chris zitierte Proposal-Seite, unter Common questions, https://wiki.openstreetmap.org/wiki/Proposed_features/ lanes_General_Extension#The_issues_with_the_lanes_tag sieht ja das lanes=N tag quasi nur für die Rückwärtskompatibilität. Ich war mir beim Schreiben des Proposals dieses Problems schon bewusst und habe deshalb extra darauf hingewiesen. Der Schlüssel lanes ist meiner Meinung nach broken-by-design. Das darüberstehende Beispiel benutzt cycleway:lanes:...=, während https://wiki.openstreetmap.org/wiki/Bicycle hier bicycle:lanes= einführt? Vom Prinzip her ist bicycle:lanes=...|designated|... und cycleway:lanes=|lane| identisch. Welche Variante besser ist, kann ich sagen. Ich tendiere eher zu bicycle:lanes, da es konsistent mit der Angabe anderer access-Beschränkungen wäre, z.B. bus:lanes. Ich denke hier sollten die Mapper mit Nutzungszahlen abstimmen. Gültig sind aber beide Varianten, das sollten Datenkonsumenten berücksichtigen. Das Beispiel B1 ist besonders unglücklich, da es beim Spurlayout kein forward/backward benutzt. Ohne die lanes=3 + lanes:forward=2 bin ich komplett ratlos in welche Richtung die Spuren gehen. Selbst wenn ich das kenne, muss ich aus bicycle:lanes=designated vermuten dass designated eine Halbspur ist (falls nicht auch noch ein Bus mit langfährt), während yes eine Vollspur benutzt. Nun kann ich die beiden bicycle=designated subtrahieren und komme auf die Vollspuren, die ich nun endlich dem lanes=count zuordnen kann. Beispiel B1 ist unvollständig und daher nicht sinnvoll zu interpretieren. Die :lanes-Varianten sind hier sicher von mir, allerdings konnte ich hier nie fertig editieren, da mir der selbst ernannte Wächter der Seite sofort wieder herum editierte und no consensus vor die Nase geknallt hat und ich dazu definitiv keine Lust hatte. Korrekt wäre B1 wohl so: lanes=3 lanes:forward=2 lanes:backward=1 lanes:bus:forward=1 lanes:taxi:forward=1 vehicle:lanes:forward=yes|no|no bicycle:lanes:forward=no*|designated|no bus:lanes:forward=yes|no|designated taxi:lanes:forward=yes|no|designated vehicle:lanes:backward=yes|no bicycle:lanes:backward=no*|designated * Ob yes oder no kann ich ohne weitere Infos nicht entscheiden. Implementiere das mal bitte jemand auf einem Android. Wenn das fertig ist, kommt noch die Variante, falls die Rad/Busspur zufällig rechts aussen ist, das als cycleway:right=share_busway zusammenzufassen (B3). Ich denke, das macht auf jedem OS Probleme, da B1 einfach nicht korrekt ist. B3 würde ich analog zu B1 taggen: lanes=3 lanes:forward=2 lanes:backward=1 lanes:bus:forward=1 lanes:taxi:forward=1 vehicle:lanes:forward=yes|no bicycle:lanes:forward=no|designated bus:lanes:forward=yes|designated taxi:lanes:forward=yes|designated vehicle:lanes:backward=yes|no bicycle:lanes:backward=no|designated B4 erfindet noch service=bus obwohl das ja ein access-Recht ist und keine Art der Strasse. Um ehrlich zu sein, würde ich diese Seite generell einfach ignorieren. Wer Lust auf Edit-Wars hat, möge hier natürlich mit Freude eintauchen. ;-) bg, Martin P.S: Die Taggings habe ich jetzt mal schnell ohne viel Kontrolle runtergetippt; man möge mir Fehler verzeihen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegespuren mit Fahrradspur
Das Tagging - auch im Beispiel B1 - ist komplett konsistent. Die lanes-Schlüssel liefern dir die Anzahl der Spuren für den motorisierten Verkehr. Und die Werte in den xxx:lanes-Schlüssel liefern dir das Layout(!) und die Eigenschaften aller Spuren. Du musst überhaupt nichts hin und herschieben, du hast alle Informatione. Kein Widerspruch. Nicht inkonsistent. Am 4. Dezember 2014 um 13:36 schrieb Tom Pfeifer t.pfei...@computer.org: Ich halte das Tagging in der beschriebenen Form für inkonsistent, genau aus dem von Martin unten beschriebenen Grund, lanes sind Vollspuren für zweispurige Fahrzeuge. lanes=n und die Anzahl der turn:lanes sollten daher zueinander passen, andernfalls ist der Router überfordert und wird das Tagging für diese Kreuzung als fehlerhaft verwerfen. Das diskutieren wir grade in OsmAnd wo derzeit die turn:lanes-layouts eingebaut werden. Schaut auch bitte mal die Beispiele (no consensus) an auf https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_ and_bus.2Ftaxi_lanes In Beispiel B1, deckt mal die Skizze zu und versucht es aus dem Tagging zu rekonstruieren. Ich bekomme 3 lanes angeboten, eine backward, zwei forward, und habe dann jeweils 5 Werte für access die ich irgendwo nach rechts oder links schieben kann. Ich halte daher das Problem der zwischengelagerten Halbspuren für ungelöst. Vermutlich muss das turn:lanes-Schema um entsprechende Werte für Halbspuren ergänzen. Tom Benjamin Grimm-Lebsanft wrote on 2014-12-04 13:15: Hallo Martin, danke für die Antwort. Hab mir das gerade am Beispiel der Freiburger Kronenbrücke abgeschaut. Danke dass du meine Gedanken nochmal bestätigst! Liebe Grüße Benjamin On 04.12.2014 12:34, Martin Vonwald wrote: Der Wert cycleway ist nicht zulässig für turn. Du taggst in turn einfach alle Abbiegemarkierung: turn:lanes=through|through|none|rightbzw. turn:lanes=through|through|through|right Und idealerweise spezifizierst du noch die dritte Spur explizit als Radspur: bicycle:lanes=yes|yes|designated|yes Ich nehme an, dass ein Wechsel von der Abbiegespur nach links nicht erlaubt ist? Dann bietet sich noch folgendes an: change:lanes=...|...|...|no Übrigens - da ein oft gemachter Fehler - falls du lanes=x angeben möchtest, wäre lanes=3 korrekt, da der Schlüssel lanes nur die Spuren für den motorisierten Verkehr zählt. Deshalb ist die Anzahl der Werte der :lanes-Schlüssel (beachte den Doppelpunkt) auch nicht zwingend gleich der Angabe der Anzahl im lanes-Schlüssel. bg, Martin Am 4. Dezember 2014 um 12:21 schrieb Benjamin Grimm-Lebsanft benja...@lebsanft.org: Hallo zusammen, ich versuche mich gerade an der Abbiegespurenwochenaufgabe zu beteiligen und finde zu der, meiner Meinung nach recht häufig vorkommenden, Fahrradspur-Problematik keine Infos im Wiki. Anschauungsbeispiel. Von links nach rechts sind die Spuren wie folgt: geradeaus geradeaus Fahrrad rechts abbiegen Wie mappe ich jetzt die Fahrradspur? Ist das dann through|through|cycleway|right? Vielen Dank für die Hilfe Benjamin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] in Austria, good experience - thank you!
2014-11-10 10:29 GMT+01:00 Stefan Tiran stefan.ti...@student.tugraz.at: Hi, Norbert Wenzel wrote: You're missing the point of this discussion. It's not about whether correct data should be deleted but about the question if mapping parallel footways is actually correct data. This might be your point of view but I would not consider it as common sense. It is obviously also my point of view. How many do we need, so that point of view becomes common sense? And if one does not consider the separate footways correct data and one feels it destroys valid routing (as in Kevin's example) it's easy to delete them without violating any OSM rule we all agree upon. Kevin's example merely shows that asking the wrong question results in useless answers. If you intend to go the direct line, crossing the street at an arbitrary point, it does not make sense to use a router in order to calculate a route on dedicated footways. Instead you should use the so-called off-road navigation mode of your GPS device, which only shows the direction. You are talking about asking the wrong question and in the same context you state if our tagging destroys your application, don't use it. And yes, that is exactly what you just have said. This footway tagging is in fact destroying information. It is not correct data as it misses information and it somehow removes information that was already there. So everyone who uses this tagging is deleting correct data. In OSM everyone is allowed to use any tag he/she likes as long as it does not conflict with any existing data nor invalidates or removes it. If you (for the avoidance of doubts: you=everyone who uses this tagging) used some new tag and not highway=footway, this all wouldn't be a problem. But you want it to show up in the renderers (tagging for the renderer) and some routers (tagging for the routers). So before you (in the meaning as given above) start pointing fingers at someone (disrespecting the work of others) you should first look into the mirror. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] in Austria, good experience - thank you!
2014-11-09 22:19 GMT+01:00 Kevin Kofler kevin.kof...@chello.at: But the data is NOT correct. +1 I agree with KaiRo, this nonsense data should just be deleted, ASAP, before the disease spreads. +1 and another +1 for putting data into quotation marks. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] in Austria, good experience - thank you!
2014-10-30 14:19 GMT+01:00 Robert Kaiser ka...@kairo.at: Those should all be deleted. They are sideways and ought to be mapped as tags on the street +1 . I consider this kind of mapping as destructive. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Adressdaten in POI nodes
Hi! Am 12. August 2014 17:44 schrieb Christian H. Bruhn br...@arcor.de: In Lübeck haben wir eine building-Relation erstellt, die als outline-member die Gebäudehülle mit den Adressinfos enthält und die einzelnen POIs als contains-member (z.B. [1]) ohne Adressangaben. Warum sollte man in einer Geo-DB jene Knoten, welche sich alle innerhalb einer bestimmten Fläche befinden, extra noch in eine Relation geben? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressdaten in POI nodes
Am 13. August 2014 10:08 schrieb Falk Zscheile falk.zsche...@gmail.com: Weil es nicht zwingend ist, dass etwas innerhalb eines Polygons auch eine Beziehung zum Polygon hat. Doch. Die Beziehung ist: es befindet sich innerhalb des Polygons ;-) Was genau ist nochmal die Aussage der contains-Member? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressdaten in POI nodes
Am 13. August 2014 11:52 schrieb Tom Pfeifer t.pfei...@computer.org: Martin Vonwald wrote, on 2014-08-13 10:43: Am 13. August 2014 10:08 schrieb Falk Zscheile falk.zsche...@gmail.com: Weil es nicht zwingend ist, dass etwas innerhalb eines Polygons auch eine Beziehung zum Polygon hat. Doch. Die Beziehung ist: es befindet sich innerhalb des Polygons ;-) Was genau ist nochmal die Aussage der contains-Member? Da die Datenbank nur flächige Koordinaten kennt, können Objekte, die sich z.B. unterirdisch befinden, innerhalb eines Polygons gezeichnet sein, ohne eine Beziehung dazu zu haben. Dann sollten sie aber einen abweichenden level/layer-Tag haben. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Mapillary
Am 12. Juli 2014 11:29 schrieb martinq osm-mart...@fantasymail.de: Bei Bild [1] war schon jemand schneller (blur request in progress) Ja, ich ;-) Und damit das ganze auch in JOSM funktioniert gibt's das hier: http://www.openstreetmap.org/user/ubahnverleih/diary/21485 Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mapillary
Hi! Am 10. Juli 2014 11:25 schrieb Andreas Labres l...@lab.at: cc-by-sa 4.0 Die Fotos könnte ich für einiges gebrauchen, aber leider sind praktisch alle Schilder verpixelt, z.B. [1]. Kann man die Ersteller der Fotos irgendwie kontaktieren um an die Originalfotos ohne Verpixelung ranzukommen? KFZ-Kennzeichen müssen bei öffentlich zugänglichen Fotos ja verpixelt werden (außer man hat die Zustimmung zur Veröffentlichung). Nur schießt der Verpixelungsalgorithmus bei Mapillary offensichtlich deutlich übers Ziel. Martin [1] http://www.mapillary.com/map/im/bInKjKWn4DMQwZxqqsWq1Q ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-de] FYI: Automatische Erkennung der Verkehrsseite im JOSM-Stil Fahrspur- und Straßenattribute
Zur Info: die aktuellste Version des Stils Fahrspur- und Straßenattribute unterstützt nun die neue JOSM-Datenbank um automatisch die Verkehrsseite zu ermitteln. Um dies zu aktivieren, muss man die Stil-Farbe boolean.right.hand.traffic auf Grau setzen (irgendein Grau, nur nicht Schwarz oder Weiß), welches nun auch die Standardeinstellung ist. Falls ihr die automatische Erkennung deaktivieren wollt, setzt die Farbe entweder auf Schwarz (Linksverkehr) oder Weiß (Rechtsverkehr). Ihr benötigt die aktuellste JOSM Version (7287) und müsst möglicherweise den Cache von JOSM löschen oder ein paar Tage warten. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Mappen von Gehsteigen
Am 28. Februar 2014 09:13 schrieb Stefan Tauner stefan.tau...@gmx.at: On Fri, 28 Feb 2014 08:55:46 +0100 Martin Vonwald imagic@gmail.com wrote: History repeats itself. Daß sich Gesellschaften einen möglichst neutralen Schiedsrichter suchen, wenn man sich nicht direkt einigen kann, ist in der Tat schon öfters vorgekommen in der Menschheitsgeschichte. Und genau das neutral erkenne ich hier nicht. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Hi! Am 27. Februar 2014 21:30 schrieb Martin Raifer tyr@gmail.com: Was aber nicht OK ist, ist einfach die eine Variante in eine Andere umzumappen, ohne Mehrwert für OSM dabei zu erzeugen. Wer beurteilt, ob ein Mehrwert entstanden ist? Derjenige der das beurteilt, legt ja somit auch fest was ok ist und was nicht. Was machst du, wenn jemand in der Veränderung einen Mehrwert sieht? Beste Grüße, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 27. Februar 2014 23:43 schrieb Kevin Kofler kevin.kof...@chello.at: Martin Raifer wrote: Was aber nicht OK ist, ist einfach die eine Variante in eine Andere umzumappen, ohne Mehrwert für OSM dabei zu erzeugen. War das nicht genau das, was Railjet gemacht hat, als er diese Gehsteige dazugezeichnet hat? Auf diese Frage hätte ich jetzt auch gerne eine Antwort von dem Vertreter der DWG. Bin schon sehr gespannt darauf. Ach ja: ich sehe den Mehrwert eines nicht-getrennten Erfassens der Gehsteige im erheblich vereinfachtem Editieren und der klar ersichtlichen Zusammengehörigkeit. Einen Verlust von Information kann ich nicht erkennen. Entscheidet auch die DWG ob dieser Mehrwert erlaubt ist oder nicht? Oder provokativ gefragt: dürfen wir jetzt nur noch das machen, was uns einige wenige vorschreiben? Ich erkenne übrigens auch definitiv keine Mehrheit für das getrennte Erfassen. Oder hat die DWG - oder sogar bestimmte Mitglieder des DWG - das Recht die Mehrheit selbst zu bestimmen? Denn diesen Eindruck habe ich im Moment. History repeats itself. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Hi! Super, danke. Dieser Stil ist wirklich SEHR nützlich für's Adressmappen. Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Warum alternative Version und nicht konfigurierbar? Seit einigen Wochen kann man Stil-Farben konfigurierbar machen in JOSM. Das verwende ich im Fahrspur-Stil um verschiedenste Einstellungen konfigurierbar zu machen. Ist zwar nicht hübsch funktioniert aber: bei Optionen bedeutet Weiß - Ja und Schwarz - Nein. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Gehsteigmapping und Ressourcenallokation
Ich stimme dir grundsätzlich zu und halte persönlich das separate Gehsteigmapping sogar für in hohem Maße destruktiv (Gründe wurden von verschiedensten Seiten genannt und ich werde sie nicht wiederholen). Aber, und das ist ein großes aber, so funktioniert OSM nicht. In OSM macht jeder das was ihm Spaß macht. Das ist der Hauptgrund warum wir in OSM so viele Details haben die in anderen Karten(-daten) fehlen. Manchmal führt es natürlich dazu, dass dadurch Daten erfasst werden, welche deiner oder meiner Meinung nach minderwertig sind. Aber das ist deine oder meine Meinung. Langer Rede kurzer Sinn: es macht keinen Sinn anderen Leuten zu sagen macht doch bitte dies oder das. Wenn es ihnen Spaß machen würden, würden sie es sowieso machen. Und wenn nicht, dann sollen(!) sie es gar nicht machen. lg, Martin P.S: Ach ja, nur falls Zweifel bestehen: das war nur meine Meinung ;-) Am 26. Februar 2014 15:27 schrieb liberalerhuman...@gmx-topmail.de: Unabhängig von praktischen Problemen halte Ich am Gehsteigmapping einen Aspekt für problematisch: In Wien sind noch nicht einmal alle Häuser und Hausnummern erfasst. Anstatt Gehsteige einzuzeichnen, die von keiner mir bekannten Anwendung ausgewertet werden, wäre es sinnvoller, Daten einzutragen, für die es eine tatsächliche Verwendung gibt. Mit den entsprechenden Datensätzen der Stadt Wien und der basemap stehen dafür gute Quellen zur Verfügung. Ebenfalls nur bruchstückhaft erfasst ist das Netz des öffentlichen Verkehrs. Es wäre hilfreich, wenn man sich farauf konzentrieren könnte, vor allem solche Daten einzutragen, die trotz ihres hohen Nutzens noch fehlen. MfG, Humanist ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Du wirst auf diese Frage hier keine Antwort bekommen. Beide Seiten haben ihre Argumente und Diskussionen brachten nie einen Konsens. Beste Grüße, Martin P.S: Ich mappe ausschließlich sidewalk:xxx. Am 24. Februar 2014 16:49 schrieb martin ringer martinrin...@hotmail.com: Wie sinnvoll ist das mappen von Gehsteigen? Ich war der Meinung, es reicht, wenn man sidewalk:right ... angibt und die Gehsteige nicht extra einzeichnet? In Linz scheint man sich jedenfalls dafür entschieden zu haben, die Gehsteige extra einzuzeichnen. In Innsbruck war man dagegen. Da zeichnet man nicht einmal alle Tramgeleise ein. Wie soll man sich da noch auskennen? Zeichnen für die Renderer? Vorteil/Nachteil für die Navigation? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] St.-ZickeZacke-Str.
Alleine schon die minimale Verwendung von long_name sollte als Indiz dafür reichen, dass dieses Tags so gut wie nie gebraucht wird. Ich wollte jetzt ein Beispiel nennen, wo long_name sinnvoll ist, mir ist aber auf die Schnelle einfach nichts eingefallen - was aber nicht bedeutet, dass ich bestreite, dass es in bestimmten Fällen doch sinnvoll sein kann. Im konkreten Fall - Straßennamen - ist es für mich eindeutig, dass in name der Name voll ausgeschrieben sein soll und - falls notwendig - in short_name die gebräuchlichste Kurzschreibweise. Der Hauptgrund dafür wurde schon mehrfach genannt: abkürzen der ausgeschriebenen Variante ist einfach, ausschreiben der abgekürzten Variante ist raten. Ein Straßenschild kann soviel on-the-ground sein wie es will, es zeigt immer nur eine Schreibweise des Namens und nicht den Name selbst. Bei der ganzen Diskussion ist aber bisher ein Thema untergegangen: Support für short_name bei der Darstellung unserer Daten, in erster Linie also bei Kartenrenderern. beste Grüße, Martin Am 5. Februar 2014 09:00 schrieb Falk Zscheile falk.zsche...@gmail.com: Am 4. Februar 2014 21:33 schrieb Bernhard Weiskopf bweisk...@gmx.de: Nach meiner Auffassung ist name an der Straßenlinie der Name der Straße und nicht das was auf irgendeinem Schild steht. Ein oder mehr Schilder sind ein starker Hinweis auf den Namen, die Schreibweisen auf den Schildern können aber durchaus anders sein und werden wegen Längenbegrenzung manchmal abgekürzt. Am 5. Februar 2014 00:28 schrieb Martin Koppenhoefer dieterdre...@gmail.com: +1 Am 5. Februar 2014 07:33 schrieb Martin Vonwald imagic@gmail.com: +1 Nur noch eine Verständnisfrage, name=value ist für euch also das, was hier an anderer Stelle als long_name=value diskutiert wurde? Bei eurer Sichtweise der Dinge wäre der Wert von long_name=value gleichbedeutend mit name=value und daher eine redundante Nennung? Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Am 4. Februar 2014 21:33 schrieb Bernhard Weiskopf bweisk...@gmx.de: Nach meiner Auffassung ist name an der Straßenlinie der Name der Straße und nicht das was auf irgendeinem Schild steht. Ein oder mehr Schilder sind ein starker Hinweis auf den Namen, die Schreibweisen auf den Schildern können aber durchaus anders sein und werden wegen Längenbegrenzung manchmal abgekürzt. +1 Wenn ich das Schild und was darauf steht mappen will, setze ich einen node auf den Ort des Schilds und schreibe die genaue Schreibweise dorthin. ;-) Das folgt ja dann der so gerne zitierten on-the-ground-Regel. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Am 2. Februar 2014 20:35 schrieb Peter Wendorff wendo...@uni-paderborn.de: name=Sankt-ZickeZacke-Straße und short_name=St.-ZickeZacke-Straße. Klares +1 dafür. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktualisierung des JOSM-Stils Fahrspur- und Straßenattribute
Was ich vergessen habe: JOSM cacht die Datei, das Stil-Update wird also möglicherweise erst in ein paar Tagen bei euch auftauchen (außer ihr löscht den Cache von JOSM manuell). Beste Grüße, Martin Am 29. Januar 2014 21:48 schrieb Gertrud Simson simson.gert...@gmail.com: Danke für den Stil! Ich nutze ihn immer, wenn ich lanes oder turn:lanes eintrage. VG Klumbumbus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Aktualisierung des JOSM-Stils Fahrspur- und Straßenattribute
Hi! Nach dem größeren JOSM Update gestern habe ich heute den Stil Fahrspur- und Straßenattribute [1] aktualisiert, welcher viele Fahrspureigenschaften schon während des Editierens darstellt: * Fahrbahnmarkierung für Abbiegespuren werden nun deutlich genauer dargestellt. Dies war schon einige Zeit lang verfügbar aber aufgrund eines Speicherlecks deaktiviert, welches im letzten JOSM-Update behoben wurde (Danke!). Probiert einfach turn:lanes=slight_left;left;sharp_left|slight_right;right;sharp_right . * Die meisten Stil-Einstellungen (inklusive der Unterstützung für Linksverkehr) können nun in Bearbeiten - Einstellungen - Anzeigen-Einstellungen - Farben konfiguriert werden. Eine genaue Beschreibung findet ihr bei [1]. Viel Spaß, Martin [1] https://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Trafik mit WESTbahn / WESTbus Ticketverkauf
Hi! Am 16. Januar 2014 23:03 schrieb Martin kre...@gmx.at: shop=kiosk public_transport_tickets:WESTbahn=yes public_transport_tickets:WESTbus=yes Schaut für mich vernünftig aus. Mich stört allerdings etwas, dass ein WESTbahn im Schlüssel steht - eigentlich ist das ja ein Wert. Eventuell ein klassisches public_transport_tickets=WESTbahn;WESTbus? So wie du es angibst, könnte(!) es auch problematisch werden, wenn man eine Liste der möglichen Tickets ermitteln will, z.B. bedeutet public_transport_tickets:bus=yes das es hier ganz allgemein Bustickets gibt oder ist bus ein Name? Alternativ vielleicht public_transport_tickets:brand=WESTbahn;WESTbus ? Dann ist völlig klar was gemeint ist. beste Grüße, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Trafik mit WESTbahn / WESTbus Ticketverkauf
Hi! Am 17. Januar 2014 10:51 schrieb thomas.flandera#inode.at thomas.fland...@inode.at: Was aber wiederum nur zum Tragen kommt, wenn die Suche case-sensitive wäre - ist sie aber nicht. Welche Suche meinst du? Leerzeichen oder Nicht-Leerzeichen hingegen verändern den String sehr wohl - was gravierende Auswirkungen hat, insbesondere bei der Suche. Somit ist es egal ob dort WESTBAHN, westbahn, WESTbahn oder Westbahn (oder vielleicht sogar WestBahn) steht - nicht egal wäre es aber wenn dort aufeinmal west bahn stehen würde... Mir geht es um dieses Prinzip - nicht ob der String fett oder kursiv formatiert ist... ;) Ich sehe viele Gründe dafür: Stefan Tauner stefan.tau...@gmx.at hat am 17. Januar 2014 um 10:37 geschrieben: Aus Keys würde ich sowas - wenn irgendwie möglich - heraushalten. Beste Grüße, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Trafik mit WESTbahn / WESTbus Ticketverkauf
Ich habe das Gefühl, dass wir (Thomas, Stefan und ich) mehr oder weniger der selben Meinung sind, aber grandios an einander vorbei reden. ;-) Kurzer Zusammenfassungsversuch: Namen sollten wenn möglich genau so angegeben werden, wie sie vom Namensgeber definiert bzw. verwendet werden (wobei Unterschiede in der Groß-/Kleinschreibung bei einigen, aber nicht allen Anwendungen irrelevant sind). Und Namen sollte möglichst nicht in den Schlüssel, sondern in den Wert. Passt das irgendwie so? Am 17. Januar 2014 11:42 schrieb Stefan Tauner stefan.tau...@gmx.at: On Fri, 17 Jan 2014 11:26:10 +0100 (CET) thomas.flandera#inode.at thomas.fland...@inode.at wrote: Mir geht es aber trotzdem nicht um die Suche und ob groß oder klein - mir geht es um Leerzeichen oder nicht - also um die Schreibweise des Namens und das Beispiel, welches von Friedrich, der plötzlich die Schreibweise eines Eigennamens komplett verändert (so dass es eine Suche gar nicht mehr finden kann, ausser ich verwende wildcards ab dem dritten Zeichen...) Das tut in diesem Fall aber nichts zur Sache... Ich versteh dich nicht. *Du* hast begonnen mit irgendeiner undefinierten Suche zu argumentieren. Daß eingefügte oder weggelassene Abstände Eigennamen komplett verändern ist für mich genau so klar, wie daß eine Änderung der Großschreibung der Buchstaben das zur Folge haben kann. Im Markenrecht würde man sogar auf andere Charakterstika achten müssen (Farben, Formen, Symbole usw). Das ist für uns natürlich nicht direkt relevant, aber der Grund dafür ist, daß es im Markenrecht wichtig ist, Marken eindeutig unterscheiden zu können - was genau ist, worum es hier eigentlich geht: eindeutige Identifizierung von abstrakten Dingen. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Trafik mit WESTbahn / WESTbus Ticketverkauf
Am 17. Januar 2014 01:00 schrieb Friedrich Volkmann b...@volki.at: Ich bin der Meinung, wir sollten uns bei der Groß-/Kleinschreibung an die normalen Rechtschreibregeln halten Es sind Namen, egal wie oft du das ignorierst. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Highway Shields (Strassennummern)
Hi! Am 13. Januar 2014 20:05 schrieb Frederik Ramm frede...@remote.org: Ich bin da jetzt kein Experte, aber dieses Stueck Autobahn in der Bildmitte hier http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige Nummern, und daher kommt hier gar nix ;) Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich Gedanken darüber machen den verschiedensten Tools und Anwendungen den Umgang mit Strichpunkt-separierten Werten beizubringen. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurmapping?
Hi! Am 8. Januar 2014 23:32 schrieb Florian Lohoff f...@zz.de: Wenn man spät teil - d.h. erst dort 2 spuren baut wo wirklich die verzögerungsspur abzweigt, aber den beginn der verzögerungsspur dadurch markiert das man ab dort lanes++ hat und dann mit turn:lanes=through|through|slight_right markiert ist klar wo die verzögerungsspur beginnt und wo diese dann wirklich abknickt so das man nicht mehr wechseln kann. Ganz meiner Meinung. Ich versuche kurz zusammenzufassen, was man alles wie angeben kann und wie ein Navi das auswerten könnte. Als Beispiel nehme ich eine Abfahrt einer vierspurigen Autobahn. * Überkopfwegweiser weit vor der Abfahrt: diese können recht detailiert mit destination[:xxx]:lanes angegeben werden. Ein destination:lanes=Wien|Wien|Berlin|Zürich + destination:ref:lanes=A1|A1|A1|B2 + destination:country:lanes=AT|AT|DE|CH + destination:sign:lanes=|||park_and_ride könnte ein Navi ähnlich einem Überkopfwegweiser darstellen - die linke Spur führt nach Wien (Österreich) auf der A1 und die ganz rechte nach Zürich (Schweiz) auf der B2 - dort gibt es auch ein P+R (die anderen Spuren sind analog zu verstehen). Mir persönlich sind Überkopfwegweiser noch Overkill. Ich habe das nur ein paar mal eingetragen um das Tagging und die Auswertung zu testen. * Auf der vierten Spur sind nun Fahrbahnmarkierungen für geradeaus und rechts abbiegen: turn:lanes=none|none|none|through;slight_right. Ein Navi könnte hier Rechtshalten ansagen. Außerdem kann ein Spurassistent die entsprechenden Markierungen anzeigen. * Der Verzögerungsstreifen beginnt: die Fahrspuranzahl wird korrigiert (lanes=5) und turn:lanes=none|none|none|through|slight_right gesetzt. Das Navi kann nun rechts abfahren oder ähnliches ansagen und der Spurassistent entsprechend die fünfte Spur anzeigen. Vor allem für Renderer ist noch ein placement=right_of:2 nützlich. IdR zeichnen wir den OSM-Weg ja in der Mitte der Fahrbahn, bei einer vierspurigen Autobahn also zwischen der zweiten und dritten Spur. Da wir nun fünf Spuren haben, sollte man eigentlich den OSM-Weg in die Mitte der dritten Spur legen, was allerdings zu unansehnlichen Schlenkern beim Rendern (auch im Navi) führt. Ein placement=right_of:2 sagt den Datenkonsumenten, dass der OSM-Weg am rechten Rand der zweiten Spur liegt. Ein einfacher Datenkonsument, welcher keine Spuren rendert, stellt den Fahrbahnverlauf jetzt einfach gerade dar. Ein Datenkonsument, welcher Spuren auswertet, weiß aber auch, dass links vom OSM-Weg zwei Spuren liegen und rechts drei. Klassisches Win-Win. * Ein Wechsel von der dritten auf die vierte Spur ist nicht mehr erlaubt (kommt öfters vor um Spätabbieger zu verhindern): change:lanes=yes|yes|not_right|yes|yes . Anzeige im Spurassistenten ändert sich. * Ein Wechsel auf den/von dem Verzögerungsstreifen ist nicht mehr erlaubt (durchgezogene Linie) - von der dritten auf die vierte aber wieder: change:lanes=yes|yes|yes|not_right|no . Anzeige im Spurassistenten ändert sich. * Die Spur trennt sich von der Hauptfahrbahn: auf den gemeinsamen Knoten kommt ein motorway_junction + name=Name der Abfahrt. Auf die Abfahrt kommen alle passenden destination-Tags (dies muss nicht identisch sein mit dem Namen der Abfahrt am Knoten!). Auf der Hauptfahrbahn wird die Spuranzahl wieder reduziert (lanes=4), placement, turn:lanes und change:lanes sind nicht mehr notwendig. Ein Navi kann die exakte Distanz zu dieser Abfahrt über den gemeinsamen Knoten ermitteln. Das Navi hat nun alle Informationen um vorher(!) anzusagen/anzuzeigen: In 800m abfahren auf die B2 in Richtung Zürich Abschließend nochmal der Hinweis, dass praktisch alle genannten Tags (bis auf destination:lanes) vom entsprechenden JOSM-Stil [1] unterstützt und dargestellt werden. Man sieht also schon während des Editierens den Spurverlauf, die Fahrbahnmarkierungen und auch einige Zielangaben. Und für wagemutige mit viel Speicher noch die Empfehlung am Anfang des Stils style_use_svg auf yes zu setzen; dadurch erhält man ein deutlich detaillierteres Rendering des turn-Schlüssels. Beste Grüße, Martin [1] http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auto versus PKW im deutschen StVR - war: Parkplatz nur für PKW
Am 9. Januar 2014 08:57 schrieb Simon Poole si...@poole.ch: Macht das Leben für die Auswerter ein kleines bisschen schwieriger aber ist die praxisnahe Lösung. Es gibt eine Anzahl x von Auswertern für welche diese Tags relevant sind. Es gibt eine viel größere Anzahl y an Mappern, welche sich kompliziertere Regeln merken müssten und sie auf eine gewaltig große Anzahl z von Wegen eintragen und warten müssten. Ich bin definitiv auch dafür den Auswertern es ein klein wenig schwieriger zu machen und es für die Mapper einfach. Unterm Strich ist das Ergebnis das selbe und der Aufwand ist sehr, sehr, sehr [weitere sehr einfügen] viel geringer. Natürlich sinf die boat=no and motor_boat=no an jede Strasse taggende darüber unglücklich. . ;-) Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurmapping?
Am 9. Januar 2014 09:46 schrieb chris66 chris66...@gmx.de: Sehr schön. Sollte im Wiki verewigt werden. Bin etwas knapp bei Zeit in den nächsten Wochen, aber du hast recht, ein Überblick mit ein paar Beispielen würde gut tun. Außerdem sind meine Beispiele auf der Lane_assist Seite veraltet, da sie den placement-Schlüssel nicht verwenden. Hier z.B. sieht man schön den unnötigen Schlenker bei D-E und G-H: http://wiki.openstreetmap.org/wiki/Lane_assist/Examples/Motorway_Deceleration_Lane_at_Exit Ich muss die wohl mal aktualisieren. Etwas Geduld bitte ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurmapping?
Hi! Am 9. Januar 2014 10:17 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Hallo Martin, der Lanes-Style hat bei mir immer noch Probleme, die Strassenbreite korrekt über alle Zoomstufen anzuzeigen. Die gerenderte Breite 'springt' je nach Zoomstufe um ein paar Meter hin und her. Ich erinner mich das als Bug schon irgendwo gelesen zu haben (oder du hattest es schon in einer deiner Mails erwähnt). Ist dafür eine Lösung in Sicht? Beruhte das auf einen JSOM-Bug, der gefixt werden muss? Das beruht im Prinzip auf diesem Problem: https://josm.openstreetmap.de/ticket/8588 Ich würde es gar nicht so als Bug ansehen - es ist einfach eine Designentscheidung in MapCSS (nicht in JOSM). Ich denke, da wird sich auf absehbare Zeit wenig ändern. Bevor du jetzt aber im Bugtracker für 8588 deine Stimme abgibst, gib sie bitte für http://josm.openstreetmap.de/ticket/8581 ab. Damit lässt sich sehr viel mehr richtig gutes machen! Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurmapping?
Am 9. Januar 2014 16:15 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Gibt JOSM den aktuellen Zoom nich als float zurück? Nein bzw. mir ist keine Möglichkeit bekannt, diese Information in einem Stil abzufragen. Die pixel/m Angaben der mapcss Zoomstufen sind doch scheinbar bekannt. Ich habe sie geraten ;-) Das aktivieren der svg-Option im Style hat jetzt auf das geschilderte Problem keinen Einfluss, oder? Nein, es verbessert das Rendering u.a. der Abbiegespuren (turn-Schlüssel). beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurmapping?
Hi! Am 8. Januar 2014 19:40 schrieb Fabian Schmidt fschm...@informatik.uni-leipzig.de: laut http://wiki.openstreetmap.org/wiki/Talk:Lane_assist/Examples/Motorway_exitwar das Fazit einer Diskussion auf tagging@, dass es bei *Abfahrten* besser sei, früher aufzuteilen, da niemand die Abfahrt verpassen will, dass der weltweit überwiegende Stil in OSM wäre und es die anderen großen Navianbieter auch so machen. Jedes mir bekannte Navi gibt die Instruktionen bevor die tatsächliche Abfahrt beginnt - idR angepasst an die Geschwindigkeit jeweils ca. 5-10 Sekunden vorher. Wenn man hier auftrennt, kommt die Ansage zu früh und vor allem bei Stadtautobahnen ist man dann schnell eine Abfahrt zu früh dran. Ich tagge prinzipiell so: sobald die Straßenmarkierungen anzeigen das ein Verzögerungsstreifen kommt, setze ich turn:lanes=...|slight_right (oder passenderes). Sobald der Verzögerungsstreifen beginnt wird lanes=x angepasst und natürlich turn:lanes entsprechend. Am Ende des Verzögerungsstreifens wird der OSM-Weg getrennt. Am Hauptweg wird lanes=x wieder reduziert. Die Abfahrt bekommt potentiell ein turn bzw. turn:lanes und wo immer möglich destination, destination:ref Co. So sind alle Daten für eine exakte Ansage vorhanden. Vor allem weiß jeder Datenkonsument genau, wo die tatsächliche Trennung beginnt. Langer Rede kurzer Sinn: eine vorzeitige Trennung und ein individuelles Mappen des Verzögerungsstreifens halte ich für kontraproduktiv. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz nur für PKW
Am 7. Januar 2014 10:01 schrieb chris66 chris66...@gmx.de: Am 07.01.2014 08:48, schrieb Martin Vonwald: Am 5. Januar 2014 23:35 schrieb chris66 chris66...@gmx.de: motorcar=designated, motorcycle=no, hgv=no, bus=no Besser (da zukunftssicher) und kürzer finde ich: motor_vehicle=no + motorcar=designated/yes Da viele Mapper die Vererbungsregeln der access-Hierarchie nicht verstehen, besteht bei dieser Variante IMHO eine höhere Wahrscheinlichkeit, dass es kaputt-verbessert wird. Da hast du natürlich nicht unrecht. Ich probiere es trotzdem so, da es meiner Meinung nach die richtigste Variante ist. Wenn es viele Mapper nicht verstehen, sollte wir die Dokumentation verbessern (ja, ja, ich weiß - die liest eh keiner ;-) ) bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-at] Fehlerhafte Kennzeichnung B17 eines Teils der Triester Straße
Hi! Mir ist gerade aufgefallen, dass noch Teile der ehemaligen B17 weiterhin als B17 markiert sind, z.B. hier: http://www.openstreetmap.org/#map=14/47.8686/16.2361 In diesem Bereich ist die Wiener Straße bzw. Grazer Straße als B17 markiert, welches nicht mehr korrekt ist. Grund dafür ist diese Relation: http://www.openstreetmap.org/relation/569918 Diese enthält die sog. Triester Straße, welche wohl den alten Verlauf behalten soll. Allerdings ist bei dieser Relation auch ref=B17 gesetzt, was nun in diesem Bereich nicht mehr stimmt, da die B17 in diesem Bereich weiter östlich neu gebaut wurde. Ich bin dafür das ref=B17 aus der Relation zu entfernen. Beste Grüße, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Parkplatz nur für PKW
Am 5. Januar 2014 23:35 schrieb chris66 chris66...@gmx.de: motorcar=designated, motorcycle=no, hgv=no, bus=no Besser (da zukunftssicher) und kürzer finde ich: motor_vehicle=no + motorcar=designated/yes bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schienenkreuze und Weichen
Hi! Am 30. Dezember 2013 13:26 schrieb Andreas Neumann andr-neum...@gmx.net: - Möglichkeit zwei wäre, die sich kreuzenden Wege nicht mit einem Node zu verbinden. Dann könnte aber Nutzer XY kommen und den Node setzen. Diese Möglichkeit habe ich für Straßen schon mal vorgeschlagen: http://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction Hat auch weitere Vorteile wie z.B. sehr viel weniger Relationen. Etwas ähnliches könnte vielleicht auch bei Straßenbahnen funktionieren, wobei ich mich damit noch nie beschäftigt habe. beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] EuroVelo 6 (EV6)
Wenn mich nicht alles täuscht, rendert OpenCycleMap keine Routen, welche mit network=icn getaggt sind. Beim EV6 wurde am 12.10.2013 das Tag von bisher ncn auf icn geändert. Zum Vergleich dazu ist der EV9 als network=ncn getaggt und bisher auch sichtbar. bg, Martin Am 13. Dezember 2013 13:55 schrieb Kevin Kofler kevin.kof...@chello.at: Hallo, an alle, die sich mit dem Taggen von Radwegen auskennen: Mir ist aufgefallen, daß der EV6 Österreich seit einigen Tagen von der OpenCycleMap verschwunden ist. Wenn ich mir die Relationen mit Merkaartor anschaue, kann ich das Problem aber leider nicht erkennen. Es wäre also gut, wenn sich jemand das anschauen könnte (der sich mit dem Taggen von Radwegen besser auskennt als ich Nichtfahrradbesitzer ;-) ). Mit freundlichen Grüßen, Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Basemap.at
Hi! Ich muss hier leider das Gegenteil feststellen - wie auch schon von anderen angemerkt: oft sind die Hausnummern am falschen Gebäude, manchmal sind Straßennamen falsch, Gebäudeumrisse haben nicht selten keinerlei Ähnlichkeit mit dem wahren Gebäude. Trotz allem ist die basemap ganz brauchbar. Vor allem in Gebieten wo noch nicht viel gemappt wurde, kann man aus der Kombination geoimage.at und basemap.at recht sinnvolle Daten erstellen. Blind vertrauen ist bei basemap aber mMn gefährlich. bg, Martin Am 10. Dezember 2013 15:07 schrieb Christoph Lingg | komoot christ...@komoot.de: Hallo, freu mich sehr über die Hausnummern und konnte bei mir im Heimatort bisher keine Fehler feststellen. Ich dachte mir noch, ob man nicht über Bilderkennung die ganzen Hausumrisse einsammeln sollte und dort in OSM eintragen, wo sonst noch keine Häuser sind? Wäre das immer noch abzeichnen und rechtlich machbar? Findet ihr das überhaupt gut? Ich fand das Häuser abzeichnen recht stupide und bisher war die Detailtiefe bei basemap meist größer als bei OSM. Beste Grüße, Christoph Am 05.12.2013 um 11:34 schrieb Günther Zin. osm...@fh15.dyndns.tv: Hallo! Am Mi, 4.12.2013, 14:39, schrieb Roland Schuller: Also das ist ja echt mal super. Habe es gleich mit meinem Heimatort verglichen und etliche Hausnummern erweitert. Aber Vorsicht! Auch für Oberösterreich schaut's gut aus :-) So weit ich gesehen habe stimmen die Einträge nicht immer. Manche Strassen sind Falsch. Hausnummern auf falschen Gebäuden, ... Bitte nicht einfach stupide abzeichnen sondern mit Hirn und Verstand und vielleicht einem Geoimage Layer :-) Was mir noch aufgefallen ist: ähnlich wie bei Doris (selbe Datenbasis?) sind bei vielen Gebäuden die Hausnummern auf die Garagen getaggt. Gruß, Günther ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Gibt es die Möglichkeit JOSM auf dem IPAD laufen zu lassen?
Für einfaches Unterwegs-Mappen kannst du Go Map!! [1] verwenden. JOSM würde ich persönlich auf dem iPad (oder auf sonst irgendeinem Touch-Gerät) nicht einmal probieren wollen; die Oberfläche muss einfach touch-optimiert sein, damit es Spaß macht. Wenn ich komplexere Sachen mappen will, dann erstelle ich mit Go Map!! Knoten mit einem note-Eintrag, lade die Änderungen NICHT hoch sondern importiere sie zuhause in JOSM und mache dort die Arbeit. Ist meiner Meinung nach viel effizienter als ein aufwendiges Herumgetapse auf den Mobilgeräten. Have fun, Martin [1] https://itunes.apple.com/us/app/go-map!!/id592990211?mt=8 Am 27. November 2013 21:03 schrieb Steffen Heinz eifelhu...@gmx.de: Am 27.11.2013 20:39, schrieb Michael Reichert: Hallo, Am 27.11.2013 20:18, schrieb Steffen Heinz: Ich hab mir ein gebrauchtes IPad zugelegt, und will es natürlich auch für OSM nutzen. Ich komme gut mit JOSM zurecht, hab noch nichts besseres gefunden also läuft JOSM? Nein. Das Betriebssystem des iPad ist iOS und dort gibt es kein Java. gr gibts was ähnlich gutes? Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 21. November 2013 17:42 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Einen Felsüberhang würde ich auch nicht als shelter erfassen, eine Höhle mit Bank schon. wieso? Für mich macht das Dach und ggf. der umliegende Schutz den shelter aus, keineswegs die Sitzbank. Sehe ich genauso. Ein shelter ist für mich in erster Linie eine Art Wetterschutz. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 20. November 2013 10:58 schrieb Martin Koppenhoefer dieterdre...@gmail.com: meine Vermutung ist, dass hier Landeier und Stadtmenschen ein bisschen aneinander vorbei diskutieren. Klar, wenn man die Auswahl hat, wird man sich nicht zuerst in einen Viehunterstand flüchten, aber wenn man in abgelegenen Regionen unterwegs ist, dann wird man da weder Probleme wegen Hausfriedensbruch bekommen, noch eine große Auswahl aus unterschiedlichen Schutzunterständen haben, aus denen man im Falle eines Unwetters auswählen kann. Ggf. geht es dann auch um Leben und Tod, je nachdem, wie schlecht man ausgerüstet ist, und wie wild die Natur dort ist... +1 Ein Unterstand ist ein Unterstand. Genauso wie eine Kuh sich in eine überdachte Bushaltestelle (shelter_type=public_transport) stellen kann [1] oder ein Reh in offene Schutzhütte (lean_to) kann sich ein Mensch in einen Viehunterstand (field_shelter) stellen. Ich verweise hier auch auf rock_shelter - da will ja jetzt hoffentlich niemand behaupten, dass das nur für Menschen ist, oder? Wenn der Unterstand nicht öffentlich zugänglich ist, kennzeichnen wir das wie üblich mit access. Wenn ich im Gebirge von einem Unwetter überrascht werde, ist es mir herzlich egal ob das Dach über meinem Kopf auch explizit für mich gebaut wurde oder nicht - Hauptsache trocken. Beste Grüße, Martin [1] http://screensupscreensdown.files.wordpress.com/2011/03/img_0687-copy.jpg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 20. November 2013 21:53 schrieb Stephan Wolff s.wo...@web.de: Am 20.11.2013 11:16, schrieb Martin Vonwald: Ein Unterstand ist ein Unterstand. Ein Viehunterstand verhält sich zum Unterstand wie die Hundeschule zur Schule oder der Krötentunnel zum Fußgängertunnel. Genauso wie eine Felsvorsprung zu einer Bushaltestelle. In OSM verwenden wir dafür unterschiedliche Tags. Du - nicht wir. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Ich tagge solche Unterstände mit amenity=shelter und shelter_type=field_shelter. Siehe http://wiki.openstreetmap.org/wiki/Key:shelter_type . Martin Am 19. November 2013 00:01 schrieb René Falk li...@falconaerie.de: Am 18.11.2013 23:25, schrieb Gregor Waluga: Hallo! Hat hier schon jemand einen Viehunterstand (kein Stall) gemappt? Amenity=animal_shelter ist schon anderweitig vergeben. Meinst du in etwa sowas? http://forum.openstreetmap.org/viewtopic.php?pid=351687#p351687 Hallo Gregor, Nee, eher nicht. Bei mir sind das 3 Wände und ein Dach (Minimalausführung) ohne Möglichkeit die 4. Seite zu schließen oder zu versperren. und stehen auf Weiden und Koppeln rum. Es gibt auch Luxusausführungen mit Futterkrippe, Wasser und Einstreu. Im Unterschied zum Stall können die Tiere nach eigenem Gusto rein- und rauslaufen. Ich glaube, in England nennt man die Pferdeversion Paddockbox. Solche Unterstände gibt es auch für andere Weidetiere, nicht nur für Pferde. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Listenmail in Listenmail verlinken
Ich mach es so (umständlich, aber geht): 1) Archiv der Mailingliste suchen - http://wiki.openstreetmap.org/wiki/Mailing_lists 2) Thread suchen und öffnen 3) Nachricht suchen - Link https://lists.openstreetmap.org/pipermail/talk-de/2013-November/105768.html Martin Am 19. November 2013 09:57 schrieb Markus liste12a4...@gmx.de: Im Listenmails wir manchmal eine Frage gestellt, die in der Liste schon beantwortet wurde. Wie kann man in einer Listenmail auf eine andere Listenmail verlinken? Wie erstellt man den passenden Link, wenn man die Mail auf die man hinweisen will kennt/geöffnet hat? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Restaurant, zwei Eingaenge
Am 14. November 2013 13:22 schrieb chris66 chris66...@gmx.de: Am 14.11.2013 13:12, schrieb Michael Neumann: Loesungsvorschlaege? Innerhalb des Gesamtgebäudes B eine Teilfläche A mit amenity=restaurant mit den entsprechenden Eingängen E. Perfekt. Wenn man die Fläche des Restaurant nicht exakt bestimmen kann (wird wohl schwierig im Gebäude) dann reicht auch ein Best-Guess. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Mappen von Stiegen (als Teil der Adresse)
Da sich bisher keiner dazu durchringen konnte, die eindeutig falsche Angabe im Wiki (addr:housenumber ist definitiv kein Konsens für die Stiegennummer) wieder zu entfernen, habe ich dies nun erledigt - möglichst neutral mit beiden Varianten. Das das keine langfristige Llösung ist sollte klar sein und ich unterstütze definitiv die klare Aussage, dass ausschließlich addr:unit dafür zu verwenden ist. Martin [1] http://wiki.openstreetmap.org/wiki/WikiProject_Austria#Adressen ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Stiegen (als Teil der Adresse)
Hi! Am 11. November 2013 13:14 schrieb Markus Straub markus.straub...@gmail.com : Und im WikiProjekt Austria [2] findet sich diese Behauptung - die ich nicht sehr sinnvoll finde (Adressen kann man ja beim Ausgeben formatieren wie man will, aber das darunterliegende Datenformat sollte schon einheitlich sein - also wenn addr:unit dann überall): Die Nummer der Stiege gehört in Österreich zur Hausnummer dazu (wird also als Teil von addr:housenumber=* und nicht via addr:unit=* getaggt). 16-26/68 ist also eine gültige Hausnummer (und bedeutet Hausnummern 16 bis 26, Stiege 68). Das ist meiner Meinung nach nicht nur nicht sehr sinnvoll sondern sogar schädlich. Solche unmotivierten regionsspezifischen Alleingänge führen nur dazu, dass die Daten nicht sinnvoll verarbeitet werden können. Ich habe bisher und werde auch weiterhin addr:unit für die Stiege verwenden. bg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Datenmodell für straßenbegleitende Wege
Am 4. November 2013 09:46 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Bei straßenbegeitenden Radwegen mit Zeichen 237, 240 oder 241 ist Radfahren auf der Straße verboten. ist es nicht, die Benutzung des Radwegs ist unter bestimmten Bedingungen vorgeschrieben, das ist aber nicht dasselbe wie ein Verbot auf der Straße, das haben wir schon zig mal diskutiert. Und weil man das nicht oft genug sagen kann und bicycle=no, welches von manchen tatsächlich gesetzt wird, auf den jeweiligen Straßen schlichtweg falsch ist, gibt es dafür ein +1. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] JOSM-Plugin turnlanes
Hi! Probiere es hiermit: http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes Das :lanes-Konzept ist deutlich mächtiger und universeller als turnlanes. Ich habe auch noch die Hoffnung, dass irgendwann [1] gefixt wird, denn dann sieht die Darstellung der Abbiegespuren viel besser aus, ist viel flexibler und genauer und man kann auch noch viel mehr Infos zusätzlich auswerten. (Wer aus ausprobieren will: style_use_svg=yes setzen am Anfang vom Stil) Falls sich also jemand an einem Patch versuchen will hat er meinen Dank. Gilt auch für ein paar extra Up-Votes. vg, Martin [1] http://josm.openstreetmap.de/ticket/8581 Am 9. Oktober 2013 16:18 schrieb Christian Aigner | caigner openstreet...@sys-admin.at: Hallo, liebe Kolleginnen und Kollegen! Ich bin gerade über ein JOSM-Plugin gestolpert, das geradezu genial ist: turnlanes Schaut euch mal dieses Video-Tutorial an: http://www.youtube.com/watch?v=uF_ZuIwLruQ Statt die Straße in zwei oder mehrere Fahrbahnen aufzusplitten, werden lanes spezifiziert und die entsprechenden Abbiegeregeln gesetzt. Hier gibt's mehr zu dem Plugin: https://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes#Plugin Ich probier das gleich mal aus. :-) LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] osmand / steyr / B122
Hier ist das Problem (in Version 5): http://www.openstreetmap.org/browse/way/26183696/history Ein oneway=yes passt hier nicht. Ich korrigiere das jetzt. Martin Am 13. September 2013 22:03 schrieb Rainer Fügenstein r...@oudeis.org: hallo, auf dem weg (per auto) von sierning ins zentrum von steyr hat mich osmand jedes mal genötigt, die B122 auf höhe trollmannstrasse zu verlassen, wild durch diesen stadtzeil zu kurven und über die reindlgutstraße wieder auf die B122 aufzufahren. offensichtlich wollte osmand unbedingt dieses stück vermeiden: www.openstreetmap.org/browse/way/144458561 in die gegenrichtung (nach sierning) wars überhaupt kein problem. finde aber nichts was osmand aus dem tritt bringen könnte. die bushaltestellen vielleicht? habt ihr eine idee? mfg ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Anzahl lanes bei forward und backward und turn
Hi! Ich bin dazu übergegangen entweder nur lanes einzutragen (bei Eindeutigkeit z.B. lanes=2 bei oneway=no) bzw. nur lanes:forward und lanes:backward (also ohne lanes). Finde ich irgendwie intuitiver. Im Prinzip sollte es aber egal sein, solange zwei Schlüssel vorhanden sind. Achtung Falle: der Schlüssel lanes zählt nur die Spuren für motorisierten Verkehr und auch sonst einige Spurarten nicht. Ist unschön, aber historisch leider so gewachsen. Schlüsseln mit der :lanes-Erweiterung beziehen sich aber auf alle Spuren! Deshalb ist z.B. folgendes möglich: lanes:forward=1 + turn:lanes:forward=through|through;right . Eine der beiden Spuren in Vorwärtsrichtung wird eben nicht vom lanes-Schlüssel gezählt. bg, Martin Am 20. August 2013 00:42 schrieb Gertrud Simson simson.gert...@gmail.com: Hallo, ich habe gestern ein bisschen mit lanes und turn:lanes gespielt. Dabei habe ich diese teilweise z.B. folgendermaßen eingetragen: lanes=3 lanes:*backward*=1 turn:lanes:*forward*=through|right oder: lanes=5 lanes:*backward*=3 turn:lanes:*forward*=through|right turn:lanes:*backward*=left|through|right In den Beispielen fehlt also jeweils lanes:forward=2 Dies ergibt sich jedoch theoretisch im Normalfall aus den ersten beiden Zeilen. Wenn ich mir im Wiki hier: http://wiki.openstreetmap.org/wiki/DE:Key:lanes#Beispiele das vorletzte und das drittletzte Beispiel anschaue, frage ich mich, ob es doch sinnvoll ist generell immer lanes:forward=* *und* lanes:backward=* anzugeben (natürlich vorrausgesetzt es ist keine Einbahnstraße wie z.B. bei Autobahnen). Ist das sinnvoll oder unnötig? VG Klumbumbus ___ 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] Variable Geschwindigkeitsbegrenzung
Hi! Am 10. August 2013 14:04 schrieb Andreas Neumann andr-neum...@gmx.net: Es gibt in osm das Tag für Signalanlagen (maxspeed=signals). Ich bin aber der Meinung, dass auf Grund der generellen Maximalgeschwindigkeit von 130km/h maxspeed=130 stehen müsste, da dieser Wert (a) für die Router wichtig ist und (b) in einigen Navis angezeigt wird (wenn auf der Strecke geblitzt wird, dann nur die 130 und wegens Abstandseinhaltung). Wie ist eure Meinung? Ich tagge entsprechend http://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed . Das ergibt maxspeed=130 (mehr gibt es dort nie - die Signalanlagen regeln nur runter) und maxspeed:variable=peak_traffic . bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] 2-gleisiges Straßenbahnmapping in Wien
Auf der tagging-Liste kam gerade das: http://lists.openstreetmap.org/pipermail/tagging/2013-April/013377.html Ich habe es noch gar nicht angesehen, aber offensichtlich macht sich noch jemand Gedanken über das selbe Problem. Ich schau später mal rein - vielleicht macht ihr ja das selbe. Vg, Martin Am 12.04.2013 um 15:34 schrieb Albin Michlmayr alm...@gmx.at: Am Fri, 12 Apr 2013 15:06:57 +0200 (CEST) schrieb Andreas Uller a.ul...@gmx.at: Ich habe den :lanes Tag für die Lage von Straßenbahnschienen schon mehrfach in Graz verwendet, z.B. hier: http://www.openstreetmap.org/browse/way/160928106 (Körösistraße) http://www.openstreetmap.org/browse/way/26543826 (Leonhardstraße) http://www.openstreetmap.org/browse/way/58691405 (Riesstraße) Danke für die Beispiele, den grazer Ansatz mit den lanes kannte ich bisher noch nicht. Ich habe mich bisher an den Grundsatz gehalten, nur dann zweigleisig zu mappen, wenn die Straßenbahn einen eigenen Gleiskörper hat. Bei von anderen Mappern getrennten Straßen und Schienen habe ich die Trennung bisher aber auch noch nicht rückgängig gemacht sondern mit den getrennten Schienen die Relationen wieder hergestellt. Wenn mit den oben genannten Tags keine wesentlichen Informationen verloren gehen dann bin ich auch bereit, mich gelegentlich mit dem Zusammenlegen der Ways in Wien zu beschäftigen. Wenn wir schon mit dem wiedereingliedern der Straßenbahn in die Straße beschäftigt sind, werfe ich gleich noch ein Problem auf, dass so wie ich glaube in Wien auch nicht wirklich zufriedenstellend gelöst ist - nämlich die Gleisbögen für abbiegende Straßenbahnen. Die wurden ja auch irgendwann einmal recht flächendeckend getrennt von den Straßen eingezeichnet. Abgesehen davon, dass sie gerendert schön aussehen bieten sie bei Kreuzungen von 2 Straßenbahnstrecken tatsächlich Zusatzinformation, wo die Straßenbahn abbiegen kann und wo nicht (Schließlich können Schienenfahrzeuge einfach so von einem Gleis weder aufs Nebengleis springen noch auf ein Querendes). Weiß jemand ob es da schon Überlegungen gab, diese Gleisbögen durch irgendwelche schienenspezifischen Abbiegerelationen zu ersetzen? Liebe Grüße, Albin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] 2-gleisiges Straßenbahnmapping in Wien
Am 12. April 2013 14:18 schrieb Stefan Tauner stefan.tau...@gmx.at: On Fri, 12 Apr 2013 10:11:11 +0200 Martin Vonwald imagic@gmail.com wrote: Naja, wenn ich je ein Tramwaygleis pro Richtung einzeichne und beide liegen oftmals in der Mitte einer Straße, müßte ich auch den Straßen-Way links und rechts davon zeichnen und nicht hoffen, dass es durch den Renderer in der geeigneten Zoomstufe schon irgendwie drunter sein wird. Sonsts wärs ja total inkonsistent. Was jetzt nichts daran ändert, dass man das normalerweise nicht möchte und auch bei Gleisen nicht möchten sollte :)) Kommt jetzt drauf an: wenn die Gleise einen eigenen Gleiskörper haben, passt da ja so. Wenn sie hingegen - wie öfter - auf einer Fahrspur verlaufen, dann gehört da meiner Meinung nach nichts getrennt sondern alles auf einen Weg. man beachte die smilies ;) ich glaube auf der ml und ganz allgemein bei den regulars gibts da eh einen konsens der vernunft (bzgl. gehsteigen und bimgleisen; bei fahrradwegen ist es subjektiv weniger eindeutig, bzw die grenze, ab der ein eigener way für gerechtfertig gehalten wird, ist nicht bei allen gleich. aber das führt jetzt alles zu weit). es gibt probleme und bisher gab's relativ wenig lösungsvorschläge wie man damit umgehen kann. nur sudern und vergleichsweise technisch und philosophisch hier darüber zu diskutieren, wie man es richtig machen würde, bringt nix, wenn nicht mitlesende etwas komplett anderes machen und sich mit dem problem nicht auseinandersetzen. Richtig, deswegen sollte man eine Lösung auch dokumentieren - wenn man sich einigen kann. Hilft zwar auch nicht immer, aber zumindest ein bißchen. Ich habe schon bei verschiedensten Anlässen angeboten, auch mittels railway:lanes gekennzeichnete Straßenbahngleise in den JOSM-Stil einzubauen, damit man sie beim Editieren sieht. Sollte relativ flott gehen, da ich selber aber kaum Straßenbahnen einzeichne möchte ich das nur machen, wenn sich auch ein paar Leute zum Tagging bekennen und es auch einsetzen, anderenfalls ist es sinnloses Arbeit und verlangsamt den Stil nur für alle. beste Grüße, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] 2-gleisiges Straßenbahnmapping in Wien
Hi! Am 11. April 2013 13:10 schrieb Stefan Kopetzky sk...@ostblock.org: Das kann eigentlich nur ins Auge gehn, aber hauptsach wir haben jeden Schienenstrang und jede Spur auseinandergepflückt und klauben das dann wieder über Relationen zusammen. Es bleibt ja nicht bei Spuren... Nur eine kurze Zwischenfrage: woher hast du den Eindruck, dass die Fahrspuren jetzt vermehrt einzeln gemappt werden? Haben wir uns nicht gerade eher davon verabschiedet durch die ganzen :lanes-Tags? Die werden ja auch schon - zumindest rudimentär - von einer Navi-App unterstützt. vg, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Tags an Straßen
Sorry, das muss jetzt einfach sein: Am 9. April 2013 15:35 schrieb Frederik Ramm frede...@remote.org: Diese addr-Tags sind ausschliesslich fuer Objekte mit einer postalischen Adresse vorgesehen - nicht fuer Baeume http://de.wikipedia.org/wiki/Br%C3%A4utigamseiche http://de.wikipedia.org/wiki/Himmelgeister_Kastanie ;-) Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags an Straßen
Hi, Am 08.04.2013 um 17:05 schrieb Heinz-Jürgen Oertel hj.oer...@t-online.de: Wenn der User nicht die nächsten Tage antwortet, werde ich diese Attribute löschen. Lehn dich mal nicht zu weit aus dem Fenster. Auch wenn ich hier zustimme und ich(!) würde diese Daten auch nicht auf den Straßen eintragen, das Löschen von an sich korrekten Daten hat in OSM nichts verloren. Du (und auch ich) hast eine andere Meinung. Das ist aber nur eine Meinung. Solange die Daten nicht faktisch falsch sind hat niemand das Recht sie zu löschen. Und auch das alles war nur eine Meinung - meine. Das ist der Fluch eines Communityprojektes: es gibt nur wenig richtig und falsch, dafür aber viele Meinungen. Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gepflegtes Gebüsch
Am 4. April 2013 17:03 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Wurde nicht genau dafuer immer landcover=* propagiert? Das hat fast keine hoehere Bedeutung neben was den Boden bedeckt, ist also nur eine bessere Variante von mal es gruen im Renderer und dass ist es ja wohl, wass man moechte wenn man sich Gedanken um den Bewuchs von Parkplatztrennflächen macht. Da ist auch gar nichts schlimmes dabei, mit landuse=* ist das systematisiert und auch nicht mehr mappen fuer den Renderer (in der ursprünglichen Bedeutung von: ein falsches Tag benutzen um das Rendererergebnis zu beeinflussen). Damit umgeht man die Problematik, das landuse eher für grosse Gebiete definiert ist und auch die leidliche natural=* Problematik im urbanen Raum. (@Martin: fällt dir der Widerspruch unkultiviert - urban nicht im eigenen Posting auf? Diese Büsche wachsen da wohl kaum wild, sondern wurden sorgsam vom Besitzer angepflanzt.) Ansonsten schliesse ich mich Franks Meining (fast) an. Bitte Parkplatztrennflaechenbuesche erst dann mappen, wenn der Rest der Umgebung einen aehnlichen Detailgrad bereits erreicht hat. Ansonsten lieber mit Hausnummern und Turn-restrictions beschaeftigen. +1 von mir von Anfang bis Ende. Bleibt nur die Hoffnung, dass es auch tatsächlich irgendwann gerendert wird, denn falls nicht, wird es nicht getaggt. Für JOSM kann ich euch einen Stil anbieten, welche die meisten landcover-Tags darstellt. Aber wie wir wissen, wird heutzutage fast nichts mehr getaggt was nicht auch gerendert wird. Und falls es nicht gerendert wird, dann wird es halt falsch getaggt, damit es doch gerendert wird :-/ Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Stil Fahrspur- und Straßenattribute
Hi! Am 8. März 2013 13:08 schrieb smart...@gmx-topmail.de: Verbesserungen wünsche mich mir aber trotzdem bitte: ich erkenne graphisch keinen Unterschied zwischen right, merge_to_right und slight_right. Der erste Pfeil geht rechts rum, der zweite und dritte bedeutet rechts einordnen. Also Graphisch eher so: http://wiki.openstreetmap.org/w/index.php?title=File:Vorank%C3%BCndigungspfeil.svgpage=1 Dank einiger Verbesserungen in JOSM gibt es nun individuelle Grafiken für alle Werte des Schlüssels turn und für Beschränkungen (Bus, Taxi, Rad sind fertig; HOV kommt noch). Ist nicht ganz perfekt, da die Grafiken nicht transparent sein können, aber erheblich besser als bisher. Ich muss das ganze noch etwas testen bevor ich es online stelle. Ich wäre aber auch dankbar für etwas Hilfe beim testen, also wenn du die Vorabversion haben willst melde dich bitte. JOSM ab 5812 wird benötigt. vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.
Hi! Ich habe damit begonnen einzelne Verkehrsschilder zu erfassen, weil ich festgestellt habe, dass es oft nicht einfach ist den Überblick zu behalten wo jetzt ein Limit anfängt und wo es aufhört - vor allem wenn man Straßen nur stückerlweise mappt. Für Geschwindigkeitsbeschränkungen verwende ich traffic_sign=maxspeed + maxspeed=x . Soweit so klar, nur das erste Problem wartete nicht lange: wie mappe ich das Ende der Beschränkung? Nach einigem hin und her entschloss ich mich zu maxspeed=implicit, da so ein Schild ja eigentlich genau das aussagt: aber hier gilt die allgemeine, implizite Geschwindigkeitsbegrenzung. Bei Überholverboten habe ich jetzt ein ähnliches Problem. Der Beginn ist klar: traffic_sign=overtaking + overtaking=no. Aber wie das Ende? Passt hier ein overtaking=yes (das steht nicht am Schild)? Oder vielleicht auch besser ein implicit hier? Bevor ihr antwortet bitte berücksichtigt, dass ich ausschließlich von Verkehrsschildern rede. Ich möchte jetzt bitte keine x-te Diskussion lostreten ob Geschwindigkeitslimits auf den Straßen so oder so oder ganz anders zu mappen sind ;-) Und für mich sind die Verkehrsschilder in erste Linie auch nur eine Erleichterung zum Mappen. Mich nervten die hunderten Knoten mit note=Beginn 70 und note=Ende Überholverbot. Ich will das ganze auch während des Editierens sehen und dazu muss es auswertbar sein, was eine note nicht ist. Anmerkungen, Idee, Vorschläge? Beste Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsschilder: Ende von Geschwindigkeitslimit/Überholverbot/usw.
Hi! Hm... ok, alle meine Mails starten in Zukunft mit: Bitte zuerst vollständig lesen und erst danach antworten ;-) Natürlich sollen die Geschwindigkeiten auf die Wege. Die Verkehrsschilder sind nur als Hilfe für die Mapper gedacht. Sehr oft hat man gerade rund um Kreuzungen unterschiedliche Geschwindigkeiten pro Fahrtrichtung und wenn man dann nur eine Richtung abfährt und die Geschwindigkeiten entsprechend einträgt sind die Werte für die andere Richtung entweder falsch oder fehlen komplett. Wenn man die Schilder zusätzlich einträgt kann man das ganze stückweise machen. Widersprüche kann es natürlich immer geben - das ist dann ein Hinweis den Status neu zu ermitteln. So stelle ich mir das vor: http://www.vonwald.info/osm/images/Speedlimit%20Trafficsign.jpeg Mir geht es nur darum die note-Knoten zu ersetzen durch etwas was sinnvoll auswertbar ist. vg, Martin Am 20. März 2013 11:55 schrieb Peter Wendorff wendo...@uni-paderborn.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Martin. Am 20.03.2013 11:23, schrieb Martin Vonwald: Hi! Ich habe damit begonnen einzelne Verkehrsschilder zu erfassen, weil ich festgestellt habe, dass es oft nicht einfach ist den Überblick zu behalten wo jetzt ein Limit anfängt und wo es aufhört - vor allem wenn man Straßen nur stückerlweise mappt. Für Geschwindigkeitsbeschränkungen verwende ich traffic_sign=maxspeed + maxspeed=x . Soweit so klar, nur das erste Problem wartete nicht lange: wie mappe ich das Ende der Beschränkung? Nach einigem hin und her entschloss ich mich zu maxspeed=implicit, da so ein Schild ja eigentlich genau das aussagt: aber hier gilt die allgemeine, implizite Geschwindigkeitsbegrenzung. Ich sehe das Problem schon früher: Was heißt denn für dich Anfang und Ende? Im Normalfall steht das Verkehrsschild, das du mappst, ja nicht an einer Einbahnstraße, sondern an einer, die zwei Richtungen kennt. Wenn Du das Schild neben der Straße einträgst, braucht man für die Auswertung 1) die Geometrie: okay, das Schild steht nahe von Straße X 2) die Richtung, in der das Schild jetzt gelten soll. An der Straßenseite kann man das nicht zwingend ausmachen, denn manchmal sind Verkehrsschilder auch beidseitig angebracht. Abgesehen davon ist das Wissen über das lokale Verkehrssystem (Linksverkehr, Rechtsverkehr) notwendig. Mappst Du das Schild als node der Straße, dann fällt 1 als Schwierigkeit weg, 2 bleibt aber. Aus genau diesem Grund werden die Geschwindigkeitsbegrenzungen eben üblicherweise vor allem am way getagged, und nicht als Schilder. Ob es übersichtlicher wird, wenn die Schilder eingetragen sind, bezweifle ich, denn das sind erstmal nur zusätzliche nodes im editor. Nichtsdestotrotz würde ich die Schilder aber evtl. auch eintragen. Bei Überholverboten habe ich jetzt ein ähnliches Problem. Der Beginn ist klar: traffic_sign=overtaking + overtaking=no. Aber wie das Ende? Passt hier ein overtaking=yes (das steht nicht am Schild)? Oder vielleicht auch besser ein implicit hier? siehe oben: ich würds als Eigenschaft des Weges eintragen. Bevor ihr antwortet bitte berücksichtigt, dass ich ausschließlich von Verkehrsschildern rede. Ich möchte jetzt bitte keine x-te Diskussion lostreten ob Geschwindigkeitslimits auf den Straßen so oder so oder ganz anders zu mappen sind ;-) hmm... sorry, aber das hättest du vorher schreiben müssen.. ;) Aber: Und für mich sind die Verkehrsschilder in erste Linie auch nur eine Erleichterung zum Mappen. Mich nervten die hunderten Knoten mit note=Beginn 70 und note=Ende Überholverbot. das verstehe ich, und note ist auch sicher NICHT auswertbar. Aber maxspeed am Weg ist auswertbar, und overtaking=no (oder ähnliches, ich hab keine Ahnung, wie das eingetragen wird) ist es auch. Ich will das ganze auch während des Editierens sehen und dazu muss es auswertbar sein, was eine note nicht ist. Dazu müsste es doch machbar sein, 'nen Stil zu schreiben, der entweder die Schilder als icons auf dem way anzeigt oder den weg entsprechend umfärbt etc. Ich jedenfalls würde den Weg gehen, bevor Hilfskonstruktionen aus zusätzlichen Nodes herangezogen werden, die die Übersichtlichkeit für den Mapper nur scheinbar verbessern, denn wenn deine Hilfsnodes den Way-Attributen widersprechen, hast du gar nichts gewonnen. Gruß Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJlaQACgkQi8ffXNvWmYQwAgCfayEWwNSSbUqZVeOn47D6oyUV yecAn2T+cB9qNKuSPMFrn/wagIbQjbri =4lvg -END PGP SIGNATURE- ___ 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] JOSM Stil Fahrspur- und Straßenattribute
Hi! Am 15. März 2013 17:58 schrieb André Reichelt andr...@online.de: Am 15.03.2013 10:48, schrieb Stefan: Sehr schön. Ich denke, es ist ein super Tool um die osm-Qualität für Navis zu verbessern. Jetzt wäre es nur noch super, wenn der Stil auch mit dem graphischen TurnLanes-Generator kompatibel wäre. Das Plugin verwendet ein komplett anderes Tagging-Schema, welches - soweit ich das beurteilen kann - auch nicht mit einem MapCSS-Stil dargestellt werden kann. Es kommt noch dazu, dass es sich nicht wirklich in die :lanes-Erweiterung integriert, welche ja sehr viel mehr bietet als nur Abbiegespuren, da praktisch jeder beliebige Key mit :lanes erweitert werden kann um spurbezogene Eigenschaften anzugeben. Praktische Beispiele welche auch vom aktuellen Stil unterstützt werden sind: Spurbreiten, spurabhängige Beschränkungen, Spurwechsel. vg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naviagtion mit OSM-Karten unter Android
Hi! Am 18. März 2013 11:30 schrieb Hans Schmidt z0idb...@gmx.de: sehr viel richtiges ... Danke für diese klaren und aus meiner Sicht richtigen Worte. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] 3D-Gebäude - OSM2World rendert jetzt auch Österreich
Danke schön! Ich wollte in den nächsten Tagen anfragen, ob es nicht möglich wäre etwas mehr von Österreich zu rendern :-) Am 18. März 2013 13:42 schrieb Wolfgang Silbermayr wolfgang.silberm...@gmail.com: Falls sich von euch jemand mit 3D-Gebäudemapping beschäftigen will, die Webseite http://maps.osm2world.org/ rendert seit einigen Tagen auch Österreich. Das Rendering wird allerdings im Moment nicht sofort durchgeführt, sondern erst nach Stunden bis wenigen Tagen. Die Entwickler arbeiten jedoch daran, diesen Zeitraum zu verbessern. Wer Informationen zum Mappen benötigt, findet ein wenig davon unter https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Interessante Gegenden, von wo man sich etwas abschauen kann: http://maps.osm2world.org/?zoom=17lat=48.57397lon=13.45544 http://maps.osm2world.org/?h=128view=Nzoom=16lat=47.06156 Das Tagging für 3D-Gebäude ist noch etwas in Bewegung, daher kann es durchaus sein, dass später noch Nacharbeit notwendig ist, wenn ihr jetzt etwas taggt. Die Ergebnisse sind jedoch schon sehr beeindruckend. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
