[OSM-talk] List of alternative fuel stations for the US
Hi, an article (sorry, in German) http://www.golem.de/1104/82985.html pointed out there is a list of alternative fuel-stations provided for the US. That especially includes new electric fuel-stations, apart from the gas-stations which have been around for some time. http://www.afdc.energy.gov/afdc/locator/stations/ When trying to download the data you must accept terms and conditions, which -if I read them right- provide free rights to use the data for other purposes (may be used for any purpose whatsoever). Might it be interesting to contact them for a cooperation, maybe setup a small sync for that dataset? Kind regards, Stefan Neufeind ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] is this usage of osm a violation of cc-by-sa?
On 02/16/2010 03:50 PM, Jonas Stein wrote: http://www.troiki.de/karte.jpg http://www.troiki.de/anfahrt.html They don't have any attribution on the pages, otherwise is the kind of I'll take care of it and inform them. On the webpage there is still no change. What did they say? Hi, unfortauntely even after giving them a bit more time I still didn't hear _any_ feedback from them. According to Frederik's good suggestion to maybe not bug the legal-talk with reminders about this any longer I'll take this thread off-list for the moment. And I'd be happy to coordinate with you, Jonas, how we proceed with them. As the wiki-page Frederik mentioned http://wiki.openstreetmap.org/wiki/Lacking_proper_attribution suggests I'll give it a second try to contact them. Kind regards, Stefan Neufeind ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] You may not sublicense your rights under these Terms to any person
On 02/11/2010 11:08 AM, Oliver Kuehn (skobbler) wrote: Hi Mike, you can use the data and display them on the OSM map but not import them into the OSM database itself. The license terms of the National Public Toilet Map dataset are not compliant with Create Commons Attribution-ShareAlike 2.0 license, which says You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License (Attribution-ShareAlike 2.0). The showstopper here is viral element (heriditary). You should approach the authorities if they are willing to grant you a separate Attribution-ShareAlike 2.0 license for the data set. Agreed, trying to ask them would be a good thing. Has helped in some cases in the past where authorities (city government or the like) re-thought their license :-) By the way: Is there a list of data that can be used but maybe not (yet) merged somewhere? Maybe that could also hold information about who tries to approach an authority or in case we fail that data is still listed somewhere to be usable for mashups etc. Regards, Stefan ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] You may not sublicense your rights under these Terms to any person
On 02/11/2010 12:11 PM, James Livingston wrote: On 11/02/2010, at 8:14 PM, Stefan Neufeind wrote: Agreed, trying to ask them would be a good thing. Has helped in some cases in the past where authorities (city government or the like) re-thought their license :-) The Australian Toilet Map data got discussed on talk-au back in December, and from the discussion the problem is that the department's records of where various data came from is a bit sketchy, so they aren't sure they can actually put it under a better licence :( Hmm, so actually we'd need some volunteers on a toilet trip to go there, check the toilet details and map it from their own site-survey. Maybe that would even get sponsored by the government since the license of that data is clear afterwards? *heh* Regards, Stefan ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] TMC: new location code table version 9.0 for Germany
On 02/10/2010 02:02 PM, Claudius wrote: Am 10.02.2010 11:27, Marcus Wolschon: http://www.bast.de/cln_005/nn_42544/DE/Aufgaben/abteilung-f/referat-f4/Location-Code-List/location-code-list-start.html Praktische Auswirkungen auf uns bzw. auf den TMC Validator? Die IDs werden ja nur fortgeführt und nicht geändert, oder? Also müsste nur die Datenbank des Validators aktualisiert werden, korrekt? Abgesehen von eventuellen Fehlerkorrekturen sollten dort keine Änderungen sondern nur Ergänzungen erfolgen, ja. Somit wäre o.g. Validator (und ggf. Websites o.ä. die TMC-Infos verwenden) anzupassen. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC Validator - Innerorts/Außerorts
On 01/13/2010 05:34 PM, Michael Bemmerl wrote: Zitat von Sven Anders s...@anders-hamburg.de: Im Besonderen würde mich interessieren, ob diese Angabe aus den TMC-Daten kommt oder ob die aus OSM-Daten ermittelt wurde (z.B. Punkt liegt innerhalb einer boundary-Relation mit entsprechendem admin_level). Er kommt aus den TMC Daten. Haben wir bereits eine Wiki-Seite für Fehler bzw. Ungereimtheiten in den TMC-Daten? Ich hab' bereits ein paar Punkte gefunden, die z.B. laut TMC außerorts sind, aber in Wirklichkeit innerorts sind. Oder ein Punkt, der in der falschen administrativen Ebene ist (eigentlich in einer andere Gemeinde). Ich glaube nicht. Vielleicht einfach erstmal eine Seite zugehörig zu TMC im Wiki aufmachen? Wo es klare Fehler sind würde sich ja obendrein vielleicht auch das BASt über eine Info von dir freuen. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] is this usage of osm a violation of cc-by-sa?
On 02/05/2010 12:31 PM, Chris Hill wrote: Jonas Stein wrote: http://www.troiki.de/karte.jpg http://www.troiki.de/anfahrt.html if so, should someone contact troiki and explain how to use the osm maps correct. They don't have any attribution on the pages, otherwise is the kind of use of OSM I would hope to see. If my schoolboy German would stand it I'd write to say how good it is to see them using OSM, and would they mind adding an attribution please. They need to sort it out before Lulu-Ann sees it :-) I'll take care of it and inform them. Kind regards, Stefan ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Use of OSM data by the military and/or intelligence services
On 02/04/2010 09:15 PM, Rob Myers wrote: On 04/02/10 14:49, Martin Koppenhoefer wrote: AFAIK our current license offers our data for everyone who attributes correctly, but I'd like to raise the issue of malicious use of our data by governmental organisations. What do you thing about setting up a paragraph that prohibits the use of our data for military and intelligence services? Not that I'm hoping this would seriously prevent the use in case we have useful data to them, but still it would be a statement. [...] A discriminatory licence would prevent all of these benefits while not preventing military or espionage use or creation of other map data that we do not get access to. I mention these points as illustrations of the argument that abandoning a commitment to freedom would be bad, not in addition to it. I agree on that. Imho freedom and openness in this context is what counts. And if they were to use our data (with proper attribution) and maybe even contribute to it, I don't see a reason why _we_ shouldn't be open. Kind regards, Stefan ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Track-Anonymisierer gesucht
Johann H. Addicks wrote: Bernd Wurst schrieb: Also wer [...] aktiv Tracks hochlädt [...]. Ich finde deine Annahmen etwas willkürlich und falsch. Ich wünsche mir ein Desktop-Programm zum Anonymisieren von von GPX-Dateien. Das ganze sollte a) Datum und Uhrzeit des Tracks anonymisieren [...] Hi, warum dann einen Teil der Anonymisierung nicht gleich beim Hochladen in der API machen? Interessieren im zentralen Repo noch z.B. Timestamps (wer war _wann_ dort)? PS: So ganz überzeugt bin ich aber noch nicht das die Tracks zentral hochladen überhaupt sinnvoll ist - lade also entsprechend keine hoch, wie sicher einige andere Leute ebenfalls. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Bernd Wurst wrote: Hallo. Halbwegs off-topic, aber ich hoffe mal, jemand weiß dazu etwas... Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt auf die Straßenabschnitte projeziert werden? Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich nicht glauben mag, dass die TMC-Daten Freitext a la A8 zwischen Kreuz Stuttgart und Dreieck Leonberg enthalten sondern ich würde erwarten, dass es da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben. Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon? Oder ist das alles prorietär, keiner weiß was davonund man kann sich die Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-) Hi, ich habe mal ausführliche Infos dazu in den Händen gehabt. Hab zuletzt für jemand anders auf dieser Liste schon mal danach geforscht (aber meine Unterlagen bisher noch nicht wiedergefunden). Was ich weiss ist, daß alle Zustände sowie auch Abschnitte etc. numerisch kodiert sind. Es gibt eine Location-List. Es könnte also ggf. sinnvoll sein hier eine Zuordnung zu schaffen bzw. für einzelne Abschnitte die Zuordnung ggf. direkt in die OSM-Daten aufzunehmen. Och Mensch ... wo hab ich die Sachen nur ... Zentraler Kontakt für einen Dienst den wir damals angedacht hatten war die Polizei NRW (ich glaube in Düsseldorf), die auch zentral eine Schnittstelle anbieten über die die Verkehrsinfos zu beziehen wären ... übrigens kostenlos und per TCP als Feed. PS: Was der WDR aussendet sind nochmal etwas aufbereitete Infos, die arbeiten auch noch mit dem ADAC sowie ihren eigenen Staumeldern zusammen und ergänzen. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Ulf Lamping wrote: Florian Lohoff schrieb: D.h. bei den maxspeeds gaebe es noch interesse - ist bloss schlecht gepflegt - und bei hoehe, breite oder gewicht interessiert es den normal-mapper nicht und es wird auch nicht visualisiert. Hab jetzt gerade mal im JOSM eine Icon Darstellung eingebaut (eingebaut hatte ich das schon ne Weile her, aber jetzt habe ich noch einen Bug gefixt). Eine maximale Höhe /Breite / ... wird jetzt im JOSM mit dem entsprechenden deutschen Verkehrszeichen dargestellt. Gilt nur für Nodes - Breite, Höhe, etc. sollte ja eh eher eine punktförmige Stelle sein. Eine spezielle Linien-Darstellung im JOSM ist mit den aktuellen Möglichkeiten nicht wirklich machbar ohne die Darstellung komplett zuzumüllen ... Spontan denke ich z.B. an einen Tunnel, dem jemand eine Höhe gibt. Ich gebe dir Recht, daß das in der Sache eher punktförmig ist, aber wäre es vielleicht sinnvoll das dann auch analog als Anfang/Ende einer Strecke zu supporten oder alternativ ein Symbol dann auf die Mitte der Strecke zu setzen o.ä.? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nahverkehrsmittel für OSM-Datenerhebun g einsetzen
Kai Behncke wrote: Liebe Liste, für ein Projekt (http://www.gis-camp.de) wird gerade überlegt, ob man den örtlichen Nahverkehr für eine Weile mit GPS-Empfängern ausstattet und Tracks mitloggt (die dann natürlich aufbereitet in OSM kommen). Ein herkömmliches GPS-Gerät scheint mir da nicht so günstig zu sein (Stromversorgung, Speicher), oder irre ich? Gibt es Ideen wie man so etwas technisch elegant und einigermaßen kostensparend umsetzen kann? Hi, die Stromversorgung kannst du bei manchen ja auch per USB o.ä. zuführen, wenn du nicht am Gerät selbst montieren willst. Da ließe sich ja eine beliebige 5V-Quelle dransetzen. Und es gibt auch große USB-Akkupacks etc. :-) Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schranke taggen
Marc Schütz wrote: Am Samstag 18 Oktober 2008 14:35:49 schrieb Andreas Labres: Ulf Möller wrote: Beide Sackgassen enden im selben Punkt, der Schranke. Das geht nicht. Damit wären sie verbunden. Und damit keine Sackgassen mehr. Die Straße hört doch aber unter der Schranke nicht auf? Wenn man die Schranke wegdenkt, geht sie doch ganz normal weiter, oder? Dann muss sie auch verbunden werden. Dem stimme ich zu. Desweiteren stellt sich mir die Frage, wie wir denn Schranken einzeichnen die standardmäßig geöffnet (!) sind. Es gibt solche teilweise in Stadionnähe - die sind dann nur zu großen Spielen geschlossen o.ä. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Philosophie
FreeWorld wrote: Bernd Wurst schrieb: Hallo. Am Mittwoch, 1. Oktober 2008 schrieb FreeWorld: Tenor der Diskussion: Sollte OSM einmal einen ernst zu nehmenden Vollständigkeitsgrad erreicht haben, so wäre es quasi extrem einfach möglich Unternehmen gezielt in die Karten zu schaun. Man macht beispielsweise monatliche Snapshots und schaut sich über Jahre hinweg die Entwicklung der Bahn und ihre Geschäftspolitik an. Welche Strecken werden nicht so wichtig genommen, welche wurden verkauft, was rechnet sich wohl für die Bahn am besten? Ich seh schon die Bild-Schlagzeilen: Bahn pfeift auf Kunden in Hintertufftuffdorf! Welchen Unterschied machst du hier zwischen - OSM und anderen Kartenwerken? Um solche Informationen rauszulesen muss eine Karte keine freie Lizenz haben, das darfst du von Google-Maps genauso lernen, wo es neue oder nicht mehr vorhandene Bahnstrecken gibt. - OSM und dem Kursbuch der Bahn? Schließlich steht dort ganz genau drin, welche Strecken wie stark (für Personenverkehr) genutzt werden und jedes Jahr ändert sich da einiges. Naja der Unterschied ist doch, dass ich bei OSM ohne Probleme alle Daten in der Datenbank analysieren kann, wies mir passt. Klar sind manche Infos auch in kommerziellen Karten enthalten - man kann sie dort aber nicht so leicht extrahieren. Nur weil ich irgendwo auf ner kommerziellen Karte n Aldi sehe, kann ich noch nichts über die Entwicklung des Aldikonzerns in Deutschland sagen. (Na gut, mit entsprechendem Aufwand und Analyse der Tiles, was sicher illegal ist, kann man vielleicht die Infos extrahieren und ne eigene Datenbank aufstellen...) Möglicherweise gibt es auch andere Unternehmen, die irgendwie ein Problem hätten komplett in OSM gemappt zu werden. Genausogut kann man ja die Geschäftspolitik beispielsweise von McDonalds oder Burger King oder der Post oder was weiß ich beobachten. Für Konkurrenzunternehmen sicherlich attraktiv. Warum? Ich glaube nicht, dass es ein Geschäftsgeheimnis ist, wo es wie viele McDonald's-Restaurants gibt. Schließlich gibt es auf der Website eine Liste davon. Und in jedem modernen Navi stehen diese Daten auch drin, jährlich aktualisiert und damit wunderbar geeignet um daraus Schlüsse zu ziehen. Stimmt schon. Wenn ich dort die Entwicklung über der Zeit verfolgen will, müsste ich halt ständig die aktualisierte Liste ziehen und auswerten. [...] 2. Kann ein Unternehmen rechtliche Schritte einleiten oder sich sonst irgendwie wehren, weil es in OSM auftaucht? Es gibt momentan ernsthafte Probleme, etwas handfestes zu finden wie man Google-StreetView rechtlich beikommen kann. Und die tragen nicht nur Informationen von öffentlich aufgehängten Werbetafeln ein sondern das kritische daran ist die Fotografie von Personen und nicht-öffentlichen Gebäuden. Und trotzdem scheint das so nicht angreifbar zu sein. Also ich denke nicht, dass alleine mit der Erfassung von da steht ein McDonald's-Restaurant und das ist ungefähr die Gebäudeform irgendwas zusammen getragen wird, was jemandem schadet. Dann frage ich mich aber erneut, warum die Unternehmen nicht einfach ihre Standortgeodaten rausrücken, damit sie in OSM auftauchen. Ist OSM zu unbekannt? Gibts lizenrechtliche Probleme? Gibts irgendwelche anderen Nachteile für die Unternehmen? Ein größeres Unternehmen mit dem ich zuletzt mal sprach hat die Probleme, daß ihnen selbst nur die Adressen ihrer Niederlassungen bekannt sind. Die wurden zwar geokodiert, jedoch können jene Daten nicht mit gutem Gewissen an OSM übergeben werden. (Es gab da mal einen separaten Thread zu.) Andere Unternehmen (Kieser, ...) zeigen ja das es durhcaus auch welche gibt die Daten spenden. Wie (lizenzrechtlich sauber) die ihre genauen Koordinaten allerdings ermittelt haben, ist vermutlich noch zu klären ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Info zu graphischen Symbolen aus DIN-Normen
Tobias Wendorff wrote: Hallo Leute, bei uns kam ja in letzter Zeit immer wieder die Frage auf, ob wir Symbole aus DIN-Normen im Original oder abgeändert verwenden dürfen. Folgende Rückantwort habe ich vom besagten Institut bekommen: graphische Symbole in DIN-Normen unterliegen keinem marken-/namensrechtlichen Schutz. Sie unterliegen dem Urheberschutz, sind aber für den bestimmungsgemäßen Gebrauch frei anwendbar. Da es sich um eine Gebrauchsgrafik handelt, entscheidet die Schöpfungshöhe (Kleine Münze greift nicht). D.h. aber im Zweifelsfall doch lieber freie Pendants finden, da sie die ja nicht ausdrücklich unter einer freien (zu OSM kompatiblen) Lizenz bereitstellen? Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rückantwort der Deutschen Bahn bzw. DB Netz AG
Können wir das irgendwie organisieren, z.B. das jemand ne Liste aus den OSM-Daten generiert nach Postleitzahlgebieten oder so, und jemand die dann jeweils abhaken kann? Einen Großteil kann man sicher mit local knowledge mal eben machen, wenn man in der jeweiligen Stadt wohnt. Stefan Dieter TD wrote: So richtig kann ich mir das mit den Geschäftsgeheimnissen auch nicht vorstellen. Ich denke, wir sollten ihnen den Gefallen tun und jeder für sich in seinem Bereich prüfen, was Bahnhof und was Haltepunkt ist :-) Gruß Dieter -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Thorsten Feles Gesendet: Dienstag, 30. September 2008 18:50 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Rückantwort der Deutschen Bahn bzw. DB Netz AG Tobias Wendorff schrieb: Jens Frank schrieb: Verstehe ich das richtig, dass die Bahn der Meinung ist, dass die Liste ihrer Bahnhoefe ein Geschaeftsgeheimnis ist und dass die nicht oeffentlich bekannt sein sollen? Dann wundert es mich nicht, dass sie Probleme haben, Kunden zu gewinnen. Die Liste mit Bahnhöfen haben wir ja schon. Ich habe angefragt, ob sie uns die Klassifizierungen mitteilen könnten, damit der DB-Auftritt fehlerfrei in OpenStreetMap erscheint. Ich denke, kurz vor dem Verkauf der DB-Anteile ist es wirklich für die Bahn unklug zu sagen, wie viele der Bahnhöfe wirklich technische Bahnhöfe und nicht nur Haltepunkte sind. Ich kann mir nicht vorstellen, das es sich hier um Geschäftsgeheimnisse handelt. Immerhin unterliegt das Netz der Regulierung durch die Bundesnetzagentur. Aber vielleicht können die weiterhelfen, wenngleich es auch recht schwierig ist bei denen an den/die richtige(n) Frau/Mann zu kommen. Gruß Thorsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizensänderung?
André Reichelt wrote: Dirk Stöcker schrieb: Wie das passieren soll, ist mir vollständig schleierhaft. Wenn alle Daten, die unter cc-by-sa stehen und nicht relizensiert werden aus der Datenbank rausfliegen, dann werden einige Leute, z.B. ich ganz schön sauer. Nicht weil ich der Relizensierung nicht zustimmen würde, sondern weil sehr wahrscheinlich komplette von mir mit viel Aufwand korrigierte Gebiete zerstört werden, da dort ja ursprünglich ein anderer Autor aktiv war. Oder irgendwer hat meine originalen Tracks verändert und diese fliegen deshalb raus. Irgendwie stehe ich gerade auf dem Schlauch... Warum soll jetzt plötzlich die Lizens geändert werden und in welche Lizens soll das Material überführt werden? Außerdem dachte ich immer, dass eine nachträgliche Änderung der Lizens nicht möglich sei. Könnte mich bitte jemand aufklären? Danke! Bei einer Lizenzänderung können nur jene Sachen übernommen werden bei denen die Autoren der Änderung zustimmen. Den aktuellen Status kenne ich nicht genau, aber es wurde bereits mehrfach angesprochen, daß die aktuelle Lizenz für die OSM-Bedürfnisse (Datenbank/Datenbestand statt z.B. Sourcecode oder Musik) nicht in allen Belangen passend ist und deswegen ggf. eine andere (ähnlich offene) Lizenz sinnvoller seien könnte. Einzige Chance aus meiner Sicht wäre imho eine neue Lizenz zu finden, ggf. für eine Übergangszeit bereits offiziell ein dual-licensing einzuführen und zu versuchen die Autoren früheren Materials anzusprechen um deren Zustimmung zu einer Re-Lizenzsierung einzuholen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Quellenangabe bei Weiterverarbeitung
André Reichelt wrote: Frederik Ramm schrieb: Man koennte alle User anschreiben und sagen wenn Du nicht innerhalb von 2 Monaten widersprichst, werten wir das als Zustimmung. Das halte ich für die wohl beste Möglichkeit, das Problem zu beseitigen. Die Frage ist natürlich, ob das rechtens ist, aber da stellt sich dann wieder die Frage, ob die Leute, die innerhalb von zwei Monaten nicht reagieren und das dann erst merken noch wirkliches Interesse an ihren Daten haben. Außerdem muss man bedenken, dass früher oder später die Daten eh überarbeitet werden. Ich vorab zu ganz unkompliziert find ich den nachfolgenden Vorschlag auch nicht, aber könnte man vielleicht eine Zusatzklausel einfügen, daß Mitarbeiter am Projekt ihre Kontaktdaten pflegen und in angemessener Zeit (z.B. imho auszulegen als 3 Versuche jeweils mit 4 Wochen Abstand?) kontaktiert werden können sollten? Wenn dies nicht mehr der Fall ist, würden sie automatisch einer Übertragung ihrer Rechte an die Foundation zustimmen, die dann (natürlich im Optimalfall in ihrem Sinne) handeln würde. So könnte man vermeiden, daß Leute unmittelbar alle Rechte abtreten müssen aber bei Nichterreichbarkeit dennoch die Daten irgendwie verwendet werden können. Würde es dafür dann Sinn machen ggf. weitere Kontaktdaten (alternative Emailadressen, Telefonnummern, postalische Adressen o.ä.) zu sammeln? Vielleicht gibt es ja jemanden mit einer gmx-Adresse als primäre Kontaktstelle, die er tatsächlich in 5 Jahren nicht mehr hat und da auch nicht mehr dran denkt? (Sehen wir mal von den Leuten ab die eigene Domains haben und diese auch vermutlich ein Leben lang behalten möchten.) sn ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Große Fläche Feuerwehr
Florian Schmitt wrote: Hi, Am 19. September 2008 10:16 schrieb Markus [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Dass sich der Punkt so lange hält kommt wohl daher, dass die Meisten für die Renderer arbeite... (denn wenn der Punkt nicht zusätzlich zur Fläche eingetregen wird, zeigen die Renderer nichts an. Und das will man ja anders... nicht nur. Auch auf den Garmin-Karten wird für amenities, die nicht als Node, sondern als Polygon (building) eingezeichnet sind, kein POI erzeugt. Das wirkt sich dann auch aufs Routing aus. Im übrigen: wieso soll amenity=fire_station, building=yes schlechter sein als building=fire_station? Konsequenterweise müßte dann jedes Gebäude, egal ob amenity, shop, tourism (Hotel!) oder leisure, als building=* getaggt werden. Damit geht die ansatzweise Kategorisierung verloren, die in dieser Unterteilung steckt. Die Gebäudeeigenschat von der Nutzung zu abstrahieren ist sinnvoll, zB weil ein sport-Polygon entweder eine Sporthalle (bulding) oder ein Sportpark (normale area) sein kann. Ich gebe dir Recht, daß es sinnvoll seien kann ein building=yes hinzuzufügen. Aber zur Not kann es ein Renderer ja einfach als etwas ungenaueren Umriss betrachten und meinetwegen annehmen es handelt sich um eine area. Die eigentliche Information ist doch da ist eine Feuerwehr - auch wenn damit ein Polygon getagged ist. An einigen Stellen habe ich nun schon Sachen gesehen, wo sowohl die Area als z.B. Schule (inkl. Name) als auch ein Node in der Mitte genauso getagged war. Das ist klar mappen für den Renderer bzw. den Naviexport. Könnten jene Renderer- / Naviexport-Spezis nicht vielleicht mal schauen das entsprechend umzusetzen, so daß sie sich zur Not selbst einen Mittelpunkt generieren beim Lesen der Daten um dort dann ein Symbol zu platzieren? Das ist sicherlich nicht trivial (sonst würde ich mich selbst anbieten das umzusetzen), aber sicherlich lösbar. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Große Fläche Feuerwehr
Frederik Ramm wrote: Hallo, die gaengige praxis ist eigentlich, sogenannte points of interest als punkte festzuhalten, das sagt ja bereits der name. Da leidest Du ein bisschen an Deinem eigenen Tagging-Schema; bei uns handelt es sich ja nicht um POIs, sondern um amenities oder aehnliches. Das sagt ja bereits der Name zieht also nicht. In OSM wird gemeinhin bei Fehlen detaillierter Flaechen-Info ein amenity=irgendwas an einen Node getaggt, und wenn man eine Flaeche hat, kommt der gleiche Tag an die Flaeche. Von POIs sprechen wir dabei gar nicht. wenn jemand die flaeche festhalten will bekommt die nur ein tag, das die generelle flaechennutzung beschreibt, bzw. ob es ein gebaeude ist. die wird dann per relation an den punkt gebunden. fertig. Relation zur Verknuepfung Gebaeude - Eingang finde ich gut. Dennoch ist der Punkt allenfalls der Eingang zum Supermarkt - der Punkt ist nicht der Supermarkt. Daher wuerde ich weiterhin die Flaeche als Supermarkt taggen und nicht den Punkt. Dito. sn ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kommunale OSM-Info beim RVR
Frank Jäger wrote: Hallo, organisiert durch den 'Regionalverband Ruhr' (www.rvr-online.de) fand heute (17.09.08) in Essen eine OSM-Informationsveranstaltung für Kommunalverwaltungen statt. Ca. 10 Kommunen hatten Vertreter geschickt. Die 50 Mitgliedskommunen des Verbandes werden das Ergebnisprotokoll bekommen. [...] Hallo Frank, hast du einen Link was alles zum RVR gehört, wer also die 50 sind? Auf deren Website hab ichs auf Anhieb nicht finden können ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenbestimmung
Bernd Wurst wrote: Hallo. Am Donnerstag, 18. September 2008 schrieb [EMAIL PROTECTED]: wobei ele sich immer auf ein Objekt am Boden oder den Boden selber bezieht ;-) Was für die meisten Objekte in unserer Datenbank gar nicht so verkehrt ist. :) Kommt drauf an wie hoch über dem Boden ein Briefkasten montiert ist? *duck* Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] speed_camera - wo platzieren
Dirk Stöcker wrote: On Tue, 16 Sep 2008, Wolfgang van Oorschot wrote: Nein. Es ist illegal während der Fahrt ein betriebsbereites Gerät mitzuführen, welches in der Lage ist solche Daten anzuzeigen. Legal dagegen ist es, wenn Du eine Karte ausdruckst und diese von Deinem Beifahrer vorlesen lässt. Unser Datenbestand ist also auch mit Blitzern in Deutschland nicht illegal. Dann darf also demnächst kein Schweizer mehr OSM-Karten legal auf seinem Navi benutzen. Ich halte es für einen echten Fehler Blitzer in die Karte einzufügen. Wieso? Wer zwingt denn den Schweizer-Nutzer oder sonstirgendeinen diese speziellen POI's ins Navi zu überführen? Zur Nutzung als Navigationskarte ist sowieso eine Filterung nötig, oder willst Du wirklich den gesamten Datenbestand ins Navi übernehmen. Kaum vorstellbar. Ich denke bei OSM besteht immer noch der Grundsatz, dass wir uns keine Beschränkung hinsichtlich der Datenvielfalt auferlegen wollen. Dem schließe ich mich an. Wenn sie jemand in den Datenbestand einträgt, soll er (technisch) die Möglichkeit dazu haben. Ob/wie sie nachher genutzt werden, ist jedem einzelnen überlassen. Und pflegen braucht sie ja auch nur jemand der mag. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Warnwesten - Bestellung
Tobias Wendorff wrote: Hallo Leute, ich mache mal einen neuen Post auf, weil der alte zu unübersichtlich wurde. Objekt der Begierde (Größe 2XL, damit sie auch über die Jacke passt): http://raumplanung.tobwen.de/OSM/images/warnweste_01.jpg Website der Bestellung (bitte auch/nur eine Mail an mich): http://wiki.openstreetmap.org/index.php/De:Merchandise Bedruckt wird im Siebdruckverfahren, also höchste Qualität. Mit Grundierung, damit das Logo in Fotoqualität rüberkommt. Wenn jemand eine bessere Schriftart für Vermessung kennt, bitte melden :-) So, die Nachzügler trudeln nun auch ein :-) Hab noch ein paar Leute drauf angesprochen etc. Also mit .org wäre die URL imho schon etwas sinnvoller, da offizielle URL des Projekts. Bedarf im Wiki ist nachgetragen. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Warnwesten - Bestellung
Hallo Jürgen, (diesen Reply an die Mailingliste ... ich bins nicht der die Bestellungen verwaltet *g*) ich habs mal im Wiki nachgetragen. Imho wird der Preis wohl bei so ca. 10 Euro liegen nach der aktuellen Anzahl ... Grüße, Stefan Juergen Lehle wrote: Hallo Stefan, ich hätte auch gerne zwei Warnwesten. Falls der Preis noch sinkt evtl. auch mehr. Viele Grüße Jürgen Lehle http://openstreetmap.org/user/JuergenL Am 13. September 2008 17:15 schrieb Stefan Neufeind [EMAIL PROTECTED]: Tobias Wendorff wrote: Hallo Leute, ich mache mal einen neuen Post auf, weil der alte zu unübersichtlich wurde. Objekt der Begierde (Größe 2XL, damit sie auch über die Jacke passt): http://raumplanung.tobwen.de/OSM/images/warnweste_01.jpg Website der Bestellung (bitte auch/nur eine Mail an mich): http://wiki.openstreetmap.org/index.php/De:Merchandise Bedruckt wird im Siebdruckverfahren, also höchste Qualität. Mit Grundierung, damit das Logo in Fotoqualität rüberkommt. Wenn jemand eine bessere Schriftart für Vermessung kennt, bitte melden :-) So, die Nachzügler trudeln nun auch ein :-) Hab noch ein paar Leute drauf angesprochen etc. Also mit .org wäre die URL imho schon etwas sinnvoller, da offizielle URL des Projekts. Bedarf im Wiki ist nachgetragen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Large Hadron Collider at CERN now in OppenStreetMap
Andrew McCarthy wrote: On Wed, Sep 10, 2008 at 06:28:15AM -0700, Karl Newman wrote: On Wed, Sep 10, 2008 at 1:57 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: Its not perfectly positioned and I think the circumference is a tad short but I made a reasonably good insert of the CERN LHC (and SPS) into the database last night in time for the first full circle beam test of the LHC, which has just successfully completed. So, for anyone wanting to know exactly where the two accelerator rings are in the world it's now possible to point them to OpenStreetMap. Another first for community mapping :-) http://www.openstreetmap.org/?lat=46.2731lon=6.073zoom=12layers=0B00FTF I hope the data made the planet dump (JIT), in which case it should appear also on the Mapnik layer shortly. For now the two rings are tagged with highway=trunk and highway=primary respectively. They also carry tunnel=true of course. There are a couple of big notes tagged as well that confirm the highway tag is less than ideal and that something better needs to be used. But for now, since they don't connect with the road network I don't think anyone will be routing over them ;-) enjoy Cheers Andy Not sure if you should be chastised for tagging for the renderer or commended for the PR effort :-P Perhaps highway=footway, bicycle=yes, access=private isn't too far from the truth? :) highway=footway, foot=no, particle=yes Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] TU Darmstadt Gebäudenummern
Alex Pleiner wrote: Hallo OSMler, ich habe gestern in Darmstadt alle fehlenden Gebäude der TU (Stadtmitte, Lichtwiese und Bot. Garten) nachgetragen und mit Gebäudenummern, Institutsnamen (sofern vorhanden) und Fachbereichen versehen (name). Stadtmitte: http://www.openstreetmap.org/?lat=49.87649lon=8.65726zoom=17layers=0B0FTF Lichtwiese: http://www.openstreetmap.org/?lat=49.86152lon=8.6807zoom=17layers=0B0FTF Botanischer Garten: http://www.openstreetmap.org/?lat=49.86925lon=8.68053zoom=17layers=0B0FTF Grundsätzlich würde ich die Gebäudenummern eher im ref-Tag sehen, andererseits fragen mich die Studenten immer: Wo ist denn S3|06?, so dass ich diese Info fast als wichtigeste ansehen würde. Dazu kommt, dass die Kombi aus Nummer, Gebäudename und/oder Fachbereich manchmal arg lang und häßlich aussieht. Mich würde eure Meinung interessieren, wie man das lösen könnte und ob es ein einheitliches Konzept für Gebäudenummern (nicht Hausnummern) gibt. Ref klingt imho logisch. Nur bräuchten wir dann vielleicht auch die ref-Angaben in den Karten (afaik derzeit nicht?). Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: was sind das für Icons
Michael Buege wrote: Zitat Jan Tappenbeck: ich habe in meinem Gebiet eine Vielzahl von gelben rechteckigen Icons mit einem Ausrufezeichen ! Was bedeuten diese und wie könnte ich diese ggf. eleminieren ? Das sind Notes, die z.B. mit highway- und name-Tags versehen wurden. Wenn Du die Tags entfernst, verschwindet auch das Icon. Habs mal bereinigt. Es waren auf zig Nodes eines Wegs highway=footway name=... gesetzt, was aber jeweils den Angaben des zugehörigen Wegs entsprach. Kam vermutlich durch markieren eines Bereiches im Editor und dann wurden neben dem Weg auch die Nodes markiert. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von kurzen Straßenstück en steuern
Christian Mayr wrote: osmarender:renderName=no Sowas wird von mir entfernt, sofern ich an diesem Teilstück irgendwelche Änderungen vornehmen muss. wieso ? Wie auch immer - ich entferne solche Tags auch grundsätzlich, wenn ich sie sehe. Unser Ziel darf es nicht sein, Fehler in den Renderern durch Rendererweichen zu beheben. Wenn der Renderer mit den Daten nicht zurecht kommt - Pech. Die einzige Lösung ist, dass man die Fehler direkt an der Quelle behebt und nicht mit Workarounds schafft. Das führt nur zu Problemen, wenn irgendwann nicht mehr nur Mapnik und Osmarender undere Daten verarbeiten. Ist ja schön und recht, ich halte es aber für äußerst fragwürdig von einem anderen Mapper das einfach komentarlos zu löschen. Ich würde mich ans Bein gepisst fühlen wenn mir jemand meine Arbeit mutwillig zerstört. Wenn die Renderer das dann mal einfach so können ist es ja ein leichtes die entsprechenden Tags mit einem script aus der ganzen db zu entfernen. Und wenn es nicht gewünscht ist sochle tags zu verwenden warum wird das dann vom renderer ausgewertet? Ich sehe es an dieser Stelle persönlich als dirty hack bzw. quickfix, bis jemand eine saubere Möglichkeit implementiert um Sonderfälle zu umgehen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von kurzen Straßenstück en steuern
André Reichelt wrote: Sven Anders schrieb: Und warum will mir jemand verbieten bestimmte Tags zu verwenden und mich in meiner Freiheit bei OSM beschneiden? Es verbietet Dir ja niemand, solche Tags zu setzen. Aber die Freiheit ist gegenseitig, denn ich nehme mir die Freiheit, das wieder zu löschen. Nochmal, wir stellen eine Datenbank zur Verfügung, die eine Straßenkarte beinhaltet, also KEINE Steuerungskartei für irgend einen Renderer. Wenn so etwas wirklich nötig ist, dann sollte der Betreiber von Osmarender doch bitte eine externe Datenbank bereitstellen. Andre, du musst zugeben das schießt auch etwas übers Ziel hinaus. Genauso hättest du schreiben können wenn wir schon _seinen_ Renderer verwenden, dann möchte er das doch bitte endlich sauber reparieren. *lol* Jungs, geht mal vor die Tür und vertragt euch dann wieder ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wlan von maps.fon.com
Martin Koppenhoefer wrote: Am 28. August 2008 17:50 schrieb Per Hansen [EMAIL PROTECTED]: Christoph Eckert schrieb: [...] Andererseits stören die Hotspots ja in unserer Datenbank erstmal nicht. Warum also nicht 'drinnelassen und abwarten, ob die Fon-Jungs die Dinger pflegen? Falls ja ist es doch super. Falls nein kann man sie in einem halben Jahr noch immer 'rauswerfen. Na die stören schon. Z.B. wenn man mit dem Maplint annotation layer versucht Mapping-Fehler auszubügeln... Aber auch weil sie an Stellen auftauchen wo man keine POSi vermuten würde (mitten auf der Straße oder im Wasser) und sie deshalb ständig anklickt um zu überprüfen was das da soll. wenn die Qualitaet so schlecht ist, dann ist Loeschen in den von Dir genannten Faellen (Punkt im Wasser) vielleicht wirklich besser. Ich wuerde als erstes versuchen, den Autor zu kontaktieren (ueber author-tools in JOSM ermitteln). Danach wird hoffentlich mehr Klarheit herrschen, wer da was und woher importiert hat. Wenn es sich wirklich nur um FON-APs handelt, und diese in einer parallelen und kompatiblen Datenbank gefuehrt werden, dann wuerde ich allerdings auch die Openlayers-Einblend-Methode praeferieren. ACK ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wlan von maps.fon.com
Jochen Topf wrote: On Thu, Aug 28, 2008 at 07:07:06AM +0200, Michael Buege wrote: amenity=wlan class=free note=FIXME source=http://maps.fon.com [...] Maplint annotation zeigt die Punkte auch als deprecated_features an! Ich finde nicht, dass Maplint annotation als Instanz fuer die Daseinsberechtigung fuer jedwede Art von Geoinformationen im OSM-Datenbestand geeignet ist. Maplint kann nur Hinweise geben, wo etwas falsch sein könnte. Es kann einem ein Verstehen des Problems nicht abnehmen. In diesem Fall sagt es deprecated, weil der class-Tag früher für etwas ganz anderes verwendet wurde, dass wirklich nicht mehr benutzt werden soll. Hier hat jetzt jemand class=free für etwas ganz anderes eingeführt. Ob diese Punkte sinnvoll sind, dazu kann ich nichts sagen. Aber ein Tag-Key der einfach class heißt ist so wenig aussagekräftig, dass er nicht benutzt werden sollte. Besser wäre hier wohl etwas wie payment_class oder dergl. Zum Kern-Thema: Auch ich würde sie drinlassen. Und ich glaube das der allgemeine Konsens doch auch ist möglichst Infos drinzulassen die für irgendwen Relevanz haben (könnten) - natürlich vorausgesetzt die Datenqualität stimmt o.ä. Aber da müsste man erstmal von ausgehen. Leute können ja Details in ihrer Umgebung prüfen und nachtragen. Sinnvoller als hier an ein größeres Löschen zu denken o.ä. wäre es vermutlich praktische Überlegungen anzustellen wie z.B. in JOSM o.ä. einzelne Tag-Klassen/-Ebenen ausgeblendet werden könnten o.ä. Ich meine es gäbe auch was in Richtung fee= was Leute für Parkplatz-Automaten oder so schon mal verwendet haben. Müsste man im tagwatch mal nachsehen. Eine Frage wäre vielleicht noch, wie man einheitlich Preise in versch. Variationen notieren kann um diese ggf. auch automatisiert auswerten zu können ... also free, 1Euro/h, 1Euro/Tag+3Euro/GB oder sonstwas - hmm ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wlan von maps.fon.com
Gut, aber dann sprechen wir nicht darüber ob es sinnvoll ist die Daten zu haben, sondern eher ob sie überhaupt korrekt sind. Das ist was anderes imho. Kann jemand aus der Fon-Gemeinde ggf. mal ein paar Leute kontaktieren (geht das?) deren Hotspot-Standpunkt nicht korrekt ist und abfragen wie groß die Abweichungen wirklich sind? Entweder die Positionen sind zu ungenau oder völlig veraltet. Grüße, Stefan Rolf Gehring wrote: Hallo, auch in meiner Umgebung habe ich zwei WLAN gefunden. Eins befindet sich auf einem Bürgersteig, der andere auf einem Wasserschutzgebiet (Parkähnliche Gestaltung ohne Gebäude). Ich habe mich mit PDA und WLAN-Finder auf diese Stellen gestellt und was wurde angezeigt? ... Nichts. Warum wurden diese Teile ... soweit ich mich erinnere als sinnvoll angesehen? Ein WLAN-Spot kann vielleicht 30, vielleicht auch 300 Meter weit reichen. Diese Node muss also schon recht genau dort hingesetzt werden, wo der Sender steht. Wenn man keinen Empfang hat, dann ist es egal, ob der Spot 400 oder 4000 Meter entfernt steht. Ich sehe ihn schlicht und einfach nicht. Was ist also sinnvoll daran? Was hilft ein FIXME weiter? Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Martin Koppenhoefer Gesendet: Donnerstag, 28. August 2008 02:49 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] wlan von maps.fon.com 2008/8/28 Per Hansen [EMAIL PROTECTED]: Kiel und vermutlich auch andere Städte sind voll von wlan-POIs, die allesamt identisch sind und für mich wie Werbung aussehen! amenity=wlan class=free note=FIXME source=http://maps.fon.com Diese Informationen bringen keinerlei Mehrwert. wieso das denn? Die zeigen WLAN-Stationen mit FON. Maplint annotation zeigt die Punkte auch als deprecated_features an! Sollten die nicht besser entfernt werden? Kann man alle Punkte mit exakt diesen Eigenschaften per Skript löschen? Grüße Per nee, lass mal lieber drin, da wurde vor einiger Zeit drüber gesprochen, und die Teile wurden soweit ich mich erinnere als sinnvoll angesehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wlan von maps.fon.com
John07 wrote: Christoph Eckert schrieb: Moin, Und genau da sehe ich das Problem. WLAN-Netze sind imho etwas sehr dynamisches und noch dazu nicht auf den ersten Blick sichtbares. Daher denke ich, dass sie in unserer Datenbank nicht sinnvoll sind, imo wurde das schonmal hier diskutiert und die Meinung war damals ebenfalls so. der Sichtweise würde ich mich durchaus anschließen. Andererseits stören die Hotspots ja in unserer Datenbank erstmal nicht. Warum also nicht 'drinnelassen und abwarten, ob die Fon-Jungs die Dinger pflegen? Falls ja ist es doch super. Falls nein kann man sie in einem halben Jahr noch immer 'rauswerfen. Damit kann ich mich anfreunden. Meine Aussage war auch etwas genereller gemeint. Bei den Fon-Hotspots ist ja eine Art Community dahinter, da gibts schon Chancen, dass die gepflegt werden. Anders sieht es bei normalen Wlans aus, die jemand in seiner Stadt mappt. Die könnte man imo fast gar nicht pflegen. Wenn man es pflegen könnte, sähe ich mit SSID und MAC ggf. den Vorteil das man auch eine grobe Navigation o.ä. anhand dieser Angaben machen könnte, wenn die Standorte bekannt sind. Und solche Datenbanken nutzen andere Dienste ja auch. Wenn man die Datenbasis also in OSM integriert bekommen könnte ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen auf gleicher Höhe ... und/oder auch versetzt
René Falk wrote: Am Dienstag, 26. August 2008 schrieb Rolf Gehring: Hallo, diese Frage beantworte ich aus heutiger Sicht mit einem klaren nein. Ursprünglich hatte ich auch mal die Ansicht gehabt, einen zusätzlichen Way als Buslinie unter Einbeziehung dieser externen Haltestellen auf den übrigen Nodes der Straße zu erstellen. Diese Idee habe ich aber verworfen. Auf einem Straßenabschnitt und der einen Bushaltestelle habe ich hier im Ortsteil fünf Buslinien, die sich dann bei den nächsten Kreuzungen und Einmündungen verteilen. Diese eine Baushaltestelle ist also Mitglied in den fünf Buslinien-Relationen, aber als sichtbare Haltestelle sowie als Node nur einmal vorhanden. Deshalb ist ein oder sind fünf Service-Way unzweckmäßig. Wozu brauchst man dabei 5 mal service? Das Problem sehe ich in den richtungsbezogenen Haltestellen, insbesondere wenn sie weiter auseinanderliegen, mehrere dutzend Meter sind ja keine Seltenheit, man will sie ja da eintragen wo sie sind. Wie tagged man die Richtung für einen Node? Node neben den Weg setzen? *duck* Desweiteren wurden right/left (in diesem Fall) sowie forward/backward (für z.B. Geschwindigkeitsbeschränkungen o.ä.) als Modifier schon mal angesprochen ... ich bin mir aber nicht sicher, ob wir damals einen Konsens oder eine Mehrheit in der Diskussion hatten. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege erfassen
Raimond Spekking wrote: René Falk schrieb: Wie machst Du das mit Bäumen zwischen Fahrbahn und Bürgersteig/Radweg? Einen schmalen Streifen als wood einfügen? Jeden Baum einzeln wäre ein bischen viel Arbeit Ja? Das städtische Grünflächenamt würde sich freuen, wenn Sie OSM auch als Baumkataster [1] nutzen können :) Raymond. PS: Ich mappe (noch) keine Bäume ... [1] http://de.wikipedia.org/wiki/Baumkataster Dürfen tun sie sicherlich. Wenn sie auf dem Wege ggf. noch weitere Infos beisteuern hätten auch beide was davon. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Phone numbers in OSM
[EMAIL PROTECTED] wrote: I would like to add another argument to the Phone numbers discussion. If taken from the OSM database, any piece of paper with the phone number needs to inform about the license and source. - It is not realistic to think that phone numbers will be copied from the map with the licence information. a) If a wrong phone number is copied from OSM it will put a bad light on OSM, but the wrong source can be corrected. b) If a wrong phone number is copied from OSM without the source information, and someone finally finds out where the wrong number comes from, it's even worse. I agree that the entering of phone numbers should be done only beeing very careful. But how can you ensure? I think you can't. And pointing to the OSM disclaimer (This data is not reliable!) for the phone numbers doesn't prevent the owner of the wrong phone number to wake up at night, because a dump user from overseas did not think of the timezones. I think phone numbers should only be published with the acknowledgement of the owner, and that's far more than OSM can organize. Hi, While I understand your worries, I don't think it's feasible to demand full checks and confirmation by the owner. Personally I've been collecting various information from POIs around the city I live (and abroad) to have them in the map, easily available and to have the information relate to a point on the map. Most information were also tagged with an official URL which I researched in most cases and took the phone-number etc. from their official website. This for sure doesn't prevent you from making an error and possibly resulting in a wrong phone-number somewhere, sure. If there is a free yellowbook that we could work together somehow, I see that as a good chance to have _one_ place where e.g. changed data needs to be updated. Otherwise maybe we should have yellowpages for OSM on our own (possibly under the same license) which allows both relating that information to POIs on the map (but not necessarily) and also offering an easy frontend for finding/updating address-data (maybe by email-authentification or something). I've come up with thoughts for two scenarios: 1) Keeping all data in OSM as currently is. 2) Splitting certain information into a separate database but with close relation (on the API-side etc.) to the current OSM-data. The first solution would be good to keep it simple. However then we have all data in one huge bundle (e.g. one planet-file) and also have all data even if somebody just wants to render a map. If that's fine with us for the moment, that's okay. But if we think that e.g. phone-numbers, weblinks, maybe descriptions or opening-hours etc. should be separate then I'd imagine a separate database where such data goes to - maybe even using the same node-/area-IDs to keep the relation to the geo-information. Maybe it would be possible backward-compatible (same api, but updates to phone= go as updates into the other DB etc.). Good side of this solution would imho be to possibly be able to also create nodes without geo-information ... just the yellowpage-data first, and if somebody is able to place a correct marker on the map he'd need to be able to merge/link/... both information in the DB. Idea for yellowpage-name: yp.openstreetmap.org ? Kind regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Phone numbers in OSM
Florian Lohoff wrote: On Wed, Aug 20, 2008 at 03:54:56PM +0200, [EMAIL PROTECTED] wrote: I am definitively against phone numbers in OSM. On many communities on the internet publishing phone numbers and email adresses is not welcome because wrong numbers can't be found easily and people suffering from such phone calls will be really annoyed. Please use the WEBSITE tag - nobody will be annoyed by an error in a URL and if a phone number changes the sitemaster will take care and not the mapper. If there is no website for the amenity, you can add the URL of the search result of the yellow pages. The point will be that one day you need the yellow-pages machine readable link. E.g. every car navigation will show you the next 20 hotels surrounding you and will offer the numbers and addresses. I do agree though that these informations should not be the scope of OSM but there should be some possibility to link them. I agree. But in the meantime imho where available we should at least add that information to have them available in a clear and structured way together with the POIs. If at a later step we decide to split off certain information (opening hours, descriptions, ratings, ...) into a separate POI-database or something, then we're ready to go. Regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] OSM-POIs in 3D
Alexander Zipf wrote: wie habt Ihr die Dachformen realisiert? Man sieht, dass sie stark vereinfacht sind, aber stimmt z.B. die Ausrichtung der Satteldaecher? Einige sind ja zu erkennen. Wurden die Neigungen vereinfacht? Sehen auf den ersten Blick ein bisschen flach aus. Respekt trotzdem, sieht sehr vielversprechend aus. Die Datengrundlage für die Gebäude in HD basiert wie gesagt auf den Daten des Vermessungsamtes HD - z.Zt. nicht OSM (sorry..) Das Vermessungsamt nimmt die Dächer in HD zur Zeit auf. Das ist noch nicht vollständig, d.h. in vielen Gebieten werden noch Flachdächer erzeugt, wenn keine weiteren Informationen vorliegen. Das dürfte in den meisten der in den Screenshots sichtbaren Gebieten der Fall sein (bzw. wenn Du im Navigator in den Außenbezirken navigierst). In den Fällen, in denen Dachformen dargestellt werden, sollten sie mit der Realität übereinstimmen, die Ausrichtung auf alle Fälle. Aber richtig: schon um die Datenmenge nicht zu groß werden zu lassen, werden z.B. Dachgauben i.d.R: nicht berücksichtigt, d.h. es gibt Vereinfachungen (nur einzelne Gebäude wurden im LOD2 ausmodelliert - dazu muss man die entsprechenden LOD-Styles für die Gebäude auswählen). Wir überlegen aber durchaus auch einfach Standard-Dächer auf die Gebäude zu setzen, wenn keine exakte Dachform vorliegt. Das sieht dann vielleicht netter aus, hat aber wenig mit der Realität zu tun. Oh, d.h. auch die darüber schwebenden POIs habt ihr gar nicht OSM-basiert? Schade :-( Gibt es vielleicht eine Möglichkeit aus dem Projekt Daten durch die Stadt Heidelberg abzuleiten für OSM oder ggf. OpenAerialMap etc. - mit Genehmigung versteht sich? Wenn ihr da doch einmal gute Kontakt habt, die für innovative Projekte offen sind ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Heidelberg: No-name-Einträge?
Hi, über die XNagiator-Diskussion bin ich auf diesen Ausschnitt aufmerksam geworden: http://www.openstreetmap.org/?lat=49.40618lon=8.67485zoom=17layers=B00FTF Da gibt es Einträge mit No name rechts von der Karl-Metz-Straße. Könnte da jemand mit local knowledge ggf. mal nach schauen? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Heidelberg: No-name-Einträge?
Stefan Neufeind wrote: Hi, über die XNagiator-Diskussion bin ich auf diesen Ausschnitt aufmerksam geworden: http://www.openstreetmap.org/?lat=49.40618lon=8.67485zoom=17layers=B00FTF Da gibt es Einträge mit No name rechts von der Karl-Metz-Straße. Könnte da jemand mit local knowledge ggf. mal nach schauen? reply-to-self :-) Ich glaube die Frage hat sich schon fast geklärt. Der Parkplatz hat gar keinen Namen (kommt häufiger vor). Und die Straße gehört scheinbar zur Bergheimer Straße als Ableger dazu ... das entspricht zumindest den offiziellen Adressen der dort bereits eingezeichneten 3 Veranstaltungsorte. Ich habe das nun erstmal so ergänzt. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WikiMap Frankfurt-Nordend
Johann H. Addicks wrote: Hallo, ich schaue gerade relativ ratlos auf die Ankündigung(?) auf http://www.frankfurt.de/sixcms/detail.php?id=3662661_ffmpar[_id_inhalt]=3627701 Als Teil des vom Verkehrsdezernat Frankfurt am Main initiierten und vom Bund geförderten Forschungsprojekts „Vernetzte Spiel- und Begegnungsräume“ liegt der Schwerpunkt von WikiMap.Nordend zunächst auf projektbezogenen Inhalten. Eine Kreuzung aus Wikimappia, Google-Earth-Community und Wer-kennt-wen mit Landkarte? Hi, die Hintergründe kenne ich zwar leider nicht, aber es sieht fast so aus als wäre für ein mit öffentlichen Geldern gefördertes Projekt mal wieder keine sinnvolle Grundlagen-Entscheidung gefällt worden ... insbesondere wenn das Argument sind ja noch nicht alle Straßen in OSM enthalten für einen begrenztes Einzugsgebiet nicht zutrifft ... *kopfschüttel* Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied: sport=swimming leisure=water_park
Florian Heer wrote: Hallo Peter! Peter Herison schrieb: Ich habe immer die ganze Schwimmbadflaeche (also auch Aussenbereiche, Liegewiesen usw.) als leisure=water_park bezeichnet. Die Becken als natural=water, und zusaetzlich, wenn das Becken Bahnen hat, mit sport=swimming. Aha? Ein Schwimmbecken ist Naturwasser? :-) Nein, ich hab auch noch kein offizielles Tag für Kunstbecken gefunden, aber wenn ich eins taggen muss, weigere ich mich einfach, da was von natural zu schreiben. Auch wenns nicht gerendert wird setz ich da landuse=water hin. Das wäre ja eigentlich schon fast Menschgemachtes Wasser. Bei künstlichen Seeen müssen wir aber keien Diskussion anfangen ob das nun natürlich ist oder nicht :-) Imho ist ein landuse also neutraler. (PS: Sollte natürlich sinnvollerweise imho auch gerendert werden.) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Indoor-/Outdoor-Schwimmbad?
Gibt es eigentlich eine Möglichkeit zu bezeichnen, ob wir über ein Freibad oder eine Indoor-Badeanstalt sprechen? Habe in den Map_Features nichts dazu gefunden. sport=swimming o.ä. hätten wir in einem separaten Thread ja schon erwähnt. Aber nutzt ihr für sowas dann noch Zusatztags? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze taggen
Mark Obrembalski wrote: Christoph Eckert [EMAIL PROTECTED] schrieb: Moin, Um in diesem Thread wieder zum Thema zu kommen: Der richtige Ausdruck ist tree stand, wie mir ein amerikanischer Jäger berichtete. Das ist wohl einer der offiziellen Ausdrücke dafür, und ich finde passt auch gar nicht mal schlecht. zumindest habe ich nichts viel besseres zu bieten. Es hat mir ein Native Speaker noch eine Hunting Platform (hunting=platform) angeboten. dict.leo.org kennt rised hide (britisches Englisch) oder einfach hide, stance oder stand. hide könnte irreführend sein imho, mit stance assoziiere ich gar nichts (heißt ja nichts) und stand könnte imho durchaus auch passen und leicht ersichtlich sein. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze taggen
Johann H. Addicks wrote: Das ist natürlich politisch hochheikel; Jäger müssen dann fürchten, dass sich militante Tierschützer anhand von OSM-Daten systematisch über die Hochsitze hermachen. Das ist überhaupt nicht heikel. Abgesehen davon, dass ich -von einigen Ausnahmen mal abgesehen- von Jagdgegnern angesägte Hochsitze für ein Ammenmärchen halte. (Nein, Tierschützer sind das auch in meinen Augen nicht): Ich halte rund 1/3 der Hochsitze in der Flur für gefährlich im Sinne von ohne Sicherung nicht besteigbar, weil der Weiß- und Braunfäule freier Lauf gelassen wurde. Aber zugegeben weiß natürlich der Jägern in seinem Revier, was ihn erwartet. Und wer sonst noch klettert ist ggf. selbst schuld. Abgesehen davon, wer ernsthaft Hochsitze sabotieren wollte, der braucht keine solche Datenbank. Dafür reicht es, mit offenen Augen irgendwo durch die Flur zu laufen: Überall wo ein gutes Schussfeld ist, da gibt's mindestens einen Hochsitz, und leider nicht nur dort. Wenn man Nachtcaches verlegen möchte und eine Route durch den Forst sucht, auf der man _keine_ Hochsitze kreuzt, steht man oft vor nahezu unlösbaren Problemen. Vielleicht ist das hier in Rhein-Main aber auch nur eine Ausnahme, weil die Jadgpachten hier exorbitant teuer sind und somit die Jäger sich's auch anders ein wenig kosten lassen. Und damit's dann auch immer gut was zu schiessen gibt, werden die Bestände selbst in mildesten Wintern durchgefüttert. In der nächsten Stufe wird hier dann ganzjährig gemästet, warum auch nicht auch das Schwarzwild gleich mit. Momentan verwende ich zum Auszeichnen Annehmlichkeit=Hochsitz Es scheint keinen britischen Terminus für einen Hochsitz zu geben? Um in diesem Thread wieder zum Thema zu kommen: Der richtige Ausdruck ist tree stand, wie mir ein amerikanischer Jäger berichtete. Das ist wohl einer der offiziellen Ausdrücke dafür, und ich finde passt auch gar nicht mal schlecht. Was denkt der Rest? ce, magst du das mal im Wiki (propsal?) festhalten? sn ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze taggen
Christoph Eckert wrote: Moin, Um in diesem Thread wieder zum Thema zu kommen: Der richtige Ausdruck ist tree stand, wie mir ein amerikanischer Jäger berichtete. Das ist wohl einer der offiziellen Ausdrücke dafür, und ich finde passt auch gar nicht mal schlecht. zumindest habe ich nichts viel besseres zu bieten. Es hat mir ein Native Speaker noch eine Hunting Platform (hunting=platform) angeboten. Was denkt der Rest? Mir ist es letztlich egal. Hauptsache wir verwenden alle die gleichen Tags ;-) . Die Frage ist ob der Hochsitz unterhalb des Schlüssels Annehmlichkeit, Menschengemacht, Austüraktivitäten oder Jagd firmieren soll. Vorschläge? man_made=tree_stand vielleicht, weil da gibts auch nen survey_point etc., der wohl häufiger verwendet wird? ce, magst du das mal im Wiki (propsal?) festhalten? Viel zu viel Aufwand für viel zu wenig Effekt. Wir denken uns einen möglichst eindeutigen Tag aus und hauen das in die Datenbank. Den Rest erledigt Tagwatch für uns. Hmmm ... aber newbies werdens in den Map_Features sowie ggf. in den proposals suchen imho. Dann könntest du auch gleich ein Icon etc. vorschlagen. Imho gar nicht mal verkehrt ... Aber gut. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] weitere Koordination - Deutsche Post AG - Briefkasten
Hi, whoops, mir ist gerade aufgefallen, daß diese Mail (vom 30.7.) scheinbar gar nicht ihren Weg an die Mailingliste gefunden hat (an talk-de-bounces geschickt statt talk-de *sigh*). Daher hier erneut. Ein paar Leute haben für ihre Umgebung ja nun schon Listen der Deutschen Post AG erhalten. Bei einigen fand sich wohl ein Hinweis in der Email/dem Dokument das die Daten nicht weitergegeben werden dürfen. (Bei mir war das nicht der Fall.) Um zum einen zu vermeiden, daß Leute doppelt und dreifach anfragen und damit wir auf der anderen Seite nicht wiederrechtlich Listen ins Wiki stellen, würde ich vorschlagen unter z.B. http://wiki.openstreetmap.org/index.php/Briefkarten eine Liste von Personen zu benennen, denen Listen vorliegen. Wenn jemand dann auch aus dem Gebiet kommt, kann er sich an diese Personen wenden um ein paar Tipps zu erhalten wo in der Nähe seines Wohnortes ggf. noch Briefkästen zu finden sind oder ob nun alle erfasst wurden. Nehmen wir eigentlich auch Leerungszeiten mit auf? Gibt es dafür schon eine beispielhafte Umsetzung oder würde man das z.B. erstmal in eine note aufnehmen? !! für alle aus Neuss und Umgebung: !! Ich habe für Neuss und Vororte (4146x, 4147x) auf Anfrage nun auch eine Liste mit Briefkästen sowie Packstationen erhalten. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenbezeichnungen an saemtlichen Knoten
Sebastian Waschik wrote: Hallo, mir ist heute aufgefallen, dass in Dahme (Ostsee) häufig die Straßenbezeichnung nicht nur an dem Weg steht, sondern auch an den Knoten zum Weg. http://www.openstreetmap.org/?lat=54.216584lon=11.087222zoom=18layers=B00FTT Ich denke mal, dass das nicht richtig ist, aber da ich nicht allzu lange dabei bin, frage ich lieber einmal nach. Wenn es falsch ist, wie löst ihr das? Also erst mal kann man natürlich demjenigen Bescheid sagen, der das angelegt hat. Aber einer sollte es dann ja lösen. Für das Lösen gibt es dann wohl nur die Möglichkeit jeden Knoten einzeln anfassen? Oder wie stellt man anders fest, dass man hinterher nicht versehentlich die Information gelöscht hat, die nicht im zugehörigem Weg gespeichert ist? Hi, er wird beim markieren nicht nur die ways sondern auch die nodes markiert haben, ein typischer Fehler. Schreib ihn doch mal an, so als Tipp für die nächsten Mappings dieses Autors. Ein paar Ways die ich in dem Bereich finde seh ich mir gleich mal an ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Löschmeister ...
Hanno Böck wrote: Am Dienstag 12 August 2008 schrieb Mario Link: Habe dank ITO gesehen das Sachen von mir gelöscht wurden, habe dann beim löschenden User höflich nachgefragt wieso derjenige einen bestimmten Weg ersatzlos (!) gelöscht hat (also weg - nicht verändert, ergänzt oder korrigiert). Die Antwort: ich bin über den Weg gestolpert, als ich mit JOSM-Validator meine und damit auch Eure Arbeit kontrolliert habe. Der Weg war mit 2 Fehlern eingetragen. Bei Fuß- und Radwegen mache ich schon mal kurzen Prozess und lösche die. Hmm, also das ist eigentlich schon Vandalismus. Was uns wieder zu der Frage bringt, wie man damit umgeht... Also ich würde ihn höflich darauf hinweisen, dass das überhaupt nicht geht (anderer Leute arbeit mutwillig kaputtmachen) und ansonsten eine um Accountsperrung bei den Administratoren bitten. Vielleicht nochmal freundlich die Hintergründe erklären, ggf. die Mailingliste in CC setzen um das Thema gemeinsam anzusprechen? Vielleicht ist ihm wirklich nur nicht ganz so bewusst warum ein anderes vorgehen sinnvoller wäre ... Ich denk mal das sollte irgendwie zu klären sein *Optimist* Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Löschmeister ...
Dirk-Lüder Kreie wrote: Mario Link schrieb: Auch so was gibt es: Habe dank ITO gesehen das Sachen von mir gelöscht wurden, habe dann beim löschenden User höflich nachgefragt wieso derjenige einen bestimmten Weg ersatzlos (!) gelöscht hat (also weg - nicht verändert, ergänzt oder korrigiert). Die Antwort: ich bin über den Weg gestolpert, als ich mit JOSM-Validator meine und damit auch Eure Arbeit kontrolliert habe. Der Weg war mit 2 Fehlern eingetragen. Bei Fuß- und Radwegen mache ich schon mal kurzen Prozess und lösche die. Und noch weiteres Geschreibsel dieser Art. Ich muss gestehen, da bin ich Baff. Ist das erste mal das ich innerhalb des OSM-Projektes auf einen selbsternannten Beurteiler und löscher anderer Leute Arbeit Treffe. Gibt es so was öfter oder hatte ich nun besonderes Pech auf so einen OSMler zu treffen? Habe ich verpasst, das es nun ein Räumkommando gibt? :-) Ich hab die Erfahrung gemacht, dass etwa einer in 30-40 Usern plötzlich so einen Ordnungsfimmel bekommt und alles nach seiner Weltsicht umtaggt, auch wenn er (scheinbar) erstmal keine Ahnung von den Lokalitäten bzw. Sonderfällen hat. Aber ist nicht ganz richtig (falsche grade-Zuordnung, kein Name vergeben oder whatever) ist ja immer noch besser als gar nicht erst vorhanden. Das sollte man ihm imho doch irgendwie deutlich machen können ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Frederik Ramm wrote: Hallo, Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind Strassenlaternen Unfug? Parkbaenke? Flugrouten? Dann müssen wir wohl auch mal Dinge auf irgendeine Art zusammen festlegen. Muessen wir? Denn es ist wahr, es gibt Grenzen was noch als sinnvoll zu erachten ist. Die gibt es sicherlich, die Frage ist, von wem als sinnvoll zu erachten. Ich habe z.B. schon paar Mal nach einem Tag für mein Goldfischglas in meinem Keller auf dem Schreibtisch gefragt und nie wußte jemand eine Antwort, dann werde ich jetzt selbst ein paar Tags entwickeln und die Datenbank zumüllen mit Dingen die nur ich gebrauchen kann? Wir brauchen Regeln! Ohne die geht es nicht. Bislang sind wir gut damit gefahren, dass es eine Tendenz gibt; man kann zu irgendwas ne Meinung einholen und bekommt manchmal ein ueberwiegendes Schrott oder ein ueberwiegendes ja klasse, mach. Es gibt allerdings keine wirklich festgelegten Regeln, und das soll auch so bleiben. Wir muessen nicht daran arbeiten, Dir zu verbieten, dass Du Dein Goldfischglas taggst (und einen Kontrollapparat aufzubauen, der sicherstellt, dass Du es auch wirklich nicht machst). Wir muessen vielmehr daran arbeiten, dass Dein Goldfischglas nur diejenigen zu sehen bekommen, die sich fuer Goldfischglaeser interessieren! Das waere fuer alle die beste Loesung. Beim Rendern funktioniert das schon einigermassen; beim Editieren wird es noch kommen. Das ist wie mit dem Internet: Du kannst ein Foto von Deinem Goldfischglas reinstellen, niemand verbietet Dir das. Ob es jemand anguckt, ist eine andere Frage. Hi Frederik, es ist nicht immer nur alles schwarz und weiss :-) Ich glaube es bestreitet keiner, daß erstmal alles eingetragen werden darf und möglich seien muss. Aber wo es sinnvoll ist lass uns doch gemeinsam mal Überlegungen anstellen wie man das eiheitlich am besten löst. Ich habe auch häufig Sachen wo ich keine Notwendigkeit darin sehe das Rad neu zu erfinden. Und wenn sich kluge Leute schon mal über die optimale Lösung Gedanken gemacht haben, adaptiere ich die in so einem Fall auch gerne. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - RFC - (maxspeed = none)
Gerrit Lammert wrote: Tordanik wrote: Bei einer „normalen“ Straße erkennt man die Information, dass es jemand geprüft hat, daran, dass in diesem Fall ein maxspeed=50 (oder was auch immer die Standardgeschwindigkeit ist) hingeschrieben ist. Ah, jetzt verstehe ich meinen Fehler. Ich hatte angenommen es gibt sowas wie Defaultwerte bei OSM, genauso wie in der Wirklichkeit. Wenn an der Straße kein Geschwindigkeitsbegrenzungsschild steht, gelte die Defaultbegrenzung (z.B. 100km/h auf Landstraßen, 50km/h in Städten...). Naiv wie ich bin, dachte ich für eine OSM-Straße ohne Begrenzung gelte dasselbe, aber dem ist wohl nicht so. Dann werd ich mal schnell meinen Fehler korrigieren und und an jede residential ohne explizite Verbote ein bicycle=yes und foot=yes dranhängen, an Autobahnen ein bicycle=no und foot=no, an Parkwege ein car=no, train=no, ship=no, airplane=no, spaceship=no, ... Entschuldigt den Sarkasmus, aber wie wäre es damit, das bisschen einheitliches verhalten, das noch geblieben ist zu bewahren? Gerrit PS: Ein building=yes sollte nach 9/11 immer auch ein airplane=no bekommen... Sind jene impliziten defaults außer in dne Renderern/Navis irgendwo erfasst, als eine Art wenn dies gesetzt, gelten folgende Defaults für andere Werte? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bennenen von Gebaeuden, Plaetzen, etc.
fred wrote: Hi, On Sat, 09 Aug 2008 00:01:49 +0200, Tobias Hägele [EMAIL PROTECTED] wrote: Also bei Tankstellen läuft es meistens so, dass sich Bspw. Aral die Tanke mietet, den Shop an Paul Brause weiterverpachtet und der Sprit [...] Also doch: operator=ARAL was für mich als Spritkäufer am interesantesten ist. Denn bei operator=Paul Brause würde ich eine freie Tankstelle erwarten. Ich denke auch, dass die Paul Brause-Info etwas weniger spannend ist als die Aral-Info. Aber man koennte das schon euber den Namen abwickeln, oder? Name=ARAL Tankhof Pforzheim Mitte, Operator=Paul Brause? Auch in meinem lokalen Subway-Fastfood haengt ein Schild This store is proudly operated by Paul Brause. Es waere also schlicht falsch, ein operator=Subway hinzuschreiben. Dennoch ist das nateurlich das, was mich interessiert. Also Name=Subway? Andrerseits ist das, wie bei den Tankstellen auch, uneindeutig... Name=Subway Store 123 Karlsruhe-Mitte? Auch doof. Vielleicht sollten wir doch als Faustregel sagen, dass wir als Name das taggen, was die Leute auch benutzen, und nicht das, was der offizielle Name ist...? Whoops, habe dein Posting erst nach meinem von gerade gelesen. Sorry. Ja, in diesem Fall stimme ich dir zu - man könnte den gebräuchlichen Namen verwenden (wenn dieser auch nicht unbedingt eindeutig ist). Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benennen von Gebäuden, Plätzen etc .
Stephan Schildberg wrote: Und ich würde auch in den Operator nur den gebräuchlichen Namen eintragen. Wir sind doch keine Juristen! Was interessiert mich, ob Lidl eine AG oder eine GmbH KO ist? Ich will nicht wissen, das das Kaufhaus operator=Karstadt Quelle AG hat sondern ob es ein Karstadt oder ein Quelle ist. Und bei den Unternehmen ist ja auch ständig Bewegung drin, mal geht der an die Börse, mal wird der Teil verkauft Achja und auch bei gepachteten Edekas interessiert mich eher das es einen Edeka gibt, als wie der Inhaber heißt, da sie üblicherweise ein Einheitliches Sortiment haben (Beispiel: wo gibt es den Alergiker-Brei? Edeka? Ja die haben Mich interessieren auch die Namen Inhaber, gib mir zumindest die Chance sie eintragen zu können. Für gewöhnlich gibt es eine Veröffentlichung die sichtbar für den Kunden sein muß. Dafür. Wenn du die Infos hast, sollst du sie auch eintragen können. Die Frage ist ja nur wie wir die platzieren wenn wir etwas einheitlich haben wollen. Ist operator deiner Ansicht nach eine Option, da das vermutlich die Person ist die den Laden betreibt? Zudem würde ich gerne Mitgliedschaften aufnehmen, wie z.B. Bioland, demeter, naturland, etc., oder auch Akzeptanz von Kreditkarten, Werbegemeinschaften, blablabla Klingt grundsätzlich auch nicht verkehrt. Hättest du da vorschläge (ggf. sogar als Proposals) oder hast du mal geschaut ob/wie andere sowas machen? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere WMS-Layer in JOSM einbinden?
Tobias Wendorff wrote: Hallo, Frederik Ramm schrieb: Das habe ich schon vor gehabt, aber irgendwie verleitet das womöglich die User dazu, doch Karten ohne Erlaubnis einzubinden. Ich denke nicht, dass es die Aufgabe der JOSM-Entwickler sein sollte, ihre Benutzer zu bevormunden ;-) Ich will OSM aber durch solche Sachen nicht in Verruf kommen lassen. Vergleichen o.ä. ist ja durchaus berechtigt, es dürfen nur keine Daten übernommen werden (oder abgeleitete Werke erstellt werden) wo dies lizenzrechtlich nicht möglich ist. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bennenen von Gebäden , Plätzen , etc.
Bernd Wurst wrote: Hallo. Am Samstag, 9. August 2008 schrieb Stefan Neufeind: Bernd, wäre es denn deiner Meinung nach sinnvoll für eine eindeutige Zuordnung (Filterung, Anzeige Logos, ...) noch Tags wie das hin und wieder erwähnte brand=... o.ä. zu nutzen? Ich habe bisher operator für sowas benutzt. Da das aber (siehe diese Diskussion) weder im Wortsinne korrekt ist noch allgemein so benutzt wird, wäre ein neues Tag dafür IMHO sinnvoll. Für mich und mein schulenglisch klingt brand jetzt intuitiv unschön, eher nach Marke im Sinne von Hersteller. Grade habe ich mal exemplarisch ein paar englische Wikipedia-Seiten zu solchen Ketten angeschaut und es scheint so, als wäre brand, chain oder trade name bunt gemischt in Benutzung. Ich habe nichts gegen brand einzuwenden, wenn das ein Muttersprachler intuitiv auf Namen der Handelskette zuordnen würde... haarspalterei Was aber, wenn jemand einen Zigarettenautomaten taggen will? - operator=Tabakwaren Müller - brand=tobaccoland Dann will er noch den Typ bzw. das Fabrikat der Maschine taggen und würde dafür evtl. gerne brand nehmen... ;-) /haarspalterei Hmm, wenn du diese Idee weiter verfolgen möchtest, wäre das ein Problem, ja :-) Mir liegen Zigaretten-Automaten nicht am Herzen, aber vielleicht findet sich jemand der zumindest Tags sucht um die dort erhältlichen Sorten zu taggen (cuisine=... *smile*). Gäbe es denn allgemein sowas wie Sorten/Artikelarten/... in anderen Bereichen auch, so daß es ggf. sinnvoll ist sich hierfür etwas zu überlegen? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] bus_stop / bus_station
Hi, I just discovered there is highway=bus_stop and amenity=bus_station According to map features the latter is for a larger bus_station with several bus-stops etc. Having a closer look I saw that they are shown differently e.g. in JOSM. highway=bus_stop in this case is a dark blue something on a black background, whereas the other is clearly visible as a bus_stop/_station. And several normal stops at roads near here were tagged as a bus_station which actually are just one small stop on the side of a normal road. So strictly looking they were tagged wrong (by me mosly, by the way). I wonder if others see the problem as well and if mappers really see a difference between the two. Otherwise maybe it would make sense to make both treated equal and assume stat a larger station is an area/way instead of just a node (where actually more lanes, stops etc. are there)? Regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Datenbankbereinigung
Dirk Stöcker wrote: On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... Left/right geht auch andersrum. Ist kein also Argument. Die Richtung bergaufwärts auch nicht: a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die Richtung z.B. so ein, wie ich gefahren bin. b) kann man sowas Höhendaten herausbekommen. c) könnte man das mit elevation-Daten oder Tags eintragen, wenn es denn unbedingt in den Daten sein soll (verschneiden mit Höhenmodell kommt mir allerdings sinnvoller vor). Andere Argumente? Das -1 wird ja sowieso kaum genutzt. Die einzige Anwendung, die ich gesehen habe waren parallele Autobahnen und dort kann man ohne weiteres die zweite Spur umdrehen. Es gibt 1336 Wege mit oneway=-1 in der Datenbank (gegenüber 40 true/yes). http://tagwatch.stoecker.eu/Europe/En/tagstats_oneway_-1.html 7 oneway=-1 liegen auf Knoten, sind also sehr wahrscheinlich Unfug. Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann kann man diese dämliche -1-Regel abschaffen. Aus meiner Sicht ist diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig verkompliziert. Diese Regel hat auch keine Entsprechung in irgendwelchen anderen OSM-Regeln. Das sollte dennoch jeweils vorbehaltlich einer händischen Prüfung sein. Vielleicht stehen andere Infos ala right/left drin die erst bei einer händischen Prüfung/Änderung auffallen würden und die du bei einem Skriptlauf schlichtweg nicht beachten (somit verfälschen würdest). Regards, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
FreeWorld wrote: Ich verstehe auch nicht, warum es problematisch ist sich auf ein einheitliches Schema zu einigen. Bisher habe ich oneway=true benutzt, weil ich dachte das wäre am verbreitetsten. Ist es wohl nicht. Wenn jetzt einer ein Skript durch die Datenbank jagt und alles von true nach yes konvertiert und irgendwo abgemacht wird, dass wir yes statt true benutzen, dann hätte ich da als Mapper wirklich überhaupt kein Problem damit. Da fühle ich mich echt in meiner Freiheit nicht eingeschränkt. Das würde mir auch irgendwie Sicherheit geben, wenn überall yes steht, dass dann zumindest das korrekt ist. Das klingt ja hier manchmal so, als wäre es den Mappern unzumutbar einen standartisierten Wahrheitswert zu verwenden. Und wenn man nach 2 Wochen nochmal die Datenbank aufräumt diesbezüglich, finde ich das auch nicht schlimm. Ich weiß schon, dass einige denken, dass es eigentlich auch egal ist, da ja eben alle 3 Varianten gerendert werden und es ja nur 3 sind usw. und das stimmt auch. Es macht das Leben aber oft einfacher, wenn man nur eine hat. Auch für die Mapper. Also wie gesagt, von mir aus gerne vereinheitlichen. Ich stell mich gerne um. Grundsätzlich teile ich deine Meinung in diesen speziellen Fällen. Für Infos abseits davon muss jedoch trotzdem noch Platz/Freiheit bleiben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Christian Malolepszy wrote: Hallo, On Thu, Aug 07, 2008 at 07:25:28PM +0200, Frederik Ramm wrote: Niemand hatte je den Anspruch, ein Format zu schaffen. Die Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es zum Leben braucht. Mir ist schon klar, dass es fuer die Nutzer der Daten etwas komplizierter ist, aber die vernuenftige Loesung waere, sich einen normierenden Zwischenlayer auszudenken, der die Daten in das wandelt, was man gerne haette, und NICHT, die Mapper normieren zu wollen. zwingen etwas normiert zu machen wäre ein falscher ansatz. zwischenschicht ist der richtige ansatz, nur sollte man meiner meinung nach die zwischenschicht, nicht beim herauslesen der daten ansetzen, sondern für bekannte sachen beim hineinscheiben in die datenbank oder in periodischen jobs, denn: - beim lesen der daten (zum beispiel: das api ersetzt die werte) würde es bedeuten, daß es immer wieder gemacht werden muß was performance kostet. - wenn jede anwendung eine zwischenschicht implementiert und für die interpretation der werte zuständig ist, bedeutet das eine fehleranfälligkeit und pflegeaufwand. beispiel: für boolean werte (z.B. oneway) kann folgendes in der db stehen: oneway=true oneway=TRUE oneway=trUE oneway=yes oneway=YES oneway=1 usw. jede anwendung muss nun um dieses eine feld zu unterstützen ein regelwerk und normierung der werte durchführen. dies bedeutet aufwand und fehleranfälligkeit für jede anwendung. und wenn dann einer hinkommt und oneway=ja oder oneway=si hinschreibt muß jede anwendung angepasst werden. beim hineinschreiben passiert es nur ein einziges mal und alle die da drauf zugreifen können sich da drauf verlassen, daß die daten sauber sind und eben bei boolen werten wie oneway da z.B. immer true zurückkommt. Mir sind übrigens auch ein paar Tags aufgefallen, die vorne/hinten ein Leerzeichen hatten o.ä. Das wirkt sich in der Praxis dahingehend aus, daß ein name (vielleicht copy-n-paste-error?) nicht gerendert wird und name tadellos funktioniert. Auch hier könnte vielleicht ein trimmen (Leerzeichen, Zeilenumbrüche - unter PHP quasi die Funktion trim()) für keys und ggf. auch values durchaus gute Dienste leisten ohne Daten zu verfälschen. Das macht im übrigen auch der JOSM-Validator, wenn man ihm für jene Fehler nach dem validieren sagt fix. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Windkraftanlagen weg? :-(
Frederik Ramm wrote: Hallo, Stefan Leupers wrote: Hallo zusammen, ich habe vor einiger Zeit ein paar Windenergieanlagen bei mir in der Nähe getaggt. Ordnungsgemäß, wie es laut http://wiki.openstreetmap.org/index.php/De:Map_Features und http://wiki.openstreetmap.org/index.php/Key:power_source sein soll mit power=generator power_source=wind Eine Zeit lang waren die auch ordnungsgemäß in mapnik eingezeichnet, aber sein ein paar Tagen/Wochen(?) werden die leider nicht mehr angezeigt. :-( Das Mapnik-Rules-File hat seit dem 4.6. einen Eintrag fuer man_made=power_wind. power=generator wird nicht gerendert, und es ist auch nicht ersichtlich, dass es jemals gerendert wurde. (Ich habe nicht alle historischen Versionen durchgesehen, es ist also *denkbar*, dass eine solche Regel mal existierte und entfernt wurde, aber unwahrscheinlich, denn sowas wuerde dann idR im Changelog stehen.) Hmm, die genannten Wikiseiten (power_source) legen ja Nahe, daß mittlerweile power_source die richtige Variante wäre (ohne an dieser Stelle eine erneute hitzige Diskussion über richtig entfachen zu wollen). Wäre es denn möglich, daß du die Regeln vielleicht um power_source=wind erstmal für diese Fälle ergänzt? Ein schneller Blick auf den Tagwatch für Europa zeigt, daß dort man_made=power_wind auf 92 kommt, hingegen power_source=wind auf 4529. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] superways as relations ?
Matthias Julius wrote: [EMAIL PROTECTED] (vegard) writes: On Mon, Aug 04, 2008 at 11:07:24AM -, m*sh wrote: On Mon, August 4, 2008 10:14, vegard wrote: For naming of streets in cities, where properties change very often and you have to make many small ways, it sometimes gets annoying that the name is duplicated. I was wondering: How good/easy would it be to make a superway-relation to fix that? I.e. group several ways for labeling-intentions? I'm no expert on the inner workings in either of the renderers, but to me it sounds like a quick fix to a small annoyance. If someone that knows the renderers could either agree or disagree, I'd be happy anyways (well, obviously happier if they agree :) Actually there is a 'mantra' on a german mailing list stating that, we are not tagging for the renderer I agree. We're not tagging for the renderer. At least, we're not tagging it *wrongly* for the renderer. But in practise, we might need to give the renderer some hints with some extra tagging. Of that, I personally am a little more inclined to accept that. But others might agree/disagree with me. I think adding a relation like that to help the renderer does in no way destroy the data model. Regardless of the renderers, duplication of data is evil, IMHO. Every time a way is split to allow one of its properties to change all other properties are duplicated. [...] This leads me to another thought: How do editors handle cases where a way is member of a relation and you split it? Would make sense to add both parts to the relation imho. Does somebody know how editors handle that currently? Kind regards, ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] POI-recording-device
Florian Lohoff wrote: On Sun, Jul 06, 2008 at 04:54:13PM +0200, Bernd Wurst wrote: Hallo. Ich hab mir bei einer längeren Autofahrt mit vielen Geschwindigkeitsbegrenzungen gedacht, dass die zwar bestimmt nicht alle in OSM sind, aber ich jetzt auch nicht jedes Mal die Digikam zücken will, wenn ein Schild kommt. Daher die Frage: Gibt es ein Gerät, das ich parallel zum GPS-receiver im auto montieren kann und das z.B. alle Sekunde ein gering-aufgelöstes, weitwinkliges Bild macht, mit dem man dann später sämtliche POIs und Geschwindigkeitsbegrenzungen nachtragen kann. Ziel soll es sein, dass man während der Fahrt nichts weiter tun muss, sondern nachher als Geotagged-Images alles auswerten kann. Hat jemand ne Idee, wie man sowas realisieren könnte? Ich dachte ja schon an das OpenMoko, aber das hat keine Kamera... :) Ich denke es macht mehr sinn die arbeit beim fahren zu machen d.h. dort schon zu selektieren. Die 4000 fotos der reise von Dortmund nach Hannover sieht sich keiner mehr an. Der punkt mit der Kamera ist das wenn die lichtbedingungen nicht optimal sind alle bilder verschwommen sind - Selbst bei 1/125s geht das bei tempo 100 schief ... Ich selber habe das mit autorecordings gemacht. Dh. ich habe einen taster am Blinkerhebel und nen headset. D.h. ich tippe den taster und in dem moment wird ein waypoint geschrieben mit dem was ich aufspreche. [...] Mit was machst du denn die Audioaufnahmen? Ich hatte überlegt das per Handy zu machen (trail-explorer, aktuelle beta) - aber mein Handy nervt dann immer mit Sicherheitsabfragen rum. Andere Idee war Maemo Mapper auf nem N770 ... aber da gibt es afaik keine einfache Möglichkeit die Recordings zu aktivieren, oder? Am schönsten wäre imho den Knopf am Bluetooth-Headset für Gespräch annehmen (Aufnahme starten) zusammen mit Maemo Mapper o.ä. nutzen zu können. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Alpha: Webbrowser-Plugin für JOSM
André Reichelt wrote: Tobias Wendorff schrieb: Daher musste er leide auf den Internet Explorer umsteigen, wodurch viele Benutzer ausgegrenzt werden :-( Naya, der Marktanteil von Windows dürfte bei 90% ca. liegen. Und auf die 10% Spinner kann man verzichten :P. Ob jenes Kräfteverhätlnis auch für OpenStreetMap zutrifft? Wissen tue ich es nicht, habe aber durchaus so meine Zweifel :-) sn ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Fernsteuer-Plugin
Alexander Menk wrote: Hi, Frederik Ramm wrote: ich habe ein neues Plugin fuer JOSM gebaut, mit dem eine Web-Anwendung wie z.B. OSBugs oder Tagwatch ueber einen speziellen Link Befehle an JOSM schicken kann (lade den Bereich X und selecte das Objekt Y). So wird es hoffentlich leichter, mal eben in JOSM irgendwas zu laden, was man in Tagwatch gefunden hat o.ae. Detailliertes Announcement auf Englisch hier: http://lists.openstreetmap.org/pipermail/josm-dev/2008-August/001254.html gute Idee. Einziger Haken ist natürlich, dass JOSM zur Benutzung des Links bereits laufen muss. Hast du darüber nach gedacht, ein spezielles Link-Protokoll dafür zu benutzen? Die Idee ist links wie z.B. josm://load_and_select? zu benutzen statt http://localhost:8001 Die Frage ist natürlich wie man das Browser- und Betriebssystemübergreifend implementieren kann. JOSM zu starten ist doch eigentlich für diesen Anwendungszweck kein Problem, oder? Und so braucht man im System keine Protokolle zu registrieren etc. Imho ist das durchaus die einfachste Variante. PS: Wir müssten uns nur auf eine bestimmte Port-Nummer für die Links einigen - oder die alternativ pro Site vielleicht in einem Cookie speichern :-) Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fon WLAN Hotspots
Liege ich falsch oder ist das für uns leider nicht offen genug? Imho könnte man maximal nen POI-Layer bauen, den man separat auf dem Client nachladen kann ... das müsste aber jeder User dann selbst tun und müsste selbst über die Rechte aufgeklärt werden. PS: Evtl. auf legal nochmal näher ansprechen ... Grüße, Stefan Stefan Keller wrote: Hier gäb's noch verortete Handy-Masten... (GPL v3) :- http://www.opencellid.org/ - S. Am 3. August 2008 17:24 schrieb Florian Schweikert [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Laut Wikipedia, kann man auch als Bill inzwischen kostenlos andere Punkte verwenden. Ich bin persönlich kein Freund des Fon Prinzips (nur 50% der Einkünfte, ...) mfg, Florian (Kelvan) Am 3. August 2008 08:47 schrieb Jürgen Fleckenstein [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Florian Schweikert schrieb: Hallo, Mir ist aufgefallen das in Wien mehrere FON WLAN Hotspots getaggt sind. Was mich irritiert ist das sie als class=free getagt sind, soll das heißen sie sind unverschlüsselt? Ja, immer. Frei im Sinne von verbinden und surfen ist Fon ja nicht. (Im Gegensatz zu Funkfeuer/Freifunk) Kann mir das wer schnell mal erläutern, in der Wiki war nichts zu finden. Solltest Du selbst ein FON WLAN betreiben und das Modell Linus gewählt haben, kannst Du Dich überall auf der Welt kostenlos einwählen. (siehe: http://de.wikipedia.org/wiki/FON#Nutzungsmodelle). Gruß Jürgen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging für Kiss+Ride?
Frederik Ramm wrote: Hallo, parking=kiss_and_ride wäre mit Abstimmung verbunden Das ist ein Irrtum. Du brauchst keine Abstimmung, um neue Tags einzufuehren. Für alle, die es nicht kennen: Diese Parkplätze befinden sich an einigen Bahnhöfen, um seine Liebsten für die Reise zu verabschieden (klingt irgendwie tragisch). Man darf dort bis zu 30 Minuten kostenfrei parken, wenn man sich halt wirklich von Jemanden verabschiedet :-) Ich stell mir gerade vor, dass die schuechternen Jugendlichen das so benutzen wie andrerorts den Mistelzweig... wenn man die Angebetete erstmal unter einem Vorwand zum Kiss+Ride bugsiert hat, dann darf man sie auch kuessen ;-) Ach nee, die schuechternen Jugendlichen haben ja noch keinen Fuehrerschein. Ich musste beim Thema gerade an andere einschlägige Parkplätze denken, wo Wohnmobile parken und man dem Dienstleistungsgewerbe nachgeht. Aber das war ein Trugschluss :-) Zum Thema: Letztendlich ist es doch einfach nur ein normaler Parkplatz. Daher find ich die Möglichkeit das auch wie im Originalposting vorgeschlagen regulär zu taggen. maxstay gibt es ja schon in den map features. Dort müsste allerdings noch die Zeiteinheit angegeben werden. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Versetzte Stadtbahnhaltestellen
Thorsten Feles wrote: Bernd Wurst schrieb: Hallo. Ich hab hier eine Stadtbahnhaltestelle, deren Richtungshaltestellen nennenswert versetzt sind. Es handelt sich um zwei Häuserblocks bzw. ca. 100 Meter Versatz. Mir ist nicht richtig wohl dabei, das als einzelnen Node zu setzen, im Gegensatz finde ich aber zwei gleich benannte Haltestellen kurz nacheinander auch nicht gut. Ideen? Es gibt das Proposal http://wiki.openstreetmap.org/index.php/Proposed_features/Side_of_stop Ist auch nicht das Gelbe vom Ei, da von der Richtung des Weges abhängig und die ändert sich schon mal Aber etwas besseres habe ich noch nicht gefunden. Hi, gut, sowas müsste dann mit in den Editor eingebaut werden (ggf. optional) ala: Wenn reverse way dann alle Nodes auf dem Weg durchgehen und ggf. Richtungsangaben umdrehen. Gerade schießt mir durch den Kopf an was wir diese Art von Tagging denn festmachen wollen. Trifft das nur für Busse und trams zu? Mindestens ja auch so Sachen wie light_rail die ja auch auf der Straße fahren. Was ist dann z.B. mit einem Taxi-Parkplatz (ggf. als zusätzliche Spur aber trotzdem direkt als Teil der Strasse ausgeführt)? Wollen wir ein derartiges Tagging nur für Sachen direkt _auf_ der Straße verwenden oder auch für Dinge die sich direkt an der Strasse befinden (Telefonzellen, Briefkästen, ggf. sogar Kioske o.ä.)? Das hätte dann den Vorteil das man zur Not auch mal die Straße verschieben kann ohne gleich aus versehen einen Kiosk auf die falsche Straßenseite wandern zu lassen. Und für Dinge die sich an der Straße befinden hätte sich damit dann auch die Frage geklärt wie weit man sie von der Straße wegzeichnen müsste. Renderer könnten dann selbst einen passenden Abstand wählen um z.B. bei breiteren Straßenlinien nicht plötzlich einen Briefkasten mit der Straße verschmelzen zu lassen etc., wodurch die Information der Straßenseite dann komplett verloren geht. Wäre es dann hier also sinnvoll zu überlegen Tags allgemein eine Richtung geben zu können? Über die Möglichkeit forward/backward an Key oder Value anzuhängen werden wir uns vermutlich nur immer noch mehr Probleme mit renderern einhandeln imho ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Oneway=1 ind Node? (nur um sicher zu gehen)
Andreas Pothe wrote: Hanno Böck: yes und klar, macht keinen Sinn. Ein Node hat ja keine Richtung, kann also schlecht oneway sein. Der Fehler kann entstehen, wenn man ein ganzes Gebiet markiert (mit diesen Rahmen bei gedrückter Maustaste). Man kommt leicht in Versuchung zu denken, dass dann die Wege markiert werden, tatsächlich werden aber auch alle Nodes im Rahmen mit markiert. Einen ähnlichen Fehler hatte ich anfangs auch gemacht, aber zum Glück bemerkt, bevor ich die Daten hochgeladen habe. Gibt es denn bei JOSM eine Möglichkeit nur Wege oder nur Nodes in dem Bereich zu markieren? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Versetzte Stadtbahnhaltestellen
Thorsten Feles wrote: Robin Rattay schrieb: Stefan Neufeind schrieb: gut, sowas müsste dann mit in den Editor eingebaut werden (ggf. optional) ala: Wenn reverse way dann alle Nodes auf dem Weg durchgehen und ggf. Richtungsangaben umdrehen. Die aktuelle Version von JOSM kann das - fast. Zur Zeit beachtet es nur Tags auf dem Weg selbst (oneway sowie left:*/right:* bzw. *:left/*:right). Wer weitere Tags weis die da rein sollten, bitte bescheid sagen. Bescheit: wie hier http://wiki.openstreetmap.org/index.php/Proposed_features/Side_of_stop vorgeschlagen auch backward und forward bitte. Das würde ich grundsätzlich unterstreichen. Es wurde in diesem Thread ja auch ausgeführt, daß/warum wir sowohl left/right als auch forward/backward (o.ä.) brauchen. Allerdings stellt sich mir dann immer noch die Frage ob man das nun vor/hinter den key oder den value schreiben sollte. Aber unproblematisch z.B. für renderer ist das alles nicht, da diese meist auf feste keys/values reagieren, oder? Als postfix würde das Prinzip vermutlich insb. bei Keys mit anderen Details kollidieren (right:something:some_detail ...) oder? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Himmelrichtungsabhängige Tags?
Das mit den Richtungen kann imho schnell subjektiv sein und zu Fehlern führen. Persönlich finde ich die Richtung eines ways deutlich unproblematischer. Stefan Alexander Schulze wrote: Hi, fände ich auch günstiger, vor allem weils dann unabhängig von der Richtung des ways ist. Hab ich woanders auch schon so in der Richtung kennengelernt. Allerdings zusätzlich noch mit den Zwichenhimmelsrichtungen (NW--SE usw.) schönen Gruß Alex Florian Arnold schrieb: Hallo, Hanno Böck schrieb am 03.08.2008 12:45: Mir schwebte da sowas wie ein left/right-prefix vor, welches dann bspw. auch der editor intelligent mitdrehen könnte wenn man die straße dreht. Also so in der art: left:highway=bus_stop Was dann eben, wie Du sagtest, auch für objekte an der straße genutzt werden kann, aber auch für so sachen wie gehweg/radweginfos (wobei man dafür natürlich noch both bräuchte, oder man erklärt both zum default). left/right hat im gegensatz zur fahrtrichtung den vorteil dass es nicht verkehrsregelnabhängig ist (also man bspw. den selben renderer für england und dland nehmen kann). Ich wünsche mir auch irgendein Konzept, wie die Richtungsabhängigkeit von Tags mal systematisiert werden kann. Left/right hat allerdings immer noch den Nachteil, dass es von der Richtung des Ways abhängig ist, die sich ja schon mal beim Editieren aus Versehen leicht ändern kann, z. B. beim Verschmelzen von Ways. Wie wäre es denn daher, wenn man die Richtung an den Himmelsrichtungen festmacht? Also z. B. in Deinem Fall north:highway=bus_stop Ich persönlich würde so was wie ein north/south/east/west-Präfix (vielleicht auch Postfix) für die Fälle bevorzugen, wo eine Lage seitlich des Ways gemeint ist, (Haltestelle, Radweg, Briefkasten), für eine Richtung entlang des Ways (Einbahnstraßen, Fließrichtung von Flüssen, Steigungen) vielleicht so was wie to_north. Das würde doch die Sache sehr stabil gegenüber unabsichtliche Änderungen machen und trotzdem noch die Möglichkeit einer automatischen Verarbeitung durch Editoren ermöglichen. Viele Grüße, Florian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Oneway=1 ind Node? (nur um sicher zu gehen)
Marc Schütz wrote: Am Sonntag, 3. August 2008 11:31 schrieb Stefan Neufeind: Gibt es denn bei JOSM eine Möglichkeit nur Wege oder nur Nodes in dem Bereich zu markieren? Ja, du kannst die Auswahlliste aktivieren (links der Button unter dem Buch), dann zuerst alle Objekte mit dem Mausgummirechteck auswählen, dann in der Liste die Wege oder Nodes markieren (die sind schon nach Typ gruppiert), und anschließend auf Select klicken. Geht, danke. Wie Dimitri schon schrieb: Erschließt sich nicht auf den ersten Blick, ist dann aber doch logisch und eigentlich ganz praktisch zu wissen. So häufig hab ichs auch noch nicht gebraucht ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bennenen von Gebäuden, Plätzen, etc.
Tobias Wendorff wrote: Florian Lohoff schrieb: Ist das nicht eher brand=Lidl ? Ich dachte, wir schreiben immer operator=LIDL - so machen wir es doch auch bei Optikern und so!?! Ich habe leider gerade kein Prospekt zur Hand, meine aber bei einem Edeka-Laden schon mal gelesen zu haben, daß wieser im Rahmen der Kette von Familie soundso betrieben wird. Dann wäre der Name des Geschäfts doch immer noch Lidl oder Edeka und Operator wäre dann jene Familie, oder? Gleiches für z.B. Tankstellen o.ä. (Pächter = Operator = der, der es betreibt?). Wenn Name und Operator genau anders herum zu nutzen _wären_ würde auf der Karte ja überall Paul Brause stehen und nirgends mehr Aral auftauchen, was aber dem entsprechen dürfte was ein User in der Karte suchen wird, oder? (Außerdem ist Aral oder whatever ja imho nicht der Betreiber sondern halt nur die Kette/der Namensgeber/...) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Himmelrichtungsabhängige Tags? (w as : Versetzte Stadtbahnhaltestellen)
Martin Koppenhoefer wrote: Am 3. August 2008 22:17 schrieb Dimitri Junker [EMAIL PROTECTED]: Hallo, ich halte nicht so viel von den Himmelsrichtungen, weil sie nur bei geraden Strassen gut funktionieren, es ging hier um Eigenschaften von Nodes, z.B. für einen Busstop. Und man kann schon sagen, daß man sich am Busstop an der Nordseite der Straße trifft, selbst bei einem Kreisverkehr. Bei Eigenschaften die den ganzen Weg betreffen gebe ich Dir recht, aber da ist es auch einfach diese ggf. automatisch anzupassen. Nodes haben keine Richtung, daher geht das bei Nodes auch nicht. Es kann sich bei left und right immer nur um die Richtung eines ways handeln. JOSM hat ja mittlerweile ein sehr interessantes feature, dass es beim Drehen von Ways mit bestimmten richtungsabhaengigen tags warnt und fragt, ob diese mit umgedreht werden sollen AFAIK aber eben nur für Eigenschaften des Ways. natürlich, s.o. Dies kann man in Zukunft noch erweitern, wenn weitere solcher Tags hinzukommen. Braucht man eigentlich nicht, man müßte sich nur einigen, daß dafür immer die gleiche Syntax verwendet wird. Also z.B. immer left_side_of_way, in_way_direction und die umgekehrten. Diese ließen sich dann sowohl für bus_stop=left_side_of_way cycle_way=left_side_of_way da man ja nicht mehrere key/value-Paare mit den gleichen Keys haben kann, wie wär es denn zusätzlich zum normalen tagging mit: bus_stop:direction = forward;right Dann könnten zur Not manche Renderer bei bus_stop auch einfach nach dem yes Ausschau halten wie bisher und kommen nicht ins trudeln. (Wir sprechen nicht explizit von mappen für den renderer - nur ein abwärtskompatibel modellieren imho, was durch jene spezialisierenden Zusatzeigenschaften doch elegant ist.) und alles andere verwenden. Vorteil, auch eine etwas ältere JOSM-Version würde nicht neue Tags übersehen. Dimitri geht halt nur für ways, bei Nodes sehe ich nicht, wie das funktionieren soll. Stell Dir mal vor, der Node sitzt genau an der Verbindung von 2 entgegengesetzten ways, welcher der ways soll dann betrachtet werden? So herum hatte ich es noch nicht betrachtet. Da sähe ich aktuell nur die Möglichkeit dies per Policy zu regeln (wenn das auch unschön ist): Einem Tag kann man eine direction (forward/backward sowie left/right) nur geben, wenn er Mitglied von genau einem Way ist. Bei mehreren Wegen durch den Node oder einem Node zu dem kein Weg existiert wäre jenes Tag dann sinnlos und sollte gefixt werden. Zwar ist es nicht so elegant derartige Einschränkungen an die Verwendung in einem freien Datenmodell zu machen, jedoch halte ich dies für die schmerzfreiste (einzige?) Lösung. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback: Deutsche Post AG - Briefkasten
Jens Müller wrote: Thorsten Feles schrieb: Ich gehe davon aus, dass die Post sehr wohl weiß wie viele Kästen sie wo hat. Wenn Sie das aber nicht sagen wollen, Ihr Problem. Es könnte aber auch damit zusammenhängen, dass man vermeiden möchte, dass jemand mal wirklich zählt und dann zur Bundesnetzagentur rennt. Hehe. Es könnte ja jemand ein Skript schreiben, daß anhand der Anforderungen an die Briefkastendichte rausfindet, wo in der Karte noch ein Briefkasten fehlt, damit man den gezielt suchen kann. Nette Idee :-) Ist denn schon wieder Ostern? ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Packstationen. War: Feedback: Deutsche Post AG - Briefkasten
Daniela Duerbeck wrote: Tobias Wendorff wrote: habe Rückantwort der Deutschen Post AG bekommen und gleich mal einen Artikel raus gemacht: Zu einem ähnlichen Thema hätte ich noch eine Frage: dhl hat mir bezüglich der Packstationen und Paketboxen leider immer noch nicht geantwortet. Nun sind aber eigentlich alle Informationen übers Web abrufbar, nur ohne Hack halt leider nur manuell. Jetzt würde mich interessieren, ob man, wenn man sich alle Infos holt, manuell, oder per Skript, man die dann eintragen darf? Man müßte wohl ein perlskript schreiben, das mit dem Client bei Yellowmap redet und sich von woanders zu den Adressen die Koordinaten holen. Theoretisch müßte das gehen, aber darf man das? Oder darf ich zumindest, wenn ich mir die Adressen ganz normal (manuell) hole, dann mittels Adress-zu-Koordinatentransfer die Koordinaten eintragen? Hi, Imho nein. Du erstellst ein abgeleitetes Werk von etwas mit (afaik) ungeklärten Rechten. Wenn du das zum überprüfen deiner händisch abgefahrenen Packstationen o.ä. verwendest, wäre es meienr persönlichen Auffassung nach okay, da du die eigentliche Erfassung ja selbst durchgeführt hast. Einfaches übernehmen (ggf. inkl. Fehlern oder absichtlichen Stolperfallen) ist aber keine gute Idee. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[OSM-talk] Tagwatch and osmxapi-links
Hi, in tagwatch, e.g. at http://tagwatch.stoecker.eu/Europe/En/tags.html I see entries that link to adresses like http://osmxapi.hypercube.telascience.org/api/0.5/*%5Bvalue=LIDL%5D That page takes quite a while to load but then returns with an empty document. Is that a timeout in the api or so? How do people manage to use tagwatch to find specific tagged entries (e.g. which need fixing)? Kind regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tagwatch and osmxapi-links
Robert Vollmert wrote: On Jul 29, 2008, at 14:25, Stefan Neufeind wrote: in tagwatch, e.g. at http://tagwatch.stoecker.eu/Europe/En/tags.html I see entries that link to adresses like http://osmxapi.hypercube.telascience.org/api/0.5/*%5Bvalue=LIDL%5D That page takes quite a while to load but then returns with an empty document. Is that a timeout in the api or so? How do people manage to use tagwatch to find specific tagged entries (e.g. which need fixing)? Those links point to XML documents that your browser may (Firefox) or may not (Safari) display. Best to download link location and save to whatever.osm. Would make sense to provide some kind of style information to make any browser that can handle XML display the data nicely? Hi, my firefox (ff3) doesn't display anything here, but also no error or something. And there is nothing in the document it downloaded (view document source). Trying to wget the data from console $ wget http://tagwatch.stoecker.eu/*%5Badopted=*%5D; after some waiting actually results in Connecting to osmxapi.hypercube.telascience.org|137.110.119.130|:80... connected. HTTP request sent, awaiting response... 501 Internal Server Error 2008-07-29 15:09:20 ERROR 501: Internal Server Error. Hmm ... I expect it's only just me and the API is working fine? :-) Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tagwatch and osmxapi-links
Tom Hughes wrote: In message [EMAIL PROTECTED] Stefan Neufeind [EMAIL PROTECTED] wrote: Trying to wget the data from console $ wget http://tagwatch.stoecker.eu/*%5Badopted=*%5D; after some waiting actually results in Connecting to osmxapi.hypercube.telascience.org|137.110.119.130|:80... connected. HTTP request sent, awaiting response... 501 Internal Server Error 2008-07-29 15:09:20 ERROR 501: Internal Server Error. Hmm ... I expect it's only just me and the API is working fine? :-) The API is working fine thanks, but that isn't the API, it's zappy and that is currently down as is well documented. Ah, I didn't recognize that. Is there a simple way to download a planet.osm (or germany.osm or so) and run an osmxapi locally? Or what would be the easiest way to extract all keys/values of a certain type or so to easily edit them in JOSM and upload those few after correction? Regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Osmxapi down
Aurelien Jacobs wrote: Hi, It seems osmxapi is down: $ wget http://osmxapi.hypercube.telascience.org/api/0.5/node[place=*][code_departement=54] Warning: wildcards not supported in HTTP. --2008-07-29 19:17:34-- http://osmxapi.hypercube.telascience.org/api/0.5/node[place=*][code_departement=54] Resolving osmxapi.hypercube.telascience.org... 137.110.119.130 Connecting to osmxapi.hypercube.telascience.org|137.110.119.130|:80... connected. HTTP request sent, awaiting response... 501 Internal Server Error 2008-07-29 19:18:01 ERROR 501: Internal Server Error. If someone could have a look at it, that would be nice. Hi, came across the same thing here as well. It's down by intention and that's documented on the platform status-page in the wiki. Regards, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Feedback: Deutsche Post AG - Briefkasten
Tobias Wendorff wrote: Hallo, Sven Grüner schrieb: Aha! Soll ich mich da einfach per email melden? That's how I did it. Die haben mir eine Word-Datei mit netten Lagebeschreibungen geschickt (Links neben dem Aldi) - teilweise mit Fragezeichen dahinter :-) Vermutlich die gleichen Informationen, die auch an der Hotline gegeben werden. Ich weiß allerdings nicht, inwieweit die das manuell machen. Es kann also sein, dass sie irgendwann keine Lust mehr haben. Darf denn zumindest jenes File veröffentlicht (weitergegeben) werden? Dann könnte man es ja, je nach Umfang, auf Wikiseiten packen und jeder schaut das er in seiner näheren Umgebung (nach PLZ?) alle bereits vorhandenen Briefkästen aus der Liste entfernt. Dann sehen wir in welchen Gebieten noch was übrig bleibt. (Meine aktuelle Schätzung ist, daß die Verteilung von Briefkästen in der Fläche noch halbwegs überschaubar ist pro Stadt.) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
Tobias Wendorff wrote: Hallo, Frederik Ramm schrieb: wie ist eigentlich der Stand in Sachen OpenGeoDB-Import? Fertig? Abgebrochen? Laeuft noch? Soweit ich weiß, gab es doch Lizenzkonflikte? Darf die Datenbank doch importiert werden? Ein Abgleich (wenn wir nicht von plumpem übernehmen von Daten sprechen) sollte doch aber okay sein, oder? Abweichungen müssten ja eh händisch validiert und ggf. vor Ort nochmal gechecked werden. Buchstabendreher o.ä. sollte man damit ggf. finden und händisch fixen können. (Für meine Begriffe wäre das kein abgeleitetes Werk, da man nicht einfach Daten übernimmt.) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
Martin Trautmann wrote: [...] Oder hier kurz die Zusammenfassung: * opengeodb bietet voellig offene Daten - es bleibt dir ueberlassen, was du damit machen willst * Daten aus der OSM duerfen nicht in die opengeodb zurueckfliessen, weil opengeodb damit den Status der Offenen Daten aufgeben muesste. Aenderungen von opengeodb-Daten sollten daher nicht ueber die OSM-Oberflaeche erfolgen, sondern direkt in der opengeodb erfolgen, um dann wieder in die OSM einzufliessen * opengeodb ist urspruenglich abgeleitet von geonames-Daten. Fuer OSM sind geonames womoeglich sogar geeigneter, weil opengeodb die Hierarchisierung und Relationen als Grundschema verwendet. Allerdings halte ich die geonames fuer einen ziemlich wild durchgemischen Haufen. Daher kennt opengeodb z.B. strukturiert das Bundesland Hamburg, den Kreis Hamburg (Kfz-Kennzeichen HH) und die Gemeinde Hamburg (unterste, bundesweit einheitlich genormte Strukturebene). Bisher folgen darunter dann die Ortsteile von Hamburg - wobei sich hier weitere Zwischenebenen anbieten, um z.B. die Insel Neuwerk, die zu Hamburg gehoert, aus der Flaeche des Stadtgebiets herauszuloesen. * opengeodb-Daten wurden mit einem OSM-Benutzer-Script komplett nach OSM uebernommen. Dieses Script wurde ohne grossen Testlauf und ohne undo-Option losgelassen. Entsprechende Probleme konnten daher nicht mehr ausgebuegelt werden: + opengeodb verwendet auch Langformen der Ortsnamen, gerade weil Ergebnisse in Textform praesentiert werden. Auf Landkarten sind solche Zusaetze wie Freie und Hansestadt Hamburg oder Aumühle bei Hamburg unüblich, da die Zuordnung offensichtlich ist. + Beim OSM-Import der Daten wurde nur zur passenden Kurzform des Namens abgeglichen. Daher kamen unerwuenschte Doppel-Eintraege in Langform hinzu. + Beim OSM-Import wurden alle Zwischenebenen mit importiert. Fuer OSM relevant ist eigentlich erst alles ab der Gemeinde-Ebene. Warum ist der letztere Punkt ein Problem? Ich habe noch nicht geschaut, wie es in OSM nun hinterlegt ist - aber in Form von Relationen (gehört zum Kreis ABC, gehört zum Bundesland ABC, ...) sind doch auch größere Informationen interessant - und sei es zur Selektion nach Bundelsand oder whatever. * opengeodb bietet weit mehr als geonames: Postleitzahlen, Einwohner, Hierarchisierung, Flaeche usw. Da müssten wir imho schauen, wie wir davon profitieren könnten. PLZ (und sei es zum abgleichen) o.ä. wäre ja nicht uninteressant für das Projekt zu haben bzw. explizit nutzen zu können (kann man ja verwenden wenn/wo es sinnvoll ist). Angaben wie Einwohner würden wir vermutlich eher über eine Verknüpfung zu einer Meta-Daten-DB später mal machen, oder? (Es wurde ja auch mal sowas ala OpenYellowBook für Gewerbe genannt, ggf. aber auch einfach Wikipedia für Daten über eine Stadt etc.). Über Tags für einfach Verlinkungen auf solche zusätzlichen Datenquellen wurde ja auch verschiedentlich schon gesprochen (aber afaik noch nichts abschließendes Vereinbart?). Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
Bernd Wurst wrote: Hallo. Am Mittwoch, 23. Juli 2008 schrieb Frederik Ramm: [...] Wie gesagt... Einwohner. Alles andere (ob man die Hierarchien geeignet in Relationen packen kann) wuerde ich spaeter machen. Kann man, wurde doch hier schon vorgestellt. Ich glaube zwar, dass das eine echt große Datenstruktur wird, die (mal wieder) sämtliche Datenbanken, Editoren und Renderer zerlegt. Aber das sind ja lösbare Probleme. :) Dafür arbeiten wir ja nicht für den Editor/Renderer *duck* :-) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
Frederik Ramm wrote: [...] Aenderungen von opengeodb-Daten sollten daher nicht ueber die OSM-Oberflaeche erfolgen, sondern direkt in der opengeodb erfolgen, um dann wieder in die OSM einzufliessen Das ist ein voellig hoffnungsloses Unterfangen. Wir koennen in OSM keine Daten gebrauchen, die nicht aenderbar sind bzw. wo man dem Benutzer sagt aender das nicht hier, sondern irgendwo anders. Das macht keiner, das kriegen wir nicht vermittelt. Ich sehe zwei Moeglichkeiten: 1. Wir importieren den OpenGeoDB-Kram und kuemmern uns nicht drum was mit OpenGeoDB wird. Das ist sehr egoistisch, aber so ist das eben mal mit Public Domain-Daten: Man muss sich nicht drum kuemmern. Was wir fuer OpenGeoDB tun koennen, ist, zumindest irgendeine ID von denen mit zu speichern, so dass OpenGeoDB regelmaessig einen diff laufen lassen kann und auf die Weise rausfindet, welche Objekte in OSM seit dem Import geaendert wurden. Diese darf OpenGeoDB dann zwar nicht direkt aus OSM herauskopieren, aber zumindest mal die Herstellung einer Liste a la die folgenden Dinge sollten mal ueberprueft werden, denn die OSM-Leute waren da anderer Meinung ist ja zulaessig. 2. Wir gehen vor wie bei (1), fuegen jedoch an jeden aus OpenGeoDB importierten Node eine Notiz an, die besagt: Wenn Du diesen Node aenderst, stimmst Du einem Re-Import in die Public Domain-OpenGeoDB zu. Wenn Du nicht einverstanden bist, entferne diese Notiz. - Dies wuerde OpenGeoDB in die Lage versetzen, diese Nodes aus OSM wieder auszulesen. Rechtlich ist das auf jeden Fall machbar, denn Urheber ist ja der Einzelne, der etwas aendert, und derjenige hat die Moeglcihkeit, beliebige zusaetzliche Lizenzen zu vergeben; in diesem Fall wuerde er also an OSM die CC-BY-SA-Rechte geben plus zusaetzlich noch den Node PD lizensieren. OpenGeoDB koennte nun all jene Nodes, bei denen diese Notiz noch intakt ist, jederzeit wieder exportieren. Umgekehrt wuerden wir regelmaessig Importe aus OpenGeoDB machen, um Aenderungen von dort mitzubekommen. Das mit (2) ist so ein bisschen eine Cowboy-Methode, aber ich finde sie den Umstaenden entsprechend eigentlich ziemlich gut; jeder hat was davon, keiner steht nachher schlechter da als vorher. Könnten wir ggf. auch allgemein source:OpenGeoDB definieren und an anderer Stelle dann allgemein diese Notizen/Lizenzgeschichten vorhalten, auch ggf. in entsprechenden Landessprachen usw.? Wir haben ja bisher auch source-Tags - und wenn jemand der Meinung ist nun überwiegend die Daten durch eigene ersetzt zu haben, kann er source rausnehmen. Eine andere Variante wäre license:pd o.ä. einzuführen, ggf. den Leuten für neue Nodes in JOSM sogar eine editierbare Voreinstellung zu geben ... und so einer etwaigen Rechte-Ausrichtung von OpenStreetMap vorwegzugreifen (den Leuten nahezulegen ihre Nodes z.B. als PD zu erfassen, wenn sie das wirklich wollen). Insgesamt finde ich die Verwaltung mehrerer Lizenzen (oder quasi Dual-Licensing?) in OSM etwas unglücklich. Nicht das uns das bei einer noch anstehenden (?) Lizenzänderungsdiskussion mal zum Nachteil wird. Aber eine bessere Idee habe ich leider auch derzeit nicht ... [...] Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] (Nicht nur) [EMAIL PROTECTED] (ist) furchtbar langsam(!)
Bernd Wurst wrote: Hallo. Am Dienstag, 22. Juli 2008 schrieb Dirk-Lüder Kreie: Im Grunde genommen bräuchte es jemanden, der freiwillig einen Server spendet, dort den OSM Planet in seine Datenbank packt, und minütlich aus den diffs aktualisiert. (ca 80 GB Plattenplatz, Traffic unbekannt). Warum wird eigentlich für sowas hier immer [*] mit planet-file und diffs gearbeitet? Also immer konvertieren nach und von XML. Wäre es nicht sinnvoll, für sowas einen einfachen MySQL-Slave einzurichten, der direkt oder über ein VPN mit dem Hauptserver kommuniziert? Die Last auf dem Haupt-Server steigt dadurch nicht wesentlich und die Daten sind immer so aktuell wie es die Netzwerkverbindung hergibt. Grade für alle Arten von Datenbank-Dumps sollte man ja immer einen MySQL-Slave machen und von dem dann die Dumps ziehen. Eigentlich sollte bei so viel Traffic IMHO sowieso alles nur-lesende nicht auf den selben Server gehen wie Schreibzugriffe (Erstellung von XML-dumps, [EMAIL PROTECTED], Download von Editoren). [*] immer == das was ich mitbekomme == XAPI-Interface Die Daten werden ohnehin als Diff's geschrieben (an verschiedenen Stellen sowie historisch benötigt). Die letzte Aussage zum Thema war, daß wenn man eine MySQL-Replikation aufsetzen würde dies dann ja _zusätzlich_ wäre - und das ist für die knappen Server-Resourcen nicht hilfreich. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry wrote: Tordanik schrieb: Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Unbedingt dafür! Die Diskussion hatte ich letzte Woche auch beim OSM-Treffen in Karlsruhe angeleiert.da ich oft auch bei der Baustellenerfassung tätig bin. Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche Strecken vielen gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt. Steht preserved für geplant? Ansonsten sollte das unbedingt mit berücksichtigt werden. Wegen Zeitangaben: Ich würde es in klammern hinter den Namen schreiben damit man es in jeder Anwendungen sehen kann und das somit möglichst alle OSM nutzer sehen und damit gegebenfall anpassen können. Dadurch besteht die grösste Wahrscheinlichkeit dass die Daten zeitnah angepasst werdenbzgl. Bauzustand, Freigabetermin... Hi Garry, du meinst im dem Zusammenhang ein Datum ala status:last_checked=20080721? Das könnte dann ja sinnvoll sein um regelmäßig mal zu schauen was ggf. noch zu kontrollieren wäre. Aber wie schon eingangs von jemand gesagt: Wir sollten uns bzgl. des Proposal vielleicht besser nicht verzetteln und Zeitstempel in ein zweites Proposal aufnehmen. Allgemein finde ich die Idee eines status gut, um so für die Orientierung sinnvolle Sachen (oder im Bau befindliche Straßen die demnächst fertig werden etc.) aufnehmen zu können, Router o.ä. aber davon abzuhalten so eine Straße oder whatever schon zu verwenden. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm wrote: Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: [...] Ich halte diese Art des Taggings fuer fragwuerdig und will das an einem Beispiel illustrieren: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. Ich gebe zu, dass die Grenze oft fliessend ist, und ob irgendwo ein Radweg oder eine Autobahn gebaut wird, beeintraechtigt den Charakter der Baustelle u.U. erheblich. Dennoch ist auch eine Autobahnbaustelle nicht in erster Linie eine Autobahn, sondern in erster Linie eine Baustelle, finde ich. Noch deutlicher wird es, wenn die Sachen nichtmal im Bau sind, sondern nur in Planung. Das würde uns im Umkehrschluß bei einer Straße aber dazu führen, daß wir eine 5km lange Baustelle einzeichnen - von der die meisten Leute davon ausgehen das dies eine Straße seien wird. Ggf. vergibst du sogar schon ref=A 5 weil du weisst das dies die Verlängerung der neuen Autobahn ist ... hmm. Das es für Gebäude (auch ein AKW) ggf. ausreichend sein kann diese als Gebäude-Baustelle zu taggen, sehe ich ggf. ein - aber ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Paketstationen
Hi, beim Thema Post viel mir gerade ein, daß ich zuletzt an einer Paketstation (kein Kiosk mit Paketannahme, sondern diese Standalone-Geräte) vorbeigekommen bin. Soweit mir bekannt gibt es die derzeit nur von der Deutschen Post, potentiell könnten ja aber demnächst auch nochmal andere Versandunternehmen etwas ähnliches machen. Sind jemand für Paketstationen passende tags bekannt, und wie würde man z.B. den Betreiber (operator=...?) taggen? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Paketstationen
Tobias Wendorff wrote: Stefan Neufeind schrieb: beim Thema Post viel mir gerade ein, daß ich zuletzt an einer Paketstation (kein Kiosk mit Paketannahme, sondern diese Standalone-Geräte) vorbeigekommen bin. Soweit mir bekannt gibt es die derzeit nur von der Deutschen Post, potentiell könnten ja aber demnächst auch nochmal andere Versandunternehmen etwas ähnliches machen. Sind jemand für Paketstationen passende tags bekannt, und wie würde man z.B. den Betreiber (operator=...?) taggen? Soweit ich weiß, habe ich hier über drei Möglichkeiten gelesen: amenity=packstation oder parcel_box oder parcel_depot dazu dann noch Informationen name=(Packstation xy) ref=(Nummer der Packstation) zip=(Postleitahl der Packstation) operator=Deutsche Post AG bzw DHL Hi, hmm, ich weiss nicht warum ich das vorhin im Wiki nicht gefunden habe. Aber da gibts tatsächlich schon was zu. Über die suche nach parcel_box hab ichs gefunden. http://wiki.openstreetmap.org/index.php/De:Howto_Map_A http://wiki.openstreetmap.org/index.php/Packstation Wenn wir nicht davon ausgehen, daß parcel_box eine spezielle Variante der post_box ist (und wir das mit post_box zusammenlegen) ist vermutlich parcel_box wirklich eine gute Variante. Was mir aufgefallen ist: Du schriebst oben von zip. Im Wiki wird postal_code erwähnt. Im Karlsruhe Schema, was zuletzt mal angesprochen wurde, findet addr:postcode Verwendung. In den Map_Features wird postal_code allgemein als Angabe genannt ... dann wäre jene Bezeichnung durchgehend doch vermutlich am sinnvollsten, oder? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Angabe für Postleitzahl - Karlsruhe Sc hema
Hi, im Karlsruhe Schema http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema wird addr:postcode vorgeschlagen. Wäre es vielleicht sinnvoll daraus postal_code zu machen, da jener Begriff auch schon in den Map_Features eingeführt wurde? Es macht doch sicherlich wenig Sinn zwischen beiden Bezeichnungen zu springen oder gar noch zip mit in die Runde zu werfen ... imho. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zigaretten- / Kondomautomaten
Andreas Jacob wrote: Am Freitag, 18. Juli 2008 00:02:24 schrieb Matthias Wimmer: Hallo! Ich habe im Wiki nichts gefunden und frage deswegen hier: Taggt irgendwer Automaten und was diese verkaufen? Wenn ja mit welchem Tag? Ich habe das Schema von Christian Körner übernommen: amenity: vending_machine vending_products: cigarettes, stamps, condoms, train_tickets ... Könntest du das mal ins Wiki schreiben (proposal?). Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Breite von Flüssen in Osmarender!
qbert biker wrote: Original-Nachricht Datum: Sun, 13 Jul 2008 13:46:04 + (UTC) Von: Sven Geggus [EMAIL PROTECTED] An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Breite von Flüssen in Osmarender! Tobias Wendorff [EMAIL PROTECTED] wrote: Ich persönlich habe noch keine Autobahnen getagged und kenne daher die Machart nicht, aber wäre es nicht sinnvoll, die Anzahl der Spuren und die jeweilige Fahrspurbreite anzugeben? Für die OSM Datenbasis könnte das sinnvoll sein. Wir diskutieren hier aber über Rendering! Ich habe noch nie eine Karte gesehen, die 2-spurige Autobahnen anders darstellt al 3-spurige. Was an der Eingeschränktheit dieser Karten und auch an der Datenbasis liegt. Soweit ich mich erinnern kann ist das Eintragen der Spuren in GDF ziemlich schräg gelöst, irgendwie mit Gruppen, so dass man die konkrete Spuranzahl oft nicht richtig eintragen kann. In diesem Sinne wäre es ein Pluspunkt für OSM, wenn die Spuranzahl richtig eingetragen und auch angezeigt wird. Für einige potentielle Anwendungsgebiete (Verkehrsforschung, Stauvorhersage), ist dieses Datum sogar von besonderer Wichtigkeit. Für manche mag auch die Existenz eines Standstreifens von Bedeutung sein. Hmm, interessant wäre die Information vielleciht durchaus, ja. Für sehr detailreiche Karten z.B. auf einem Navi könnte ich mir das schon gut vorstellen. Dann stellt sich mir allerdings beim Wechsel von 2 auf 3 Spuren die (berechtigte?) Frage an welcher Seite der Autobahn diese dritte Spur hinzukommt *duck* Hat jemand dafür auch eine Idee (und mag mal ein Proposal schreiben)? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Breite von Flüssen :)
Frederik Ramm wrote: Hallo, gemeint war glaube ich, dass man falls vorhanden width berücksichtigt. Für den Fall, dass es aber nur einen Tag est_width gibt, und kein width, wäre es nicht schlecht, dies auch abzufragen und in diesem Fall so wie sonst width beim Rendern der Breite zu berücksichtigen. Also nicht zusätzlich, sondern alternativ. Ich hab nicht wirklich Verstaendnis fuer est_width. Machen wir doch sonst auch nicht, dass wir unterscheiden zwischen geschaetzt und gemessen. Wenn der Mapper nur eine geschaetzte Breite hat, kann er die ja in width reinschreiben und source=estimate setzen oder so, und wenn jemand anders spaeter nachmessen will, soll er width aendern. Es gibt keinen Grund, warum ein est_width noch erhalten bleiben muss, wenn es ein width gibt, und daher kommt mir der Aufwand um den Extra-Tag unnoetig vor. Aber nicht der Node oder die Straße an sich sind geschätzt, nur die Breite. Wäre daher das hier im Thread mal vorgeschlagene width:source=estimate dann ggf. sinnvoll als Einschränkung? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?[patch] Breite von Flüssen : )
Stefan Schwan wrote: Am 17. Juli 2008 01:13 schrieb Frederik Ramm [EMAIL PROTECTED]: Hallo, gemeint war glaube ich, dass man falls vorhanden width berücksichtigt. Für den Fall, dass es aber nur einen Tag est_width gibt, und kein width, wäre es nicht schlecht, dies auch abzufragen und in diesem Fall so wie sonst width beim Rendern der Breite zu berücksichtigen. Also nicht zusätzlich, sondern alternativ. Ich hab nicht wirklich Verstaendnis fuer est_width. Machen wir doch sonst auch nicht, dass wir unterscheiden zwischen geschaetzt und gemessen. gemesen scheint mir hier das Stichwort - wers dabei genaunimmt wird wohl meißtens im Ergebniss eine Deziamalzahl abliefern - Vielleicht kann man sich ja darauf einigen, nur in Ganzen Zahlen (Metern) zum schätzen ? Und bei gemessen zur Not 5,01m draus zu machen? *duck* Du wirst imho nie eindeutig sagen können ob das 5cm mehr oder weniger sind bei einer Straße o.ä. Auch wird bei Flüssen etc. niemand die Breite an jedem Node messen. (Dann müsste man die Breite sogar eher an den Node schreiben als an den Flussabschnitt ... n) Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] aus dem Panel starten
Josias Polchau wrote:
Christian Koerner schrieb:
Zwei Moeglichkeiten, du legst dir 'n Shellscript an das zuvor in das
Verzeichnis wechselt in dem tilesGen.pl liegt und es von dort aufruft.
moin...ich habe die zweite Möglichkeit genommen aber noch ein rm stopfile.txt
hinzugefügt: sodass man das nicht immer wieder löschen muss:
#!/bin/sh
TAHPATH=/home/user/osm
cd ${TAHPATH}
rm ${TAHPATH}/stopfile.txt
perl ${TAHPATH}/tilesGen.pl loop
desweiteren hab ich ein weiteres script angelegt um die loop zu stoppen:
#!/bin/sh
TAHPATH=/home/user/osm
cp ${TAHPATH}/stopfile.txt.temp ${TAHPATH}/stopfile.txt
Hi,
du könntest zum erzeugen auch einfach ein
touch ${TAHPATH}/stopfile.txt
machen und in der config von tah konfigurieren, daß er nach dem beenden
durch ein stopfile automatisch auch die Datei löschen soll.
Stefan
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Kartieren von Parkwegen etc.
Karl Eichwalder wrote: Jens Müller [EMAIL PROTECTED] writes: Rad/Fußwege mit entsprechendem Schild - footway/cycleway Rad/Fußwege ohne entsprechendem Schild in der Stadt: path Rad/Fußwege ohne entsprechendem Schild außerhalb der Stadt: track Macht das Sinn? Nee. path bitte komplett ignorieren, das führt nur zu verwirrungen. Nein. Ein Radweg kann auch ohne Schild (und zB mit Piktogrammen) ein Radweg sein, eben als anderer Radweg. Man sollte nur das als highway=cycleway taggen, wo ein entsprechendes blaues schild steht und das ohne ausnahme. Nach ein traffic_sign=z240 oder =z241 oder =z237 dazupacken, dann wird es eindeutig. Wie üblich steht im wiki viel mist: alles nicht falsch, aber irgendwie ein mittelweg, der am ende keinen ans ziel führt ;) Könntest du den Thread dann bitte mal entflechten (Junge, Junge ... ne Menge zu lesen wieder ...) und mal das Wiki ergänzen? Es wäre imho gut, wenn hier Fragende eine klare Antwort im Wiki finden und sich nicht genervt was ausdenken (na gut, dann mach ich halt mal irgendwas was ich meine). Imho ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Misclassified roads
I think that's what people use key = fixme value = note for, wrong? Kind regards, Stefan Alex Wilson wrote: Perhaps a compromise would be to add a new tag: something like 'needs_review=true'. After a revisit of the road, the tag can be removed and the road classification left as is or modified as appropriate. Cheers, Alex 2008/7/10 David Ebling [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Steve, I would suggest you reconsider doing this. I would strongly support the use of highway=road for new roads that no information is available for, eg from a trace that was done with a car but no notes were made. However, by retagging unclassified to road you are essentially deleting information from the database that you don't know to be incorrect. Sure, if you know the classification is correct, change it, but don't just delete it - it could be correct. For what it's worth, I work on the following basis for UK road classifications: * trunk/primary/secondary - as signed. * tertiary - other roads that predominantly have a white line of some sort down the centre. These tend to be wider roads used by more traffic. I believe OS maps use a similar distinction, and I think it's useful for planning routes, both with a map or automatically. * unclassified - roads without a centre line. If they are too narrow for passing, I add lanes=1. On this basis I have mapped a great number of unclassified roads. It would be a real shame if you deleted this information that I had carefully collected. I accept that there are a large number of incorrectly tagged roads out there, but correct them, don't delete info on the offchance. Regards, David Message: 2 Date: Wed, 9 Jul 2008 15:36:03 +0100 (BST) From: Steve Hill [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: [OSM-talk] Misclassified roads To: talk@openstreetmap.org mailto:talk@openstreetmap.org Message-ID: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Following the approval of the highway=road tag, I've set about aggressively changing a lot of the highway=unclassified roads around Swansea, that I believe are misclassified, to highway=road, with the intention that they can then be surveyed and reclassified correctly. However, after starting to do this, I've realised just how many of the roads are misclassified - I'd estimate that well over 80% of the roads tagged as highway=unclassified are, infact, not unclassified roads. So I'm wondering about the merits of changing *all* the highway=unclassified roads in the area to highway=road so that the whole lot can be classified appropriately from scratch. This would make it obvious which roads really are unclassified and which need to be checked. What are peoples' views on this? I imagine that much of the OSM world is affected in the same way, and this renders the highway=unclassified tag relatively meaningless in it's current state. Should there be a global reclassification to fix this, or is there a better way? - Steve xmpp:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] http://www.nexusuk.org/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Cyclemap verbessern
Frederik Ramm wrote: Hallo, On 07.07.2008, at 11:34, Sebastian Niehaus wrote: Usw. - ich moechte von sowas dringend abraten. Ist bei den tracktypes eigentlich schon nicht gut und stoesst auch auf viel Widerstand. Ist tracktype also auch sinnvoll, wenn der highway kein Track ist (Radwege, Strassen ...)? Tracktype wird in der Regel nur mit tracks zusammen benutzt. http://etricceline.de/osm/Europe/En/tags.htm listet uebrigens ausserdem auch noch die Keys track type track_type tracketype trackgrade trackgrade3 trackktype trackrtype tracktaype tracktepye trackteype tracktipe tracktpye tracktye tracktyoe tracktyp tracktype_alt_1 tracktypeq tracktyper tracktypet trackway trackype trackytpe tracltype tractype ;-)... ich hatte dort geschaut, weil ich dachte, ich finde so eine Haeufigkeits-Analyse fuer die Kombination von Tags, aber da hab ich wohl was verwechselt - irgendwo war sowas doch mal. Hi Frederik, da du im Gegensatz zu mir glaube ich einfache Möglichkeiten hast mal über den Datenbestand zu suchen, magst du evtl. nach o.g. Tippfehlern mal Ausschau halten? Vermutlich treten die nur je max. 1-2x auf, und das wäre doch prima zu fixen ... Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
