Re: [Talk-de] GPS mit *gutem* Empfang?
Jimmy_K Jimmy_K at gmx.at writes: Aktuelle ist der WBT-202 und dieser hat dank des u-blox5 zum MTKII des 747A+ aufholen können: http://www.kowoma.de/gps/geraetetests/wintec_wbt202/wbt202_p1.html Stimmt. Er ist aber, wenn ich den Test richtig verstehe, nicht deutlich besser. Außerdem (Zitat vom von dir verlinkten Test): | ... dass nur die drei NMEA-Datensätze RMC, GGA (teilweise) und VTG geloggt | und somit exportiert werden können. Tiefschürfende Informationen zu HDOP, | VDOP, Anzahl und Details der empfangenen Satelliten stehen nicht zur | Verfügung. Hier ist der iBlue747A+ flexibler einzusetzen. Das Problem hatte auch der WBT 201 bereits. Man muss dem, was der Logger aufgezeichnet hat, blind vertrauen, da im Nachgang kein Filtern der Daten mehr möglich ist. Ich lege mir mein Log dann halt auf die OSM-Daten und wo mein Log gravierend abweicht, lösche ich diese Bestandteile des GPX-Tracks raus. Mir wäre bei einem neuen Logger schon wichtig, dass ich nach dem Auslesen solche Punkte, die bei schlechten Empfangsverhältnissen geloggt wurden, aussortieren kann. Prinzipiell wäre ich auch an einem Garmin-Gerät interessiert, aber hier fällt mir die Auswahl schwer. Zudem gibt es wohl nur wenige Garmin-Geräte mit MTK II Chipsatz. Eine Angabe zum Chipsatz vermisse ich auf der Garmin-Webseite komplett. Aktuell brauche ich erstmal direkt Ersatz für den WBT 201 um künftig Tracks mit besserer Qualität loggen zu können. Kann jemand bestätigen, dass das Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Verbindung ausgeschaltet wird? Wie schon erwähnt wäre mir das schon wichtig, denn in den allermeisten Fällen werde ich kein Bluetooth brauchen und Akku-Laufzeit ist mir da dann doch wichtiger. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.12 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) wenn du dafür auf der englischen Liste eine Mehrheit findest... Thread Why boundaries should not be tagged as boundaries Die internationale Community wird vermutlich für den Widerstand eines kleinen badischen Dorfes gegen den Rest der Welt nur ein müdes Lächeln übrig haben. Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Im Forum war der Aufschrei des Entsetzens eher verhalten: http://forum.openstreetmap.org/viewtopic.php?id=15135p=4 Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Würde man sich statt mit sinnloser Relizensierung mit einem vernünftigen Flächen-Datentyp befassen, hätte sich das Problem längst erledigt. Dann könnte eine boundary-Relation den Flächenumriss, den Verwaltungsmittelpunkt und die Unterelemente sauber zusammenfassen. Stattdessen ekelt man lieber altgediente OSM-Dogmatiker raus und wundert sich dann, wenn sich niemand mehr daran erinnert, warum man kein Multipolygon will. Gruß, ajoessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 07:36:54AM +0200, Ronnie Soak wrote: Ich betrachte den Entwicklungsstand von Nominatim immer noch als beta. Nicht verwunderlich, bei der Komplexitaet der Aufgabe. Weiteres Beispiel gefaellig? Such nache Fischmarkt, Erfurt openstreetmap.org: Pedestrian Way Fischmarkt, Altstadt, Erfurt, Coburg, Free State of Thuringia, 99084, Federal Republic of Germany (land mass), Europehttp://www.openstreetmap.org/?minlon=11.0283880233765minlat=50.9776000976562maxlon=11.0291347503662maxlat=50.9780693054199 Richtiger Platz, aber Coburg ist eine Stadt (und ein Landkreis?) in Bayern und hat hier nichts zu suchen. Das liegt an einem alten OpenGeoDB-Node: http://www.openstreetmap.org/browse/node/240076850 Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. In jedem Fall werden die place=region Nodes mit dem nächsten Nominatim- Update (nach dem Lizenzwechsel) gänzlich aus den Adressen verschwinden. Dann hat sich das Problem ohnehin gelöst. openstreetmap.de Fischmarkt, Altstadt, Erfurt, Ilm-Kreis, Free State of Thuringia, 99084, Federal Republic of Germany (land mass), Europehttp://openstreetmap.de/karte.html# Auch hier richtiger Platz, aber Erfurt ist eine kreisfreie Stadt, der Ilm-Kreis schliesst sich im Sueden an. Die Suche auf osm.de könnte man ruhig mal auf nominatim.osm.org umstellen. Die Mapquest-Instanz hat nach wie vor einen Datenstand von Dezember und soweit ich gehört habe, wird es auch für einige Zeit nach dem Lizenzwechsel keine Updates geben. (Was durchaus Sinn macht dort, denn der Lizenwechsel wird einiges an Boundary-Polygonen kaputt machen, sodass es anfänglich wohl ein bisschen chaotisch wird mit den Addressen, die Nominatim zurückgibt.) Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. Die englische Wikipeida hat sich auf district als Übersetzung für den deutschen Kreis geeinigt: http://en.wikipedia.org/wiki/Districts_of_Germany http://en.wikipedia.org/wiki/Talk:Districts_of_Germany#country_vs_district Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Moin, Am 19.04.2012 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) ist vielleicht gar keine so schlechte Idee. ;-) Dann wird das 'Problem' vielleicht mal international offensichtlich. Im Moment sieht es ja eher so aus, als wenn das 'Problem boundary' außerhalb einiger gallischer Dörfer international nicht so recht existiert ... Andererseits wäre es natürlich auch kein Problem, innerhalb einer type=multipolygon boundary=administrative die Rolle admin_centre=* zu behandeln ... Genauso, wie es (sogar unabhängig von der Auswertung einer Relation) möglich wäre admin_centre=ADMIN_LEVEL als Tag am Ort des Geschehens auszuwerten. Der Bezug zur Relation ist über die geografischen DB-Funktionen gegeben. Bei der letzten Variante - bräuchte man weder einen speziellen Relationstyp - noch bräuchte man eine Rollen-Sonderbehandlung bei multipolygon - könnten Renderer die Funktion des Ortes unabhängig von jeglicher Relation kennzeichnen - wäre eine Sonderbehandlung bei der Auswertung nur erforderlich, wenn man tatsächlich einen echten Bezug zwischen admin_centre und der boundary benötigt Nur der Aufwand bei einer Änderung ist geringfügig höher und geringfügig fehleranfälliger - ist aber in meinen Augen durchaus handhabbar. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. Die englische Wikipeida hat sich auf district als Übersetzung für den deutschen Kreis geeinigt: http://en.wikipedia.org/wiki/Districts_of_Germany http://en.wikipedia.org/wiki/Talk:Districts_of_Germany#country_vs_district Was jetzt aber nicht relevant ist für OSM. Es gibt so etwas ähnliches wie einen Konsens in OSM, dass die Grenzen, die mit admin_level=6 getaggt sind, place=county entsprechen. place=district ist in OSM ein Stadtteil. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Moin, Am 19.04.2012 07:59, schrieb Andre Joost: Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Aber sind die Argumente für boundary denn tatsächlich überzeugender? label sehe ich bei multipolygon genauso als sinnvoll an, es sollte also auch dort behandelt werden (können). admin_centre siehe meine Antwort von 09:13 auf Frederiks Beitrag. Unterrelationen: Ich sehe durchaus einen Sinn in Unterrelationen, allein aufgrund der Größe und Handhabbarkeit, sprich also die 'französische Teilung' und das bleibt dann nur Geometrie. Aber ist es wirklich notwendig und sinnvoll, die Verwaltungsstruktur innerhalb einer Relation abzubilden? Wenn man das tut, setzt man (als Beispiel mal SH) das Kreis_gebiet_ aus den Amts_gebieten_ zusammen. Dabei geht dann m. E. aber die Kreis_grenze_ verloren bzw. ist nicht mehr eindeutig, die muss man also als _Grenz_relation zusätzlich erfassen. Was hat man dann außer der Zusammenfassung der Amtsgebiete, die aber über den geografischen Zusammenhang der Amtsgebiete innerhalb des _Kreisgebietes_der_Grenzrelation_ gegeben ist, gewonnen? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.12 09:46, schrieb Georg Feddern: Aber ist es wirklich notwendig und sinnvoll, die Verwaltungsstruktur innerhalb einer Relation abzubilden? Wenn man das tut, setzt man (als Beispiel mal SH) das Kreis_gebiet_ aus den Amts_gebieten_ zusammen. Nein, es soll nur auf die Relationen der Ämter verwiesen werden. Die Kreisgrenze bleibt als Fläche/Polygon daneben definiert. So kann man auf einfache Weise z.B. Verbandsgemeinde Bad Kreuznach und Verbandsgemeindefreie Stadt Bad Kreuznach im Kreis Bad Kreuznach auseinanderhalten. Ohne sich die Grenzen jeweils anschauen zu müssen. Dabei geht dann m. E. aber die Kreis_grenze_ verloren bzw. ist nicht mehr eindeutig, die muss man also als _Grenz_relation zusätzlich erfassen. Als Polygon, ja. Was hat man dann außer der Zusammenfassung der Amtsgebiete, die aber über den geografischen Zusammenhang der Amtsgebiete innerhalb des _Kreisgebietes_der_Grenzrelation_ gegeben ist, gewonnen? Der simple Mapper kann nicht eben mal eine Postgis-Abfrage starten. Mit Relationen kommt er eher klar. Aber diese Art von Grenzrelationshierarchie ist eben ein kann, kein muß. Die Grenzlinienelemente sind nur in der/den Geometrie-Relation(en) bzw in neu zu schaffenden Flächenelementen drin. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Hi! Manfred A. Reiter wrote a) ein Rendering nutzen, das diese Sachen rendert (z.B. NOPs Wanderreitkarte) das bedeutet also warten, bis die Dinge dort erscheinen? Diese Karte wird momentan nicht aktualisiert, soll erst weitergehen wenn der Lizenzwechsel durch ist. Manfred A. Reiter wrote Manfred A. Reiter lt;ma.reiter@gt; wrote: Ich habe auch in eben diesem Thread gelesen, dass Schlösser und Burgen in Mapnik nicht gerendert werden ... IST das so? Kann ich was tun, um diese für Touris evtl wichtige Info trotzdem sichtbar zu machen? Ist das so??? Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. 2. Objekte liegen zu nahe beieinander. Mapnik zeichnet dann das erste Objekt oder den ersten Text und läßt alle weiteren Objekte an der Stelle, die drübergeschmiert würden, einfach weg. Dabei ist es mehr oder weniger Zufall, welches Objekt zuerst kommt. Es kann also durchaus sein, daß der Höhleneingang angezeigt wird, und deshalb Brücke und Burg weggelassen werden. Hier in der Gegend ärgern sich z.B. schon lange die Nürnberger darüber, daß auf der OSM Karte die viel kleinere Nachbarstadt Fürth angezeigt und Nürnberg weggelassen wird. Fürth kommt im Alphabet halt vorher. :-) bye Nop -- View this message in context: http://gis.19327.n5.nabble.com/Burgen-Schlosser-usw-tp5641957p5651240.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] Massenumbenennung Relationen von Multipolygon in Boundary
Hallo, On 04/19/12 07:59, Andre Joost wrote: Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Solche Aenderungen sind nicht nur vorher anzukuendigen, sondern auch vorher zu diskutieren. Was will ich aendern, wie will ich dabei vorgehen, hat jemand was dagegen. Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. So etwas ist vorher zu diskutieren und nicht hinterher. 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] Burgen, Schlösser usw ... ;-)
Hallo, Am 19. April 2012 10:48 schrieb NopMap ekkeh...@gmx.de: Manfred A. Reiter wrote Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. Stimmt, inzwischen ist die gesuchte Burg auch da, wenn man weiter reinzoomt: http://www.openstreetmap.de/karte.html?zoom=18lat=45.81561lon=14.12701layers=B000TT Grüße, Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.2012 10:07, schrieb Andre Joost: Nein, es soll nur auf die Relationen der Ämter verwiesen werden. Die Kreisgrenze bleibt als Fläche/Polygon daneben definiert. So kann man auf einfache Weise z.B. Verbandsgemeinde Bad Kreuznach und Verbandsgemeindefreie Stadt Bad Kreuznach im Kreis Bad Kreuznach auseinanderhalten. Ohne sich die Grenzen jeweils anschauen zu müssen. OK, das ist eine Möglichkeit ... Ich nutze dafür allerdings den name:prefix (resp. bei Bedarf den name:suffix). Ist genauso menschenlesbar - und kann zusätzlich programmtechnisch (z.B. vom Renderer) verwendet werden, falls gewünscht. Der simple Mapper kann nicht eben mal eine Postgis-Abfrage starten. Mit Relationen kommt er eher klar. Aber diese Art von Grenzrelationshierarchie ist eben ein kann, kein muß. Die Grenzlinienelemente sind nur in der/den Geometrie-Relation(en) bzw in neu zu schaffenden Flächenelementen drin. Das Argument kann ich als Gemeinde- bis Bundesland-Extrakt-Verwender zwar durchaus nachvollziehen. Trotzdem sehe ich da mit osmconvert und osmfilter auch Kleinanwender-Möglichkeiten gegeben. Und letztendlich bleibt es damit trotzdem nur eine Sammel-Relation - mit deren Vorzügen, aber eben auch mit deren Nachteilen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] http://wiki.openstreetmap.org/wiki/DE:BBBike_@_World
hi martin, es geht bestimmt um bbbike.org und nicht um bbbike.de - kleiner aber feiner unterschied. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/http-wiki-openstreetmap-org-wiki-DE-BBBike-World-tp5650066p5651293.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] Suche nach Elbufer, Bad Schandau
Am 19. April 2012 09:18 schrieb Sarah Hoffmann lon...@denofr.de: On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. place=district ist in OSM ein Stadtteil. das höre ich zum ersten Mal, bisher war ich von place=suburb ausgegangen, ggf. noch unterteilt in place=quarter und neighbourhood. Gem. taginfo kommt place=district überhaupt nicht in den Daten vor, es findet sich zwar ein place=city_district, aber gerade mal an 38 Stellen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.12 11:33, schrieb Martin Koppenhoefer: Am 19. April 2012 09:18 schrieb Sarah Hoffmannlon...@denofr.de: On Thu, Apr 19, 2012 at 08:51:34AM +0200, Andre Joost wrote: Am 19.04.12 08:37, schrieb Sarah Hoffmann: Offenbar wurden die Kreise bei dem Import als place=region eingetragen, das sollte wohl eher place=county sein. m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. Nö, Kreis und kreisfreie Stadt stehen auf gleichem admin_level. Ebenso Verbandsgemeinde und amtsfreie Orte auf 7, sowie Gemeinden und Städte auf level 8. name:prefix ist auch suboptimal, da sich manche Städte eben gerne als Hansestadt/Freie und Hansestadt/Kolpingstadt/Rattenfängerstadt/wass-weiss-ich-Stadt bezeichnen: http://www.mik.nrw.de/themen-aufgaben/kommunales/erfolgsmodell-kommunale-selbstverwaltung/strukturen/bezeichnungen/genehmigte-bezeichnungen.html Und ein *stadt* oder *amt* im Namen ist auch kein eindeutiges Indiz für Stadtrechte bzw Amtseigenschaften :-( Um das mal aufzudröseln, habe ich für level 6 und 8 hier entsprechende tags eingeführt: http://wiki.openstreetmap.org/wiki/DE:Grenze_zeichnen#Politische_Grenze http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze#Relation_anlegen place=* fällt da leider aus, weil das im Zusammenhang mit type=multipolygon von mkgmap und josm als Siedlungsfläche mißverstanden wird. Deshalb de:place mit city/county/town/village als mögliche Werte. Für level 7 sind mir keine passenden englischen Begriffe eingefallen. Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On 19.04.12 11:33, Martin Koppenhoefer wrote: [place=region] m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. ACK. IMO sollte man dem Nominatim beibringen, dass es Staaten gibt, deren admin-boundaries mittlerweile halbwegs vollständig sind und daher diese gedachten Wolken um Place Nodes herum entbehrlich und kontraproduktiv sind! In AT gibt's dasselbe Theater, grade die Wolken um place=region scheinen mir zu groß gedacht und -- da es die Grenzhierarchie längst gibt - entbehlich. place=district ist in OSM ein Stadtteil. das höre ich zum ersten Mal, bisher war ich von place=suburb ausgegangen, ggf. noch unterteilt in place=quarter und neighbourhood. Gem. taginfo kommt place=district überhaupt nicht in den Daten vor, es findet sich zwar ein place=city_district, aber gerade mal an 38 Stellen. ACK. Das sollte man mal final spezifizieren (und auch in Mapnik+Nominatim umsetzen). In Wien (und das gilt so ähnlich auch in anderen größeren österr. Städten) gibt es a) (Stadt-/Gemeinde-)Bezirke (admin_level 9) b) Katastralgemeinden (hauptsächlich durch Place Nodes abgebildet; Grenzen zu erfassen wäre aber denkbar) c) Grätzelnamen (entspr. place=neighbourhood) Grade bei a) und b) (momentan beide als place=suburb gemappt, was äußerst unbefriedigend ist) wäre eine durchgängige Größen- und Ebenenunterscheidung wünschenswert, in der Beschriftung im Mapnik/Standardstil genauso wie im Nominatim (der sollte überhaupt nur a) berücksichtigen und b) und c) in seiner Hierarchie ignorieren...). /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19. April 2012 10:58 schrieb Frederik Ramm frede...@remote.org: On 04/19/12 07:59, Andre Joost wrote: Angekündigt war es nicht, hat aber den *manuellen* Eintrag der Regionalschlüssel laut aktueller destatis-Liste als Ersatz der allgemeinen Gemeindeschluessel erheblich vereinfacht. Solche Aenderungen sind nicht nur vorher anzukuendigen, sondern auch vorher zu diskutieren. Was will ich aendern, wie will ich dabei vorgehen, hat jemand was dagegen. +1 automatische Edits müssen vorher diskutiert werden, es ist ein Unding, dass nach wie vor manche Mapper sich das Recht rausnehmen, flächendeckend Ihre Meinung durchzusetzen bei Themen, die in der Community umstritten sind (genauso leidig sind Massenimporte, die vorher nicht angekündigt und diskutiert wurden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19.04.12 12:16, schrieb Jan Tappenbeck: Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Da gibts doch schon was: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Building_attributes#Date_of_construction http://taginfo.openstreetmap.org/keys/?key=construction_year http://taginfo.openstreetmap.org/keys/?key=year_of_construction Gruß, Andre Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 12:16 schrieb Jan Tappenbeck o...@tappenbeck.net: Hi ! habe gerade folgendes ergänzt: Jahr der Errichtung Was heute gebaut wird, das wissen wir. Aber was ist in x-Jahren. Wenn wir gerade schon dabei sind Hausnummern zu erfassen und auch neu errichtete Gebäude sehen, dann sollten wir noch ein Zusatztag build_year=* setzen. Bei alten Gebäuden finden sich hierzu oftmals Tafeln an den Gebäuden. Ich dachte, wir nutzen englische Wörter als Tags (SCNR) warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. Wenn es um voraussichtliche Baufertigstellung geht, habe ich noch dieses gefunden: http://wiki.openstreetmap.org/wiki/Key:opening_date build_year gibt es erst 21 mal, das sollte man im Wiki nicht als etablierte Empfehlung eintragen, maximal als proposal. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
On 19/04/12 07:59, Andre Joost wrote: Am 19.04.12 00:59, schrieb Frederik Ramm: Hallo, On 04/19/2012 12:10 AM, Chris66 wrote: Ob die üblichen Regeln für Massenedits (Ankündigung auf der Liste etc.) eingehalten wurden, weiss ich nicht. Ich hab beim Autor nachgefragt. Denn wenn jetzt hier jeder einfach so die Grenzrelationen auf das aendern kann, was er gut findet, aender ich sie morgen weltweit auf multipolygon ;) Es geht nicht um weltweite Edits sondern um regionale. Was willst Du machen, wenn ich die 20 Kreise meiner Umgebung anpasse und sie dann auch noch zu den angrenzenden Kreisen in Frankreich passen ? Warum sind denn die Grenzmauern weltweit so in vielen Köpfen zementiert ? wenn du dafür auf der englischen Liste eine Mehrheit findest... Thread Why boundaries should not be tagged as boundaries +1 Die internationale Community wird vermutlich für den Widerstand eines kleinen badischen Dorfes gegen den Rest der Welt nur ein müdes Lächeln übrig haben. Es gibt auch noch badischer Dörfer etwas weiter südlich, in denen man sich mehr mit seine gallischen Nachbar verbunden fühlt. Ich würde auch vor Jahren mal angepammt, da ich beim Eintragen der PLZ-Relationen die Multipolygone durch boundary ersetzt habe. Habe es damals zurückgesetzt, war aber nie überzeugt. Es gab halt immer schon boundaries, und die Argumente für Multipolygon sind nun mal nicht sehr überzeugend. Bei boundary sind auch Knoten als admin_centre oder label erlaubt, sowie Unterrelationen zur Abbildung der Verwaltungshierarchie. Das ist beim multipolygon nicht erlaubt, weil es *nur* Geometrie sein soll. Ein Vorteil der boundaries, wobei label bei multipolygonen oft wohl auch angebracht ist. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
On Wed, Apr 18, 2012 at 11:41:02PM +0200, Tirkon wrote: Moin, offensichtlich hat jemand hier und möglicherweise in weiteren Changesets massenweise den Typ von Grenz-Relationen von multipolygon auf boundary geändert: http://www.openstreetmap.org/browse/changeset/10934495 Der OSM Inspektor gibt jetzt eine Warnung aus: Ist diese Änderung von multipolygon auf boundary nun korrekt oder nicht? Das ist ein Alter Hut - Als ich die dinger in NRW vor Jahren alle eingetragen habe habe ich mit boundary angefangen. Ich halte das aber mittlerweile fuer Bullshit und habe mich von Frederik überzeugen lassen und habe das allermeiste auch auf multipolgon geaendert und damit weitergemacht. Ich habe die aenderung auch gesehen aber soll doch jeder den Datenbestand so kaputt machen dürfen wie er will :) Dinge die gleich funktionieren sollten auch gleich heissen. Und das Thema inner/outer bildet genau das ab was die boundarys auch probieren. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hallo, Am Donnerstag, 19. April 2012 12:47:01 schrieb Martin Koppenhoefer: warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. year_of_construction oder date_of_construction sind da schon eindeutiger. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Am 19. April 2012 10:48 schrieb NopMap ekkeh...@gmx.de: Hi! Manfred A. Reiter wrote a) ein Rendering nutzen, das diese Sachen rendert (z.B. NOPs Wanderreitkarte) das bedeutet also warten, bis die Dinge dort erscheinen? Diese Karte wird momentan nicht aktualisiert, soll erst weitergehen wenn der Lizenzwechsel durch ist. Manfred A. Reiter wrote Manfred A. Reiter lt;ma.reiter@gt; wrote: Ich habe auch in eben diesem Thread gelesen, dass Schlösser und Burgen in Mapnik nicht gerendert werden ... IST das so? Kann ich was tun, um diese für Touris evtl wichtige Info trotzdem sichtbar zu machen? Ist das so??? Meine Rückfrage kommt deshalb, weil ich hier http://www.openstreetmap.de/karte.html?zoom=15lat=45.81389lon=14.12989layers=B000TT zwar einen Höhleneingang finde, aber die Burg nicht erscheint. Das kann zwei Ursachen haben: 1. Burgen werden im Kartenstil nicht berücksichtigt. Ich bilde mir aber ein, in einem anderen Thread gelesen zu haben, daß Sven das im deutschen Stil eingebaut hat. richtig, aber *nach* dieser Email ;-) 2. Objekte liegen zu nahe beieinander. Mapnik zeichnet dann das erste Objekt oder den ersten Text und läßt alle weiteren Objekte an der Stelle, die drübergeschmiert würden, einfach weg. Dabei ist es mehr oder weniger Zufall, welches Objekt zuerst kommt. Es kann also durchaus sein, daß der Höhleneingang angezeigt wird, und deshalb Brücke und Burg weggelassen werden. Hier in der Gegend ärgern sich z.B. schon lange die Nürnberger darüber, daß auf der OSM Karte die viel kleinere Nachbarstadt Fürth angezeigt und Nürnberg weggelassen wird. Fürth kommt im Alphabet halt vorher. :-) bye Nop Sven hat das Problem für die OSM.de gelöst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
On 18/04/12 14:41, Masi Master wrote: Am 17.04.2012, 22:49 Uhr, schrieb Chris66 chris66...@gmx.de: Am 17.04.2012 22:22, schrieb Bernhard Weiskopf: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Naja, das gilt aber nicht für alle Radfahrer. Ein Anhänger z.B. entbindet von der Benutzungspflicht des Radweges. Auch dar ich mich zum Linksabbiegen schon rechtzeitig auf die Straße orientieren, was bei fehlenden abgesenkten Bordsteinen schon einige 100m vorher sein kann. bicyle=no setze ich deshalb nur bei bei explizitem Verbot durch Zeichen 254 o.Ä. Auch wenn der Radweg unzumutbar ist, darf auf der Straße gefahren werden. Somit ist bicycle=no falsch (außer bei Verbotsschildern). +1 Lösche bitte die bicycle=no, wenn kein explizites Verbotsschild vorhanden ist. Es gibt aber auch Straßen mit abgesetzt parallel verlaufendem asphaltiertem Wirtschaftsweg oder Fußweg mit Fahrradfreigabe hier ergänzt man bicycle=yes (oder Tempo-30-Zonen, in denen keine nutzungspflichtigen Radwege erlaubt sind). Der abgesetzte Weg ist dann nicht als Radweg markiert, es besteht keine Nutzungspflicht und die für Radfahrer gefährlichere Straße darf benutzt werden (wird sie auch, z. B. von Rennradfahrern). Die Straße ist übrigens erheblich sicherer als die allermeisten Radwege. Man darf nur nicht äußerst rechts fahren, um die Autofahrer nicht zum Überholen ohne Abstand zu animieren. Aber das ist ein anderes Thema. +1 Bei diesem Thema hatte ich schon öfters Streit mit meine Freundin, da ich der Ansicht bin, daß Autos zum Überholen doch bitte eine eigene Spur benutzen sollen. Das sollte eigentlich Sache der Router sind. Ich würde mir eine Software wünschen, bei der mal bei allen Wegtypen (auch in Kombination von surface/smoothness usw.) die Priorisierung festlegen kann. +1 Mit einem vollgepackten Anhänger brauche ich Strecken mit möglichst geringster Steigung und glatten Fahrbahnbelag. Da nehme ich schon eher ein paar Kilometer Umweg in Kauf. Grüße fly P.S.: Die maximal erlaubte Länge eines Fahrradanhänger ist 25m. Bin leider noch nicht dazu gekommen eine zu schweissen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Hallo, On 04/19/12 13:10, fly wrote: Es geht nicht um weltweite Edits sondern um regionale. Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? 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] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 13:18 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 12:47:01 schrieb Martin Koppenhoefer: warum willst Du da auf Biegen und Brechen was durchsetzen, was bereits universell verwendbar anders eingeführt ist? start_date ist der tag, der allgemein dafür verwendet wird (wenn er in Verbindung mit dem Key building gesetzt ist), und der auch für alles mögliche andere verwendet werden kann. -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. -1 der Laden im Haus ist sowieso ein anderes Objekt als das Haus. Um das sauber abzubilden sollte man dafür nicht daselbe Objekt verwenden. Das gibt an allen Stellen nur Probleme, z.B. beim Namen, bei der Stockwerksanzahl, beim operator und überall sonst, wo nicht komplett klar ist, worauf sich der tag bezieht. Das kann man auf verschiedene Arten tun, z.B. indem der Laden als Node gemappt wird, oder indem man für das Gebäude einen way macht, der als outer in einem Laden- Multipolygon member ist (oder anders rum, wenn die Fläche jeweils genau gleich ist). Ich halte es für besser, solche Trennungen auch durch getrennte Objekte darzustellen, als die tags immer weniger universell einsetzbar zu machen, indem man ständig neue Verschachtelungen erfindet, die kaum jemand auswerten kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Frederik Ramm wrote Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? ich finde schon, wenn man die Größe des gallischen Dorfes in Bezug zur Erde setzt, ist das sehr regional ;) Mit der Art und Weise dieser Aktion bin ich auch nicht so ganz happy aber das Ergebnis überzeugt mich voll. Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/Massenumbenennung-Relationen-von-Multipolygon-in-Boundary-tp5650288p5651590.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] Straßenbegleitende Radwege
Am 19. April 2012 13:46 schrieb fly lowfligh...@googlemail.com: P.S.: Die maximal erlaubte Länge eines Fahrradanhänger ist 25m. Bin leider noch nicht dazu gekommen eine zu schweissen. Cool, endlich mal wieder eine interessante Information auf talk-de ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Gruß, Falk [1] http://www.openstreetmap.org/?lat=50.834702lon=12.928843zoom=18layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Burgen, Schlösser usw ... ;-)
Manfred A. Reiter ma.rei...@gmail.com wrote: Ein solches Ticket gibt es: https://trac.openstreetmap.org/ticket/2247 Alter 3 Jahre ... Gibt es sowas wie ein Voting für das Ticket? ... oder wie kann ich die Macher des Mapnikstils von meinem Ansinnen überzeugen? Das Problem ist wohl, dass es in der datenbank die Spalte ruins nicht gibt. Meine Datenbank hat ein hstore. Deshalb kann ich das vergleichsweise einfach einbauen. Gruss Sven -- .. this message has been created using an outdated OS (UNIX-like) with an outdated mail- or newsreader (text-only) :-P /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] Großbaustelle
On 19/04/12 14:47, Falk Zscheile wrote: Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? Bis bald fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Sarah Hoffmann lon...@denofr.de wrote: Die Suche auf osm.de könnte man ruhig mal auf nominatim.osm.org umstellen. Da das außer mir sowieso wieder niemand machen wird... done. Sven -- Der normale Bürger ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /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] Großbaustelle
Am 19. April 2012 15:21 schrieb fly lowfligh...@googlemail.com: On 19/04/12 14:47, Falk Zscheile wrote: Am 19. April 2012 14:31 schrieb fly lowfligh...@googlemail.com: On 18/04/12 14:55, Philippe Rieffel wrote: http://wiki.openstreetmap.org/**wiki/Tag:landuse%3Dbrownfieldhttp://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbrownfield genau richtig. Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. Das kommt drauf an, wie du die Aktualisierung einschätzt. Wenn Du sagst in den nächsten zwei Jahren komme ich nicht dazu zu überprüfen ob da jetzt ein Haus steht, andererseits keine andere Nutzung in betracht kommt, so halte ich brownfield für durchaus vertretbar. Das Contiloch[1] in Chemnitz existiert seit fast 20 Jahren und ich würde sagen, dass es ein brownfield ist, auch wenn sich mittlerweile seltene Arten ansiedeln, die jedem Naturschützer Freundentränen in die Augen treiben. Eine Wiederbebauung kommt nach wie vor in Betracht, falls nicht jemand die kleine Hufeisennase oder eine andere bedrohte Spezies entdeckt. Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? Martin freut sich bestimmt, wenn du das verwendest :-) Aber einen schönen Wert habe ich da auch nicht. Das wäre ja dann scrub, nur auf Krautebene :-) Vielleicht landcover=pioneer_species. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 18.04.2012 22:08, schrieb hike39: Es gab mal einen 229.000km² großen ALDI: http://www.openstreetmap.org/browse/way/124228864/history Der Fehler ist schon länger behoben und es wundert mich, dass er noch immer gefunden wird. Nominatim bei openstreetmap.org liefer mir als Ergebnis zwei Primärstraßen (Ostrau, Postelwitz), eine Almhütte und ein Haus, aber nirgends erscheint ALDI. Welche Suche hast du benutzt? Ganz einfach bei http://www.openstreetmap.de/karte.html?zoom=15lat=50.91107lon=14.17838layers=B000TT und dann in der Suchmaske Elbufer, Bad Schandau angeben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Wie sieht es bei den anderen aus? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenumbenennung Relationen von Multipolygon in Boundary
Am 19.04.2012 14:16, schrieb Frederik Ramm: Hallo, On 04/19/12 13:10, fly wrote: Es geht nicht um weltweite Edits sondern um regionale. Im konkreten Fall sind 418 Kreis- und 746 Stadtgrenzen betroffen. Ist das noch ein regionaler Edit? Bye Frederik Dafür hat er jetzt über 1000 Edits mehr in seiner Statistik, das wird seinem Ego schon was bringen. :X ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Jimmy_K jimm...@gmx.at wrote: Meine Suche stammt von openstreetmap.org, aber auch openstreetmap.de liefert bei mir keinen Aldi. Seit 15:26 ist openstreetmap.de ebenfalls nominatim.osm.org siehe mein Posting in diesem thread, Wie sieht es bei den anderen aus? Diese Frage erübrigt sich damit. Sven -- In the land of the brave and the free, we defend our freedom with the GNU GPL (Richard M. Stallman on www.gnu.org) /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] Burgen, Schlösser usw ... ;-)
Am 19. April 2012 14:52 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Manfred A. Reiter ma.rei...@gmail.com wrote: Das Problem ist wohl, dass es in der datenbank die Spalte ruins nicht gibt. Meine Datenbank hat ein hstore. Deshalb kann ich das vergleichsweise einfach einbauen. es geht ja vor allem um historic=castle, nicht nur um Ruinen, aber klar, diese Spezialtags (z.B. auch castle type) kann man nur schwer mit einer Datenbank ohne hstore abdecken. Vielleicht wäre es sinnvoller, relation_type einzuführen für Relationen, anstatt alle anderen type-Arten jeweils mit Doppelpunkten oder Unterstrichen zu subtaggen? Zumindest im klassischen Schema ohne hstore kommt man durch die wachsende Key-vielfalt schon länger an die Grenzen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS mit *gutem* Empfang?
Manuel Reimer wrote: Kann jemand bestätigen, dass das Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Verbindung ausgeschaltet wird? Wie schon erwähnt wäre mir das schon wichtig, denn in den allermeisten Fällen werde ich kein Bluetooth brauchen und Akku-Laufzeit ist mir da dann doch wichtiger. Habe etwas gesucht und was ich rausfinden konnte, ist, dass Bluetooth garnicht auszuschalten geht, was ich schade finde. Stattdessen geht das Gerät irgendwann in eine Art Stromsparmodus für Bluetooth, in dem aber weiterhin mit Geräten verbunden werden kann. Sollte ich kein anderes Gerät mit MKT II Chipsatz finden, dass ähnliches bietet, dann ist der kleine Nachteil aber zu verschmerzen. Länger wie mein WBT 201 sollte er (wenn die Angaben stimmen) trotzdem durchhalten. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großbaustelle
Am 19. April 2012 15:21 schrieb fly lowfligh...@googlemail.com: Was mache ich aber wenn Schrebergärten abgerissen wurden und nun eine Wiese vorhanden ist, welche noch dazu an einen Park angrenzt. Gebaut wird aber frühesten in einem Jahr. wenn die Wiese als solche zugänglich ist, würde ich landuse=meadow verwenden oder evtl. auch landuse=greenfield. Vormalige Schrebergärten rechtfertigen eine brownfield-Einstufung sicherlich nicht, man kann sie m.E. auch nicht als entwickeltes Gebiet bezeichnen (im Gegenteil, sind sie in aller Regel dort als meist temporäre Nutzung anzutreffen, wo eben gerade noch nichts entwickelt ist, oder wo sich aufgrund der räumlichen Gegebenheiten auch zukünftig nur schwer was entwickeln lässt, wie z.B. ungünstig geschnittene Restflächen neben Bahndämmen u.ä.). Sowohl greenfield als auch brownfield passen eigentlich sowieso nicht so ganz ins Schema, weil sie Landuseplanungen sind (also sich darauf beziehen, dass dort gebaut werden soll), und nicht die aktuelle Landnutzung beschreiben. Die wäre eher Industriebrache im Fall von brownfield oder Wiese im Fall von greenfield (oder Brache, falls die Wiese nicht gemäht wird). Ich finde auch noch die ein oder andere Kohl-Sorte, auch ist am Pflanzenwuchs noch gut zu erkennen, wo Beete bzw Häuschen waren. Die Wiese wird jedoch eher schon als Park benutzt und ist öffentlich zugängig. Mal wieder ein Fall für landcover=* ? leisure=park? landuse=meadow? landcover kann man natürlich immer verwenden, da es vom Rest unabhängig ist. Was ich vor kurzem entdeckt habe: http://wiki.openstreetmap.org/wiki/Key:habitat ist nicht gerade häufig in Gebrauch, könnte aber für Details zum Bewuchst vielleicht auch Anregungen bieten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Gibt es eine Möglichkeit, den Routern quasi eine Empfehlung (per tag o. ä.) für den meistens besser geeigneten, abgesetzten Weg mitzuteilen, oder müssen die Router damit alleine zurechtkommen? Ich denke die Router müssen das alleine schaffen. Wir erfassen einen _Zustand_, keine Empfehlungen. Schon deshalb nicht, weil jeder Fahrer andere Präferenzen hat und sich das Routing dementsprechend einstellt. Tschaui, Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
On Thu, Apr 19, 2012 at 11:59:55AM +0200, Andreas Labres wrote: On 19.04.12 11:33, Martin Koppenhoefer wrote: [place=region] m.E. braucht man für diese klar definierten Verwaltungseinheiten überhaupt kein place, das ist mit admin_level und boundary=administrative hinreichend definiert. ACK. IMO sollte man dem Nominatim beibringen, dass es Staaten gibt, deren admin-boundaries mittlerweile halbwegs vollständig sind und daher diese gedachten Wolken um Place Nodes herum entbehrlich und kontraproduktiv sind! Man ist gerade dabei, dass Nominatim beizubringen. Es gibt noch ein paar kleinere Bugs zu bereinigen, aber das Ganze wird mit dem Neuimport nach dem Lizenzwechsel live gehen. Dann werden also place-Nodes und boundary-Relationen zusammengefasst und auch admin_center und label-Roles in den Boundary-Relationen berücksichtigt, was hoffentlich einen grossen Teil der Addressfehler beseitigen sollte. In AT gibt's dasselbe Theater, grade die Wolken um place=region scheinen mir zu groß gedacht und -- da es die Grenzhierarchie längst gibt - entbehlich. Nominatim kennt 25 place=region-Nodes in Österreich. Alle scheinen noch aus dem openGeoDB-Import zu stammen und Bezirke zu bezeichnen. Wenn ich mir [1] ansehe, scheinen österreichische Bezirke den deutschen Kreisen zu entsprechen (admin_level=6). Wie bereits gesagt, folgt Nominatim der Konvention, dass dieses level place=county entspricht. Es gibt also drei Möglichkeiten, das zu bereinigen. Ihr könnt die Nodes löschen, in place=county umtaggen oder einfach bis nach dem Lizenzwechsel warten, wo dann die region-Nodes ohnehin ignoriert werden. [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative ACK. Das sollte man mal final spezifizieren (und auch in Mapnik+Nominatim umsetzen). In Wien (und das gilt so ähnlich auch in anderen größeren österr. Städten) gibt es a) (Stadt-/Gemeinde-)Bezirke (admin_level 9) b) Katastralgemeinden (hauptsächlich durch Place Nodes abgebildet; Grenzen zu erfassen wäre aber denkbar) c) Grätzelnamen (entspr. place=neighbourhood) Grade bei a) und b) (momentan beide als place=suburb gemappt, was äußerst unbefriedigend ist) wäre eine durchgängige Größen- und Ebenenunterscheidung wünschenswert, in der Beschriftung im Mapnik/Standardstil genauso wie im Nominatim (der sollte überhaupt nur a) berücksichtigen und b) und c) in seiner Hierarchie ignorieren...). Ich bin verwirrt, du erwartest, dass gleich getaggte place-Nodes unterschiedlich behandelt werden? Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Am 19.04.2012 19:44, schrieb Sarah Hoffmann: Nominatim kennt 25 place=region-Nodes in Österreich. Alle scheinen noch aus dem openGeoDB-Import zu stammen und Bezirke zu bezeichnen. Wenn ich mir [1] ansehe, scheinen österreichische Bezirke den deutschen Kreisen zu entsprechen (admin_level=6). Wie bereits gesagt, folgt Nominatim der Konvention, dass dieses level place=county entspricht. Es gibt also drei Möglichkeiten, das zu bereinigen. Ihr könnt die Nodes löschen, in place=county umtaggen oder einfach bis nach dem Lizenzwechsel warten, wo dann die region-Nodes ohnehin ignoriert werden. [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Irgendwie verwirrt mich der Link gewaltig: admin_level=4: Bundesland http://de.wikipedia.org/wiki/Bundesland_%28%C3%96sterreich%29 NUTS2 was nun NUTS2 oder Bundesland (wäre NUTS3) admin_level=5: Region NUTS3 Regionen sind aber NUTS2 (Ost, Süd, West) oder NUTS4 (in etwa die Viertel Gehört aber wohl eher i talk-at ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Hallo, Am Donnerstag, 19. April 2012 14:19:48 schrieb Martin Koppenhoefer: Am 19. April 2012 13:18 schrieb Wolfgang wolfg...@ivkasogis.de: -1 start_date ist zu allgemein und kann sich auch auf den Laden im Haus oder sonst was beziehen. -1 der Laden im Haus ist sowieso ein anderes Objekt als das Haus. Um das sauber abzubilden sollte man dafür nicht daselbe Objekt verwenden. Das gibt an allen Stellen nur Probleme, z.B. beim Namen, bei der Stockwerksanzahl, beim operator und überall sonst, wo nicht komplett klar ist, worauf sich der tag bezieht. Das kann man auf verschiedene Arten tun, z.B. indem der Laden als Node gemappt wird, oder indem man für das Gebäude einen way macht, der als outer in einem Laden- Multipolygon member ist (oder anders rum, wenn die Fläche jeweils genau gleich ist). Ich halte es für besser, solche Trennungen auch durch getrennte Objekte darzustellen, als die tags immer weniger universell einsetzbar zu machen, indem man ständig neue Verschachtelungen erfindet, die kaum jemand auswerten kann. -1 ;-) Normalerweise würde ich dir Recht geben, aber start_date für das Erstellungsdatum passt sprachlich einfach nicht. Ich glaube nicht, dass sich das durchsetzt. Zu den Trennungen: Häufig wird der Laden, der sich im Haus befindet, an das Gebäude getaggt, wenn es nur einer ist. Das mache nicht nur ich so. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Auch wenn der Radweg unzumutbar ist, darf auf der Straße gefahren werden. Somit ist bicycle=no falsch (außer bei Verbotsschildern). +1 Es gibt ja auch Räder mit besonderen Ansprüchen (Liegedreirad, Anhänger, Rennrad). Die Zumutbarkeit entscheidet der Radfahrer selbst. Den Rest regelt die Rechtsschutzversicherung ;-) Für mich klingt die Beschreibung, z. B. zum Zeichen 237 (Radweg), eindeutig: Radfahrer dürfen nicht die Fahrbahn, sondern müssen den Radweg benutzen (Radwegbenutzungspflicht). (Quelle: StVO 2010-12-01) Radfahrer dürfen nicht übersetzte ich mit bicycle = no. Das trifft erfahrungsgemäß für die große Mehrheit der Radfahrer zu. Juristische Spitzfindigkeiten möchte ich aus OSM raushalten und geregelte Abweichungen würde ich in gesonderten tags unterbringen. Routingmäßig nervig wird das bicycle=no, wenn der Radweg nicht mit allen querenden Straßen (auch gegenüber) verbundne ist, ... Das muss der Mapper in der Tat dann genau beachten. Ich finde es sogar hilfreich, wenn mir der Routenplaner anzeigt, dass ich vom Radweg auf die Straße wechseln muss, um z. B. links abbiegen zu können. Wird die Route auf der Straße angezeigt und ich fahre ordnungsgemäß auf dem abgesetzten Radweg, kann ich nicht abbiegen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Gibt es eine Möglichkeit, den Routern quasi eine Empfehlung (per tag o. ä.) für den meistens besser geeigneten, abgesetzten Weg mitzuteilen, oder müssen die Router damit alleine zurechtkommen? Ich denke die Router müssen das alleine schaffen. Wir erfassen einen _Zustand_, keine Empfehlungen. Schon deshalb nicht, weil jeder Fahrer andere Präferenzen hat und sich das Routing dementsprechend einstellt. Tschaui, Jörg Ich dachte an eine einzige Default-Vorgabe für Straße meiden: wenn nicht anders gewünscht wird der Wirtschaftsweg o. ä. geroutet, also für alle die, die den parallelen Weg benutzen dürfen (z. B. Fußgänger, Radfahrer, Mofafahrer, Reiter, Traktoren) oder gezielt für einzelne Nutzertypen mit den bekannten access keys und einem neuen Wert, z. B. unwanted oder tolerated statt den üblichen (yes / designated / private / permissive / destination / delivery / agricultural / forestry / unknown / no). Ich wünsche mir Router, die die unterschiedlichen Wünsche der Radfahrer und Fußgänger berücksichtigen können, z. B. Gefährlichkeit, Oberflächenbeschaffenheit, Ampelfreiheit, Steigungen und vieles mehr. Bei http://www.openrouteservice.org/ kann man immerhin aus fünf Vorgaben auswählen, wobei die Algorithmen zum Routen sehr komplex werden können und immer noch nicht die optimale Route auswählen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Moin, ich mag in diesem Zusammenhang noch einmal kurz auf das Thema Flächennetzwerk zurückzukommen. Have a fun read.. Am 19.04.2012 13:05, schrieb Wolfgang: -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur im Multipolygon erfasst werden. Wer was dazu sammeln will, kann das über eine site verbinden. Wieder das Thema Relationen verbiegen. Damit würdest Du z.B. sämtliche Parks als type=site Relationen erfassen, in denen Du dann die MP der Einzelflächen sammelst. Aber was ist überhaupt eine Einzelfläche? Betrachten wir beispielsweise einen Schlosspark bestehend aus mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - das Schloss selbst steht auf einem Sockel im Zentrum des Parks. 1. MP - Teiche 2. MP - Rabatten 3. MP - Wiesen 4. MP - Sockel 5. MP - Schloss Die ersten drei MP werden Löcher haben (alles mit ways in der Rolle inner machbar). Kommen wir zum Park, wir erstellen unsere type=site Relation, packen die ersten drei MP hinein und stellen uns dann die durchaus interessante Frage, ob das Schloss zum Schlosspark gehört, es demnach ebenfalls mit in die Sammelrelation aufgenommen werden sollte. Bevor wir diese Frage beantworten, stellen wir aber fest, dass mehrere der Teiche kleinere Inseln haben, wir splitten also die Teiche in 1.a. MP - Wasserflächen 1.b. MP - Inseln Man beachte, dass die Löcher lt. MP-Definition nicht zur Fläche gehören, also ist (1.a.) nicht das gleiche wie (1.). Nach deiner Einschätzung legen wir also (1.) neu an, als type=site Relation (1.neu.) type=site - name=Teiche Möchten wir nun unseren Park zusammenbauen, können wir das auf zwei Arten tun: type=site Mitglieder: MPs (1.a.) (1.b.) (2.) (3.) ... type=site Mitglieder: (1.neu.) + MPs (2.) (3.) ... Ich tendiere zu letzterer Variante, allerdings enthielte type=site dann eine Relation vom gleichen Typ. Wir beschäftigen uns also mit verschachtelten type=site Relationen. Das wir den Namen von type=multipolygon auf type=site ändern, verschleiert IMHO nur die Tatsache, dass auch Flächensammlungen nichts anderes sind als Flächen. Das geht übrigens schon aus der einfachen, bisherigen Definition von MP hervor. Betrachten wir z.B. das zweite MP des imaginären Schlossparks - die Rabatten. Schon dieses kann eine (Einzel-)Flächensammlung sein - je nachdem, wieviele Rabatten der Park hat. Die momentane Definition von Multipolygonen erlaubt es uns also, mehrere Flächen zusammenzufassen, solange sie gleichen Typs sind, sprich, solange der Mapper sie als zusammengehörig empfindet und sie mit den gleichen Tags beschreiben kann. Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. Bsp.: Kreisgrenzen und Landesgrenze - es gäbe 'zig innenliegende Kreisgrenzen, die für die Berechnung der Landesgrenze nicht relevant sind - deshalb macht es für die Berechnung der Grenzgeometrie keinen Sinn, die Landesgrenze über ein nestedMP mit allen Kreisgrenz-Relationen als Mitglieder zu erfassen. Dennoch interessiert evtl. der Flächenbezug der Kreisflächen zur Landesflächen in einem anderen Kontext. Beide Wünsche ließen sich vereinen. Um auf das Beispiel zurückzukommen: Ich kann mir auch den gesamten Park als Einzelfläche vorstellen, ohne die Grenzen der Rabatten, Teiche, Wiesen, etc. Weil ich das kann, möchte ich den Park auch als type=multipolygon anlegen und nicht als type=site (Anm.: type=site entspräche einem nestedMP, wenn man daraus die Geometrie der Gesamtfläche des Parks ermitteln will). Um mit der bestehenden Definition von MP zu arbeiten, würde ich also alle relevanten Mitglieder aus (1.) (2.) (3.) und evtl. (4.) und (5.), je nachdem ob das Schloss zum Schlosspark gehört oder nicht, ermitteln und diese in ein neues MP 6. MP - Schlosspark übertragen. Das geschieht händisch, nach Ermessen des Mappenden. Der einzige explizite Zusammenhang in OSMs Daten zwischen Schlosspark und zugehörigen Teilen (Wiesen, Teichen, Rabatten, etc.) wäre dann über die Flächengrenze des Schlossparks ersichtlich - eine komplett innenliegende Wiese, die sich keine Grenze mit Flächengrenzen des Schlossparks teilt, hätte keinen expliziten Zusammenhang in den Daten. Geht es nicht um die Geometrie, sondern einfach nur um
Re: [Talk-de] Jahr der Errichtung - Ergänzung des Lübeck-Wiki
Am 19. April 2012 21:54 schrieb Wolfgang wolfg...@ivkasogis.de: Zu den Trennungen: Häufig wird der Laden, der sich im Haus befindet, an das Gebäude getaggt, wenn es nur einer ist. Das mache nicht nur ich so. ich habe das auch schon gemacht, bin aber ein bisschen davon abgekommen. Wenn man Details hinzufügt ist es meistens besser, die einzelnen Objekte klar zu trennen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Radwege
Am 19. April 2012 22:01 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag, 19. April 2012 19:34:39 schrieb Joerg Fischer: Bernhard Weiskopf wrote: Straßenbegleitende Radwege mit den entsprechenden Schildern müssen von Radfahrern benutzt werden, hier setze ich zusätzlich an die Straße bicycle = no. Halte ich genauso. Ich erfasse den Regelfall, nicht seltene Sonderfälle wie Schnee auf dem Radweg. Sonst kommt der Nächste und entfernt alle maxspeed, denn die gelten schließlich nicht für Einsätze mit Sondersignal. Ist aber ganz einfach falsch. bicycle=designated ist das tag der Wahl. +1, die Radwege sind benutzungspflichtig wenn sie da hinführen, wo man hinfahren will, das ist was anderes als ein Verbot für Radfahrer auf der Straße. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im einfachsten Fall) way für Zaun/Mauer haben, der dann als outer einer Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern man es nicht explizit als inner way wieder ausschließt, eine Site braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt benötigt für das, was man abbilden will) dann auch nicht unbedingt alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie die Teiche in einem Schloßpark würde ich keine eigene site-Relation anlegen. Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch ohne jegliche Relation. Je einfacher man zum gewünschten Ergebnis kommt, um so besser. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche nach Elbufer, Bad Schandau
Oehm, wenn ich noch mal nachhaken duerfte: Im obigen Beispiel mit Fischmarkt, Erfurt war es osm.org, das mit Coburg einige hundert km daneben lag und osm.de, der sich nur im Nachbarkreis vertan hat. Das ist mit einem aktuellen Test uebrigens noch genauso (aber das kann auch an irgend welchem Caching liegen). Ist das auch mit den place nodes zu erklaeren? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS mit *gutem* Empfang?
On 19.04.2012 18:28, Manuel Reimer wrote: Bluetooth beim iBlue747A+ tatsächlich nach einigen Minuten ohne Sollte ich kein anderes Gerät mit MKT II Chipsatz finden, dass ähnliches bietet, dann ist der kleine Nachteil aber zu verschmerzen. Länger wie mein WBT 201 sollte er (wenn die Angaben stimmen) trotzdem durchhalten. Der Akku im im iBlue ist baugleich zu den Nokia Handy-Akkus. Da könntest du wohl Ersatz mitnehmen. Habe es nicht genauer getestet aber ich habe gehört der Logger verliert Einstellungen wenn man die Batterie rausnimmt. Falls ich mal eine halbe Stunde habe werde ich das testen und im Wiki mit dokumentieren. Sonst kannst du ja auch unterwegs mit einer externen USB Batterie nachladen falls du weit ab von einer Steckdose bist. Download der Loggerdaten auf ein Android Smartphone funktioniert auch, damit hast du auch ohne PC in der Nähe quasi unbegrenzt Speicherplatz. Bist du in der Nähe München? Ich kann dir meinen Loger zum Testen ausleihen. Per Post verschicken lohnt sich nicht, bei ebay git es den Logger gebraucht für ca. 35 EUR. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
