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: [OSM-legal-talk] ODbL / BY-SA
Why we need a SA for all merged Data? I understand ODbL like this: If you Merge some Data with OSM Data and create something (e.g. a map) from that you have to publish the merged data under ODbL(or compatible). so why we need that? With SA we intend that no one can fork OSM under a restrictive Licence, and every product with OSM-Data in it should pronounce osm inside isn't it? (did I forget something?) but mostly a fork isn't the intention of merging. Mostly you will delete the merged data after making the intended product!? so you can't merge OSM (e.g. for routing) with other restricted Data. maybe we should think back to what we really intend with a Licence. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
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] DE:Fire hydrant
Alexander Kopf schrieb: ähnlich wie diese http://j-po.de/datei/osm/osmolt/hamburg/ danke, ja de karte sieht ganz gut aus, wie erstelle ich denn so ein overlay? und wie kann ich eine karte erstellen wo dieses overlay genutzt wird? hm ich hatte mal ein Programm geschrieben, dass allerdings nich im beta stadium ist (und das nächste halbe Jahr bleiben wird) http://sourceforge.net/projects/osmparse/ wer Lust hat kann es weiter entwickeln... (darauf achten, dass ein Ausgabe Ordner gewählt ist, sonst startet es nicht) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:Fire hydrant
Alexander Kopf schrieb: http://wiki.openstreetmap.org/wiki/DE:Fire_hydrant An sich eine gute Sache. Du kannst es, wie immer in OSM so wie du denkst benutzen. Wenn dir beim Benutzen weitere Ideen kommen trägst du sie auf die Wiki-Seite ein. ob die Hydranten auf eine der 2 großen Karten kommt ist fraglich. es gibt zu viele davon... eine eigene Hydranten Karte: Möglichkeiten: - richtige Karte - Overlay - Icon map ähnlich wie diese http://j-po.de/datei/osm/osmolt/hamburg/ Ich hoffe das hat dir geholfen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der neue Datenbankserver
OT Jonas Krückel (John07) schrieb: smaug hehe und das wo der kleine Hobbit 2010 verfilmt werden soll ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] layerbasierte Karten was:Re: Karte ohne Feld- und Fußwege und mit kleinen Ortschaften
Patrick Kolesa schrieb: Aber ich frage mich, wieso es keine layerbasierte Karte gibt, bei denen man alles an- und abwählen kann. Das würde Probleme wie deins recht einfach lösen. hm ein paar gründe fallen mir auf Anhieb ein. Ob diese schwer genug sind, eine layerbasierte Karte zu verhindern möchte ich nicht bewerten gründe gegen layerbasierte Karten: - braucht mehr Speicherplatz (nicht doppelt so viel bei 2 gleichen Layern aber durch Overhead wird es aufgebläht.) - benötigt mehr Zeit zum Rendern - ist langsamer in der Anzeige (gerade auf Netbooks ein Problem) - ist nicht sofort da, sonder baut sich nach und nach auf, dadurch kann es zu Verwirrung kommen allgemein hätte aber ich Interesse an so einer Karte mit zu wirken ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Lizenz - so stelle ich mir sie vor
Philipp Klaus Krause schrieb: - Die Nennung von OpenStreetMap als Quelle, was sich gegen Forks richtet (und damit OSM der Willkür der OSF ausliefert) in wiefern? - Das Abgeleitetes unter der gleichen Lizenz we OpenStreetMap stehen muß und damit OpenStreetMap vom Rest der freien welt getrennt wird (z.B. wird es keine Bücher geben, die OSM-Kartenmaterial verwenden, da damit auf Verwendung von unter GFDL oder CC-SA stehenden TExten undBildern im gleichen Buch verzichete werden müßte) wenn ich das richtig verstanden habe ist das grade nicht von Tobias Wendorff beabsichtigt. der Author muss lediglich dafür sogen, dass alle von seinem Werk abgeleiteten werke die quelle OSM nennen, welche Lizenz dafür verwendet wird, ist egal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osmolt 2.0 Beta
Moin die 2. Beta von Osmolt 2.0 wurde veröffentlicht: https://sourceforge.net/project/platformdownload.php?group_id=237320 Osmolt ist ein Programm um eigene (räumlich begrenzte) interaktive Karten zu erstellen. das Ergebnis sieht dann zb so aus: http://j-po.de/datei/osm/osmolt/hamburg/ wenn zu einem Icon eine Beschreibung vorhanden ist kann man diese durch klick auf das Icon aufrufen (in diesem Fall, wenn zb ein Name vorhanden ist.) Osmolt kopiert alle Dateien, die für die Karte relevant sind in das Ausgabeverzeichnis. um die Karte anzuzeigen reicht es anschließend die generierte Html-Seite im Browser anzeigen zu lassen. eine grundlegende Hilfe ist im Programm integriert und sollte für eine einfache Karte ausreichen. wer spezielle Filter anlegen will zb alle post_box, aber nicht die von der post, muss noch etwas auf eine anleitung warten, oder selbst ausprobieren zur Technik: Osmolt läd für die spezifizierte BBox alle Daten herunter, die das Schlüssel-Wert-Paar haben und schaut nach, ob der knoten zu dem filter passt, anschließend generiert Osmolt eine Zeile für das CSV. Für die oben gezeigte Karte benötigte Osmolt weniger als eine Minute. Die englische Übersetzung ist im Moment kaputt und wird in einem späteren Release nutzbar sein. ich würde mich über Feedback und Bugreports freuen. dafür kann man auch Sourceforge benutzen Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Lizenz - so stelle ich mir sie vor
Philipp Klaus Krause schrieb: Josias schrieb: Philipp Klaus Krause schrieb: - Die Nennung von OpenStreetMap als Quelle, was sich gegen Forks richtet (und damit OSM der Willkür der OSF ausliefert) in wiefern? Betrachten wir den Fall, daß es einen Fork gibt, nennen wir ihn 'mal FreeStreetMap, dieser Fork sich weiterentwickelt, unter Umständen Openstreetmap überflügelt. Jemand übernimmt nun beispielsweise einen Ausschnitt aus FreeStreetMap auf seine Website. Als Quellenangabe muß auf dieser Website nun aber OpenStreetMap, nicht FreeStreetMap genannt werden. D.h. alle,s was auf FreeStreetMap aufbaut, verweist in der Quellenangabe auf OpenStreetMap statt FreeStreetMap. nein eher FreeStreetMap auf Basis von Openstreetmap oder FreeStreetMap und Openstreetmap oder so ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmolt 2.0 Beta
Tobias Wendorff schrieb: Kannst Du das vielleicht noch dahingehend erweitern, dass zunächst alle POIs im geladenen Bereich, wie bei einem Tagwatch, angezeigt werden und man dann aus dieser Liste auswählen kann? dafür müsste ich alle Daten aus der Datenbank holen und parsen. dies ist sehr zeitaufwendig und/oder Speicher-fressend. So wäre es möglich, ohne spezifischen POI-Wunsch verschiedene variabel anzeigen zu lassen. Man könnte zwar vorher mit JOSM reingucken, aber gerade bei großem OSM-Dateien bekommt dieser leider häufig Probleme. währe sehr viel Arbeit und ich bin erst mal froh, dass ich osmolt fertig bekommen habe... für solche sachen eignet sich java auch nicht wirklich als Programmiersprache. außerdem währe eine dynamische Karte, also mit nachladen per ajax besser geeignet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmolt 2.0 Beta
Tobias Wendorff schrieb: Josias schrieb: dafür müsste ich alle Daten aus der Datenbank holen und parsen. dies ist sehr zeitaufwendig und/oder Speicher-fressend. Wie kommst Du denn momentan an die POIs? Ich dachte, du parsed die XML-Datei der POIs in den Speicher und liest dann die Koordinaten der gesuchten Nodes ab? nein, das tat Osmolt 1.x das hat dann für Hamburg fast eine Stunde gebraucht. (für jeden weg müssen auch die Nodes gesucht werden.) Osmolt 2.0 fragt bei der API alle Daten die das gesuchte Schlüssel-Wert-Paar haben ab. das dauer halt dann nur noch eine min bei hamburg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Iphone G3
ich hab grad ein weiteres interessantes app gefunden: Trails hat osm Karten als Hintergrund kann aber nicht zu osm hoch laden (nur per mail) man kann fotos aus der app machen kostet aber 2,39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Java SlippyMap Entwicklung.
Dirk Stöcker schrieb: Ja. Aber der Code wird immer programmspezifisch sein. Ich habe mir das gerade nochmal angeschaut. Viel könnte man nicht in eine unabhängige Klasse auslagern ohne in Parametrierungswahnsinn zu verfallen. naja... ich hab das jetzt (nach meinen Bedürfnissen) angepasst (aufrufende Klasse implementiert ein Interface) Das ist doch die Hauptarbeit. jup da hast du recht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Java SlippyMap Entwicklung.
Moin, ich benötige eine SlippyMap mit BBox-Auswahl ähnlich dem in Josm für ein eigenes Java Projekt. ich hab mir die entsprechenden Klassen in Josm schon mal angesehen und gemerkt dass sie sehr mit Josm verwoben sind, so dass es schwer sein wird sie da raus zu bekommen, wenn man nicht so gut mit dem josm-Code vertraut ist. (leider sind nur selten MetaKlassen und Interfaces verwendet worden) Meine Frage(n): Gibt es Schon Bestrebungen (oder sogar schon fertigen code) den SlippyMapChooser unabhängig zu machen? wenn nicht, gibt es jemanden der mitmachen möchte (vielleicht, weil er selbst so was brauchen könnte?) Jemand der sich eventuell schon etwas mit dem josm code damit auskennt? alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Java SlippyMap Entwicklung.
Dirk Stöcker schrieb: Der SlippyMap-Code ist überhaupt nicht in JOSM enthalten, sondern ein unabhängiges Projekt im OSM-Repository. ah ok, dann hab ich das nicht richtig interpretiert. JOSM-spezifisch ist nur die Klasse für den Map-Chooser (org.openstreetmap.josm.gui.download.SlippyMapChooser) wenn ich das richtig sehe ist das aber genau die klasse, die für das auswählen der BBox, oder? Alles andere (org.openstreetmap.gui.*) hat mit JOSM nichts zu tun, was Du auch daran siehst, dass kein josm im Namen steckt. dort ist aber nur der jmapviewer, oder übersehe ich da was? alle Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] surface=ground
Hatto von Hatzfeld schrieb: Auf [..] stehen dieser und weitere Werte. Wäre schön, wenn die mal in die Stylefiles von josm eingepflegt werden würden :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] automatisches Update von Josm
Bernd Wurst schrieb: Es wurde in diesem Thread bisher konsequent ignoriert, aber man braucht doch überhaupt kein Perl. wget kann das alles ganz alleine. wget holt aber bei jeder Änderung gleich die ganze Datei mein Skript holt das nur, wenn sich die Versionsnummer ändert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] automatisches Update von Josm
vor einiger Zeit gab es eine Diskussion über das ausgeben der josm Version ich hab mal in Anlehnung daran ein shellskript geschrieben: Anleitung: - Code (siehe unten) in eine datei schreiben - Datei ausführbar machen - eventuell eine Verknüpfung in einem Panel oder auf dem Desktop anlegen bei jedem ausführen wird automatisch geschaut, ob es eine neue Version gibt, und wenn ja wird diese herunter geladen. anschließend wird josm gestartet Achtung es wird die neuste Version geladen, nicht die Stabile. diese hat mehr Fehler, benutze sie vorsichtig (may have more errors, be careful with this one) rm current -f wget -q http://josm.openstreetmap.de/current if perl -e 'print`unzip -c josm-latest.jar REVISION`=~/sion: (\d+)/' | cmp current devnull then echo kein update else rm josm-latest.jar -f wget -q http://josm.openstreetmap.de/download/josm-latest.jar fi java -jar josm-latest.jar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] automatisches Update von Josm
Josias schrieb: if perl -e 'print`unzip -c josm-latest.jar REVISION`=~/sion: (\d+)/' | cmp current devnull oha böser fehler ;) es muss natürlich /dev/null und nicht devnull heißen... also: rm current -f wget -q http://josm.openstreetmap.de/current if perl -e 'print`unzip -c josm-latest.jar REVISION`=~/sion: (\d+)/' | cmp current /dev/null then echo kein update else echo update rm josm-latest.jar -f wget -q http://josm.openstreetmap.de/download/josm-latest.jar fi java -jar josm-latest.jar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spukhafte Erscheinung
Norbert Kück schrieb: kann mir jemand erklären, woher Mapnik hier die Beschriftungen HB-NI, BRA-CUX und Blumenthaler Aue nimmt? das dürften Flugbezeichnungen sein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
Gerrit Lammert schrieb: zu 2b: ich denke das währe nicht sinnvoll Haltepunkte zusammen zufassen. Ist ein Kompromiss. Momentan ist noch ein Vorteil, das weniger durcheinander auf den Karten herrscht (manche Renderer zeigen die Punkte, auch wenn kein name-Tag dran ist). ok Diesen Tag gibt es (ebenso wie railway=station) bereits. Ich finde amenity passt hier eigentlich ganz gut, da es ja in meinem Konzept nicht mehr den halt auf den Schienen beschreibt, sondern das Gebilde Bahn-/Busstation, dass sich von einfachen Haltestellen in seinen Annehmlichkeiten unterscheidet (Bars, Bäcker, Verkaufsstellen, Dach, evtl. geheizt...). aber ehrlich gesagt: Stationen sind für mich keine Annehmlichkeit. ich denke wir sollten langsam von amenity als Allheilmittel wegkommen. um zu verallgemeinern passt structure besser. ;) Aber Namen sind mir ziemlich egal, es soll halt abwärtskompatibel sein und irgendwie logisch. Gibt es den namespace transport denn überhaupt schon? ist es nicht egal ob es in gibt? es ist das Wort was m.e. am besten auf diese Kategorie passt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] netzwerkspezifische Farben bei ÖPNV
moin, neuerdings hat Google einen http://maps.google.de/maps/mpl?moduleurl=http:%2F%2Fwww.gmapplets.com%2Ftransit%2Flci=transitie=UTF8ll=53.553407,9.992196spn=0.072099,0.154495z=13 siehe Hamburger Liste dieser ist nicht grade von hoher Qualität, aber es hat mich auf eine Idee gebracht: Jedes Netzwerk hat seine eigenen Farben: in Hamburg zb:S-Bahnen=grün usw diese Farben sind allerdings in vielen Städten verschieden. diese Farben werden offiziell vom Netzwerk festgelegt. Ich schlage vor diese Farbe in die routen Relationen mit aufzunehmen: zb könnte man es so taggen: network:color=* ich habe da an die css Farbdarstellung gedacht, da sie leicht verarbeitbar und eindeutig ist: die Hamburger S1 hat zb ungefähr die Farbe #33b540 dh: network:color=#33b540 über Gegenvorschläge und Anmerkungen freue ich mich Alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal (v1) : Haltestellen des öffentlichen Verkehrs
moin, ich denke das ist ein sehr durchdachter Vorschlag, auf den mit wenig Aufwand sogar automatisch umgestellt werden könnte. (alle Haltestellen, die auf der Straße/Schiene liegen sind Haltepunkte alle die daneben liegen sind Plattformen) folgende Kritik Punkte habe ich, die allerdings meine Zustimmung zum vorschlag nicht in fragestellen: zu 2b: ich denke das währe nicht sinnvoll Haltepunkte zusammen zufassen. zu 2c: ich denke jeder Haltepunkt sollte einen Namen bekommen dürfen zb Halt 2b da teilweise mehrere Haltepunkte an einer Plattform seien können zu amenity=station: bitte stapaziere amenity nicht zu sehr und nutze einen besseren tag zb transport=station zu Plattform Rendering: da es manche Plattformen gibt, auf denen auch Fahrradfahrer fahren dürfen, sollte es so gerendert werden wie path. alles gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Framework für die Kartendarstellung - Existent ???
meinst du sowas? http://j-po.de/datei/osm/?zoom=14lat=53.58012lon=9.70206layers=B0T ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] netzwerkspezifische Farben bei ÖPNV
ok... da hab ich dann schon nicht mehr mitgelesen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserski-Anlage
hm ich hab mal ein Icon für Wasserski gemacht: http://wiki.openstreetmap.org/wiki/Image:Waterski.png hatte im Wiki nichts in den Kategorien gefunden... alles Gute Josias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] daten_sichern_wiederherstellen
Claudius Henrichs schrieb: Ansonsten: In JOSM Bereich herunterladen und als OSM-Datei speichern. wann bekommt eigentlich Josm eine History-Funktion? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb schrieb: Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. da stimme ich dir voll und ganz zu. am besten würde mir aber gefallen, wenn die Hausnummern immer verschoben würden. es gibt so viele Objekte die diese überlagern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Markus schrieb: Nach meiner bescheidenen Meinung würde Darstellung Was geschieht eigentlich mit solchen und ähnlichen *Wünschen an die Renderer*? meist arbeitet die einer der Renderer in das style-file des osmarenders ein Wer ist das eigentlich: die Renderer? jeder der einen svn Zugang hat und sich da eingearbeitet hat. bin leider nur einer der ersteren ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Torsten Leistikow schrieb: Es gibt ein leisure=sports_centre. währe da nicht sport=sports_centre korrekter? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
Florian Lohoff schrieb: Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. nein... das fand ich überhaupt nicht ok. ich hab mir so viel mühe gegeben mit den Hausnummern, da möchte ich doch nicht, dass jede 2. von einem symbol überdeckt wird. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. das wäre die beste Lösung. dann muss man dieses Overlay aber auch entdecken und anschalten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fossgis Mitgliedschaft
warum sollte man bei Fossgis Mtglied werden? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
