[Talk-de] Wartungsarbeiten API am 23.6.
Hallo, am Donnerstag 23.6. wird die OSM-API von ca. 9:30 bis 21:30 nicht verfuegbar sein (keine API-Abfragen, kein Editieren, keine Diff-Updates). Wiki, Mailinglisten, und help.openstreetmap.org sollten nicht betroffen sein. Grund ist, dass einige Server vom University College of London in ein etwas besseres Rechenzentrum am Imperial College umziehen. Details gibt es spaeter auf http://wiki.openstreetmap.org/wiki/Servers/June_2011_Maintenance. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [!SPAMVERDACHT!] Re: Nuklearkarte
Hier eine Version für deutsche AKWs von IT-Consult alle GmbH (AKW-Daten lt. Wikipedia) http://www.osmwms.de/gdi-demo/ mikeE. -Ursprüngliche Nachricht- Von: Sven Geggus [mailto:li...@fuchsschwanzdomain.de] Gesendet: Donnerstag, 9. Juni 2011 10:15 An: talk-de@openstreetmap.org Betreff: [!SPAMVERDACHT!] Re: [Talk-de] Nuklearkarte Markus liste12a4...@gmx.de wrote: Eine dynamische Version gibt es hier: http://opendata.zeit.de/atomreaktoren/#/de/ Die auf Google Maps basiert... Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ 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] Relationen für Betreiber (und evtl. für alles?)
On Thu, Jun 09, 2011 at 08:06:49PM +0200, M∡rtin Koppenhoefer wrote: Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Aaargh. Das klingt auf den ersten Blick ja alles ganz toll. Alles superflexibel und so. Aber irgendjemand muss mit den Daten auch arbeiten. Das sind einerseits die Mapper, die das eintragen müssen und andererseits die Leute, die aus den Daten Karten machen oder sonstwas. Und für beide ist diese ganze Relationiererei furchtbar aufwändig. Es hat schon seinen Grund, dass OSM so erfolgreich ist und andererseits Projekte wie DBPedia und alle diese Semantik-Web-Kram-Sachen nicht in die Puschen kommen. Es ist für Menschen schwierig rekursiv verzeigerte Datenstrukturen zu verstehen. Und auch für Maschinen ist das enorm aufwändig, damit zu arbeiten. Eine Software, die die wichtigsten drei, vier Varianten von Deutsche Post aus den Operator-Tags der Briefkästen matcht ist viel viel einfacher, als eine, die Relationen nachlaufen muss. Und dass sowas mit Relationen eindeutiger wird, ist auch eine Illusion. Ich weiss nicht, ob das jetzt noch ist, aber irgendwann hatten wir mal eine Hierarchie der Stadtteile von Bremen doppelt in der Datenbank, weil halt nichts verhindert, dass man sowas macht. Nein, unsere Datenstruktur ist schon gut. Sie ist ein Kompromiss, aber ein praktikabler Kompromiss. Und sie versucht nicht, die ganze Welt in einem Datenmodell abzubilden, sondern nur die Geodaten für eine Karte zu sammeln. Wir sind keine Datenbank für Firmengeschäftsfelder oder politische Strukturen. Das soll ruhig jemand anderes machen. 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] postgresql (osmosis schema) liste von nodes - Polygon?
Alexander Matheisen alexandermathei...@ish.de wrote: Wie werden die Spezialdatenbanken erzeugt? Ein simples INSERT/SELECT? /s/datenbanken/tabellen Sorry Sven -- Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen (Wolfgang Schäuble) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Hi alle, Am 10.06.2011, 09:01 Uhr, schrieb Jochen Topf joc...@remote.org: Nein, unsere Datenstruktur ist schon gut. Sie ist ein Kompromiss, aber ein praktikabler Kompromiss. Und sie versucht nicht, die ganze Welt in einem Datenmodell abzubilden, sondern nur die Geodaten für eine Karte zu sammeln. Das ist gut und genau richtig so. On Thu, Jun 09, 2011 at 08:06:49PM +0200, M∡rtin Koppenhoefer wrote: Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben Das Problem sehe ich aber durchaus auch. Es wäre toll[TM], wenn man von irgendwoher (insbesondere auch innerhalb der Map) auf ein bestimmtes Objekt in der DB verweisen könnte, und zwar * eindeutig, als auch * persistent Beispiel: ich möchte von meiner Homepage aus, weil ich gerade über das Sony-Center in Berlin schreibe, per URI darauf verweisen. Im Moment geht das z.B. über folgende Möglichkeiten: (1) http://open.mapquestapi.com/nominatim/v1/search.php?q=sony%20center (2) http://www.openstreetmap.org/browse/relation/3221 Und hat man jeweils die Probleme: (1) ist nicht eindeutig (bei der Suche könnten mehrere ähnliche gefunden werden) (2) ist nicht persistent (die Relation könnte neu erzeugt werden oder in eine andere eingebettet, oder aufgelöst, werden) Eine nahe liegende Alternativlösung sind Wiki-Links: (3) http://de.wikipedia.org/wiki/Sony_Center (rechts oben auf Karte klicken) siehe auch http://wiki.openstreetmap.org/wiki/Key:wikipedia Allerdings hat dieser eindeutige, persistente URI den Nachteil, dass er nur für wichtige Dinge existiert, nicht z.B. für meinen Bäcker nebenan oder den Grillplatz wo ich meine nächste Geburtstagsfeier abhalten will. Bleiben also noch Koordinaten: (4) http://www.openstreetmap.org/?mlat=52.510004mlon=13.373083zoom=18 mit dem Nachteil, dass der Ort zwar eindeutig, das Objekt aber damit natürlich nicht referenziert ist. Offen bleibt die (fast philos.) Frage, was denn nun das Objekt an sich ist was referenziert werden soll. Ist Bahnhof (auf dem Hinweisschild) nicht doch eher der Bahnhofsparkplatz als das Gebäude, die Plattformen, die Schienenstücke? Können wir eine solche Datenbank: * eindeutige Identifier für Real-World-Objekte (z.B. Bahnhofsparkplatz) * eindeutige Identifier für abstrakte Konzepte (z.B. Deutsche Post) auch wenn sie nicht Teil der OSM-DB ist, mit OSM konsistent halten? IMHO ja, aber nicht durch technische Einschränkungen (Du darfst Relation XY nicht löschen, weil woanders genutzt), sondern durch technische Hilfsmittel (Script das warnt, dass 'Sony Center (Gebäude)' in der OSM-DB verändert oder gelöscht wurde). Somit wäre diese (ext.) Daten- bank etwas ähnliches wie tinyurl. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Hallo, On 06/10/11 10:04, Kay Drangmeister wrote: Das Problem sehe ich aber durchaus auch. Es wäre toll[TM], wenn man von irgendwoher (insbesondere auch innerhalb der Map) auf ein bestimmtes Objekt in der DB verweisen könnte, und zwar * eindeutig, als auch * persistent Ja, das ist ein Ding, das andauernd wiederkommt. Linken von extern auf eine OSM-ID ist ganz klar eine bloede Idee (und manche Leute fordern daraufhin konstante IDs, noch bloeder). Gerade vor ein paar Tagen hier erwaehnt: http://lists.openstreetmap.org/pipermail/talk-gb/2011-June/011749.html Die wahrscheinlich beste Loesung fuer sowas - und hier wurde ja auch schon oft drueber gesprochen - ist etwas, das mit Fuzzy-Koordinaten plus weiteren Informationen arbeitet, also z.B. das amenity=restaurant mit name=*Olive* im Bereich von 500m um den Punkt X oder so. Da braucht es dann nur noch einen Server, der solche Anfragen gut aufloest (und der dann, wenn er gut gemacht ist, gleich auch Bugmeldungen erzeugt, wenn vermehrt Links auf nicht-findbare Objekte reinkommen, oder der sogar Zugriff auf eine Historie hat und der dann sagen kann das Objekt gibt es nicht, aber es gab's bis vor 10 Wochen und wurde dann mit dem Kommentar XXX vom User YYY geloescht und so). Einen ersten kleinen Schritt in die Richtung macht schon das query-to-map von Tim Alder, das schon vor einem Jahr hier diskutiert wurde: http://lists.openstreetmap.org/pipermail/talk-de/2010-May/068971.html Das hat noch nicht alles, was man braucht, und ist auch stark auf die Ausgabe von Karten fixiert (in der Praxis will man vielleicht ja eher eine Art REST-Request machen und dann eine OSM-ID zurueckbekommen). Nominatim geht auch in die Richtung; Queries wie pub near [51.538,7.217] kann es schon beantworten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege zu Gärten taggen?
Am 09.06.2011 23:02, schrieb Manuel Reimer: wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt? Ich tendiere hier zwischen highway=track oder highway=service. Ob ein Weg zu einem Schrebergarten oder zu einem Supermarkt führt ist erstmal egal. Entscheidungskriterien sind: - Breite des Weges - Beschilderung Wenn Autos erlaubt sind: highway=service Wenn Autos nicht erlaubt/möglich sind: highway=path Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neues OpenLayers-Buch - gibt es inzwischen etwas neues ??
Am 30.05.2011 11:25, schrieb Jan Tappenbeck: hi ! in der neusten Wochennotiz wurde von dem neuen engl. Buch zu OpenLayers [1] gesprochen. Hat das schon einer und ist es auch dann noch lohnenswert wenn man das deutschsprachige Buch hat ?? Gruß Jan .-) [1] http://www.amazon.de/dp/1849514127?tag=gismanagementhomlink_code=as2creativeASIN=1849514127creative=9398camp=2514 Hi ! hat zwischenzeitlich einer von Euch dieses Buch einsehen können ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
2011/6/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 9. Juni 2011 20:29 schrieb Markus Straub markus.straub...@gmail.com: Hi, wie taggt ihr folgendes: Gässchen in einer Innenstadt (Altstadt) die keine offiziellen Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren werden können weil es keine Gehsteigabsenkung gibt und die Fläche außerdem von Gastgärten belegt ist. highway=pedestrian? highway=footway? Das selbe Frage stellt sich generell für größere Flächen die innerstädtisch klar dem Fußgänger gewidmet aber nicht als Fußgängerzone gekennzeichnet sind - quasi großflächige Aufweitung des Gehsteigs. m.E. highway=service, service=alley, evtl. noch mit width. Mit dem Motorrad könnte ich doch da durchfahren, wenn ich Dich richtig verstehe? Gruß Martin Nein man kann mit dem Motorrad definitiv nicht durchfahren (die Fläche wird ja fast komplett durch den Sommergastgarten genutzt), auch mit dem Rad wäre es schwierig und außerdem illegal. Ein highway=service kann normal befahren werden, passt also hierfür nicht finde ich. gibt es das: highway=footway area=yes ich nehm an kein renderer schluckt das.. Best, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Berliner Abbiegebeschränkungen
Am 03.06.2011 22:32, schrieb Chris66: Das Thema Routing ist leider noch immer ein Trauerspiel. Navi-Apps Test in der aktuellen C'T: OSM basierte Router schnitten bei der Routingqualität schlecht (NAVFree) bis zufriedenstellend (skobbler) ab. TomTom wurde eine sehr gute Routingqualität bescheinigt. Trostpflaster: GoogleNavigation schnitt auch nur zufriedenstellend ab, vermutlich wegen deren total veralteter Daten. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege zu Gärten taggen?
Am 10.06.2011 10:59, schrieb Chris66: Am 09.06.2011 23:02, schrieb Manuel Reimer: wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt? Ich tendiere hier zwischen highway=track oder highway=service. Ob ein Weg zu einem Schrebergarten oder zu einem Supermarkt führt ist erstmal egal. +1 Entscheidungskriterien sind: - Breite des Weges - Beschilderung Wenn Autos erlaubt sind: highway=service Der Übergang zwischen track und service ist ja wohl fließend. Wichtiger sind dann wohl Zusatzinformationen wie: access, surface und width. Wenn Autos nicht erlaubt/möglich sind: highway=path Das halte ich bei eim 3m breiten Weg für falsch. Dies ist dann wohl ein track. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 09.06.2011 20:06, schrieb M∡rtin Koppenhoefer: Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die Editor-Software sie benutzen (presets, known values, autocompletion). In der Datenbank bräuchte man den 1. Koordinatenbereich, wo der operator anzutreffen ist (kann von der ganzen Welt bishin zu einer Stadt variieren) 2. Name 3. die main-tags, mit welchen der operator zu verknüpfen ist ( zb postbox, vendingmachine, postoffice, building, ... bei der Deutschen Post AG). Für building müß man noch ein bischen besser filtern, da sonst schnell eine zu große Liste entsteht ! Es sollte zb möglich sein alle bekannten operator für Briefkästen in Deutschland im preset amenity=postbox als values zu erhalten, wenn man sich in D befindet und analog für andere Länder/Gebiete. Ich weiß, dass das ein ganze Stück Arbeit erfordert, aber es würde wohl viel mehr Eindeutigkeit schaffen als Monster-Relation-Kombinationen, oder wie stellt Ihr Euch denn so eine Relation für die Post, die Deutsche Bahn bzw andere große, weltweit tätige Konzerne vor ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von nodes - Polygon?
Am Freitag, den 10.06.2011, 07:49 + schrieb Sven Geggus: Alexander Matheisen alexandermathei...@ish.de wrote: Wie werden die Spezialdatenbanken erzeugt? Ein simples INSERT/SELECT? /s/datenbanken/tabellen Statt hier so kleinlich die Fehler anderer zu verbessern, könntest du mal direkt auf meine Frage antworten. Ich fasse deine Reaktion einfach mal als Ja auf. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
Am 10.06.2011 13:27, schrieb Markus Straub: 2011/6/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 9. Juni 2011 20:29 schrieb Markus Straub markus.straub...@gmail.com: Hi, wie taggt ihr folgendes: Gässchen in einer Innenstadt (Altstadt) die keine offiziellen Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren werden können weil es keine Gehsteigabsenkung gibt und die Fläche außerdem von Gastgärten belegt ist. highway=pedestrian? highway=footway? Das selbe Frage stellt sich generell für größere Flächen die innerstädtisch klar dem Fußgänger gewidmet aber nicht als Fußgängerzone gekennzeichnet sind - quasi großflächige Aufweitung des Gehsteigs. m.E. highway=service, service=alley, evtl. noch mit width. Mit dem Motorrad könnte ich doch da durchfahren, wenn ich Dich richtig verstehe? Gruß Martin Nein man kann mit dem Motorrad definitiv nicht durchfahren (die Fläche wird ja fast komplett durch den Sommergastgarten genutzt), auch mit dem Rad wäre es schwierig und außerdem illegal. Was heiß hier illegal, gibt es ein Schild ? Wie sieht das am frühen Morgen und im Winter aus ? Ein highway=service kann normal befahren werden, passt also hierfür nicht finde ich. Es gibt auch immer noch access=* und foot=official Leider werden da aber auch etliche Kombination nicht richtig dargestellt. aber width=* geht auf jeden Fall. gibt es das: highway=footway area=yes geht durchaus (bzw siehe oben) ich nehm an kein renderer schluckt das.. Deshalb wird meistens falscherweise highway=pedestrian benutzt. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Noch ein OpenLayers-Buch
Hi ! es gibt da noch ein OL-Buch http://www.amazon.de/Openlayers-Lambert-M-Surhone/dp/6133424176/ref=pd_sim_sbs_eb_2 Kennt das jemand ...? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hochladen Daten JOSM
Hallo, habe nach einiger Zeit wieder mit JOSM gearbeitet und mit der aktualisierten Version versucht Daten hochzuladen. Ich bekomme den Fehler Dein Zugriff auf das API vorübergehend ausgesetzt, ...anmelden... Bedingungen einsehen... Ein normales Anmelden in OSM ändert daran nichts. Ich habe eine JOSM-Einstellung, bei der ich nicht jedes Mal das Passwort eingeben muss, weiß aber nicht mehr wo man das ändert. Was tun? -- Mit freundlichen Gruessen wonk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noch ein OpenLayers-Buch
Am 10.06.2011 15:01, schrieb Jan Tappenbeck: Hi ! es gibt da noch ein OL-Buch http://www.amazon.de/Openlayers-Lambert-M-Surhone/dp/6133424176/ref=pd_sim_sbs_eb_2 Nein, aber da würde ich die Finger von lassen. Der Verlag sammelt Infos aus der Wikipedia (und anderen Quellen?), druckt und verkauft dieses. Es gibt im Netz einige Berichte dazu. Das Geld ist es nicht wert. Such mal nach Betascript Publishing. Wenn Du eine gute Rezession findest, sag Bescheid ;) Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochladen Daten JOSM
Hallo Wolfgang. Das Projekt OpenStreetMap ändert die Lizenz. Das erfordert aber das Einverständnis derer, die bisher unter der alten Lizenz zum Projekt beigetragen haben. Seit ein paar Tagen ist deshalb das Bearbeiten der Datenbank nur dann erlaubt, wenn du dich dabei entsprechend entschieden hast. Wenn Du dich unter openstreetmap.org einloggst, solltest du eine entsprechende Aufforderung bekommen, der neuen Lizenz zuzustimmen (oder eben abzulehnen). Bisher kannst Du unabhängig von deiner Entscheidung auch weiter zum Projekt beitragen; entscheiden musst du dich dafür aber. Demnächst (möglicherweise schon in den kommenden Tagen) dürfen nur noch diejenigen Betragen, die der neuen Lizenz zugestimmt haben. Details auch siehe http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Implementation_Plan Gruß Peter Am 10.06.2011 15:21, schrieb Wolfgang Wienke: Hallo, habe nach einiger Zeit wieder mit JOSM gearbeitet und mit der aktualisierten Version versucht Daten hochzuladen. Ich bekomme den Fehler Dein Zugriff auf das API vorübergehend ausgesetzt, ...anmelden... Bedingungen einsehen... Ein normales Anmelden in OSM ändert daran nichts. Ich habe eine JOSM-Einstellung, bei der ich nicht jedes Mal das Passwort eingeben muss, weiß aber nicht mehr wo man das ändert. Was tun? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von nodes - Polygon?
Alexander Matheisen alexandermathei...@ish.de wrote: Statt hier so kleinlich die Fehler anderer zu verbessern Dir ist aber schon klar, dass ich einen Fehler von _mir_ selbst korrigiert habe. Also nochmal zum mitschreiben: Ich habe fälschlicherweise Datenbanken geschrieben anstatt Tabellen. Die Idee ist, dass ich eine neue Datenbank mit osmosis schema aufsetze und sich jeder für seine Anwendungen daraus per SQL script, shell, perl, python oder was auch immer, einmal am Tag oder so Spezialtabellen für die eigene Anwendung baut. Gruss Sven P.S.: Warum sind wir nicht längst auf der devserver Liste solche Details interessieren hier doch keinen mehr. -- Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit Office nicht kompatibles Bürosoftwarepaket einzuführen. (Florian Weimer in de.alt.sysadmin.recovery) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Berliner Abbiegebeschränkungen
On Fri, Jun 10, 2011 at 01:51:24PM +0200, Chris66 wrote: Am 03.06.2011 22:32, schrieb Chris66: Das Thema Routing ist leider noch immer ein Trauerspiel. Navi-Apps Test in der aktuellen C'T: OSM basierte Router schnitten bei der Routingqualität schlecht (NAVFree) bis zufriedenstellend (skobbler) ab. Ich finde persoehnlich skobbler ganz brauchbar aber das dingen ist was die u-turn penalty angeht genauso krumm wie navit. Beide quatschen einen ewig voll man moege bitte umkehren was ja in den seltensten faellen wirklich sinn macht. Wenn ich das mit dem Harmann-Becker Festeinbau im Mercedes vergleiche liegen da einfach Welten dazwischen. Flo -- Florian Lohoff f...@zz.de „Für eine ausgewogene Energiepolitik über das Jahr 2020 hinaus ist die Nutzung von Atomenergie eine Brückentechnologie und unverzichtbar. Ein Ausstieg in zehn Jahren, wie noch unter der rot-grünen Regierung beschlossen, kommt für die nationale Energieversorgung zu abrupt.“ Angela Merkel CDU 30.8.2009 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von nodes - Polygon?
Am Freitag, den 10.06.2011, 13:38 + schrieb Sven Geggus: Alexander Matheisen alexandermathei...@ish.de wrote: Statt hier so kleinlich die Fehler anderer zu verbessern Dir ist aber schon klar, dass ich einen Fehler von _mir_ selbst korrigiert habe. Also nochmal zum mitschreiben: Ich habe fälschlicherweise Datenbanken geschrieben anstatt Tabellen. Weil du das als Antwort auf meine Frage geschrieben hattest, dachte ich, das bezog sich nur auf das Spezialdatenbanken in meinem Text. Ich glaube, jeder wusste trotzdem, was gemeint war. Die Idee ist, dass ich eine neue Datenbank mit osmosis schema aufsetze und sich jeder für seine Anwendungen daraus per SQL script, shell, perl, python oder was auch immer, einmal am Tag oder so Spezialtabellen für die eigene Anwendung baut. Meine Frage stellte sich mir, weil es in osmosis den Task --read-pgsql gibt. Aber ist eigentlich von sich aus logisch, dass man eine Postgres DB mit dem üblichen SQL abfragen kann. P.S.: Warum sind wir nicht längst auf der devserver Liste solche Details interessieren hier doch keinen mehr. Dann wechseln wir eben rüber, bezieht sich eh nur noch auf den Devserver. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noch ein OpenLayers-Buch
Am 10.06.2011 15:01, schrieb Jan Tappenbeck: es gibt da noch ein OL-Buch Das ist kein Open-Layers-Buch, das ist Buch-Spam. Der Verlag Betascript geht laut Internetberichten[0] etwa folgendermaßen vor, um an Inhalte zu kommen: 1. Beginne mit einem Wikipedia-Artikel (hier: OpenLayers [1]), verwende 1.1. dessen Titel als Buchtitel 1.2. dessen Volltext als erstes Buchkapitel 1.3. dessen Einleitung als Klappentext 2. Suche willkürlich ein paar weitere Artikel, die in dem Artikel aus Punkt 1 verlinkt sind (hier JavaScript) oder in derselben Kategorie stehen (hier: Capaware, Chameleon (GIS) [2]). Verwende 2.1. deren Titel als Untertitel des Buches 2.2. deren Volltexte als weitere Buchkapitel 3. Ergänze im Buch selbst Lizenzhinweise, aber stelle sicher, dass genügend Kunden erst *nach* dem Kauf kapieren, dass sie nichts anderes als einen überteuerten 1:1-Auszug aus der Wikipedia in den Händen halten Wiederhole das für tausende Wikipedia-Artikel und überschwemme Online-Buchhändler so mit deinen Angeboten. Irgendwer wird's schon kaufen. Also: Lasst bloß alle die Finger von dem Müll. Die Artikel könnt ihr auf Wikipedia für 38,99 € weniger lesen. Tobias [0] z.B. hier: http://www.leitmedium.de/2010/09/28/amazon-betascript-publishing-und-die-automatisierte-wikipedia-buchschwemme/ [1] http://en.wikipedia.org/wiki/OpenLayers [2] http://en.wikipedia.org/wiki/Category:Free_GIS_software ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie verbessert man die qualitaet des routings in OSM? (war: Berliner Abbiegebeschränkungen)
Hallo, Chris66 wrote: Am 03.06.2011 22:32, schrieb Chris66: Das Thema Routing ist leider noch immer ein Trauerspiel. Ja leider, das routing ist wirklich zum Teil noch etwas betruebend. Dabei duerfte routing vielleicht die Application sein mit der die meisten Leute OSM tatsaechlich benutzen und direkt davon profitieren. Mit programmen wie Skobbler, NAVFree, mapfactor navigator free, cyclestreets, garmin maps, Navit, GpsMid und diversen anderen routing Applications duerften inzwischen millionen von Leuten OSM tatsaechlich fuers routing verwenden (zumindestens wenn man einige der Pressemeldungen glauben schenkt die jeweils von mehreren millionen downloads der Programme berichten) Man liest in deren Foren auch immer wieder das User die von der Idee von OSM ueberzeugt sind zu Mappern werden um sicher zu stellen das ihr Navi gut funktioniert. Es bietet also auch ein grosses Potential neue Mapper zu gewinnen. Routing ist also wohl inzwischen eines der grossen Aushaengeschilder von OSM ausserhalb der Geek community. Da ist es besonders schade das Routing nach wie vor eines der schwaecheren Gebiete von OSM ist (moeglicherweise auch da Routing eines der hoechsten Qualitaetsanforderungen an die Daten hat) Es ist wohl eine Kombination aus Fehlern in den Daten und Programmen die nicht ideal sind und nicht immer das maximum aus den Daten machen da sie nicht alle tags auswerten. Auf der Datenseite duerfte es vor allem die falsche Connectivity sein ( siehe z.B. http://tools.geofabrik.de/osmi/?view=routinglon=10.32422lat=51.35395zoom=7 ), sowie fehlendes tagging fuer turn-restrictions, maxspeed und andere Restrictions sein. Auf der programmatischen Seite, unterstuetzen leider immer noch viele der Router wichtige tagging Schemata wie eben turn restrictions, maxspeed und barrier nicht oder nicht richtig. Als drittes Problem sind dann inkonsistenzen im tagging, bzw schwer zu interpretierende Daten. Z.B. ein barrier=gate. Ist die Schranke ueberwiegend offen und man sollte da durch routen, oder ist sie ueberwiegend geschlossen und man kann nicht durch? Laender uebergreifend verschiedenes tagging ist auch nicht gerade hilfreich programmatisches daraus zu machen. Wie unterschiedlich die verschiedenen Routing engines zum Teil die gleichen Daten interpretieren, kann man recht schoen auf http://apmon.dev.openstreetmap.org/routing sehen, wo man die Ergebnisse der vier grossen online routing engines (OSRM, Gosmore, MapQuest und CloudMade) vergleichen kann. Eine Hoffnung die Situation weiter zu verbessern ist Routing in OpenStreetMap.org aufzunehmen. Indem Routing ein Teil der Homepage wird, erinnert es hoffentlich mehr Mapper das routingfaehige Daten ein wichtiger Bestandteil von OSM ist, und das sie mehr mit den Routern herumspielen und somit Fehler in den Daten entdecken die sie dann verbessern. Um dies voran zu bringen hat die Strategic Working Group mit Unterstuetzung des OSMF boards entschieden das sie es gut heissen wuerde das Routing auf die Homepage gebracht wuerde und OSMF auch dafuer Hardwareresourcen zur Verfuegung stellen wird. Allerdings muss erst einmal die entsprechende Software fuer die Integration programmiert werden und gut genuge routing backends vorhanden sein. Derzeit gibt es zwei Ansaetze. Zum einen ein Patch von Nic Roets ( http://nroets.dev.openstreetmap.org/demo/ ) und zum Anderen ein Patch von Soren / Frederick den ich zum auspropieren mal auf den Dev server gestellt habe ( http://apmon.dev.openstreetmap.org/routing ). Beide benoetigen aber noch einiges an Arbeit bevor sie tatsaechlich integriert werden koennten. So dass es wohl noch eine Weile dauern wird. Welche anderen Moeglichkeiten gibt es die OSM Daten besser routingfaehig zu machen? Chris66 wrote: Navi-Apps Test in der aktuellen C'T: Ist der Artikel irgendwo einsichtbar? Erhaelt der Informationen um mehr darueber zu erfahren wo die C'T die Schwaechen sieht? Sind es eher die Software schwaechen, oder eher fehlerhafte Daten die die Herabstufungen verursacht haben? Kai -- View this message in context: http://gis.638310.n2.nabble.com/Berliner-Abbiegebeschrankungen-tp6436629p6462644.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie verbessert man die qualitaet des routings in OSM? (war: Berliner Abbiegebeschränkungen)
Am 10.06.2011 17:23, schrieb Kai Krueger: Welche anderen Moeglichkeiten gibt es die OSM Daten besser routingfaehig zu machen? Also, ich denke, wir bräuchten eine Art Routerstandard, der mit klaren einfachen Regeln definiert, welches Verkehrsmittel wie geroutet werden soll. zB: Sollen Autos über tracks geroutet werden? Sollen Fußgänger über Piers geroutet werden? (Oft sind Fährlinien über man_made=pier mit dem Wegenetz verbunden, aber fast kein Router berücksichtigt das). Und so weiter. Dann bräuchten wir natürlich einen (Online-) Router der diesen Standard umsetzt und täglich aktualisiert wird. Da ja teilweise Wochen-Baustellen mit access=no oder construction zeitnah getaggt werden, sind Router deren Daten nur alle paar Monate aktualisiert werden natürlich suboptimal. ;-) Dann scheint es mir, dass nur wenige Leute einfach mal mit den Routern herumspielen , Ihre täglich gefahren Strecken mal dort eingeben und checken ob eine sinnvolle Route herauskommt. Viele Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Moin, Ich treibe die Frage mal noch weiter. Vielleciht geht es ja tatsächlich mit einem einzigen query alle flächenhaften microbrewery POI zu selektieren. Momentan geht folgendes: Ich selektiere mir alle id die mich interessieren: SELECT id FROM ways WHERE (tags ? 'microbrewery') and (tags-'microbrewery'='yes'); Dann mache ich den folgenden request indem ich über alle id iteriere: SELECT astext(ST_PointOnSurface(ST_MakePolygon(ST_MakeLine(n.geom FROM (SELECT unnest(nodes) FROM ways WHERE id = ...) as w, nodes n WHERE w.unnest = n.id; So funktioniert das zwar aber es geht bestimmt noch eleganter. Mein Problem liegt konkret darin, dass ich das WHERE id = ... nicht mit WHERE (tags ? 'microbrewery') ersetzen kann, weil ich ja die einzelnen Gruppen von nodes mit ST_MakeLine bearbeiten möchte und nicht alle nodes mit diesem tag. Gruss Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
So funktioniert das zwar aber es geht bestimmt noch eleganter. Mein Problem liegt konkret darin, dass ich das WHERE id = ... nicht mit WHERE (tags ? 'microbrewery') ersetzen kann, weil ich ja die einzelnen Gruppen von nodes mit ST_MakeLine bearbeiten möchte und nicht alle nodes mit diesem tag. Ich bin mittlerweile beim gleichen Problem angelangt. Mich würde es auch interessieren, wie es gemacht wird... Wie machst du es denn jetzt? Ein Programm, in dem du dann die IDs zwischenspeicherst und dann die zweite Abfrage laufen lässt? Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Sven Geggus wrote: Ich treibe die Frage mal noch weiter. Vielleicht geht es ja tatsächlich mit einem einzigen query alle flächenhaften microbrewery POI zu selektieren. hi Sven, manchmal hilt es mir und anderen, das Problem mal wirklich genau zu beschreiben. Am Anfang (Thread-Start) wolltest du das Zentrum von Flächen finden; jetzt suchst das was mit flächenhaften Objekten. Ich sehe da schon einen gewissen Zusammenhang, aber was suchst du genau Alle Brauereien, die als Area/Polygon eingetragen sind? Wie sind die getaggt? Welches DB-Schema? osm2pgsql oder osmosis mit hstore? Und schick mal die ID eines Beispielbereiches rüber. dann schau ich mir das mal an. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6463555.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Am Anfang (Thread-Start) wolltest du das Zentrum von Flächen finden; jetzt suchst das was mit flächenhaften Objekten. Ich sehe da schon einen gewissen Zusammenhang, aber was suchst du genau Alle Brauereien, die als Area/Polygon eingetragen sind? Wie sind die getaggt? Welches DB-Schema? osm2pgsql oder osmosis mit hstore? Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen Punkten berechnet wird und nicht nur zwischen den Punkten der jeweiligen Einzelflächen. Es geht um das osmosis Schema. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Alexander Matheisen wrote: Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen Punkten berechnet wird und nicht nur zwischen den Punkten der jeweiligen Einzelflächen. Es geht um das osmosis Schema. Hi Alexander, von mehreren Flächen, deren gemeinsamer Mittelpunkt bestimmt werden soll, war -bisher- nicht die Rede. Da es höchstwahrscheinlich um das Osmosis-Snapshot Schema handelt und Sven verzweifelt versucht, aus Nodes Flächen zusammenzubauen, frage ich mich langsam was das soll. Ich vermute, Sven hat einfach vergessen, linestring und bbox als optionale Spalten der Ways-Tabelle anzulegen. @sven: bitte \d ways in psql eingeben und Ergebnis posten. so sollte das aussehen: gis=# \d ways Tabelle »public.ways« Spalte| Typ | Attribute --+-+--- id | bigint | not null version | integer | not null user_id | integer | not null tstamp | timestamp without time zone | not null changeset_id | bigint | not null tags | hstore | nodes| bigint[]| bbox | geometry| linestring | geometry| Indexe: pk_ways PRIMARY KEY, btree (id) idx_ways_bbox gist (bbox) idx_ways_linestring gist (linestring) wenn alles ok ist, geht das so: select id, tags-'name' name, st_Astext(linestring) way, st_Astext(st_PointOnSurface(linestring)) Center from ways where tags ? 'microbrewery' limit 3; id|name| way |Center --++--+-- 45360471 | Wirtschaftswunder | LINESTRING(9.002598 48.7214827,9.0028258 48.7215596,9.002932 48.7214227,9.0027042 48.7213458,9.002598 48.7214827) | POINT(9.0028258 48.7215596) 50241169 | Brauereigasthof Göller | LINESTRING(10.9715219 49.9409466,10.9715545 49.9408561,10.9716667 49.9408737,10.9717391 49.9408831,10.9717178 49.9409456,10.9717084 49.940973,10.9715219 49.9409466) | POINT(10.9716667 49.9408737) 50308663 | Enzensteiner Brauerei / Biergarten | LINESTRING(11.3679454 49.5623391,11.368205 49.5622779,11.3682603 49.5623704,11.3679972 49.5624301,11.3679454 49.5623391) | POINT(11.368205 49.5622779) (3 Zeilen) Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6463654.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
On Fri, Jun 10, 2011 at 06:13:06PM +, Sven Geggus wrote: Moin, Ich treibe die Frage mal noch weiter. Vielleciht geht es ja tatsächlich mit einem einzigen query alle flächenhaften microbrewery POI zu selektieren. Momentan geht folgendes: Ich selektiere mir alle id die mich interessieren: SELECT id FROM ways WHERE (tags ? 'microbrewery') and (tags-'microbrewery'='yes'); Dann mache ich den folgenden request indem ich über alle id iteriere: SELECT astext(ST_PointOnSurface(ST_MakePolygon(ST_MakeLine(n.geom FROM (SELECT unnest(nodes) FROM ways WHERE id = ...) as w, nodes n WHERE w.unnest = n.id; Das geht mit etwas Gruppierungsmagie, aber irgendwie wird es dann ineffizient. Die beste Methode ist, sich eine Funktion zu definieren: CREATE FUNCTION make_way_geometry(id bigint) RETURNS geometry AS $$ SELECT ST_MakeLine(n.geom) FROM (SELECT unnest(nodes), id FROM ways w WHERE id = $1) as w, nodes n WHERE w.unnest = n.id $$ LANGUAGE SQL; Dann kannst du ganz bequem schreiben: SELECT id, astext(ST_PointOnSurface(ST_MakePolygon(make_way_geometry(id FROM ways WHERE Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
On Fri, Jun 10, 2011 at 01:20:33PM -0700, Walter Nordmann wrote: Alexander Matheisen wrote: Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen Punkten berechnet wird und nicht nur zwischen den Punkten der jeweiligen Einzelflächen. Es geht um das osmosis Schema. Hi Alexander, von mehreren Flächen, deren gemeinsamer Mittelpunkt bestimmt werden soll, war -bisher- nicht die Rede. Da es höchstwahrscheinlich um das Osmosis-Snapshot Schema handelt und Sven verzweifelt versucht, aus Nodes Flächen zusammenzubauen, frage ich mich langsam was das soll. Ich vermute, Sven hat einfach vergessen, linestring und bbox als optionale Spalten der Ways-Tabelle anzulegen. Kommt darauf an. Ich finde es ein bisschen uebertrieben, fuer 100 Mio. Wege linestrings anzulegen, weil man fuer 171 Microbreweries die Flaechen braucht. Insofern ist Sven's Ansatz, das beim Ableiten seiner Tabelle zu machen, wesentlich effizienter. Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste?von?nodes?-?Polygon?
Walter Nordmann walter.nordm...@web.de wrote: hi Sven, manchmal hilt es mir und anderen, das Problem mal wirklich genau zu beschreiben. OK, noch mal von vorne... Gegeben: DB im Osmosis schema, ganz analog zum osm Dateiformat relevante Tabellen: Tabelle »public.ways« Spalte| Typ | Attribute --+-+--- id | bigint | not null version | integer | not null user_id | integer | not null tstamp | timestamp without time zone | not null changeset_id | bigint | not null tags | hstore | nodes| bigint[]| Tabelle »public.nodes« Spalte| Typ | Attribute --+-+--- id | bigint | not null version | integer | not null user_id | integer | not null tstamp | timestamp without time zone | not null changeset_id | bigint | not null tags | hstore | geom | geometry| Nun möchte ich daraus letztendlich wie bisher das kml für die Brewpub Map erzeugen. Nur ist das bisher halt erheblich einfacher weil in der osm2pgsql DB ja schon flächenhafte Elemente drin sind. Beim osmosis Schema muss ich mir diese natürlich erst zusammenbauen. Als Zwischenziel möchte ich dafür als erstes mal alle Flächen aus der ways tabelle selektieren die ein microbrewery=yes haben, deren Schwerpunkt berechnen und das Ergebnis mit astext ausgeben. Wenn ich die node id kenne geht das mit dem Lösungsvorschlag von Sarah. Ich kann allerdings statt einer einzelnen node-id nicht einfache eine andere where Bedingung verwenden, die mehrere Ergebnisse liefert, weil mir der unnest sonst alle nodes zu einer Fläche machen will. Gruss Sven -- Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär, und - dank Knut - insbesondere der Eisbär, deutlich größerer Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Am Freitag, den 10.06.2011, 13:20 -0700 schrieb Walter Nordmann: Alexander Matheisen wrote: Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen Punkten berechnet wird und nicht nur zwischen den Punkten der jeweiligen Einzelflächen. Es geht um das osmosis Schema. von mehreren Flächen, deren gemeinsamer Mittelpunkt bestimmt werden soll, war -bisher- nicht die Rede. Ich hätte es besser so ausdrücken sollen: Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen gefundenen Objekten berechnet wird statt zwischen den Punkten der jeweiligen Einzelflächen. Also konkret: Es bildet den Mittelpunkt zwischen allen Brewpubs und nicht nur zwischen den Punkten eines einzelnen Brewpub-Ways. Da es höchstwahrscheinlich um das Osmosis-Snapshot Schema handelt und Sven verzweifelt versucht, aus Nodes Flächen zusammenzubauen, frage ich mich langsam was das soll. Ich vermute, Sven hat einfach vergessen, linestring und bbox als optionale Spalten der Ways-Tabelle anzulegen. Ich denke, man sollte die aber nur beim Erzeugen der Spezialtabellen anlegen, also nur bei den Objekten erzeugen, bei denen das zur Zeit nötig ist: Brewpubs, Briefkästen, Telefonzellen und den Objekten für meine OLM. Ich denke das ist besser als das bei allen Objekten zu erzeugen, die dann eh keiner nutzt. Ansonsten ist das natürlich praktischer bei der Abfrage. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Da es höchstwahrscheinlich um das Osmosis-Snapshot Schema handelt und Sven verzweifelt versucht, aus Nodes Flächen zusammenzubauen, frage ich mich langsam was das soll. Ich vermute, Sven hat einfach vergessen, linestring und bbox als optionale Spalten der Ways-Tabelle anzulegen. Kommt darauf an. Ich finde es ein bisschen uebertrieben, fuer 100 Mio. Wege linestrings anzulegen, weil man fuer 171 Microbreweries die Flaechen braucht. Insofern ist Sven's Ansatz, das beim Ableiten seiner Tabelle zu machen, wesentlich effizienter. +1 Mit der Funktion, die du gepostet hattest, lässt sich das wohl auf die Art einfach machen. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Das geht mit etwas Gruppierungsmagie, aber irgendwie wird es dann ineffizient. Die beste Methode ist, sich eine Funktion zu definieren: CREATE FUNCTION make_way_geometry(id bigint) RETURNS geometry AS $$ SELECT ST_MakeLine(n.geom) FROM (SELECT unnest(nodes), id FROM ways w WHERE id = $1) as w, nodes n WHERE w.unnest = n.id $$ LANGUAGE SQL; Dann kannst du ganz bequem schreiben: SELECT id, astext(ST_PointOnSurface(ST_MakePolygon(make_way_geometry(id FROM ways WHERE Hört sich gut an, muss ich dann morgen mal testen. Macht die Abfragen etwas übersichtlicher, schade, dass ich meine jetzt nochmal abändern kann... Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste?von?nodes?-?Polygon?
Sven Geggus wrote:
relevante Tabellen:
Tabelle »public.ways«
Spalte| Typ | Attribute
--+-+---
id | bigint | not null
version | integer | not null
user_id | integer | not null
tstamp | timestamp without time zone | not null
changeset_id | bigint | not null
tags | hstore |
nodes| bigint[]|
|
da fehlen die optionalen Spalten linestring und bbox. Die kann/sollte
mal beim Anlegen der Tabellen unbedingt mit erzeugen. siehe:
scripts/pgsnapshot_schema_0.6_linestring.sql
-- Add a postgis GEOMETRY column to the way table for the purpose of storing
the full linestring of the way.
SELECT AddGeometryColumn('ways', 'linestring', 4326, 'GEOMETRY', 2);
CREATE INDEX idx_ways_linestring ON ways USING gist (linestring);
und analoges für bbox. Dann erzeugt dir osmosis ganz automatisch linesting
(way, der die nodes verbindet als polygon) und gegebenenfalls auch die bbox.
Nun möchte ich daraus letztendlich wie bisher das kml für die Brewpub
Map erzeugen. Nur ist das bisher halt erheblich einfacher weil in
der osm2pgsql DB ja schon flächenhafte Elemente drin sind. Beim
osmosis Schema muss ich mir diese natürlich erst zusammenbauen.
NEIN NEIN NEIN, wenn du -endlich- das Feld ways.linestring anlegst hast du
die auch.
Als Zwischenziel möchte ich dafür als erstes mal alle Flächen aus der
ways tabelle selektieren die ein microbrewery=yes haben, deren
Schwerpunkt berechnen und das Ergebnis mit astext ausgeben.
siehe mein Beispiel
Wenn ich die node id kenne geht das mit dem Lösungsvorschlag von
Sarah. Ich kann allerdings statt einer einzelnen node-id nicht
einfache eine andere where Bedingung verwenden, die mehrere
Ergebnisse liefert, weil mir der unnest sonst alle nodes zu einer
Fläche machen will.
ich hoffe mal ganz stark, dass sich deine Antwort und meine vorigen Infos
überschnitten haben.
Gruss
walter
-
Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst
sehen, dass da kein Wald ist.
--
View this message in context:
http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6463852.html
Sent from the Germany mailing list archive at Nabble.com.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema) liste von?nodes?-?Polygon?
Alexander Matheisen wrote: Wenn ich das richtig verstanden habe, geht es darum, dass bei der Abfrage von mehreren Objekten nach Tag der Mittelpunkt zwischen allen gefundenen Objekten berechnet wird statt zwischen den Punkten der jeweiligen Einzelflächen. Also konkret: Es bildet den Mittelpunkt zwischen allen Brewpubs und nicht nur zwischen den Punkten eines einzelnen Brewpub-Ways. Was soll das den?? Wofür soll das den gut sein? Ich vermute, Sven hat einfach vergessen, linestring und bbox als optionale Spalten der Ways-Tabelle anzulegen. Ich denke, man sollte die aber nur beim Erzeugen der Spezialtabellen anlegen, also nur bei den Objekten erzeugen, bei denen das zur Zeit nötig ist: Brewpubs, Briefkästen, Telefonzellen und den Objekten für meine OLM. Ich denke das ist besser als das bei allen Objekten zu erzeugen, die dann eh keiner nutzt. total falscher Ansatz; hier wird am falschen Ende gespart. Etwas Plattenplatz gegenüber einem erheblichen Aufwand, sich nur die notwendigen Sachen zusammenzubasteln. Morgen kann schon etwas fehlen, was man vergessen hat - und dann geht die ganze Sache wieder von vorne los. Das war für mich übrigens der Grund, vor ca 1 Jahr von osm2pgsql nach osmosis zu wechseln weil immer wieder Daten fehlten, die man zwar nicht zum Rendern braucht aber dennoch plötzlich dringend benötigt wurden. Nochmal: Hier wird am falschen Ende gespart und unnötiger Stress erzeugt. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6463877.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema)?liste?von?nodes?-?Polygon?
Sarah Hoffmann lon...@denofr.de wrote: Das geht mit etwas Gruppierungsmagie, aber irgendwie wird es dann ineffizient. Die beste Methode ist, sich eine Funktion zu definieren: CREATE FUNCTION make_way_geometry(id bigint) RETURNS geometry AS $$ SELECT ST_MakeLine(n.geom) FROM (SELECT unnest(nodes), id FROM ways w WHERE id = $1) as w, nodes n WHERE w.unnest = n.id $$ LANGUAGE SQL; Dann kannst du ganz bequem schreiben: SELECT id, astext(ST_PointOnSurface(ST_MakePolygon(make_way_geometry(id FROM ways WHERE OK ich seh schon, meine SQL Kenntnisse sind immer noch deutlich ausbaufähig... SELECT tags-'name',astext(ST_PointOnSurface(ST_MakePolygon(make_way_geometry(id FROM ways WHERE (tags ? 'microbrewery') and (tags-'microbrewery'='yes'); Sieht doch richtig gut aus. Jetzt muss ich eigentlich nur noch Datenbank und Aktualisierung auf dem devserver aufsetzen. Super, Danke! Gruss Sven -- /* Fuck me gently with a chainsaw... */ (David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema)?liste?von?nodes?-?Polygon?
Walter Nordmann walter.nordm...@web.de wrote: Nun möchte ich daraus letztendlich wie bisher das kml für die Brewpub Map erzeugen. Nur ist das bisher halt erheblich einfacher weil in der osm2pgsql DB ja schon flächenhafte Elemente drin sind. Beim osmosis Schema muss ich mir diese natürlich erst zusammenbauen. NEIN NEIN NEIN, wenn du -endlich- das Feld ways.linestring anlegst hast du die auch. Wenn man ohnehin Spezialtabellen erzeugt ist es erheblich effizienter diese nur für die Spezialtabellen zu erzeugen und nicht global für alle ways. Gruss Sven -- Dynamische IP-Nummern sind Security-Homöopathie. (Kristian Köhntopp) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgresql (osmosis schema)?liste?von?nodes?-?Polygon?
deine Entscheidung - dein Problem Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/postgresql-osmosis-schema-liste-von-nodes-Polygon-tp6459170p6464085.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie verbessert man die qualitaet des routings in OSM? (war: Berliner Abbiegebeschränkungen)
Hallo, Am Freitag 10 Juni 2011 17:23:35 schrieb Kai Krueger: Welche anderen Moeglichkeiten gibt es die OSM Daten besser routingfaehig zu machen? Indem die Restriction-Relation nochmal überdacht wird. Ich sehe da 2 Probleme: 1. die Notwendigkeit, den from-Way am Via-Punkt unterbrechen zu müssen. Das führt häufig zu den überflüssigen Ansagen auf Schnellstraßen ohne bauliche Trennung links halten oder geradeaus an Abfahrten, wenn man nicht abbiegen soll. Abhilfe wäre hier, für die Role from nicht nur ways, sondern auch nodes zuzulassen. Dann müsste der durchgehende way nicht mehr unterbrochen werden. 2. manche Situationen lassen sich in osm zur Zeit nicht gleichzeitig korrekt in Sinne der baulichen Situation und korrekt im Sinne des Routings darstellen. Beispiel 1 Die baulich korrekte Darstellung: C | | | A-B | | | D Problem: Von B kann man in alle Richtungen fahren. Von A kann man nach B und D fahren Von D kann man nach A und B fahren soweit kein Problem, aber: Von C kann man nur nach A und B fahren das heißt, die Restriction, auf dem Weg B-A nicht links nach D abbiegen zu dürfen, ergibt sich daraus, dass man von C kommt. Von B aus geht es. Vor Ort gelöst wurde das damit, dass es von B aus eine Linksabbiegespur gibt, die vor der Einmündung C beginnt und durch eine ununterbrochene Linie abgetrennt ist. Gemappt wurde: C | | | /-\ A--/---B \--+-/ | | | D Damit wird richtig geroutet, aber falsch dargestellt, auch wenn die Abweichung von der Realität erst in großen Maßstäben sichtbar wird. Ein anderes Beispiel, baulich korrekt wäre: C | | | A--B | | |\ | \ | | E P | | | / |/ | | D Man kan von A, B, C und D in alle Richtungen fahren, aber: Von D nach A und C nur über E Von D nach B nur über P Ein Wechsel der Spuren hinter E und P ist nicht möglich. Die Straße bildet aber wieder eine durchgehende Fläche. Gemappt wurde hier: A---B | | | | E P mit den jeweiligen Restrictions. Damit kann richtig geroutet werden, wenn man aber im Navi die Kreuzung aus Richtung A oder B sieht, sieht sie falsch aus. Eventuell kann das 2. Beispiel über mehrere via-nodes gelöst werden (was vermutlich keine SW kapiert). Für das erste Beispiel sehe ich keine Möglichkeit, der richtigen Darstellung und des richtigen Routens, denn eine Restriction würde auf die erste Einmündung bezogen werden. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
