Re: [Talk-de] Wie mappe ich Shops in Wohnhäusern?
Hi, Ich tage gebäude- (oder gelände-) spezifische Dinge immer am Polygon (Adresse, building:* usw.) Falls sich im Gebäude nur ein Geschäft findet, was auf die gesamte Fläche ausgedehnt ist, schreib ich die Daten an das Gebäude mit dran. Sind es mehrere Geschäfte werden diese als Node oder Polygon ins Gebäude gezeichnet, aber ohne die Adressdaten. Polygon immer dann, wenn ich auf Geschäfte im Geschäft treffe, wie in einem Mehrgeschäftegebäude ein Reisebüro mit Post-Shop. Für die Auswertung ist diese Schachtelung relativ einfach zu bewerkstelligen, wenn man PostgreSQL verwendet. Hier kann man Tags von umschließenden Polygonen abfragen. Ich mache dies bereits aktiv mit Adressen. Einziges Manko: Es dauert etwas, weswegen es für den Live-Betrieb nicht so ganz geeignet ist (und eine Vorberechnung für den ganzen Planet dauert etwas). In dem Zuge noch eine allgemeine Bitte (nicht nur an dich, sondern an all die, die es bisher so machen): Es hilft recht wenig, wenn man den Eingang mit den Adressdaten versieht und dann die Geschäfte drum rum verteilt. (auch wenn es schön aussieht) Man kann zwar zu einem Punkt die nächstgelegene Adresse berechnen (übrigens auch etwas Zeitaufwand), jedoch ist dies häufig FALSCH, weil irgendein Haus in der Gegend des Geschäfts gemappt wurde... Die zuverlässigste Methode ist, wenn das Geschäft/Haus selber die Adresse hat oder ein umschließendes Polygon! Für Eingänge bin ich persönlich soundso für den Tag building=entrance MfG Andreas Am 30.03.2011 23:05, schrieb ben: Hallo! Habe bis jetzt immer eine Fläche gezeichnet und building=yes gesetzt. Vor das Gebäude habe ich einen Punkt gesetzt und den zum shop mit allem pipapo gemacht. Jetzt sieht das Rendering aber total bekloppt aus, weil Hausnummern zweimal erscheinen sobald a) der Shop keine Bezeichnung hat oder b) das Icon sich mit einem anderen überschneiden würde. Beispiel hier: http://www.openstreetmap.org/?lat=51.320525lon=12.342349zoom=18layers=M Nun meine Frage: Wie mappt ihr sowas? Grüße, ben -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie mappe ich Shops in Wohnhäusern?
Hallo, vielen Dank für eure Auskunft. Wenn ich die Nodes in das Gebäude setze wird mir Mapnik aber trotzdem noch zwei Zahlen rendern, nur eben im Gebäude, oder? Grüße, ben 2011/3/31 M∡rtin Koppenhoefer dieterdre...@gmail.com Am 31. März 2011 00:08 schrieb Bartosz Fabianowski bart...@fabianowski.eu : Alternativ könnte man auch multipolygon-relationen für die Geschäfte machen (mit einem outer way). Ein Multipolygon dient dazu, Löcher in Gebiete zu schneiden, etwa Innenhöfe oder Enklaven. Zur Gruppierung von Nodes sind Multipolygone explizit *nicht* gedacht. es geht mir nicht um das Gruppieren von Nodes sondern um Zuweisung von tags zu einer area. Gruß Martin ___ 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] Wie mappe ich Shops in Wohnhäusern?
Am 30. März 2011 23:05 schrieb ben b...@nerdlabor.de: Habe bis jetzt immer eine Fläche gezeichnet und building=yes gesetzt. Vor das Gebäude habe ich einen Punkt gesetzt und den zum shop mit allem pipapo gemacht. Jetzt sieht das Rendering aber total bekloppt aus, weil Hausnummern zweimal erscheinen sobald a) der Shop keine Bezeichnung hat oder b) das Icon sich mit einem anderen überschneiden würde. Beispiel hier: http://www.openstreetmap.org/?lat=51.320525lon=12.342349zoom=18layers=M Nun meine Frage: Wie mappt ihr sowas? Ich verwende dafür die building-Relation.[1] Adressdaten kommen bei mir nur an den Hausumriss. [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] n paar Fragen
Am 30.03.2011 16:10, schrieb Thomas Ineichen: Einfacher Fall in der Realität: Gebäude mit einer Adresse, alle Eingänge des Gebäudes und die Läden darin haben auch diese Adresse. Umsetzung in OSM: Gebäudeumriss mit Adress-Tags versehen, Nodes für die Läden ins Innere der Fläche und ggf. Eingänge in die Umrandung setzen. Einmal mehr plädiere ich dafür, dass *jedes* Geschäft/Node innerhalb des Gebäudes mit der kompletten Adresse getagged wird. Gerade bei Seiten wie der OLM ist dies sehr praktisch: Bei der OLM ist es praktisch, dafür rendert halt dann die nächste Anwendung die Adresse mehrfach oder zeigt sonst ein unerwünschtes Verhalten. Anwendungen die Daten vorzukauen geht nur bis zu einem gewissen Punkt. Letztlich bleibt nur eine Lösung, wenn man in jedem Anwendungsfall sinnvolles Verhalten will: Intelligentere Software. Wohlgemerkt: Bei einer idealen Software funktionieren beide Varianten. Bei einfacher gestrickten Anwendungen funktionieren beide Varianten nicht perfekt, nur zeigt sich das eben auf unterschiedliche Weise. Inhaltlich falsch ist weder die Variante mit nur einer Adresse noch die mit Adresskopie. Ich persönlich spreche mich in so einer Situation schlicht für diejenige Methode aus, die weniger Mappingaufwand bedeutet. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie mappe ich Shops in Wohnhäusern?
Meiner Meinung nach gibt es doch genau für das Verbinden von Objekten zu einer Einheit Relationen. So eine site oder building-Relation erspart hier eine Menge Rechenzeit und macht die Sache eindeutig. Nimm bspw. die Kantine im Schulgebäude, das wiederum im Schulgelände ist, wobei das Gelände die Adresse hat. Da müsste man dann schon doppelt die Berechnung ausführen. Evtl. gibts auch Fälle, wo man das noch häufiger machen muss. Auf der anderen Seite hat man aber auch einfach POI-Nodes, die wirklich keine Adressinformationen haben, für die man dann die Berechnungen umsonst macht. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO seit 19.1.2011 nicht geupdated
http://dev.openstreetmap.de/aio/europa-daily/ Ab heute wird einmal pro Woche eine Europakarte OHNE zusätzliche Layer berechnet. Grüße Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS: Gespraech zur Zusammenarbeit OSM/OpenAddresses
Hallo, auf Anregung von Christian Karrié vom OpenAddresses-Projekt wollen wir auf der FOSSGIS-Konferenz naechste Woche in Heidelberg mal zusammensitzen und ueberlegen, wie man die Harmonisierung von OpenAddresses und OpenStreetMap voranbringen kann. Da gab es ja immer mal wieder unbeabsichtigtes Durcheinander in der Vergangenheit. Der geplante Termin dafuer ist Mittwoch 12:00 im Seminarraum 2.401 im Gebaeude 227. Wer sich fuer das Thema interessiert, ist herzlich eingeladen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Inspector MP
Hi, hier mein Kommentar zum neuen OSM-Inspector Multipolygone: (1) bei Grenzen die als type=boundary getaggt sind sollte keine Warnung kommen. Der Tag ist etabliert und laut taginfo 90.000 mal in Gebrauch, bietet außerdem mehr Möglichkeiten (siehe admin_centre). (2) touching inner rings sollten nicht als Fehler gemeldet werden. Angrenzende Flächen sind in der Kartografie schliesslich nicht ungewöhnlich. (3) Den Punkt Context bitte besser erläutern Ansonsten: Danke für die Arbeit. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Hi! On Thu, Mar 31, 2011 at 11:34:24AM +0200, Chris66 wrote: hier mein Kommentar zum neuen OSM-Inspector Multipolygone: (1) bei Grenzen die als type=boundary getaggt sind sollte keine Warnung kommen. Der Tag ist etabliert und laut taginfo 90.000 mal in Gebrauch, bietet außerdem mehr Möglichkeiten (siehe admin_centre). Nicht alles, was beim OSMI angezeigt wird ist auch gleich eine Warnung. Ob Du die Daten, die der OSMI anzeigst dafür nutzt, irgendwas zu tun, bleibt Dir überlassen. Du kannst die Layer, die für Dich nicht relevant sind, einfach ausblenden. Die Unterscheidung ist für Software, die Multipolygone verarbeitet und im Hinblick auf einen zukünftigen echten Multipolygon-Datentyp wichtig. Es wäre schön, wenn es nur genau einen Tag gibt, den man beachten muss, wenn man sowas macht. (2) touching inner rings sollten nicht als Fehler gemeldet werden. Angrenzende Flächen sind in der Kartografie schliesslich nicht ungewöhnlich. Touching inner rings sind ein Problemfall bei der Verwendung von Multipolygonen. Wenn man das dabei nicht richtig beachtet, dann bekommt man ungültige Multipolygone nach Simple Feature Standard. Daher wird das hier hervorgehoben. Und ja, man kann das richtig verarbeiten, osmium/osmjs kann das z.B. Aber ich fürchte viele Software wird da auf die Nase fallen. (3) Den Punkt Context bitte besser erläutern Zeigt einfach weitere Detaildaten an, die einem manchmal helfen, Fehler zu finden. 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] OSM Inspector MP
Am 31.03.2011 11:49, schrieb Jochen Topf: (2) touching inner rings sollten nicht als Fehler gemeldet werden. Angrenzende Flächen sind in der Kartografie schliesslich nicht ungewöhnlich. Touching inner rings sind ein Problemfall bei der Verwendung von Multipolygonen. Wenn man das dabei nicht richtig beachtet, dann bekommt man ungültige Multipolygone nach Simple Feature Standard. bei OSM ist es aber üblich den inner-Rings Tags für die innere Fläche zu verpassen. Beispiel: outer = Waldgebiet inner1 = Acker inner2 = Heide Der Acker grenzt direkt an die Heide. Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? +---+ | Wald | | ++-+| | || || | | Acker | Heide || | || || | ++-+| | | +---+ Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie mappe ich Shops in Wohnhäusern?
Mhhh... ich hab schon einige Gebäude mit building-Relationen getaggt... Hab aber noch nicht ausprobiert, wie osm2pgsql damit umgeht (wichtig ist ja, dass dann auch alle Tags an den Polygonen, Linien und Punkten zur Verfügung stehen und das war vor einem Jahr noch nicht so (hatte es mit den ÖPNV-Relationen in Ilmenau ausprobiert) Am 31.03.2011 10:37, schrieb Henning Scholland: Meiner Meinung nach gibt es doch genau für das Verbinden von Objekten zu einer Einheit Relationen. So eine site oder building-Relation erspart hier eine Menge Rechenzeit und macht die Sache eindeutig. Nimm bspw. die Kantine im Schulgebäude, das wiederum im Schulgelände ist, wobei das Gelände die Adresse hat. Da müsste man dann schon doppelt die Berechnung ausführen. Evtl. gibts auch Fälle, wo man das noch häufiger machen muss. Auf der anderen Seite hat man aber auch einfach POI-Nodes, die wirklich keine Adressinformationen haben, für die man dann die Berechnungen umsonst macht. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] n paar Fragen
Am 31. März 2011 00:30 schrieb Wolfgang wolfg...@ivkasogis.de: Mit Auswertung meine ich nicht nur Renderer, sondern auch andere Möglichkeiten, z.B. Statistik-Programme, Router, Adress -was-weiß-ich- Auswertungen ich auch Eben nicht. Das Multipolygon wird in erster Linie vom Renderer ausgewertet, was im vorliegenden Fall nicht nötig ist. wie kommst Du da drauf? Das Multipolygon ist ein Datentyp, der von allen Anwendungen ausgewertet werden kann, und nicht aufs Rendering beschränkt. Zugehörigkeit allen Objekten zugewiesen. Das einzige, was den Renderer bei der site interessieren sollte, ist der Node mit der Rolle label. dazu gibt es verschiedene Ansichten. M.E. bietet die Site auch den Vorteil, den Hauptzugang zu kennzeichnen, die Stelle wo man Tickets kaufen kann, etc. Welche der Rollen sich bei der Site durchsetzen werden ist nicht absehbar, und gerade gegen Label gb es zuletzt auf Tagging auch Opposition. Das geht, wenn jede Halle mit Adresse Fa. XY getaggt wird. Damit würde aber nicht mehr klar sein, wo jetzt die Adresse eigentlich ist, weil jedes Gebäude die Adresse haben müsste. meistens haben bei solch großen Geländen die einzelnen Gebäude und Hallen eigene Adressen, zumindest sowas wie Haus F. Ich könnte es noch weiter komplizieren, auf dem Gelände gibt es auch Sportplätze. Wenn ich ein Multipolygon um das ganze Gelände ziehe, muss ich die Sportplätze ignorieren, sonst würde ich sie mit inner ausschließen. warum? Ein Multipolygon sollte genau das umfassen, was auch durch die Tags beschrieben ist. Wenn zu einer Schule auch Sportplätze gehören, dann darf man die natürlich nicht ausschließen in dem Multipolygon, das die Schule beschreibt. Eigentlich sollte es aber umgekehrt sein, für das Zeichnen sollte der Router wissen, dass hier ein Multipolygon ist, aus dem die Sportplätze ausgeschlossen werden, damit man sie in einer anderen Signatur malen kann. die Darstellung wird anders geregelt: zeichne erst das Größere, dann das Kleinere, und das Rendering passt (wird bereits so gemacht in Mapnik). Geometrisch korrekt und unabhängig von einer stillschweigend vorausgesetzten Layer-Logik des Renderers müsste ich ein Multipolygon um das Schulgelände ziehen und alle Polygone, die dort vorhanden sind, als inner bezeichnen, also Gebäude, Sportplätze etc. Zuordnungsmäßig korrekt müsste ich ein Multipolygon um das Gelände ziehen und hoffen, dass die anderen Flächen später gerendert werden, damit sie sichtbar sind, oder ihnen einen Layer explizit zuweisen. -1, Du machst Dir m.E. Sorgen, die unbegründet sind, weil die Lösung bereits implementiert ist. Nein, genau das nicht. Ich glaube, das ist der Punkt, an dem wir aneinander vorbeireden. Die site sagt nur, dass die aufgezählten Objekte, egal welchen Typs und welcher Geometrie, zusammengehören. Der Renderer kann es in Spezialfällen auswerten, muss es in der Regel aber nicht. (Abgesehen von label, s.o.) wie bereits in einer vorigen Mail geschrieben, wichtig ist hier Typ, weil Nodes für Multipolygone nicht passen. Praktisch sind es aber wohl eher seltene Fälle, wo Nodes wirklich mehr Sinn machen als Flächen, und trotzdem ausgeschlossen werden müssen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie mappe ich Shops in Wohnhäusern?
Am 31. März 2011 09:35 schrieb Andreas Neumann andr-neum...@gmx.net: Für die Auswertung ist diese Schachtelung relativ einfach zu bewerkstelligen, wenn man PostgreSQL verwendet. Hier kann man Tags von umschließenden Polygonen abfragen. Ich mache dies bereits aktiv mit Adressen. Einziges Manko: Es dauert etwas, weswegen es für den Live-Betrieb nicht so ganz geeignet ist (und eine Vorberechnung für den ganzen Planet dauert etwas). Wie machst Du das praktisch? Gehst Du vom POI aus und suchst Polygone in der Umgebung die ihn enthalten, oder suchst Du bei allen Polygonen, die Adressdaten haben, nach bestimmten POIs im Inneren? Vermutlich ist das 2. deutlich performanter, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Am 31. März 2011 12:02 schrieb Chris66 chris66...@gmx.de: Touching inner rings sind ein Problemfall bei der Verwendung von Multipolygonen. Wenn man das dabei nicht richtig beachtet, dann bekommt man ungültige Multipolygone nach Simple Feature Standard. bei OSM ist es aber üblich den inner-Rings Tags für die innere Fläche zu verpassen. Beispiel: outer = Waldgebiet inner1 = Acker inner2 = Heide Der Acker grenzt direkt an die Heide. Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? nein, natürlich nicht, das wäre ja topologisch falsch. Was man machen könnte wäre entweder einen weiteren way zu überlagern, der beide Nutzungen enthält und nur als inner dient, oder weitere 2 Multipolygon-relationen für die beiden inneren Nutzungen (jeweils nur mit outer), so dass maeinen weiteren n aus den beiden Umrissen ohne die gemeinsame Grenze einen inner ring für das große (hier Wald) Multipolygon machen kann. Beides finde ich ein bisschen overkill weil es derzeit ja auch einfach geht (indem man die inneren Ringe sich berühren lässt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO seit 19.1.2011 nicht geupdated
Am 31. März 2011 11:26 schrieb fla...@googlemail.com fla...@googlemail.com: http://dev.openstreetmap.de/aio/europa-daily/ Ab heute wird einmal pro Woche eine Europakarte OHNE zusätzliche Layer berechnet. gibt es schon Ergebnisse, wie groß diese Karte unkomprimiert als gmapsupp.img ist? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Hallo Chris, bei OSM ist es aber üblich den inner-Rings Tags für die innere Fläche zu verpassen. Beispiel: outer = Waldgebiet inner1 = Acker inner2 = Heide Der Acker grenzt direkt an die Heide. Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? +---+ | Wald | | ++-+| | || || | | Acker | Heide || | || || | ++-+| | | +---+ Wenn Du möchtest, dass der OSMI keine Warnmeldung mehr anzeigt, dann musst Du 3 Relationen erstellen: WWW W Wald W WAAXHHW WA X HW WA Acker X Heide HW WA X HW WAAXHHW W W WWW Relation 1: Wald mit Way W als outer und Ways A, H als inner Relation 2: Acker mit Ways A, X als outer Relation 3: Heide mit Ways H, X als outer Die Ways selber erhalten keine Tags. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Am 31.03.2011 13:24, schrieb Thomas Ineichen: Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Wenn Du möchtest, dass der OSMI keine Warnmeldung mehr anzeigt, dann musst Du 3 Relationen erstellen: WWW W Wald W WAAXHHW WA X HW WA Acker X Heide HW WA X HW WAAXHHW W W WWW Relation 1: Wald mit Way W als outer und Ways A, H als inner Relation 2: Acker mit Ways A, X als outer Relation 3: Heide mit Ways H, X als outer Die Ways selber erhalten keine Tags. Verstehe. Man ersetzt also ein einfaches durch 3 advanced MPs. Dies entspricht aber nicht dem OSM Prinzip alles so einfach wie möglich zu realisieren. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenlistenabfrage
Es ist jetzt schon ne Weile her, als ich mal mit der Straßenlistenabfrage auf albspotter.eu eine sehr schoene Strassenliste fuer eine Stadtteilkarte generiert habe. Leider geht das seit geraumer Zeit nicht mehr. Gibt es mittlerweile eine andere Moeglichkeit, eine solche Strassenliste entweder online oder aus einem lokalen File zu generieren? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
On Thu, Mar 31, 2011 at 12:02:39PM +0200, Chris66 wrote: Am 31.03.2011 11:49, schrieb Jochen Topf: (2) touching inner rings sollten nicht als Fehler gemeldet werden. Angrenzende Flächen sind in der Kartografie schliesslich nicht ungewöhnlich. Touching inner rings sind ein Problemfall bei der Verwendung von Multipolygonen. Wenn man das dabei nicht richtig beachtet, dann bekommt man ungültige Multipolygone nach Simple Feature Standard. bei OSM ist es aber üblich den inner-Rings Tags für die innere Fläche zu verpassen. Beispiel: outer = Waldgebiet inner1 = Acker inner2 = Heide Der Acker grenzt direkt an die Heide. Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Nein. Aus meiner Sicht ist das völlig ok und Du musst da auch nichts machen. Der OSM Inspector weist auf eine möglicherweise problematische Situation hin. Das hilft z.B. wenn ein Tool ein Multipolygon nicht richtig darstellt und man sich fragt warum. Dann kann man im OSMI nachschauen und erkennt dadurch vielleicht, dass das Tool diesen Fall nicht richtig behandelt. Es heisst nicht, dass unbedingt an den Daten was gemacht werden muss. 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] OSM Inspector MP
Am 31.03.2011 14:11, schrieb Chris66: Am 31.03.2011 13:24, schrieb Thomas Ineichen: Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Wenn Du möchtest, dass der OSMI keine Warnmeldung mehr anzeigt, dann musst Du 3 Relationen erstellen: WWW W Wald W WAAXHHW WA X HW WA Acker X Heide HW WA X HW WAAXHHW W W WWW Relation 1: Wald mit Way W als outer und Ways A, H als inner Relation 2: Acker mit Ways A, X als outer Relation 3: Heide mit Ways H, X als outer Die Ways selber erhalten keine Tags. Verstehe. Man ersetzt also ein einfaches durch 3 advanced MPs. Dies entspricht aber nicht dem OSM Prinzip alles so einfach wie möglich zu realisieren. ;-) Um das mal als 'einfacher Mapper' zu übersetzen: Das ist doch krank! Da macht doch bald keiner mehr mit. Dann steh^sitzen paar Hanseln auf tollen Datenmodellen die echten Daten aber verfallen da da draussen keiner mehr ist der was erfasst, aktuell hält. Von den x00.000 Leuten bleiben dann noch paar übrig. Aber die Masse die Daten einfach erfassen kann ist doch gerade die Stärke, das einzige auf das man bauen kann. Besser das sich die Geodatenspezialisten Algorithmen ausdenken wie man aus existierenden 'Fuzzy' Daten klare Strukturen errechnet (erahnt:-). Oben genanntes Multi-Multipolygon kann man doch einfach aus Wald aussen innen drüber Acker: 'Aha, da ist ein Loch im Wald' ausrechnen. Die Wikipedia verfällt auch wegen wachsendem Perfektionismus, diesem und jenem, Löschen, ... letztlich vergessener Wurzeln. Das sowas (wie auch OSM) sich entwickelt ist klar, es wird komplexer, doch sollte man den rechten Moment nicht verpassen auf die Bremse zu treten und 'komplex genug' sagen. Bischen einseitig mein Text (ich weis das Realität abbilden halt kompliziert wird), tendenziell dürfte ich richtig liegen. Oder man macht die Editoren so komplex das sie das alles dem Benutzer ganz einfach machen. Acker in den Wald gemalt: Fragen ob er das ernst meint und die multipolygone selbst erstellen. Letztlich sind aber die Stellen wo ich was ändern wollte und es kompliziert wurde gerade jene wo nodes von mehreren Teilen genutzt wurden, oder relationen (z.B. Wanderwege) genutzt wurden und ich nicht wusste ob ich was kaputt mache. Also auch nix rechtes für Normalmapper. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO seit 19.1.2011 nicht geupdated
On 31.03.2011 13:18, M∡rtin Koppenhoefer wrote: Am 31. März 2011 11:26 schrieb fla...@googlemail.com fla...@googlemail.com: http://dev.openstreetmap.de/aio/europa-daily/ Ab heute wird einmal pro Woche eine Europakarte OHNE zusätzliche Layer berechnet. gibt es schon Ergebnisse, wie groß diese Karte unkomprimiert als gmapsupp.img ist? Auf dem Link oben ist eine 3.9Gb Datei :-( Wird echt Zeit, das es ein Garmin Gerät mit einem FS gibt, welches 4Gb Dateien kann. Ich bin öfters in europa unterwegs und hätte gerne eine Karte und ned 20 verschiedene. Ist zwar reiner Komfort, aber dennoch. Gruß Martin MfG, Lars Schimmer -- - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO seit 19.1.2011 nicht geupdated
Am 31.03.2011 15:25, schrieb Lars Schimmer: Wird echt Zeit, das es ein Garmin Gerät mit einem FS gibt, welches4Gb Dateien kann. Ich bin öfters in europa unterwegs und hätte gerne eine Karte und ned 20 verschiedene. Ist zwar reiner Komfort, aber dennoch. Daran glaubst du doch nicht wirklich? Garmin hat dafür überhaupt keinen Grund. Sie selber haben maximal die Topo USA die in Richtung 4GB geht. Daran dürfte sich auch in Zukunft wenig ändern. Weiterhin ist Garmin in die Richtung viele einzelne Kartendateien zu erlauben. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Am 31.03.2011 15:07, schrieb Jochen Topf: Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Nein. Aus meiner Sicht ist das völlig ok und Du musst da auch nichts machen. Der OSM Inspector weist auf eine möglicherweise problematische Situation hin. Das hilft z.B. wenn ein Tool ein Multipolygon nicht richtig darstellt und man sich fragt warum. Dann kann man im OSMI nachschauen und erkennt dadurch vielleicht, dass das Tool diesen Fall nicht richtig behandelt. Es heisst nicht, dass unbedingt an den Daten was gemacht werden muss. Das Problem ist, dass die Leute die Fehlerlisten abarbeiten und alles ändern. Ich hab gestern auch schon 2 MPs entsprechend bearbeitet. Also: Hinweis ist ok, aber es sollte nicht als Fehler tituliert werden. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS: druckbare Version des Programms LTs
Hi, einige von euch sind ja bei der diesjährigen FOSSGIS in Heidelberg mit dabei. Unter dem folgenden Link findet ihr eine druckbare Version des Programms: http://www.fossgis.de/konferenz/2011/fossgis_programm.pdf Ansonsten hier noch einmal ein Aufruf Lightning Talks (fünfminütige Kurzpräsentationen) für die FOSSGIS bei Frederik oder auch mir einzureichen. Weitere Informationen zur Konferenz findet ihr hier: http://www.fossgis.de/konferenz/2011/ Wir sehen uns in Heidelberg! viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Am 31.03.2011 16:49, schrieb Chris66: Am 31.03.2011 15:07, schrieb Jochen Topf: Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Nein. Aus meiner Sicht ist das völlig ok und Du musst da auch nichts machen. Der OSM Inspector weist auf eine möglicherweise problematische Situation hin. Das hilft z.B. wenn ein Tool ein Multipolygon nicht richtig darstellt und man sich fragt warum. Dann kann man im OSMI nachschauen und erkennt dadurch vielleicht, dass das Tool diesen Fall nicht richtig behandelt. Es heisst nicht, dass unbedingt an den Daten was gemacht werden muss. Das Problem ist, dass die Leute die Fehlerlisten abarbeiten und alles ändern. Ich hab gestern auch schon 2 MPs entsprechend bearbeitet. Also: Hinweis ist ok, aber es sollte nicht als Fehler tituliert werden. Vielleicht könnte man Werte/Noten vergeben: harmlos, schlimm,... 1,2,3,4,5,6 Ich hatte mir das die Tage auch angesehen, nicht gemerkt das man da _viele_ Gruppen auswählen kann und halt die paar Probleme der ersten Seite in meiner Gegend 50kmx50km 'gelöst', selbstüberschneidende Wege oder so. Nachdem ich dann merkte das das nur ein Sandkörnchen war verlor ich etwas sehr die Lust. Wenn man das zusätzlich bischen Endusertauglich nach großem/kleinem Problem gruppieren könnte wäre es reizvoller. Also oben die Dropdownliste 'View': evtl. eine darüberliegende Ebene wo man zwischen themenorientierten Gruppen und Wichtigkeitsorientierten auswählen kann. Ansich ja eine prima Sache, automatisch Bugs finden. Mit passender Auswertung könnte man sogar 'ne Seite im Wiki machen die Mapper über typische Fehler aufklärt, oder in z.B. JOSM was einbauen was typische Fehler (halb)automatisch korrigieren kann. Z.B. bei Selbstüberschneidende Wege/Knoten doppelt: nur diesen Weg zum bearbeiten erlauben (sozusagen maximaler Filter) so daß men leicht knoten rausziehen kann ohne die erst aus anderen Wegen zu entfernen. Wäre man in Sekunden fertig. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
fla...@googlemail.com schrieb: So nun mal ne Fehlerliste für Deutschland .. zZ 42 Fehler. Berechnet mit Gary68-Tool. C61.XML XML k=mode v=X k=dist v=10 k=check v=route:ferry k=against v=highway:bridleway k=against v=highway:cycleway k=against v=highway:footway k=against v=highway:motorway k=against v=highway:motorway_link k=against v=highway:path k=against v=highway:pedestrian k=against v=highway:primary k=against v=highway:primary_link k=against v=highway:residential k=against v=highway:road k=against v=highway:secondary k=against v=highway:service k=against v=highway:services k=against v=highway:steps k=against v=highway:tertiary k=against v=highway:track k=against v=highway:trunk k=against v=highway:trunk_link k=against v=highway:unclassified k=against v=junction:roundabout k=against v=man_made:pier /XML Anregungen ? Einfach melden Ich würde das man_made=pier rauslassen, da diese eher nicht als Fahrbahn oder routbare Strecke gelten Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
On Thu, Mar 31, 2011 at 04:49:52PM +0200, Chris66 wrote: Am 31.03.2011 15:07, schrieb Jochen Topf: Da soll man nun also die beiden inner-rings um 1 Meter auseinanderziehen auch wenn da in Realität kein Zwischenraum ist? Nein. Aus meiner Sicht ist das völlig ok und Du musst da auch nichts machen. Der OSM Inspector weist auf eine möglicherweise problematische Situation hin. Das hilft z.B. wenn ein Tool ein Multipolygon nicht richtig darstellt und man sich fragt warum. Dann kann man im OSMI nachschauen und erkennt dadurch vielleicht, dass das Tool diesen Fall nicht richtig behandelt. Es heisst nicht, dass unbedingt an den Daten was gemacht werden muss. Das Problem ist, dass die Leute die Fehlerlisten abarbeiten und alles ändern. Ich hab gestern auch schon 2 MPs entsprechend bearbeitet. Also: Hinweis ist ok, aber es sollte nicht als Fehler tituliert werden. Wo steht das denn mit dem Fehler? 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] OSM Inspector MP
Am 31.03.2011 18:45, schrieb Jochen Topf: Also: Hinweis ist ok, aber es sollte nicht als Fehler tituliert werden. Wo steht das denn mit dem Fehler? Hast recht, ist nur eine Warnung. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
Am 31.03.2011 18:13, schrieb malenki: fla...@googlemail.com schrieb: So nun mal ne Fehlerliste für Deutschland .. zZ 42 Fehler. Berechnet mit Gary68-Tool. C61.XML XML k=mode v=X k=dist v=10 k=check v=route:ferry k=against v=highway:bridleway k=against v=highway:cycleway k=against v=highway:footway k=against v=highway:motorway k=against v=highway:motorway_link k=against v=highway:path k=against v=highway:pedestrian k=against v=highway:primary k=against v=highway:primary_link k=against v=highway:residential k=against v=highway:road k=against v=highway:secondary k=against v=highway:service k=against v=highway:services k=against v=highway:steps k=against v=highway:tertiary k=against v=highway:track k=against v=highway:trunk k=against v=highway:trunk_link k=against v=highway:unclassified k=against v=junction:roundabout k=against v=man_made:pier /XML Anregungen ? Einfach melden Ich würde das man_made=pier rauslassen, da diese eher nicht als Fahrbahn oder routbare Strecke gelten Bedenke, dass es viele Personenfähren gibt, die über einen man_made=pier angebunden sind. man_made=pier sollte man in ein Touting mit einbeziehen, wenn man Fähren nutzen möchte. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector MP
Am 31.03.2011 17:10, schrieb Peter: Wenn man das zusätzlich bischen Endusertauglich nach großem/kleinem Problem gruppieren könnte wäre es reizvoller. Also oben die Dropdownliste 'View': evtl. eine darüberliegende Ebene wo man zwischen themenorientierten Gruppen und Wichtigkeitsorientierten auswählen kann. Hab' nochmal bischen reingeguckt: Ist ansich ja schon da, halt verteilt auf die vielen Gruppen. Man könnte die 'echten' Probleme warning/error zusätzlich in einer Gruppe zusammenfassen und so leichter zugänglich machen. Die Putzwilligen unter uns können dann leichter aufräumen. Anmerkung falls einer der Entwickler das liest: Bei Routing/unverbundene Wege wird z.B. ein parking_aisle markiert das nahe einer Straße enden würde. Diese Sorte Weg dürfte typischerweise oft nur an einem Ende angebunden sein, man könnte das per Regel(?) rausnehmen. Beispiel: http://www.openstreetmap.org/browse/way/105074370 Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Letzte Bitte für OSM-Stand zum Linuxtag
Heute erhielt ich noch einmal eine Mail von den Organisatoren des Linuxtages. Es wäre schön, wenn jemand den einen Stand organisieren würde... Gruß malenki Am Thu, 31 Mar 2011 19:52:52 +0200 schrieb Elke Moritz mor...@linuxtag.org: Hallo OpenStreetMap, hallo FOSSGIS! Beim Durchgehen durch die Liste der angemeldeten Projekte haben wir gesehen, dass sich bis jetzt weder OpenStreetMap noch FOSSGIS angemeldet haben. Seid Ihr dieses Jahr wieder dabei? Wollt Ihr wieder einen Stand zusammen mit Navit (bereits angemeldet) machen? Wenn ja, tragt Eure Projekte doch bitte bis Ende der Woche in unser virtuelles Konferenzzentrum ein: https://vcc.linuxtag.org Dann können wir mit den Newslettern loslegen und haben Eure Daten noch rechtzeitig bis zur Deadline für den gedruckten Katalog. Viele Grüße Elke Projects Team LinuxTag 2011 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Letzte Bitte für OSM-Stand zum Linuxtag
Hallo, malenki wrote: Heute erhielt ich noch einmal eine Mail von den Organisatoren des Linuxtages. Es wäre schön, wenn jemand den einen Stand organisieren würde... Also, ich bin dieses Jahr schon zu verplant, um noch zum LT hingehen zu koennen. Aber wenn irgendjemand einen Stand macht, dann mache ich gern Plakate und schicke Flyer und was man sonst so braucht. 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] Check für unverbundene route=ferry?
generell sind diese Checks nicht umbedingt Fehler. Am 30.03.2011 15:11, schrieb Henning Scholland: Am 30.03.2011 14:50, schrieb fly: Ich würde checken auf: * schneiden mit andern route=ferry. Das ist kein Fehler. Oder bist du schon mal unterwegs von einer Fähre auf die nächste umgestiegen? Ja auch das ! Hast Du recht, wobei ich dabei eher an Verzweigungen gedacht habe. Sollte aber mit dem unconnected first/last node check abgefangen werden. * schneiden mit coastline Führt zu vielen falschen Fehlern, wenn die Fähre zu einer Straße wird (Anleger). Fähre und Straße mit der coastline zu verbinden mache ich idR nicht, da coastline was recht sensibles ist. Ein Fähranleger schwimmt oder er ist die Küstenlinie alles andere macht keine Sinn ! Dort ist dann genau der Schnittpunkt. * schneiden mit highways mit gleichem layer. Ob man das extra checken muss? Sicher ist es ein Fehler, aber sowas wird doch bestimmt schon bei den highway-checks mit überprüft, oder? Ich kenne keinen aktuell laufenden check für die Küstenstraßen von Mittelmeer und Nord/Ostsee. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
fla...@googlemail.com schrieb: So nun mal ne Fehlerliste für Deutschland .. zZ 42 Fehler. Berechnet mit Gary68-Tool. C61.XML XML k=mode v=X k=dist v=10 k=check v=route:ferry k=against v=highway:bridleway k=against v=highway:cycleway k=against v=highway:footway k=against v=highway:motorway k=against v=highway:motorway_link k=against v=highway:path k=against v=highway:pedestrian k=against v=highway:primary k=against v=highway:primary_link k=against v=highway:residential k=against v=highway:road k=against v=highway:secondary k=against v=highway:service k=against v=highway:services k=against v=highway:steps k=against v=highway:tertiary k=against v=highway:track k=against v=highway:trunk k=against v=highway:trunk_link k=against v=highway:unclassified k=against v=junction:roundabout k=against v=man_made:pier /XML Anregungen ? Hier bin ich über tertiary_link gestolpert: http://www.openstreetmap.org/?lat=43.19412lon=27.710659zoom=19 Weiß nicht, ob man die obige Prüfliste oder das Tag korrigieren sollte... Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
fla...@googlemail.com schrieb: Anregungen ? Einfach melden Noch eins: Es gibt auch öfter Fähren, die direkt an Eisenbahnlinien angebunden sind. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] n paar Fragen
Hallo, Am Donnerstag 31 März 2011 12:56:31 schrieb M∡rtin Koppenhoefer: -1, Du machst Dir m.E. Sorgen, die unbegründet sind, weil die Lösung bereits implementiert ist. -1 Wir haben hier einen einfachen Fall, in dem wir davon ausgehen können, dass der Renderer eine stillschweigende Layer-Ordnung eingebaut hat. Das ist im Grunde nicht besser als als ein explizites layer=1. Und genau darauf läuft deine Lösung hinaus, wenn es sich eben nicht um Objekte wie landuse -/- sport -/- building handelt, sondern z.B. um einen größeren Fährterminal, auf dessen Gelände sich Parkplätze für Autos und Fahrräder befinden. Welche amenity schlägt jetzt die andere? Man könnte weitere Beispiele zimmern, wo es eben nicht so eindeutig geregelt ist. Ich glaube, mein Standpunkt ist damit deutlich geworden, auch wenn ich dich vermutlich nicht überzeugt habe. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS Videoaufzeichnungen – Helfer MacBook gesucht
Hallo, wie mittlerweile feststeht werden wir bei der FOSSGIS von einigen Vorträgen Videoaufzeichnungen anfertigen, damit alle, die aus irgendwelchen Gründen nicht anwesend sein können oder den Vortrag verpassen, ihn auch noch im Nachhinein ansehen können. Um das zu tun brauchen wir noch Helfer, die entweder den Schnittrechner oder eine Kamera bedienen. Mehr dazu und eine Liste zum Eintragen befindet sich im Wiki hier: http://wiki.openstreetmap.org/wiki/FOSSGIS_2011/Videomitschnitte/Liste Außerdem suchen wir noch ein MacBook mit Firewire-Anschluss für unser mobiles Setup, mit dem wir einzelne Vorträge bei Bedarf in den anderen beiden Sälen aufzeichnen wollen. Falls ihr uns ein solches Gerät bei der Konferenz zur Verfügung stellen könntet, würden wir uns sehr freuen, schreibt mir einfach eine E-Mail. Wer eine Kamera mit Firewire-Anschluss hat, kann diese ebenfalls gerne noch mitbringen, am besten kurz bei mir Bescheid sagen. Grüße, Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
