Re: [Talk-de] Wander-Radwege Relationen anpassen - missverstanden ??
Moin, Jan Tappenbeck schrieb am 30.10.2011 19:08: das ist ja eigentlich wieder so ein klassischer Fall des Satzen wir mappen nicht für den Renderer - hier würde es heißen wir mappen nicht für die Applikation. Das darf natuerlich nicht sein. Da ist es doch viel besser, wenn wir gezielt GEGEN die Applikation mappen. Ein Wanderer würde auch sich bei einer Papierkarte besser aufgehoben fühlen, wenn der richtige Weg (bei ihm der Fussweg) in der Karte auch markiert wird. Wir mappen ja nicht fuer Renderer... :-) Mal abgesehen davon ist deine Sichtweise allenfalls sehr begrenzt zutreffen: Man mag die anzeige von Routenrelation auf den Sonderwegen vielleicht schoener finden, wenn man bis zum Anschlag in die Karte rein zoomt (auch das stimmt schon nicht mehr, wenn die Sonderwege auf beiden Seiten der Fahrbahn in die selbe Relation muessten), aber spaetestens wenn man etwas weiter raus zoomt, kehrt sich die Sache um. Prinzipbedingt blendet naemlich eine Karte frueher oder spaeter die separat erfassten Sonderwege aus, da ihre Anzeige mit denen der Strasse kollidiert. Auf solch einer Zoomstufe will man aber trotzdem noch den Verlauf der Relation erkennen koennen. Und wenn der dann schief zur Strasse liegt, sieht das nicht gerade gut aus. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander-Radwege Relationen anpassen - missverstanden ??
Jan Tappenbeck schrieb am 30.10.2011 08:10: Mir geht es um die Relation (z.b. Jakobsweg) - diese würden vom Routing auf dem Sonderweg besser aufgehoben sein als auf der Hauptstraße ! Jan, du hast doch ein Garmin Navi und baust dir dafuer doch eigene Karten. Probiere doch einfach mal aus, was fuer ein Routing dabei raus kommt, wenn dich das Navi gezielt diese strassenbegleitenden Wege lang schicken soll. Wenn du dabei was brauchbares hinbekommen hast, dann koennen wir die Diskussion hier ja noch mal wieder neu anfangen. Bis dahin gilt weiterhin mein Rat: Verschiebe nicht von anderen angelegte Relationen auf diese strassenbegleitenden Sonderwege. Da man dabei einige Anwendungen kaputt macht, koennte es sein, dass andere darueber nicht gleucklich sind. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander-Radwege Relationen anpassen - missverstanden ??
Claudius schrieb am 30.10.2011 12:42: Frage 1: Welche Anwendungen sind das? Z.B. ein Routing, das bevorzugt Weg-Relationen folgen will. Frage 2: Wenn die Anwendungen nicht mit richtig erfassten Daten (Ich kenne auch Abschnitte das Jakobsweges die vor Ort explizit auf dem Fußweg beschildert sind) zurechtkommen, dann sollte die Anwendung fehlerbereinigt werden. Wie so oft bei OSM ist dies mal wieder ein Fall, wo es kein richtig und kein falsch beim Erfassen der Daten gibt. Es gibt nun mal bestimmte Vorlieben der Mapper fuer die eine oder andere Variante. Deshalb ja auch mein Aufruf, bestehendes Mapping in so einem Streitfall nicht zu veraendern. Und zu sagen dann soll halt die Anwendung bereinigt werden ist ziemlich blauaeugig, denn wenn man beim Erfassen ein unbrauchbares Mappingschema gewaehlt hat, dann kann da auch eine noch so gute Anwendung nichts mehr retten. Aber bei OSM haben wir ja auch eine Vorliebe dafuer, den automatischen Datenauswertungen das Leben unnoetig schwer zu machen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander-Radwege Relationen anpassen
Jan Tappenbeck schrieb am 29.10.2011 18:46: es werden gerade vermehrt Rad- und Fusswege erfaßt. Ich möchte in diesem Zusammenhang nur noch einmal daran erinnern dort verlaufende Relationen entsprechend nachzuführen. Mir sind einige dadurch entstandene Fehler aufgefallen. Zudem verlaufen diese Relationen jetzt auf den Straßen obwohl jetzt die Wege vorhanden sind. Mal abgesehen davon, dass ich das separate Erfassen von Rad- und Fusswegen als Bloedsinn ansehe, ist es auch extrem ungluecklich, wenn man die Wegrelationen auf diese Sonderwege verschiebt. Dann erhaelt man nur noch als Wegbeschreibungen: fahre von Radweg auf Radweg nach Radweg. Damit kann dann keiner mehr was anfangen. Ich weiss, das bei diesem Thema die Meinungen auseinandergehen. Deshalb sollte man tunlichst die Relationen da lassen, wo sie sich z.Z. befinden. Die Chance ist gross, dass man sonst einen anderen Mapper ziemlich veraergert. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rundwanderweg wird aufgegeben - disused relation?
Bernhard Weiskopf schrieb am 24.09.2011 02:10: Wie entmarkiere ich die Relation (route = foot) zum Rundwanderweg 9? Gibt es auch bei den Relations disused = yes oder ähnlich? Das ist viel zu fehleranfaellig: Jede Auswertung, die das Tag nicht kennt, wuerde dann die Route faelschlicher Weise weiterhin anzeigen. Besser setze route=disused (+ eine Note), dann weiss jeder Mapper, was da los, und aus den Karten verschwindet die Route ganz automatisch. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauen einer Karte...
Moin, Lars Schimmer schrieb am 07.09.2011 15:49: 3. mit mkgmap.jar jeweils ein gmapsupp für die Tiles und eine für SRTM erzeugen. Dabei wirft es aber bei den 25 Computerteddy Tiles manchmal einen Error (wenn man einfach tiles_6* schreibt, schreibt man die 25 einzelnen tiles hin, gibt es keinen Error. War von wegen: SRT Datei konnte nicht geschrieben werden, schon voirhanden) 4. mit lgmt042a.zip beide gmapsupp.img zu einem zusammenfügen das wirft dabei folgende Warnings mehrmals: == Warning: repeated map ID number. Es spricht m.E. nichts dagegen, gleich mit mkgmapn eine gemeinsame gmapsupp.img Datei aus den OSM und SRTM Daten zu erzeugen. Das kann man in einem Schritt machen, mkgmap kann aber auch nachtraeglich img-Dateien zu einer gmapsupp.img zusammenpacken. Die meisten, die ich gelesen habe, schneiden einen Bereich aus der ganzen Karte aus und holen die Daten dann rüber in eine Datei, splitten die dann auf und werkeln auf den dann weiter. Das Routing von einer Kartenkachel zur naechsten ist nicht ganz unproblematisch. Frueher ging das mit den Kacheln von Comupterteddy gar nicht, ob sich das inzwischen geaendert hat, weiss ich nicht. Wenn man sich die Kacheln selber schneidet, hat man auf alle Faelle den Vorteil, dass man die Kacheln guenstiger geschnitten sind, so dass man mit weniger Kacheln auskommt und deshalb auch nur ueber weniger Kachelgrenzen routen muss. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geänderte Wegführung bei Radrouten
Andreas Tille schrieb am 10.07.2011 09:30: Was ist nun also sinnvollerweise zu tun, wenn es in der Natur zwei verschiedene Ausschilderungen ein und derselben Route gibt? Solange beide ausgeschildert sind, wuerde ich auch beide in OSM erfassen, jede Route als eigene Relation. Da muss dann mindestens ein note-Tag dran, das diese besonderheit erklaert. Ob ich den Namen der Routen auch anpassen wuerde (XYZ - alte Variante) weiss ich nicht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zum landuse
Jan Tappenbeck schrieb am 19.06.2011 18:26: Nun habe ich einmal einige Bilder gemacht und hätte gerne gewußt wie Ihr diese taggen würdet? http://www.tappenbeck.net/forum/osm/osm_grass_an_moor = in der Mitte ist eine moorige Fläche - die Randfläche würdet Ihr wie taggen ?? http://www.tappenbeck.net/forum/osm/osm_bab_damm.jpg = wie wäre diese Fläche, die weder beweidet noch gemäht wird zu taggen ?? http://www.tappenbeck.net/forum/osm/osm_brache_bab.jpg = hier ein Detail zu dem vorangegangenen Bild ! Ich wuerde das alles als landuse=meadow eintragen. Bei der Flaeche neben der Autobahn wuerde ich uebrigens nicht darauf wetten, dass die nicht ab und an mal gemaeht wird. Zumindest Straeucher oder Baeume duerften da ab und an entfernt werden, da man i.A. keinen Wald bis an die Autobahn heran wachsen laesst. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grüne beschilderte Radwege erfassen
Claudius schrieb am 16.06.2011 15:03: Hat sich schon jemand mit der Erfassung ausgeschilderter (Bsp. siehe [1] und [2]) lokaler Radwege beschäftigt? Ich kenne nur die Relationen [3] von denen network=lcn wohl am besten geeignet wäre. Aber da diese Radrouten ja oft keinen Anfangs- und Endpunkt haben ist das eher schwierig. Ich könnte alle dieser Radwege im Stadtgebiet in eine lcn-Routenrelation aufnehmen, aber das wäre dann auch sinnfrei. Wie geht ihr damit um? Moin, ich gehe entsprechend http://wiki.openstreetmap.org/wiki/Radwegenetze vor. Da hat sich aber noch kein einheitliches Verfahren durchgesetzt, am Fuss der Seite findest du auch links zu anderen Methoden. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternativen und Linienbegleitend
M∡rtin Koppenhoefer schrieb am 14.06.2011 15:21: Dein hedge_bank hat allerdings trotzdem seine Berechtigung, weil es - wie ich das feature in Wikipedia verstanden habe - ja ein Wall und Bäume darauf sind. Wenn es nur lineares Gestrüpp/Bäume sind (also ohne Wall), dann kann/sollte man hedge benutzen. Laut Wikipedia sind Knicks von Gehölzen bewachsene breite Geländestreifen, HAEUFIG künstlich errichtete Erd-, Stein- oder Torfwälle. Es muss also nicht zwingend ein Wall da sein. Das findet sich auch in der Praxis so wieder, ich kenne auch durchaus solche Strauchhecken die nicht auf einem Wall sondern an einem Graben entlang stehen. Fuer mich macht deshalb eine Unterscheidung zwischen hedge und hedge_bank keinen Sinn, dass ist genauso muessig wie die Diskussionen ueber path und footway. In der von Dir erstellten Wikiseite steht am Ende, dass das flächenhafte Erfassen keinen Sinn mache. Dem kann ich nicht beipflichten. Oder sind die Knicke immer gleich breit? Flächenhaftes Erfassen hat mehrere Vorteile, z.B. kann man damit Objekte im Knick erfassen, was bei einer Linie nur bedingt geht (und weniger Aussage haben wird, weil unklar bleibt, wo genau sich das Objekt befindet). Natuerlich sind Knicks nicht immer gleich breit, aber typischer Weise ist ihre Breite in Relation zu den Gesamtabmessungen zu vernachlaessigen. Wenn so eine gestruep breiter wird, dann wird man das wohl eher als natural=scrub erfassen (aehnlich duerfte aus barrier=wall ab bestimmten Abmessungen ien building=yes werden). Erschwerend kommt noch hinzu, dass man bei einem Knick (oder auch einer Baumreihe) die Breite nur schwer definieren kann, in welcher Hoehe will man denn messen? Die Straeucher eines Knicks werden ausserdem ueblicherweise alle paar Jahre mal komplett zurueckgeschnitten (siehe Bild auf Wikipedia), da bleibt dann wirklich nicht mehr viel an Breite ueber. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Garry schrieb am 07.06.2011 15:46: Warum soll dort nicht funktionieren was bei highway funktioniert? In erster Linie, weil es beim highway mit dem tracktype auch nicht wirklich funktioniert, was ja auch regelmaessig wieder Thema in den Diskussionen ist. OK, die Bereitschaft das zu mappen wird geringer sein.. Das kommt erschwerend hinzu. Selbst hier in Deutschland sind auf dem platten Land genug Waldstuecke noch ueberhaupt nicht (woraus man natuerlich schliessen kann, dass da auch keiner lang kommt, den eine genauere Unterteilung interessieren koennte). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Garry schrieb am 07.06.2011 16:03: Wer die Strasse bearbeiten möchte soll die Strasse bearbeiten können und wer die Waldgrenze bearbeiten möchte eben die Waldgrenze. Noch mal zur Erinnerung: Wir reden hier von dem Fall, wo ein Wald bis an eine Strasse heran reicht. = Waldgrenze = Strasse Es macht also keinerlei Sinn, ein Objekt genauer und ein Objekt weniger genau in der Datenbank haben zu wollen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichflächen
Jan Tappenbeck schrieb am 06.06.2011 12:28: landuse = meadow scheidet wohl wegen fehlender Nutztierhaltung - selten und wenn vorübergehend nur Schafe ! Da sehe ich nun wirklich keinen Widerspruch. Hier in meiner Region sind die Deich meist als Linie mit embankment=yes erfasst und die entsprechenden Flaechen als landuse=meadow. man_made=dyke waere sicherlich auch ok, ist hier aber halt nicht ueblich. Haeufig genug gibt es auch Wege auf der Deichkrone, so dass die Kombination von highway=* und embankment=yes naeherliegend erscheint. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Jan Tappenbeck schrieb am 06.06.2011 12:52: kann mir einer sagen wie man so ein Zwischending zwischen landuse=forest und natural=scrub taggen würde?? Da der Uebergang zwischen forest und scrub ja sowieso fliessend ist und jeder Mapper die Grenze irgendwo anders sieht, wird die Sache wohl kaum uebersichtlicher werden, wenn man da noch eine Zwischenkategorie einfuehren wuerde. Beim Wald hat man ja sowieso das Problem, dass innerhalb der Waldflaeche die unterschiedlichsten Wuchshoehen vorherrschen koennen. Da koennen in einer Ecke 25m hohe Fichten dicht an dicht stehen, und direkt daneben sind dann nur drei verienzelte Baeume und dazwischen waechst das Unterholz nach. Das eien ist genauso landuse=forest wie das andere. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
M∡rtin Koppenhoefer schrieb am 06.06.2011 17:42: Du müsstest irgendwie das Alter (Pflanzdatum, auch ungefähr) der Bäume unterbringen (bzw. die durchschnittliche Wuchshöhe - nicht gerade ein dauerhaftes Attribut allerdings). Naja, wenn man keinen Zaubertrank hat, wachsen Baeume nicht so schnell. Problematisch sehe ich eher, dass man das nur sehr schwer abschaetzen kann und dass das abhaengig von Baumart, Dichte des Bewuchses, Dichte des Unterholzes und was weiss ich nicht noch alles, auch nicht wirklich aussagekraeftig ist. Mit objektiven Kriterien wird man das also kaum brauchbar erfassen und auswerten koennen. Bliebe noch eine abstrakte Einschaetzung wie forest_type=gradeX, aber auch da wuerde ich keine wirklich brauchbaren Daten erwarten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Frederik Ramm schrieb am 31.05.2011 15:53: Aber ein OSM-Way ist nicht die Wegmitte, sondern eine Naeherungsdarstellung fuer die gesamte Strasse. Frag jemanden, bis wohin der Wald geht, und derjenige sagt bis zur Landstrasse. Dann *ist* die Landstrasse die Flaechenbegrenzung, und es ist voellig in Ordnung, die Landstrasse zur Flaechenbegrenzung zu nehmen. Dass daraus dann etwas Falsches wird, wenn jemand den Way, der die Landstrasse repraesentiert, als die Mitte der Landstrasse interpretiert, das ist dessen Problem. Sehe ich genauso. Nach meiner Meinung gehoert also nur ein Abstand zwischen die (als Linie erfasste) Strasse und eine Flaeche, wenn zwischen der Strasse und dieser Flaeche noch ein anderes Objekt liegt, dass man spaeter zu erfassen gedenkt. Bei einem Wald den Rand mit einer Genauigkeit einer Fahrbahnbreite den Rand festlegen zu wollen, ist sowieso muessig. Verlaeuft entlang der aeussersten Borke eines Stammes der Waldrand? Ober ist der am weitesten hinausragende Zweig der Rand des Waldes? Oder eine offizielle Flurstueckgrenze? Oder... Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
M∡rtin Koppenhoefer schrieb am 31.05.2011 16:36: Praktisch jede Straße hat einen Graben, vor allem, wenn durch einen Wald führt. Dir ist schon klar, dass deine Formulierung impliziert, dass der Graben Teil der Strasse ist? Wenn man schon keine Lust hat, den Waldrand zu bestimmen, kann man genausogut (oder besser m.E.) einfach die Straße _durch_ den Wald führen, also den Wald dort überhaupt nicht teilen und dadurch den Generalisierungsgrad bereits angeben. Kann man auch. Haeufig bietet sich die Teilung des Waldes entlang von Strassen nur aus rein pragmatsichen Gruenden an. Interessanter sind sicherlich Faelle, wo nur auf beiden Seiten der Strasse unterschiedliche Objekte angrenzen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
M∡rtin Koppenhoefer schrieb am 31.05.2011 18:20: ja, und wenn da nun auf der einen Seite ein Wald und auf der anderen ein Feld angeschlossen wird, dann grenzen die beiden in OSM direkt aneinander (gemeinsame Nodes), während Du in der Realität eine Straße _dazwischen_ hast. Klar, solche Fehler kann man auch durch Analyse beseitigen. Guter Punkt. Wenn man die Flaechen bis zur (linienfoermigen) Strasse eintraegt, dann kann man in der Auswertung erkennen, dass Strasse und Flaeche gemeinsame Knotenpunkte haben und daraus kann man die Topologie konstruieren. Wenn man dagegen die Flaeche in einem Abstand von der Strassenlinie enden laesst, ist man in der Auswertung ziemlich aufgeschmissen. Nachteil von diesem Argument ist leider, dass die logische Schlussfolgerung daraus ist, Flaechen grundsaetzlich als Multipolygon einzutragen, damit man die einzelnen Grenzlinien gleich fertig geliefert bekommt. Das kann man allerdings dadurch entkraeften, dass man so eine Wer-grenzt-an-wen-Analyse normalerweise nicht braucht, die reinen Flaechenauswertungen mit diesem Ansatz aber erheblich aufwendiger macht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Peter Wendorff schrieb am 28.05.2011 09:50: Es ist nur ein Hilfsmittel, das stimmt, aber solange die Renderer auf strikten Regeln arbeiten müssen, wird es Leute geben, die den Weg zu Oma auf der Deutschlandkarte sehen müssen, und deshalb jede noch so kleine Straße auf dem Weg als besonders wichtig einstufen. So ganz hast du die Idee des Vorschlags noch nicht verstanden. Mit den vorgeschlagenen Hilfstags kann man keine Anzeige beim Renderer erzwingen, ein Element kann dadurch nicht wichtiger werden, als es jetzt schon ist. In der umgekehrten Richtung gibt es dem Mapper allerdings die Moeglichkeit, Elemente fuer hohe oder niedrige Detail-Auswertungen als nachrangig zu kennzeichnen, da sie auf diesem Detaillevel durch ein anderes Element hinreichend repraesentiert werden. Klar - man kann die Regeln des Renderers anpassen und das da eben nicht mehr machen; aber für JEDE Berücksichtigung solcher Tags wird es früher oder später jemanden geben, der sie ausnutzt, um die Standardkarte den eigenen Wünschen entsprechend umzugestalten, und eben nicht selbst zu rendern. Die Missbrauchsmoeglichkeiten sind da sehr beschraenkt: 1. Ein Mapper kennzeichnet etwas als main, was von anderen eher als minor gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen nicht ausgeblendet - Die Karte sieht genauso aus wie heute ohne solche Zusatztags. Die Lage hat sich also durch den Missbrauch nicht verschlechtert. 2. Ein Mapper kennzeichnet was als minor, was von anderen eher als main gekennzeichnet werden wuerde - Das Element wird bei niedrigen Zoom-Stufen eventuell von einigen Renderen nicht mehr angezeigt (bei vielen Typen wuerde ein minor heute keinen Sinn machen und von einem Renderer deshalb auch nicht beruecksichtigt werden.) - Ein andere Mapper wird das Element auf der Karte vermissen und das Tagging entsprechen korregieren. Das ist genauso, wie Mapper auch heute bei den Strassenkategorien unterschiedlicher Meinung sein koennen, davon geht die OSM-Karte nicht unter. Auf die Kennzeichnung abstract gehe ich hier nicht weiter ein, da es bislang keine derartigen Elemente gibt, das waere also eher was fuer die Zukunft, wenn sich entsprechender Bedarf ergibt. Hier zeigt sich eben auch (mal wieder), dass das Konzept von der OSM-Standardkarte als in erster Linie Proof-of-Konzept und Mapper-Hilfe nicht ganz wasserdicht ist: Die hier sinnvolle Demonstration zusätzlicher Möglichkeiten widerspricht eigentlich dem Ansatz, Hilfe für Mapper und Einstiegspunkt für das Finden vieler Fehler zu sein, wäre aber ein Glanzpunkt, was die Konzept-Implementierung angeht. Dem will ich nicht widersprechen, vorallem deshalb, weil ich nicht verstanden habe, was du damit sagen willst ;-) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Peter Wendorff schrieb am 28.05.2011 19:17: Aber wenn ich nicht wichtiger taggen kann, dann tagge ich eben alle konkurrierenden Objekte als minder wichtig, um mein Ziel zu erreichen. Das klappt deshalb nicht, weil ein Renderer ja gar nicht pauschal alles mit minor markiertes unterdruecken wuerde, es kommt dabei ja immer noch zusaetzlich auf den Typ des Objektes an. Ausserdem wuerde damit ein Objekt ja auch nicht komplett aus der gerenderten Karte verschwinden, sondern nur auf Zoom-Stufen, wo es in der Anzeige sowieso mit einem anderen Objekt konkurrieren wuerde, d.h. mit guter Wahrscheinlichkeit sowieso verdeckt waere. Auch jetzt ist es so, dass ein Renderer ab einer bestimmten Zoom-Stufe entscheidet, dass ein Objekt zu Gunsten der Uebersicht nicht mehr angezeigt wird. Durch das Detail-Mapping haben wir nun aber immer haeufiger den Fall, dass der Renderer allein aufgrund des Typs der Objekte nicht ausreichend auswaehlen kann, was er weg lassen sollte (es gibt einfach zu viele gleichrangige Objekte). Ist es da nicht sinnvoller, wem man als Mapper dem Renderer einen Tipp geben kann, was er bei der Anzeige im Zweifelsfall unterdruecken koennte, als dass das zufaellig passiert? Wie? Mapnik zeigt die Nachbarstraße an und nicht die Straße, in der ich wohne? dann tagge ich die Nachbarstraße eben als weniger wichtig. Wenn man ein Objekt (eine Strasse) in der Anzeige bevorzugen moechte, dann hat man auch heute schon die Moeglichkeit, an der Klassifizierung rumzuspielen. Die Mapnik-Karte wird von einigen OSM-Aktivisten (mich eingeschlossen) nicht in erster Linie als gute Karte angesehen. Es geht nicht darum, dass die Standard-Stile auf osm.org die best-aussehenden Karten darstellen; es geht vielmehr darum, sichtbar zu machen, was mit OSM alles möglich ist. Mir geht es ja auch nicht darum, dass unbedingt die Mapnik-Karten besser aussehen soll, das Problem betrifft naemlich auch alle anderen automatisch erzeugten Karten. Wenn jemand also das Ziel hat, eine optisch moeglichst schoene Karte zu erzeugen (im Gegensatz zu deinem Anspruch an die Standardkarte), dann verbauen wir ihm dafuer jegliche Moeglichkeit. Wenn wir den Mappern keine Moeglichkeit geben, in gewissen Grenzen die Kartenansicht mit zu beeinflussen, dann neigen die Mapper dazu, zu diesem Zweck die Daten zu verfaelschen (Mappen fuer den Renderer, haeufigster Fall ist da sicherlich das Layer-Tag bei Flaechen). Das Problem ist bei einem Hilfstag ausgeschlossen, wenn es per Definition fuer die Bedeutung des Elementes irrelevant ist. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Hier hat ja auch keiner verlangt, das Rad zurueck zu drehen. Letztendlich laeuft es aber darauf hinaus, dass wir frueher keine Unterscheidung fuer unterschiedliche Abstarktionsebenen brauchten, unsere Daten waren fuer sowas einfach noch nicht gut genug. Das mit den Daten hat sich inzwischen geaendert, leider ist aber mit der Datengenauigkeit nicht auch die Strukturtiefe mitgewachsen, so dass inzwischen manchmal die Daten um so schlechter nutzbar geworden sind je genauer sie sind. Wie man auch an den anderen z.Z. aktuellen Diskussionen liest, ist das Problem nicht auf die Bahnstrecken beschraenkt und verlangt wohl deshalb auch nach einer grundsaetzlicheren Loesung. Da es sowas bei OSM ja aber prinzipiell nicht gibt, wurschteln wir uns eben weiter mehr schlecht als recht durch. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Heiko Jacobs schrieb am 27.05.2011 19:32: man muss das halt beim Rendern in den Griff kriegen. Such mal im Wiki nach dem Stichwort Linienbündel Auch das erfordert weitere Information, das kann ein Renderer einfach nicht von sich aus leisten. Die schlechten Erfahrungen mit den Multipolygonen lassen mich ausserdem daran zweifeln, dass solche Konstrukte das Richtige fuer die Masse der Gelegenheitsmapper ist. Was haltet ihr von folgendem Schema fuer Hilfstags aehnlich den Tags speziell fuer Osmarender, d.h. sie sollen nicht das Objekt selber beschreiben sondern eine Hilfestuetze zur Auswertung/Darstellung bieten. - detail_level=minor Ein Objekt, dass nur auf den groessten Zoomstufen angezeigt werden sollte. Auf groeberen Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=main oder detail_level=abstract) ausreichend repraesentiert wird. - detail_level=main Ein Objekt, dass auf allen Zoomstufen angezeigt werden sollte. - detail_level=abstract Ein Objekt, dass nur auf den kleinsten Zoomstufen angezeigt werden sollte. Auf genaueren Karten kann es bei Bedarf weggelassen werden, da es durch andere Objekte (mit detail_level=minor) ersetzt wird. Mit diesem Schema koennte man z.B. eine Strasse als main definieren und die separat erfassten Rad- und Fusswege als minor. Jeder Renderer koennte mit diesen Informationen dann ohne grossen Aufwand selbst entscheiden, ab welcher Zommstufe der Begleitweg dargestellt wird, und ab welchen Zoomstufen es sinnvoller ist, nur die eigentliche Strasse darzustellen. Ein Mapper haette mit diesem Schema die Moeglichkeit, Elemente, die ihm persoenlich unnoetig detailliert erscheinen, als untergeordnet zu markieren oder sogar durch abstraktere Elemente zu ersetzen, ohne dass er dafuer die eigentlichen Tags der Elemente in der Datenbank veraendern muesste. Es geht also keine Information verloren, und ein Mapper, der meint in seinem Revier etwas aufraeumen zu muessen, kollidiert nicht mit einem Detail-Mapper. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Stephan Wolff schrieb am 27.05.2011 19:51: Ins Datenmodell von OSM passt es nicht, identische Gleise als physikalische Objekte einmal als master und einmal als slave zu bezeichnen. Die Strecke als Verwaltungsobjekt, das mehrere Gleise zusammenfasst, könnte eher die Zusatzinformation aufnehmen, welche der Mitglieder die Lage der Relation repräsentieren sollen. Dem Datenmodell ist es vollkommen egal, ob die Information als Tag ans Objekt eingetragen wird, oder ob man dafuer eine Relation darueber baut und die Information dann als Rolle der Mitglieder erfasst. Der Informationsgehalt diesbezueglich ist erstmal voellig identisch. Interessant wird die Relation erst, wenn man wissen will, wer genau der Master zu einem bestimmten Slave ist. Bei der von dir vorgeschlagenen, hierachischen Ordnung der eigentlich gleichrangigen Element ist das aber nicht notwendig, da der Master ja auch ohne die Informationen vom Slave funktionieren soll. Wenn man aber meint, dass man diese Information braucht, dann darf jede Relation nur einen einzigen Master haben. = Man braucht unheimlich viele Kleinstrelationen und das ganze System ist praktisch nicht mehr zu warten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Henning Scholland schrieb am 27.05.2011 20:28: Von einer solchen Abstufung halte ich nichts. Schließlich soll der Renderer (und der Programmierer dahinter) entschieden wann er was darstellt. Die Entscheidung liegt ja auch weiterhin bei dem Renderer. Er ist ja nicht gezwungen die Hilfstags auszuwerten, und wenn er es tut, dann kann er das ja auch fuer verschiedene Elemente unterschiedlich handhaben. Eine Karte fuer Radfahrer koennte so z.B. Radwege immer darstellen wollen, eine Karte fuer Autofahrer wuerde sich in diesem Falle anders entscheiden, und bei Gleisen wuerde es beiden reichen, nur eins von mehreren parallel darzustellen. Das Tag ist ja keine verbindliche Vorgabe fuer die Renderer, sondern es ist nur ein Hilfmittel, um den Auswerteprogrammen das Weglassen von Objekten zu erleichtern. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Garry schrieb am 26.05.2011 12:10: Ich verstehe nicht warum bei railway es jetzt plötzlich ein Problem sein soll was bei Autobahnen von Anfang an praktiziert wurde. Zum Teil liegt es gerade eben daran, dass es bei railway nicht von Anfang an so praktiziert wurde. Wenn man zum Vergleich die Karten von vor 1 Jahr hat und dann sieht, dass die heutigen in dieser Beziehung schlechter geworden sind, dann muss doch irgendwas hier nicht ganz richtig laufen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Garry schrieb am 25.05.2011 11:19: Gehst Du blindlings zu einem fremden *) Museum, Restaurant etc. ohne Dich zuvor über die aktuellen Öffnungszeiten zu informieren nur weil Du eine Adresse davon hast? *) bei nennenswerter Anreise zu einer bewusst gewählten Einrichtungen Ja, manchmal: Letzten Samstag stand ich nach fast 2h Anfahrt vor dem leider wegen Renovierung geschlossenem Dom in Hildesheim. Das aber nur am Rande. Viel entscheidender ist ja, dass ein solches Taggingschema ja universell fuer alle Einrichtungen gelten soll. Und wenn ich im Notfall zum naechsten Krankenhaus will, dann moechte ich bestimmt nicht vor Ort feststellen, dass meine Karte/mein Router leider ein kleines constrution=yes/ruins=yes oder vergleichbar sinnwiderlegendes uebersehen/nicht gekannt hat. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
M∡rtin Koppenhoefer schrieb am 25.05.2011 17:06: das behauptest Du so, aber ich finde dafür nirgendwo Anhaltspunkte, ausser in diesem Thread. Dass OSM nicht überall vollständig ist, wissen wir. Aber das jetzt zum Feature umzudeuten halte ich doch für unsinnig. Im Wiki steht für railway=rail jedenfalls nirgendwo, dass das eine abstrakte Strecke sein soll, und nicht ein physisches Gleis. Selbst in den ältesten Versionen der Seiten (die englischen, ob auf deutsch da irgendwo Übersetzungsfehler sein sollten habe ich nicht geprüft). Genauso findet sich auch nirgendwo ein Anhaltspunkt, dass mit dem Tag ein einzelnes Gleis gemeint sien koennte. Und das wird ganz einfach daran liegen, dass damals ueberhaupt niemand auf die Idee gekommen ist, jemand koennte in OSM einzelne Gleise eintragen wollen. Bei highway=* hat man ja auch nicht als erstes hingeschrieben, dass damit nicht einzelne Fahrspuren gemeint sind. Fakt ist und bleibt, dass urspruenglich alle mir bekannten Bahnstrecken als einfache railway=* eingetragen waren (und zwar mittig), und erst letztens hier die Mode aufgekommen ist, fuer dieses Tag eine andere Bedeutung anzunehmen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Stephan Wolff schrieb am 25.05.2011 20:35: Erfassung der Einzelgleise soweit möglich. Erstellen einer Relation für jede zweigleisige Strecke, bei der ein Gleis (z.B. das nördlichere) role=master und das Gegengleis und die Querverbindungen role=slave erhalten. Wesentlich einfacher und praktikabler waere es, wenn man nur die slave-Gleise (oder alternative nur die master-Gleise) mit einem extra Tag kennzeichnen wuerde, die Relation ist eigentlich ueberfluessig. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse (war: See in Wald in (L|N)SG)
Johannes Huesing schrieb am 24.05.2011 06:30: Diesen Weg hat man zu meinem Unmut schon beschritten, als man entschied, dass Feldwege nicht zu einem Feld gehören und die Landnutzung erst 3 Meter links und rechts der Wegmitte beginnt. Hat man das entschieden? Ich habe das nicht entschieden und mappe auch nicht so. In meinem Umland gibt es allerdings verschiedene Mapper, die zwischen verschiednene Flaechenelementen grundsaetzlich einen Streifen frei lassen. Da passt dann nateurlich auch noch ein kleiner Weg dazwischen. Warum diese Mapper das tun, weiss ich nicht. Ich vermute, dass ist den Unzulaenglichkeiten irgendeines Editors oder Validators geschuldet. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Garry schrieb am 24.05.2011 12:53: Die Frage des gleisgetreuen Mappens stellt sich doch ausserdem längst nicht mehr, an vielen Orten ist es längst umgesetzte Realität Genauso wie jemand einfach angefangen hat, von streckenweisen Mappen auf gleisweises Mappen umzustellen, kann jemand anderes von gleisweisen Mappen auch wieder zurueck auf streckenweises Mappen umstellen. Das macht sogar deutlich weniger Arbeit. Aber ich habe hier die Diskussion angestossen, damit man irgendwie beides miteinander vereinbart bekommt. Bislang ist das gleisweise Mappen ja auch noch weit davon entfernt, ueberall verbreitet zu sein. Um so frueher man da also eine brauchbare Loesung findet, um so besser. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Garry schrieb am 24.05.2011 17:09: In die eine Richtung ist es eine Detailverbesserung, in die andere würde sicher nicht nur ich es als Vandalismus ansehen... In beiden Richtungen wird Information zerstoert, die von unterschiedlichen Auswertungen genutzt werden. Letztendlich werden die meisten Kartenansichten durch das detailliertere Mapping schlechter und nicht besser, so dass die Sichtweise des Vandalismus alles andere als eindeutig ist. Worin liegt den nun das eigentliche Problem dass man eine neue Lösung braucht? Wir haben z.Z. erstmal das Dilemma, das ein und das selbe Tag fuer zwei unterschiedliche Bedeutungen benutzt wird: Meistens bezeichnet railway=* eine komplette Bahnstrecke, haeufig ist damit aber auch nur ein einzelnes Gleis gemeint. Eine Bildschirmgrosse Deutschlandkarte mit allen wichtigen Strassen- und Eisenbahnverbindungen wird man nicht lesbar hinbekommen. Nicht erst bei einer Deutschlandkarte, ist man an einzelnen Gleisen eigentlich nicht mehr interessiert, selbst die 1:25000 Messtischblaetter enthalten zwar einzelne Gebauede aber unterscheiden nicht einzelne Gleise an. Das heisst natuerlich nicht, dass man grundsaetzlich auf die einzelnen Gleise verzichten muss/will, aber es zeigt doch recht deutlich, wie haeufig die Information Bahnstrecke die interessantere ist. Natuerlich kann man solche Karten auch mit Gleisen anstelle der Strecken zeichnen, sieht dann aber entsprechend besch... aus. Das ist dann mal wieder ein Fall, wo wir uns bei OSM das Leben kuenstlich schwer machen. Aber hey, die kommerziellen Karten wollen ja auch leben. Dazu kommt dann noch das Problem Linien-Relationen, die sich auch meist nicht sinnvoll auf einzelne Gleise abbilden lassen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reste eines 1919 zerstörten werkseigenen Schießplatzes
M∡rtin Koppenhoefer schrieb am 23.05.2011 12:02: für Ruinen bitte lieber ruins=yes setzen. Bloss nicht. Diese Zusatztags, die die Bedeutung der anderen Tags negieren sind in dieser unspezifierten OSM-Welt die pure Vorlage zur Fehlinterpretation. Keine Auswertung kann wissen, welche Negierungen den Mappern so alle einfallen (ruins=yes, construction=yes, abandoned=yes und was weiss ich nicht noch alles). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Rainer Kluge schrieb am 23.05.2011 10:23: Ich habe weder im Wiki noch in den Archiven eine befriedigende Lösung für das Taggen einer öffentlichen Einrichtung, im konkreten Fall eines Museums, gefunden, welche sich noch im Bau befindet. Ich halte das Erfassen solcher Einrichtungen für sinnvoll, da sich die Bauarbeiten oft über Jahre hinziehen und in dieser Zeit schon etwas zu sehen ist, meist sogar recht spektakuläres. Baugebiete werden mit landuse=construction erfassen. Es ist zwar eher ungewoehnlich aber nicht verboten, dass auch ggf. auf einen Node anzuwenden. Mir geht es darum, dass die Einrichtung gerendert wird, aber bei der POI-Suche oder bei anderen Auswertungen der Daten mit noch nicht in Betrieb, geschlossen oder Eröffnung voraussichtlich Mitte 2012 gekennzeichnet wird. Gibt es dafür eine eingeführte Lösung? Andernfalls würde ich das Gebäude mit name=Museum xxx (Eröffnung Mitte 2012) taggen, ggf zusätzlich name:EN=Museum xxx (opening mid 2012) Die Tags, die die spaetere Funktion beschreiben, sollten auf keinen Fall schon waehrend der Bauphase gesetzt werden, die Gefahr der Fehlinterpretation ist einfach viel zu hoch. Stattdessen kann man das mit construction=* erfassen. Genau dieser Ansatz wird auch bei Strassen usw. praktiziert. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Moin, Bjørn Bäuchle schrieb am 22.05.2011 22:47: ich bin in Frankfurt eifrig dabeigewesen, Eisenbahnen gleisgenau zu mappen. Wenn ich dich richtig verstehe, hast du da auch nichts dagegen, richtig? Prinzipiell nicht, nur die Art des Taggings finde ich suboptimal. Aber dann mach doch einen Vorschlag, wie man sonst die Einzelgleise taggen soll, wenn railway=* für dich nicht akzeptabel ist!? Im Prinzip so, wie von Felix beschrieben, indem man einen Weg fuer die Bahnstrecke als Ganzes in der Datenbank hat, und extra Wege fuer die einzelnen Gleise. Die koenenn von mir aus mit railway_spur oder was auch immer getagged sein. Der Ansatz, dass sowas keine Aufgabe fuer den Mapper sondern fuer den Renderer ist, klingt zwar erstmal sehr schoen, aber ist praktisch ja wohl nicht wirklich durchfuehrbar. Wie soll der Renderer wissen, welche Gleise zu einer gemeinsamen Bahnstrecke gehoerne und welche nicht? Soll er das einfach nur aus den Lageinformationen raten? Abgesehen von dem dafuer noetigen Aufwand wird das in der Praxis bestenfalls sehr bescheidene Ergebnisse liefern koennen. Genauso weltfremd ist die Hoffnung, dass es nur eine Frage der Zeit ist, bis ueberall railway=* ein einzelnes Gleis bezeichnet. Selbst in Deutschland gibt es nicht flaechendeckend Luftbilder in der dafuer notwendigen Qualitaet. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bahnstrecke vs. Gleis
Moin, frueher war es eigentlich ueblich, dass railway=* als way eine komplette Bahnstrecke bezeichnet hat. Letztens scheint aber jemand entschieden zu haben, dass ihm das Tag viel besser auf einzelne Gleise angewand gefaellt. Als Folge davon bekommt man jetzt aber in den groeberen Zoom-Stufen keine ordentliche Kartenansicht der Bahnstrecken mehr hin, da es ausser den Einzelgleisen keinerlei Bahnwerte mehr in der Datenbank gibt. Wie bekommt man das wieder in den Griff? Einfach so die (meist doppelten) nebeneinander liegenden railway=* Wege wieder zusammenfassen will nicht, da sich damit ja jemand ziemliche Arbeit gemacht hat, auch wenn er damit einiges kaputt macht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Heiko Jacobs schrieb am 22.05.2011 17:25: Keine Ahnung, von welcher Ecke der Welt Du redest, aber zumind. in zwei Ecken (Karlsruhe und Bremerhaven) war ich es, der Schienennetze gleistreu (um)mappte nach Bing im Bhv und lokalem Luftbild in KA. Bei letzterem konnte ich mich gerade noch vom schienen- und schwellentreuen Mappen zurückhalten ;-) Ich bin aber nicht der einzige gleistreue Mapper in deutshcen Landen, der Trend wird unaufhaltbar sein Ich habe ja auch nichts gegen die Detail-Erfassung, aber warum konnte dafuer nicht ein neues Tag genommen werden? Ein Gleis ist nun mal was anderes als eine komplette Bahnstrecke. Beim Detailmapping von Wohngebieten benutzt man ja auch building=* fuer die Gebauede und traegt nicht einfache viele kleine landuse=residential ein. So hat man zum einen das Problem, das railway=* in einigen Gegenden Gleis ind anderen Regionen aber Bahnstrecke bedeutet. Und das andere Problem ist, dass man an den Einzelgleisen nur in einigen Zoom-Stufen interessiert ist, in anderen Zoom-Stufen die kompletten Bahnstrecken die brauchbare Information sind. Geradezu klassisch ist dieser Streit bzgl. des Themas, ob man (Fuß- und) Radwege als von der Hauptfahrbahn unabhängiges Objekt (highway=cycleway bzw. path, was wiederum ein weiteres klassisches Streitthema ist) oder lieber als Zusatzeigenschaft der Gesamtstraße (cycleway=track etc.) Und deshalb muessen die bekannten Fehler/Probleme auch auf andere Themen uebertragen werden? Warum kann man nicht aus einmal gemacht Fehlern lernen? Mit Aufkommen der abmalen Luftbilder werden sicher auch Konflikte aufkommen bzgl. detailliertem Flächenmapping (Vorgarten, Haus, Garagenzufahrt, ...) kontra Wohnviertel via einfachem landuse=residential, wobei man das immerhin einfacher koexistent mappen kann ... Das waere doch zu schoen, wenn das irgendwann mal gelingen wuerde. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reste eines 1919 zerstörten werkseigenen Schießplatzes
Moin, Alexander Matheisen schrieb am 20.05.2011 14:47: Am Freitag, den 20.05.2011, 09:19 +0200 schrieb Albrecht Will: im Zusammenhang mit dem Versailler Vertrag wurde ein Schießplatz der Fa. Krupp Gruson geschleift. Die Werksgebäude wurden danach zivil genutzt. Wie sollte ich die Reste eines früheren Munitionsbunkers und Beobachtungsposten (Meßstände) taggen? Die Bunker würde ich als military=bunker und destroyed=yes taggen. Ich schaetze, Kern der Frage ist, ob auch nicht-militaerische Bunker als military=* einzutragen sind. Ich persoenlich wuerde da keinen Unterschied machen. Bei den Kategorien geht es bei uns ja sowieso ziemlich durcheinander (ob nun man_made oder amenity oder was auch immer ist doch ziemlicher Zufall), so dass man bei einem Bunker nun nicht kleinlicher sein muss als noetig. Dafuer spricht auch, dass in der urspruenglichen Frage die Formuliereung danach zivil ja auch impliziert, dass die vorherige Nutzung nicht zivil gewesen waere. Was man hier noch abwegen sollte, ist der Zustand der Bunker. Da es sich hier ja nur noch um Reste handelt, waere vielleicht historic=ruins das passendere Tag mit ergaenzenden Tags, um die Ruinen naeher zu beschreiben. Denn military=bunker bedeutet ja, dass es auch heute noch ein Bunker ist. Gruss Torsten ___ 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 19.05.2011 17:51: Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. Es hat halt jeder so seine eigene Mapping-Technik, jeder Ansatz hat ja auch seine Vor- und seine Nachteile. Bei den Flussflaechen z.B. gibt es in meiner Region einen Mapper, der an den Trennstellen die beiden Teile immer ein wenig ueberlappen lasst. Das sorgt dann dafuer, dass Renderer an der Schnittstelle keinen sichtbaren Streifen erzeugt, aber ueberlappende Fluss-Abschnitte ist datentechnisch natuerlich totaler Bloedsinn. Gruss Torsten ___ 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
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Steffen Grunewald schrieb am 17.05.2011 11:00: Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... Was tun? Bei den Lienewitzseen ist es schon in Ordnung so, dass das Naturschutzgebiet und die Seen nicht gemeinsam in einem Multipolygon stecken, denn schliesslich gelten auf der Ueberschneidungsflaeche ja beide Eigenschaften. Das scheint also ein Problem der Kartendarstellung zu sein. 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). Das sollte aber eigentlich nichts mit der Darstellung der Seen auf der Garmin-Karte zu tun haben, auf meiner selbstgebauten Garmin-Karte sind sie naemlich zu sehen (im Gegensatz zur Bahnflaeche oder dem Gewerbegebiet, die vom Wald ueberdeckt werden). Gruss Torsten ___ 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)
Falk Zscheile schrieb am 17.05.2011 14:30: Das ist aber eine Karte und da darf man wegen Urheberrecht etc. nicht einfach abzeichnen. Wenn ich mich recht an die Lizenzdiskussionen letzten erinnere, dann sollte gegen ein Nachemfinden der eingetragenen Gebiete eigentlich nichts sprechen, da sich das Urheberrecht eher auf die Darstellung der Karte bezieht als auf die enthaltenen Informationen. Ob dem so ist, kann ich als nicht-Jurist natuerlich nicht garantieren. (Ein Jurist wird das wahrscheinlich noch weniger garantieren koennen:-) Wenn man aber die Karte als Vorlage nimmt und daraufhin dann freihaendig die Umrisse des Naturschutzgebietes bei OSM eintraegt, so wird einem keiner einen Strick daraus drehen koennen, da man ja nicht mehr wird erkennen koennen, was einem als Vorlage gedient hatte. Ein Tag note=estimated oder so waere dann aber wohl angebracht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dorf - Landuse reidental oder Bauernhof
M∡rtin Koppenhoefer schrieb am 16.05.2011 13:06: Alternativ könnte man auch beides taggen (z.B. mit einer Multipolygon-relation), das finde ich aber redundant. Wenn du BEIDES taggen willst, dann brauchst du ganz bestimmt keine multipolygon-Relation. Denn die ist naemlich gerade dafuer da, um Loecher in Flaechen zu schneiden, also um anzugeben, dass die Eigenschaft der aeusseren Flache NICHT im Innern gilt. Ansonsten soll landuse ja die VORANGIGE Nutzung angeben, da zwei Werte gleichzeitig angeben zu wollen, ist ziemlich widersinnig = Der Mapper sollte sich halt entscheiden, was ihm da wichtiger scheint. Wirklich falsch ist keines der beiden Tags. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dorf - Landuse reidental oder Bauernhof
M∡rtin Koppenhoefer schrieb am 16.05.2011 13:58: Danke für den Hinweis, aber die Multipolygon relation ist schon lange nicht mehr nur dazu da, Löcher irgendwo reinzuschneiden. ... z.B. Bild 4. Es reicht ein einzelner geschlossener outer way aus, um ein gültiges Multipolygon zu definieren. Mit multipolygon-Relationen kann man jede Menge Bloedsinn treiben, der theoretisch korrekt ist. Das hat dann aber nichts mehr mit den zu erfassendne Daten zu tun, sondern dient ausschliesslich dem Spieltrieb des Mappers. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dorf - Landuse reidental oder Bauernhof
M∡rtin Koppenhoefer schrieb am 16.05.2011 16:34: Wieso meinst Du, wurde die Spezifikation der Multipolygone erweitert? Offensichtlich kennst du ja hinreichend Gegenbeispiele gegen diese Erweiterung, so dass wir das hier nicht zum x-ten Mal durchkauen muessen. Im konkreten Fall hatte ich ja geschrieben, dass ich nur landuse=farmyard verwenden würde, und keine weiteren landuses überlappen würde. Und ich habe nur darauf hingewiesen, dass multipolygon-Relationen auch keine Ueberlappung definieren sondern deren Gegenteil. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Frederik Ramm schrieb am 18.04.2011 22:19: Irgendwann habe ich ihm mal eine recht freundliche Mail geschrieben, so nach dem Motto, ich wuerde manchmal auch an seinen Sachen was aendern, und ich wollte ihn ja zu nichts draengen, aber ob er von diesem Lizenzwechsel gehoert hat, und ob er mir vielleicht sagen koennte, wie seine Haltung dazu ist (denn wenn ich weiss, dass er nicht mitmacht, waere es z.B. bloed von mir, einen von ihm gezeichneten Strassenlauf zu verfeinern). Es kam keine Antwort. Nicht weiter schlimm, dachte ich. Allerdings war er nun gleich einer der ersten auf der Ablehner-Seite, und da war ich ehrlich gesagt schon ein bisschen angepisst. Eine sehr aehnliche Beschreibung koennte auch auf mich zutreffen (ich denke aber, ich bin nicht der von dir angeschriebene). Auf die bei mir eingegangene, entsprechende Mail habe ich nicht geantwortet, weil sie keinerlei konkreten Bezug hatte und so aussah, als ob sie an alle Mapper geschickt worden ist, die der neuen Lizenz noch nicht zugestimmt hatten. = Sie hat es nicht ueber meinen persoenlichen Spam-Filter geschafft. In dem von dir geschilderten Fall kann es also gut sein, dass du nicht der einzige warst, der den Mapper angeschrieben hat, und aufgrund einer solchen Vorgeschichte deine Mail dann unbeantwortet blieb, ohne dass der Betreffende was gegen dich oder dein Anliegen hatte. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Kai Krueger schrieb am 18.04.2011 18:52: Wie man mit Daten von Nein-sagern umgeht ist eine schwierige und umstrittene Sache. Wie sieht die Lage eigentlich bei den GPS-Tracks von Leuten aus, die den neuen Bedingungen nicht zustimmen? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel Phase 3 beginnt am Sonntag
Frederik Ramm schrieb am 14.04.2011 14:44: Wer sich fuer Details zum Lizenzwechsel interessiert, der kann neben den Informationen im Wiki auch meinen Vortrag von letzter Woche auf der FOSSGIS-Konferenz anschauen: Folien... http://www.geofabrik.de/media/2011-04-06-fossgis-lizenzwechsel.pdf Film... http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2011/FOSSGIS2011-323-de-osm_lizenz.mp4 Nebenbei bemerkt: Der Vortrag (genauer gesagt die Folien) hat mir sehr gut gefallen, denn obwohl die Grundaussage Pro-Lizenzwechsel ist, werden auch alle Gegenargumente (zumindest was mich betrifft) aufgefuehrt. Sowas sieht man fuer meinen Geschmack heutzutage viel zu selten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Sporthallen
M∡rtin Koppenhoefer schrieb am 11.04.2011 16:30: unter sports_centre verstehe ich bisher eine größere Sportanlage (einschl. der Gebäude und Plätze), Ab wann ist es eine groessere Anlage? Ab zwei Sporthallen? Ab einer Sporthalle mit angrenzendem Gymnastikraum? Eine Sporthalle mit zwei getrennten Spielfeldern? Vom Tagging her zwischen einer einfachen und einer groesseren Sportanlage unterscheiden zu wollen, schient mir nicht sonderlich sinnvoll. Frueher gab es uebrigens Leute, die unter leisure=sports_centre ausschliesslich ein Fittnesstudio verstanden haben, also ganz was anderes als deine Interpretation. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit germany.osm.pbf?
Moin, Frederik Ramm schrieb am 24.03.2011 01:44: Es gibt einen Trick, wie man den Redirect umgehen kann, und zwar, indem man -noredirect an den Dateinamen hinten dran haengt. BITTE das aber nur im Ausnahmefall benutzen und nicht einfach mal blind in jedes Skript reinhauen, sonst kann ich mir den Redirect komplett sparen ;) Der Server ist bei einem Hoster mit 6 TB Inklusivvolumen im Monat, und nur durch den Redirect zu gwdg.de kann ich das ueberhaupt einhalten - sonst wuerde das richtig teuer. Mir ging es im Wesentlichen darum, Bescheid zu sagen, dass da was nicht ordentlich laeuft. Und das hat ja offensichtlich auch funktioniert, vielen Dank dafuer! Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit germany.osm.pbf?
Moin, ich lade mir gerade die Version von heute runter, und mein Firefox sagt mir, dass da nur 391MB unterwegs sind. Laut Geofabrik-Homepage muessten das aber 843MB sein. Irgendwas scheint da kaputt zu sein. Gruss Torsten Torsten Leistikow schrieb am 22.03.2011 21:59: Moin, beim Bauen eine Garmin-Karte mit mkgmap sind bei mir heute aus der germany.osm.pbf nur POIs herausgekommen, die Ways fehlten alle. Mit der germany.osm.bz2 von heute war alles in Ordnung. Hat jemand aehnliche Probleme? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Problem mit germany.osm.pbf?
Moin, beim Bauen eine Garmin-Karte mit mkgmap sind bei mir heute aus der germany.osm.pbf nur POIs herausgekommen, die Ways fehlten alle. Mit der germany.osm.bz2 von heute war alles in Ordnung. Hat jemand aehnliche Probleme? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karten fuer Japan
Moin, Frederik Ramm schrieb am 12.03.2011 15:25: ich koennte mal ein bisschen Hilfe von den Garmin-Experten hier brauchen. Ich bin gebeten worden, stuendlich aktualisierte Garminkarten fuer Japan bereitzustellen und habe das so halbwegs auf labs.geofabrik.de/japan zum Laufen gekriegt. Die Garmin-Sachen erstelle ich derzeit so: Waere es nicht einfacher/besser, wenn du stuendlich eine frische Version eine etablierten Garmin-Karte von Japan bauen wuerdest? Z.B. die AIO-Karte oder so? Denn neben den Parametern kommt es ja auch durchaus noch auf die style-Dateien an, der Default ist zwar nicht schlecht aber sicher auch nicht das Optimum. Das template.args ist das, was aus dem Splitter rausfaellt. Wenn du immer das selbe Gebiet baust, dann benutze am Besten das template.args vom ersten Lauf auch gleich als Eingabe-Parameter fuer alle neuen splitter Aufrufe. Dann benutzt splitter immer die selben Schnittkannten und man spart sich den Arbeitsgang des Bestimmens der Kannten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeichen 250, Privatweg, Anlieger frei
Rolf Bode-Meyer schrieb am 07.03.2011 16:16: Also einfach das strikteste der aufgeführen Beschränkungen setzen und dabei ignorieren dass 250 nur Fahrzeuge betrifft? Da steht aber kein echtes Zeichen 250 sondern eins, dass von Anwohnern selbst aufgestellt und modifiziert worden ist. Ich denke schon, dass die Interpretation access=privat fuer diesen Fall passt. Denn letztendlich haben die Anwohner das Schild aufgestellt, um auszudruecken, dass sie a) dort Hausrecht haben und b) man da nicht lang soll. Ich glaube nicht, dass sie dabei grossartige Ueberlegungen angestellt haben, dass Zeichen 250 eigentlich nur fuer Fahrzeuge gilt. Und ich denke auch nicht, dass man aus der nicht STVO-konformen Beschilderung ein Nutzungsrecht fuer Fussgaenger ableiten kann. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeichen 250, Privatweg, Anlieger frei
M∡rtin Koppenhoefer schrieb am 07.03.2011 19:50: ich wäre mir nicht so sicher, dass man selbst an einer Privatstraße einfach mal so Verkehrsschilder aufstellen darf, ohne sich mit den Behörden dazu abzustimmen. Das kann man wohl so pauschal auch nicht sagen (mal ganz abgesehen davon, dass es sich hierbei ja auch um kein echtes sondern um ein abgewandeltes Verkehrsschild handelt). Tatsache ist aber, dass das Schild da steht. Ob zu Recht oder nicht, koennen wir nicht wissen und brauchen wir auch nicht entscheiden. Darum ging es mir auch nicht, es ging darum, dass Fußgängerverkehr u.U. vom Besitzer geduldet werden muss, auch wenn ihm die Straße gehört. Es kann natuerlich sein, dass der Besitzer theoretisch Fussgaengerverkehr dulden muesste. Aber m.E. soll das Schild ausdruecken, dass er z.Z. keinen Fussgaengerverkehr duldet. Bei einem Gebaeude tragen wir ja auch nicht ein, ob das rechtmaessig erbaut worden ist, sondern wir tragen ein, dass es da ist. Also ist die Frage hier auch nicht, ob der Eigentuemer das Schild zu Rech aufgestellt hat, sondern was das Schild bedeutet. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktion 14 ( Aquitaine) und Autoroute de Gasgogne
hike39 schrieb am 19.02.2011 10:31: Dort gibt es eine neue Autoroute, die noch in keinen Luftbildern auftaucht. Da ich deswegen bei Kreuzungen dieser mit untergeordneten Strassen nicht erkennen konnte, ob diese als Bruecken oder Untertunnelungen realisiert worden sind, habe ich einfach verbindende Knoten eingebracht. Nun habe ich folgende eMail von RedFox erhalten: Can you revert your modifications about Autoroute de Gasgogne where you have merged motorway with tertiary. Motorway NEVER cross tertiary or other highway. This can be only bridge or tunnel. Wie soll ich vorgehen? Einfach die Linien sich ueberkreuzen lassen, aber OHNE gemeinsamen Knoten. Dann fehlt zwar die Angabe, ob sie sich per Tunnel oder Bruecke kreuzen und welche Strasse oben oder unten ist, aber immerhin ist der Verlauf der Strassen drin und es ist auch klar, dass sie nicht miteinander verbunden sind. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhe umrechnen
Markus schrieb am 14.02.2011 16:45: In DE bekommt man Höhen meist mit der Angabe müM, NN oder NHN. Wie rechnet man das genau in unser Höhensystem um? Gruss, Markus PS: Welches ist unser Höhensystem? Unsere lat-lon-Daten beruhen ja auf den WGS84 Koordinaten. Die Hoehen auf das entsprechende Ellipsoid zu beziehen, ist wenig sinnvoll, da voellig praxisfern (nirgendwo werden Ellipsoidhoehen benutzt). Neben dem Ellipsoid gibt es verschiedene Geoid-Modelle, die leider normalerweise nicht frei sind (so dass man auch nicht einfach vom Ellipsoid auf ein Geoid umrechnen kann). Die gute Nachricht ist aber, dass die verschiedenen Geoid-Modelle sich nur wenig voneinander unterscheiden, ueblicherweise sind die Unterschiede deutlich geringe als unsere Messgenauigkeit. Insofern kann man sich das umrechnen gleichsparen. Wenn du eine Hoehenangabe in die Datenbank eintraegst, ist es zu 99,9% egal, ob das nun NN oder NHN oder was auch immer ist. So genau kann man das selber sowieso nicht messen, und auch irgendwelche Angaben auf Schildern sind i.A. eher nicht so genau. Wenn du bei einem Hoehenwert ganz sicher bist (ein ordentlich vermessener Punkt), dann trage das zugrundeliegende System einfach als zusaetzliche Information in die Datenbank ein. (Die ueblichen Tags habe ich gerade nicht vorliegen, sollten sich aber im Wiki finden.) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhe umrechnen
Markus schrieb am 14.02.2011 19:46: (nirgendwo werden Ellipsoidhoehen benutzt). Auch nicht SRTM? CIGAR? Auch dort werden die Hoehen ueber dem Geoid angegeben. Die Sache ist ja, dass es nur ein Geoid gibt, die unterschiedlichen Modelle sind halt verschiedene Versuche dieses mathematisch zu beschreiben. Die gute Nachricht ist aber, dass die verschiedenen Geoid-Modelle sich nur wenig voneinander unterscheiden, Hm - man liest von bis 100 m Sicher, dass damit nicht der Unterschied zwischen Geoid und Ellipsoid gemeint ist? Ja, es geht um genaue Höhen. Die man als Referenzpunkte nutzen kann. Und die hast du mit einer entsprechenden genauigkeit in einer kompatiblen Lizenz vorliegen? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege im Nationalpark
Steffen Heinz schrieb am 09.02.2011 16:45: ist ja noch nicht zu alt und ist altes Militärgebiet. Bist du sicher, dass die Bing Luftbilder nicht eventuell alt sind? Bei einem mir bekannten, ehemaligen Uebungsplatz wurden massive die Wege zurueckgebaut. D.h. was frueher mal da war, ist heute nicht mehr. Das Wegenetz wurde für Besucher eingeschränkt, auf einen Bruchteil. Ganze Gebiet sind gesperrt. Wenn da ein echter Weg ist, den aber Normalmensch nicht nutzen darf aber z.B. ein Foerster, so trage ich den Weg mit entsprechenden Access-Tags ein. Inoffizielle Wege (sichtbare Trampelpfade) in gesperrten Gebieten trage ich nicht ein: Da ist kein Weg weil da kein Weg sein darf. (Mich stoert das schoen gewaltig, dass die Leute sich nicht an die Vorschriften in den Schutzgebieten halten koennen.) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege im Nationalpark
M∡rtin Koppenhoefer schrieb am 09.02.2011 17:57: Die Wege kommen zum Teil auch durch Tiere. In dem Naturschutzgebiet hier bei mir nebenan kommen die Wege sowohl durch Menschen als auch durch Tiere: Da sind es hauptsaechlich die sch... Hundebesitzer, die auf die Umwelt keine Ruecksicht koennen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Frederik Ramm schrieb am 26.01.2011 21:47: So wie das auf der mkgmap-Liste klingt, muss wohl auch beim Zubereiten des Europa-Ausschnitts die neue Version benutzt werden. (Da wird doch mit Osmosis geschnitten, oder?) Kommt da heute Nacht die neue Version zum Einsatz? Hab ich zwar nicht so verstanden, aber ich aktualisiere vorsichtshalber mal mein osmosis auch. Inzwischen klingt das auf der mkgmap-Liste auch wieder anders, da war wohl beim Bauen der neuen Splitter-Version was schiefgegangen. Ich werde die neuste Splitterversion mal auf eine alte europe.osm.pbf loslassen, eine neue pbf-Version kann ich bei meiner lahmen Internetverbindung sowieso erst am Wochenende testen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Frederik Ramm schrieb am 26.01.2011 09:31: Scott Crosby schreibt auf dev, dass er (mit Hilfe von Stephan Knauss) jetzt eine verbesserte Implementierung gemacht hat, bei der die Probleme unter Windows nicht mehr auftreten. In der trunk-Version von Osmosis ist das wohl ab sofort enthalten. So wie das auf der mkgmap-Liste klingt, muss wohl auch beim Zubereiten des Europa-Ausschnitts die neue Version benutzt werden. (Da wird doch mit Osmosis geschnitten, oder?) Kommt da heute Nacht die neue Version zum Einsatz? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GEOFABRIK pbf Downloads nicht aktuell?
Moin, Frederik Ramm schrieb am 11.01.2011 20:25: Es scheint ein Problem mit dem GWDG-Mirror zu geben, der hat sich letzte Nacht keine neuen Daten geholt. Der Geofabrik-Server schickt Dich aber trotzdem dahin (im blinden Vertrauen darauf, dass dort die aktuellen Daten sind). Da wollte ich es dann heute noch mal mit den neusten Daten versuchen, aber so richtig gesund sieht ft5.gwdg.de nicht aus. Er antwortet zwar auf ein ping, und Index von ftp://ftp5.gwdg.de/; bekomme ich im Feuerfuchs auch zu sehen, aber irgendwelche Daten scheint er z.Z. nicht rauszuruecken. Da steht in der Statusleiste nur Warten auf ftp5.gwdg.de ... und sonst tut sich nichts. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GEOFABRIK pbf Downloads nicht aktuell?
Torsten Leistikow schrieb am 12.01.2011 16:33: Da wollte ich es dann heute noch mal mit den neusten Daten versuchen, aber so richtig gesund sieht ft5.gwdg.de nicht aus. Er antwortet zwar auf ein ping, und Index von ftp://ftp5.gwdg.de/; bekomme ich im Feuerfuchs auch zu sehen, aber irgendwelche Daten scheint er z.Z. nicht rauszuruecken. Da steht in der Statusleiste nur Warten auf ftp5.gwdg.de ... und sonst tut sich nichts. Jetzt scheint ftp5.gwdg.de wieder zu laufen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GEOFABRIK pbf Downloads nicht aktuell?
Moin, ist bei den pbf-Auszuegen von der GEOFABRIK irgendwas kaputt? Gestern Nachmittag hatte ich germany.osm.pbf runtergeladen, da waren anscheinend verschiedene Aenderungen von mir aus den letzten Tagen noch nicht drin. Heute Nachmittag habe ich dann wieder die Datei runtergeladen. Laut GEOFABRIK-Seite ist die vom 11-Jan-2011 02:07, aber die md5-Summe ist genau die selbe wie bei der gestern runtergeladenen. Kann jemand das Problem bestaetigen oder dementieren? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OT] Garmin etrax vista schaltet sich ab
Moin, als weitere moeglich Erklaerung kann ich noch bieten, dass bei Erschuetterungen leicht mal der Kontakt zu den Akkus verlorengehen kann. Auch wenn die Battrien ja eigentlich immer vom selben typ sind, so sitzen sie doch mal mehr und mal weniger fest in den Halterungen. Falls das das Problem ist, so wird im Internet empfohlen, ein bisschen Schaumstoff unter die Kontaktfedern zu klemmen. Von einem blossen Verbiegen der Federn wird i.A. abgeraten, die sollen dabei gerne mal abbrechen. Bei meinem Etrex trat dieses Problem erst mit zunehmendem Alter auf, wenn die Batterien aber zufaellig minimal kurz ausfallen, dann kann das sicherlich auch bei einem Neugeraet passieren. Gruss Torsten PS: Nur wegen einem abloesenden Gummi tauscht man doch nicht so ein Geraet. Im Internet gibt es genug Anleitungen, wie man das mit beidseitigem Klebeband selber repariert, das haelt dann besser als zuvor. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßen-Tags für Luftbildstraßen
Es liegt bei OSM in der Natur der Sache, dass die Daten meistens nicht vollstaendig sind. Ob es ein fehlendes oneway, ein maxspeed, maxheight, maxweight oder eine access-Beschraenkung ist, ab wann kann man ueberhaupt davon reden, dass eine Strasse komplett erfasst ist? Wenn man jetzt aber einfach ale Strassen pauschal als highway=road eintraegt, dann verschenkt man jede Menge Informationen, die man sonst schon mal in der Datenbank haben koennte. Da highway=raod auch bedeuten koennte, dass es sich um einen Fussweg handelt, sind diese Strassen fuers Routing komplett unbrauchbar. Ein fehlendes oneway-Tag wuerde immerhin in 50% der Faelle trotzdem das richtige Routing liefern :-) Also immer so viel Informationen wie moeglich in die Datenbank eintragen, der Rest wird schon im Laufe der Zeit ergaenzt werden. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
André Joost schrieb am 13.12.2010 09:13: Da die europe.pbf bis zum 2.12.2010 wohl funktionert haben soll: Die Datei ist jetzt 4,1GB gross. Hat sie zufaellig in letzter Zeit die 4GB Grenze ueberschritten? Das wuerde allerdings auch nicht erklaeren, wieso eine selbstgepackte pbf-Datei auf einem Windof-System funktioniert, es sei denn, dass schon beim packen auf dem Windof-Rechner ein Teil verloren geht und die pbf-Datei deshalb gar nicht vollstaendig waere. Gibt es irgendwo eine andere pbf-Datei groesser als 4GB, die man mal zum Vergleich probieren koennte? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Andre Joost schrieb am 11.12.2010 17:43: Lässt sich das aktuelle Niederlande-Extrakt verwerten? Ich habe eben mal netherlands.osm.pbf splitter zum Frass vorgeworfen: Das funktionierte ohne Probleme. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Moin, europe.osm.pbf will sich bei mir immer noch nicht mit splitter (r161) zerlegen lassen (Windof x64 System). Ich hatte eigentlich gehofft, dass sich das gleichzeitig mit dem Plattenproblem loesen wuerde, es schienen ja aber wohl zwei verschiedene Effekte zu sein. Kann inzwischen jemand sagen, ob das ein europe.osm.pbf oder ein splitter-Problem ist? Koennen wir irgendwie eingrenzen, welche Programme und welche pbf-Ausschnitte sich z.Z. nicht miteinander vertragen? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hecken
Steffen Heinz schrieb am 10.12.2010 15:10: Die Gegend um Monschau und Simmerath ist ja Typisch für die Hecken (http://de.wikipedia.org/wiki/Monschauer_Heckenland), auch als Feld und Wieseneinzäunung was mir was Schwierigkeiten macht sind parallel laufende Wege (beides verschmilzt leicht) Das Problem hat man im Norden der Republik auch, wenn man Knicks oder Graeben erfasst. Solange es hier keine allg. akzeptierte Loesung fuer Linienbuendel gibt, ist das nun mal so. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hecken
M∡rtin Koppenhoefer schrieb am 10.12.2010 16:52: ein echtes Problem erkenne ich nicht, das sind Probleme beim Rendern, die m.E. durch ein Linienbündel nicht besser würden (sondern nur gröber, dh. man verlöre Details). Lösen könnte man es durch Flächen (echte Straßenflächen, Randstreifenflächen, etc.), Nein, so funktioniert das nicht. Ein Renderer MUSS die Strassen, Wege usw. vergroessert (d.h. nicht massstabsgerecht anzeigen), da man sie ja sonst bei grossen Massstaeben nicht wuerde erkennen koennen. (Eine Karte hat nun mal eine andere Aufgabe als ein Luftbild). Die Strasse als Flaeche eintragen wuerde da ueberhaupt nichts helfen. Eine Beschreibung der Linienbuendel braucht man dann, um auch bei solchen nichtproportionalen Vergroesserungen die relative Lage der Linien zueinander ordentlich wiedergeben zu koennen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hecken
M∡rtin Koppenhoefer schrieb am 10.12.2010 17:26: wir reden aneinander vorbei: klar, in kleineren Zoomstufen sollten die Straßen (in einer Karte, die auf Straßen Wert legt) überhöht werden. In diesen Zoomstufen hat man aber auch üblicherweise keine Hecken drin, oder? Die Vergroesserung der Strassen faengt deutlich frueher an, als du zu denken scheinst. Wenn dem nicht so waere, dann gaebe es auch keine Probleme bei der Darstellung von Wegen und benachbarten Hecken, da durch die Koordinaten ja in der Datenbank drin steht, dass die nebeneinander liegen. (Nur ist diese Information halt nicht ausreichend fuer die saubere Anordnung der Objekte beim Rendern.) Eine Karte mag ja noch ein definiertes Zielpublikum haben, eine Geodatenbank sollte aber möglichst universell sein. Was spricht denn dagegen, dass man die Linienbeundeleigenschaft in der Datenbank erfasst (abgesehen davon, dass man sich da bislang auf kein Vorgehen einigen konnte)? Das ist letztendlich ja nur eine Zusatzinformation. Ein Luftbild hat m.E. überhaupt keine Aufgabe. Und wofuer soll das flaechenmaessige Abmalen von Linienbobjekten deiner Meinung nach gut sein? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hecken
M∡rtin Koppenhoefer schrieb am 10.12.2010 18:18: Kannst Du die Frage nochmal präzisieren? Zur Erinnerung, der Anfang war folgendes Problem: Steffen Heinz schrieb am 10.12.2010 15:10: Die Gegend um Monschau und Simmerath ist ja Typisch für die Hecken (http://de.wikipedia.org/wiki/Monschauer_Heckenland), auch als Feld und Wieseneinzäunung was mir was Schwierigkeiten macht sind parallel laufende Wege (beides verschmilzt leicht) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hecken
RalfGesellensetter schrieb am 10.12.2010 20:17: Hallo, es ist doch genau andersherum: Ok, beim Massstab kann ich mir immer nicht merken, in welcher Richtung man von grosser bzw. kleiner spricht. Bei kleinen Zoomstufen müssen z.B. Straßen breiter dargestellt werden (im Maßstab 1:1 wären 5 Meter ein halber Millimeter) und für Hecken ist daher kaum Platz (bei einem Linienbündel würde sich die Lage entsprechend der Darstellung verschieben) - Hecken werden erst bei großen Zoomleveln sichtbar (dann ist die Straße evtl. sogar eingigermaßen Maßstabsgetreu bzw. eher zu dünn). 1:1 ist schon ein extrem grosser Massstab, Messtischblaetter z.B. haben ja 1:25000. Und auch auf so einer Zoomstufe will man ja Feld-Hecken, Knicks, Graeben, Zaeune, Mauern usw. sehen. Damit man da aber die Wege ordentlich erkennen kann, muessen sie so verbreitert gezeichnet werden, dass sie angrenzende Objekte ueberdecken, wenn man diese nicht entsprechend verschieben wuerde. Auf einer normalen, topographischen Karte ist das also ganz ueblich, es faellt halt beim Betrachten nur nicht auf und so genau nachmessen macht ja auch keiner. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Frederik Ramm schrieb am 07.12.2010 22:26: Koennte jemand es mal mit einer kleinen Datei probieren (saarland.osm.pbf oder so) und im Vergleich dazu die .osm.bz2? Ich habe eben mal die neuste germany.osm.pbf runter geladen und die hat mit splitter problemlos funktioniert. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit osm.pbf
Frederik Ramm schrieb am 06.12.2010 20:05: Welches europe.osm.pbf (genaue Dateigroesse und/oder md5-Summe) nutzt Du? Ich habe heute Nachmittag die europe.osm.pbf runtergeladen (4.359.056.275 Bytes) und die eben vergeblich Splitter vorgesetzt. Die daraus resultierenden Garmin-Karten scheinen nur Punktobjekte zu enthalten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Fichtennadel schrieb am 22.11.2010 08:13: Mir ist es jedenfalls zu aufwendig, nochmal über jeden Weg eine Relation drüberzulegen, nur weil er markiert ist. Ist er denn ohne besonderen Grund markiert? Oder steckt da ein System hinter der Markierung, dass man per Relation gut erfassen koennte? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
NopMap schrieb am 21.11.2010 08:57: Nein. Wenn der Editor gleich in eine Karte integriert ist, wird er von den Nutzern auch gefunden - dazu gibt es ja den alten Potlatch unter Edit direkt auf der Hauptseite. Ich denke, die Idee ist gar nicht schlecht: Wenn ein Endanwender ein freie Wanderkarte nutzt, dann muss er auf dem Weg dahin ja nicht ueber die OSM-Hauptseite gehen. Und dort, wo er seine Wanderkarte findet, findet er auch gleich einen einfachen Editor, der genau auf diese Karte hin optimiert ist. So kann er mit relativ einfachen Mitteln seine Wanderkarte verbessern. Dass er dabei im Hintergrund die OSM-Karte verbessert, wird dem Anwender egal sein. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzungen in einem Park - Ebenen
tshrub schrieb am 21.11.2010 07:10: werden Nutzungen in einem Park (Sichtwiese, Liegewiese, Weide, Wasser, Forst, Blumen, ...), dessen Gesamtfläche als layer=-1 gekennzeichnet/unterlegt ist, noch einmal mit leisure=park kennzeichen? Eigentlich nicht, da es sich aus der Unterlegung ergibt? Das layer=-1 ist da erstmal kompletter Bloedsinn und sollte gleich gelöscht werden. Denn der Park liegt ja nicht physikalisch unter den Einzelobjekten. Ansonsten rein von der Semantik her muessen/sollten die Objekte innerhalb der Parkpflaeche nicht noch mal zusaetzlich mit leisure=park gekennzeichnet werden. Das ergibt sich ja bereits aus dem umschliessenden Park-Polygon Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
qbert biker schrieb am 20.11.2010 14:55: In diesem Fall war die Lehre aus der Sache, dass OSM derzeit keine Wanderkarte ersetzt, die markierte und beschilderte Wege sauber in der Darstellung von wilden Trampelpfaden trennt, wobei man letzere nur mit viel Selbstvertauen und Geländegefühl begehen sollte. Nach meinem Verstaendnis sollten ausgeschilderte Wege als Relationen eingetragen werden, die dann auf den ueblichen Wanderkarten auch entsprechend hervorgehoben werden. Etablierte Mittel und Wege gibt es also. Offensichtlich warst du in einer Gegend unterwegs, wo die OSM-Karte noch nicht so ausgereift ist wie anderswo. Aber das wir mehr oder minder weisse Flecken haben ist ja nichts neues. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Fichtennadel schrieb am 20.11.2010 16:40: Jein. Die Relationen werden nach aktuellem Stand für Wanderrouten, also benannte Wanderwege verwendet. Ein Weg kann auch markiert sein, ohne dass er einen Namen trägt oder zu einer bestimmten Route (z.B. Weitwanderweg 01) gehört. Also in dem Gebiet, in dem ich mich ab und an rumtreibe, werden alle markierten Wanderwege per Relationen erfasst (und zwar nicht nur von mir). Dabei ist es egal ob sie einen besonderen Namen haben oder sonstwie markiert sind. Und ich wuesste auch nicht, wie man abgrenzen sollte, ab wann markierte Wege als Routen anzusehen sind und wann nicht. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
Ulf Lamping schrieb am 16.11.2010 09:20: Ich würde eine Pumpstation von der Art her parallel zu Pipeline sehen: http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline Ob die einzelnen Subtags dort besonders schlau gemacht sind lasse ich mal dahingestellt, aber die Ähnlichkeit zwischen einer Pumpstation und einer Pipeline sind in der Realität so frappierend, das die dort verwendeten Subtags auch hier verwendet werden sollten. (Mal abgesehen davon, dass wir bei der urspruenglichen Fragestellung nicht mal genau wissen, wer da was pumpt.) Die Frage hier ist doch mal wieder, aus welchem Blickwinkel man ein Objekt betrachtet: A) Es handelt sich hierbei grob gesagt um ein Objekt der Abwasserentsorgung. Und wenn man das genauer betrachtet, sieht man, dass es sich dabei um eine Pumpstation handelt. oder B) Es handelt sich hierbei grob gesagt um eine Pumpstation. Und wenn man sich diese genauer betrachtet, sieht man, dass diese Abwaesser pumpt. Die eine Sichtweise ist genauso gut/schlecht richtig/falsch sinnvoll/unsinnig wie die andere. Und da wir bei OSM nun mal keine festen Vorgaben machen, kann man davon ausgehen, dass auch beide Sichtweisen ihre Anhaenger haben werden und dementsprechend auch beide irgendwann in der Datenbank auftauchen werden. Ein Glueck, dass es fuer die meisten Anwendungen (Karten) sowieso egal ist. Und wenn sich eine Anwendung speziell diesem Thema widmen will, dann wird sie sich halt mit den verschiedenen Spezialfaellen und Sichtweisen rumschlagen muessen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pumpwerk der Entsorgung
Jan Tappenbeck schrieb am 15.11.2010 12:07: da ich da nicht reinschauen kann weiß ich von einem Bekannten nur das es sich um ein Pumpwerk für Schmutzwasser handelt. Deine Frage ist also genaugenommen: Wie Tagge ich etwas moeglichst praeziese, von dem ich gar nicht genau weiss, was es ist ;-) Zum Thema: Ist wastewater_plant wirklich falsch? Mit meinem Laienhaften englisch wuerde ich sagen, dass das allgemein eine Einrichtung der Wasserentsorgung beschreibt. Dass wir damit bisher ausschliesslich Klaeranlagen bezeichen, duerfte in erster Linie daran liegen, dass noch keiner den Bedarf gesehen hat, andere Wasserentsorgungsanlagen genauer einzutragen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offline Tile Server?
André Joost schrieb am 10.10.2010 18:14:
Eigentlich brauchst du gar keinen Server dafür. Es reicht, wenn du den
Aufruf in Openlayers in der openStreetMap.js umbiegst:
OpenLayers.Layer.OSM.Mapnik = OpenLayers.Class(OpenLayers.Layer.OSM, {
/**
* Constructor: OpenLayers.Layer.OSM.Mapnik
*
* Parameters:
* name - {String}
* options - {Object} Hashtable of extra options to tag onto the
layer
*/
initialize: function(name, options) {
var url = [
file:///D:/Tiles/Mapnik/${z}/${x}/${y}.png
];
options = OpenLayers.Util.extend({ numZoomLevels: 19 }, options);
var newArguments = [name, url, options];
OpenLayers.Layer.OSM.prototype.initialize.apply(this,
newArguments);
},
CLASS_NAME: OpenLayers.Layer.OSM.Mapnik
Danke fuer den Tipp. Das sieht doch so aus, als ob es mein Problem loesen
muesste, und neben bei lerne ich dann auch gleich noch mal OpenLayers kennen :-)
Gruss
Torsten
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trigonometrischer Punkt
Moin, Chris66 schrieb am 29.09.2010 21:29: im Wiki stehts halt anders: Im Wiki steht halt viel Muell drin. Auf der ele-Seite wird als Hoehenreferenz die height above sea level angegeben, womit allgemein die Hoehe ueber dem (welchem auch immer) Geoid gemeint ist. Erst im Nebensatz wird WGS84 erwaehnt, wobei die Ellipsoid-Hoehe ja was komplett anderes ist. Und wenn man sich mal Hoehendaten in der Datenbank anschaut, dann wird man da normalerweise die Geoid-Hoehe finden, mir ist zumindest noch keine andere Eintragung begegnet. - Die GPS Chips liefern halt die elliptische Höhe (angezeigt wird aber auf vielen GPS Geräten trotzdem die durch die Firmware ermittelte NN Höhe). Dein Geraet liefert die entweder die Hoehe ueber dem Ellipsoid, oder aber die Hoehe ueber Mean-Sea-Level (wie auch immer definiert). Hierzulande kann man beide Werte gut unterscheiden, da doch ein erheblicher Unterschied besteht (ca. 30-40m). Das Ergebnis ist aber nicht trivial zu konvertieren, da man ja nicht weiss, welche Umrechnung das Geraet intern benutzt hat. - Der Referenzwasserspiegel ist weltweit nicht einheitlich. Nein, aber verglichen mit der Genauigkeit der meisten uns vorliegenden Daten ist das durchaus zu vernachlaesisgen. Die elliptische (wgs84) Höhe ist hingegen weltweit einheitlich und nicht von der Güte des Geoidmodells abhängig. Es ist zwar einheitlich, interessiert aber niemanden. Nirgendwo auf der Welt werden Hoehen relativ zum Ellipsoid angegeben, weil die Abweichungen zum Geoid (welchem auch immer) viel zu gross sind. Also mueste man alle Werte, die man irgendwoher bekommt, erst fehlerbehaftet auf das Ellipsoid umrechnen. Und wenn man die Daten dann nutzen will, dann darf man fehlerbehaftet das Ganze wieder zurueck auf die Geoidhoehe konvertieren. Wenn man keine Probleme hat, dann macht man sich welche, oder was soll das sonst bringen? Wer (wie ich) trotzdem lieber die gebräuchliche NN Höhe in den Daten haben will kann es ja mittels alt:NN=### tun. Sinnvoll ist es, die Hoehe ueber Mean Sea Level (also die Geoid-Hoehe bezogen auf welche Referenz auch immer) als Default in die Datenbank einzutragen. Angesichts der Tatsache, dass unsere Werte i.A. sowieso nicht 100%-ig exakt sind, ist das fuer uns alle Mal genau genug. Und wenn man ausnahmsweise mal einen Wert sehr genau hat, dann kann man ihn ja entsprechend der alt:* Notation zusaetzlich mit Angabe des Referenzsystems eintragen. Nebenbei bemerkt: Die SRTM-Hoehendaten benutzen auch WGS84 Koordinaten fuer die Lage und geben trotzdem die Hoehe ueber dem Geoid an. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anonymisierungs-Tool für gpx-Dateien ges ucht
Simon Kokolakis schrieb am 29.09.2010 16:32: dann ist nur noch intern ein Bezug zu meinem Usernamen vorhanden, für Außenstehende aber definitiv nicht? Diese Trennung kannst du vergessen. Es kann dir kein ehrlicher Mensch garantieren, dass diene Daten nicht in falsche Haende gelangen. Sobald die Daten deinen Rechner verlassen hast du sie nicht mehr unter Kontrolle. Alles ausserhalb dieser Linie musst du rein faktisch als oeffentlich betrachten. Deshalb ist der Webdienst zum Anonymisieren auch eine Schnappsidee, denn damit hat man ja nur ein neues potentielles Datenleck eingefuehrt. Es kann dir keiner garantieren, dass nicht eben dieser Webdienst deine Daten speichert/auswertet/weiterleitet bevor er sie anonymisiert. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trigonometrischer Punkt
Markus schrieb am 29.09.2010 18:38: Ich habe aber keine Ahnung, wie man eine Höhe aus NHN oder NN in unser wgs84 umrechnet... Am besten gar nicht. (ansonsten siehe http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/intpt.html) Hoehe ueber dem Elipsoid interessiert allgemein nicht, als Referenz nimmt man eigentlich immer ein Geoid und gibt die Hoehe relativ zur Meereshoehe. Deshalb ist es am sinnvollsten, wenn man einfach das Refernezsystem mit angibt. Siehe auch: http://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anonymisierungs-Tool für gpx-Dateien ges ucht
Stephan Wolff schrieb am 29.09.2010 18:50: Ein solcher Webdienst wäre aber schon ein großer Fortschritt. Nicht einen Deut aufwendiger aber wesentlich sinnvoller waere es, wenn das Anonymisiertool kein Webdienst waere sondern eine Anwendung auf deinem Rechner. Wozu um alles in der Welt soll das auf einen fremden Server laufen? Nebenbei bemerkt lasse ich bei meinen Tracks immer das Jahr intakt, damit immerhin noch eine grobe zeitliche Zuordnung moeglich ist. Vielleicht ist es mal ganz hilfreich, wenn man mal alte Tracks von der Anzeige ausschliessen will (z.B. wenn sich der Verlauf eienr Strasse mal geaendert hat). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Fläche =?utf -8?q?umschlie=C3=9Ft?= Wald
Wolfgang schrieb am 27.09.2010 22:57: Straßen, Wege etc nehme ich aus dem landuse nicht raus. Ebenso wie bei Wohngebieten ändert die Tatsache eines Weges / einer Straße nichts an dem zusammengehörigen Gebiet. Das sehe ich wie einen Spielplatz im Wohngebiet. Das speziellere überdeckt hier das allgemeinere, verdrängt es aber nicht. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anonymisierungs-Tool für gpx-Dateien ges ucht
Chris66 schrieb am 27.09.2010 14:48: Am 27.09.2010 14:09, schrieb Simon Kokolakis: Eine sinnvolle Anonymisierung wäre meines Erachtens: - Zerlegung der Tracks in Stücke einer bestimmten Maximallänge z.B. 50 - Bei jedem Stück wird der Zeitstempel aller Punkte um einen eigenen Zufallswert verschoben, so dass die relative Zuordnung erhalten beibt. -1 Entweder korrekte Daten hochladen oder es sein lassen. -1 Anonymisierte Daten sind besser als gar keine Daten. Ich werde bestimmt nicht auf fremde Server hochladen, wann ich wo gewesen bin. Ich schneide bei meinen tracks haendisch Anfang und Ende ab und aendere das Datum jeweils auf den 1.1. des Jahres. Aus den Zeitstempeln könnte man zB. Verkehrsflussanalysen machen, wenn Du das fälschst geht das nicht mehr Dafuer reichen die Daten sowieso noch lange nicht aus, wir sind ja schon froh, wenn wir ueberhaupt genug Daten zusammen bekommen, um den Strassenverlauf genau bestimmen zu koennen. Selbst beim Autobahnkreuz hier bei mir nebenan kommen keine 50 Spuren zusammen. Das ueber mehrer Jahre verteilt willst du zeitbasiert untersuchen um eine Verteilung festzustellen? Bei Stellen mit sehr vielen Tracks wirst du heochstens feststellen koennen, um wieviel Uhr da jeweils ein und der selbe Mapper auf sienem taeglichen Arbeitsweg vorbei kommt. Und genau solche Informationen sollte man aus den Daten besser nicht gewinnen koennen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Fläche =? iso-8859-15?q?umschlie=DFt?= Wald
Manuel Reimer schrieb am 26.09.2010 21:09: Wolfgang wrote: Etwas verzerrt wird das ganze aus meiner Sicht, wenn jetzt verstärkt dazu übergegangen wird, innerhalb der Wohngebiete jede Rasenfläche und jeden Vorgarten zu mappen. Wäre das nicht OK, wenn dafür ein Multipolygon angelegt wird? Ist der Vorgarten ein Teil des Wohngebietes? Wenn du der Meinung bist, dass er dazu gehoert, dann darfst du ihn natuerlich nicht per multipolygon ausschneiden. Um es nochmal zu explizit zu sagen: Eine multipolygon-Relation ist dazu da, um eine Flaeche mit Ausschluessen zu definieren. D.h. innerhalb der inner-Polygone sollen die Tags der Relation nicht gelten. Es ist nicht dazu da, um die Anzeigereihenfolge der Renderer bei ueberlagernden Eigenschaften zu regeln. Diese Entscheidung ist alleine Sache der Renderer, da je nach Anwendung die eine oder die andere Eigenschaft wichtiger sein wird. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mkgmap und ref
aighes schrieb am 10.09.2010 22:32:
Das Problem aus dem Forum mit mehreren Relationen musst du aber immer noch
lösen.
Auf der mkgmap-Liste habe ich gerade die folgende Information bekommen:
I implemented the $(variable_name) syntax some time ago, to get bus
route relations translated properly. An excerpt from --style=routes:
[relations file]
type=route ... {
apply { set mkgmap:route='$(mkgmap:route),${ref}' | '${ref}' }
}
[lines file]
highway=* mkgmap:route=* { name '${mkgmap:route}' } [0x1d resolution 16]
Note that in the apply rule, the $(mkgmap:route) is referring to an
attribute of the relation member, and the ${ref} is referring to an
attribute of the relation.
Probleme macht das allerdings noch, wenn mit verschiedenen Rollen (forward,
backward) bei den Mitgliedern gearbeitet wird. Das kann dann dazu führen, dass
der ref Text doppelt in der Karte erscheint.
Gruss
Torsten
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zu viele Namen in OSM-Karten
Robert Kaiser schrieb am 09.09.2010 13:39: Das Tagging ist sehr oft nicht wirklich falsch (siehe z.B. mein Lieblingsbeispiel, wo das Schulareal und das Schulgebäude selbst beides den Namen der Schule tragen). Entweder verstehe ich dich falsch, oder aber ich bin entgegengesetzter Meinung. Wenn eine Schule bereits als Gelaende erfasst ist, dann gehoert an die einzelenen Gebaeude meiner Meinung nach nur noch ein building=yes. Aussnahme ist, wenn die einzelnen Gebaeude eigenstaendige Namen haben. Der Name der Schule hat in so einem Fall an den Gebaeuden aber nichts mehr zu suchen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm richtig getaggt?
M∡rtin Koppenhoefer schrieb am 06.09.2010 00:18: könnte man, aber es ist auf Dauer schädlich (es ist jetzt schon schädlich). Wem oder was schadet es denn? Ok, man hat ein bisschen mehr Verwirrung dadurch, aber wirklich weh tut es eigentlich nicht. Viel schlimmer ist der umgekehrt Fall, wenn unter einem Tag verschiedene Bedeutungen verstanden werden. aber es ist ein unnötiger Mehraufwand und Platzbedarf. Kannst du das mit dem Platzbedarf irgendwie weiter ausfuehren? Wieviel Bytes Einsparung erwartest du dir denn dadurch, wenn du alle Elemente mit landuse=farm auf landuse=farmland umaenderst??? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm richtig getaggt?
Claudius schrieb am 05.09.2010 20:05: Das ist nicht möglich, da bisher mit landuse=farm getaggt flaggen eben *nicht* eindeutig Felder sind, sondern sowohl die Fläche mit den Wirtschaftsgebäuden als auch die bewritschaftete Fläche bezeichnet sein kann. Das waren aber schon immer Fehleintragungen, landuse=farm hat von Anfang an die bewirtschafteten Flaechen gemeint. Jedes Auswerteprogramm (zumindest soweit ich weiss) behandelt farm und farmland gleich (was sollte es auch sonst tun, es meint ja per Definition das selbe). Insofern kann man da eigentlich keinen Schaden anrichten, wenn man das automatisch gleich zieht. Man kann es aber auch lassen wie es ist. Wie oben bereits erwaehnt ist es ja Einleichtes fuer die Auswerteprogramme, beide Tags gleich zu behandeln. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farm richtig getaggt?
Christopher Reimer schrieb am 03.09.2010 23:09: Und was soll ich jetzt machen, dass es stimmt? So scheint es ja nicht bleiben zu können. Ruhig bleiben und nicht alles so ernst nehmen. Wie schon andere geschrieben haben, gibt es bei diesem Thema (wie eigentlich bei jedem Thema bei OSM) unterschiedliche Meinungen. Insofern kannst du im Prinzip die Daten so eintragen, wie es dir am sinnvollsten erscheint bzw. am besten gefaellt. Ich persoenlich verbinde zwei Flaechen oder auch einen Weg und eine Flaeche genau dann miteinander (d.h. benutze die selben Knoten), wenn zwischen den beiden Flaechen nichts ist, was ich als eigenes Element in die Karte einzeichnen moechte. Andere Leute sehen das anders. Alles wieder rausschmeißen? Das ist in diesem Fall die schlechteste aller Moeglichkeiten. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff schrieb am 02.09.2010 09:46: Mir ist durchaus bewusst, dass die Navigation nicht die erforderliche Genauigkeit bieten kann. Um so wichtiger ist aber die Modellierung korrekter Topologie. Auch einem Blinden Fußgänger kann ich die Anweisung geben, den Fußweg entlangzugehen. Solange keine Rückfrage kommt ich hab mist gebaut kann das System davon ausgehen, dass der Fußgänger auf dem Fußweg geblieben ist, und entsprechend auch ungenaue GPS-Signale korrigieren. Nichts anderes machen Kfz-GPS, wenn sie das GPS-Signal auf der Straße einfangen, obwohl es teilweise danebenliegt. Um so schaedlicher ist aber ein uebermaessiger Detailreichtum der Daten. Was du hier zu bauen versucht ist ein klassischer Verstoss gegen das http://de.wikipedia.org/wiki/Nyquist-Shannon-Abtasttheorem. Wenn du mit zu ungenauen Position auf zu detaillierten Wegnetzen navigieren willst, dann wird das fuerchterlich daneben gehen, weil du immer wieder zu falschen Entscheidungen kommst, wo du gerade bist. praktisch ausgedrueckt bedeutet das, dass deine Navigation nicht wird erkennen koennen, auf welcher Strassenseite du dich befindest. Deshalb wird sie zwangslaeufig immer wieder falsche Komandos geben, um die Strasse zu wechseln. Ungenaue GPS-Signale sind aber kein Argument für ungenaue Karten - im Gegenteil: Bei grob modellierten Kartendaten UND ungenauem GPS-Signal steigt die Wahrscheinlichkeit, dass Fehler sich aufsummieren - und das Endergebnis noch schlechter ist. So eine Folgerung gilt nur fuer kontinuierliche Systeme. Bei diskreten Systemen, womit wir es hier ja zu tun haben, koennen und werden zu viele Details durchaus zu einer Verschlechterung fuehren. Ich hoffe nicht, aber ich hoffe auch, dass die OpenStreetMap Potential nach oben hat - und nicht einfach durch Relevanzdiskussionen gestoppt wird, die künstliche Beschränkungen auferlegen. Ich hoffe, bei deiner Bachelorarbeit versuchst du nicht die naturgegebenen Beschraenkungen der Mathematik zu verletzen. Da kannst du sicher sein, dass die Mathematik gewinnen wird. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnrouting
Moin, Carsten Schwede schrieb am 29.08.2010 11:54: Else sagt bei so ziemlich jeder normalen Abfahrt, daß ich doch bitte Links halten soll. Das macht Sinn, wenn tatsächlich von mehreren Spuren eine dann in die Abfahrt abzweigt. Bei üblichen Abfahrten ist das aber etwas ungewöhnlich. Ist ja nett von Else, daß sie öfters mal spricht, aber komisch ist das schon. Ganz so schlecht sind meine Erfahrungen nicht, meine Sabbeltussi leitet mich inzwischen auch schon ganz brauchbar ueber Autobahnkreuze usw. hinweg, vor einem Jahr waren ihre Ansagen da noch ziemlich grausam. Vielleicht habe ich aber auch einfach nur Glueck mit der Erfasung in der Gegend, in der ich unterwegs bin. Welche Garmin-Typen benutzt du denn? 0x01 fuer motorway und 0x09 fuer motor_way link muessen es wohl schon sein, sonst passen auch die Ansagetexte nicht ordentlich (links halten vs links abbiegen). Ansonsten wenn du in deiner Gegend mehrere Stellen hast, wo die Autobahn grundlos unpassend getrennt ist, dann repariere sie doch einfach, so dass es fuer das Routing keine Probleme macht (Hauptsache damit macht man keiner anderen Anwendung neue Probleme). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff schrieb am 01.09.2010 18:12: Wenn also eine Spielstraße auf eine normale Verkehrsstraße mündet, geht der Bürgersteig entlang der normalen Straße nahtlos in den Spielstraßenbereich über. Wie also ist das einzutragen? Wenn man keine Probleme hat, dann schafft man sich eben welche: Da in einer Spielstrasse ein Fussgaenger ueberall lang kann, macht eine explizite Erfassung von Fussgaengeruebergangsstellen prinzipiell keinen Sinn. Die gesamte Strasse ist ja eine Uebergangsstelle, oder andersformuliert: Ein Fussweg geht nahtlos ueber eine Spielstrasse hinweg. Die OSM-Welt koennte so schoen einfach sein, wenn man sie denn nur liesse und nicht auf Krampf jeden Grashalm einzel eintragen wuerde. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff schrieb am 01.09.2010 21:39: Mir fehlt noch eine richtig gute Lösung, die Einzelnen Teile der Straße zusammenzubinden Und solange das fehlt, sind die separat eingetragenen Wege reiner Datenmuell, der mehr stoert als das er nutzt. Es gibt halt eben nicht nur die von dir eingetragenen Querungsmoeglichkeiten sondern noch unendlich viele dazwischen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
