Re: [Talk-de] Idee für automatischen Serverwechsel bei Kartenausfall
Am 05.10.2012 12:30, schrieb Jan Tappenbeck: Ich würde gerne automatisch die Kacheln eines anderen Servers einbinden, wenn der Toolserver mal ausfallen würde. Hi, mit der selben Problematik haben wir uns auch schon auseinander gesetzt. Ich gehe mal von Openlayers aus. Am Besten wäre es aus unserer Sicht, wenn man (zb statt der einen URL im WMS oder TMS) eine liste von URLs angeben könnte, nach Priorität sortiert. im im XYZ-Layer kann man bereits mehrere URLs angeben, dabei werden die Requests aber gleichmäßig auf alle URLs verteilt. das ist schön für Lastverteilung aber nicht für Ausfallsicherheit. Andreas bereits erwähnte, kann man entweder den Timeout per JS abfangen oder vor dem Laden einen kleinen Request absenden. Gruß Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hamburger Verkehrsverbund benutzt jetzt OSM
Hi, Seit kurzem benutzt der Hamburger Verkehrsverbund (HVV) OSM-Karten als Hintergrundkarte für seinen Verkehrsnetzplan. http://geofox.hvv.de/jsf/mapsOSM.seam Außerdem werden die OSM-Daten als Grundlage für das Fußgängerrouting in der Fahrplanauskunft genutzt. z.B.: http://geofox.hvv.de/jsf/home.seam?clear=truestartName=AlsterstartType=2destName=Planten+un+BlomendestType=2 Mit freundlichem Gruß Josias Polchau Softwareentwickler, GIS E-Mail: josias.polc...@hbt.de Tel.: +49 40 369779-72 HBT Hamburger Berater Team GmbH Stadthausbrücke 3, 20355 Hamburg Geschäftsführer: Ilse Habermann, Hans-Joachim Habermann, Arne Habermann, Daniel Hoffmann Handelsregister: HRB 31629 Hamburg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zu historischen Gedenksteinen - Sühnesteine etc.
Am 18.02.2012 23:24, schrieb Martin Koppenhoefer: ich würde das als historic=memorial taggen und ggf. einen Subtyp dazu evtl. mit memorial=grave ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mobile Hardware zum Mappen (war: Dakota 20 oder Oregon 450?)
Am 17.02.2012 17:28, schrieb Ronnie Soak: Oder mag mal wer JOSM fuer Android und Stifteingabe optimieren? Auch wenn josm in java geschrieben ist, müsste es auf Android portiert werden. Es gibt aber schon einen recht brauchbaren (wenn auch noch verbesserungswürdigen) Editor: Vespucci ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik2 und deutscher Stil
Am 01.02.2012 10:31, schrieb Andre Joost: nachdem der offizielle Mapnik stil im svn nun auf Mapnik2 ugestellt wurde: hat sich da schon jemand um den deutschen Stil bemüht? Das Problem beim deutschen Kartenstil ist, dass er m.e. lange nicht mehr aktuell ist. Inzwischen ist die Weiterentwicklung von mapnik-en soweit fortgeschritten, dass es m.e. einfacher wäre ein Diff zwischen altem mapnik-en und mapnik-de zu erstellen, und dann halbautomatisch jeweils auf die aktuelle Version von mapnik-en anzuwenden. Anders formuliert: was sind die essentiellen Unterschiede? Farben und Formen der Straßen. Dazu noch ein paar Besonderheiten, die in der letzten Zeit erarbeitet wurden. Diese Unterschiede sollten im Wiki Dokumentiert werden und (evtl. durch ein Skript) auf die aktuelle Version angewendet werden. Natürlich können weitere Besonderheiten hinzugefügt werden. Die letzte Änderung an Mapnik-de ist vom 2.7.11. Gruß Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dsds?
Am 20.01.2012 01:54, schrieb Klaus-Hermann Otto Stanislaus Plöger: Schreiben wir jetzt auch alle meine Fahrradpannen hier hinein? Es geht hier um das Wack, das ein erhebliches Hindernis in der Seefahrt darstellt. Ich wette unter den nächsten Nachträgen der professionellen Seekarten wird auch dieser Bereich sein. an alle Kadetten: Viel Spaß beim Kleben ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dsds?
Am 20.01.2012 12:08, schrieb Klaus-Hermann Otto Stanislaus Plöger: http://www.elwis.de/BfS/bfs_start.php Meinst Du sowas? Mein Schwager berichtete von Kartenschnipseln, die sie in die Seekarten kleben mussten. Bekommen haben sie die vom Herausgeber. evtl. hab ich da aber auch was durcheinander bekommen... Josias (SBF See) :D ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
Am 28.06.2011 15:24, schrieb Wolfgang: Abgesehen von Aktualität habe ich nach der on the ground rule bisher noch keine Postleitzahlen, Gemeindegrenzen oder TMC-Tafeln gesehen, zumindest nicht flächendeckend. wo wird TMC auf der Karte _angezeigt_? es geht so viel ich es gesehen habe hier nur um den deutschen Kartenstil und nicht das was in die OSM-DB eingetragen werden darf. Ich glaube die Relevanzregel für das Eintragen war: relevant ist, was für den Eintragenden relevant ist und für ca. 2 Wochen am selben Platz ist aber das sind auch nur Richtlinien, keine Gesetze. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?
Am 28.06.2011 14:52, schrieb Jan Torben Heuer: Umgekehrt könnte man auch Argumentieren der Taxiway ist ein Weg wie jede andere Straße auch und sollte auch wie jede andere erstellt werden - nicht als Fläche. naja... es liegt im ermessen des eintragenden eine Straße als Fläche oder als Linie einzutragen Ich denke gerade am Beispiel Tempelhof sehen wir, dass Flächen und Straßen ineinander über gehen und eine pragmatische Lösung um sowohl eine schöne Karte als auch ein funktionierendes Routing zu erreichen wäre schön. Wenn jemand es schafft den Funel Algoritmus auf diese Flächen anzuwenden, um so besser. Ich würde generell eher mit einem Sichtbarkeitsgraphen arbeiten, und die Routen über den platz vom Router vorberechnen und so das Routingnetz automatisch erweitern. Vielleicht ist es ja eine Möglichkeit eine Fläche als 'form' einer Linie zu definieren um somit sein aussehen explizit darzustellen. Über eine Relation könnte beides verbunden werden. Somit wären nicht zwei unabhängige Objekte in der Datenbank und Routing/Renderer benutzen je was sie brauchen. Nur so ne Idee. so eine idee hatte ich auch schon mal... aber Wege über Plätze (es sei denn sie sind real vorhanden) sind meiner Meinung nach überflüssig * Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?
Am 27.06.2011 20:04, schrieb Peter Wendorff: P.S.: Ja, ich weiß, dass das bisher kaum zu vermeiden ist, aber ich kenne keine Lösung, wie das sauber geht, und unsaubere Lösungen will ich gar nicht vorschlagen. wenn du Routing-Algorithmen meinst: Es gibt viele Arbeiten, die sich mit dem Routing über Plätze beschäftigen. Da kann man zb den Funel-Algorithmus oder einen Sichtbarkeitsgraphen benutzen. Es gibt keinen grund für Hilfswege außer der Faulheit der Programmierer. Das wichtigste ist allerdings die Plätze mit den weiterführenden Wegen oder den angrenzenden straßen zu verbinden. *Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
Am 24.06.2011 02:21, schrieb Frederik Ramm: So, wie es im Moment ist, gibt es allerdings niemandem, bei dem man einen Mangel melden koennte und der sich dann darum kuemmert. Hi, wenn ich zeit hätte (ich bastele grad noch an dem Fußwegrouting), würd ich das gerne machen, weil mich das brennend interessiert. Was fehlt ist ein Art Ticketsystem. Das würde auch für die nötige Tranzparenz sorgen und doppelte Einträge reduzieren. Ich würd mich zumindest an der Betreuung dieser beteiligen und ab und Änderungen einpflegen. Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Krankenhausgelände
Am 10.05.2011 16:25, schrieb Georg Feddern: sondern ist schlicht falsch, Hi, ich störe mich grade bisschen an dem Wort falsch. Mein Verständnis von OSM war, dass es kein richtig und falsch gibt. es gab früher nur 2 Regeln bei OSM: 1. Nutze keine Urheberrechtlich geschützen Daten 2. Have Fun was meinst du, warum auch der Key ein Freitext ist? genau, weil es keine Beschränkung geben sollte. OSM hatte immer Common Tags also meistens so gebrauchte Tags aber nie nutze Tags ausschließlich so, wie sie im Wiki stehen. mag sein, dass sich das grade etwas kleinkariert anhört, wenn ich so auf einem Wort herumreite, und mag sein, dass ich dich einfach falsch verstanden habe, aber ich stelle nach all den Jahren fest, dass grade diese Freiheit OSM zu dem gemacht hat was es nun ist. ich würde mich freuen, wenn OSM weiterhin eine offene Comunity ist, in der Jeder das machen kann, was er für richtig hält, wenn er keinen anderen stört. bisher haben wir uns schon immer einigen können. Alles Gute wünscht Josias Relevant ist, was der Eintragende für relevant erachtet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] U-Turn via einen Way
Am 06.03.2011 17:56, schrieb M∡rtin Koppenhoefer: Wenn ich dann an der Gegenrichtung ankomme, darf ich entweder links abbiegen oder nicht (turnrestriction). Ob ich auf der Querstraße selbst wenden darf oder nicht, wäre wieder nur ein U-Turn mit einem Node (oder nur ein tag auf dem Weg. wenden verboten). verkehrsrechtlich gilt die Hin- und Rückrichtung als eine Straße. und wenn da ein No-U-Turn-Schlid steht, dann ist es verboten zu wenden. jetzt ist einfach nur die frage, wie man das abbildet in OSM - und nicht, ob diese Regelung Sinn macht ;) auf großen Kreuzungen macht dieses verbot schon Sinn. wenn nämlich von links die Linksabbieger und von oben die Rechtsabbieger grün haben, dann würde man mit einem U-Turn einen Unfall verursachen. | | -+---+--- | | -+---+--- | | ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am 08.02.2011 16:34, schrieb Frederik Ramm: aber das ganze darf auch nicht zu einem free-for-all a la Tiles@Home werden, wo jeder seine Lieblingstags eintragen darf ;) das große Problem von t@h ist doch, dass Überlappungen nicht herausgerechnet werden. es muss einfach eine Hierarchie geben (wie bei mapnik derzeit) Objekt x wird nur gerendet, wenn kein Objekt mit einer höheren Hierarchie an der Stelle oder in der Nähe ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Siedlungsstruktur in OSM verfeinern (Place und rank)
Zu dem Thema Beschriftung einer Karte gibt es eine interessante Master Arbeit: leider nicht wirklich öffentlich, hab nur einen Vortrag gehört. seine lösung war: ich erkläre das mal bildlich, lässt sich aber gut in einen Algorithmus packen - für jede Beschriftung einen Score speichern. (- der Score gibt indirekt die Größe der Beschriftung vor.) - auf der untersten zoomstufe werden alle Beschriftungen dargestellt. - jede beschriftng hat eine (virtuelle) auf-dem-Kopf-stehende Pyramide über sich - die Höhe der Pyramide wird durch den Score bestimmt. - der öffunungswinkel der Pyramiden ist die skalierung der schrift auf der karte - dazu kann man einen festen Rand addieren das wird dann ein Paraboloid - die zoomstufen sind ebenen Schnitte durch diesen Pyramidenwald: Zoomstufe | 0 1 \ / __ 2\/___ \/ 3 \ /\ / \ / 4 \/ \/\/ Namen: Name1 Name2 Name3 - wenn sich Pyramiden überschneiden wird die angezeigt, die den größten score hat. (Pyramide von Name2 wird abgeschnitten) - als zusätzliche Erweiterung kann noch die Position der Beschriftung angepasst werden (bezogen auf den Punkt: mittig drüber oder drunter, rechts, links usw) - anschließend werden Überschneidungen gezählt und über über lernende Algorithmen (zb ameisen) die positionierung verbessert werden. so viel ich weiß wird dieses verfahren professionell eingesetzt. Harmann Becker (bzw deren frühere Tochter Inovativ Systems) benutzen das. ich hoffe ich hab mich verständlich ausgedrückt... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Siedlungsstruktur in OSM verfeinern (Place und rank)
der Score kann über beliebige Funktionen berechnet werden zb: Einwohnerzahl (*|+) Fläche (*|+) Wichtigkeit (*|+) PolitischeFunktion wichtigkeit kann zb über die anzahl von öffentlichen einrichtungen, die größe dieser usw berechnet werden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] An die thread-Piraten
Am 09.10.2010 10:34, schrieb Tom Müller: Kann man das mit Thunderbird zufällig auch? wenn du im Thunderbird osm-de als Newsgroup liehst (zb über gmane), kannst du mit der taste 'k' ein Thema ignorieren. Beim nächsten Aufruf wird das Thema nicht mehr angezeigt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von shops in OSM
Am 16.09.2010 23:30, schrieb Frederik Ramm: Dann aber bitte erst ab Zoom Level 19 klar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von shops in OSM
Am 16.09.2010 17:45, schrieb Peter Wendorff: Spricht etwas dagegen, das für das Stadtgebiet selbst zu rendern? Wahrscheinlich der Aufwand. zB: nicht jede Stadt oder Gemeinde kann es sich leisten einen Server nur für die Karten hinzu stellen oder sich jemanden zu engagieren, der sich mit osm auskennt. ich denke wir sollten wirklich langsam daran denken mehr Details im Standard Style zu rendern. damit meine ich vor allem Geschäfte. die sind gut dokumentiert und wenn sie erst mal gerendert werden, werden sie auch viel öfter eingetragen (könnt man gut beim öpnv sehen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telefonzelle, Position
Am 14.09.2010 13:33, schrieb Walter Nordmann: schwachsinn, so nen tag gibt es nicht. raus damit oder einfach ignorieren http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A#T wenn man nur nach Howto_Map_A gehen würde, wäre OSM nicht so reich an Möglichkeiten. Nur weil man selbst im Moment keinen Sinn in den Tags sieht, könnte sich jemand anderes was dabei gedacht haben. Deshalb, wenn man nicht sofort den sinn erkennt, einfach den Ersteller fragen. Ansonsten landen wir bei den Löschmonstern von Wikipedia. Wie schon mein Vorposter gesagt hat, das ist die offizielle Adresse der Telefonzelle, wie sie die Telecom angibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am 07.09.2010 06:16, schrieb Florian Lohoff: On Mon, Sep 06, 2010 at 09:13:24PM +0200, Josias Polchau wrote: Am 06.09.2010 09:37, schrieb Florian Lohoff: SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der TRAPI sind die vielen kleinen files und perl als interpretersprache die nicht wirklich super fuer die bit ops ist (Ich bin sonst schon ein perl fan) Du kennst PostGis? die Geometrie-Daten werden in einem Binärformat abgespeichert. Ein eigenes DB-Schema kann man auch erstellen. Ähnlich dem von Mapnik. Ja - Kenn ich - beschaeftige mich seit mehreren Jahren damit. Aber mal drueber nachgedacht wie ineffizient es ist in der Postgres/Gis einen node abzulegen in einer tabelle die eine numerische id, lat, lon und sonst nix enthaelt? Die tabelle ist nicht besonders breit und der index in etwa genausogross wie die tabelle selbst. Das geht wenn man es massschneidert signifikant effizienter ... Nein die Suche ist bei Postgres effizient nicht der Speicherplatz. und genau das brauchen wir für die XAPI nicht um sonst hat die bisherige XAPI auch eine DB im hintergrund. Das problem an der alten ist, dass keiner mehr den code warten kann bzw eine weitere instanz aufsetzen kann. d.h. 60GB zu 6.2GB - da ist ohne index nen faktor 10 dazwischen. Postgres/Gis ist super als rapid prototyping und um schnell mal mit wenig daten was ans laufen zu bringen. Aber OSM bring das zeugs schnell an den rand des machbaren es sei denn man ist kroesus und kann mit Hardware danach werfen. Ich weiß nicht, ob du da nicht etwas vergessen hast. Ich hatte immer gelernt: Entweder Schnell oder Platzsparend. also, entweder man baut ein binärformat, das klein ist, das man aber sequentiell ohne index durchsuchen muss oder man benutzt ein Relationales Modell, das Sehr hohe Zugriffszeiten hat, dafür aber sehr groß ist. durchsuch mal volltext 6 GB ohne index. das dauert zu lange. zumindest für die XAPI Terrabyte Festplatten kosten nicht mehr die Welt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständi g tot
Am 06.09.2010 09:37, schrieb Florian Lohoff: SQL DBs passen nicht wirklich schoen zu den OSM Daten. Das Problem mit der TRAPI sind die vielen kleinen files und perl als interpretersprache die nicht wirklich super fuer die bit ops ist (Ich bin sonst schon ein perl fan) Du kennst PostGis? die Geometrie-Daten werden in einem Binärformat abgespeichert. Ein eigenes DB-Schema kann man auch erstellen. Ähnlich dem von Mapnik. Datenbanken sind genau für so etwas gemacht. sie müssen nicht erst eingelesen werden, sondern haben Indzes usw. ich hab sehr gute erfahrungen gemacht. sogar für routing gibt es eine Postgis erweiterung. Selbst komplizierte GeoOperationen auf Deutschland waren in meiner VM extrem schnell trotz 1 GB Ram Server haben meist ein vielfaches. In Zukunft wird es so kommen müssen, wenn man eine Funktionierende und nutzbare XAPI haben möchte. Man braucht einfach einen kompletten Server für sowas. ein kleiner webspace reicht für die Welt nicht aus. Ich finde das Thema OSM binary file format spannend. hm da bin ich nicht so ein großer fan von, da wird die selbe Situation Entstehen wie sie jetzt existiert. Keiner kann den Code warten, es seidenn du Kommentierst extrem gut. das ist aber meiner Erfahrung nach nur bei wenigen Entwicklern die solche Sachen machen der Fall. Wichtig ist auch das der import schnell geht, so das fritzchen mueller das auch mal schnell auf seiner kiste machen kann. Das wird bei solchen datenmengen nicht passieren. das wird auch in zukunft die Webspaces sprengen. Deshalb habe ich mal mit einem parallelisierten OSM XML file reading rumgespielt d.h. beliebig viele cores dafuer zu nutzen (Wenn das bunzip single threaded ist kann man durchauf 6-8 Cores beschaeftigen). Klappt soweit ganz gut. Die frage ist nur wie man jetzt das ganze XML in eine Datenbank verbuddelt - Da habe ich erste experimente mit integer compression und string deduplication gemacht - nen bischen wie die google protocol buffers (ohne die zu kennen) bis ich dann ueber die osm binary file implementierung gestolpert bin. Cool. leider kenne ich mich in dem Gebiet noch nicht aus, sodass ich dir da nicht helfen kann.. außerdem kann es ja auch verschiedene Ansätze geben. evtl auch einen Verteiler der je nach art die Anfrage an verschidene Syteme weitergibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Als witeres KO kriterium sehe ich die Aktualität. eine XAPI sollte offt geupdated werden, aber chronejobs sind nur selten bei webhostern dabei. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 06.09.2010 11:26, schrieb Peter Wendorff: Zwei Gedanken dazu: 1) es wäre gut, wenn man eine bevorzugte Boundingbox angeben kann für den eigenen XAPI-Node. Als Hintergrund sehe ich dabei Die Server, die XAPI-ähnliche Abfragen regelmäßig selbst auf einer begrenzten BBox anfordern. das ist sehr viel verwalltungsaufwand. die Übergeordnete einheit müsste wissen, wer welche BBox abdeckt. gerade webspace ist extrem begrenzt. kann also nur wen überhaupt ein land abdecken. Man kann sehr viel verteilt implementieren. doch braucht es dafür ein gutes protokoll. ich bin für eine Lösung ähnlich der jetzigen XAPI: es gibt mehrere Server und der Verteiler verteilt die Anfragen je nach Last ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] XAPI Neubauen WAS:Re: XAPI ständig t ot
Am 03.09.2010 18:06, schrieb Sven Geggus: Wenn ich das richtig verstanden habe ist dei XAPI in einer Programmiersprache geschrieben, die außer dem Author der XAPI niemand spricht. Genau das ist das Problem. Wie wäre es die XAPI in einer modernen, für Webanwendungen geeigneten Programmiersprache neu zuschreiben. Ich hatte mir dazu noch einige Gedanken gemacht, habe aber nicht genug Zeit so etwas allein zu entwickeln. Deshalb hab ich mal ein Projekt auf Sourceforge erstellt, dem jeder gerne beitreten kann. https://sourceforge.net/projects/xapi/ Hier ein paar Sachen die geklärt werden müssen. Datenbank: Ich bin aus eigener Erfahrung für Postgres/Postgis. es ist sehr schnell auch mit großen Datenmengen Für MySQL würde sprechen, dass es von vielen Webhostern unterstützt wird. Auf normalem Webspace kann man es derzeit sowieso nicht aufbauen. man brauch mehr als 5 GB Speicherplatz. eine Boundingbox ohne spezielle Funktion dauert auf diesen Datengrößen einfach zu lange Programmiersprache: Java: für Java würde Sprechen, dass so ziemlich jeder der programmieren kann auch Java kann bzw es leicht zu erlernen und die Entwicklungsumgebungen ausgereift sind. Python für Python würde sprechen dass es von Vielen Webhostern unterstützt wird. Aber wie oben schon oben gesagt braucht man so wieso einen guten Server dafür. Hat jemand andere Vorschläge oder Argumente? immer her damit. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am 22.08.2010 13:20, schrieb Felix Hartmann: Dass kannst du nicht, solange der Fork unter CCBYSA steht. da Daten von der CC nicht abgedeckt werden, sind meine Daten nach Deutschem (EU-) Recht eigentlich garnicht oder nur für OSM lizensiert. ^^ bin gespannt was dabei rauskommt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Am 22.08.2010 20:12, schrieb 007: Ich selbst unterstütze einen Fork auf keinen Fall. Egal welchen und egal unter welcher Lizenz der läuft. Ich würde alles daran setzen das meine Daten in keinem Fork landen. Es kann nur ein Ziel geben und zwar das gemeinsam an einer freien Karte gearbeitet wird. aber das sagt ja gerade frei aus, dass es frei genutzt werden kann... auch wenn ich die Begründung für den fork ablehne, bin ich schon dafür dass forks existieren dürfen. Was würdest du machen, Kontrolle von OSM in die falschen Hände gerät? p.s.: bitte äußert mal konkrete Nachteile der ODbL die die Unbenutzbarkeit von CC aufwiegen (dass Sachen gelöscht werden müssen zählt meiner Meinung nach nicht, da CC nicht OSM schützen kann und deshalb sowieso gewechselt werden muss) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Last auf den Servern
Am 16.08.2010 00:06, schrieb Jonas Stein: Es gibt eine kleinste Einheit z.B. 1km x 1km und diese xml-Kacheln werden in einen cache gelegt. Der Transfer kann dann nach rsync manier erfolgen. Haette noch viele positive Nebeneffekte wie z.B. dass caching von WMS einfacher wuerde. hm interessante idee, aber warscheinlich würde es genau das gegenteil bedeuten... diese kacheln müssten erzeugt werden, dürfen aber nicht zu alt sein (damit du es noch bearbeiten kannst.) im moment ist es so, dass sehr selten 2 an einem teil der karte arbeiten. desshalb würde jede kachel nur für einen einzigen erzeugt werden = keine cache funktion sondern mehr arbeit für den server außerdem reicht eine kachel zum rendern nicht aus... du brauchst zb auch alle gebiete, die um diese kachel herum sind... zb das wohngebiet, dass zwar um die kachel herum ist aber keine der außenlinen diese schneidet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was is'n 'ne Eisdiele
Am 13.08.2010 16:06, schrieb Chris66: Ich denke man sollte erstmal per Bot das amenity=ice_cream durch shop=ice_cream ersetzen und die Vorlage in JOSM entsprechend ändern. hm also die meisten Eisdiele gleichen mehr einem Cafe als einem einfachen shop... sollte allerdings der Eisverkauf das einzige sein was der 'Laden' anbietet kann ich mir shop auch gut vorstellen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäume in Girona
Am 6. Juli 2010 16:36 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Übrigens: jeder Baum ist einzigartig ;-) ich verweise noch mal auf den früheren grundsatz für osm: relevant ist das was dem Ersteller wichtig ist ich weiß nicht, ob der immer noch gilt. (wär schade drum, siehe Wikipedia) der grundsatz meinte (so wurde es mir 2007 erklärt) wenn dir wichtig ist, die Kanaldeckel Einzutragen, weil du zb von der stadtreinigung bist und das für deine Anwendung brauchst, dann ist es Relevant für osm. (oder auch Hydranten für die Feuerwehr) Also: wenn jemandem Bäume wichtig sind, und sie einträgt, sind sie relevant. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum ist die Mercator Projektion für OSM vorteilhaft?
ich weiß nicht ob die Gauß-krüger noch etwas sagt, das wurde (wird teilweise immer noch) von den Deutschenvermessungsämtern benutzt der vorteil ist, dass es Winkel echt ist ( für vermessung sehr wichtig) der nachteil: es funktionier fast nur in deutschen breitengraden WGS84 ist weltweit relativ genau hat aber den nachteil, dass die koordinaten (wenn man long und lat in ein kartesisches koordinaten system sperrt ;)) garnicht winkel genau sind außerdem kommt so ein Ei heraus wenn man es ausrollt der vorteil von merkator ist tatsächlich, dass es Relativ winkel echt ist, dafür aber nicht wirklich flächenecht. es wird vereinfacht WGS genommen und der (90-Epsilon).° genommen und auf die Länge des Äuqators gestreckt. wie oben geschildert ist die Winkelechtheit für die vermessung sehr wichtig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum ist die Mercator Projektion für OSM vorteilhaft?
On 13.07.2010 01:56, Dirk-Lüder Kreie wrote: Nicht nur Winkelechtheit, auch das Niveau muss stimmen, was WGS84 ebenfalls nicht hinreichend genau liefert. Das ist aber auch eher ein Grund dafür, dass OSM die dritte Dimension vernachlässigt, als für die Projektion relevant. stimmt, aber heir ging es ja glaub ich um josm, welches ja sowieso nur 2+1 Dimensionen hat (3. dimension als attribut relativ zum objekt) kennst du einen elypsoid, der besser auf die erde passt? für OSM muss er ja für die ganze welt passen. mir fällt grad keiner ein... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
On 12.06.2010 10:59, Frederik Ramm wrote: Im allgemeinen ist die Faustregel hi Frederik, (und alle anderen;)) wie ist es mit der neuen lizenz? im wiki habe ich dazu nichts gefunden... generell wurde doch gesagt dass sich um großen und ganzen nichts ändern wird... ist das korrekt? Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
On 15.06.2010 09:07, Frederik Ramm wrote: Das Wiki hat ungefaehr 40 Seiten zur neuen Lizenz: http://wiki.openstreetmap.org/wiki/Category:Open_Data_Licence diese sind aber so unübersichtlich, dass kaum ein normaler Mensch sie versteht CC war da übersichtlicher... Kuenftig: Deine Verkehrsdichte-Daten muessen ODbL sein, nach dem PNG kraeht kein Hahn. Das gilt nicht nur für Veröffentlichungen sondern auch für interne Prozesse (zb Vergleiche), oder? dh man kann auch keine OSM Daten mit andern Daten vergleichen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
On 15.06.2010 11:25, Frederik Ramm wrote: Ich glaube uebrigens, dass das auch schon von Navteq-Seite aus schwierig ist, zumindest weiss ich, dass man Navteq und TeleAtlas nicht mergen darf - ob das jetzt an den Lizenzbestimmungen von Navteq oder denen von TeleAtlas liegt, weiss ich nicht. wie macht das dann google? die benutzen ja schließlich auch verschiedene anbieter... hm sehe grad, navteq hab ich noch nicht gefunden... aber alte pakannte wie Tele Atlas und AND sind auch dabei ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kamerabilder auswerten
ich hab mal bei der uni tübingen angefragt, da gabs mal ein projekt dazu: [1] er der (dort angegebene) verantwortliche erklährt sich bereit, wenn bei uns konkrete Planungen zu einem projekt bestehen, auch mit sourcecode zu helfen, macht aber darauf aufmerksam, dass nur mit Beispielbildern getestet wurde. außerdem gibt er folgenden Tipp: Sehr häufig werden SVMs (Support Vector Machines) für Verkehrszeichenerkennung eingesetzt, such mal nach svm traffic sign recognition alles gute josias [1] https://cis.informatik.uni-tuebingen.de/se-ss-09/downloads/fileid=1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kamerabilder auswerten
es reicht ja alle 2-5 sec ein bild zu machen... für bilder gibt es ja diverse programme ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kamerabilder auswerten
ich hatte schon öfters darüber nachgedacht.. was eigentlich das wichtigste wäre: erkennung von verkehrschildern. dafür gibt es software... leider hab ich bisher nur teuer software gefunden, oder konzepte, wie so was gemacht wird... aber nie fertige, nutzbare programme... so schwer dürfte das eigentlich nicht sein, schließlich gibt es genug diplom arbeiten über das erkennen von formen in bildern alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Icon-Bastler
On 10.02.2010 16:00, Jan Tappenbeck wrote: http://wiki.openstreetmap.org/wiki/Image:Kiosk.png ist repariert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Icon-Bastler
On 08.02.2010 12:00, Jan Tappenbeck wrote: * Zeitung-Office. ist zwar ein kiosk, die zeitung daraus kann aber gerne extrahiert werden: http://wiki.openstreetmap.org/wiki/Image:Kiosk.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Lizenz und abgezeichnete Daten
im Deutschen recht gibt es übrigens eine verhältnismäßigkeitsklausel. dh das Gericht muss abwägen ob bestimmte Maßnamen dem Beklagten überhaupt zugemutet werden können.(siehe zb foren-haftung) Ich denke das ist abzuwägen, in wie weit Waten die importiert und anschließend verändert wurden zu behandeln sind. ich zumindest kenne kein Urteil dazu On 13.01.2010 22:11, Roland Ramthun wrote: Am Mittwoch, den 13.01.2010, 21:02 +0100 schrieb Thomas Ineichen: Hallo zusammen, Ich habe eine Frage zu folgendem Beispiel: Firma F übergibt OSM Luftbilder nach der alten Lizenz. Mapper M zeichnet ein paar der Wege ab. F möchte aber die Bilder nicht nach der neuen Lizenz freigeben. Die Bilder kann man vermutlich nicht unter ODbL stellen, das ist ja eine Datenbank-Lizenz :-) Unter CC-BY-SA standen die vorher vermutlich auch nicht. M möchte hingegen möchte gerne der neuen Lizenz zustimmen. Darf er das? Muss er erst die abgezeichneten Daten löschen? Was, wenn er selber nicht mehr genau weiss, welche Strassen er abgezeichnet hat? Die Nutzung der Bilder kann der Rechteinhaber jederzeit untersagen, die alte Vereinbarung gilt dann aber weiterhin, bis zum Termin der Untersagung. Falls in der Vereinbarung steht, dass die aus den Bildern abgeleiteten Daten nur unter CC-BY-SA stehen dürfen, müsste man wohl löschen, ist der Fall nicht explizit geregelt, weiß ich es nicht, würde aber vermuten, dass man die Daten behalten kann. Es kommt also wohl eher auf den ganz konkreten Vertrag für die Nutzung der Luftbilder an. Grüße Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzregeln für OpenStreetMap?
Peter Körner schrieb: Kann Dir http://www.openstreetmap.org/user/username/edits da nicht helfen? Nicht wenn er den nutzer *sucht* :) er kann erst mal seinen namen eingeben. anschließend sucht er nach der sitzung in der er den knoten editiert hat, anschließend sucht er den konoten und wer ihn gelöscht hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] sich auf OSM Straßen in 3D bewegen?
es gab mal ein post in dem beschrieben wurde, was du dir vorstellst. das war irgend eine bekannte spiele engine... an einen weiteren post erinnere ich mich, in dem der import nach blender beschrieben wurde... alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Jan Tappenbeck schrieb: und dann davor amenity=xmas nein, gar nichts... wozu braucht man das? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bald ist Weihnachten - Bäume und Mär kte
Johann H. Addicks schrieb: und dann davor amenity=xmas wozu braucht man das? Damit man schon im September schauen kann, wo man mit etwas Glück gleich Mitte Oktober einen Weihnachtsbaum kaufen kann nein ich meinte ausschließlich das amenity... das xmas steht doch schon im key. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Mirko Küster schrieb: Weil es keine einzige Anwendung auswertet und dieser Node komplett tot in der DB gammelt. na danke... zb Osmolt in der kommenden Verison kann das... hab mir solche mühe gegeben ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Karl Eichwalder schrieb: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: shop_list=bicycle;xxx etc. ausserdem, wie willst sowas sonst mappen? zwei pois fuer einen laden?!? Genau so. Warum denn nicht? Falls notwendig, tust du dann beide wieder in eine relation, wie man das beispielsweise mit strassenschnipseln auch machen sollte. das funktioniert bei Restaurants aber nicht die art der küche wird über den cuisine tag festgelegt. wie willst du dann einen china-mann der sowohl chinesisch als auch taiwanesisch kocht taggen? meist macht er es in der selben Küche. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. wenn OSM weiter so rasant wächst, wächst auch die Wartezeit exponentiell. Leseoperationen koennen durchaus etwas zeitverzoegert von Mirrors kommen. Ein Editor koennte Dir den (schnell zugreifbaren, aber 2 Minuten verzoegerten) Datenstand vom Mirror anzeigen, sobald Du aber eine Aenderung machst, koennte er schnell pruefen, ob das Objekt wirklich noch auf dem zentralen Server unveraendert ist und anderenfalls sagen: Sorry, das Objekt hat gerade eben schon jemand anders geaendert. Sowas kann einem ja auch bei Wikis usw. passieren, die Sache wuerde dadurch nicht unbenutzbar. das kann einem auch jetzt schon passieren. aber das kann nur eine Zwischen-Lösung sein Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem lösen können bevor die Wartezeiten so groß werden, dass keiner mehr Lust hat bei OSM mitzumachen Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Hallo, Josias Polchau wrote: Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. das sehe ich nicht so. ich hab zwar nur etwas Erfahrung bei großen Datenbanken, aber wir werden, schätze ich, in einem Jahr nicht umhin kommen die live-Datenbank-Last auf mehrere Server zu verteilen. Die Schreib-Last ist doch aber nur ein Bruchteil von der Lese-Last. Wenn unsere Tools die Leseoperationen besser trennen - auch JOSM koennte doch problemlos von einem leicht verzoegerten nur-Lese-Mirror lesen statt von der Zentrale - dann kann die zentrale Datenbank die Schreiblast noch eine ganze Weile aushalten. wenn ich es richtig verstanden hab geht es also um das schnelle Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? also eine Weiterentwicklung der XAPI? die XAPI wurde von 80n entwickelt Xapi source code uses GT.M a high-performance schemaless database. warum wurde keine geo DB genommen? damit schneller logische Operationen ausgeführt werden können? http://xapi.openstreetmap.org/scripts/ anscheinend ist es in Pascal geschrieben (hatte das eigentlich anders in Erinnerung) letztendlich ist die Programmiersprache ja egal, wenn entsprechend gute DB abfragen gestellt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Hallo, Josias Polchau wrote: wenn ich es richtig verstanden hab geht es also um das schnelle Ausliefern von Informationen, die sehr klar eingegrenzt werden können, oder? Ja. Erschwerend kommt hinzu, dass wir fuer sehr viele Anwendungen diese Informationen im topologisch sauberen OSM-Modell ausliefern wollen und *nicht* in Form von Standardgeometrien. Das heisst, wir wollen schoen ordentlich alle betroffenen Nodes, Ways und Relations haben und nicht einfach eine in die Landschaft gezeichnete Linie. Auf letzteres sind die einschlaegigen Geodatenbanken aber in der Regel spezialisiert. In der API sieht eine typische gib mir alles in diesem Bereich-Anfrage so aus: [..] das ist die geo-Herangehensweise. eine weitere nötige Operation ist das Finden aller Knoten mit dem Tag XY und natürlich auch anders herum Wenn sowohl das Gebiet (ist ja meist der fall) als auch die tags eingeschränkt sind müsste das Programm so intelligent sein, heraus zu finden, welches der beiden die Auswahl am meisten einschränkt... also zb bei den Babyklappen in Deutschland sollte das prog natürlich erst mal alle Babyklappen suchen und erst später regional einschränken. http://osm.youseeus.de/osmolt/babyklappe/deutschland/ Bei Straßen würde man natürlich zuerst nach Gebiet einschränken. Insgesamt ist das halt eine nicht ganz primitive Operation. also eine Weiterentwicklung der XAPI? Oder eine Weiterentwicklung der API, koennte man genauso sagen. die XAPI wurde von 80n entwickelt Xapi source code uses GT.M a high-performance schemaless database. warum wurde keine geo DB genommen? Erstens ist eine geo DB nicht unbedingt besser (s.o.), zweitens gilt bei OSM ja wer das Programm schreibt, darf entscheiden, und 80n hat sich fuer M entschieden, eine Datenbankprogrammiersprache aus dem medizinischen Bereich, die deutlich aelter als SQL ist. älter ist ja nicht immer besser (bei Informatik eher andersrum ^^) Die Programmiersprache ist dann egal, wenn genuegend Leute die gewaehlte Sprache gut beherrschen *oder* der Programmierer auf absehbare Zeit willens und in der Lage ist, jede Anpassung und sonstige Arbeit am Code selbst vorzunehmen. MUMPS ist ja wirklich schwer zu lesen, und ich weiß nicht, ob sich wirklich später jemand findet den code zu warten. ^^ Beim XAPI haben wir zum Beispiel genau das Problem - es gibt Engpaesse, aber es gibt auf der ganzen Welt nur eine Person, die sich mit dem Einsatz der Programmiersprache M speziell fuer OSM-Daten beschaeftigt hat. Das ist knapp. ich würd ja Java vorschlagen, weil ich das sehr gut kann, und C++ nicht wirklich mag Skripsprachen scheinen mir nicht effizient genug (ich weiß Java auch nicht.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Irgendwas läuft schief in der POI-Welt !
Jan Jesse schrieb: Hallo allerseits, ich werfe mal in die Debatte, daß wir seit ca. 3 Monaten unsere zugegeben spezielle POI-DB stabil (natürlich aber nicht perfekt) am Netz haben. (Link unten) Die wichtigsten Features sind in etwa wie folgt zu beschreiben: [..] das hört sich ja viel versprechend an... ich würde gerne mehr darüber erfahren... weil genau das ist es, was ich seit einem jahr suche... diese Software zu erweitern währe natürlich cool und ich würde wo ich kann dabei gerne mithelfen. alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Frederik Ramm schrieb: Tirkon wrote: Ist dabei auch an eine Konfigurierbarkeit der Karte gedacht, so dass sich ähnlich wie beim Openstreetbrowser bestimmte Gruppen von Objekten ein- und ausblenden lassen? Grundsaetzlich nicht schlecht, vielleicht haben die Macher des OpenStreetBrowsers ja Lust, sich einzubringen. Das ist auch mein Traum (weshalb ich Osmolt begonnen habe.) letzt endlich müsste man die macher von OpenStreetBrowsers, Freietonne (die ja auch Hilfe dabei angeboten haben) und andere, die sich mit diesem Thema beschäftigen zusammen bringen.. alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
hallo Frederik, wenn ich einen Wunsch äußern dürfte: ich hätte gerne einen schnellen XAPI-Server. nicht jeder ist in der Lage auf seinem Webspace eine OSM-Datenbank im Hintergrund einzurichten, möchte aber trotzdem on-the-fly daten anzeigen will. ich löse es derzeit so, dass ich einmal die daten von XAPI herunterlade und statisch abspeichere, aber so wirklich zufrieden bin ich nicht. derzeit dauert es ca 1-3 min bis eine Antwort von der XAPI kommt. ist nur ein Wunsch, und evtl nur meiner (ich weiß nicht wie viele Anwendungen auf die xapi zugreifen). alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Sven Anders schrieb: Als Alternative könnte ich mir eher Vorstellen: * das du einen Projektantrag ausfüllst und dann (nach Genehmigung) * auf dem -Server dein Tool einrichtest * und es so umstrickst das es eine Datenbank benutzt, die dann für mehere Tools automatisch aus einem Planet aktualisiert wird. evtl kennen inzwischen einige Osmolt. - einfache POI-Kartenerstellung mittels Steuerdatei (so nach dem motto: amenity=fast_food aber nicht cuisine=kebab = alle fastfood-restaurantes die keine dönerbuden sind, wenn man auf ein POI draufklickt, werden Zusatzinformationen wie öffnungszeiten angezeigt (mittels Openlayers)) (Beispiel siehe unten) und ich würde gerne so etwas als webservice anbieten. kenne mich mich aber vor allem im Java-Segment aus. allein trau ich mir das nicht zu. Hat jemand Lust bei so etwas mit zu helfen? gerade wo ein POI-Editor angedacht wird, wäre ein Service der individuelle POI-Karten-Erstellt doch super. Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Döner - Ebbe in Hamburg und Berlin
Chris-Hein Lunkhusen schrieb: Hi das schreibt man auch kebap. laut http://wiki.openstreetmap.org/wiki/Key:cuisine schreibt man es kebab. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Döner - Ebbe in Hamburg und Berlin
hab ich da was falsch gesehen? in vielen Deutschen Städten sind Döner-Imbisse kaum eingezeichnet ich hab mal auf folgendes getestet: amenity=restaurant cuisine=kebab oder amenity=fast_food cuisine=kebab http://osm.youseeus.de/osmolt/doener/ mehrere Angaben bei cuisine kann osmolt (noch) nicht verarbeiten... wird aber bald implementiert sein (wenn ich zeit finde) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung von Turn Restrictions?
hier gab es mal sowas, scheint aber derzeit nicht zu funktionieren: http://osm.virtuelle-loipe.de/restrictions/ sb-lis...@gmx-topmail.de schrieb: Hallo, ich habe eine kurze Frage, die ich mir nicht über eine Google Suche oder Suche im OSM-Wiki beantworten konnte. Ich suche eine OSM-Karte, auf der bisher eingepflegten Turn Restrictions visualisiert sind. Ich weiß, dass man Turn Restrictions in JOSM bereits sehen kann. Es wäre für mich allerdings praktisch, wenn ich mit einem schnellen Blick auf einer Karte erkennen könnte, wo noch Gebiete ohne Turn Restriction sich befinden. Das kann Ansporn sein, in solche Gegenden zu fahren um diese Informationen zu erheben - sollten sie noch nicht vorhanden sein. Meine Frage: Gibt es eine solche Visualisierung bereits? :-) Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visualisierung von Turn Restrictions?
Tobias Wendorff schrieb: Josias Polchau schrieb: hier gab es mal sowas, scheint aber derzeit nicht zu funktionieren: http://osm.virtuelle-loipe.de/restrictions/ Gibt es einen Screenshot, wie das funktionierend aussieht? Screenshot,hab ich leider keinen, aber damals waren da dann Straßenschilder am Wegrand liegend etwa http://wiki.openstreetmap.org/images/e/e0/No_right_turn_a.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nextbike - Position automatisch in OSM
ich hab für hamburg mal so was gemacht... nur live ist da nichts... http://osm.youseeus.de/osmolt/bicycle_rental/hamburg/ alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern im JOSM-Stil
Sven Geggus schrieb: Nun ja, es gibt ja schon Stellen an denen man bewußt solche solche Verbindungen zwischen landuse und Straße macht. z.B. bei Eingangstoren: http://www.openstreetmap.org/browse/node/443793951 physikalisch ist das tor nur mit der straße und dem evtl vorhandenen Zaun verbunden. Landuse ist eine nicht-physikalische interpretation/zusammenfassung von mehreren Objekten... andererseits: bei osm ist es teilweise üblich zaun und landuse auf einen knoten zu packen... aber eine geschnittenes landuse (ohne zb zaun) braucht meinermeinung nach keinen knoten, da auch keine eche verbindung besteht... jm2c Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Friedhelm Schmidt schrieb: Wenn ein Müllcontainer eine amenity ist, dann ist es eine Wasserzapfstelle auch. Alosmein Vorschlag: amenity = water_tap. wir sollten uns nicht so an amenity fest klammern. das tolle bei osm ist ja, dass auf beiden Seiten (x=y) was steht und man so Kategorien festlegen kann. wenn wir alles mit amenity taggen, dann können wir diese Kategorisierung auch gleich weg lassen. Anstatt immer gleich nach amenity zu schreien, sollten wir unser Köpfchen mal bisschen anstrengen und uns eine gute Oberkategorie ausdenken. Mut für was etwas Neues Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Friedhelm Schmidt schrieb: Wenn ein Müllcontainer eine amenity ist, dann ist es eine Wasserzapfstelle auch. Alosmein Vorschlag: amenity = water_tap. Josias Polchau schrieb: Anstatt immer gleich nach amenity zu schreien, sollten wir unser Köpfchen mal bisschen anstrengen und uns eine gute Oberkategorie ausdenken. eventuell könnte man ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Tobias Knerr schrieb: Ich finde ja, in einem Top-Level-Tag sollte so wenig Information wie möglich stecken, weil manch einer die Detailinformation vielleicht nicht erfassen kann/will. Deshalb halte ich drinking_water für unglücklich gewählt. (Oder lässt sich immer eindeutig und ohne Zusatzaufwand feststellen, ob es sich um Trinkwasser handelt oder nicht? In diesem Fall wäre die Unterscheidung im Top-Level-Tag natürlich sinnvoll.) wieso nicht einfach water=tap oder water=pump water=hand_pump ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Martin Koppenhoefer schrieb: z.B. weil amenity=drinking_water schon 4480 mal in Europa verwendet wird und div. Anwendungen es unterstützen? wie von den Vorposteren dargelegt, bringt das einem wenig, wenn man nicht trinkbares Wasser taggen will. amenity wenn wir weiterhin so viel amenity benutzen können wir es gleich in POI umbenennen. eine andere bedeutung hat es in der OSM welt nämlich nicht mehr, und dann können wir es eigentlich gleich weglassen. weil es eine redundante Information ist. POI ist jeder Punkt, da er, wenn er nicht interessant wäre, nicht eingetragen worden wäre. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäche, wie zu taggen
Lothar Emmerich schrieb: * Muss jeder Bach eingetragen werden? Es gibt Rinnsale, die nur bei starkem Regen Wasser führen. am anfang meiner OSM zeit wurde mir das so erklärt: wichtig ist was für den einzelnen wichtig ist. Wenn du meinst, dass sie unbedingt drin sein sollen, dann zeichne sie ein. es gibt kein Muss oder Verbot ach so, doch, es sollte mindestens 2 Wochen am selben Fleck stehen. das war vor 2 Jahren, den aktuellen Stand weiß ich nicht genau. alles Gute Josias PS: bitte kein HTML in mailinglisten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Mirko Küster schrieb: Solche Schächte mit Hauswasserwerk oder auch Handschwengelpumpe auf der Parzelle würde ich entsprechend mit eigenem Tag abgrenzen und für Spezialkarten vorbehalten. Das ist sowieso Privat oder Pachtgelände und nicht zugänglich. Das ist was anderes wie zentrale oder öffentliche Entnahmestellen. Karten die normale Brunnen und dergleichen rendern würden Schreberanlagen sonst förmlich unter Brunnen begraben. In der Richtung müsste sowieso noch einiges getan werden. Für Tiefbrunnen, Wasserwirtschaftliche Anlagen, Wasserschutzzonen usw. haben wir noch nichts. hm welche Oberbegriff könnte man denn da nehmen? 'water=?' ist mir zu allgemein, kann aber auch passen. im deutschen würde man evtl Wasserbewirtschaftung sagen, im englischen klingt das nicht so schön 'water resources management' oder 'management of waters' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
ich hab es brunnen genannt also fountain laut leo heißt das auch Zapfstelle Jan Tappenbeck schrieb: es gibt Trinkwasser-Definitionen (http://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddrinking_water) aber für nicht Trinkwasser-Zapfstellen (z.B. Handpumpe im Schrebergarten) habe ich nichts gefunden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Martin Koppenhoefer schrieb: ich halte das für weniger geeignet, da es schon einen erheblich Unterschied gibt zwischen einer Handpumpe im Schrebergarten oder auf dem Friedhof, und einer repräsentativen Fontaine, oder einem skulpturalen Brunnen. Achtung, es gibt einen Unterschied zwischen fountain[en] und Fontäne[de]. Das eine ist generell eine Wasserquelle das andere eher eine Verbesserungsmaßnahme in Form eines Wasserausstoßes. wenn du Leo nicht vertraust, kannst du ja mal einen Muttersprachler fragen. übrigens ein Brunnen ist eigentlich genau dass was Jan sucht, nämlich eine Wasserentnahmestelle. und fountain im ursprünglichen Sinne ist eine Flussquelle. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Martin Koppenhoefer schrieb: klar kann man immer noch feiner durch Sub-tags differenzieren, aber das Taggen einer Handpumpe im Schrebergarten als Brunnen (weil LEO an letzter Stelle neben Brunnen, Fontaine, Ursprung, Wasserspiel und Wasserstand auch Zapfstelle als mögliche Bedeutung erwähnt) wäre m.E. fast so wie eine Fußgängerzone als Autobahn zu taggen und dann durch Zusatztags klarzustellen, dass es doch eine Fußgängerzone ist. hm evtuell könnte man leisure=watersource nehmen leisure, da es hier am besten passt (zb slipway) und es auf keinen fall eine Annehmlichkeit ist... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sportanlage - wie taggen
Martin Koppenhoefer schrieb: m.e. entweder sport=multisport oder sport=hockey;tennis war das nicht sport=multi statt sport=multisport ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [list-split] aufteilen der Mailingliste
ich möchte vorschlagen die Mailingliste zu splitten ich habe in den letzten 2 tagen 400 neue Beiträge in 28 neuen Themen bekommen. Selbst mit einem newsreader ist das sehr viel zu lesen. deshalb möchte vorschlagen, die mailingliste zu splitten. mir ist bisher kein Grund eingefallen, warum man das nicht machen sollte. die liste .de würde weiterhin existieren aber nur noch für Ankündigungen und die Bekanntmachung der Ergebnisse von Diskussionen genutzt werden, die wirklich alle interessieren. als unter listen würde zb folgende listen namen/themen in Frage kommen: tagging : wie tagge ich was proposals : Vorschläge für neue Tags application : Diskussionen über die Programme im Dunstkreis von OSM talk: alles andere man könnte sie noch etwas anders nennen oder aufteilen um die Diskussion darüber etwas zu strukturieren werde ich 2 mal hier auf antworten. bitte schreibt doch eure diskussions beiträge in die jeweiligen diskussions bäume: für die diskussion über die namen der listen: [list-split: names] für die diskussion über muss das überhaupt sein?: [list-split: generell] das ist eine Bitte mehr nicht. alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [list-split: generell] Diskussion über muss das überhaupt sein? was Re: [list-split] aufteilen der Mailingliste
um die Diskussion darüber etwas zu strukturieren werde ich 2 mal hier auf antworten. bitte schreibt doch eure diskussions beiträge in die jeweiligen diskussions bäume: für die diskussion über muss das überhaupt sein?: [list-split: generell] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [list-split: names] diskussion über die namen der listen was: [list-split] au fteilen der Mailingliste
um die Diskussion darüber etwas zu strukturieren werde ich 2 mal hier auf antworten. bitte schreibt doch eure diskussions beiträge in die jeweiligen diskussions bäume: für die diskussion über die namen der listen: [list-split: names] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [list-split] aufteilen der Mailingliste
Bernd Wurst schrieb: Hallo Josias. Willkommen auf einer High-Traffic-Mailingliste. Man lernt durch das Abonnement solcher Listen das Feature ignore thread zu benutzen und zu lieben. Am Donnerstag, 28. August 2008 schrieb Josias Polchau: deshalb möchte vorschlagen, die mailingliste zu splitten. Dieser Vorschlag kommt alle paar Wochen. Nein, taugt nicht. und warum nicht? mir ist bisher kein Grund eingefallen, warum man das nicht machen sollte. die liste .de würde weiterhin existieren aber nur noch für Ankündigungen und die Bekanntmachung der Ergebnisse von Diskussionen genutzt werden, die wirklich alle interessieren. Hast du jemanden, der zuverlässig so nen Sklavenjob macht? Die meisten Diskussions-Ergebnisse schaffen es ja noch nicht mal auf eine Wiki-Seite, wie sollen die denn dann auf eine announcement-Liste kommen? tja... wer möchte, das das was er sich ausgedacht hat, auch benutzt wird, der macht das, für alles andere hab ich einfach keine zeit... wenn ich neben der Arbeit und dem Studium auch noch bisschen Mappen will... als unter listen würde zb folgende listen namen/themen in Frage kommen: tagging : wie tagge ich was proposals : Vorschläge für neue Tags application : Diskussionen über die Programme im Dunstkreis von OSM talk: alles andere Wo hört ein Thema auf und wo fängt talk an? Eine tagging-Diskussion endet doch oft genug bei proposals. Eine whatever-Diskussion kann schnell zu einer application-Diskussion werden. Das Ergebnis wären unglaublich viele Off-Topic-Mails oder unuzsammenhängende Cross-Posts. Jeder muss dann auf allen Mailinglisten subscribed sein um die Zusammenhänge zu verstehen. wenn man einen Vorschlag macht, der sich auf tags beziht, sowas kommt in proposals, anschließend sagt mal in der alten diskussion das es in proposals so etwas gibt... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [list-split] aufteilen der Mailingliste
Martin Koppenhoefer schrieb: tagging und proposals sind m.E. die gleiche Rubrik. application koennte man evtl. chat-app-de nennen, es gibt ja schon JOSM-dev und Dev kann man machen... aber vor allem Find ich wichtig, dass es mal gemacht wird... es wurde schon öfters vorgeschlagen, aber irgend wie ist die diskussion immer im sande verlaufen, weil ein paar gemeckert haben, aber als ich mich etwas umgehört habe, bin ich fast nur auf Leute gestoßen, die das splitten befürworten. Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS: Von Italien nach Dänemark .. .
ein weiterer vorschlag: die oberfläche etwas aufräumen also einen button (noch besser einen textlink), der die erweiterten suchoptionen erscheinen lässt. so wird das ganze übersichtlicher. ag Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fährverbindungen als Teil der normale n Straße
Garry schrieb: Und ausserdem ist das in Rendsburg ja eigentlich gar keine Fähre sondern eine Schwebebahn - hängt unter der Eisenbahnbrücke :-) in Rendsburg und Umgebung gibt es so weit ich mich erinnern kann mehrere Fähren... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] java Programm zum Parsen von PIOs für Openlayer.text
Josias Polchau schrieb: bekannte bugs: die Umrechnung in die Mercator Projektion ist nicht ganz korrekt. wenn jemand erfahrung damit hat, währe es schön, wenn er helfen könnte die Mercator Projektion ist jetzt auch korrekt. \o/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] java Programm zum Parsen von PIOs für Openlayer.text
moin ich hab ein java Programm geschrieben, das in einer OSM-XML Datei nach bestimmten Tags suchen kann, und diese dann in das Openlayer.Layer.text-format bring. https://sourceforge.net/projects/osmparse/ beispiele: http://josias.polchau.de/datei/osm/?zoom=11lat=53.57041lon=9.88104layers=B0 http://josias.polchau.de/datei/osm/shop.html wenn jemand das Programm benutzen will und die Bedienung nicht versteh, kann er gerne fragen... bekannte bugs: die Umrechnung in die Mercator Projektion ist nicht ganz korrekt. wenn jemand erfahrung damit hat, währe es schön, wenn er helfen könnte ich bin natürlich für jeden hinweis dankbar, auch im bezug auf andere bugs alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] java Programm zum Parsen von PIOs für Openlayer.text
hi Tobias Tobias Wendorff schrieb: bekannte bugs: die Umrechnung in die Mercator Projektion ist nicht ganz korrekt. wenn jemand erfahrung damit hat, währe es schön, wenn er helfen könnte Ich habe ähnliche Probleme und führe meine Berechnungen daher in WGS84 durch (meine Daten liegen als WGS84 vor). ich kenne mich leider nicht wirklich damit aus aber so viel ich weiß kann Openlayers nur mercator Benutzt OSM denn den normalen Mercator oder die neue Variante: Spherical/Web Mercator: EPSG:3785 osm benutzt so viel ich weiß gant normal Längen und Breitengrad leider kenne ich mich damit auch nicht so gut aus, sonnst hätte ich admit ja auch nicht so ein problem ich bin natürlich für jeden hinweis dankbar, auch im bezug auf andere bugs Werde ich mir mal angucken! danke Grüße Tobias alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fährverbindungen als Teil der normale n Straße
Bernd Wurst schrieb: Hallo. Ich als süddeutsches Landei wusste gar nicht, dass es sowas überhaupt gibt, aber ich weiß jetzt gleich nicht wie ich das taggen soll. ;-) Also, bin grade im Urlaub in Rendsburg und da gibt es über den Nord-Ostsee- Kanal zwei Fähren, die vollständig Teil der Verkehrs-Infrastruktur sind. Kostenlos zu benutzen, nicht anmeldepflichtig oder sonstwas, wenn man von A nach B will, der Kanal dazwischen ist, dann fährt man auf die Fähre, die bringt einen rüber und gut. das ist historisch bedingt, der Kanal wurde zu Kaiser Wilhelms Zeiten gebaut. in Norddeutschland hatten die Bauern traditionell viel Land (da das Land nicht unter den söhnen aufgeteilt wurde) deshalb wurden teilweise Bauern von ihren Feldern abgeschnitten. aus diesem Grund wurden die Kanalfähren eingeführt und den Bauern zugesichert, dass sie kostenlos bleiben, was bis heute der Fall ist. so hab ich das jedenfalls gehört ;) alle gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur Diskussion zum BGH, I ZR 81/96
Florian Heer schrieb: Hmm... OSM ist aber als Datenbank nicht ein Werk mit einem Urheber, sondern eine Sammlung von Daten, deren Einzelurheber ihre Daten unter CC freigegeben haben... Nur so als Gedanke, keine Ahnung, ob das einen Unterschied dabei macht. Definition Datenbankwerk nach §4 Abs.1 UrhG: Sammlungen von Werken, Daten oder anderen unabhängigen Elementen, die aufgrund der Auswahl oder Anordnung der Elemente eine persönliche geistige Schöpfung sind (Sammelwerke), werden, unbeschadet eines an den einzelnen Elementen gegebenenfalls bestehenden Urheberrechts oder verwandten Schutzrechts, wie selbständige Werke geschützt. (§4 Abs.1 UrhG ) = mit Werk ist das ganze also die gesamte Datenbank gemeint, und es wird explizit gesagt, dass nicht das einzelne gemeint ist. alles gute josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur Diskussion zum BGH, I ZR 81/96
Florian Heer schrieb: Wenn sich herausstellen /sollte/, dass die deutsche Rechtsauffassung zu den Kartendaten einem internationalen Konsens entspricht, also das Urheberrecht hier gar nicht zur Anwedung kommen kann, dann nur zu, ansonsten gefährden wir die internationale Nutzung von OSM. Sollte sich das allerdings herausstellen, dann ist auch meiner Meinung nach eine Lizensierung von OSM-Daten unter CCBYSA hinfällig, dann sind Kartendaten nämlich vogelfreies Allgemeingut. das ist nicht korrekt... denn OSM ist eine Datenbank, und ist laut Urheberrecht im ganzen geschützt: §§ 4 Abs.2 und 87a ff. UrhG dh teile darf man kopieren aber das ganze nicht (auch nicht in großen teilen) was wiederum heißt die datenbank, die hinter googlemaps steht darf man zum vergleichen in einzelnen Fällen benutzen, ganze streßenzüge aber nicht. sage ich als ein Inormatikstudent der grad Medienrecht belegt hat keine garantie, dass das auch wirklich so ist... alles gute josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Brainstorming zum OpenRouteService
Bernd Wurst schrieb: Nein. Bei allen gut ausgebauten Straßen (primary, trunk, motorway) würde ich im routing-Service einen Straßennamen-Wechsel ignorieren. ich denke das sollte vor allem getan werden, wenn man noch weit vom Ziel entfernt ist ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] private Straßen im Osmarender
moin ich habe (testweise) mal ein paar private Wege eingezeichnet: http://informationfreeway.org/?lat=53.5778917848606lon=9.712452546108976zoom=17layers=B000F000F doch der Osmarender stellt das m.E. viel zu prominent da, um es dann wieder durch zu streichen, wodurch das ganze noch viel auffälliger wird. außerdem wird auch noch die Straße, die gar kein 'prvate' ist durchtrennt. alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] private Straßen im Osmarender
Tobias Wendorff schrieb: Meinst Du die gelben Wege vor den Häusern oder die grünen Wege, z.B. nördlich der Geschwister-Scholl-Straße? ich meinte kleinen Straßen die so mit dünnen roten Linien durchgestrichen sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] private Straßen im Osmarender
Bernd Wurst schrieb: Hallo. Am Montag, 14. Juli 2008 schrieb Josias Polchau: doch der Osmarender stellt das m.E. viel zu prominent da, um es dann wieder durch zu streichen, wodurch das ganze noch viel auffälliger wird. Osmarender sollte primär als Werkzeug für Mapper angesehen werden um ihre eingegebenen Daten zu prüfen. Die Karten sind i.A. nicht so schön wie z.B. die Mapnik-Karten, dafür wird aber viel mehr Information darin visualisiert. das ist jetzt wieder ein Glaubenskrieg: ich find Osmarender hat die schöneren Farben Die Info, ob eine Straße privat ist oder nicht, ist für Routen-Planer sehr wichtig, aber für Karten-Betrachter meist nicht besonders wichtig. Die Darstellung macht generell Sinn, dass man sich Dinge wie zweite Straße rechts veranschaulichen kann. Denn in der Realität würde man da Privatstraßen wohl mitzählen. dann sollte man die Straßen eher gräulich machen und (Bloße Einfahrten, die man subjektiv gesehen nicht mitzählen würde, würde ich vermutlich gar nicht mappen.) die Einfahrten sind meist so 15 Meter lang außerdem wird auch noch die Straße, die gar kein 'prvate' ist durchtrennt. Das ist ein Darstellungsfehler der für oben genannte Haupt-Anwendung für Osmarender nicht ganz tragisch ist. Ich denke auch, dass aus diesem Grund noch keiner das Problem gesucht, gefunden und behoben hat. :) da komme ich jetzt nicht mehr mit... welche Haupt-Anwendung meinst du? alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] ... NARF!
wer betreut eigendlich [EMAIL PROTECTED] bei mir knallt das ding regelmäßig meine 2 gb Ram voll und nach 5 min in denen der pc nicht reagiert, sagt er mir dann error : out of memory error runtime error: file osmarender/osmarender.xsl line 595 element circle ... na tolll... das er das auch schon gemerkt hat... hätte ich ihm auch schon 5 min früher sagen können kann man da nicht eine funktion einbauen, die vorher prüft, ob genügend Speicher vorhanden ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Icons?
ich hab jetzt vor einiger zeit neue icons (/piktogramme) erstellt... wo kann ich die hochladen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Sport Piktogramme
Raphael Studer schrieb: Hi, Ev. noch ein Nicht-Ball-Sport Gerät, ausser es handelt sich um ein Multi-Ball-Sport Platz :) hast du einen vorschlag? Ein Ball (muss nicht Farbig sein, aber z.b. mit Linien). Ringe (diejenigen die von der Decke hängen an denen man turnen kann) und ein Hockey Stock? meintest du so was? http://josias.polchau.de/download/osm/multi4.svg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Sport Piktogramme
Raphael Studer schrieb: Den braunen Ball noch etwas nach unten, damit der nicht so an der Linie oben klebt. mach ich, wenn ich zeit hab ;) Ev. noch ein Nicht-Ball-Sport Gerät, ausser es handelt sich um ein Multi-Ball-Sport Platz :) hast du einen vorschlag? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM-Screencast
hi, die aufnahmen sind sehr leise... ich kann auf meinen Notebook-Lautsprechern kaum was hören... alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Sport Piktogramme
Christoph Eckert schrieb: wo sind die? die hab ich in den letzten Semesterfehrien gemacht ;) http://wiki.openstreetmap.org/index.php/Image:Sport-soccer.png http://wiki.openstreetmap.org/index.php/Image:Sport-swimming.png http://wiki.openstreetmap.org/index.php/Image:Sport-tennis.png die sind schon etwas länger in der Karte drin... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [EMAIL PROTECTED] aus dem Panel starten
moin, ich suche eine Möglichkeit [EMAIL PROTECTED] unter Ubuntu aus dem Panel zu starten etwa so: /home/user/osm/tilesGen.pl loop Can't locate tahconfig.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /home/josias/osm/tilesGen.pl line 32. BEGIN failed--compilation aborted at /home/josias/osm/tilesGen.pl line 32. auch perl /home/user/osm/tilesGen.pl loop funktioniert nicht. weiß jemand eine Lösung? alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Vandalismus
Dominik Spies schrieb: [...]das war ein Versehen, da im Editor (Potlach) diese Straßen und Landkreisgrenzen blau unterlegt waren, was in anderen, schon ziemlich fertiggestellten Bereichen (Ruhrgebiet) nicht der Fall war. In erster Linie habe ich aber die Bezeichnung 'road' gelöscht, da ich diese Bezeichnung unter Map Features nicht fand. Erst am Ende entdeckte ich, daß ein Klick auf eine 'boundary' eine 'relation' anzeigte und ich da wohl Mist gebaut habe. [...] ich kann das echt gut verstehen... ls ich das erste mal auf eine relation gestoßen bin, bin ich auch erst mal stutzig geworden... hab mich dann erst mal informiert... ich finde die sollten auf jedenfall in den Map Features erwähntwerden... auch was man unter dem tag type versteht. ___ 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
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
alles gute Josias
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
