Re: [Talk-de] Wie Gemeindename taggen?
Hi, bundesrainer schrieb: > Am 30.07.2010 07:26, schrieb Pascal Neis: Vielen Gemeinden sind in meiner Umgebung lediglich als Node mit name, place und weiteren Tags gemappt. Dabei verwenden sie immer das place=village Tag. Gibt es für die Abgrenzung innerhalb der Place-Nodes nicht für die Gemeinde eine andere Abstufung? Nein. Zwischen "village" und "town" bietet der "place"-Tag keine weitere Abstufung. Ich find's irgendwie nicht so richtig gut ... M.E. wäre ein expliziteres angeben eines Gemeindenames schon besser! Ist der "Name" einer Gemeinde nicht immer explizit? Ich verstehe nicht, was du hier meinst. Der Hintergrund warum ich frage ist die Verwendung der Gemeinde-Node in einer Adresssuche. Man weiß zwar das es ein Place-Node ist, man kann aber nicht aus dem Tag direkt herauslesen das es sich lediglich um den Gemeindenamen und nicht um ein Dorf handelt. Klar, wenn man es mit einem Multipolygon löst braucht man sich darüber keine Gedanken machen, ich bin nur gestern Abend auf die Nodes gestoßen und dabei ist mir die Frage gekommen. Bei vielen anderen Tags gibt es doch eine Vielzahl von verschiedenen Values. Warum nicht also noch einen weiteren mehr beim Place-Tag um genau eine Gemeinde zu kennzeichnen und damit eine feiner Unterscheidung zu erhalten ... ? danke & viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Gemeindename taggen?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.07.2010 07:26, schrieb Pascal Neis: > Vielen Gemeinden sind in meiner Umgebung lediglich als Node > mit name, place und weiteren Tags gemappt. Dabei verwenden sie > immer das place=village Tag. Gibt es für die Abgrenzung innerhalb > der Place-Nodes nicht für die Gemeinde eine andere Abstufung? Nein. Zwischen "village" und "town" bietet der "place"-Tag keine weitere Abstufung. > Ich find's irgendwie nicht so richtig gut ... > M.E. wäre ein expliziteres angeben eines Gemeindenames schon > besser! Ist der "Name" einer Gemeinde nicht immer explizit? Ich verstehe nicht, was du hier meinst. Die administrativen Strukturen lassen sich über Grenzrelationen am besten wiedergeben, wie von Augustus beschrieben. Beste Grüße, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMUnLSAAoJEPT/XJzV1tNzjmMIAImbnZnSIKhus3mCVc7zUSF2 VN7fxK3k4tV6xktRHKDexPI3eg0up7+pbHkgnEB6xRGcEvFRW1LztA853MJWgWow f8PNX7zgAkVnSGsAtVygNXFCls1MtIjdTYP84zl7MENZGijsHXYcmkFjsOebz2I6 zYGydfetqnvSk1rGNQF3yVl0kZX5dJaBznHvn1278j1ZP4+DZQSJP68mcP8X5ta6 iV6gV+28RDrgyTgjw5T1Y/r2QtowCFdj1NZMLcAxg7hOFB+mjp4zACy1DjdA0ZvH dAqkm0qAZ/1RgOA+HUADCkNEVizhiYifNhQ+MU8HCMReJZ6Bh3T8a3pRLHcd9yM= =mVV1 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Gemeindename taggen?
On 30.07.10 07:26, Pascal Neis wrote:
> Vielen Gemeinden sind in meiner Umgebung lediglich als Node
> mit name, place und weiteren Tags gemappt. Dabei verwenden sie
> immer das place=village Tag. Gibt es für die Abgrenzung innerhalb
> der Place-Nodes nicht für die Gemeinde eine andere Abstufung?
> Ich find's irgendwie nicht so richtig gut ...
> M.E. wäre ein expliziteres angeben eines Gemeindenames schon
> besser!
(aus österr. Sicht, aber die ist nicht so grundsätzlich unterschiedlich, nur die
Begriffe sind ggf. anders benannt)
Bis hinunter zur Gemeinde ist in AT (Bundesländer, pol. Bezirke, Gemeinden)
alles über Grenzpolygone definiert (und in OSM umgesetzt). Ja, es gibt das
Problem, wo eine Beschriftung derselben am besten plaziert wird und wo das
"Zentrum" solcher Gebiete anzunehmen ist. Gleichzeitig macht es für einen Router
kaum Sinn, irgendwo dorthin zu routen*), außer vielleicht zum jeweiligen
Verwaltungszentrum (Gemeindezentrum, BH, Landeshauptstadt; es würde Sinn machen,
eine solche Info in die Grenzrelation mit aufzunehmen). Diese Info müßte es in
OSM aber erst mal geben...
Unterhalb gibt es Ortschaften verschiedenster Größe (von Wien bis zum letzten
benannten isolated_dwelling; es gibt dafür ein Ortschaftsverzeichnis). Die sind
als place= Nodes repräsentiert. Und dorthin zu routen macht wahrscheinlich Sinn
("ich will nach Ort soundso"). Allerdings bleibt das Problem, wo ich der
"Mittelpunkt" dieses Ortes? vs. wo wird die Beschriftung hinplaziert. IMO sind
place= Nodes momentan Beschriftungspunkte, die eben die Platzierung der
Beschriftung definieren, und nicht wirklich den Ortsmittelpunkt angeben. Das
sollte man theoretisch auch irgendwie lösen...
Vom OpenGeoDB Import gibt es auch noch place nodes für die Gemeinde, aber die
führten in den meisten Gemeinden zu einer störenden Doppelbeschriftung, weshalb
sie großteils entweder gelöscht oder unsichtbar gemacht wurden. Die könne man
ev. reaktivieren/umdefinieren als Gemeindemittelpunkte, müßte gleichzeitig aber
den Renderern beibringen, das nicht zu rendern (weil Mapnik ja bekanntlich
fast(?) jedes name= rendert) und man müßte/könnte eine Zuordnung zwischen
Gemeindegrenze und "Beschriftungsnode" machen (wenn Du Gemeinden beschriften
willst, dann platziere die Beschriftung bitte dorthin).
*) nur so als Beispiel: die Gemeinde Wienerwald
besteht aus den Orten:
- Dornbach
- Grub
- Sittendorf
- Gruberau
- Stangau
- Sulz im Wienerwald
- Wöglerin
Wohin würde der Router routen wollen, wenn ich "Gemeinde Wienerwald" als Ziel
angebe? Einen Ort Wienerwald gibt es nicht. Übrigens ist auch die Adresse in der
Wikipedia Topfen, die Adresse des Gemeindeamtes ist Kirchenplatz 7, 2392 *Sulz*
im Wienerwald. Nur das kannst Du aus OSM-Daten derzeit nicht rauslesen...
Servus, Andreas
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_=3D=3Futf-8=3Fq=3F =5Fforward/backward=3F=3D?=)
Am Donnerstag 29 Juli 2010, 23:47:04 schrieb steffterra: > Es war aber sicher der Fall gemeint, dass einer der beiden tags falsch war, > da man den node von woanders hergezogen hat und dann bei der Vereinigung > entwscheiden muss, was jetzt stimmt. aber völlig irrelevant. denn das > problem hat man jetzt auch und sollte leicht zu lösen sein. Keine > Diskussiongrundlage, wie ich meine. > richtig, den Konflikt gibt es dann unabhaengig vom Modell. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:49:45 schrieb steffterra: > Am 29.07.2010 um 23:34 schrieb Guenther Meyer: > > Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: > >> Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass > >> die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten > >> way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher > >> sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung > >> der Unsicherheitsfaktoren. > > > > einen Unsicherheitsfaktor hast du immer. > > Nachher kommt ein Mapper, sieht deine drei ways und denkt sich "so ein > > Schmarrn, das ist doch nur ein Strasse", und zerlegt dir das Ganze > > wieder... ;-) > > Dafür gibts wikis und den Editro, der das ganze entsprechend rüberbringt. > Note-tags gibts auch noch. > leider keine 100%ige Loesung, aber die einzige, die wir im Moment haben. > Für die Umsetzung müssen natürlich alle an einem Strang ziehen. +1 > Abwärtskompatibilität bleibt ja dennoch erhalten. lassen wir uns ueberraschen. ich denke das koennte bei deinem Modell interessant werden. Man muesste mal ausprobieren, was ein heutiger Renderer aus deinem Modell machen wuerde (kann ich gerne machen, sobald was getaggtes vorliegt)... > > Letztendlich bleibt es dann doch wieder am Frontend haengen. > > Der User sollte nicht wissen muessen, ob er left, right, forward, > > backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen > > way dranbasteln soll... > > doch woher soll das frontend wissen, wo backward usw. in der Realität ist? > ist das so schwer?! der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?utf-8?q?_=3D=3Futf-8=3Fq=3F=5Fforward/b ackward=3F=3D?=)
Am Donnerstag 29 Juli 2010, 23:37:00 schrieb Ulf Lamping: > Am 29.07.2010 23:16, schrieb Guenther Meyer: > > Am Mittwoch 28 Juli 2010, 20:12:50 schrieb M∡rtin Koppenhoefer: > >> die Richtung dreht auch der Editor selbst automatisch alle Nas lang > >> (JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts > >> dran vorbei: die Richtung ändert sich (zumindest derzeit) oft. > > > > na dann wundert mich ja gar nix mehr... > > > > Stellt sich die Frage, warum macht er das, und muss das so sein? > > Das ist jetzt nicht dein Ernst, oder? > doch. bitte erklaer's mir! signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:44:33 schrieb steffterra: > Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder > baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich > etwas übersehen? > inklusive Fahrspurtagging. Da Konzept sollte wohl auch fuer andere Strassen erweitert werden, leider kamm dann erstmal nix mehr... > >> Das mag für Dich gelten, ich kenne hier aber keine Diskussion des > >> letzten Monats, das es zu irgendeinem Konsens brachte. > > > > an das wirst du dich bei OSM gewoehnen muessen ;-) > > Nein das meinte ich nicht. Iss schon klar ;-) Ich hatte aus Deinen Worten > gelesen, dass alles geklärt sei und dass das tagging, wie es ist doch > ausreicht. > Gut das das geklaert ist. Wenn alles perfekt waere, wuerde ich sicher nicht hier schreiben ;-) > Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren > ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn > dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein > sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. > Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. > > Irgendwie musst du die Gruppierung ja in der Datenbank speichern. > > Das naheliegendste ist da natuerlich eine einfache Relation. > > Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu > > taggen (wahrscheinlich sogar die bessere). > > ich dachte an eine ID die durch einen einfachen Algorithmus aus den > beteiligten ways automatisch errechnet wird. Ist das bei Relationen > genauso? > Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. > >> Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle > >> _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ > >> sinnvoll), die dieses Model bietet. > > > > wie jetzt, dein Modell? > > Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen > Spezialfälle umsetzbar? > Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts "Gruppe" selbst. > > da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit > > josm). Ich schau's mir an, und versuche dann mal, dasselbe auf "meine" > > Weise zu relaisieren... > > Da müsst Ihr Euch leider noch etwas gedulden. Aus beruflichen Gründen bin > ich massiver eingespannt, als ich dachte und bin froh, diesem Thread > weiter verfolgen zu können. > mir geht's da leider aehnlich... Aber hey, wenn am Ende was brauchbares rauskommt, kommt's auf ein paar Tage mehr auch nicht an ;-) > > richtig, das Frontend ist das wichtige. > > Ob sich dahinter drei ways mit ein paar Tags oder nur ein Way mit vielen > > Tags verbergen, ist doch eigentlich egal. > > Nein, da man schon möglichst einfach durchblicken sollte! wie ich schon an > anderer Stelle schrieb, ist mein Modell einfacher zu verstehen, da an dem > way getaggt wird, den es betrifft. also auf dem way der Straßenseite, die > es betrifft und nicht abstrakt am backward-attribut klebt, der noch von > der wayrichtugn abhängig ist und da noch die gefahr besteht, dass falsch > gedreht wurde udn zwischenzeitlich richtig nachgetaggt wurde und dann > wieder gedreht wird, weil man slebst aus versehen alles danach falschherum > eingetragen hat. Direkt am way der Straßenseite ist es halt einfach > einfacher. Und viel einfacher nachzuvollziehen - auch für nachfolgende > Mapper, da die visuelle Lage auf der Karte schon vieles klärt. > abwarten. kann sein, muss aber nicht. > email iust grausam. Ich mag Mailinglisten nicht besonders, auch wenn ich > mit UUCP-Newsgroups und 9600er Modem groß wurde. foren finde ich > praktischer, wenn gescheit moderiert und offtopics in eigene Threads > getrennt werden. Ausserdem sind Diskussionstränge leichter nochmal > durchzulesen, da es keine mehrfachabzweigungen gibt und man auch von > frühereren Postings nochmal zitieren kann. Aber das ist ja jetzt auch > offtopic. sorry. > das mit den Threads haengt rein von der Disziplin der User ab. Prinzipiell finde ich ML ein sehr gutes Medium fuer Diskussionen. Nur bei der Eroerterung von komplexeren Themen, die am besten grafisch visualisiert werden sollten, mag es vielleicht bessere Medien geben. Aber ja, wir schweifen ab... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Gemeindename taggen?
Hi Agustus, Augustus Kling schrieb: Pascal Neis gmail.com> writes: >> Hi, wird eine Gemeinde so richtig über eine Node getaggt: ... name:Mustergemeinde place:village ... Mir geht insbesondere um den place-Tag. Normal wird doch village eigentlich immer für ein "Dorf" unter 10k Einwohner verwendet. Gibt es für einen Gemeindenamen nicht auch ein anderes Tag?[…] Hallo Pascal, die Dörfer sollten mit place=village beschrieben werden. Größere Dörfer können als place=town beschrieben werden – wahrscheinlich wird man diese lokal als Stadt bezeichnen. Statt dem Knoten (Node), kannst du aber auch einen Polygon um das Dorf zeichnen. Gemeinden würde ich anhand der politischen Grenzen zeichnen, so sie dir grob bekannt sind. Hierzu solltest du die Gemeindefläche als Multipolygon mit folgenden Tags anlegen: type=multipolygon boundary=administrative admin_level=8 name=Mustergemeinde danke für die Antwort! Vielen Gemeinden sind in meiner Umgebung lediglich als Node mit name, place und weiteren Tags gemappt. Dabei verwenden sie immer das place=village Tag. Gibt es für die Abgrenzung innerhalb der Place-Nodes nicht für die Gemeinde eine andere Abstufung? Ich find's irgendwie nicht so richtig gut ... M.E. wäre ein expliziteres angeben eines Gemeindenames schon besser! viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Forum, Wiki, Tagging-Fragen WAS Re: natural=tree und village_green
Frederik Ramm [Fri, Jul 23, 2010 at 10:33:42PM CEST]: > Hallo, > > M∡rtin Koppenhoefer wrote: [...] > > >Ich finde es nicht besonders glücklich, dass die deutsche Community > >sowohl im Forum als auch auf Talk-de über Tagging-Fragen diskuttiert. > > Noch viel schlimmer finde ich die Tagging-Fragen-Diskussion im Wiki. > Da findest Du in aller Regel nochmal ganz andere Leute, die sich > weder auf der Mailingste noch im Forum und oft nicht mal auf > Stammtischen rumtreiben. > Und ist das auch ein mehr soziales als technisches Phänomen? Wegen der besseren Vernetzung der Informationen halte ich mich eher an das Wiki, sehe aber auch dort eher Dialoge versanden, bevor das eigentliche Problem gelöst wird. Am ehesten halte ich mich aber an die Vorgaben von JOSM :-} -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi") ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracktype an Nicht-tracks
auch ein hübsches treppchen - eventuell "nur" grade4? http://gis.638310.n2.nabble.com/file/n5353459/treppe_grade5.jpg - if it's there and you can see it, it's REAL if it's there and you can't see it, it's TRANSPARENT if it's not there and you can see it, it's VIRTUAL if it's not there and you can't see it, it's GONE Roy Wilks, 1983 -- View this message in context: http://gis.638310.n2.nabble.com/tracktype-an-Nicht-tracks-tp5352796p5353459.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
On Donnerstag, 29. Juli 2010 17:05 schrieb Christoph Matthei : >Grundsätzlich gebe ich Dir recht; man sollte auf keinen Fall >Multipolygone als Ersatz für Flächen ansehen. Ist es nicht so, dass Multipolygone die Flächendarstellung in OSM sind und area=yes und alle impliziten areas wie landuse früher zwar die einzigen Möglichkeiten waren aber jetzt eine Möglichkeit für einfache Fälle sind: "Relationen vom Typ Multipolygon werden zur Darstellung von allen möglichen Flächen verwendet. Die Multipolygon Relation ist OpenStreetMap's Datentyp für Flächen. Der Einfachheit halber können Flächen auch durch einen geschlossenen Weg versehen mit einem Tag, das eine Fläche nahelegt, dargestellt werden. Zum Beispiel wird ein geschlossener Weg mit dem Tag "landuse=forest" als Fläche interpretiert, nicht dagegen ein geschlossener Weg mit dem Tag "junction=roundabout". Dies ist jedoch nur bei einfachen Flächen möglich, deren Umriß aus einem einzigen Weg besteht und keine Löcher aufweist." Quelle: http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon Willi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Gemeindename taggen?
Pascal Neis gmail.com> writes: > > Hi, > wird eine Gemeinde so richtig über eine Node getaggt: > ... > name:Mustergemeinde > place:village > ... > > Mir geht insbesondere um den place-Tag. > Normal wird doch village eigentlich immer für > ein "Dorf" unter 10k Einwohner verwendet. > Gibt es für einen Gemeindenamen nicht auch > ein anderes Tag?[…] Hallo Pascal, die Dörfer sollten mit place=village beschrieben werden. Größere Dörfer können als place=town beschrieben werden – wahrscheinlich wird man diese lokal als Stadt bezeichnen. Statt dem Knoten (Node), kannst du aber auch einen Polygon um das Dorf zeichnen. Gemeinden würde ich anhand der politischen Grenzen zeichnen, so sie dir grob bekannt sind. Hierzu solltest du die Gemeindefläche als Multipolygon mit folgenden Tags anlegen: type=multipolygon boundary=administrative admin_level=8 name=Mustergemeinde Siehe hierzu auch http://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen Mit den Multipolygonen lassen sich auch Namen für Gemeinden angeben, die nicht als reale Orte existieren – wie beispielsweise Argenbühl. Grüße Augustus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Foosgis2010: Erläuterung zur GIS Sof tware
Lars Lingner wrote: >Meinst Du den Tagungsband? Dort sind (fast) alle Vorträge/Beiträge >enthalten. Aber das geht wohl nicht mehr als dünnes Heft durch... Na, wenn ich den nicht kennen würde, dann wäre wohl die gesamte Intention der Fossgis an mir vorbeigegangen. ;-) >Oder meinst Du die Flyer? >http://svn.osgeo.org/osgeo/marketing/flyer/project_brochure_pdfs/de/ > >Sonst fällt mir nur noch der GDI-DE Leitfaden ein: >http://www.gdi-de.de/de_neu/download/flyer_broschueren/Geodienste_Leitfaden_2Aufl.pdf > Vielen Dank! In der Broschüre, die ich meine, kam Postgis vor, in dieser jedoch nicht. Dennoch trifft Dein Link das in Frage stehende Thema auf den Kopf. Genial! :-) Wenn Du noch etwas in der Art kennst, dann gerne mehr. Muss natürlich nicht unbedingt auf der Fossgis präsent gewesen sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 29.07.2010 um 23:34 schrieb Guenther Meyer: > Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: >> Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die >> Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way >> wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, >> dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der >> Unsicherheitsfaktoren. >> > > einen Unsicherheitsfaktor hast du immer. > Nachher kommt ein Mapper, sieht deine drei ways und denkt sich "so ein > Schmarrn, das ist doch nur ein Strasse", und zerlegt dir das Ganze wieder... > ;-) Dafür gibts wikis und den Editro, der das ganze entsprechend rüberbringt. Note-tags gibts auch noch. Für die Umsetzung müssen natürlich alle an einem Strang ziehen. Abwärtskompatibilität bleibt ja dennoch erhalten. > Letztendlich bleibt es dann doch wieder am Frontend haengen. > Der User sollte nicht wissen muessen, ob er left, right, forward, backward > taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln > soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?utf-8?q?_forward/backward?=)
Am 29.07.2010 um 23:26 schrieb Guenther Meyer: > Am Donnerstag 29 Juli 2010, 21:09:47 schrieb Tobias Knerr: >> Am 29.07.2010 16:59, schrieb steffterra: >>> Am 28.07.2010 um 23:38 schrieb Tobias Knerr: Wenn ich zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben, >>> >>> welche Widersprü+che meinst du denn? forward-backward kann es ja nicht >>> sein, da diese attribute ja nicht mehr nötig sind. >> >> Wie du später selber sagst, so etwas wie >> maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. >> Nach der Vereinigung kann nur eines davon zutreffen, und welches das ist >> kann nur der Mapper entscheiden. >> > > Irgendwie komm ich da grad nicht mit: > Es gibt tatsaechlich ways, die uebereinanderliegen, und im selben Bereich > unterschiedliche (Geschwindigkeits-) Tags haben? > > Ansonsten wuerde ich unter Vereinigung eher sowas verstehen: > > aus dem: > > *--way1--*--way2--* > > soll das werden: > > *wayneu-* > > wenn die beiden ways unterschiedliche Geschwindigkeitstags in derselben > Richtung haben, dann kann das durchaus richtig sein. Eine Vereinigung ist > dann > sowieso nicht sinnvoll. +1 Es war aber sicher der Fall gemeint, dass einer der beiden tags falsch war, da man den node von woanders hergezogen hat und dann bei der Vereinigung entwscheiden muss, was jetzt stimmt. aber völlig irrelevant. denn das problem hat man jetzt auch und sollte leicht zu lösen sein. Keine Diskussiongrundlage, wie ich meine. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 29.07.2010 um 23:15 schrieb Guenther Meyer: > Am Mittwoch 28 Juli 2010, 15:23:35 schrieb steffterra: >> Am 28.07.2010 um 08:05 schrieb Guenther Meyer : >>> ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer >>> Fahrspurtagging >>> gab's schon mal ein Konzept, dass ohne separate ways auskommt... >>> Das ist also nichts neues. >> >> Die seperaten ways helfen hier aber auch bei dem Problem der >> richtungsanhängigen ways und eben nicht nur bei der Abbildung von >> Fahrspuren! >> >> Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke. >> > > nagel mich nicht drauf fest, aber ich glaub das war das hier: > http://www.mail-archive.com/talk-de@openstreetmap.org/msg59559.html Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich etwas übersehen? >> Das mag für Dich gelten, ich kenne hier aber keine Diskussion des >> letzten Monats, das es zu irgendeinem Konsens brachte. > an das wirst du dich bei OSM gewoehnen muessen ;-) Nein das meinte ich nicht. Iss schon klar ;-) Ich hatte aus Deinen Worten gelesen, dass alles geklärt sei und dass das tagging, wie es ist doch ausreicht. >> Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-) >> >> Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere >> denken schon. Aus diesem Grund entstand mein Engagement für dieses >> Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich >> geschildert. >> > > Fuer mich ist das Problem hausgemacht. Hat aber auch wieder mal mit > "gewachsener Struktur" zu tun: Nunja, Du klangst schon, als ob es kein Problem gäbe, oder schlimmer, dass der Karren so festgefahren ist, dass sich das für Dich somit erledigt hat und das aktuelle Tagging in Deinen Augen ausreichen _muss_. > wenn es nur darum geht, das "Richtungsproblem" zu loesen, finde ich deinen > Vorschlag absoluten Overkill. Nein ich führe ja auch andere Vorteile auf, wie z.b. die Möglichkeit der Fahrspuren-Nutzuzng für Navis, exaktere Abbildung von komplizierten Kreuzungen, etc. > Nichtsdestotrotz ist es ein interessantes Konzept, das denke ich, mehr > bringen > kann als die Losloesung von der Richtung. Das sehe ich auch so. Danke. >> Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich >> Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu >> erklären, dass doch alles in Butter ist. Mache bitte gerne >> _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine >> andere Möglichkeit. >> >> Aber bitte demotiviere nicht andere, neue, evtl. bessere >> Lösungsansätze zu verfolgen. >> > Dann hast du mich vielleicht falsch verstanden. Leute demotivieren ist das > letzte was ich vorhabe. Nur bin ich auch so realistisch, dass ich weiss, > dass es nicht so einfach ist, technisch durchdachte Dinge und vor allem > Veraenderungen dem OSM-Volk nahezubringen. Das beste Konzept nutzt nunmal > nichts, wenn es keiner benutzt... Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. > Ich habe uebrigens nie behauptet, das alles in Butter ist. Ganz im Gegenteil, > bei OSM gibt es jede Menge an Dingen, die verbessert werden koennten und auch > muessten. Nur ist mein Weg eher der, auf Basis des vorhandenen die einfachste > Loesung zu finden. Und ich denke, die gibt es fuer viele Dinge durchaus. Das finde ich auch, wenn das denn möglich ist. Wenn jetzt jemand ein völlig anderes Konzept hätte, das Relationen/Gruppierung oder ähnliches und gleichzeitig die richtungsabhängigen tags unnötig machen würde, wäre ich der erste, der es unterstützt und sein eigenes Modell fallen lässt. >>> Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache >>> Relation. Die automatische Erstellung durch den Editor aendert daran >>> genau >>> nichts. >> >> Woher weißt Du dass es nichts anderes ist? Wäre das technisch die >> Lösung, das gewollte so umzusetzen? >> > > Irgendwie musst du die Gruppierung ja in der Datenbank speichern. > Das naheliegendste ist da natuerlich eine einfache Relation. > Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu > taggen > (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? >> Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle >> _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ >> sinnvoll), die dieses Model bietet. >> > > wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? > da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm)
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?utf-8?q?_forward/backward?=)
Am 29.07.2010 23:16, schrieb Guenther Meyer: Am Mittwoch 28 Juli 2010, 20:12:50 schrieb M∡rtin Koppenhoefer: die Richtung dreht auch der Editor selbst automatisch alle Nas lang (JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts dran vorbei: die Richtung ändert sich (zumindest derzeit) oft. na dann wundert mich ja gar nix mehr... Stellt sich die Frage, warum macht er das, und muss das so sein? Das ist jetzt nicht dein Ernst, oder? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: > Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die > Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way > wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, > dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der > Unsicherheitsfaktoren. > einen Unsicherheitsfaktor hast du immer. Nachher kommt ein Mapper, sieht deine drei ways und denkt sich "so ein Schmarrn, das ist doch nur ein Strasse", und zerlegt dir das Ganze wieder... ;-) > > Eben: Die Fälle, wo der Mapper in deinem Modell bei Vereinigungen selber > > entscheiden muss, gibt es auch jetzt schon. Aber das gilt auch > > umgekehrt: Was in deinem Modell automatisch möglich wäre, ginge auch > > jetzt schon automatisch. > > Nein, da die unsicherheit besteht, dass der way zwischenzeitlich einmal aus > Versehen gedreht wurde und die JOSM-Warnmeldung mangels Kenntnis > missachtet wurde. Die Unsicherheit im generellen Umgang mit left/right und > forward/backward erlebt man ja schon, wenn man die Argumente hier > teilweise (nicht Deine) hier liest. Teilweise wurde nicht verstanden, dass > backward/forward nicht das gleiche wie links/rechts ist, etc... Das zeigt, > dasss das System im Grunde schon recht schwierig für manche ist. Dann > kommt noch die Komponente dazu, dass der way aus den verschiedensten > Gründen auch durch andere Editoren gedreht werden könnte, die keine > Warnung oder ein automatischen Drehen der Tags ermöglichen. Wenn man aber > einen way für jede Richtung einer Straße hat, dann passiert das erst gar > nicht. > Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?utf-8?q?_forward/backward?=)
Am Donnerstag 29 Juli 2010, 21:09:47 schrieb Tobias Knerr: > Am 29.07.2010 16:59, schrieb steffterra: > > Am 28.07.2010 um 23:38 schrieb Tobias Knerr: > >> Wenn ich > >> zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben, > > > > welche Widersprü+che meinst du denn? forward-backward kann es ja nicht > > sein, da diese attribute ja nicht mehr nötig sind. > > Wie du später selber sagst, so etwas wie > maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. > Nach der Vereinigung kann nur eines davon zutreffen, und welches das ist > kann nur der Mapper entscheiden. > Irgendwie komm ich da grad nicht mit: Es gibt tatsaechlich ways, die uebereinanderliegen, und im selben Bereich unterschiedliche (Geschwindigkeits-) Tags haben? Ansonsten wuerde ich unter Vereinigung eher sowas verstehen: aus dem: *--way1--*--way2--* soll das werden: *wayneu-* wenn die beiden ways unterschiedliche Geschwindigkeitstags in derselben Richtung haben, dann kann das durchaus richtig sein. Eine Vereinigung ist dann sowieso nicht sinnvoll. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?utf-8?q?_forward/backward?=)
Am Mittwoch 28 Juli 2010, 20:12:50 schrieb M∡rtin Koppenhoefer: > die Richtung dreht auch der Editor selbst automatisch alle Nas lang > (JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts > dran vorbei: die Richtung ändert sich (zumindest derzeit) oft. > na dann wundert mich ja gar nix mehr... Stellt sich die Frage, warum macht er das, und muss das so sein? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-15?q?_forward/backward?=)
Am 29.07.2010 um 21:09 schrieb Tobias Knerr: > Am 29.07.2010 16:59, schrieb steffterra: >> >> Am 28.07.2010 um 23:38 schrieb Tobias Knerr: >>> Wenn ich >>> zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben, >> >> welche Widersprü+che meinst du denn? forward-backward kann es ja nicht sein, >> da diese attribute ja nicht mehr nötig sind. > > Wie du später selber sagst, so etwas wie > maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. > Nach der Vereinigung kann nur eines davon zutreffen, Nein, es kann auch zutreffen, dass ab dem Verbindungsnode die neue Geschwindigkeit gilt. Aber es ist dann keine Unterscheidung mehr, zwischen zwei maxspeed:backward-Tags sondern zwischen zwei maxspeed-tags, bei denen klar ist, auf welcher Straßenseite es gitl. Beim backward-key weiss man das nicht, da der way ja falsch gedreht worden sein könnte. Letzteres gibt es aber nicht in meinem Gruppierungs-Modell. > und welches das ist > kann nur der Mapper entscheiden. Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. >>> Wenn die Tags *nicht* widersprüchlich sind, könnte das der Editor das >>> jetzt auch schon erledigen. (Beispiel wären zwei Ways mit >>> entgegengesetzter Richtung, einer mit maxspeed:forward=60 und einer mit >>> maxspeed:backward=60.) >> >> Ich glaube Du hast es wirklich falsch verstanden, oder das Eingangsposting >> nicht richtig gelesen. In der 3-letzten mail von mir standen auch 5 >> Beispiele, wie im Gruppierungs-Modfell getaggt wird. > > Nun, ich glaube, dass du *mich* falsch verstehst. ;-) Lies mein Posting > doch einfach mal unter der Annahme, dass ich dich im Großen und Ganzen > verstanden habe, und dass ich Formulierungen wie "jetzt auch schon" > bewusst verwende. :-) Habe ich. Ich versuche immer unvoreingenommen zu sein. Des weiteren bin ich durchaus fähig selbstkritisch mit meinem Modell umzugehen und wäre schon zufrieden, wenn ein anderer Vorschlag daraus entstünde, der die Problematik effektiver und schneller lösen könnte. Ich kämpfe ja hier nicht und schon gar nicht um jeden Preis mit einem Brett vor dem Kopf :-) > Ich rede im zitierten Absatz nämlich nicht über dein Modell, sondern das > aktuelle mit :forward/:backward-Suffix. Ich weiss :-) >>> Also: Vereinigungen erfordern nur bei widersprüchlichen Angaben an den >>> Teilen manuelle Eingriffe, und diese manuellen Eingriffe sind bei jedem >>> Modell notwendig. >> >> Bei diesem eben nicht, was ja einer der Vorteile ist. ;-) Widersprüchliche >> Angaben bei der Vereinigung von "Richtugnsways" aus meinem Modell könnten >> höchstens sein, dass die zu vereinenden Richtungsways unterschiedliche Werte >> ihrer Tags haben, Also z.b. maxspeed=50 und der andere maxspeed=60 (nochmal >> zur Erinnerung: beide auf der gleichen Seite der Straße). Dann kann man >> vereinigen, sollte aber überprüfen, was die Wirklichkeit sagt. Aber das gilt >> auch jetzt schon bei einem way, ohne richtungsabhängige Unterschiede. > > Eben: Die Fälle, wo der Mapper in deinem Modell bei Vereinigungen selber > entscheiden muss, gibt es auch jetzt schon. Aber das gilt auch > umgekehrt: Was in deinem Modell automatisch möglich wäre, ginge auch > jetzt schon automatisch. Nein, da die unsicherheit besteht, dass der way zwischenzeitlich einmal aus Versehen gedreht wurde und die JOSM-Warnmeldung mangels Kenntnis missachtet wurde. Die Unsicherheit im generellen Umgang mit left/right und forward/backward erlebt man ja schon, wenn man die Argumente hier teilweise (nicht Deine) hier liest. Teilweise wurde nicht verstanden, dass backward/forward nicht das gleiche wie links/rechts ist, etc... Das zeigt, dasss das System im Grunde schon recht schwierig für manche ist. Dann kommt noch die Komponente dazu, dass der way aus den verschiedensten Gründen auch durch andere Editoren gedreht werden könnte, die keine Warnung oder ein automatischen Drehen der Tags ermöglichen. Wenn man aber einen way für jede Richtung einer Straße hat, dann passiert das erst gar nicht. > Wenn du das anders siehst, nenne doch mal ein Beispiel, bei dem > Vereinigungen beim :forward/:backward-Modell zwangsläufig (also nicht > nur aufgrund von Unzulänglicheiten aktueller Editoren) einen manuellen > Eingriff erfordern, der durch dein Modell überflüssig würde. Alleine durch die Tatsache, dass durch die Lage der ways klar wird, welche Fahrbahnseite gemeint ist, werden viele Fehlerquellen ausgeschlossen. Ausserdem ist es eine natürlichere Abbildung der Wirklichkeit, als die Abstraktion durch die Tags, die auch noch von einem anderen Faktor (Richtung des ways ansich) abhängig sind, was sich zudem auch noch ändern kann. In meinem Modell ist der way da, wo er ist. Eindeutig durch die Koordinaten festge
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei forward/backward)
Am Mittwoch 28 Juli 2010, 15:23:35 schrieb steffterra: > Am 28.07.2010 um 08:05 schrieb Guenther Meyer : > > ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer > > Fahrspurtagging > > gab's schon mal ein Konzept, dass ohne separate ways auskommt... > > Das ist also nichts neues. > > Die seperaten ways helfen hier aber auch bei dem Problem der > richtungsanhängigen ways und eben nicht nur bei der Abbildung von > Fahrspuren! > > Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke. > nagel mich nicht drauf fest, aber ich glaub das war das hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg59559.html Generell hatte der qbert biker damals recht interessante Konzepte... > >> Latte an einem way, der dann ncoh die Gefahr birgt durch ein > >> einfaches > >> Drehen des way komplett über den Haufen geschmissen zu werden. Abe > >> r das > >> wurde auch alles schon einmal besprochen. > > > > die Drehproblematik ist wirklich hinreichend behandelt; ebenso dass > > es keines > > neuen Schemas bedarf, um *diese* in den Griff zu kriegen. > > Das mag für Dich gelten, ich kenne hier aber keine Diskussion des > letzten Monats, das es zu irgendeinem Konsens brachte. > an das wirst du dich bei OSM gewoehnen muessen ;-) Es gibt hier leider zu viele Leute, die alles und jeden kritisieren, aber auf den Versuch einer konstruktiven Diskussion nicht eingehen. > Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-) > > Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere > denken schon. Aus diesem Grund entstand mein Engagement für dieses > Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich > geschildert. > Fuer mich ist das Problem hausgemacht. Hat aber auch wieder mal mit "gewachsener Struktur" zu tun: Am Anfang gab es die Richtung des ways, die dann irgendwann zur Richtungsanzeige von Einbahnstrassen verwendet wurde. Die Moeglichkeit, diese im Editor zu drehen, mag da durchaus noch sinnvoll sein. Spaeter wurden dann alle moeglichen Tags drangehaengt, und schon gab es die ersten Probleme. Inzwischen koennen die Editoren das wohl besser handlen, aber das grundlegende Problem bleibt bestehen (ein Editor kann nicht immer jedes neue Tag kennen, das hier beruecksichtigt werden muesste). Deswegen mein Loesungsvorschlag: Lasst die grundlegende Richtung in Ruhe, diese bleibt die Referenz. Wenn ein Attribut gedreht werden muss, dann dreht das Attribut, und nicht die Referenz, an der noch andere Dinge dranhaengen. Das ist schnell und einfach machbar. Nehmt es an, oder auch nicht! Schlagt was besseres vor, oder auch nicht! Aber meckert nicht nur rum. sorry fuer den kurzen Ausfall, zurueck zum Thema: wenn es nur darum geht, das "Richtungsproblem" zu loesen, finde ich deinen Vorschlag absoluten Overkill. Nichtsdestotrotz ist es ein interessantes Konzept, das denke ich, mehr bringen kann als die Losloesung von der Richtung. > Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich > Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu > erklären, dass doch alles in Butter ist. Mache bitte gerne > _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine > andere Möglichkeit. > > Aber bitte demotiviere nicht andere, neue, evtl. bessere > Lösungsansätze zu verfolgen. > Dann hast du mich vielleicht falsch verstanden. Leute demotivieren ist das letzte was ich vorhabe. Nur bin ich auch so realistisch, dass ich weiss, dass es nicht so einfach ist, technisch durchdachte Dinge und vor allem Veraenderungen dem OSM-Volk nahezubringen. Das beste Konzept nutzt nunmal nichts, wenn es keiner benutzt... Ich habe uebrigens nie behauptet, das alles in Butter ist. Ganz im Gegenteil, bei OSM gibt es jede Menge an Dingen, die verbessert werden koennten und auch muessten. Nur ist mein Weg eher der, auf Basis des vorhandenen die einfachste Loesung zu finden. Und ich denke, die gibt es fuer viele Dinge durchaus. > > Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache > > Relation. Die automatische Erstellung durch den Editor aendert daran > > genau > > nichts. > > Woher weißt Du dass es nichts anderes ist? Wäre das technisch die > Lösung, das gewollte so umzusetzen? > Irgendwie musst du die Gruppierung ja in der Datenbank speichern. Das naheliegendste ist da natuerlich eine einfache Relation. Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen (wahrscheinlich sogar die bessere). > Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle > _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ > sinnvoll), die dieses Model bietet. > wie jetzt, dein Modell? da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf "meine" Weise zu relaisieren... > > Warum willst du was neues erfinden, wenn es genau das, was du > > brauchst, bereits gibt? > > Hmm d
[Talk-de] OSM-Redner fuer 4.10. in Goettingen gesucht
Hallo, am 4./5. Oktober sind an der Uni Goettingen die "Open-Access-Tage" (http://www.open-access.net/). Am 4. machen die einen Session unter dem Titel "Open Access und Open Content", und haetten da gern jemanden, der in einem kleinen Vortrag (ca. 30 min. inkl. Fragen) OSM vorstellt. Reisekosten koennen in begrenztem Umfang erstattet werden. Ich wuerde mich freuen, wenn jemand aus der Community Lust und Zeit haette, das zu uebernehmen. Wenn Ihr Euch bei mir meldet, stelle ich den Kontakt zu den Veranstaltern her. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie Gemeindename taggen?
Hi, wird eine Gemeinde so richtig über eine Node getaggt: ... name:Mustergemeinde place:village ... Mir geht insbesondere um den place-Tag. Normal wird doch village eigentlich immer für ein "Dorf" unter 10k Einwohner verwendet. Gibt es für einen Gemeindenamen nicht auch ein anderes Tag? Bei mir in der Umgebung sind aber alle Gemeindenamen mit village getaggt ... wie macht ihr das? danke&gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracktype an Nicht-tracks
Am 29.07.2010 21:36, schrieb Heiko Jacobs: Die footways mit tracktype dürften öfters eigentlich trampelpfad-paths sein? Wie kann man sich wohl highway=steps tracktype=grade5 vorstellen? ;) Es gibt zwar die Sac-Scales, aber denen fehlt die Abstufung zwischen "grade1-3". Was steps=grade5 ist? Das im Sommer: http://www.addicks.net/gallery/osm/DSCF8267 Nein, Treppenstufen, unbefestigt in den Hang gebuddelt gibt's öfters in Gegenden mit Lehmigem Boden. Das ist natürlich nicht für Publikumsverkehr, sondern eher "Zuweg zu Hochsitzen. u.Ä". Und bei dem Trampelpfad der mich letzte Woche von rechts kommend dort hochgeführt hat, überlege auch, ob das jetzt eher ein path mit sacscale=mountain_hiking war oder doch steps ;-) http://www.addicks.net/gallery/GeoCaching/DSCF9402_002 -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] tracktype an Nicht-tracks
Moin Da im Forum gerade die Frage "tracktype-Verwendung an highway=path" diskutiert wurde, hier mal eine kleine interessante Statistik: .ways track path foot cycle bridl servic residen steps unclas ford road grade1 179873 168996 1069 1058 1437 2 2107236163 2350 771 grade2 206410 199222 1817 1369 66627 1165111851572 2654 grade3 190677 185317 2412927 20275628 52586222 2919 grade4 127257 123000 26447636386213 15860 76 1811 grade5 96200 91805 32486503570 72 8037 34 26 8 Summe 768340 11190 4767 2403 260 41854242 297 3254 106 163 von 911076 238601 458375 81760 2639 398567 1159538 59142 200069 306 24043 in % 84% 5% 1%3% 10% 1% 0%1% 2% 35%1% 5 % sind nicht so unbedeutend, zumal wenn man berücksichtigt, dass von den paths etliche (1/5 ?) zum footway-/cycleway-Ersatz-Schema gehören dürften. Als reiner Pfad in Feld und Wald dürfte somit ein noch höherer Anteil mit tracktype ausgerüstet sein. Die footways mit tracktype dürften öfters eigentlich trampelpfad-paths sein? Wie kann man sich wohl highway=steps tracktype=grade5 vorstellen? ;) Wem die Proportionalschrift die Tabelle verhagelt: http://forum.openstreetmap.org/viewtopic.php?pid=92866#p92866 Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-15?q?_forward/backward?=)
Am 29.07.2010 16:59, schrieb steffterra: > > Am 28.07.2010 um 23:38 schrieb Tobias Knerr: >> Wenn ich >> zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben, > > welche Widersprü+che meinst du denn? forward-backward kann es ja nicht sein, > da diese attribute ja nicht mehr nötig sind. Wie du später selber sagst, so etwas wie maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. Nach der Vereinigung kann nur eines davon zutreffen, und welches das ist kann nur der Mapper entscheiden. >> Wenn die Tags *nicht* widersprüchlich sind, könnte das der Editor das >> jetzt auch schon erledigen. (Beispiel wären zwei Ways mit >> entgegengesetzter Richtung, einer mit maxspeed:forward=60 und einer mit >> maxspeed:backward=60.) > > Ich glaube Du hast es wirklich falsch verstanden, oder das Eingangsposting > nicht richtig gelesen. In der 3-letzten mail von mir standen auch 5 > Beispiele, wie im Gruppierungs-Modfell getaggt wird. Nun, ich glaube, dass du *mich* falsch verstehst. ;-) Lies mein Posting doch einfach mal unter der Annahme, dass ich dich im Großen und Ganzen verstanden habe, und dass ich Formulierungen wie "jetzt auch schon" bewusst verwende. Ich rede im zitierten Absatz nämlich nicht über dein Modell, sondern das aktuelle mit :forward/:backward-Suffix. >> Also: Vereinigungen erfordern nur bei widersprüchlichen Angaben an den >> Teilen manuelle Eingriffe, und diese manuellen Eingriffe sind bei jedem >> Modell notwendig. > > Bei diesem eben nicht, was ja einer der Vorteile ist. ;-) Widersprüchliche > Angaben bei der Vereinigung von "Richtugnsways" aus meinem Modell könnten > höchstens sein, dass die zu vereinenden Richtungsways unterschiedliche Werte > ihrer Tags haben, Also z.b. maxspeed=50 und der andere maxspeed=60 (nochmal > zur Erinnerung: beide auf der gleichen Seite der Straße). Dann kann man > vereinigen, sollte aber überprüfen, was die Wirklichkeit sagt. Aber das gilt > auch jetzt schon bei einem way, ohne richtungsabhängige Unterschiede. Eben: Die Fälle, wo der Mapper in deinem Modell bei Vereinigungen selber entscheiden muss, gibt es auch jetzt schon. Aber das gilt auch umgekehrt: Was in deinem Modell automatisch möglich wäre, ginge auch jetzt schon automatisch. Wenn du das anders siehst, nenne doch mal ein Beispiel, bei dem Vereinigungen beim :forward/:backward-Modell zwangsläufig (also nicht nur aufgrund von Unzulänglicheiten aktueller Editoren) einen manuellen Eingriff erfordern, der durch dein Modell überflüssig würde. Ich behaupte, es gibt keins. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] phpMyGPX v0.6.1 veröffentlicht
Hallo allerseits, ich habe eine neue Version meiner PHP/MySQL/OpenLayers-basierten Web-Anwendung zur Verwaltung und Darstellung gesammelter GPX-Dateien und Fotos veröffentlicht. Nachdem sich die vorherige Version 0.6 leider als recht fehlerbehaftet herausgestellt hat, hoffe ich, dass die neue 0.6.1 etwas besser ist. Die wichtigsten Neuerungen sind: 0.6.1 - Unterstützung von Zeitzonen mit passender Anzeige von Uhrzeiten - automatisches Geotagging von Fotos während Import anhand von GPX - viele Fehler behoben 0.6 - verbesserte Suchfunktion: Datum und Zeiträume für alle Elemente - einfache Sortierfunktionen für alle Tabellen - Tooltips mit Beschreibung und Dateiname an Links zu GPX-Details - beim Fotoimport ist zuzuordnende GPX-Datei einfach wählbar - Tabellen-Layout nun abhängig von Nutzer/Admin-Modus - neuer Kartenstil: Hike & Bike Map (Danke Colin!) - neues Overlay: Hillshading (auch von toolserver.org) - Geschwindigkeitsprofile für Tracks als Grafik - besseres Fehlerbehandlung beim Fotoimport Dank Jörg F. gibt es seit einiger Zeit auch eine deutsche Seite [2] im OSM-Wiki, sowie ein umfangreiche Anleitung (engl.) unter OpenSuse von Karl E. Anmerkungen, Kritik und Ergänzungen im Wiki sind natürlich willkommen :-) Viele Grüße, Sebastian [1] http://phpmygpx.tuxfamily.org/ [2] http://wiki.openstreetmap.org/wiki/DE:PhpMyGPX P.S.: Sind derartige Mitteilungen hier überhaupt erwünscht oder wird das eher als Spam angesehen? Es handelt sich ja nicht direkt um ein OSM-Tool, auch wenn die Motivation zur Entstehung ausschließlich durchs Mappen zustande kam... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V 3376
--- Original Nachricht --- Absender: André Riedel Datum: 28.07.2010 21:09 Am 28. Juli 2010 20:50 schrieb Steffen: Dann frage ich mal: Wie sind die Relationen dann zu taggen? [2] type=public_transport JOSM -> public_transport Im Oxomoa-Schema (http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema) wurde entschieden, dass ein type nicht notwendig wäre, da man so und so immer public_transport=* schreiben muss. Es ist aber nicht verkehrt, es zu verwenden. > Wo steht dies eingentlich ? Im Wiki hab ich das beim überfliegen nicht gefunden. Ich finde das unlogisch. Denn ein type-Tag würde ja angeben von welchem Typ eine Relation ist. Dies wäre dann in der Auswertung doch einfacher. Aber wenn dem so ist, werde ich aus meinen Relationen das type-Tag entfernen. Da sich JOSM zuerst das type-Tag anschaut und hier ein für das Programm unbekannter Wert verwendet wird, zeigt er nichts an. [3] public_transport=stop_area JOSM -> Öffentliche Verkehrsmittel Auf Grund des oben genannten Schemas korrekt interpretiert. wie ist dies zu erklären? [1] public_transport=stop_area JOSM -> Öffentliche Verkehrsmittel [2] type=public_transport & public_transport=stop_area JOSM -> public_transport André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-15?q?_forward/backward?=)
Am 28.07.2010 um 23:38 schrieb Tobias Knerr: > Am 28.07.2010 20:12, schrieb M∡rtin Koppenhoefer: >> die Richtung dreht auch der Editor selbst automatisch alle Nas lang >> (JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts >> dran vorbei: die Richtung ändert sich (zumindest derzeit) oft. > > Die Richtung ändert sich natürlich, aber das ist ja nur dann ein > Problem, wenn manuelle Eingriffe an den Tags nötig werden. Und inwiefern > verbessert so etwas wie der Gruppierungs-Vorschlag da etwas? In dem Modell (siehe Eingangsposting dieses Threads) werden die richtungsabhängigen Tags auf dem Richtungsway getaggt, aber ohne das left/right, forward/backward-attribut, da sich dieses ja aus der Lage des Richtungsways automatisch ergibt. > Wenn ich > zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben, welche Widersprü+che meinst du denn? forward-backward kann es ja nicht sein, da diese attribute ja nicht mehr nötig sind. Deshalb mache ich das ganze ja ;-) > muss mich der Editor ebenfalls fragen, was ich denn jetzt am > Vereinigungsresultat haben möchte. > > Wenn die Tags *nicht* widersprüchlich sind, könnte das der Editor das > jetzt auch schon erledigen. (Beispiel wären zwei Ways mit > entgegengesetzter Richtung, einer mit maxspeed:forward=60 und einer mit > maxspeed:backward=60.) Ich glaube Du hast es wirklich falsch verstanden, oder das Eingangsposting nicht richtig gelesen. In der 3-letzten mail von mir standen auch 5 Beispiele, wie im Gruppierungs-Modfell getaggt wird. > Also: Vereinigungen erfordern nur bei widersprüchlichen Angaben an den > Teilen manuelle Eingriffe, und diese manuellen Eingriffe sind bei jedem > Modell notwendig. Bei diesem eben nicht, was ja einer der Vorteile ist. ;-) Widersprüchliche Angaben bei der Vereinigung von "Richtugnsways" aus meinem Modell könnten höchstens sein, dass die zu vereinenden Richtungsways unterschiedliche Werte ihrer Tags haben, Also z.b. maxspeed=50 und der andere maxspeed=60 (nochmal zur Erinnerung: beide auf der gleichen Seite der Straße). Dann kann man vereinigen, sollte aber überprüfen, was die Wirklichkeit sagt. Aber das gilt auch jetzt schon bei einem way, ohne richtungsabhängige Unterschiede. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] NATO Truppenübungsplatz BERGEN - Aufm essen
Moin ! am Wochenende steht der Truppenübungsplatz "Bergen-Hohne" [1] für das Volksradfahren [2], [3] zur Verfügung. Eine Chance, die es nur einmal im Jahr gibt, um dieses Gelände legal aufzumessen. Gruß Jan :-) [1] http://www.openstreetmap.org/?lat=52.823&lon=9.817&zoom=11&layers=M [2] http://www.tourismus-bergen.de/veranstaltungen.php [3] http://www.kalender.oberes-oertzetal.de/grossbild.php?ID=2334 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnikstyle "Germanica"
Martin Simon wrote: > Gibt es nicht einen Minimalistischen Cascadenik-Stil, der einfach mit > diesem Standard-OSM-Setup (Datenbank mit osm2pgsql importiert, die > shapefiles, die der Standard-OSM-Mapnik auch benutzt etc...) > funktioniert? Schau mal die Styles von Collin Marquardt an: http://mapnik-utils.googlecode.com/svn/sandbox/cascadenik/hike_n_bike/ Sven -- "We just typed make" (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] svn probleme
ja genau. es geht mittlerweile auch wieder. strg-z ist auch ein kommando des editors, der dort verwendet wird... strg-o ist schreiben und strg-z verlassen. hm. strange. On Thu, 2010-07-29 at 14:56 +0200, Peter Körner wrote: > Am 29.07.2010 13:29, schrieb Gary G:: > > svn commit stopped > > das klingt nach einer Nachricht deiner Shell, über ein hin den > Hintergrund verschobenes Programm: > > peterkoer...@dedskwie44 ~ > $ sleep 10 > > (Strg+Z) > > [1]+ Stopped sleep 10 > > peterkoer...@dedskwie44 ~ > $ > > peterkoer...@dedskwie44 ~ > $ fg > sleep 10 > (Programm läuft weiter) > > > Lg, Peter > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
Am 27.07.2010 03:48, schrieb Willi: > Die inner sind doppelt getaggt mit natural=land und place=island. Beim > Orsasjön sind die Inseln gar nicht oder nur mit naturland=land markiert. Ich > bevorzuge place, da es island und islet gibt. natural und place kann und sollte auch ruhig gleichzeitig verwendet werden. Die Unterscheidung island und islet finde ich dagegen unnötig, da die Grenze fließend ist. Sinnvoller wäre es alle Inseln mit place=island zu taggen und die Unterscheidung, falls sie irgendwo nötig sein sollte, über die Inselfläche oder die Einwohnerzahl zu machen. Ich habe gesehen dass der outer-way über 1000 nodes hat. Auch wenn die Api glaube ich bis 2000 nodes handhaben kann, wäre es trotzdem sinnvoll diesen way aufzusplitten. Die Küstenlinie wird ja (hoffentlich) nach und nach immer weiter verfeinert und so wird es zwangsläufig dazu kommen. Vielleicht verursacht das ja die Probleme. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] svn probleme
Am 29.07.2010 13:29, schrieb Gary G:: svn commit stopped das klingt nach einer Nachricht deiner Shell, über ein hin den Hintergrund verschobenes Programm: peterkoer...@dedskwie44 ~ $ sleep 10 (Strg+Z) [1]+ Stopped sleep 10 peterkoer...@dedskwie44 ~ $ peterkoer...@dedskwie44 ~ $ fg sleep 10 (Programm läuft weiter) Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] seek in osm files III
habe es nun geschafft, die seek geschichte in osm.pm einzubauen. ist aber noch nicht im svn, weil probleme (siehe andere mail) benutzt man dann zum beispiel checkrelation.pl, was einige sprünge in den file scans durchführt, führt das zu einer geschwindigkeitssteigerung von 15% ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] svn probleme
hi, habe ein problem mit svn client unter ubuntu bzw. svn.openstreetmap.org wenn ich svn commit eingebe, kommt der editor für die log msg und danach dann ein "svn commit stopped" von der shell (bg job) - keine detailierte meldung! danach bestehen dann lokale locks, die mit svn cleanup gelöst werden müssen und das commit hat nicht funktioniert. jemand eine idee? ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Job fuer einen Bot: Hoehenangabe im Namen
>> Bei unzaehligen Berghuetten steht die Hoehe im Namen. >> http://www.openstreetmap.org/browse/node/477726059 >> name = Gehrenalpe (1354m) > nehme an, dass das Taggen für den Rednerer ist, da so die Höhenlöage der > Hütte wie in Wanderkarten üblich mit angezeigt wird: > http://b.tile.openstreetmap.org/18/138342/91687.png > Es könnte aber auch sein, dass die Höhenlage tatsächlich Teil des Namens ist, > wie man es evtl. an der Hütte selbst auch lesen könnte - falls dem häufig so > ist. >> Hier waere ein umtaggen nach ele=* gut: >> http://wiki.openstreetmap.org/wiki/Key:ele >> Wer kennt sich damit aus? > Schreib ihn doch bitter erstmal an, und weise ihn nett darauf hin, dass das > so nicht gedacht ist. Sicher war es nicht böse gemeint. Das hatte ich gleich als erstes gemacht und auch schon das ele=* Tag erklaert, nach dieser Antwort: "Ich finde die Höhenangabe bei Hütten und Bergen sinnvoll." Gibt es eine Festlegung das Hütten- und Bergnamen ohne Höhe erfolgen müssen?" Nun ist dieses Schema sehr weit verbreitet. Es waere also viel Arbeit die Huetten aufzuspueren und das haendisch umzuschreiben. Gruesse, -- Jonas Stein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Foosgis2010: Erläuterung zur GIS Softw are
Am 29.07.2010 09:22, schrieb Tirkon: > Moin, > > Auf dem Stand von OSM auf der Fossgis2010 lag ein einzelnes dünnes > Heft, in dem auf Deutsch eine Übersicht über Software rund um GIS > gegeben wurde. Ich konnte nur einen kurzen Blick hineinwerfen. Dabei > gewann ich den Eindruck, dass es auch für GIS-Laien relativ gut > verstehbar war, so dass man sich damit einen Überblick verschaffen > konnte. Aus Zeitmangel konnte ich mich nicht darin vertiefen und > später war das Heft verschwunden. > Meinst Du den Tagungsband? Dort sind (fast) alle Vorträge/Beiträge enthalten. Aber das geht wohl nicht mehr als dünnes Heft durch... Oder meinst Du die Flyer? http://svn.osgeo.org/osgeo/marketing/flyer/project_brochure_pdfs/de/ Sonst fällt mir nur noch der GDI-DE Leitfaden ein: http://www.gdi-de.de/de_neu/download/flyer_broschueren/Geodienste_Leitfaden_2Aufl.pdf Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
On 2010-07-27 16:45 M∡rtin Koppenhoefer wrote: > Am 27. Juli 2010 10:15 schrieb Christoph Matthei : >> Hallo, >> >> On 2010-07-27 03:48 Willi wrote: >> >>> beim Ansehen der Seen sind mir mögliche Fehlerquellen aufgefallen. >>> Da der outer-Ring an sich nichts darstellt, sollte er keine Tags haben. >>> natural=water gehört an das Multipolygon, da dieses die Wasserfläche (outer >>> minus alle inner) darstellt >>> (http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage). Dies ist >>> auch bei Orsasjön der Fall. >>> Die inner sind doppelt getaggt mit natural=land und place=island. Beim >>> Orsasjön sind die Inseln gar nicht oder nur mit naturland=land markiert. Ich >>> bevorzuge place, da es island und islet gibt. >> >> Danke, das werde ich mal versuchen. Abgesehen davon, hast Du mir >> allerdings den großen Erkenntnisgewinn in Sachen Multipolygon beschert. >> Und zwar dass ich ein Multipolygon auch benutzen sollte, um solche >> Sachen wie Stadtteile, Waldgebiete etc. (also Flächen, die häufig >> sowieso von Wegen begrenzt sind) einzutragen. Das spart zum einen Arbeit >> beim Erstellen und zum anderen vereinfacht es ja erheblich das spätere >> Bearbeiten. >> Man lernt nie aus. > > > es spart Zeit, führt im Endeffekt aber zu Ungenauigkeiten. Ich zeichne > die Wälder, landuses etc. so, dass sie an ihrer "echten" Grenze enden. > Dadurch führt man zum einen weiteres Detail ein (Grundstücksgrenzen an > der Straße im Falle von Landuse, bessere Flächentreue, etc.) und > achtet zum anderen mehr auf solche Dinge wie Lichtungen an der Straße, > die eine Ecke in den Wald machen, etc. Grundsätzlich gebe ich Dir recht; man sollte auf keinen Fall Multipolygone als Ersatz für Flächen ansehen. Trotzdem gibt es in meinem Wirkungsbereich zum einen sehr große Waldgebiete, die von langen (tweilweise kurvigen) Straßen oder Flüssen begrenzt werden, wo ich nicht die Fleißarbeit erledigen werde, parallel zu den Straßen zusätzlich einen Weg für die Landnutzung zusammenzuklicken. Die schiere Größe des Gebietes (die Fläche unserer Gemeinde beträgt ca. 1700 km², überwiegend Wald) und der Mangel an Luftbildern macht eine genauere Flächenabgrenzung unrealistisch. Zum anderen sehe ich es z.B. bei Stadtteilgrenzen schon als wahrheitsgemäß an, dass diese bis zur Straßenmitte reichen. Und wenn das mal nicht so ist kann man ja einen ansonsten tag-freien Weg in die Relation einfügen. Den anderen Vorteil von Multipolygonen bei Waldgebieten sehe ich in der Möglichkeit von Inseln - Siedlungen, Lichtungen, die mit dem normalen area-tagg ja m.W. nicht realisierbar sind. Gruß, Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V 3376
Am 29.07.10 09:50, schrieb André 'Ingrid' Joost:
Am 29.07.10 09:14, schrieb Georg Feddern:
Es muss die Relation ausgewählt sein, nicht deren Elemente.
Also (ggf. erst eine Relation anlegen und/oder) in der Relationsliste
doppelklicken - erst danach kann man die Relationseigenschaften im
Preset bearbeiten.
Aber nur, wenn man type=route bereits von Hand eingetragen hat!
Wer denkt sich denn sowas aus?
Wenn man eine neue Relation anlegt, bekommt diese nicht automatisch den
Fokus, Der ist nach wie vor bei dem Element, das man in die Relation
eingefügt hat (ohne ein Element kann man keine neue Relation anlegen).
Also muß man erst am Anfang der Relationsliste nach einer Relation
namens ("0", 1 Element) suchen, diese doppelklicken, und dann kann man
die Vorlage nutzen.
Gruß,
André Joost
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochgeladene Tracks auf Karte anzeigen
yzemaze wrote: >>> Wenn google jetzt noch OSM Tiles anzeigen würde ;-) >> >> Irgendwo hatte ich gelesen, dass Bing maps das bald anbieten will. >> Weiß jemand, wann das erfolgen soll? > >ist schon live, allerdings wird silverlight benötigt >http://www.bing.com/community/blogs/maps/archive/2010/07/12/bing-maps-adds-open-street-maps-layer.aspx Da bin ich wohl auf die Marktschreier reingefallen. Die Ankündigungen erweckten den Eindruck, dass OSM jedem standardmässig als Layer angeboten würde. So ist der Layer für mich auf Bing Maps auch nicht zu finden: http://www.bing.com/maps/?FORM=Z9LH2 Ist eigentlich die Mehrheit der Internet User so gestrickt, dass sie jeden Dreck abnickt, der installiert werden soll? Ich sehe schon kommen: Wenn auch Google nicht mehr an OSM vorbeikommt, gibt es das nicht ohne Chrome. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V 3376
Am 29.07.10 09:14, schrieb Georg Feddern: Moin, André Joost schrieb: Theoretisch gibt es ja in josm eine Vorlage für Relationen mit den Vorgaben Multipolygon, Abbiegerestriktion und Route. Nur irgendwie sagt er mir immer (Version 3329), die Auswahl wäre unpassend :-( ja, da habe ich bis gestern auch lange dran geknabbert, ist aber im Endeffekt eigentlich logisch: Es muss die Relation ausgewählt sein, nicht deren Elemente. Also (ggf. erst eine Relation anlegen und/oder) in der Relationsliste doppelklicken - erst danach kann man die Relationseigenschaften im Preset bearbeiten. Aber nur, wenn man type=route bereits von Hand eingetragen hat! Wer denkt sich denn sowas aus? Gut, also in der Routentyp-Combobox bitte noch ein "Freileitung" für power ergänzen, und die Starkstromabteilung ist zufrieden ;-) Für die Oxomoa-Fraktion müsste dann unter Vorlagen/Relationen noch ÖPNV-Linie für type=line ergänzt werden. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnikstyle "Germanica"
Am 24. Juli 2010 11:15 schrieb Jochen Topf : > Hab leider keine Ahnung vom Mapnik-Viewer. Kommt der vielleicht mit den > includes nicht zurecht? Oder brauchst Du eine neuere Mapnik-Version? Mapnik ist bei mir auf Version 0.7.1-1 (debian sid). Ich habe es jetzt mal mit generate_image.py versucht, das funktioniert auch mit dem Standard-Stil, aber wenn ich den von Cascadenik damit benutzen will, stößt mapnik auf Elemente, die ich in meinem Setup nach dem Wiki nicht habe. Gibt es nicht einen Minimalistischen Cascadenik-Stil, der einfach mit diesem Standard-OSM-Setup (Datenbank mit osm2pgsql importiert, die shapefiles, die der Standard-OSM-Mapnik auch benutzt etc...) funktioniert? Ich baue gerne den Stil von Grund auf neu, aber ich kriege im Moment absolut kein Bild davon, wie diese Dinge überhaupt zusammen hängen, weil leider mit Cascadenik nichts läuft (und ich zu dessen Format auch keine Dokumentation finden kann, die es mir erlaubt, so einen Stil von null an neue zu bauen). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Foosgis2010: Erläuterung zur GIS Sof tware
Moin, Auf dem Stand von OSM auf der Fossgis2010 lag ein einzelnes dünnes Heft, in dem auf Deutsch eine Übersicht über Software rund um GIS gegeben wurde. Ich konnte nur einen kurzen Blick hineinwerfen. Dabei gewann ich den Eindruck, dass es auch für GIS-Laien relativ gut verstehbar war, so dass man sich damit einen Überblick verschaffen konnte. Aus Zeitmangel konnte ich mich nicht darin vertiefen und später war das Heft verschwunden. Weiß jemand, um welches Heft es sich handelte? Wer ist der Herausgeber und ist das Heft möglicherweise auch im Internet als PDF oder Ähnliches vefrügbar. Falls der Text des Heftes unter einer freien Lizenz steht, wäre es als Einführung in die die Welt der GIS Software sicher auch hier im Wiki. Erst im Zuge der Vefolgung dieser Mailingliste wird mir erst heute klar, dass dieses Heft vieles von dem Technobabble hier in der Mailingliste verständlicher gemacht hätte, zu dem man auch im Internet und bei Wikipedia keine Antworten findet, da die entsprechenden Artikel von Experten für Experten geschrieben sind und zumeist nur das das "Was" aber nur selten das "Warum" erklären. Nebenbei bemerkt, ist das häufig auch im OSM-Wiki ein Problem. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V 3376
Moin, André Joost schrieb: Theoretisch gibt es ja in josm eine Vorlage für Relationen mit den Vorgaben Multipolygon, Abbiegerestriktion und Route. Nur irgendwie sagt er mir immer (Version 3329), die Auswahl wäre unpassend :-( ja, da habe ich bis gestern auch lange dran geknabbert, ist aber im Endeffekt eigentlich logisch: Es muss die Relation ausgewählt sein, nicht deren Elemente. Also (ggf. erst eine Relation anlegen und/oder) in der Relationsliste doppelklicken - erst danach kann man die Relationseigenschaften im Preset bearbeiten. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
