Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 21.08.2015 00:28, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Dort ist das eigentlich relativ einfach, denn die meisten natürlichen Wasserläufe sind hier kaum begradigt, so dass man sie gut an der Form erkennen kann. Die mäandernden Flüsse sind 20-60m breit. Das war nicht die Frage. Aber welche Gräben hatten einen natürlichen Vorgänger und müssten als stream erfasst werden? Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Das Problem ist hier nicht die Erfassung historischer Zustände, sondern die Bewertung der Gegenwart aufgrund von Erkenntnissen über die Vergangenheit. Wollen wir von den Mappern verlangen, dass sie die Vergangenheit jedes Objekts ermitteln und danach das Haupttag festlegen? Soll ein Mapper ein Kleingewässer, dessen Vergangenheit er nicht ermitteln kann, als stream oder ditch taggen? Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Alle Anwendungen, bei denen in irgendeiner Form eine Analyse der Struktur des Gewässernetzwerkes stattfindet. OSM wird häufiger für Kartendarstellungen als zu Strukturanalysen des Gewässernetzwerkes verwendet. Das Tagging sollte sich m.E. eher an den Bedürfnissen der Hauptnutzung orientieren. Der zentrale Punkt ist, dass natürliche Fließgewässer generell den steilsten Weg bergab fließen. Für Bergbäche mag es gelten. Für mäandernden Flüsse nicht. Begradigte Bäche und Entwässerungsgräben sind meist so angelegt, dass das Wasser auf direktem Weg ablaufen kann. In der ober genannten Region werden mehrerer Flüsse über Pumpwerke entwässert. Die Alte Sorge fließt dadurch auf den letzten 9km rückwärts. In den Gräben fließt das Wasser dagegen nur durch die Schwerkraft. Für künstliche Wasserläufe gilt beides nicht (Kontinuität im engeren Sinne natürlich schon, jedoch nicht nach außen wenn man Tunnel und Druckstollen mit einbezieht). Tunnel und Druckstollen wird man eher am tunnel-Tag als am waterway-Tag erkennen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Der Nord-Ostsee-Kanal ersetzt die Eider zwischen Flemhuder See und Rendsburg. Er nimmt das Wasser der Obereider und aller ehemaligen Zuflüsse auf. Ist dieser Abschnitt ein natürliches Gewässer? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Moin, kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Fast alle Flüsse in Europa sind vom Menschen deutlich verändert. Bis zu welcher Abweichung vom Verlauf vor menschlichen Eingriffen ist der begradigte Flussabschnitt natürlich? Auch Schifffahrtskanäle verlaufen zu großen Teilen auf alten Flussstrecken und übernehmen die Entwässerungsfunktion des Flusses. Sind diese Teile des Kanals natürlich? Ist ein Stausee, an dessen Stelle sich vor der Stauung ein deutlich kleinerer See befand, natürlich? Oder ist die Fläche des ehemaligen Sees natürlich und der Außenbereich künstlich? Ist ein See, der im 19.Jh zur Trinkwasserversorgung angelegt wurde, natürlich? Sind ehemalige Kiesgruben, die sich durch Grundwasser und Regen in Seen wandeln, oder Löschteiche neben Bauernhöfen natürlich? Sind Gartenteiche mit Folienboden natürlich? Wie soll ein Mapper, der einen Stausee, einen Teich oder einen Graben sieht, entscheiden, ob es sich um ein verändertes, natürliches oder ein künstliches Gewässer handelt? Ich würde die Unterscheidung in künstliche und natürliche Gewässer aufgeben und sie nur nach Größe und Funktion unterscheiden. Gruß Stephan Am 19.08.2015 07:39, schrieb Michael Paulmann: Es gibt Stauseen mit water=lake und natural=water, Stauseen mit nur natural=water und Stauseen mit natural=water und water=reservoir. ... anscheinend taggt ja jeder auch menschengemachte Wasserflächen wie er/sie das will. 2015-08-04 16:00 GMT+02:00 Norbert Kück o...@nkbre.net: Gewässer, die von Menschen NICHT GESCHAFFEN sondern VERÄNDERT wurden, sind KEINE KÜNSTLICHEN Gewässer. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 20.08.2015 14:20, schrieb Christoph Hormann: On Thursday 20 August 2015, Stephan Wolff wrote: kann jemand eine sinnvoll anwendbare Definition von künstlichen / menschengemachten Wasserflächen geben? Für stehende Wasserflächen: natürlich (also water=lake/pond): die Wasserfläche existierte schon vor dem Beginn menschlicher Eingriffe/würde ohne menschliche Eingriffe existieren. Für Wasserläufe: natürlich (also waterway=river/stream und ggf. waterway=riverbank bzw. water=river für das Polygon): es hat vor den menschlichen Eingriffen einen Wasserlauf gegeben, der im Verlauf und in seinem Einzugsgebiet dem jetzigen ähnelt. Bei großen Flüssen und Seen ist offensichtlich oder zumindest leicht zu ermitteln, ob sie vom Menschen geschaffen wurden. Aber gerade bei den kleinen Gewässern, um die es hier geht, ist die Unterscheidung nach diesen Kriterien sehr schwer. Wer hat schon Karten aus der Zeit der ersten Kultivierung? Welche kleinen Wasserläufe dieses Gebiets sind natürlich? http://www.openstreetmap.org/#map=13/54.3349/9.4072 Die Bezugnahme auf die Vergangenheit vor den menschlichen Eingriffen ist natürlich im Sinne der Überprüfbarkeit etwas heikel. Das macht die Unterscheidung aber noch nicht generell sinnlos. Der historische Ansatz passt nicht zu OSM. In OSM wird generell der aktuelle Zustand erfasst. Soll man zwei aktuell gleiche Wasserläufe mit unterschiedlichen Tags erfassen, wenn einer einen natürlichen Vorgänger hatte? Wer die ganze Unterscheidung komplett abschaffen möchte sollte bedenken, dass dies den Nutzen der Daten insbesondere in wasserbaulich stark erschlossenen Gebieten enorm einschränken würde. Welche Anwendungen braucht die Unterscheidung nach der Entstehung des Gewässers? Für welche Anwendungen würde es eine enorme Einschränkung bedeuten? Um auf Übersichtskarten nur Große Flüsse darzustellen fehlt dagegen eine Unterteilung in kleiner Fluss, großer Fluss und Strom wie im ersten Diagramm im Wikipediaartikel Fließgewässer. https://de.wikipedia.org/wiki/Flie%C3%9Fgew%C3%A4sser Aktuell werden kleine Wasserläufe ohne erkennbares System als ditch, drain oder stream bezeichnet. Schlimmer kann es nicht werden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 04.08.2015 09:57, schrieb Martin Koppenhoefer: Am 03.08.2015 um 23:09 schrieb Stephan Wolff s.wo...@web.de: https://www.openstreetmap.org/way/35067961 zweispurig, beidseits Geh- und Radweg, Linienbusverkehr, Unigelände Wo steht, dass highway=residential immer öffentliche Straßen sind? in Berlin an der TU ist eine vergleichbare Straße, als Service getaggt: residential ist eine Straßenklasse, die Wohnbebauung voraussetzt, das ist an der Kieler Uni vermutlich auch nicht gegeben. Die Straße an der TUI Berlin kenne ich nicht. surface=cobblestone spricht eher für eine wenig benutzte Zufahrt. In Kiel sind offenbar alle beteiligten Mapper mit residential einverstanden. Ob residential auch für Straßen im Gewerbegebiet passt, wurde ja gerade im anderen Thread diskutiert. Solange mein erstes Beispiel unstrittig ist, gilt die Aussage, dass es highway=unclassified gibt, die keine öffentlichen Straßen sind. q.e.d. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 05.08.2015 16:30, schrieb Florian Lohoff: Auch da habe ich eigentlich erstmal keinen Stress mit - Wichtig hier ist die Kommunikation - Also wenn solche Dinger in irgendeiner form da sind - aber nicht vor Ort ersichtlich dann erwarte ich mind. einen Note auf dem Way der erklärt warum das so sein muss. Wenn sowas nicht da ist und vor Ort nicht ersichtlich ist warum eine restriction existiert dann entferne ich sowas auch ohne gross nachzufragen. Daten, die man nicht vor Ort verifizieren kann, einfach zu löschen, finde ich falsch. Eine Quellenangabe für jedes Tag ist in OSM nicht obligatorisch. Eine Recherche im Internet (spiekeroog auto) oder eine Nachfrage beim Mapper, der das Verbot eingetragen hat, oder eine eigene Eintragung am Objekt (fixme=Kein Verbotsschild - Autos doch erlaubt?) mit angemessener Frist wären m.E. mindestens erforderlich, bevor man Informationen löscht. Offensichtlich falsche Daten darf man natürlich ohne Nachfrage löschen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 03.08.2015 um 09:42 schrieb Martin Koppenhoefer: Am 03.08.2015 um 01:53 schrieb Stephan Wolff s.wo...@web.de: Das ist eine Grundsatzfrage für unser Tagging. Für fast alle Regeln gibt es Ausnahmen für spezielle Gruppen (Polizei, Rettungsdienste, Grünflächenamt, Stadtwerke, Jagdpächter, etc.) oder Sondererlaubnisse für Einzelpersonen oder Fahrzeuge. ja, daher ist no auch fast immer zu restriktiv Setzt du für alle Fußwege, auf denen gelegentlich Fahrzeuge des Grünflächenamts fahren, motor_vehicle=private? Normalerweise erfassen wir nur die allgemeinen Regeln in OSM. davon lese ich gerade zum ersten Mal, bisher bin ich davon ausgegangen dass Ausnahmen auch erfasst werden, zumindest ansatzweise. Ausgeschilderte Regeln gelten allgemein, die erfassen wir natürlich. Aber Sondererlaubnisse für Einzelpersonen oder Fahrzeuge kenne ich in OSM nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 03.08.2015 um 09:45 schrieb Martin Koppenhoefer: Am 03.08.2015 um 01:53 schrieb Stephan Wolff s.wo...@web.de: highway=residential/unclassified etc sagt ja öffentliche Straße d.h. StVO. In Deutschland trifft es meist, aber nicht immer zu. könnte das hier nochmal erläutert werden, bitte? Verstehe ich das richtig, dass es highway=res/unclassified gibt die keine öffentlichen Straßen sind? Z.B. https://www.openstreetmap.org/way/155221649 zweispurig, Mittellinie, Geh- und Radweg, mit Verbindungscharakter https://www.openstreetmap.org/way/35067961 zweispurig, beidseits Geh- und Radweg, Linienbusverkehr, Unigelände Wo steht, dass highway=residential immer öffentliche Straßen sind? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 30.07.2015 um 22:22 schrieb Florian Lohoff: Wenn die Gemeinde alle Beschlüsse auf ihrer Webseite veröffentlicht, könnte man das website-Tag am Gemeindeobjekt als einen solchen Hinweis interpretieren :-) Ansonsten existieren keine Polygone in der realen Welt und Metainformationen gehören nicht in eine Geodatenbank. Puh - also wer von den casual-mappern guckt denn als erstes in ein Gemeindeobjekt ob denn wohl da spannendes drin steht? Man kann nicht alle wichtigen Beschlüsse der Gemeinde in das Objekt bei OSM aufnehmen. Der Mapper muss schon auf der Webseite der Gemeinde eine Recherche machen. Wie am Smiley ersichtlich, war der Vorschlag nicht ganz ernst gemeint. Und es geht ja um unterschiedlichste Gebiete. Das diese Informationen nicht in eine Geodatenbank gehören sehe ich noch ein bischen anders da es eben Geoinformationen sind. Das für OSM nur Metainformationen sind mag ja sein - Aber wenn ich mir den schrott mit den umrissen der Hochauflösenden Bing Bilder von anno Tobak oder so ansehe dann ist das eine absurde Diskussion. Ich hätte da durchaus mehrere Anwendungsfälle - Für NRW den Hinweis auf die DOPs/ALKIS Daten vom LVermA (Es gibt immer noch jede menge ID Nutzer die von uralten und lagekaputten Bing Bildern abzeichnen) oder eben solche dinger wie die Autofreien Inseln. Am Ende könnte man sogar noch z.b. den JOSM Validator mit informationen versorgen z.b. Gebiet mit Linksverkehr oder die default sprache so das ein name:de in Deutschland im Validator aufpoppt. Die Umrisse der hochauflösender Bildquellen habe immerhin ein definiertes Polygon, gehören aber nicht in eine Geodatenbank. Ein willkürlich gezeichnetes Polygon für jeden Defaultwert (railway:gauge; urban:maxspeed; default_language) würde unsere Datenbank mit tausenden riesiger Gebiete zumüllen. Für den Mapper wären diese Polygone auch nicht auffindbar. Jetzt aufgrund des einen Schildes alle wege auf der Straße mit einem motor_vehicle=no zu versorgen halte ich für total übertrieben. Das Verbot gilt wegen der Widmung für jede einzelne Straße auf ganzer Länge. Das Schild ist nur ein punktförmiger Hinweis darauf. =no ist falsch - Es sind dort motor_vehicles unterwegs und die dürfen das. Das ist eine Grundsatzfrage für unser Tagging. Für fast alle Regeln gibt es Ausnahmen für spezielle Gruppen (Polizei, Rettungsdienste, Grünflächenamt, Stadtwerke, Jagdpächter, etc.) oder Sondererlaubnisse für Einzelpersonen oder Fahrzeuge. Normalerweise erfassen wir nur die allgemeinen Regeln in OSM. Dann ist =no korrekt. Anderenfalls müssten wir nahezu alle Fußwege mit motor_vehicle=private ergänzen. Selbst ein Zeichen 250 ist kein access=no. 99% der Mapper haben eine andere Meinung als du. ;-) Ein Zeichen 250 ist ein Fahrzeuge aller Art. Mit dem Pferd oder zu Fuß darf ich da sehr wohl rein. Du hast recht. Ich hatte mich verlesen. highway=residential/unclassified etc sagt ja öffentliche Straße d.h. StVO. In Deutschland trifft es meist, aber nicht immer zu. Gib mir doch mal ein Beispiel für eine StVO konforme Beschilderung für ein access=no. Ich kenne da gerade keine. § 45 STVO Die Straßenverkehrsbehörden können die Benutzung bestimmter Straßen oder Straßenstrecken aus Gründen der Sicherheit oder Ordnung des Verkehrs beschränken oder verbieten und den Verkehr umleiten + ein Dutzend weitere Gründe Ein Schild zeigt das Verbot nur an. Ein über die Straße gespanntes Flatterband reicht vermutlich schon als Kennzeichnung. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 30.07.2015 09:54, schrieb Florian Lohoff: Mir schwebte eigentlich eher vor das man quasi über Polygone seperat in einer Datenbank mappingregeln oder generell regionale infos ablegen kann. Diese URL/ID wird dann beim Download von Daten aus der API gleich mitgeliefert so das JOSM z.b. ein Popup zeigen kann nach dem Motto: Im Heruntergeladenen Bereich existieren Regionale Informationen - Vor dem Hochladen bitte lesen: Wenn die Gemeinde alle Beschlüsse auf ihrer Webseite veröffentlicht, könnte man das website-Tag am Gemeindeobjekt als einen solchen Hinweis interpretieren :-) Ansonsten existieren keine Polygone in der realen Welt und Metainformationen gehören nicht in eine Geodatenbank. In anderen Orten sind vielleicht nur zwei Straßen für den Kfz-Verkehr verboten. Zu jeder einzelnen Gemeindestraße existiert aber eine Widmung und deshalb gehört diese Information zum highway-Objekt. Inseln haben typischerweise GAR KEINE Zufahrt. Das ist ja genau das spannende. Es ist ein isolierter Graph. Beschilderungen dieser art sind aber rechtlich eigentlich punktförmige Verbote mit einer Richtung auf der Straße. D.h. ich darf den Punkt auf der Straße nicht in der jeweiligen Richtung überschreiten. In OSM tragen wir die als Streckenverbote ein (Was falsch ist). Jetzt aufgrund des einen Schildes alle wege auf der Straße mit einem motor_vehicle=no zu versorgen halte ich für total übertrieben. Das Verbot gilt wegen der Widmung für jede einzelne Straße auf ganzer Länge. Das Schild ist nur ein punktförmiger Hinweis darauf. Es besteht ein allgemeines Verbot mit wenigen Ausnahmegenehmigungen. Es besteht aber eben kein generelles Verbot aller Kraftfahrtzeuge. Ich sehe immer wieder mapper die irgendwelche Straßen mit access=no taggen. Das ist in 99% aller fälle falsch. Selbst ein Zeichen 250 ist kein access=no. 99% der Mapper haben eine andere Meinung als du. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 29.07.2015 11:07, schrieb Florian Lohoff: On Mon, Jul 27, 2015 at 11:35:18PM +0200, Stephan Wolff wrote: es ist für die Diskussion hilfreich, die Deutsche Autofreie Insel als Spiekerogg zu benennen und einen betroffenen Weg zu verlinken: Auch ein Link auf die Bilder bei Mapillary würde helfen. Also wer Spiekeroog nicht bei Mapillary findet dem kann ich nicht Helfen. Die Mapillary Bilder sind im ueberigen alle von mir um eben auch den zustand der Beschilderung zu Dokumentieren. Natürlich kann man herausfinden, welche Insel du bearbeitet hast und wo die Bilder zu finden sind. Ein direkter Link macht es aber deutlich einfacher. In fast allen Fußgängerzonen fahren gelegentlich Fahrzeuge zur Anlieferung, Entsorgung, Aufbau von Marktständen mit Sondergenehmigung. Man kann streiten, ob motor_vehicle=no oder motor_vehicle=private dafür korrekt ist. Das bei highway=residential implizierte motor_vehicle=yes ist auf Spiekerogg definitiv falsch. Woraus ergibt sich das? Wenn das definitiv falsch ist müsste es eine Beschilderung geben. Nein, die weitaus meisten Verbote existieren nur als Gesetz, Verordnung oder Satzung. Wir mappen auch diese Verbote. motor_vehicle=no ist einfach falsch und kaputt. Es gibt genau ein einziges Schild das Kraftfahrzeuge regelt auf Spiekeroog. Wenn es die einzige Zufahrt ist, ist die Beschilderung vollständig. Die SpiekeroogKOM fährt überall mit dem ElektroLKW rum und das ist nach StVO ein Kraftfahrtzeug. Also ist ein motor_vehicle=no einfach falsch. Wenn das alles nach einer Rechtsverordnung passiert müsste da ein motor_vehicle=permissive oder ähnliches drauf. Es besteht ein allgemeines Verbot mit wenigen Ausnahmegenehmigungen. Aus einem Urteilstext des OVG Lüneburg 7. Senat, Urteil vom 21.03.2013: Aufgrund einer Widmung der [Gemeinde] von 1969 ist auf den Spiekerooger Gemeindestraßen der Verkehr mit Kraftfahrzeugen verboten. Die Straßenverkehrsbehörde des Landkreises Wittmund hat dementsprechend ein Kraftfahrzeugverkehrsverbot angeordnet[] Der Landkreis Wittmund erteilte dem Kläger unter dem 20. Dezember 2007 Ausnahmegenehmigungen für seine Fahrzeuge von dem auf der Insel Spiekeroog angeordneten Kraftfahrzeugverkehrsverbot. Eine generelle Erlaubnis besteht also nicht. Aber es ging nicht primär um das mappen von Spiekeroog sondern das vorhalten von regionalen Besonderheiten. Wo findet der gelegenheitsmapper für eine Region mappingregeln für eben diese Besonderheiten. Es bestehen besondere lokale Regeln der Straßennutzung. Man findet sie in fast jedem Artikel über Spiekeroog. Die Mappingregeln gelten allgemein. Auf motor_vehicle=no ändern und einen Link zur Rechtsverordnung im Kommentar des Changesets unterbringen :-) Wo ist die Rechtsverordung? Vermutlich ist die Widmung der Straßen im Archiv der Gemeinde einsehbar. Im Internet habe ich sie nicht gefunden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] regionale mappingregen - Deutsche Inseln e.g.
Am 27.07.2015 um 15:10 schrieb Florian Lohoff: Hi, ich bin auf einer Deutschen Autofreien Insel und hier hat jemand in den letzten 12 Monaten quasi alle Straßen mit einem motor_vehicle=no getagged. Mal davon abgesehen das es eine solche Beschilderung nicht existiert fahren hier ja durchaus die Kommunalen Fahrzeuge und des regionalen Logistikunternehmens mit dem Elektro-LKW - Was ja nach StVO auch Kraftfahrtzeuge sind. Ich halte das tagging für ziemlichen unsinn. Da wird gemapped wie man meint und nicht wie defakto beschildert ist. Da wird auch schnell mal irgendwas zu einem highway=pedestrian was eine völlig normale - wenn auch enge Straße ist (Mit normalem Logistikverkehr). Ich habe jetzt mal einiges korrigiert und habe entsprechend auch Fotos bei Mapillary der Beschilderung vor Ort. Ich habe auf den einschlägigen ggfs. strittigen Wegen mal Notes hinterlassen. Moin, es ist für die Diskussion hilfreich, die Deutsche Autofreie Insel als Spiekerogg zu benennen und einen betroffenen Weg zu verlinken: https://www.openstreetmap.org/way/4470494/history#map=15/53.7681/7.6988 Auch ein Link auf die Bilder bei Mapillary würde helfen. In fast allen Fußgängerzonen fahren gelegentlich Fahrzeuge zur Anlieferung, Entsorgung, Aufbau von Marktständen mit Sondergenehmigung. Man kann streiten, ob motor_vehicle=no oder motor_vehicle=private dafür korrekt ist. Das bei highway=residential implizierte motor_vehicle=yes ist auf Spiekerogg definitiv falsch. Die Reihenfolge erst diskutieren - dann editieren wäre sinnvoll. Ideen? Auf motor_vehicle=no ändern und einen Link zur Rechtsverordnung im Kommentar des Changesets unterbringen :-) Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 um 21:04 schrieb Christoph Hormann: Es geht hier nicht um die Erfassung von Strömungen in einem Gewässer und auch nicht darum, dass irgendjemand behauptet, dass waterway=riverbank ein Tag ohne jede Probleme wäre, sondern darum, dass natural=water + water=river eher einen Rückschritt gegenüber dem riverbank-Tagging darstellt. Die genannten Probleme können aber nur dann auftreten, wenn man natural=water ohne water=* verwendet. Da die Angabe von water=* deutlich differenzierter als das alte Schema ist, werde ich diese Möglichkeiten (zumindest teilweise) nutzen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 um 06:25 schrieb Markus: Habe hier eine merkwürdige Änderung entdeckt: http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway=riverdiff=nextoldid=1176333 Das würde ein weltweites Tagging-Schema zerstören... Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. Das neue Schema ist mehr als ein Jahr alt, viele Flüsse sind schon so erfasst. Wenn du die Änderung erst jetzt entdeckst, ist die Zerstörung offenbar nicht bedeutend. Welche Anwendung ist überhaupt betroffen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 10:32, schrieb Christoph Hormann: On Friday 29 May 2015, Stephan Wolff wrote: Das würde ein weltweites Tagging-Schema zerstören... Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. Das ist genau der Knackpunkt - es mag wie in vielen anderen Bereichen auch Grenzfälle geben. In der überwiegenden Zahl der Fälle ist die Unterscheidung jedoch vor Ort eindeutig möglich und für die meisten Datennutzungen die über einfache Karten nach dem Schema 'alles Blau malen' hinaus gehen ist diese Unterscheidung sehr wichtig und sollte deshalb idealerweise bereits im primären Tag erfolgen. Welche Anwendungen sind denn konkret betroffen? Dies ist bei waterway=riverbank für stehend/fließend der Fall, nicht jedoch für natürlich/künstlich (waterway=riverbank wird traditionell auch für Kanäle verwendet). Eine gerichtete Strömung über ein Flächenobjekt zu beschreiben, ist ohnehin schwierig. Wenn man waterway=riverbank auch für Kanäle verwendet, ist es eher die Unterscheidung rundlich/länglich. natural=water + water=* erlaubt generell auch das undifferenzierte Tagging von Wasserflächen, was auch in über 90 Prozent der Fälle so gemacht wird - siehe http://taginfo.openstreetmap.org/tags/natural=water#combinations und der Umstieg von waterway=riverbank auf natural=water + water=river wird dies verstärken, denn das water=river wird dann oft - weil scheinbar unnötig - weggelassen. Insgesamt eine schlechte Entwicklung. Vielleicht setzt sich water=* auch langsam durch und man kann zwischen Flüssen, Altarmen, Kanälen, Seen und Teichen unterscheiden. Das wäre eine sehr gute Entwicklung. Dass waterway=riverbank unschön ist, weil es eigentlich ein Linien-Tag aus der vor-Multipolygon-Zeit ist und weil es - siehe oben - keine Unterscheidung Fluss-Kanal ermöglicht steht außer Frage. Im Proposal zur Änderung wird das Thema Unterscheidung fließende/stehende Gewässer jedoch leider nicht thematisiert. Gab es diese Unterscheidung bislang? Dann hätte man waterway=riverbank für Kanäle verbieten müssen. Ich würde deshalb grundsätzlich empfehlen, im Allgemeinen bei der Verwendung von waterway=riverbank für Flüsse zu bleiben und bei der Verwendung von natural=water *immer* ein water=* zu taggen. Dem zweiten Teil kann ich zustimmen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank
Am 29.05.2015 10:02, schrieb Martin Koppenhoefer: Da die Übergänge zwischen den Wasserflächen von Flüssen, Kanälen und Seen (im doppelten Wortsinn) fließend sind, finde ich das neue Schema logisch und praktikabel. verstehe ich nicht. Es ist doch egal ob man water=river oder waterway=riverbank taggt, wo der Fluss aufhört und der See anfängt muss man so oder so entscheiden. Es ist nicht einmal definiert, wann man eine Verbreiterung eines Flusses als See bezeichnet. Wenn es weder eine klare inhaltliche noch räumliche Grenze gibt, finde ich die Verwendung des gleichen Haupttags mit Differenzierung im Subtag logisch. Das neue Schema ist mehr als ein Jahr alt, viele Flüsse sind schon so erfasst. Wenn du die Änderung erst jetzt entdeckst, ist die Zerstörung offenbar nicht bedeutend. Welche Anwendung ist überhaupt betroffen? waterway=riverbank komplett rausnehmen aus dem Fluss-Artikel finde ich auch nicht gerade hilfreich, grenzt in der Form für mich an Vandalismus, immerhin gibt es nach wie vor 283K Objekte, die diesen Tag haben, water=river sind gerade mal 10.700 vorhanden (nach wie Du selbst schreibst, über einem Jahr). Zum Wiki-Artikel gebe ich dir recht. Man darf waterway=riverbank nicht einfach streichen. Für die Renderer und anderen Anwendungen scheint die Umstellung aber problemlos zu sein. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenspende Naturschutzgebiete in SH
Moin, ich habe vom einem Mitarbeiter des Landesamts für Landwirtschaft, Umwelt und ländliche Räume Schleswig-Holstein (LLUR) einen Datensatz mit allen NSGs, FFH- und Vogelschutzgebieten in SH zur Nutzung in OSM bekommen. Weitere Informationen dazu habe ich ins Forum geschrieben: http://forum.openstreetmap.org/viewtopic.php?id=30181 Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 25.01.2015 21:02, schrieb kelvan bugmenot: uU etwas OT: Was mir auch klar wurde bei dem Gespräch ist, dass die aktuellen aeroway tags etwas nunja rudimentär und teilweise unpräzise sind. Eine Sache scheint für Flughäfen (zumindest für den Bereich mit dem ich gesprochen habe) essentiell zu sein, die Unterscheidung zwischen taxiway und taxilane. Der Unterschied hier ist ca wie zwischen einer Landstrasse und einer Strasse am Parkplatz. Habe dazu ein Proposal im Wiki angelegt: https://wiki.openstreetmap.org/wiki/Proposed_features/taxilane Nachteile deines Vorschlags: - nicht kompatibel zu bestehenden Daten - man erkennt nicht, nach welcher Definition ein taxiway erstellt wurde - ohne die Kenntnis der Trennlinie kann man keine korrekten Daten erstellen Sinnvoller wäre m.E. ein Zusatztag zu taxiway, das die Zuständigkeit (ATC oder Airport) angibt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Entscheidungsfindung und Toleranz bei OSM
Für alle, die im Forum nicht mitlesen: Während im Wiki [1] noch über den Sinn der associatedStreet-Relationen (mit bislang unklarem Ausgang) abgestimmt wird, wird im deutschen Forum im Thread Qualitätssicherung associatedStreet-Relationen dazu aufgerufen, alle diese Relationen in Deutschland zu löschen. Mich erschreckt die fehlende Toleranz und der fehlende Respekt vor den Daten anderer Mapper. Ich hoffe, dass die Entscheidungsfindung durch Löschen von Daten nicht zur Regel in OSM wird. [1] https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet [2] http://forum.openstreetmap.org/viewtopic.php?id=29816p=1 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungsfindung und Toleranz bei OSM
Am 25.01.2015 um 20:40 schrieb Frederik Ramm: On 01/25/2015 06:12 PM, Stephan Wolff wrote: Während im Wiki [1] noch über den Sinn der associatedStreet-Relationen (mit bislang unklarem Ausgang) abgestimmt wird, wird im deutschen Forum im Thread Qualitätssicherung associatedStreet-Relationen dazu aufgerufen, alle diese Relationen in Deutschland zu löschen. Ich glaube, da gibst Du die Diskussion im Forum unzureichend wieder. Ein Satz kann keine Diskussion wiedergeben. Welche Information fehlt dir? Dass von korrekten associatedStreet-Relationen vor dem Löschen der Straßenname übernommen wird? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Am 23.01.2015 10:40, schrieb André Riedel: Am 21. Januar 2015 um 14:00 schrieb André Riedel riedel.an...@gmail.com: Fragt man Overpass findet man ganze verschiedene Interpretationen von Wasserwegen mit dem Name Mühlgraben: Durch Begriff Mühlbach hat sich die Nutzung von stream stark vermehrt. In Norddeutschland dürften Mühlengraben und Mühlenbach die häufigeren Namensvarianten sein. Persönlich würde ich stream nur dann verwenden, wenn man darüber springen kann. drain und river würde ich komplett ausschließen. river und stream unterscheiden sich doch nur in der Breite. Warum sollte man das eine akzeptieren und das andere ausschließen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mühlgraben
Moin! Am 21.01.2015 um 14:00 schrieb André Riedel: Hallo, wie trägt man einen Mühlgraben ein? Ich nehme an, du meinst den Zufluss zu einer historischen Wassermühle. Wassermühlen sind dort entstanden, wo man einen Bach aufstauen konnte und genügend Gefälle für ein Wasserrad hatte. Bei hinreichender Wassermenge kam man auch ohne Mühlenteich aus. Bäche werden als waterway=stream getaggt, auch die Abschnitte, die ein künstliches Gewässerbett haben (was in Deutschland auf einen großen Teil der Flüsse und Bäche zutrifft). canal ist laut englischem Wiki auf Schifffahrtkanäle und sehr große Bewässerungskanäle beschränkt: Use waterway=canal for man-made waterways used for transportation or also for the largest waterways created for irrigation purposes. Im deutschen Wiki fehlt leider die Größenangabe. Dafür wird ausdrücklich gesagt Kanalisierte Flüsse werden mit waterway=river bezeichnet. Das sollte entsprechend auch für kanalisierte Bäche gelten. Es erscheint mir sinnlos, Schifffahrtkanäle und Mühlgräben mit demselben Tag zu bezeichnen. Man kann ein solches Tag nicht sinnvoll auswerten. Jede Darstellung durch den Renderer wäre für eines der Beispiele völlig unangemessen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrageplattform
Am 21.01.2015 10:47, schrieb Harald Hartmann: Nachdem ich ein bisschen Zeit hatte, und mich mal wieder ein bisschen mit PHP beschäftigen, sowie auch einmal die OAuth Authentifizierung ausprobieren wollte, ist als Prototyp die Umfrageplattform für OpenStreetMap (http://osm.haraldhartmann.de/umfrage) entstanden. Technisch finde ich die Umfrageplattform sehr gut gelungen (bis auf das einzelne Absenden der Fragen). Die Darstellung der Ergebnisse abhängig von der Erfahrung der Mapper bringt einen Zusatznutzen. Ich habe in der Umfrageplattform zwei Fragen gestellt, die immer wieder für Diskussionen sorgen - so zumindest mein Eindruck nach fast einem Jahr aktiven Dabeiseins. Die Fragen sind auch so gestellt, dass sie fragen, wie man es aktuell macht, unabhängig von der Lehrmeinung, Wiki oder Diskussionen Der Nutzen einer Umfrage hängt sehr davon ab, ob die Fragen und Antwortmöglichkeiten neutral und verständlich formuliert sind. Das ist bei den zwei Fragen von Harald der Fall. Manche Taggingfrage wird nicht so einfach zu formulieren sein. Wertende Begriffe wie überflüssig oder verbessern oder Sarahs Frage Landuse und Strassen verkleben, würden eine Umfrage nutzlos machen. Die Frage wie man es aktuell macht könnte man besser durch eine Analyse der Changesets der letzten Monate beantworten. Interessant ist doch eher die Frage, welche Variante man für die Zukunft bevorzugen würde (insbesondere wenn es um neue Ideen geht). Bei mehr als zwei Antwortoptionen gibt die Auswahl einer Variante eine Meinung nur teilweise wieder. Ein Nutzer könnte Option A und B gut finden, C akzeptabel und D falsch. Vielleicht könnte man besser jede Option auf einer Skala zwischen voller Zustimmung und voller Ablehnung einzeln bewerten. Wie soll die Umfrageplattform organisiert sein? Wenn ein Moderator oder ein kleines Team Themen auswählt und daraus Fragen neutral formuliert, wäre eine solche Plattform sehr hilfreich. Wenn jeder Umfragen beliebig formulieren und zur Abstimmung bringen kann, wäre das m.E. kein Gewinn gegenüber den bisherigen Diskussionen. Je nachdem wie das Feedback (bitte ausschließlich über das Feedbackformular auf der Seite) ist, würden sich bestimmt Mittel und Wege finden lassen, den Prototyp auszubauen. Wo ist das Feedbackformular? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start-/Landebahn
Am 12.01.2015 17:37, schrieb Martin Koppenhoefer: Am 12. Januar 2015 um 11:36 schrieb Stephan Wolff s.wo...@web.de: Einen way. Eine Piste ist gerichtet, Tags wie incline=* wäre für Flächen sinnlos. Die Breite lässt sich problemlos als width beschreiben. Das deutsche Wiki zu aeroway=runway ist eindeutig, das englische leider nicht. man kann auch durchaus in Flächen eine Richtung erkennen, echte ways gibt es sowieso nur in der db und der Mathematik, aber nicht im echten Leben. Mit diesem Argument könnte man auch alle Mittellinien von Straßen und Flüssen durch die Fläche ersetzen. Für viele praktische Anwendungen hat die Abstraktion auf eine Linie aber viele Vorteile. Im Gegensatz zu den meisten Straßen und Flüssen mit wechselnden Breiten wird eine Piste durch die Mittellinie und Breite exakt definiert. Um die Breite problemlos als width zu beschreiben, muss man sie erstmal kennen / messen, was bei Landebahnen oft nicht praktisch geht. Die Breite ist vom Betreiber definiert. Man kann sich leicht der Wikipedia oder einer Luftfahrtpublikation entnehmen. Die Fläche der Piste ist natürlich nicht einfacher zu erkennen. Gerade an Übergängen zu den Rollwegen können dabei leicht Fehler entstehen. Einen incline-tag halte ich hier auch für wenig sinnvoll, man kann aber z.B. die Höhen einzelner Punkte angeben, was dann auch deutlich mehr Informationsgehalt hat als der incline-tag. Ausser an Treppen nutze ich den eigentlich nie, Auch die Bahnneigung ist ein offizieller Wert, den die Piloten benötigen, um die Startstrecke zu berechnen. Man kann sie leicht aus einer Liste übernehmen. Die Höhen einzelner Punkte dürften kaum in der nötigen Genauigkeit zu gewinnen sein. Grundsätzlich finde ich es sinnvoll, die allgemein üblichen Daten auch in OSM zu verwenden. Meist sind dies die Werte, sie auch praktisch benutzt werden. Als Mensch kann ich mit Länge und Breite einer Piste etwas anfangen, mit der Koordinatenliste eines Polygonzugs nicht. Ob die Höhen einzelner Punkte mehr Information als die Bahnneigung hat, ist irrelevant, wenn ich die Neigung in ein Formular eintragen muss. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geodaten des Bundes
Moin, gibt es etwas Neues zur Nutzung der Geodaten des Bundes in OSM? Ich habe eine Aussage von Joachim Kast aus dem letzten Oktober gefunden: Ich habe im Vorfeld der letze Woche stattgefunden INSPIRE-Konferenz des BMI die Beauftragte der Bundesregierung für Informationstechnik gebeten, zu überprüfen, ob der Bund das schon erwänte Berliner Modell der Namensnennung anwenden könnte. Wegen der derzeit laufenden Koalitionsverhandlungen rechne ich auch nicht mit einer schnellen Antwort. Es scheint absurd, dass der Bund und OSM die gleiche Bedingung an die Nutzer stellen und die Lizenzen deshalb nicht kompatibel sind. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten des Bundes
Am 27.05.2014 20:50, schrieb Joachim Kast: Ich bin im Juni/Juli zu Workshops beim Lenkungsgremium GDI-DE und beim BMI eingeladen. Dabei werde ich natürlich (wie immer) auf die verzwickte Situation der Namensnennung sowie deren Lösung in Berlin und NRW hinweisen. Das wäre moralisch einfacher, wenn OSM umgekehrt genauso flexibel wäre. Wenn diese Termine vorbei sind, werde ich hier über den aktuellen Stand berichten. Danke für dein Engagement. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten
Am 20.05.2014 16:17, schrieb Falk Zscheile: Am 20. Mai 2014 10:13 schrieb Sven Anders s...@anders-hamburg.de: source:name=Straßenverzeichniss Hamburg vom 07.05.2009 source:name=Schild am Eingang des Kleingartens. Dann sollte man das aber so weit abstrahieren, dass eine Maschinenlesbarkeit gewährleistet ist! Sonst hält sich der Mehrwert des zusätzlichen Tags doch sehr in Grenzen. Ja, die Beispieltexte sind nicht nutzbar. Wenn man abstrahiert source:name=offical, local [was weiß ich] hätten auch die Leute, die Straßenlistenauswertungen machen oder eben Navigationssoftware bauen (Ausgangsproblem) etwas davon, weil sie bei der Datenauswertung Besonderheiten identifizieren und eine Lösung erarbeiten können. Für einige Anwendungen wäre diese Information sicherlich nützlich, aber: - es gibt fast 74.000.000 way mit highway in der Datenbank. - viele Mapper werden wohl die Mühe scheuen, viel Arbeit in eine Zusatzinformation von geringem Nutzen zu investieren. - die meisten Mapper können gar nicht entscheiden, vom wem Name auf dem Straßenschild festgelegt wurde. Insbesondere in den Problemfällen (Militar-, Uni oder Kleingartengelände) ist es vor Ort oft nicht erkennbar. Praktisch ist die Idee wohl nicht umsetzbar. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettet die Kleingarten-Wegenamen
Am 19.05.2014 14:33, schrieb Wolfgang Hinsch: Praktische Folge: Der (z.B.) Taxifahrer bekommt entweder eine Hasskappe, weil er den Namen in seinem OSM-Navi nicht findet, oder weil er den Namen 10x findet. Zum Vergleich: Google findet für Dahlienweg Hamburg fast 350.000 Ergebnisse und ist trotzdem nicht unbrauchbar. Wo liegt das Problem, wenn die OSM-Ergebnisse nach der Bedeutung der Straße (Hauptstraße...Spielstraße, Feldweg, Pfad) sortiert werden? Dann ist die amtlich benannte Straße fast immer an erster Stelle. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
Moin, die Definitionen zu Namen im Wiki sind stabil und zumindest zwischen deutscher und englischer Version recht konsistent: name: allgemeine Bezeichnung/ Standardname/ common default name name ist nur der Name, keine Kategorie, Typ, Beschreibung name is the name only not categorie, type, description loc_name: lokale Bezeichnung/ slang name or unofficial-sounding In einer umfassenden Datenbank kann es keine für alle Anwendungen optimale Datenstruktur geben. Eine Änderung der Definition für eine spezielle Anwendung ist kaum durchsetzbar (und m.E. auch nicht sinnvoll). Den größten Nutzen erhalten wir, wenn sich alle an die Definition im Wiki halten. Wegenamen in Kleingärten gehören nach der oben genannten Definition nach name während Parzellennummern nach ref (reference numbers or codes) gehören. Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber nicht in der Karte. Nein, die Darstellung in einer Karte sollte kein Argument sein. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
Am 19.05.2014 16:05, schrieb Martin Koppenhoefer: Am 19. Mai 2014 15:50 schrieb Stephan Wolff s.wo...@web.de: während Parzellennummern nach ref (reference numbers or codes) gehören. was die Namen angeht bin ich bei Dir, aber aus dem Wiki oder der Praxis was für ref abzuleiten halte ich schon für gewagt. Man könnte sicherlich ref verwenden, weil es sehr unspezifisch definiert ist und auch in der Praxis sehr oft verwendet wird, wenn es irgendwelche Nummern zu taggen gibt, aber man könnte sich da genauso gut auch was Spezifischeres für Parzellennummer denken, mit dem Vorteil, im Zweifel nicht raten zu müssen, welche Art Nummer nun gemeint ist. Ja, das war unsauber formuliert. Eine Parzellennummer ist kein name, eine Parzellennummer passt zur Definition von ref, für Kleingartenparzellen dürfte dies die allgemein übliche Nummerierung sein (während es für Straßen, Brücken, Grundstücke etc. mehrere Systeme gibt) und es wird im Wiki Tag:allotments=plot so vorgeschlagen. Daher ist ref zumindest ein geeignetes Tag. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg) Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist noexit nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen? Sollte man alle Werte außer yes und no entfernen oder ist eine Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg) Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist noexit nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen? Sollte man alle Werte außer yes und no entfernen oder ist eine Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Moin, mich erschreckt die kompromisslose Haltung und die teils aggressive Wortwahl als Reaktion auf eine höflich geschriebene Bitte. Ich habe in einigen Fällen darauf verzichtet, mir bekannte Fakten in OSM einzutragen. Einen Seeadlerhorst und den stationären Bauwagen eines Waldkindergartens habe ich gar nicht erfasst, ein außerhalb des Ortes gelegenes Vereinsheim ohne Beschilderung nur mit building=yes. Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. Hochsitze haben m.E. nur eine geringe Relevanz, da sie nicht zum Gebrauch für die Allgemeinheit bestimmt sind und wegen der getarnten Bauweise und relativ häufiger Standortänderungen auch schlecht als Wegmarke geeignet sind. Falls es in einer Region zu starkem Vandalismus an Hochsitzen gekommen ist oder der Anfragende sogar plausibel machen kann, dass OSM-Karten für gezielte Beschädigung genutzt wurden, könnte ich mir eine Entfernung dieser Daten vorstellen. Don't be evil. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz bei Geodaten?
Am 19.02.2014 20:00, schrieb Steffen Wolf: Hmm, ich les grad noch die Erklaerungen zu den einzelnen Punkten: Massstab 1:5000, da werden in der Deutschen Grundkarte Flurstuecksgrenzen und einzelne Hausnummern dargestellt. Das sieht der Leitfaden auch nicht als bedenklich an. Das beruhigt mich etwa in Hinblick auf unsere Hausnummernsammelei. Aber eigentlich gehen wir ja weiter und stellen auch noch die Haeuser dar. Dazu sagt der Leitfaden aber nix. Ich würde das so verstehen: Hausumrisse tauchen schon auf Karten ab etwa 1:50.000 auf und sind unproblematisch. Selbst mit den Zusatzinformationen der Hausnummern und Flurstücksgrenzen der Deutschen Grundkarte ist es unbedenklich. Auf problematische Zusatzinformationen (Hier wohnt der Prominente ...) können und sollten wir m.E. verzichten. Gruß an meinen (fast) Namensvetter Stephan Wolff ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PV-Anlage
Am 06.12.2013 17:04, schrieb chris66: Am 06.12.2013 16:54, schrieb Fabian Schmidt: OSM überrascht mich immer wieder: http://www.openstreetmap.org/#map=17/51.018/13.804 Mich überrascht es negativ. Einen Mehrwert gegenüber einem Gesamtobjekt kann ich nicht erkennen, aber solche Spielereien schaden allen bestehenden Auswertungen des Tags, ob als Listen oder Symbolen in Karten. Dass die 141 Solarzellen einzeln gemappt sind (laut Wiki wohl zulässig)? Die Definition im Wiki ist leider unbrauchbar: A generator [] is a device that converts one form of energy to another. Darunter würden auch die Kraftwerkskessel (Kohle zu Dampf), Motoren, Heizungen und alle elektrischen Verbraucher fallen. Die Analogie zum Generator im Kraftwerk wäre eher der Wechselrichter im Solarkraftwerk. Man könnte nur den Wechselrichter oder die zusammengeschalteten Solarmodule mit Wechselrichter als einen generator erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Definition Schule
Moin, amenity=school wird teilweise für Tanzschulen, Sprachschulen, Seminare oder Hörsäle/Vortragsräume benutzt. Das englischsprachige Wiki beschreibt nur klassische Schulen: Use amenity=school to identify a place where pupils, normally between the ages of about 5 and 18 are taught under the supervision of teachers. This includes primary and secondary schools Das deutsche Wiki ist leider nicht so eindeutig: Auf talk-de gab es im März 2010 eine längere Diskussion über die Definition von Schule im Sinne des hier beschriebenen Tags. Im wesentlichen standen sich zwei Meinungen gegenüber: Zum einen wurde Schule als Bildungseinrichtungen im weitesten Sinne verstanden (Gymnasium, Fahrschule, Segelschule etc.). Zum anderen sollten unter Schule nur die klassischen Schulen (Grundschule, Hauptschule, Realschule, Gymnasium, Berufsschule) verstanden werden... Besteht die Meinungsverschiedenheit noch oder können wir die Definition des englischen Wikis übernehmen? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 21.11.2013 17:42, schrieb Martin Koppenhoefer: Am 21. November 2013 17:23 schrieb Stephan Wolff s.wo...@web.de: Meine Argumentation ist, dass Einrichtungen für Menschen anders als Objekte mit ähnlicher Bezeichnung für Pflanzen und Tiere erfasst werden. wobei es hier ja eher um eine unspezifische Eigenschaft (Windschutz, Regenschutz, Unterstand und Schutzmöglichkeit) geht. In der Not wird man (nach Rücksprache mit einem Arzt) z.B. vermutlich auch ein Medikament für Tiere nehmen, wenn es keine Alternative gibt. Das passiert, wenn der Tierarzt als amenity=doctors erfasst wird ;-) Deinen Grundsatz von Menschen als Gegensatz zu Pflanzen und Tieren finde ich ein bisschen haarig. Wenn ich Menschen, Tiere und Pflanzen in 2 Gruppen packen müsste, wären bei mir die Tiere eher bei den Menschen als bei den Pflanzen, weil die Anforderungen und Bedürfnisse doch näher liegen sollte. Ich will Hundeschulen und Baumschulen nicht zusammenfassen. Es können mehr als 2 Gruppen bzw. Tags sein. Eine Baumschule, in der Bäume erzogen werden, fällt nicht unter amenity=school. Habe noch nie gehört, dass in einer Baumschule Bäume ERzogen werden. Dort lernen die Bäume gerade zu stehen. Duden zu erziehen: 2. (Gartenbau) (Pflanzen) [heran]ziehen Einen Felsüberhang würde ich auch nicht als shelter erfassen, eine Höhle mit Bank schon. wieso? Für mich macht das Dach und ggf. der umliegende Schutz den shelter aus, keineswegs die Sitzbank. Wenn man shelter so umfassend definiert, müsste man alle Carports, Vordächer und viele Balkone und Brücken ebenfalls so erfassen. Unter amenity (Wiki: Covering an assortment of community facilities...) wäre es trotzdem falsch. Nochmals die Frage: warum nicht building=field_shelter? das kann man ja machen (oder building=roof), schließt aber das amenity nicht aus. Dann besteht Einigkeit, dass building=field_shelter ein geeignetes Tag ist, und Uneinigkeit zu amenity=shelter. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 21.11.2013 08:49, schrieb NopMap: Stephan Wolff wrote Ein Viehunterstand verhält sich zum Unterstand wie die Hundeschule zur Schule oder der Krötentunnel zum Fußgängertunnel. In OSM verwenden wir dafür unterschiedliche Tags. Die Argumentation ist nicht konsistent. Um Deine Metapher aufzugreifen: Ein Unterstand verhält sich zu einem Felsüberhang wie eine Schule zur Baumschule.Es ist nicht von Menschenhand als Schutz gebaut wie die übrigen Shelter und es sagt nichts darüber aus wieviel Kletterei nötig ist um ihn zu erreichen. Meine Argumentation ist, dass Einrichtungen für Menschen anders als Objekte mit ähnlicher Bezeichnung für Pflanzen und Tiere erfasst werden. Mit Bauart und Material hat es nicht zu tun. Eine Baumschule, in der Bäume erzogen werden, fällt nicht unter amenity=school. Eine Schule für Kinder unter einem großen Baum dagegen schon. Einen Felsüberhang würde ich auch nicht als shelter erfassen, eine Höhle mit Bank schon. Nochmals die Frage: warum nicht building=field_shelter? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Restaurant, zwei Eingaenge
Moin! Am 14.11.2013 13:12, schrieb Michael Neumann: habe momentan folgendes Problem, wie mappe ich ein Restaurant mit zwei Eingaengen getreu dem Motto http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element ? Nach dem KISS-Prinzip als Punkt in der Mitte des Gastraumes. Die Wahl des Eingangs hängt auch davon ab, ob man zum Saal, zur Bar oder zur Außenterrasse will. Auf den letzten Metern kann ein Router ohnehin nicht helfen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 20.11.2013 11:16, schrieb Martin Vonwald: Ein Unterstand ist ein Unterstand. Ein Viehunterstand verhält sich zum Unterstand wie die Hundeschule zur Schule oder der Krötentunnel zum Fußgängertunnel. In OSM verwenden wir dafür unterschiedliche Tags. Wenn ich im Gebirge von einem Unwetter überrascht werde, ist es mir herzlich egal ob das Dach über meinem Kopf auch explizit für mich gebaut wurde oder nicht - Hauptsache trocken. Das ist keine Begründung den Viehunterstand als amenity einzuordnen. Die meisten Objekte mit Dach sind als building erfasst. Das passt auch in diesem Fall. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 19.11.2013 12:15, schrieb NopMap: amenity=shelter + shelter_type=field_shelter klingt genau passend. Ich finde amenity=shelter völlig unpassend. Seit 2006 ist das Tag als Wetterschutz für Menschen definiert. Jetzt soll ein Anfang 2013 auf einer Unterseite eingetragenes Zusatztag die Bedeutung aufheben. Damit provoziert man Missverständnisse ähnlich wie bei disused=yes. Wer bei Regen eine Schutzhütte sucht, möchte nicht vor einem eingezäunten Viehunterstand landen. Ich würde den Viehunterstand eher als Gebäude denn als nützliche und wichtige Einrichtungen (amenity) sehen. Warum nicht building=field_shelter? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 19.11.2013 20:13, schrieb NopMap: Die alten Shelter unterscheiden sich bereits deutlich voneinander, Grillpavillion, Picknickplatz oder Schutzhütte machen einen großen Unterschied. Von daher ist es jetzt schon nötig, für eine sinnvolle Auswertung den Typ zu berücksichtigen. Das sind Freizeiteinrichtungen mit Schutzdach. Manche Anwendungen werden den Untertyp auswerten, andere werden nur ein Symbol für Shelter zeichnen. Bei 60% ist shelter_type nicht einmal benutzt. Ein landwirtschaftliches Nutzgebäude passt nicht dazu. Laut taginfo wird shelter_type=field_shelter auch nur 12 mal verwendet. Wir sollten dafür nicht ein etabliertes Tag umdefinieren. Wenn es Dir egal ist ob es eine Berghütte oder ein Bushäuschen ist und es Dir nur um ein Dach geht, dann ist Dir auch mit einem solchen Unterstand gedient. Viele Objekte können als Regenschutz dienen. Ein Unterstand für Rinder hinter einem Stacheldrahtzaun wäre meine letzte Wahl. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
Moin, für eine brauchbare Fahrradkarte genügt es offensichtlich nicht, wenn Straße und Radweg einzeln erfasst sind (siehe Mapnikkarte mit je nach Zoomlevel sichtbaren, halb überdeckten oder gar nicht sichtbaren straßenbegleitenden Radwegen). Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Mein Garmin-GPS hat mich teils vom Radweg auf die Straße und zurück auf den Radweg geschickt, um wenige Meter in der Kurve abzukürzen. Das Lübecker-Modell mit dem Tag cycleway:*=sidepath, den Relation für eigenständige Radwege an Straßen und den sidepath:refname=* mit willkürlich gewählten Pseudonamen finde ich seltsam. Ich teile die von Rainer genannten Kritikpunkte. Wir sollten uns endlich eine bessere Lösung überlegen. Offenbar braucht man die Information, ob ein Radweg straßenbegleitend oder eigenständig ist, und umgekehrt, ob zu einer Straße ein Radweg als eigener way existiert. Dafür wäre je ein einfaches Tag ausreichend. Brauchen wir eine Relation, die alle Wegsegmente (Straße und Radweg) zusammenfasst? Brauchen wir eine explizite segmentweise Zuordnung straßenbegleitender Radwege zur Straße? Für straßenbegleitende Fußwege sollte das Modell natürlich auch anwendbar sein. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abkürzungen (bei Sportvereinen) im Namen
Am 14.10.2013 17:51, schrieb fly: Am 14.10.2013 17:32, schrieb Martin Koppenhoefer: Am 14. Oktober 2013 17:26 schrieb fly lowfligh...@googlemail.com: Ich habe bisher diese Abkürzungen ausgeschrieben und wenn überhaupt name:de mit der Abkürzung geschrieben. Im Süd-Süd-Westen bin ich da aber wohl allein auf weiter Flur. Auch in Norddeutschland ist diese Interpretation sehr selten :-) M.E. sind da die meisten Vereine vor allem unter der Abkürzung bekannt, teilweise ist auch weitgehend unbekannt, was das überhaupt ausgeschrieben bedeutet, von daher finde ich die Abkürzung OK, ggf. könnte man beides eintragen (also entweder zusätzlich short_name oder zusätzlich official_name). +1 und was ist nun entscheidend oder gar keine name=* und nur short_name=* plus official_name=* mit den jeweiligen Übersetzungen ? Die übliche Namensform nach name, bei Bedarf zusätzlich short_name, official_name oder alt_name. bei Ortsbezeichnungen wird es noch spannender, da meistens nicht genug Platz auf Schildern und Karten ist, wird in der Regel abgekürzt. Allerdings wenn ich nun oral nach dem Weg frage wird der Name komplett ausgesprochen. Auch hier sollte der am häufigsten benutzte Name als name erfasst werden. Das muss nicht der offizielle Name sein. Statt Freie und Hansestadt Hamburg spagt man meist nur Hamburg. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
Moin, ein Server, der die gesamte Historie von OSM enthält und den Download der Daten eines (kleinen) Gebiets zu einem wählbaren Datum erlaubt, wäre für solche Probleme sehr nützlich. Damit könnte man auch die zeitliche Entwicklung eines Gebiets oder die Veränderungen durch ein Changeset visualisieren. Gibt es Überlegungen, so etwas einzurichten? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
Am 02.10.2013 16:35, schrieb fly: Wäre echt super, würde aber auch ganz schön viel Speicherplatz benötigen oder dachtest Du an live-rendern ? Nein, ich dachte nur eine eine API mit Datumsangabe. Der Server müsste nur den full history dump effizient filtern. Die Daten könnte man dann im Editor analysieren oder mit Maperitive rendern. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, PSG
Am 24.09.2013 19:02, schrieb Markus: http://wiki.openstreetmap.org/wiki/User:Imagico/Coastline_Mapping_from_Landsat_Scenes Super Arbeit - herzlichen Dank! +1 Gibt es eine Möglichkeit, die Teile der Küstenlinie zu identifizieren, die *Sägezahn* -Form haben? also möglicherweise alte PGS-Importe sind? Und diese dann auf einem Layer farbig anzuzeigen, source=PGS und source=PGS(could be inacurately) (zusammen 4,3 Millionen mal verwendet, davon 90% Nodes) deuten stark auf PGS-Importe hin. Im Zweifel kann man zusätzlich auf Version=1 prüfen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zensur in OSM?
Moin! Am 21.09.2013 08:40, schrieb Jörg Frings-Fürst: Seit wann unterliegen Holzstapel dem Datenschutz? Das tun sie nicht. Eine kleine Fläche, die vermutlich temporär zur Holzlagerung genutzt wird, als name = Holzstapel zu erfassen, ist aber auch nicht korrekt. Seit wann ist es untersagt die aufgestellten Schilder mit den Zuordnungen meiner Autos - Parkplätze zu mappen? Ein access=private ist besser als das Kennzeichen als Name des Parkplatzes. Ein Router versteht nicht, was der Name bedeutet. Hausnummern am Eingang -- auch Datenschutz? Eine Nummer am Gebäude genügt. Firmenname gelöscht -- bestimmt kein Datenschutz? Oder doch? Meinst du JFF-Software? Er hat daraus einen POI im inneren des Gebäudes gemacht. Die Gleichsetzung von Gebäude und Firma finde ich allgemein unschön, bei building = apartments mit anderen Mietern ist es unpassend. Das ist eine Verbesserung. So geht das nicht. wambacher hat auch sonst nur Fehler korrigiert. Er hätte zumindest den Kommentar Datenschutz und andere Verbesserungen nennen sollen. ;-) Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Moin! Am 20.09.2013 09:11, schrieb Markus: kann ein geschlossener way Linie und Fläche zugleich sein, bei Inseln natural=coastline und place=island Die Küstenlinie bezeichnte ja - eine Linie (die Wasser und Land trennt) Ja. - die Fläche einer Insel oder Kontinentes Nein. Es heißt nicht nur coastLINE und ist als way im wiki definiert sondern die einzelnen Objekte sind (bis auf kleine Inseln) nicht geschlossen. Es gibt nur die Bedingung, dass alle ways mit natural=coastline als Gesamtheit eine Fläche definieren müssen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linie und Fläche zugleich
Danke für die Anmerkungen. Ich werde Inseln als Multipolygon erfassen. In JOSM beschränkt sich der Mehraufwand auf die Tastenkombination Strg+Alt+A. In DE:Tag:place=island habe ich eine entsprechende Anmerkung eingefügt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Linie und Fläche zugleich
Moin, kann ein geschlossener way Linie und Fläche zugleich sein, wenn er je ein tag hat, das nur als way und nur als Fläche definiert ist? Ist dann definiert, ob weitere tags die Linie oder die Fläche beschreiben? Konkret habe ich das Problem bei Inseln. Ist ein geschlossener way mit natural=coastline und place=island korrekt oder sollte der way nur natural=coastline und ein multipolygon (mit diesem way als outer) place=island tragen? In letzterem Fall wäre auch ein name-tag eindeutig der Fläche zuzuordnen. Die Frage ist nicht auf Inseln beschränkt. Auch ways mit landuse=* und barrier=fence und andere Kombinationen gibt es häufig. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, wood
Am 17.09.2013 21:04, schrieb Martin Koppenhoefer: meine Präferenz wäre, die einzelnen Baumflächen zu zeichnen und ggf. den Felsen als eigenes Objekt, wenn überhaupt. Ist schon mehr Arbeit, aber auch mehr Infos (sonst kann man eben auch keine Karte machen auf der man sehen kann, wo die Bäume wachsen, und zu wissen, wo die Bäume wachsen und wo nicht, lässt wiederum andere Rückschlüsse zu, die man dann eben auch nicht machen kann). Alle Baumgruppen einzeln zu erfassen ist zumindest von Hand nicht praktikabel. Zudem unterliegt der Baumbewuchs einem steten Wandel. Wenn der Wind eine Baumgruppe umwirft, bleibt oft eine fast saubere Felsmulde zurück, deren neue Begrünung Jahrzehnte dauert. Ich halte die Information, ob eine Insel Baumbewuchs hat, für wichtig (nicht nur zur Zeltplatzsuche), den Informationsgewinn der Einzelflächen aber für den Aufwand zu gering. Bei dichterem Bestand wäre vielleicht auch natural=woodland für die Gesamtfläche ein brauchbarer tag (also dünner als Wald, aber dichter als nur einzelne Bäume). Wird das Wort woodland so verstanden? Ich hätte es als Wald übersetzt. Dann fehlt immer noch die Information, dass die übrige Oberfläche aus Fels besteht. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, wood
Moin! Am 17.09.2013 06:53, schrieb Markus: Hast du den Ausschnitt mit der Mapnikkarte auf osm.org verglichen? Ja - wir rendern die Karte ja selbst. Änderungen der Küstenlinie sehen wir nur in sehr langen Abständen im Datenbestand. Entsprechend verspätet können wir diese rendern ... Wenn Du eine Idee hast, wie wir das verbessern können, wäre das super! Aktuell werden Änderungen der coastline schon nach wenigen Tagen auf osm.org sichtbar (manchmal dauerte es schon mehrere Wochen). Sind die dafür erzeugten Shapefiles nicht auch für euch nutzbar? Gewässer ohne Gezeiten: Mean Sea Level (Mittlerer Wasserstand) ist aber in diesem Fall nicht eindeutig. Ja, sie ist in den Schären im Luftbild besonders schwer erkennbar. Auf guten Luftbildern sind Fels und Wasser gut unterscheidbar. Meine Frage bezog sich aber speziell auf die Abgrenzung in Schilfgebieten. Auf dem Luftbild erkennt man allenfalls ob die Baumkronen lückenlos stehen. Das wäre für mich der Wald. Nützlich wäre ein tag für teilweise baumbedeckte Gebiete. Ja. Wäre folgendes sinnvoll? natural=bare_rockNur Fels natural=bare_rock;wood Fels mit Bäumen natural=wood;bare_rock Wald mit Felsinseln natural=wood Wald In den Schären ist die Orientierung zwischen den Inseln sehr schwierig, weil diese optisch hintereinander liegen und sozusagen miteinander verschmelzen. Da hilft jeder identifizierbare Objekt an Land. Oder ein GPS-Empfänger :-) Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, wood
Am 14.09.2013 21:40, schrieb Christoph Hormann: On Saturday 14 September 2013, Stephan Wolff wrote: http://wiki.openstreetmap.org/wiki/DE:Coastline#Verbessern_der_Gena uigkeit Das habe ich gelesen und musste über keine Generalisierung schmunzeln. Die Küstenlinie ist ein klassisches Beispiel für ein Fraktal und hätte ohne Generalisierung unendlich viele Punkte und sogar unendliche Länge. Das wäre nur dann der Fall, wenn Du ein Messverfahren mit unbegrenzter Auflösung verwendest. In der Realität hat bereits die ursprüngliche Datengrundlage (also das Luftbild oder das GPS-Signal) eine klare Auflösungsgrenze und der Ratschlag, gegenüber dieser nicht zusätzlich zu vereinfachen, ist recht sinnvoll - ganz einfach nach dem Motto: wenn man sich schon die Mühe macht, das zu erfassen, dann sollte man die Erfassung nicht schlechter machen, als sie aufgrund der Datengrundlage eh zwangsläufig ist. Die Intention war mir klar. In den Schären kann man schon die auf den vorhandenen Luftbildern sichtbaren Steine nicht alle einzeichnen. Bei höher aufgelösten Bildern muss man zwangsläufig die coastline glätten. Berücksichtigt man, dass der fotografierte Wasserstand nicht unbedingt dem mittleren Wasserstand entspricht, kommt man auf eine Unsicherkeit von wenigen Metern bei Fels-/Kiesküsten, deutlich mehr bei Schilfgürteln und weniger bei künstlichen Befestigungen. Diese Genauigkeit versuche ich beim Einzeichnen der coastline zu erreichen. Hinzu kommt die Lageunsicherkeit der Luftbilder, die man mangels brauchbarer GPS-Tracks (die meisten Tracks in den Schären stammen von Wasserfahrzeugen) nur eingeschränkt korrigieren kann. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Definition coastline, wood
Am 13.09.2013 20:28, schrieb Markus: ich habe in den letzten Wochen oft die Küstenlinie der schwedischen Ostschären bearbeitet. :-) - ja, da gibt es noch viel zu tun: http://map.openseamap.org/map/?zoom=12lat=58.40895lon=16.89403layers=BFTFFFTFFTT0TF Hast du den Ausschnitt mit der Mapnikkarte auf osm.org verglichen? Ihr solltest dringend den Kartenhintergrung aktualisieren :-) Teilweise befinden sich breite Schilf-/Röhrichtgürtel zwischen offenem Wasser und festem Land. Gibt es eine Definition, wo man die coastline dort am besten einzeichnet? Gezeitengewässer: Mean High Water Springs (Mittleres Hochwasser) Gewässer ohne Gezeiten: Mean Sea Level (Mittlerer Wasserstand) http://wiki.openstreetmap.org/wiki/DE:Coastline#Linien_an_der_Küste Die Definition kenne ich, sie ist aber in diesem Fall nicht eindeutig. Ich habe meist den ersten Farbwechsel im Schilfgürtel als Küstenline genommen, aber das ist sehr willkürlich. Den Schilfgürtel würde ich davon unabhängig (also nicht an die Küste kleben) mit natural=schilf oder so einzeichnen. Du meinst sicherlich natural=wetland, wetland=reedbed. Zum Luftbildmappen von Küstenlinien hatte ich mal was geschrieben: http://wiki.openstreetmap.org/wiki/DE:Coastline#Verbessern_der_Genauigkeit Das habe ich gelesen und musste über keine Generalisierung schmunzeln. Die Küstenlinie ist ein klassisches Beispiel für ein Fraktal und hätte ohne Generalisierung unendlich viele Punkte und sogar unendliche Länge. Ich würde gern auch den Baumbewuchs erfassen Von einzelnen Kiefern, die sich auf dem nahezu kahlen Fels halten, bis zu Waldstücken mit Humusboden ist alles vertreten. Ich würde nur geschlossenen Wald auf Humus mappen. Auf dem Luftbild erkennt man allenfalls ob die Baumkronen lückenlos stehen. Nützlich wäre ein tag für teilweise baumbedeckte Gebiete. Die kommen ja auch im Gebirge vor. Super wäre auch, wenn Du gleich einzele Häuser und Stege mappen könntest, das hilft sehr beim Orientieren zwischen den Inseln :-) Das ist viel Arbeit. Machst du mit? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 13.09.2013 10:16, schrieb Manuel Reimer: Stephan Wolff s.wolff at web.de writes: Die Grenzlinien nah an der Wegmitte existieren in der Realität nicht. OSM ist kein Kartenmalprojekt sondern ein Geodatenbankprojekt. Für Abstands- und Flächenberechnungen gibt es Unterschiede, auch wenn die Kartendarstellung (für einen speziellen Renderer) gleich aussehen mag. Stimmt. Und deshalb wäre es eigentlich korrekt, die Grenzlinien garnicht so nahe an die Wegmitte zu ziehen sondern zwischen den Grenzlinien sollte ein Abstand bleiben, der der Wegbreite entspricht. Je nach Flächendefinition und Wegtyp kann das korrekt sein (s.u.). Weil das sch... aussieht ziehe ich sie trotzdem näher an die Wegmitte ran. Ob etwas gut aussieht, hängt von den Renderregeln, den betrachteten Zoomlevel und dem Geschmack des Betrachters ab. Wir wollen korrekte Daten erfassen und nicht schöne Karten malen. Streng genommen müsste man sogar alle Flächen an Wegen trennen, da der Weg die Fläche ja auch in der Realität unterbricht. Es gibt beide Möglichkeiten: - der Weg unterbricht/zerschneidet/teilt die Fläche - der Weg ist ein Teil/liegt in/führt durch die Fläche Die landuse-Flächen interpretieren die meisten Mapper so, dass Wege und Erschließungsstraßen Teil der Fläche sind. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 13.09.2013 15:34, schrieb Martin Koppenhoefer: Am 13. September 2013 14:12 schrieb Stephan Wolff s.wo...@web.de: Die landuse-Flächen interpretieren die meisten Mapper so, dass Wege und Erschließungsstraßen Teil der Fläche sind. interessanterweise sieht die öffentliche Hand das genau anders rum. Hat sich die öffentliche Hand zur OSM-Definition von landuse geäußert? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Definition coastline, wood
Moin, ich habe in den letzten Wochen oft die Küstenlinie der schwedischen Ostschären bearbeitet. Teilweise befinden sich breite Schilf-/Röhrichtgürtel zwischen offenem Wasser und festem Land. Gibt es eine Definition, wo man die coastline dort am besten einzeichnet? Ich würde gern auch den Baumbewuchs erfassen (zum Zelten sind die kleinen Waldstücke viel bequemer als nackter Fels). Von einzelnen Kiefern, die sich auf dem nahezu kahlen Fels halten, bis zu Waldstücken mit Humusboden ist alles vertreten. Wie könnte man dort die Außenlinie von natural=wood definieren? Gibt es Ideen, wie man Mischungen als Fels, Gras und Wald beschreiben könnte? Ein Beispiel für beide Problemfälle: http://binged.it/1erWZlC Gruß Stephan PS: Es sind noch reichlich Inseln nach, die in OSM nicht oder nur sehr grob erfasst sind. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11.09.2013 20:28, schrieb Martin Koppenhoefer: Am 11. September 2013 19:25 schrieb Stephan Wolff s.wo...@web.de: Weit überwiegend wird landuse als Gebiet (Bau-, Gewerbe-, Wohngebiet) verwendet, das Wege und Nebenstraßen einschließt. Ja, das ist in Deutschland zumindest überwiegend (noch) so, aber das könnte man ja ändern, wenn ein Wille da ist. M.E. sind wir beim landuse noch relativ am Anfang, [] Nicht nur in Deutschland sondern fast überall. Für eine Änderung der landuse-Definition wäre zumindest ein ausformulierter Vorschlag und eine breite Zustimmung der Mapper dazu nötig. Falls wirklich Bedarf besteht könnte man einfacher die Flurstücke der Straße als Fläche erfassen und hätte die private Grundstücksfläche als Differenz aus landuse und Straßenfläche. Dadurch würde man nebenbei auch die von einigen ungeliebten shared nodes zwischen Straße und Privatgrundstück vermeiden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 12.09.2013 07:00, schrieb Manuel Reimer: Es ist definitiv falsch, wenn du in irgendeinem schon gut gemappten Gebiet jetzt stundenlang irgendwelche sauber getrennten Flächen zusammenklebst. Das ist auch dann falsch, wenn die Flächen deiner Ansicht nach genau angrenzen. Das ist keine Ansichtsfrage. Wenn zwei Grundstücke mit unterschiedlicher Nutzung in der Realität aneinandergrenzen, dann ist eine gemeinsame Grenze beider landuse-Flächen die einzig korrekte Beschreibung (auch wenn die Näherung durch zwei eng benachbarte Fläche meist geduldet wird). Ich bin mir da wirklich unsicher und dachte ich frage mal nach. Nach dem rendern sieht das ja ganz ok aus... Wenn man die Flächen bevorzugt an Wegen trennt und die Nodes nah genug an den Weg ranzieht, dann fällt die Trennung im Rendering genau so wenig auf. Die Grenzlinien nah an der Wegmitte existieren in der Realität nicht. OSM ist kein Kartenmalprojekt sondern ein Geodatenbankprojekt. Für Abstands- und Flächenberechnungen gibt es Unterschiede, auch wenn die Kartendarstellung (für einen speziellen Renderer) gleich aussehen mag. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 10.09.2013 11:35, schrieb Wolfgang Hinsch: Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen Multpolygone übereinander gelegt werden muss. Eine Universität mit den Unterteilungen in Fakultäten, Fachbereiche, Institute und Lehrstühle sowie zentralen Einrichtungen, die oft sehr verschachtelt sind, ist eine der kompliziertesten Institutionen. Wir können sie sicherlich nicht vollständig in OSM abbilden. Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shared Nodes bei landuse
Am 11.09.2013 15:36, schrieb Florian Lohoff: landuse=farmland und landuse=meadow liegen ja gerne direkt nebeneinander. Wenn noch ein track dazwischen durchgeht dann teilen sich die flaechen nicht die nodes, weder miteinander noch mit dem track. Anders als bei Straßen haben landuses ja exakt die geometrische ausdehnung die die nodes andeuten, wohingegen eine landuse die bis zum Straßennode geht ja vermeindlich bis zur Straßenmitte gehen würde. Weit überwiegend wird landuse als Gebiet (Bau-, Gewerbe-, Wohngebiet) verwendet, das Wege und Nebenstraßen einschließt. Der Satz im Wiki Im Idealfall endet die eingezeichnete Landnutzung an der Grundstücksgrenze. findet sich nur in der deutschen Version und wurde erst im Mai 2013 eingefügt. Was ich immer vermeide ist unterschiedliche typen von flaechen ihre nodes sharen zu lassen. D.h. landuser/leisure, landuse/amenity oder ganz wichtig landuse/highway teilen sich bei mir nie die nodes. Warum? Selbst wenn man landuse als Grundstücke definiert, haben Wohngrundstücke zu Schulen (amenity) und Parks (leisure) oftmals gemeinsame Grenzen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude, Grundstücke und Institutionen
Am 11.09.2013 13:07, schrieb Martin Koppenhoefer: Am 11. September 2013 13:01 schrieb Stephan Wolff s.wo...@web.de: Ich würde alle Teile nur der Universität zuordnen. Das passt zumindest zur deutschen Rechtslage, in der die Universität als ganzes eine rechtsfähige, juristische Person (meist eine Körperschaft des öffentlichen Rechts) ist. Die Untergliederungen würde ich nur als Punkt erfassen. ich finde, mindestens die Fachbereiche und evtl. auch die Institute können wir schon hinbekommen, und das sind auch eher stabilere und für die Orientierung äusserst wichtige Informationen, [] Ähnlich verhält es sich übrigens oft auch mit Krankenhäusern, insbesondere Unikliniken. In beiden Fällen sind für sinnvolles Routing genauere Informationen als nur: da ist das Universitätsklinikum XY nötig, vor allem, wenn es mehrere Standorte gibt. Eine Universität oder ein Uniklinikum lassen sich meist gut als Fläche definieren. Die einzelnen Institute und Fachkliniken sind aber oft so kleinteilig untereinander und mit Gemeinschaftsräumen vermischt, dass eine Flächenerfassung kaum möglich ist. Zudem gibt es oft mehrstöckige Gebäude mit unterschiedlicher Nutzung auf jeder Ebene. Das Institute und Fachkliniken in die OSM-Datenbank gehören, wird hoffentlich nicht bezweifelt. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 08.09.2013 19:23, schrieb Henning Scholland: Am 08.09.2013 17:49, schrieb Tirkon: Bei OSM ist die Situatuion anders. Mit zunehmenden Inhalten wird das Editieren für weniger erfahrene Mapper immer schwieriger. Wenn eine zunehmende Komplexität verhindert, dass die Maintainer vor Ort zunehmend im Tag- und Relationsdickicht nicht mehr durchblicken und sich damit an einfache Korrekturen nicht mehr herantrauen, wird es schwierig. Das liegt aber nur an den Editoren. Wenn du bspw. josm auf einfache Art sagen könntest: Ich möchte jetzt nur Supermärkte und Hotels bearbeiten und josm blendet den ganzen Rest aus (außer Gebäude, Supermärkte und Hotels) und führt im Hintergrund eine Überprüfung aus, die warnt bzw. verhindert, dass man mit einer Aktion andere Objekte verändert, dann wäre es völlig egal, welcher Mist da sonst noch in der DB ist. Mit POIs könnte das funktionieren, auch wenn die Ausrichtung an vorhandenen Strukturen hilft, das neue Objekt zu platzieren. Bei Flächen ist es schon weit schwieriger. Dazu müsste der Editor die Semantik aller Tags kennen, um zu entscheiden, welche Flächen sich überlappen dürfen. Sonst erhält man einen Supermarkt, in den eine Waldecke hineinragt. Bei Relationen, wie den hier diskutieren Wahlkreisen, wird es gänzlich unmöglich. Wenn Relationenen für den Mapper nicht sichtbar sind und er die Basisobjekte bearbeitet, können die Relationenen kaputt gehen oder (schlimmer) inhaltlich falsch werden. Eine universelle Regel zur Reparatur der Relationen kann es nicht geben. Man kann die Komplexität der Daten nicht vor den Mappern verbergen. Bestes Beispiel sind die ÖPNV-Daten. Ohne Kenntnis der ÖPNV-Modelle kann man viele Straßen nicht editieren ohne die Buslinien zu zerstören. Der von Tirkon beschriebene Widerspruch existiert und wir müssen in jedem Einzelfall zwischen Informationsgewinn und Datenkomplexität abwägen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gebäude, Grundstücke und Institutionen
Moin! Ich frage mich oftmals, wie man Institutionen am besten erfasst. Als Institution verstehe ich hier Geschäfte, Industrieunternehmen, Handwerksbetriebe, Vereine, Institute, Behörden, Ärzte, Anwälte, etc. Diese kommen in sehr unterschiedlichen Größen und Bauformen vor. Einige typische Beispiele: - großes Industrieunternehmen (Gelände mit mehreren Gebäuden, ein Haupttor und mehrere Nebentore) - mittelgroßes Gewerbe / Handel (ein Grundstück, ein Gebäude, ein Eingang) - Gewerbehof / Supermarkt (mehreren Institutionen nebeneinander in einem Gebäude, gemeinsame Nutzung des Grundstücks / Parkplatzes) - mehrstöckiges Geschäftshaus (Ladenlokal, Büros, Praxis übereinander) In unser Datenbank sind viele Institutionen nur als name-Tag am Gebäude erfasst. Für einen menschlichen Nutzer mit ausreichendem Sprachverständnis und Vorwissen ist meist erkennbar, was gemeint ist, für fremdsprachige Nutzer und automatische Auswertungen nicht. Beim Einzelhandel und einigen anderen Objekten ist neben building und name zumindest ein weiteres Tag wie shop, office etc. üblich. Dabei bleibt undefiniert, ob name und andere tags zum Gebäude oder zum Gebäudenutzer gehören. Meist passt nicht einmal die Gebäudeaußenlinie als Grenze der Institution, da entweder ein Grundstück dazu gehört oder das Gebäude weitere Nutzer hat. Einige Gebäude sind nach dem Hauptmieter benannt, während kleinere (rechtlich selbstständige) Mieter als Punkt innerhalb des Gebäudes liegen. Große Institutionen werden oft als mehrere Gebäude mit gleichem Namen (Mehrdeutigkeit bei der Suche, falsche Ergebnisse bei Zählungen) oder als landuse mit Namen der Institution (Mehrdeutigkeit der tag-Zuordnung) erfasst. Für das Kartenbild mag das Tagging akzeptabel sein, aber eine sinnvolle Analyse der Geodaten ist damit kaum möglich. Ein POI innerhalb eines Gebäudes ist unproblematisch, aber eine Unterscheidung nach der Größe ist nicht möglich. Mir fallen folgende Kriterien ein, die ein Datenobjekt für Institutionen im Idealfall erfüllen sollte: - genau ein OSM-Objekt pro Institution (Datenbankauswertung, Routingziele) - mindestens ein Tag zur Klassifizierung der Institution (shop, club, office, craft, etc.) - eindeutige Zuordnung der OSM-Tags zum Gebäude oder zur Institution - eindeutige Zuordnung von Gebäuden / Parkplätzen zur Institution - Haupteingang statt Flächenmitte als Routingziel - Flächenmittelpunkt für Kartenbeschriftung - Abschätzung der Wichtigkeit einer Institution, um bei Kollisionen des Kartentextes die wichtigere Institution darzustellen und bei einer Suche diese als erstes aufzulisten - evtl. sogar Besucher-/Kundenparkplatz als Routingziel für PKW - alles möglichst einfach und selbsterklärend ;-) Leider ist alles zugleich kaum möglich. Wollen wir eher Grundstücke, Gebäude oder einfach den Zugangspunkt als Institution erfassen? Brauchen wir für große Institutionen Relationen, die die Gesamtfläche, Gebäude, Parkplätze und den Hauptzugang miteinander verknüpfen? Wollen wir für Gebäude und Institutionen grundsätzlich verschiedene OSM-Objekt nehmen oder die Tags durch einen Prefix eindeutig machen (z.B. building:name, shop:name)? Wie kann man die Bedeutung einer Institution aus unseren Daten erkennen? Hilft die Grundstücks- bzw. Gebäudefläche oder brauchen wir manuell gepflegte Daten (z.B. importance=1 bis importance=5)? Ich tendiere dazu, Institutionen mit eigenem Grundstück als Fläche zu erfassen (ohne diese gleichzeitig als landuse zu verwenden), kleinere als Punkt innerhalb eines Gebäudes. Was meint ihr dazu? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie tagge ich ein Gebäude des Zolls?
Moin, die Verwandschaft zwischen Zoll und Polizei ist nicht gerade eng. Der Zoll ist Teil der Bundesfinanzverwaltung, die Polizei gehört zum (meist Landes-)Innenministerium. Dem Vorschlag amenity=customs schließe ich mich an. Gruß Stephan Am 27.07.2013 12:01, schrieb Henning Scholland: Naja amenity=police ist evtl. etwas irreführend, auch wenn es (zumindest hier) verwandt ist, sind doch die Aufgaben weit entfernt (aus Kundensicht). Taginfo spuckt bspw. knapp 300 amenity=customs aus. Henning Am 27.07.2013 11:37, schrieb jotpe: amenity=police, name=Zoll ? Oder gibt es was besseres? Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 5 Jahre OSM - eine persönliche Bilanz
Moin, am 16.7.2008 habe ich meinen ersten Beitrag zu OpenStreetMap geleistet. Damals war selbst in unserem Landeshauptdorf Kiel das Straßennetz nur zu einem kleinen Teil erfasst. Ich bin oftmals mit meinem alten GPS12 durch die Straßen und Wege geradelt, habe an relevanten Punkten den Markerknopf gedrückt, zu Hause die Daten per seriellem Kabel übertragen und in die OSM-Datenbank hochgeladen. Mit Potlatch 0.x ließen sich die OSM-Daten zusammen mit den gerade übertragenen Tracks darstellen und editieren. Es gab damals nur wenige elementare Tags, die auch für einen Einsteiger schnell erlernbar waren, aber noch keine Relationen. Als Datenquellen gab es neben den GPS-Tracks nur schlecht aufgelöste Landsat-Bilder, die allenfalls eine grobe Abschätzung von Wäldern und Seen erlaubten. Die Editoren hatten noch manche Schwäche, so dass leicht ein fälschlich unverbundener Weg entstand. Trotzdem war fast jeder Beitrag ein Gewinn für OSM. Die Änderungen erschienen manchmal nach wenigen Stunden auf der Osmarender-Karte, aber die Mapnik-Karte wurde nur einmal pro Woche aktualisiert. Eine nicht geschlossene Fläche oder ein falsches Tag blieben so eine ganze Woche sichtbar. Seitdem hat sich eine Menge getan. Ich bin mir nach kurzer Zeit ein Garmin eTrex Vista HCx zugelegt und konnte an meinem neuen Laptop auch mit JOSM flüssig arbeiten. Die Editoren wurden immer leistungsfähiger. Das Straßennetz ist in Deutschland fast vollständig erfasst. Mit den Luftbildern von Aerowest und vor allem Bing ist die Datenqualität sehr gestiegen und es können auch Strukturen, wie Knicks und Bäche erfasst werden, die vorher kaum zugänglich waren. Auf der Mapnik-Karte erscheinen Änderungen jetzt schon nach wenigen Minuten. Es entstehen immer mehr Projekte, die OSM-Daten nutzen und auswerten. Er werden immer mehr Details und Zusatzinformationen in OSM erfasst. Trotzdem gibt es für mich auch einige Wermutstropfen. Gerade die vielen Details machen einige Karten unübersichtlich, die Routeranweisungen zu kompliziert und viele Auswertungen unmöglich, wenn viele Elemente ohne Zusammenhang in der Datenbank stehen. Selbst im Kernbereich von OSM gibt es kaum Datenstrukturen, die mehrere ways zu einer Straße, mehrere Kreuzungspunkte zu einer Straßenkreuzung oder mehrere Ausfahrten zu einem Autobahnkreuz zusammenfassen. In vielen Bereichen werden immer neue Daten erfasst, ohne dass Aussicht auf einen Grad an Vollständigkeit besteht, der für eine breite Nutzung nötig ist. Selbst überschaubare Fortschritte, wie etwa Höchstgeschwindigkeiten aller Autobahnen zu erfassen, gelingen nicht. Das ÖPNV-Modell ist gescheitert. Buslinien mit mehreren Varianten lassen sich kaum damit umsetzen. Eine Straße, über die fünf Buslinien in 12 Varianten führen, ließe sich bei vollständiger Erfassung der Linien auch nicht mehr sinnvoll editieren. Es hat sich leider keine demokratische Kultur gebildet, bei der die Mapper gemeinsam über die weitere Richtung von OSM entscheiden. Viele Fragen, die schon vor Jahren diskutiert wurden, tauchen immer wieder auf, ohne dass es einen Weg zur Entscheidung gibt. Für eine Neueinsteiger werden die Einstiegshürden immer größer, zum einen unvermeidlich, da es immer mehr und komplexere Daten gibt, die man nicht zerstören darf, aber zum anderen unnötig, da die Regeln und Gebräuche nur unvollständig und teils widersprüchlich im Wiki abgelegt sind und daneben viele weitere Informationsquellen mit schlecht auffindbaren Diskussionen. Die Entscheidung, die vielen Spezialkarten und Anwendungen nicht über die zentrale Webseite osm.org zugänglich zu machen, erschwert die Wahrnehmung und Nutzung (und indirekt die Finanzierung) von OSM. Anwendungen, die nur über tief verschachtelte Wikiseiten oder eine Google-Suche zugänglich sind, werden kaum genutzt. Ich verbinde dennoch viel positives mit meinem Engagement für OSM. Um fehlende Wege auszumessen, bin ich in viele Sackgassen und Feldwege gefahren und habe manch interessantes Detail entdeckt. Ich habe Ausflüge in schlecht erfasste Gegenden gemacht, die ich sonst nicht besucht hätte. Beim Editieren ergaben sich immer wieder Fragen, die mich zu Google-Recherchen animieren. Ich habe viele Diskussionen im Forum und talk:de mitgelesen und dabei einiges gelernt. Der Umgang miteinander war dort meist freundlich und konstruktiv. Und natürlich nutze ich auch die OSM-Daten, oft auf Reisen und zu deren Vorbereitung. Jetzt ist es wieder einmal spät geworden und meine persönliche Bilanz aus 5 Jahren mit OSM, die natürlich keinen Anspruch auf Vollständigkeit und Objektivität erhebt, erscheint einen Tag zu spät :-). Stephan (aka seawolff) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Moin! Am 07.07.2013 08:19, schrieb Tracy Kasperczyk: Sehr geehrte OSM-Gemeinde, wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München ( http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und einheitlichen Darstellung. Bitte beschreibt, was ihr ändern und vereinheitlichen wollt, bevor ihr in großem Umfang Bahnhöfe überarbeitet. Gibt es schon einen Musterbahnhof? Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Ich finde den Namen globale_id_pt ungünstig (Denglish und nicht intuitiv verständlich). Warum nicht ref_ifopt? Die von anderen geäußerten Bedenken gegen diese Information teile ich nicht. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pseudonamen
Am 30.06.2013 23:52, schrieb Martin Koppenhoefer: Spricht etwas dagegen, solche Texte von name nach description zu verschieben? wenn der Inhalt des tags deutsch ist, dann würde ich description:de verwenden. Laut Wiki wird für description die ortsübliche Sprache (local language) verwendet. Europäischer Fernwanderweg E6, Deutschland, Harz Der Europäische Fernwanderweg kommt mir allerdings schon wie ein Name vor, Europäischer Fernwanderweg E6 ist zweifellos ein Name. Dass es eine definierte Teilstrecke mit dem Namen Europäischer Fernwanderweg E6, Deutschland, Harz gibt, würde ich bezweifeln. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ways mit boundary = aerial_views
Moin! Am 01.07.2013 08:07, schrieb Wolfgang Hinsch: Am Sonntag, den 30.06.2013, 12:20 +0200 schrieb Stephan Wolff: Ich bin über diese Objekte ebenfalls nicht glücklich: - die Grenzen von Luftbildquellen sind keine Geodaten und wären in einer Metadatenbank besser aufgehoben, die man in den OSM-Editoren als zusätzlichen Layer einblenden kann. Dort wären auch sonstige Informationen zu Datenquellen und deren Fehlern gut aufgehoben - boundary=aerial_views ist auch nicht gut. Metadaten sollten einen andere Keys als Geodaten verwenden, damit man sie davon unterscheiden und gegebenenfalls filtern kann Wenn wir möchten, dass die Mapper mehr Daten lokal verarbeiten und dann in Extra-Layern verwalten, müssen die Editoren dafür erst einmal fit gemacht werden. [] Im Moment leider unbenutzbar. Der Reihe nach: - als erstes sollte man die Metadaten eindeutig kennzeichnen, z.B. durch den Prefix meta: im key. Damit könnte man Metadaten schon filtern und es könnten keine Verwechselungen mit Geodaten auftreten. - eine eigene Datenbank für Metadaten (Datenquellen, Offset von Luftbildern, Hinweise für Mapper, Bugs, ...) erfordert eine gründliche Diskussion und erheblicher Arbeit für die Administratoren. Ich sehe das eher als Fernziel. - die Anpassungen im Editor wären dann nicht mehr umfangreich. Eine Warnung, wenn Objekte mit meta:-Prefix im Geodatenlayer auftauchen und umgekehrt wäre einfach. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ways mit boundary = aerial_views
Am 30.06.2013 10:56, schrieb Pascal Neis: Der Schriftzug entsteht durch den folgenden Way[2]. Diese Arten von Ways wurden vermutlich durch die folgende Wiki-Seite[3] erstellt. Ehrlich gesagt bin ich mir über den Sinn solcher Ways nicht ganz sicher, bzw. müssen sie wirklich einen name-tag beinhalten? Ich bin über diese Objekte ebenfalls nicht glücklich: - die Grenzen von Luftbildquellen sind keine Geodaten und wären in einer Metadatenbank besser aufgehoben, die man in den OSM-Editoren als zusätzlichen Layer einblenden kann. Dort wären auch sonstige Informationen zu Datenquellen und deren Fehlern gut aufgehoben - boundary=aerial_views ist auch nicht gut. Metadaten sollten einen andere Keys als Geodaten verwenden, damit man sie davon unterscheiden und gegebenenfalls filtern kann - name sollte durch description ersetzt werden. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Pseudonamen
Moin, viele OSM-Objekte (insbesondere Relationen) haben name-Tags, die es in der realen Welt nicht als Namen gibt. Beispiele: Deutschland (Landmasse) Deutschland — Danmark Deutsche Bundesautobahnen VGXY Buslinie 1 nordwärts Variante 1 Europäischer Fernwanderweg E6, Deutschland, Harz Spricht etwas dagegen, solche Texte von name nach description zu verschieben? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenz
Am 30.06.2013 12:36, schrieb René Kirchhoff: auf osm.org ist der Text bereits mehrsprachig: http://www.openstreetmap.org/copyright/en http://www.openstreetmap.org/copyright/de http://www.openstreetmap.org/copyright/fr Die Texte sind teilweise widersprüchlich: We require that you use the credit “© OpenStreetMap contributors”. Wir verlangen die Verwendung des Hinweises „© OpenStreetMap-Mitwirkende“. Es fehlt eine Erläuterung, wann man welche Sprachversion einsetzen muss bzw. sich frei entscheiden darf. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pseudonamen
Am 30.06.2013 17:58, schrieb Michael von Glasow: On 30/06/13 13:39, Wilhelm Spickermann wrote: Spricht etwas dagegen, solche Texte von name nach description zu verschieben? Für die Relationen legt die Beschreibung der Relationen die Bedeutung der Relationstags fest. So ist im Public Traffic Proposal für den Namen von Linienvarianten angegeben: verkehrsmittel nr doppelpunkt from doppelpfeil to also z.B. Bus 17: Paris = Pelkum Danke für den Hinweis. Das Proposal kannte ist nicht und diese Namensvariante habe ich auch noch nicht gesehen. Ich werde diese Form als zulässigen Namen ansehen. Aber ansonsten bin ich sehr dafür. Im Prinzip ja... aber Erfahrung zeigt, dass Relationen in JOSM in der Relationen-Liste schwer wiederzufinden sind. Da hilft ein eindeutiger name-Tag (description wird in JOSM 5990 nicht ausgewertet). Wenn name nicht existiert, wird note angezeigt. Vielleicht lassen sich die josm-Entwickler überzeugen, auch description darzustellen. Wichtiger wäre es, in den Presets neben dem name-Feld auch description anzubieten. Viele Mapper schreiben vermutlich aus Unwissenheit Beschreibungen ins name-Tag. Mit Pseudonamen an anderen Objekten wäre ich strenger... etwa München-Augsburg an einem Bahngleis oder Nummern von Tramlinien direkt am Gleis. Solche Informationen gehören eher in den description-Tag oder in eine route-Relation. Ja, ÖPNV und Bahnanlagen bieten eine große Vielfalt an Taggingvarianten. Gibt es schon einen Konsens, wie Bahnsteignummern zu erfassen sind (Gleis X/Bahnsteig X/X als name oder ref an Gleis oder Bahnsteig)? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kann jemand ein schönes Plakat malen?
Am 22.06.2013 13:03, schrieb Frederik Ramm: Wer zwar nicht malen kann, aber einen guten Einfall zu meiner Skizze hat oder wer findet, dass etwas wichtiges ausgelassen ist, der darf das natuerlich auch gern hier diskutieren. Ich kann nicht malen und darf deshalb etwas zum Inhalt sagen. Das obere Drittel gefällt mir. Der mittlere Teil ist sehr technisch und passt nicht richtig zum übrigen Inhalt. Ich würde auf Begriffe wir diff und planet verzichten und nur von minütlichen Aktualisierungen und Datenbankauszug als Datei sprechen. Es fehlt eine Angabe, welche Inhalte in der OSM-Datenbank stehen (insbesondere Daten, die nicht in der Standardkarte sichtbar sind, wie Öffnungszeiten, erlaubte Höchstgeschwindigkeit, Rollstuhleignung, etc.). Die Overpass/Xapi gehört eher in den unteren Teil. Bei den unten genannten Anwendungen wird kaum deutlich, was OSM von den übrigen Kartendiensten (Google, Bing, TomTom,...) unterscheidet (gute Fußgängernavigation, Spezialkarten, interaktive Kartenanwendungen). Es fehlt eine Angabe zur Lizenz (z.B. Die Daten können für nahezu alle privaten und kommerziellen Zwecke genutzt werden, wenn auf die Urheberschaft von OSM hingewiesen wird.) Niemand kann sich alle URLs des Plakats merken. Eine zum Plakat passende Webseite mit klickbaren Links wäre schön. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am 05.06.2013 21:39, schrieb Martin Koppenhoefer: Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. wenn area=yes getaggt ist sollte das so sein dass sie als Fläche gerendert werden Das hatte ich ja schon im ersten Beitrag erwähnt. Bei railway=station ist das Problem im Wiki nicht erwähnt, so dass die meisten Mapper daran scheitern dürften. Die Tags an die Fehler der Auswerteprogramme anzupassen ist m. E. die schlechteste Lösung. Den Fehler bei leisure=track besteht vermutlich auch mit area=no weiter. Wenn es ausreicht, in den Mapnikregeln die select-Anweisung von polygon auf line für die genannten Tags zu erweitern, wäre das einfach zu machen und die Mapper wären von dem Problem entlastet. Die beste Lösung wäre natürlich, osm2pgsql zu verbessern oder zu ersetzen. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Am 05.06.2013 01:47, schrieb Martin Koppenhoefer: Das Problem ist, wie osm2pgsql arbeitet, man kann nur keys als Fläche zuordnen, aber nicht k/v-Paare, d.h. im Zweifel wird man eher ein Liniendefault setzen und nur mit area=yes auf Fläche gehen, weil sonst so was wie bei leisure=track passiert (leisure wird immer als area angesehen). Als Lösung kann man auf einen Area-Datentyp hoffen, oder darauf, dass man auch k/v-Kombinationen in osm2pgsql styles definieren kann. Oder z.B. einen anderen Importer verwenden, Imposm kann das vielleicht? Danke für die schnelle Antwort. Es war mir nicht klar, dass osm2pgsql diese Einschränkung hat. Es ist schade, dass ein Tool, welches für die Hauptkarte wichtig ist, die elementaren Definitionen nicht korrekt umsetzen kann. Trotzdem sollte es doch möglich sein, Objekte wie highway=services, highway=rest_area und railway=station, die in der line-Datenbanktabelle landen, aber nur als Fläche definiert sind, auch als Fläche zu rendern. Für leisure=track könnte man trotz Flächenzuordnung nur die Außenlinie ohne Füllung malen. Dann hätte man trotz der falschen Zuordnung durch osm2pgsql eine korrekte Kartendarstellung. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Widersprüche zwischen Wiki-Definition und Mapnik-Rendering
Moin, highway=services ist im Wiki als Punkt oder als Fläche definiert. Ohne area=yes wird eine geschlossene Linie in der üblichen Mapnik-Karte jedoch nicht als Fläche dargestellt. Dies ist auch im Wiki beschrieben: area=yes muss für Flächen gesetzt werden, sonst wird es fälschlich als Weg statt als Fläche gerendert. Es gab zu diesem Fehler Ende 2010 ein Trac-Ticket [1], das ohne Korrektur geschlossen wurde. Vor 8 Wochen habe ich ein neues Ticket [2] erstellt, das bislang nicht bearbeitet wurde. Das gleiche Problem besteht auch für highway=rest_area und railway=station. Bei leisure=track tritt das gegenteilige Problem auf. Das Tag ist als Linie im Wiki definiert, wird aber als Fläche gerendert. Einige Mapper haben sich der Mapnik-Darstellung angepasst und erstellen ein jetzt Multipolygone. Mangelt es dem Mapnik-Team nur an Zeit oder besteht Uneinigkeit in der korrekten Definition der Tags? Würde es helfen, eine verbesserte osm2pgsql-Konfiguration zu erstellen? Wem könnte man diese schicken? Viele Grüße Stephan [1] https://trac.openstreetmap.org/ticket/3255 [2] https://trac.openstreetmap.org/ticket/4835 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tower:type für Lichtmasten und Schlauch/Feuerwehrtürme
Am 26.05.2013 10:33, schrieb Andreas Labres: Und beim Feuerwehrturm kommt's auf die Tatsache an, dass es ein Feuerwehrturm/Schlauchturm ist. Nicht auf die Verwendung. Und mit Fitness hat das sowieso nix zu tun. Hast Du einen guten Tagging-Vorschlag dafür. Grundstück mit amenity=fire_station, Gebäude als building=yes mit height=... oder building:levels= Ob darin Schläuche getrocknet werden, Training stattfindet oder nur noch altes Material gelagert wird, ist nur für die Feuerwehrleute wichtig (und die sehen dafür nicht bei OSM nach). Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Güterbahnhöfe / Verladestationen
Am 26.04.2013 11:04, schrieb Martin Koppenhoefer: Am 26. April 2013 00:25 schrieb Stephan Wolff s.wo...@web.de: http://www.openstreetmap.org/?**lat=48.6973lon=8.99464zoom=** 17layers=Mhttp://www.openstreetmap.org/?lat=48.6973lon=8.99464zoom=17layers=M OT: Das Daimlerwerk ist ein typisches Beispiel, dass gut gemeint nicht immer gut ist. das war als Beispiel für eine größere Bahnverladung gemeint, wie sie in der Realität vorkommt. Die Abbildung in OSM hatte ich nicht gemeint und mir auch nicht besonders genau angesehen. Das war keine Kritik an deinem Beitrag. Ich hatte den Link angeklickt und war auf den ersten Blick enttäuscht, wie schlecht die OSM-Daten selbst in deutschen Großstädten sind. building=yes ist zu bridge=yes nicht kompatibel. layer=1 genügt. das höre ich zum ersten Mal, dass das nicht kompatibel sei, worauf beziehst Du Dich da? Ich würde vermutlich auch eher building=bridge verwenden für geschlossene Übergänge von einem Gebäude auf Höhe der Obergeschosse. building beschreibt eine Fläche, bridge=yes ist nur für ways definiert. Für Übergänge bietet sich path/footway mit bridge=yes an. Bei größeren Gebäudeteilen über der Straße ist building=* mit layer=1 sinnvoll. Wenn sich Büroflächen in aufgeständerten Gebäuden befinden, ist building=bridge m.E. nicht passend, aber das ist jetzt völlig OT. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Güterbahnhöfe / Verladestationen
Am 21.04.2013 15:02, schrieb Martin Koppenhoefer: Hier noch ein Beispiel: http://www.openstreetmap.org/?lat=48.6973lon=8.99464zoom=17layers=M OT: Das Daimlerwerk ist ein typisches Beispiel, dass gut gemeint nicht immer gut ist. Die Werksstraßen haben sicherlich nicht alle den Namen Daimlerwerk und sollten m. E. als service und nicht als unclassified oder residential klassifiziert sein. layer=-1 und layer=0 für die Werksstraßen sind hier meist überflüssig. Die Werksgleise haben heißen nicht Daimler AG Sindelfingen. building=yes ist zu bridge=yes nicht kompatibel. layer=1 genügt. Wenn ich das Luftbild nach den GPS-Tracks der Umgebung justiere, ergibt sich ein deutlicher Offset von Luftbild und OSM-Daten. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] landuse nicht für Detailmapping verwenden (war: Abgerissenes Haus)
Am 06.12.2012 19:29, schrieb Martin Koppenhoefer: landuse differenzieren durch subtags: Ja, gern landuse differenzieren durch neue values: Wenn nötig, ja differenzieren mit neuen Werten für den landuse key eher nicht (weil dann gibt es ja schon einen Hauptwert der das abdeckt), aber neue Werte für Flächen, für die bisher noch gar nichts passt: ja. So hatte ich es gemeint. landuse umdefinieren von Gebiet auf Einzelgrundstück: Nein wieso umdefinieren? Welche Granularität Sinn macht, kann man ja diskutieren, bisher war das nie festgelegt. Es ging immer um die vorherrschende Nutzung einer Fläche, aber wie groß die Fläche sein soll, ist der Einschätzung des Mappers überlassen, damit der sich den jeweiligen Erfordernissen anpassen kann. Eine Mindestgröße in Quadratmeter steht da nicht, aber das englische Wiki sagt explizit: Mainly used for describe the primary use of land by humans. [...] More detailed tagging for land uses is available in amenity=*, leisure=* and tourism=*, im deutschen Wiki wird landuse als Gebiet und nicht als Grundstück beschrieben. Einzelgrundstück ist auf jeden Fall noch nicht ausreichend finde ich, wenn Du Dir z.B. amtliche Daten ansiehst dann sind da unterschiedliche Nutzungen auf Teilen des Grundstücks natürlich noch erfasst. Es gibt in amtlichen Daten sicherlich fein aufgelöste Nutzungsunterscheidungen. Dafür haben wir in OSM diverse tags. Es gibt ebenfalls Wohn- und Industriegebiete in amtlichen Daten. Diese werden oft in Karten vom Stadtplan bis zur Generalkarte verwendet. Dafür gibt es in OSM nur landuse. Andererseits muss es nicht immer ein landuse sein, wenn z.B. schon ein shop oder so als Fläche eingetragen ist in einem Wohngebiet dann impliziert das m.E. schon landuse=retail für diese Fläche. Was da Sinn macht kann man ja überlegen, z.B. ob man die Kundenparkplätze und andere Aussenflächen irgendwie zur shop-Nutzung dazubringen möchte. Bei typischen Supermärkten verwende ich auch landuse=retail. Bei einer Schreinerei (Werkhalle) mit Wohnhaus fände ich 2 unterschiedliche landuses auf dem gleichen Grundstück z.B. angemessen. Das widerspricht der lange bestehenden Definition von landuse im Wiki. Man sollte besser building=house und building=industrial verwenden. Je weniger wir generalisieren und nicht nur über Attribute (zu residential wäre ein Beispiel: allgemeines Wohngebiet, reines Wohngebiet, Kleinsiedlungsgebiet) abbilden, um so vielfältiger sind die Möglichkeiten, die Daten später zu nutzen. +1 Ob man im Rendering später einen Fleckenteppich haben will oder daraus allgemeinere Landuses vorberechnet und benutzt (oder Vorberechnete benutzt) (oder gar keine), die Möglichkeiten sind dann alle da, Man kann aus dem Flickenteppich die Gebiete nicht zurückberechnen. während wenn man mit Relevanzkriterien und Bekämpfen der Details immer nur eine Version haben wird, nämlich eine generalisierte. Für die Details hat man weiterhin building, shop, craft, amenity, leisure, tourism und viele andere. Für eine generalisierte Darstellung braucht man landuse in der bestehenden Definition. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse nicht für Detailmapping verwenden (war: Abgerissenes Haus)
Am 06.12.2012 11:40, schrieb Henning Scholland: Wenn man es komplett neu anpackt (was ich bei dem Kuddelmuddel durchaus für richtig halten würde) sehe ich das nicht so. Welches Kuddelmuddel? landuse ist eindeutig als primäre Nutzung (also überschneidungsfrei) eines Gebiets (nicht Einzelgrundstück oder Teil davon) definiert. Weit überwiegend wird es so genutzt. Es würde genügen, die relativ wenigen falschen Verwendungen zu korrigieren. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgerissenes Haus
Am 06.12.2012 03:39, schrieb Martin Koppenhoefer: Früher in der Anfangszeit hat man auch erst mal nur einen way mit oneway=no für die Autobahnen gezeichnet, solange noch gar nichts da war, ich finde es nur folgerichtig, wenn bei allgemein feinerer Detaillierung der Karte auch der landuse sich weiter ausdifferenziert, Der Vergleich passt nicht. highway ist schon immer (zumindest seit ich dabei bin) als baulich getrennte Fahrbahn definiert, landuse als Gebiet. Wenn ein Mapper highway für einzelne Fahrspuren benutzt, gibt es auch Proteste. landuse differenzieren durch subtags: Ja, gern landuse differenzieren durch neue values: Wenn nötig, ja landuse umdefinieren von Gebiet auf Einzelgrundstück: Nein Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] landuse nicht für Detailmapping verwenden (war: Abgerissenes Haus)
Moin! Am 05.12.2012 23:33, schrieb Henning Scholland: Am 05.12.2012 23:17, schrieb Michael Kugelmann: Am 05.12.2012 22:13, schrieb Henning Scholland: dass irgendwo definiert war, Es geht nicht darum dass es irgendwo definiert ist sondern um die reale Verwendung. Das ist der Lauf der Dinge. Es gab Zeiten, da war es sehr beschwerlich, wenn nicht sogar unmöglich, Landuse detailliert zu erfassen. Hinzu kommt, dass es in den Augen vieler auch noch wichtigeres zu mappen gab, als den Landuse detailliert zu erfassen. landuse wird in deutschen Wiki als Gebiet und nicht als Grundstück beschrieben. Das englische Wiki sagt sogar explizit: Mainly used for describe the primary use of land by humans. [...] More detailed tagging for land uses is available in amenity=*, leisure=* and tourism=* Ich finde es wichtig, dass mit landuse zumindest ein tag für die Beschreibung übergeordneter Strukturen vorhanden ist. Auch wenn man beim Mappen nach Luftbildern in der höchsten Auflösung arbeitet und sich das Werk danach ebenso ansieht, gibt es andere Anwendungen und Karten in größerem Maßstab, die größere Strukturen benötigen. Eine einzelne Baulücke würde ich auch umgangssprachlich als im Wohngebiet und nicht als unbebautes Gebiet zwischen zwei Wohngebieten beschreiben. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Style für josm: Fahrspuren
es gibt einen neuen Style für josm rund um Straßendetails wie Fahr- und Abbiegespuren, Busspuren, Fahrbahnbreite... http://wiki.openstreetmap.org/wiki/DE:Josm/styles/lane_features Hallo Wolfgang, gib doch mal einen Link zu einer Musterkreuzung an, wo man sich die Darstellung des Styles ansehen kann. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Detailmapping
Moin! Am 16.11.2012 14:48, schrieb tumsi: Ich bin gerade auf einen Fall von außerordentlichem Detailmapping gestossen [1]: Gartenwege, Grundstücksbegrenzungen durch Zäune und Hecken, Garagenauffahrten, kleine Gartnteiche etc. Ich würde bei einer solchen Siedlung allenfalls die Wohnhäuser als building=house erfassen, da ich in den übrigen Details kaum einen Nutzen erkenne. Aber, wie die übrigen schon geschrieben haben, steht es jedem frei, auch solche Detailelemente aufzunehmen. Für einige Anwendungen sind so viele Detail allerdings lästig. Manche Karten sind mit weniger Elementen übersichtlicher, auf GPS-Geräten ist der Speicherplatz begrenzt und die geringe Rechenleistung kann die Anzeige sehr träge machen, etc. Daher wäre es gut, wenn Garagen, private Auffahrten, Zäune zwischen Einzelgrundstücken, Pools oder Gartenteiche filterbar wären ohne die ähnlichen Elemente im öffentlichen Raum zu verlieren. Gebäude versuche ich (soweit möglich) als building=garage/house/appartment/... zu erfassen. Auffahrten als highway=service, service=driveway (track ist hier natürlich falsch) sind ebenfalls bei Bedarf unterdrückbar. Für die übrigen Elemente sollten wir ähnliche Unterscheidungen einführen, bevor die Nutzer, die das nächste Freibad suchen, zu den privaten Pools im Damaschkeweg 8, 10, 14 und 23 geschickt werden und sie sich daraufhin von OSM abwenden. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesucht - einen Punkt pro BAB-Anschlusstelle (Kreuz)
Moin! Am 14.11.2012 16:11, schrieb Martin Koppenhoefer: Am 14. November 2012 15:34 schrieb Jan Tappenbeck o...@tappenbeck.net: Ist es möglich pro Anschlussstelle (alle Fahrbahnrichtungen) einen Note mit der Ref-Nummer und dem AS-Namen zu generieren. Am einfachsten könnte ich es mir vorstellen, wenn die Nodes, der AS, einfach gemittelt werden. In der Datenbank liegen meist zwei Nodes mit motorway_junction pro Anschlusstelle ohne Verknüpfung. Mit einer einfachen Datenbankabfrage ist es nicht getan. Man kann allenfalls alle Nodes abrufen und über Abstand und name raten welche zusammenpassen. Mit einer Relation könnte man den Zusammenhang explizit in die Datenbank schreiben. Bei einem Kreuz gibt es in Deutschland _die_ ref-Nummer nicht, es sind meist zwei verschiedene Nummern. []eigentlich ist das ja kein echtes Problem mit Mapnik, wenn man mehrere Punkte bekommt, weil die normalerweise so dicht zusammen liegen, dass sowieso wegen der Kollissionserkennung nur einer gerendert wird, Das _kann_ für einzelne Zoomlevel zutreffen, aber selbst dann liegt der Text nicht wie erwünscht in der Mitte. Bei mittlerem Zoomlevel hat die eine Ausfahrt noch zwei Beschriftungen, die nächste evtl. gar keine. Beispiel: A7 Ausfahrt 16-19 Zoom 12 (http://osm.org/go/0HpMSf6--) 16: Nummer und Text doppelt 17: nix 18: Nummer einfach 19: Nummer und Text doppelt Wenn wir die Qualität gedruckter Straßenkarten erreichen wollen, müssen wir mehr Zusammenhänge über Relationen abbilden. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best of OSM-Website
Am 02.11.2012 15:21, schrieb Martin Koppenhoefer: Auch der neue Skandalflughafen in Berlin ist ausführlich gemappt, obwohl noch nicht in Betrieb Der gehört eher auf die Worst-of-OSM-Website: - falsche Tags (Flächen der Rollwege als aeroway=apron, ehemalige Pisten als aeroway=runway ohne abandoned oder disused) - viele falsche landuse-Flächen (industrial für den Tower, maedow zwischen den Rollwegen, brownfield für optionale Erweiterungen) - viele Objekte mit sinnlosen layer-Tags (runway mit layer=5, Flächen der Rollwege mit layer=-1) - viele Beschreibungen im name-Tag (Flughafen Berlin Brandenburg (Eröffnung 27.10.2013), Betriebsstraße, ehem. RWY 14/32) - nicht mehr bestehende Objekte mit abandoned=yes (Selchower Flutgraben) Wir könnten für die Mapper, die bunte Flächen malen und beschriften wollen, Tags wie map_colour, map_layer, map_text, etc. einführen, damit landuse, layer und name nicht dafür missbraucht werden. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit History eines Ways
Am 01.11.2012 10:14, schrieb Rainer Knaepper: http://www.openstreetmap.org/browse/way/35743954/history Laut Chronik gibt es also genau eine Version. Im Potlatch werden mir aber DREI Versionen angezeigt (Edit in Potlatch2, weg anklicken, H drücken). Moin, 2009 hatte ich die Mühle nach einem Besuch am Mühlentag (Der deutsche Mühlentag ist jedes Jahr der Pfingstmontag) auf Basis meiner GPS-Daten erstellt. Mehr als drei Jahre hat niemand die Daten angefasst... Sonntag hat Rainer die Mühle und Umgebung verbessert und zeitgleich habe ich ebenfalls den See und den Pfad anhand der jetzt verfügbaren Bing-Luftbilder editiert. Beim Upload meiner Daten kam es zu mehreren Konflikten. Ich habe jeweils die aktuelle Datenbankversion bei der Konfliktlösung ausgewählt und meine Änderungen an diesen Objekten verworfen. Trotzdem hat es mein Upload offenbar in die Potlatch- Historie geschafft. Vielleicht kann ein Eingeweihter erklären, welche Transaktionen in der Datenbank intern ablaufen. Ps: Den Mapper seawolff habe ich schon angeschrieben, aber noch keine Antwort bekommen. Ich habe die Nachricht zu spät bemerkt. Da OSM immer unterschiedliche Absendeadressen in die Mail einträgt, landen die Mitteilungen bei mir im Ordner Unbekannt :-) Viele Grüße Stephan (aka seawolff) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Länderübersetzungen mittels CLDR
Am 20.10.2012 23:47, schrieb Kolossos: Puh, so die Übersetzungen der Hauptstädte sind jetzt mit Hilfe der Wikipedia und Add-tags auch drin. Moin, ich habe auch zwei Anmerkungen: - ich finde die Namenslisten deutlich zu lang. Bei Berlin sind es knapp 200 Übersetzungen. Im Editor ist so etwas kaum zu bearbeiten. Wenn name:XY gleich dem int_name bzw. name ist, kann man m.E. das Tag weglassen. - bei einigen Übersetzungen sind falsche Namensteile dabei, z.B. name:ilo = Berlin, Alemania name:pdc = Berlin, Deitschland Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von falschen Verkehrsregeln
Moin! Am 20.10.2012 22:06, schrieb Bernhard Weiskopf: Ich habe vor, beide Straßentypen mit den realen Benutzungen zu taggen, also in beiden Fällen „motor_vehicle = destination“, also kein Fahrrad-Durchfahrverbot im 1. Beispiel und „Anlieger frei“ verbunden mit „highway = service“ im 2. Beispiel Ich würde es genauso machen. Wenn jemand einen Fehler beim Aufstellen der Schilder gemacht hat, müssen wir diesen nicht in OSM übernehmen ;-) Gerade für Radfahrer gibt es sehr oft inkonsistente Beschilderung. Feldwege mit Durchfahrverbot und Zusatzschild „Landwirtschaftlicher Verkehr frei“ und Grünanlagen mit unterschiedlichen Schildern oder nur physikalischen Sperren an den Zugängen sind weit verbreitet. Kann man einen Weg von einer Seite legal mit dem Rad befahren, muss implizit oder explizit bicycle=yes gelten, auch wenn in Gegenrichtung ein Verbot steht. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von falschen Verkehrsregeln
Moin! Am 20.10.2012 23:56, schrieb Henning Scholland: Hallo Wer sagt dir denn, wer den Fehler gemacht hat und was nun richtig ist? Die Verbotsschilder stammen meist aus dem letzten Jahrtausend, die Radwegweiser aus dem jetzigen. Es gilt natürlich die aktuellere Aussage :-) Ein Radroutenschild hebt auf jeden Fall nicht ein Verkehrszeichen nach StVO auf. Wenn du Z250 mit dem Rad ignorierst, begehst du erstmal eine Ordnungswidrigkeit. Ob die nun geahndet wird oder nicht spielt erstmal keine Rolle. Ich fände es jedenfalls falsch, wenn wir in OSM absichtlich falsche Daten eintragen, nur weil dann das Routing genehmer ist. Ich versuche herauszufinden, was gemeint ist, und das gemeinte abzubilden. Privatwege mit Schild Befahren verboten interpretiere ich eher als access=private oder access=destination statt als access=no. Inkonsistente Beschilderung lässt sich ohnehin nicht sinnvoll abbilden. An vielen Einbahnstraßen steht der Zusatz Radfahrer frei, aber auf den Querstraßen haben die Abbiegeverbote diesen Zusatz nicht. Ich erfasse das Abbiegeverbot in diesem Fall nicht. Es wäre evtl. auch eine interessante Auswertung zu schauen, wie viele Radrouten über solche Stellen führen. Die sinnlose Beschilderung könnte man als Zusatztag erfassen: bicycle=yes inconsistent_sign:bicycle=no Dann hat man sinnvolles Routing und kann die sinnlose Beschilderung auswerten ;-) Bei maxspeed tragen wir doch auch den Wert ein, der auf dem Schild steht und nicht den Wert, den wir meinen dort fahren zu dürfen. Bei Geschwindigkeitsbegrenzungen würde ich auch vermuten, dass die Schilder den tatsächlichen Willen der Behörde abbilden. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für Abluftkiste, turm,...
Moin! Am 07.10.2012 01:59, schrieb Martin Koppenhoefer: Aber warum sollen wir solche Objekte überhaupt erfassen? Mir fällt keine sinnvolle Anwendung ein. weil es sie gibt? Wir beschreiben doch die Welt, wieso sollten wir diese Dinger nicht mit aufnehmen? Groß genug sind sie ja oft, so dass man sie kaum übersehen kann. Abluftbauwerke von Straßentunneln würde ich auch aufnehmen. Das von Lars genannte Objekt ist ein 1m^2 Kasten auf einem Privatgrundstück, der nur beim Rasenmähen ein Hindernis darstellt. Ich erfasse auf Wohngrundstücken die Häuser, Gemeinschaftsparkplätze und evtl. Einzelgaragen, aber keine Terrassen, Beete, Holzschuppen, Sandkisten oder Kellerschächte. Ich will niemanden hindern, aber jeder sollte den potentiellen Nutzen mit den Kosten (jede Datenmenge wird etwas größer, die Editordarstellung etwas unübersichtlicher, jede Datenverarbeitung etwas langsamer) vergleichen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für Abluftkiste, turm,...
Moin! Am 06.10.2012 22:36, schrieb Lars Schimmer: Die kleinen (oder auch großen) Türme, die als Abluftöffnung für Tiefgaragen oder Tunnel dienen. Hat da jemand einen passenden Tag für? Bei mir vorm Balkon steht so einer, rund 1m hoch, 2m breit, 0.5m tief, Gitter auf der Rückwand. Somit durchaus ein building:yes Aber wie tagt man, das es nen Abluftschacht ist? Ein nicht betretbares technisches Objekt würde ich eher unter man_made einordnen. Aber warum sollen wir solche Objekte überhaupt erfassen? Mir fällt keine sinnvolle Anwendung ein. Viele Grüße Stephan ___ 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
Moin! Am 29.09.2012 01:43, schrieb Martin Koppenhoefer: Am 29. September 2012 00:11 schrieb Stephan Wolff s.wo...@web.de: Da im Golf jeder Bunker aus Sand besteht, kann man surface=sand auch weglassen. Ein Programm, das golf=bunker nicht auswertet, kann auch die Eigenschaft surface=sand nicht nutzen bzw. darstellen. Wieso? Das Programm muss von Golf keine Ahnung haben, um Sand z.B. gelb zu rendern, unabhängig davon, wo der sich befindet. surface ist nur eine Eigenschaft, kein eigenständiges Objekt. Wenn man das eigentliche Objekt nicht in der Karte darstellt, möchte man sicherlich auch nicht dessen mutmaßliche Farbe malen. Nicht jeder Sand ist gelb, nicht jedes Objekt mit gelber Sandoberfläche möchte man auch gelb malen. Mapnik zeichnet Sportplätze und highways mit surface=sand nicht in gelb. Es ist nicht einmal entscheidbar, ob ein geschlossener way mit surface=sand eine Linie oder eine Fläche darstellt. Viele Grüße Stephan ___ 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 29.09.2012 15:04, schrieb Martin Koppenhoefer: Am 29. September 2012 13:18 schrieb Stephan Wolff s.wo...@web.de: surface ist nur eine Eigenschaft, kein eigenständiges Objekt. na und? Die Renderregeln sind meist Objektbasiert. Es ist nicht einmal entscheidbar, ob ein geschlossener way mit surface=sand eine Linie oder eine Fläche darstellt. wenn man Befürchtungen hat, kann man ja area=yes oder no ergänzen. Die Information steckt schon in golf=bunker. Theoretisch könnte ein Renderer eine Fläche mit surface=sand und area=yes außer in Kombination mit highway=* oder leisure=* gelb malen. Praktisch wird es niemand so machen, sondern entweder golf=bunker darstellen oder auf dieses Detail verzichten. Gruß Stephan ___ 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 28.09.2012 21:41, schrieb Tobias Knerr: Am 28.09.2012 13:39, schrieb Martin Vonwald: Nein - natural=sand ist genauso Schwachsinn wie ein Großteil der natural-Werte. Ist aber halt das, was dem ganzen am nächsten kommt, daher habe ich das damals verwendet. :-/ Ist nicht das etablierte Tag, das einem landcover=sand am nächsten kommt, eher surface=sand? Ein Tagging wie golf=bunker + surface=sand für einen Sandbunker passt doch gut. Da im Golf jeder Bunker aus Sand besteht, kann man surface=sand auch weglassen. Ein Programm, das golf=bunker nicht auswertet, kann auch die Eigenschaft surface=sand nicht nutzen bzw. darstellen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
