Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 20. September 2011 03:18 schrieb Christian Müller : > Dein Hinweis auf die Siedlungsgeographie kam als Antwort auf mein Bemühen, > Siedlungsflächengrenzen von administrativen Grenzen zu trennen. Wie bitte? Du hattest zu Beginn und für längere Zeit unbeirrt behauptet, Siedlungsgrenzen und administrative Grenzen seien dasselbe. Von trennen kann da keine Rede sein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
On Mon, Sep 19, 2011 at 11:54:15PM +0200, Henning Scholland wrote: > Das macht es aber nicht besser. Du verlangst von anderen, dass ein > Service der einmal angeboten wurde ewig bestehen bleibt, weil du diesen > Service anderen empfohlen hast und das kann in meinen Augen nicht sein. OK, vielleicht war die Wortwahl meiner Begründung suboptimal. Allerdings denke ich nicht, daß ich etwas verlangt habe, sondern ich habe eine Antwort auf die Bitte um Meinungen zum RA gegeben. Es ging darin unter anderem darum, ob der Service bestehen bleibt oder nicht. Der OP Adrian hat es nicht nötig gehabt, darauf unwirsch zu reagieren. Ich weiß jetzt nicht in welcher Eigenschaft Du Dich an der Diskussion beteiligst. >>> daraus nicht die Pflicht, sie über ewig und 3 Tage so weiter anzubieten. >>> Evtl. musst du deinen Bekannten andere Seiten empfehlen. Es ist ja nicht >>> so, dass es jetzt keine alternativen Lösungen gibt um eine Relation in >>> einen Track zu bringen oder auf einer Karte anzuzeigen. >> ... die da wären??? >> >> Also wie genau finde ich z.B. nur mit einem Browser ob es eine Relation >> "*Jakobsweg*" gibt, die durch Ravensburg führt. Das genau war mein >> Anwendungsfall. Und um hier gleich noch die Bemerkung von Frederik zu >> beantworten: Wenn Google sowas finden sollte (was ich jetzt absichtlich >> nicht probiert habe), dann ist das keinesfalls eine äquivalente Lösung >> zu der, die nunmehr verschwunden ist. Sie setzt voraus, daß eine >> Relation irgendwo mal auf einer Webseite erwähnt wurde, was nicht >> notwendig der Fall ist. Speziell ist das nicht der Fall bei kürzlich >> angelegten Relationen, die man per Google definitiv nicht kurz nach dem >> Anlegen finden kann. > http://hiking.lonvia.de/de/ Es mag sein, daß hier ein Proxy was rausfilter, aber wo genau finde ich dort bitte das Eingabefeld für den regulären Ausdruck "*Jakobsweg*"? Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Moin, Andreas Tille schrieb: On Mon, Sep 19, 2011 at 11:54:15PM +0200, Henning Scholland wrote: "*Jakobsweg*" gibt, die durch Ravensburg führt. Das genau war mein Anwendungsfall. http://hiking.lonvia.de/de/ Es mag sein, daß hier ein Proxy was rausfilter, aber wo genau finde ich dort bitte das Eingabefeld für den regulären Ausdruck "*Jakobsweg*"? Gleicher Anwendungsfall, aber anderes Tool ==> ggf. etwas andere Vorgehensweise. Du kannst Dir die Gegend anschauen, die Dich interessiert und über die Schaltfläche "Routes" wird eine Liste aller Routen (=Relationen) eingeblendet. (Diese Liste lässt sich dann übrigens ganz normal im Browser nach "Jakobsweg" durchsuchen.) Aber der Jakobsweg taucht als "kontinental" auch ganz oben auf. Falls nicht (wie hier im Stadtbereich von Ravensburg), ist er in der betrachteten Gegend halt (noch) nicht vorhanden. Dann ggf. weiter herauszoomen, bis er auftaucht. Bei Klick auf die jeweilige Route wird diese in der Karte markiert und es werden weitere Informationen/Möglichkeiten angezeigt. Dein Anwendungsfall ist damit zumindest abgedeckt. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Am 20.09.2011 10:27, schrieb Andreas Tille: On Mon, Sep 19, 2011 at 11:54:15PM +0200, Henning Scholland wrote: Also wie genau finde ich z.B. nur mit einem Browser ob es eine Relation "*Jakobsweg*" gibt, die durch Ravensburg führt. Das genau war mein Anwendungsfall. Und um hier gleich noch die Bemerkung von Frederik zu beantworten: Wenn Google sowas finden sollte (was ich jetzt absichtlich nicht probiert habe), dann ist das keinesfalls eine äquivalente Lösung zu der, die nunmehr verschwunden ist. Sie setzt voraus, daß eine Relation irgendwo mal auf einer Webseite erwähnt wurde, was nicht notwendig der Fall ist. Speziell ist das nicht der Fall bei kürzlich angelegten Relationen, die man per Google definitiv nicht kurz nach dem Anlegen finden kann. http://hiking.lonvia.de/de/ Es mag sein, daß hier ein Proxy was rausfilter, aber wo genau finde ich dort bitte das Eingabefeld für den regulären Ausdruck "*Jakobsweg*"? Moment: Du wolltest die Jakobswegrelation finden, die durch Regensburg verläuft. Von einem Eingabefeld war nicht die Rede. Beweg' dich in obiger Karte auf Regensburg und lass dir die Routen anzeigen, die vorhanden sind und wähle dir die passende raus. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Am 20.09.2011 10:27, schrieb Andreas Tille: On Mon, Sep 19, 2011 at 11:54:15PM +0200, Henning Scholland wrote: http://hiking.lonvia.de/de/ Es mag sein, daß hier ein Proxy was rausfilter, aber wo genau finde ich dort bitte das Eingabefeld für den regulären Ausdruck "*Jakobsweg*"? Wie man den Weg findet, wurde hier schon beschrieben. Es ist die Relation 38443 "Jakobsweg Ulm - Konstanz". Wenn du die als GPX-Track extrahierst, egal ob mit dem alten Relation Analyzer, mit meinem Tool rel2gpx.pl oder mit Josm, dann wirst du genau das bestätigt bekommen, was ich heute morgen schon geschrieben habe: - der Weg beginnt auf freiem Feld irgendwo zwischen Wiblingen und Unterweiler. - Es sind 16 isolierte Teilstrecken erfasst, zum Teil nur wenige Meter voneinander entfernt sind, aber auch zwei große Lücken von 10 und 45 km, - ein wohl nicht zum Jakobsweg gehörender Abzweig nördwestlich von Meckenbeuren und ein weiterer am westlichen Rand von Brochenzell. Die kleinen Lücken könnte ein Tool miteinander verbinden und in Josm gibt es dafür m.W. sogar ein Plugin. Aber das ist sicher nicht die Aufgabe eines Analyzers. Der soll Fehler aufzeigen und nicht selbständig Fehler ausbügeln. Solange solch prominente Wanderwege so miserabel erfasst sind, würde ich OSM keinem Außenstehenden als Quelle für GPX-Tracks empfehlen. Das schadet dem Projekt mehr als es nützt. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
On Tue, Sep 20, 2011 at 11:10:36AM +0200, Henning Scholland wrote: > Moment: Du wolltest die Jakobswegrelation finden, die durch Regensburg > verläuft. Von einem Eingabefeld war nicht die Rede. Beweg' dich in > obiger Karte auf Regensburg und lass dir die Routen anzeigen, die > vorhanden sind und wähle dir die passende raus. Also im Kontext mit dem Relation Analyser war es möglich, Relationen per regulärem Ausdruck zu suchen. Dort hätte ich "*Jakobsweg*" gesucht und mir dann die Relation herausgepickt, die in der Gegend verläuft, die ich suche. Ich bin sicher, daß es verschiedene Tools gibt, die auf die eine oder andere Art zum Ziel führen. Das Suchen nach regulären Ausdrücken im Namen einer Relation betrachte ich als praktische und wertvolle Eigenschaft, die mir an der Neuentwicklung fehlt und die ich sonst nirgends finde. Der neue RA ist ein Tool das Relationen analysiert, von denen man nun notwendigerweise die ID kennen muß. Früher gab es (im RA!) Methoden, um nach den zu analysierenden Relationen zu suchen. Ich habe das Fehlen dieser Suchfunktion (mit ganz offensichtlich total mißverständlichen Worten für die ich mich entschuldigen möchte) im Thread Relation Analyzer noch state of the art? bemängelt, weil ich glaube, daß das Fehlen eben nicht "state of the art" ist. Ich wäre total begeistert, wenn man mir Anspruchsdenken, fehlendes Wissen über andere Tools, etc. in einem gesonderten Thread mitteilen würde, weil ich befürchte, daß sich der OP nicht mehr durch so einen langen OT Thread wühlen möchte. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Hallo, am Rande moechte ich anmerken, dass "Regensburg" und "Ravensburg" zweierlei sind (Du sprachst anfangs von Ravensburg, andere lasen Regensburg), und dass "*Jakobsweg*" zwar ein regulaerer Ausdruck im allgemeinen Informatik-Sinn sein kann, dass die meisten Software-Entwickler diese Zeichenkette aber nicht als "regulaeren Ausdruck" bezeichnen wuerden (da "*" ueblicherweise "beliebig viel vom vorhergehenden Zeichen" bedeutet). Der neue RA ist ein Tool das Relationen analysiert, von denen man nun notwendigerweise die ID kennen muß. Früher gab es (im RA!) Methoden, um nach den zu analysierenden Relationen zu suchen. Hat der alte RA denn dazu eine eigene, lokale Relationendatenbank verwendet, oder hat er eventuell auf die XAPI zugegriffen? Falls naemlich letzteres, dann koennte das der Grund fuer den Wegfall des Such-Features sein. Zum Thema "Suchen mit Google" schriebst Du anderswo: Und um hier gleich noch die Bemerkung von Frederik zu beantworten: Wenn Google sowas finden sollte (was ich jetzt absichtlich nicht probiert habe), dann ist das keinesfalls eine äquivalente Lösung zu der, die nunmehr verschwunden ist. Sie setzt voraus, daß eine Relation irgendwo mal auf einer Webseite erwähnt wurde, was nicht notwendig der Fall ist. Dass Google nicht alles findet, ist sicher richtig, und dass ein gerade neu angelegtes Objekt nicht gefunden wird, auch. Aber Du solltest das nicht gleich abtun; auch OSM-Ways koennen grundsaetzlich von Google gecrawlt werden, und diese haben wiederum Links auf die Relationen, in denen sie enthalten sind und auf andere Ways, die am Ende anschliessen. Ueber kurz oder lang sollte also das gesamte Strassennetz sowie saemtliche Relationen, die mindestens eine Strasse nutzen, enthalten sein ;) Mit Google finde ich bei site:www.openstreetmap.org way jakobsweg ravensburg an 4. Stelle die Relation 38443, von der hier die Rede ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Am 20.09.2011 13:00, schrieb talk-de-requ...@openstreetmap.org: Am 11.09.2011 17:45, schrieb Uwe R. Kunzmann: * Warum ?ndern sich die Links zum Aufruf des Analyzers? Ich habe diesen beispielsweise in Webseiten eingebunden, um auch unbedarfte Leute an das Thema heranzuf?hren. Wenn diese Links jetzt einfach von heute auf morgen nicht mehr funktionieren, dann ist das nicht gerade ein Pluspunkt f?r OpenSource& die Community... Wie der Name schon sagt handelt es sich beim Analyzer um ein Analyse-Tool f?r den Mapper, mit dem die Vollst?ndigkeit und Konsistenz einer Relation gepr?ft werden kann. Die GPX-Tracks waren ein Nebenprodukt der Analyse und k?nnen f?r manche Mapper bei der Pflege von Relationen als zus?tzliche Unterst?tzung n?tzlich sein. Wer sie braucht, kann sie auch mit Josm erstellen. Hallo nochmal, schön, dass jetzt irgendwo gesagt wird, dass der Analyzer "nur" ein Analyse-Tool für Mapper ist - ich würde mich als solchen bezeichnen und habe nicht unerheblichen Aufwand in die Fertigstellung einiger Routen gesteckt. Nebenbei hab ich dann die Routen als KML extrahiert und stelle diese bei mir lokal als Service für meine Gäste zur Verfügung. Bekanntlich macht aber Information Hunger nach mehr - und daher, und weil ich OSM aufgrund der "öffentlichen" Bearbeitkeit als hervorragendes Werkzeug ansehe, habe ich natürlich auch den Link auf den Analyzer gesteckt - nachdem ich diesen dann nach vielem Suchen als sinnvolles und geeignetes Werkzeug erkannt habe. Besonders gut fand ich dabei nicht die Dastellung der Routen auf OSM, sondern die Möglichkeit, die auf OSM bearbeiteten Routen eben beispielsweise auf GoogleMaps direkt als KSM anzeigen zu können - das ist nun mal für den Otto-Normalverbraucher einfach eine bessere Darstellung, die eher "gewohnten" Karten entspricht, in welche dann *deutlich* markiert die Routen eingetragen sind. Über GoogleMaps habe ich dann übrigens für mich als "Mapper" auch nachgesehen, wo noch Lücken sind und diese geschlossen. Der Analyzer war aber nach meinem Verst?ndnis nie daf?r vorgesehen, alltagstaugliche GPX-Tracks f?r "unbedarfte Leute" zu produzieren. ...dafür habe ich ihn auch nicht genommen. Aber wie willst Du denn Interesse bei Leuten zur Mitarbeit finden, wenn diese sich auf allen möglichen Seiten (es gibt ja weisgott genug, gpsies, etcetera...) erst ma "durchwursteln" müssen?? Unter "alltagstauglich" verstehe ich dabei, dass ein (Rad-)Wanderweg als Track vorliegt, der unver?ndert in ein Outdoor-Navi geladen werden kann und mit der Track-Navigationsfunktion des Ger?ts nachgelaufen/gefahren werden kann. Das setzt voraus, dass der Track linear (Kreisverkehre!) und l?ckenlos ist und bei Radwanderwegen auch Einbahnstrecken ber?cksichtigt. Das sind Anforderungen, die f?r den Analyzer nicht relevant bzw. nicht essentiell sind. für mich erst mal auch nicht - zur Not kann man schieben. Ich hatte ja auch mal die Vision eines alltagstauglichen GPX-Export-Tools f?r unbedarfte Leute. Beim Versuch, ein solches Tool zu entwickeln, habe ich erkannt, dass die OSM-Datenbank auf absehbare Zeit nicht als Basis daf?r geeignet ist. Viele Routen sind nur l?ckenhaft erfasst. Bei anderen gibt es Abstecher, Varianten und Einbahnstrecken, die nicht als solche gekennzeichnet sind. Routen, die einmal komplett ohne Haken und ?sen erfasst waren, und f?r die alle mir bekannten Tools einen "alltagstauglichen" Track erzeugt haben, sind nach wenigen Monaten wieder "versaut", weil jemand versehentlich die Relationszugeh?rigkeit auf nicht zur Route geh?rige Wegsegmente ausgedehnt hat. ok, das bedeutet eben "Pflege". Aber bitte nicht immer wieder mit "neuen" tools - wobei ich gar nicht dagegen einwenden will, neue Dinge bereitzustellen. Allerdings scheinen etliche Leutchen die alte Version des Analyzers als "gut" eingestuft zu haben. Wäre es dann ein Problem, den "alten" Analyzer wieder zum Laufen zu bringen? Plattenplatz kann es nicht sein heutzutage, das Skript dürfte auch nicht so riesig sein - und sooo viel Rechenleistung wird das ganze wohl auch nicht benötigen. "Unbedarfte Leute" k?nnen mit GPX-Tracks solcher Routen nichts anfangen und bekommen nur einen negativen Eindruck von OSM. Hmmm.. hier wird mir eine andere Meinung gestattet sein. Jeder, der sich mit OSM auch nur kurz beschäftigt, wird wissen, dass hier tausende Leute mitarbeiten. Und das kann nun auch mal dazu führen, dass temporär etwas "nicht mehr so ganz in Ordnung" ist - aber das sollte ja dann auch wieder korrigiert werden - oder? Und wie soll das passieren, wenn man das nicht ab und an überprüft und sich einfach nur auf die Richtigkeit der daten verlässt? Dann haben wir immer mehr Datenmüll, weil immer mehr (fast) identische Routen auf immer mehr Servern abgelegt sind... Und ewig grüßt die Redundanz... Also - nochmal zusammengefasst: ich finde es schade, dass der "alte" Analyzer mit vielen guten Möglichkeiten nicht mehr erreichbar ist. Natürlich gibt es tausende andere Wege, um ans Ziel zu komm
Re: [Talk-de] Relation Analyzer noch state of the art?
ohhh - toll, offensichtlich hat sich entweder am neuen Analyzer noch was getan - oder ich war letzte Woche zu blind. Er ist fast wieder so gut wie der "alte". Zwei Anmerkungen: - vielleicht wuerde es Sinn machen, hinter dem kleine unscheinbaren Link "Home" noch das Wort "Suche" zu schreiben?? - das würde die Bedienung erleichtern. - eigentlich fehlt jetzt nur noch die Möglichkeit zum Export als GPX oder/und KML - und - als I-Tüpfelchen - die Anzeige auf GoogleMaps... :-) Gruss - uku69. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Merkwürdige Küstendarstellung
Hi ! kann mir einer sagen warum in http://www.openstreetmap.org/?lat=36.724384&lon=-3.578896&zoom=18 so eine Wassereinbuchtung ist und das Flussbet nicht gerendert wird ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
On Tue, Sep 20, 2011 at 01:46:36PM +0200, Frederik Ramm wrote: >am Rande moechte ich anmerken, dass "Regensburg" und "Ravensburg" > zweierlei sind (Du sprachst anfangs von Ravensburg, andere lasen > Regensburg), Die Verwechslung war mir nicht entgangen, ich hatte sie aber ignoriert, da es ohnehin nur um das Prinzip ging und jedes beliebige Beispiel hätte genommen werden können. > und dass "*Jakobsweg*" zwar ein regulaerer Ausdruck im > allgemeinen Informatik-Sinn sein kann, dass die meisten > Software-Entwickler diese Zeichenkette aber nicht als "regulaeren > Ausdruck" bezeichnen wuerden (da "*" ueblicherweise "beliebig viel vom > vorhergehenden Zeichen" bedeutet). Auch das ist richtig. Ehrlich gesagt, weiß ich auch gar nicht mehr, wie die richtige Syntax zum Suchen im RA war (und kann es nun auch nicht mehr nachvollziehen). > Hat der alte RA denn dazu eine eigene, lokale Relationendatenbank > verwendet, oder hat er eventuell auf die XAPI zugegriffen? Falls > naemlich letzteres, dann koennte das der Grund fuer den Wegfall des > Such-Features sein. Ich glaube, diese Frage wird Adrian beantworten müssen. Ich habe ihn mal in CC gesetzt, falls er den langen Thread nicht mehr verfolgen sollte. > Dass Google nicht alles findet, ist sicher richtig, und dass ein gerade > neu angelegtes Objekt nicht gefunden wird, auch. Aber Du solltest das > nicht gleich abtun; auch OSM-Ways koennen grundsaetzlich von Google > gecrawlt werden, und diese haben wiederum Links auf die Relationen, in > denen sie enthalten sind und auf andere Ways, die am Ende anschliessen. > Ueber kurz oder lang sollte also das gesamte Strassennetz sowie > saemtliche Relationen, die mindestens eine Strasse nutzen, enthalten sein > ;) Ahhh, richtig - sorry, das ich den Hinweis ignoriert habe! > Mit Google finde ich bei > > site:www.openstreetmap.org way jakobsweg ravensburg > > an 4. Stelle die Relation 38443, von der hier die Rede ist. site:www.openstreetmap.org/browse/relation jakobsweg ravensburg Kurz: Es gibt also eine Lösung, die zumindest hilfsweise das liefert, was mir im neuen RA besonders fehlt. Denoch möchte ich behaupten, daß zu einem "state of the art" Relation Analyzer eine wie auch immer geartete Suche nach den zu analysierenden Relationen dabei sein sollte. Wenn es dabei in der Tat technische Probleme geben sollte, die sich als "nicht in kurzer Zeit behebbar" herausstellen, wird Adrian das sicher darlegen können. Danke noch mal für die hilfreiche Erklärung Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 20.09.2011 10:22, schrieb Martin Koppenhoefer: Am 20. September 2011 03:18 schrieb Christian Müller: Dein Hinweis auf die Siedlungsgeographie kam als Antwort auf mein Bemühen, Siedlungsflächengrenzen von administrativen Grenzen zu trennen. Wie bitte? Du hattest zu Beginn und für längere Zeit unbeirrt behauptet, Siedlungsgrenzen und administrative Grenzen seien dasselbe. Von trennen kann da keine Rede sein. So ein Unfug! Ich habe genau einmal behauptet, dass Grenzen des Ortes (_Ortsgrenzen_ nicht Siedlungsgrenzen, wie Du es darstellst) administrative Grenzen seien und dass schon deshalb keine Notwendigkeit für ein place polygon besteht, weil admin. Grenzen durch "boundary" erfasst werden. Daraufhin hast Du argumentiert, dass es eine weitere Ortsgrenze im Kontext der Siedlungsfläche gibt, _ohne_ im Übrigen die Feststellung zu treffen, dass auch die Gemeindegrenze eine Grenze eines Ortes (Ortsgrenze), bzw. die Gemeindefläche eine Fläche des Ortes (Ortsfläche) ist. Am 07.09. 20:09 hast Du dazu festgehalten, dass es "[...] einen Unterschied zwischen administrierter Fläche (boundary=administrative) und Siedlungsfläche (place-polygon) [gibt], daher braucht man auch beide. Als best_practice würde ich vorschlagen, für places eine Relation zu machen und den place-node mit der Rolle settlement_centre dort mit der Place-Fläche zu verknüpfen." Dieser Unterscheidung habe ich _nie_ wiedersprochen. Stattdessen habe ich zwei wichtige Kernaussagen getroffen: * Siedlungsfläche != place-polygon (das ist nicht _dasselbe_, schon am 08.09. habe ich versucht, Dir das aufzuzeigen) * Die Siedlungsfläche ist implizit über entsprechende Flächennutzungen der Gemeindefläche erfasst. Beleg: http://www.mail-archive.com/talk-de@openstreetmap.org/msg87405.html Deine nächste Aktion war, die durch externe Quellen belegte Definition der 'Siedlungsfläche' anzufechten und zu behaupten, dass eine siedlungsgeographische Grenze existierte, die nicht automatisch aus anderen OSM-Daten ermittelbar wäre. Soweit so gut, ich habe angenommen, dass Du weißt wovon Du sprichst und daher die vermutlich richtige Feststellung getroffen, dass es mehrere Ortsgrenzen nach Sinn und Kontext in Bezug auf einen Ort geben kann. Das habe ich Dir mittlerweile manigfaltig dargelegt. Dennoch willst Du bis heute unbeirrt mittels /place/ eine bestimmte Ortsgrenze von vielen erfassen, eine die /Dir/ am wichtigsten erscheint. Du gewichtest völlig unzulässig, da es in der Tat, aber das ist rein spekulativ, sogar mehr Leute geben dürften, die die Gemeindegrenze als die wichtigste aller möglichen Grenzen eines Ortes (Ortsgrenzen) betrachten. Die Lösung des Problems ist, keine Grenzen und Flächen, die (nur) in Bezug zu einem Ort stehen, als Ort /place/ zu taggen. Schöne Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Merkwürdige Küstendarstellung
On Tuesday 20 September 2011 14:40:01 Jan Tappenbeck wrote: > Hi ! > > kann mir einer sagen warum in > http://www.openstreetmap.org/?lat=36.724384&lon=-3.578896&zoom=18 so > eine Wassereinbuchtung ist und das Flussbet nicht gerendert wird ? > > Gruß Jan :-) > Die Küstenlinie wird nicht sofort neu gerendert, wenn sie verändert wird. Das kann einige Tage oder sogar Wochen dauern. Grüße, bh 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] Merkwürdige Küstendarstellung
Am 20.09.2011 15:44, schrieb Bernhard R. Fischer: Die Küstenlinie wird nicht sofort neu gerendert, wenn sie verändert wird. Das ist mir neu, gibt es hierzu Quellen zum Nachlesen? MC ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Merkwürdige Küstendarstellung
Am 20.09.2011 15:44, schrieb Bernhard R. Fischer: On Tuesday 20 September 2011 14:40:01 Jan Tappenbeck wrote: Hi ! kann mir einer sagen warum in http://www.openstreetmap.org/?lat=36.724384&lon=-3.578896&zoom=18 so eine Wassereinbuchtung ist und das Flussbet nicht gerendert wird ? Gruß Jan :-) Die Küstenlinie wird nicht sofort neu gerendert, wenn sie verändert wird. Das kann einige Tage oder sogar Wochen dauern. Grüße, bh ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de hi ! ich meine diese NICHT geändert zu haben ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 20. September 2011 15:35 schrieb Christian Müller : > * Siedlungsfläche != place-polygon (das ist nicht _dasselbe_, schon am > 08.09. habe ich versucht, Dir das aufzuzeigen) > * Die Siedlungsfläche ist implizit über entsprechende Flächennutzungen > der Gemeindefläche erfasst. Siedlungsfläche, wie ich es gemeint habe (und wie ich gehofft hatte, dass es im Kontext verständlich sei, da ich das zig mal konsistent verwendet habe), betrifft die räumliche Ausdehnung der menschlichen Ansiedlung. > Deine nächste Aktion war, die durch externe Quellen belegte Definition der > 'Siedlungsfläche' anzufechten "Deine Siedlungsfläche" steht hingegen im Kontext Flächenverbrauch/Flächenversiegelung. Darum ging es mir nie, und wenn man das sinnvoll erheben wollte, müsste man möglichst feingranular die Oberflächenausbildung (versickerungsfähig oder nicht und bis zu welchem Grad) erfassen. Alternativ kann man auch einfach eine grobe Schätzung über die Flächennutzung anstellen. Interessiert mich aber höchstens am Rande. Es bringt nichts, Wörter aus ihrem Zusammenhang zu reissen, "wer googlet besser" zu spielen, und dann ohne den Kontext zu erkennen und die Informationen einzuordnen "externe Quellen" anzuführen, die ein anderes Thema behandeln, wo aber der Wortlaut vorkommt. > Die Lösung des Problems ist, keine Grenzen und Flächen, die (nur) in Bezug > zu einem Ort stehen, als Ort /place/ zu taggen. was soll das für eine Lösung sein? Ort=place, die Lösung ist, Orte als place zu taggen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Merkwürdige Küstendarstellung
On 20.09.2011 15:47, Martin Czarkowski wrote: Am 20.09.2011 15:44, schrieb Bernhard R. Fischer: Die Küstenlinie wird nicht sofort neu gerendert, wenn sie verändert wird. Das ist mir neu, gibt es hierzu Quellen zum Nachlesen? Wie so oft, das Wiki :) http://wiki.openstreetmap.org/wiki/Coastline Ciao Igor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Merkwürdige Küstendarstellung
Am 20.09.2011 15:51, schrieb Igor Podolskiy: Wie so oft, das Wiki :) http://wiki.openstreetmap.org/wiki/Coastline alles klar, thx MC ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Merkwürdige Küstendarstellung
Moin, Jan Tappenbeck schrieb: Am 20.09.2011 15:44, schrieb Bernhard R. Fischer: On Tuesday 20 September 2011 14:40:01 Jan Tappenbeck wrote: warum in http://www.openstreetmap.org/?lat=36.724384&lon=-3.578896&zoom=18 so eine Wassereinbuchtung ist und das Flussbet nicht gerendert wird ? Die Küstenlinie wird nicht sofort neu gerendert, wenn sie verändert wird. ich meine diese NICHT geändert zu haben ! hast Du auch nicht. Aber das Flussbett mit area = yes layer = -1 waterway = river als geschlossenen Weg würde ich nochmal überdenken: waterway=riverbank Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr.61
Hallo, die neue Wochennotiz Nr. 61 mit allen Neuigkeiten aus der OpenStreetMap-Welt ist da:http://blog.openstreetmap.de/2011/09/wochennotiz-nr-61/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Hi! Sorry, dass ich erst jetzt auf die Mails reagiere. War leider die ganze Woche weg. Vielen Dank für dein Feedback. "Harsche Kritik" ist besser als keine Kritik. Es ist sicherlich ärgerlich, dass durch den neuen Relation Analyzer erst einmal Funktionen verloren gegangen sind. Ich habe keine Möglichkeit mehr gesehen den alten RA weiter zu pflegen. Außerdem war der alte RA eher ein Relation Export Tool mit einer Analyzer-Funktion. Der alte RA hat einfach versucht aus jeder Relation eine durchgehende Linie zu bilden. Dies hat immer wieder zu Missverständnissen geführt, da viele User den RA zum Analysieren von komplexen Relationen genutzt haben und die Ergebnisse total falsch waren. Ich denke, dass der neue Ansatz aus einer Relation einen oder mehrere Graphen zu bilden deutlich mehr Potential hat. Mit dem neuen RA lassen sich beispielsweise Buslinien sehr gut prüfen. Dies war auch die Motivation hinter der neuen Version. Einen Parallelbetrieb von zwei Versionen halte ich nicht für sinnvoll, da dies zu ähnlichen Problemen wie mit der Lizenz führen könnte. Mein Vorschlag ist die neue Version weiter zu verbessern. Deshalb ist auch der Source Code verfügbar. Die Darstellung der Relationen auf einer Karte ließe sich sehr einfach realisieren. Der Code für den GPX Export ist bereits vorhanden. Bzgl. der Probleme mit der Suche bin ich etwas erstaunt. Ich bin davon ausgegangen, dass das neue Formular deutlich mehr Transparenz liefert, da der User genau angeben kann in welchen Tags er suchen will. Jakobsweg ist kein Problem: http://ra.osmsurround.org/searchRelation?name=%25Jakobsweg Auch über den Ref Tag: http://ra.osmsurround.org/searchRelation?ref=Jw Aus Performancegründen werden jedoch immer nur max. 100 Relations angezeigt. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
On Tue, Sep 20, 2011 at 02:34:17PM +0200, Uwe R. Kunzmann wrote: > ohhh - toll, offensichtlich hat sich entweder am neuen Analyzer noch was > getan - oder ich war letzte Woche zu blind. Er ist fast wieder so gut > wie der "alte". Wir mögen kollektiv blind gewesen sein. > Zwei Anmerkungen: > - vielleicht wuerde es Sinn machen, hinter dem kleine unscheinbaren Link > "Home" noch das Wort "Suche" zu schreiben?? - das würde die Bedienung > erleichtern. Jaaa, btte. Dann wäre die längliche Diskussion hier auch hinfällig gewesen. > - eigentlich fehlt jetzt nur noch die Möglichkeit zum Export als GPX > oder/und KML - und - als I-Tüpfelchen - die Anzeige auf GoogleMaps... :-) Das wäre in der Tat das I-Tüpfelchen, denn auch ich bin der Meinung, daß auch Mapper durchaus mit letzteren Arbeiten und es nicht notwendig nur zum "Feldeinsatz für Unbedarfte" benutzt werden dürfte. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
On Tue, Sep 20, 2011 at 06:58:12PM +0200, Adrian Stabiszewski wrote: > Einen Parallelbetrieb von > zwei Versionen halte ich nicht für sinnvoll, da dies zu ähnlichen Problemen > wie mit der Lizenz führen könnte. OK, das ist ein Argument (und mittlerweile will ja wohl auch keiner mehr so richtig den alten haben, da sich der neue ja offensichtlich dahin entwickelt, alle Wünsche zu erfüllen). > Mein Vorschlag ist die neue Version weiter zu verbessern. Deshalb ist auch > der Source Code verfügbar. Die Darstellung der Relationen auf einer Karte > ließe sich sehr einfach realisieren. Der Code für den GPX Export ist bereits > vorhanden. Sehr schon (sowohl die Codebereitstellung als auch der GPX-Export). > Bzgl. der Probleme mit der Suche bin ich etwas erstaunt. Ich bin davon > ausgegangen, dass das neue Formular deutlich mehr Transparenz liefert, da > der User genau angeben kann in welchen Tags er suchen will. Klar, die neue Suche ist viel besser. Ich hatte sie offensichtlich nur nicht gefunden (und war da scheinbar auch nicht der einzigste). Wie bereits erwähnt, könnte da noch etwas am Text / Layout verbessert werden. > Jakobsweg ist kein Problem: > > http://ra.osmsurround.org/searchRelation?name=%25Jakobsweg > > Auch über den Ref Tag: > http://ra.osmsurround.org/searchRelation?ref=Jw Alles sehr schön. Danke! > Aus Performancegründen werden jedoch immer nur max. 100 Relations angezeigt. Auch kein Problem. Die Suche fördert IMHO gleich auch noch ein zu behebendes Problem zu Tage: Da sollten wohl mal die eine oder andere Relation zusammengefaßt werden (muß man sich aber mal in Ruhe ansehen). Vielen Dank für das lieb gewonnene Tool Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
On Wed, Jul 20, 2011 at 01:19:03PM +0200, M∡rtin Koppenhoefer wrote: > > Wenn irgendwer derjenige ist, der das Privileg hat, seine Karte als > > Default auf osm.org dargestellt zu bekommen, dann muß er damit rechnen, > > daß es Leute gibt, die Fehler finden und den Wunsch äußern, daß sie > > korrigiert werden. Für sowas sollte eigentlich auch ein Bugtracking > > System her, in dem das Problem und die Diskussion dazu geloggt werden. > > Es ist ja soweit ich weiss grundsätzlich auch durchaus erwünscht, dass > man konstruktive Verbesserungsvorschläge ins trac einstellt. Die URL > ist > trac.openstreetmap.org --- für die Mapnik-Render-Regeln muss man als > Komponente "mapnik" auswählen. Was lange währt ... Nun habe ich erstmal das Ticket aufgemacht: http://trac.openstreetmap.org/ticket/4015 Danke für den Hinweis Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Offizieller Satz von OSM Diensten
Hallo, die Diskussion entzündete sich aktuell zwar am Relation Analyzer ist aber irgendwie ins generelle abgedriftet und daher würde ich mir gern einmal Klarheit verschaffen wollen. Ich halte es für förderlich, wenn im OSM Projekt ein stabiler Satz von Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM Projekt gehören und auf die man dann auch verweisen kann. Ich sehe das deshalb für notwendig an, weil meiner Meinung nach ein Großteil der Nutzer eine gewisse Konsistenz und Stabilität schätzt und bei ernst zu nehmenden Projekten erwartet (und IMHO auch erwarten darf). Zu diesen Werkzeugen würe ich natürlich in erster Linie einen Standard Renderer von Karten für das Web, einen Editor, eine Karte für GPS Geräte, aber auch solche Sachen wie den RA und weitere nützliche Tools zählen. Mir ist auch bewußt, daß es zu den oben genannten Dingen *immer* mehrere Lösungen gibt, und das das auch von vielen als Vorteil angesehen wird. Das wird z.B. an Diskussionen über Renderer[1] oder die diversen Threads über die AIO in diesem Jahr deutlich. Mir ist durchaus bekannt, daß es keine optimale "eine für alles Lösung" geben kann und daß es möglicherweise sogar mehrere Lösungen geben muß - doch dann sollten diese Lösungen auch einem bestimmten Satz von Qualitätskriterien genügen, der verläßlich auch durch diese Alternativen eingehalten wird. In meinen Augen sollten folgende Punkte Bestandteil dieser Qualitätskriterien sein: 1. Gehosted / downloadbar unter der Domain openstreetmap.org 2. Zugehörige Komponente auf http://trac.openstreetmap.org/ 3. Version Control System unter openstreetmap.org, damit sich ein Entwicklerteam bilden kann 4. Zugehörige Mailingliste unter openstreetmap.org In meinen Augen ist eine solche Formalisierung bei einem Projekt dieser Größe und Bedeutung (beides nimmt ja nach wie vor zu) dringend notwendig, um eine effektive Organisationsstruktur zu schaffen, die letztlich Entwicklern und Nutzern zu Gute kommt, Neulingen den Einstieg erleichtert und Kritikern die Argumente schwer werden läßt. Viele Grüße Andreas. [1] http://lists.openstreetmap.org/pipermail/talk-de/2011-July/087627.html ff -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Hallo,
Ich halte es für förderlich, wenn im OSM Projekt ein stabiler Satz von
Werkzeugen etabliert wird, die fest sozusagen "offiziell" zum OSM
Projekt gehören und auf die man dann auch verweisen kann.
Ja. Solche Dienste stellen allerdings eine hohe Belastung fuer das
Projekt dar, denn sie muessen dann ja auch am Laufen gehalten werden.
Hat man erstmal allen Leuten erzaehlt, dass man z.B. ein XAPI betreibt,
dann erwarten die Leute auch, dass das tut.
Dem einen oder anderen mag das verblueffend erscheinen, aber solche
Rechner warten sich auch nicht von allein. Mittlerweile hat OSM ja schon
einen gehoerigen Park zusammen, und ich kriege das manchmal mit, wenn
mal wieder abends ein Netzteil ausfaellt oder ein Rechner vom UCL zum IC
gefahren werden muss oder umgekehrt. Hardware muss gekauft, Prognosen
muessen gemacht werden, Logfiles ueberwacht, Beschwerden muss
nachgegangen werden und so weiter.
Deswegen werden solche Dienste, von denen das Projekt verspricht, dass
sie laufen, ganz bewusst auf eine moeglichst kleine Liste beschraenkt.
Dazu gehoert ganz oben natuerlich Lese- und Schreibzugriff fuer
Editoren, und gleich danach die Planet-Dumps und Diffs. Dann kommen
Webseite, Mailinglisten, Wiki, Forum, help.openstreetmap.org - die sind
wichtig, aber zugleich ist es da auch nicht schlimm, wenn sie mal ne
Stunde nicht tun, daher machen die weniger Stress. Dann kommt der
Tileserver; das ist schon ein Punkt, an dem es einige Stimmen gibt, die
sagen, dass man den Tileserver langfristig abschaffen sollte und
mittelfristig bereits seine Nutzung strenger einschraenken (d.h. zum
Beispiel keine kostenlosen Kacheln mehr fuer iPhone-Applikationen, deren
Autoren damit Geld verdienen).
Alles weitere - zum Beispiel OWL, oder Routing, oder Nominatim, oder
diverse Analyseprogramme oder OpenStreetBugs, der OSM-Inspector,
keepright, Relation Analyzer, Dupenode-Map, Garminkarten, taegliche
regionale Extrakte - sind nicht Teil von dem "stabilen Satz von
Werkzeugen", und das aus einem guten Grund - es waere naemlich zu viel
Arbeit, fuer diese Stabilitaet zu garantieren.
Selbst bei den Kern-Services gehen die Meinungen ueber Stabilitaet
auseinander. Wir sind ein Projekt von Hobbyisten, und wenn die API
irgendwann von 0.6 auf 0.7 umgestellt wird, dann wird sie ein paar Tage
nicht erreichbar sein. Ebenso kann es bei Umzuegen oder Wartungsarbeiten
auch mal sein, dass der Tileserver einen Tag nicht geht.
Es ist richtig, dass einige Leute "erwarten", dass sowas nicht passiert,
aber da muss man dann gegensteuern und die Erwartungen korrigieren; es
kann nicht angehen, dass man an unser freiwilliges und unbezahltes
Admin-Team in London Anforderungen stellt, als ob man mit denen einen
Wartungsvertrag abgeschlossen haette.
Zu diesen Werkzeugen würe ich natürlich in erster Linie einen Standard
Renderer von Karten für das Web, einen Editor, eine Karte für GPS
Geräte, aber auch solche Sachen wie den RA und weitere nützliche Tools
zählen.
Es ist wuenschenswert, dass es solche Dinge gibt, und dass wir ein
Oekosystem haben, in dem Leute sowas bauen koennen, aber Kern-Dienste
des Projekts koennen das nicht werden, oder wir muessen gleich mehrere
Programmierer und Admins bezahlen. Und das wiederum wuerde das
Anspruchsdenken nur noch erhoehen ("wir bezahlen diese Leute, die sollen
das gefaelligst mal ordentlich machen").
Ich bin heilfroh, dass es nicht "die offizielle Garminkarte" gibt, und
bei den Tile-Layern geht die Entwicklung zum Glueck auch weg von
"Mapnik-Standardkarte fuer alle". Sowas erstickt doch jede Innovation.
Mir ist durchaus bekannt, daß es keine optimale "eine für alles Lösung"
geben kann und daß es möglicherweise sogar mehrere Lösungen geben muß -
doch dann sollten diese Lösungen auch einem bestimmten Satz von
Qualitätskriterien genügen, der verläßlich auch durch diese Alternativen
eingehalten wird.
Beim Tile-Layer fuer die Startseite hat die OSMF ein paar
Qualitaetskriterien festgelegt und praktisch gesagt: Jeder, der einen
Layer baut, der diese Kriterien erfuellt, kann prinzipiell seinen Layer
auf der Startseite anbieten lassen. - Hosten und Rendern muss er
natuerlich selbst.
In meinen Augen ist eine solche Formalisierung bei einem Projekt dieser
Größe und Bedeutung (beides nimmt ja nach wie vor zu) dringend
notwendig, um eine effektive Organisationsstruktur zu schaffen, die
letztlich Entwicklern und Nutzern zu Gute kommt, Neulingen den Einstieg
erleichtert und Kritikern die Argumente schwer werden läßt.
Wir haben das mit dem FOSSGIS-Devserver ja probiert; es gibt da gute und
schlecht Erfahrungen. Der Plan war dort auch, dass man Leuten die
Ressourcen gibt, um ihre Sachen zu entwickeln und laufen zu lassen, und
dass durch gegenseitige Offenheit auch eine Zusammenarbeit entsteht.
Leider hat sich gezeigt, dass es fuer viele eben doch reizvoller ist,
was eigenes zu machen, als bei einem bestehenden Projekt mitzuarbeiten.
Diese Neuerfindung des Rads ist d
Re: [Talk-de] Offizieller Satz von OSM Diensten
On Tue, Sep 20, 2011 at 10:28:23PM +0200, Frederik Ramm wrote:
>
> Es ist richtig, dass einige Leute "erwarten", dass sowas nicht passiert,
> aber da muss man dann gegensteuern und die Erwartungen korrigieren; es
> kann nicht angehen, dass man an unser freiwilliges und unbezahltes
> Admin-Team in London Anforderungen stellt, als ob man mit denen einen
> Wartungsvertrag abgeschlossen haette.
Das ist klar.
>> Zu diesen Werkzeugen würe ich natürlich in erster Linie einen Standard
>> Renderer von Karten für das Web, einen Editor, eine Karte für GPS
>> Geräte, aber auch solche Sachen wie den RA und weitere nützliche Tools
>> zählen.
>
> Es ist wuenschenswert, dass es solche Dinge gibt, und dass wir ein
> Oekosystem haben, in dem Leute sowas bauen koennen, aber Kern-Dienste
> des Projekts koennen das nicht werden, oder wir muessen gleich mehrere
> Programmierer und Admins bezahlen.
Ich bin unsicher, ob das bezahlen notwendig ist. Die Leute ansich sind
ja bereits da und tuen offensichtlich gute und nützliche Dinge. Was
meiner Meinung nach fehlt ist eine effektivere Organisationsstruktur.
> Ich bin heilfroh, dass es nicht "die offizielle Garminkarte" gibt, und
> bei den Tile-Layern geht die Entwicklung zum Glueck auch weg von
> "Mapnik-Standardkarte fuer alle". Sowas erstickt doch jede Innovation.
Das sehe ich anders, kann meinen Standpunkt aber zugegebenermaßen nicht
beweisen.
> Wir haben das mit dem FOSSGIS-Devserver ja probiert; es gibt da gute und
> schlecht Erfahrungen. Der Plan war dort auch, dass man Leuten die
> Ressourcen gibt, um ihre Sachen zu entwickeln und laufen zu lassen, und
> dass durch gegenseitige Offenheit auch eine Zusammenarbeit entsteht.
> Leider hat sich gezeigt, dass es fuer viele eben doch reizvoller ist,
> was eigenes zu machen, als bei einem bestehenden Projekt mitzuarbeiten.
Das "Leider" im letzten Satz nehme ich mal als teilweise/schwache
Zustimmung zu dem von mir gesagten.
> Diese Neuerfindung des Rads ist durchaus nicht immer schlecht und kann
> dazu fuehren, dass radikale neue Ideen sich durchsetzen - wenn man die
> Leute zwingt, alle am gleichen Seil zu ziehen, dann laufen einem die
> wirklichen Genies vielleicht auch davon ;-)
Von Zwang würde ich nicht sprechen wollen. Es hat sich an vielen
Stellen als sinnvoll erwiesen, Standards festzulegen und effektiv
verhindern kann und will ich nicht, daß das Rad hin und wieder neu
erfunden wird. Es gilt allerdings zu vermeiden, daß es auf Grund einer
mangelhaften Struktur beinahe zwangsläufig geschieht, daß das Rad
ständig neu erfunden wird.
> Wenn wir etwas nicht selbst auf die Beine stellen koennen, besteht kein
> berechtigter Grund zu der Annahme, dass es dann erfolgversprechend ist,
> zu verlangen, "irgendjemand" ("das Projekt", "die OSMF") solle das
> machen. Wir sind das Projekt. Entweder machen wir das oder keiner.
Vollkommen klar. Ich kenne solche Mechanismen aus dem Debian Projekt,
das sich als Do-O-Cracy bezeichnet, sehr gut.
> Es gibt immer mal wieder Sponsor-Angebote, die im Sande verlaufen, weil
> sich niemand drum kuemmert oder weil halt irgendein kleiner Server mit 8
> GB in einem Rechenzentrum in Russland niemanden interessiert. Ein erster
> Anfang koennte sein, dass sich jemand mal den Hut aufsetzt, dass er
> diese Sponsor-Angebote registriert und auf der anderen Seite Anfragen
> von Leuten entgegennimmt, die gern einen Service anbieten wuerden.
> Eventuell kann daraus auch eine groessere "Plattform" werden, eventuell
> kann auch einer sagen "ich bin bereit, einen Server zu administrieren,
> auf dem jemand anders einen OSM-Dienst installiert" oder so. Damit
> koennte man die weit verbreitete Eigenbroetlerei vielleicht ein bisschen
> aufbrechen und den Leuten mit guten Ideen ueber die Anfangshuerden
> hinweghelfen.
Soetwas in der Art schwebte mir vor.
> Aber mehr als eine Katalysator-Funktion ist m.E. zentral nicht drin.
Das wäre aber schon mal was.
> Wer
> "verlaessliche" Angebote braucht, der kann die nicht bei einem
> Hobbyprojekt suchen.
Ich bin mir nicht sicher, ob die Bezeichnung "Hobbyprojekt" noch korrekt
ist. Bei Debian gibt es auch keine fest Angestellten und dennoch würde
ich nicht die Bezeichnung Hobbyprojekt wählen. OSM scheint mir eher mit
WikiPedia vergleichbar zu sein, auch das ist kein Hobbyprojekt mehr (gut
hier werden wohl auch einige Leute für Ihre Arbeit daran bezahlt). Die
Frage ist, von welchem Standpunkt aus OSM als Hobbyprojekt oder eben
nicht klassifiziert wird. Aus Nutzersicht ist es das schon nicht mehr,
denn es wird durchaus zu professionellen Zwecken eingesetzt. Ich glaube
beobachtet zu haben, daß bei Freien Projekten die Zunahme an Code /
Daten über einen bestimmten Punkt hinaus zu einer neuen Qualität in der
Organisation führt und IMHO auch führen muß. Dem gilt es in geeigneter
Weise Rechnung zu tragen - auch wenn ich hier die genaue Weise schuldig
bleiben muß, was das vorher gesagte zugegebenermaß
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 19.09.2011 20:16, schrieb Martin Koppenhoefer: Am 19. September 2011 19:34 schrieb Christian Müller: Am 16.09.2011 11:16, schrieb Martin Koppenhoefer: Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch errechnen, weil die Informationen dazu fehlen. Bei den landuses - so man sie alle erfasst hat - sind die benötigten Informationen hingegen vorhanden. Daher geht es da. -1 Das ist, sorry, absoluter Unfug. /Erstens/ sind die benötigten Informationen für die Siedlungsstellen existent, wenn landuses komplett erfasst sind. Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_ menschlichen Siedlung sie gehören. Das ist das Problem, nicht, ob sie besiedelt sind. Natürlich ist das klar - anhand der Gemeinde, bzw. Gemarkungsgrenze, innerhalb derer die landuses liegen. Im allgemeinen umfassen politische Grenzen einer Gemeinde einen größeren Bereich, mindestens aber den Bereich der Siedlung. Selbst wenn eine politische Grenze aktuell nicht mehr zu finden ist, wird es eine historische geben, die für die Ermittlung benutzt werden kann. Die Information einer Siedlungsflächengrenze ist damit klar redundant [[denn es gibt Regeln, mittels derer sie sich ausrechnen lässt]]. Ich vertrete aber die Auffassung, dass diese Regeln nicht außerhalb der DB stehen sollten. Schließlich ist sie über eine Relation innerhalb OSM effizient pro Fall abbildbar. In gewisser Weise steckt Redundanz dann nur dadurch in der DB, dass die Regel mehrmals angewandt wird. Das hat aber eben auch den Vorteil, dass Ausnahmen ohne weiteres abbildbar sind. Bisher standen dazu in unserer Debatte zwei Realisierungen zur Auswahl: a) Erfassung über (wiederbenutzte) Flächengrenzen b) Erfassung über Sammelrelation aller Teilflächen der Siedlungsfläche. b) hat klare Nachteile gegenüber a), siehe Datenhaltungsmail. Das ist alles nur Wiederholung, siehe frühere mails.. /Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll auf ein Netz grobgranularer Flächen schließen. So kompliziert ist das nicht. Du lehnst Dich hier viel zu weit aus dem Fenster. /Wie/ kompliziert das werden kann, überblickst Du gar nicht. Ich überblicke das auch nicht, behaupte aber auch nicht, dass ich das könnte. Der immense Vorteil ist aber dabei, dass alle Informationen vorliegen und ich selbst entscheide, was für mich unwesentlich ist, und was nicht. Ich lese nur /ich/ in deinen Sätzen. So funktioniert OSM nicht. Um /als Datennutzer/ entscheiden zu können, was für mich wesentlich ist, muss ich aus einem Angebot /wählen/ können. /Du/ bist hier gerade derjenige der einem dieses Angebot vorschreiben will, weil /Du/ der Meinung bist, dass ein Salat aus MICROgemappten Flächen ausreiche, um sich alle erdenklichen gröberen Fälle auszurechnen. Umgekehrt muss ich /als Mapper/ /wählen/ können, auf welcher Ebene ich Informationen zum Projekt hinzufüge. Nicht jeder hat die Muse, deinen Vorstellungen von Größen, die "nicht weiter teilbar" sind, nachzukommen. Solche Leute dürfen dann keine Flächennutzung mehr erfassen, oder wie? Und der nächste MICROmapper, der kommt, und das Gebiet der Forstwirtschaft dann "parzelliert" zerstört die Arbeit des MACROmappers - weil eben das Gebiet der Forstwirtschaft _nicht_ notwendigerweise, wie Du schreibst, aus Mini-Parzellen zusammensetzbar ist. Ich bin der Meinung, dass Du immer noch nicht durchdacht hast, welche wirklichen Konsequenzen deine Streichung von "überwiegend" aus der Definition zur Flächennutzung hat. Nochmal, wenn Du die "reine" statt überwiegende Flächennutzung erfasst, heißt das für Dich und alle, die Du damit begeistern willst: a) Erfassung aller erdenklichen Flächennutzungen einer Fläche b) Unterteilung der vorhandenen Fläche in kleinste Einheiten, die eine __eindeutige__ Erfassung der Flächennutzung ermöglichen Ich bitte Dich nochmals, mitzudenken: Eine Fläche beliebiger Größe kann _immer_ nochmal geteilt werden, um die Flächennutzung genauer zu erfassen: Selbst für einen Acker funktioniert das: linienschmale Flächen werden z.B. als Furche des Ackers genutzt. Bist Du allen Ernstes der Aufassung, dass aus diesen kleinsten, MICROgemappten landuses, sich _jeder_ diese gröberen Gebiete aus einem komplexen Regelset "zusammenbauen" will? Die Regel für den Acker wäre dann: Gruppiere alle Furchen, um das Gebiet des Ackers zu erhalten. (Total einfach! Da braucht man doch die überweigende Nutzung der Gesamtfläche als Acker gar nicht erfassen..) Ganze Softwareprojekte würden sich dann damit beschäftigen, Regelwerke zu pflegen, weil /Du/ der Auffassung warst, dass die Gruppierung feingranularer Strukturen in "gröbere" ja ein Kinderspiel sei (es aber schon für die Berechnung der Siedlungsflächengrenze verneinst!). Es geht nämlich nicht nur um die Flächengröße sondern auch um die Art der Nutzung. Eine kleine abe
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 20.09.2011 15:50, schrieb Martin Koppenhoefer: Am 20. September 2011 15:35 schrieb Christian Müller: * Siedlungsfläche != place-polygon (das ist nicht _dasselbe_, schon am 08.09. habe ich versucht, Dir das aufzuzeigen) * Die Siedlungsfläche ist implizit über entsprechende Flächennutzungen der Gemeindefläche erfasst. Siedlungsfläche, wie ich es gemeint habe (und wie ich gehofft hatte, dass es im Kontext verständlich sei, da ich das zig mal konsistent verwendet habe), betrifft die räumliche Ausdehnung der menschlichen Ansiedlung. Ja, von mir aus - und selbst dann ist es nur _eine_ weitere Fläche des Ortes unter vielen. Darum geht es vorrangig. Deine nächste Aktion war, die durch externe Quellen belegte Definition der 'Siedlungsfläche' anzufechten "Deine Siedlungsfläche" steht hingegen im Kontext Flächenverbrauch/Flächenversiegelung. Darum ging es mir nie, und wenn man das sinnvoll erheben wollte, müsste man möglichst feingranular die Oberflächenausbildung (versickerungsfähig oder nicht und bis zu welchem Grad) erfassen. Alternativ kann man auch einfach eine grobe Schätzung über die Flächennutzung anstellen. Interessiert mich aber höchstens am Rande. Es bringt nichts, Wörter aus ihrem Zusammenhang zu reissen, "wer googlet besser" zu spielen, und dann ohne den Kontext zu erkennen und die Informationen einzuordnen "externe Quellen" anzuführen, die ein anderes Thema behandeln, wo aber der Wortlaut vorkommt. Wieso? Das haben wir doch bis jetzt sehr erfolgreich gespielt. Ich finde, wir sind, seitdem Du mit der Toponamastik damit begonnen hast ;-), recht weit gekommen. Du kannst das, was Du dabei gelernt hast, nun verleugnen oder annehmen. Davon abgesehen bringt es auch nichts, wenn Du Wörter aus allen anderen Kontexten reißt, und für deinen Kontext allein beanspruchst.. Wir sind an einem Punkt, wo wir beide den Fakt anerkennen können, dass _viele_ Flächen des Ortes, je nach Sinn und Kontext, definiert werden können. Dabei gibt es keine Fläche, die irgendeinen Vorrang gegenüber anderen hat. Es macht also keinen Sinn, _eine_ dieser vielen Ortsflächen, als /DIE/ Ortsfläche zu küren, welche das Prädikat "place" verdient. Ich habe /dein/ Verständnis einer Siedlung nie grundsätzlich anfechten wollen. Mir geht es nur darum, dass durch die Tags, die Du verwendest, für _alle_ verständlich bleibt, was damit gemeint ist und zwar ohne erst einen Monat lang Diskussionen führen zu müssen. Allg. Tag-Bedeutungen, die OSM im Kern braucht, können nicht von einer Person, oder einem Kreis von Personen "gehijackt" werden, welche das Tag dann in einen speziellen Kontext führen. /place/ war in OSM immer _viel_ mehr als nur ein key mit welchem settlements erfasst werden. Wenn Du (und andere) Siedlungsgrenzen erfassen wollen/müssen, dann bitte unter neuem, aussagekräftigem Tag. Besetze boundary=settlement oder ähnliches, aber nicht place.. Die Siedlungsgrenzen, ob nach /deiner/ Definition oder nicht, sind für OSM nützliche Daten, schonmal allein, weil sie Dich interessieren. Aber bitte mit aussagekräftigem Tag. Du tust Dir als Spezialist auch selbst keinen Gefallen, wenn Du deine Vorstellung einer settlement border als place-polygon abbildest - denn place-polygons kann es auch zu place-nodes geben, die mit settlements überhaupt nichts zu tun haben. Ich muss also schonmal nach key /place/ _und_ value /city,village,etc./ filtern, und weiß dann immer noch nicht, ob alle Mapper (nur) die settlement border mit place gemappt haben oder nicht doch irgendeine andere, der zahlreichen Ortsgrenzen. Ein aussagekräftiges Tag hält Dir (und allen anderen, die auch noch so auf der Welt sind), all diese Probleme vom Leib. Du und jeder andere können sich dann boundary=settlement über die XAPI ziehen, und wenn dann etwas nicht richtig ist, begreift auch Joemapper, wo er die Grenze hinrücken muss. Weiterhin kannst Du auf einer Wiki-Seite zum Thema ausführlich zur Bestimmung der Siedlungsgrenze berichten, sofern Du das möchtest, etc. pp. Die Lösung des Problems ist, keine Grenzen und Flächen, die (nur) in Bezug zu einem Ort stehen, als Ort /place/ zu taggen. was soll das für eine Lösung sein? Ort=place, die Lösung ist, Orte als place zu taggen. Ja, genau, das schreibe ich ja, __Orte__ als place, nicht __Siedlungen__ Und genau deswegen macht ein place-polygon insbesondere für Dich keinen Sinn: weil es nicht _Ortsgrenzen_ sind, die Du taggst, sondern _Siedlungsgrenzen_ Bitte tue uns den Gefallen und rücke Dinge innerhalb OSM erkennbar in den Kontext, in dem Du dich befindest, anstatt bestehende Dinge aus ihrem bestehenden Kontext herauszurücken. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Hallo.
Am 20.09.2011 22:28, schrieb Frederik Ramm:
> Alles weitere - zum Beispiel OWL, oder Routing, oder Nominatim, oder
> diverse Analyseprogramme oder OpenStreetBugs, der OSM-Inspector,
> keepright, Relation Analyzer, Dupenode-Map, Garminkarten, taegliche
> regionale Extrakte - sind nicht Teil von dem "stabilen Satz von
> Werkzeugen", und das aus einem guten Grund - es waere naemlich zu viel
> Arbeit, fuer diese Stabilitaet zu garantieren.
Du schreibst ja selbst dass es schon innerhalb des aktuellen Sortiments
an *.openstreetmap.org-Services Dienste zweiter Klasse gibt die nicht
mit der gleichen Konsequenz online gehalten werden und wo es nicht
schlimm ist wenn die mal ne Weile nicht funktionieren.
Von daher wäre es eigentlich machbar die Services die von deutlich mehr
als einer Person betreut werden einfach in einem Bereich auf den
OSM-Servers zu hosten und damit das Team das die primären Services
betreut nicht damit zu belasten.
Du bringst selbst OpenStreetBugs als Beispiel, das ist für mich sogar
noch ein Sonderfall.
OSM bietet primär die Infrastruktur um Kartendaten zu sammeln, zu
speichern und diese wieder allen zur Verfügung zu stellen.
Sekundär kommen dann (so lese ich das aus deiner Mail) die Services um
Mapper zu koordinieren und um Austausch zu ermöglichen ("Community").
Meiner Ansicht nach sollte OSB sogar noch dazwischen einsortiert werden.
Denn ein Mapper kann auch mal ausweichen. Man braucht nicht unbedingt
das Forum oder die Mailingliste um mit anderen Mappern in Kontakt zu treten.
Ein Neuankömmling aber der nur einen Fehler in der Karte berichten will,
der sollte eigentlich eine einfache Möglichkeit dazu bekommen. Momentan
gibt es für diesen Menschen gar kein Angebot, er muss selbst irgendwie
zu OSB finden.
Ein kleines bisschen skandalös finde ich das schon, dass es dieser
Service nach wie vor nicht auf die OSM-Hauptseite geschafft hat. :)
Gruß, Bernd
--
Ich halte es für besonders wichtig, dass sich ein junger Geist
zunächst seinen Weg in der Welt der Phänomene sucht und ihm Formeln
ganz und gar erspart bleiben. - Albert Einstein
signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
On 20.09.11 20:55, Andreas Tille wrote: > Was lange währt ... Nun habe ich erstmal das Ticket aufgemacht: > > http://trac.openstreetmap.org/ticket/4015 > > Danke für den Hinweis Also mich tät interessieren, wie man sich ein Benutzungsverbot auf einem path im Wald vorstellen muss... IMO: entweder ist dort ein Zaun o.ä. oder das Verbot wird ziemlich wirkungslos sein... Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Hi, On 09/21/11 06:42, Bernd Wurst wrote: Du bringst selbst OpenStreetBugs als Beispiel, das ist für mich sogar noch ein Sonderfall. [...] Ein kleines bisschen skandalös finde ich das schon, dass es dieser Service nach wie vor nicht auf die OSM-Hauptseite geschafft hat. :) Da gibt es ja schon seit geraumer Zeit den Plan, OSB nicht nur auf die Hauptseite zu bringen, sondern auch betriebsmaessig in die OSM-Datenbank und das Rails-Frontend zu integrieren. Kai Krueger hat daran gearbeitet, aber irgendwie hat das Feature es nie in die Produktion geschafft. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offizieller Satz von OSM Diensten
Hallo, On 09/20/11 23:21, Andreas Tille wrote: Aber mehr als eine Katalysator-Funktion ist m.E. zentral nicht drin. Das wäre aber schon mal was. Da gab es im Dezember 2010 dieses OSMF-Vorstands-Meeting-Wochenende in Pisa, und in dessen Protokoll (https://docs.google.com/View?id=d38xqz5_6fj2bcdcm) steht: "OSMF wants to financially support projects which are aligned towards improving the data on OSM's DB, widen the reach of the Database. The Strategic WG is encouraged to come up with a plan to build a project incubator." Das hat zwar jetzt die Betonung auf der Geldseite, aber offensichtlich haben die da auch schon drueber nachgedacht, wie man erreichen kann, dass Leute, die zwar vielleicht die Zeit und das Koepfchen, nicht aber das Geld und die Hardware haben, etwas gutes zu bauen, unterstuetzt werden. Seitdem hab ich aber von diesem "project incubator" - ueber den vielleicht auch wegen des arg buzzwordigen Namens etwas gelaechelt wurde - nichts mehr gehoert. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
