Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Moin, Christian Müller schrieb: http://de.wikipedia.org/wiki/Toponomastik klärt unser Missverständnis auf Die Seite schreibt, dass im deutschen 'Ortsname' doppelt verwendet wird, - zum einen als Synonym für Toponym (und genau dort sehe ich place=* angesiedelt) - zum anderen ///im Speziellen/// als Name einer Siedlungsstelle (dort siehst Du place=* offenbar) Letzteres grenzt zigtausende bisherige Verwendungen von place=* aus. place ist in OSM _nicht_ nur eine Siedlungsstelle. Auch, aber eben nicht nur. place values erfassen Toponyme in Größenordnungen von Kontinenten bis runter zu Waldlichtungen. Da ist keine Systematik erkennbar, bis auf eben den Fakt, dass es Toponyme erfasst. 1. Martin hat place als Synonym für Toponym (hä? Ein Hoch auf Wikipedia ...) nie angezweifelt, im Gegenteil, er hat es immer bestätigt als eine Örtlichkeit, sei es Siedlung, Flur, Gebiet, Region etc. 2. Wie kommst Du darauf, dass Martin place _nur_ als Name einer Siedlungsstelle belegen will? Aber der Name einer Siedlungsstelle ist eben _auch_ ein Toponym. 3. Kannst Du Dir nicht vorstellen, dass man für solch ein Toponym (einer Region) in OSM auch mal eine Ausdehnung benötigt? Wie soll man ein Toponym einer weitläufigen Region (Polynom ... quatsch ... Polygon) verarbeiten, wenn diese Information nur in einer einzigen Koordinate (node) in OSM enthalten ist, man aber nur einen (mehr oder weniger großen) Randbereich dieser Region bearbeitet? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Moin, Christian Müller schrieb: Am 13.09.2011 18:13, schrieb Martin Koppenhoefer: PS: Bitte nicht immer border schreiben, es heisst boundary. Ich spreche von der basisgeometrischen Grenze, dem mit 'border=*' getaggten way, der in OSM Grundlage von boundary-Relationen ist. Oh - muss ich jetzt alle meine boundary=* - Keys umschreiben? =-O Der way, der in OSM als Grenze getaggt wird, wird mit boundary=* getaggt, _nicht mit border=*_! Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
On 11-07-07 13:52, Jacques Nietsch wrote: Das Gerät könnte interessant sein. http://www.pocketnavigation.de/news/view_2792__medion-zeigt-erstes-eigenes-outdoor-navi-auf-der-ifa/1.1.88.html Mir fehlt bisher eine Übersicht, welche Navis für OSM geeignet sind. Welche Merkmale gibt es überhaupt? * Unterstützung von OSM-Kartenmaterial In welcher Form werden da Daten extrahiert, eingedampft und eingespielt? * Überhaupt Unterstützung von OSM-Daten (z.B. POI) * Tauglichkeit zum GPS-Tracking Ich habe versuchsweise mal http://wiki.openstreetmap.org/wiki/Liste_der_Navigationsger%C3%A4te angelegt - vielleicht lohnt es sich, das zu ergänzen. Bis zum Advent sollte man da eine Liste finden, was als Weihnachtsgeschenk taugt :-) Auf Vergleichsseiten wie http://geizhals.at/deutschland/?cat=gps finde ich bisher noch nichts, das als Merkmal direkt nutzbar wäre. Indirekt wären USB oder (Mikro-)SD vermutlich Mindestanforderungen, denn über BlueTooth will man sich einen Import wohl nicht antun. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Hallo Martin, prinzipiell ist diese Liste gut, nur was ist mit den allgemein eingesetzten Garmin- Navis? Die unterstützen erstmal gar nicht OSM- Kartenmaterial, aber sind trotzdem die meist genutzten Geräte und geeignet, da hierfür die meisten Karten erstellt werden. Am 15.09.2011 09:51, schrieb Martin Trautmann: Mir fehlt bisher eine Übersicht, welche Navis für OSM geeignet sind. Welche Merkmale gibt es überhaupt? * Unterstützung von OSM-Kartenmaterial -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
On 11-09-15 10:59, Carsten Schwede wrote: Hallo Martin, prinzipiell ist diese Liste gut, nur was ist mit den allgemein eingesetzten Garmin- Navis? Die unterstützen erstmal gar nicht OSM- Kartenmaterial, aber sind trotzdem die meist genutzten Geräte und geeignet, da hierfür die meisten Karten erstellt werden. Das wären Geräte mit Eignung für GPS-Tracking - wobei man hier vielleicht noch Kategorien verwenden sollte: POI-Erfassung (Koordinaten) POI-Benamsung (z.B. Straße und Hausnummer) GPS-Tracking (Koordinaten + Zeit) Komfort-Tracking mit allem was das Herz begehrt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_
Am 14. September 2011 19:06 schrieb Christian Müller cmu...@gmx.de: +1 Es ist mehr ein Editor-Ding: b) erzeuge ein multipolygon, addiere die n Segmente als outer weise --dem multipolygon-- die Flächen-Tags des Originals zu Die Funktion b) gibt es in Editoren bisher nicht - das macht MapperIn zeitraubend step-by-step. b) gab es mal (convert to multipolygon), ist aber irgendwie wieder aus meinem JOSM verschwunden. (Vielleicht ein plugin, das ich deinstalliert habe? Weiss jemand näheres?). Was es gibt ist SHIFT+A - create multipolygon, dabei werden allerdings ausser type=multipolygon keine Tags gesetzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Martin Trautmann [mailto:tr...@gmx.de] schrieb am Donnerstag, 15. September 2011 14:52 Ich habe versuchsweise mal http://wiki.openstreetmap.org/wiki/Liste_der_Navigationsger%C3%A4te angelegt - vielleicht lohnt es sich, das zu ergänzen. Es gibt ja schon diese nach Systemen gegliederten und detaillierten Tabellen http://wiki.openstreetmap.org/wiki/Software/Mobile z.B. für Android auch in Deutsch http://wiki.openstreetmap.org/wiki/DE:Android Wäre es da nicht sinnvoller diese Seiten zu ergänzen statt parallel eine oder mehrere neue aufzuziehen? Willi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
On 11-09-15 12:41, Willi wrote: Es gibt ja schon diese nach Systemen gegliederten und detaillierten Tabellen http://wiki.openstreetmap.org/wiki/Software/Mobile z.B. für Android auch in Deutsch http://wiki.openstreetmap.org/wiki/DE:Android Wäre es da nicht sinnvoller diese Seiten zu ergänzen statt parallel eine oder mehrere neue aufzuziehen? Hm, ganz im Gegenteil: Solche Information mag inhaltlich passen und sollte mit einander vernetzt werden. Gerade die genannten Beispiele zeigen aber Software-Aspekte, statt der zugehörigen Hardware. Gibt es überhaupt ein reines Navi, das mit Android läuft? Auch mobile Software richtet sich eher an PDAs, Smartphones, Tablets und Laptops, und nicht an Navis. Gerade dort sehe ich also kaum Überlapplung. Wo es hingegen Überlappung gibt, da sollte man zusammenlegen oder sauber trennen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Hallo. Am 15.09.2011 09:51, schrieb Martin Trautmann: Ich habe versuchsweise mal http://wiki.openstreetmap.org/wiki/Liste_der_Navigationsger%C3%A4te angelegt - vielleicht lohnt es sich, das zu ergänzen. Ich habe jetzt keine belastbaren Hintergrund-Infos gefunden aber verstehe ich das richtig dass das genannte Medion-Gerät zwar mit OSM-Karten vorinstalliert ist, man aber nur mit dem beigelegten Gutschein (einmalig?) von Medion neue OSM-Karten laden kann? Wenn das so ist, ist das ja (abgesehen von dem vermutlich besseren Kartenmaterial) keinen deut mehr OSM-kompatibel als alles andere auch. OSM-Kompatibel bedeutet doch irgendwie auch dass man (wenn man will) tagesaktuelle OSM-Karten selbst draufspielen kann. Ich fände so eine Liste zwar schon auch sinnvoll, aber nur wenn nachher etwas anderes als das allseits bekannte Garmin geht mit (teilweise drastischen) Einschränkungen, alle anderen gehen nicht steht. Gruß, Bernd -- Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails noch bei Kerzenlicht geschrieben haben... - Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000 signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Am 15.09.2011 13:34, schrieb Martin Trautmann: On 11-09-15 12:41, Willi wrote: Es gibt ja schon diese nach Systemen gegliederten und detaillierten Tabellen http://wiki.openstreetmap.org/wiki/Software/Mobile z.B. für Android auch in Deutsch http://wiki.openstreetmap.org/wiki/DE:Android Wäre es da nicht sinnvoller diese Seiten zu ergänzen statt parallel eine oder mehrere neue aufzuziehen? Hm, ganz im Gegenteil: Solche Information mag inhaltlich passen und sollte mit einander vernetzt werden. Gerade die genannten Beispiele zeigen aber Software-Aspekte, statt der zugehörigen Hardware. Gibt es überhaupt ein reines Navi, das mit Android läuft? Auch mobile Software richtet sich eher an PDAs, Smartphones, Tablets und Laptops, und nicht an Navis. Gerade dort sehe ich also kaum Überlapplung. Wo es hingegen Überlappung gibt, da sollte man zusammenlegen oder sauber trennen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Dem würde ich auch zustimmen. Ich fänd es nur wichtig, dass in dem Eintrag auch ein Querverweis zu den Handys mit drin steht (und andersrum), weil sie von der praktischen Anwendung her schon vergleichbar sind. Grüße Ralf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_
Am 15. September 2011 12:01 schrieb Martin Koppenhoefer dieterdre...@gmail.com: b) gab es mal (convert to multipolygon), ist aber irgendwie wieder aus meinem JOSM verschwunden. (Vielleicht ein plugin, das ich deinstalliert habe? Weiss jemand näheres?). Was es gibt ist SHIFT+A - create multipolygon, dabei werden allerdings ausser type=multipolygon keine Tags gesetzt. Das b) gibt es: ist ein Plugin für JOSM und heisst multipoly-convert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Turn restriction Probleme in Baden-Württemberg
Hallo, habe gerade Karten für Navit aus osm Daten selbst gebaut. Dabei sind mir eine Reihe von Warnungen aufgefallen. Kann jemand was damit anfangen? OSM Warning:http://www.openstreetmap.org/browse/relation/29221 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/61165 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/72986 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/72989 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/72990 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/93201 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/139010 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/199136 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/240335 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/240336 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/348820 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/365206 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/365207 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/367240 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/391263 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/391264 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/393521 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/445532 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/445635 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/445638 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/456921 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/539243 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/569796 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/721637 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/721651 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/932612 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/932647 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/964179 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1101630 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/1105438 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1119273 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1119274 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1362050 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1362863 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1397364 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/1448701 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/1454984 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1454989 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1454992 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1455043 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1532040 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1532041 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1532046 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1532049 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1573022 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1580323 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1653153 turn
Re: [Talk-de] Turn restriction Probleme in Baden-Württemberg
Am 15.09.2011 17:25, schrieb Rainer Dorsch: Hallo, habe gerade Karten für Navit aus osm Daten selbst gebaut. Dabei sind mir eine Reihe von Warnungen aufgefallen. Kann jemand was damit anfangen? Ja klar, die Meldungen sagen doch alles. Nummer 1-5 hab ich grade die Verursacher angeschrieben. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenhaltung: Flächen und Flächen_grenzen_
Hi, Am 15.09.2011 15:30, schrieb Martin Koppenhoefer: Am 15. September 2011 12:01 schrieb Martin Koppenhoefer dieterdre...@gmail.com: b) gab es mal (convert to multipolygon), ist aber irgendwie wieder aus meinem JOSM verschwunden. (Vielleicht ein plugin, das ich deinstalliert habe? Weiss jemand näheres?). Was es gibt ist SHIFT+A - create multipolygon, dabei werden allerdings ausser type=multipolygon keine Tags gesetzt. Das b) gibt es: ist ein Plugin für JOSM und heisst multipoly-convert. Hm, mir war es nicht gegenwärtig, Du musstest danach suchen und nachprüfen. Außerdem ist es nur ein Plugin und es bezieht sich nur auf JOSM - wie sieht es z.B. in Potlatch aus? Das multipoly-convert als DAS Flächentool wahrgenommen wird, dürfte damit fast ausgeschlossen sein.. Da ist das Verständnis von overlapping ways als Kernfunktionalität bei der Flächenerfassung wesentlich ausgeprägter - leider.. Es ist doch viel einfacher (und vordergründig intuitiver), wenn man Flächen/Gebiete auf bestehenden Daten erfassen will, einfach einen overlapping way zu zu zeichen und den zu taggen, anstatt sich mit der aufwendigen Erstellung eines multipolygons zu beschäftigen: Dazu muss ich erstmal wissen, dass ich multipolys allgemein für die Erfassung jeder Fläche verwenden kann. Dann brauche ich ein grobes Verständnis von Relationen und, weiter, ich muss wissen, welche Werkzeuge des Editors, bzw. noch schlimmer, Plugins, benötigt werden, um komfortabel mit ihnen umzugehen. Multipolygon Features müssten Kernfunktionalität werden. Bis zu einem Punkt, wo es Joemapper (fast) gar nicht mehr auffällt, dass er es mit multipolys zu tun hat - denn erst dann werden sie nicht mehr von den meisten/vielen MapperInnen links liegen gelassen oder als Nerd-Spezial-Spielzeug abgetan.. Das Konvertieren zw. Multipolys und Flächen sollte im Endeffekt gar nicht notwenig sein, weil jede Fläche ein Multipoly /ist/. Um da hinzukommen, müssen Editoren multipoly-aware arbeiten, d.h. dem Mapper viele Schritte, die er jetzt manuell macht, abnehmen. Es muss inuitiv sein, multipolys zu verwenden. So intuitiv, wie einen closed way zu zeichnen. = An welchen Flächen eine Flächengrenze teilnimmt, ist mit overlapping ways, wie oben erwähnt, durch Rotieren möglich: Nacheinander selektiert der Editor alle Flächen, die an der Flächengrenze beteiligt sind. Vgl. dazu multipoly: Ich selektiere die Flächengrenze und schaue in die Liste /aller/ Relationen, ob es Flächenrelationen gibt, und wenn ja welche. Um eine Fläche auszuwählen, selektiere ich die entsprechende multipoly-relation. Usability-technisch dürfte zwischen beiden eigentlich gar kein Unterschied bestehen, denn in beiden Fällen wird der gleiche Sachverhalt modelliert, auch wenn die Daten/haltung/ leicht anders ist. Overlapping ways sind keine echte Alternative zu Multipolys. Es ist zwar der gleiche Flächenbezug modellierbar (obwohl er bei overlapping ways schwieriger zu ermitteln ist), aber beim Schnitt von Daten mit einer bbox sind overlapping ways pure evil. Das Problem ist, dass alle overlapping ways geladen werden, sobald ein Wegknoten innerhalb der bbox liegt. Beispiel dt. Grenzen: - die Nation, die Bundesländer, die Kreise, die Gemeinden sind ohne weiteres durch overlapping ways abbildbar - nun werden die Daten einer -sehr kleinen- bbox geladen, durch welche die Bundesgrenze verläuft (z.B. bei Görlitz) - Resultat: - es wird der closed way der kompletten Bundesfläche geladen (der closed way ohne Flächeninhalt ist die Grenze) - es wird der closed way der kompletten Fläche des Bundeslandes geladen - es wird der closed way der kompletten Fläche des Kreises geladen - es wird der closed way der kompletten Fläche der Gemeinde geladen - im Editor sehe ich dann alle Flächen, deren Flächengrenze sich bei Görlitz überlappt - mich interessierte doch aber eigentlich nur das Segment der Flächengrenze, welches innerhalb der BBOX lag, nicht die Flächen - weil die Bundesfläche sehr groß ist - so groß, dass bereits der /way/ ihrer Flächengrenze zu umfangreich ist, als das er bei jeder BBOX-Anfrage im Grenzgebiet geladen werden könnte, erfasst man also nicht die Fläche, sondern die Flächengrenze - lädt man nun die gleiche BBOX, passiert folgendes - Resultat: - es wird ein way geladen, ein Flächengrenzsegment, auf dem Bundes-, Kreis- und Gemeindegrenze überlappen - zusätzlich werden die Relationen Bundes-, Kreis- und Gemeindegrenze geladen - letztere sind alle unvollständig - für jede der Relationen sind nur die /ways/ (Flächengrenzsegmente) geladen, die innerhalb der BBOX liegen Analoges gilt eigentlich für das restliche Flächennetzwerk. Man stelle sich eine Siedlungsflächengrenze als closed way von Berlin vor und einen kleinen landuse=residential am Rande Berlins. Beide haben ein
Re: [Talk-de] Verfahren bei place wenn node und area vorhanden ist. WAR Re: Wohngebiete landuse=residential und ihr Bezug zu Straßen, einheitliche Erfassung (war Re: wieder mal - Flächen und Wege)
Am 15.09.2011 08:39, schrieb Georg Feddern: Oh - muss ich jetzt alle meine boundary=* - Keys umschreiben? =-O Der way, der in OSM als Grenze getaggt wird, wird mit boundary=* getaggt, _nicht mit border=*_! War ein Versehen, sorry - habe mich dazu schon distanziert.. Du müsstest nur deine mit boundary_type getaggten ways in border_type umbenennen.. :) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Am 15.09.2011 08:12, schrieb Georg Feddern: 1. Martin hat place als Synonym für Toponym (hä? Ein Hoch auf Wikipedia ...) nie angezweifelt, im Gegenteil, er hat es immer bestätigt als eine Örtlichkeit, sei es Siedlung, Flur, Gebiet, Region etc. Da hast Du ein paar Teile des Freds verpasst.. Deine Aussage in (1.) bezieht sich nur auf den place-node, nicht auf ein place-/polygon/. Für place-nodes waren wir uns immer einig. 2. Wie kommst Du darauf, dass Martin place _nur_ als Name einer Siedlungsstelle belegen will? Indem er unter place-/polygonen/ _nur_ Siedlungsstellen verstanden hat. Ein place-polygon (Ortsgrenze) kann aber je nach Anwendung politische Grenze, Siedlungsflächengrenze, Wohngebietsgrenze oder sonst was sein, /obwohl/ alle diese Grenzen mit dem gleichen place-node (Ortsnamen/Toponym) bezeichnet werden. Da Ortsgrenzen in OSM schon durch boundary=* erfasst werden und es keine Gewichtung gibt, welcher der X Ortsgrenzen, der Ortsname denn nun näher steht, sollte man auch keinen direkten Bezug des Ortsnames zu /nur einer/ der X Ortsgrenzen herstellen. Letzteres würde ein place-polygon, dass _nur_ die Siedlungsstelle mappt, aber tun. 3. Kannst Du Dir nicht vorstellen, dass man für solch ein Toponym (einer Region) in OSM auch mal eine Ausdehnung benötigt? Wie soll man ein Toponym einer weitläufigen Region (Polynom ... quatsch ... Polygon) verarbeiten, wenn diese Information nur in einer einzigen Koordinate (node) in OSM enthalten ist, man aber nur einen (mehr oder weniger großen) Randbereich dieser Region bearbeitet? Über Relationen, an denen der place node teilnimmt place node als Mitglied von boundary=administrative place node als Mitglied von boundary=settlement Je größer die Region, umso wahrscheinlicher ist es, dass Du es sowieso mit einem Multipolygon zu tun hast, also schon eine Relation da ist, der Du einfach nur noch den place node hinzufügen musst, falls das noch nicht der Fall ist. Summa summarum: Befindet sich nur der place node im Editor, sind alle Regionen, denen dieser Ortsname zugeordnet ist, in der Relationsliste zu finden. Befindet sich nur die Region (eine Flächengrenze davon) im Editor, steht der zugehörige Ortsname: - entweder als name=* Tag im ihr zugeordneten place node - oder direkt, aber redundant, im name=* Tag der Regionsrelation Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 03:43, schrieb Martin Koppenhoefer: .. Daten das hergeben - auch als Renderer herausfinden, dass ein bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere Gebiete automatisch aus feiner und differenzierter aufgelösten Gebieten berechnen und sich dabei je nach Karte, die man erstellt, entscheiden, welche Nutzungen man nicht differenzieren will, und welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug sind, sie einzeln zu zeichnen. Ich habe mich dazu zur genüge ausgelassen.. Erinnere Dich an deine Argumente dazu, dass sich gröbere Gebiet der Siedlungsstelle nicht aus den Einzelflächen 'automatisch' errechnen zu lassen - vielleicht hilft Dir das dabei, zu verstehen, dass die überwiegende Zahl von Gruppierungen, die gröbere Gebiete bilden, nicht automatisch errechenbar sind. Außerdem wären, selbst wenn ein komplexes Regelset in Renderregeln gröbere Gebiete aus MICROgemappten automatisch bildet, die Datenbeziehungen nicht in OSM (wo sie hingehören, da auch die Datenbeziehungen Teil der Realität sind), sondern -off-site- in den Algorithmen des Renderers. Das wäre in etwa so, die Route-Relationen von Radnetzwerken nicht in OSM aufzunehmen, weil der Renderer weiß, welche Wege er gruppieren muss, um z.B. die Elbe-Radroute zu rendern. .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 03:34, schrieb Martin Koppenhoefer: Am 15. September 2011 01:34 schrieb Christian Müllercmu...@gmx.de: Am 14.09.2011 15:17, schrieb Garry: Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in die Karte aufnehmen. Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne Detailverlust im Wald) sind: wieso sollte das kein Detailverlust sein? !? wie meinen? Du meinst, wieso die Lösungen, die ich vorgeschlagen habe, die hier aber nicht zitiert sind, keinen Detailverlust darstellen? Das Anliegen von Garry war, sekludierte Häuser im Wald nicht zu verlieren, wenn er /alle/ Häuser aus den Daten entfernt, bevor er eine Karte für sein Garmin erstellt. Bisher verliert er die, deshalb zeichnet er für die zwei Häuser, unabhängig von unserer Diskussion über die Relevanz, einen landuse=* ein. Das braucht er aber /z.B./ nicht, wenn er alle buildings=* wegfiltert, die innerhalb landuse=residential oder landuse=commercial liegen, weil dann die buildings (und damit das Detail) innerhalb landuse=forestry in seinen Daten erhalten bleiben. /Deshalb/ ist /für sein Problem/, die Frage, ob für die Häuser im Wald ein landuse=* erfasst werden sollte, nicht relevant. Ihm ging es nicht um den landuse=*, sondern darum das Detail der Häuser nicht zu verlieren. Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
Martin Trautmann wrote: On 11-07-07 13:52, Jacques Nietsch wrote: Das Gerät könnte interessant sein. http://www.pocketnavigation.de/news/view_2792__medion-zeigt-erstes-eigenes-outdoor-navi-auf-der-ifa/1.1.88.html Mir fehlt bisher eine Übersicht, welche Navis für OSM geeignet sind. Zaehlt die Klasse der WinCE navi's (die wohl den groessten Teil der verkauften Navis abdeckt) als fuer OSM geeignet? Die meisten unterstuetzen zwar keine OSM Karten nativ, aber bei den meisten dieser WinCE Navi's kann mann sehr leicht die Software austauschen und durch OSM kompatible Software ersetzen. Haeufig reicht es einfach eine andere SD Karte in das Geraet zu stecken und neu zu booten und man hat ein OSM kompatibles Navi geraet. Da alles auf der SD Karte installiert is, kann man genauso leicht auch wieder zum alten System zurueck wechseln in dem man einfach die alte SD Karte wieder einlegt. Das heist die Hardware vieler Navi's ist kompatibel zu OSM, nicht aber deren Software. Ein Beispiel fuer eine recht professionelle und leicht zu installeirende OSM kompatible Navigationssoftware fuer WinCE Navi's ist Navigator Free von Mapfactor ( http://navigatorfree.mapfactor.com/de/ ). Damit kann man dann diverse Navi's wie die von Medion, oder Navigon OSM tauglich machen. Andere Optionen fuer WinCE sind z.B. Navit ( http://www.navit-project.org/ ) und moeglicherweise gibt es noch weitere Moeglichkeiten. (Garmin Software?) Das ist auch recht gut geeignet aeltere Navigeraete wieder aktuelle zu gekommen. Kai -- View this message in context: http://gis.638310.n2.nabble.com/OSM-kompatible-Navi-tp6558069p6797656.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] Wohngebiete, landuse=residential Verwendung - continued
Am 15. September 2011 18:10 schrieb Christian Müller cmu...@gmx.de: Am 15.09.2011 08:12, schrieb Georg Feddern: Da hast Du ein paar Teile des Freds verpasst.. Deine Aussage in (1.) bezieht sich nur auf den place-node, nicht auf ein place-/polygon/. Für place-nodes waren wir uns immer einig. üblicherweise haben tags auf nodes eine ähnliche/gleiche Bedeutung wie derselbe Tag auf einem way oder einer Fläche. 2. Wie kommst Du darauf, dass Martin place _nur_ als Name einer Siedlungsstelle belegen will? Indem er unter place-/polygonen/ _nur_ Siedlungsstellen verstanden hat. ich hatte mich in div. Mails sowohl auf Siedlungen als auch auf andere Bedeutungen von place (locality, island) bezogen. Ein place-polygon (Ortsgrenze) kann aber je nach Anwendung politische Grenze, Siedlungsflächengrenze, Wohngebietsgrenze oder sonst was sein -1, das behauptest Du, aber je nach place-Wert sollte klar sein, was gemeint ist. Politische Grenzen können zusammenfallen mit diesen place Grenzen, aber sie sind unabhängig. Es ist der admin_centre Teil, der ggf. einen Bezug des nodes zu einer politischen Grenze herstellt, nicht der place-tag. place node als Mitglied von boundary=administrative place node als Mitglied von boundary=settlement place-polygone gibt es tausende, boundary=settlement gibt es noch gar keinen. Warum sollte man das einführen, wenn place-polygone schon dafür existieren? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 18:28 schrieb Christian Müller cmu...@gmx.de: Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Das hatte ich nicht gemeint. Vergleichbar würde es vielleicht eher, wenn dort der Förster wohnt oder der Holzfäller. Aber selbst dann würde die Info, dass dort jemand wohnt, wichtig finden. M.E. ist nicht ein landuse so wichtig wie der andere, sondern man muss als mapper abwägen. Ein Bäcker ist z.B. auch nach deutschem Recht im Wohngebiet möglich, eine Wohnnutzung im Wald normalerweise nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM kompatible Navi
On 11-09-15 18:55, Kai Krueger wrote: Zaehlt die Klasse der WinCE navi's (die wohl den groessten Teil der verkauften Navis abdeckt) als fuer OSM geeignet? Die meisten unterstuetzen zwar keine OSM Karten nativ, aber bei den meisten dieser WinCE Navi's kann mann sehr leicht die Software austauschen und durch OSM kompatible Software ersetzen. Der Tipp dürfte nur wenigen bekannt sein. Solche Info sollte auf der oder einer eigenen Seite ergänzt werden, möglichst auch mit Kochrezept, wie man das erreicht. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebiete, landuse=residential Verwendung - continued
Moin,
Am 15.09.2011 19:14, schrieb Martin Koppenhoefer:
Ein
place-polygon (Ortsgrenze) kann aber je nach Anwendung politische Grenze,
Siedlungsflächengrenze, Wohngebietsgrenze oder sonst was sein
.. das behauptest Du, aber je nach place-Wert sollte klar sein, was
gemeint ist. Politische Grenzen können zusammenfallen mit diesen place
Grenzen, aber sie sind unabhängig.
-1
Ich übersetze mal nur ein einziges Wort deines letzten Satzes,
vielleicht fällt es Dir ja dann auf:
Politische Grenzen können zusammenfallen mit diesen Orts Grenzen,
aber sie sind unabhängig.
Politische Grenzen _sind_ Ortsgrenzen (per Logik, per allg.
Sprachgebrauch, per Gesetz, seit Lebzeiten),
genauso wie die Grenze einer Siedlungsfläche eine Ortsgrenze /ist/.
a /place=/ _ist_ der Ort
a /place name=/ _ist_ der Ortsname
a /place boundary=/ ist _eine_ Ortsgrenze (von vielen)
Für die überwiegende Zahl von Orten gibt es mehrere Ortsgrenzen-Typen
/place boundary types/.
_Je_ nach Anwendungsfall meint 'Ortsgrenze' /place boundary/ einen
bestimmten 'Ortsgrenzentyp' /place boundary type/
===
Man zähle eins und eins zusammen und modelliert entweder _alle_
Ortsgrenzentypen mit place=* oder keinen.
===
place=* mit _einem einzigen, bestimmten_ Ortsgrenzentyp (z.B. den der
Siedlungsfläche) zu besetzen, ist deshalb falsch!, weil
- die Siedlungsflächengrenze nicht DIE Ortsgrenze ist, sonder nur
_eine_ von vielen.
- die Siedlungsflächengrenze vor anderen Ortsgrenzen /keinen/
Vorrang hat.
- es keine Ordnung, bzw. spezielle Hierachie der Ortsgrenzen gibt!
- alle Ortsgrenzen in gleichem Maße Ortsgrenze sind (peers)
Es ist also genauso gültig das /place polygon/ (wenn es denn deiner
Meinung nach schon eine Ortsgrenze darstellt) eher an die politische
Grenze zu vergeben.
In Wikipedia z.B., was nichts heißen will, ist 'Ortsgrenze' ohne
Begriffsklärung direkt auf 'Politische Grenze' verlinkt.
Die politischen Grenzen eines Ortes sind, da die Politmapper die
'Ortsgrenze' (das place-polygon) nicht für sich beanspruchen (können!),
als boundary=administrative getaggt.
Folgerichtig ist es mehr als unbedacht, nun daherzukommen und das
place-polygon (den Begriff der Ortsgrenze) mit einem anderen
Ortsgrenzentyp zu besetzen.
Noch besser kann ich es nicht erklären, ohne zu vermuten, dass Du mich
nicht verstehen willst..
Es ist der admin_centre Teil, der
ggf. einen Bezug des nodes zu einer politischen Grenze herstellt,
nicht der place-tag.
-1 Der /Bezug/ ist die Menge {place, boundary}. Wie ich den
ausdrücke ist völlig irrelevant. Du könntest sagen der /Bezug/ ist mit
admin_centre benannt.
Wenn Du die /Ortsgrenze/ als /Ort/ (place=* auf closed way) erfasst,
ist man eigentlich angehalten,
die Siedlungsfläche (das place-polygon) auch als /Ort/ zu verwenden.
Soll ich dann, deiner Meinung nach, das place-polygon als
admin_centre in die boundary-Relation aufnehmen?
Berechtigt dazu wäre ich, denn Du hast definiert, dass die
Siedlungsfläche der Ort /ist/. Das ist aber kein allg. Verständnis,
sondern deins.
Es gibt andere, die unter dem Ort die politische Grenze verstehen, oder
nur das Rathaus, oder eine ungefähre Lage, oder den Wirtschaftsraum
etc. pp.
Das die Siedlungsgeographiker ihre /scharfe/ Definition von /Ort/ auf
1/4 der cities gepresst haben, heißt noch lange nicht, dass es gut ist.
Ein Ortsname /place/ bezeichnet unscharf ein geographisches Gebiet, so
unscharf, dass man ihn nur als /ausdehnungslosen/ Punkt (node) erfassen,
und dann in Bezug zu seinen X+2 scharfen Grenzen setzen sollte. Ich
weiß nicht, ob das dann die beste Abbildung der Realität ist, aber ich
weiß, dass die vorhandene Abbildung in diesem Bereich inkonsequent und
inkonsistent ist. Man kann das natürlich alles so lassen, aber es ist
halt, nun ja, lame..
Wenn man nicht auf die Details achtet, kommen früher oder später größere
Probleme auf einen zu.. Widersprüche summieren sich auf. Den Ort und
seine Ortsgrenzen so zu modellieren, dass uns das in Zukunft nicht im
Wege steht, ist eigentlich wirklich kein Ding, aber ich scheitere ja
schon am ersten Spezialisten mit Tunnelblick auf die Siedlungsgeographie.
Ist das Projekt festgefahren?
Betrachten Joemapper und Spezialisten die bestehende Datenlage als ihren
Glauben und die Worte des Wikis als heilige Schrift?
Wir werden es erfahren, in den nächsten zweitausend Jahren.
place node als Mitglied von boundary=administrative
place node als Mitglied von boundary=settlement
place-polygone gibt es tausende, boundary=settlement gibt es noch gar
keinen. Warum sollte man das einführen, wenn place-polygone schon
dafür existieren?
Weil es Sinn macht (tm). und weil ich, evtl. war das falsch, bisher
dachte, dass Leute OSM nicht als /sinnloses/ Hobby erachten.
Evtl. findest Du ein besseres Wort für settlement.. Wenn 'place'
(Ort) unbedingt als Siedlungsfläche
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 19:18, schrieb Martin Koppenhoefer: Am 15. September 2011 18:28 schrieb Christian Müllercmu...@gmx.de: Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Das hatte ich nicht gemeint. Vergleichbar würde es vielleicht eher, wenn dort der Förster wohnt oder der Holzfäller. Aber selbst dann würde die Info, dass dort jemand wohnt, wichtig finden. M.E. ist nicht ein landuse so wichtig wie der andere, sondern man muss als mapper abwägen. Eben, sag ich ja. Zwei Bäcker im Wohngebiet oder Zwei Häuser im Wald interessieren /mich/ überhaupt nicht, wenn ich wissen will, wofür ein Gebiet genutzt wird. /Dich/ hingegen schon. == Flächennetzwerk Das ist eine Lösung in der das koexistieren können. Denn zusammenfinden lässt sich da nichts: /Mich/ interessieren Granularitäten von zwei/drei Häusern nunmal nicht. Mit einem Flächennetzwerk könntest Du dein Ding machen, während andere ihr Ding machen, ohne dass es hier ständig zu m.E. und ich sehe das so, etc. pp. kommen muss. Evtl. unterhält man sich dann endlich mal über progessivere Sachen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
