Re: [Talk-de] OSM case sensitiv?
Hallo. Am Montag, 12. Oktober 2009 schrieb Stephan Knauss: > Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu > viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. > Brauchen wir diese Freiheit wirklich? Ich bin dafür, dass jeder, der die Daten nutzt (und folglich weiß, ob er case-sensitive Infos erwartet) einfach ggf. ein "lower()" [je nach Sprache] aufruft. Das schränkt niemanden ein und löst das Problem auch. Es gibt sicherlich viele gute Gründe warum man das eine oder andere in den key packen will und technisch ist es kein Problem. Warum also irgendwas einschränken nur weil der Tellerrand des einzelnen vielleicht zu hoch ist? Gruß, Bernd -- Ein Huhn ist weiter nichts als die Methode eines Eis, ein weiteres Ei zu machen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Ulf Lamping wrote: Erstmal Danke an Dich und die Anderen, die meine Fragen so ausführlich beantworten. Oft freue ich mich auch über diejenigen, welche meine Fragen weitergehend diskutieren, denn daraus erwachsen Antworten, zu denen ich nicht einmal die Frage kannte. >P.S: Wieso fragst du eigentlich? Ich möchte meine Antwort mit ein paar Gegenfragen einleiten: Es war einmal eine Zeit ohne Computer. Niemand hätte sich im Geringsten etwas wie Google Maps oder gar OSM vorstellen können. Und ich stellte mir die Frage: Warum trabe und fahre ich einer Straße in Bau nach, nur um zu wissen, wo entlang und wohin sie führt. Warum fahre ich mit einer Bahn, nur um zu wissen, wo ihre Endhaltestelle ist. Warum versuche ich den Unterschied zwischen einer Autobahn und einer autobahnähnlichen Straße zu ergründen? Warum hinterfrage ich Straßen und ÖPNV, obwohl ich damit die anderen Verkehrsteilnehmer aufhalte? Warum nutze ich die Straßen und den ÖPNV nicht wie diese, um von A nach B kommen, sondern um Ihrer selbst willen? Heute kenne ich die Antwort: OSM! ;-) >Dir ist schon bewußt, daß du andere von der Arbeit abhälst? Tut das nicht jeder, der hier fragt? Jeder, der hier antwortet, wird wissen, warum er dies tut, möglicherweise aus Transparenzgründen. Meine Fragen waren aus Interesse an den Möglichkeiten und Grenzen von OSM gestellt. Im konkreten Fall denke ich schon, dass sich so mancher fragt, warum der Aufbau einer Seite beim Navigieren in Potlatch mitunter Minuten dauert. Manchmal befördert dieses lange Andauern sogar den Firefox ins Jenseits. Und das nicht nur an meinem Computer und meinem DSL Anschluss. Die Antwort macht transparent, warum das trotz den entgegengesetzen Erwartungen bezüglich des neuen Servers so ist, und weckt sicher nicht nur bei mir Verständnis dafür. Ich denke, dieser Zustand ist besser, als wenn sich jemand wutschnaubend "über die da oben" oder über ein unpersonifiziertes OSM ausläßt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Hallo Martin,
>> (1)
>> Es gibt Gebäude, die wirken eher wie eine Brücke über eine Strasse.
>> Z. B. Autobahn-Raststätten:
>> http://upload.wikimedia.org/wikipedia/commons/7/78/Bridge_service_area_Frankenwald.jpg
>> ("Es sieht aus, als hätte man das Gebäude drüber gelegt")
> es sieht nicht nur so aus, es ist so.
Ja, meine Aussage war da sehr verkürzt..
>> (2)
>> Es gibt Strassen, die wirken eher wie Tunnels durch ein Gebäude.
>> Z. B. Einkaufs-Passagen:
>> http://sanasol.de/galleries/ladenpassage/web/ladenpassage2.jpg
>> ("Es sieht aus, als hätte man aus dem Gebäude etwas herausgenommen")
> aha? Du findest, das sieht so aus, als hätte jemand was aus dem
> Gebäude herausgenommen? Abgesehen davon, dass ich schon einen
> Unterschied sehe zwischen Erde und einem Gebäude, finde ich pers. auch
> nicht, dass es so aussieht. Ich finde es sieht so aus, als hätte
> jemand das Gebäude so gebaut, dass es einen Durchgang gibt.
Wieder verkürzt. Das Gebäude wurde nicht "über die Passage" geplant,
sondern als Quader und dann hat der Architekt "ein Loch ins Modell
gesägt" und gesagt: Hier führt die Passage durch.
>> (3)
>> Es gibt Tunnels, die wurden nicht gegraben und sind nicht unter der
>> Erdoberfläche:
>> http://www.blogwiese.ch/archives/33
>> http://osm.org/go/0CZ9B7IAO-?layers=B000FFF
> Ich vermute mal, dass das im eigentlichen Sinn kein Tunnel ist,
> sondern eine Einhausung der Strecke. Meinetwegen könnte man solche
> Spezialfälle evtl. auch als Tunnel taggen, da der Unterschied hier
> wirklich nicht riesig ist (allerdings ist das Teil z.B. ein Hindernis,
> das mal nicht so ohne weiteres queren kann, während ein Tunnel in
> Querrichtung normalerweise kein Hindernis darstellt.
Guter Einwand!
Aber auch wenn auf beiden Seiten Erde aufgeschüttet wird, so dass man
über den Tunnel hinweg spazieren kann, liegt der Tunnel für mich
gefühlt nicht "unter der Erdoberfläche".
>> Ich schreibe extra "wirken", denn ein normaler OSMler ist weder
>> exakter Wissenschaftler noch DIN-auswendig-Könner.
> das ist auch beides nicht nötig, es reicht, es im Wiki klar zu machen,
> was ein Tunnel ist. Übrigens würde m.E. fast kein Mensch ausserhalb
> von OSM auf die Idee kommen, eine Ladenpassage Tunnel zu nennen.
Es sind ja auch nur diejenigen _innerhalb_ OSM wichtig. ;-)
Was ist eigentlich eine Unterführung für Dich? Laut Wikipedia zählen
Unterführungen nicht zu den Tunnels..
>> Vorallem bei so
>> Allerweltswörtern wie "Tunnel" oder "Brücke" kommt der nämlich gar
>> nicht auf die Idee, dass die Begriffe irgendwie normiert sein könnten.
> wie gesagt: eine Durchfahrt oder Passage wird kaum jemand Tunnel nennen.
Hm, ja.. eine gedeckte Einfahrt zum Innenhof würde ich nicht Tunnel
nennen.. Passagen aber irgendwie schon..
>> Ich finde deshalb, die Grund-Keys sollten so einfach wie möglich sein
>> - wer's genauer ausdrücken will, kann zusätzliche Keys verwenden.
> +1.
> Die Straße/der Durchgang könnte also z.B. im Passagenfall wie eine
> normale Straße/Weg getaggt werden, und wer darstellen will, dass es im
> Gebäude ist, der wählt dafür einen Extratag, der dieses ausdrückt.
> Tunnel hat damit nichts zu tun.
So meinte ich das eigentlich nicht. :)
"tunnel" steht für mich sinnbildlich für "es geht nur nach vorne oder
hinten raus, links/rechts/oben ist's zu", darum würde ich solche
Stellen auch allgemein mit tunnel=yes tagen.
Gruss,
Thomas
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Tobias Knerr wrote: > DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten > wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache > geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland > gültigen Dingen, wie eben deinem Beispiel. Ich bin dafür, dass die keys nur aus Kleinbuchstaben bestehen. Hier zu viele Sonderzeichen zu erlauben erzeugt doch nur Verwirrung. Brauchen wir diese Freiheit wirklich? Es gibt sicher genügend Beispiele bei denen es sinnvoll sein könnte. Und eben so viele warum eben nicht. Hier kann man auch prächtig seine Meinung dazu haben. Siehe die Diskussion letztens um die Übersetzungstabelle von Steve. Lass uns lieber mit etwas einfachem beginnen. Wenn wir mal so weit sind, dass wir mit einfachen keys das nicht mehr abbilden können dann können wir immer noch das lockern. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Sarah Hoffmann wrote: select distinct (osm_id*-1) as id, name, "name:en" as name_en from planet_osm_line where osm_id <0 AND admin_level='2' > Da musst du jetzt aber noch diejenigen Relationen herausfiltern, > die nur als Subrelationen gebraucht werden, also zum Beispiel > #51239 "Deutschland - Schweiz". Schade. Dann wird es wohl nicht ohne Handarbeit gehen. Die Liste kann zumindest als Ausgangspunkt dienen. >> Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? > Das ist normal. planet_osm_line enthält nur einfache Wege. Wenn > eine Relation zerstückelt ist, taucht jedes Teilstück einzeln > in planet_osm_line auf. Klingt einleuchtend. Da hätte ich auch selbst drauf kommen können. Vielen Dank für die Erklärung. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
Frederik Ramm wrote: > Die "minute-replicate"-Diffs machen es ungefaehr so, wie Du > oben beschreiben hast. Die sind relativ neu, einige Hinweise dazu finden > sich im Thread "hourly diffs are missing edits (too)" auf der dev-Liste. Ich habe das mal ausprobiert, läuft ganz gut. Auf dem Server werde ich das wohl so verwenden. Für meine Workstation daheim finde ich es etwas unpraktisch. Der Rechner ist über Nacht aus, dann bin ich ein paar Stunden arbeiten. Dann ist es doch wieder ein größeres Stück das fehlt. Da würden Stunden-Diffs auch reichen. Eventuell wären die auch ein wenig kleiner. Ist bekannt ob es wenn die Minutendiffs rund laufen das auch für Stunden/Tage geben wird? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Frederik Ramm wrote: > Meine Hoffnung stuetzt sich auf zweierlei: Erstens haette ich eine > stundenlange Lese-Operation gefolgt von ein paar wenigen > Schreiboperationen - ich nehme an, dass die Datenbank die ganze Zeit > ueber relativ ungestoert weiter zur Nutzung zur Verfuegung stehen kann, > waehrend ein Komplett-Import (selbst wenn er auf einer anderen > Datenbankinstanz gemacht wird) die Kiste eher ausbremst. Wie findest du "Leichen" in der DB? Du müsstest dir ja zu jedem Eintrag merken ob er noch gültig ist, oder nicht. Wenn du von einem Planet File ausgehst findest du recht einfach die geänderten und die neuen Einträge. Vielleicht nur die IDs speichern, die gefunden wurden? Und später ein SELECT per EXCEPT drüber? Im schlimmsten Fall ein SeqScan pro Tabelle. > Zweitens wuerde > die Index-Erzeugung, die nach meiner Erfahrung mindestens ein Drittel > der Planet-Import-Zeit einnimmt, auf ein vernachlaessigbares Mass > zusammenschrumpfen. Wodurch wird denn die Indexerzeugung gestartet VACUUM ANALYZE? >> Ich hatte mal mit imports für einzelne Länder gespielt. Da war neu >> einlesen schneller als Diff einspielen. > Da hast Du das Neu-Einlesen dann aber ohne --slim gemacht, oder? Ja. Das brauche ich ja nur wenn ich updaten will oder der Speicher knapp wird. Stephan ___ 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
Hi, Josias Polchau wrote: > 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.) Ich habe meine eigenen Vorlieben, aber es ist wirklich so, wie ich oben schrieb: Wer eine gescheite Software programmiert, der darf aussuchen, welche Sprache er dazu benutzt. Und wer nichts programmiert, der darf auch anderen nicht reinreden ;-) Wobei man fairerweise schon gestehen muss: Waere die XAPI in Ruby geschrieben gewesen, dann haette sie vielleicht schon lang den Weg auf die zentralen Server gefunden... aber welcher von den Admins bindet sich schon gern was ans Bein, wo er im Krisenfall nicht in der Lage ist, mal selber was zu reparieren... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ 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
[Talk-de] ATMEL-Programmierer für OSM-Projekt g esucht
Hallo Community, gibt es hier vielleicht Mitglieder, die Software für ATMEL-Chips (ATmega88) programmieren können (C etc.)? Es handelt es sich um einen sehr genauen barometrischen Höhenmesser für OpenStreetMap, der vor einigen Wochen angeplant wurde. Schaltpläne und Bauteile sind schon vorhanden, Platinenfertiger stellt kostenlose Prototypen bereit - nur die Software für den ATMEL fehlt noch (Linux- und Windows-Software sind kein Problem). Würde mich über PMs freuen, ggf. kann ich eine eigene Mailingliste einrichten. Mehr Details dann dort, weil Off-Topic. Viele Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reminder: OSM-Vortrag in Zürich am 13.10.
> nicht vergessen: >> [Vortrag in Zürich] Ups, das sollte eigentlich an die Schweizer Liste gehen. Nujo, vielleicht ist ja morgen jemand per Zufall in Zürich.. :) Gruss, Thomas ___ 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
> Und das > ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten > statt live arbeiten tun wir doch mit Potlatch (bzw. angeblich tun einige das ;) > und die Änderungen nur als rudimentäre Striche, > statt beispielsweise in Mapnik Darstellung erscheinen. Dann werf mal nen Blick auf http://www.merkaartor.org/ :) Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reminder: OSM-Vortrag in Zürich am 13.10.
Hallo Liste, nicht vergessen: > OpenStreetMap - die freie Landkarte und Geodatenbank - Dienstag, 13. > Oktober > Warum OpenStreetMapper mit GPS Empfängern durch die Gegend laufen > und die Weltkarte neu zeichnen. Von Andreas Brauchli, OpenStreetMap. > > Die Kurzvorträge beginnen jeweils um 17.15 Uhr. Danach DJ-Set mit > Creative Commons lizenzierter Musik. > > Ort: bQm, unter der Polyterrasse, Leonhardstrasse 34, 8092 Zürich > > Veranstalter: [project 21] - studentische Organisation für nach- > haltige Entwicklung der Uni und ETH Zürich > > Weitere Infos unter www.project21.ch/cc-bqm Gruss, Thomas ___ 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 Ramm schrieb: > Insgesamt ist das halt eine nicht ganz primitive Operation. und wenn man diese Operationen auf geographischer Ebene verteilen würde, soweit es geht? Abfragen über ganz Deutschland oder Europa sollten dann gleich unterbunden werden. Auch wäre es vielleicht sinnvoll, Anfragen ab einer bestimmten Anzahl von Nodes schon bei der Überschreitung eines Wertes bei den Inner-Selects abzubrechen. Grüße Tobias ___ 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, 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: 1. Suche alle Nodes in diesem Bereich. Geht schnell, kann aber schon mal einige zigtausend Nodes ergeben. 2. Suche alle Ways, in denen irgendwo einer von diesen Nodes vorkommt. 3. Suche alle Nodes aus den in Schritt 2 gefundenen Ways; vergleiche die Liste mit der Liste aus 1; fuege all jene hinzu, die noch nicht drin waren 4. Suche alle Relationen, die einen der Nodes oder Ways aus 1/2/3 enthalten 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. > anscheinend ist es in Pascal geschrieben Irrtum. > letztendlich ist die Programmiersprache ja egal, wenn entsprechend gute > DB abfragen gestellt werden. 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. 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. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ 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] OSM case sensitiv?
Tobias Wendorff schrieb: > Tobias Knerr schrieb: >> DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten >> wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache >> geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland >> gültigen Dingen, wie eben deinem Beispiel. > > Also ist "DE:Kommunikation" auch falsch? Demnach müsste es ja eigentlich > "de:communication" heißen. Ich nehme an, du sprichst vom Wiki? Für die meisten Seiten ist die Benennung der Namensräume dort tatsächlich nicht mit dieser Norm konform; nämlich dort, wo es sich bei den DE:*-Seiten (wie meist der Fall) um reine Übersetzungen handelt, und nicht um Übertragungen auf die hiesigen Verhältnisse. Gerade bei DE:Kommunikation liegt aber eher der Fall vor, dass es tatsächlich (nach einem kurzen Blick jedenfalls) um Kommunikation mit Datenspendern in Deutschland (im deutschsprachigen Raum?) geht. Es ist auch zu bedenken, dass Seitentitel in einem MediaWiki nicht mit Kleinbuchstaben anfangen können. Trotzdem ist mir nicht ganz klar, warum auf DE: statt De: vereinheitlicht wurde - letzteres kam früher nämlich durchaus auch vor. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Tobias Knerr schrieb: > DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten > wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache > geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland > gültigen Dingen, wie eben deinem Beispiel. Also ist "DE:Kommunikation" auch falsch? Demnach müsste es ja eigentlich "de:communication" heißen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
Chris-Hein Lunkhusen schrieb: > Ich stolpere nämlich gerade über die verschiedenen > Schreibweisen von maxspeed=DE:urban > (de:urban, DE:Urban, De:urban, De:Urban)... Das ist die übliche Verwirrung zwischen Sprach- und Länderkürzeln, siehe auch http://de.wikipedia.org/wiki/ISO_3166#Geographische_.28ISO_3166.29_und_sprachliche_.28ISO_639.29_Einteilung DE steht für Deutschland, de für die deutsche Sprache. Von daher sollten wir korrekterweise auch de dort verwenden, wo es um die deutsche Sprache geht (also z.B. name:de), und DE bei im Gesetzgebungsraum Deutschland gültigen Dingen, wie eben deinem Beispiel. Tobias Knerr ___ 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
Original-Nachricht > Datum: Mon, 12 Oct 2009 10:53:34 +0200 > Von: Josias Polchau > An: talk-de@openstreetmap.org > Betreff: Re: [Talk-de] Strato sponsort 3 Server für OSM Hallo, > 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. Na ja, mal schaun. > wenn OSM weiter so rasant wächst, wächst auch die Wartezeit > exponentiell. Solange die Maschine nicht am Limit kraechtzt, ist eher ein lineares Problem. Fruehere Engpaesse wurden wohl hauptsaechlich mit internen Verfeinerungen (Quadtrees, etc.) behoben. > 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 Ein paar machen schon noch mit ;) Loesungsanseatze gabs schon immer, z.B. die Regionalisierung der DB. Der amerikanische Kontinent ist ja dank Massenimport einer der groessten Brocken, hat aber wenig verbindung mit dem Rest der Welt und waere damit ein guter Testkandidat. Ich denke auch, dass sich bei Datenorganisation und API noch einiges machen liesse. Dass z.B. alle Nodes gleich behandelt werden, egal ob die als POI Attribute abbilden, oder nur als Stuetznodes fungieren, macht die Arbeit mit der API z.B. auch nicht einfacher. Ein Satz von effizienten Basiselementen wie Flaechen und Polygone, auf die man ohne Umweg ueber die Nodes zugreifen kann, koennte so einiges vereinfachen. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM case sensitiv?
On Mon, Oct 12, 2009 at 11:58:43AM +0200, Chris-Hein Lunkhusen wrote: > sehe ich das richtig dass OSM generell case sensitiv > ist, sowohl für Tags als auch für Werte ? > > Also oneway=yes ist was anderes als Oneway=yes > und oneway=YES, etc. ? Ja, richtig. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ 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. In der Richtung kann man mit Sicherheit dann auch noch mehr tricksen. >> Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem >> lösen können > > Es ist nichts dagegen einzuwenden, dass Leute darueber nachdenken, wie > sie die Schreibanforderungen auf mehrere Datenbanken verteilen koennen. > Ich glaube nur nicht, dass viel bei herauskommt. Insbesondere da die Leute, die in diesem Bereich wirklich die Arbeit machen (und die durchaus wissen was sie tun) hier eh nicht mitlesen :-) Gruß, ULFL ___ 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, 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. > Deshalb lasst uns schon jetzt darüber nachdenken, wie wir das Problem > lösen können Es ist nichts dagegen einzuwenden, dass Leute darueber nachdenken, wie sie die Schreibanforderungen auf mehrere Datenbanken verteilen koennen. Ich glaube nur nicht, dass viel bei herauskommt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM case sensitiv?
Hi, sehe ich das richtig dass OSM generell case sensitiv ist, sowohl für Tags als auch für Werte ? Also oneway=yes ist was anderes als Oneway=yes und oneway=YES, etc. ? Ich stolpere nämlich gerade über die verschiedenen Schreibweisen von maxspeed=DE:urban (de:urban, DE:Urban, De:urban, De:Urban)... Grüße Chris :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vereinfachte OSM-Karte Ausdrucken
Jonas Krückel schrieb: > > >> Gibt es dafür schon eine Anwendung (OS Vista 32bit)? > > Entweder schaust du bei walking-papers.org vorbei Danke, genau so etwas habe ich gesucht. oder du nutzt Kosmos > und nutzt einen einfachen Style aus dem Wiki oder erstellst einen > eigenen. > Gruß > Jonas > >> Gruß >> Dieter Jasper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vereinfachte OSM-Karte Ausdrucken
Am 12.10.2009 um 10:58 schrieb dieter jasper : > Hallo, > möchte eine Karte meines Wirkungsgebietes auf einem Tintenstrahldruc > ker > (A4) vereinfacht ausdrucken, so dass nur die Linien dargestellt > ausgedruckt werden (Tinte sparen). Straßennamen usw. sind nicht notw > endig. > Diesen Ausdruck möchte ich verwenden, um z. B. Hausnummern und POI's > auf > dem Ausdruck einzutragen, um sie später am Rechner in die Datenbank > einzupflegen. > Der Ausschnitt und der Zoomfaktor sollten wählbar sein. > > Gibt es dafür schon eine Anwendung (OS Vista 32bit)? Entweder schaust du bei walking-papers.org vorbei oder du nutzt Kosmos und nutzt einen einfachen Style aus dem Wiki oder erstellst einen eigenen. Gruß Jonas > > Gruß > Dieter Jasper > > > ___ > 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
[Talk-de] Vereinfachte OSM-Karte Ausdrucken
Hallo, möchte eine Karte meines Wirkungsgebietes auf einem Tintenstrahldrucker (A4) vereinfacht ausdrucken, so dass nur die Linien dargestellt ausgedruckt werden (Tinte sparen). Straßennamen usw. sind nicht notwendig. Diesen Ausdruck möchte ich verwenden, um z. B. Hausnummern und POI's auf dem Ausdruck einzutragen, um sie später am Rechner in die Datenbank einzupflegen. Der Ausschnitt und der Zoomfaktor sollten wählbar sein. Gibt es dafür schon eine Anwendung (OS Vista 32bit)? Gruß Dieter Jasper ___ 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] Gebäude über Straße
> Paul Baumbach schrieb: > > Hier hab ich ein Beispiel: Das Gebäude 09 der Universität ist als > layer 1 > > getagt. Osmarender kann es korrekt, Mapnik hingegen nicht. > > > http://www.openstreetmap.org/?lat=52.13963&lon=11.64197&zoom=17&layers= > 0B00F > > > > Verläuft der Weg unter dem Gebäude oder durch das Gebäude? > Ich habe nochmal versucht ein gute Bild vom Gebäude zu finden, aber leider war da nichts zu machen. Allerdings geht der Weg auf Höhe der Erdoberfläche durch das Gebäude hindurch. Ahnlich verhält es sich mit der Bibliothek, die etwas weiter östlich auf dem Campus steht. Auch hier verlaufen Wege unter dem Gebäude, allerdings kragt hier ein Teil des Gebäudes heraus (siehe http://tinyurl.com/yf5da2q ). Hier wird es definitv nicht richtig gerendert. Grüße, Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
Hallo, marcus.wolsc...@googlemail.com wrote: > Werden die Changeset-IDs linear hochgezählt? Ich glaube ja (ist halt eine Postgres-Sequenz). > Falls ja könnte man die Query so gestalten: > > Select * from changesets where id > [grösste Chageset ID des letzten > Laufes] > OR id in [alle nicht aufgetauchten changeset IDs in einem "geeignetem" > Intervall] > > der zweite Teil könnte möglicherweise genau diese Lücken finden. Grundsaetzlich ja, aber die normalen Diffs gehen nicht nach Changesets, dort werden einfach nodes/ways/relations in einem bestimmten Zeitfenster rausgesucht! Die "minute-replicate"-Diffs machen es ungefaehr so, wie Du oben beschreiben hast. Die sind relativ neu, einige Hinweise dazu finden sich im Thread "hourly diffs are missing edits (too)" auf der dev-Liste. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten - L ücken in Diffs
On Mon, 12 Oct 2009 09:23:29 +0200, Frederik Ramm wrote: > Hallo, > > marcus.wolsc...@googlemail.com wrote: >>> Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - >>> Ausnahme die "minute-replicate"-Diffs - wird langsam inkonsistent, weil >>> prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei >>> >>> so einem Diff (auch Stunden- oder Tagesdiffs). >> >> Kannst du das näher erläutern? > > Osmosis erzeugt die Diffs auf dem zentralen Server aufgrund der > History-Tabelle mit einem Query, der alles abfragt, was zwischen zwei > Zeitpunkten passiert ist. Aufgrund der Transaktionsisolierung bekommt > Osmosis aber nur die Daten, die einen Timestamp im fraglichen Fenster > haben UND deren Transaktion schon committed ist. Durch diff-Uploads kann > es einige sehr lang laufende Transaktionen geben. > > Beispiel: Das stuendliche Diff fuer den Zeitraum 13:00-14:00 wird um > 14:20 erzeugt und hat alle Daten mit Timestamp 13:00-14:00. Wenn um > 12:59 eine Transaktion begonnen wird, die bis 13:21 laeuft, so > erscheinen um 13:21 ploetzlich lauter Daten in der Datenbank, die einen > Timestamp von 12:59 haben. Diese verpasst das Diff, und sie werden auch > im 14:00-15:00-Diff nicht drin sein. > > Fuer alle anderen Arten von diffs gilt das vergleichbar. Danke für die Erklährung Frederik. Mir ist da gerade etwas zu eingefallen: Werden die Changeset-IDs linear hochgezählt? Falls ja könnte man die Query so gestalten: Select * from changesets where id > [grösste Chageset ID des letzten Laufes] OR id in [alle nicht aufgetauchten changeset IDs in einem "geeignetem" Intervall] der zweite Teil könnte möglicherweise genau diese Lücken finden. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, marcus.wolsc...@googlemail.com wrote: >> Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - >> Ausnahme die "minute-replicate"-Diffs - wird langsam inkonsistent, weil >> prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei >> so einem Diff (auch Stunden- oder Tagesdiffs). > > Kannst du das näher erläutern? Osmosis erzeugt die Diffs auf dem zentralen Server aufgrund der History-Tabelle mit einem Query, der alles abfragt, was zwischen zwei Zeitpunkten passiert ist. Aufgrund der Transaktionsisolierung bekommt Osmosis aber nur die Daten, die einen Timestamp im fraglichen Fenster haben UND deren Transaktion schon committed ist. Durch diff-Uploads kann es einige sehr lang laufende Transaktionen geben. Beispiel: Das stuendliche Diff fuer den Zeitraum 13:00-14:00 wird um 14:20 erzeugt und hat alle Daten mit Timestamp 13:00-14:00. Wenn um 12:59 eine Transaktion begonnen wird, die bis 13:21 laeuft, so erscheinen um 13:21 ploetzlich lauter Daten in der Datenbank, die einen Timestamp von 12:59 haben. Diese verpasst das Diff, und sie werden auch im 14:00-15:00-Diff nicht drin sein. Fuer alle anderen Arten von diffs gilt das vergleichbar. Bye Frederik ___ 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, Tirkon wrote: > Und demnach > liegt dann hier der Casus knacktus, denn die ist eben langsam. Und das > ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten > statt live arbeiten und die Änderungen nur als rudimentäre Striche, > statt beispielsweise in Mapnik Darstellung erscheinen. Um Ulfs Statement hier etwas auszukleiden: Was Du schreibst ist unlogisch, denn der Datenbankserver hat genau gleichviel zu tun, egal, ob ich auf Benutzerseite nur graue Striche oder eine farbenpraechtige Mapnik-Karte darstelle. Das hat also miteinander nichts zu tun. Es waere theoretisch denkbar, einen Editor zu machen, der mit Mapnik rendert - lediglich, wenn Du dann ein Objekt mit der Maus "anfasst" und Nodes verschiebst, wirst Du davon Abstand nehmen muessen, denn *so* schnell, dass das Rendering "live" Deiner Maus folgen kann, ist Mapnik dann auch wieder nicht. > Ergo konnte der Flaschenhals, dem durch die damalige Spendenaktion für > den Server der Foundation begegnet werden sollte, nicht beseitigt > werden. Das wird auch nie gelingen. - Es sind aber sehr viele Mischformen denkbar. Der zentrale Server muss auf absehbare Zeit zentral fuer Schreiboperationen bleiben. 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. > Also bringt der Strato Server hier auch keine Abhilfe. Der Strato-Server wird bestimmt nicht magisch fuer schnelleres Editieren sorgen, soviel ist sicher. Aber die logische Kette, mit der Du diesen Schluss erreichst, ist nicht ganz stimmig. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
On Mon, Oct 12, 2009 at 12:22:19AM +0200, Stephan Knauss wrote: > Frederik Ramm wrote: > > Stephan Knauss wrote: > >> select distinct (osm_id*-1) as id, name, "name:en" as name_en from > >> planet_osm_line where osm_id <0 AND admin_level='2' Da musst du jetzt aber noch diejenigen Relationen herausfiltern, die nur als Subrelationen gebraucht werden, also zum Beispiel #51239 "Deutschland - Schweiz". > Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Oder > hat es bei mir im Laufe der Zeit mal den Import zerbröselt? Die DB > bekommt schon länger nur die Tages-Diffs. Das ist normal. planet_osm_line enthält nur einfache Wege. Wenn eine Relation zerstückelt ist, taucht jedes Teilstück einzeln in planet_osm_line auf. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, Stephan Knauss wrote: > Wo würdest du denn speziell ansetzen um signifikant Zeit gegenüber einem > Neuimport zu sparen? Meine Hoffnung stuetzt sich auf zweierlei: Erstens haette ich eine stundenlange Lese-Operation gefolgt von ein paar wenigen Schreiboperationen - ich nehme an, dass die Datenbank die ganze Zeit ueber relativ ungestoert weiter zur Nutzung zur Verfuegung stehen kann, waehrend ein Komplett-Import (selbst wenn er auf einer anderen Datenbankinstanz gemacht wird) die Kiste eher ausbremst. Zweitens wuerde die Index-Erzeugung, die nach meiner Erfahrung mindestens ein Drittel der Planet-Import-Zeit einnimmt, auf ein vernachlaessigbares Mass zusammenschrumpfen. > Ich hatte mal mit imports für einzelne Länder gespielt. Da war neu > einlesen schneller als Diff einspielen. Da hast Du das Neu-Einlesen dann aber ohne --slim gemacht, oder? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
