Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Am 16.08.2010 14:50, schrieb fly: We sieht das eigentlich für wheelchair dann aus wenn vehicle=no gesetzt ist ? Ein Rollstuhlfahrer wird im allgemeinen als Fußgänger angesehen. Das wheelchair=no steht dafür, das Wege für Rollstuhlfahrer auf Grund der Steigung/Bodenbeschaffenheit/Breite/Unebenheiten im Boden/hoher Stufen nicht zugänglich ist. Oder würdest du dich mit einen Rollstuhl auf die Autobahn trauen? MfG Andreas -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bitte um Mithilfe: Friedhofmapping jetzt im wiki
Am 17. August 2010 00:26 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 16. August 2010 21:08 schrieb Falk Zscheile Der Datenschutz hat bekanntlich eine ganz ähnliche Quelle (Art. 1 Abs. 1 GG i.V.m. Art. 2 Abs. 1 GG). U.u. kann es also schon ausreichen, dass die Angehörigen nicht wünschen, dass die Ruhestätte des Toten öffentlich bekannt gemacht wird, um einen zivilrechtlichen (Unterlassungs-) Anspruch zu konstruieren. und dann? Dann löschen wir denjenigen halt wieder, oder kürzen den Nachnamen ab. Das ist dann die Unterlassung. Dieser rein hypothetische und vermutlich extrem seltene Fall sollte uns m.E. nicht schon vorab davon abhalten, uns selbst künstliche Beschränkungen aufzuerlegen. Dann lassen wir am besten den Mapper vor Ort entscheiden, für wie hypothetisch er das Ganze hält. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Andreas Neumann wrote: Oder würdest du dich mit einen Rollstuhl auf die Autobahn trauen? Wenn er 60 km/h schafft ... dann schon. :) Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSeaM und Freie Tonne war: Unterscheidung (war Tiefenangabe alsName)
Am 17. August 2010 03:08 schrieb Andreas Labres l...@lab.at: Viel trauriger finde ich aber, daß diese Streithähne hier sich offenbar noch immer nicht auf ein gemeinsames, einheitliches Schema geeinigt haben... Irgendwie sollte man die alle mal in einen Raum sprerren und erst wieder rauslassen, wenn sie vorher ein von allen unterschriebenes Blatt Papier mit dem gemeinsamen Schema durch die Tür schieben... ;-/ Rein von der Anzahl der eingetragenen nautischen Informationen (Elementen) liegt FT deutlich vorn. Persönlich finde ich auch die Handhabbarkeit bei der Eintragung bei FT besser. Die Datenschemen beider Projekte haben dagegen nach wie vor jeweils Vor- und Nachteile Eine faktische Entscheidung dürfte damit nicht mehr in all zu großer Ferne gegeben sein, wenn nicht noch etwas unvorhergesehenes geschieht ... Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Am 17. August 2010 07:17 schrieb Mario Salvini salv...@t-online.de: Am 17. August 2010 03:21 schrieb Andreas Labres l...@lab.at: On 11.08.10 21:24, Jan Jesse wrote: water:depth= Mich würde mal interessieren, wieso der key so heißen soll? Welche water:* oder welche *:depth gibt's sonst noch? Servus, Andreas du fragst dich auch, warum nicht einfach depth=* me, too *g* depth könnte beispielsweise auch angeben, wie weit die Wasseroberfläche eines Sees unter normal Null liegt (Nur als Gedankenspiel.) Was mir noch fehlt ist das Bezugssystem, auf das sich die Wassertiefe Höhe bezieht, also auf welches normal Null sich die Wassertiefe aber auch die Höhe von Bergen etc. bezieht. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
Am 17. August 2010 01:06 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Ist: rental=xy fee=no nicht ein Widerspruch in sich? Nein, es ist nur die große Ausnahme, dass die Geldleistung auf Null gesetzt wird, während die Gewährleistungsansprüche bei auftretenden Mängeln an der Mietsache bestehen bleiben sollen. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Am 17. August 2010 10:09 schrieb Falk Zscheile depth könnte beispielsweise auch angeben, wie weit die Wasseroberfläche eines Sees unter normal Null liegt (Nur als Gedankenspiel.) Bezug auf NN kommt mir seltsam vor bei Wassertiefen. Normalerweise bezieht sich das auf den Grund. Was mir noch fehlt ist das Bezugssystem, auf das sich die Wassertiefe Höhe bezieht, also auf welches normal Null sich die Wassertiefe aber auch die Höhe von Bergen etc. bezieht. Wassertiefe wie gesagt eher nicht auf NN, die Höhe hingegen wird in WGS84 angegeben: http://wiki.openstreetmap.org/wiki/H%C3%B6he#H.C3.B6henmessung_in_OSM Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Am 17. August 2010 10:17 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 17. August 2010 10:09 schrieb Falk Zscheile depth könnte beispielsweise auch angeben, wie weit die Wasseroberfläche eines Sees unter normal Null liegt (Nur als Gedankenspiel.) Bezug auf NN kommt mir seltsam vor bei Wassertiefen. Normalerweise bezieht sich das auf den Grund. Der Wasserstand ändert sich aber je nach Gezeiten und/oder Wetterlage. Dementsprechend befindet sich mal mehr oder weniger Wasser über dem Grund. Deshalb ist man gezwungen einen Normalwasserstand als einen hypothetischen Wert anzugeben. Das kann der niedrigste, der höchste oder etwas dazwischen sein. Für die Nordsee hat man das in den Seekarten (Seekartennull) vor ein paar Jahren umgestellt.[1] Wäre also schon sehr unschön, wenn die alten Daten den weg in die Karte finden würden. Dem beugt man am besten vor, indem man das Bezugssystem gleich mit nennen muss. Auch in problematischen Ostseerevieren wird über die Wassertiefe durch die Verkehrszentrale informiert. Dann kann sich jeder ausrechnen, ob er beim aktuellen Wasserstand noch mit seinem Schiff durchfahren kann oder es besser sein lässt. Was mir noch fehlt ist das Bezugssystem, auf das sich die Wassertiefe Höhe bezieht, also auf welches normal Null sich die Wassertiefe aber auch die Höhe von Bergen etc. bezieht. Wassertiefe wie gesagt eher nicht auf NN, die Höhe hingegen wird in WGS84 angegeben: http://wiki.openstreetmap.org/wiki/H%C3%B6he#H.C3.B6henmessung_in_OSM Womit wir schon wieder bei einem Problem sind. Ich bezweifle, dass die vor einiger Zeit hier diskutierten Höhenangaben in Namen von Berghütten in WGS 84 angegeben sind. Zugegebenermaßen sind ein paar Dezimeter in der Höhe nicht sicherheitsrelevant, wogegen sie in der Tiefe einen erheblichen Unterschied machen -- jedenfalls in flachen Revieren. Gruß, Falk [1] http://www.bsh.de/de/Produkte/Infomaterial/Seekartennull/index.jsp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: was soll mit leeren nodes gemappt werden?
Hallo, Jonas Stein wrote: ich habe bislang leere Nodes geloscht, fand aber gestern einen User im IRC, der malt sich Symbole mit leeren Nodes als Merker. Naemlich mich. Zunaechst muessen wir die Frage klaeren: Wollen wir eine Karteninformation egal welcher Art durch geometrische Anordnung leerer Nodes ablegen? Muessen wir nicht. Ich finde, und das habe ich Jonas mehrfach auf dem IRC zu erklaeren versucht, dass er hier einer voellig unnoetigen und OSM-untypischen Regelungswut anheim gefallen ist. Wir muessen solche Fragen vielleicht dann diskutieren und klaeren, wenn es zu Konflikten kommt. Solange es das nicht tut - who cares? Ich koennte es ja verstehen, wenn Jonas von irgendjemandem wegen der Loeschung von solchen Nodes kritisiert worden waere, aber das war gar nicht der Fall. Es wirkte auf mich eher so, als ob Jonas irgendwie langweilig war und er nach irgendwelchen Proposals gesucht hat, die er der breiteren Oeffentlichkeit vorwerfen kann. Dabei kam er dann auf ungetaggte Nodes (sollte man gleich mal einen Bot drauf ansetzen), und ich habe ihm geantwortet, immer mal langsam mit den jungen Pferden, solche Nodes koennen durchaus ihren Grund haben. Es gibt viele interessante Betaetigungsfelder bei OSM fuer Leute mit Tatendrang. Ich wuerde mich freuen, wenn Jonas sein Augenmerk etwas staerker drauf lenken wuerde, selbst etwas zu erschaffen, anstatt Regeln zu erarbeiten, mit denen er anderen vorschreibt, wie sie ihre Arbeit tun sollen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
ein Giesskannenverleih - oder meinst du damit nur die ähnliche Taggingstruktur? Ja. -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tipps zum Friedhofmapping gesucht
amenity=water drinkable=no Was, wenn sicher bekannt ist, dass es sich um Trinkwasser handelt? Kann man dann amenity=drinking_water verwenden? Dann sollte aber wenigstens ein Schild Trinkwasser angebracht sein. Ich ueberlege, aber gerade, ob man die vielen zerstreuten Wasserstellen nicht zu einem Tag zusammenfassen sollte. Jede Fachrichtung hat sich ein eigenes Tag fuer die Wasserstelle ausgedacht. Wasserstelle fuer Menschen (Trinkwasser) Wasserstelle fuer Pferde Wasserstelle um Boot/Caravan zu betanken ... Sind doch alles Wasserstellen trinkbar=j/n gedacht fuer = Boot, Caravan, Pferd, Mensch, Giesskanne Gebuehr = j/n Schlauch =j/n Anschluss = ... Becken =j/n Hat jemand Lust das weiter zu denken und ggf. ein Proposal zu giessen? Gruesse, -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
On 16.08.10 23:39, Jonas Stein wrote: Nach und nach stellen wir fest, was man alles leihen und mappen kann. Dabei sind die Verleihstationen strukturell gleich. Sie unterscheiden sich nur in dem was man ausleiht. So wie bei der dancing_school: mir fällt jetzt nicht ein, was der Benefit wäre, das unter einen gleichen key zu bringen. Es gibt sicher kein generisches hier kannst Du Dir was ausleihen Symbol, sondern es wird immer ein den Gegenstand (oder die Gruppe) brauchen: - hier kannst Du Dir ein Fahrrad leihen - hier ist eine Autovermietung - hier ist das Haus der 1000 Maschinen oder sowas. Warum also sollte man ohne Not bestehende, funktionierende Tags (amenity=bicycle_rental, amenity=car_rental) über'n Haufen schmeißen? Wenn Du jetzt sagst, Du bräuchtest einen Tag zum Verleihen von etwas, das es noch nicht gibt (nehmen wir das Maschinen-Beispiel, das gibt's glaube ich noch nicht), dann könnte man einen hier kann man sich was anderes ausleihen und zwar Maschinen überlegen .Z.B. amentiy=rental_agency für sowas. Aber bicycle/car_rental muß man deswegen nicht anfassen, finde ich. Und den Segway Rental würde ich als Option zu bicycle_rental dazunehmen, das kommt in der Praxis wohl realistisch wirklich vor (z.B. http://www.pedalpower.at/ verleiht in Wien Segways). Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tipps zum Friedhofmapping gesucht
Am 17. August 2010 10:51 schrieb Jonas Stein n...@jonasstein.de: Was, wenn sicher bekannt ist, dass es sich um Trinkwasser handelt? Kann man dann amenity=st drinking_water verwenden? Dann sollte aber wenigstens ein Schild Trinkwasser angebracht sein. nö, es ist völlig unerheblich, ob da ein Schild steht, solange die Bedingung gilt: es ist sicher bekannt, dass es sich um Trinkwasser handelt Wasserstelle fuer Menschen (Trinkwasser) wieso für Menschen? http://wiki.openstreetmap.org/wiki/Drinking_Water spricht von Trinkwasser und fertig. Wasserstelle um Boot/Caravan zu betanken da geht es wohl um den Anschluss, es handelt sich sozusagen um spezialisierte Wohnwagenwasserstellen. Sind doch alles Wasserstellen trinkbar=j/n das ist alles trinkbar, es gibt keine Trinkwasserstellen trinkbar=nein. gedacht fuer = Boot, Caravan, Pferd, Mensch, Giesskanne Gebuehr = j/n Schlauch =j/n Anschluss = ... Becken =j/n Hat jemand Lust das weiter zu denken und ggf. ein Proposal zu giessen? bisher brauchte da noch niemand weitere Details. Ich plane allerdings, in meiner demnächst zu veröffentlichenden lokalen Trinkwasserkarte auch die Typen der einzelnen Trinkbrunnen - soweit Daten vorhanden - anzuzeigen. Schlauch, Becken, Anschluss und Gebühr kommt dabei allerdings bisher nicht vor (in der Realität), oder ist durch den Typ bereits abgedeckt, weshalb ich keine Motivation habe, diese ganzen Werte vorzusehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Seekabel
Hallo zusammen, ich bin gerade durch Zufall auf diese Seite [1] des Kingfisher Information Service gestolpert, auf der die Koordinaten von Seekabeln (XLS-File [2]) rund um Großbritannien gelistet sind. Die ersten beiden Kabel habe ich mir stichprobenartig (Anlandestelle in GB) angesehen und nicht in OSM gefunden. Meinem Verständnis nach sind die Daten zu OSM kompatibel (FREE OF CHARGE). Deswegen würd ich die Kabel gerne (händisch) importieren. Für Stromkabel würde ich das etablierte Tagging (power=cable) beibehalten aber für Kommunikationskabel bin ich weder im Wiki noch im talk-de-Archiv noch bei der Freien Tonne auf ein passendes Tag gestoßen. Ich hatte an folgendes gedacht: man_made=cable cable=communication Ideen/Alternativen/Ergänzungen? Gruß, Markus [1] http://www.kisca.org.uk/charts.htm [2] http://www.kisca.org.uk/ThinnedCables_Feb_2010.zip ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
Am 17. August 2010 11:01 schrieb Andreas Labres l...@lab.at: So wie bei der dancing_school: mir fällt jetzt nicht ein, was der Benefit wäre, das unter einen gleichen key zu bringen. naja, dort hat man sich doch auch geeinigt (oder?), school=dancing ohne amenity=school zu benutzen. Es gibt sicher kein generisches hier kannst Du Dir was ausleihen Symbol, sondern es wird immer ein den Gegenstand (oder die Gruppe) brauchen: - hier kannst Du Dir ein Fahrrad leihen - hier ist eine Autovermietung - hier ist das Haus der 1000 Maschinen oder sowas. ein generisches Symbol ist sicher nicht die beste Lösung, würde aber zusammen mit einem Text schon Sinn ergeben. aus rental=ufo könnte jeder Datenkonsument sofort erkennen, dass da Ufos verliehen werden, auch wenn er gar nicht weiss, was Ufos sind. Warum also sollte man ohne Not bestehende, funktionierende Tags (amenity=bicycle_rental, amenity=car_rental) über'n Haufen schmeißen? das müsste man ja gar nicht. rental und amenity könnte man übergangsweise beides taggen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Hi ! ich habe kürzlich erst gesehen das man den Garmin auch über USB-Port anschließen kann. Das war allerdings ein LINUX Rechner. Kann mir einer sagen ob das mit dem USB auch bei Windows geht - muss ich dort dasselber mit gpsd machen wie bei einem bluetooth gps ??? ... oder gibt es eine andere Befehlsreihenfolge? gpsd und live-gps habe ich nämlich gestartet und im zweiten batch wird immer AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm AutoSaving finished AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm AutoSaving finished AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm gemeldet - kommt wohl irgendetwas an - aber im josm ist nichts zu erkennen !! Versuche ich die D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm zu öffnen bekomme ich die Meldung das diese nicht existiert !! Da sind auch nur D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm.tmp zu finden Kann mir einer weiterhelfen ??? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Hi ! ich habe kürzlich erst gesehen das man den Garmin auch über USB-Port anschließen kann. Das war allerdings ein LINUX Rechner. Kann mir einer sagen ob das mit dem USB auch bei Windows geht - muss ich dort dasselber mit gpsd machen wie bei einem bluetooth gps ??? ... oder gibt es eine andere Befehlsreihenfolge? gpsd und live-gps habe ich nämlich gestartet und im zweiten batch wird immer AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm AutoSaving finished AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm AutoSaving finished AutoSaving data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.gpx AutoSaving osm data to file D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm gemeldet - kommt wohl irgendetwas an - aber im josm ist nichts zu erkennen !! Versuche ich die D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm zu öffnen bekomme ich die Meldung das diese nicht existiert !! Da sind auch nur D:\OpenStreetMap\JOSM\surveyor-20100817-100917.osm.tmp zu finden Kann mir einer weiterhelfen ??? gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel
Am 17. August 2010 11:08 schrieb olvagor o...@terbrueggen.net: Meinem Verständnis nach sind die Daten zu OSM kompatibel (FREE OF CHARGE). Deswegen würd ich die Kabel gerne (händisch) importieren. meinem Verständnis nach nicht. Die Daten kommen von http://www.ukcpc.org.uk/guidelines.asp dort steht: © Copyright 2001 - 2010 UKCPC allerdings sind die Daten wohl auch von der EU, irgendwo kann man sie also vielleicht in einer kompatiblen Lizenz bekommen. Interessant finde ich diese Art Daten auf jeden Fall. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel
Am 17. August 2010 11:16 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 17. August 2010 11:08 schrieb olvagor o...@terbrueggen.net: Meinem Verständnis nach sind die Daten zu OSM kompatibel (FREE OF CHARGE). Deswegen würd ich die Kabel gerne (händisch) importieren. meinem Verständnis nach nicht. Die Daten kommen von http://www.ukcpc.org.uk/guidelines.asp dort steht: © Copyright 2001 - 2010 UKCPC wobei dort auch steht: The data is also available for download over the Internet - both in readable text/graphic form as pdf files, and as files ready encrypted for the supported plotter systems. The final objective is the free distribution of the data, in the most useable form, to all relevant fishing vessels working in the waters covered. Das Endziel ist die kostenfreie Distribution der Daten..., d.h. die Aussichten stehen wohl nicht schlecht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Am 17. August 2010 11:11 schrieb o...@tappenbeck.net o...@tappenbeck.net: ich habe kürzlich erst gesehen das man den Garmin auch über USB-Port anschließen kann. Das war allerdings ein LINUX Rechner. Kann mir einer sagen ob das mit dem USB auch bei Windows geht - muss ich dort dasselber mit gpsd machen wie bei einem bluetooth gps ??? kurz mal aufs Datum geschaut, ob der 1. April ist ;-) Klar kannst Du den 60CSx über USB anschließen, das ist m.E. Standard. Treiber gibts bei Garmin oder auf der mitgelieferten CD. Weitere Software brauchst Du nicht zwangsläufig, könnte aber evtl. hilfreich sein, je nachdem, was Du damit machen willst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 17.08.2010 11:08, schrieb olvagor: Meinem Verständnis nach sind die Daten zu OSM kompatibel (FREE OF CHARGE). free of charge = free as in beer Beste Grüße, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMalUGAAoJEPT/XJzV1tNz4scH/2XZ8miWM7qZG5CF0nfXWTh0 1ANbFozGEXZeGhFwowR33B3F3RnReFAfbysqrIhk6dNRGcvDSdWFKy5jaAPSo65q WFewGYQJtn5CjisB3pGH3M6kphz7jmAEtKWh2jGG+/0qMEn719x4FkKhs38huUfc OKtPkXwqmOG3xWdSQrNPwznu/4d2kGlbc+RFYGDMXD5pKtv50UKKFt879c13ZbNl 9ox9BwJOSUwk0kbSvGKsmXlHOKv42L2DGYtTz/ukZFXTPZzKAX9vGB3fbz4a8uRK AlRaTVlTCNdeTu6GiVSKe7a+kP3AzMO4XgrrIRtAI8HuWSqP+2hqt971/DlMQwQ= =WF2P -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
On 17.08.10 11:11, M∡rtin Koppenhoefer wrote: naja, dort hat man sich doch auch geeinigt (oder?), school=dancing ohne amenity=school zu benutzen. Also geeinigt sehe ich nicht... ;) Ich finde die aktuelle Tendenz, weil es als amenity schon so viele values gibt, ständig neue keys zu erfinden (emergency=, school=, rental=), insgesamt nicht so prickelnd. Sowohl der Radverleih wie die Tanzschule sind amenities, also sollte man den key dafür auch verwenden. Irgendwie tut das ja niemandem weh, wenn die amenity-Tabelle lang ist. Irgendwie gibt es gewisse HauptKeys (wie amenity oder leisure usw.) und es gibt eine Menge (oft universell nutzbarer) OptionenKeys (wie opening_hours= oder ref=). Und ich finde es nicht gut, neue Keys, die meist als Option zu irgendwas erfunden wurden, dann zu einer indirekten Erweiterung einer Hauptkategorie vergenußzwergelt werden. Ich finde, man sollte das schärfer trennen und dann eben auch alleinstehende OptionenKeys als verboten ansehen, anstatt implizit was hineinzuinterpretieren. Wenn nicht amenity=bicycle_rental, dann amenity=rental_station und subject_of_rental=bicycle,segway. Wenn nicht amenity=dancing_school, dann amenity=school und type_of_school(oder type:school)=dancing. Aber da die Zusammenfassungen von Dingen, die nix miteinander zu tun haben, für mich auch keinen Sinn macht, wäre ich am ehesten dafür, die entsprechenden amenity=(bicycle_rental|car_rental|dancing_school|driving_school|skiing_school) values zu nehmen. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad- und Wanderweg auf gleichem Weg -- wie taggen
Am 16. August 2010 23:31 schrieb smart...@gmx-topmail.de: Hi, ein geteerter 2m-Breiter Weg ist entweder tracktype1 oder unclassified. Aber auf keinen Fall ein Path. Meiner Meinung nach: Path= ein Trampelpfad, unbefestigter Waldweg kleiner als eine Autobreite. Eben nicht, path ist ein Modell, das alle untergeordneten (also unterhalb von track) Wege beschreiben kann, also gerade auch gut ausgebaute, ausgewiesene Fuß- und Radwege. Die können, zumal wenn kombiniert oder als Zweirichtungsradweg, schon mal locker 2,5 m und mehr erreichen, also eigentlich ganz komfortabel zum Auto fahren... ;-) Ich würde sie, wenn sie tatsächlich per Blauschild ausgewiesen sind, trotzdem nicht als track oder service taggen, vor allem nicht innerorts (bei umgewidmeten, ehemals landwirtschaftlichen Wegen bin ich mir da nicht so sicher, vor allem, wenn sie eine Ausnahmegenehmigung für lw. Verkehr enthalten..). Die Breite sollte also, vor allem im innerörtlichen Bereich, nicht als alleiniges Kriterium herhalten. Die Wanderwege und Radwege werden als Relation auf den Weg gelegt. Richtig, wenn man *wege durch *routen austauscht, wird's noch deutlicher. Schau Dir bitte unbedingt die Map-Features an: http://wiki.openstreetmap.org/wiki/DE:Map_Features Dort steht richtigerweise, daß mit path _auch_ Trampelpfade getaggt werden können, nicht, daß path Trampelpfad bedeutet. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad- und Wanderweg auf gleichem Weg -- wie taggen
Am 17. August 2010 12:03 schrieb Martin Simon grenzde...@gmail.com: Ich würde sie, wenn sie tatsächlich per Blauschild ausgewiesen sind, trotzdem nicht als track oder service taggen, vor allem nicht innerorts +1 (bei umgewidmeten, ehemals landwirtschaftlichen Wegen bin ich mir da nicht so sicher, vor allem, wenn sie eine Ausnahmegenehmigung für lw. Verkehr enthalten..). +1, da bin ich mir sicher, dass es tracks sein sollten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Zitat o...@tappenbeck.net: ich habe kürzlich erst gesehen das man den Garmin auch über USB-Port anschließen kann. Das war allerdings ein LINUX Rechner. Jepp, und zwar meiner. Ich hab's dir doch damals gezeigt, oder nicht? Es steht auch in der Beschreibung des Garmin, also rtfm! Kann mir einer sagen ob das mit dem USB auch bei Windows geht - Jepp, dein Rechner kann das. Einfach mal alles zusammenstecken und warten, was passiert. Ist ganz einfach, Jan. ;-) Wenn sich nix tut, PM an mich, ich ruf zurueck. muss ich dort dasselber mit gpsd machen wie bei einem bluetooth gps ??? Ja. Halt eben nur ueber USB. -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
Hi Andreas, Warum also sollte man ohne Not bestehende, funktionierende Tags (amenity=bicycle_rental, amenity=car_rental) über'n Haufen schmeißen? Uebern Haufen geschmissen werden die ja nicht gleich. Das rental soll ja voll kompatibel mit den bestehenden sein. Vieles ist in der Entwicklung und manche Tag-Schemata wurden schon mit der Zeit angepasst, weil man bessere Methoden fand. Falls sich rental etablieren sollte (derzeit sind wir ja noch bei der Planung wie es aussehen koennte) - dann wuerde wohl in ein paar Jahren die amenity=car_rental von der community als obsolet markiert werden. Man muss auch bedenken, dass wir bis jetzt nur 5 Verleih-Tags haben. Davon einige die noch im 'vote' Stadium sind. Verleihbare Dinge gibts aber zu tausend. Wenn statt einem Ski nun Schlitten geliehen werden koennen bedarf das kein Proposal mit eigener Struktur mehr, sondern kann auf kurzem Dienstweg ergaenzt werden. siehe auch http://wiki.openstreetmap.org/wiki/Proposed_features/rental#Rationale -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
ein generisches Symbol ist sicher nicht die beste Lösung, +1 das Proposal wurde mittlerweile dahingehend etwas ergaenzt. Anhand des vlues wird ein anderes Icon gerendert. So wie der Value vom Shop unterschieden wird. -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Hallo Steffterra, habe den Thread erst jetzt gelesen, von meiner Seite für den Ansatz eine +1 ! Dies könnte man aber Problemlos auch nur im Editor umsetzen. Um es mit deinem Beispiel zu verdeutlichen: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (innen eingezeichnet Süd-Nord): maxspeed=50, destination=Hamburg -way (außen eingezeichnet Süd-Nord): maxspeed=40, destination=Bahnhof könnte man auf das aktuelle Schema mit highway=secondary name=Beispielstraße bicycle=designated cycleway:right=lane maxspeed:forward=60 maxspeed:backward:lane-1=50 maxspeed:backward:lane-2=40 (mögliche Lösung um die Fahrspuren aus deinem Ansatz zu addressieren) destination:forward=München destination:backward:lane-1=Hamburg destination:backward:lane-2=Bahnhof lanes=4 (oder auch lanes:forward=2, lanes:backward=2) Ein Editor könnte alle :forward/:backward und :left/:right ausblenden und statdessen die parallelen Ways darstellen. Alternativ könnte ein Editor auch drei Eingabefelder bieten: Eins für allgemeine Tags, eins für die Tags in Pfeilrichtung und eins für die Tags entgegen der Pfeilrichtung. Auch das drehen eines Weges sollte nicht unterbunden werden - die Anwendung müsste beim drehen des Weges nur automatisch :forward in :backward, :left in :right, (und :lane-2 in :lane+2) ändern. Grüße, Robert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
Am 17. August 2010 12:55 schrieb Jonas Stein n...@jonasstein.de: Hi Andreas, Warum also sollte man ohne Not bestehende, funktionierende Tags (amenity=bicycle_rental, amenity=car_rental) über'n Haufen schmeißen? Uebern Haufen geschmissen werden die ja nicht gleich. Das rental soll ja voll kompatibel mit den bestehenden sein. Vieles ist in der Entwicklung und manche Tag-Schemata wurden schon mit der Zeit angepasst, weil man bessere Methoden fand. Genau, aber in diesem Fall ist die Methode eben (wie bereits ausgeführt) nicht besser, weil sie das taggen nicht erleichtert. Eine Autovermietung ist mit einer Schlittenvermietung nicht vergleichbar. Daher ist es sinnlos alle unter einem gemeinsamen Tag zusammenzufassen. Sinn macht das beispielsweise bei natural=wetland/wetland=*, weil nicht jeder Sumpf, Moor, Salzwiesen etc. unterscheiden kann. Die wichtige gemeinsame Information ist: dort bekommt man nasse Füße Hier ist eine Differenzierung mit Sub-Tags also sehr sinnvoll. Das jemand eine Autovermietung von einem Skiverleih nicht unterscheiden kann ist eher unwahrscheinlich. Die gemeinsame Oberinformation hier kann man etwas mieten ist zudem völlig wertlos ... Für so etwas gibt es fixme=* Eine Umstellung bloß um weniger verschiedene Werte für amenity zu erhalten, ist nicht gerechtfertigt, da es an einem praktischen Nutzen fehlt (reine Formsache). Falls sich rental etablieren sollte (derzeit sind wir ja noch bei der Planung wie es aussehen koennte) - dann wuerde wohl in ein paar Jahren die amenity=car_rental von der community als obsolet markiert werden. Man muss auch bedenken, dass wir bis jetzt nur 5 Verleih-Tags haben. Davon einige die noch im 'vote' Stadium sind. Verleihbare Dinge gibts aber zu tausend. Wenn statt einem Ski nun Schlitten geliehen werden koennen bedarf das kein Proposal mit eigener Struktur mehr, sondern kann auf kurzem Dienstweg ergaenzt werden. Ich akzeptiere Tags auch wenn sie keinen Proposalprozess durchlaufen haben ... Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Am 17.08.2010 13:06, schrieb Robert Heel: Auch das drehen eines Weges sollte nicht unterbunden werden - die Anwendung müsste beim drehen des Weges nur automatisch :forward in :backward, :left in :right, (und :lane-2 in :lane+2) ändern. ... wobei ein :lane1 und :lane2 ausreichen würde und kein Vorzeichenwechsel notwendig wäre, da :forward und :backward ja bereits die Richtung angibt ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: was soll mit leeren nodes gemappt werden?
Zunaechst muessen wir die Frage klaeren: Wollen wir eine Karteninformation egal welcher Art durch geometrische Anordnung leerer Nodes ablegen? Muessen wir nicht. [..] Warum streubst Du Dich so sehr dagegen, dass dies von der Community sachlich hinterfragt wird? Ich finde es ist voellig legitim sich sachlich und hoeflich darueber zu diskutieren. Das Thema ist wichtig fuer alle, die sich mit Fehlersuche, Validatoren, Skripten und der API beschaeftigen. Ein Bedarf der Diskussion besteht alleine deswegen schon, weil diese Methode bislang noch sehr unbekannt ist. Im IRC wusste keiner davon, dass jemand etwas sinnvolles mit Nodes malen moechte, bis Du uns aufgeklaert hattest. Gleiches Bild zeigt sich in den Mailinglisten. In der internationalen talk-Liste - loeschten fast alle leere Nodes - wurde vom malen mit leeren Nodes ohne Fixme und note dringend abgeraten - war weitgehend unbekannt, dass es User gibt, die durch leere Nodes Informationen hinterlegen Die Diskussion laeuft dort sehr sachlich und informativ ab. Da der thread schon recht gross ist sammel ich hier verschiedene Statements, die fuer das Thema interessant sein koennten. http://wiki.openstreetmap.org/wiki/Emptynodes Mithilfe natuerlich erwuenscht... es ist ein Wiki. Beste Gruesse, -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel
Am Dienstag, den 17.08.2010, 11:18 +0200 schrieb M∡rtin Koppenhoefer: wobei dort auch steht: The data is also available for download over the Internet - both in readable text/graphic form as pdf files, and as files ready encrypted for the supported plotter systems. The final objective is the free distribution of the data, in the most useable form, to all relevant fishing vessels working in the waters covered. Das Endziel ist die kostenfreie Distribution der Daten..., d.h. die Aussichten stehen wohl nicht schlecht. Hm stimmt, das hatte ich auch eben gefunden. Ich glaub, ich werd da mal ne Mail hinschreiben. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal: Verleih von xy
Am 17. August 2010 12:58 schrieb Jonas Stein n...@jonasstein.de: ein generisches Symbol ist sicher nicht die beste Lösung, +1 das Proposal wurde mittlerweile dahingehend etwas ergaenzt. Anhand des vlues wird ein anderes Icon gerendert. Icons in Proposals sind zwar nett, aber das Voting bezieht sich nicht darauf. Jeder, der eine Karte rendert, entscheidet selbst darüber, ob und wie er ein feature darstellt. Von daher ist es ein Service für manche Kartenersteller, schonmal einen Iconvorschlag zu haben (schaden tut's nicht), aber wer eine eigene Karte mit grafischem Anspruch erstellt wird meist ein Icon brauchen, dass zum eigenen Stil passt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: was soll mit leeren nodes gemappt werden?
Am 17. August 2010 14:58 schrieb Jonas Stein n...@jonasstein.de: Sorry das stimmt. Ich nehm alles zurueck. Hier stehts: http://wiki.openstreetmap.org/wiki/Untagged_unconnected_node User 'Head' hatte mich gerade darauf aufmerksam gemacht. nur weil der User Harry im April 2010 festgelegt hat, dass (alle/manche?) ungetaggten und unverbundenen Nodes bugs sind, ist das noch lange nicht Gesetz. Von Freds Idee (bzw. , dass er es so macht, weil jemand das mal so vorgeschlagen hat, und er das lustig findet), 3 Punkte in die Daten zu malen, wissen die Mapper, die hier schon länger mitlesen, über die Liste. Ich halte das persönlich nicht für schädlich und finde die Aufregung total übertrieben. Andererseits würde ich es auch niemandem empfehlen, FIXMEs so unterzubringen: die Gefahr ist einfach zu groß dass ein Saubermann daherkommt und einem das wieder rauslöscht. Auch ist der Nutzen m.E. eingeschränkt, weil man die Nodes schlechter wiederfinden kann als einen determinierten Tag. Prinzipiell hoffe ich, dass wir wieder mehr zu leben und leben lassen zurückkommen, und weniger bei Ich habe Recht und das setze ich auch mit allen Mitteln durch, notfalls gegen meine Mitstreiter! verharren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
Am 16.08.2010 22:53, schrieb Ulf Lamping: In meiner Umgebung sind aktuell bereits ein Paar Reifenhändler mit shop=car_repair getaggt. Das stimmt zwar einerseits (es ist ja eine Art Autoreparatur) Wenn es eine Art Autoreparatur ist, sollten wir das so auch abbilden: shop=car_repair car_repair=tyres Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
Am 17. August 2010 15:42 schrieb Peter Körner osm-li...@mazdermind.de: Am 16.08.2010 22:53, schrieb Ulf Lamping: In meiner Umgebung sind aktuell bereits ein Paar Reifenhändler mit shop=car_repair getaggt. Das stimmt zwar einerseits (es ist ja eine Art Autoreparatur) Wenn es eine Art Autoreparatur ist, sollten wir das so auch abbilden: shop=car_repair car_repair=tyres -1, wenn, aber ist es m.E. eher nicht. Es ist eine bestimmte Art von Wartung bzw. Ersatzteilhandel (Verschleißteilersetzung), nicht Reparatur. Der Nutzen von Subtags ist hier m.E. begrenzt und im Zweifel eher irreführend (wessen Fahrzeug kaputt ist, der will keinen Reifenhändler finden, und andersrum). Reifenhändler (wie die übrigens auf deutsch heissen, nicht Reifenreparateure oder so) sind m.E. eine eigene Klasse. Evtl. eher Autozubehör als Autoreparatur (wenn man um jeden Preis subtaggen will). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Falk Zscheile wrote: Am 17. August 2010 07:17 schrieb Mario Salvini salv...@t-online.de: Am 17. August 2010 03:21 schrieb Andreas Labres l...@lab.at: On 11.08.10 21:24, Jan Jesse wrote: water:depth= Welche water:* oder welche *:depth gibt's sonst noch? water:*=* -- andere Attribute des Wassers (spontan fallen mir nur Sachen wie Farbe oder Salzgehalt ein, die ich jetzt nicht sonderlich sinnvoll fände; aber vielleicht hat ja jemand was konkretes) depth bezieht sicher aber schon immer auf Wasser, deshalb könnte man den Key in der Tat auch gleich depth=* nennen. Interessanter als die Frage nach dem Namen des Tags ist aber die Frage, was dann damit getaggt wird. Einen einzelnen Node mit Tiefenangabe finde ich z. B. weniger sinnvoll als eine bekannte Mindesttiefe in einem Fahrwasser, einer Durchfahrt oder einer sonstigen Wasserfläche. Auf diese Weise lassen sich mit recht wenig Aufwand sinnvoll für nautische Zwecke nutzbare Tiefendaten eines ganzen Gewässernetzes in OSM einführen. Einzelnodes mit depth=3.7 sagen mir dagegen nichts darüber, ob ich dazwischen sicher durchfahren kann oder nicht. Dies scheint mir Teil des Gedankenproblems hinsichtlich water:depth vs. seamark:depth in diesem Thread zu sein. Maximaltiefen könnten für nicht-nautische Zwecke ebenfalls sinnvoll sein. depth könnte beispielsweise auch angeben, wie weit die Wasseroberfläche eines Sees unter normal Null liegt (Nur als Gedankenspiel.) Nein. *Tiefe* bezieht sich immer auf die Entfernung eines Gewässergrunds zur Wasseroberfläche. Bei Wasserflächen in Depressionen hat die Oberfläche eine negative *Höhe* unter dem Meer. Habe ich jedenfalls anders noch nie gesehen. Auf jeden Fall werden Tiefen in Richtung Erdmittelpunkt größer, und Höhen werden in Richtung Weltraum größer. (Die Tiefen in Binnenseen werden in topographischen (Land-)Karten aber auch manchmal als Höhen angegeben, in Metern über NN, bzw. der jeweiligen Bezugsfläche der Landesvermessung. Das kann verwirren.) Was mir noch fehlt ist das Bezugssystem, auf das sich die Wassertiefe Höhe bezieht, also auf welches normal Null sich die Wassertiefe aber auch die Höhe von Bergen etc. bezieht. Meiner Ansicht nach hat OSM gegenwärtig keine Probleme mit unterschiedlichen Bezugsflächen. Die Unterschiede zwischen den sinnvollen Bezugssystemen liegen nämlich typischerweise im Bereich der Messungenauigkeit. Vor die Wahl von einheitlichen Höhenbezugsflächen in OSM sollte meiner Ansicht nach die Suche nach entsprechenden Use-Cases gestellt werden. -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osm in NANO 3 Sat
Jetzt in NANO auf 3Sat. Openstreetmap mit Navi für Behinderte lg,Bernhard http://khtml.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Leuchttuerme und andere Landmarken (ex: Unterscheidung)
Mario Salvini wrote: Am 16. August 2010 23:35 schrieb Arne Johannessen a...@thaw.de: [...] Das Tage würde ich dann aber vielleicht anders nennen, denn die IHO definiert ausdrücklich (eigentlich durchaus logisch): landmark ungleich seamark Wie wäre es mit einfach nur: landmark=* (z. B. landmark=yes oder landmark=prominent) Im Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging#Landmarks ist das Konzept für landmark zwar ein etwas anderes. [...] stimmt. im Proposal wird dabei mehr auf die S57 bezug genommen, die mit dem Akronym LNDMRK (Landmark) und dem Attribut CATLMK (Category of Landmerk) die Möglichkeit bietet Landmarken zu beschreiben. Aber vermutlich habt ihr recht und wir können das Dank OSM und der schon vorhandenen TAGgin-Kultur anders die gleichen Sachen erfassen (z.B. für cemetry, winmill, tower, etc..) Ja, also wir haben ja hier den Sonderfall, zu einer existierenden Landkarte (OSM) nautisch-hydrographische Daten hinzufügen zu wollen. S-100/S-101, S-57 und S-4 (früher M-4) sind alle für Daten bzw. Karten vorgesehen, die von vornherein nur zur Navigation gedacht sind -- Seekarten eben. Die IHO-Standards sind sicherlich auch für uns sehr nützlich. Für bereits in OSM konzeptuell vorhandene Objekte wie Gebäude, Brücken, Straßen etc. sollten sie aber nicht angewandt werden bzw. höchstens in Bezug auf den nautischen Wert dieser Objekte. Andreas Labres wrote: Bei Landmarken ist aber eine Kennzeichung das ist eine Landmarke schon relevant. Das Ding muß von See gut zu sehen sein, es hilft Dir nix, wenn der Kirchturm in einer Senke steht und davor ein Hügel mit Wald Dir die Sicht verdeckt. Oder blöd, wenn diese Kirche grade keinen weithin sichtbaren Kirchturm hat. Mario Salvini wrote: Mit landmark=yes/promentent/whatever könnt ich mich persönlich auf jeden Fall durchaus anfreunden. :) Dass ein derartiges Tag konsensfähig seien könnte, scheint der bisherigen Diskussion hier jedenfalls zu entnehmen zu sein. Das könnten wir vielleicht auch mal im Wiki irgendwie dokumentieren? Ich habe da leider noch keinen Account und bin mir hinsichtlich der Gepflogenheiten unsicher. Ich hätte z. B. Skrupel, einfach so das Proposal zu bearbeiten. Wie geht man hier am besten vor? M∡rtin Koppenhoefer wrote: Am 16. August 2010 23:35 schrieb Arne Johannessen a...@thaw.de: (Mögliches Problem: Landmarken für die Luftfahrt?) wie wärs mit landmark=nautic? Wenn es natürlich von Land, See und aus der Luft ein Landmark ist (dürfte öfters vorkommen), dann bräuchte man dafür evtl. einen extra Wert (sowas wie landmark=nautic/aerial/all od. yes). nautical hieße das auf Englisch. Gegenpart: aeronautical. Ein Bisschen lang, funktioniert aber vom Prinzip her prima. Der Fall beide würde wohl von landmark=nautical;aeronautical abgedeckt (wegen mir auch landmark=all), der Fall weiß nicht genau von landmark=yes. Rolf Meyerhof wrote: Warum nicht landmark=navigation ? wenn es für Land Luft und See gelten soll? Ginge vom Prinzip her auch (gefällt mir nicht besonders, ist aber nur Geschmacksache). Mario Salvini wrote: vielleicht im zweifelsfalle ein landmark:naval=* oder landmark:aerial=* ? naval heißt wörtlich Flotten- (also militärischer Bezug), passt daher nicht. Dass wir hier einen extra Namensraum brauchen, glaube ich auch nicht. Dass eine Landmarke auffällig ist, können wir ebenso gut über conspicuous=yes o. ä. erfassen. (Wenn Du fließend in S-57 denkst: das entspräche dem Attribut CONVIS=1) Mario Salvini wrote: Bei den Baken haben wir ja im Grunde ein ähnliches Problem mit Luft unf Wasser ;) Haben wir? Ich kenne in der Luftfahrt an Beacons nur die ABNs, die das bekannte Blinksignal auf Flugplätzen von sich geben (normal W/W in Deutschland, W/G in Nordamerika). Das kann man prima genau wie Feuer (Lichter) auf Leuchttürmen und Tonnen taggen (wird in Seekarten auch so gemacht). Die Widmung der Lichter (z. B. Aero. / CATLIT=5 etc.) bräuchten wir eigentlich auch noch ... aber das kann wohl warten. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] landuse=residential wird nicht gerendert...
Hallo, ich habe jetzt alles versucht, was mir eingefallen ist, aber ich komme nicht drauf... Wer kann mir sagen, warum diese Fläche: http://www.openstreetmap.org/browse/way/72541717 nicht vom Mapnik gerendert wird... Ich komme einfach nicht drauf... :-( Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm in NANO 3 Sat
Der Beitrag wurde jetzt schon recht oft im fernsehen recycled, leider On Di, 2010-08-17 at 18:33 +0200, bernhard zwischenbrugger wrote: Jetzt in NANO auf 3Sat. Openstreetmap mit Navi für Behinderte signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=residential wird nicht gerendert...
Am 17. August 2010 18:50 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Hallo, ich habe jetzt alles versucht, was mir eingefallen ist, aber ich komme nicht drauf... Wer kann mir sagen, warum diese Fläche: http://www.openstreetmap.org/browse/way/72541717 nicht vom Mapnik gerendert wird... Ich komme einfach nicht drauf... :-( Sie ist nicht geschlossen... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seekabel
olvagor schrieb: Das Endziel ist die kostenfreie Distribution der Daten..., d.h. die Aussichten stehen wohl nicht schlecht. Hm stimmt, das hatte ich auch eben gefunden. Ich glaub, ich werd da mal ne Mail hinschreiben. Mail ist unterwegs, dann bin ich mal auf das Ergebnis gespannt. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=residential wird nicht gerendert...
Sie ist nicht geschlossen... inzwischen schon, sah auf den ersten blick ganz sauber aus, erst der validator in josm hat's gemerkt. am forst 25 ist noch etwas merkwürdig - hat aber nix mit dem problem zu tun. gruss walter - Mögest Du in interessanten Zeiten leben - alter chinesischer Fluch -- View this message in context: http://gis.638310.n2.nabble.com/landuse-residential-wird-nicht-gerendert-tp5433011p5433168.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Mario Salvini wrote: [http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging] also der erste Link zum Proposal war der offizielle bzw. öffentliche We der Community Seezeichen zu erfassen. Die anderen Links sind entweder Inhalte der einen oder der anderen überwiegend deutschen Fraktionen (ich glaube das bekommt die restliche Welt garnicht so mit) Aha, danke für die Klarstellung. In den letzten Tagen wurde ja auch schon ein wenig weiter am Wiki gearbeitet; damit und mit den laufenden Diskussionen zum Thema wird mir nun klarer, was wozu gehört. Ich spreche jetzt mal zur zum Proposal, über die anderen Links können sich die jeweiligen Gruppen äußern. Mir persönlich wäre eine klare Bezeichnung im Link (z.B. OSeaM/Bake-Schema.. etc. dass es sich um Projekt-Unterseiten handelt wichtig, weil sonst wirklich bald kein Aussehnstehender mehr durchblickt... +1 Ich habe jedenfalls bis vor wenigen Tagen da überhaupt nicht durchgeblickt. Das Proposal orientiert sich am Schema S57 Dies, also die Nähe des Proposals zu S-57, kann ich überhaupt nicht feststellen. Das ist aber, wie schon angedeutet, auch Sehr Gut So (mit großen Anfangsbuchstaben). Auf [OSM-talk] fiel auch gerade der Begriff S-57 (im Thread Tagging Seamarks). Ich will die Stränge jetzt nicht redundant führen, daher gerade nur so viel: S-57 ist ein eigentlich veraltetes, binäres, äußerst unflexibles Datenformat, dessen Methodik bei der Kategorisierung und Auszeichnung von Geodaten mit der Technik und den Werten von OSM grundsätzlich inkompatibel ist. S-57 zu folgen, ist also *nicht* anzustreben. Dennoch kann natürlich S-57 zusammen mit dem Nachfolger S-100/S-101 und dem IHO-Standard für Papierseekarten S-4 (ehemals M-4) zusammen mit dessen Anhängen INT 1 (Karte 1), INT 2 und INT 3 als extrem nützliches Nachschlagewerk zu nautischen Geodaten dienen. Ich nehme an, dies ist auch das, was mit den zahlreichen Referenzen zu S-57 gemeint sein soll? Darauf bezieht sich meine Nachfrage in diesem Thread. Die Formulierung im Wiki wäre in dem Fall entsprechend zu verbessern. Völlig unabhängig vom Erzeugen der nautischen Tags in OSM ist übrigens der Export von OSM in ein Datenformat, welches in Kartenplottern und anderen Geräten an Bord direkt verwendet werden kann. Exportieren von OSM nach S-57 ist grundsätzlich immer möglich, man vergleiche hier die bestehenden Export-Funktionen von OSM nach Garmin-Formaten. Da braucht man (sollte man?) bei der Gestaltung der Tags keine Rücksicht drauf nehmen. ... und versucht die doch sehr kryptischen und eher maschinenorientierten Scheibschemata in eine menschlich lesbare und vor allem in eine einfache, intuitive OSM-STruktur zu wandeln. In der Tat finde ich das Proposal alles in allem sehr lesbar, einfach und weitgehend auch intuitiv, jedenfalls meiner Ansicht nach. Ob das gelingt oder nich sollte da diskutiert werden. OK, ich besorge mir dann endlich mal einen Wiki-Account und mache da ein paar Anmerkungen auf der Diskussions-Seite. Allerdings hielte ich sehr viel davon, nicht alle nautischen Themen auf einer einzigen Seite zu diskutieren (wird sicher sonst bald sehr unübersichtlich), sondern die Themen aufzusplitten. Anbieten würde sich hier die Einteilung der INT 1. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Am 17. August 2010 19:36 schrieb Arne Johannessen a...@thaw.de: ... Ob das gelingt oder nich sollte da diskutiert werden. OK, ich besorge mir dann endlich mal einen Wiki-Account und mache da ein paar Anmerkungen auf der Diskussions-Seite. Allerdings hielte ich sehr viel davon, nicht alle nautischen Themen auf einer einzigen Seite zu diskutieren (wird sicher sonst bald sehr unübersichtlich), sondern die Themen aufzusplitten. Anbieten würde sich hier die Einteilung der INT 1. Grüße, Arne Hi Arne, das Proposal bekommt jetzt eh mal ein Clean-up. Welche Einteiung würdest du denn nach INT-1 vorschlagen? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Hallo, Arne Johannessen wrote: Dies, also die Nähe des Proposals zu S-57, kann ich überhaupt nicht feststellen. Das ist aber, wie schon angedeutet, auch Sehr Gut So (mit großen Anfangsbuchstaben). Auf [OSM-talk] fiel auch gerade der Begriff S-57 (im Thread Tagging Seamarks). Ich will die Stränge jetzt nicht redundant führen, daher gerade nur so viel: S-57 ist ein eigentlich veraltetes, binäres, äußerst unflexibles Datenformat, dessen Methodik bei der Kategorisierung und Auszeichnung von Geodaten mit der Technik und den Werten von OSM grundsätzlich inkompatibel ist. S-57 zu folgen, ist also *nicht* anzustreben. Vielleicht sollte das jemand auch der internationalen Community mal so sagen. Fuer die stellt es sich im Moment so dar (nach dem, was Malcolm Herring in diesen Thread geschrieben hat): * OpenSeaMap ist der Standard fuer Hochseemapping, * FT wird mehr fuer Binnengewaesser eingesetzt * und sonst gibt es nix. Dass es, wie ich dieser Diskussion hier jetzt entnehme, noch etwas drittes gibt, naemlich ein OpenSeaMap- und FT-unabhaengiges Taggingschema, ist glaub ich keinem so richtig klar. Darauf sollte entsprechend hingewiesen werden. Aber nicht von mir, ich bin eine Landratte. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
Am 17.08.2010 15:42, schrieb Peter Körner: Am 16.08.2010 22:53, schrieb Ulf Lamping: In meiner Umgebung sind aktuell bereits ein Paar Reifenhändler mit shop=car_repair getaggt. Das stimmt zwar einerseits (es ist ja eine Art Autoreparatur) Wenn es eine Art Autoreparatur ist, sollten wir das so auch abbilden: shop=car_repair car_repair=tyres Wenn ich mit meinem Motorrad zu einem Reifenhändler fahre (was ich ab und zu tue) und mir dort neue Reifen aufziehen lasse ist es eben definitiv *keine* Autoreparatur mehr - ein Motorrad ist einfach kein Auto. Genausowenig wie ein Traktor, Bus oder LKW ein Auto ist - dort aber (je nach Händler) auch Reifen abbekommt. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Am 17. August 2010 20:32 schrieb Frederik Ramm frede...@remote.org: Hallo, Arne Johannessen wrote: Dies, also die Nähe des Proposals zu S-57, kann ich überhaupt nicht feststellen. Das ist aber, wie schon angedeutet, auch Sehr Gut So (mit großen Anfangsbuchstaben). Auf [OSM-talk] fiel auch gerade der Begriff S-57 (im Thread Tagging Seamarks). Ich will die Stränge jetzt nicht redundant führen, daher gerade nur so viel: S-57 ist ein eigentlich veraltetes, binäres, äußerst unflexibles Datenformat, dessen Methodik bei der Kategorisierung und Auszeichnung von Geodaten mit der Technik und den Werten von OSM grundsätzlich inkompatibel ist. S-57 zu folgen, ist also *nicht* anzustreben. Vielleicht sollte das jemand auch der internationalen Community mal so sagen. Fuer die stellt es sich im Moment so dar (nach dem, was Malcolm Herring in diesen Thread geschrieben hat): * OpenSeaMap ist der Standard fuer Hochseemapping, * FT wird mehr fuer Binnengewaesser eingesetzt * und sonst gibt es nix. Dass es, wie ich dieser Diskussion hier jetzt entnehme, noch etwas drittes gibt, naemlich ein OpenSeaMap- und FT-unabhaengiges Taggingschema, ist glaub ich keinem so richtig klar. Darauf sollte entsprechend hingewiesen werden. Aber nicht von mir, ich bin eine Landratte. Bye Frederik Hi Frederik, vielleicht nochmal für alle hier beschrieben: FT hat keine eigenes Tagging-Schema. Haben Sie nie gehabt und nie angestrebt. FT hat eine eigene DB die erstmal völlig autark von OSM ist. Für einen Export zu OSM richtet sich FT nach dem offiziellen Proposal auf der OSM-Wiki, wo jeder mitmachen kann. Dann gibts da noch das Projekt OpenSeaMap. Von außen betrachtet ein kleiner Zirkel von Leuten, die (mehr odler weniger für sich) etwas entwickeln haben. Auch nach mehrmaligen Einladungen mit Ihre Ideen mit ins Wiki-Proposal beizusteuern, ist da leider nicht wirklichw as passiert, sondern Sie entwickeln halt ihr Ding weiter. Warum es sich im Laufe der Zeit immer auf FT vs. OseaM hinausläuft, wissen nur die Götter... Ich suche da aber auch mittlerweile nicht mehr nach dem Ursprung und dem Sinn. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=residential wird nicht gerendert...
Walter Nordmann wrote: inzwischen schon, sah auf den ersten blick ganz sauber aus, erst der validator in josm hat's gemerkt. Danke erstmal. Ich nutze Merkaartor und der kennt keinen Validator. Wie hätte ich das Problem lösen können? Die Stelle, an der du offensichtlich gefixt hast, habe ich auch schon als komisch ausgemacht. Aber indem ich die Relation an einem Punkt mutwillig zerschnitten habe. Ich hatte dann zwei Stücke, die an meinem Schnittpunkt und an dem Punkt, an dem du verknüpft hast, geendet haben. Ich habe es aber nicht geschafft, das Ding zu schließen... Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=residential wird nicht gerendert...
Am 17.08.2010 20:54, schrieb Manuel Reimer: Ich nutze Merkaartor und der kennt keinen Validator. Wie hätte ich das Problem lösen können? Die Antwort wird dir nicht gefallen, aber das hört sich nach einem guten Grund an, Merkaartor nicht zu verwenden, auch wenn er definitiv schöner ist. Wenn du ein C++ Programmierer bist, kannst du natürlich auch versuchen, Merkaartor um einen Validator zu erweitern.. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 16.08.2010 15:21, schrieb Willi: Das weiß ich auch und habe deshalb auch geschrieben, dass eine Strasse durch gedachte Mittellinie und Breite repräsentiert wird und nicht, dass die Breite maßstabsgerecht gezeichnet wird. Das hängt vom Zoomlevel und der Anwendung ab. Durch eine gemeinsame Linienutzung von Mittellinie und landuse-Flächen machst Du von vorneherein unnötige Einschränkungen. Die Datenbank und den Server möchte ich gerne sehen, der eine Weltkarte mit allen Details aller Objekte verarbeiten kann und die Menschen, die all dies eingeben können und wollen. Da es dies weder heute noch in der Zukunft geben wird werden bereits bei Erfassung und Eingabe Objekte Niemand braucht einen Computer mit mehr als 640(?)kByte Speicher... Schon mal gehört? vereinfacht oder weggelassen. Zur Zeit zum Beispiel Straßen als Linien mit Breite und nicht als Flächen mit stark variierender Breite. Wege über Zur Zeit mag es noch nicht so wichtig sein die exakte, varierende Strassenbreite wiederzugeben, aber es gibt durchaus den einen oder anderen der schon exakte Flächen einträgt. Mit einer gemeinsam genutzten Linie von Strassenmittellinie und Landuse hast Du permanent das Problem dass sobald jemand an der Strasse was verschiebt auch die Flächendaten verändert werden und damit exakt eingetragene Daten verfälscht werden. Warum also diese nicht in der Realität existierende Abhängigkeit künstlich schaffen? Flächen ohne diese auszuschneiden. Häuser als Knoten und nicht als Polygon. Morgen geben vielleicht mehr Menschen mehr Details ein und die Server sind in der Lage dies wie gewünscht zu verarbeiten. Aber es wird immer nur ein Teil, ja ein Bruchteil der Wirklichkeit sein. Es wird doch längst schon gemacht das für bestimmte Anwendungen bestimmte Daten extrahiert werden! Die Computertechnick hat bisher stets mit den wachsenden Anforderungen der Datenbedürfnisse schritt gehalten. Warum sollte sich das jetzt plötzlich ändern? Unsere Straßengraphen sind von der Denke her eher Routing orientiert, sie sind zur genauen Abbildung von Straßenflächen eigentlich ungeeignet. sieh Dir einfach mal einen Katasterplan an, und Du verstehst, warum das Quatsch ist Der zumindest ursprüngliche Zweck von OpenStreetMap ist es wie der Name sagt, eine weltweite Straßenkarte zu erstellen und entsprechend diesem Zweck sind die Möglichkeiten der Abbildung in der OSM Datenbank. Wenn nun manche immer mehr Details hinzufügen oder Ansprüche wie an eine Katasterkarte stellen, so ist ihnen das nach den OSM Prinzipien unbenommen. Diese Maßstäbe sind jedoch wiederum nach den OSM Prinzipien nicht allgemeingültig. Es gilt sogar: Individual mappers have every right to tag things differently from what is stated in the Wiki, and it is not OK for anybody to turn the suggestions contained in the Wiki into strict rules that are applied automatically. http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct#Discuss_your_plans. Der Name entstand zu einem Zeitpunkt als die meisten noch davon ausgingen dass OSM wieder mal so ein lächerlicher Versuch von ein paar Spinnern ist die glauben mit ihren Trackaufzeichnungen Navteq Co konkurrenz machen zu können, kaum einer glaubte an einen nennswerten Erfolg. -1, Wie kommst Du da drauf? Brücken, Tunnel und die entspr. Layer sollen immer explizit angegeben werden. Natürlich ist es wünschenswert, dass diese eingetragen werden. Aber wie ich schrieb, es ist nicht notwendig. Meines Erachtens ist es sogar besser, sie wegzulassen statt fehlerhaft einzutragen. Dann sieht jeder sofort, dass hier noch etwas erfasst und eingetragen werden kann. Ich kam Irgendjemand wird sich irgendwann daran stören dass etwas fehlerhaft eingetragen ist und es korrigieren. Bis dahin kann man auch mit nicht ganz korrekten Daten leben. Darum sollte man die tagging-Regeln so definieren dass die Korrektur eines Objektes nicht zwangsläufig ein anderes verfälscht und wir können uns über sich kontinuierlich verbessernde Daten freuen. nie auf die Idee, Brücken nach gusto oder gar Google einzutragen oder hunderte Kilometer Flüsse nicht nach LandSat einzuzeichnen weil ich nie auf den kreuzenden, bereits eingezeichneten Straßen war oder hunderte gefahrene Kilometer fehlender Straßen zweiter und dritter Ordnung nicht einzuzeichnen nur weil keine Zeit war nachzusehen ob gerade Fluss im Tunnel oder Brücke über Fluss vorliegt, geschweige denn Zeit war, Widerlager auszumessen oder weil in der Nacht die überquerten Flüsse erst gar nicht zu sehen waren. In einem wenig erfassten Land mit ein paar Aktiven sieht es anders aus als in einem Land in dem im Schnitt pro 100 qkm mehrere OSMer sind. Ich habe häufig Daten (Strassen, Gewässer, Bahnlinien) aus der Erinnerung ergänzt und eingetragen. Teilweise sind das immer noch die einzigsten Daten im grösseren Umkreis, teilweise wurden sie schon umfassend ergänzt und korrigiert. Für eine (Strassen)Navianwendung ist es relativ
Re: [Talk-de] Tipps zum Friedhofmapping gesucht
Am 17.08.2010 11:04, schrieb M∡rtin Koppenhoefer: gedacht fuer = Boot, Caravan, Pferd, Mensch, Giesskanne Gebuehr = j/n Schlauch =j/n Anschluss = ... Becken =j/n Hat jemand Lust das weiter zu denken und ggf. ein Proposal zu giessen? bisher brauchte da noch niemand weitere Details. Ich plane allerdings, in meiner demnächst zu veröffentlichenden lokalen Trinkwasserkarte auch die Typen der einzelnen Trinkbrunnen - soweit Daten vorhanden - anzuzeigen. Schlauch, Becken, Anschluss und Gebühr kommt dabei allerdings bisher nicht vor (in der Realität), oder ist durch den Typ bereits abgedeckt, weshalb ich keine Motivation habe, diese ganzen Werte vorzusehen. Sehe den Bedarf auch nicht - eine Viehtränke, ein Trinkbrunnen, eine Toilette, eine Friedhofswasserstelle und ein Anschluss zur Fahrzeugbetankung/Pflege sind irgendwie doch was ziemlich unterschiedliches... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
Ulf Lamping schrieb am 17.08.2010 20:38: Wenn ich mit meinem Motorrad zu einem Reifenhändler fahre (was ich ab und zu tue) und mir dort neue Reifen aufziehen lasse ist es eben definitiv *keine* Autoreparatur mehr - ein Motorrad ist einfach kein Auto. Genausowenig wie ein Traktor, Bus oder LKW ein Auto ist - dort aber (je nach Händler) auch Reifen abbekommt. Und wenn ich mir bei der Tankstelle eine Zeitung hole, dann bleibt es doch trotzdem noch eine Tankstelle. Man kann nahezu fuer jedes Geschaeft ein Beispiel finden, wo das eigentliche Tag nicht passt (eine Baeckerei verkauft auch Getraenke, ein Supermarkt auch Computer). Ein Gegenbeispiel ist also keinerlei Argument fuer oder gegen ein bestimmtes Tag. Abgesehen davon finde auch ich shop=tires besser, obwohl ich davon ausgehe, dass viele Renderer, sobald sie das neue Tag irgendwann mal gelernt haben, das mit dem selbem Symbol darstellen werden wie eine Autowerkstatt. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
Am 17.08.2010 21:43, schrieb Torsten Leistikow: Ulf Lamping schrieb am 17.08.2010 20:38: Wenn ich mit meinem Motorrad zu einem Reifenhändler fahre (was ich ab und zu tue) und mir dort neue Reifen aufziehen lasse ist es eben definitiv *keine* Autoreparatur mehr - ein Motorrad ist einfach kein Auto. Genausowenig wie ein Traktor, Bus oder LKW ein Auto ist - dort aber (je nach Händler) auch Reifen abbekommt. Und wenn ich mir bei der Tankstelle eine Zeitung hole, dann bleibt es doch trotzdem noch eine Tankstelle. Das hat aber direkt nichts mehr mit amenity=fuel (also dem eigentlichen Sprit) zu tun, sondern was die Tankstelle an zusätzlichen Services (neben fuel) anbietet. Der Logik folgend müßten wir sonst amenity=car_fuel verwenden - die meisten die dort tanken fahren ja Auto ;-) Abgesehen davon finde auch ich shop=tires besser, tyres (BE) vs. tires (AE). Das wäre mir relativ egal, andererseits wird tyres aktuell häufiger verwendet und wir tendieren bei OSM ja eh eher zu BE. obwohl ich davon ausgehe, dass viele Renderer, sobald sie das neue Tag irgendwann mal gelernt haben, das mit dem selbem Symbol darstellen werden wie eine Autowerkstatt. Ich schreibe gerade an einer Karte für Motorradfahrer rum, die genau hier eine Unterscheidung trifft. Außer bei Reifenhändlern gibt es nämlich in der Praxis kaum (keine?) Überschneidungen zwischen car_repair und Motorradthemen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Hi Mario, sondern die Themen aufzusplitten. Anbieten würde sich hier die Einteilung der INT 1. das Proposal bekommt jetzt eh mal ein Clean-up. Welche Einteiung würdest du denn nach INT-1 vorschlagen? Schau mal nach http://wiki.openstreetmap.org/wiki/Talk:Marine_Mapping (recht weit unten), da habe ich letztes Jahr schon mal was zusammengestellt. Grüße, Heiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Mario Salvini wrote: das Proposal bekommt jetzt eh mal ein Clean-up. Ja, ich habe gelesen, der Wiki-User Cbm will da aktiv werden. Liest der hier mit? (Bist Du das am Ende selbst?) Welche Einteiung würdest du denn nach INT-1 vorschlagen? Die sich aus ihr selbst ergebende sieht auf den ersten Blick schon verdammt gut brauchbar aus. Das BSH hat sich damals bei der Erstherstellung der INT 1 für die IHO einen Haufen Arbeit gemacht, darauf können wir sicher gut aufbauen. Ich würde es mit einer Wiki-Seite je Kapitel (also je Buchstabe) probieren. Die Abschnitte innerhalb Kapiteln (z. B. P20-P23 für Richtfeuer, P30-P31 für Leitfeuer etc.) würde ich überwiegend auf die selbe Wiki-Seite mit jeweiligen Überschriften setzen wollen. Das gehört ja halt irgendwie doch zum Hauptthema Leuchtfeuer und kann gut zusammen diskutiert werden. Nicht alle Kapitel, Abschnitte und Zeichen machen für OSM Sinn. Einige können vorerst ignoriert und später durch Verweise auf die Map Features ersetzt werden. Für die übrigen, interessanten Kapitel würde ich dann je eine Wiki-Seite vorsehen: F - Wasserbauten, Häfen I - Tiefen K - Felsen, Wracks, Schifffahrtshindernisse L - Offshore-Anlagen [Windfarmen, Plattformen, Kabel, Pipelines etc.] M - Schifffahrtswege N - Gebiete, Grenzen P - Leuchtfeuer Q - Tonnen, Baken Die weitere Unterteilung auf den jeweiligen Seiten können wir quasi aus der INT 1 abschreiben. Eintragen der einzelnen Symbole bzw. Tags dann je nach Bedarf. Wir brauchen auch noch einzelne weitere Themen wie z. B. Brücken (D20-D29) und Landmarken (E1-E2, Rest siehe Map Features). Für die könnten auch schon mal die jeweiligen Seiten (z. B. D Bauten und E Landmarken) erzeugt werden, oder man schreibt sie erst auf eine sonstiges-Seite. Der Vorteil beim Einteilen nach INT 1 (Zeichenerklärung für Seekarten) ist vor allem die einfache Referenz. Da sind dann hübsche Abbildungen der aus den Seekarten vertrauten Kartenzeichen drin, und eben eine gute Einteilung sowie treffende englische Begriffe (die fürs Taggen nützlich sein können). Der Kartograph/Mapper findet überall Verweise zur IHO S-4 (früher M-4) mit weiterem nautischen Hintergrundwissen. Der mit S-57 vertraute Programmierer findet im Anhang D der S-57 eine Cross-Reference zur INT 1, und zwar auch in deren Einteilung. Und: die INT 1 ist leicht verfügbar. Wer mal einen BR- oder SKS-Schein gemacht hat, findet typischerweise noch eine gedruckte Ausgabe der Karte 1 (INT 1) in der Schublade. Das Ding gibt's auch günstig im Buchhandel, und es existiert auch in einigen Sprachen im Netz zum kostenlosen Download: Dänisch + Englisch: ftp://ftp2.kms.dk/download/soekortret/publikationer/kort1.pdf Französisch + Englisch: http://www.iho-ohi.net/iho_pubs/standard/S-4/INT1_FR_Ed.4.pdf Amerikanisch (etwas älter): http://www.nauticalcharts.noaa.gov/mcd/chartno1.htm Die Kapitel-Einteilung ist auf der jeweils vorletzten Seite im PDF bzw. auf dem Rücken des gedruckten Hefts zu sehen, oder im Inhaltsverzeichnis. Letzten Endes kommt es auf die Einteilung nicht unbedingt an. Aber die INT 1 drängt sich auf, ist praktisch und macht für uns Sinn, meiner Ansicht nach. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Gibt mal ein paar Tips wie man das mit JOSM und OS X macht ... Lg Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Hallo Mario! Wie die verschiedenen Schemata zustande kamen, ist ja letztlich irrelevant. Wichtig ist (aus Sicht der OSM-Community insgesamt), final zu /einem/ zu kommen. Ich gebe Dir recht, Proposed_features/marine-tagging sieht auf den ersten Blick vernünftig aus (warum man z.B. Topzeichen angeben muß/soll(?), wenn die sich eh aus der Klassifikation ergeben, sehe ich grade nicht... gibt's da lokale Diskrepanzen?), während seamark:* IMHO unnötig komplizierte Doppelpunkt-Verschachtelungen hat. Die einen beharren auf ihrem Schema (und untermauern das mit der IHO S-57), die andern beharren auf nicht ihrem Schema (und betonen, daß es ein Proposal ist), aber unterm Strich geht nix weiter. Schlagt Euch die Köpfe ein, spielt den Beleidigten, was immer, aber kommt zu /einem/ Ergebnis... endlich... (tschuldige, wenn ich das jetzt so deutlich sage). Aber dieses ewige bitte der hat wieder das umgetagt und der hält sich daran nicht usw. muß endlich ein Ende haben. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reifenhändler ...
On 16.08.10 22:53, Ulf Lamping wrote: Laut tagwatch gibt es ~90 mal shop=tyres, was ich als Tag ganz passend finde. +1 also ist car_repair eigentlich falsch. ++1 /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Am 18. August 2010 00:09 schrieb Andreas Labres l...@lab.at: Ich gebe Dir recht, Proposed_features/marine-tagging sieht auf den ersten Blick vernünftig aus (warum man z.B. Topzeichen angeben muß/soll(?), wenn die sich eh aus der Klassifikation ergeben, sehe ich grade nicht... gibt's da lokale Diskrepanzen?), während seamark:* IMHO unnötig komplizierte Doppelpunkt-Verschachtelungen hat. Ich auch nicht. Im Prinzip müsste es ausreichen anzugeben ob ein Topzeichen auf der Tonne vorhanden ist oder nicht. Ob das dann auch noch bei Tonnen am einmündenden/abzweigenden Fahrwasser funktioniert dürfte eher ein Problem des Renderers als eines des Taggings sein. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Hallo Andreas, Die einen beharren auf ihrem Schema (und untermauern das mit der IHO S-57), die andern beharren auf nicht ihrem Schema (und betonen, daß es ein Proposal ist), aber unterm Strich geht nix weiter. Schlagt Euch die Köpfe ein, spielt den Beleidigten, was immer, aber kommt zu /einem/ Ergebnis... endlich... (tschuldige, wenn ich das jetzt so deutlich sage). Aber dieses ewige bitte der hat wieder das umgetagt und der hält sich daran nicht usw. muß endlich ein Ende haben. Ich persönlich habe da jetzt ein gutes Gefühl, und stimme Dir in Deiner Rückschau, und vor allem in Deiner Forderung zu. Und dabei sollten wir es dann auch belassen. Wir sind jetzt bei INT1 :-) Sorry, das gleiche hätte ich Mario geschrieben, wenn ich vorhin Zeit gehabt hätte ;-) JJ www..??/seekarte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Hallo Dirk, Am 17.08.2010 um 23:30 schrieb fla...@googlemail.com: Gibt mal ein paar Tips wie man das mit JOSM und OS X macht ... Ganz einfach. Auf der Garmin Seite nach Road Trip suchen. Runterladen, installieren, 60Csx anschliessen, OK. Damit habe ich meinen Workflow aufgebaut. Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Am 17.08.2010 23:30, schrieb fla...@googlemail.com: Gibt mal ein paar Tips wie man das mit JOSM und OS X macht ... Ihr wollt also allen ernstes einen 60CSx als GPS-Empfänger an einem laufenden Laptop betreiben, um die livedaten in Josm angezeigt zu bekommen? Ich kann ja verstehen, wenn Leute, die nur eine Bluetooth-Maus und kein neuzeitliches Handy besitzen, soetwas (meintwegen auch mit einem Netbook) tun. Aber das was Ihr (Du und Jan) da vorhabt, das halte ich für reichlich abgedreht. Oder habt ihr jemanden, der Euch in der Gegend herumfährt, so dass ihr vom Rücksitz (Auto, Tandem, Achterdeck) unterwegs in JOSM arbeiten wollt? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Toppzeichen S-57 in OSM
Falk Zscheile wrote: Am 18. August 2010 00:09 schrieb Andreas Labres l...@lab.at: [...] (warum man z.B. Topzeichen angeben muß/soll(?), wenn die sich eh aus der Klassifikation ergeben, sehe ich grade nicht... gibt's da lokale Diskrepanzen?), [...] Ja, die gibt es. Das internationale Schema der IALA wird nicht überall angewendet, und nicht alle Arten von Zeichen sind überhaupt in dem Schema erfasst. Ich auch nicht. Im Prinzip müsste es ausreichen anzugeben ob ein Topzeichen auf der Tonne vorhanden ist oder nicht. Für solche Zeichen, die dem IALA-Schema entsprechen, kann der Renderer ein Default für die Form und Farbe des Toppzeichens kennen und braucht keine weiteren Infos als ja oder nein nicht. Aber es gibt eben auch andere Zeichen. Ob das dann auch noch bei Tonnen am einmündenden/abzweigenden Fahrwasser funktioniert dürfte eher ein Problem des Renderers als eines des Taggings sein. Kreuzungen sind unproblematisch, im Gegensatz zu allen möglichen Arten von nationalen und privaten Toppzeichen (Tafeln, Flaggen, Klobürsten, Fische und was nicht alles). Einen Tag für die Spezifikation von Toppzeichen-Formen zu haben, ist somit unumgänglich. Für IALA-Zeichen kann ein Tag für die Toppzeichen-Form aber evtl. wegfallen, weil dort ein Default-Wert bekannt ist. Ebenso sollte der Renderer als Default für die *Farbe* des Toppzeichens einfach die (Haupt-)Farbe der Tonne annehmen. Aber es gibt Ausnahmen, für die brauchen wir ein Tag. Beispiel (ohne mich auf die Tag-Namen festzulegen): * buoy=safe_water impliziert: topmark=no, colour=red;white, striped=vertical * buoy=safe_water mit topmark=yes ist gleichbedeutend mit topmark=sphere * buoy=safe_water mit topmark=sphere impliziert: colour:topmark=red Um eine normale Mitteltonne zu taggen, reicht dann ein einfaches buoy=safe_water, topmark=yes/no aus. Wenn aber jetzt ein Depp ein falsches Toppzeichen montiert oder die Sonne die rote Farbe zu weiß verbleicht oder das Toppzeichen zur Hälfte abgefallen ist (alles schon gesehen), dann können wir auch diesen IALA-Spezialfall trotzdem abbilden. So viel zur Notwendigkeit. Wie jetzt die Tags konkret heißen, ist im Prinzip egal (obwohl ich natürlich eine Meinung habe). -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin 60 CSx via USB-Kabel an JOSM
Am 18.08.2010 01:18, schrieb Johann H. Addicks: Am 17.08.2010 23:30, schrieb fla...@googlemail.com: Gibt mal ein paar Tips wie man das mit JOSM und OS X macht ... Ihr wollt also allen ernstes einen 60CSx als GPS-Empfänger an einem laufenden Laptop betreiben, um die livedaten in Josm angezeigt zu bekommen? Ich kann ja verstehen, wenn Leute, die nur eine Bluetooth-Maus und kein neuzeitliches Handy besitzen, soetwas (meintwegen auch mit einem Netbook) tun. Aber das was Ihr (Du und Jan) da vorhabt, das halte ich für reichlich abgedreht. Oder habt ihr jemanden, der Euch in der Gegend herumfährt, so dass ihr vom Rücksitz (Auto, Tandem, Achterdeck) unterwegs in JOSM arbeiten wollt? -jha- zu fuss beim abendspaziergang auf dienstreisen - irgendwie muss man den abend rumbekommen. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
