Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Diese Antwort bezieht sich jetzt sowohl auf die Mail von Garry als auch auf die andere Antwort von Martin. Natürlich ist das keine Optimale Lösung, und nein, ich würde dieses Tool nicht einsetzen um die manuelle Unterteilung zu ersetzen. Ich denke aber, dass es sinnvoll sein könnte, die großen landuses erstmal automatisch zu teilen, um dann manuell die Grenzen zu verfeinern. Deine Aussage, Garry, damit gingen Daten verloren, stimmt ja nur, wenn du vorher landuses zusammenfasst, wo die Daten schon genauer sind. Da, wo Wälder über Bundesstraßen etc. liegen, sind die Daten aber noch nicht in der Datenbank. Gruß Peter P.S.: Nein, ich würde das Tool auch nicht als vollautomatisches Update laufen lassen wollen, sondern z.B. als JOSM-Plugin, mit dem ich ein landuse entsprechend splitten und dann nachbearbeiten kann - und dafür stell ich mir das ganz praktisch vor, weil einiges an Arbeit entfällt, die man beim systematischen manuellen Aufteilen hätte: Den alten Grenzverlauf da nachzuziehen, wo das große landuse-Poly zu Ende war, das Erstellen einer Relation, wenn gewünscht, das Setzen der Tags auf der Relation (oder alternativ auf den einzelnen Polygonen) und so weiter. Am 19.05.2011 01:23, schrieb Garry: Am 18.05.2011 14:38, schrieb Peter Wendorff: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simon: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gut dass Du den Smiley nicht vergessen hast. Dass kann man als Notlösung dort machen wo die Daten noch nicht besser sind. Markante Konturen gehen so verloren da sich bestenfalls der minimale, aber nie der reale Abstand zwischen Fahrbahn und Waldgrenze angeben lässt. Garry ___ 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] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 17:44, schrieb M∡rtin Koppenhoefer: Während das noch einfach ist, löst es doch das Problem nicht (oder nur dann, wenn es auch eine Straße einen Weg dort gibt, und der auch regelmäßig wie mit dem Lineal gezogen ist, es also keine Büsche und Bäume, Gräben und Feuchtgebiete gibt, und auch keine Flüsse und Bäche, deren Ufer nicht gemappt sind, und keine Sandflächen und Brachen und keine steilen Stellen, keinen Fels und wenn die Leute, die den Landuse taggen sowie die, die danach dort was mappen, konsequent alles, was nicht dieser Landuse ist, per Multipolyon ausschließen.). Ist mir ehrlich gesagt zu pauschal/approssimativ, fehleranfällig und steril. Man verliert halt praktisch sämtliche topographischen Eigenheiten des Gebiets. Eine schöne Karte sieht für mich anders aus. Gute Daten (vor allem auch stabile, die man einfach verändern/verfeinern kann, und die die Flächennutzung auch quantitativ wiedergeben, und nicht nur visuell solange die Renderreihenfolge nicht geändert wird), sehen m.E. auch anders aus. +1 Sehr gut die Problematik beschrieben! Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 14:38, schrieb Peter Wendorff: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simon: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gut dass Du den Smiley nicht vergessen hast. Dass kann man als Notlösung dort machen wo die Daten noch nicht besser sind. Markante Konturen gehen so verloren da sich bestenfalls der minimale, aber nie der reale Abstand zwischen Fahrbahn und Waldgrenze angeben lässt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seltsame Denkmaeler in Hamburg
Am 18.05.2011 12:16, schrieb Henning Scholland: Hallo, wäre es denkbar, dass das Gebäude denkmalgeschützt wäre? Kaum, dann sollten sie in der Denkmalliste stehen: http://www.hamburg.de/contentblob/201404/data/denkmalliste-gesamt.pdf Soweit ich sehe, wurden alle Changesets mit Potlatch 1.3 oder 1.4 angelegt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Pin und supercoole OSM-Tasse
Am Dienstag, 17. Mai 2011 schrieb Thomas Reincke: > Am 16.05.2011 23:19, schrieb RalfGesellensetter: > > Gratuliere - ich habe die Tasse am Samstag auf dem Linuxtag in Berlin > > gesehen! Gibt es den Entwurf irgendwo als Bild/Quelldatei? Ich finde > > Ist das diese Tasse? > http://shop.kernelconcepts.de/images/osm-mug-preview.png > Genau! Cool, das ist ja wirklich genau die Vorlage, das Logo ist das alte - schon gut gemacht, vielleicht sind die Farben nicht gerade die hübschesten, aber praktisch für Vieltagger! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM | Kartenmaterial | Anwendungsmöglichkeit |GARMIN.img
instaliere mal eine Karte von hier (http://dev.openstreetmap.de/aio/germany-daily/nsis/) das sollte die Suche teilweise funktionieren, auch wenn man die Daten überträgt. Was teilweise nun bedeutet .. muss jeder selber für seine Bedürfnisse klären. Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 14:38 schrieb Peter Wendorff : > Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: >> Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu >> bedenken, dass man problemlos größere Gebiete von angrenzenden >> gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber >> unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete >> zu bilden. > > Aufgabe an gelangweilte Programmierer (falls es solche gibt): > Tool, das genau das Problem löst: > Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit > (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von > dessen width-Tag aus. ;) Während das noch einfach ist, löst es doch das Problem nicht (oder nur dann, wenn es auch eine Straße einen Weg dort gibt, und der auch regelmäßig wie mit dem Lineal gezogen ist, es also keine Büsche und Bäume, Gräben und Feuchtgebiete gibt, und auch keine Flüsse und Bäche, deren Ufer nicht gemappt sind, und keine Sandflächen und Brachen und keine steilen Stellen, keinen Fels und wenn die Leute, die den Landuse taggen sowie die, die danach dort was mappen, konsequent alles, was nicht dieser Landuse ist, per Multipolyon ausschließen.). Ist mir ehrlich gesagt zu pauschal/approssimativ, fehleranfällig und steril. Man verliert halt praktisch sämtliche topographischen Eigenheiten des Gebiets. Eine schöne Karte sieht für mich anders aus. Gute Daten (vor allem auch stabile, die man einfach verändern/verfeinern kann, und die die Flächennutzung auch quantitativ wiedergeben, und nicht nur visuell solange die Renderreihenfolge nicht geändert wird), sehen m.E. auch anders aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Garry schrieb am 18.05.2011 11:30: > Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte > kein "inner" einer Waldfläche sein sondern eine Trennfläche zwischen > zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen > nodes. U.a. würde sonst ein spätere Detailverfeinerung > unnnötig kompliziert werden. Im Prinzip bin ich bei dir. In dem fraglichen Fall hier ist aber nicht Bahnstrecke entlang das landuse eingetragen worden, sondern nur das Bahnhofsgelaende (schaetze ich mal). Und Schritt 1 waere sicherlich erstmal, das man den Konflikt zwischen den beiden ueberlappenden Nutzungen aufloest. Ich selber wuerde auch eher den Wald entlang der Bahnstrecke teilen, da ich auch alles andere als ein Freund von multipolygon-Relationen bin. Denn schliesslich haben wir hier ja mal wieder einen der vielen Faelle, wo die Relation die Mapper ueberfordert hat. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM | Kartenmaterial | Anwendungsmöglichkeit |GARMIN.img
Hallo Zusammen! Vielleicht hat ein GARMIN + Windows + Mapsource-Nutzer eine Antwort auf meine Frage. Ausgangslage: - GARMIN Vista eTrex Hcx - GARMIN TOPO DE (2007) - GARMIN City Navigator NT - Win7 (32) PC - Suche für das Routing am PC über Mapsource +Startpunkt = Adresse oder Wegpunkt +Endpunkt = Adresse Funktioniert für die Planung am PC und unterwegs einwandfrei Ziel: Mit gleicher Hard- und Software die GARMIN-Karten ersetzen (weil alt) und statt dessen OSM-Kartenmaterial von http://www.raumbezug.eu/ag/internet/osmGarmin.htm aus der Quelle http://download.geofabrik.de/osm/europe/germany/ verarbeitet u.a. mit Mkgmap zu verwenden. Problem: - Kartenmaterial nach Anleitung (http://www.raumbezug.eu/downloads/dl/dl.php?id=31 )in Mapsource geleitet, aber eine Adressuche ist dort nicht möglich. - Kartenmaterial über Mapsource nach Speicherkarte GARMIN geleitet (nicht immer die ganze Karte, sondern ausgewählte Tiles und auch Stücke anderen Materials, wie z.B. der TOPO, daher durch Mapsource): auch keine Adresssuche - Routing nur von und zu bekannten POI oder Koordinaten Die vorverarbeitende Anwendung http://wiki.openstreetmap.org/index.php/Mkgmap beschreibt ja noch ein paar offen Baustellen. Frage: Sehe ich es richtig, dass ich das, was ich bisher mit dem GARMIN-Kartenmaterial gemacht habe, so mit aus dem unter "Ziel" genannten Quellen erhältlichen Material nicht genauso tun kann? Gruß Thomas ___ 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] Seltsame Denkmaeler in Hamburg
M∡rtin Koppenhoefer wrote: > Was haltet Ihr davon, wenn wir versuchen, dieses Thema (über > Relationen?) mal anzugehen? Genau! Wir brauchen unbedingt noch viel mehr Relationen! Sven -- The source code is not comprehensible (found in bug section of man 8 telnetd on Redhat Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simon: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dorf - Landuse reidental oder Bauernhof
Am 17.05.2011 16:29, schrieb M∡rtin Koppenhoefer: Naja, um Multipolygone an sich kommt man kaum drum rum, weder als Mapper noch als Datenverwerter. Derart einfache Renderer sind halt nicht geeignet, um OSM-Daten zu rendern. Grundsätzlich gibt es Darum schrieb ich ja auch "ohne Not". Bei kleinen Inselflächen wird man kaum darum herum kommen, aber aus einem Waldgebiet mit 10km Kantenlänge erhebliche andere Landuseflächen als "inner"-Polygon herauszuschneiden muss im Normalfall nicht sein. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 12:56, schrieb Martin Simon: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer: Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu einer "kompletter" aussehenden Karte, ist aber ungenau und führt zu erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: http://www.openstreetmap.org/browse/way/91584654 Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung größerer Gebiete gedacht, in denen durchaus auch Wege liegen können und (m.E.) sollen. Ein Problem liegt schon mal darin dass zu wenig zwischen "Bodenbedeckung" und Landnutzung unterschieden wird, damit könnte man sich sonst für die Zukunft viel Arbeit sparen wenn man jetzt schon konsequent unterscheidet. Ich würde wirklich nicht an jedem track oder path (oder für jedes Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig landuse=residential an jedem highway=residential, path oder gar der Am Anfang von OSM dachte man auch nocht nicht so sehr daran einzelne Gebäude einzutragen... Meine persönnliche Grenze bei Waldflächen ist dezeit bei Strassenkategorien oberhalb residential um die Aufwand nicht zu hoch zu treiben. Landuse=residential trenne ich eigentlich nur dann wenn die Strasse nicht "innerörtlich" ist. Wenn die Verfügbarkeit der Grundstücksgrenzen gegeben ist wäre Martins Vorschlag eleganter. Mir geht es vor allem auch darum dass ich lokal schnell Detailverbesserungen einbringen kann ohne mir Gedanken machen zu müssen dass deswegen in 10km Entfernung etwas kaputt geht weil sich jemand mit Multipolygonen zu sehr verkünstelt hat Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es natürlich anders aus. Landuse = rail ist ja inzwischen schon relativ gut verbreitet, bei landuse=road sieht es noch deutlich schlechter aus zumal es von den Rendereren nicht/kaum unterstützt wird. Von daher bin ich eher bei deinem ersten Beispiel als beim zweiten, wo landuse=farmland anscheinend für einzelne Felder (oder sogar die effektiv genutzte Acker-/Weidefläche via Luftbild) genommen wird, selbst wenn sie nicht durch (eingezeichnete) Wege unterbrochen werden. In den Niederlanden gab es einen Import von Waldflächen, der die Flächen aller Waldwege aussparte - was zu tausenden "Miniwäldern" führte und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort nicht nutzen kann, weil man dann praktisch alle Waldflächen verliert... Probleme hat man jetzt teilweise auch mit sehr grossen Waldflächen. Abgesehen davon wäre es ja nicht besonders geschickt die erhaltenen Daten wieder zu verschlechtern... Ich denke wir brauchen eher eigene tags für "Feld", "Flurstück" etc. und sollten landuse=* eine Ebene "höher" belassen, bei der Nutzung eines größeren Gebietes. Im Prinzip ja, halte ich aber nicht für durchsetzbar da schlagartig alle Anwendungen entsprechend umgestellt werden müssten. Martins Vorschlag kann dagegen fliessend umgesetzt werden Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 12:56 schrieb Martin Simon : > Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer : >> Multipolygonen. Ausserdem ist der Informationsgehalt ungleich >> geringer. > Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung > größerer Gebiete gedacht, in denen durchaus auch Wege liegen können > und (m.E.) sollen. m.E. kann ein Weg nicht im Landuse liegen (bzw. nur Wege auf Grundstücken). Landuse entspricht nicht dem Flächennutzungsplan (m.E.). > Ich würde wirklich nicht an jedem track oder path (oder für jedes > Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig > landuse=residential an jedem highway=residential, path oder gar der > Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es > natürlich anders aus. Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. > In den Niederlanden gab es einen Import von Waldflächen, der die > Flächen aller Waldwege aussparte - was zu tausenden "Miniwäldern" > führte ja, daran siehst Du ja schon: auch die Behörden arbeiten mit kleinen Stücken. Die sparen die Waldwege deshalb aus, weil es eben Sinn macht. > und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr > kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort > nicht nutzen kann, weil man dann praktisch alle Waldflächen > verliert... das ist ein kleineres Problem, das durch die derzeitige Unvollkommenheit bei der Kartenerstellung resultiert. Wir mappen ja nicht für mkgmap, und wenn es auf dem Garmin wünschenswert sein sollte, die Flächen vor (oder während oder nach) der Kartenerstellung zusammenzufassen, dann kann man das ja tun. Damit würde sich dieses Problem lösen. > Ich denke wir brauchen eher eigene tags für "Feld", "Flurstück" etc. > und sollten landuse=* eine Ebene "höher" belassen, bei der Nutzung > eines größeren Gebietes. Vorteil? Eigene Tags für Feld und Flurstück kann man ja gerne haben (z.B. um Namen und Nummern einzugeben), aber wäre es da nicht sinnvoller, auch gleich die Landnutzung mit ranzuhängen, als nochmal doppelt eine "Generalisierung der Landnutzung" zu überlagern, die man auch automatisch erstellen könnte? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seltsame Denkmaeler in Hamburg
Am 18.05.2011 12:16, schrieb Henning Scholland: Hallo, wäre es denkbar, dass das Gebäude denkmalgeschützt wäre? Selbst Teile könnten es sein, auch im Innenbereich (z.B. eine Treppe) oder Fassaden(gruppen) Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer : > Einzelne identifizierbare Flächen würde ich als solche mappen, und > nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu > einer "kompletter" aussehenden Karte, ist aber ungenau und führt zu > erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen > Multipolygonen. Ausserdem ist der Informationsgehalt ungleich > geringer. > > Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: > http://www.openstreetmap.org/browse/way/91584654 > > Wie ich es machen würde: > http://www.openstreetmap.org/browse/way/106441866 Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung größerer Gebiete gedacht, in denen durchaus auch Wege liegen können und (m.E.) sollen. Ich würde wirklich nicht an jedem track oder path (oder für jedes Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig landuse=residential an jedem highway=residential, path oder gar der Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es natürlich anders aus. Von daher bin ich eher bei deinem ersten Beispiel als beim zweiten, wo landuse=farmland anscheinend für einzelne Felder (oder sogar die effektiv genutzte Acker-/Weidefläche via Luftbild) genommen wird, selbst wenn sie nicht durch (eingezeichnete) Wege unterbrochen werden. In den Niederlanden gab es einen Import von Waldflächen, der die Flächen aller Waldwege aussparte - was zu tausenden "Miniwäldern" führte und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort nicht nutzen kann, weil man dann praktisch alle Waldflächen verliert... Ich denke wir brauchen eher eigene tags für "Feld", "Flurstück" etc. und sollten landuse=* eine Ebene "höher" belassen, bei der Nutzung eines größeren Gebietes. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NSG (war: See in Wald in (L|N)SG - Sichtbarkeitsproblem)
Am 18. Mai 2011 02:27 schrieb Stephan Wolff : > Moin! > > Am 17.05.2011 16:19, schrieb M∡rtin Koppenhoefer: >> >> Am 17. Mai 2011 14:30 schrieb Falk Zscheile: >>> >>> Verordnungen haben den Vorteil, dass aus ihnen der >>> Inhalt ohne weiteres entnommen werden kann ... Für die >>> Karten im Anhang einer Verordnung gilt das leider auch nicht ohne >>> weiteres. >> >> dagegen sollte man auch mal vorm Verfassungsgericht (oder >> Bundesverwaltungsgericht?) klagen: wenn man die Verordnung ohne die >> Karte nicht verstehen kann, dann sollte die Karte doch auch gemeinfrei >> sein, > Erfolgversprechender wäre wahrscheinlich eine Petition an den Deutschen > Bundestag. Wenn sich so viele Mitunterzeichner finden, dass die Petition > wahrgenommen und beraten wird, kommen jedenfalls die Argumente auf den > Tisch. Da eine Freigabe solcher Geodaten fast nichts kostet und heute jede > Partei offiziell die Bürgerbeteiligung fördern will, sehe ich eine kleine > Erfolgschance. > Geodaten sind meiner Meinung nach Ländersache. Eine Petition zu deren digitaler Freigabe müsste sich in diesem Fall an das jeweilige Landesparlament wenden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seltsame Denkmaeler in Hamburg
Am 18. Mai 2011 12:16 schrieb Henning Scholland : > Hallo, wäre es denkbar, dass das Gebäude denkmalgeschützt wäre? ja, das hört sich nach einer sinnvollen Erklärung an. Wobei historic=monument kein besonders sinnvolles Tagging dafür ist. Die Vorschläge (ggf. unvollständig) wie man Denkmäler erfassen könnte sind: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area http://wiki.openstreetmap.org/wiki/Talk:WikiProject_Germany/Kulturdenkmale Hier wird (falls die Vermutung stimmt) ein gängiges Problem deutlich: man sollte nicht verschiedene Objekte/Dinge der realen Welt in einem OSM-Objekt vereinen, weil sonst unklar ist, welcher tag sich auf welches Objekt bezieht. Z.B. ein Gebäude (building), mit Baujahr (start_date), wo dann, wenn eine Firma in diesem Gebäude sitzt, einfach der Name (name) und die Telefonnummer (phone) der Firma mit an das Gebäudeobjekt gehangen werden. Jetzt ist nicht mehr eindeutig, ob sich start_date auf das Gebäude oder die Firma bezieht (dito für den Namen). Was haltet Ihr davon, wenn wir versuchen, dieses Thema (über Relationen?) mal anzugehen? Sowas wie eine Rolle "Nutzer" z.B. wäre nicht schlecht. Dann könnte man sich auch die einzelnen Nodes sparen, die man bisher oft in Gebäude mit mehreren Nutzern einfügt. Ein Teil der Adresse wäre nur beim Nutzer (Stockwerk, Tür, Treppe), andere wären nur am Gebäude (Straße, Land, Hausnummer, etc.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NSG (war: See in Wald in (L|N)SG - Sichtbarkeitsproblem)
Am 18. Mai 2011 02:27 schrieb Stephan Wolff : > Falls Interesse besteht, schreibe ich einen Petitionstext und reiche diesen > nach einer Diskussion ein. Gern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seltsame Denkmaeler in Hamburg
Am 18.05.2011 10:50, schrieb Frederik Ramm: Hallo, zufaellig sind mir ein paar als historic=monument getaggte Nodes in Hamburg aufgefallen: FTA Film & Theaterausstattung GmbH 983251540 TherapieWege Angelika Richter Ergotherapie 983251541 Spielhalle Jackpot 983251554 Landesbetrieb Verkehr - Fahrerlaubnis 829910165 Landesbetrieb Verkehr - Zulassung 829910166 Zyto Service 842591456 Olympus 842591730 Olympus Trainingscenter 842592185 Olympus Medical 842592971 Olympus Medical 842592974 Olympus Medical Service 842593605 Tischler Innung 842595351 Kurvertier Service August Staar GmbH 842595804 Schlosserei 842596225 Hanse Hof 842596378 ISI 842596943 Membran International GmbH 842597173 GTÜ s & P Siggel & Co. Gmbh 842601564 C.f. Mirbach Hanse GmbH Autohaus SC Wedding Clubhaus 660820001 Praxis Hartung , Schenk 596559372 Stichprobenartige Pruefung ergab, dass die von unterschiedlichen Leuten angelegt wurden, also eher unwahrscheinlich, dass ein einzelner da seinen Editor nicht versteht. Gibt es Grund zu der Annahme, dass irgendeiner unserer Editoren in bezug auf historic=monument zu einer Fehlbedienung einlaedt? Die Liste oben ist nicht vollstaendig, ist mir nur zufaellig bei der Arbeit mit einer Liste von POIs in Hamburg aufgefallen. Kurzes grep ergibt allerdings, dass es weltweit nur 5 "historic=monument" gibt, die ein "GmbH" im Namen haben, d.h. ueber Hamburg hinaus scheint das Phaenomen nicht so verbreitet zu sein, (Bevor mir das Ausmass des Problems klar wurde, hatte ich eine "Stuber Automobile GmbH" bereits von historic=monument zu shop=car umgetaggt, aber den Rest ueberlasse ich lieber den Hamburgern - wer weiss, vielleicht ist das ja alles ein historisches Gewerbedorf oder sowas...) Hallo, wäre es denkbar, dass das Gebäude denkmalgeschützt wäre? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 11:30 schrieb Garry : > Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte > kein "inner" einer Waldfläche sein sondern eine Trennfläche zwischen zwei > einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. +1, sehe ich auch so. Wenn es geht, getrennte Polygone anlegen. Gemeinsame nodes können in so einem Fall eigentlich gar nicht existieren, da ja eine erhebliche Fläche dazwischenliegt. Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu einer "kompletter" aussehenden Karte, ist aber ungenau und führt zu erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: http://www.openstreetmap.org/browse/way/91584654 Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wirtschaftsgebäude in Ortslagen
Am 18. Mai 2011 09:15 schrieb Albrecht Will : > als ziemlich Neuer bei OSM fand ich bisher keine Hinweise, wie in einem > Dorf/Kleinstadt Wirtschaftsgebäude getagged werden könnten. Weglassen würde > bedeuten, dass ein Stadtplan reichlich Lücken aufwiese, sprich: Obwohl > eigentlich eine geschlossene Gebäudefront da ist, würden mit den Wohngebäuden > und Geschäften etwas "fremdes" entstehen. tagge sie einfach als das, was sie sind. Generell sind bauliche Anlagen in OSM erstmal building=yes, wenn man es genauer haben will (erstrebenswert m.E.), dann building=Gebäudetyp. Wirtschaftsgebäude ist ja ein Oberbegriff, meistens kann man es genauer spezifieren, um was es sich handelt (Küche, Speicher/Lager, Remise, Stall, ...). Wenn Du Dich nicht auf das Gebäude sondern den landuse beziehst, dann würde ich üblicherweise die Wirtschaftsgebäude zur Nutzung des Gebiets dazuschlagen, also Wirtschaftsgebäude auf einem Bauernhof z.B. in den landuse=farmyard miteinschließen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 16:43, schrieb Torsten Leistikow: Nicht ganz sauber ist allerdings das Multipolygon 8794: - Zwei jeweils geschlossenen, aneinandergrenzende outer-Mitglieder sind unnötig kompliziert, da sollte man lieber zwei Relationen draus machen. (In diesem Fall braucht der Weg 9719294 nicht mal ein Multipolygon sein, z.Z. gibt es da drin keine inner-Mitglieder.) - Mehrere Flaechen innerhalb des Multipolygons sind nicht als inner-Mitglieder eingetragen, obwohl sie nicht zur Waldflaeche dazugehoeren (z.B. Weg 53389956 landuse=rail oder Weg 47046253 landuse=commerial). Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte kein "inner" einer Waldfläche sein sondern eine Trennfläche zwischen zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. U.a. würde sonst ein spätere Detailverfeinerung unnnötig kompliziert werden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Seltsame Denkmaeler in Hamburg
Hallo, zufaellig sind mir ein paar als historic=monument getaggte Nodes in Hamburg aufgefallen: FTA Film & Theaterausstattung GmbH 983251540 TherapieWege Angelika Richter Ergotherapie 983251541 Spielhalle Jackpot 983251554 Landesbetrieb Verkehr - Fahrerlaubnis 829910165 Landesbetrieb Verkehr - Zulassung 829910166 Zyto Service 842591456 Olympus 842591730 Olympus Trainingscenter 842592185 Olympus Medical 842592971 Olympus Medical 842592974 Olympus Medical Service 842593605 Tischler Innung 842595351 Kurvertier Service August Staar GmbH 842595804 Schlosserei 842596225 Hanse Hof 842596378 ISI 842596943 Membran International GmbH 842597173 GTÜ s & P Siggel & Co. Gmbh 842601564 C.f. Mirbach Hanse GmbH Autohaus SC Wedding Clubhaus 660820001 Praxis Hartung , Schenk 596559372 Stichprobenartige Pruefung ergab, dass die von unterschiedlichen Leuten angelegt wurden, also eher unwahrscheinlich, dass ein einzelner da seinen Editor nicht versteht. Gibt es Grund zu der Annahme, dass irgendeiner unserer Editoren in bezug auf historic=monument zu einer Fehlbedienung einlaedt? Die Liste oben ist nicht vollstaendig, ist mir nur zufaellig bei der Arbeit mit einer Liste von POIs in Hamburg aufgefallen. Kurzes grep ergibt allerdings, dass es weltweit nur 5 "historic=monument" gibt, die ein "GmbH" im Namen haben, d.h. ueber Hamburg hinaus scheint das Phaenomen nicht so verbreitet zu sein, (Bevor mir das Ausmass des Problems klar wurde, hatte ich eine "Stuber Automobile GmbH" bereits von historic=monument zu shop=car umgetaggt, aber den Rest ueberlasse ich lieber den Hamburgern - wer weiss, vielleicht ist das ja alles ein historisches Gewerbedorf oder sowas...) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wirtschaftsgebäude in Ortslagen
Guten Morgen in die Runde, als ziemlich Neuer bei OSM fand ich bisher keine Hinweise, wie in einem Dorf/Kleinstadt Wirtschaftsgebäude getagged werden könnten. Weglassen würde bedeuten, dass ein Stadtplan reichlich Lücken aufwiese, sprich: Obwohl eigentlich eine geschlossene Gebäudefront da ist, würden mit den Wohngebäuden und Geschäften etwas "fremdes" entstehen. ich habe erstmal diese Wirtschaftsgebäude gezeichnet und bin nun etwas unsicher. Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de