Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
Am 25.09.2014 13:03, schrieb thsMD: Noch eine Zusatzfrage: Welche Attribute verwendet man, wenn Radfahren auf dem Weg explizit nicht verboten ist (kein Schild), ich aber der Meinung bin, dass dort keiner mit seinem Rad langfahren möchte? Theoretisch gilt für Wege ohne Schilder (aus Art. 25 BayNatSchG): Das Radfahren, das Fahren mit Krankenfahrstühlen und das Reiten ist im Wald nur auf Straßen und geeigneten Wegen zulässig. Die Vorschriften des Straßen- und Wegerechts und des Straßenverkehrsrechts bleiben unberührt. Nur hält sich sowieso keiner dran. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 28.02.2014 11:38, schrieb Martin Koppenhoefer: Eher nicht, weil mit einem Zusatztag wie locality=square würde das vielleicht schon wieder anders aussehen (und in einem nächsten Schritt könnte man das place=locality gleich ganz weglassen und nur locality=* taggen). Alternativ vielleicht auch toponym=square oder so? +1 Ich finde place=locality sowieso etwas unscharf, da es für sehr unterschiedliche Typen von Örtlichkeiten Verwendung finden kann. Mit name=Schwarzwald, place=locality wird eine recht bedeutende Örtlichkeit beschrieben, wobei name=Grabenfeld, place=locality nur von lokaler Bedeutung ist. Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist an eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe ziehen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbild-Versatz - Schachtdeckel
Am 10.02.2014 21:14, schrieb Dirk Sohler: Markus schrieb: *lach* - und was bedeutetperfekt? ;-) Bei einem GPS-Empfänger mit ’nem Arsch voller Satelliten und mit RTCM bedeutet „perfekt“ eine Abweichung im Zentimeterbereich. Zentimeterbereich? Mal eine kleine Anmerkung: Wir verschieben uns mit ganz Europa jedes Jahr ca. 2,5 cm ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 05.11.2013 23:33, schrieb Martin Koppenhöfer: Am 05.11.2013 um 23:18 schrieb Garry garr...@gmx.de: Wo gibt es so etwas in nenneswertem Ausmass? Siehst Du ein Problem wenn Anwendungen(!) residentials per default als innerorts interpretieren wenn (noch) nicht anderst angegeben? Im Ausland und ggf. in den neueren Bundesländern (Bestandsschutz), in den älteren Bundesländern ist der Landschaftszersiedelung schon ziemlich lange durch BauGB 35 (Bauen im Aussenbereich) ein Riegel vorgeschoben, das stimmt zwar, aber die Welt ist ja noch ein bisschen größer ;-) Ja, genau, in ländlichen Gebieten gibt es jede Menge Ortsstraßen mit surface=gravel/unpaved. Ausschlaggebend für mich ist, ob es dort Straßennamen und Häuser mit Hausnummern gibt, die sich dem Ort zuordnen lassen. Meist fangen diese Straßen im Ort geteert an und sind zum Ortsrand hin unbefestigt. Häuser im Außenbereich mal ausgenommen. Der Feldweg fängt dann eben nach dem letzten Haus an. Bei einer Tour kann man das auch meistens sofort erkennen. Steht am Feldweg ein Ortsausgangsschild, kann es sich unter Umständen sogar um eine Verbindungsstraße mit surface=gravel handeln. Bei nicht-residental kommt halt innerorts ein maxspeed mit source:maxspeed=de:urban dran. Für residental außer Orts fällt mir jetzt kein Beispiel ein, aber wenn das auftreten sollte, bekommt der Weg z.B. maxspeed=100 source:maxspeed=DE:rural. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Portal zur Geolizenz
Hallo Liste, schon gesehen? Ein Portal der Bundesrepublik Deutschland zur Geolizenz ist online: www.geolizenz.org Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 14.06.2013 02:07, schrieb Martin Koppenhoefer: Am 13. Juni 2013 22:23 schrieb Masi Master masi-mas...@gmx.de: Bezieht sich das Zusatzschild nicht IMMER auf das zulässige Gesamtgewicht, und das Zeichen 250 mit dem Gewicht drinnen immer auf das tatsächliche Gewicht? (Oder so ähnlich...) Dann müsste der Auswerter den Unterschied kennen und nur schauen, in welcher Kombination das Schild getaggt ist (sofern es hier richtig eingetragen ist). m.E. braucht man 2 unterschiedliche tags, einen für tatsächliches Gewicht (maxweight und weight) und einen für zulässiges Gesamtgewicht (fehlt AFAIK noch). Was haltet Ihr davon? maxweight:conditional=7.5 @ hgv Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 13.06.2013 12:48, schrieb Martin Koppenhoefer: Anlässlich eines aktuellen Threads in der ital. Mailing-Liste wollte ich mal hier nachfragen, ob es eine allgemeine Lösung für diese Restriktion gibt: http://commons.wikimedia.org/wiki/File:Zeichen_253.svg mit Zusatzzeichen 7,5 Tonnen. (Name des Zeichens: Verbot für Kraftfahrzeuge mit einem zulässigen Gesamtgewicht über 3,5 t, einschließlich ihrer Anhänger, und Zugmaschinen, ausgenommen Personenkraftwagen und Kraftomnibuse) D.h. das gilt nicht für Busse und Personenkraftwagen (Geländewagen etc.), aber für den Rest, und es geht um das zulässige Gesamtgewicht, das inkl. Anhängern 7,5 Tonnen nicht überschreiten darf (also nicht das tatsächliche Fahrzeuggewicht). Ausserdem geht es nur um Kraftfahrzeuge, d.h. z.B. etwaige Pferdekutschen, die evtl. über 3,5 t zul. Gesamtgewicht kommen könnten, sind auch nicht betroffen. Vorschlag: hgv:conditional=no @ (weight3.5) (http://wiki.openstreetmap.org/wiki/Conditional_restrictions) Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 13.06.2013 14:59, schrieb Martin Koppenhoefer: Am 13. Juni 2013 13:37 schrieb bkmap burkhard.kirch...@web.de: Vorschlag: hgv:conditional=no @ (weight3.5) (http://wiki.openstreetmap.**org/wiki/Conditional_**restrictionshttp://wiki.openstreetmap.org/wiki/Conditional_restrictions ) Halb OK, gibt aber ein paar Probleme: 1. hgv beschreibt die Klasse nicht ausreichend. OK, Natürlich müsste es (weight7.5) heißen. Was an hgv passt denn nicht? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht
Am 13.06.2013 17:42, schrieb Martin Koppenhoefer: On 13/giu/2013, at 15:35, bkmap burkhard.kirch...@web.de wrote: 1. hgv beschreibt die Klasse nicht ausreichend. OK, Natürlich müsste es (weight7.5) heißen. Was an hgv passt denn nicht? sorry, das hgv passt vermutlich schon, wenn es auch im Wiki nicht weiter beschrieben wird, Problem ist das weight. Habe dazu zwar im Wiki nichts explizit gefunden, würde aber davon ausgehen, dass das wie height funktioniert, also das tatsächliche Gewicht beschreibt. Dann sollte ja hgv:conditional=no @ (weight7.5) passen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSM Flyer
Am 20.05.2013 17:56, schrieb Tobias Hobmeier: Hi hi, wir wollten uns einen eingenen Flyer basteln und suchen quasi als Inspirationsquelle den aktuellen OSM flyer am besten als Sourcecode äquivalent :-D hat jemand einen link für mich? http://svn.openstreetmap.org/misc/pr_material/german_flyer_2013_01/ Guß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Buchstaben-Ergänzung bei Hausnummern mappen?
Hallo, Dem Nutzer will ich in dieser Sache nur ungern eine Schreibweise vorschreiben. Das empfinde ich persönlich als Überregulierung und ist meist sowieso nicht durchsetzbar. Außerdem gibt es ja, wie bereits erwähnt, regionale Unterschiede ;) +1 Ich stimme dem zu. Man soll es jedem selbst überlassen, ob er das Ei am breiten oder spitzen Ende aufschlägt ;) Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tankstellen
Hallo, Am 12.03.2013 15:53, schrieb Wolfgang Wienke: Hi, findet Ihr es ok, wenn man auf open-link-map bei einer Tankstelle einen Link zu dem entsprechenden Eintrag bei clever-tanken (mit den Preisen) angibt? Ich wäre dafür, diese Verordnung abzuwarten: http://www.bmwi.de/BMWi/Redaktion/PDF/V/verordnung-zur-markttransparenzstelle-fuer-kraftstoffe,property=pdf,bereich=bmwi2012,sprache=de,rwb=true.pdf Dann könnte man die Datenbank direkt abfragen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tankstellen
Am 12.03.2013 16:49, schrieb bkmap: Hallo, Am 12.03.2013 15:53, schrieb Wolfgang Wienke: Hi, findet Ihr es ok, wenn man auf open-link-map bei einer Tankstelle einen Link zu dem entsprechenden Eintrag bei clever-tanken (mit den Preisen) angibt? Ich wäre dafür, diese Verordnung abzuwarten: http://www.bmwi.de/BMWi/Redaktion/PDF/V/verordnung-zur-markttransparenzstelle-fuer-kraftstoffe,property=pdf,bereich=bmwi2012,sprache=de,rwb=true.pdf Wobei ich bei dem Entwurf nicht verstehe, warum die Identifikationsnummer geheim bleiben und warum der Zugang nicht für jeden frei sein soll. Es gibt ja schließlich das Informationsfreiheitsgesetz. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Test neues Geofabrik-Download-Setup
Hallo Frederik, Am 27.02.2013 13:59, schrieb Frederik Ramm: jetzt hier etwas fertig, was ich eigentlich bald zum Standard-Downloadserver machen moechte: http://download.geofabrik.de/test Für mich sieht das recht übersichtlich aus. Was ich sonst bemerkt habe: Die back-links funktionieren nicht. Im Link [one level up] auf der Seite europe.html steht ..\europe.html statt .\index.html auf der Seite europe/germany.html steht ..\germany.html statt ..\europe.html Möglicherweise auch in den anderen Seiten? Auf der Seite europe.html steht im direkten Link [.osm.pbf] bei Thüringen germany/thueringen.osm.pbf statt germany/thueringen-latest.osm.pbf und im Link [.shp.zip] steht germany/thueringen.shp.zip statt germany/thueringen-latest.shp.zip Das -latest scheint übrigens überall zu fehlen. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Hallo, die Files für den neuen Flyer liegen in http://svn.openstreetmap.org/misc/pr_material/german_flyer_2013_01/ Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 18.01.2013 09:33, schrieb Falk Zscheile: Am 18. Januar 2013 08:08 schrieb Martin Vonwald (imagic) imagic@gmail.com: Am 18.01.2013 um 01:00 schrieb Bernhard Weiskopf bweisk...@gmx.de: Warum ist das falsch? Die blauen Zeichen 237, 240 und 241 bedeuten: Radfahrer dürfen nicht die Fahrbahn ... benutzen. Ich interpretiere das als klares Verbot, also bicycle = no auf der Straße. Ich bin gerade mit dem Fahrrad gefahren. Auf einer Straße. Neben einem benützungspflichtigen Radweg. An der Polizei vorbei. Nichts ist passiert! Warum? Kleiner Tipp: es ist weiß und kalt. Die Benützungspflicht gilt nur, wenn der Radweg auch benutzt werden kann. Wenn der Radweg z.B. nicht geräumt ist, muss ich ihn nicht benutzen. Ebenso muß ich ihn nicht benutzen, wenn er zwar frei ist ich aber nicht auffahren kann, weil z.B. an der aktuellen Stelle keine Absenkung vorhanden ist. Das sind nur zwei Beispiele von vielen. All das bedeutet, dass bicycle=no auf der jeweiligen Straße falsch ist. Nein, wir orientieren uns bei OpenStreetMap (bei allen Unsicherheiten, die es gibt) immer noch im Normalfall. Also wie ist die Lage wenn keine besonderen Umstände hinzutreten. Dein Argument, dass Du heute auf der Straße gefahren bist, weil der Radweg nicht geräumt war, ist kein Grund, das tagging zu ändern. Den gesunden Menschenverstand sollst/musst du auch sonst im Straßenverkehr gebrauchen -- egal was Dir Karte oder Router sagt. In diesem Fall ist der gesunde Menschenverstand, das man nur dort fahren soll, wo es auch sicher geht, gerichtlich anerkannt, nicht mehr und nicht weniger. Das taggen zu wollen halte ich für nicht angebracht. Wenn Du es unbedingt willst, dann kannst Du gern als Tag bicycle:winterservice:cycleway:no:snow=yes verwenden, aber nicht bicycle=no als grundsätzlich getroffene Verkehrsregelung in Frage stellen. So ganz unrecht hat Martin nicht. Seine Argumente sind aber schwach, wie Du ja auch bemerkt hast. Mir ist da jetzt ein stärkeres Argument eingefallen: Wenn man irgendwo abbiegen oder vielleicht ein Grundstück erreichen will, und dies auf dem Radweg nicht erreichbar ist, darf man die Straße benutzen. An solchen Stellen würde ein bicycle=no auf der Straße dem Router verbieten, Fahrräder dort entlang zu führen. An anderen Stellen sehe ich keine Bedenken, das so zu handhaben. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013 00:11, schrieb Wolfgang Hinsch: Am Mittwoch, den 16.01.2013, 16:53 +0100 schrieb Josef Latt: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist, als Gegensatz zu bicycle=designated. ärt war oder nicht. Wie wär's denn hier mit highway=path oder highway=track? highway=cycleway impliziert immer bicycle=designated wenn das anders ist, sollte man path oder track verwenden. Da sind Fahhräder implizit erlaubt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Hallo, Am 17.01.2013 17:30, schrieb Masi Master: Am 17.01.2013, 09:16 Uhr, schrieb bkmap burkhard.kirch...@web.de: Am 17.01.2013 00:11, schrieb Wolfgang Hinsch: Am Mittwoch, den 16.01.2013, 16:53 +0100 schrieb Josef Latt: Und wann ist nun das Resumee? foot=yes an highway=footway als Verifikation, welche real keine ist, oder Datenmüll. Dito für bicyle=no anhighway=footway Auch bicycle=yes an highway=cycleway fällt in diese Kategorie. bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist, als Gegensatz zu bicycle=designated. ärt war oder nicht. Wie wär's denn hier mit highway=path oder highway=track? highway=cycleway impliziert immer bicycle=designated wenn das anders ist, sollte man path oder track verwenden. Da sind Fahhräder implizit erlaubt. Warum soll man path oder track zweckentfremden? Ein Radweg ist ein auf Radfahrer angepasster Weg. Dazu zählen u.a. abgesenkte Bordsteine, Sicherheitsraum zu Parkplätzen Fußweg, sehr ebenener Untergrund, gradlinige Führung, gute Sicht/wenig Gefahrenstellen, ... Falsch! Nicht jeder Weg, der diese Eigenschaften hat, also wunderbar zum Radfahren geeignet ist, ist ein Radweg. Warum soll man einen Radweg nicht als solchen taggen? Ein path kann alles sein, und ein track ist wieder was anderes. Ok, wenn es ein richtiger ausgewiesener Radweg (mit Zeichen 237, 240 oder 241) ist. Dann ist bicycle=designated implizit. Das steht wenigstens so im Wiki. bicycle=yes überschreibt also das implizite bicycle=designated. Wenn man als Defaultwert für Deutschland noch foot=no und horse=no annimmt, ist also ein Weg gemeint, der 1. kein ausgewiesener Radweg ist, aber auf dem 2. auch kein anderer Verkehr erlaubt ist, sondern nur Fahrräder. Das wäre z.B. Zeichen 250 und Zusatzzeichen 41.1 (Wahrscheinlich in der Kombination gar nicht möglich). Also mir fällt kein solcher Weg ein. Sicher aber ist, dass eine solche Attributierung für ausgewiesene Radwege eindeutig falsch ist. Wenn mir so etwas in die Finger kommt, schaue ich an Ort und stelle nach und korrigiere das. Wenn ich richtig verstanden habe, soll ein highway=cycleway ein Tag bicycle=yes bekommen, weil: bicycle=yes wurde (wird?) z.B. im Lübecker Raum benutzt, um anzuzeigen, dass der Weg für Radfahrer erlaubt, aber nicht verpflichtend ist. Ich bin dafür, dass man das Ganze so einfach und klar handhabt, dass man nichts falsch machen kann: Ein Radweg ist für mich ein Radweg, wenn er als Radweg ausgewiesen ist, ansonsten track oder path, je nachdem. Wenn es ein kombinierter Fuß- und Radweg ist (Zeichen 240 oder 241) kommt noch foot=designated und segregated=yes/no dazu. Wenn der Radweg entlang einer Straße verläuft, darf ich nicht auf dieser Straße fahren. Das attributiere ich AUF DIESER STRASSE mit bicycle=no. Dann weiß das auch jeder Router. Was kann man da falsch machen? Es sind schon alle Tags dafür erprobt und etabliert. Es besteht kein Grund, dafür etwas Neues zu erfinden. Warum, um Himmelswillen sollte man das so kompliziert machen? Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 17.01.2013 21:23, schrieb Steffen Wolf: Hallo bkmap und Josef Latt, bkmap schrieb: Am 17.01.2013 17:30, schrieb Masi Master: Ein Radweg ist ein auf Radfahrer angepasster Weg. Dazu zählen u.a. abgesenkte Bordsteine, Sicherheitsraum zu Parkplätzen Fußweg, sehr ebenener Untergrund, gradlinige Führung, gute Sicht/wenig Gefahrenstellen, ... Falsch! Nicht jeder Weg, der diese Eigenschaften hat, also wunderbar zum Radfahren geeignet ist, ist ein Radweg. Ein Radweg ist für mich ein Radweg, wenn er als Radweg ausgewiesen ist, ansonsten track oder path, je nachdem. Ihr nehmt an, dass nur mit Zeichen 237, 240 und 241 ausgezeichnete Wege Radwege sein koennen. Dabei ignoriert ihr die anderen Radwege, also die nichtbenutzungspflichtigen Radwege. http://de.wikipedia.org/wiki/Radverkehrsanlage#Nicht_benutzungspflichtige_Radwege Stimmt aber „Radwege ohne Benutzungspflicht“ sind fahrbahnbegleitend. cycleway:right/left, cycleway:right/left:bicycle=yes Wo eine Kombination higway=cycleway und bicycle=yes sinnvoll wäre, ist allenfalls folgende Situation. Ein „Radweg ohne Benutzungspflicht“ (kein blaues Schild aber auf andere Weise eindeutig dem reinen Radverkehr zuordenbar) der durch eine breite Linie von der Straße abgesetzt ist, verläuft vor einer Kreuzung ein Stück baulich getrennt etwas abseits der Straße. Auf diesem Stück könnte man higway=cycleway und bicycle=yes einsetzen. higway=path, foot=no, horse=no wäre da denkbar, aber dort würde ich wahrscheinlich auch higway=cycleway vorziehen. Ungeachtet dessen halte ich Massenedits ohne Ortskenntnis nicht für sinnvoll. Man sollte sich solche Stellen wenigstens mal in Natura ansehen. Wenn Massenedits doch notwendig sind, sollten sie vorher diskutiert werden. Mit Ortskenntnis oder wenn es wirklich eindeutig ist, sehe ich keine Probleme. Ich habe z.B. im meinem Heimatgebiet Bäche mit tunnel=yes auf tunnel=culvert umgestellt. Ich habe aber jeden einzeln beim Edit kontrolliert, ob es sich wirklich um eine Durchörterung handelt. Ohne Ortskenntnis kaum möglich. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 15.01.2013 15:26, schrieb Volker Schmidt: Falls ich das richtig verstehe, betrachtest du layer=-1 an einem Gewaesser falsch? Mir scheint hingegen layer=-1 an einem Gewaesser voellig korrekt, da - normalerweise Wege und Strassen mit dem - impliziten - layer=0 eingetragen werden. Dadurch wird sichergestellt, dass Gewaesser unter den Strassen durchfuehren, auch wenn kein 'bridge' oder 'tunnel' tag gesetzt worden ist. Dann verläuft das Gewässer auch unter z.B. den Waldflächen, die es kreuzt. Na ja, im Luftbild sieht man den Bach im Wald ja auch nicht ;-) Diese Praxis erscheint mir insbesondere sinnvoll in Faellen von kleinen Gewaessern, wo das das explizite taggen von Bruecken usw. haeufig erst in einem zweiten oder dritten Durchgang - wenn ueberhaupt - durchgefuehrt wird Das Gewässer sollte m.E. nur an den Stellen Layer=-1 erhalten, an denen es andere Objekte unterquert. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Hallo, Am 15.01.2013 09:50, schrieb Hans Schmidt: Hallo, ich habe auch noch was gefunden: In dem Teil zu „Wie funktioniert OpenStreetMap“ steht „Haus- nummern“. Das müsste allerdings „Hausnummern“ heißen. Viele Grüße Habe eine 300-dpi-Version als jpeg hoch geladen (png ist zu groß): http://wiki.openstreetmap.org/wiki/File:German_flyer_2013_01_300dpi.jpg Sobald ich auf SVN hochladen kann, kann der Flyer dann direkt mit dem SVN-Verzeichnis verlinkt werden. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Am 14.01.2013 08:14, schrieb Gerhard Hermanns: Hallo zusammen, ich finde, dass wir da schon einen sehr guten Flyer haben, danke dafür! Wenn ich das richtig sehe, ist der neue Flyer noch nicht in der Wiki verlinkt. Wird er denn schon verwendet? Ist noch nicht hoch geladen und nicht verlinkt. Ich habe auch keinen SVN-Account, um die Daten an die richtige Stelle zu laden. Ich habe sie aber an Frederik geschickt, da die Geofabrik ja bislang den Druck gesponsert hat. Neue Flyer gibt es aber aus Zeitgründen wahrscheinlich erst Ende Februar. Falls akuter Bedarf an den Files besteht, könnte ich sie als gezippt ins Wiki laden. Wer sie selbst Drucken lassen will, muss sich, je nach Druckerei, selbst um die Aufbereitung kümmern, oder eben warten, bis es wieder welche von der Geofabrik gibt. Mir sind auch noch ein paar Fehler aufgefallen: 1) Abschnitt Machen Sie mit ...: * Am Ende des ersten Absatzes fehlt der Punkt, es scheint aber, als sollte der Satz dort noch weitergehen? ... mit Links zu Foren [und ... (?)]. * Das Ende des zweiten Absatzes fehlt. * Im dritten Absatz steht Openstreetmap statt OpenStreetMap. * Ebenfalls im dritten Absatz: Es müsste OSM-Daten statt OSM Daten heißen. 2) Im Abschnitt Wozu eine ... klebt der Text sehr nah am Bild des GPS-Geräts. 3) Im Abschnitt Wie funktioniert ... die von Chaos erwähnten Umbrüche. Leider hat sich noch ein kleiner Fehler eingeschlichen.Im 2ten Textblock der unteren Hälfte, finden sich mehrere Worte mit Trennstrichen trotz Verwendung mitten in der Zeile. Ge-bäudeumrisse Haus-nummer. Danke für die Fehlersuche. Vor morgen komme ich aber nicht zu Korrekturen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Hallo zusammen, Danke für die Fehlersuche. Hier die korrigierte Fassung: http://wiki.openstreetmap.org/w/images/9/99/German_flyer_2013_01.png Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Am 14.01.2013 22:42, schrieb gmbo: Mir war noch etwas aufgefallen. Wenn man den Flyer 2 seitig druckt, dann ist eine Seite auf dem Kopf. Habe mir mal die eine Hälfte um 180° gedreht. Dann klappt der Duplexdruck prima. Ich könnte das Bild im Wiki hochladen, sah dort aber dass es aus einer SVN Quelle kommt, bin da noch unsicher was da am besten ist. Das Bild ist aus 2 SVG-Files exportiert, die zusammen mit den verwendeten Grafiken im genannten SVN-Repository liegen. Wie schon gesagt: Da ich keinen SVN-Account habe kann ich die Files nicht einchecken. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL-Flyer
Hallo, Am 26.10.2012 17:53, schrieb Peter Wendorff: Am 26.10.2012 17:41, schrieb Martin Koppenhoefer: Am 26. Oktober 2012 16:13 schrieb Peter Wendorff OpenStreetMap veröffentlicht die Kartendaten unter der OpenDabaseLicense (ODbL 1.0) und darauf muss man auch hinweisen, wenn man die Daten von Openstreetmap in einem Werk verwendet. Weitere Auflagen gibt es für Werke aus OSM Daten nicht, wohl müssen aber Verbesserungen und Ergänzungen, die man an den Daten vornimmt, auch wieder unter der ODbL stehen, sofern man diese Daten oder daraus gemachte Werke weitergeben will. Da sich hier nichts weiter getan hat, habe ich mal Eure Vorschläge in den Flyer eingearbeitet. Was haltet Ihr davon? http://wiki.openstreetmap.org/wiki/File:German_flyer_2013_01.png Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Abfrage mit UTM (war: Gauß-Krüger-Koordinaten)
Am 10.12.2012 06:31, schrieb Martin Trautmann: On 12-12-09 21:40, Martin Trautmann wrote: On 12-12-09 14:44, Henning Scholland wrote: Was mach' ich falsch? Ein Teil des Fehlers wurde gefunden - ich habe zu simpel das Beispiel aus dem Wiki übernommen: cs2cs +init=epsg:31466 +to +init=epsg:4326 input.txt ^ Wie zwei Abschnitte weiter vorne erklärt ist 31466 gk2, während ich gk4 mit init=epsg:31468 benötigte. Es gibt übrigens auch Gitterdaten (BETA), die die Transformation sehr viel genauer machen. Dazu ist hier für den Einstieg: http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/BETA2007dokumentationV15.pdf Ich hab aber noch keine Ahnung, ob bei der Umrechnung mit cs2cs der halbe Meter Kontinentaldrift schon in die Berechnung einfließt. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Distriktgrenzen anhand von Straßenverzeichnis eintragen, Grenzverlauf?
Am 05.10.2012 11:14, schrieb Walter Nordmann: Ich würde die Distrikte als Grenzen erfassen (admin_level=10 ?) sodass die Strassen in ihrem Distrikt liegen. Dann kann man ALLE Objekte - also auch Geschäfte, Kindergärten, Haltestellen, Ampeln, Zebrastreifen, Littfass-Säulen, HKTS auf ihre Lage hin abfragen und nicht nur die, die ein is_in-Tag haben. Dass die Grenzen nicht genau sein können, ist mMn vertretbar. +1 Ich würde aber nicht nach name:(Straße1 | Straße2 | ...) sondern nach addr:street:(Straße1 | Straße2 | ...) suchen. Damit werden alle Häuser markiert, die zu den Straßen gehören. Ein Multipolygon mit admin_level=10 drum rum zu ziehen, wäre dann recht einfach. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer
Am 26.09.2012 17:00, schrieb Frederik Ramm: Gerade das OpenSeaMap-Team ist in der Vergangenheit oefters mit Eigenmaechtigkeiten beim Tagging aufgefallen, auf die man freundlich, aber bestimmt hinweisen sollte; OpenSeaMap hat einen eigenen Rendering-Stack und kann voellig problemlos auch ein seamark:type = restricted_area in die eigenen Karten einzeichnen, die muessen dazu kein landuse=military setzen. +1 Stimmt, das würde ich durch military=danger_area ersetzen. aviation=danger_area das dort genutzt wird, sieht nach Neuerfindung aus. Ein Proposal für aviation gibt es im Wiki noch nicht. Der Rest seamark:*=* sieht doch gut aus. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer
Am 26.09.2012 17:12, schrieb Falk Zscheile: Am 26. September 2012 16:39 schrieb Jan Jesse j...@jesse.de: Ich glaube, daß solche für den Renderer gemachten Einträge auf Dauer gefährlich sind, da hier keine Realität, sondern ein gewünschtes Kartenbild generiert wird. Im Zusammenhang mit nautischen Informationen hat das aber inzwischen seine Tradition. OpenSeaMap fährt da eine ziemlich eigenwillige Strategie. Schade finde ich, daß sie tatsächlich meinen, alle Informationen nach eigenem Schema neu taggen zu müssen, dabei unendlich viele Fehler passieren und die Konsistenz der nautischen Informationen zumindest in Deutschland erheblich gestört ist. Auch wenn ich mich im Schema von OpenSeaMap nicht besonders auskenne, so glaube ich nicht, dass landuse=military auf das Konto des OSeaM Schemas geht. OSeaM hatte sich da mit Sicherheit etwas eigenes ausgedacht, schwerer verständliches ausgedacht ;-) Aber es kann ja auch nicht die Lösung sein, dass ich den OSeaM-Leuten auf die Nerven gehe, damit sie seamark:restricted_area:category=military in der eigenen Karte darstellen, damit ich dann dem user, der landuse=military unpassend verwendet schreiben kann Das musst du jetzt nicht mehr machen, OSeaM kann das jetzt selbst Vorschlag: military=danger_area Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bahn-Fahrplan als offene Daten
Hallo, das wäre doch mal ein Anfang, um den öffentlichen Nahverkehr wirklich öffentlich zu machen. http://www.openpetition.de/petition/online/bahn-fahrplan-als-opendata-veroeffentlichen Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: Darstellung der Wanderwege des Harzklubs im OSM
Am 18.09.2012 21:26, schrieb Manuel Reimer: Johannes Hüsing wrote: Dann wäre es ja auch schon strittig, ob man operator=REWE mit beim Supermarkt einträgt. ... oder gar name=REWE... Ich frage mich hier, was das Markenrecht tatsächlich aussagt. Nennen und niederschreiben wird man den Namen ja wohl dürfen. Soweit ich weiß, kann die Nennung einer Wortmarke im geschäftlichen Verkehr nicht untersagt werden (http://dejure.org/gesetze/MarkenG/23.html). Ich darf den Namen nur nicht für einen anderen Wanderweg verwenden. Ich denke der Knackpunkt ist vielmehr die Urheberschaft für den Wegverlauf: § 59 Werke an öffentlichen Plätzen (1) Zulässig ist, Werke, die sich bleibend an öffentlichen Wegen, Straßen oder Plätzen befinden, mit Mitteln der Malerei oder GRAPHIK, durch Lichtbild oder durch Film zu vervielfältigen, zu verbreiten und öffentlich wiederzugeben. Bei Bauwerken erstrecken sich diese Befugnisse nur auf die äußere Ansicht. Also ausdrucken als GRAPHIK darf ich den Wegverlauf, wenn ich die Wege anhand der Schilder selbst erfasst habe. Datenbanken sind aber nicht ausdrücklich erwähnt. Wahrscheinlich muss das ein Gericht entscheiden. Das könnte kurios werden, weil deutsche Gerichte gedruckte Landkarten als Datenbanken eingestuft haben :-) Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: Darstellung der Wanderwege des Harzklubs im OSM
Hallo, Im übrigen gibt es die Panoramafreiheit. Ein Objekt, dass sich ständig in der Öffentlichkeit befindet, darf von öffentlich zugängigen Plätzen aus abgebildet werden, das musste sich schon die Verwaltung von Potsdam sagen lassen. Das Ablesen und Eintragen der Beschriftung ist eine Form der Abbildung. Das finde ich sehr interessant. Ich habe nämlich bisher noch nichts gefunden, das eine Datenbank als Form der Abbildung erlaubt. In Gesetz steht nur mit Mitteln der Malerei oder Grafik, durch Lichtbild oder durch Film. Kann man eine Datenbank, aus der eine Grafik erstellt wird als Mittel der Grafik ansehen? Gibt es da etwa irgendein Urteil bezüglich Potsdam? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=locality = Flurbezeichnung ?!?
Am 12.09.2012 17:00, schrieb Fabian Patzke: Chris66 wrote [...] Ich schmeisse mal place=land_lot (http://en.wikipedia.org/wiki/Land_lot) oder place=parcel in die Runde. Das land lot entspricht laut Wikipedia unserem Flurstück, die waren früher evtl. mal gleich mit den Gebieten, die bei uns Flurnamen tragen, heute sind es aber in Katastern verwalteten genau festgelegte Gebiete. Das entspricht nicht den lockeren Gebieten mit Flurnamen bei uns. Eine Flur ist im Kataster bei uns kein lockeres Gebiet sondern mit ihren Grenzen wohl definiert. In der amtlichen Gemarkungsübersicht ist genau zu erkennen, welche Flurstücken zu welcher Flur und Gemarkung gehören. Normalerweise ist das etwa so: Das Flurstück ist eine Parzelle oder auch Grundstück, also ein kleines Teilstück einer Flur, das als kleinste Einheit im Kataster geführt wird. Der Eigentümer und andere Rechte in Verbindung mit diesem Flurstück werden im Grundbuch geführt. Die Gemarkung besteht aus mehreren Fluren, die innerhalb der Gemarkung normalerweise durchnummeriert werden. Meist entsprechen die Gemarkungsgrenzen den Grenzen der Ortsteile und heißen auch so. Innerhalb der Grenzen einer Gemeinde gibt es meist mehrere zusammenhängende Gemarkungen, deren Außengrenzen die Gemeindegrenzen bilden. In Ausnahmefällen gehört auch mal eine außerhalb liegende Gemarkung als Enklave zur Gemeinde. Gewanne sind zusammenhängende lang gezogene Bereiche einer Flur, die aus mehreren Flurstücken bestehen. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=locality = Flurbezeichnung ?!?
Hallo, Im Prinzip ist das was hier im Thread mit Flur bezeichnet ist eher ein Gewann, würde ich vermuten. Gibt es jemanden der da einen englischen Begriff für diese Unterteilung kennt? Gewanne hat man (so weit ich weiß) angelegt, damit man auf mehreren zusammenhängenden Feldern zusammenhängend arbeiten und die gleiche Frucht anbauen konnte. Ob sie irgendwo im Kataster noch Bedeutung haben, weiß ich nicht. Die Flurnamen und Gewannnamen in Thüringen jedenfalls nicht. Der Heimatbund Thüringen aber erforscht die historischen Flurnamen und gibt regelmäßig Reporte heraus (http://www.heimatbund-thueringen.de/index.php?id=104). So viel mit bekannt ist, werden dabei diese alten Namen den im Kataster nummerierten Fluren zugeordnet. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=locality = Flurbezeichnung ?!?
Am 12.09.2012 11:29, schrieb Fabian Patzke: Moin, Bernd Wurst wrote Am 12.09.2012 10:51, schrieb Fabian Patzke: wir haben hier bei uns in der Gegend als Alternative Flurnamen mit place = field_name erfasst, damit sie erstmal in der DB sind, aber nicht so prominent erscheinen. Was dann später damit gemacht wird, kann man immer noch sehen ;) Flurnamen zu rendern ist eine gewisse Kunst, denn je nach dem wie groß das Gebiet ist, sollten die kleiner oder größer gerendert werden. Für die Darstellung ist es daher wohl unvermeidlich, zumindest ungefähr die Fläche der Flur zu mappen. place=locality ist mir jedenfalls auch zu prominent dargestellt für einfache Flurnamen, daher finde ich deinen Ansatz besser. Leider gibt es bei uns mehr Wald als Felder und daher widerstrebt mit field_name ein bisschen... :( Jo, das stimmt, aber mit Grenzen bei so schwammigen Regionen tu ich mir irgendwie auch schwer ;) field_name war halt das was wir als Übersetzung für Flurname gefunden haben. Im Niederländischen heißen die auch Veldnamm. Wenn jemand allerdings eine bessere Übersetzung ins Englische hat nur her damit. In England heißt die Flur cadastral section. Ich kriege jedoch beim Gedanken an place=cadastral_section leichte Bauchschmerzen. Wäre nicht besser boundery=cadastral border_type=cadastral_section ? Oder es muss halt ein neuer Schlüssel her. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug auf der Hauptseite (openstreetmap.org). Wer kann das reproduzieren?
Hallo, Tritt das nur bei mir auf, oder haben das andere auch? Tritt bei mir im Heimnetz mit Linux und Firefox nicht auf. Hab jetzt mal im Firmennetz mit squid Proxy unter WIN mit Firefox probiert. Da tritt es gehäuft auf. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger (DVR GS1000 / Tetex 1GP)
Am 23.08.2012 09:42, schrieb qunuxy-osmmailingli...@yahoo.com: Hallo! Am 23.08.2012 03:25, schrieb Johann H. Addicks: Vielleicht kann ja jemand von Euch auf dieser Grundlage das Format enträtseln. Wir haben mehrere Lösungen erarbeitet und vorgeschlagen: http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096027.html http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096035.html http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096038.html http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096042.html http://lists.openstreetmap.org/pipermail/talk-de/2012-June/096047.html Was haben wir vergessen zu enträtseln? Das einzige, was mir noch schleierhaft ist, sind die Beschleunigungsdaten (falls es wirklich welche sind). Die passen noch nicht so ganz. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger (DVR GS1000 / Tetex 1GP)
Am 23.08.2012 12:45, schrieb Paul Hartmann: Am 23. August 2012 12:14 schrieb bkmap burkhard.kirch...@web.de: Am 23.08.2012 09:42, schrieb qunuxy-osmmailingli...@yahoo.com: Das einzige, was mir noch schleierhaft ist, sind die Beschleunigungsdaten (falls es wirklich welche sind). Die passen noch nicht so ganz. In wie fern? Man sieht doch zumindest recht schön die Erdbeschleunigung als Offset und könnte danach dann kalibrieren. Ok, man kann die Werte auf 1g kalibrieren. Trotzdem ist mir nicht ganz klar, woraus die krummen Werte resultieren (ist wohl letzen Endes auch egal :-) . ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falten von Plänen A4
Am 28.06.2012 21:29, schrieb hansdorfff: Hallo, Am 15. Mai 2012 19:18 schrieb Jan Tappenbeck o...@tappenbeck.net: kennt jemand eine gute Falttechnik für Stadtpläne (A4 / A3) die nicht mit irgendwelchen Patenten im Konflikt steht? Falls Du die alte Falttechnik von Falk meinst, das Patent [1] darauf ist schon ein paar Jahrzehnte abgelaufen (siehe z.B. auch [2]). Aber für A4 oder A3 macht das vermutlich gar keinen Sinn. Mir fällt noch Miura Map Fold ein, bin aber uninformiert, was die Patentlastigkeit betrifft: http://lifehacker.com/5888022/the-miura-fold-is-how-youd-fold-a-map-if-you-were-awesome Hier die Liste der Schutzrechte: http://www.miura-ori.com/English/e-Property.html Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger
Am 11.06.2012 23:22, schrieb qunuxy-osmmailingli...@yahoo.com: Am 11.06.2012 15:17, schrieb Steffen Grunewald: So offensichtlich ist das für mich nicht - dann sollte doch nach Pythagoras die Summe der Quadrate der einzelnen Komponenten genau 100 ergeben? Nein, warum? Da aber der eine Wert ziemlich konstant über 1000 liegt, geht das schon mal nicht Wenn du den Beschleunigungssensor auf den Boden legst, so dass eine Achse des Sensors exakt zum Erdmittelpunkt ausgerichtet ist, dann wird dieser für diese Achse (Z) ziemlich genau die Erdbeschleunigung von 1 g anzeigen und für die beiden anderen Achsen (X und Y) 0 g. Wenn du jetzt den Sensor in Richtung der X-Achse beschleunigst, so wird dieser für die Z-Achse weiterhin 1 g anzeigen und zusätzlich für die X-Achse die entsprechende Beschleunigung und für die Y-Achse immer noch 0 g. Jetzt kannst du den Sensor auch noch zusätzlich in Richtung der Y-Achse beschleunigen, dann zeigt der Sensor für die Z-Achse immer noch 1 g an und für die X- und Y-Achse die entsprechenden Beschleunigungen. Erst wenn du den Sensor nach oben oder unten beschleunigst, wird dieser nicht mehr die Erdbeschleunigung anzeigen. Meistens wird der Sensor aber nicht zum Erdmittelpunkt ausgerichtet sein, dann misst der Sensor natürlich auch für die X- bzw. Y-Achse des Sensors Anteile der Erdbeschleunigung, bei den anderen Achsen verhält sich das entsprechend. Wenn man das Gerät mal nacheinander in allen 3 Achsen ausrichtet, kann man wenigstens verifizieren, ob es sich überhaupt um Beschleunigungsdaten handelt. Was die Einheit der Beschleunigung betrifft, kann man milli-g wohl ausschließen. Ich bekomme, wenn ich alle Vektoren summiere auf 1,05802 g. Selbst wenn ich den Wert auf 1024*g normiere, komme ich auf 1,0332 g. Das Erzvorkommen, das unter dem Gerät liegen muss, möchte ich gerne ausbeuten dürfen :-) Aber möglicherweise ist das Gerät auch nicht kalibriert. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger
Am 10.06.2012 10:33, schrieb Paul Hartmann:
Hm, als zusätzliche Schikane scheint der Offset für jede Datei
verschieden zu sein (vergleiche erste Mail). Naheliegenderweise müsste
der Wert im Header kodiert sein:
559683543 = 57
545946117 = 40
Was haben sich die Hersteller hier nur wieder einfallen lassen, um
sicherzustellen, dass der Käufer auch brav die mitgelieferte Software
nutzt?
Das hat nur wirklich Sinn, wenn man dafür extra Kohle verlangt und auch
das ist noch fraglich.
Dieser Variante hier ist die Größe des Offsets egal. Ich gehe davon aus,
dass das drittletzte Zeichen vor dem '\n' immer ein '*' ist:
#include stdio.h
#include stdlib.h
#include string.h
char * convert_line(char * s, int offset) {
int i;
int n = strlen(s);
for (i=0; in; i++) {
s[i] = (s[i] + offset) 0xff;
}
return strchr(s,'$');
}
int main(int argc, char *argv[]) {
int line_buf_len = 1024;
char * line_buf = malloc(line_buf_len);
if (NULL==line_buf) {
printf(can't allocate memory\n);
exit(1);
}
if (argc != 2) {
printf(usage: %s filename\n, argv[0]);
exit(1);
} else {
FILE *file = fopen(argv[1], r);
if (file == NULL) {
printf(Could not open file\n);
exit(1);
} else {
int a = 0; /* erste Zeile */
int offset = 0;
char * p_nmea=NULL;
while (NULL!=fgets(line_buf, line_buf_len, file)) {
int l = strlen(line_buf);
line_buf[l-1]=0;
if (a){ // erst ab 2. Zeile
if (1==a) { // nur in 2. Zeile
offset = '*'-line_buf[l-4]; // das 3t-letzte Zeichen sollte ein
'*' sein.
}
p_nmea = convert_line(line_buf, offset);
if (p_nmea) {
printf(%s\n, p_nmea);
}
}
a++;
}
fclose(file);
}
}
free(line_buf);
return 0;
}
Viele Grüße
Burkhard
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger
Am 11.06.2012 01:58, schrieb qunuxy-osmmailingli...@yahoo.com:
Dieser Variante hier ist die Größe des Offsets egal.
Meinst du damit z.B. 57 + 1024 oder 57 - 1024?
Mit dieser Version sollte das ebenfalls funktionieren:
ok, die Version war bei mir noch nicht angekommen. Da hätte ich mir das
Posten sparen können :-)
Burkhard
#includestdlib.h
#includestdio.h
int main (int argc, char *argv[])
{
if (argc != 2)
{
printf(usage: %s filename\n, argv[0]);
exit(1);
}
else
{
FILE *file = fopen(argv[1],r);
if (file == NULL)
{
printf(Could not open file\n);
exit(1);
}
else
{
int start = 0;
int detect = 0;
int c = 0;
long int pos = 0;
int offset = 0;
while ((c = fgetc(file)) != EOF)
{
if (c == '\n')
{
if(start)
{
printf(\n);
}
else
{
start = 1;
}
}
else
{
if(start)
{
if(detect)
{
c+=offset;
printf(%c,c);
}
else
{
pos = ftell(file);
while ((c = fgetc(file)) != EOF)
{
if (c == '\n')
{
fseek(file,-4,SEEK_CUR);
offset = '*' - fgetc(file);
detect = 1;
break;
}
}
fseek(file,pos-1,SEEK_SET);
}
}
}
}
fclose(file);
}
}
return 0;
}
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unbekanntes Datenformat aus GPS-Logger
Hallo, Falls jemand Interesse hat, ich lege gerne mal ein Tacklock in die Dropbox. http://dl.dropbox.com/u/42317300/GS1000-GPSLOG.FILE0001.dat Sind das die echten Binärdaten oder ist das eventuell vom Terminal kopiert? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hallo, eine schöne Sache ist das geworden. Bei surface würde ich mir noch die Möglichkeit wünschen, weitere Werte einzugeben. +1 Ja, ist toll geworden. Hab schon Wege bei mir gefunden, die ich ergänzen muss. Für die Liste würde ich vorschlagen: artificial_turf, asphalt, cobblestone, compacted, concrete, concrete:lanes, concrete:plates, fine_gravel, grass, grass_paver, gravel, ground, metal, mud, paving_stones, pebblestone, sand, tartan, wood, clay Nach meiner Meinung sind die Werte paved und unpaved sehr grob und man sollte sie lieber weglassen, wenn man keine genaueren Daten hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Hallo, Hab schon Wege bei mir gefunden, die ich ergänzen muss. Für die Liste würde ich vorschlagen: artificial_turf, asphalt, cobblestone, compacted, concrete, concrete:lanes, concrete:plates, fine_gravel, grass, grass_paver, gravel, ground, metal, mud, paving_stones, pebblestone, sand, tartan, wood, clay Ok, ich habe die Liste nochmals erweitert. http://tracks.osmsurround.org/ Die in meiner Region auf Waldwegen am häufigsten vorkommenden Oberflächen ground und compacted (Makadamdecke) sind leider noch nicht dabei. Da nuss ich weiterhin JOSM starten, um etwas auszurichten. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Am 31.05.2012 11:16, schrieb Martin Koppenhoefer: Am 31. Mai 2012 11:10 schrieb bkmapburkhard.kirch...@web.de: Die in meiner Region auf Waldwegen am häufigsten vorkommenden Oberflächen ground und compacted (Makadamdecke) sind leider noch nicht dabei. Da nuss ich weiterhin JOSM starten, um etwas auszurichten. ground (auch wenn ich gestehe dass ich das selbst auch schon genutzt habe) ist nicht besonders aussagekräftig, weil das im Prinzip fast alles sein kann (ausser Gras, Schotter und befestigt), also von weichem Waldboden bis zu Fels. -1 Wenn es kein Gras ist, ist Erde bei uns relativ selten. Meist ist es natürlicher Schieferschotter mit wenig Lehm oder Erde dazwischen, stellenweise auch massivere Schieferplatten. Das ist garantiert keine Erde. Direkt im Wald ist es dann oft Waldboden aus Fichtennadeln, verrottenden Holzstücken und Baumwurzeln dazwischen. Das ist auch keine Erde. Bleibt als Tag ground oder man muss neue Tags erfinden. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks Selector wird zum Editor
Am 31.05.2012 16:31, schrieb BBO: Hallo aighes-2 wrote Am 31.05.2012 13:24, schrieb bkmap: Wenn es kein Gras ist, ist Erde bei uns relativ selten. Meist ist es natürlicher Schieferschotter mit wenig Lehm oder Erde dazwischen, stellenweise auch massivere Schieferplatten. Das ist garantiert keine Erde. Direkt im Wald ist es dann oft Waldboden aus Fichtennadeln, verrottenden Holzstücken und Baumwurzeln dazwischen. Das ist auch keine Erde. Bleibt als Tag ground oder man muss neue Tags erfinden. Dann wäre letzteres doch eine sinnvolle Maßnahme. Zwischen Fichtennadel, Laub und Schiefer gibt es doch schon einen gewissen Unterschied, den man auch erfassen sollte. ;-) Wie ich das von hier kenne ist das meist auf einem Weg bunt gemischt. Mal ein paar cm anliegender Fels, ein paar Meter Erde/Nadeln von Wurzeln durchzogen, ein paar Meter ein Gemisch aus Erde und Steinen. Das ganze noch teils in der einen Spurrille anders als in der andern. Bisher ging ich davon das ground für genau solche Fälle gedacht ist (ich habe es so verwendet). Wie würdet ihr das taggen? Benutzt ihr ground für alle natürlichen Oberflächen? Ja, außer es ist wirklich sichtbar Erde, Gras, Kies, Sand oder... Man könnte alles noch weiter differenzieren, aber jede Oberflächenart zu mappen halte ich für übertrieben. Genauso, wie ground verschiedenartig sein kann, ist mud auch nicht immer gleich mud. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - freie Geodaten; Frage falsch verstanden?
Am 12.04.2012 12:23, schrieb Peter Wendorff: Am 12.04.2012 10:55, schrieb Jan Tappenbeck: Hi ! ich glaube meine Frage wurde etwas falsch verstanden. Es geht darum das es Leute gibt die sagen meine Hausnummer soll aber nicht ins Internet - die Grundlage für die Freiheit der Geodaten suche ich. Das ist ein anderes Thema. Die von dir angesprochenen Bedenken meine Hausnummer soll nicht ins Internet gehen in Richtung des Datenschutzes. Datenschutz bezieht sich aber auf persönliche bzw. personenbezogene Daten. Dazu besagt das Datenschutzgesetz (§3, Abs. 1) Personenbezogene Daten sind Einzelangaben über persönliche oder sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person. Knackpunkt ist damit also, ob die betroffene Person bestimmbar oder bestimmt ist. Für Google StreetView gibt es wohl Urteile, dass es sich auch bei der Hausnummer um ein personenbezogenes Datum handeln könne, aber wenn man bedenkt, das Hausnummern durchaus veröffentlicht werden, sowohl von den klassischen kommerziellen Datenanbietern (NavTec, Teleatlas, Behörden) als auch in Karten (Falk etc.), dann vermute ich, dass es sich dabei so nicht um personenbezogene Daten handeln dürfte. Das Urteil vom Landgericht Köln 28 O 578/09 geht sogar noch weiter. Es lässt sogar Fotos zu, die in Zusammenhang mit der Adresse veröffentlicht wurden. Natürlich ohne Verknüpfung mit den Namen der Mieter oder Eigentümer. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slovenien_2_ Karte verschoben?
Am 07.04.2012 17:44, schrieb Martin Koppenhoefer: ja, wenn man sich auskennt kann man immer wesentlich besser und zuverlässiger kartieren, als wenn man Bilder einer Gegend interpretiert, die man nicht kennt. Man kann ja mit Ortskenntnis auch alles das Anhand von Luftbildern einzeichnen, was man auf dem Bild an sich gar nicht erkennen kann. Ohne Ortskenntnis verkneife ich mir Edits nach BING. Auch mit Ortskenntnis ziehe ich es vor, Fotos zu machen. Außerdem ist es sehr sinnvoll, immer brauchbare GPS-Tracks zu haben. Bevor man nach BING editiert, sollte man die BING-Bilder mindestens nach eigenen oder von Usern hoch geladenen GPS-Tracks oder anderen halbwegs zuverlässigen Marken ausrichten. Ich habe in bergigem Gelände schon Änderungen im Versatz der BING-Bilder von 30 m auf einer Strecke von nur 200 m vorgefunden. Auf der ebenen Fläche ist das nicht so krass. Als Gedankenstütze, zur Kontrolle und zum Erfassen von Konturen und kurzen fehlenden Wegstücken finde ich BING sehr sinnvoll. Aber man sollte immer wieder die Richtigkeit bezüglich Aktualität und Lage kontrollieren. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen in OSM
Am 04.04.2012 08:04, schrieb Andre Joost: Am 04.04.12 01:58, schrieb Garry: Am 03.04.2012 17:05, schrieb Andreas Neumann: STOP! Ich weiß, jeder darf alles mappen, was er für würdig hält, aber hier sind wir an einen Punkt angelangt, der weder auf Dauer wartbar ist, noch in der Fläche realisierbar wird. Bei solch fluktuierenden Daten sollten wir uns überlegen, eher die Verkehrsverbände drauf zu drängen, dass die ihre Daten maschinenlesbar zur Verfügung stellen und wir nur noch eine ID an die Linie packen. Ansonsten wäre es reiner Wahnsinn. +1 Der Aufwand die Daten in OSM zu erfassen ist viel zu hoch dafür nur um Demo-Anwendungen damit zu füttern die zeigen was man alles tolles mit den Daten machen könnte, sowas hier z.B.: http://www.openstreetmap.org/browse/relation/403713 (Es gibt auch eine Relation für Normalsterbliche) aber kaum jemals so weit kommen wird daraus eine annähernd zuverlässige Anwendung zu machen. +1 Ein brauchbarer ÖPNV-Router kommt ohne Fahrplandaten und Echtzeitinformationen nicht aus. Wir liefern allenfalls Geodaten, also: +1 Es gibt ein länderübergreifenden Projekt, an dem schon mehrere Bundesländer teilnehmen und das europaweit ausgedehnt werden soll. Hab keine Ahnung, unter welcher Lizenz das Projekt und die Implementierungen stehen: www.delfi.de/ Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreatives Mapping von Wald_Flurstücken
Hallo, hab ich irgendws verpasst? Ich war immer der Meinung, dass Landuse erst mal nichts mit den ADMINISTRATIVEN Flächen wie Grundstück, Flurstück, Gemarkung und Flur zu tun hat. IMO haben wir dafür noch gar keine Tags. Da gab es schon mal eine ähnliche Diskussion in Zusammenhang mit Stadtvierteln und landuse. Am 6. März 2012 18:51 schrieb Falk Zscheilefalk.zsche...@googlemail.com: Laut wiki ist place=locality auch für Flächen möglich. Wäre das nicht das Richtige für solche Flurbezeichnungen? Das sehe ich auch so. Wenn man die Grenzen eines Flur-/Gewannnamens kennt, dann sollte man dies auch als Multipolygon eintragen. +1. Wenn man allerdings genau weiss, um was es sich handelt (Flur, Gewann, Gemarkung,) ẃäre ein Zusatztag nicht schlecht. place=locality wird für alle möglichen Toponyme die nicht einen bewohnten Ort darstellen verwendet. place=locality ist in Ordnung für einen Ort oder eine Area, die nicht von Menschen bewohnt wird. Das hat aber in erster Linie nichts mit Grundstück, Flurstück, Gemarkung und Flur zu tun. Wenn wir sowas einarbeiten wollen, dann mit einem dafür geeigneten Schema. Am besten eins, das nicht nur für Deutschland passt. Dazu fallen mir aber gleich mal 2 Fragen ein: 1. Hat schon jemand so ein Schema angedacht? 2. Wo genau wollen wir dann die Daten herbekommen, wenn wir nicht vom Kataster abschreiben wollen. 3. Wollen wir das überhaupt in OSM erfassen, oder überlassen wir das lieber den Kataster- und Liegenschaftsämtern? Ich denke, wir sollten, mit wenigen Ausnahmen, haupsächlich das mappen, was man draußen sieht und nicht was in amtlichen Dokumenten steht. Das heißt, ich mappe dort wald, wo ich weilchen sehe. Wenn es für irgendeine Gegend einen Namen gibt, dann trage ich sie als locality ein, egal ob diese Gegend mit irgenwelchem landuse=* zusammenfällt. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreatives Mapping von Wald_Flurstücken
Am 08.03.2012 09:34, schrieb Falk Zscheile: Am 8. März 2012 09:13 schrieb bkmapburkhard.kirch...@web.de: hab ich irgendws verpasst? Möglicherweise ;-) Ich war immer der Meinung, dass Landuse erst mal nichts mit den ADMINISTRATIVEN Flächen wie Grundstück, Flurstück, Gemarkung und Flur zu tun hat. IMO haben wir dafür noch gar keine Tags. Darum ging es nicht. Es ging nur um die Bezeichnung von Landschaftsbestandteilen, jenseits der Zahlenbezeichnung von Flur und Flurstück. Doch: ..Wenn man die Grenzen eines Flur-/Gewannnamens kennt... Ich tue mich hier in der Diskussion etwas schwer mit den Begriffen Flur und Gewann. Das sind Begriife aus der Liegenschaftsverwaltung. Und nicht erst seit gestern, sonder schon seit dem Mittelalter, als man begann alles aufzuschreiben:-) (Und vorher bezeichnete man als Flur auch meist nur das was kein Wald war :-) ) Flure als Landschaftsbestandteile haben zum Teil auch Landschaftsbestandteil oder Örtichkeit ja, aber Flur nein. richtige Namen und die tragen wir meine Meinung nach in die Datenbank ein und taggen das Ganze mit place=locality bzw. geben wir der entsprechenden landuse-Fläche den Namen. Wenn der Wald Auenwald, Schwarzes Holz oder so heißt und dann noch zufällig mit der Landuse-Fläche übereinstimmt, gerne. Ich denke aber das ist überflüssig, denn man kann der Waldfläche gleich einen Namen geben. Genauso kann man einer Wiese einen Namen geben ohne place=locality. place=locality kann, aber muss micht mit Fläche landuse=* zusammenfallen. Welche Fälle erfasst place=locality deine Meinung nach? Laut Wiki Örtichkeiten, die einen Namen haben, aber keine Siedlung sind. z.B.: Eulenwinkel, Bärental, Hexenmoor, Waldfrieden für Örtlichkeiten, die irgendo in der Pampa liegen. Man kann einen Punkt eintragen oder eine Fläche irgendwo im Gelände. Landnutzungsgrenzen spielen dabei keine Rolle. Ich interpetiere das so, dass Gewann Irgendwo, Flur Dingsbumshausen oder Gemarkung Einstedt nicht dazu gehören. Das sind Liegenschaftsangaben. Da gab es schon mal eine ähnliche Diskussion in Zusammenhang mit Stadtvierteln und landuse. Mag sein. Kannst Du den Streitstand kurz skizzieren? So kann ich nicht sagen, ob das Problem dort gleich gelagert war :-) Da ging es um einzelne Grundstücke, die mit landuse erfasst worden sind. Da wurden auch die Begriffe Parzelle und Landnutzung vermicht. Auch um die Landnutzungsgrenzen und die Stadtbezirks- und andere Verwaltungsgrenzen ging es. Fallen die zusammen oder muss das nicht so sein? Im Wesentlichen drehte sich die Diskussion um die Vermischung des Taggings von Verwaltungseinheiten und Landnutzung. Wenn hier mit Flur nicht die Verwaltungseinheit gemeint ist, trifft das jedoch hier nicht zu. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreatives Mapping von Wald_Flurstücken
Oben wurde bereits die Möglichkeit dargelegt, dass man den Wald in seine Einzelteile zerlegen könnte, mit den einzelnen Waldteilen. Diese werden jeweils mit Landuse und Namen versehen und das Ganze über eine Relation zum Gesamtwald und Gesamtwaldnamen zusammengefasst. Wäre es eine Alternative den Gesamtwald/Gesamtwaldnamen als einheitliche Fläche zu belassen und in den Wald Polygone mit place=locality zu malen, um die Teilstücke zu benennen? Was denkt ihr? Was spricht dagegen? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sportplatz
Am 27.02.2012 09:56, schrieb Manuel Reimer: tumsitumsiat gmx.de writes: Am 24. Februar 2012 17:25 schrieb Wolfgangwolfgangat ivkasogis.de: Was man ggf. brauchen könnte wäre ein weiterer spezifischer Wert. sports_facility passt da ganz gut für was kleineres als ein Sportzentrum +1 Tagwatch kennt zumindest in DE kein sports_facility. Ohne Diskussion würde ich hier nichts neues einführen. Wird dann auch nicht gerendert! Zumindest eine Doku (siehe mein letztes Posting) kennt für Sporthalle auch sports_centre. Wenn es um eine Schießsportanlage geht, gibt es ein Wiki: http://wiki.openstreetmap.org/wiki/DE:Tag:sport%3Dshooting Ich denke aber nicht, dass dies der Weisheit letzer Schluss ist. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten
Am 22.02.2012 16:18, schrieb Tobias Knerr: Am 22.02.2012 15:58, schrieb tumsi: gibt schon ein Schema oder Proposal für das Eintragen von Tageszeitabhängigen Geschwindigkeiten? Bisher habe ich nur dies gefunden. http://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed [...] Also ziemlich viel Wildwuchs, weswegen hier wohl mal ein ordentliches Proposal angebracht wäre. Ein Proposal gibt's schon: http://wiki.osm.org/Proposed_features/Extended_conditions_for_access_tags Das wäre dann die Variante maxspeed:(08:00-18:00) = 50 Das Proposal ist sehr allgemein gehalten, so dass man auch andere Attribute tageszeit-abhängig gestalten kann. Beispielsweise gibt es ja Dinge wie Lieferverkehr zwischen 6 und 10 Uhr frei oder zeitabhängige Einbahnstraßen. Außerdem kann man damit auch witterungsabhängige Maxspeeds (80 km/h bei Nässe) abbilden. Nur habe ich das aus zwei Gründen nicht mehr weiter verfolgt: Der erste ist, dass es viel Gegenwind wegen der Verwendung von Sonderzeichen in Schlüsseln gab. Der zweite ist das Fehlen jeglichen Engagements von Seiten derjenigen Entwickler, für die dieses Thema relevant wäre. Ich finde diesen Vorschlag ziemlich gut. Schade, dass die Diskussion im Sande verlaufen ist. Wie wäre es, wenn Du die Sache wieder aufwärmst? Das Hauptargument dagegen waren die Sonderzeichen im Schlüssel. Der Vorschlag von Eimai, der Sonderzeichen im Key vermeidet, war doch gar nicht so schlecht: Move parameters from key to value key=[condition]value;[condition]value... Das wäre dann: maxspeed = [08:00-18:00]50 Er hat die Conditions in [] gesetzt. Möglich wäre vielleicht auch: key=condition:value[;condition:value]...[;condition:value] maxspeed = (08:00-18:00):50 Ich finde persönlich die Variante mit [] besser, weil sie mehr Spielraum für Verknüpfungen hergibt. Wäre mal ein Ansatz für eine einheitliche Syntax für Bedingungen. [condition][condition] wäre dann eine logische UND-Verknüpfung Da das Komma für logische ODER-Verknüfungen bereits verwendet wird könnte man mit [condition],[condition] eine ODER-Verknüpfung realisieren. Selbst komplexe Bedingungen ließen sich damit konstruieren: [[condition],[condition]][[condition],[condition]] z.B. [[psv],[tourist_bus]][maxheight2.5][maxweight7] Solange es keine Software gibt, die z.B. zeitabhängiges Routing durchführen kann, wird ohnehin kein Taggingschema als wirklich etabliert gelten können. Solange es kein vernünftiges Schema für Bedingungen gibt, weiß keiner, wonach er sich richten soll. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten
Am 23.02.2012 12:29, schrieb Martin Koppenhoefer: Am 23. Februar 2012 12:15 schrieb bkmapburkhard.kirch...@web.de: Der Vorschlag von Eimai, der Sonderzeichen im Key vermeidet, war doch gar nicht so schlecht: Move parameters from key to value key=[condition]value;[condition]value... Das wäre dann: maxspeed = [08:00-18:00]50 Er hat die Conditions in [] gesetzt. Das benötigt dann halt multiple values, weil man meistens ja auch noch die verbleibende Zeit von 18-8 h angeben will. +1 maxspeed = 80;[08:00-18:00]50 allgemein 80 8-18 Uhr 50 oder wenns komplizierter wird: maxspeed = 80;[hgv]60;[hgv][Mo-Fr 08:00-18:00]30;[08:00-18:00]50 allgemein 80 LKW 60 LkW Mo-Fr 8-18 Uhr 30 andere von 8-18 Uhr 50 Ich finde den Vorschlag gut, 1. weil man diese Bedingungen fast überall in gleicher Form anwenden kann, nicht nur bei maxspeed, 2. weil wenn in den [] stehenden Tooken auf bekannte Condition Codes geprüft wurden, den gleichen Algorithmus verwenden kann, wie bei den Öffnungszeiten. Conditions könnten z.B. sein: [bus], [hgv], [maxweight7] oder andere. Wenn keiner dieser Codes ausgewertet werden konnte, ist es eben eine Zeitbedingung wie in den Öffnungszeiten, das da in den Klammern steht. Mit Komma verknüpft man die Bedingungen als logisches ODER und ohne Komma als logisches UND. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten
Wie wäre es mit: maxspeed = 80 maxspeed:conditions = [08:00-18:00]50 Also ein default-Wert für alle dummen Anwendungen und eine Verfeinerung für neue Anwendungen, welche die conditions auswerten können. +1 Neben der Uhrzeit könnten da auch andere Bedingungen genannt sein. Spontan fällt mir neben Nässe auch noch an Schultagen ein. Henning +1 An Schultagen gibt es in den opening_hours schon: SH off Das Schema für opening_hours könnte man komplett mit verwenden. Hab mal diesen Vorschlag überflogen: https://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Namespace Der ist gut strukturiert. Mit scheint diese Namespace-Variante aber recht kompliziert für den Otto-Normal-Mapper. Ich denke die Eimai-Variante ist da einfacher und übersichtlicher. Wenn man Vergleiche zulässt, kann man beliebig mit UND, ODER und NOT verknüpfen. Man kann das auch für beliebige andere Tags verwenden. Beispiele: maxspeed=60 maxspeed:conditions=[bus]50;[bus][Mo-Fr 09:00-18:00; SH off]30 Busse dürfen an Wochentagen außer in den Schulferien von 9-18 Uhr nur 30 fahren, sonst 50. Ansonsten darf 60 gefahren werden. [bus] ist das Gleiche wie [bus=yes] maxweight=5.5 maxweight.conditions=[bus] oder maxweight.conditions=[bus]void oder auch maxweight.conditions=[bus]none Bis 5.5 t außer Busse. [bus=no] gilt für alles, was kein Bus ist. [[[bus],[bycycle]]=no] ist das Gleiche wie [bus=no][bycycle=no] und gilt für alles außer Bus und Fahrrad Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 22.02.2012 13:11, schrieb Martin Koppenhoefer: Am 22. Februar 2012 08:37 schrieb bkmapburkhard.kirch...@web.de: Man sollte den Punkt imo aber trotzdem an einer Stelle platzieren, an der wahrscheinlich auch eingestiegen werden kann. Im Wiki steht dazu, dass die stop_position mit einer platform verknüpft werden soll, von der aus eingestiegen werden kann. Das gibt dann zusammen mit anderen Objekten eine public_transport=stop_area. Ja, versteht sich. Das sollte unbedingt so sein. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 21.02.2012 11:19, schrieb Martin Koppenhoefer: Am 21. Februar 2012 08:20 schrieb bkmapburkhard.kirch...@web.de: Na dann sollten wir die Halteposition eben so kennzeichnen, dass da mit hoher Sicherheit ein Einstieg ist. Übrigens hab ich das bisher auch immer so gehalten. Ich fahre ja schließlich auch als Fahrgast und nicht als Lockführer. Du wirst dann aber vermutlich auch gar nicht an der stop position des Zugs interessiert sein, sondern am Bahnsteig der zu dem Gleis gehört, wo Dein Zug abfährt oder ankommt. Es gibt aber auch andere Nutzungen von OSM Daten. Diese Stop-position-Details bei Bahnhöfen sind m.E. eher für Simulationsbetreiber und Pufferküsser relevant, als für Fahrgäste. Oft gibt es ja auch noch mehrere davon (abhängig von der Zuglänge). OK - das ist richtig. Von der S-Bahn kenne ich Kurzzüge, Vollzüge und Langzüge. Da sind 1 bis 3 Teile zusammengekoppelt. Da wird die Halteposition meist an der Tafel angezeigt: - Bahnsteigbeginn - Der letzte Wagen hält am Bahnsteigbeginn - Bahnsteigmitte - Die Zugmitte hält in der Bahnsteigmitte - Bahnsteigende - Der erste Wagen hält am Bahnsteigende. Mal weiter spinnen... Wenn man die Länge des Zuges und die Art der Halteposition (beginn|mitte|ende) laut Fahrplan kennt, kann man anhand der Plattformgeometrie den Bereich der Plattform ermitteln, neben dem der Zug hält. Also alles an der Plattform gemessen und nicht am Haltepunkt. public_transport=stop_position ist dann, zusammen mit der Relation, nur für den Datenbezug zwischen Fußgängerbereich und Bahnstrecke ausschlaggebend. Die Position (beginn|mitte|ende) kann nicht in der OSM-Datenbank stehen. Das macht keinen Sinn. Die müsste schon in der Datenbank mit den Fahrplaninformationen stehen. Der Zugtyp (kurz|voll|lang) sollte auch im Fahrplan stehen. Gegebenenfalls könnten die Längen der Züge je Zugtyp im OSM stehen, aber imo sind die Zuglängen ebenfalls besser im Fahrplan oder in Zusatzdaten zum Fahrplan aufgehoben. Die können sich ja kurzzeitig ändern. Für andere Bahnstrecken ist das, so viel ich weiß, nicht viel anders. Alles zusammen betrachtet gibt es demnach für mich keinen Grund, zusätzliche Haltemarkierungen in OSM zu erfassen. Für wichtig halte ich die eindeutige Erfassung der Namen und der Referenzen der Haltebereiche, damit der richtige Fahrplan und anhand der Zeittabelle der richtige Zug gefunden werden kann. Alle weiteren Informationen gehören zum Zug. Länge, Wagenstand und was man sonst noch will. So, Ihr könnt jetzt mal weiter spinnen... Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 22.02.2012 00:51, schrieb Garry: Am 21.02.2012 08:20, schrieb bkmap: Am 21.02.2012 00:46, schrieb Garry: Am 20.02.2012 11:45, schrieb bkmap: Am 17.02.2012 18:01, schrieb Roland Olbricht: Stationen sollte grundsätzlich nicht auf Gleisen liegen. Das Wiki ist da etwas missverständlich. Im Idealfall gibt es pro Gleis einen Bahnsteig. Wenn keine Bahnsteige erfasst sind, ist eine einzelne Node railway=station abseits der Gleise das Beste. public_transport=stop_position ist ganz falsch und sollte nur aus Kompatibilitätsgründen verwendet werden. public_transport=stop_position sollte laut Wiki ursprünglich den Ort kennzeichnen, an dem die Fahrzeugspitze hält. Wo steht das mit der Fahrzeugspitze? Und wie kann public_transport=stop_position ganz falsch sein??? Bei der Bahn ist es üblich die Haltepositionen für die Fahrzeugspitze anzugeben da dort derjenige sitzt der die Postion einzuhalten hat. Wichtig ist nicht, was bei der Bahn üblich, sondern was Konsens bei OSM und sinnvoll ist. Der Lockführer wird sich wohl kaum nach der Halteposition bei OSM richten. Ob und wer diese Haltepunkte einträgt und wer sie anwendet ist ein anderes Thema, es sind zumindest reale, verifizierbare Daten die sich für einen Eintrag eignen Ein frei definierter Begriff/Punkt stop_position der nur ein Hilfsmittel für den Router ist (vergleichbar mit den auch ehr unerwünschenten highway-Hilfslinien die einen Router über frei Plätze dirigieren sollen) schafft hier Verwirrung. Besser wäre sowas wie routing_gateway wenn man tatsächlich für Routing-Zwecke nicht auf so einen Punkt verzichten kann. Es sollte auf jeden Fall verhindert werden dass seh- und gehbehinderte Menschen im guten Glauben an eine zum Einsteigen für sie ungeeignete Postion geführt werden. Na dann sollten wir die Halteposition eben so kennzeichnen, dass da mit hoher Sicherheit ein Einstieg ist. ...so eine mehr oder weniger willkürlich gewählter Einstiegspunkt gibt es in der Realität nicht und sind reine Hilfspunkte für Router mit zweifelhaftem Sinn. Letztlich erfährt man erst vor Ort an welchem Punkt bzw. besser in welchem Bereich man tatsächlich in den geeigneten Zug steigen kann. Gleisänderungen, Ersatzzug, Schienenersatzverkehr etc, sind relativ häufig so dass ein scheinbar präziser Einstiegspunkt eine trügerische Sicherheit gibt. Die Angabe des Bahnsteigs ist hier genügend genau. Das haben wir doch mit dem Tagen des Bahnsteigs. Übrigens hab ich das bisher auch immer so gehalten. Ich fahre ja schließlich auch als Fahrgast und nicht als Lockführer. Als Fahrgast interessiert mich zunächst wie komme ich zum Bahnhof/Haltestelle und anschliessend wo ist der Bahnsteig an dem mein Zug fährt. Ich glaube Du hältst hier zu sehr an dem Begriff stop_position fest. Vielleicht sollte man dessen Bedeutung und die der Relationen mal etwas genauer beschreiben. Mit 75726 Haltepunkten im OSM ist er schon etabliert. Ich nehme es so hin, genauso wie ein highway=steps kein highway sein kann :-) public_transport=stop_position ist, zusammen mit der Relation, nur für den DATENBEZUG zwischen Fußgängerbereich/Plattform und Bahnstrecke ausschlaggebend. Sie sagt nichts weiter aus, als dass die PLATTFORM/Bahnsteig zu DEM GLEIS gehört, auf dem der Punkt stop_position liegt und das Transportmittel ungefähr dort anhält. Das ist eine wichtige Information für viele Anwendungen und besser als die Annahme, dass das Gleis oder die Straße nahe bei der Plattform zur Plattform gehört. Ich halte diese Information nicht für überflüssig, genausowenig wie die relation, die alles zusammenfügt. Wer public_transport=platform (also das Schema) verwendet, sollte sich bemühen, auch die anderen Regeln dieses Schemas einzuhalten, die damit verbunden sind. Man sollte den Punkt imo aber trotzdem an einer Stelle platzieren, an der wahrscheinlich auch eingestiegen werden kann. Mit Platzkarte zusätzlich wo kommt mein Wagen zum stehen. Ansonsten versuche ich Menschentrauben zu meiden (die Du unter Umständen auch gerade mit Deiner Halteposition vielleicht zukünftig provozierst) und dort einzusteigen wo am wenigsten los ist. Wer ein wagengenaues Routing möchte, braucht ohnehin mehr Daten als in OSM zu erfassen sind. Er braucht zusätzlich zur Geometrie des Bahnsteiges die Informationen im Fahrplan und zugehörige Daten. Er braucht die Zugnummer und Informationen zum Zug wie die Zuglänge, den zugehörigen Wagenstand und was auch immer noch wichtig erscheint (Platznummern zum Wagenstand). Noch kurz zur Info: Ich war weder am Wiki noch an der Entwicklung des Schemas beteiligt. Ich habe beides nur verfolgt und verwende es. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
Am 19.02.2012 16:57, schrieb Simon Poole: Bezüglich den grössten deutschen Mappern kann ich noch folgendes sagen, es hat einen sehr hohen (ca. 50%) Rate von Bounces (also Mail aus irgendwelchen Gründen nicht zustellbar). EIne Grössenordnung mehr als in anderen Ländern. Das ganze ist also schon recht abgearbeitet, es hat aber wohl noch -viele- kleinere Mapper (mit weniger als 100 erstellten highways nach meinen Listen), die man vermutlich erreichen kann. Wenn das Mapper sind, die in jeweils einem eng begrenzten Gebiet an die 100 1st-Edits von Highways haben, kommt das in dieser kleinen Region einem Kahlschlag gleich. Viele kleine Kahlschläge richten auch großen Schaden an. Deshalb kann man die kleinen Unentschlossenen nicht vernachlässigen. Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 17.02.2012 18:01, schrieb Roland Olbricht: Stationen sollte grundsätzlich nicht auf Gleisen liegen. Das Wiki ist da etwas missverständlich. Im Idealfall gibt es pro Gleis einen Bahnsteig. Wenn keine Bahnsteige erfasst sind, ist eine einzelne Node railway=station abseits der Gleise das Beste. public_transport=stop_position ist ganz falsch und sollte nur aus Kompatibilitätsgründen verwendet werden. public_transport=stop_position sollte laut Wiki ursprünglich den Ort kennzeichnen, an dem die Fahrzeugspitze hält. Wo steht das mit der Fahrzeugspitze? Und wie kann public_transport=stop_position ganz falsch sein??? Das Schema für den Öffentlichen Nahverkehr (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) ist nicht aus einer Laune heraus entstanden. Es gab ein Proposal, eine sehr ausführliche Diskussion und es wurde darüber abgestimmt (Status: Approved (active)). Ich persönlich werde mich so gut es geht an dieses Schema halten, da ich kein besseres kenne. Die Nahverkehrskarten und Router werden sich nach diesen Vorgaben richten. Der Punkt public_transport=stop_position gehört auf das Gleis!!! (The stop position is the place where the vehicle usually stops on the rails or on the street. A public_transport=stop_position is tagged as a Node on the way, even when a bus stops in a bus bay.) Die Halteposition ist verknüpft mit dem Haltestellennamen und dem Referenznamen. Aus diesen Namen und den Relationen, in denen die stop_position enthalten ist, können z.B. die aktuellen Fahrplaninformationen extern ermittelt werden. Das ist für alle ernsthaften ÖPNV-Anwendungen und für Router von großer Bedeutung. Falls Du Vorschläge für Verbesserungen, Änderungen oder Ergänzungen dazu hast, dann schreibe bitte ein Proposal, wie man das Schema ergänzen kann. Wir diskutieren es gerne. In größeren Bahnhöfen kann das wegen unterschiedlicher Fahrzeuglängen natürlich nicht funktionieren. Heute wird das Tag meistens irgendwo auf dem Gleis plaziert und suggeriert dann eine nicht gegebene Genauigkeit - Tags mit zwei verschiedenen Bedeutungen sind immer sehr problematisch. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 20.02.2012 12:08, schrieb Frederik Ramm: Hallo, On 02/20/2012 11:45 AM, bkmap wrote: Das Schema für den Öffentlichen Nahverkehr (http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) ist nicht aus einer Laune heraus entstanden. Es gab ein Proposal, eine sehr ausführliche Diskussion und es wurde darüber abgestimmt (Status: Approved (active)). Mit den Stimmen von ca 80 von ungefaehr 50.000 aktiven Mappern. Was nicht mehr oder weniger bedeutet als wir 80 finden das gut und werden das so anwenden. Ja genau, und 6 von ca. 50.000 lehnen es ab und 3 mögen es nicht, was also nicht mehr oder weniger bedeutet als: Wir 9 von ca 50.000 wollen das nicht und werden es nicht benutzen... :-) Das ist fuer die verbleibenden 49.920 aktiven Mapper natuerlich ein Indikator - wenn sich da 80 Leute Gedanken gemacht haben und ein bestimmtes Schema gut finden, dann koennte ich das ja auch so machen. Muss ich aber nicht. Die Nahverkehrskarten und Router werden sich nach diesen Vorgaben richten. Das bleibt wohl den Machern der Nahverkehrskarten ueberlassen. Der Transport-Layer auf www.openstreetmap.org scheint sich zum Beispiel nicht an das Schema zu halten; eine Bushaltestelle, die ausschliesslich als public_transport=stop_position, bus=yes getaggt ist, wird dort nicht gezeigt (z.B. http://www.openstreetmap.org/?lat=43.6278lon=7.095558zoom=18layers=T); nur, wenn zusaetzlich das alte highway=bus_stop gesetzt wird, passiert was. Stimmt, auch die anderen gängigen Karten halten das derzeit auch so: http://www.öpnvkarte.de/?zoom=17lat=43.6278lon=7.09556layers=B http://www.openptmap.org/?zoom=17lat=43.62799lon=7.09593layers=BTFT Die Nahverkehrskarten waren ja schließlich früher da, als der Vorschlag zum einheitlichen Tagging. Teile des einheitlichen Schemas finden aber nach und nach Eingang in die Karten. Die Macher von Karten und anderen Applikationen haben ja nicht unendlich Zeit, weil sie wahrscheinlich noch nebenbei arbeiten gehen. Hab mich vielleicht etwas plump ausgedrückt. Das Wiki ist kein Gesetz. Aber wer möchte, dass sein Tagging in Zukunft auch in der Praxis funktioniert, muss sich schon etwas nach dem Wiki richten und ich bin der Meinung, dass das vereinheitlichte Schema schon den Weg zum weist, der sich weiter entwicken lässt, ohne gleich wieder in einer Sackgasse zu landen. Falls Du Vorschläge für Verbesserungen, Änderungen oder Ergänzungen dazu hast, dann schreibe bitte ein Proposal, wie man das Schema ergänzen kann. Wir diskutieren es gerne. Proposals zu schreiben ist eine Moeglichkeit, aber einfach machen ist in OSM durchaus auch zulaessig. +1 Wahrscheinlich wird derjenige den weiteren Verlauf bestimmen, der das vorgeschlagene JOSM-Plugin schreibt :-) Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 21.02.2012 00:46, schrieb Garry: Am 20.02.2012 11:45, schrieb bkmap: Am 17.02.2012 18:01, schrieb Roland Olbricht: Stationen sollte grundsätzlich nicht auf Gleisen liegen. Das Wiki ist da etwas missverständlich. Im Idealfall gibt es pro Gleis einen Bahnsteig. Wenn keine Bahnsteige erfasst sind, ist eine einzelne Node railway=station abseits der Gleise das Beste. public_transport=stop_position ist ganz falsch und sollte nur aus Kompatibilitätsgründen verwendet werden. public_transport=stop_position sollte laut Wiki ursprünglich den Ort kennzeichnen, an dem die Fahrzeugspitze hält. Wo steht das mit der Fahrzeugspitze? Und wie kann public_transport=stop_position ganz falsch sein??? Bei der Bahn ist es üblich die Haltepositionen für die Fahrzeugspitze anzugeben da dort derjenige sitzt der die Postion einzuhalten hat. Wichtig ist nicht, was bei der Bahn üblich, sondern was Konsens bei OSM und sinnvoll ist. Der Lockführer wird sich wohl kaum nach der Halteposition bei OSM richten. Ein frei definierter Begriff/Punkt stop_position der nur ein Hilfsmittel für den Router ist (vergleichbar mit den auch ehr unerwünschenten highway-Hilfslinien die einen Router über frei Plätze dirigieren sollen) schafft hier Verwirrung. Besser wäre sowas wie routing_gateway wenn man tatsächlich für Routing-Zwecke nicht auf so einen Punkt verzichten kann. Es sollte auf jeden Fall verhindert werden dass seh- und gehbehinderte Menschen im guten Glauben an eine zum Einsteigen für sie ungeeignete Postion geführt werden. Na dann sollten wir die Halteposition eben so kennzeichnen, dass da mit hoher Sicherheit ein Einstieg ist. Übrigens hab ich das bisher auch immer so gehalten. Ich fahre ja schließlich auch als Fahrgast und nicht als Lockführer. Viele Grüße Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nord-Stream-Pipeline - Liste gelesen
Am 06.02.2012 16:50, schrieb Jan Tappenbeck: Am 06.02.2012 16:41, schrieb Jan Tappenbeck: Am 06.02.2012 16:25, schrieb Johann H. Addicks: wird und in weiten Teilen noch gut sichbar ist. Ein gewaltiges Bauwerk das sicherlich in OSM rein sollte, auch wenn in einigen Jahren nicht mehr sichtbar ist. Aber wir mappen ja auch Stromleitungen .-) Ich vermute, dass diese Pipeline es auch in die Liste der kritischen Infrastrukturen kommt. Wenn wir alles mappen, was da auf der NIPP- und CIKR-Listen steht, dann klopft vermutlich bald die nächste Behörde.. wo sind diese Listen zu finden ??? Gruß Jan :-) Hi ! jetzt habe ich bei Heise die Liste gelesen - stellt sich die Frage ob wir uns davon beeindrucken lassen oder nicht Erst mal müssten sie NIPP- und CIKR-Listen mit den deutschen Behörden abgestimmt und in Schutzbereiche aufgenommen werden. Was in Deutschland nicht in einem Bereich laut Schutzbereichgesetz steht und keine militärische Anlage ist, können wir imo mappen, egal ob es später in einen Schutzbereich aufgenommen wird. Im Gesetz steht anzufertigen und nicht angefertigt zu haben. Wenn wir ein Gebiet legal mappen, kann man es uns nicht nachträglich in der Datenbank verbieten. Sonst müssten wir uns ja stets und ständig Gedanken machen, was den Militärs vielleicht später mal als schutzwürdig erscheint (Ob eine rein zivile Gasleitung jemals als militärisch schutzwürdig eingestuft wird, ist sehr fraglich). Man könnte aber das Rendern (Anfertigung einer bildlichen Darstellung) der Daten als verboten betrachten, auch wenn die Daten schon vorhanden waren, als das jeweilige Gebiet noch gar kein Schutzbereich war. Die Daten muss man auch dann meineserachtens nicht aus der Datenbank löschen. Man müsste lediglich die Darstellung speziell gekennzeichneter Gebiete durch die Renderer verhindern. Für die amtliche Verwaltung der Schutzbereiche sind, soweit mir bekannt ist, die Landkreise und kreisfreien Städte verantwortlich. Weiß jemand, ob es landes- oder bundesweite Listen gibt? Da kommt mir auch folgendes in den Sinn: Ohne Ortskenntnis nach Luftbildern zu mappen, kann dazu führen, dass man Schutzbereiche mappt, ohne dass man etwas davon mitkriegt. Und das ist in Deutschland illegal. Ein ziemlich starkes Argument gegen reines Sessel-Mapping. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Night of the living maps 07.02.2012 - Globale virtuelle Mapping Party
Am 27.01.2012 11:33, schrieb Ronnie Soak: Ja, da hast du recht. Das mache ich bisher zusaetzlich so. Gerade bei Haeuserformen, die ja meist nur wenige tags enthalten und hauptsaechlich aus 'Form' und 'Position' bestehen halte ich es fuer zumindest nicht schaedlich, auch den source key zu verwenden. Ordentliche Changset-Comments sind aber immer guenstiger. Allerdings muss man sich oft zu kleineren Changesets zwingen... Wenn ich z.B. Waldwege mit source=bing nach selbst erfassten Daten korrigiere, lösche ich meist source=* wieder heraus. Ich bin bei fehlendem source=* bisher immer davon ausgegangen, dass die Daten von mir stammen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hintergrund Josm Editor
Am 24.01.2012 12:42, schrieb Martin Koppenhoefer: Am 24. Januar 2012 09:50 schrieb Steffen Heinzeifelhu...@gmx.de: Am 23.01.2012 22:35, schrieb Martin Siegel: Ich finde, ein dunkler Hintergrund ist, vorallem bei langem Arbeiten am Bildschirm, deutlich entspannender für die Augen. das Gegenteil ist der Fall! Das ist wohl auch Geschmacksache. Grundsätzlich kann man schwarze Schrift auf weissem Hintergrund in der Regel besser lesen als andersrum (dazu gibt es Studien, das bezieht sich aber AFAIR auf gedruckte Medien, d.h. nicht hinterleuchtet sondern reflektiv). Andererseits flimmert weiss je nach Monitor ggf., während schwarz normalerweise bedeutet, dass der Monitor dort gar nichts anzeigt. Das mag sich durch die LCD-Technologie evtl. etwas verändert haben, dennoch tendiert das weiss dazu, zu blenden, während schwarz in dieser Hinsicht harmlos ist. Entscheidend ist daher die Umgebungsbeleuchtung: der finstere Hacker nachts im dunklen Kämmerlein nutzt wohl besser einen dunklen Hintergrund, der Schlipsträger im hell ausgeleuchteten Büro besser einen hellen... Schaut mal da: Weka Praxishandbuch Arbeitssicherheit und Gesundheitsschutz im Büro; S 135 ISBN-10: 3811180223 ISBN-13: 978-3811180222 http://books.google.de/books?id=UPcJ13-ZNAEClpg=PA135ots=o13LFdsJwFdq=%22Farbe%20in%20benutzungsoberfl%C3%A4chen%22%20dinhl=depg=PA135#v=onepageq=%22Farbe%20in%20benutzungsoberfl%C3%A4chen%22%20dinf=false Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schiffslagerplatz
Am 25.01.2012 09:05, schrieb Jan Tappenbeck: hi ! es gibt Plätze wo Schiffe gelagert / überwintert werden. Wie würdet Ihr das taggen ? amenity=boat_storage http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dmarina Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine
Hallo, Am 04.01.2012 16:13, schrieb Jan Tappenbeck: ich habe einmal wieder gebastelt - eine Sonderkarte zu dem Thema Grenz- und Meilensteine. Zu erreichen ist die Karte über die URL: http://www.tappenbeck.net/osm/maps/deu/index.php?id=1044 Sieht sehr gut aus, das motiviert mich, die restlichen von Ulrich Rüger vermessenen Rennsteigsteine auch noch zu importieren. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Name für Bahnhof?
Am 20.12.2011 19:20, schrieb Manuel Reimer: Hallo, wo wir es hier gerade von Namen haben: Wie genau wird ein Bahnhof korrekt genannt? Bei bahn.de nach dem Bahnhof suchen und diesen Namen übernehmen? Oder gibt es dann Lizenzprobleme? Bei Bahnhöfen würde ich den Namen nehmen der am Schild steht. Zusätzlich uic_ref=*. Für Bushaltestellen sieht es schon anders aus. Wenn die Fahrplanansicht bei http://openptmap.org funktionieren soll (dort wird zu http://mobile.bahn.de verlinkt), dann sollte Name oder mindestens der ref_name=Haltestelle,ort so wie bei bahn.de angegeben werden. Ich würde das mal als Bildungsvorschrift für den ref_name interpretieren. Man muss ja dabei nicht abschreiben. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Problem mit dem Zeichnen von Ways
Am 19.12.2011 09:56, schrieb Jan Tappenbeck: Hi ! seit einigen Versionen von JOSM gibt es zumindest bei mir erhebliche Probleme mit dem Zeichnen von Ways. Immer wieder wird die Verbindung zum vorherigen Node verloren bzw. es lassen sich diese Nodes nur ganz schwer wieder greifen. Wirf doch mal Probehalber die Plugins alle raus (Kannst sie ja dann wieder rein kopieren.) Wenn der Fehler bei einem Plugin liegt, sollte dann der Effekt weg sein. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tools zum Remappen NACH dem Lizenzwechsel?
Am 15.12.2011 23:00, schrieb Henning Scholland: Hallo Am 15.12.2011 20:29, schrieb Stephan Wolff: Am 15.12.2011 15:36, schrieb Frederik Ramm: Wieso wollt ihr denn partout bis nach dem Wechsel warten? Man kann doch auch die Unentschiedenen jetzt schon neu machen? Das kann verschiedene Gründe haben: - Einige Mapper werden ihre Zustimmung vielleicht demonstrativ am letzten Tag geben. In Kiel war ein mapper sehr aktiv, der bis zum 19.6. als ODBL-Ablehner und seit dem 20.6. mit neuem Account als Zustimmer tätig ist. Möglicherweise möchte er seine Objekte erhalten. Ich vermute eher, dass er weiter mappt, weil es wahrscheinlich bei OSM noch sinnvoller ist dies zutun, als bei einem Fork. Die Daten kommen dadurch noch in den letzten CC-BY-SA-Extrakt rein. Bei uns hier gibt es auch einen ODBL-Ablehner mit massenweise V1-objekten, der unter einem neuen account fleißig weiter editiert. Ich vermute mal, dass er nach Lizenzumstellung auf einen fork wie http://fosm.org/ umschwenkt. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Am 14.12.2011 00:22, schrieb Frederik Ramm: Fallen Euch Beispiele ein, bei dem das Austauschen eines Keys ein echtes Werk sein koennte? Bei highway=* und andere main tags auf jeden Fall. Wenn z.B. highway=unclassified (vom Luftbild abgemalt) in highway=residential geändert wurde (weil inzwischen jemand Ortskenntnis hat), halte ich das schon für ein Werk. Andererseits sehe ich nicht ein, dass alle Edits nach einem nicht trivialen Edit eines Nichtzustimmers wegfallen sollen. Attribute eines Objektes sind imo grundsätzlich vom Objekt an sich abgeleitete Werke und keine von anderen Attributen des Objektes abgeleiteten Werke. Man muss also den Ersteller eines Attributes nicht um Einverständnis fragen, damit man ein weiteres Attribut dem Objekt hinzufügen darf, dessen Autor bereits zugestimmt hat. Beispiel: version 1: user1 (Zustimmer) erste Version higway=residental version 2: user2 (Ablehner) oneway=yes version 3: user3 (Zustimmer) name=Ortsstraße version 4: user4 (Zustimmer) surface=paved version 5: user5 (Zustimmer) width=6 version 6: user6 (Zustimmer) maxspeed=30 Ohne Zweifel ist Version 1 von user1 das Hauptwerk von dem alle anderen abgeleitet sind. Version 2: oneway=yes von user 2 ist ein abgeleitetes Werk von Version 1. Die Versionen 3 bis 6 sind alle samt abgeleitete Werke von Version 1 und nicht von Version 2!!! Bei der Umstellung muss also prinzipiell nur oneway=yes gelöscht werden. Anders sieht aus, wenn Punkte verschoben oder hinzugefügt wurden, oder die tags voneinander abhängen (oneway=yes und oneway:bicycle=no). Ich habe aber bisher keine Vorstellung, wie man das alles halbwegs allgemeingültig abbilden könnte. Gibt es in der Hinsicht schon Ideen? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Am 13.12.2011 16:35, schrieb Frederik Ramm: In einem Fall, in dem Nichtzustimmer A einen Way mit 50 Nodes anlegt und Zustimmer B den dann aufsplittet in zwei, wird der OSMI nur die eine Haelfte des Ways rot einmalen und die andere fuer sauber halten; in diesem Fall erkennt man aber an den Nodes, die ja dann alle rot sind, dass da etwas faul ist, und man wuerde vermutlich ohnehin den Way komplett neu erfassen. afaik wird die ID der einen Haelfte des Weges beibehalten und die andere Haelfte bekommt erst mal die ID -1 und beim Hochladen dann eine nagelneue ID. Die Punkte bleiben erst mal die alten. Wenn dann noch jemand alten Punkte ersetzt, gibt es keine Referenz mehr auf die ursprünglichen Autoren. Liege ich da richtig? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Ich muss grad grinsen. Ob das wirklich ein Werk im juristischen Sinne darstellt wenn jemand zu einem Way ein oneyway=yes hinzufügt !? Aber gut, die Telekom durfte das magenta-T auch als Ihr Eigentum schützen lassen. ;-) Muss auch grinsen, wenn ich das schreibe. Komme mir schon vor, wie einer der Erbsen zählt :-) Aber die Diskussion um die Lizenzumstellung bewegt sich auf diesem Level an Detailliertheit. Das muss sie wahrscheinlich auch. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie wandeln nach Gauß Krüger Koordinaten?
Am 12.12.2011 16:40, schrieb Manuel Reimer: Hallo, gegeben ist eine GPX-Datei mit Wegpunkten. Jemand hat Interesse an diesen Daten, bittet mich aber, diese im Gauß Krüger Format zu übermitteln. Nun die Frage: Aktuell sind die Daten im OpenStreetMap üblichen Format. Wie wandle ich das um und in welchem Format werden Gauß Krüger Koordinaten üblicherweise gespeichert? GPX wird es ja wohl eher nicht sein? PROJ.4, der cartographic coordinate system filter verwendet Textfiles als input und output. http://wiki.openstreetmap.org/wiki/DE:Gau%C3%9F-Kr%C3%BCger Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Am 09.12.2011 13:31, schrieb Bernd Wurst: Hallo. Am 09.12.2011 10:51, schrieb Andi K: die Vollständigkeit der Wege liegt bei fast 100% Ich tippe die Vollständigkeit von Google eher auf 120%, zumindest was Waldwege betrifft. Es gibt einige Wege die wirst du vor Ort nicht mehr finden aber Google schlägt die für's Routing munter vor. Die haben einfach den selben Blödsinn importiert, den das Vermessungsamt hier schon seit Jahren als amtliche Karte anbietet. :( Ja, das ist bei mir auch so. Es sind Wege eingezeichnet, die es gar nicht mehr gibt, oder auf denen man eine Axt braucht um durchzukommen. Zuweilen fehlen auch Wege. http://www.openstreetmap.org/?lat=50.5031lon=11.1334zoom=14layers=M Nur sind bei weitem nicht alle Gebiete so gut gemappt. Dort ist Google klar im Vorteil. Für Neueinsteiger oder Gelegenheitsmapper fehlt jetzt dadurch ein Stück Motivation, mitzumachen. Unbestritten ist bei OSM immer noch der große Vorteil, dass es sich um offene Daten handelt :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Deutscher Wiki-Text zu remapping
Am 02.12.2011 16:39, schrieb Fabian Schmidt: Am 30.11.11 schrieb bkmap: Aber bei mir kriege ich keine Tiles: http://osm.informatik.uni-leipzig.de/map/?zoom=14lat=50.47404lon=11.16012layers=B0T ups, der Renderer lief nicht. Ok die Tiles sind jetzt da. Nur scheinen die Daten etwas alt zu sein, jedenfalls älter als 14. November 2011. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Deutscher Wiki-Text zu remapping
Am 30.11.2011 00:52, schrieb Wolfgang Barth: Am 29.11.2011 21:05, schrieb Manuel Reimer: Schaut gut aus. Was mir komplett fehlt ist dieser Link: http://osm.informatik.uni-leipzig.de/map/ Als Merkaartor-Nutzer war das für mich die einzige Möglichkeit, mir einen Überblick zu verschaffen. Guter Hinweis, habs reingeschrieben. Es gibt grün und blau, die erklärt sind. Was bedeuten die türkis eingefärbten Wege? Steht direkt unter der Karte - mal scrollen... Aber bei mir kriege ich keine Tiles: http://osm.informatik.uni-leipzig.de/map/?zoom=14lat=50.47404lon=11.16012layers=B0T Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]
Am 20.11.2011 14:14, schrieb Martin Koppenhoefer: Am 19. November 2011 22:31 schrieb Wolfgangwolfg...@ivkasogis.de: Wie gesagt, Behindertennavigation ist eine andere Sache, aber Wattwege grundsätzlich aus OSM oder allen Amwendungen herausnehmen zu wollen, halte ich für reichlch übertrieben. das war glaube ich auch nicht die Forderung. Überlegbar wäre doch z.B., ob man einen eigenen Wert für den highway-tag einführt, so dass diese Wege nur dann berücksichtigt werden, wenn die Anwendung sie kennt (und sich der Programmierer überlegen kann, wie er sie präsentiert). Warum nicht etwa so: highway=path access=no foot=high_tide+2-low_tide+0:30 oder highway=path access=no foot:hour_on=high_tide+2h foot:hour_off=low_tide+30min Jede auswertesoftware, die mit den Zeiten nicht zurechtkommt, zeigt den Pfad dann als gesperrt an. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]
Am 22.11.2011 15:19, schrieb Martin Koppenhoefer: Am 22. November 2011 15:00 schrieb Chris66chris66...@gmx.de: Naja, auf absehbare Zeit kommen die wenigsten Router mit solchen Konstrukten zurecht und da ist es IMHO ok, wenn solche temporären Wege standardmäßig *nicht* routbar sind. völlig einverstanden. Warum macht man solche Verrenkungen und nimmt nicht einfach einen neuen Wert für highway, z.B. highway=tidal_road für Straßen und highway=tidal_path für Wege (falls es das gibt) IMO brauchen wir Gezeiten-Eigenschaften, die wir nicht nur an Straßen oder Pfade hängen können. Es gibt ganz sicher noch andere gezeitenabhängige Objekte (Parkplätze, Wassersporteinrichtungen, nautische Objekte ...). Deshalb bin ich dafür, vorhandene zeitliche Restriktionen um die Gezeiten zu erweitern. Dann kann man aus Sicherheitsgründen so taggen, dass das Objekt keinen Zugang erlaubt, wenn die Anwendung diese zeitliche Einschränkung nicht verarbeiten kann. Übrigens ist es nicht relevant, ob die Wege bei Niedrigwasser vorhanden sind oder nicht, sondern ob der Zugang möglich und sicher ist. Das trifft auf Wege entlang der Steilküsten besonders zu. Man kann viele Wege am Fuß der Steilküste eigentlich nur begehen, wenn die Ebbe gerade einsetzt. Dann kann man dem Wasser sozusagen hinterher laufen. Noch bevor die Flut einsetzt sollte man aber schleunigst wieder umkehren, damit man nicht in einer der Buchten vom Wasser eingeschlossen wird. (Das gilt auch fürs Watt. Man kann da auf leichten Erhebungen vom Wasser eingeschlossen werden.) Wir brauchen ein Tagging, das solche Sachverhalte abbilden kann und das für andere gezeitenabhängige Objekte ebenfalls funktioniert (IMO über Objekteigenschaften). Router, die das Tagging nicht verstehen, dürfen sicherheitshalber nicht über diese Objekte routen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [WISY-Spam]Bus-Platformen und Mapnik
Am 10.11.2011 14:38, schrieb Chris66: Am 10.11.2011 14:25, schrieb Jan Tappenbeck (OSM): ich habe mich gerade über die Darstellung von Mapnik in Lübeck gewundert das dort einige Namen doppelt waren. Jetzt habe ich gesehen das es die Plattformen der Bushaltestellen sind. Wir mappen nicht für die Renderer - das weiß ich aber hat einer eine Idee wie man es umgehen könnte. So lassen sich Karten schwerer an den Mann / die Frau bringen. Hier ein Beispiel-Element: http://www.openstreetmap.org/browse/way/31664599 Moin Jan, wie sollen die Mapnik Maintainer auch den dauernden Tagging-Änderungen der ÖPNV Leute (gestern highway = platform, heute public_transport = platform) hinterherkommen? ;-) Der Name ist nun mal an beiden Elementen (platform und Straße) anhängend. Und in der Haltestellen-Relation und am Haltepunkt steht er auch noch. Normalerweise sollte es reichen, wenn er in der Relation steht. Keine Ahnung, wo das überhaupt schon richtig ausgewertet wird. Die Anwendungen hinken bei so etwas natürlich hinterher. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: [WISY-Spam]Bus-Platformen und Mapnik
Am 10.11.2011 14:56, schrieb Wolfgang Barth: Am 10.11.2011 14:25, schrieb Jan Tappenbeck (OSM): ich habe mich gerade über die Darstellung von Mapnik in Lübeck gewundert das dort einige Namen doppelt waren. Jetzt habe ich gesehen das es die Plattformen der Bushaltestellen sind. Wir mappen nicht für die Renderer - das weiß ich aber hat einer eine Idee wie man es umgehen könnte. So lassen sich Karten schwerer an den Mann / die Frau bringen. Also ich bin nicht der Meinung, daß dieses Rendering irritierend oder gar falsch ist. Es gibt häufig Haltestellen mit Name Messe, Museum ... oder so, die anders lauten als der Name der Straße in der sie sich befinden, gerade wenn ÖPNV z.B. in dieser Straße entlangfährt und mehrere Haltestellen dort bedient. Deshalb halte ich diese Darstellung in einer Karte für gut und klar. Wenn alles richtig wäre, müsste dort das Symbol für die Bushaltestelle angezeigt werden. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rundwanderweg wird aufgegeben - disused relation?
Am 27.09.2011 10:58, schrieb André Joost: Am 27.09.11 10:06, schrieb Sarah Hoffmann: On Tue, Sep 27, 2011 at 08:48:51AM +0200, André Joost wrote: Am 24.09.11 02:10, schrieb Bernhard Weiskopf: Wie entmarkiere ich die Relation (route = foot) zum Rundwanderweg 9? Gibt es auch bei den Relations disused = yes oder ähnlich? Einfach Löschen möchte ich nicht, vielleicht trägt dann jemand den Weg wieder mühevoll ein, die Aufgabe des Wegs ist bisher in der Presse nicht veröffentlicht worden. Die Relation sollte deshalb bei den Wegsegmenten in den Editoren noch erkennbar sein. In der Wanderreitkarte u. ä. soll der Weg aber nicht mehr angezeigt werden. Ein Hinweis unter description oder zur Not bei name genügt nicht, diese Tags werden oft nicht angezeigt. Wenn du a) osmc:symbol=* b) network=* rauswirfst, wird es wegen a) in der Wanderreitkarte und wegen b) in lonvias Karte nicht mehr angezeigt. b) ist nicht korrekt, es wird immernoch als lokale Route angezeigt. Pflicht sind auf der Lonviakarte nur die Tags type=route/superroute und route=hiking/foot/walking. Und im übrigen gibt es auch andere OSM-basierte Wanderkarten. Eine allgemein gültige Lösung des Problems wäre also nett. Dann würde ich route=disused_walking oder disused_hiking vorschlagen. Vielleicht besser disused=yes. Das ist schon etabliert und ich würde es auch auf routen anwenden. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nominatim
Am 13.09.2011 21:27, schrieb Dimitri Junker: Hallo, Das stand doch genau da?!1elf Ups, da sah für mich nichts nach Ortsname aus, sorry. Erstes wird gefunden, zweite nicht. Ich habe einen Bugreport erstellt Danke, hätte ich jetzt auch gemacht. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nominatim
Hallo, wer kann mir helfen? Warum wird das Haus 25, Schöne Aussicht, Neuhaus am Rennweg gefunden und das Haus 23, Schöne Aussicht, Neuhaus am Rennweg nicht? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Eigenschaftenfenster weg
Am 08.09.2011 11:53, schrieb Jan Tappenbeck: hi! durch einen temp. zweiten Bildschirm ist mein Eigenschaftsfenster weg - über propertiesdialog.bounds konnte ich nicht finden und das docked wird irgendwie nicht geschrieben. Kann mir einer von Euch die erforderlichen Einträge mit Basisdaten bereitstellen um den Dialog zu docken und ggf. oben links zu platzieren? File: preferences im JOSM-Benutzerverzeichnis propertiesdialog.docked=true Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NMEA
Hallo, so verstehe ich das: RMC Feld 8/9 ist der Kurs über Grund - d.h. die Wahre Bewegungsrichtung RMC Feld 10/11 und HDG Feld 4/5 ist die Abweichung des Erdmagnetfeldes von der Nordrichtung (Variation) HDG Feld 1 und HDM Feld 1 ist die Ausrichtung des Schiffes oder der Flugzeugnase zu der missweisenden Nordrichtung nach gemessenem Magnetfeld. HDT Feld 1 ist die wahre Ausrichtung des Schiffes oder der Flugzeugnase HDG Feld 2/3 ist die Abweichung des Kompasses vom Erdmagnetfeld infolge von Störfeldern (Deviation). Die Missweisung ist der Gesamteinfluss von Deviation und Variation. Gruß Burkhard Am 06.09.2011 06:19, schrieb Rolf Meyerhof: Hallo Dimitri In IIRMC wird nicht der Kurs angezeigt sondern die Magnetic Variation in Grad. Das ist Deklimation oder auch Missweisung. Gruß Rolf -Ursprüngliche Nachricht- Von: Dimitri Junker [mailto:o...@dimitri-junker.de] Gesendet: Dienstag, 6. September 2011 02:00 An: talk-de@openstreetmap.org Betreff: [Talk-de] NMEA Hallo, ich schlage mich gerade mit NMEA herum und wunder mich über sehr unterschiedliche Kurse in verschiedenen Sätzen: $IIRMC,203740,A,3700.660,N,00813.710,W,3.1,105.0,280711,3,W,A*10 IIHDG,043.0,,,3,W*2A $IIHDM,043.0,M*25 $IIHDT,040.0,T*26 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiet
Am 25.07.2011 20:09, schrieb Michael Bemmerl: Markus schrieb: Wie schreibt man Betreten verboten in die DB? Wie wär's mit access=no? Wenn aber Wege im Gebiet verlaufen, die betreten werden dürfen, was hat dann Vorrang? Das Gebiet oder der Weg? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist map2go ?
Am 03.07.2011 07:42, schrieb Jan Tappenbeck: hi ! habe gerade den Link http://www.map2go.org/maps/ gefunden - kann mir einer sagen was das ist oder dahinter steckt ?? Ich finde kein Impressium und sonstigen Texte !! Gruß Jan :-) Keine Ahnung, WhoIs zeigt: Registrant Name:Thorsten Hildebrand Registrant Street1:map2go.org, office #2029973 Registrant Street2:c/o OwO, BP80157 Registrant Street3: Registrant City:Roubaix Cedex 1 Registrant State/Province: Registrant Postal Code:59053 Registrant Country:FR Registrant Phone:+33.899701761 Registrant Phone Ext.: Registrant FAX: Registrant FAX Ext.: Registrant Email:9ojfwv7mf6o7yxr51...@w.o-w-o.info Die Telefonnummer verweist auf: OVH (vereinfachte Aktiengesellschaft mit einem Kapital von 500.000 €) Handelsregister von Roubaix – Tourcoing 424 761 419 00011 APE-Code 721Z – USt-IdNr.: FR 22-424-761-419-00011 Geschäftssitz: 140 Quai du Sartel, 59100 Roubaix (Frankreich). Tel.: +33 (0)899 701 761 Elektronische Kontaktaufnahme: Kontaktformular auf der Website www.ovh.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] prüfen von Relationsvollständigkeiten
Am 27.06.2011 00:43, schrieb M∡rtin Koppenhoefer: Am 26. Juni 2011 21:36 schrieb Simon Poolesi...@poole.ch: Leider steht nirgends ob distance die Soll- oder Istlänge ist. Und man kann lange darüber philosophieren welches überhaupt sinnvoll wäre m.E. macht nur die Soll-länge Sinn, die Istlänge ist ja schon automatisch da (Zumindest wenn man eine lat-long-DB hat kann man das dort ohne Probleme rauslesen). Die Soll-länge wäre das, was jemand der die Route geprüft hat, beim Zeitpunkt der Prüfung ermittelt, oder? Eine Prüfung auf Länge kann aber nur grob erfolgen. Das hieße sonst, dass jeder, der z.B ein einzelnes Wegsegment korrigiert oder detailliert hat, immer die neue Länge berechnen und eintragen muss. Wenn eine Relation zusammenhängend ist und grob der Sollänge entspricht, könnte man davon ausgehen, dass sie komplett ist - aber nur grob. Wenn es sich um eine Routen-Relation handelt, wäre es m.E sinnvoll, den Anfangs- und Endpunkt explizit festlegen zu können. Dann ist die Route vollständig, wenn sie einschließlich dieser beiden Punkte zusammenhängend ist. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderwegeverlauf und Kartenwerk der Landesvermessung
Am 30.05.2011 09:39, schrieb Jan Tappenbeck: Hi ! ich hatte heute gerade ein Telefonat mit einem Wegewart für Wanderwege und als er von OSM gehört hat wurde ihm schon anders. Aus allen Ecken wird er nach GPS gefragt etc. und er kommt da personell auch nicht mehr gegen an. Ich hatte gezielt nach dem GPS-File für einen Weg gefragt und er hat mir gesagt das deren Daten in der Karte der Landesvermessung enthalten sind und wir diese doch dann vor dort übernehmen könnten. Schließlich habe die diese auch nur bereitgestellt bekommen - und ich könne mich doch auch auf Ihn berufen. Wie denkt Ihr darüber - bei wem liegen die Rechte Gruß Jan :-) Auf diese Problematik bin ich auch schon gestoßen. In Thüringen ist die Sachlage etwa so: Die Wandervereine und Wegewarte der Kommunen legen zusammen den Kreiswegewarten den Verlauf der Wanderwege fest. Diese Wanderwege müssen mit dem Thüringer Forst abgestimmt werden. Dabei werden sie im Rahmen des Projektes Forsten und Tourismus im GIS des Thüringer Forstes erfasst. Von Thütinger Forst werden auch die amtlichen Blattschnitte mit den Wegeverläufen herausgegeben. Die Nutzungsrechte an den Daten werden dann an Kartenverlage und andere kommerzielle Nutzer verkauft. Es liegt also klar ein kommerzielles Interesse des Thüringer Forstes vor. Auf meine Anfrage betreffs der Veröffentlichung der Wegeverläufe in OSM erhielt ich dementsprechend folgende Antwort: *** VON: andreas.lu...@forst.thueringen.de Sehr geehrter Herr Kirchner, nach Rücksprache mit unserem GIS-Referat bedaure ich Ihnen mitteilen zu müssen, dass wir Ihnen die Daten nicht zur Verfügung stellen können. Begründung: Eine Veröffentlichung der Erholungswege im OpenStreetMap ist problematisch: 1) Mit der Veröffentlichung verlieren die Daten ihren amtlichen Charakter, da im OpenStreetMap jeder registrierter Nutzer die Daten verändern darf , so dass nachträglich keine Garantie mehr existiert, dass es unsere Daten sind, obwohl aus der Datenbeschreibung der Eindruck erzeugt wird, das es amtliche Daten sind. 2) Die kostenfreie Veröffentlichung der Daten (auch zum downoad möglich) widerspricht den Regelungen der Thüringer Verwaltungskostenordnung, die momentan die Kostenpflichtigkeit der Datennutzung vorsieht (10.000€ für den kompletten Datenbestand von Thüringen). Dies würde insbesondere auch den Interessen der Kartenverlage widersprechen, die unsere Daten in Lizenz kaufen und Wanderwegekarten vermarkten. 3) Die Datenpflege im OpenstreetMap verfolgt ein anderes Konzept. Stellt man einmal die Daten dort rein - muß man sie auch dort pflegen (das kann dann jeder registrierter Benutzer tun - siehe P.1.). Man kann jedoch nicht mehr die alten Daten komplett löschen und durch neue ersetzen. Mit der geplanten Veröffentlichung der Daten im GEOPROXY und GOOGLE-Earth werden wir der Bevölkerung eine kostenfreie Möglichkeit der begrenzten Datennutzung bieten. Dort können wir jedoch der Datenherr bleiben und die Daten regelmäßig pflegen, da sie unser technisches und geistiges Eigentum bleiben. Mit freundlichen Grüßen Andreas Lucas Referatsleiter * ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Rennsteigverlauf zwischen Ernstthal und Spechtsbrunn
Hallo Liste, ich war vor 2 Wochen mit dem Fahrrad am Rennsteg bei Spechtsbrunn. An der Kreuzung beim Triniusblick ist mir aufgefallen, dass Die Informationstafel über den Rennsteigverlauf und die Markierung des Rennsteiges fehlerhaft sind. Den Sachverhalt hat wohl auch auch schon ein eifriger Verfechter des Original-Rennsteiges bemerkt und den größten Teil des Textes mit schwarzer Farbe und dem Wort FALSCH zugesprüht. Zu Hause hab ich in allen mir verfügbaren alten Dokumenten nachgesehen und meine Vermutung wurde bestätigt: Die Tafel beschreibt als Original-Rennsteig die Route über den wassergebunden ausgebauten Fahrweg und als Alternativroute den historischen Rennsteig. Das ist wirklich falsch. Nun habe ich daraufhin das Naturparkinformationszentrum Spechtsbrunn angerufen und hab den Sachverhalt erläutert. Mir wurde gesagt, dass das bekannt ist und das das vor ca 4 Jahren im Zuge der Zertifizierung so festgelegt wurde. Alle Karten wären jetzt so gezeichnet und das wäre jetzt eben jetzt so festgelegt. Nach den ich gesagt habe, dass das ja kein Dogma ist und bei der Wiederholungszertifizierung der aus Unkenntnis festgelegte Weg korrigiert werden kann, fing die Frau am Telefon sofort zu streiten an: Da führt kein weg rein. und Ich werde mich mit aller Macht dafür einsetzen das das so bleibt. Sie beobachte das Internet und würde gegen alle gegenteiligen Versuche einschreiten. Sie bemerkte außerdem, dass man sich doch nicht die Chance verbauen könne, die Touristen direkt zum Gasthof Brand zu führen, an dem der echte Rennsteig nicht direkt vorbei führt. Ihre Touristen würden sowieso lieber den gerade, breiten Weg gehen. Als ich nachfragte, wer genau das entschieden hat, sagte sie mir, dass sie mir darauf keinen Auskunft erteilen müsste. Eigentlich hatte ich vor, den Original-Rennsteig in die OSM-Relation einzutragen und den Fahrweg als alternativ. Das entspräche nämlich den historischen Gegebenheiten und nicht kommerziellen Überlegungen. Habt Ihr schon ähnliche Erfahrungen gemacht? Was haltet Ihr davon? Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bolzplatz
Am 20.04.2011 12:15, schrieb Sven Geggus: Jan Tappenbecko...@tappenbeck.net wrote: nicht schlagen, wenn schon 100x gefragt wurde. aber wie ist ein Bolzplatz zu taggen ? Ballsport Fussball finde ich zu hochgegriffen. Würde das in der Kategorie Freizeit einordnen. leisure=pitch sollte es doch nach wie vor geben, oder? Und sport=soccer dazu. Der Rest ergibt sich aus der Größe der Fläche. Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäche mit layer=-1
Am 20.04.2011 12:11, schrieb M∡rtin Koppenhoefer: Am 19. April 2011 12:20 schrieb bkmapburkhard.kirch...@web.de: In letzter Zeit habe ich Bäche öfters durchgehend mit mit layer=-1 erfasst, damit sie unter Brücken und in Rohren automatisch unten verschwinden. Jetzt habe ich gemerkt, dass das im Osmarender schief geht. Die Bäche verschwinden nämlich auch unter Waldflächen. Ich denke werde mich drüber machen und die Bäche auf Layer=0 umarbeiten. Nur wenn sie als Tunnel gekennzeichnet sind erhalten sie dann layer=-1. Im Gegenzug bekommen dann die Brücken über bäche layer=1. Hat jemand eine bessere Idee? M.E. braucht man da keine Idee, steht alles im Wiki: http://wiki.openstreetmap.org/wiki/Layer Layer sind relative Höhenangaben an Stellen, wo sich mehrere Objekte überlappen, alles andere ist tagging für die Renderer. Ok - die Wiki-Seite kenne ich ja. Hab ja auch alles schon lange geändert. Mein ursprünglicher Gedanke war, dass es wohl nicht stören würde, wenn man einen kompletten Bach eine Ebene tiefer legt, da er sowieso immer unter den Wegen durch geht. Das war ein Irrtum. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bäche mit layer=-1
Hallo Liste, In letzter Zeit habe ich Bäche öfters durchgehend mit mit layer=-1 erfasst, damit sie unter Brücken und in Rohren automatisch unten verschwinden. Jetzt habe ich gemerkt, dass das im Osmarender schief geht. Die Bäche verschwinden nämlich auch unter Waldflächen. Ich denke werde mich drüber machen und die Bäche auf Layer=0 umarbeiten. Nur wenn sie als Tunnel gekennzeichnet sind erhalten sie dann layer=-1. Im Gegenzug bekommen dann die Brücken über bäche layer=1. Hat jemand eine bessere Idee? Bye Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS/GSM Tracker gesucht
Am 24.09.2010 13:58, schrieb Rene Caspari: Hallo Liste, vielleicht hat der eine oder andere ja schon etwas Erfahrung in der Richtung, und zwar suche ich ein kleines GPS Empfangsgeraet, welches in der Lage ist, per GSM seine Standortdaten per IP zu versenden. Intervall sollte einstellbar sein, 1x/min sollte aber schon drin sein. Eine lange Akkulaufzeit ist auch nicht zu unterschaetzen, ebenso wie ein relativ guter GPS Empfang. z.B.: http://www.globaltechnics.co.uk/index.php?target=categoriescategory_id=27 Wenn das ganze dann noch klein genug ist, dass man es an einem Guertel mit sich fuehren kann (z.b. beim joggen), waere es geradezu ideal. Kind regards, Rene ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 03.09.2010 08:40, schrieb André Joost: Am 03.09.10 07:35, schrieb bkmap: Tags wie construction:awarding_authority wären dann leicht möglich War nur ein Beispiel: Auftraggeber oder Bauherr, der auf der Bautafel steht. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 02.09.2010 01:02, schrieb M∡rtin Koppenhoefer: Am 2. September 2010 00:53 schrieb Garry garr...@gmx.de: Das übliche tagging ist allerdings: highway = construction construction = tertiary Das Thema war noch lange nicht ausdiskutiert. doch, war es. Du warst halt nicht mit dem Ergebnis einverstanden. Im Prinzip ist es doch wurscht, wie die Tags heissen. Hauptsache es funktioniert und kommt nicht so leicht zu Verwechslungen. In diesem Sinne ist die highway=construction-Variante die bessere. Es ist noch nicht ausdiskutiert. OSM lebt und entwichelt sich Ich habe das Thema verfolgt, hatte aber bei meinen Aktivitäten bislang noch keinen Grund, darüber genauer nachdenken zu müssen. Das ist jetzt anders und es würde mich wundern, wenn ich der eineige bin, der jetzt oder in Zukunft auf ähnliche Sachverhalte stößt. Beispiele: Eine Sportstätte wird erschlossen und gebaut - mein Tagging für alle Bestandteile inclusive Parkplätze und Zufahrtswege: access=no, construction=yes Ein Teich wird leergelassen und inclusive Schutzhütte und Wege umfangreich rekunstruiert. Das Gebiet ist für jeglichen Zugang gesperrt - mein Tagging: access=no, construction=yes Mir fallen zig Situationen ein, bei denen durch Rekonstruktion vorübergehend kein Zugang möglich ist: Einkaufszentrum, Schwimmhalle, Eislaufbahn, Parkhaus, Aussichtsturm . Nach meinem jetzigen Kenntnisstand wäre ein einheitliches Tag construction=yes für alle in Bau befindliche Objekte sehr sinnvoll uns logisch, auch wenn schon 1000 Leute die übliche Variante nutzen, die ich für Straßen übrigens auch schon verwendet habe. Ich bin dafür, neue Objekte mit construction=yes zu taggen. Die alten Tags müssen für eine Umstellung nicht unbedingt geändert werden. Die verschwinden sowieso, wenn die Baumaßnahme beendet ist. Wenn jemand einen besseren Vorschlag hat - bitte posten! Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Im Bau befindliche Brücke
Am 02.09.2010 10:59, schrieb M∡rtin Koppenhoefer: steht doch oben: construction=motorway bzw. residential ok. Und was ist nun mit Objekten, die keine Straßen sind? Das war mein Einwurf weiter oben: Eine Sportstätte wird erschlossen und gebaut - mein Tagging für alle Bestandteile inclusive Parkplätze und Zufahrtswege: access=no, construction=yes construction:period und vielleicht ergänende Tags wie construction:awarding_authority wären dann leicht möglich und auch für jedes Objekt benutzbar, sogar in einer Relation. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
