Re: [Talk-de] Extrahieren/filtern direkt aus PBF?
Am 10. März 2012 20:32 schrieb Frederik Ramm frede...@remote.org: ... * imposm tut zwar eigentlich was ganz anderes, ist aber in Python gemacht und liest pbf-Daten ein, d.h. Du koenntest Dir dort bei Bedarf den Lese-Code klauen und dann selber was in Python machen. Vielen Dank für den Tipp mit imposm. Das habe ich auch schon mal für was ähnliches benutzt. Bloß hatte ich gar nicht auf dem Schirm, dass es auch direkt PBF-Dateien einliest. Das beschleunigt die Sache schon sehr! (z.B. Deutschland: 1,2 GB PBF statt 20 GB XML) Grüße Marian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Schon wieder: entrance nodes, housenumber und POIs
Jaja, ich weiss, mir kommt die Diskussion auch schon den Ohren heraus, aber ich stolpere doch immer wieder ueber Faelle in der Praxis, in denen ich nicht weiss, wie ich taggen soll. Ich wuerde hier gerne noch einmal ein Beispiel geben, und das dann moeglicherweise auch mal so im Wiki dokumentieren: Ein Gebaeude, eine Plakette verraet einen hist. namen: Haus zum Schwan. Umgeben von drei Strassen, je einen Eingang zu jeder Strasse. Eingang 1: Von A-Strasse, Zugang zu einem Blumenladen, Adresse unbekannt. Eingang 2: Von B-Strasse, Zugang zu 2 Aerzten, einem Rechtsanwalt und einem Versicherungsbuero, Adresse ist klar erkennbar A-Strasse 5 Eingang 3: Von C-Strasse, Zugang zu Wohnungen, Hausnummer ist 23, wahrscheinlich C-Strasse Ich wuerde so taggen: Gebaeudeumriss mit building = yes name = Haus zum Schwan Eingang 1 als node auf dem Umriss mit entrance = main wheelchair = yes shop = florist name = Blumen Giesela (keine addresse weil unbekannt, sonst hier) Eingang 2 als node auf Umriss entrance = main wheelchair = yes access = destination (Tuer ist nicht offen, man muss klingeln) addr:housnumber = 5 addr: street = A-Strasse Einang 3 als node auf Umriss entrance = yes access = private wheelchair = no addr:housenumber = 23 addr:street = C-Strasse Dazu 4 POI nodes im Gebaeudeinneren in der Naehe von Eingang 2 amenity = doctor name = Praxis Dr. Knochenbrecher amenity = dentist name = Zahnarztpraxis Dr. Bohr office = insurance name = Futsch und Weg A.G. office = lawyer name = Fuchs und Co. Mir schon bekannte Nachteile: - Datensatz der inneren POIs ist nicht vollstaendig, weil Adresse fehlt - keine formale Zuordnung von entrance und POI - uneinheitliches Tagging, weil POI einmal extra, einmal direkt am entrance node (- rendering noch unschoen bei Hausnummern/POI am entrance) GIbt es Verbesserungsvorschlaege mit weniger Nachteilen? Lieber Adresse redundant an alle POIs (+entrance?)? Eine Relation um POIs und entrance? Gruss, Chaos99 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] station=subway_entrace
Mir ist aufgefallen, dass der häufigste Wert in der Datenbank station=subway_entrance ist. Diesen Wert finde ich ein bisschen seltsam, da ein häufiges Subtagging-Schema in OSM ist: a=b, b=c wobei c in der Regel b weiter beschreibt. Bei railway=station würde ich erwarten, dass mit station der Bahnhof weiter unterschieden wird (so wie es die anderen beiden station-Werte light_rail und subway auch tun.) http://taginfo.openstreetmap.org/tags/station=subway_entrance http://taginfo.openstreetmap.org/tags/railway=subway_entrance Weiss jemand, wo diese station=subway_entrance herkommen (gibt es dazu eine Empfehlung im Wiki irgendwo, ist das in irgendwelchen Presets, hat es Vorteile gegenüber railway=subway_entrance?). Weiterhin könnte man evtl. noch überlegen, ob ein U-Bahn-Zugang überhaupt zu railway oder station gehört, oder es vielleicht sinnvoller wäre, das unter entrance zu erfassen, aber andererseits ist das so wie es ist einigermaßen etabliert und integriert, sollte man also eher nicht ändern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schon wieder: entrance nodes, housenumber und POIs
Am 12.03.2012 11:06, schrieb Ronnie Soak: Mir schon bekannte Nachteile: - Datensatz der inneren POIs ist nicht vollstaendig, weil Adresse fehlt - keine formale Zuordnung von entrance und POI - uneinheitliches Tagging, weil POI einmal extra, einmal direkt am entrance node (- rendering noch unschoen bei Hausnummern/POI am entrance) GIbt es Verbesserungsvorschlaege mit weniger Nachteilen? Lieber Adresse redundant an alle POIs (+entrance?)? Eine Relation um POIs und entrance? I.d.R. verfahre ich so wie Du, hänge die Adressen also an die entrance-nodes. Im Falle mehrerer POIs pro Adresse tagge ich die Adresse redundant an alle POIs und vermeide eine Relation. Das hat Vorteile, wenn z.B. einer der POIs umzieht: Wird vergessen, den alten POI in der DB zu entfernen, taucht schon bei einer Suche in vielen Systemen die Adressinfo mit auf und es lässt sich durch den Nutzer, sowie durch einen anderen Mapper schneller entscheiden, welches der richtige POI ist. Machst Du z.B. kein Bereichsausschnitt, sondern fragst Daten über die XAPI an, mit Filter (name = Zahnarztpraxis Dr. Bohr) erhältst Du ausschließlich POIs, nicht umliegende Gebäude. Für Dich beim Mappen ist die Adresse ja nur deshalb redundant, weil Du alles siehst, also die Daten ungefiltert vorliegen hast. Eine Relation wäre sauberer, wenn es Dir auf Redundanzvermeidung ankommt - das macht aber imho nur dann Sinn, wenn die Tools diese vermiedene Redundanz Dir als Mensch wieder aufblähen können, sprich die Relation effektiv auswerten. Ansonsten freut man sich lediglich, dass man als Mapper minimal komplex gemappt hat und allen Anwendern die damit nicht zurecht kommen, vorhalten kann, die Information sei klar da ;-) Im übrigen wäre es anhand identischer Adressen auf mehreren Objekten einfach, die Daten zu transformieren, sollte sich das Projekt später auf eine Relation einigen und diese in den Tools auswerten können. Grüße, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schon wieder: entrance nodes, housenumber und POIs
Hallo, Am Montag, 12. März 2012 13:00:35 schrieb Christian Müller: Am 12.03.2012 11:06, schrieb Ronnie Soak: Mir schon bekannte Nachteile: - Datensatz der inneren POIs ist nicht vollstaendig, weil Adresse fehlt - keine formale Zuordnung von entrance und POI - uneinheitliches Tagging, weil POI einmal extra, einmal direkt am entrance node (- rendering noch unschoen bei Hausnummern/POI am entrance) GIbt es Verbesserungsvorschlaege mit weniger Nachteilen? Lieber Adresse redundant an alle POIs (+entrance?)? Eine Relation um POIs und entrance? I.d.R. verfahre ich so wie Du, hänge die Adressen also an die entrance-nodes. Im Falle mehrerer POIs pro Adresse tagge ich die Adresse redundant an alle POIs und vermeide eine Relation. Das hat Vorteile, wenn z.B. einer der POIs umzieht: Wird vergessen, den alten POI in der DB zu entfernen, taucht schon bei einer Suche in vielen Systemen die Adressinfo mit auf und es lässt sich durch den Nutzer, sowie durch einen anderen Mapper schneller entscheiden, welches der richtige POI ist. Machst Du z.B. kein Bereichsausschnitt, sondern fragst Daten über die XAPI an, mit Filter (name = Zahnarztpraxis Dr. Bohr) erhältst Du ausschließlich POIs, nicht umliegende Gebäude. Für Dich beim Mappen ist die Adresse ja nur deshalb redundant, weil Du alles siehst, also die Daten ungefiltert vorliegen hast. Eine Relation wäre sauberer, wenn es Dir auf Redundanzvermeidung ankommt - das macht aber imho nur dann Sinn, wenn die Tools diese vermiedene Redundanz Dir als Mensch wieder aufblähen können, sprich die Relation effektiv auswerten. Ansonsten freut man sich lediglich, dass man als Mapper minimal komplex gemappt hat und allen Anwendern die damit nicht zurecht kommen, vorhalten kann, die Information sei klar da ;-) Im übrigen wäre es anhand identischer Adressen auf mehreren Objekten einfach, die Daten zu transformieren, sollte sich das Projekt später auf eine Relation einigen und diese in den Tools auswerten können. +1 Für denjenigen, der das lieber per Relation lösen möchte, 3 Sites, jedesmal das Haus, ein entrance und die zugehörigen POIs. Im vorliegenden Fall halte ich die Lösung ohne Relationen auch für besser. Spätestens bei 50+ POIs würde ich aber vermutlich zur Relation greifen (Dubai Tower oder so :-) ) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schon wieder: entrance nodes, housenumber und POIs
Am 12.03.2012 15:13, schrieb Wolfgang: Im vorliegenden Fall halte ich die Lösung ohne Relationen auch für besser. Spätestens bei 50+ POIs würde ich aber vermutlich zur Relation greifen (Dubai Tower oder so :-) ) Evtl. dann in die diversen indoor mapping proposals eintauchen und wenigstens level=* verwenden, um die Etagen voneinander abzugrenzen. 50+ POIs auf den Grundriß eines Towers projiziert, macht sicher keinem Mapper Spaß.. Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotomapping mit Garmin 62s
Hi ! ich wollte das ausprobieren. 1. Auf der Karte Karte einrichten Datenfelder 1(groß) gefunden !! und Datenfelder ändern Uhrzeit aber den Eintrag finde ich nicht - kannst Du mir ein Bild zukommen lassen oder ein Bild wo das mal abgebildet Gruß Jan :-) Wenn man in der Kartenansicht aber andere Datenfelder sehen möchte und weil ein Synchonisierungsfoto pro Session genügt: 2. Reisecomputer - dieselbe Prozedur. Wenn die kleine Uhrzeit oben groß genug ist, kann man das große Datenfeld auch für einen anderen Inhalt nutzen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] QLandkarteGT und Höheninfos
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin! Ich versuche schon seit längerem, eine ordentliche Höhenprofilkarte aus QLandkarteGT zu bekommen. Strecke ist: VON: N46° 27.965 E015° 46.084 NACH: N45° 48.988 E015° 50.322 Ich nehme die OpenCycleMap, trage beide Punkte ein, erzeuge eine Route zwischen den beiden Punkten und lasse diese als Fahrradtour unter vermeide Autobahn und vermeide Mautstrassen vom OpenRouteService berechnen. Es kommt eine 91km lange Route mit einer Zeit von 5:49:45 bei heraus. (die letzten Tage sponn der ORS etwas, aber gerade funktioniert er). Nun das Problem: ich mache aus der Route ein Track mittels Track erzeugen und möchte alle 100m einen Trackpunkt setzen, die Höheninformationen kommen von www.geonames.org. Unter einer 1.2.3 auf debian stürtzt QLandkarteGT ab. Unter windows mit Version 1.3.2 gibt es einen Track, aber die Höhe schwankt ständig zwischen 0 und 4 meter - unschön für eine Fahrradtour. Ich hab auch schon versucht, alle 50,200,10 Meter einen Trackpunkt zu setzen. Aber es kommen keine guten Höhenangaben bei heraus. Wie bekomme ich eine gute Höhenprofilkarte? Danke. MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9eEEYACgkQmWhuE0qbFyONyQCfR6ro3ZzRjtkdNXgXOn0ZseIh N+YAoITATT5k66NoF0X+/9Se+OhzpcKv =sW/H -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schon wieder: entrance nodes, housenumber und POIs
Ich hab da mal eine Wikiseite mit dem bisherigen Konses (so gut ich das eben mitbekommen habe) erstellt. Als Tutorial mit den groessten Problemen, die man so beim Haeusermappen hat. Rechtschreibung und Umlaute folgen dann in Version 2 ;) Da koennt ihr ja mal drueberschauen und ggfs. ergaenzen oder im Talk Anmerkungen dranschreiben. http://wiki.openstreetmap.org/wiki/DE:Buildings Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] QLandkarteGT und Höheninfos
Hallo Lars, Am 12.03.2012 16:03, schrieb Lars Schimmer: Unter einer 1.2.3 auf debian stürtzt QLandkarteGT ab. Unter windows mit Version 1.3.2 gibt es einen Track, aber die Höhe schwankt ständig zwischen 0 und 4 meter - unschön für eine Fahrradtour. Ich habe öfters mal ähnliche Probleme, auch dann, wenn ich ein Overlay in einen Track umwandle. Manchmal klappt es, wenn ich QLGT beende und neu starte. Ich habe den Verdacht, dass es irgendwie mit der Größe bzw. Komplexität des Tracks und dem Zugriff auf die Höhendaten bei geonames.org zusammenhängt. Ich rate dazu, das Problem auf der QLandkarte-GT-Liste zu posten: gmane.comp.gis.qlandkartegt.user Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten und grünes Wahlprogramm in Baden-Württemberg?
Am 30.04.11 schrieb Thomas Reincke: Am 29.03.2011 14:02, schrieb Sven Geggus: --schnipp-- Gemeinfreistellung von Datenbeständen des Landes Ich habe eben mal nachgeschaut, was daraus geworden ist und bin angenehm überrascht. heise schreibt heute, dass es voran geht und Daten unter http://opendata.service-bw.de/ zugänglich sind. Prototyp des Open Data Portals Baden-Württemberg vorgestellt Der Prototyp stellt exemplarisch Datensätze in einem von Maschinen lesbaren und interpretierbaren Format zur Verfügung... http://www.baden-wuerttemberg.de/de/Meldungen/273500.html?referer=88529 Gruß, Fabian.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotomapping mit Garmin 62s
Jan Tappenbeck schrieb: ich wollte das ausprobieren. 1. Auf der Karte Karte einrichten Datenfelder 1(groß) gefunden !! und Datenfelder ändern Uhrzeit aber den Eintrag finde ich nicht - kannst Du mir ein Bild zukommen lassen oder ein Bild wo das mal abgebildet Handbuch http://support.garmin.com/support/manuals/manuals.htm?partNo=010-00868-01language=decountry=DE Seite 29 hth ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tag-Differenzierung und deren Folgen
Hi ! ich habe heute eine Karte mit Maperitive von der Lübecker Altstadt gerendert und hätte fast das K bekommen. Allgemein gibt es für Gebäude das Tag building=yes und dann ggf. building:type=. Wenn das nun auch richtig gelesen habe im Wiki sollte sich das auf building=[den jeweiligen Typ] bzw. building=residental ändern mit der Zeit. Die Folgen davon habe ich selber erlebt. Es fehlten eine Vielzahl von Gebäuden und dann ging die Suche los. Sicherlich kann man das alles Konfigurieren und wir taggen nicht für die Render aber dieser Weg ist in meinen Augen ein Irrweg. Der alte Weg ist der bessere. Wer will kann mal eben eine Karte mit building=yes rendern und ist auch gewiss alles erwischt zu haben - wer mehr will kann auf die Subtags als Unterscheidungsmerkmal zurückgreifen. Wenn ich das also im Wiki richtig gelesen habe, dann sollte wirklich noch einmal darüber nachgedacht werden ob das so der richtige Weg ist. Letztendlich hat nur eines geholfen - alles markiert und dann daraus building = yes gemacht ! Fertig. Das Ergebnis ist auf der Traumpfade 2012 (25.3.2012) in Lübeck zu sehen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag-Differenzierung und deren Folgen
Hallo Jan. Schon immer gilt: alles, was building=* aber nicht building=no ist (und das wäre eigentlich blödsinn), kann als building=yes betrachtet werden, yes ist aber fallback für ja das ist ein building. Warum einen zusätzlichen Tag verwenden, wenn yes doch nur sagt ist irgendein Gebäude. Damit sollte auch Maperitive klarkommen können. Im Übrigen ist deine Behauptung, das wäre früher anders gewesen, falsch - jedenfalls seit Mitte 2010, als ich angefangen habe hier, ist das unverändert: building=irgendwas ist eine Spezialisierung von Building=yes, und wenn ich alle Gebäude haben will, nehme ich eben alles, was ein building-Tag hat - und schließe höchstens building=no aus (evtl. auch noch building=entrance, aber deshalb rutscht das ja nach aktuellem Stand aus dem building-tag wieder raus. Gruß Peter Am 12.03.2012 21:20, schrieb Jan Tappenbeck: Hi ! ich habe heute eine Karte mit Maperitive von der Lübecker Altstadt gerendert und hätte fast das K bekommen. Allgemein gibt es für Gebäude das Tag building=yes und dann ggf. building:type=. Wenn das nun auch richtig gelesen habe im Wiki sollte sich das auf building=[den jeweiligen Typ] bzw. building=residental ändern mit der Zeit. Die Folgen davon habe ich selber erlebt. Es fehlten eine Vielzahl von Gebäuden und dann ging die Suche los. Sicherlich kann man das alles Konfigurieren und wir taggen nicht für die Render aber dieser Weg ist in meinen Augen ein Irrweg. Der alte Weg ist der bessere. Wer will kann mal eben eine Karte mit building=yes rendern und ist auch gewiss alles erwischt zu haben - wer mehr will kann auf die Subtags als Unterscheidungsmerkmal zurückgreifen. Wenn ich das also im Wiki richtig gelesen habe, dann sollte wirklich noch einmal darüber nachgedacht werden ob das so der richtige Weg ist. Letztendlich hat nur eines geholfen - alles markiert und dann daraus building = yes gemacht ! Fertig. Das Ergebnis ist auf der Traumpfade 2012 (25.3.2012) in Lübeck zu sehen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Genauigkeit von buildings
Hallo! Inzwischen sind ja an vielen Orten die buildings eingezeichnet, woher diese Daten auch immer stammen mögen und wie sie auch generiert wurden. Diese Daten sind übrigens im Detail oft fehlerhaft. Natürlich gibt es in den Bereichen auch einzelne Lücken. Haltet ihr es für sinnvoll, Häuser in solchen Lücken nach Abschätzung frei Hand einzutragen? Auch wenn ich keine Luftbilder oder sonstige Planungsunterlagen habe? Meistens kann man eine Gebäude auch nicht abgehen und man ist sowieso an den Grenzen der Genauigkeit vieler GPS-Logger. Die Genauigkeit ist hier also sicherlich bescheiden. Besser eine ungenaues Haus als gar keins oder dann besser weglassen? -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von buildings
Am 12.03.2012 21:37, schrieb Wolfgang Wienke: Hallo! Inzwischen sind ja an vielen Orten die buildings eingezeichnet, woher diese Daten auch immer stammen mögen und wie sie auch generiert wurden. Diese Daten sind übrigens im Detail oft fehlerhaft. Natürlich gibt es in den Bereichen auch einzelne Lücken. Haltet ihr es für sinnvoll, Häuser in solchen Lücken nach Abschätzung frei Hand einzutragen? Auch wenn ich keine Luftbilder oder sonstige Planungsunterlagen habe? Meistens kann man eine Gebäude auch nicht abgehen und man ist sowieso an den Grenzen der Genauigkeit vieler GPS-Logger. Die Genauigkeit ist hier also sicherlich bescheiden. Besser eine ungenaues Haus als gar keins oder dann besser weglassen? IMHO, wenn keine Luftbilder zur Verfügung stehen, ist es besser nur einen node mit den Adressdaten zu taggen, anstatt einen ungenauen Grundriß zu zeichnen. Wenn auf einen Luftbild-genauen Grundriß durch vorhandene Daten geschlussfolgert werden kann, dann kann e.g. das Haus in der Lücke einer Häuserzeile auch dadurch rekonstruiert werden - für andere kann ein source=good_guess als Tag am näherungsweisen Linienzug des Hauses hilfreich sein. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von buildings
Moin! Ich lasse hier bei mir vor Ort die Gebäudeumrisse weg, wo ich noch keine Luftbilder habe (Neubaugebiet) und trage dort lediglich die Adressdaten als Node ein. Auf diese Weise weiss ich immer, wo ich noch Gebäudeumrisse nachtragen muss. Wenn die Gebäudeumrisse erstmal da sind, dann würde ich annehmen, dass es erledigt ist. Alternativ kannst Du natürlich auch eine FIXME-Bemerkung an das Gebäude dranhängen, damit es nicht in Vergessenheit gerät. Andre Am 12.03.2012 21:37, schrieb Wolfgang Wienke: Hallo! Inzwischen sind ja an vielen Orten die buildings eingezeichnet, woher diese Daten auch immer stammen mögen und wie sie auch generiert wurden. Diese Daten sind übrigens im Detail oft fehlerhaft. Natürlich gibt es in den Bereichen auch einzelne Lücken. Haltet ihr es für sinnvoll, Häuser in solchen Lücken nach Abschätzung frei Hand einzutragen? Auch wenn ich keine Luftbilder oder sonstige Planungsunterlagen habe? Meistens kann man eine Gebäude auch nicht abgehen und man ist sowieso an den Grenzen der Genauigkeit vieler GPS-Logger. Die Genauigkeit ist hier also sicherlich bescheiden. Besser eine ungenaues Haus als gar keins oder dann besser weglassen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geodaten und grünes Wahlprogramm in Baden-Württemberg?
Am 12.03.2012 17:50, schrieb Fabian Schmidt: heise schreibt heute, dass es voran geht und Daten unter http://opendata.service-bw.de/ zugänglich sind. wobei die Daten angeblich (gemäß Heise) CCbySA sind = wäre also gezielt zu klären ob wir die verwenden dürfen. Zumindest aber sollten wir sie zum Vergleich Objekt ist in OSM vs. OSM ist nicht in OSM heranziehen (vgl. Straßenauswertung) können. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von buildings
Hallo, Am Montag, 12. März 2012 21:37:53 schrieb Wolfgang Wienke: Hallo! Inzwischen sind ja an vielen Orten die buildings eingezeichnet, woher diese Daten auch immer stammen mögen und wie sie auch generiert wurden. Diese Daten sind übrigens im Detail oft fehlerhaft. Natürlich gibt es in den Bereichen auch einzelne Lücken. Haltet ihr es für sinnvoll, Häuser in solchen Lücken nach Abschätzung frei Hand einzutragen? Auch wenn ich keine Luftbilder oder sonstige Planungsunterlagen habe? Meistens kann man eine Gebäude auch nicht abgehen und man ist sowieso an den Grenzen der Genauigkeit vieler GPS-Logger. Die Genauigkeit ist hier also sicherlich bescheiden. Besser eine ungenaues Haus als gar keins oder dann besser weglassen? Mit dem GPS kannst du das Gebäude sowieso nicht aufnehmen, weil dicht an der Hauswand das Gerät nur noch spinnt. Das liegt einerseits an der Abdeckung, andererseites an der Reflektion der GPS-Signale an Hauswänden, Fensterflächen etc. Wenn die Abstände zu den Nachbargebäuden abschätzbar sind und der Grundriss einigermaßen einfach ist, könnte man es nach Schätzung eintragen. Ansonsten kann man auch von (mindestens 2) bekannten Punkten (Abzweig Straßenmitte, Sieldeckel, oder was immer man im Luftbild findet) die Entfernung zur Hausecke messen, bsp. mit Infrarot. Danach in JOSM über das Entferungsmodul die Strecken eintragen. Der Schnittpunkt ist die Hausecke. ps. wäre schön, wenn es da ein Plugin Vorwärtseinschnitt gäbe. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag-Differenzierung und deren Folgen
Hallo, Am Montag, 12. März 2012 21:20:34 schrieb Jan Tappenbeck: Hi ! ich habe heute eine Karte mit Maperitive von der Lübecker Altstadt gerendert und hätte fast das K bekommen. Allgemein gibt es für Gebäude das Tag building=yes und dann ggf. building:type=. Wenn das nun auch richtig gelesen habe im Wiki sollte sich das auf building=[den jeweiligen Typ] bzw. building=residental ändern mit der Zeit. Die Folgen davon habe ich selber erlebt. Es fehlten eine Vielzahl von Gebäuden und dann ging die Suche los. Sicherlich kann man das alles Konfigurieren und wir taggen nicht für die Render aber dieser Weg ist in meinen Augen ein Irrweg. Der alte Weg ist der bessere. Wer will kann mal eben eine Karte mit building=yes rendern und ist auch gewiss alles erwischt zu haben - wer mehr will kann auf die Subtags als Unterscheidungsmerkmal zurückgreifen. Wenn ich das also im Wiki richtig gelesen habe, dann sollte wirklich noch einmal darüber nachgedacht werden ob das so der richtige Weg ist. Dein Weg ist jedenfalls nicht der Richtige. Letztendlich hat nur eines geholfen - alles markiert und dann daraus building = yes gemacht ! Fertig. Das Ergebnis ist auf der Traumpfade 2012 (25.3.2012) in Lübeck zu sehen. Da du ja jetzt das Ergebnis hast, erwarte ich eigentlich, dass du diesen mindestens unsinnigen Edit wieder zurücksetzt. Sonst zerstörst du in rücksichtsloser Weise die Arbeit anderrer Mapper. Man kann so eine Änderung auch lokal machen. :1,$ s/building=.*\ /building=yes/ in sed oder vim geht auch in Windows. Was meinst du, was los gewesen wäre, wenn ich für die Fahrradkarte einfach mal eben alle Radwege gelöscht hätte? Lust hätte ich ja gehabt... ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag-Differenzierung und deren Folgen
Hallo, Am Montag, 12. März 2012 22:42:59 schrieb Wolfgang: Hallo, Am Montag, 12. März 2012 21:20:34 schrieb Jan Tappenbeck: Hi ! ich habe heute eine Karte mit Maperitive von der Lübecker Altstadt gerendert und hätte fast das K bekommen. Allgemein gibt es für Gebäude das Tag building=yes und dann ggf. building:type=. Wenn das nun auch richtig gelesen habe im Wiki sollte sich das auf building=[den jeweiligen Typ] bzw. building=residental ändern mit der Zeit. Die Folgen davon habe ich selber erlebt. Es fehlten eine Vielzahl von Gebäuden und dann ging die Suche los. Sicherlich kann man das alles Konfigurieren und wir taggen nicht für die Render aber dieser Weg ist in meinen Augen ein Irrweg. Der alte Weg ist der bessere. Wer will kann mal eben eine Karte mit building=yes rendern und ist auch gewiss alles erwischt zu haben - wer mehr will kann auf die Subtags als Unterscheidungsmerkmal zurückgreifen. Wenn ich das also im Wiki richtig gelesen habe, dann sollte wirklich noch einmal darüber nachgedacht werden ob das so der richtige Weg ist. Dein Weg ist jedenfalls nicht der Richtige. Letztendlich hat nur eines geholfen - alles markiert und dann daraus building = yes gemacht ! Fertig. Das Ergebnis ist auf der Traumpfade 2012 (25.3.2012) in Lübeck zu sehen. Da du ja jetzt das Ergebnis hast, erwarte ich eigentlich, dass du diesen mindestens unsinnigen Edit wieder zurücksetzt. Sonst zerstörst du in rücksichtsloser Weise die Arbeit anderrer Mapper. Man kann so eine Änderung auch lokal machen. :1,$ s/building=.*\ /building=yes/ in sed oder vim geht auch in Windows. Was meinst du, was los gewesen wäre, wenn ich für die Fahrradkarte einfach mal eben alle Radwege gelöscht hätte? Lust hätte ich ja gehabt... ;-) Gruß, Wolfgang ... und ich dachte schon, du hättest wirklich ;-) wir haben doch noch nicht den 1.4. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Weg / Fläche unregelmäßig gesperrt
Moin, wie kann ich ausdrücken, dass ein Weg oder eine Fläche unregelmäßig frei oder gesperrt ist? Beispiele sind - ein Weg der zur Krötenwanderzeit für Kfz gesperrt wird - ein Weg über ein Werftgelände, der bei Slip- oder Kranarbeiten gesperrt wird - eine Bundeswehrfläche, die außerhalb der Übungszeit öffentlich zugänglich ist - ein Platz, der mehrere Wochen im Jahr für Sonderveranstaltungen (Circus, Jahrmarkt, Ausstellung etc.) benutzt wird und sonst als Parkplatz dient. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weg / Fläche unregelmäßig gesperrt
Hi, dazu sind mir bis jetzt nur http://wiki.openstreetmap.org/wiki/Key:access#Access_time_restrictions untergekommen. Wenn Dir das nicht ausreicht, wirst Du etwas eigenes erfinden müssen. Grüße Christian Am 12.03.2012 23:53, schrieb Stephan Wolff: Moin, wie kann ich ausdrücken, dass ein Weg oder eine Fläche unregelmäßig frei oder gesperrt ist? Beispiele sind - ein Weg der zur Krötenwanderzeit für Kfz gesperrt wird - ein Weg über ein Werftgelände, der bei Slip- oder Kranarbeiten gesperrt wird - eine Bundeswehrfläche, die außerhalb der Übungszeit öffentlich zugänglich ist - ein Platz, der mehrere Wochen im Jahr für Sonderveranstaltungen (Circus, Jahrmarkt, Ausstellung etc.) benutzt wird und sonst als Parkplatz dient. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Remapping - was darf, was nicht
Moin! Am 11.03.2012 14:43, schrieb Simon Poole: Noch zu Klarstellung, der ganz einfache Fall: ein ursprünglich von einem Nicht-Zustimmer erstellter Weg wird gesplitet und irgend ein Tag wird dem gespliteten Objekt hinzugefügt, oder das Stück wird in eine Relation eingetragen, zu einem Objekt ohne relizensierbare Stützpunkte führt. Ein solcher Weg verschwindet (auch mit Anwendung der V0 Regel) aus der DB. Das ist eindeutig. Wurde das abgesplitete Objekt weiterbearbeitet, z.B. Geometrie verändert, ganz umgetaggt etc., so wird es zwar übernommen, aber man kann sich dann auch auf den Standpunkt stellen, dass so oder so wenig bis nichts mehr vom ursprünglichen Werk vorhanden ist. Jein. Der spätere Bearbeiter kannte sicherlich das physikalische Objekt. Aber es werden nebenbei alle weiteren Eigenschaften legalisiert, die noch vom Nicht-Zustimmer stammen können und den späteren Bearbeitern evtl. nicht bekannt sind. Die andere Weghälfte gilt als nicht ODBL konform, obwohl dort der gleiche Anteil des ursprünglichen Werks enthalten ist. Eine Spliterkennung könnte zu einem fairen Ergebnis führen. Beide bearbeiteten Wegteile könnten erhalten bleiben, die von Nicht-Zustimmern gesetzten Tags in beiden Teilen entfernt werden. Der umgekehrte Fall ist unangenehmer. Wenn ein Nicht-Zustimmer einen langen Weg splitet um z.B. eine Brücke einzufügen, gilt er danach als Urheber der Brücke und des gesamten nachfolgenden Wegteils. Den Weg wieder zu legalisieren macht viel Arbeit. Würde der Split erkannt und rückgängig gemacht, gäbe es bei der Lizenzumstellung nur einen minimalen Verlust. Die Brücke wäre mit wenig Aufwand neu einzutragen. Wenn der Weg Teil einer Relation ist, hat man noch mehr Arbeit, den geteilten Weg wieder ODBL konform zu machen. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] vergest das Posting
HI ! danke das wir darüber gesprochen hatte - irgendwie wohl etwas viel an dem Tag gewesen. Man kann so eine Änderung auch lokal machen. :1,$ s/building=.*\ /building=yes/ Das war natürlich nur ein lokaler edit ! Gruß Jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit von buildings
Am 12.03.2012 22:34, schrieb Wolfgang: Mit dem GPS kannst du das Gebäude sowieso nicht aufnehmen, weil dicht an der Hauswand das Gerät nur noch spinnt. Das liegt einerseits an der In der Vor-Luftbild-Ära habe ich mal ein Fabrikgebäufe mit GPS aufgenommen. Zwei mal rumgelaufen, das hat ganz gut gepasst. Ansonsten kann man auch von (mindestens 2) bekannten Punkten (Abzweig Straßenmitte, Sieldeckel, oder was immer man im Luftbild findet) die Entfernung zur Hausecke messen, bsp. mit Infrarot. Danach in JOSM über das Entferungsmodul die Strecken eintragen. Der Schnittpunkt ist die Hausecke. So mache ich das auch. Bei normalen rechteckigen Einfamilenhäusern die parallel zur Straße stehen reicht es meist, einen Punkt in der Gebäudemitte aufzunehmen, Abstand 10m, breite 8m, Tiefe ca. 5 m. Das Ergebnis ist besser als bei vielen Luftbildzeichenern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
