Re: [Talk-de] Details mappen in Dortmund
Da jammert der richtige. Darf man denn mal fragen, aus welchen nichtöffentlichen Quellen deine Weichenbenennungen stammen? Im Luftbild sind die bestimmt nicht zu erkennen. Ich erzähle das hier bestiommt schon zum 50 mal. Ich sammle entsprechendes Material schon Jahre. Unter anderem für virtuelle Gegenstücke, wo man solche Informationen dringend braucht. Ich machs nicht erst seit gestern. Und Streckennamen an jedem Gleis braucht auch niemand. Schon garnicht in mapnik und der cyclemap sichtbar. Solange die Relationen nicht sicher sind und das ganze da nicht fest gesichert werden kann, ist diese Information gerade für nicht Indsider sehr hilfreich. Zerbröselt die Relation dann hast du massenhaft herrenlose Gleise, die außer ein Insider keiner mehr zuordnen kann. Hatte ich dem Bernd auch schon so geschrieben. Wie gesagt, man kann über alles reden. Aber der Herr hat ja nichtmal die Eier zu diskutieren. Von dir kam genauso keine Rückantwort. Aber wenn der gnädige Herr K. meint, das tracks=1 an gleisgenau gemappten Schienen überflüssig ist (obwohl es so im Wiki steht), löscht er das ohne Rücksicht auf bisher gemapptes einfach mal weg. Die habe ich da gelöscht wo du sie wieder an die von mir neu erfassten Gleise rangetaggt hast. Und zwar nachdem ich dir erklärt habe warum. Es kam ja keine Antwort. Und tracks 1 ist am ausführlich gemappten Gleisfeld eine überflüssige Information, genau wie ein Layer 0. Das macht da Sinn, wo es eben nicht gleisgenau ist. Und da habe ich das auch nicht rausgenommen. Vielleicht solltest du deinen Perfektionismus da austoben, wo nicht schon alles genau genug gemappt ist. Nach zwei Jahren seid ihr die ersten und einzigen die sich beschweren und so reagieren. Ich mein mir ist es wurscht. Wenn ihr da bei euch keinen Wert auf detailreiche Geoinformationen legt und mehr auf Ich war hier, dann mache ich da weiter wo man sich über die Informationen freut. Und ich habe nichts weiter gemacht als etwas zu ergänzen was eben alles andere als genau ist. Ihr habt ganze Strecken auf einer Linie zusammen gefasst und mit pseudo Verbindungen verzweigt. Den ref bzw. Streckennummer noch fälschlicherweise mit 26xx+26xx angeben. Das kann man so nichtmal auswerten, wenn man es nicht zufällig sieht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Da jammert der richtige. Es kam eben noch besser. Ich solle doch bitte meine cc-by-sa Quellen offenlegen. Dann darf ich gnädigerweise wieder mappen. Wahrscheinlich noch schön auf Markenfestplatten mit Schleife. Geht jetzt auch hier der Blockwart los? Ich lege ja gerne offen, aber gegenüber denen die es auch angeht, OSMF, Frederik oder wer auch immer, gerne auch wenn Interessierte mal vorbeikommen, was schon der Fall war. Ich werde jetzt aber defintiv nicht Terrabyte an Fotos und Material massenhaft im vorraus an selbst ernannte Blockwarte rausschicken. Mapper wie ajoessen und berndw braucht das Projekt. Das bringt unheimlich voran. Wird dann bald so effizient wie Wikipedia. Ich werde meine Daten heute Nacht löschen und dann wars es das mit OSM. Es geht anscheinend nicht ohne Gralshüter und Blockwarte, das frustet dann irgendwann mehr als das es Spaß macht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Mmmh. Und was bedeutet der Stempel Nicht für Dritte auf jedem Gleisplan im Zusammenhang mit cc-by-sa? Und das interessiert mich was, wenn ich beispielsweise vor Ort meine Aufzeichnungen und Bilder mache? BTW hätte ich sogar teilweise die Möglichkeit. Unsere Nachbauten wurden sogar von der Bahn abgenommen und zum gewerblichen Vertrieb freigegeben, ganz normal. Ich könnte einiges dem zugrunde liegendes Material offiziell verwenden. Das abgleitete sowieso. Das mache ich aber nichtmal und nutze nur die eigene Ersterfassung, was so sauber ist. Egal, es hat sich erledigt. Wer was braucht soll sich bei mir melden. Unter solchen Umständen wird das nichts mit OSM. Gruß Mirko attachment: weiche.jpg___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Du solltest Dich von ein paar einzelnen Mappern nicht vergraetzen lassen. Wenn umgekehrt jeder gegangen waere, den Du in der Mailingliste ein bisschen ruppig angefasst hast... ;-) Hallo Frederik, ich meine es ja garnicht ruppig. Da läuft vieles neben der Liste, auch real. Wer mich kennt weiß wie es gemeint ist. Das kommt hier ohne Emo usw. nur nicht richtig rüber. Wenn ich ruppig werde dann sieht das ganz anders aus. Ansonsten war das bisher ja auch kein Problem. So einen Fall wie hier habe ich noch nicht erlebt und kenne auch keinen der sowas erlebt hat. Wenn es mal Streitfälle gab dann konnte man das klären. Nur gabs hier anfangs gleich keine Antwort mehr und die Informationen wurden gleich gekillt. Ich solle doch bitte vorher die örtlichen Gralshüter erraten und sie um Erlaubnis bitten. Jetzt zuletzt noch nachgeschoben einen Darfschein nachreichen. Selber geben die Herren aber auch keinerlei Source etc. an. Betriebsstellenabkürzungen, VzG usw. stehen auch nicht bei Yahoo. Und ich glaube kaum das die auch die ehemaligen und noch aktiven Fdl kennen von denen ich die Information habe. Ist mir auch egal, weil ich keinem was unterstellen will. Wir rudern hier alle im gleichen Boot. Wenn mich zukünftig noch mehr von dieser Art Überraschungen erwartet, dann verzichte ich lieber und gebe die Daten an Leute die es gerne nutzen und wo man sich eventuell gegenseitig austauschen kann. Mir fehlt auch noch sehr viel und so ergänzt sich das ganze. Ich setze mich aber nicht Stunden hin um was beizutragen, nur damit das am nächsten Tag wegen Bodennebel, Blockwart, Purismus oder Ich war hier wieder völlig umsonst war. Da kann aich auch Wasser an die Wand nageln, kommt unterm Strich das gleiche bei raus. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
DAS ist arrogant (einfach löschen, wenn sie MICH stören). Du willst Daten löschen, damit wir mehr Daten bekommen? Durchschau ich noch nicht. Scheint leider normal zu werden. Ich hatte die Tage bisschen was in Köln gemacht. Unter anderem gleisgenaues mappen mit einigen Details, eben weil ich das ganze als Geodatenbank sehe und diese Daten für das rendern von Gleisplänen nutzen möchte. Schließt ja den ÖPNV nicht aus oder stört irgendwie. Einzig vielleicht das Rendering. Aber nichts was man nicht im Style etwas verbessern könnte. Gleise, Weichen etc, legt man einmal, das ändert sich alle Jahrzehnte mal, wenn etwas umgebaut wird. Dan kam ein gewisser berndw und war der Meinung das sich beträchtlich große Bahnbetriebswerke und Rangiergruppen doch auch durch ein einziges Gleis darstellen lassen. Super zu editieren, halbwegs ausreichend für Routen, aber um damit arbeiten zu können so zu nichts zu gebrauchen. Da wurde dann einfach ohne zu antworten mal schön gelöscht. Auch eine Antwort. Da setzt man sich Tage hin und dann das, das erste mal in 2 Jahren wo mir sowas passiert. Man kann ja drüber reden wie man es löst. Aber so macht es keinen Spaß mehr. Da schenke ich meine Daten lieber einem Projekt, wo man sein Wissen auch umsetzen kann und zwar so das man auch was von hat. Ich bin ehrlich gesagt kurz davor meine Daten rauszuschmeißen und hier aufzuhören. Geodaten werden hier mehr und mehr sehr eingeschränkt auf sehr wenige Felder gesehen. Das kann es nicht sein, OSM hat weit mehr Potential. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
nachdem jetzt die Aerowestbilder zur Verfügung stehen, habe ich angefangen, Straßen etc. flächig zu mappen [1]. Mein Vorbild ist Roßleben. Das hatte ich nur mal testweise so umgesetzt und funktioniert so in OSM noch nicht. Das kann man mal in einem kleinen abgelegenem Wohngebiet vor der eigenen Haustür testen. Ich rate jetzt aber davon ab, gleich wichtige Straßen mit solchen absolut nicht OSM konformen Testgeschichten umzusetzen. Das haut dir derzeit jeder Router um die Ohren. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
deswegen darf den auch nicht der Fahrlehrer ausstellen, sondern ein amtlicher Prüfer. Leute, ihr dreht euch im Kreis. Der Gesellenbrief kommt auch von der Handwerkskammer / IHK bzw. Innung und nicht von der Berufschule dem überbetrieblichen reinen Schulungsbetrieb, der Berufschule oder dem Betrieb. Trotzdem ist die das Bildungswerk und die Berufschule eine reine Bildungseinrichtung. Berufschulen haben wir hier auch zwei Typen. Einmal die staatliche und daneben die private, wo man bei letzterer beispielsweise Schulgeld zahlen muss, da am Ende aber z.B. ganz normale Kindergärtner oder Ergotherapeuten rauskommen, deren Papiere dann genauso irgendwo von offizieller Stelle kommen. Auch Schulen sind lange keinen rein staatlichen Einrichtungen mehr, unser Gymnasium und Internat wechselte letztes Jahr auch vom öffentlichen auf privaten Träger, ist aber weiterhin ein Gymnasium. Man sieht es wieder mal wieder viel zu Deutsch. Da ist wieder die üble denke vom Darfschein im Umlauf, geht international gesehen komplett in die Hose. In armen Ländern kommt man mit so mancher Defintion hier gleich garnicht weiter, die hätten keine Schule nach der Defintion. Eine Schule ist für mich schlicht eine Bildungseinrichtung. Egal welchen Träger die hat, welche Papiere da dahinter stecken. Natürlich nicht das absolut absurde Beispiel von der Baumschule, auch nicht die kleine Tanzschule oder sowas in der Art. Aber alle Bildungseinrichtungen die aus-, fort- und weiterbilden sind Schulen. Subtag dazu und gut ist. Wollen wir jetzt wieder für jedes Bildungswerk, BBZ etc. wieder eine Latte Tags erfinden, die in kein Preset passen, die sich keiner merken kann? Ich möchte nicht wissen wiviele Volkshochschulen etc. schon lange als school getagt in der DB rumliegen, eben weils bisher schlicht nichts anderes gab. Hier ...taucht dann als Schule auf haben wir schon. Das ganze mit Defintion umwerfen und was da wieder kommt ist doch wieder so eine Scheindebatte. Klar machts wieder Arbeit. weniger für die immer wieder vorgeschobenen Anwendungen, 3 Router und vielleicht 20 Renderer. Das sind für die jeweils maximal einen Tag im Style umschreiben. Die Arbeit haben die Mapper. Die hat man aber auch so ständig und oft. Man muss quasi wöchentlich gucken was sich da wieder geändert hat. Und da ändert sich auch so oft etwas und man muss umtaggen. Das tut aber weniger weh wenn man das einmal sauber durchzieht. School für Bildungseinrichtungen und dann gleich sauber alle Subbezeichnungen dazu. Da kann man alles in einem Rutsch schön abfrühstücken. Die Alternative sieht wieder suboptimal aus. Für alles wieder einen eigenen Tag, jeden 10 mal totgequatscht, Wochen und Monate für eine Abstimmung von vielleicht 20 Leuten. Und wenn man Glück hat, hat man seine Bildungseinrichtungen dann endlich mal in 2 oder 3 Jahren richtig eingeordnet. Kikifax den man eingentlich vorgestern im vorbeigehen hätte abhaken können. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
naja, meine Definition allgemein- oder berufsbildende Schulen war schon so gewählt, dass man sie überall einsetzen kann. Man könnte auch sagen, alles wozu man umgangssprachlich Schule sagt. Du meinst eher wozu wir hier in Deutschland umgangssprachlich nur Schule sagen. Genau das geht aber international in die Hose. Und das geht mir auch nicht weit genug. Zu einem Bildungswerk etc. sagt auch keiner Schule. Das ist aber eine Einrichtung wo überbetrieblich ausgebildet und geschult wird. Es ist eine besondere Schulform, aber nichts wo ich großartig einen ganz exclusiven Tag brauche. Genauso die privaten Berufsschulen hier. Nennt auch nicht wirklich einer Schule. Hier kam auch wieder irgendwo das Scheinargument des verwaschens. Das school Tag ist eine einzige Waschmaschine. Bis heute hat doch auch keiner zwischen Grund-, Haupt-, Relaschule etc. unterschieden und keinen stört es. Da kann die Entwicklung nur besser werden. School war und ist ein Sammelbegriff, mehr kann man da garnicht mehr verwaschen. Wegen mir könnte man school auch auf allgemeinbildende Schulen beschränken und für berufsbildende Schulen auch was anderes nehmen. Warum denn immer etwas anderes und alles unnötig verkomplizieren und zerhackstückeln? In der Praxis ist der Tag doch schon lange verwaschen. Ich sehe den an allen möglichen Arten von Schulen. Oberbergriff School und dazu die genaue Angabe für was. Vom Aufwand her ist es völlig bums ob komplett neuer oder Zusatztag unter dem bestehenden. Ich muss die Berufschule so oder so umtaggen, die bereits unter school versammelten Berufschulen verschwinden auch nicht einfach so. Ich spare mir aber wieder eine zusätzliche Obergruppe. Genau das meine ich mit dem Rumgeiere. Bitte nicht für jede Schulform wieder einen ganz eigenen Tag, den man wieder typisch studentisch deutsch auf ewig dahin kaut. Und man als Mapper wie auf Kohlen sitzt, die Daten hat, aber man bei der Tagfindung mal wieder ewig nicht aus der Hefe kommt. Das ist total unproduktiv. Liste der Schulform sammeln, alle Zusätze in einem Durchgang abnicken und los geht es. Das tut aber weniger weh wenn man das einmal sauber durchzieht. School für Bildungseinrichtungen und dann gleich sauber alle Subbezeichnungen dazu. In Deutschland sehe ich das nicht so. Wie wärs mit education=driving_school für die Fahrschule (ohne amenity)? Deutschland ist ein kleines unter vielen. Wie sieht es global aus? Davon ab bin ich da komplett leidenschaftslos. Es ist ein Tag und keine Weltwirtschaftsentsscheidende Richtungsweisung. Es tut nicht weh, wenn auch die Fahrschule klar und deutlich als Zusatz unter School auftaucht. Das ist eher eine Entscheidung zwischen Quadratisch praktisch gut als Zusatz in einer Gruppe. Oder eben quälend langsam in der Entscheidunbgsfindung mit anderen als Einzeltags. Hier fehlt eindeutig sowas wie ein Poll. Dafür, dagegen, enthalten. Ansonsten diskutiert man hier noch in einem Jahr und kommt nicht weiter. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenze folgt der Küstenlinie
Man könnte doch einfach einen zusätzlichen Tag an den Grenz-way anhängen (Vorschläge?). Dann hat jeder Renderer die Wahl, ob und ab welcher Vergrößerungsstufe diese Küstenbegleitenden Grenzen dargestellt werden sollen. Wozu? Du hast doch mit coastline und boundary zwei seperate Tags zum auswerten. Da konnte der Renderer schon immer entscheiden ob nun das eine, das andere oder eben wie bei Mapnik beides dragestellt wird. Ein Dritter Tag ist da garnicht nötig. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] straßenbegleitende Radwege
Meiner Meinung nach gehört diese Information zu dem Way, und muss - zumindest solange es keine handhabbaren Relations dafür gibt - per name-Tag angegeben werden. Und das bringt dir dann was? Das der Weg da irgendwo neben der Straße läuft das siehst du auf der Karte und dann vor Ort. Dem Router kanns total egal sein, der will nur wissen wo der dich am besten lang schickt. Die grundlegenden Probleme bleiben auch so ungelöst. Und das wird auch keine Relation lösen. Jedenfalls nicht in der Form wie man die jetzt bedient. Das befummeln deutschlandweit 3 Experten, 100 machen sie wieder kaputt und in ganzen Städten hat man noch nichtmal begonnen begleitende Fußwege oder Radwege an die Straße zu taggen. highway=x, name=x und das war es. Ich habe es nicht geteset, aber Fußgängerrouting dürfte doch derzeit eher Rätselraten sein. Man muss ja noch davon ausgehen, das alles unterhalb Trunk automatisch Fußgängertauglich ist. Für eine genauere Vorhersage müsste man alles außerhalb seperat angelegter Fußwege, Wege mit foot=yes und Straßen mit footway=left/right/both ignorieren. Ansonsten routet es doch schnell mal über die direkte innerstädtische vierstreifig ausgebaute Landesstraße, wenn da nicht direkt einer foot=no angehangen hat. Aucvh ansonten über alles was man keinem Fußgänger zumuten möchte. Wird sicher noch ein ganz spannendes Thema. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spam
Der spammt aber wie verrückt: Der würde ich nicht sagen, eher es. Das übernehmen heute größtenteils Bots. Meistens asiatischer Raum oder Botnetze auf infizierten Rechnern und Werbservern. Besonders geknackte Rooties von wanna be Linux ist sicher Admins bombardieren da ganz hübsch. Mich wundert es ehrlich gesagt sehr, das es OSM erst jetzt befällt. Denn wir haben im Grunde rein garnichts was dem vorbeugt, OSM steht offen wie eine Scheune. Wer ein Forum hat der kennt das Problem. Selbst mit Captcha, Bottrap oder der Sperrung des asiatischen Raumes, kommen die ab und an noch durch. So langsam sollte man sich da mal Gedanken machen. Das bisschen was bisher kam ist noch garnichts, wenn die loslegen dann kommen Accounts und Spams im Sekundentakt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spam
Aber für die Aussage, dass Captchas selten was nutzen, möchte ich gerne mal einen Beleg aus der Paxis hören. Alle mir bekannten Sites die Captchas (egal welcher Qualität) nutzen, haben meiner Kenntnis nach kein Spamproblem. Vielleicht ein Usability-Problem, aber darum geht es ja gar nicht. Hast du bei denen auch einen Einblick was dahinter läuft? Da sind meist noch Anpassungen im Scipt nötig, zusätzlich laufen da noch Botfallen. Und trotzdem kommt da noch etwas durch. Für lohnende Fälle werden günstige Chinesen angeheuert, die dann persöhnlich Accounts anlegen, welche dann für Bots offen stehen. Ein Captcha allein hilft schon lange nicht mehr. Ich kann dir ja gerne mal Log schicken, was da alles aufläuft und angesprochen wird ist heftig. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
car_rental und bike_rental gibt's ja schon. Aber boat_rental leider noch nicht. Vieles andere auch noch nicht und da gibts ne Menge was vermietet werden kann. Das bedeutet in der Form auch drei Trilliarden Hauptschlüssel. Ich wäre streng dafür die bisherigen Rentals zu kippen und unter amenity=rental zu gruppieren. Da kannst du mit rental=* unendlich weitere hinzufügen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Proposal für boat_rental
Klingt gut, ich denke, man kann dann geeignete rental-Werte fuer Videoverleihe und Laufhaeuser einsetzen ;-) Videothek haben wir ja schon, würde aber auch passen. Aber es wird doch heute soviel vermietet, da müssen wir uns doch nicht schon wieder die nächste Krücke bauen, wo man für jeden Mist wieder einen weiteren amenity aufmachen muss. Der Tag wird so schon unerträglich gedehnt. Der Mist geht ja aktuell schon wieder bei school los, ich kann es langsam nicht mehr lesen. Weil ich gerade mal kurz in Köln gefummelt habe, der neue Ikea am Butzweiler vermietet beispielsweise Anhänger. In Baumärkten und bei anderen kann man Werkzeuge oder ganze Bauschmaschinen mieten. Ganze Branchen vermieten nebenbei oder hauptsächlich irgendwas. PA, Zelte, IT, Klohäuschen oder was auch immer. Deswegen bietet es sich an amenity=rental und retal=* für reine Mietgeschichten zu nutzen. Das rental=* könnte man dann auch noch an bestehende Firmen, Shops etc. hängen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Laenderexperten
schade, ich dachte, es gaebe einen gemeinsamen ansatz. Nur ganz entfernt. Wenn ich bei OSM mitmache, meine Daten da rein setze, dann weil ich es allen komplett frei zur Verfügung stellen will. In der Hoffnung das andere es gleich tun, Daten ergänzen oder Ecken liefern, wo mir Daten fehlen und wo ich mich für interessiere. Das ganze möchte ich dann auch nach belieben nutzen. Andere können meine Daten auch nach belieben nutzen. Ich mache aber nicht die Arbeit für irgendein Freibier Portal, was mich wieder einschränkt und wo ich letztendlich nichts von habe, außer Arbeit. Wenn ich irgendwelche detailierten Spezialkarten gegen Cash liefern will, dann mache ich das selber und kassiere für meine Arbeit auch selber. Wenn du eine angemessene Beteiligung an den Kartenersteller ausschüttest dann könnte man sich auf anderer Basis für wirklich spezielle Sachen ergänzen. Ich mache die Arbeit, du bietest die Plattform zur Vermarktung. Habe ich absolut nichts gegen. Aber arbeit machen und dritte kassieren schön die Lizenzkosten dafür, nee, Da kann man auch gleich dieses Goggle Teil nutzen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumkataster
Das kann ja kein Mensch aktuell halten. Aber man könnte anhand solcher Daten sicher schön erkennen, wo Straßen von Alleen gesäumt sind Und dann? Ich kenne kein übliches Tagging dafür. Ich hatte das mal bei mir mit einzelnen Bäumen durchgespielt. Da kommt dann sowas bei raus (grüne Punkte). http://www.openstreetmap.org/?lat=51.29571lon=11.43631zoom=17layers=B000FTF Ist eine Möglichkeit. Müsste man allerdings abgrenzen. Normales natural=tree wird vorwiegend für markante Bäume und Naturdenkmäler genutzt. Je nach Rendering hast du ansonsten eine Tonne Icons mit der Prominenz von ND Bäumen. Simple Bäume müssen daher auch klar in den Daten zu erkennen sein und entweder garnicht oder nicht weiter störend gerendert werden. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?Tracks / Access / Routing über Trac ks
Hier in der Gegend würdest du mit deinem Beispiel nicht glücklich werden. Die Täler sind da oft so eng, daß da kein Weg im Tal verläuft. Der Weg parallel zum Bach macht da gerne mal viele Höhenmeter bei teilweise heftigen Steigungen (bis 20% kann man hier schnell mal finden). ;-) Hier haben wir das doch selber in der Hand. Wir haben doch praktisch die unbegrenzte Möglichkeit eine Eignung für alle erdenklichen Fortbewegungsmittel zu hinterlegen. Und da wir die Daten auch selber erfassen, kann man die Eignung auch selber einschätzen. Dein Beispiel könnte man z.B. zusätzlich mit mtb scale beschreiben. Sowas kann man noch ausbauen und meinetwegen auf Rennrad etc. zuschneiden. Oder ein Schlüssel der nicht nur innerhalb eines Radtypes abstuft, sondern Radtyp mit Grade verknüpft. Rennrad, City, Touren, MTB. Man müsste dann nur den Router entsprechend zuschneiden und Auswahlmöglichkeiten anbieten. Zum Beispiel: meide wo möglich Haupstraßen, bevorzuge Wege geeignet für MTB und darunter/ bevorzuge Wege Schwierigkeitsgrad ausschließlich MTB, bevorzuge oder meide offizielle Radwege. Das wird dann zwar auch nicht direkt die wirklich absolut perfekte Route ergeben, aber besser als alles bisher da gewesene kann es nur werden. Versuche gab es da schon viele. Aber die konnte man ehrlich gesagt in die Tonne treten. Hier geisterte mal irgendwo ein Link zu so einem Router auf OSM Basis herum. Da hatte ich mal testweise eine Route von Naumburg zu uns nach Roßleben probiert. Da existiert eine direkte Fernradwegverbindung die sogar größtenteils für Rennrad geeignet ist, daneben noch einige andere Wege die gut geeignet sind. Der Router führte einen aber ungleich weitläufiger im weitem südlichem Bogen über Landesstraßen drumherum. Da kannst du ehrlich gesagt auch gleich über die Autobahn routen, ist so wie man hier über die Landstraßen heizt nur geringfügig unsicherer. Beim Radroutung kann es nur besser werden. Oft will man das wirklich nicht, aber ich bin andererseits auch mal in Situationen wo ich wirklich nur schnellstmöglich zum Ziel kommen möchte und da ist das schon hilfreich sowas zu haben. Routing über Tracks. Da werden immer wieder alle Fortbewegungsmittel in einen Topf geschmissen. Klar macht das routen über Tracks bei einigen wenigen Sinn. Aber eben nicht bei allen. Ein Router der vorwiegend auf Kraftfahrzeuge zugeschnitten ist, braucht Tracks nur dann, wenn es absolut keinen anderen Weg gibt oder das Ziel eben an einem Track liegt. In der Berechnung kann der Tracks die so zwischendurch in die Berechnung geraten zu 1000% rauswerfen, da sind Tracks schlicht überflüssig. Und hier wiederhole ich mich mal wieder. Alles ab Grade 2/3, also nicht asphaltierte oder betonierte Fläche, ist immer nur eine Momentaufnahme zum Zeitpunkt der Erfassung. Der Wegzustand ist im ständigen fluss, lässt sich auch nicht vorhersagen. Wo gestern noch eine gute Schotterpiste war, kann übermorgen die Fortskolonne zur Schlacht ausholen und ein Schlammloch hinterlassen, was auch ewig nicht mehr beseitigt wird. Und ich weiß nicht wo andere die Informationen hernehmen um sowas vorher zu sehen. Aber hier sind die mal hier und mal da, ohne das sowas irgendwo öffentlich angekündigt wird. Man kann maximal anhand frischer Fortszeichen erahnen, das hier irgendwann mal was passieren könnte. Wann ist aber unklar. Letztes Jahr waren die Forstzeichen schon im Frühjahr da. Einige Stellen wurden erst im Herbst oder noch garnicht bewirtschaftet. Wann und wie siehst du erst, wenn du mal wieder vor Ort bist, vorm Flatterband oder dem bereits kaputten Weg stehst. Tracktype die älter als 6 Monate sind sollte man eher vorsichtig bewerten, die kann man nicht wirklich zur genauen Planung heran holen. Hier liegen teils noch fette Eichen von Kyrill auf den Wegen. Nach dem jetzigen Winter wird wohl auch wieder massig Verbruch liegen. Das wieder zu kontrollieren geht nicht mal eben. Alleine der Wald hinter mir hat knapp 2000 km Forstwege. Teilweis wirkliche Horrorwege. Das fährt man nicht mal eben zwischendurch ab Alle anderen Transportmittel stehen doch auf einem völlig anderem Blatt. Wer seine Fahrradroute über einen KFZ Router plant, der sich eben nicht oder nur oberflächlich auf die Bedürfnisse vom Radfahrer einstellen lässt, kann doch nicht wirklich erwarten, das man deswegen generell auch Tracks zwischendurch zulässt. Was da rauskommt kann man doch auch schön anhand von LKW Fahrern sehen die PKW Navis nutzen. Da wo die teilweise reinfahren kann das offensichtlich nicht passen. Da zieht auch nicht die Ausrede, das da nicht genügend Schilder stehen. Die waren teilweise früher schlicht nicht nötig, eben weil sich LKW nie dahin verirrten. Das Problem entstand überhaupt erst mit der Nutzung von PKW Navis für LKW. Und da steht eben nicht drin, das da eine Brücke mit maximal 16t und eine Unterführung mit maximal 3m Höhe in der Route stecken. Das sind Sachen die bei einem Navi für Fahrzeuge bis 3,5t
Re: [Talk-de] Tracks / Access / Routing über Tracks
Es geht mir darum, wie es mit der Benutzung der Wege aussieht. Aus diesem Grund spreche ich in den Überschriften auch explizit von Wegen. Das Beispielsweise Fußgänger auch quer durch den Wald stapfen dürfen interessiert im Zusammenhang mit highway=track nicht. Meine Punkte beziehen sich auf Wege... Man unterscheidet dort z.B. bei den Fahrrädern zwischen befestigen Wegen und Straßen und unbefestigten. Je nach Definition von unbesfestigt wäre also auch schon ein Track Grade 3 für Fahhräder tabu, wenn kein ausgeschildeter Weg darüber führt. Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks / Access / Routing über Tracks
http://wiki.openstreetmap.org/wiki/DE:Track:access Schau bitte nochmal genau nach, insbesondere beim Thüringer Waldgesetz. Ein wenig differenzierter ist das schon, mit ja, nein und vielleicht ist es nicht getan. Für Fahrränder besteht z.B. Wegpflicht. Die und besonders MTB dürfen keine inoffiziellen Trails etc. Nutzen. (Könnte der MTB Karte noch schön in die Parade fahren) Fahrzeuge Forstwirtschaft egal welcher Art freigegeben. Behinderte mit Sonderparkgenehmigung für Schwerbehinderte dürfen selber oder als Beifahrer im Wald fahren. (Wichtig für Behindertenkarten) Kutschen nur auf Reitwegen. Der Waldeigentümer kann seinen Teil auch vom Gesetz abweichend freigeben. Auf bestimmten Flächen sind auch die sonst erlaubten Punkte nichtig. Für Motorsport besteht generelles Verbot. Das Waldgesetz in Sachsen-Anhalt hat garkeine Punkte in der Richtung. Hier werden an den Zufahrten zum Wald entsprechende Schilder gesetzt, oder auch nicht. Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks / Access / Routing über Tracks
Wenn ich hier andererseits schaue, wie vielseitig manche mit tracktypes umgehen, dann wundert mich da gar nichts mehr. Wenn bei Mirko ein grade3 schon metertiefe Spurrinnen hat, dann möchte ich auf dessen grade2 vermutlich auch nicht mehr Autofahren. Was willst du denn sonst nehmen? 1 ist mit besfestigter Oberfläche 2 ist verdichteter Schotter Ab 3 geht der durchweg nur durch Traktorreifen entstandene und hier zu 99% übliche Feldweg los. Feldwege wurden hier in der Regel nie direkt gebaut. Es blieb zwischen den Agrarflächen ein Grünstreifen frei und der wurde dann je nach Platz befahren. Richtig besfestigt sind nur wenige wichtige Hauptwirtschaftswege. Es zählt das der halbwegs fest ist, wie tief die Spuren sind, ist hier doch garnicht gefragt. Und da ist es leider nicht so eindeutig. 5 ist hier schon halb zugewachsen aber noch immer genutzt. Die Bilder im Wiki sehen bis 5 noch viel zu gut aus. Wenn ich danach ginge, bräuchte ich noch weitere 5 Stufen. Ab 3 oder sogar 2 sind doch sowieso immer nur Momentaufnahmen zum Zeitpunkt der Erfassung und sollten nie zu wörtlich genommen werden. Was dieses Jahr eine 3 verdient kann wenige Monate später oder im nächsten eine 5 sein. Es kam auch schon vor das eine gute 2 auf dem Rückweg nicht mehr zu gebrauchen war. Der hochverdichtete Schotter war durch Harvester komplett ausgefahren, zurück blieb ein Schlammloch mit ganz tiefen Spurrinnen. Das aktuell zu halten ist unmöglich. Oberhalb von 3 kann man im grunde als unbesfestigt zusammen fassen. Das ändert sich ständig und ist nach wenigen Monaten oft nicht mehr aktuell. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks / Access / Routing über Tracks
Dann solltest Du Deine Einstufung von 3-5 nochmal überdenken. 5 ist nunmal das schlechteste, d.h. ein paar Deiner Grade 5 sind vielleicht doch noch grade4. Ist ja sooo wichtig auch nciht ;-). Ich würde es schon auch an der Konstruktion und dem Untergrund festmachen. Ein Grade5 ist bei mir überhaupt nicht konstruiert (oder total verfallen), also lediglich ein Trampelpfad mit mind. Autobreite. Muss ich nicht. 3 ist halbwegs fest, erkenn- und befahrbar. Gibts in einer großen Bandbreite. So schön wie im Wiki allerdings nicht, unbefestigte gehen hier erst ab der dort gezeigten 4 los. Ob nun mit Friseuesenporsche oder Geländewagen spielt da keine Rolle, muss der Fahrzeugführer selber entscheiden. Und die gibts auch mit Erschließungscharakter. Meinetwegen zum Schießplatz, Gartenanlagen, Datschen oder Einzellgehöften. Gerade weil die oft sehr mieß sind, tagge ich die nie als Service. 4 ist Grasweg der noch erkenn- und befahrbar ist. Kann von der Ebene her besser als 3 sein, ist aber dafür auch mal versumpft und sehr bewachsen. 5 ist dichter Bewuchs, nur noch mit Geländewagen oder schwere Technik befahrbar. Der Weg ist zwar noch da, oft sogar noch Spurrinnen. Aber da brauchst du schon eine Machete. Aber das ist wie gesagt im ständigen Fluss und immer nur Momentaufnahme zum Erfassungszeitpunkt. Eine nicht befahrene 3 ist nach wenig Nutzung im nächsten Jahr schnell eine 5. Im Wald ist es je nach Forstaktivität auch mal umgekehrt. Die guten 2er sind durch die Fortsmaschinen total kaputt, werden Monate oder Jahre nicht mehr ausgesbessert. Die ehemaligen 5er sind frei und der Untergrund zu einer schönen ebenen Fläche gefahren. Tracktype kann man immer nur bedingt vertrauen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks / Access / Routing über Tracks
Ja, aber die Skala geht bis 5. ;-) Geht man nach den dortigen Bildern dann fehlt noch was. Das unter 5 gezeigte kommt nichtmal im Traum an das was hier den schlechtesten Wegzustand darstellt. Das mag sowohl regional unterschiedlich sein als auch von einem Einheimischen anders wahrgenommen werden als von einem Ortsfremden. Fakt. Es gibt Regionen da ist jeder Mistweg richtig asphaltiert. Sowas gabs hier bis vor kurzem überhaupt nicht. Eine Hand voll übelste Betonplattenwege mit Kranankern und Bröckelbeton war die Königsklasse. Liegt auch daran das wir hier eine ganze andere Landwirtschaft gefahren haben. Wir haben riesen Felder die damals und heute von Großbetrieben bewirtschaftet werden. Wegebau hat der Zetti mit den Reifen erledigt praktisch funktionierend musste es sein. Zetti, W50 und Co. sollte da durch, nicht der Trabbi. In Westdeutschland ist eher alles winzig und privat, Wegequalli hat da auch mit eine Rolle gespielt. Ich klassifiziere meist nach folgenden Anhaltspunkten: 1 - asphalt / kann man mit inlines und city-kinderwagen drauf fahren 2 - schlechter asphalt oder guter schotterweg / kann man mit fahrrad und kinderwagen drauf fahren und wird auch bei schlechtem Wetter nicht besonderes dreckig 3 - gut befestigt aber holpriger / kann man noch gut mit dem fahrrad fahren (braucht aber ggf. schutzbleche oder outdoorkleidung) 4 - deutlich sichtbarer weg aber nur bei sehr gutem Wetter für fahhrad/kinderwagen nutzbar 5 - reiner Dreckweg, der meist nur jahrszeitabhängig wirklich sichtbar ist Bis zwei bin ich halbwegs dabei. Deine 1 Deluxepiste gibts hier nicht, nur auf umgewidmeten Fernradweg. Da zählt für mich richtig versiegelte Oberfläche. Wie rauh die ist inetressiert nicht. 2 ist verdichteter Schotter, kann man drauf fahren, hat aber auch mal kleine Löcher. 3 fängt hier bereits mit Spurrinnen an. So Wege mit Kinderwagen befahrbar gibts hier nicht. 4 ist Grasweg, 5 ist Machete. Nach deiner Einteilung bräuchte ich bist Grade 8 oder 10. Wir haben hier viele die ich als grade3 einstufe, die sehr gut befestigt sind, aber z.B. nen Grünstreifen in der Mitte haben. Die sind auch bei üblem Wetter nicht weich sondern nur an der Oberfläche etwas dreckig. Nach diesen Kriterien haben wir kein Grade 3. Ein Weg der starke Abhängigkeit vom Wetter zeigt oder bei Waldarbeiter- Benutzung schnell mal unpässlich wird, würde ich schon als grade4 einstufen. Mach gleich eine 5 draus, dann haben wir hier zu 90% nur 5. Da geht mir aber wieder der Grade für alles schlimmere aus. Ich halte meine Einstufung für analog zu http://wiki.openstreetmap.org/wiki/Proposed_features/grade1-5 mit der Anmerkung, dass Grünstreifen in der Mitte aber ansonsten gut befestigt dort nicht vorkommt und bei mir grade3 ist. Den Grünstreifen finde ich besonders entscheidend, da der z.B. einem Rollstuhl oder Kinderwagen schnell mal zum Verhängnis werden kann. Ja, sagte ich schon. Das dort gezeigte kommt viel zu gut weg. Das geht noch weit schlimmer als das unter 5 gezeigte. Naja, man trennt die ja nicht auf um sie dann wieder zusammen zu werfen. Ich finde schon, dass man mit einer gewissen Ortskenntnis und einigen Erfahrungswerten beurteilen kann für was der Weg normalerweise zu gebrauchen ist. Kannst du nicht. Ungenutzte wachsen zu, andere werden je nachdem was aktuell bewirtschaftet werden soll besser oder schlechter. Jedes Jahr wächst da auch mal 2 zu oder wird kaputt gefahren, 5er werden entkrautet. Das merkst du erst, wenn du da mal wiueder vorbei kommst. Hier hängen keine 5 Jahrespläne mehr aus, aus denen du irgendeine Entwicklung ableiten könntest Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hab ich da einen Fehler gemacht?
- Administrativ (z.B. landuse=residential) = Nichts ausschneiden) Wann wurde ein Landuse in die Administrative gehoben? Ich glaube das verwechselst du gerade mit einem place=* Polygon. Das begegnet mir aber leider recht häufig. Da werden residentials getaggt, Ortsname dran und das soll dann der Ort sein. Findet aber keiner. Da muss noch ein Place dazu, ansonsten wird das nicht gefunden. Entweder Landuse mit Place Node, Landuse mit mit Place zusammen im Polygon (zusätzlich wohl noch Node nötig) oder Place Polgon mit mehreren Landuses darin, ohne natürlich irgendwas auch Place auszuschneiden. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
Ja, ich hoffe und glaube auch, dass die Sache für OSM positiv ist. Vielleicht werden jetzt endlich mal korrekte access-rights an die Feldwege gepappt usw. Definitiv nicht, es sei denn man erfindet welche dazu. In manchen Ecken sind Feldwege nicht extra beschildert, bei uns hier auch nur etwa 1%. Da muss sich schon der Navianbieter einen Kopf machen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
klar, aber auch nichtbeschilderte Feldwege haben access-Rechte. Wenn man in einem Bundesland ist, wo das Befahren grundsätzlich erstmal erlaubt ist, dann wäre das z.B. vehicle=yes oder motorcar=yes. Ja, laut Landes-, Kreis-, oder Kommunalrecht kannst du dir auch bei einer bestimmten Marsstellung einen Jadeaffen abholen. Das kannst garnicht alles taggen und wäre für die meisten nichtmal nachvollziebar, eben weil es irgendwo in der Ortsteil Findlings Verordnung versteckt steht. Getaggt wird was wirklich klar vor Ort nachvollziehbar ist oder was die StVO hergibt. Zumal yes sowieso default ist und man sich das sparen kann. Feldwege ab bzw. über Grade 3 kannst du beispielsweis für normale Straßenfahrzeuge komplett ausnehmen. Die sind zumindestens hier teilweise so heftig, das hinterlässt einen herrenlosen Auspuff. Feldwege machen überhaupt nur dann Sinn, wenn das Ziel, also die letzte Meile, an einem solchen liegt. Zwischendurch haben Feldwege garnichts zu suchen, ausser es geht absolut nicht anders, was aber eigentlich nicht vorkommen dürfte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
was für ein Quatsch, Verkehrsregeln stehen nie in irgendeiner Ortsteil-Verordnung. Natürlich nicht in der Orteilsverordnung, dafür aber in anderen Gesetzen, die der normale Verkehrsteilnehmer garnicht auf dem Schirm hat. Die Feldwege hier im Dammbereich sind z.B. auch nicht nach StVO beschildert, dürfen aber nach Umweltgesetz nicht befahren werden. Wald etc. das gleiche. Da gibts kaum StVO Beschilderung aber trotzdem darfst du da aufgrund anderer Gesetze nicht lang. ach ja? Wo ist dieser Default denn dokumentiert? Die Wikidefinition lese ich eher als default=no. Ist mir ehrlich gesagt komplett neu und irgendwo auch wider der anderen Wege. Normal sperrt man ja explizit alles was nicht darf. Wenn ich jetzt auf jedem Mistweg alles angeben müsste was darf, wird man ja irgendwann bekloppt. Da müsste ich hier bei fast jedem Weg eine komplette yes Liste hinterlegen. Mal unabhängig davon ob das auch Sinn macht. Grade 3 hat hier oft mal 50 cm tiefe Traktorspuren und ganz häßliche Sandsteinbrocken. Da fährts du nur einmal mit dem Friseusenporsche rauf, dann hängst du mit allen Rädern in der Luft. Und wie schon geschrieben. Feldwege haben im normalen PKW Routing zwischendrin nur in ganz wenigen Ausnahmefällen was zu suchen und könnten daher default ausgenommen werden. Das macht nur dann Sinn, wenn man zu irgendeinem Gehöft möchte, wo man auf den letzten Metern garnicht anders kann. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
Eine Anliegerstraße wird zugunsten eines grade4(!) Feldwegs verlassen. Na ja, würde sich nichts ändern, wenn man nach Martin geht und wie hier üblich auch noch auto=ja anbringen würde, wenn der Router sowieso generell Feldwege mit einbezieht. Da müssen die Router lernen mit klar zu kommen, teilweise auch mit nationalen Unterschieden. In Deutschland ist das Routen über Feldwege für PKW schlicht sinnfrei, nur Ausnahmefälle und letzte Meile. Im Ausland kann es da sicher wieder anders aussehen. Kann aber nicht darauf hinauslaufen, das wir nun hierzulande Feldwege künstlich sperren. Hier sind die ja wie schon geschrieben kaum gesperrt. Wird auch nicht mehr so schnell kommen. Zu DDR Zeiten gab es keinerlei oder kaum Sperrungen in der Richtung. Man hat es teilweise erfolglos versucht zu ändern. Wer sich auskennt fährt trotzdem noch über den Wirtschaftsweg. Dieses gefühlte Recht bekommst du vorerst nicht raus. Ich hatte ja vorhin schon den Dammbereich angesprochen. Da wird regelmäßig im Amtsblatt angemahnt den nicht zu befahren, kostet Strafe. Wird trotzdem gemacht. Die kommerziellen Kartenanbieter haben sich es da gleich ganz einfach gemacht. Die Feldwege haben die hier garnicht in den Karten gemalt, wo kein Weg da auch kein Problem. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler-Bugs: Kreisverkehre
wenn es nach Umweltrecht (wie Du schreibst, habe ich jetzt nicht geprüft) verboten ist, wäre es ja nicht künstlich sondern ganz real eine Sperrung. Wenn du das wie in dem Fall zufällig weißt dann ja. Aber der normale Mapper studiert doch nicht sämtliche Gesetzestexte bzw. weiß davon nichts. Der guckt auf das was er vor Ort sieht. Das ist dann auch am Objekt selbst nicht nachvollziehbar. Da kannst du nur in den Note schreiben das hier statt 250 irgendein Gesetz gilt und darauf hoffen das es auch beachtet wird. Ändert aber am Grundproblem nichts. Hier sind gesperrte Feldwege nur mit Schild gesperrt. Für offene existiert soweit mir bekannt keinerlei andere Regelung. Da wäre irgendeine Sperrung also wirklich frei erfunden. BTW bezieht sich das im Dammbereich auf: Thüringer Wassergesetz (ThürWG) § 77 Besondere Pflichten zum Schutze und zur Unterhaltung der Deiche (1) Auf Deichen und ihren beiderseitigen, vom Deichfuß aus mindestens drei Meter breiten Geländestreifen, sind das 1. Entfernen der Grasnarbe, 2. Halten von Geflügel, 3. Weiden und Treiben von Vieh, außer Schafhütung, 4. Lagern von Stoffen und beweglichen Sachen, 5. Fahren mit Kraftfahrzeugen und Reiten untersagt. Auf Deichen ist das Pflanzen von Bäumen und Sträuchern untersagt. Die Wasserbehörde kann Ausnahmen zulassen, wenn sie der Unterhaltung des Deiches dienen oder öffentliche Belange nicht entgegenstehen. Hätte ich auch nicht gewusst, wenn man nicht einige wenige Schilder mit dem Hinweis hingestellt hätte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wandertafel, Info-Tafel als Geschäf tsmodell
Bei 20.000 Gemeinden allein in DE und je Ort mehreren Tafeln (in Simmelsdorf waren es 12) könnte das ein zukunftsträchtiges Geschäft sein...! :-) Nicht wirklich. So eine Karte aufsetzen ist garnichtmal so schwer. Ich bin nun auch kein Frickel Experte und kriege das mitlerweile hin. Das aufwendigste ist, das man für den jeweiligen Fall erstmal einen geeigneten Kartenstil schreiben muss. Denn hinterher groß umbauen ist nicht drin und sauber nachbauen ginge auch nicht schneller. Also wird ein Stil gebaut und das Ergebnis mit Inkscape verfeinert. Das kannst du dann beliebig weiter verarbeiten. In der Richtung bin ich schon unterwegs. Vorerst nur für speziel ausgesuchte Wanderungen, die dann allerdings Kartentechnisch sehr ins Detail gehen. Problem ist der ständige Fluss der Daten und die extrem schwankende Quallität. Wo du in dem einen Ort schon bestens mit anderen konkurrieren kannst, musst du woanders erstmal auf Daten warten. Dazu kommt das man die Daten nie so wird nehmen können wie sie aus der DB kommen. Man wird immer nahe, doppelte oder ungünstig platzierte und viele andere Sachen nachkorrigieren müssen. Es geht aber. Aber noch schwieriger ist es deine Sachen dann auch an den Mann zu bringen. Bei uns nutzt man beispielsweise fertige Karten von einem Verlag und nachbearbietete Luftbilder vom LVA. Da bestehen Verträge, es klüngelt und Fördertöpfe gehen um. Wenn da nicht unbedingt jemand sitzt der OS freundlich ist und ein offenes Ohr hat, kommst du da garnicht rein. Hier bei uns ist das z.B. garnicht der Fall, weswegen ich bereits schon mit Leuten aus dem Nachbarkreis zusammen arbeite. Ob und wie sich das überhaupt lohnt, muss sich erst noch zeigen. Davon leben können wird man sicherlich noch lange nicht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht der gemeldeteten Bugs von skob bler-Nutzern
Aufgrund der Vielzahl der Meldungen sind wir erstmal sehr erfreut über die Akzeptanz des Rückkanals. Auf der anderen Seite sehen wir, dass wir ihn ein ganzes Stück weiterentwickeln müssen, wenn das Feedback im bestmöglichen Maße zur Verbesserung des Karte genutzt werden soll. Ist auch wirklich nötig. In meinem Kerngebiet gab es bis jetzt noch keine Meldungen. Mag daran liegen, das hier keiner tot übern Zaun hängen will und nicht durch kommt oder es ist nichts aufgefallen. Um mich herum gibts dann vereinzelt welche, sind aber teilweise absolut nicht nachvollziehbar. http://beta.skobbler.de/osmbugs?zoom=14lat=51.46875lon=11.06735layers=B000T Da ist die relativ neue Autobahn und paralel läuft eine zur Landstraße abgestufte Bundestraße. Was will der Melder damit sagen? Offensichtlich ist da null. Kann sein das er sich auskennt, ihm desshalb bekannt ist, das man auf der parelelen Landstraße teilweise sogar schneller ist. Nur ist das dann kein Bug. Und ich mache auch nicht beim Verkehrsbedeutungsroulette mit. Oder er wollte da in ein Nest und wurde herum gleitet. Man weiß es nicht. Da müssen klarere Meldungen her. In der Form kann man nichts machen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (was : skobbler-Update mit OSM ist live)
PS: Abbiegespuren sind häufig baulich getrennt, oft durch Fußgängerinseln. Diese könnte man evtl. verkehrwiderrechtlich bzw. mit Sonderrechten auch mit dem Auto überqueren, sofern keine Leitplanken, Stahlrohrrahmen o.ä. dem entgegenstehen, und dafür bräuchte man dann eine Relation. Wie will man denn allen Ausnahmen von der Regel gerecht werden? Klar kann man dafür wieder irgendeine Realation neben der Relation in der Relation machen. Nur wer setzt das letztendlich tatsächlich um und vor allem wer will das Pflegen? Das Strippenmodell ist für genaues mappen einfach zu dünn. Das reicht für simple Fälle wie Straße von A nach B, versagt aber schon bei so einfachen Fällen wie 2:1 oder einseitige Überholverbote etc. Und wenn es ganz kompliziert wird gehts rätseln los. Aber wenn ich wirklich das umsetzen will was ich sehe, muss ich das auch so beschreiben und darstellen können. Das passt so irgendwie nicht. Auf der einen Seite hätte man am liebesten jegliche Möglichkeit abgedeckt, hat dafür aber nur den Minimalkonses an Darstellungsmöglichkeit. Hier mal so ein ganz simples Ding. http://osm.org/go/0MEAePiSJ Landstraße kann du gerade und links weg, rechts grüne Pfeil Spur mit Zebra. Das gleiche nochmal mit der Bundesstraße von Süden her. Da hast du dann die Wahl es entweder ganz einfach zu halten und ein Kreuz zu machen, unterschlägst aber damit wieder Geografische Informationen und solche wie beispielsweise grüner Pfeil. Oder man macht so eine Krücke wie es jetzt ist. Beides nicht gerade Prall. Wie macht man es nun richtig? Im Anhang mal ein Skizze der eigentlich simplen Situation. Kannst ja mal einen Vorschlag machen der Darstellbar ist, geroutet werden kann, einer Geodatenbank würdig ist und solche extra Bratwürste wie Rettung berücksichtigt. Gruß Mirko attachment: kreuzung.jpg___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiete/Landschaftsschutzgebiete
Wenn sich OSM flexibler aufstellen würde und mit solchen NC-Lizenzen zusammenarbeiten könnte, stünden nützliche und enorm große Datenmengen zur Verfügung. Da verbaut sich OSM mit seiner extremen Haltung selber den Weg. Wie willst du das Problemen denn lösen, das Daten die nicht kommerziell genutzt werden dürfen nicht doch auf dem falschem Angebot landen? Du kannst sowas nicht fest flaggen und in gerenderten Kacheln ist das erst garnicht ersichtlich. Das lässt sich egal wie nicht direkt in die OSM Daten bringen, da bleibt nur seperate Haltung und Nutzung. Und das geht doch auch heute schon. Du kannst die Daten als eigenen Layer in eigener Verantwortung darüber einblenden. OSM ist in der hinsicht fexibel das die Daten frei sein müssen und damit auch frei genutzt werden können, mehr geht ja eigentlich nicht. Für NC müsste man sich eher selber beschränken. Und es wäre ehrlich gesagt eher hinderlich, wenn man bei jedem Datensatz wieder irgrndwie auf irgendwelche Sondernutzzungsrechte aufpassen müsste. Eine DB, eine Lizenz und für alles weitergehende ist der jeweilige Anwender zuständig. Und ehrlich gesagt ist so ein NSG schneller vor Ort erfasst, als das man nicht kompatible Lizenzen ewig beweint. In der Zeit die es braucht so eine Lizenz entsprechend zu ändern, hast du das schon 10 mal auf anderem Weg erfasst. Im Moment haben wir ein ganz anderes Problem. Die Fläche eines NSG oder LSG hast du schnell anhand der Schilder erfasst, schneller als eine Recherche nach einer entsprechend freien Karte erfolg hat, kannst das aber noch nicht richtig eintragen, weil die entsprechenden offiziellen Grenzdefinitionen noch immer nicht vorliegen. Einzig offiziell ist ja diese nature_reserve Fläche, welche keine weitere Unterscheidung zulässt und wo man die eigentliche Landflächen drüber pappen muss. Oder man misbraucht den National Park, was aber auch wieder nicht richtig ist und was zudem auch viel zu promienent dargestellt wird. Für erste brauchts also endlich mal offizielle Grenzgeschichten die dann auch vollständig unterstützt werden. Daten sammeln kann man viel, auch bestens ohne irgendwelche NC Geschichten. Bringt aber nicht viel, wenn man die dann mangels vernünftiger Beschreibungsmöglichkeit nicht wirklich in die DB eintragen kann oder Tags verbiegen muss bzw. durch nicht unterstützte tot in der DB vergammeln. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Betitelung historischer Gebäude
oftmals gibt es Gebäude die historische einmal eine Bedeutung hatten und heute noch eine Tafel tragen. Wie taggt Ihr diesem ?? Ht sich irgendwas geändert was wieder nicht dokumentiert wurde, oder warum nimmt man dafür nicht mehr das einst dafür angedachte old_name? http://wiki.openstreetmap.org/wiki/DE:Key:name addr:housename ist doch dafür komplett verkehrt. Das ist für Fälle gedacht wie z.B. benamste Gebäude innerhalb einer Adresse. Wie Halle A, Haus Aqua etc. Oder da wo es nur Namen gibt welche dann die Hausnummer ersetzen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Betitelung historischer Gebäude
Bei Einsiedlerhäuser gibt es sowas durchaus auch in Deutschland. Ja sowas, wie bei Forsthäusern usw. vereinzelt mal. Und man kann, nicht muss, beispielsweise bei einem Gelände mit offiziellen Hausnamen sowas angeben. Manche Unis haben z.B. solche Hausbezeichnungen. Das habe ich beispielsweise ab und an wenn ich etwas aus der Fernleihe zurück schicke und der Laden seine Bibo irgendwo verteilt hat. Da stehts auch als Rücksendeadresse mit bei. Historische Bezeichnungen haben da aber nur wenn wirklich offiziell gebräuchlich was zu suchen. Das taucht dann ja in einer entsprechenden Adressanwendung mit auf. In dem Fall würde dann folgendes ausgegeben: Volksbank Traveland eG Altes Rathaus Flensburger Straße 21 25899 Niebüll Finde den Fehler... Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Betitelung historischer Gebäude
Das trifft es meiner Meinung nach nicht. Es gibt in meinem Heimatort verschiedene Häuser, die auch heute noch einen Namen haben, der von der Nutzung abweicht. Und führen diese Häuser diesen historischen Namen noch ganz offiziell nach außen? Wenn nicht ist ein historischer Name auch nichts für eine aktuelle Adresse sondern eine historische Bezeichnung für den entsprechenden Tag. name=Volksbank addr:housename=Altes Rathaus Das ist aber nicht die Volksbank altes Rathaus sondern die Volksbank Kuhbläke eG. Und die wird das alte Rathaus mit 99% Sicherheit nicht mehr als offizielle Adresse führen. Ein anderer Fall wäre name=Seniorenwohngemeinschaft Haus Allhoff addr:housename=Haus Allhoff So heisst das Haus seit mehreren hundert Jahren und der Name wird noch immer benutzt. Da gibt es keinen old_name. Doppel Moppel, Hausname ist da doch schon im offiziellen Namen enthalten. addr:housename würde dann Seniorenwohngemeinschaft Haus Allhoff oder kurz Haus Allhoff lauten, wenn das Haus keine richtige Adresse mit Nummer und oder Straße hätte. Wäre in dem Fall aber nichtmal nötig, weil das schon redundant ist. Und dieser Name mag zwar keine offizielle Anschrift der Post sein, wird aber im Ort benutzt und jeder weiß direkt, was gemeint ist. Von daher ist addr:housename meiner Meinung nach korrekt. Denkfehler, du mappst nicht für dich und deine Nachbarn, sondern für diejenigen die sich eben nicht auskennen und das finden sollen. Und denen hilft die Info wie der Volksmund das Dingen vor Ort nennt nichts. Hier sagt man auch noch zu vielen Dingen Konsum (Einkaufsladen), LPG (Agrarbetrieb) oder sowas in der Art. Das ist aber mehr so ein lokaler Insider, der in der Adresse nicht hilft und wo ein nicht Ossi auch teilweise wie eine Kuh bei Gewitter gucken dürfte. Agrar Adorf GmbH LPG Wilhelm Pieck I Straße der DSF 1 06637 Stummsdorf Die Lacher hast du damit auf deiner Seite. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Betitelung historischer Gebäude
Wir müssen zwischen Haus und aktueller Nutzung unterscheiden. Das HAUS kann keinen Namen führen, es besitzt einfach einen, vollkommen unabhängig davon, was die Leute treiben, die da aktuell drin sind. Du hast doch verschiedene Name Tags. Das hat doch aber nichts mit der Adresse zu tun. addr ist für die postalische Anschrift und da haben keine lokalen Bezeichnungen oder wie auch gerne genommen Telefonnummern oder sonstiges drinnen zu suchen. Die Kiste mit Haus und Nutzung ist doch ein generelles Problem. Du hast das Gebäude, kannst dem Gebäude aber keine eigenständigen Subeigenschaften anhängen, musst das wieder über POIs lösen und das alles wieder mit meinetwegen einer Relation zusammen frickeln. Machen aber die wenigsten, die POIs werden meistens nur darüber ausgekippt. Die Situation finde ich auch häßlich. Aber solange die entscheidenen Leute sich weiterhin auf die für Otto normal zu schwierigen Relationen ausruhen bzw. die nicht so in die Editoren einbauen, das es so einfach ist wie einen Schlüssel zu setzen, wird sich da auch nichts ändern. Das ist richtig. Trotzdem besitzt das Haus den Namen und ist auch unter diesem bekannt. Lokal ist das unter altes Rathaus bekannt. Aber das interessiert doch auswärtige nicht, wenn er nach der Adresse sucht. Das ist nur für die Adresse relevant, wenn diese Bezeichnung beim anschreiben tatsächlich benötigt wird. Ansonsten gehörts nicht in Adressetags. Aber der Name Haus Allhoff hängt am Haus. Dass da eine WG drin ist, die den gleichen Namen trägt, ist nur Zufall. Die könnte auch Senioren-WG Alice Schwarzer heissen. Hätte, könnte tralala. In dem Fall heißt die Einrichtung so wie das Haus auch ursprünglich heißt. Da ist es wumpe ob das nun im name oder housename steht, Haus Allhoff wird so oder so gefunden. Wie die hätte heißen können interessiert doch keinen. Es ist nunmal das Seniorenwohnheim Haus Allhoff im Haus Allhoff. Ist doch das gleiche wie wenn man folgendes machen würde. building=train_station railway=station name=Bahnhof Adenau addr:housename= Bahnhof In der Information hast du praktisch 4 mal die Information Bahnhof drin. Nein, die Seniorengemeinschaft ist nur ein Nutzer. Was, wenn da noch ein zweites Geschäft drin wäre? Das Haus heisst weiterhin Haus Allhoff Siehe oben. Eine Postagentur mit Postbank im Rahtaus geht auch nicht, 3 mal amenity und damit muss ich zwei Sachen sowieso auslagern. Völlig andere Kiste und hat nichts mit der Adresse zu tun. Nein, ich mappe, was da ist. Wer da hinterher was von hat, ist sekundär. Und ich versuche die Tags so zu wählen, dass sie am besten passen. Logisch mappst du was da ist. Aber solange die Volksbank nicht ganz offiziell unter Altes Rathaus angeschrieben wird, hat das nichts im Housename zu suchen. Es gehört nicht zur postalischen Anschrift. Dafür kannst du old_name, loc_name oder reg_name nutzen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausfahrtbeschilderung/Wegweiser für Navi gationsanweisungen
Bisher habe ich noch keine Systematik entdeckt, wie man solche Wegweiser oder Abfahrtbeschilderungen in OSM hinterlegen kann. Hat sich schon mal jemand damit beschäftigt? Nicht direkt dafür aber an anderer Stelle für Wegweiser. Ich liste die Ziele einfach mit destination:1=Ziel1 12 km destination:2=Ziel2 6 km usw. auf. Das lässt sich sicher leicht auslesen und späte auch mit from to via richtungstechnisch erweitern. Musst dann eben auf die juntion taggen und diese dann entsprechend danach auswerten. Hier mal ein Beispiel für den Fall Wanderwegweiser wo ich das in meiner Ecke so andwende. http://www.openstreetmap.org/browse/node/360327668 Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausfahrtbeschilderung/Wegweiser für Navi gationsanweisungen
Das hilft aber nur, wenn klar ist, dass :1 auch immer oben zu stehen hat auf dem Schild bzw der am größten beschriftete Ort für diese Richtung ist. Aber wie tagt man denn die Richtung? Gefragt war doch auch erstmal nur eine Möglichkeit die Ziele an der Anschlussstelle zu hinterlegen und die dann irgendwie auszuwerten. An welcher Stelle und wohin ist doch für eine Ansage oder ein Bildchen erstmal unerheblich. Da erscheint dann an Anschlussstelle 16 die Astadt 10 km. Dafür reicht so eine simple Liste dicke aus. Richtung ist wieder eine ganz andere Kiste. Und dafür gibts ja diese Realation. Nur nutze ich die selber für meine Fälle aus gutem Grund nicht. An manchen Wegweisern hast du gerne mal an die 20 Ziele. Da brauchst du für jede wieder eine eigene Relation. Ich habe bisher so an die 500 Wegweiser mit Zielen in der Art eingetragen, im Schnitt 5 Ziele. Macht ca. 2500 Relationen um die Ziele zu beschreiben. Geht da mal ein Wegweiser verloren ist der schnell zurück geholt oder die Version geändert. Fliegen dir die Relationen um die Ohren dann hast du ein Problem. Ja, ehemalige Relationszugehörigkeiten können 10 Experten auf der Welt über zig Gigabyte Planet und ein halbes Rechenzetrum zurückholen. Hast du aber die Nummern nicht alle irgendwo dokumentiert, was ich peröhnlich bei der mitlerweile riesen Menge die ich da betreue und trotz sparsamen einsatzes nicht mehr wirklich voll überblicke, kannst du als Mapper von vorne anfangen. Relationszugehörigkeiten sind auf den für einfache Mapper erreichbaren Tools nicht dokumentiert. Solange es da nicht einfacher wird, gehe ich den einfacheren Weg und warte auf eine Lösung die anwenderfreundlich und auch leichter zu pflegen ist. Die Eigentlichen Ziele sind ja schon hinterlegt. Für den Rest liegen die entsprechenden Bilder parat, ist nach ein oder zwei Tagen nachgerüstet. Anyway, einen Fahrspurassistenten bekommt man damit aber so oder so nicht hin. Wirst du in OSM auch lange warten können. Dafür müsste die Abbildung der Straße ansich erstmal grundlegend mehr hergeben als nur eine simple Strippe, aus der man alles mit monströsen Tagketten rauszupressen versucht, gleichzeitig darf man das aber nicht wieder einfach nur auf relation type X abwälzen, wo sich wieder alles nur in einem kryptischen relationsfenster absspielt. Und was vor allem wieder nur ein Editor wirklich richtig kann. Das kriegt man doch heute schon teilweise Würfelhusten. Die Straßen sind förmlich in streifen geschlagen, dutzende Relationen hängen dran. Von der Buslinie bis zur Abbiegeregelung. Da bete ich jeden Tag das nicht irgendein Anfänger in der Nähe hustet. Erste Amtshandlung ist immer der Blick auf History und ITO. Da geht eigentlich wöchentlich irgendwo was krachen. Wenn man das auf die art noch weiter ausweitet dann gute Nacht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] die strassenliste kommt ja so langsam ins rollen.
Die Struktur scheint in RLP und dem osten noch wesentlich kleiner zu sein und die Verbandsgemeinschaften bilden von der größe her das, was z.b. in NRW die Gemeinden sind. Hier im osten gibts garnicht soviele Verbandsgemeinden. In Sachsen-Anhalt haben beispielsweise voriges Jahr unsere Nachbargemeinden die erste überhaupt in SA gebildet. Auch nur aus Zwang, weil man dort die Verwaltungsgemeinschaften abgeschaft hat. Ansonsten hat man dort viel eingemeindet. Das hat dann auch wieder so seine Nachteile. Die Fläche unserer Kreisstadt hat eine Fläche so groß wie die der Landeshauptstadt. Das ganze ist aber so zersiedelt das 80% davon nur Natur ist und die Wege länger werden. Wenn du da vom Außenposten zum Amt musst, sind das gleich mal 20 km. Hier in Thüringen siehts anders aus. Wer kann bleibt selbstständig, tritt dann nur der Kosten wegen in eine VG ein. Wird sich aber auch ändern, jedes Jahr geht in fast jedem jedem Ort 1% der Einwohner verloren, die VGs sollen auch hier weg. Intern wird schon oft gestritten wer wen fressen soll. Hier sind die eigenständigen Nester mit 100 Seelen und einem Straßennamen noch vollkommen normal. Da brauchst du gleich garkeine offizielle Straßenliste. Hier ist es aber leider auch normal das in nach der Eingemeindung noch dutzende doppelte Straßennamen bestehen bleiben. Dewegen auch immer öfter mal die Kritik mit dem Routing oder Suche nur anhand eines Gemeindegrenzpolygons. Das geht in vielen Fällen ohne genaue Ortsteilangabe in die Hose. Die Nester sind in der gleichen Gemeinde, haben die gleiche PLZ, der Ortsteil machts aus. Wie hübsch häßlich das ausgehen kann macht Google vor. Die gehen anscheinend nur nach PLZ. Und so erscheinen POIs aus unserer Stadt oft mal irgendwo 15 km weiter auf der Kuhbläke. Das Problem mit den vielen nestern kommt daher das in der DDR noch nahezu die Gliederung seit Kriegsende bestand. Wirklich jedes Nest war da noch eingens verwaltet. Die ersten richtigen Änderungen kamen auch erst 1994. Und so gehts kleckerweise weiter. Und so hast du auch heute noch Kreise mit bis zu 90 Gemeinden. Das hat aber einen Vorteil. Ich habe einst wie so vieles andere einiges Material aus dem Heimatkundeunterricht vor der Tonne gerettet. Daraus lassen sich alle Grenzen gut ableiten, muss nur die obsoleten ausklammern. Das ist aber eben wegen der der noch riesgen zersiedelung eine aufwendige rödelei, weswegen ich wirklich nur bei richig Laune Grenzen eintrage. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS/OSM-Konferenz: Anmeldung noch bis 26.Februar möglich
In der Liste hier wird oftmals empfohlen, bei Unstimmigkeiten erst einmal den Editierenden anzuschreiben. Da er aber dazu keine Zustimmung gegeben hat, wäre selbst dieses unzulässig. Folglich wäre es auch unmöglich, eine lokale Community insbesondere in ländlichen Regionen zusammen zu bekommen. Das würde ich den Hardlinern, die gegen den Spam mit allen Mitteln vorgehen würden, zu bedenken geben. Und genau für diese Kontaktmöglichkeit wurde das auch geschaffen. Da kommt alle 4 oder 5 Wochen mal was, manchmal auch länger nicht, wenn man irgendwo unterwegs ist. Da gehts dann um konkrete Dinge aus der Mappingpraxis oder eine konkrete Anfrage von Nutzern. Etwas anderes sind dann wieder irgendwelche Rundmails ins blaue, die nichts damit zu tun haben und für die man sich vielleicht auch garnicht interessiert. Mich interessieren z.B. solche Kneipentreffen recht wenig, das nächstgelegene steigt glaube irgendwo 60 km entfernt, ist mir ohnehin auch so bekannt. Mit denen habe ich nur insofern soviel zu tun, das wir an einer großen Karte basteln. Wir werden uns aber schon aufgrund der Entfernung und Ausrichtung auf nicht absehbare Zeit nie in der Praxis schneiden. Und irgendwelche trockenen Konferenzen mit Vertreterschalträgern sind auch nichts für mich. Die Rumfahrerei kostet ja auch wieder und so dicke habe ich es lange nicht. Da lieber treffe ich mich mal gleichgesinnten und krauche im Gelände herum. Bei mir zählt schlicht Nich quatschen, machen!. Kontakte laufen auch so, dann eber eben peröhnlich über den Kontakt und dann geht es auch nicht ins blaue um Ringelpiez mit Anfassen sondern um konkrete konstruktive Ziele in der täglichen Praxis, bei denen man dann eng zusammen arbeitet und die sich wirklich lokal oder regional abspielen. Da trifft man sich dann auch mal Ort unter vier oder sechs Augen. Sowas ergibt sich ganz von selbst, vor zwei Tagen war gerade erst wieder jemand bei mir. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS/OSM-Konferenz: Anmeldung noch bis 26.Februar möglich
Hm, also ich zumindest hatte schon oefters mit Deinen Daten zu kaempfen, als ich mich mit Multipolygonen beschaeftigt habe. Die sind zum Teil ziemlich, wie soll ich sagen, kunstvoll ;-) Und? Ich habe bis dato nicht eine PM von dir erhalten. Zu dem Thema eigentlich von garkeinem. Wenn es da Probleme gibt dann musst du den Mund aufmachen. Was da in irgendwelchen Hinterzimmern an Problemen kommt, kann man nicht riechen. Wenn es keiner anspricht dann kann man auch nichts verbessern. Genau das meinte ich mit kunstruktiven wirken. Du hast offenbar eine verzerrte Wahrnehmung von Konferenzen im Open Source-Bereich - oder auch gar keine Wahrnehmung; auf welchen warst Du denn schon? Open Source noch nicht, aber einige andere. Deine Vorurteile seien Dir gegoennt, aber sei so gut und beleidige nicht die, die sich bei der Vorbereitung und Durchfuehrung einer solchen Konferenz engagieren, indem Du diese abwertenden Vorurteile hier in die Weltgeschichte hinausposaunst. Ich habe lediglich geschrieben, das ich trockene Konferenzen mit Vertreterschalträgern nicht mag und die soweit meide und desshalb auch keine automatischen Einladungen dazu möchte. Das war weder eine Beleidigung noch ging das gegen irgendeine bestimmte Veranstaltung oder irgendwelche Leute die irgendwas vorbereiten. Das war schlicht meine persöhnliche Meinung die generell das Thema Konferanz betrifft und da lasse ich mir auch den Mund nicht verbieten. Den Schuh hast du dir jetzt selber angezogen. Ganz dein Problem. Statt wie ein getretener Hund zu jammern, hättest du nun beispielsweise aufklären können, das es konkret bei euch lockerer zugeht oder sowas in der Art. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telefone ohne Geldannahme
es gibt vom Pink-Panther Telefonsäulen [1] ohne Dach und ohne Währungsannahme von denen nur eine 0800er-Nummer angerufen werden kann und SOS-Rufe getätigt werden können. Wie schon mehrmals auf der Liste gepostet... Das ist ein Basistelefon, der Telefonzellenersatz in umsatzschwachen Gegenden. Hier auf dem Land die einzig noch verbliebenen öffentlichen Telefone. Die werden mit T-Card, Calling, Kredit usw. gefüttert. Steht auf den Teilen auch ausführlich drauf. Hat nichts mit Notruf oder 0800 zu tun. Beides sind nur die üblichen Grundfunktionen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS/OSM-Konferenz: Anmeldung noch bis 2 6.Februar möglich
Es geht hier um Massenmails die für eine Veranstaltung innerhalb des Projektes werben zu dem sich der Benutzer selbst angemeldet hat! Derzeit gibt es den Schalter Informiere mich über Veranstaltungen noch nicht, aber ich finde, dass man den im Rahmen einer Anmeldung durchaus per default auf on schalten kann. Nur weil ich mich anmelde, will ich nicht per default aus jeder Ecke in der ich zufällig mal was mache irgendwelche Informationsmails oder Einladungen bekommen. Wenn du dich an irgendwelchen Fix Aktionen beteiligst und nicht nur auf das vor deiner Haustür konzentrierst, hast du ganz Fix sämtliche Einladungen von Lampukistan bis Wanne-Eikel im Kasten. Ist ja schön, wenn der Husumer Stammtisch an mich denkt und zur Mapping Party nach Tönning berufen möchte. Nur wird es nie passieren, das ich mich 8 Stunden in die Bummelbahn setze und dort antrete. Wenn ich wider erwarten mal die Zeit und Bock habe zu so einer Veranstaltung zu kommen, dann informiere ich mich schon selbst danach, bzw. mache aktiv ein Häkchen. Osnabrück wäre auch schon wieder aus meinem Interessenkreis raus. Vielleicht wenn man sich mal für Leipzig oder Erfurt entscheidet. Randholland ist zu weit. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telefone ohne Geldannahme
Wer lesen kann ist klar im Vorteil ;-) Ebenso wer googeln kann. http://mwl.telekom.de/produkte/pdf/OeTel_Basistelefon.pdf Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen vonkommerziellen Verwertern der OSM Daten?!?
OSB ist *ein* Klick an die richtige Stelle auf einer normal dargestellten Karte. Keine Account-Registrierung, kein ruckeliges Flash, keine merkwürdig andersfarbigen Linien. Genau dafür ist OSB doch da. Wenn jemand Potlatch nutzt und versehentlich Dinge kaputt macht, kommt hier doch gleich wieder die Vandalismus- und Sperr-Dikussion. Lasst die Leute die keine Zeit oder Motivation haben sich einzuarbeiten doch einfach OSB nutzen. Für einen Mapper mit etwas Erfahrung ist es ja nur eine Sache von unter einer Minute, die Reports einfach umzusetzen. In dem Fall geht das ja noch durch. Trotzdem hilft mir das in dem Punkt wenig. Was in meiner Ecke fehlt weiß ich selber. Was ich brauche ist keine Strichliste die mir das offensichtliche nochmal bestätigt, sondern mal eine helfende Hand, die meine 2 Milliarden Punkte umfassende ToDo mit abarbeitet oder wenigenstens entgegen kommt. Da ist ein Bäcker! hat keinen Wert. Eine hilfreiche Meldung wäre, wenn z.B. im Comment gleich mal einige Eckpunkte mitgeliefert würden. Das kann man dann gerne für Nicht Mapper eintragen. Aber ohne alles ändert sich nichts, es würde so oder so eingetragen, wenn die Ecke mal dran ist. Ich fahre nicht wegen einem einzelnen POI los. Wenn muss das auf der geplanten Route liegen, oder der Ort ist als ganzes dran. Ich mache einmal ein Raster gründlich von A wie Adresse bis Z wie Zaun. Die nächste Tour geht dann in komplett unerfasstes Gebiet. Dann habe ich die Daten zuhause und mappe je nach Laune das was gerade Spaß macht weg. Übrigends betraf das Beipiel zufällig keinen externen reinen Anwender. Manche geben da ihre Nicks an. In dem Fall war es einer der auch mappt, allerdings am anderen Ende der Republik. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern von Seezeichen und Editor
PS: die üblichen JOSM-Vorlagen können die komplexen Regeln der Seezeichen nicht abbilden, und bei der Eingabe auch nicht prüfen. Deshalb wurden die beiden Editoren geschaffen. Damit auch Nicht-OSMer (oder OSMer ohne nautische Erfahrung) simpel und korrekt Daten eingeben können. Kunststück, dazu müsste man in OSM erstmal eine Dokumantation aufstellen die den Namen auch verdient. OSMer sind nicht bescheuert, nur wenn man denen nicht zeigt was wie auszusehen hat, kann das natürlich auch nichts werden. Was in OSM eingetragen wird, muss aber gerade zuerst auf OSM ersichtlich sein. Ansonsten muss ich mich dann nicht wundern, wenn jemand sowas aus versehen kickt. Andersrum können eure Editoren vieles nicht was man in OSM daneben eintragen kann. Und genau dann kommts dazu das die Dinger Informationen von OSM Seite her zerlegen oder das irgendwelche Doppeleinträge entstehen. Wie dem auch sei. Wenn man auf der OSM DB arbeiten möchte dann muss das egal von welcher Seite problemlos möglich sein. Ohne das man sich auf zwölfunddreißig extra Seiten anmelden und deren Funktionsweise studieren muss. Die Anwendungen sollen auf OSM aufbauen, nicht umgekehrt.Wenn man exclusiv mit eigenen Tools arbeiten möchte dann geht das nur auf einer eigenen DB, ansonsten wird immer irgendwas schief laufen. Wenn ich in JOSM auf soetwas stoße, dann muss es möglich sein im Wiki nachschlagen zu können was es bedeutet. Und da ist es auch wurst ob das nun nach Ilala, Knut, Inga oder Brunhilde Verordnung eingetragen wurde. Das muss auf OSM nachvollziehbar sein, genau wie das unter den bestehenden oder vielleicht noch kommen Seekarten unteinander funktionieren muss. Nicht kann sondern wirklich muss. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
mich würde mal interessieren, wie Eure Motivation steht, Bugs in den Daten, die von Usern aus einer kommerziellen Anwendung wie skobbler gemeldet werden, zu beheben. Wie seht Ihr diese kostenlose Hilfe von Freiwilligen zur Umsatz- und Wertschöpfung eines Unternehmens wie Skobbler, speziell durch ein zahlende-User Geschäftsmodell? Da sehe ich keinen Unterschied zu anderen Bugmeldeseiten. Was an Datenfehlern passiert wird ohnehin schon beim bearbeiten mit abgefrühstückt. Doppelte Nodes usw. Sowas kommt gleich garnicht in die DB. Aber ich würde jetzt nicht extra losziehen um irgendwas zu überprüfen was irgendwer irgendwo bemängelt. Das macht man wenn es passt und man zufällig vorbei kommt. Auf solche Seiten gucke ich vielleicht alle 4 bis 6 Monate. Ganz hinten stehen beispielsweise so Einträge wie teilweise bei OSB Da ist ein Bäcker!. Da frage ich mich dann auch. Typ, du standest davor, hättest alles was man Eintragen kann notieren können, hast dir die Mühe gemacht das hier einzutragen. Warum zu Hölle hast du nicht gleich selber einen POI gesetzt und warum muss ich jetzt meinen Kadaver für dich dahin schleifen? Und das bleibt dann halt liegen, bis der Tag kommt, wo ich zufällig mal vorbei komme. Das kann dann halt auch mal ein Jahr dauern. Wem das zu langsam geht muss halt selber hin, oder zahlt halt Fahrgeld. Und genau nicht anders ist das mit kommerziellen Bugmeldungen. Die können da Buglisten ohne Ende erstellen. Es ist doch keiner verpflichtet das abzuarbeiten. Das bereinigt sich dann von selbst. Wenn sich nicht genügend Dumme finden welche die Arbeit machen, quilt deren Bugmelder irgendwann über und die Funktion erledigt sich nach genügend Kritik von selbst. Denn das kreidet keiner OSM an, sondern dem Laden der es anbietet. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Topomapper
XP-Home in der Sandbox geht auch. Auf zwei anderen XP-Rechnern geht's nicht. Weiss der Henker, was die da machen. Auf XP funktioniert die Seite bei mir einwandfrei unter IE 8, FF 3.0.18 und FF 3.6. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenlistenabgleich - jetzt in Selbstbedienung
Woa - was ist das denn - mehrere outers - Ich halte die relation allerdings fuer broken - Es gibt eine grosse Outer - dann mehrere inner - und dann innerhalb einer der inners dann noch ein outer - Mal davon abgesehen das ich das ganze thema outer/inner nicht wirklich handle ist das aber nur mit mehreren relations abzuhandeln - wie das allerdings mit boundarys funktionieren soll *kratz am kopf*. Mehrere Outer sind doch nichts seltenes. Beim INFAS Import und der tollen Idee da Multipolygone draus zu machen hat man das Problem nur nicht so auf dem Schirm gehabt. Die Daten waren teilweise stark vereinfacht, Ex- / Enklaven oft erst garnicht mit drin. Wenn ich nach den mir bekannten Ecke gehen dann fehlten die komplett. Die kamen erst wieder nachdem, wie bei mir, bereits gut erfasste Grenzen wieder repariert wurden un die Ex- / Enklaven wieder nachgetragen waren. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassensuche in der Karte
... der dann ja wieder in Nominatim zurückfliesen könnte. Packt das ganze doch erstmal auf eine besucherstarke Seite und loggt die Fehler mit. Damit kann man dann erstmal die häufigsten Fehler nach und nach mitnehmen. Vor allem die auf welche man selber im Moment nicht gleich kommt. Alles andere wird man dann wohl später mit einem etwas umfangreicherem Wörterbuchvergleich erschlagen müssen, was dann bei Vertippern usw. Vorschläge machen kann. Eben so wie das normale Nutzer von den üblichen Seiten kennen. Oft sind nicht nur Abkürzungen das Problem sondern eben auch Vertipper oder falsche Schreibweisen. Bei uns z.B. Berthold Brecht vor Ort und in Straßenliste und diversen Onlinequellen aber auch als Bertolt Brecht zu finden. Wenn es die DB nicht kann dann wird man den Bertolt aus dem Branchenbuch nicht finden, die DB hat nur den Berthold. Und schon garnicht, wenn man sich ganz vertut und den Bertholt sucht. Ebenso beliebt ist Gerhart vs. Gerhard Hauptmann, Ried vs. Rieth usw. Mit einer simplen Ersetzung mit zig trilliarden Möglichkeiten stößt man sicher schnell an Grenzen. Für eine zielgerichtete Stadt ist das vielleicht noch drin. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassensuche in der Karte
Ist übrigens beides richtig, jetzt kommt es nur darauf an, was der wirkliche Name ist. Weiß ich doch, desshalb schrieb ich ja das Berthold auf den Schildern steht, aber in manch Veröffentlichung und sogar der Straßenliste der Bertolt auftaucht. Was da nun richtig ist da soll sich die Stadt drauf einigen, nicht unser Problem. Das Problem ist aber das ich in der DB nur die Berthold-Brecht-Straße habe. Suche ich aber bei OSM im gesuchten Ort nach Bertolt oder dem Fehler Bertholt (bei solch heute nicht mehr gebräuchlichen Namen nicht selten) dann schweigt sich die Suche bei OSM einfach aus. Da fehlt noch eine Lösung die das wie bei anderen Diensten entweder automtaisch per Wörterbuch korrigiert oder Vorschläge macht. Mit dem simplen ersetzen von einfachen Abkürzungen ist es daher lange nicht getan. Und jetzt bitte keine wenig witzigen Vorschläge wie Duden kaufen! einblenden. Das fruchtet in der Praxis genauso toll wie IE wird nicht unterstützt, lade bitte Firefox oder andere realitätsferne Geschichten. Das zieht bei 5 bis 10 Plätties, der Rest war zum letzten mal bei OSM oder verbreitet die Meldung das OSM doof ist. ;-) Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassensuche in der Karte
Normalerweise bin ich auch für Kompatiblität mit allen Browsern, aber bei meiner Openlinkmap sehe ich es nicht ein, alles umzuprogrammieren, nur weil der IE das nicht versteht, sowohl CSS als auch Javascript, wo doch alle anderen Browser (Firefox, Opera, Safari, Konqueror, Arora, Iceweasel, Epiphany) überhaupt keine Probleme haben. Nur weil MS keine vernünftige Software zustanden bringt, muss ich nicht noch versuchen, das dazu komatibel zu machen. Vorweg, bitte Quote wenigstens mit einer Zeile Abstand. Ich habe nichtmal was gegen Tofu, aber wenn der Text nichtmal mit wenigstens etwas Abstand zwischen 2 Meter Text liegt, braucht man dann erstmal 30 Minuten um deinen Text überhaupt zu finden. Zu deiner Karte, dein gutes Recht. Aber der IE ist noch immer mit Abstand der am weitesten verbreitete Browser. Muss man so hinnehmen, umerziehen funktioniert nicht mal eben. Ist mir auch ehrlich gesagt egal. Ich bin der letzte der jemandem seine Lieblingssoftware mit teils unsinnigen Argumenten aufs Auge drücken möchte. Ich könnte nichts böses darüber sagen. IE war bei mir bisher genauso Sicher wie jeder andere Browser auch. Die Sicherheitsvorkehrungen und der vor der Tatstatur machen es aus, nicht der Name oder die Firma dahinter. Wenn ich nun beispielsweise Werbung oder Anfragen für OSM mache, dann muss ich davon ausgehen, dass gegenüber eben ein IE läuft, der durch irgendwelche Arbeitsplatzlizenzen etc. sogar vorgeschrieben ist. Da kann man dann leider nicht mehr entsprechende IE Unfähige Seiten mitgeben. Da hilft es dann auch nicht auf den Firefox zu verweisen. Entweder können die nicht, oder da passiert in den meisten Fällen das gleiche wie früher mit den Für IE optimiert Seiten bei Anhängern anderer Browser. Die haben es auch nicht eingesehen mal eben den Bwrowser zu wecheln. Umgekehrte Situation heute, die man keinem krum nehmen kann. Also wenn es geht, den IE kann man noch nicht abschreiben. Das wäre so als wolle man ein wichtiger Autokonzern werden, vertreibt aber nur Autos mit LGP Antrieb. Das klappt vielleicht in 10 Jahren, nur heute schließt man so den Löwenanteil der potentiellen Nutzer aus. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Die Wege und Punkte liegen zwischen den normalen OSM-Daten im File und haben künstliche IDs im Bereich 11. Sie haben nicht die Tags ihrer Relation, sondern neue Tags, die Farben oder Wandermarkierung direkt beschreiben. Die Tags, die Du zum Rendern auswerten mußt, findest Du in Composer in der Tabelle der Renderregeln. Leider nicht ganz das was ich brauche. Da müsste erstmal ein ganzer Style her der an den eigentlichen Daten nichts weiter ändert, die eigentlichen Daten brauche ich eigentlich unverändert, nur die Roten brauche ich umgewandelt. Oder eben die Routen aus dem File fitzeln. Nur das dauert länger als die bisherige Methode. Bekommt man es irgendwie hin, das man alles ausser den Roten komplett ignorieren und verwerfen kann? Oder gehts das irgendwie über ein anderes Tool? Im Moment bleibt da ja anscheinend alles irgnorierte als ungetaggt liegen. Unnötiger Ballast der nur Rechenzeit kostet. Das müsste weg, so das am Ende nur die eigentlichen transformierten Roten über bleiben. Dann müsste man für diese Routen eben die vorhanden Schlüssel an die neuen Wege kriegen. Bein rendern selbst brauche ich nur name, ref und osmc:symbol am Weg, Wegfarbe wird bei hiking/foot automtaisch rot, bzw. grün bei bicycle. Auch automatische platzierung von Icons brauche ich nicht. Die muss man so oder so von Hand korrigieren, automatisch läuft das nie mehrheitlich zufriedenstellend. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fällt keine sinnvolle Begründung ein. Wenn die Seiten jeweils anders präsentieren oder nur einen Teil verwenden dann ist das ja kein Problem. Aber warum entwickelt man nicht ein gemeinesames Schema, das man dann auch propblemlos von OSM Seite her nachlesen und anwenden kann, damit auch problemlos von eventuell weiteren Anwendungen? Damit erübrigt sich dieses total sinnlose rumgeeiere und auch der reine OSMer muss sich nicht mehr über irgendwelche Eingriffe ärgern. Auch erübrigt das manch sinnlose Redundanz. Freietonne will z.B. bei Kontaktdaten an Schleusen ein waterway:lock:phone. Damit das auch alle anderen lesen können, muss man wieder ein extra phone setzen. Sicher ist es einfacher über den ganzen Dump einfach nach diesem Schlüssel zu suchen. Aber wäre es im nicht im Sinne von OSM, einfach nur phone für alle zu setzen? Da muss die Anwendung eben die relevanten Elemete wie eben in dem Fall lock vorfiltern statt nach Namensräumen über alles zu suchen. Man stelle sich mal vor andere würde das genauso machen. Irgendwann hat man die exakt gleiche Information unter zig Namensräumen in als x facher Kopie. Die Haupt DB wird sinnlos aufgebläht und bei einer Änderung steigt der Aufwand. Statt einmal phone zu ändern, muss man meinetwegen 20 Schlüssel ändern. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Vielleicht weil Composer immer versucht, 5 Kacheln parallel runterzuladen? Auf jeden Fall funktioniert es woanders. Ich weiß nun nicht wie das genau arbeitet. Vielleicht hängt er sich auf, weil er eventuell alle vorhandenen Netzwerkadapter abfragt und eben bei mehreren mit Fehlern bombardiert wird? Bei mir sind 3 davon im Einsatz. Einer nach draußen für Internet, einer intern der draht und drahtlos verteilt und einer der Daten über Sat reinholt. Letzte beide wären in dem Fall Sackgasse. Ich deaktiviere die mal und probiere es. Die *_realtion.osm sind in der Tat wurscht, die hat Composer schon ausgewertet. Man könnte noch die *_poly.osm dazumergen für Multipolygone, aber die scheint Kosmos nicht zu verarbeiten. War aber so schonmal ein automatisiserter Schritt mehr. Ansonsten musste ich die Relationen von Hand separieren. Oder entsprechend die XAPI arbeiten lassen. Ich würde sagen, wir reden noch aneinander vorbei, meinen aber das Gleiche. Der ganze, mühevolle Prozeß, den Du da beschreibst, wird von Composer bereits automatisch erledigt. Bis auf die Aktivierung von Multipolygonen, falls Kosmos die überhaupt kann. Das einzige Problem ist es jetzt noch, einen Satz Renderregeln zu haben, der die Wandermarkierungen richtig anzeigt. Die Frage ist, was muss man tun und wo findet man nun diese neuen Wege ohne ID, welche die Tags ihrer Relation geerbt haben? Das ganze reicht als normales OSM File, um es dann beispielswe per Osmosis mit Daten und SRTM verbinden zu können. Der Rest läuft über Osmarender automatisch. Renderregeln brauche ich in dem Fall nicht, die blanken Wege m,it den tags der Relation. Enstprechende Renderregeln samt Symbolen habe ich schon. Auch für die Wege die man bisher nur mit Text darstellen konnte. Alles fertig, es fehlen nur die Wege. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Menschliche. Die Mitstreiter können schlicht nicht miteinander. Nicht das Problem der OSM Datenbank und deren Community. Man hat ehrlich gesagt Glück das man hier geduldig und locker ist. In anderen Projekten hätte man beide schon ausgeschlossen. Sind wir jetzt schon soweit, Minderheiten rauszuwerfen? Ich hoffe nicht, denn dann bleibt von OSM nicht viel übrig. Minderheiten sind natürlich willkommen, wenn sie denn mit und nicht gegen arbeiten. Das liegt halt daran, daß es zwei Parteien gibt, die sich nicht einigen wollen. Dann haben sie Pech, die müssen nicht nur untereinander sondern auch mit OSM ansich klar kommen. Die Daten auf OSM sind für alle da. Nicht nur für Schnick oder Schnack. Wenn es nicht geht dann müssen die jeweils ne eigene DB aufziehen. Aber fangen wir jetzt an die Radwege rauszuwerfen, weil sich die Radfahrer nicht auf ein Schema einigen können? Ich hoffe nicht. Zwei paar Schuhe. Das ist eine OSM interne Taggingauseinandersetzung die sich irgendwann über die mehrheitliche Verwendung klären wird. Die beiden Seekarten sind jeweils ein externes Grüppchen, die ihre Nickelichkeiten der OSM Community aufzwingen. Die Tags sind ja nichtmal richtig für eine Verwendung direkt in OSM dokumentiert. Nein, man nutzt OSM als bequeme Kippe fürs eigene Steckenpferd. Der Arsch ist der OSM User der auf OSM arbeitet und dann zwischen den Kindergarten gerät. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Er würde uns im Gegenzug sämtliche seiner Daten zur Verfügung stellen. Diese enthalten Infos über die Anzahl paralleler Gleise, den Stand der Elektrifizierung sowie Infos, ob die Strecke bereits aufgegeben oder gar zurückgebaut wurde. Die Daten hat er hauptsächlich aus alten Kursbüchern sowie Bekanntmachungen der Bahn zusammengesucht. Hast du dir da schon Gedanken gemacht wie das dann in die DB kommen soll? Das und einige Informationen mehr hatte ich nämlich schon gleisgenau auf Strecken und Bahnhöfen in Teilen von Mitteldeutschland eingetragen. Das betraf die Thüringer Bahn zwischen Merseburg und Bebra, Großkorbetha - Leipzig, Bahnnetz in Leipzig, Leipzig - Chemnitz, weitere Strecken östlich und südlich von Leipzig und einige Strecken in Nord- und Mittelthüringen. Teilweise auch schon historisches dabei. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
1.) Mirko kannst Du mir ggf. die Rules zur Verfügung stellen ? Sorry, im Moment erstmal nicht. Die Entwicklung ist im Auftrag für jemandem mit Interesse an speziellen walking papers entstanden. Das soll mal mit für die touristische Vermarktung hier genutzt werden. Unsere sogenannte bürgerliche Kreisherrschaft ist schlicht zu doof oder klüngelt nur, weswegen man das nun verstärkt privat in die Hand nimmt. Das geht erstmal vor. Wenn der Stress da vorbei ist dann gucken wir mal. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Es gibt eventuell noch eine Variante, wenn es Dir um die Wanderrouten geht. OSM Composer führt ein genau so ein Preprocessing von OSM Daten durch, bei dem Wanderrouten und Wandermarkierungen in das OSM eingefügt werden. Normal werden die Daten dann an mkgamp übergeben, aber man kann diesen Schritt auch abschalten und etwas anderes damit machen. Ich lade sie in eine mapnik-Datenbank, aber Du könntest sie auch von Kosmos zeichnen lassen. Wenn du jetzt noch mitteilen oder am besten gleich dokumentieren könntest wie? Im Wiki steht da nichts genaues zu. Ich hatte das vorher schonmal probiert. Gebiet laden blieb schonmal stecken, nach 5 Kacheln wird die Netzverbindung quasi blockiert, hilft nur noch Composre abschießen. Lokales File ging, Garmin export ging, außer das er eine Datei irgendwie nicht anlegt. Eine *_realtion.osm liegt nicht in Data, im Prorgramm selber erscheint nichts im Fenster Routen. Also wie funktioniert das Preprocessing mit dem Composer eigentlich? So vom Programm her kommt nicht dahinter. Da haben sicher einige Interesse dran, allen voran diejenigen die Mapnik nicht nutzen können oder wollen. Da bleibt nur Relationen zu auswertbaren Wegen umwandeln. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Naja, das ist ja auch das erste mal, das jemand danach fragt - wäre sehr verwunderlich dazu schon ein Howto zu finden. :-) Zumindestens der erste der öffentlich fragt, dessen Frage auch beachtet wurde oder sich überhaupt traut zu fragen. Ich bin bei meinen Versuchen auf dutzende Probleme gestoßen. Einige davon unter anderem auch unbeantwortet im Forum liegend. Wenn ich hier mal durch bin dann versuche ich die gelösten Sachen mal für andere zu dokumentieren. Beispiel das Area Center mit Osmosis, hat mir hier bisher auch keiner drauf geantwortet. Mitlerweile hab ich es gelöst. Wenn du dir die Beispiele so anguckst dann steht da nichts von gewissen Clases die man mit aufrufen muss, oder beispielsweise die Pipe Geschichte beim mergen die sein muss, aber nur simpel ohne als Beispiel dasteht. Mitlerweile bin ich trotz grausamen Englisch und als Konsolennoob doch recht weit gekommen. Gewünschter Bereich wird mit JOSM geladen und als data.osm abgelegt, der Rest läuft fast komplett im Stapel. - Brauche ich Höhenlienen dann lasse mit bereits fertige srtm2osm Daten über Osmosis sortieren und mergen , ohne gleich Schritt 2 - Berechnung Area Center Hier leider noch eine Pause Da muss ich die Bounds Schachtel aus data.osm leider wieder von Hand einfügen. Osmosis kickt die leider, gibts eventuell einen Befehl der die wieder in den Output übernimmt? - Rendern - Bezierkurven berechnen - temporäre Daten entfernen Vorerst fertig und geschnittenes SVG für die Weiterverabreitung. Da soll wenn es geht dann noch eine Optimierung zwischen. Beispielsweise leere Definitionen aufräumen usw. Bis dahin läuft alles. Man muss eben dann noch von Hand etwas Nacharbeiten. Doppelte Bushaltestellen, verdeckte Schriften, zuviele ref etc. Das ist aber das kleinste Übel. Ersteres klingt nach Netzwerkproblemen beim Download. Die 0.81 hat leider noch ein (bereits behobenes) Problem beim Einlesen der Routen aus dem Komplettfile. Wenn Du die Option Ausschnitt aus... wählst, funktioniert es. Das ist ja im grunde das gleiche wie gestückeltes Daten nachladen in OSM. Da läuft das ohne Probleme. Nur hier im Composer nicht. Der macht 5 Kacheln und dann ist das ganze Netzwerk ausgebremst. Aber ansich kein Problem, mir gehts nur um kleine regionale Ausschnitte, kann man als File über JOSM holen und laden. Die Routen hat er jetzt auch erkannt. Also Symbole nachgetragen, Markierung gesetzt und gespeichert. Das Diagramm hast Du gefunden? http://wiki.openstreetmap.org/wiki/DE:OSM_Composer#Output Ja, aber funktionierte wie gesagt gestern nich, heute ja. Letztendlich kannst Du einfach die ganze Sektion für Garminausgabe abschalten und das Regionsname_data.osm für die Weiterverarbeitung verwenden. Das einzige was noch nötig ist, aus *_data.osm und *_routes.osm irgendwie wieder eine gemeinsame Datei zu machen. Die *_data.osm kann JOSM garnicht erst lesen Das Attribut 'version' für das OSM Element ID 2632366 fehlt. Die *_routes.osm kann er lesen, die beinhaltet aber nur die Relationen. Die kann ich aber nicht verwenden, ansonsten könnte ich ja gleich die Realationen aus der dem eigentlichen File rendern, macht Osmarender aber nicht. Da sind zwar auskommentierte Styles vorgesehen und man kann SchowRelation auf yes setzen, nur gerendert werden die dann trotzdem nicht. Ein riesen Problem wenn man die Routen aber auf der Karte braucht. KOSMOS ha ta auch einen Bug. der rendert Routes nicht komplett Du hast dann Wandermarkierungen und Highlighting von Routen als zusätzliche Nodes und Ways im XML, so daß sie mit jedem Programm gerendert werden können. Ja, die Frage ist wo? Vielleicht verstehen wir uns auch falsch und du meinst garnicht was ich brauche. Ich brauche praktisch die eigentlichen Member der Relation, aber nicht mit ihren eigenen wegbezogenen Tags, sondern blank ohne ID (Ansonsten hagelt es wegen gleicher ID Konflikte), mit den Eigenschaften bzw. Tags der Realtion selbst. Also route=hiking, name, osmc:symbol direkt am Weg. Diese so aufbereiteten Wege kann man dann über die eigentlichen Daten legen und entsprechend rendern. So kann man das Problem der nicht verabeiteten Relationen umgehen. Momentan mache ich das für jede einzelne Route von Hand. Relation separieren, Member laden, wegbezogene Tags löschen, die Mermale der Relation allen Wegen verpassen. Alles duplizieren, in neue Ebene kopieren um die IDs loszuwerden, das Wegepaket wieder auf die richtige Position schieben, File speichern. Danach alle Einzelrouten mergen und dann mit den eigentlichen Daten mergen. Das kann man mal machen, aber wenn sich Wege verschieben, Member ändern, muss man das für die betroffenen Routen jedesmal neu machen. Bei entsprechender Aktivität in den Daten wirst du irgendwann ramdösig. Desshalb suche ich einen Weg das ganze weitgehend automatisch zu verarbeiten Theoretisch wäre auch denkbar eine direkte Anbindung von Kosmos inklusive Renderrules wie für den Garmin einzubauen, falls das öfters mal
Re: [Talk-de] ref-Tags in Relationen und Wegsegmenten
gibt es irgendeinen Grund warum man die ref-Tags der einzelnen Wegsegmente zusätzlich zum ref-Eintrag in der Relation beibehält? Die Unfähigkeit mancher Renderer dies korrekt darzustellen sehe ich nicht als Grund. Klar kann man das wieder alles schön in Relationen packen und damit auch schön verkomplizieren. Gerne auch Namen etc. Aber, Wege kann ich direkt erfassen und auswerten, das wieder über Relationen nachzuholen ist bei jeglicher Auswertung wieder eine eklige Fummelei. Ist die Relation dann gleich Lückenhaft oder mal wieder ganz verloren, was alles andere als selten ist, ist die Information erstmal weg. Kenne ich die Ecke nicht und kanns nicht zuordnen, kann ich mit den Daten nichts mehr anfangen. Ist alles ausgelagert dann ist ref, name oder was sonst noch in einer Relation steckt weg. So eine Relation geht schnell mal kaputt, es passiert aber seltener das gleich massenhaft die Wege ansich verschwinden. Änderungen daran kann über die History wieder zurückholen. Ist die Relation higegen weg, weiß ich aber nichtmal in welcher der Weg mal steckte. Ehemalige Relationszugehörigkeiten werden nicht dokumentiert. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ref-Tags in Relationen und Wegsegmenten
Das ist nicht korrekt. Es ist nur etwas aufwendiger, an diese Information heranzukommen, aber da saemtliche historischen Informationen als eine grosse Datei herunterladbar sind, kann ich, genuegend Zeit und einen geeigneten Rechner vorausgesetzt, sehr wohl eine Liste aller Relationen produzieren, zu denen ein gegebener Weg je gehoert hat. Seht das doch bitte nicht immer aus der speziellen Sichtweise eines Programmieres oder Datenbankexperten. Wenn ich als normaler Mapper die Daten Pflege, habe ich nur die Mittel und das Wissen zur Verfügung was ich mit den Editoren, der Seite usw. geliefert bekomme. Als Mapper habe ich mitnichten ein Rechenzentrum samt Toolchain, Ringelsöckchen und Klingelsöckchen zur Hand und kann damit auch im Schlaf umgehen. Da habe ich die History auf der Seite oder in JOSM, die Rückstellmöglichkeit über Potlatch. Alles was Spezialisten da noch so im Hintergrund haben weiß ich dann nicht und kann darauf auch nicht zurückgreifen. Ist im Einzellfall auch wie mit Photonentorpedos auf Flöhe schießen. Wenn dann müsste es auch vorne in der History passieren. Kannst du gleich mal als Anregung für die nächste API anpinnen. Wenn ich als Mapper die ehemalige Relationszugehörigkeit nur über einen Doktor in datenbanktechnik heraus bekomme, ist der Aufwand so monströs riesig, das man zur Erkennbarkeit des Nutzens erst ein geeignetes Rasterelektronenmikroskop erfinden müsste. ;-) Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ref-Tags in Relationen und Wegsegmenten
Deswegen waere es voellig korrekt, zu sagen, dass ehemalige Relationszugehoerigkeiten nicht ohne weiteres einsehbar seien (oder eine aehnliche Formulierung). Die Aussage, sie wuerden nicht dokumentiert, ist aber unzutreffend; hier geht es um Fakten und nicht um Sichtweisen. Bis eben wars mir wie sicherlich 99% der Mapper nicht bekannt das sowas irgendwo mit Spezialwissen möglich wäre. Also ist es für die wenigen Spezialisten möglich, ok. Ändert aber nichts am Grundproblem. Und zwar das dies für die überwältigende Mehrheit nicht möglich ist und verschwundene Relationen in der normalen Mapperpraxis bei Unkenntnis über genaue ehemalige Zugehörigkeiten ein Problem bei der Geschichte wären. Da nützt dir das faktische Haar in der Suppe nichts. Es sei denn du bietest dich freiwllig an danach zu forschen. Ich hätte da schonmal ein dutzend verlorener Member. Kaputte Relationen gibts im Wochentakt. Wenn Du eine Aussage ueber eine Sichtweise gemacht haettest (ist mir nicht zugaenglich, ist mit zu aufwendig oder ist mir nicht bekannt), haette es fuer mich keinen Grund zum Widerspruch gegeben. Ok, ich stelle ab jetzt im jedem Post ein ist mir nicht bekannt! voran oder organisiere mir eine Glaskugel. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
es gibt viele Beispiele für KOSMOS-Regeln auf [1] aber kann einer von Euch eine Wanderkarte mit Wanderwegrelationen empfehlen und hat einer von Euch schon Erfahrungen mit der Plotausgabe auf A0 gemacht? Ich hatte einen Style geschrieben der mit fast exakt mit den LVA Karten harmonisiert. Auch erstmal für Walkings. Jetzt kommt aber das große Aber. KOSMOS hat einige Grenzen welche die Eignung für größere Sachen stark einschränkt. Neben Sachen wie falsch umgebrochene Ortsnamen, nicht steuerbares Rendering von beispielsweise ref an den kleinsten Elementen, keine Möglichkeit Texte vom Pfad abzurücken oder nicht rendern der Eigenschaften von inner Elementen in einem Multipolygonen, zeigt auch auch manch Route aus Relationen nicht durchgehen an. Manche Abschnitte werden nicht eingefärbt. Wenn man nur begrenzte Abschnitte zum Ausdrucken macht dann gehts vielleicht, muss aber sehr viel von Hand nacharbeiten. Ich war damit nicht zufrieden. Handarbeit ist je nach Datendichte aber sowieso noch nötig, es gibt noch keine funktionierende Sortierung von naheligenden Symbolen oder Namen, die muss man zurecht rücken. Ich habe es dann mit Mapnik probiert, scheiterte aber leider schon an der ständig hängen gebliebenen Installation der Datenbank. Die Original Links aus dem Wiki HowTo sind leider tot. Daher versuche ich es gerade mit Osmarender. Das läuft soweit, mir fehlt noch eine Antwort auf die Frage wie man Osmosis zum preprocess von Area Center nutzen kann. Rendert man so dann braucht ein Kärtchen schonmal 2 Stunden. Und Route Relationen schneint Osmarender auch nicht zu können, die müsste man in jeweiles in Pfade umwandeln, und diese dann über die Daten legen. Das funktioniert. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Wenn Du sowieso Preprocessing machst, kannst Du aber auch wieder Kosmos nehmen ... Und was haben jetzt die vielen Einschränkungen und Probleme von KOSMOS gegenüber anderen mit dem Problem zu tun, das Osmarender das zwar besser kann, diese Probleme nicht hat und lediglich die Platzierung von Icons durch Area Center lang braucht? Was sich durch preprozess lösen lässt. Ich im Moment das nur noch nicht zum laufen gebracht habe, weil mir noch der saubere funktionierende Konsolenaufruf fehlt. KOSMOS ist zwar schnell, kann aber vieles nicht und macht auch Fehler. Die zu korrigieren würde sogar länger dauern als es glich mit Osmarender und ohne preprocess zu machen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Hier mal ein kleiner Vergleich, noch nicht ganz ausgereift. Der erste Versuch mit KOSMOS. Der Style war noch nicht ganz fertig. Bei den zahlreichen Grenzen und Problemen wie unvollständige Routen hatte ich das abgebrochen. Vorsicht, die Tiles sind nicht optimiert sondern nur fürn kurzen Test direkt aus Kosmos gezogen. Laden dauert daher etwas. http://www.ts-eastrail.de/wandern/ Hier mal ain Ausschnitt aus Osmarender. Auch noch etwas von dem was ich mir vorstelle entfernt. Aber mit viel tryerror holt man da schonmal mehr raus. http://img15.imageshack.us/img15/2118/testkarte.jpg Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
und bei der Routen-Relationen schreibst Du doch auch, dass Osmarender die überhaupt nicht beherrscht. Und ebefalls das KOSMOS da genauso seine Probleme hat und nicht richtig funktioniert. Deine Mail kam etwas zu spät, ich hatte eben mal einen dirketen Vergleich auf die Liste geschickt. Da siehst du was KOSMOS mit Routen macht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osmosis und Area Center
Hallo, ich habe da ein kleines Problem. Ich rendere Ausschnitte mit der osmarender.xsl und momentan MSXML, das meldet zwar nix, ist aber einen ganzen Tick schneller als XMLstarlet. Hat aber noch immer einen zeitraubenden Faktor. Und zwar ist das die Area Center Berechnung. Die Schluckt für ein Kärtchen mit einigen Symbolen schonmal gerne 2 Stunden. Für richtige Kartenausschnitte werden da sicher Tage draus. Irgendwo auf einer Diskussionseite hatte ich dann etwas über preprocessing des Datenfiles mit Osmosis gelesen, was dann alles deutlich beschleunigen sollte. Bie Beschreibung hielt sich aber wie üblich kurz und als nicht Experte steht man schnell im Wald. Ich wollte nun meine bat so schreiben, das er mir das file berechnet und dieses berechnete File dann rendert. Das scheitert aber daran das ich beim Osmosis Aufruf nichts als Java Fehler ernte. Das Studium der tah Files half auch nichts. Ich habe jetzt schon dutzende Commandozeilenversuche durch. Innerhalb des tah Prozesses läuft es ja, ich wollte das aber zum direkt rendern rausziehen. Hat das zufällig einer am laufen und kennt den richtigen Aufruf? Die osmosis.jar liegt momentan unter: C:\osm\tilesAtHome\java\osmosis\osmosis.jar Die area-center.jar unter: C:\osm\tilesAtHome\java\area-center.jar Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telefonnummern mappen?
scheint leider eine etwas längere Diskussion zu werden, da Lulu-Ann erfahrungsgemäß nicht so leicht locker lässt. Auf ihrer Diskussionsseite im Wiki gibt's jetzt auch eine Diskussion zu dem Thema. Einige ihrer Aussagen empfinde ich als Frechheit, besonders diese hier auf meine Anmerkung dass ich keine Diskussion im Wiki zu dem Thema finden konnte: Solange sie nur im Wiki rumsinniert und nicht direkt Daten löscht, ist es ja noch nicht wirklich schlimm. Die Leuten werden desshalb nicht gleich anfangen Daten zu löschen. Wenn ja, Edit War spiele ich gerne 80 Jahre mit, seh ich trocken. Bis lang habe ich immer gedacht dass es in der OSM-Community anders läuft. Ich war immer der Meinung, dass der, der eine Änderung herbeiführen möchte, auch die zugehörige Diskussion anstößt, und zwar VOR der Änderung. Das ist richtig. Man kann etwas anfangen wenn es beispielsweise noch nicht vorhanden ist. Ich mache beispielsweise auch keine Proposals. Ich lege je nach Laune mal eine Seite an, dokumentiere Dinge die ich großflächig anwende. So wie beispielsweise bei den Mittelspannungsleitungen. Wenn es anderen gefällt dann verbreitet sich das von alleine, wenn nicht ist es wenigstens dokumentiert. Aber an vorhandenes sollte man ohne darüber zu sprechen nicht rangehen, schon garnicht eine quasi Abschaffung verkünden. Das war eine absolute Minusaktion. Mit der Meinung dürfte sie auch so ziemlich ganz alleine stehen. BTW: Eben mal in OpenYP für meine Ecke nachgeschaut. Da ist ja nichtmal 0,01% von dem vorhanden, was ich bereits direkt in OSM geschaufelt habe. Alternative für Branchenadressen? Vielleicht in 10 Jahren, oder auch nicht. Auf A.A.A. und Co. kann ich ebenfalls verzichten. Beschlossen und verkündet, Abfahrt! Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telefonnummern mappen?
Ich persoenlich finde Telefonnummern in OSM etwas grenzwertig, aber wer sie eintragen will, der soll das tun. Dann kannst du auch gleich das ganze Konzept der POI in Frage stellen. Die trägt man nicht umsonst aus einem Guss ein. Nur eine Koordinate mit Namen ist nur die Hälfte Wert, POI Archive kriegst du auf jeder zweiten Seite, die restlichen Informationen musst du dir dann wieder aus anderern Quellen zusammen suchen. Und das ist oft weniger einfach als es klingt. Branchenbücher gibts wie Sand am Meer. Viele davon sind aber unvollständig, veraltet oder voll mit Müll. Viele Firmen, Läden oder anderes was ich so vor Ort eingetragen habe findest du erst garnicht so einfach im Netz. Schon garnicht in diesem Open Branchenbuch, da steht ja garnichts drin. Da musst du schon gezielt mit Insiderwissen das Örtliche durchkämmen. Kleine findest du z.B. oft nur über den Namen des Betreibers. Da hat OSM einen riesen Vorteil. Nämlich alle Informationen direkt mit Standort und das auch noch meistens sehr aktuell, präzise und oft auch gut gepflegt. Das ist einmal bei enstprechend dichten Daten und einer guten Anwendung Gold wert. Wo sonst findest du solch vollständige Datensätze die sogar Dinge wie Öffnungszeiten beinhalten? Das gibts zwar schon für spezielle Sachen, z.B. kaufda, aber auch das alte Problem. Unvollständig, veraltete Informationen und die üblichen Problem der Google Karte. Unser Schlecker wird beispielsweise in einem 10 km entfernten Dorf angezeigt. Gleiche Straße und PLZ, Ort scheint der Goggle API egal. Solange es keine vernüftige extrene Anwendungt gibt, bleibt uns garnichts anderes üblich auch eine Telefonnummer direkt in OSM einzutragen. Später hat es vielleicht mal sowas wie eine externe POI DB, die man dann automatisch mit OSM verbinden kann. Oder meinetwegen eine für Kontaktdetails, das eigentliche Objekt bekommt nur noch eine ID. Im Moment haben wir das aber nicht. Und da wäre schön doof die ohenhin erfassten Kontaktdetails nicht zu nutzen. Irgendwann würde man sich darüber ärgern und würde beim sammeln wieder von vorne anfangen. Grenzwertig finde ich daran nichts, eher ein Potential für eine Reihe weiterer Anwendungsgebiete abseits reiner Karten und Nerd Spielzeuge. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap // OpenCritics
opencritics:id=12345 Diese ID wird wohl bestehen bleiben (außer sie wird mutwillig gelöscht) und erlaubt dauerhaft ein Mapping zwischen OSM und eigenen Objekten. Statt mutwillig wuerde ich fahrlaessig sagen - sowas kommt leicht mal unter die Raeder, wenn einer nicht aufpasst. Ja klar, das kann passieren. Ist aber meiner Einschätzung nach deutlich seltener, als das jemand nen Node löscht und neu anlegt. Komplett sicher fährt man auch damit natürlich nicht, da stimm ich zu. Mal davon ab. Spielt diese ID mal einige Ideen und Jahre weiter. Dann haben wir irgendwann mehr IDs von Drittprojekten als Geodaten selbst in der DB. Schon aus praktischen gründen würde ich sowas kicken. Sowas hat meiner Meinung nach überhaupt nichts in einer Geo DB zu suchen. Das Projekt befasst sich im grunde rein mit Senf. Das einzig gemeine mit OSM ist der simple Fakt der für alles gilt. Das zu bewertende Objekt ist eines was in der Natur steht, was wir natürlich abbilden. Die Daten kann man sich ja aus OSM holen, aber zurückschreiben und rumlinken gibt wieder nur Probleme und graue Haare. Mit gelöschten Objekten ist nunmal ein Problem. Lässt sich in so einem Projekt auch nicht lösen. Die Daten sind ja ständig im Wandel. Daneben können sich Tags ändern, die Daten kommen mit einer neuen API anders etc. Wer weitgehend sichere Daten will der muss sie lokal halten und sich einen Kopf um eine funktionierende Aktuallisierung machen. Das ist nicht die Aufgabe von OSM. Wir sammeln Daten und stellen diese bereit, das ganze ohne jegliche feste Regel. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Das ist Länderrecht (oder sogar kommunal?) und vermutlich unterschiedlich geregelt. Ich beziehe mich oben auf Berlin. Quelle Glaube kommunal, hier unsere Besttimmungen dazu: (Hausnummernverordnung) Auf Grund des § 27 Absatz 3 des Thüringer Gesetzes über die Aufgaben und Befugnisse der Ordnungsbehörden (Ordnungsbehördengesetz OBG-) vom 18. Juni 1993 (GVBl, S.323), geändert durch Gesetz vom 24.10.2001 (GVBl. S. 265), vom 20.06.2002 (GVBl. S. 247) erläßt die Stadt Roßleben als Ordnungsbehörde folgende Verordnung: § 1 Geltungsbereich, Zweck (1) Diese ordnungsbehördliche Verordnung gilt für das gesamte Gebiet der Stadt Roßleben, sofern in den nachfolgenden Bestimmungen nicht ausdrücklich etwas anderes geregelt ist. (2) Diese ordnungsbehördliche Verordnung dient der einheitlichen Vergabe von Hausnummern an Gebäudegrundstücken, zur Wahrung der öffentlichen Ordnung und Sicherheit sowie der Gewährleistung der rechtzeitigen Erreichbarkeit durch Rettungsdienste und Feuerwehr. § 2 Vergabe der Hausnummern (1) Jedes Gebäudegrundstück erhält in der Regel eine Hausnummer. Bei Häusern mit mehreren Eingängen bzw. Treppenhäusern, zwischen denen keine allgemein zugängliche Verbindung besteht, erhält jeder Eingang eine gesonderte Hausnummer. Bilden mehrere Gebäude eine wirtschaftliche Einheit, erhalten sie eine gemeinsame Hausnummer. Von mehreren auf einem Grundstück errichteten Gebäuden erhält jedes wirtschaftlich selbstständige Gebäude eine eigene Hausnummer. (2) Das Sachgebiet Liegenschaften der Stadt Roßleben teilt die Hausnummer zu. Bei der Errichtung von Neubauten werden die festgesetzten Hausnummern dem Grundstückseigentümer auf Antrag schriftlich mitgeteilt. Bestehen für bereits bebaute Grundstücke, die unter diese Verordnung fallen, keine Hausnummern, erfolgt die Festsetzung durch die Stadt Roßleben. § 3 Pflichten des Eigentümers Der Eigentümer des Gebäudes, für welches das Sachgebiet Liegenschaften der Stadt Roßleben eine Hausnummer zugeteilt hat, ist verpflichtet, die Hausnummer innerhalb von 8 Wochen nach Erhalt der Mitteilung, bei Neubauten spätestens bis zum Bezug des Gebäudes, gemäß § 2 Abs. 2 auf seine Kosten zu beschaffen und entsprechend den Bestimmungen dieser Verordnung und etwaigen weiteren Auflagen ordnungsgemäß anzubringen und zu unterhalten. § 4 Anbringen der Hausnummern (1) Die Hausnummer ist an der Straßenseite des Gebäudes an gut sichtbarer Stelle anzubringen. Befindet sich der Hauseingang an der Straßenseite, ist sie unmittelbar rechts neben der Eingangstür in Höhe der Oberkante der Tür anzubringen. Befindet sich die Eingangstür nicht an der Straßenseite, ist die Hausnummer straßenseitig an der Eingangstür nächstliegenden Ecke des Gebäudes anzubringen. Würde die Einfriedung eine gute Sicht von der Straße auf die am Gebäude angebrachte Hausnummer verhindern, ist sie unmittelbar rechts neben dem Eingang der Einfriedung zur Straße hin anzubringen. (2) Aus Gründen der Übersichtlichkeit sind für Häuserblöcke oder Hausgruppen zusätzlich zu den einzelnen Nummern an sichtbarer Stelle die Hausnummern zusammengefasst anzubringen. (3) Es kann eine andere Art der Anbringung zugelassen oder angeordnet werden, wenn dies in besonderen Fällen, insbesondere zur besseren Sichtbarkeit der Hausnummer, geboten ist. § 5 Gestaltungsvorschriften Die Hausnummern müssen gut lesbar sein. Für die Zahlen wird eine Mindesthöhe von 70 mm und für die Buchstaben eine Mindesthöhe von 50 mm vorgeschrieben. Die Lesbarkeit der Hausnummer ist durch den Eigentümer zu gewährleisten. § 6 Änderung von Hausnummern (1) Bei der Änderung der bisherigen Hausnummer finden die §§ 2 bis 5 entsprechende Anwendung. Zur besseren Orientierung kann die alte Hausnummer für die Dauer höchstens von einem Jahr ab Vergabedatum am Haus bzw. am Grundstück belassen werden. Sie ist in rot so durchzustreichen, dass sie noch lesbar ist. Nach Ablauf dieses Zeitraumes ist die alte Hausnummer zu entfernen. (2) Bei notwendiger Erneuerung der Hausnummer tritt an die Stelle der Mitteilung nach § 2 Abs. 2 Satz 3 die Aufforderung der Stadt an den Eigentümer, die Hausnummer zu erneuern. Im Übrigen finden die §§ 2 bis 5 entsprechende Anwendung mit der Maßgabe, dass die vom Eigentümer zu tragenden Kosten auch die Aufwendungen beinhalten, die in unmittelbarem Zusammenhang mit der Erneuerung der Hausnummer am Haus entstehen. § 7 Ausnahmen Auf schriftlichen Antrag kann die Abt. Liegenschaften der Stadt Roßleben Ausnahmen von den Bestimmungen dieser Verordnung zulassen. § 8 Ordnungswidrigkeiten (1) Ordnungswidrig im Sinne von § 50 des Ordnungsbehördengesetzes (OBG) handelt, wer 1. vorsätzlich oder fahrlässig entgegen § 3 sein Haus nicht auf eigene Kosten mit der dem Grundstück vom Sachgebiet Liegenschaften der Stadt Roßleben zugeteilten Hausnummer versieht, 2. die Hausnummer nicht gem. § 5 von der Straße aus erkennbar und lesbar anbringt und erhält oder 3. die Hausnummer entgegen den Bestimmungen in § 4
Re: [Talk-de] Werbung
Klingt vielleicht komisch, aber OSM ist eben nur für Experten. ? Auf der Datenanwenderseite noch ja, da basteln noch Experten für Experten, auf der Datenbeibringerseite definitiv nicht, ansonsten könnten wir großflächig die Daten mit der Lupe suchen. Vergessen manche nur leider immer wieder, was eben wieder zu Punkt 1 führt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werbung
Da hab ich mich vielleicht falsch ausgedrückt, aber alle angemeldeten Benutzer sind zu über 90% keine normalsterblichen PC-Nutzer, sondern in der Regel Leute, die aus irgendeinem Grund viel mit PC zu tun haben. Viel mit PC kann vielfälltig sein. Der Mitstreiter in meiner Ecke ist zwar Statiker und kann CAD, ist aber ansonsten auch kein Programmierer oder Profi. Der wandert einfach nur gerne. Ich habe weder studiert oder komme aus der Informatik, habe nur was im Games Bereich gemacht und desshalb seit Jahren einige Geodaten auf Halde. Ich bin absoluter Quereinsteiger mit kleiner Inselbegabung. Könnte aber nichtmal selbstständig ein OpenLayers Script nach Wunsch stricken. Experte ist hier relativ. Die meisten die hier in der Fläche Mappen sind definitiv keine Experten. Da kommen die unterschiedlichsten Motivationen zusammen. Die meisten die ich so abseits dieser Liste kennengerlent habe, sind ganz normale PC Nutzer. Das bekommt man aber nicht mit. Denn öffentlich oder hier auf Liste sind es eben meist die wenigen Profis die sich zeigen. Ein Normalnutzer verirrt sich schonmal recht selten auf eine ML. Die sind im Forum oder gleich ganz passiv. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mal vorsichtig gefragt. Redest Du hier einer syntaktisch bedeutsamen Einrückung wie bei Python das Wort oder wolltest Du nicht hier ein paar Tags offen lassen/schachteln? Ist mir ja schon klar, dass OSM nicht streng XML folgt, aber sowas wie mehrere Tags mit identischem Inhalt/identischer ID finde ich schon ungebräuchlich. Das war nur so eine Idee, ich bin kein Programmierer. Als Erweiterung der bestehenden Syntax kann das gehen und es kann dann nützlich sein, wenn das Gesamtgebilde nicht eine Relation sein soll (wie ein landuse=farmland mit mehreren Gebäuden drin). Man muss aber bedenken, dass durch so eine Schachtelung nicht so leicht m:n-Relationen abbildbar sind wie bei ... naja ... Relationen. Deshalb sehe ich sie nur als Ergänzung und nicht als Ersatz. Das soll es sein, eine Ergänzung für die vielen einfachen Fälle, wo es die große Relation nicht braucht, die viele eben gleich bleiben lassen. Das bisherige Vorgehen ist ja, das über räumliche Zugehörigkeit zu regeln, also ein Gebäudeumriss mit verschiedenen Knoten für die Bäckere^H^H^H^H^H^H^HTeig- warenfiliale, Pos^H^H^HSchreibwarenladen mit gelber Theke, Spielhölle und Boutique. Die Räumliche Zuordnung über Relation macht ja vielleicht bei einem riesen Einkaufszentrum oder anderen großen Sachen noch Sinn. Daneben hats aber in der Masse viele Lädchen oder Nutzer in kleinen Häusern. Ich hatte ja immer wieder das Beispiel der Postbank in der Postagentur, das zusammen in einem Laden der mehreres anbietet. Das spielt sich alles auf etwa 60m² ab. Da hast du das kleine Häuschen und darüber eine riesen POI Wolke, redundante Adressen etc. Die Zoomstufe dafür wurde noch garnicht erfunden. In Osmarender hast du Brei, in Mapnik garnichts, es verdrängt sich alles. Für solche Sachen reicht es die einzelnen Nutzungen einfach ans Gebäude hängen zu können. Da brauchst du auch keine Räumliche zuordnung. Und vielleicht ist dann diese Gruppierung auch ein besserer Ansatz das Renderer das auch sauberer Ordnen können. Denn die Position wäre dann egal, alles kann sauber platziert werden. Bei POI Wolken wird einfach nur verdrängt. Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig verstanden habe) gegenüber räumlicher Ordnung und Relationen einen wesentlichen Vorteil bietet. Wenn die Editorschnittstelle davor das Entscheidende ist, ist das Datenmodell dahonter doch ohnehin zweitrangig (zumindest wenn es zu wenig anfängerfreundlich erscheint). Mir ist es ja im grunde egal wie es gelöst wird. Nur Fakt ist, die Relation in der jetzigen Form ist für viele Sachen weit drüber. Und in der jetzigen Form für viele ein Grund einen Bogen drumherum zu machen, andere zerhauen sie unbewusst. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wir sammeln Geodaten. Adressen sind eigentlich fest an Grundstücke oder Gebäudeteile vergebene Merkmale. Geplante aber unbebaute Grundstücke haben auch fest vergebene Adressen, die wir hier allerdings nicht hinterlegen. Sehen oder wissen wir ja meistens sowieso nicht und wir verwalten die ja nicht sondern pflegen den aktuell vorhandenen Bestand. Unsere Möglichkeiten geben es aber schlicht nicht her ein Grundstück zu definieren, dem als Member die Gebäude und darunter wiederum die einzelnen Nutzer als Gruppen anzulegen. Deswegen machen wir für alles einen POI und da muss dann jedesmal extra die Adresse dazu oder der POI irgendwie verknüpft werden. Kontaktdaten sind kein Bestandteil der eigentlichen Adresse, das sind frei wählbare Kontaktmöglichkeiten eines einzlenen Nutzers oder einer Sache, die vollkommen unabhängig von Adressen laufen. Auch Gegenstände oder Nutzer ohne Adresse können einen Kontakt haben. Automaten, Imbissstände, Informationsangebote... Kontaktdaten passen daher nicht wirklich ins Adressschema. Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Da wo es nicht nötig ist brauchts keine unnötig aufblähten und verkomplizierten Tags. Vor allem wenn diese dann derzeit ohne Editorunterstützung auskommen muss und wieder dutzende Tippfehler ansaugt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Sun, Feb 07, 2010 at 02:02:46PM CET]: [...] Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Hab jetzt nicht nachgeschaut, ob das vorkommt, aber was würde man bei phone=* im Zusammenhang mit amenity=phone erwarten? Die Nummer einer anrufbaren Telefonzelle, die Nummer der zugehörigen Störungsstelle, oder eine nähere Beschreibung des Telefons (ähnlich wie natural=wetland, wetland=marsh)? Was du da erwartest weiß ich nicht. Ich würde darunter die Nummer einer anrufbaren Zelle verstehen, da phone nunmal für die Telefonnummer steht. Für einen Spezialfall wie Telefonzelle muss man dann mit Zusatzangaben entsprechend abgrenzen. service:phone Störung, emergency:phone Notruf etc. Da hat sich noch keiner weiter Gedanken gemacht. Bei der Telefonzelle hat man es sich aber auch wieder zu einfach gemacht. Eigentlich sind das ja call box, telephone booth, telephone box, phone box. Während man nur phone ja eigentlich normal im contact nutzt. Das ist wieder so eine unnötige hausgemachte Überschneidung. Ansonsten hast du genauso wie bei access die gleiche Grütze. Neutrale einfache Tags wie bicycle=yes, die sich eigentlich schön global einsetzen lassen, für den einen Spezialfall wie eben access auf ewig festgenagelt. Dafür muss man dann jeglicher anderen Verwendung wieder einen extra Namensraum verpassen oder gar einen ganz neuen Tag erfinden. Extrem häßlich, aber wohl nicht mehr zu ändern. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Ihr und eure Relationen... kompliziert, von vielen gemieden und alles andere als die ultimative Lösung für alles. Ja ich kann eine Site für ein Grunstück anlegen, und ja, ich kann dann eine Buildung machen. Das kann ich schön verschachteln. Ist aber sowas von anfällig und für viele zu kompliziert. Editorunterstützung garnicht bis kompliziert. Mit solchen Konstrukten nagelst du dir einen enormen Pflegeaufwand an die Backe. Ich würde da gerne einen anderen Weg gehen. Tag Set oder Group am Objekt selbst. Hauptobjekt Buildung mit seiner Adresse und vielleicht anderen Angaben und darunter für jeden Nutzer ein Set. Das erbübrigt dutzende Redundanzen und Einzelnodes, sowie Semikolonorgien, die sich maschinell auch nicht mehr Ordnen lassen und von der korrekten Eintragsreihenfolge des Nutzers abhängen. Im Set hast du das Problem nicht. Da kannst du meinetwegen das Set amenity=bank und das Set amenity=post_office als Postagentur in einem Objekt haben, beides jeweils mit seinen eigenen Angaben und ohne Überschneidungen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Du übertreibst m.E. maßlos: was soll an der Relation kompliziert sein? Die Zugehörigkeit wird an jedem Objekt angezeigt. Für dich ist das nicht kompliziert. Aber wie oft laufen Leute auf für die das nicht so ist, die Relationen meiden oder unbewusst kaputt machen? Aktuell haben wir doch wieder mal verschwundene Relationen auf der Liste. wieso? Von selbst geht das nicht kaputt... Doch, wenn irgendwein Tool Mist baut. Ansonsten braucht bloß einer einen Weg teilen, den Dialog nicht verstehen und wieder hats einen Fehler. Relationen fliegen einem permament um die Ohren. Ein Horror wenn jedes Gebäude eine hätte. Da bist du mehr mit fixen als mit anlegen beschäftigt. Ich habe vor einem halben Jahr aufgehört zu zählen, wie oft beispielsweise Busrelationen kaputt gingen. Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Das ist doch Schnee von Morgen, davon höre ich zum ersten Mal, und weder Editoren noch API verstehen das. Wieso das einfacher oder überhaupt was anderes als ne Relation sein soll, ist mir auch nicht klar geworden. Eben keine Relationen die wieder als eigenes Objekt dutzende andere Objekte mit Rollen zusammen kitten. Genau das solls nicht sein. Objekte wie jetzt auch, nur vom editor unterstützt die Möglichkeit ein eigenes Set oder Schachtel ins Objekt bringen. Nehmen wir als Vergleich einen Osmarender Style. Der hat eine Hauptschachtel die grob den Hauptag beschreibt. Darunter jeweils eine eigene Schachtel für jeweilige Defintionen die aber so immer in Verbindung mit Hauptobjekt bleibt. Im Moment geht pro Nutzung immer nur eine einzige Schachtel. So könntest du alles in einem Objekt halten, hast keine Überschneidungsprobleme mit gleichen Tags und brauchst auch keine zusätzlichen virtuellen Objekte wie Relationen. Haus Adresse +Set 1 Bank Kontakt etc. +Set 2 Post Bank Kontakt etc. Klar wird das noch nicht unterstützt. Man ruht sich ja noch auf den Beschränkungen und den Relationen aus. Das muss man erstmal audkaspern. Übrigends ist die Idee auch nicht neu. Kam früher schonmal und andere haben auch schon in der Richtung nachgedacht. Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Erstens schreibe ich dir zum 1000 male das ich das weiß und zweitens interessiert das jetzt garnicht. Der Normale Mapper ist froh wenn er ein Gebäudepolygon zusammen hat. In Grundstücken braucht man in der Breite noch nicht zu denken. Das machst du, ich machs auch, vielleicht noch zehn oder zwanzig andere. Die Masse packt es mangeles besserer Daten ans Haus oder einen Node. Von daher sollte es eigentlich ganz einfach sein: Siterelation, Grenze ist das Grundstück, dieses erhält die Adresse, darauf liegen die Gebäude (mit ggf. Adresszusätzen die nur gebäudeweise gelten) und die Nutzungen (oder, wenn man es gerne kompliziert hat: die Nutzungen in den Gebäuden). Es ist für die breite Anwenderschaft eben alles andere als leicht. Es hat schon Seltenheitswert, wenn ich mal auf so eine Realtion stoße. Die Masse legt einfach Einzelobjekte. Ich nutze das auch nicht. Ich sehe wie andere Relationen permanent kaputt gehen. Solange das nicht sicherer wird oder eben eine andere Lösung kommt, mache ich einen Bogen darum. Verhunzte Objekte habe ich schnell wieder aus dem Backup geholt oder zurückgestellt. Bei Relationen ist es bei jeder einzelnen ne schöne Bastelarbeit. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
In der osmarender.xml für Zoomstufe 17 sind Relationen vorgesehen, allerdings muß man am Anfang der Datei showRelationRoute=yes setzen, und der Relationsblock !-- Relation/Routes SDW -- am Ende der Regeln ist auskommentiert. Wenn man das umgeht, kann man zumindest die Wegstücke anders einfärben. Symbole oder refs an den Weg zu pappen tuts allerdings nicht, dafür müsste in der xsl entsprechendes vorgesehen sein. Das hatte ich auch gesehen. Theoretisch müsste es dann auch laufen wenn man showRelationRoute=yes und entsprechende Regeln auf andere Styles umkopiert. Tuts aber nicht. Jedenfalls nicht direkt übers XSL über XML Starlet. Ebenso wie Inner von Multipolygonen nur ausgeschnitten aber nicht nach rule ausgefüllt werden. Rendert mal über tilesAT local also orp, wird relation gleich ignoriert. Das scheint generell nicht zu laufen. In der XSL (6.0 Alpha 6 ) sind da einige Zeilen ab 1168, 1292 die sich um Relationen drehen, auskommentiert ist nichts. Ich verstehe aber zu wenig von der Materie um den Fehler zu finden. Hast du das denn in irgendeiner Version tatsächlich zum laufen gebracht, oder auch nur vermutet? Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine feste Art von Rolle, um die man sich nicht kümmern braucht, weil der Editor das macht, könnte man z.B. Gruppe nennen) mit bedienerfreundlicher Editorunterstützung. Nichts dagegen, im Gegenteil, nur solange man das nicht programmiert bleibt es halt Wunschdenken. Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die Möglichkeiten des Objektes selbst etwas erweitern. Wir haben jetzt z.B. ein Gebäude mit seinen üblichen Eigenschaften: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / /way Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal amenity, phone whatever verpassen. Ein Tag geht nur einmal, ein zweiter Wert würde den alten einfach überschreiben. Zu der Zeit wo man noch andere Sorgen und wenige Details hatte hats gereicht. Deswegen sind wir gezwungen alles einzeln abzulegen, gewisse Redundanzen zu schaffen, Krücken wie die Semikolongeschichte zu bauen und das dann ggf. wieder über ein neues Objekt, eben die Relation, wieder zu vereinen. Damit fahren wir aber eigentlich mit Kirche, Marktplatz und Rathaus ums Dorf. Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way Ich weiß nun nicht wie schwierig das ist um es in einer zukünftigen API vorzusehen. Ansich wäre es ja nur eine neue Tagrule und eine Erweiterung der ID, um die Gruppen Sub ID anhängen zu können. Ich denke mal die IDs sind begrenzt, wo es haken wird. Das schwierigste wird die Umsetzung im Editor sein. Aber wenn ich den Relationseditor sehe, scheint es da fähige Leute zu geben die das können. Dann ist natürlich auch die Frage wie Renderer das dann auswerten. Nur schlimmer kann es für die im Grunde auch nicht kommen. Die haben meist unzusammenhängende POI Wolken liegen und müssen herumrechnen, verdrängen etc. Vielleicht würde eine saubere Gruppierung sogar eine besser Grundlage schaffen. wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig auch gleich sinnvolle Hierarchien vorschlagen, also z.B. Grundstück Gebäude Einheit (Laden, Wohnung, Büroeinheit) ggf. Untereinheit (Raum, Zimmer, Saal) Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ich denke, wir schreiben da etwas aneinander vorbei, IMHO beschreibst Du einen Typ Relation, indem Du dem Way die Fähigkeiten von Relationen geben willst (Du nennst die Relation Way, aber im Prinzip ist es eine Relation, die zusätzlich zu den Nodes auch noch Ways enthält. Wenn Du die Nodes und die Richtung weglassen würdest, wäre es nicht so kompliziert ;-) Ja, im übergeordneten Sinn ist es eine Relation aber diese Erweiterung des eigentlichen Objektes hat nichts mit der in OSM gebräuchlichen Form einer Relation zu tun. Der Way wird nur um eine Schachtel erweitert, statt dafür wieder eine eigene extra Relation zu benutzen. Ich würde das Kind dann auch gerne von dieser Bezeichnung fernhalten, das alleine lässt manchen schon wegrennen. Teilweise zu Recht. die Lösung hast Du ja selbst schon geschrieben: mit dem Semikolon als Trenner kann man mehrere Werte an einen Schlüssel hängen. Die Nachteile sind, dass man a) bei den übrigen Tags z.T. nicht klar ist, für welchen Wert sie gelten sollen (oder für alle?) b) die derzeitigen Anwendungen nicht damit klar kommen Eben deswegen ist das Semikolon eine Krücke und keine Lösung, sollte es auch nicht werden. Bei mehreren Werten muss der Anwender peinlich darauf achten das Werte in der richtigen Reihenfolge zueinander stehen. Aus der Praxis wissen wir wie anfällig sowas ist. Semikolon ist eine Sackgasse und halbgare Notlösung. Das müsste man mal richtig an den Eiern packen. Sobald Du von Adressen und Hausnummern sprichst, geht es im Prinzip um Grundstücke. Zum x ten male. Es geht mir nicht um Grundstücke und deren Nummern. Grundstücke und deren Grenzen sind Luxusdetails die nur wenige bringen können. Wer solche Daten erbringt der weiß auch wie, die Masse interessierts erstmal nicht. Die ist froh eine Gebäudekoordinate oder sogar eine Form zu haben. Da klemmts erstmal primär. Grundstücke werden für die Masse erst interesannt, wenn es auch entsprechende Grundlagen gibt. Beispielsweise flächendeckende Luftbilder. Abseits der Ballungsgebiete wirds da auch zukünftig zappenduster aussehen. AeroWest nützt mir z.B. garnichts. Alte Goggle Bilder bedingt, da hats hier seit jeher nur für die 10 Jahre alten gereicht. Bleiben nur die LVA, aber da wird man noch lange nichts reißen. Oberpfalz war Glück. Bayern kann es sich leisten, andere müssen Geld verdienen. Es ging hier um Kontaktdetails und eben Probleme wie Tagüberschneidungen. Ja, Adressen = Grundstück, haben wir bis zum erbrechen durchgekaut. 99% können aber Grundstück nicht und haben nur Gebäude (Koordinate). Erstmal muss man das Gebäude und anderes lösen. Und das mit einer Methode, bei der auch Joe the Mapper problemlos loslegen kann. Auch wenn das manche hier immer wieder gerne ausblenden. Die Masse sind hier keine Informatiker oder Profis. Über weitergehendes wie aus Daten ne Karte machen reden wir gleich garnicht. Da verzweifle ich aktuell alle 5 Minuten dran. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ruhr2010-barrierefrei: Zugang mit Rollstuhl
Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Die Datenmengen sind zu gering als das dadurch unüberwindbare Probleme entstehen werden. Und für die Zukunft wäre das addr:* Schema viel besser. Nimm nicht nur die Tag Seiten, da spuckt jede was anderes aus. Wirklich vergleichbar wäre nur eine Zählung über das was die XAPI wirklich aus der Datenbank holt. Da dürfte das Bild ein anderes sein. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Das beträfe alleine in meiner Ecke hunderte von Einträgen. Einfach ist es für dich, hast ja die Arbeit nicht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenlistenabgleich - jetzt in Selbstbedienung
Denn bis auf Sachsen-Anhalt haben alle Betroffenen eine Außengrenze. Keine Ahnung ob es hilft. Ich hatte vor einigen Wochen die Ex-/ Enklaven bei mir vor der Tür nachgetragen. Relationen aber entsprechend sortiert. http://www.openstreetmap.org/?lat=51.3464lon=11.4117zoom=14layers=B000FTF Das Vorwerk Heygendorf liegt geografisch in der Stadt Allstedt und damit im Kreis Mannsfeld Südharz, ist aber ein abgelegenes Stück der Stadt Querfurt im Saalekreis. Gleiches beim Kalbenholz darunter. Ganz unten ein Zipfel Sachsen-Anhalt, der aber für sich allein mit einigen Metern Abstand komplett umschlossen in Thüringen liegt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotomapping in Ratingen kostenpflichtig?
Oder geh mal zu der Britischen oder US Botschaft oder Konsulaten und knips da mal ausführlich die geschöfte und gebäude in der nachbarschaft. Es gibt zwei Wege zu Fotografieren. Erster ist das ich möglichst auffallend mit OSM Weste wie ein Japanischer Tourist rumspringe, wie wild fuzze und möglichst noch diktiere oder notiere. Das ist gut wenn ich Werbungs fürs Projekt machen will und gerne den Erklärbär spiele. Schlecht für das Daten sammeln ansich, weil man mehr auf korrektes Verhalten bedacht ist und wertvolle Zeit flöten geht. Das habe ich einmal gemacht. Bis ich dann einen Landmarker einer Gastrasse aufnehmen wollte und ein Schäfer meinte im Bild zu sein, der irgendwas zu verbergen hatte und mir die Kamera aus der Hand schlagen wollte. Der zweite Weg ist einfach ohne aufzufallen mitzuschwimmen, das GPS trackt vor sich hin und die Bilder aus dem Handgelenk oder mit umgehangener Kamera zu machen. So mache ich es. 95% bekommen so garnicht mit was gerade passiert und du kannst dich wunderbar ungestört aufs Daten sammeln konzentrieren. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
IE wird nicht unterstützt. Grundsätzlich garnicht mehr? Wäre nämlich gut mal zu wissen woran man ist. Bei der alten war es nämlich so das es mal ging und mal nicht. Es war dann immer peinlich wenn man Permas an irgendwleche Stellen rausgeschickt hat und dann die Rückmeldung kam das nichts zu sehen war. Meist wird ja nur IE genutzt. Dann nutze ich die Karte nicht mehr für Anfragen. Noch ein Problem was schon in der alten Karte bestand. http://topo.geofabrik.de/?lon=11.4607lat=51.3447zoom=13 Hier ist normal eine riesen Lichtung in der Mitte. Die wurde entsprechend mit anderen Landuses per Multipolygon aus der Waldfläche ausgeschnitten. Der Wald wird aber durchgezeichnet. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
Grundsätzlich nicht. Man hätte für den IE an einigen Stellen größere Extrawürste im Javascript implementieren müssen - und diese wandelnde Sicherheitslücke ist mir keine Arbeit wert. Wenn es zuviel Arbeit macht ok, schränkt den Nutzerkreis aber massiv ein. Man kann zwar drunter schreiben das nur Browser XY geht, da werden aber viele das gleiche machen wie einst die Nutzer die mit Netzkappe und Co. auf Optimiert für IE stießen. Nämlich die Seite zu statt anderen Browser installieren. Da wo bestimmte Lizenzen und Softwarepakete vorgeschrieben sind hilfts ohnehin nicht. Wandelnde Sicherheitslücke kann man so oder so sehen. Mit steigendem Marktanteil wird auch Firefox Probleme kriegen. Der Mythos vom sicheren Browser gilt für einige auch nur aus einem Grund. Die Nutzerschaft ist so klein und unbedeutend, dass sich nichtmal einer die Mühe macht eine zu suchen und auszunutzen. Auch manch Linux Distri hat oft mal häßliche Löcher, sicher ist nichts. Ok, das ist aber auch ein Hammer, so viele Einzelpolygone anstatt einfach ein großer Umriß. Na egal, die Multipolys macht srtm2osm, da werden wir wohl eine neuere Version auf dem Server brauchen. Wie will man es sonst umsetzen? Da sind nunmal dutzende verschiedene Landnutzungen drinnen, teils auch jeweils mit eigenen Flurnamen. Dafür sind Multipolygone nunmal da. Fläche auf über Fläche geht nicht automatisch, Layer ist tabu und mit einem einzigen inner fallen ja sämtliche Informationen weg. Ich weiß, du bist beispielsweise kein Fan von Farmland. Nur sind die Daten nunmal nicht nur für die Wanderkarte. Wer anders könnte die Daten vielleicht doch wieder gebrauchen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
Na, ganz einfach: Ein outer, ein inner ohne Tags um die ganze Lichtung und dann die ganzen kleinen Polys ohne Relation. Das würde mit einfachsten Mitteln den gewünschten Sachverhalt ausdrücken. Bleiben noch immer die vielen kleinen Inner die im Wald rumliegen. Viel leichter wirds nicht wirklich. Außerdem funktionierte das zum Erstellungszeitpunkt auch nicht in jeder Karte, da wurde glaube in Osmarender der Wald einfach durchgezogen. Kann man ignorieren, wollte ich aber nicht, zumal das so auch nicht wirklich falsch ist. Dieses Multipoly dürfte viele Programme, z.B. mkgmap für die Garminkarten, hoffnungslos überfordern. Tja, so ist das eben. Wir taggen offiziell nicht für die Renderer, inoffiziell aber doch, weil sich eben nicht alle Anwendung an eine Vorgabe halten oder durch Beschränkungen halten können. Da sind aber die Entwickler gefragt. Ich nutze nur das was offiziell dokumentiert ist. Da muss sich der Mapper drauf verlassen das dokumentierte Vorgaben passen und eventuelle Probleme da auch mit einfließen. Man kann es nicht wissen wenn kein Entwickler eine eventuelle Inner Grenze anspricht. Ich werde jetzt bestimmt kein Garmin etc. kaufen und jegliche Anwendung auf eventuelle Probleme durchspielen. Aktuell arbeite ich auch an einer Karte, fange vom Style her bei null an und kenne auch die Probleme die dann in der Aufbereitung und Darstellung so aufkommen können, das nervt ab und an ganz schön. Da muss man auch mal in den sauren Apfel beißen und irgendwas umbauen. Denn auf der anderen Seite verstehe ich auch die Seite des Mappers. Der taggt und bastelt nach dem Wissen was ihm zur Verfügung steht. Was mir hier dann auf die Füße fällt, kann der nicht riechen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
Ich habe für diesen Zweck die Datei Tileset.pm im Verzeichnis lib/ manipuliert: Danke, das funzt einwandfrei. Störend ist da nur noch das man eben immer nur eine feste z12 Kachelkkordinate pro Durchgang mitnehmen kann. Hat den Nachteil das man die ungeschnittenen großen png und svg wieder zusammensetzen muss. Wäre hübscher wenn wie beim einfachen Rendern mit dem xsl die interne bbox des Datenfiles benutzt würde. Da wäre noch ein Fehler, allerdings von Inkscape. Das war auch der Grund warum bei ich tah nicht mehr mitgerendert habe. Bei jedem Inkscape Durchgang meckert er die preferences.xml an. Rechte habe ich schon mehrfach umgesetzt, hilft nur nicht. In dem Zustand kanns leider nicht alleine laufen, der Fehler unterbricht in jeder Zoomstufe. Das kam irgendwann mal nach direkter Nutzung von Inkscape. Irgendeine Einstellung scheint tah da nicht zu schmecken. C:\Dokumente und Einstellungen\Mirko Küster\Anwendungsdaten\Inkscape\preferences.xml not a valid XML file, or you don't have read permissions on it. Inkscape will run with default settings. New settings will not be saved. Und noch ein kleines Problem. Bekommt man Osmarender irgendwie dazu auch das element Relation mit zu nutzen? Das braucht man beispielsweise wenn eine Grenze einen vorhandenen Weg mit nutzt. Die Grenze wird ja dann nur über die Relation selber ausgedrückt, das Wegsegment ist meinetwegen ein Waterway oder Highway. Relation scheint er aber zu ignorieren. Wäre unschön wenn man deswegen Routen und Boundarys als eigene Wege anlegen müsste. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
Was hast du denn jetzt Besonderes eingestellt? Nichts was mir jetzt direkt bewusst wäre. Das läuft hier nach tryerror. Mühsam ernährt sich das Eichhörnchen, es geht aber voran. Ich sehne den Tag herbei wo jemand kompetentes es sich mal zur Aufgabe macht die Möglichkeiten eines Mapnik beispielsweise in die überschaubare Umgebung eines Kosmos zu packen. Man hat dutzende Ideen für Kartenanwendungen, die nötigen Daten ebenfalls und am Ende scheitert es nur daran, dass die passenden Renderer schwer aufzusetzen und anzupassen sind. Irgendwo ist halt immer ein Haken. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
C:\Dokumente und Einstellungen\Mirko Küster\Anwendungsdaten\Inkscape\preferences.xml not a valid XML file, or you don't have read permissions on it. Inkscape will run with default settings. New settings will not be saved. einfach löschen, die Datei wird mit den default settings neu angelegt. Bringt leider nichts. Die Idee hatte ich auch schon. Datei gelöscht, Inkscape gestartet, Datei wird neu angelegt. Aber tah meckert weiterhin. Keine Ahnung was da sein soll. Am Anfang lief das doch auch ohne Fehler. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
Wie du siehst, muss jeder SVG-Befehl mit svg: ergänzt werden. Um die gleiche Darstellungsgröße der Symbole mit der Füllung zu erreichen, muss der Wert [1] dem Wert [2] im Kopf der Style-Datei entsprechen: Soweit war ich schon, hatte auch gepasst. Die Objekte waren aber in der Fläche verschoben und jeweils ansich falsch skalliert. Das habe ich jetzt soweit hinbekommen. Passt noch nicht ganz 100% (minimale Üperlappung im Subpixelbereich) aber für meine Zwecke reicht es so. Problem vorerst gelöst, danke. Dann habe ich noch ein Problem. Momentan nutze ich die tilesAThome Konfiguration in der lokalen Variante. So generiert das ganze ja praktischerweise je ein ganzes svg und png pro Zoomstufe, splittet fertige Tiles für Openlayers und das ganze auch fertig optimiert. Damit hätte man interaktive und fast druckbare Variante erschlagen. Nun kann man damit aber nur beispielsweise den Aufruf perl tilesGen.pl xy 2173 1363 12 starten. Damit wählt man aber nur eine bestimmte Kachel auf dem Planeten an, die dann ihre Daten aus einem API Auruf zieht. Ich würde aber gerne die API umgehen und aus einem lokalen OSM File rendern. Ich möchte gerne die Höhenlinien und einige lokale Sachen mit einrendern. Die können und sollen ja nicht auf Server. Wie kriege ich jetzt eine tilesATlocal Konfiguration dazu die API zu umgehen und stattdessen ein lokales File zu ziehen? Alles danach dürfte sich nicht ändern, es wird ja auch nur mit dem aus der API geladenen OSM File hantiert. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenname kurz oder lang?
es läuft eh periodisch ein Skript über die Karte das -str. und -strasse in -straße umwandelt. Welches Skript? http://wiki.openstreetmap.org/wiki/User:Xybot#So_what_does_the_FixStrasseDeAT_ruleset_do_exactly Ich hoffe, das Skript denkt an die Schweiz, wo Strassen auch Strassen bleiben müssen. http://wiki.openstreetmap.org/wiki/User:Xybot#So_what_does_the_FixStrasseCh_ruleset_do_exactly Fehlt nur endlich die Möglichkeit meinetwegen ein xybot=no zu setzen um Eigennamen etc. zu schützen. Die muss man derzeit alle lokal sammeln, weil der Bot durchweg alles ersetzt, auch da wo damit überhaupt erst ein Fehler produziert wird. Und das History Spamming nimmt auch langsam überhand. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
soweit ich mich erinnere gibt es dazu eine Anleitung im Wiki, die genau das beschreibt. Die SVGs sind im Prinzip XML-code, d.h. man kann sie durch Ändern der Header so anpassen, dass man sie direkt reinschieben kann. Wiki habe ich schon durch. Der ganze Code muss umgebaut und einiges rausgeschmissen werden. Was ich auch schon versucht habe. Nur irgendwas haut da mit Skallierung und Position nicht hin. Vielleicht nehme ich auch nur das falsche Ausgangsformat. Die Wiki Anleitung sagt nicht viel aus. Konkret will ich beispielsweise den Waldhintergrund topoähnlicher gestalten. Hintergrundfarbe passt schon, nur die Elemente darüber wollen nicht. Ich hatte ja erst mit Kosmos angefangen, ein guter topo Style war schon fertig. Nur kann das Programm keine Multipolygone, rendert ref an jedem noch so kleinen Segment, bricht an manchen Ortsnamen unerklärlich den letzten Buchstaben um, Wegnamen kann man nicht neben den Weg schieben, bei Routenrelationen werden warum auch immer Abschnitte ignoriert, name in Flächenmitte eine Relation geht auch nicht etc. Das Tool ist gut und eigentlich für meinen Fall einer wirklich kleinen regional begrenzten Karte eigentlich erste Wahl, dafür brauchts keine Datenbank. Aber leider eben auch etwas zu simpel und anscheinend durch .net zu eingeschränkt. Dann wollte ich Mapnik versuchen. Das fing schon damit an, dass die Links in der Wiki Anleitung tot waren. Also letztes Release der Post DB von der Seite geholt und installiert. Funktionierte, nur dann wollte ich die PostGIS über stack nachinstallierten und die blieb permanent in der Installation hängen. Damit fällt Mapnik auch erstmal aus. Letzte Chance ist Osmarender. Wenn das auch nicht läuft dann gebe ich es auf. Ohne Informatikstudium scheint man bei den Renderern schon verloren zu haben. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umtragung für Kanus/Paddelboote etc
Für eine brauchbare Wasserwanderkarte auf OSM-Basis wäre vermutlich gar kein sehr großer Aufwand nötig, da die Zahl der befahrbaren Flüsse und der Umtragestellen nicht so groß ist und die Flüsse, Brücken und Zufahrten mit Parkplatz oft schon erfasst sind. Stell dir das mal nicht ganz so einfach vor. Ich hatte auch mal angefangen unseren Fluss entsprechend zu taggen. Umtragestellen und Einsetztreppen auch mit diesen Tags versehen. So wenig sind es nicht. Jeder Ort hat hier ein Einsetztreppe und jede Schleuse kann umgetragen werden. Das geht soweit noch. Weitergehend wirds Bein aber Dicke. Für einige Schifffahrtszeichen gibts noch garkeine Tags. Für andere gibts zwar welche, allerdings von den beiden konkurrierenden Karten. Die eine nutzt dann auch noch normale Tags mit. Und so kann es dir passieren, dass deren DB einfach mal so direkt in den OSM Daten herum schreibt. Ist mir erst letztens passiert. Die nutzen ja beispielsweise für Kontaktdaten an Schleusen wieder eigene Tags, dafür haben wir aber in OSM ja bereits gebräuchliche, die dann auch alle lesen können. Das sieht aber deren DB nicht. Und so hatte einer anhand einer Buchbeschreibung versucht zu taggen. Das Buch hat einen uralten Stand. Meine erst im September nachkontrollierten Sachen waren futsch. Solange die mit ihren Gewässerkartenprojekten also nichtmal mit der Haupt DB auf Harmonie kommen, vorhandenes einfach so überbügeln, macht das erfassen in OSM nicht wirklich Spaß. Dieses nebeneinander her gewurschtle behindert eher als das es was bringt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umtragung für Kanus/Paddelboote etc
Da gibt es zwei Projekte und eines davon baut Scheiße finde ich dem anderen Projekt gegenüber nicht fair. Nenn bei solchen Aussagen doch ruhig Namen. Ich nenne keine Namen, weil so eine Situation generell und auch egal bei welchem Projekt eher subotimal ist. Wenn das nicht sauber miteinander arbeitet dann bitte eine eigene DB, das ganze auf Linie bringen oder eine Prüfungsroutine, welche das vernichten auf der Hauptdatenbank verhindert. Ansonsten kann man so einfach nicht arbeiten. Hast du denjenigen mal angeschrieben? Vielleicht ist das ein Bug in einem von irgendwelchen Skripten, der dann *schleunigst* behoben werden sollte - sonst geht nur nochmehr kaputt. Vielleicht sind die Hintergründe aber auch ganz andere. Nichts mit Bug. In dem Fall war es sogar der Betreiber von einem der Projekte persöhnlich. Der hats auf seinem System nicht sehen können, eben weil man eher mit der Hauptdatenbank konkurriert und überschreibt, statt weitergendes im eigenen System zu machen. Wozu braucht man bitte beispielsweise eigene Tags für Kontaktdaten? Da wertet man beispielsweise einzig den Hauptschlüssel, beispielsweise lock für Schleuse, und entnimmt so nur dort die ohnehin schon etablierten Tags. Nein, da muss ein extra Schema her um nicht vorfiltern zu müssen. Wenn das jeder so macht, hast du einmal die Kontaktdaten im OSM üblichen Schema und darunter noch zwöfunddreißig mal das gleiche mit jeweils eigenem Namensraum. Das bläht nicht nur die DB schön auf, wer ändert denn dann 20 Nummern, wenn sich beispielsweise die Telefonnummer ändert? Ja, eine gewisse Harmonisierung hätte hier inzwischen durchaus seinen Charme. Das wäre eingentlich Grundvorrausetzung damit das überhaupt funktionieren kann. Schlimm genug das zwei Projekte im grunde das gleiche machen und sich gegenseitig angehen. Ich erinnere da nur an den Kindergarten mit dem umtaggen. Woanders hätte man beide auf die Strafbank gesetzt. Es geht aber absolut nicht an, das man die für die Haupt DB gültigen Tags auf der Haupt DB ignoriert und der Bequemlichkeit halber dort eigene größtenteils undokumentierte Schmenen über vorhandenes etabliertes drüberbügelt. Entweder führt man seine Tags in die Hauptdatenbank ein, dokumentiert das auch. Dann kann man von beiden Seiten problemlos arbeiten. Oder man zieht nur die Grundinformationen aus der Haupt DB und hält sein Schema oder die Auswertungsmethode auf dem eigenem System. Man Stelle sich mal vor das jede Anwendungsseite was eigenes macht und lustig auf der DB rumschreibt. Um das zu überblicken muss man auf jeder dieser Seite arbeiten. Die sollen die Informationen ja gerne nutzen, deswegen tragen wir die ja ein. Aber bitte nicht die Haupt DB für die jeweils eigenen Zwecke verbiegen. Da blickt irgendwann garkeiner mehr durch. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM vs. externe DatenBanken (war: Umtragung für Kanus/Paddelboote etc)
- Original Message - From: Ulf Lamping ulf.lamp...@googlemail.com To: talk-de@openstreetmap.org Sent: Sunday, January 31, 2010 5:31 PM Subject: Re: [Talk-de] OSM vs. externe DatenBanken (war: Umtragung für Kanus/Paddelboote etc) Am 31.01.2010 16:02, schrieb Mirko Küster: Da gibt es zwei Projekte und eines davon baut Scheiße finde ich dem anderen Projekt gegenüber nicht fair. Nenn bei solchen Aussagen doch ruhig Namen. Ich nenne keine Namen, weil so eine Situation generell und auch egal bei welchem Projekt eher subotimal ist. ... Dass der Abgleich einer parallelen DB mit OSM einiges an Sorgfalt erfordert, sollte jedem klar sein der sowas aufsetzt. Wenn jemand nicht willens oder schlicht unfähig ist sowas sauber durchzuführen, muß man ihn darauf hinweisen und wenn er sich als uneinsichtig oder unfähig erweist die Probleme abzustellen schlimmstenfalls halt auch sperren. Das dürfte OSM weit aber prinzipiell Konsens sein und dazu brauchst du auch nicht mehrere Absätze zu schreiben. Was dabei genau sauber ist, dürfte allerdings nicht so klar sein, da hat jeder so seine Sichtweise. Sachen ungesehen rauslöschen oder zu überschreiben weil man die bestehenden Daten in seiner eigenen DB nicht sieht, dürfte aber ganz klar unter unsauber fallen. Mit so einer generellen Aussage das sollte man nicht tun bewegst du aber im konkreten Fall erstmal garnichts. Was wir dann brauchen ist: a) was geht schief? b) um welche Elemente geht es (z.B. permalink davon)? c) hast du den Verursacher informiert und (wie) hat er geantwortet? d) ist damit zu rechnen, daß sowas in Zukunft wieder passiert? Wenn du uns nicht die Details der Aktion mitteilen willst, steht der Rest deiner Aussage irgendwie im luftleeren Raum. Da bleibt mir dann nämlich nichts anderes übrig als dir zu sagen: Tja, da können wir dir wohl nicht helfen und müssen warten bis jemand anderes wieder auf das gleiche Problem stößt, der Willens und in der Lage ist wirklich an der Lösung des Problem zu arbeiten. Gruß, ULFL ___ 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] OSM vs. externe DatenBanken (war: Umtragung für Kanus/Paddelboote etc)
Da bleibt mir dann nämlich nichts anderes übrig als dir zu sagen: Tja, da können wir dir wohl nicht helfen und müssen warten bis jemand anderes wieder auf das gleiche Problem stößt, der Willens und in der Lage ist wirklich an der Lösung des Problem zu arbeiten. Das war hier doch garnicht das Thema. Das war nur ein Hinweis das sowas immer mal wieder passieren kann. Der konkrete Fall ist schon etwas her und sehen gibts auch nicht mehr. Da wird einfach zurückgestellt und der Fall ist erledigt. Für mich persöhnlich also nicht so das Problem. Anderes wird lokal gespeichert und fertig. So wie beispielsweise das leidige Spiel mit dem xybot, der auch Eigennamen bei Straßen verschlimmbessert. Eh ich mich da ewig und drei Tage mit Betreiber rumschlagen muss, mache ich das lieber so. Das Problem ist ebenfalls lange bekannt, scheint den Botbetreiber aber nicht zu jucken. Von daher egal. Ich habe da nicht die Zeit für mich mit irgendwelchen Fehlern von Drittanwendungen herumzuschlagen. Erfassen und eintragen ist der Arbeit genug. Mir fehlt da auch der technische Backround um wirklich helfen zu können. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM vs. externe DatenBanken (war: Umtragung für Kanus/Paddelboote etc)
So wie beispielsweise das leidige Spiel mit dem Mirko, der immer öffentlich Probleme benennt aber öffentlich nichts zu dessen Lösung beitragen will. Nicht will sondern schlicht nicht kann. Ich kann dir nur sagen das ich Daten bei OSM eintrage, diese dann von einem anderen Projekt einfach überschrieben wurden, weil man da anscheinend nicht alle OSM Daten sieht. Was die da machen kann ich dir nicht sagen, keine Ahnung. In dem Fall hast du dich doch aufgedrängt. Das Problem war garnicht Thema. Das war nur ein Hinweis das beispielsweise Freietonne OSM Daten mit eigenen Daten überschreibt und das unschön enden kann. Der Fall der mich peröhnlich betrifft war schon vor Wochen in einem eigenen Thema abgesfrühstückt. Was soll ich dazu noch weiter sagen? Außerdem ist das hier doch teilweise auch sinnlos. Da war z.B. die Geschichte mit dem Bicycle, da konnte man sagen was man wollte, du warst ganze vorne dabei generell zu mauern. Wenn das deine Lösung ist dann ist ja alles klar. Wenn ich jetzt nachfrage kommt dabei wohl raus, daß das Problem eigentlich auch schon längst behoben ist. Wieso kommt mir gerade der Gedanke, daß eine weitere Diskussion mit dir schlicht Zeitverschwendung ist? In meinem Fall ja, hatte ich ja bereits geschrieben. Was da generell läuft kann ich nicht sagen, ich bin kein Programmierer und weiß auch nicht was bei den Projekten so läuft. Wenn du wissen möchtest wie die da auswerten und in der DB herumschreiben, musst du schon die Projektverantwortlichen selber befragen. Ich bin einfacher Mapper, kein Programmierer. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osmarenders eingebaute pattern anpassen
Hallo, folgendes Problem. Mit dem Offline Frontend lassen sich die Styles ja soweit gut anpassen. Nur eines nicht, die vordefinierten Flächenmuster. Die stecken Hardcode als XML im Style und werden nicht als eigenes svg wie die Icons geladen. Ich bin soweit gekommen das ich den Quelltext aus einem mit Inkscape erstellten svg soweit verbogen und in den Style gefrickelt habe, das es teilweise funktioniert. Bei einem Element funktioniert das nicht, das andere sitzt nicht genau da wo es sitzen sollte. Gibt es irgendeine Möglichkeit ein fertiges svg in stylekonformen Code zu übersetzen, oder wie haben die Entwickler das gebaut? Oder kann man gar die hardcode pattern rausnehmen und ein normales svg für Flächen verlinken? Gruß Mirko___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
