Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Am Mittwoch, 9. Januar 2008 08:32:06 schrieb Martin Trautmann: Ich werde eine solche Liste vielleicht wieder auf die entsprechende talk-Seite stellen, wie bei http://wiki.openstreetmap.org/index.php/Talk:Baden-Württemberg#Korrekturvor schläge Bonn-Brühler Straße Bonn-Brühler-Straße ... da finde ich die alte Schreibweise selbst aber richtiger Die ist meines Wissens auch vollkommen korrekt. Holzgasse, Tonnepütz, Lohheckenweg Holzgasse ... sollte man hier besser dreimal das tag Name vergeben, statt alles mit ,, ; oder / in einen Eintrag zu packen? Das wurde anscheinend schon von dem betreffenden Mapper korrigiert. Chateoneufstraße Chateauneufstraße Henry-Spaak-StraßeHenri-Spaak-Straße Oh Gott! Das sind 27 Objekte, die zum ersten gehören, was ich in OSM vor einem 3/4 Jahr gemacht habe... und der Fehler hat sich bis heute gehalten! Heppertzweg Heppertsweg Heppertsweg ist richtig und taucht auch so in meinen Aufzeichnungen auf... Meiergasse Meiersgasse Die Meiersgasse in Alfter gibt es, sie wurde von einem anderen Mapper gemacht. Eine Meiergasse gibt es wohl im benachbarten Bornheim. Quiriniusstraße Quirinusstraße Da hat OpenGeoDB Recht! Willi-Haas-Straße Willy-Haas-Straße ...genau wie hier! Bei den noch offenen Einträgen fehlt mir z.B. die Ortskenntnis für Am Lindchen und Im Lindchen. Am Lindchen ist richtig. :-) Danke für die Hinweise! Bei einigen Straßennamen wäre Ich im Leben nicht darauf gekommen, daß sie falsch geschrieben sind - gerade weil Ich sie schon mein ganzes Leben lang kenne. ;-) Ich verstehe diese OpenGeoDB-Sache irgendwie noch nicht so ganz. ;-) Die ist ja auch erst am Anfang: Ich bin in der ersten Runde, wo nur der nächste Nachbar zur Gemeinde-Koordinate verglichen wird. Der opengeodb fehlt bisher die Detailkenntnis von Wegenetzen und Straßen. Die wächst gerade erst mal bis zur Ortsteil-Ebene. Als nächstes kann ich damit prüfen und verbessern, welche Ortsteil-Koordinaten ich habe. In der zweiten Runde erfolgt also später ein Abgleich zum passenden Ortsteil. In der Runde sollten dann auch Einträge auffallen, die fälschlich einer Nachbargemeinde zugeordnet wurden, weil dieser Ortsteil näher an der Gemeindegrenze als an der Gemeindekoordinate lag und die Nachbargemeinde Straßen mit gleichem Namen aufweist. OK, aber woher stammen nun die Straßendaten? Auf der Seite von OpenGeoDB erweckt alles den Anschein, daß es in OpenGeoDB keine Straßen gäbe, sondern der Fokus auf Städten und Gemeinden liegt. OK, mit Hilfe der Erste Test-Daten-Diskussion reime Ich mir jetzt zusammen, daß du Straßenlisten der Gemeinden genommen und im Umkreis der OpenGeoDB-Gemeindeeinträge einen Vergleich dieser mit denen in OSM gemacht hast. Richtig? An der Stelle kann ich aber Hilfe brauchen, ob jemand ein Script schreiben mag, das alle zusammenhängenden Weg-Stücke mit gleichem Namen in einem einzigen Tabelleneintrag zusammenfassen kann. Damit kann ich mich bei z.B. zehn Weg-Einträgen mit gleichem Namen auf die drei beschränken kann, die getrennte Strassen darstellen, während die anderen über gemeinsame Knoten oder Knotenduplikate mit minimalem Abstand damit zusammenhängen. Mit soetwas kenne Ich mich leider auch nicht genügend aus. Schönen Gruß Martin Auch schöne Grüße und nochmal Danke für deine Mühen! -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse =farm fXr ganze Felder/Wiesen, Unsinn?
ich bin - wieder mal - fuer eine trennung: landuse zeigt an, was da ist, wird also fuer eine flaeche, die voll mit baeumen steht, als forest oder sowas getaggt. ob und wie die flaeche wirtschaftlich genutzt wird, muss in ein separates tag, genauso wie eventuelle andere attribute. Genau, es ist nur irgendwie genau umgekehrt ;) landuse scheint anzeigen zu sollen, wie etwas genutzt wird (z.b. forest) und nature sagt, was dort rumsteht (z.b. wood). Und da zumindest in D der wald bis auf wenige ausnahmen genutzt wird, setzt man einfach immer beide attribute. Ausnahmen sind z.b. baumbereiche in landuse=recreation_ground oder landuse=cemetery oder eben diese leisure-sachen wie leisure=park. Sorry wenn ich den Thread nochmals aufwärme, aber ich frag mich grad wozu beide Attribute notwendig sind. Gibt es ein landuse=forest (also eine Forstwirtschaftliche Landnutzung) auf der KEINE Bäume stehen (also natural=wood)? Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] On 2008-01-08 23:20, Martin Trautmann wrote: Hallo, wie gewünscht habe ich auch mal Nordrhein-Westfalen abgeglichen, wie viele der gelisteten Gemeindestraßen schon in OSM erfasst sind. Bemerkung am Rande: Die extrahierten Daten nach Bundesland, die ich hier benutzte, enthalten einige Strassen, die hollaendisch klingen und eine groessere Anzahl (etliche Dutzend), die ich eher Niedersachsen zuordnen wuerde. http://download.geofabrik.de/osm/europe/germany/nordrhein-westfalen.osm.bz2 groessere Menge an Strassen, die ich bei der Domainfactory enthalten Die Bundeslandgrenzen, die die geofactory laut http://biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Schoenen Gruss Martin -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Besenwirtschaft/Straußwirtschaft/Heck enwirtschaft/...
On Tuesday, 8 January 2008 23:52:40 +0100, Michael Kugelmann [EMAIL PROTECTED] writes: Christoph Eckert schrieb: das generelle Problem ist IMO aber schon gegeben. Es gibt Straßen, die nur zu bestimmten Uhrzeiten befahrbar sind, wie auch Fähren. Eine Routingsoftware sollte IMO davon wissen. [...] Das finde ich auch OK. Aber so weit sind wir im Moment noch gar nicht. Und: das was Christoph geschildert hatte, ist ja ein regelmäßiges bzw. wiederkehrendes Verhalten = das kriegt man in den Griff. Manches kann man sicher mit den bereits existierenden Restrictions (date_on, date_off, day_on, day_off, hour_on, hour_off) erreichen. Bei den Besenwirtschaften ist es ja eigentlich viel schlimmer. Das ist ja nicht regelmäßig = jedes Jahr anders [...] Ein aehnliches Problem hat man aber auch bei mancher Ausflugsgaststaette. Da gibt es einige, die z.B. nur an Wochenenden offen sind oder nur waehrend der Neben- und Hauptsaison. Never the less suche ich immer noch so etwas wie ein TAG für einen Besen. Hat niemand eine Idee, wie man so etwas taggen kann? Notfalls müsste man (ich) über proposed features so etwas einführen. ... und als Icon-Vorschlag dann einen Besen? :-) Momentan habe ich vor, die Besenwirtschaften in meinem Umfeld (Kernen im Remstal, da gibt es einige) als Restaurant zu taggen und die Besen-Eigenschaft im Namen aufzufuehren. Da koennte ein Fremder, der mit dem Begriff im Namen nichts anfangen kann, dann zwar oefter vor verschlossener Tuere stehen, alle anderen wissen um die unregelmaessigen Oeffnungszeiten und man kann spaeter immer noch nach diesen suchen und entsprechend (um)taggen. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] groessere Menge an Strassen, die ich bei der Domainfactory enthalten der satz keinen sinn ergibt, streichen bitte... (wurde versehentlich nicht gelöscht) -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Hallo, Die Bundeslandgrenzen, die die geofactory laut http:// biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] On 2008-01-09 13:27, Frederik Ramm wrote: Hallo, Die Bundeslandgrenzen, die die geofactory laut http:// biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Ich habe keine Ahnung, in welchem Format sie derzeit genutzt werden und wie das korrigierbar wäre. Bei Bedarf kann ich aber zumindest raussuchen, bei welchen Koordinaten besonderer Korrekturbedarf besteht. In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Schoenen Gruss Martin Trautmann -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] §5 UrhG, Städti
Es gibt ja im deutschen Urhebergesetz diesen netten Paragraphen 5, der amtliche Werke als gemeinfrei (public domain) einstuft. (1) Gesetze, Verordnungen, amtliche Erlasse und Bekanntmachungen sowie Entscheidungen und amtlich verfaßte Leitsätze zu Entscheidungen genießen keinen urheberrechtlichen Schutz. Also habe ich mal auf den Webseiten der Stadt gestöbert und bin in den Satzungen zum Thema Stadtrecht häufiger über Formulierungen wie Aufgliederung und örtliche Abgrenzung des Fassungsbereiches und der engeren Schutzzone sind in dem Lageplan des Städtischen Vermessungsamtes Baden-Baden Maßstab 1:2.000, der Bestandteil dieser Rechtsverordnung ist, dargestellt. Dieser Lageplan ist bei der Stadtverwaltung Baden-Baden – Amt für öffentliche Ordnung – in Baden- Baden, Gutenbergstr. 13, niedergelegt. Er kann dort während der Dienststunden eingesehen werden. gestolpert. Da der Lageplan ja explizit als Teil der Rechtsverordnung aufgeführt ist, müsste er ja auch gemeinfrei sein. D.h. ich könnte beim Amt für öffentliche Ordnung aufkreuzen, Fotos der Karte machen und munter für OSM digitalisieren, oder? Hat jemand bei diesem Vorgehen irgendwelche Bedenken? Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Was haltet ihr davon? MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Raphael Studer schrieb: ... Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. interessanter Unterscheidungsansatz -- mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Zuordung von Straßen zu Orten via Rel ations
Hi, Da sich Martin Trautmann ja momentan die Arbeit macht, Straßen Orten zuzuordnen könnte man das Script doch gleich hernehmen um damit die entsprechenden Relations in OSM Anzulegen, dann könnte man das in Zukunft direkt aus den Daten rauslesen und muss nicht über den Abstand raten. Außerdem könnte man bei der Gelegenheit alle zusammenhängenden Wege mir selben Namen auch über eine Relation verbinden. MfG Andreas Hubel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Am Mittwoch, 9. Januar 2008 14:15 schrieb Frederik Ramm: Hallo, Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Ich habe keine Ahnung, in welchem Format sie derzeit genutzt werden und wie das korrigierbar wäre. Das sind einfache Polygon-Dateien, die pro Zeile einen Punkt mit geographischer Laenge und Breite enthalten. Das ist alles, was ich brauche - eine Info der Form die Landesgrenze von NRW verlaeuft ueber die folgenden Punkte Bei Bedarf kann ich aber zumindest raussuchen, bei welchen Koordinaten besonderer Korrekturbedarf besteht. Ich will halt in diesem Punkt sehr korrekt vorgehen. Jede Datenquelle, mit der ich das abgleiche, muss lizenzmaessig astrein sein. Ja, wobei das raussuchen von einzelnen Punkten in einer Landkarte erstmal erlaubt ist In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Faende ich auch gut, aber mir ist unklar, wo man die Daten in einer freien Form herbekommen kann. Eigentlich muessten Laendergrenzen doch in irgendeiner Form amtlich veroeffentlicht sein... Ja, da bin ich zumindest für Hamburg drann. Siehe: http://wiki.openstreetmap.org/index.php/Hamburg/Grenzbeschreibungen Anscheinend gibt es sowas im Netz aber nicht für übergeordnete Ebenen (Bundesländer/Landesgrenzen) zumindest hab ich da noch nichts gefunden. Ich hab in Hamburg schon ziemlich lange hin und her telefoniert bis ich einen Ansprechpartner hatte. Das ist eigentlich etwas für einen Geschichtsstudend der eine Freundin hat die in einem Bundesarchiv arbeitet :-). Gruß Sven Anders ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Javascript-Editor für OSM
Nett. Noch ein bischen mehr JavaScript und das Ding wäre noch um einiges besser. Gibts irgendwo nen SVN oder Teilprojekt in dem es darum geht das Ding auszubauen und auf die Hauptseite mit einzubetten? MfG Andreas Hubel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
In-Reply-To: [EMAIL PROTECTED] On 2008-01-09 16:14, Andreas Hubel wrote: Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. Das waere vor allem dann verkehrt, wenn man diese Daten direkt aus der opengeodb holen wollte, statt sie gleich der OSM mitzugeben - das fuehrt nur zu einer Verdoppelung der Daten und verhindert gleichzeitig, dass Änderung zurückfliessen würden. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. Im Gegenteil steckt genau im originalen part_of die Relation drin, weil hier die loc_id des naechsten opengeodb-Eintrags steckt. Svens Beispiel scheint das flachzuklopfen (part_of / Teil von / is_in_loc_id gegenueber is_in) openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier 50011 name Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche http://kent.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400* kamen mit 0.2.5 und 0.2.6 erst hinzu) In der Name (50010:NAME) steckt die vollstaendige Namensbezeichnung drin, wie z.B. Freiburg im Breisgau. Die 50011 wird derzeit nicht wirklich genutzt. Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf den Basisteil wie freiburg (lower case, no Umlauts, no extensions) openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Die wiki-Seite sollte vielleicht mit einem Beispiel gefuettert werden type: Stadt, Landkreis, Gemeinde, Stadtviertel, Stadtbezirk, Ortsteil, ... layer: das gibt die Hierarchie-Ebene an. Beispielsweise gibt es Hamburg als Bundesland (AGS 02, layer 3), als Landkreis (AGS 02000, layer 5) und als Gemeinde (AGS 0200, layer 6) Auf layer 4 liegen die Regierungsbezirke, auf layer 7 die Orte, auf layer 8 die Ortsteile, auf 9 die Strassen, auf 10 Einzeladressen Durch Teil von (part of, is_of) und Ebene (level, layer) wird ausreichend genau beschrieben, wo im Baum das ganze hierarchisch haengt. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden wikipedia-Name: name=freiburg opengeodb:name=Freiburg im Breisgau wikipedia:de=Freiburg_im_Breisgau openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich sind, teils direkt durch Benutzerwunsch. Von daher waere 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem Feld einfach nur eine Abkuerzung. generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Was haltet ihr davon? IMHO fuer OSM wichtig ist vor allem die loc_id als Referenz zur opengeodb selbst. Hilfreich erscheint mir die part_of / is_in_locid / Teil von / 40010 wie auch die AGS / community_identification_number / Gemeindeschlüssel / 50060 level / layer / Ebene / 40020 ist für die Hierarchien in der openbeodb wichtig und steckt in Deutschland bis zur Gemeindeebene auch implizit im AGS (zweistellig: Bundesland bis achtstellig: Gemeinde). Es gibt die Überlegungen, den AGS auch als nicht-amtlichen oder halb-amtlichen Gemeindeschlüssel bis ganz nach unten durchzuziehen. Beispielsweise gibt es amtliche fünfstellige Strassenschlüssel, also 13stellige Schlüssel für jede einzelne (Gemeinde-)Strasse in Deutschland. Postleitzahlen sind einerseits sehr attraktiv, andererseits aber sehr problematisch: für eine korrekte Zuordnung müsste man in der OSM eine durchgehende Strasse tatsächlich an der PLZ-Grenze trennen. Es kann sogar sein, dass eine Strasse zu einer PLZ gehört, die Anschriften an dieser Strasse aber durch die postalische Zuordnung ganz anderen PLZ-Einträgen zugeordnet sind - in Österreich scheint das gängige Praxis zu sein. Von den Namesvarianten würde ich nur name / 50010 verwenden, je nach Bedarf auch NAME_7BITLC / sort_name / ASCII / 50012 Die anderen Namensvarianten sind wenig interessant. Hier muss aber
Re: [Talk-de] landuse = forest oder natural=wood
Ich finde, die Unterscheidung ist überflüssig. Am besten wäre es, wir würden einen der beiden Keys abschaffen. Da die beiden Dinge in Mapnik auch noch auf unterschiedlichen Zoomstufen gerendert werden, entstehen so schief aussehende Karten. Zugegeben, dies könnte (müsste) bei den Renderern geändert werden. Die gegenwärtige Praxis ist mMn weitgehend wilkürlich. Ich verwende jetzt nur noch landuse=forest, nachdem ich zuvor einige zeitlang natural=wood genommen habe. Ich glaube aber, die Mehrheit verwendet mittlerweile landuse=forest. Eine Auszeichnung der Flächen mit beiden Attributen, wie von keichwa vorgeschlagen, finde ich auch nicht so gut. Longbow4u ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forest oder natural=wood
Ich finde, die Unterscheidung ist überflüssig. Am besten wäre es, wir würden einen der beiden Keys abschaffen. Ich finde, nur weil es in D/CH nicht sehr oft vor kommt, ist das kein Grund es abschaffen zu wollen. Es gibt einen Unterschied, mag er auch in unserer Region kleiner sein als anderswo. Trotzdem sollten wir ihn berücksichtigen. Da die beiden Dinge in Mapnik auch noch auf unterschiedlichen Zoomstufen gerendert werden, entstehen so schief aussehende Karten. Zugegeben, dies könnte (müsste) bei den Renderern geändert werden. Die gegenwärtige Praxis ist mMn weitgehend wilkürlich. IMO entstanden die aktuellen Zuordnungen nicht aus willkür (CH ist fast alles natural=wood), sondern aus unklar- oder unwissenheit. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Tagwatch vom 9.01.2008
Moin. Ich habe heute mal wieder den neusten planet.osm ausschnitt von Deutschland [1] genommen und eine neue Tagwatch Seite erstellt. Dabei hab ich auch gleich ein wenig an dem script dazu rumgefummelt. Der eigentlich unterschied zu vorher besteht lediglich darin, das die Beschreibungen zu den einzelnen Tags aus dem Template auf den jeweilgen [[Tag:Key=Value]] seiten kommen oder wenn diese nicht existiert von den unterseiten der Tagwatch Seite geholt werden. Ist beides nicht vorhanden, werden die Tags am unteren Rand der Seite ohne weitere Informationen aufgelistet. Zudem wird angezeigt ob es sich bei dem jeweiligen Tag um einen Node, Way oder Area handelt. Desweiteren wird die feature palette von osmarender6 genommen um die beispiele zu rendern. Viel spaß beim durchwühlen. http://etricceline.de/osm/index.htm Gruß Jörg --- [1] http://download.geofabrik.de/osm/europe/germany.osm.bz2 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Raphael Studer schrieb: ... Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. interessanter Unterscheidungsansatz Jau. Christbaumplantagen oder Baumschulen wären besser als landuse=farm zu taggen (plus natural=wood). der Wald schon immer da das ist schon eine nette vorstellung :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Am Mittwoch, 9. Januar 2008 16:14 schrieb Andreas Hubel: Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. Ja, da gibt es mehrere Ansätze. Ich will gerne begründen, warum ich alle Daten aus der OpenGeoDB auch in OSM haben möchte. OpenGeoDB ist im deutschsprachigen Raum sehr gut, aber leider nur dort. Wenn jetzt jemand von außerhalb Daten wie z.B. Postleitzahlen benutzen möchte muss er entweder openGeoDB kennen oder die Daten müssen in OSM stehen. In Wikipedia gibt es den Grundsatz: das Wikipedia kein Platzproblem hat, und genau das sehe ich für OSM auch, die Daten werden ja benutzt, sonst würde ja auch niemand OpenGeoDB nutzen, warum soll man sie nicht auch ohne Medienbruch gleich in OSM nutzen können. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. Wenn es nicht mehr genutzt wird, ist es ganz einfach es überall zu entfernen. Im Moment wird es z.B. bei www.openstreetmap.org in der Suche benutzt. Und ich erzeuge ja auch noch zusätzlich Relationen, damit man auf das Tag nicht angewiesen ist. openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Wenn sie wirklich redundant sind, kann sie ja jemand aus der OpenGeoDB löschen. Dann tauchen sie beim nächsten Update nicht mehr auf. Wenn sie doch irgend einen Sinn haben ist es doch schön sie direkt in OSM suchen zu können. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. Ja, solange der Name und der OpenGeoDB Name identisch sind. Aber ein Benutzer kann (uns soll ja auch jederzeit dürfen!!) den Namen ändern. Werte die mit OpenGeoDB: anfangen, sollte er möglischst nicht ändern, denn die kommen ja (in jedem Fall) aus der OpenGeoDB Datenbank, und werden beim nächsten Import überschrieben. openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Warum? Der String wird automatisch erzeugt und für den Benutzer ist es angenehmer die URL zu kennen. Wer mal versucht hat mittels google auf die URL http://fa-technik.adfc.de/code/opengeodb/dump/ zu kommen wird mir bestimmt recht geben, dass die Daten im Moment alles andere als einfach zu finden sind. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Nun ist OpenGeoDB ja nicht nur für Deutschland sondern auch für ein paar Nachbarländer aktiv und ich möchte nur eine Übersetzung einfügen. Ich hatte auch mal Überlegt ob ich mir die Sache einfach mache und stattdessen einfach: openGeoDB:50060 statt openGeoDB:community_identification_number nehmen sollte, finde es aber besser sprechende Namen zu verwenden. Bin gerade etwas frustiert, weil ich das Gefühl hatte, nach der letzten Rückmeldung (die ich im übrigen sehr konstruktiv fand!!), jetzt wirklich los zu legen und nicht wieder über so grundlegende Designfragen diskutieren zu müssen, aber laßt Euch davon nicht abhalten, denn es wird ja eher besser, wenn ein paar mehr Leute Ihren Sempf dazu geben! Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Am Mittwoch, 9. Januar 2008 17:17 schrieb Martin Trautmann: openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier 50011 name Ja, das war ein Übertragungsfehler. Ich meinte: 50010. Kann das im Moment nicht im Wiki ändern (gibt ne Fehlermeldung beim bearbeiten der Seite). Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche http://kent.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400* kamen mit 0.2.5 und 0.2.6 erst hinzu) In der Name (50010:NAME) steckt die vollstaendige Namensbezeichnung drin, wie z.B. Freiburg im Breisgau. Das ist IMHO für OSM der Name, weil auf einer Landkarte ja üblicherweise auch die Bezeichnung ausgeschrieben wird. Die 50011 wird derzeit nicht wirklich genutzt. Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf den Basisteil wie freiburg (lower case, no Umlauts, no extensions) solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden wikipedia-Name: name=freiburg opengeodb:name=Freiburg im Breisgau wikipedia:de=Freiburg_im_Breisgau Warum nicht trotzdem alles nennen, es ist ja ne Zusatzinformation, dass diese Daten in anderen Quelle auch so verzeichnet sind, also z.B. name=München openGeoDB:name=München wikipedia:de=München Das hat auch den Vorteil, das man auch als Benutzer schnell mal einen Tippfehler finden könnte. Wenn z.B. sowas auftaucht: name=Muenchen openGeoDB:name=München openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich sind, teils direkt durch Benutzerwunsch. Von daher waere 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll. Warum darf der String nicht länger sein? Gibt es irgend ein Problem wenn der String zu lang wird? openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem Feld einfach nur eine Abkuerzung. Das finde ich nicht so gut (das ein Feld auch noch für einen anderen Zweck benutzt wird, denn es gibt ja kein Autokennzeichen: BW) Ich hatte in einer früheren Version Die anderen Namensvarianten sind wenig interessant. Hier muss aber darauf hingewiesen werden, dass es auch landesspezifische Varianten gibt, z.B. opengeodb:name=Deutschland opengeodb:name:en=Germany opengeodb:name:fi=Saksa opengeodb:name:he=גרמניה usw. Ist genau so implementiert. Bei Daten wie population / 60070 muss beachtet werden, dass solche Daten in der opengeodb in der Regel mit einer Datumsangabe kombiniert sind - z.B. gültig am Stichtag 2006-12-31 (genauer: von 2006-12-31 bis 2006-12-31). Guter Hinweis: den Stichtag sollte ich hier noch hinzufügen. Ich hab eben mal nachgesehen, warum ich das nicht gemacht habe: mysql select * from geodb_intdata where valid_until3000-01-01; Empty set (0.00 sec) Ist wohl erst in neueren Versionen drin. Ich hatte gehofft, das in OpenGeoDB nicht mehr so viel Bewegung im Datenschema ist. Gruß Sven Anders ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplatz
Am 08.01.2008 17:49 schrieb Christian Maurer: André Reichelt schrieb: Dimitri Junker schrieb: Hm, mein Medion setzt alle halbe Meter einen Punkt. Da kann man sogar erkennen, wenn man einen Schritt nach links geht. Also entweder Ihr verwendet schlechte GPS-Systeme oder ich mache irendetwas falsch/besser. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de das kann schon sein das dein medion das macht, und ich glaub dir auch noch das man den schritt nach links sieht, ABER mach das ganze sagen wir 4x im abstand von je 2 std, wenn die 4 tracks dann immer noch übereinanderliegen dann will ich auch so einen medion haben... Eben. Auflösung und Genaugkeit sind zwei paar Schuhe. Mit hoher Auflösung falsche Daten anzeigen ist durchaus möglich.-) Harald. --+- Harald Kirsch | pifpafpuf bei gmx punkt de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Radfahrer absteigen, Hunde
Am Montag, den 07.01.2008, 17:34 +0100 schrieb Guenther Meyer: Am Montag 07 Januar 2008 schrieb Daniel Schmidt: * Radfahrer absteigen: Hier führt ein Radweg über eine Brücke. Auf der Brücke selbst dürfen die Räder jedoch nur geschoben werden. bicycle=no waere richtig! ich wuerds nur als fussweg taggen - ohne angabe fuer fahrraeder. Nach der Beschreibung ist es ein Radweg über eine Brücke bei dem die Räder aber nur geschoben werden dürfen. Also: highway=cycleway bicycle=no ;-) Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Ich halte verwaltungsgrenzen nicht für vorrangig wichtig. Zumindest nicht in D und auch nicht in der EU. Für mich haben wald- und sonstige grünflächen sowie flüsse und schienenstrecken eine hohe priorität :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Duplicated Nodes und wie man sie los wird
Raphael Studer schrieb: AFAIK kann die JOSM auch automatisch beheben, indem man die Karte Validiert und ahschliessend FIX drückt. Ja, mit dem Validator-Plugin von JOSM gibt es die Möglichkeit das automatisch fixen zu lassen. Allerdings kann es bei Punkten ausserhalb des Download-Rechtecks sein, dass den doppelten Punkten ein nicht heruntergeladener Weg zugeordnet ist. Bei Hochladen kommt dann die etwas verwirrende Meldung Precondition failed. Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Nicht mehr durchflossene Flussbetten
Hat jemand eine wie man diese nicht mehr durchflossenen Flussbetten taggt ? Um hier kurz auszuführen was ich meine: Im Lauf seines Lebens windet sich ein Fluss kurvig durch die Natur, immer auf der Suche nach dem schnellsten Weg. Wenn also ein Fluss einen kürzeren Weg findet, kann es sein, dass eine Schlinge nicht mehr durchflossen wird und mit der Zeit vom Fluss abgetrennt wird um zu einem stehenden Gewässer wird, da es ja noch Wasser führt, aber keine Verbindung mehr zum Fluss hat. Wie würdet ihr sowas taggen ? Ein waterway=river ist es ja nicht mehr. Aber es als See via natural=water zu taggen widerstrebt mir auch ein bisschen. -- Sebastian Gebhard PGP: 6CD7EBCE www.sege-mag-dich.net ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie weit sind wir in der Schweiz ?
Andreas Stricker [EMAIL PROTECTED] wrote: Das zeigt, dass OSM gerade für Fussgänger sehr attraktiv werden kann. Das zeigt, dass OSM auch für Wanderer Potenzial hat! Die Mehrzahl der Fußwege dürften Wanderwege sein, die von Touristen gezeichnet wurden. Nur mal so als Beispiel. Den Wanderweg über den Lötschenpass, auf dem ich letzen Sommer unterwegs war z.B. (ganz im Gegensatz zur Straße ins Gasterntal) bei OSM existent. BTW, der GPS Empfang in solchen vergleichsweise schmalen Bergtälern ist alles andere als optimal. Mein SIRF II hatte damit jedenfalls echte Probleme. Das ist auch der Grund weshalb ich die genannte Straße bisher nicht gezeichnet habe. Wie sieht das eigentlich rechtlich aus, wenn man solche Straßen in Google Earth aus dem Luftbild abmalt und das Polygon dann mit josm in Straßen umwandelt. Ist sowas legal? Ich finde ja sowieso, dass wir eigentlich dringend halbwegs brauchbare Richtlinien für Wanderwege brauchen. Gruss Sven -- I'm a bastard, and proud of it (Linus Torvalds, Wednesday Sep 6, 2000) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erste Test-Daten von OpenGeoDB
Hallo Holger, Holger Issle schrieb: In Weil und Umgebung gibt es ein paar Spinner, die auch die Namen der Feld- und Waldwege erfasst haben, so es welche gibt. Nur die markanten Punkte im Schönbuch (Waldgebiet) fehlen noch ;-) Eh ? Was soll das denn heissen ? Na klar erfasse ich Wegenamen im Schönbuch. Der Wanderverein (oder wer auch immer) hat sich die Mühe gemacht, Holzschilder mit Namen wie Hoppelesklingensträßchen zu schnitzen und an die Bäume zu nageln. Warum nicht ins OSM damit ? Übrigens hat unsere Gemeinde kürzlich die Standorte der Hundetoiletten veröffentlicht. Das könnte man genausogut aufnehmen, schliesslich mag es ja gewissenhafte Hundebesitzer geben, die sich im Notfall zum nächtgelegenen Beutelspender Fussgänger-navigieren lassen wollen. Vorschläge für amenity-tags sind willkommen. Grüsse, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nicht mehr durchflossene Flussbetten
Sebastian Gebhard schrieb: Ein waterway=river ist es ja nicht mehr. Aber es als See via natural=water zu taggen widerstrebt mir auch ein bisschen. Also die Engländer nennen sowas oxbow-lake, also See. Und da deren Interpretation der Tags bei OSM das Maß der Dinge ist, weil die Tags in/nach deren Sprache eingeführt werden würde ich mich daran halten das Ding als See zu taggen. Aber davon abgesehen spielt bei meiner Auffassung von See die Entstehung keine Rolle, sondern was es jetzt ist. Vollgelaufene Kiesgruben würde ich auch als See taggen. Und das dieser See mal ein Fluss war erschließt sich ja aus der Form und dem angrenzenden Fluss. Aber wenn du gesonderten Wert darauf legst, kannst du ja zusätzlich ein oxbow=yes taggen. Ist ja alles möglich. http://en.wikipedia.org/wiki/Oxbow_lake Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] dead-end-Gleise z.B. in Kopfbahnhof
Mario Salvini schrieb: gibts da schon ne Methode die gesondert zu markieren? Wäre ja schon sinnvoll, bei ausgefallenen GLiskontrukten, ob ein Gleis nur noch nciht zuende erfasst wurde, oder einfach ein Ende hat. Für Straßen gibt's da noexit=yes: http://wiki.openstreetmap.org/index.php/Key:access#noexit Wieso sollte man das nicht analog auch für Schienenwege verwenden? Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Linuxtag 2008 Berlin
Hallo, am Freitag laeuft die Abgabefrist fuer Papers zum Linuxtag 2008 in Berlin ab. Wenn niemand anders dazu Lust hat, werde ich einen OpenStreetMap-Vortrag einreichen, aber ich will mich nicht vordraengeln ;-) Unabhaengig davon wird es hoffentlich auch wieder einen kleinen OSM-Stand geben, aber das muss man zum Glueck noch nicht jetzt planen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Jau. Christbaumplantagen oder Baumschulen wären besser als landuse=farm zu taggen (plus natural=wood). der Wald schon immer da – das ist schon eine nette vorstellung :) Wenns nicht so ist, dass der Wald schon da war bevor wir da waren, dann korrigier mich bitte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Duplicated Nodes und wie man sie los wird
Ja, mit dem Validator-Plugin von JOSM gibt es die Möglichkeit das automatisch fixen zu lassen. Allerdings kann es bei Punkten ausserhalb des Download-Rechtecks sein, dass den doppelten Punkten ein nicht heruntergeladener Weg zugeordnet ist. Bei Hochladen kommt dann die etwas verwirrende Meldung Precondition failed. Weshalb wird ein Punkt ausserhalb des Download Rechtecks herunter geladen? Das geschieht doch nur wenn er zu einem Weg gehört und somit wär dieser Weg auch dabei oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
