Re: [Talk-de] Adressen erfassen
Am 25.01.11 08:57, schrieb Walter Nordmann: André Joost wrote: Nun, die Marler Adressen sind importiert worden. Leider passt die Lage der Straßen manchmal nicht zu den Nummern :-( Normalerweise sollten die Straßen in DE zwischen den gerade und ungeraden Hausnummern liegen. Da gibt es ja wohl nur zwei Möglichkeiten: a) alles auf die Plattentektonik schieben b) Straßen schubsen c) auf den miesen GPS-Empfang schieben. Ich hatte mich für b) entschieden. Aber nur dort, wo ich auch wirklich unterwegs war. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tagesschau benutzt OSM-Karte (via DPA)
Zufällig gefunden: http://www.tagesschau.de/ausland/explosionmoskau102-magnifier_pos-1.html Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagesschau benutzt OSM-Karte (via DPA)
Benjamin Lebsanft benjamin at lebsanft.org writes: siehe: http://lists.openstreetmap.org/pipermail/talk-de/2011-January/082286.html Liebe Grüße Benni Ich war so aufgeregt, dass ich das entdeckt hatte. :D Sorry. Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25.01.2011 08:57, schrieb Walter Nordmann: Nun, die Marler Adressen sind importiert worden. Leider passt die Lage der Straßen manchmal nicht zu den Nummern :-( Normalerweise sollten die Straßen in DE zwischen den gerade und ungeraden Hausnummern liegen. Da gibt es ja wohl nur zwei Möglichkeiten: a) alles auf die Plattentektonik schieben b) Straßen schubsen c) Die Importkoordinaten sind ungenau Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25.01.11 10:22, schrieb Chris66: Am 25.01.2011 08:57, schrieb Walter Nordmann: Nun, die Marler Adressen sind importiert worden. Leider passt die Lage der Straßen manchmal nicht zu den Nummern :-( Normalerweise sollten die Straßen in DE zwischen den gerade und ungeraden Hausnummern liegen. Da gibt es ja wohl nur zwei Möglichkeiten: a) alles auf die Plattentektonik schieben b) Straßen schubsen c) Die Importkoordinaten sind ungenau Nein, die passen ganz gut zu den Luftbildern. Nur einige Straßen halt nicht. Die sind nämlich nicht mit importiert worden. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25. Januar 2011 10:22 schrieb Chris66 chris66...@gmx.de: Am 25.01.2011 08:57, schrieb Walter Nordmann: Nun, die Marler Adressen sind importiert worden. Leider passt die Lage der Straßen manchmal nicht zu den Nummern Da gibt es ja wohl nur zwei Möglichkeiten: a) alles auf die Plattentektonik schieben b) Straßen schubsen c) Die Importkoordinaten sind ungenau +1, ich wüŕde die Nummern schubsen und nicht die Straßen, es sei denn, man hat gute Gründe (tracks) davon auszugehen, dass die Straßen nicht stimmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
M∡rtin Koppenhoefer wrote: +1, ich wüŕde die Nummern schubsen und nicht die Straßen, es sei denn, man hat gute Gründe (tracks) davon auszugehen, dass die Straßen nicht stimmen ich sehe hier aber eine extrem gute übereinstimmung zwischen bing und den importierten hausnummern. würd so 95% der adressen mit 2-3 metern korrektheit schätzen. http://www.openstreetmap.org/edit?editor=potlatch2lat=51.665597lon=7.118837zoom=18 - straßen schubsen p.s. auch die gpx-tracks sind einigermassen gut in bezug auf die luftbilder gruss walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/Adressen-erfassen-tp5952533p5958137.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse bei mehrfacher Landnutzung
Am 25. Januar 2011 01:28 schrieb Stephan Wolff s.wo...@web.de: Moin, wenn ein Gelände mehrere verschiedene Nutzungen hat, ist es schwierig diese als landuse zu erfassen. Beispiele: - Militärgelände mit forstwirtschaftlich genutztem Wald das ist m.E. in der Tat ein valides Beispiel. M.E. 2 üperlappende Landuses (military ist eigentlich eher ein Attribut als ein echter landuse), ggf. per mp-relation. Das Militärgebiet wird in der Regel auch die Lichtungen miteinschließen, der Wald m.E. nicht. - Wald rund um die Brunnen eines Wasserwerks den Brunnen würde ich je nach Situation vermutlich aus dem Wald ausnehmen (Multipolygon) - Friedhöfe, Parks, Golfplätze mit Wald Würde ich übereinanderlegen/überlappen lassen. Parks sind aber z.B. in OSM auch kein landuse, Golfplätze m.W. auch nicht, bei Friedhöfen ggf. ähnlich wie military verfahren. Persönlich tagge ich die von Bäumen überdeckten Flächen zusätzlich mit landcover=trees 1. nur die primäre Nutzung als landuse, weiteres nur als natural, surface, etc. = landuse=military;natural=wood Nachteil: keine Erfassung der forstwirtschaftlichen Nebennutzung würde ich nicht machen. Schon die Festlegung einer primären Landnutzung ist m.E. nicht machbar. Das hängt alleine davon ab, für welchen Aspekt man sich beim Auswerten interessiert, daher sollte man die Daten nicht schon beim Aufnehmen zensieren. 2. überlappende Flächen mit verschiedenem landuse = landuse=military; als zweite Fläche landuse=forest Nachteil: Darstellung durch Renderer zufällig, Doppelzählung bei Flächenberechnungen die Doppelzählung kann ich nicht nachvollziehen: klar wird dasselbe Stück Boden mehrfach gezählt, aber in anderen Rubriken. Wenn ich alle landwirtschaftlich genutzten Flächen haben will, dann kommt (bei vollständigen und richtigen Daten) auch das raus, was ich haben will. Gibt es für das Problem schon eine übliche Lösung? Keine allgemeine. Kann es m.E. auch gar nicht geben, das hängt zu sehr von der Situation ab. Dass Bäume eine ausschließliche Nutzung sein sollen ist aber sicher kein Zustand, den man ewig mit sich rumschleppen will. Ein Auseinanderpfriemeln von landuse, natural und ggf. Einführung von landcover könnte aber sicher mithelfen, das ein bisschen klarer werden zu lassen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] generisches Landuse für bebautes Land
Am 25. Januar 2011 04:49 schrieb Johann H. Addicks addi...@gmx.net: Am 25.01.2011 01:20, schrieb Stephan Wolff: Es gibt afaik keine Entsprechung für das in den Bebauungsplänen so gern gewählte Mischbebauung. ja, leider. Auch sonst lässt sich die BauNVO (Nutzungsverordnung, http://www.gesetze-im-internet.de/baunvo/index.html#BJNR004290962BJNE001002307 ) nur schlecht auf OSM übertragen. Wir haben in den Bereichen, die vor allem vorkommen, (Wohngebiet, Gewerbegebiet, Industriegebiet) kaum Klassen, während einige Spezialfälle schon recht detailliert abgebildet werden. Prinzipiell würde ich der amtlichen deutschen Unterteilung ihren Sinn nicht absprechen, und es wäre nicht schlecht, wenn man bei Bedarf mind. auf diesem Basislevel ankommen könnte. Die BauNVO sieht diese Nutzungsarten vor (in Bebauungsplänen wird das dann z.T. noch deutlich feiner spezifiziert, Freitext ist möglich/üblich): § 2 Kleinsiedlungsgebiete § 3 Reine Wohngebiete § 4 Allgemeine Wohngebiete § 4a Gebiete zur Erhaltung und Entwicklung der Wohnnutzung (besondere Wohngebiete) § 5 Dorfgebiete § 6 Mischgebiete § 7 Kerngebiete § 8 Gewerbegebiete § 9 Industriegebiete § 10 Sondergebiete, die der Erholung dienen § 11 Sonstige Sondergebiete Der Unterschied z.B. zwischen einem reinen Wohngebiet und einem allgemeinen Wohngebiet liegt darin, welche Nicht-wohnnutzungen zusätzlich grundsätzlich erlaubt sind (Erlaubnisse und Befreiungen gibts extra, es können also Ausnahmen entstehen, genauso wie sie auch durch sonstige Sondergebiete möglich sind). Wenn man das mit OSM vergleicht, dann fehlen offenbar derzeit folgende Nutzungsarten, bzw. sind derzeit sehr grob enthalten (dann besser subtagging als neue Klasse): - Dorfgebiete - Mischgebiete - Kerngebiete - Gewerbegebiete (Industry light) und ggf. ein Sondergebiet, welches man durch subtags verfeinern könnte, damit nicht für jede Besonderheit gleich ne neue Klasse entstehen muss. Hat jemand Lust, ein Proposal dazu zu erstellen? Ich komme gerade nicht dazu und habe auch noch ein paar Proposals am Laufen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 24.01.2011 21:18, schrieb Chris66: Am 24.01.2011 21:07, schrieb Frederik Ramm: Es gibt eine Reihe von Gruenden, die gegen Strassenrelationen zur Adressierung sprechen: * weitaus weniger benutzt * komplizierter einzugeben, komplizieter auszuwerten * Adressen und Strassen sind unterschiedliche Konzepte (das Haus mit der Adresse X-Strasse 1 kann auch in der Y-Strasse stehen) Fuer die Relationen spricht, dass dabei Daten gespart werden Naja, wer Daten sparen will kann ja die schöne Erfindung der addr:interpolation nutzen. Sieht in my opinion auch schöner als sowas aus : http://www.openstreetmap.org/?lat=51.65894lon=7.07692zoom=17 ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Einfach die Häuser dazu zeichnen, dann siehts auch nicht mehr so schlimm aus. Wenn das aber schon schlimm für dich ist, schau bloß nicht zu unseren nödlichen Nachbarn... ;-) Wenn man die Adressen genau hat, sollte man sie auch genau eintragen und nicht interpolieren. Interpolieren ist aber besser, als nur einen Node jeweils am Straßenanfang und das ist wiederum besser als gar keine Hausnummern. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Rasweg
muss mal wieder was fragen! die RAdwegstrecke ist hier unterbrochen: http://www.openstreetmap.org/?lat=50.60036lon=6.29442zoom=17layers=C ich weis nicht wie ich die Lücke schließen soll (ein STück Straße, Kreisverkehr) Ich habe schon einiges ausprobiert aber nicht das richtieg gefunden Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25.01.11 12:02, schrieb Steffen Heinz: muss mal wieder was fragen! die RAdwegstrecke ist hier unterbrochen: http://www.openstreetmap.org/?lat=50.60036lon=6.29442zoom=17layers=C ich weis nicht wie ich die Lücke schließen soll (ein STück Straße, Kreisverkehr) Ich habe schon einiges ausprobiert aber nicht das richtieg gefunden Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Der Kreisverkehr stellt kein Problem dar: einfach komplett mit rein (also den Radweg aussenrum). Josm erkennt solche Kreisverkehre schon von alleine, und meckert nicht in der Relationsdarstellung. Die nördliche Straße ohne Radweg musst du an der Kreuzung mit dem Kreisverkehrsradweg aufteilen, und den Schnipsel zwischen Radweg und Straßenkreisverkehr aus der Radrelation rausnehmen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25.01.2011 12:02, schrieb Steffen Heinz: muss mal wieder was fragen! die RAdwegstrecke ist hier unterbrochen: http://www.openstreetmap.org/?lat=50.60036lon=6.29442zoom=17layers=C ich weis nicht wie ich die Lücke schließen soll (ein STück Straße, Kreisverkehr) Ich habe schon einiges ausprobiert aber nicht das richtieg gefunden Hi, hab's repariert. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25.01.11 12:28, schrieb Chris66: Am 25.01.2011 12:02, schrieb Steffen Heinz: muss mal wieder was fragen! die RAdwegstrecke ist hier unterbrochen: http://www.openstreetmap.org/?lat=50.60036lon=6.29442zoom=17layers=C ich weis nicht wie ich die Lücke schließen soll (ein STück Straße, Kreisverkehr) Ich habe schon einiges ausprobiert aber nicht das richtieg gefunden Hi, hab's repariert. Du willst dich also an der Missachtung benutzungspflichtiger Radwege mitschuldig machen? Gruß und SCNR, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] VOTING für historic:civilization
Seit ein paar Tagen kann man für historic:civilization abstimmen. Würde mich über Beteiligung freuen. Leider scheint im Wiki was nicht zu stimmen, jedenfalls findet die Suche nach diesem Term überhaupt nichts, daher hier der Hinweis. http://wiki.openstreetmap.org/wiki/Proposed_features/historic:civilization#Voting Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mailingliste im Thunderbird-Newsreader
Hi ! vor längerer Zeit wurde die lokale Mailingliste für Lübeck eingerichtet. Kann mir einer sagen warum diese in meinem Thunderbird-Newsgruppen-Verzeichnis (gmane.comp.gis.openstreetmap.) trotz aktualisieren immer noch nicht angezeigt wird? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 23.01.2011 12:47, schrieb Chris66: Am 23.01.2011 12:16, schrieb ht321: wo werden die Adressangaben wie 'city', 'country' etc. bei einer Adressrelation am sinnvollsten eingetragen: der Trend geht weg von den Relationen. Also einfach die Infos (5er Pack) addr:street/housenumber/country/city/postcode als Node oder an's Building pappen. Ich empfinde den Trend bedenklich, immer mehr Informationen in einzelnen Nodes abzulegen ohne die logischen Zusammenhänge ebenfalls in der Datenbank zu erfassen. Im höchsten Zoomlevel hat man dann zwar eine gute Darstellung, aber selbst ein idealer Renderer hat keine Chance, Einzelobjekte zusammenzufassen und brauchbare Abstraktionen für mittlere Zoomlevel zu erzeugen. Anwendungen erkennen keine Strukturen und können nur Wolken von Einzelpunkten auswerten. Der gleiche Einwand gilt natürlich auch für kurze Straßenstücke (Abbiegespuren) und parallellaufende Wege (Linienbündel). Eine universelle Lösung dieses Probleme gibt es vermutlich nicht, aber wir sollten uns bemühen, die Informationen möglichst sinnvoll erschließbar zu machen. Adressangaben als Einzelnode/building machen eine brauchbare Darstellung im Zoomlevel 15-16 schwer bis unmöglich. Ein Renderer könnte bestenfalls auf feste Texte in housenumber testen (1,21, 41,...) um eine Auswahl zu treffen. Zusammenhänge in den Adressen müssen erraten werden (gehören zwei Adressen mit gleichen Straßennamen und PLZ aber unterschiedlichen Ortsnamen zur selben Straße?). Zusätzliche Linien zur Adressinterpolation würden grundsätzlich eine bessere Auswahl der Hausnummern in einer Karte erlauben (1, 2 und die Endpunkte der Linien). Relationen können Adressdaten bündeln und dabei das Wissen der Mapper nutzen. Sie erlauben es (viel einfacher als bei einer Suche in Einzelpunkten) die niedrigste und höchste Hausnummer einer Straße zu ermitteln. Relationen sparen Speicherplatz, wenn man Teile der Adresse nur in der Relation ablegt. Sie benötigen einen höheren Aufwand beim Erstellen, aber machen die Datenpflege teils einfacher. Ich denke, OSM sollte mehr sein als eine riesige POI-Sammlung. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] generisches Landuse für bebautes Land
Am 25. Januar 2011 11:46 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 25. Januar 2011 04:49 schrieb Johann H. Addicks addi...@gmx.net: Am 25.01.2011 01:20, schrieb Stephan Wolff: Es gibt afaik keine Entsprechung für das in den Bebauungsplänen so gern gewählte Mischbebauung. ja, leider. Auch sonst lässt sich die BauNVO (Nutzungsverordnung, http://www.gesetze-im-internet.de/baunvo/index.html#BJNR004290962BJNE001002307 ) nur schlecht auf OSM übertragen. Wir haben in den Bereichen, die vor allem vorkommen, (Wohngebiet, Gewerbegebiet, Industriegebiet) kaum Klassen, während einige Spezialfälle schon recht detailliert abgebildet werden. Prinzipiell würde ich der amtlichen deutschen Unterteilung ihren Sinn nicht absprechen, und es wäre nicht schlecht, wenn man bei Bedarf mind. auf diesem Basislevel ankommen könnte. Die BauNVO sieht diese Nutzungsarten vor (in Bebauungsplänen wird das dann z.T. noch deutlich feiner spezifiziert, Freitext ist möglich/üblich): § 2 Kleinsiedlungsgebiete § 3 Reine Wohngebiete § 4 Allgemeine Wohngebiete § 4a Gebiete zur Erhaltung und Entwicklung der Wohnnutzung (besondere Wohngebiete) § 5 Dorfgebiete § 6 Mischgebiete § 7 Kerngebiete § 8 Gewerbegebiete § 9 Industriegebiete § 10 Sondergebiete, die der Erholung dienen § 11 Sonstige Sondergebiete Wer sich damit auskennt kann ja ein residential=de:6_BauNVO etc. verwenden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Solange der Radweg auf einem straßenbegleitenden Radweg verläuft, nehme ich egtl. immer die Straße in die Relation und nicht den Radweg, eben weil dieser egtl. ein oneway sein müsste und ich keine Lust auf doppelte Arbeit hab. Wenn der Radweg für beide Richtungen freigegeben ist, dann kommt die Relation auf den Radweg. Viele Grüße, Henning, der das gesonderte erfassen straßenbegleitender Wege ohnehin verteufelt. Am 25.01.2011 13:35, schrieb Chris66: Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mailingliste im Thunderbird-Newsreader
Am 25.01.11 13:33, schrieb Jan Tappenbeck: Hi ! vor längerer Zeit wurde die lokale Mailingliste für Lübeck eingerichtet. Kann mir einer sagen warum diese in meinem Thunderbird-Newsgruppen-Verzeichnis (gmane.comp.gis.openstreetmap.) trotz aktualisieren immer noch nicht angezeigt wird? Vielleicht muß man die Liste bei gmane noch extra anmelden? Von alleine schauen die ja nicht nach, was es bei osm alles neues geben könnte... Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25.01.2011 13:55, schrieb Stephan Wolff: Am 23.01.2011 12:47, schrieb Chris66: Am 23.01.2011 12:16, schrieb ht321: wo werden die Adressangaben wie 'city', 'country' etc. bei einer Adressrelation am sinnvollsten eingetragen: der Trend geht weg von den Relationen. Also einfach die Infos (5er Pack) addr:street/housenumber/country/city/postcode als Node oder an's Building pappen. Ich empfinde den Trend bedenklich, immer mehr Informationen in einzelnen Nodes abzulegen ohne die logischen Zusammenhänge ebenfalls in der Datenbank zu erfassen. Im höchsten Zoomlevel hat man dann zwar eine gute Darstellung, aber selbst ein idealer Renderer hat keine Chance, Einzelobjekte zusammenzufassen und brauchbare Abstraktionen für mittlere Zoomlevel zu erzeugen. Anwendungen erkennen keine Strukturen und können nur Wolken von Einzelpunkten auswerten. Der gleiche Einwand gilt natürlich auch für kurze Straßenstücke (Abbiegespuren) und parallellaufende Wege (Linienbündel). Eine universelle Lösung dieses Probleme gibt es vermutlich nicht, aber wir sollten uns bemühen, die Informationen möglichst sinnvoll erschließbar zu machen. Der Zusammenhang ist doch in den Tags enthalten. addr:street ist bei allen Objekten einer Straße gleich. Der Auswerter muss also nur alle Objekte finden und dann sinnvoll Gliedern. Bspw. nur 1,2,5,6,11,12,... anzeigen. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25. Januar 2011 13:35 schrieb Chris66 chris66...@gmx.de: Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25. Januar 2011 13:55 schrieb Stephan Wolff s.wo...@web.de: Ich empfinde den Trend bedenklich, immer mehr Informationen in einzelnen Nodes abzulegen ohne die logischen Zusammenhänge ebenfalls in der Datenbank zu erfassen. die räumlichen Zusammenhänge ergeben sich allerdings automatisch, das sollte bei Hausnummern z.B. ausreichen. Im höchsten Zoomlevel hat man dann zwar eine gute Darstellung, aber selbst ein idealer Renderer hat keine Chance, Einzelobjekte zusammenzufassen und brauchbare Abstraktionen für mittlere Zoomlevel zu erzeugen. doch, die hätte er (gleiche Straße, gleiche Gegend, gleiche PLZ, gleiche Stadt, ...) Anwendungen erkennen keine Strukturen und können nur Wolken von Einzelpunkten auswerten. kommt auf die Anwendung an... ...Zusammenhänge in den Adressen müssen erraten werden (gehören zwei Adressen mit gleichen Straßennamen und PLZ aber unterschiedlichen Ortsnamen zur selben Straße?). wenn die Straße verbunden ist vermutlich ja, sonst eher mal vorsichtig sein Zusätzliche Linien zur Adressinterpolation würden grundsätzlich eine bessere Auswahl der Hausnummern in einer Karte erlauben (1, 2 und die Endpunkte der Linien). zusätzliche Interpolation, wenn die Nummern bereits fortlaufend sind? Wahrscheinlich meinst Du, fortlaufende Nummern zu verbinden? Den Mehrwert kann ich nicht erkennen, man könnte aber natürlich eine Relation bemühen. Relationen auszuwerten finde ich z.B. nicht so einfach (persönlich komme ich da an Grenzen, man müsste in der Mapnik-Kette als ersten Schritt Modifikationen in C vornehmen, damit die Relationen überhaupt von osm2psql umgewandelt werden). ermitteln. Relationen sparen Speicherplatz, wenn man Teile der Adresse nur in der Relation ablegt. Sie benötigen einen höheren Aufwand beim Erstellen, aber machen die Datenpflege teils einfacher. dagegen, nur Relationen zu verwenden: da geht viel öfter kaputt als einfache Datenstrukturen. Hier editieren ja nicht nur Profis, sondern eben vor allem Amateure, die meisten mit Potlatch, das sich bisher nicht direkt durch gutes Relationenhandling hervorgetan hat. Ich denke, OSM sollte mehr sein als eine riesige POI-Sammlung. ich denke, das ist es bereits ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] generisches Landuse für bebautes Land
Am 25. Januar 2011 14:02 schrieb Falk Zscheile falk.zsche...@googlemail.com: Am 25. Januar 2011 04:49 schrieb Johann H. Addicks addi...@gmx.net: Es gibt afaik keine Entsprechung für das in den Bebauungsplänen so gern gewählte Mischbebauung. z.B. für Wohnhäuser mit Geschäften im Erdgeschoss Oder Wohnhaus mit Handwerksbetrieb im Hof Es gibt aber keine Hindernisse, landuse=residential durch ein Subtag residential=[wasauchimmer] insoweit zu erweitern. ja, wobei eine Erweiterung von landuse=residential immer eine Art von Wohngebiet sein sollte. Das für Mischgebiete zu verwenden würde ich eher nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Idee für Relationssplittung
Hi ! ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] generisches Landuse für bebautes Land
Am 25. Januar 2011 14:05 schrieb Falk Zscheile falk.zsche...@googlemail.com: § 2 Kleinsiedlungsgebiete § 3 Reine Wohngebiete § 4 Allgemeine Wohngebiete § 4a Gebiete zur Erhaltung und Entwicklung der Wohnnutzung (besondere Wohngebiete) § 5 Dorfgebiete § 6 Mischgebiete § 7 Kerngebiete § 8 Gewerbegebiete § 9 Industriegebiete § 10 Sondergebiete, die der Erholung dienen § 11 Sonstige Sondergebiete Wer sich damit auskennt kann ja ein residential=de:6_BauNVO etc. verwenden. dagegen. Das sind m.E. so elementare Dinge, dass ich mir da international einheitliches Tagging wünschen würde. Sowas wie de:6_BauNVO könnte man in einen legal-tag für Baurecht einsetzen (z.B. mit amtlicher Grundlage, Bebauungs- und Flächennutzungspläne sind ja gemeinfrei), aber nicht als Klassifizierung im landuse-tag. Es fehlen ja auch nur einzelne Werte: * Gewerbegebiet - könnte man als landuse=industrial und Zusatztag light oder so taggen. Auch Lagerhallen und Schrottplätze werden ja als industrial getaggt, eine Unterscheidung von Produktionsflächen wäre da z.B. auch nicht schlecht (subtag). * Sondergebiete werden bisher jeweils einzeln als Hauptklasse definiert, könnte man auch mit subtags regeln, um eine Basiskarte auch schon etwas einfacher herstellen zu können * Dorfgebiete könnte man erfinden, sowas gibt's überall. Evtl. ist das auch eine übergeordnete Einheit, mit der man die einzelnen Landuses wie farmyard zusammenfassen könnte (Multipolygon-Relation). * Mischgebiete fehlen m.E. * Kerngebiete sind bei uns AFAIK commercial/retail, gibt es sowohl mit Wohnnutzungen als auch ohne. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.11 15:33, schrieb Jan Tappenbeck: Hi ! ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? In josm: Relation im Relationseditor sortieren lassen (Symbol A..Z) dem letzten/ersten Element an der Trennung ein role-Tag verpassen Relation duplizieren (Pfeil nach unten rechts) in jeder der beiden Relationen die überflüssigen von/bis zu den role-getaggten rauslöschen (Symbol Papierkorb) Man kann auch mehrere Elemente zum löschen markieren. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg
Am 25.01.2011 13:35, schrieb Chris66: Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. das isses ja, ich weis nicht wie das geht! Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg
Am 25.01.2011 12:28, schrieb Chris66: Ich habe schon einiges ausprobiert aber nicht das richtieg gefunden Hi, hab's repariert. danke, schreib mal wie dus gemacht hast, mir privat das mit der relation hab ich nicht verstanden Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg
Am 25.01.2011 15:58, schrieb Steffen Heinz: danke, schreib mal wie dus gemacht hast, mir privat das mit der relation hab ich nicht verstanden In Josm zunächst einen Way selektiert der in der Relation enthalten ist, in den Eigenschaften die zugehörige Rela angeklickt und geöffnet. Dann die fehlenden Ways selektiert und im Rela-editor hinzugefügt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anmeldeprozedur
Das eine deutsche Version der CTs benutzerfreundlicher wäre ist wohl unbestritten. Allerdings ist es, so wie die Situation heute ist, -sehr- unwahrscheinlich (aus bereits mehrfach dargelegten Gründen), dass die OSMF resp. die LWG einverstanden wäre eine solche Version als bindend zu veröffentlichen und alternativ zu den bestehenden Versionen zu akzeptieren. Die Sachlage ist heute eher so, dass die Tatsache ob die CTs und ODBL mit der aktuellen OS (die Kartographiebehörde in England, einem irrelevanten Land mit sehr wenig Mappern) Lizenz kompatibel ist, mehrere Grössenordnung mehr Priorität hat in den Köpfen der Leute die schlussendlich bestimmen, als die Bedürfnisse der gut 50% der aktiven Mapper die deutschsprachig sind. Nur, solange auf talk-de auf Selbstbefriedigung gemacht wird und die Diskussion und Anliegen nicht den richtigen Ansprechpartnern zugetragen werden (d.h. schlussendlich legal-talk Maillinglist, die LWG und dem OSMF Board), wird sich auch nichts an den Prioritäten ändern. Simon Am 23.01.2011 13:46, schrieb Ulf Möller: Am 23.01.2011 12:04, schrieb M∡rtin Koppenhoefer: Wenn er es kostenlos macht, spricht m.E. nichts dagegen (würde ich aber nicht erwarten, und auch für unverschämt halten, es zu fragen, ist ja viel Arbeit), ansonsten halte ich es für Geldverschwendung, da das deutsche Recht eine deutsche Version nicht verbindlich vorschreibt. Solange die Details noch überarbeitet werden, sehe ich das auch so. Wenn die endgültige Fassung feststeht, finde ich eine Übersetzung schon sinnvoll, weil es benutzerfreundlicher ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg
Am 25.01.2011 16:10, schrieb Chris66: Am 25.01.2011 15:58, schrieb Steffen Heinz: danke, schreib mal wie dus gemacht hast, mir privat das mit der relation hab ich nicht verstanden In Josm zunächst einen Way selektiert der in der Relation enthalten ist, in den Eigenschaften die zugehörige Rela angeklickt und geöffnet. Dann die fehlenden Ways selektiert und im Rela-editor hinzugefügt. danke... hatte schon einige probiert, nur so nicht! Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25.01.2011 13:55, schrieb Stephan Wolff: Am 23.01.2011 12:47, schrieb Chris66: addr:street/housenumber/country/city/postcode als Node oder an's Building pappen. Ich empfinde den Trend bedenklich, immer mehr Informationen in einzelnen Nodes abzulegen ohne die logischen Zusammenhänge ebenfalls in der Datenbank zu erfassen. Im höchsten Zoomlevel hat man dann zwar eine gute Darstellung, aber selbst ein idealer Renderer hat keine Chance, Einzelobjekte zusammenzufassen und brauchbare Abstraktionen für mittlere Zoomlevel zu erzeugen. Ein idealer Renderer kann sehr wohl die Hausnummern einer Straße zusammenfassen (dank addr:street und geographischer Nähe). Dann könnte er z.B. einen gedachten Way entlang der Nodes/Hausmittelpunkte legen und nur die Hausnummern vor und nach einem Schnitt des gedachten Ways mit einer abzweigenden Straße darstellen. Unsere heutigen Renderer schaffen so etwas nicht mal im Ansatz, aber den idealen Renderer hast du ins Spiel gebracht - es ist ein beachtlicher Aufwand, aber keineswegs unmöglich. Das zeigt, dass die nötigen Infos durchaus vorhanden sind. Die Frage läuft also eher darauf hinaus, ob wir Hilfskonstrukte einbauen sollten, die den Entwicklern von Anwendungen die Arbeit erleichtern. Gerade dann, wenn sie keine echte Zusatzinformation anbieten, sondern nur vorhandene Information leichter zugänglich machen. (Ähnlicher Gedankengang übrigens wie die imaginären Ways über Plätze, die unlängst diskutiert wurden.) Ich würde sagen: Auf keinen Fall dann, wenn das Hilfskonstrukt deutlich komplizierter ist als die einfache Eintragung. Wenn etwa statt gewöhnlichen Tags an Gebäuden oder POIs eine Relation für jede Straße nötig wird, dann finde ich das zu teuer. Adressangaben als Einzelnode/building machen eine brauchbare Darstellung im Zoomlevel 15-16 schwer bis unmöglich. Ein Renderer könnte bestenfalls auf feste Texte in housenumber testen (1,21, 41,...) um eine Auswahl zu treffen. Die sinnvollste Lösung für unperfekte Renderer liegt m.E. in den vorhandenen Systemen, die zu dichte/überlappende Beschriftungen verhindern. Damit könnte man die Darstellung in ähnlicher Weise vom Abstand zwischen den Hausnummern abhängig machen. Schließlich wäre bei verstreut liegenden Häusern eine häufigere Nennung der Hausnummern angebracht als bei einer geschlossenen Bebauung entlang einer Straße. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.2011 15:40, schrieb André Joost: Am 25.01.11 15:33, schrieb Jan Tappenbeck: ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? In josm: Relation im Relationseditor sortieren lassen (Symbol A..Z) dem letzten/ersten Element an der Trennung ein role-Tag verpassen Relation duplizieren (Pfeil nach unten rechts) in jeder der beiden Relationen die überflüssigen von/bis zu den role-getaggten rauslöschen (Symbol Papierkorb) Kennt jemand den Macher des Relations-Analyzer? Weil der sortiert ja vermutlich intern, um Lücken rauszufinden, hat also das wichtigste nötige Werkzeug schon eingebaut, da sollte es ein leichtes (?) sein, die Einzelsegmente als eigene Relation ausgliedern zu lassen vom RA. Dann bräuchte man nur an der passenden Stelle kurzfristig ein Loch reinzubasteln, bevor man RA bemüht ... Am besten gleich eine Master-Relation mit anlegen lassen, wenn noch nicht da. Oder generell eine Option, den RA die Relation sortiert auf den Server zu laden. Die Ideen kamen mir kürzlich mal, als ich den RA paar größere Relationen prüfen ließ. Oder man baut im RA gleich ein teile nach dem Weg _-Eingabefeld ein ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Hallo, On 25.01.2011 14:07, Henning Scholland wrote: Solange der Radweg auf einem straßenbegleitenden Radweg verläuft, nehme ich egtl. immer die Straße in die Relation und nicht den Radweg, eben weil dieser egtl. ein oneway sein müsste und ich keine Lust auf doppelte Arbeit hab. Wenn der Radweg für beide Richtungen freigegeben ist, dann kommt die Relation auf den Radweg. wenn die Radwege eingetragen sind, würde ich dem auch Tribut zollen, indem ich die Radrouten auf diese lege. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
On 25.01.2011 14:33, Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Ja, wobei forward bzw. backward die Beziehung zwischen der Richtung des Weges und der Richtung der Route angeben (forward, wenn Wegrichtung = Routenverlauf, backward, wenn Wegrichtung != Routenverlauf). Beispiel: http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF Dieses Konzept wird leider häufig falsch verstanden und daher z.B. bei Busrouten immer seltener benutzt. Die Alternativen sind: a) auf die Richtungsunterscheidung ganz verzichten b) separate Relationen für die Routen A-B und B-A anlegen. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Setzt voraus, dass die Relation sortiert ist und zumindest ich mache mir den Aufwand nicht. Relationen, die ich anlege, sind generell unsortiert. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25. Januar 2011 17:47 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Setzt voraus, dass die Relation sortiert ist und zumindest ich mache mir den Aufwand nicht. Relationen, die ich anlege, sind generell unsortiert. seit die API die Relationsreihenfolge beibehält, ist das eigentlich schon nicht schlecht, wenn man sie einträgt. JOSM sortiert einem die Relationen so es geht auch automatisch, ist also kein großer Aufwand. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reit- und Wanderkarte - Jahresrückblick
NopMap wrote: hike39 wrote: danke, bin nun anscheinend fündig geworden. Bin dabei über den Menuepunkt Verzeichnisse - Wanderwege gegangen. Allerdings hat es mich etwas verwundert, dass dort dann ein Gesamtverzeichnis aller Wanderwege aufgebaut wird, auch wenn ich mich z.B. nur für jene in Rheinland-Pfalz interessiere. Ja, ich weiß, die Liste stammt noch aus einer Zeit als die Karte halb so groß war und 10 mal weniger Wanderwege enthielt. Inzwischen sind das ja schon über 100.000km geworden. Das gehört alles mal neu gemacht, So, hat eine Weile gedauert, aber jetzt ist das ganze Thema mal generalüberholt. Die alte globale Webliste gehört der Vergangenheit an. Eine mehr oder weniger komplizierte Zuordnung zu Länderumrissen gibt es auch nicht mehr. Basis für die Wegeliste bildet jetzt ganz einfach der aktuelle Kartenausschnitt und Landesgrenzen spielen keine Rolle. Wesentlich einfacher und auch übersichtlicher. Umgekehrt gibt es jetzt die Möglichkeit, jedes Wandersymbol auf der Karte wie einen POI anzuklicken, um Infos über den Weg zu bekommen. Bin mit dem Ergebnis soweit ganz zufrieden - aber es würde mich interessieren wie Andere damit zurecht kommen. bye Nop -- Hallo Alle Im Infomodus gibt es die Auswahl Anzeige Reitbetriebe. Ich habe für das zugehörige Tagging nichts gefunden. Insbesondere ob nur Nodes oder auch Areas ausgewertet werden. Habe nämlich zwei Reitbetriebe in meiner Gegend, aber es wird nur einer angezeigt. Gruss Loth ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserlauf sichtbar machen.
Am 21.01.2011 19:12, schrieb Christian H. Bruhn: Es läuft gerade eine Abstimmung zu einem default layer für Tunnel und Brücken [1]. [1] http://wiki.openstreetmap.org/wiki/Proposed_features/default_layer_for_bridge_and_tunnel Der Vollständigkeit halber hier noch das Ergebnis der Abstimmung: 37 Nein-Stimmen 18 Ja-Stimmen 2 Unentschieden Das Proposal ist damit abgelehnt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.2011 17:37, schrieb Heiko Jacobs: Am 25.01.2011 15:40, schrieb André Joost: Am 25.01.11 15:33, schrieb Jan Tappenbeck: ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? In josm: Relation im Relationseditor sortieren lassen (Symbol A..Z) dem letzten/ersten Element an der Trennung ein role-Tag verpassen Relation duplizieren (Pfeil nach unten rechts) in jeder der beiden Relationen die überflüssigen von/bis zu den role-getaggten rauslöschen (Symbol Papierkorb) Kennt jemand den Macher des Relations-Analyzer? Weil der sortiert ja vermutlich intern, um Lücken rauszufinden, hat also das wichtigste nötige Werkzeug schon eingebaut, da sollte es ein leichtes (?) sein, die Einzelsegmente als eigene Relation ausgliedern zu lassen vom RA. Dann bräuchte man nur an der passenden Stelle kurzfristig ein Loch reinzubasteln, bevor man RA bemüht ... Am besten gleich eine Master-Relation mit anlegen lassen, wenn noch nicht da. Oder generell eine Option, den RA die Relation sortiert auf den Server zu laden. Die Ideen kamen mir kürzlich mal, als ich den RA paar größere Relationen prüfen ließ. Oder man baut im RA gleich ein teile nach dem Weg _-Eingabefeld ein ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ne, das wäre nicht gut, da kompliziert und fehleranfällig, wenn man nicht genau weiß was man tut. Besser wäre es, wenn man selektierte Wege in dem Relationseditor in den Daten markieren kann. Derzeit kann man immer nur ein Element mit Zoom auf markieren. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
On 25.01.2011 17:47, Manuel Reimer wrote: Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Setzt voraus, dass die Relation sortiert ist Wieso? Ein Sortieralgorithmus würde dann nach zwei Lösungen suchen: eine für den Pfad A-B und eine für den Pfad B-A (eine Kante muss in jeder der beiden Sortierungen enthalten sein, es sei denn, sie hat die Rolle forward oder backward, dann muss sie in genau einer Sortierung enthalten sein). Schwierig wird's jedoch bei Radrundwegen... und zumindest ich mache mir den Aufwand nicht. Relationen, die ich anlege, sind generell unsortiert. Gruß Manuel Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen erfassen
Am 25.01.2011 15:19, schrieb M∡rtin Koppenhoefer: Am 25. Januar 2011 13:55 schrieb Stephan Wolffs.wo...@web.de: Ich empfinde den Trend bedenklich, immer mehr Informationen in einzelnen Nodes abzulegen ohne die logischen Zusammenhänge ebenfalls in der Datenbank zu erfassen. die räumlichen Zusammenhänge ergeben sich allerdings automatisch, das sollte bei Hausnummern z.B. ausreichen. ... (gleiche Straße, gleiche Gegend, gleiche PLZ, gleiche Stadt, ...) Das ist schwierig auszuwerten. Es kann in wenigen km Entfernung zweimal Dorfstraße mit gleicher PLZ geben. Es kann aber auch lange Straßen mit zwei oder mehr PLZen geben. Ein Mapper schreibt den Gemeindenamen, ein anderer den Ortsteil, einer Hamburg, ein anderer Hansestadt Hamburg. ...Zusammenhänge in den Adressen müssen erraten werden (gehören zwei Adressen mit gleichen Straßennamen und PLZ aber unterschiedlichen Ortsnamen zur selben Straße?). wenn die Straße verbunden ist vermutlich ja, sonst eher mal vorsichtig sein Schon ein namenloser Kreisverkehr trennt die Straße. Relationen auszuwerten finde ich z.B. nicht so einfach (persönlich komme ich da an Grenzen, man müsste in der Mapnik-Kette als ersten Schritt Modifikationen in C vornehmen, damit die Relationen überhaupt von osm2psql umgewandelt werden). Ja, man braucht eine Erweiterung von osm2pgsql. Aber der Style wäre einfach. Eine Erkennung zusammenhängender Adressen über eine verbundene oder unverbundene Straße wäre im Mapnik-Style dagegen fast unmöglich. ermitteln. Relationen sparen Speicherplatz, wenn man Teile der Adresse nur in der Relation ablegt. Sie benötigen einen höheren Aufwand beim Erstellen, aber machen die Datenpflege teils einfacher. dagegen, nur Relationen zu verwenden: da geht viel öfter kaputt als einfache Datenstrukturen. Hier editieren ja nicht nur Profis, sondern eben vor allem Amateure, die meisten mit Potlatch, das sich bisher nicht direkt durch gutes Relationenhandling hervorgetan hat. Das mag sein. Aber wenn man einen Schreibfehler im Straßennamen korrigieren muss, möchte man auch mit Potlatch lieber eine Relation als viele Einzelnodes editieren. Ich denke, OSM sollte mehr sein als eine riesige POI-Sammlung. ich denke, das ist es bereits ;-) Übertreibung verdeutlicht ;-) Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Henning Scholland schrieb: Besser wäre es, wenn man selektierte Wege in dem Relationseditor in den Daten markieren kann. kann man Derzeit kann man immer nur ein Element mit Zoom auf markieren. nö, das hatten wir erst ganz kürzlich hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg80853.html malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Tatsache...jetzt wo du es sagst fällt es mir sogar selber wieder ein :-[ Henning Am 25.01.2011 21:56, schrieb malenki: Henning Scholland schrieb: Besser wäre es, wenn man selektierte Wege in dem Relationseditor in den Daten markieren kann. kann man Derzeit kann man immer nur ein Element mit Zoom auf markieren. nö, das hatten wir erst ganz kürzlich hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg80853.html malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Jan Tappenbeck schrieb: Hi ! ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? da anscheinend schon beide Relationen vorhanden sind: Beide im Relationseditor öffnen. Die abzusplittenden Elemente im 1. Relationseditor markieren und anschließend deren Objekte markieren lassen. Die markierten Objekte im 2. Relationseditor hinzufügen, doppelte dabei verneinen. Die markierten Elemente im 1. Relationseditor löschen. Alle Angaben ohne Gewähr, da nicht praktisch getestet. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse bei mehrfacher Landnutzung
Am 25.01.2011 05:47, schrieb Willi: Am Dienstag, 25. Januar 2011 07:28 schrieb Stephan Wolff [s.wo...@web.de] wenn ein Gelände mehrere verschiedene Nutzungen hat, ist es schwierig diese als landuse zu erfassen. Beispiele: - Militärgelände mit forstwirtschaftlich genutztem Wald Meines Erachtens ist hierfür ein guter Ansatz zunächst möglichst strikt zwischen Nutzung und Bedeckung einer Fläche zu unterscheiden. Hierfür gibt es - landuse http://wiki.openstreetmap.org/wiki/Key:landuse und - landcover als Vorschlag die Situation zu verbessern http://wiki.openstreetmap.org/wiki/Proposed_features/landcover . Das kannte ich noch nicht. Der Vorschlag löst aber mein Problem nicht, da es mehrere Nutzungsarten eines Geländes geben kann. Die Werte für Nutzung sollten dann nur reine Nutzung beinhalten und nichts über die Bedeckung aussagen. Dies ist zur Zeit nicht der Fall. Zum Beispiel sagt landuse=military etwas über die Nutzung und nichts über die Bedeckung aus. Aber landuse=orchard bedeutet sowohl landwirtschaftliche Nutzung als auch Bedeckung mit Bäumen oder Stauden. Eine konsequente Trennung ist schwierig. Manch Nutzungen implizieren eine Oberflächengestaltung. Bei landuse=grass scheint der Autor des Wikitextes nur an die Bedeckung und nicht an die Nutzung gedacht zu haben: An unspecified area were grass grows. E.g. a lawn in a park, the middle of a roundabout, part of a golf course, the side of the road, etc. Werden zur Darstellung der Nutzung Schraffuren und Symbole verwendet,... Die Darstellung ist eine zweite Frage. Je nach Zweck der Karte wird man ein tag deutlich darstellen, schwach überlagern oder weglassen. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse bei mehrfacher Landnutzung
Am 25. Januar 2011 23:32 schrieb Stephan Wolff s.wo...@web.de: Das kannte ich noch nicht. Der Vorschlag löst aber mein Problem nicht, da es mehrere Nutzungsarten eines Geländes geben kann. +1, die Lösung könnte da m.E. nur sein, verschiedene landuses überlappen zu lassen. Je nachdem wie man landuse definiert, kann es evtl. aber auch an jeder Stelle nur einen geben (sagen manche). Dann müsste man mal das komplette Konzept durchdenken. Ein landuse=military, der gleichzeitig Wald ist, müsste dann eben landcover=trees sein. Oder ein Übungsgelände ist eben gar kein landuse, sondern der landuse ist Wald, und das militärische Übungsgelände bekommt einen anderen tag als landuse. Ich persönlich sehe das Problem nicht, wenn man mehrere OSM-landuses überlappt. Eine konsequente Trennung ist schwierig. Manch Nutzungen implizieren eine Oberflächengestaltung. Bei landuse=grass scheint der Autor des Wikitextes nur an die Bedeckung und nicht an die Nutzung gedacht zu haben: ja, Gras ist kein Landuse, darin ist man sich weitgehend einig. Ist aber trotzdem praktisch und gedacht für Verkehrsinselgrün und ähnliches. Richtiger wäre m.E., es beim landuse als sowas wie Verkehrsnebenflächen oder so zu titulieren und landcover=grass zu verwenden. Zusätzlich gibt es ja noch natural, was auch keiner Logik folgen will ;-) (das ist mal eine Quelle, Bucht oder ein Gipfel, mal Wasser, Schlamm oder Gebüsch). Das könnte man m.E. für geographische Features wie die ersteren verwenden, und die physischen Werte wie water, scrub und mud könnten landcover werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse bei mehrfacher Landnutzung
Hallo, M∡rtin Koppenhoefer wrote: +1, die Lösung könnte da m.E. nur sein, verschiedene landuses überlappen zu lassen. Je nachdem wie man landuse definiert, kann es evtl. aber auch an jeder Stelle nur einen geben (sagen manche). Dann müsste man mal das komplette Konzept durchdenken. Ein landuse=military, der gleichzeitig Wald ist, müsste dann eben landcover=trees sein. Oder ein Übungsgelände ist eben gar kein landuse, sondern der landuse ist Wald, und das militärische Übungsgelände bekommt einen anderen tag als landuse. Ich hab schon professionelle Datensaetze gesehen, bei denen verschiedene Landuse-Typen ein Exklusivitaetsflag hatten, d.h. es gab eine Reihe von Basis-Landuse-Typen, die waren untereinander exklusiv (*entweder* Wald *oder* Wasser), und dann aber noch eine Reihe von zusaetzlichen Landuse-Typen, die beliebig hinzugemischt werden konnten. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg
Am 25.01.11 15:56, schrieb Steffen Heinz: Am 25.01.2011 13:35, schrieb Chris66: Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. das isses ja, ich weis nicht wie das geht! Da kann ich dir die Ausarbeitung von EvanE empfehlen: http://wiki.openstreetmap.org/w/images/7/76/Unterlagen-Workshop-Relationen.pdf Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Am 25.01.11 14:33, schrieb Falk Zscheile: Am 25. Januar 2011 13:35 schrieb Chris66chris66...@gmx.de: Am 25.01.2011 12:14, schrieb André Joost: Also wenn da schon ein straßenbegleitender Radweg eingetragen ist, solltest du das Radverkehrsnetz auch auf diesen legen. Naja, und wenn auf beiden Seiten ein Radweg ist, würde man ja auch die Straße in die Relation eintragen. Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? In diesem Fall nicht, weil das Radverkehrsnetz NRW keine vorgegebeene Richtung hat. Es handelt sich eher um ein Sammelsurium ausgeschilderter Radverbindungen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.11 17:37, schrieb Heiko Jacobs: Kennt jemand den Macher des Relations-Analyzer? Der leist hier gelegentlich mit ;-) Weil der sortiert ja vermutlich intern, um Lücken rauszufinden, hat also das wichtigste nötige Werkzeug schon eingebaut, hat josm auch. Oder generell eine Option, den RA die Relation sortiert auf den Server zu laden. Dazu müsste der RA aber auch um die OSM-Anmeldung erweitert werden. Mir ist es lieber, wenn sowas ausschliesslich im Editor gemacht wird. Dazu ist der schliesslich da. Es gibt ja auch Fälle, wo ich die Segmente lieber von Hand anordnen möchte. Eine Schleifenfahrt über einen Busbahnhof neben der Route bekommt man nämlich nicht automatisiert hin, oder ein Rundwanderweg, der auf den letzten Metern zum Parkplatz nochmal ein Stück des Hinwegs mit benutzt. Sowas erkennt auch die Sortierung von Josm nicht automatisch. Bie der Erkennung von Kreisverkehren hat josm WIMRE die Nase vorn. Gruß, André Joost Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.11 21:57, schrieb Georg Feddern: da anscheinend schon beide Relationen vorhanden sind: Beide im Relationseditor öffnen. Die abzusplittenden Elemente im 1. Relationseditor markieren und anschließend deren Objekte markieren lassen. Die markierten Objekte im 2. Relationseditor hinzufügen, doppelte dabei verneinen. Um sich das Verneinen bei einer größeren Anzahl zu sparen, kann man auch erst alle selektierten Objekte aus der Zweitrelation entfernen (Schaltfläche mit den durchgestrichenen Kästchen), anschließend hinzufügen. Die Selektion bleibt ja nach der ersten Operation erhalten. Nur die Sortierung ist dann im Ar***. Die markierten Elemente im 1. Relationseditor löschen. So kann man auch unabsichtlich duplizierte Relationen zusammenführen, wenn man nicht sicher ist, ob alle Elemente der ersten auch in der zweiten enthalten sind, und umgeklehrt. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
