Re: [Talk-de] (neue) Lizenz
Ich halte das, ehrlich gesagt, für herausgeschmissenes Geld und Zeit. Die Anwälte der OSMF wollen (IMHO) mit Sicherheit die Anzahl der Sprachversionen auf das absolute Minimum halten. Jede zusätzliche Übersetzung birgt die Gefahr von subtilen Unterschiede und bringt in der Zukunft nur weitere Kosten und Ärger. Da die englische Version problemlos rechtsgültig angenommen werden kann in Deutschland, halte ich es für sehr unwahrscheinlich, dass sie eine nicht vom OSMF in Auftrag gegebene deutschsprachige Version akzeptieren würden (würde ich auch nicht), d.h. auch bei vorliegen einer beglaubigten Übersetzung wird man trotzdem die englische (oder meinetwegen die französische) Version der CTs annehmen müssen. Ich sehe auch das Problem des OP nicht ganz, er kann sich ja via einer Vertrauensperson versichern, dass die inoffizielle Übersetzung den englischen CTs enstspricht, wirklich besser wird das auch bei vorliegen einer beglaubigten Übersetzung nicht. Simon - Original Message - From: Peter Körner osm-li...@mazdermind.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Sent: Saturday, October 30, 2010 12:29 PM Subject: Re: [Talk-de] (neue) Lizenz Am 30.10.2010 13:01, schrieb Steffen Heinz: sorry, das ich noch mal darauf zurückkomme! Ich kann den Text nicht lesen (bin kaum des englisch mächtig) ein Mensch aus dem Bekanntenkreis sagte das (zumindest in meinem Falle) ein Unterschrift nicht rechtsgültig ist wenn der Text nicht gelesen werden kann - übersetzungen würden nur dann reichen wenn die rechtlich (vereidigter Übersetzer) abgesichert sind. Und genau das ist das Problem, bisher hat sich keiner dafür verantwortlich gefühlt. Ich habe eine Anfrage An Herrn Udo Vetter vom Lawblog [1] gesendet mit der Frage nach einer Ansprechstelle und einer Einschätzung der Kosten für eine Beglaubigung und ggf. Übersetzung. Ich werde hier berichten, sobald ich eine Antwort erhalte. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Feinkost
hi ! hat einer eine Idee für Feinkostgeschäfte ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feinkost
jan99 wrote: hat einer eine Idee für Feinkostgeschäfte ? wie wär's mit deli ? http://dict.leo.org/ende?lp=endelang=desearchLoc=0cmpType=relaxedsectHdr=onspellToler=search=deli -- View this message in context: http://gis.638310.n2.nabble.com/Feinkost-tp5693009p5693051.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] PLZ Import
Schade dass der Address-Inspector von der GeoFabrik immer noch keine Konsistenzprüfung KA-Schema vs. PLZ-Polygone machen kann. In Marl zB. sind die Adressen von der Stadtverwaltung gestiftet und importiert worden, da könnte man also schön die PLZ-Polygone danach ausrichten, wenn es nicht so aufwändig wäre. Oder kennt jemand einen Trick wie man in JOSM die Adress-Nodes zB. je nach letzten beiden Stellen der PLZ einfärben kann. (zB ...72 rot, ...76 grün). Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am Sonntag 31 Oktober 2010, 21:57:51 schrieb Élisée Reclus: Also irgendwie strukturieren und sortieren musst du es für Menschen ja in jedem Fall ab einer gewissen Anzahl möglicher Werte, da man ansonsten den Überblick verliert. Du kannst (oder solltest) weder im Wiki noch im JOSM-Menue (z.B.) hundert Werte untereinander haben. Warum nicht also schon eine Struktur im Datenformat abbilden? +1 Ein (neuer) Mapper könnte außerdem, wenn er die Werte nicht nachschlagen kann oder will, schonmal „healthcare=yes“ mit „fixme=*“ mappen. oder er kann, falls er was neues findet, wofuer es noch kein Tag gibt, dieses Objekt als healthcare = xyeinrichtung taggen, und man weiss sofort, dass es hier um eine Gesundheitseinrichtung handelt. waere ja nicht so, dass aehnliches nicht schon mal vorgeschlagen wurde... ;-) 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] Healthcare-Proposal
Am 31.10.2010 21:57, schrieb Élisée Reclus: Also irgendwie strukturieren und sortieren musst du es für Menschen ja in jedem Fall ab einer gewissen Anzahl möglicher Werte, da man ansonsten den Überblick verliert. Du kannst (oder solltest) weder im Wiki noch im JOSM-Menue (z.B.) hundert Werte untereinander haben. Das gelingt JOSM jetzt schon (siehe Vorlagen-Menü Einrichtungen - Gesundheit), und auch im Wiki ist es kein Problem, z.B. auf Map Features ein Tag wie junction=roundabout unter die thematisch passende Überschrift Highway zu stellen. Warum nicht also schon eine Struktur im Datenformat abbilden? Weil das beim Finden nicht weiter hilft, da ja die Strukturierung nicht auf die Verankerung im Datenformat angewiesen ist, siehe oben. Ein (neuer) Mapper könnte außerdem, wenn er die Werte nicht nachschlagen kann oder will, schonmal „healthcare=yes“ mit „fixme=*“ mappen. Inwiefern hilft das dem erfahrenen Mapper - sei es derselbe Mapper zu einem späteren Zeitpunkt oder ein Kollege - beim Vervollständigen des Eintrags? Er hat ohnehin Zugang zum fixme=add dentist und braucht das healthcare=yes daher nicht. Und die die Daten verarbeitenden Anwendungen können anhand des Schlüssels schon mal ungefähr auswerten um was es sich handelt, auch wenn sie den genauen Wert nicht kennen sollten. Also dass es sich z.B. um einen Laden handelt oder in dem Fall um eine Gesundheitseinrichtung. Dann weiß der Anwender, dass sich dort ein Krankenhaus, eine Hebamme, ein Alternativmediziner oder vielleicht doch eine Lagerstätte für Blutkonserven befindet. Findest du das wirklich nützlich? Mit einem name=Hans-Meier-Krankenhaus weiß man natürlich mehr. Aber dann ist der Name das Nützliche, nicht das healthcare=*, und der Name wäre auch mit einem amenity=* noch ähnlich gut auffindbar. Der bei weitem wichtigste Punkt ist aber meiner Meinung nach der erste. Und den könnten wir ohne Änderung des Datenmodells umsetzen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reboot-Nachlesen
Am 31.10.2010 20:52, schrieb Élisée Reclus: Am 31.10.2010 20:24, schrieb Tobias Knerr: Dieselbe Frage stellt sich aber auch z.B. bei amenity=hospital mit sogar 55.000 Verwendungen. Welches Vorgehen ist vorgesehen, um das in den Daten und den zahlreichen Anwendungen zu ändern? Sinnvoll wäre meiner Meinung nach zuallererst ein Robot-Durchlauf, der allen amenity=hospital ein zusätzliches healthcare=hospital zuweißt. Die Anwendungen müssen dann per Hand geändert werden. Nach einer Übergangszeit für die Umstellung der Anwendungen sollte ein zweiter Robot-Durchlauf die doppelten amenity=hospital löschen. Moin ! kann man eigentlich irgendwo solche reboot-aktionen nachlesen damit man seine app anpassen kann ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am 01.11.2010 10:39, schrieb Tobias Knerr: Das gelingt JOSM jetzt schon (siehe Vorlagen-Menü Einrichtungen - Gesundheit), und auch im Wiki ist es kein Problem, z.B. auf Map Features ein Tag wie junction=roundabout unter die thematisch passende Überschrift Highway zu stellen. Natürlich kannst du auch über Umwege und Krücken wieder alles halbwegs sortieren. Aber besser ist es meiner Meinung nach gleich alles sortiert und so einfach wie möglich zu halten. Als Vorbild für Ordnung und Übersichtlichkeit solltest du meiner Meinung nach wirklich nicht das Wiki anführen. Das ist ziemlich chaotisch. Ich habe vor nicht all zu langer Zeit erst bei OSM angefangen und ich kann wirklich nicht sagen, dass ich mich im Wiki zurechtgefunden habe. Es freut mich, wenn !i! und Verbündete da aufräumen wollen. Warum nicht also schon eine Struktur im Datenformat abbilden? Weil das beim Finden nicht weiter hilft, da ja die Strukturierung nicht auf die Verankerung im Datenformat angewiesen ist, siehe oben. Eigentlich schon. Ich denke, dass es v.a. wichtig ist es neuen Mappern leicht zu machen. Die Leute, die schon lange dabei sind, finden sich eh zurecht (und wissen alles besser). Inwiefern hilft das dem erfahrenen Mapper - sei es derselbe Mapper zu einem späteren Zeitpunkt oder ein Kollege - beim Vervollständigen des Eintrags? Er hat ohnehin Zugang zum fixme=add dentist und braucht das healthcare=yes daher nicht. Dem erfahrenen Mapper hilft es vmtl. nicht, aber die Information „healthcare=yes“ hat jedenfalls schonmal eine Bedeutung und ist automatisch auswertbar. Dann weiß der Anwender, dass sich dort ein Krankenhaus, eine Hebamme, ein Alternativmediziner oder vielleicht doch eine Lagerstätte für Blutkonserven befindet. Findest du das wirklich nützlich? Natürlich finde ich das nützlich. Mit einem name=Hans-Meier-Krankenhaus weiß man natürlich mehr. Aber dann ist der Name das Nützliche, nicht das healthcare=*, und der Name wäre auch mit einem amenity=* noch ähnlich gut auffindbar. Es ist ja nicht so, dass das Setzen von „name=foo“ verboten wäre. Natürlich kann das auch nützlich sein. Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reboot-Nachlesen
Am 01.11.2010 10:40, schrieb Jan Tappenbeck: kann man eigentlich irgendwo solche reboot-aktionen nachlesen damit man seine app anpassen kann ? Ich muss leider sagen, dass ich da keine Ahnung habe. Es gibt natürlich die Announce- und die Dev-Mailingliste. Es wäre schön wenn so etwas darüber bekannt gemacht würde. http://lists.openstreetmap.org/listinfo/announce http://lists.openstreetmap.org/listinfo/dev Entwickler von OSM-Anwendungen sollten diese Liste eigentlich lesen. Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feinkost
2010/11/1 fx99 f...@vollbio.de: jan99 wrote: hat einer eine Idee für Feinkostgeschäfte ? wie wär's mit deli ? +1, shop=deli wird bereits 279 mal genutzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. -- View this message in context: http://gis.638310.n2.nabble.com/neue-Lizenz-tp5689277p5693489.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] (neue) Lizenz
Am 1. November 2010 12:07 schrieb Peter Körner osm-li...@mazdermind.de: Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. die meisten hätten auch nicht das juristische Verständnis, die Lizenz und Ihre Implikationen bis ins Letzte zu verstehen, wenn es eine juristisch verbindliche Übersetzung gäbe. Ich sehe es auch so, dass es Geldverschwendung wäre, eine solche über das rechtlich erforderliche Maß (Italien fordert es z.B. gesetzlich, dass es eine italienische Version gibt, damit es in Italien gilt) für alle möglichen Sprachen (und Jurisdiktionen) anzufertigen. Anwälte kosten sehr viel Geld, das ich anders besser ausgegeben sehe. Wer sich da bei der OSMF beschwert sollte sich vielleicht eher bei der dt. Regierung beschweren. Ich glaube ausserdem, dass die allermeisten der genaue Text der Lizenz nicht so wichtig ist, solange diese frei ist und bestimmte Teile wie Attribution und ggf. share-alike fordert. Sooo viel ändert sich ja nicht durch die Anpassung von Werken (die wir aber immer schon eigentlich für Daten wollten) auf Daten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 1. November 2010 12:26 schrieb fx99 f...@vollbio.de: Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. Einen verbindlichen dt. Text zu fordern halte ich für problematisch. Vermutlich müsste der dann wieder verbindlich ins englische übertragen werden? Es ist ja nicht so, dass man sich nicht auf dt. über die Lizenzfrage informieren kann: http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License http://wiki.openstreetmap.org/wiki/DE:ODbL/Why_CC_BY-SA_is_Unsuitable http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Implementation_Plan Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Ich finde ja auch, dass das eigentlich ja auch von der OSMF besser (na ja eigentlich überhaupt) erklärt werden sollte. Aber das ungeschickte, bis nicht vorhandene Marketing um die CTs ist ein anderes Thema. Simon - Original Message - From: Peter Körner osm-li...@mazdermind.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Cc: Simon Poole si...@poole.ch Sent: Monday, November 01, 2010 12:07 PM Subject: Re: [Talk-de] (neue) Lizenz Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Wie schon geschrieben: es ist im Interesse aller die Anzahl der Übersetzungen auf das Minimum zu beschränken. Nur schon die Wartung jeder Übersetzung wird sofort zu einem Problem (nur als Beispiel kommen ja irgendwann bald die CTs 1.1). Und wenn auch der deutschsprachige Teil von OSM sehr gross ist, muss man doch sehen, dass andere Sprachregionen genau die gleichen, durchaus berechtigten, Einwände machen könnten. Irgendwo muss man die Grenze ziehen ansonsten wird's einfach endlos. Nochmals: die OSMF wird vermutlich keine deutschsprachige Version der Lizenz akzeptieren, d.h. man würde, auch wenn eine beglaubigte Übersetzung vorliegt, immer noch die englische Version annehmen müssen. In der Situation sehe ich keinen Vorteil darin neben der aktuellen inoffziellen noch eine weitere (auch inoffizielle) Übersetzung zu haben. Simon - Original Message - From: fx99 f...@vollbio.de To: talk-de@openstreetmap.org Sent: Monday, November 01, 2010 12:26 PM Subject: Re: [Talk-de] (neue) Lizenz Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. -- View this message in context: http://gis.638310.n2.nabble.com/neue-Lizenz-tp5689277p5693489.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 01.11.10 schrieb Peter Körner: Es geht einzig und allein um's Bauchgefühl. Falls es Deinem Bauchgefühl hilft: zumindest die deutsche Übersetzung der CTs[1] (Teilnahmevereinbarung) war letzten Dienstag Thema der Lizenzarbeitsgruppe[2]. Gruß, Fabian. [1] http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Contributor_Terms [2] http://www.osmfoundation.org/wiki/Working_Group_Minutes___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ÖPNVKarte - Neuigkeiten?
Hallo zusammen! Falls das eine FAQ ist, sorry. Aber ich habe weder auf öpnvkarte.de, noch auf der deutschen und englischen OSM-Wiki-Seite etwas darüber finden können. Im Listenarchiv sah ich nur, dass Anfang September etwas von einem Serverumzug geschrieben wurde, aber seitdem konnte ich auch nix mehr finden. Auf der Webseite selbst steht auch Stand September. Zur Zeit keine Updates. Weiß jemand mehr darüber und wann es wieder Updates gibt? Ist Melchior nur einfach im Urlaub oder ist hier längerfristig mit Problemen zu rechnen? Kennt jemand eine schöne Alternative? Wir waren nämlich eigentlich gerade dabei, unser ÖPNV-Netz in Landshut zu erfassen - und da ist eine schön gerenderte Karte natürlich ein guter Ansporn... :-) -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Chris66 wrote: Schade dass der Address-Inspector von der GeoFabrik immer noch keine Konsistenzprüfung KA-Schema vs. PLZ-Polygone machen kann. schöne idee ;) - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5693827.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] PLZ Import
Chris66 schrieb: In Marl zB. sind die Adressen von der Stadtverwaltung gestiftet und importiert worden, da könnte man also schön die PLZ-Polygone danach ausrichten, wenn es nicht so aufwändig wäre. Oder kennt jemand einen Trick wie man in JOSM die Adress-Nodes zB. je nach letzten beiden Stellen der PLZ einfärben kann. (zB ...72 rot, ...76 grün). Ich würde einfach den entsprechenden Filter für jede PLZ nacheinander nehmen. Dem dicken gelben Buch zufolge git es in Marl nur drei PLZ-Zonen. -- Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Wie ist denn nun die allgemeine Meinung: sollen es jeweils eindeutige (unique) keys sein, oder soll die Bedeutung (ggf. auch) kontextabhängig sein? Je früher man solche Fragen klärt, um so eher kann man konsistent weitermachen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo, nachdem mein Programm welches ich derzeit entwickle mal wieder aufgrund einer Null-Pointer-Exception abgeschmiert ist, ist mir aufgefallen, dass die Extrakte der Geofabrik teilweise Fehler in der Datenlogik aufweisen. Mir ist klar, dass es nicht ganz trivial ist einen Bereich auszuschneiden (es geht hier, mal wieder, um Berlin, aber mMn darf es nicht passieren, dass dabei Daten entstehen die schlicht falsch sind. Der Way 77487735 [1] hat einen Knoten der genau auf der Berliner Stadtgrenze liegt. Dementsprechend ist er Way auch im Extrakt enthalten, was ja auch richtig ist. Allerdings sind alle Knoten entfernt, die nicht innerhalb der Grenzen Berlins liegen. Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Ein Weg/Kante kann nicht nur aus einem Knoten bestehen. Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Danke Tom [1] http://www.openstreetmap.org/browse/way/77487735 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 01.11.2010 15:54, schrieb M∡rtin Koppenhoefer: Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Und noch ein Beispiel: bicycle=yes an Barrieren heisst: hier können Fahrräder passieren; an Wegweisern (information=guidepost) bedeutet es: Hier gibt's Infos für Radfahrer. Interessant wird es, wenn der Wegweiser an einer Barriere befestigt ist. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Ich hab mir perl (offline) Skripte gechrieben, mit dem ich addr:postcode gegen das durch die PLZ Relation umschlossenen Gebiet teste. Das Ergebnis ist z.B. dargestellt in: http://wiki.openstreetmap.org/wiki/Stuttgart/PLZ Zusätzlich kommt noch eine Datei mit den falschen PLZs heraus. Eingaben: 1. bounding box für das gesamt Gebiet 2. Liste mit Relationsnummer und PLZ der PLZ Gebiete. Bei Interesse PN schicken. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5694327.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] Best Practice fürs Erfinden von Tags
On Mon, Nov 01, 2010 at 03:54:56PM +0100, M∡rtin Koppenhoefer wrote: Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Gutes Beispiel. Wenn man auf http://taginfo.openstreetmap.de/keys/service schaut, dann sind die häufigsten Values: parking_aisle, driveway, alley, spur, yard, siding, parking, yahoo aerial images, dealer;repair, parts, ... Offensichtlich ist das eine wilde Mischung aus Zusatztags für highway, railway und shop. M.E. ein klarer Fall, wo das in mehrere Tags aufgelöst gehört. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
On Mon, Nov 01, 2010 at 04:16:42PM +0100, Tom Müller wrote: nachdem mein Programm welches ich derzeit entwickle mal wieder aufgrund einer Null-Pointer-Exception abgeschmiert ist, ist mir aufgefallen, dass die Extrakte der Geofabrik teilweise Fehler in der Datenlogik aufweisen. Mir ist klar, dass es nicht ganz trivial ist einen Bereich auszuschneiden (es geht hier, mal wieder, um Berlin, aber mMn darf es nicht passieren, dass dabei Daten entstehen die schlicht falsch sind. Der Way 77487735 [1] hat einen Knoten der genau auf der Berliner Stadtgrenze liegt. Dementsprechend ist er Way auch im Extrakt enthalten, was ja auch richtig ist. Allerdings sind alle Knoten entfernt, die nicht innerhalb der Grenzen Berlins liegen. Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Ein Weg/Kante kann nicht nur aus einem Knoten bestehen. Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Diese Fragen kommen wieder und wieder. Leider gibt es keine Ausschneidelogik, die für alle Anwendungsfälle richtig ist. Und leider sind manche Logiken auch deutlich aufwändiger in der Durchführung als andere. Daher ist das einfach ein Kompromiss. Das Ausschneiden passiert mit dem Programm Osmosis, das verschiedene Optionen hat, um die Logik einzustellen. Wenn Du selbst die Daten ausschneidest, kannst Du Dir selbst auswählen, welche Logik Dir am besten passt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 01.11.2010 17:52, schrieb fx99: Ich hab mir perl (offline) Skripte gechrieben, mit dem ich addr:postcode gegen das durch die PLZ Relation umschlossenen Gebiet teste. Das Ergebnis ist z.B. dargestellt in: http://wiki.openstreetmap.org/wiki/Stuttgart/PLZ Zusätzlich kommt noch eine Datei mit den falschen PLZs heraus. Eingaben: 1. bounding box für das gesamt Gebiet 2. Liste mit Relationsnummer und PLZ der PLZ Gebiete. Bei Interesse PN schicken. Supi. Irgendwie müsste man noch die Großkundensondernummern kennzeichnen, damit die aus der Prüfung ausgenommen werden können. Gibts da schon sowas in der Art addr:postcode:type=company ? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS un d Galileo für bessere Navigation
Es ist doch sowieso schon seit 2004 bekannt das GPS und GALILEO kompatibel sein werden. Also was will mir die Meldung bei Golem nun diesbezüglich eigentlich sagen? Wieso muss da noch was 'erforscht' werden ? Hallo Zusammen, ja, diese Meldung ist noch etwas speziell und Zukunftsmusik: golem: Napa: Kombination aus GPS und Galileo für bessere Navigation http://www.golem.de/1010/78985.html Es geht darum, dass u.a. Firmen IMST als Projektkoordinator, Navigon, Navteq, das Fraunhofer-Institut für Integrierte Schaltungen, die Navcert GmbH sowie der Lehrstuhl für Integrierte Analogschaltung (IAS) der RWTH Aachen und die Universität Koblenz daran forschen a) ein Empfangsmodul für GPS und Galileo für Fussgänger mit 1 m Genauigkeit entwickeln aber auch b) Dabei sollen zusätzliche Informationen zu Straßen und Fußwegen in die Karten integriert werden, um beispielsweise die Anzeige von Zebrastreifen und Ampeln sowie Unterführungen anzuzeigen. Da hat es für mich dann den Bogen zu OSM geschlagen, da ich es praktisch fände, wenn OSM Aktivisten frühzeitig zumindest mal den IST-Stand kommuniziert bekommen, um dies für aktuelle Entwicklungen direkt zu berücksichtigen und man nicht erst anfängt OSM dahingehend vorzubereiten, wenn diese Gruppe fertig ist. Oder bin ich da zu voreilig? Hat da jemand Kontakte? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Multiliguale Liste mit den Keys
gibt es eigentlich irgendwo eine mehrsprachige Liste der Keys um diese in App einzubauen - die man ggf. per Download irgendwo automatisch ziehen könnte. Bei manchen wäre eine Kombi aus key = value erforderlich bei anderen nur der Key (z.b. maxspeed). Gruß jan :-)Überprüft mit AntiVir MailGuard v10.0.1.27 AVE 8.2.4.86 VDF 7.10.13.76___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 1. November 2010 18:00 schrieb Jochen Topf joc...@remote.org: operator Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. ja, wobei auch width und sowas ja nicht statistisch ausgewertet wird, sondern freie Werte üblich sind. Trotzdem will man da Klarheit haben, was gemeint ist. D.h. Definition und Dokumentation. ist Man darf m.E. nicht nur auf Taginfo und ähnliches in der jetzigen Form schielen, wie es da am einfachsten ist, eine Auswertung zu machen, evtl. müsste man dort auch nochmal eine Unterscheidung treffen, in welchem Kontext ein Tag verwendet wird. Grundsätzlich sind verschiedene Bedeutungen desselben Tags wie bei service (übrigens bisher AFAIK wenigstens mit unique values) eigentlich kein Problem, solange es bei den Kombinationen keine Überschneidungen gibt (also z.B. ein way railway und highway gleichzeitig wäre). Bisher steht eigentlich nur fest, dass unique keys die Auswertung erleichtern und es andererseits dem Mapper geringfügig schwieriger machen, da sich das Vokabular vergrößert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 18:04 schrieb Jochen Topf joc...@remote.org: Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Das Ausschneiden passiert mit dem Programm Osmosis, das verschiedene Optionen hat, um die Logik einzustellen. Wenn Du selbst die Daten ausschneidest, kannst Du Dir selbst auswählen, welche Logik Dir am besten passt. m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug (sollten unabhängig von der ausgewählten Logik nicht enthalten sein). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
re, * 007 northc...@gmx.de [2010-11-01 18:47]: Es ist doch sowieso schon seit 2004 bekannt das GPS und GALILEO kompatibel sein werden. Also was will mir die Meldung bei Golem nun diesbezüglich eigentlich sagen? Wieso muss da noch was 'erforscht' werden ? und eigentlich wollte ich gar nicht auf die Technik hinaus :/ b) Dabei sollen zusätzliche Informationen zu Straßen und Fußwegen in die Karten integriert werden, um beispielsweise die Anzeige von Zebrastreifen und Ampeln sowie Unterführungen anzuzeigen. Da hat es für mich dann den Bogen zu OSM geschlagen, da ich es praktisch fände, wenn OSM Aktivisten frühzeitig zumindest mal den IST-Stand kommuniziert bekommen, um dies für aktuelle Entwicklungen direkt zu berücksichtigen und man nicht erst anfängt OSM dahingehend vorzubereiten, wenn diese Gruppe fertig ist. Oder bin ich da zu voreilig? Hat da jemand Kontakte? -- Grüße, Benny gpg 0xFC505AB0 jabber be...@benny.de sip be...@benny.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Bei all den Diskussionen sollte auch der Nutzen von OSM berücksichtigt werden. eben Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Das einzige Problem ist und bleibt natürlich die nun ausführlich geführte Ist das jetzt ein Service oder nicht-Diskussion. schön wärs, Probleme gibt's natürlich noch viele. Hier treffen tatsächlich zwei unterschiedliche OSM-Sichtweisen aufeinander. a) Nutzen, b) Straßenbewertung (WYSIWYG). Nutzen ist kein absolutes Kriterium, solange die Daten die benötigte Information enthalten wird man immer einen Nutzen daraus ziehen können. Straßenbewertung ist ebenfalls ziemlich allgemein gehalten und kann alles bedeuten. WYSIWYG ist eher ein Editorfeature als eine Datenbankregel, vermutlich meinst Du damit das zu taggen, was man vor Ort sieht. Das passt auf physische Eigenschaften wie Oberfläche, Breite etc., aber eben nicht auf die highway-Klassifikation. So z.B. scheinen level_crossings den Taggern nicht wirklich wichtig, weil sieht man ja, dass da Straße und Schiene kreuzen... Nur ein Routing-Topologie-Erzeuger sieht das eben nicht!!! doch klar, sieht er an dem gemeinsamen Node. Das level_crossing dient nur dazu, auszudrücken, dass man es wirklich so meint. Eine Schiene, auf der ein Autozug verkehrt, die wiederum eine Straße kreuzt ... ziemlich heftig, dies ohne level_crossing auseinanderzuhalten! ob da ein Autozug verkehrt oder nicht spielt überhaupt keine Rolle, solange man da nicht von der Straße auf den Zug abbiegen kann. Ja natürlich sind hier Schiene und Strasse mit dem selben Knoten verbunden, weil (WYSIWYG) ist ja so. ... (Aber ist eben Mist). wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich kann mich da nur wiederholen. Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! Ich selbst hab's auch versucht, einen Algo geschrieben, der in noch einigermaßen vertretbarer Zeit die Daten von OSM routingfähig rechnet und das Ganze mal durchgespielt. Mein Fazit ist dabei relativ eindeutig ausgefallen und spiegelt sich in meinen Kommentaren in diesem Thread wider. Wenn es hier also jemanden gibt, der es geschafft hat, seine OSM-Daten routingfähig zu kriegen und dabei sämtliche OSM-Relationen berücksicht, der möge sich bitte melden. SuperComputer-Benutzer sind von dieser Umfrage allerdings ausgeschlossen ;-) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
On 01.11.2010 20:09, M∡rtin Koppenhoefer wrote: m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug Das hatten wir schon mal, ist etwas über ein Jahr her. Wege komplett ohne Nodes habe ich damals als Ergebnis der Diskussion gelöscht: http://www.openstreetmap.org/browse/changeset/2250280 Die hatten damals auch schon länger keine Nodes mehr. Wege mit nur einem Node hatten wir IMHO auch angesprochen, dann aber stehen gelassen weil es dafür eventuell Gründe geben könnte. Mir persönlich wäre auch lieber wenn ein way aus 2 oder mehr Nodes bestehen muss. Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: 48238597 23907650 83584123 83584739 82651049 83602048 83602054 83633771 Da könntest du dir fast schon jeden von Hand ansehen und bei Bedarf aufräumen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] PotM - Oktober 2010 - Trinkwasser - Abschluss
Moin ! ich habe die Abschlussstatistik im Wiki hinterlegt: http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/october#Statistik Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 01.11.2010 21:18, schrieb Carsten Moeller: Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kleiner Zusatz noch: Oder auch schon gesehen: railway=rail + highway=residential + motorcar=yes als ein Weg! War eigentlich auch richtig, weil Brücke (was fehlte), aber letztere interessiert einen Router eigentlich nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 01.11.2010 21:08, schrieb Stephan Knauss: On 01.11.2010 20:09, M∡rtin Koppenhoefer wrote: m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug Das hatten wir schon mal, ist etwas über ein Jahr her. Wege komplett ohne Nodes habe ich damals als Ergebnis der Diskussion gelöscht: http://www.openstreetmap.org/browse/changeset/2250280 Die hatten damals auch schon länger keine Nodes mehr. Wege mit nur einem Node hatten wir IMHO auch angesprochen, dann aber stehen gelassen weil es dafür eventuell Gründe geben könnte. Mir persönlich wäre auch lieber wenn ein way aus 2 oder mehr Nodes bestehen muss. Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: 48238597 23907650 83584123 83584739 82651049 83602048 83602054 83633771 Da könntest du dir fast schon jeden von Hand ansehen und bei Bedarf aufräumen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Tschuldigung kurz zwischengegrätscht zu haben Bei dieser Analyse sollte man evtl auch aufanderfolgend gleiche Knotenreferenzen und ggf. unterschiedliche Referenzen mit gleichen Koordinaten mit einbeziehen und ggf. wenn unsinnig reduzieren. Dann werden's schon ein paar mehr Ein-Knoter. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo! Tom Müller-2 wrote: Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Entlang eines Osmosis-Schnittes finden sich meistens solche und andere Artefakte. Es ist empfehlenswert, das nächstgrößere Extrakt herunterzuladen und selbst mit Osmosis und den gewünschten Einstellungen die Daten auszuschneiden - am Besten noch mit ein wenig zusätzlichem Platz um den gewünschten Bereich herum. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Exporte-teilweise-fehlerhaft-in-Datenlogik-tp5694060p5695109.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] PLZ Import
Chris66 wrote: Supi. Irgendwie müsste man noch die Großkundensondernummern kennzeichnen, damit die aus der Prüfung ausgenommen werden können. Gibts da schon sowas in der Art addr:postcode:type=company ? Meiner Meinung nach hat die PLZ eines Großkunden wenig mit der Adresse zu tun. Warum nicht einfach mit postal_code=... taggen. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5695128.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] ÖPNVKarte - Neuigkeiten?
Hi Am 01.11.2010 14:26, schrieb Gernot Hillier: Auf der Webseite selbst steht auch Stand September. Zur Zeit keine Updates. Weiß jemand mehr darüber und wann es wieder Updates gibt? Ist Melchior nur einfach im Urlaub oder ist hier längerfristig mit Problemen zu rechnen? Ausschnitt aus dem Seitenquelltext: div align=center Copyright (C) 2009 by Melchior Moosbr / Datenstand der Openstreetmap-Daten: Anfang September 2010, momentan keine Updates!br / Warum es keine aktualisierte Karte mehr gibt weiß ich auch nicht. Ein Update ab und zu wäre schon nett. Kennt jemand eine schöne Alternative? Außer selber rendern fällt mir auf Anhieb auch nichts ein. Gruß Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:47:58 schrieb Jochen Topf: Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen Tag specialty gibt, der die Art des Mediziners angeben soll, um den es hier geht. das kann ich jetzt gar nicht nachvollziehen... Aber wenn ich das wiederverwenden will, z.B. mit specialty=italian an einem Restaurant oder specialty=football bei einem Sportverein. Dann habe ich total verschiedene Dinge miteinander vermischt. Will ich jetzt im Editor eine Auswahlbox einbauen, die mir eine Auswahl der wichtigsten Werte erlaubt, dann muss ich berücksichtigen, ob ein heathcare, restaurant oder sports-Tag zusätzlich hier dran ist. Ja, und? kontextabhaengige Menues sind nichts besonderes. Schau ich eine Statistik der Werte an, finde ich alle möglichen wild durcheinander. Das Wort speciality ist zu generisch, es sagt eigentlich nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden will. das ist doch eine Aussage?! Es wird niemals Sinn machen, die specialty-Fälle von healthcare und restaurant zusammen zu betrachten, so wie man z.B. im Falle von name gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen und dem Namen von Medizinern suchen kann. und deswegen soll man nicht dasselbe Tag verwenden duerfen? Betrachte specialty als generisches Tag, das einfach als genauere Spezifizierung des Haupttags benutzt wird. Das ist besser und v.a. einfacher, als fuer jede einfache Spezifizierung einen neuen Key zu erfinden... Ich muss da Martin vollstaendig recht geben: So speziell wie noetig, aber so generisch wie moeglich. Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht will man einer Brücke einen anderen Namen geben als der Straße darauf, dann wäre ein bridge_name nicht schlecht. Sollte so ein Fall noetig sein, dann wuerde ich dafuer name:bridge bzw. name:street nehmen. Denn in erster Linie ist es immer noch ein Name wie jeder andere auch - der halt in diesem speziellen Fall fuer einen bestimmten Teil des Objekts gilt. Hier hilft es auch, sich zu überlegen, was denn der typische, häufige Fall ist und was eher ein Spezialfall. Bei Namen will man sicher auch mal Namen bestimmter Objekte auf verschiedene Arten schreiben. Aber notfalls reicht es eben, alle gleich zu schreiben. Bei einem ref glaube ich da schon weniger dran. Ich will sicher keine Bushaltestellen-Bezeichner haben, die aussehen wie die typischen Straßensymbole (highway shields). Der einfache Fall sollte einfach sein (also vorallem nicht die Kombination mehrerer Tags erfordern), Spezialfälle aber durchaus. Bei ref macht eine Unterscheidung wesentlich mehr Sinn, als bei name, ja. Aber auch hier kann man die Bedeutung des Tags in den meisten Faellen vom Kontext ableiten. Fuer Spezialfaelle kann man immer noch sowas wie ref:highway bzw. ref:bridge verwenden. 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] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:56:54 schrieb Karl Eichwalder: Bernd Wurst be...@bwurst.org writes: Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Manche dinge haben allerdings zwei doer mehr namen; standardbeispiel: straße auf einer brücke. Das können wir so ohne weiteres nicht abbilden. name:highway = foo name:bridge = bar 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] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo Carsten, On 01.11.2010 21:48, Carsten Moeller wrote: Am 01.11.2010 21:08, schrieb Stephan Knauss: Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: [...] Bei dieser Analyse sollte man evtl auch aufanderfolgend gleiche Knotenreferenzen und ggf. unterschiedliche Referenzen mit gleichen Koordinaten mit einbeziehen und ggf. wenn unsinnig reduzieren. Dann werden's schon ein paar mehr Ein-Knoter. Ja, da hast du recht. Technisch gesehen (aus sicht der API) hat der Weg dann aber schon mehr als einen node. Eben mehrfach einen gleichen. Dass es dann noch nodes mit unterschiedlichen IDs auf gleicher Koordinate geben kann kommt dazu. Ich hätte mir gewünscht, dass die API zumindest die Anzahl 2 oder mehr fordert. Und wenn die Prüfung nicht zu teuer wird auch gerne die verschärfte Variante mindestens 2 verschiedene Node-IDs. So lange das die API nicht einfordert ist es an den Editoren bzw. den Mappern das entsprechend anzuwenden oder hinterher aufzuräumen. Schweift aber langsam etwas von der Ursprungsfrage ab. Ich halte es jedenfalls nicht für einen Bug des Extracts wenn da ein way mit weniger als 2 Nodes enthalten ist. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 23:11 schrieb Stephan Knauss o...@stephans-server.de: Ich halte es jedenfalls nicht für einen Bug des Extracts wenn da ein way mit weniger als 2 Nodes enthalten ist. ich beziehe mich auf http://wiki.openstreetmap.org/wiki/Way A way is an ordered interconnection of at least 2 and at most 2,000[1] bzw. [1] http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/config/application.yml (scheint nicht zu funktionieren) wenn die Info da falsch im Wiki steht sollte man es m.E. ändern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hi! M∡rtin Koppenhoefer wrote: ich beziehe mich auf http://wiki.openstreetmap.org/wiki/Way A way is an ordered interconnection of at least 2 and at most 2,000[1] bzw. [1] http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/config/application.yml (scheint nicht zu funktionieren) wenn die Info da falsch im Wiki steht sollte man es m.E. ändern. Das sind zwei Paar Stiefel. Das Wiki beschreibt die Daten in der OSM Datenbank und ist korrekt. Die lokale Verarbeitung mit anderer Software wie z.B. Osmosis wird davon nicht berührt. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Exporte-teilweise-fehlerhaft-in-Datenlogik-tp5694060p5695365.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] AIO - Routing über Fähren
Am 1. November 2010 21:02 schrieb Carsten Moeller cmindivid...@gmx.de: Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! die bekommen es auch nicht hin, neue Daten zeitnah in Ihre Renderings zu übernehmen, oder einen schönen Renderstil zu entwickeln, wieso sollte das ein Kriterium sein? Bei ÖPNV ist allerdings neben den Routen auch ein Fahrplan nötig, damit man sinnvoll routen kann damit --- zumindest wenn nicht jede halbe Stunde eine Fähre geht. Für die reine Route des ÖPNV reicht im Prinzip die Liste der Haltepunkte weil es keine Rolle spielt, welchen genauen Weg das Mittel dafür nimmt (Strecke und Zeit wären natürlich nicht schlecht). Fürs Routing interessant ist dann wie oben schon gesagt in erster Linie der Fahrplan. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
wei postal_code für strassen ist. - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5695395.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] Online-Befragung der OSM-community - community-Daten zu gewinnen!
War es das hier?: http://blog.fefe.de/?ts=b29afd7d genau das wars. Okay, die exakte Adresse war nicht dabei, aber ... -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Kann man so nicht wirklich vergleichen! Einen See ist ein Stück der Erdoberfläche die mit Wasser bedeckt ist (abgesehen von den unterirdischen Seen). Eine Badewanne ist ein nach oben offenere Behälter der mit Wasser gefüllt ist. Beide haben im Prinzip nur gemeinsam dass sie mit Wasser gefüllt sind um ihren Zweck zu erfüllen. Ein Flugplatz bzw. Start/Landeplatz ist dagegen ein Stück Land das ausnahmslos dafür definiert ist dass dort regelmässig Boden-Luftübergänge von Fluggeräten stattfinden und von dort eine entsprechende damit verbundene Gefährdung ausgeht die insbesondere alle Luftfahrzeuge (ob Modellflieger oder A380)betrifft. Als Reisender Interessiert mich natürlich nur der Flughafen an dem mein Flug abgeht. Die wenigsten suchen sich ausserdem erst einen Flugplatz - schon gar nicht per Navi - und versuchen von dort aus einen Flug zu ihrem Ziel zu bekommen. Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Aus der Angabe Flugplatz bzw. Start/Landeplatz kann man nun mal nicht mehr erkennen als das dort eine Luft-Boden Übergang von Fluggeräten stattfindet. Und mehr hineinzuinterpretieren wäre schlichtweg falsch! Eine Angabe des immer(?) dreistelligen Flughafenkürzels das auf jedem Verkehrs-Flugticket zu finden sein sollte hat man eine eindeutige Zuordnung zu welchem Flughafen man muss. wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Vielleicht sollte man hier Unterscheiden zwischen Punkt-zu-Punkt-Verbindungen in denen die Eisenbahn eine Strasse ersetzt bzw. wintersichere, kurze Verbindungen ermöglicht (Bsp. Sylt, Lötschbergtunnel, Furkatunnel, Vereinatunnel) und den Autoreisezugverbindungen bei denen man einfach nur die eigene Lenkzeit im Fernverkehr verkürzen möchte (Bsp. Lörrach - Hamburg.). Ersteres sollte so ausgelegt sein dass es schon mit einfachen Routern funktioniert die nicht tausende von unterschiedlichen Details auswerten, - in der Regel fährt man dort einfach hin und kann nach rel. kurzer Wartezeit einfach auf den Zug fahren. Hier macht es Sinn dass in das ganz normale Strassenrouting zu integrieren. Zweiteres erfordert mehr Aufwand und wird in der Regel auch deutlich vorher gebucht. Hier macht es ehr keinen Sinn das ins normale Strassenrouting zu integrieren, man gibt als Ziel den Verladebahnhof ein und routet dann vom Entladebahnhof erneut. Für einen Reiseplaner kann man hier mehr Aufwand investieren und diese Alternative vorschlagen. Entsprechendes gilt natürlich auch für Fähren. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte - Neuigkeiten?
Am 01.11.2010 23:00, schrieb Carsten Schönert: Kennt jemand eine schöne Alternative? Außer selber rendern fällt mir auf Anhieb auch nichts ein. Die Tools der Geofabrik lassen einen zumindest vieles anschauen, wenn auch nicht so schön. http://tools.geofabrik.de/osmi/?view=pubtrans_stopslon=6.36052lat=50.81470zoom=14 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am Montag 01 November 2010, 22:00:14 schrieb fx99: Meiner Meinung nach hat die PLZ eines Großkunden wenig mit der Adresse zu tun. Na doch, wenn man ein Gebäude eines Betriebs mit eigener PLZ nach Karlsruhe- Schema tagged, gehört da die wahre PLZ dran. Und die ist dann halt nicht passend zu der anderer Gebäude drum herum. Gruß, Bernd -- Fachbegriffe der Informatik (#367): Patentverhandlungen Beide Firmen drucken ihre Patente aus und legen die Stapel nebeneinander. Der mit dem höheren Stapel hat gewonnen. (Rainer Zocholl zitiert einen Patentanwalt) 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
