Re: [Talk-de] All in one Garmin Map - news
Christian Knorr schrieb: Es scheint allerdings einen bug (entweder in OL oder im Browser) zu geben, dass die Vektorobjekte, also die Kacheln, einfach verschwinden, wenn man sehr nah ranzoomt. Kann ich nicht bestätigen. Hier bleibt alles da wo es sein soll. Firefox 3.0.19 auf kubuntu 8.04 (hardy) Doch, die verschwinden schon (FF 3.6.2 / WinXP), aber nur unter bestimmten Umständen, nämlich dann, wenn die Stützpunkte sehr weit außerhalb des Bildschirms liegen, also wenn man z.B. in der Mitte einer langen Linie seht weit hineinzoomt. Ich habe hier http://dev.openstreetmap.de/navipowmmaps/TileMap.htm das selbe Problem mit der alten Ebene Tile Raster, hier sind die Linien aber auch wirklich sehr lang (S90 bis N90 und W180 bis E180). Deshalb habe ich das Raster auf eine andere OL-Funktion umgestellt. Da werden die Linien anscheinend nur im sichtbaren Bereich gezeichnet. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesperrte Autobahnauffahrten
Fips Schneider schrieb: access=no date_on=2010-05-01 date_off=2010-05-20 (...) Leider wird das Tag date_on und date_off vom Renderer nicht berücksichtigt... date_on und date_off ist auch ziemlich doof, da man nicht weiß, welches Attribut gemeint ist! Es könnte sich ja genauso auf maxspeed oder sonst was beziehen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig seit dem 20.0 4.10 turn-restrictions!
Falk Zscheile schrieb: Nicht jeder hat den Nerv überall noch einmal access-Tags zu setzen, wo sich dies bereits aus dem Barrieretypen ergibt. Das ist extrem umständlich und wir wollen es doch dem Mapper so einfach wie möglich machen und nicht den Programmierern :-) Nur wenn etwas vom Normalfall abweicht ist ein zusätzliches access-Tag sinnvoll. Warum unterscheiden wir sonst überhaupt verschiedene Barrieretypen? Gibt es denn irgendwo eine Übersicht, zu welchen barrier-Typ welche default access-Tags gehören? Das wäre m.E. die Voraussetzung dazu, dass das sinnvoll implementiert werden kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte drucken (Photopapier)
Detlev Reiners schrieb: Stephan Knauss schrieb: Wie muss man das denn umrechnen, bzw. wie funktionieren die Belichter für Fotos? Werden die Bilder gerastert? ich habe ein Bitmal als Quelle, also einen Punkt pro Farbe. Die Belichter erzeugen einen schwarzen Punkt. Bei einer Auflösung von 1.200 dpi kann der Belichter 1200 schwarze Punkte gleicher Größe auf einem Zoll ausgeben. (...) Ich weiß nicht, ob es in der ursprünglichen Frage um einen Offset-Druck gegangen ist. Es wird ja -wenn ich es richtig verstanden habe- nur ein einziges Exemplar benötigt, außerdem ist die Rede von Fotopapier. Ich denke mal, wenn so ein chemisches Verfahren gemeint ist, mit dem auch Digitalfotos ausbelichtet werden, dann können die Geräte max. 300 dpi. Diese müssen dann aber nicht mehr aufgerastert werden, da die Farbabstufung auf einen Pixel erfolgt. Ich würde es mit so ca. 150 dpi versuchen, das ist ein guter Kompromiss zwischen Schriftgröße und Qualität. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NaviPOWM 0.2.3 freigegeben
Hallo Julian Doru Julian Bugariu schrieb: Wenn Du mir sagst, was ich hier: http://sourceforge.net/apps/mediawiki/navipowm/index.php?title=NaviPOWM_Maps reinschreiben soll, dann mache ich das gerne. Ansonsten kannst ja versuchen Dich mit dem neuen tollen Design von SourceForge und der jetzt leider (von SF) erzwungenen Anmeldung fuer das Wiki rumzuschlagen... ;-) Ich habe nun alle Karteninfos auf http://wince.dentro.info/koord/osm/ zusammengestellt und pflege sie dort. Du kannst auf SF einen link darauf setzten und meine Sachen dort entfernen. Bis auf Nordamerika sind nun alle MAP-Files im Format 0.2.3! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Wanderkarte wird interaktiv
Hallo Nop, Nop schrieb: Routen planen Die Karte wurde mit einem Routenplaner integriert. (...) Über Euer Feedback zu Problemen, Erfolgen und Verbesserungen würde ich mich freuen. Das sieht schon recht gut aus! Ein snap-to-way wäre natürlich noch schöner, ist aber auf der Grundlage von den Rasterdaten schwer machbar. Was mir aufgefallen ist: 1) Verschieben eines Wegpunktes: Klickt man einen Punkt an und bewegt dann die Maus, so springt der Punkt etwas zur Seite, d.h. die Koordinaten von mouse_down und mouse_move sind unterschiedlich. 2) Rundweg Will man einen Rundweg anlegen (ausmessen), so kann man den Zielunkt nicht auf den Startpunkt legen, sondern muss ihn nachträglich dorthin schieben. Eine Schießen-Funktion wäre da sehr schön. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinformationen auf OSM-Karte
Hallo, Steffen Wolf schrieb: Tobias Wendorff schrieb: diese Website zeigt aktuelle Verkehrsinformationen auf einer OSM-Karte (laut Information auf der Website): http://www.freiefahrt.info/ Komisches Datenmaterial. Es ist eindeutig OSM, ich erkenn ein paar Knicks in den Strassen, aber wenn man so weit reinzoomt, dass die POIs erscheinen, dann ist's irgendwie veraltetes OSM. Da sin Fehler im Datenmaterial, die ich vor einem halben oder dreiviertel Jahr schon behoben habe... Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu asia.osm von der Geofabrik
Hallo Frederik, bei der Erstellung der Navi-POWM-KArten sind mir noch folgende Dinge an den Geofabrik-Extrakten aufgefallen: - Es gibt doppelte Bereiche in asia.osm und australia-ociania.osm. Indonesien etc. sind ein beiden Extrakten vorhanden. - Der westliche Teil von Ozeanien fehlt komplett (Cook Island, franz. Polynesien, etc) - Hawaii und Honolulu, etc fehlen im Nordamerika-Extrakt - Grönland ist komplett in Nordamerika enthalten. Ein kleiner Teil davon (bei Island) ist auch im Europa-File - Spitzbergen ist nirgendwo enthalten Also falls Du irgendwann mal zeit hast, könntest Du Dir das ansehen?!? Gruß, Stefan Stefan Dettenhofer (StefanDausR) schrieb: Frederik Ramm schrieb: Ich glaube, diese Daten fehlen - weil *ich* nicht wusste, wie ich ein Osmosis-Polygon konstruiere, das ueber die 180°-Grenze hinausgeht. Bist aber bislang der erste, der deswegen fragt ;-) Bye Frederik Hallo Frederik, Analoges gilt auch für australia-ociania.osm! Übrigens gibt es Überschneidungen von australia-ociania.osm mit asia.osm: Indonesien und die ganze Inselwelt sind in beiden Dateien vorhanden. Die betroffenen Gebiete siehst Du hier: http://wince.dentro.info/koord/osm/TileMap.htm Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der Geofabrik
Hallo, Frederik Ramm schrieb: Stefan Dettenhofer (StefanDausR) wrote: also ich stelle ja die Kartendaten für NaviPOWM zur Verfügung. Dazu werden die OSM-Daten in 1°x1°-Stücke zerlegt und in das passende Kartenformat (*.map) gewandelt. Waere es vielleicht moeglich, an der Stelle mit einem der Garmin-Karten-Erzeuger zusammenzuarbeiten? Ich stecke in dem Prozess nicht so ganz drin, aber auch die zerhacken den Planeten mehr oder weniger willenlos in handhabbare Brocken, und einige sogar taeglich... eventuell kann man da Zwischenprodukte austauschen? wer von den Kartenerzeugern zerteilt denn das planet-file und könnte mir ggf. Teil-OSM-Dateien zur Verfügung stellen? Zur Info: Ich erstelle schon seit einiger Zeit die Karten für NaviPOWM und biete die MAP-Files hier an: http://wince.dentro.info/koord/osm/index.html Die MAP-Files decken jeweils genau 1°x1° ab. Zur Erzeugung müssen die OSM-Dateien erst in handliche Stücke zerteilt werden. Momentan benutze ich die Kontinente von der Geofabrik und setzte diese in gewissen Abständen um. Die Umsetzung dauert aber relativ lange, so dass ich immer nur einzelne Teile der Welt erzeugen kann. In den Dateien der Geofabrik fehlen ein paar Landflächen und andere sind doppelt vorhanden. So wäre es natürlich am besten, das ganze planet-file zu benutzen, was aber an meinen Rechnerkapazitäten scheitert. Daher meine Frage (Idee vor Frederik): Zerteilt jemand sowieso in regelmäßigen Abständen die ganze Welt in handliche Stücke und kann mir diese OSM-Teile zur weiteren Verarbeitung zur Verfügung stellen? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen bei multiplen Gebäuden
Hallo, Bernd Wurst schrieb: Am Donnerstag, 5. November 2009 schrieb René Falk: Bernd Wurst schrieb: Frag mal Einheimische: Meistens haben alle Gebäude eine eigene Hausnummer. Grade bei älteren Adressen wurde das oft so gemacht. Bei uns hatte mal ein (mittlerweile abgerissenes) Backhäuschen eine eigene Hausnummer. Die Bushaltestelle hat noch immer eine. Das ist meiner Erfahrung nach eher eine regionale Kuriosität. Mag sein, aber es ist völlig normal, dass *Grundstücke* (Parzellen) eine Hausnummer erhalten. Stehen die Gebäude auf unterschiedlichen Parzellen (z.B. links und rechts eines Weges) dann haben die höchstwahrscheinlich unterschiedliche Nummern. Bei den -mir vorliegenden- amtlichen Katasterkarten gibt es alle Varianten: - ein Gebäude (eine Hausnummer) geht über mehrere Flurstücke - mehrere Gebäude (mit unterschiedlichen Hausnummern) auf einem Flurstück - ein Gebäude hat mehrere Hausnummern (Texte innerhalb des Polygons) - Mischformen daraus Eine eindeutige Zuordnung Hausnummer - Flurnummer ist so nicht möglich So weit ich weiß, sollen aber zukünftig die Gebäude mit mehreren (Haupt-)Eingängen (=Hausnummern) in einzelne Polygone aufgeteilt werden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der Geofabrik
Hallo Carten, Carsten Schwede schrieb: Jetzt kannst Du loslegen: Danke! Das Skript steht nun und die Umsetzung läuft: http://wince.dentro.info/koord/osm/navipowm/planet/ mal sehen, wie lange es dauert! Ist es noch richtig, dass beim Zerteilen der OSM-Dateien die Relationen entfernt werden? NaviPOWM nutzt sie m.W. momentan noch nicht, wollte es nur wissen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo ist der Nordpol?
Hallo, Steffen Wolf schrieb: Oder einfach nur Linien ueber die Datumsgrenze? Das geht m.W. per Definition nicht! Du musst bei lon=-180 bzw. lon=+180 einen neuen Weg anfangen bzw. die Fläche teilen! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der Geofabrik
Hallo, schlechte Nachrichten: 1) Die Umsetzung ist immer noch nicht fertig 2) Die vorgekachelten OSM-Daten sind für NaviPOWM nicht brauchbar! Leider kann ich die Daten doch nicht verwenden, da ways, die in 2 Kachel vorkommen nur in einer vorhanden sind. OSM2POWM benötigt dies Daten aber in beiden (oder mehreren) OSM-Files. Das Ergebnis sieht nun so aus, das in NaviPOWM an den Kachelgrenzen viele ways fehlen! Also muss ich mir die OSM-Kacheln doch selber erzeugen! Gruß, Stefan Stefan Dettenhofer (StefanDausR) schrieb: Carsten Schwede schrieb: Jetzt kannst Du loslegen: Danke! Das Skript steht nun und die Umsetzung läuft: http://wince.dentro.info/koord/osm/navipowm/planet/ mal sehen, wie lange es dauert! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der?Geofabrik
Hallo Sven, wo finde ich denn die fertigen OSM-Kacheln? Stefan Sven Geggus schrieb: Hast Du mal geschaut ob Du die tiles verwenden kannst die der mkgmap Tilesplitter erzeugt? http://www.mkgmap.org.uk/page/tile-splitter Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der?Geofabrik
Hallo Sven, Sven Geggus schrieb: Am besten nimmst Du dir einfach mal eines der Bundesländer vom geofabrik Server und steckst sie in den Tilesplitter rein: http://www.mkgmap.org.uk/page/tile-splitter Wenn Du damit was anfangen kannst (...) Also ich habe mal Bayern umgesetzt und festgestellt, dass mit den default Parametern die Grenzen der tiles vom Programm festgelegt werden. Ich benötige aber OSM-Kacheln mit festen Grenzen und Überlappung, also z.B. so: left=12.90 right=14.10 bottom=51.90 top=53.10 für E013N52 left=13.90 right=15.10 bottom=51.90 top=53.10 für E014N52 left=14.90 right=16.10 bottom=51.90 top=53.10 für E015N52 Mit welchen Parametern bzw. welcher areas.list werden denn die Tiles erzeugt? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der?Geofabrik
Hallo Nop, Nop schrieb: Man kann ihn dohc auch zwingen, eine vorhandene areas.list zu nutzen. Könnte man die nicht entsprechend präparieren? Das könnte schon gehen, aber dann kann ich es auch gleich -wie bisher- mit osmosis machen! Meine ursprüngliche Frage zielte ja darauf hinaus, bereits vorhandene Zwischenergebnisse nutzen zu können. Ich möchte nicht, dass jemand seine Skripte wegen mir ändern muss. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisverkehr für Relationen aufspalten
Hallo, Garry schrieb: Ich meine da war mal wa mit Brücke im Kreisverkehr der eine Aufspaltung nötig macht. Es könnte auch eine Geschwindigkeitsbeschränkung sein oder ein Spurerweiterung, oder was auch immer! Man könnte doch für diese Fälle eine Relation erstellen, die die Teile (ways) des Kreisverkehrs enthält. Dann hat man auch wieder alles beisammen. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wer zerteilt planet.osm? - war: Frage zu asia.osm von der Geofabrik
Hallo zusammen, da ich für NaviPOWM weder die OSM-Tiles von Computerteddy nutzen kann, Carsten Schwede schrieb: Leider kann ich die Daten doch nicht verwenden, da ways, die in 2 Kachel vorkommen nur in einer vorhanden sind. Das ist bei mir beabsichtigt um keine redundanten Wege zu haben. noch die von Sven mit dem Tilesplitter erzeugten gebrauchen kann, Sven Geggus schrieb: Mit welchen Parametern bzw. welcher areas.list werden denn die Tiles erzeugt? Dynamisch nach Vorgabe des Tilesplitters. Klappt also nicht. werde ich zukünftig so verfahren: - Die Kontinente der Geofabrik (und Cloudemade) bilden das Grundgerüst der Daten - Die fehlenden Gebiete ergänze durch Direktabfragen an die XAPI. - Kacheln, die in 2 Kontinenten liegen (und somit 2 unterschiedliche MAP-Files generieren) werde ich löschen und ebenfalls direkt aus der XAPI erzeugen. Das ist für mich immer noch einfacher, als das gesamte planet-file zu verarbeiten. Die Daten sind wie immer hier: http://wince.dentro.info/koord/osm/index.html Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] HighPrecision GPS receiver home build?
Hallo Flo, Florian Lohoff schrieb: Weisst du die RDS Gruppen und message types? Meist Du so etwas? http://www.qsl.net/dk7in/RASANT.html Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NaviPOWM 0.2.3 freigegeben - Planet komplett
Hallo zusammen, die MAP-Files für NaviPOWM (0.2.3) stehen nun für den ganzen Planeten zur Verfügung! Ich ergänze die Teile, die in den Geofabrik-Kontinenten fehlen mit Abfragen an die XAPI. Alle Daten und Infos unter: http://wince.dentro.info/koord/osm/ Falls noch etwas fehlt, bitte Info an mich! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fernsehbericht bei planet wissen
Hallo zusammen, gestern kam auf BR-alpha die Planet Wissen-Sendung Die Geheimnisse der Landkarten, in der auch OpenStreetMap vorgestellt wurde. Kai Behnke und Frederik Ramm wirken auch mit. http://www.planet-wissen.de/sendungen/2009/11/24_landkarten.jsp In den dritten Programmen wird die Sendung wiederholt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fernsehbericht bei planet wissen
Hallo, ich habe zwar die Sendung aufgezeichnet, die Qualität ist aber nicht besonders gut. Stefan Tirkon schrieb: Leider war gemäß meinem http://tvbrowser.org/de/ueber-mainmenu-16.html die letzte Wiederholung schon zum Zweitpunkt des Postings im Gange. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM als Abmahnverein
Hallo, eigentlich sollte man darüber lachen, auf der anderen Seite ist es auch traurig: Frederik Ramm schrieb: Das ist leider ein Problem, das hier bei uns zu grassieren scheint. Im Wiki gibt es eine immer laenger werdende Liste von angeblichen Lizenzverletzern - zum Teil reichte es schon, dass eine auf einer Webseite korrekt vorhandene OSM-Nennung in der Druckansicht nicht sichtbar war, um in dieser Liste zu landen. Es gibt da ein paar Uebereifrige bei uns, die sich leider auch leicht mal im Ton vergreifen und der Gegenseite vorsaetzliches Handeln unterstellen. http://wiki.openstreetmap.org/wiki/License_violation Ich kannte die Seite nicht, musste nun aber feststellen, dass ich darin auch auftauche! Warum? Wahrscheinlich, weil ich auf der alten maxspeed-Karte nur einen Link zu openstreenmap.org gesetzt habe und nicht die volle Lizenz angegeben ist! Diese Karte ist (war) ausschließlich für uns Mapper interessant und die sollten wissen was man darf und was nicht, da muss ich nicht alles hinschreiben. Auf meiner Hauptseite http://wince.dentro.info/koord/osm/index.html steht die Lizenz übrigens korrekt da, genauso wie auf der Karte, von der man sich die NaviPOMW-Karten herunterladen kann. Ich finde es schon sehr aufschlussreich, dass ich deshalb nicht kontaktiert wurde, sonder direkt in der black-list auftauche... Da macht man sich dann schon so Gedanken, für was und für wen man die Freizeit opfert! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector jetzt weltweit und mit places-Ansicht
Hallo Frederik, tolle Sache! Ich hätte noch eine Frage: Frederik Ramm schrieb: Ausserdem gibt es einen ganz neuen places-Layer, der Ortschaften und ihre Größe anzeigt Bei den places wird ja die Einwohnerzahl angezeigt bzw. der Hinweis, dass sie fehlt. Wie soll bei Gemeinden (Märkten) verfahren werden, die aus mehreren Ortschaften bestehen? Die gesamte Einwohnerzahl an den Hauptort oder an jeden Teilort den entsprechenden Wert? Konkretes Beispiel meines Wohnortes: Der Markt Lappersdorf besteht aus 30 Gemeindeteilen und hat insgesamt 13525 Einwohner Der Gemeindeteil Lappersdorf hat aber nur 2585 Einwohner Der Gemeindeteil Hainsacker hat 2531 Einwohner ... usw ... Man bräuchte also eigentlich für den place Lappersdorf 2 Darstellungen, einmal den Markt und das andere Mal den Gemeindeteil Am elegantesten wäre das über eine Relation zu lösen oder wie ist das sonst realisiert? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] xapi läuft wieder! - anderes Zeitf ormat?
Ulf Lamping schrieb: Außerdem werden die lat/lon Werte jetzt mit allen verfügbaren Nullen am Ende geliefert, also nicht mehr 86.84 sondern 86.840 - was auch nicht unbedingt im Sinne des geringen Transfervolumens ist ;-) Führt jetzt bei einem XSLT Skript von mir dazu, das fast alle Nodes gegenüber frühereren Referenzpunkten ihren Platz geändert haben :-( Man darf auch nie Fließkommazahlen auf Gleichheit testen, sondern immer nur Integer-Werte! Also vorher Runden und dann auf Gleichheit testen! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector jetzt weltweit und mit places-Ansicht
Hallo Jochen, Jochen Topf schrieb: Ich würde so taggen, wie es für einen Menschen aussieht, nicht wie es irgendeine Gemeindeordnung sagt. D.h. wenn da eine Ansammlung von Häusern ist, dann bekommt die ein Tag, die das benennt, was da ist. Wenn also die Samtgemeinde Blunder-Frubel aus den Ortsteilen Blunder, Frubel und Grebel besteht, dann bekommen die Teile jeweils place=village und name=Blunder, =Frubel, =Grebel und das wars. Die Gesamtkonstruktion ist ja nur eine künstliche Konstruktion. Bei den Grenzen ist das anders. Die Gemeindegrenze ist ja so definiert, dass sie die Grenze von Blunder-Frubel ist und wird auch so benannt. Das ist mal meine unmaßgebliche und nicht sehr durchüberlegte Meinung. :-) also nochmal, weil ich Frederik anders verstanden habe: Die Gesamgemeinde Blunder-Frubel hat z.B. population=12000 Der Ortsteil Blunder bekommt place=village und name=Blunder und population=7000 Der Ortsteil Frubel bekommt place=village und name=Frubel und population=4800 Der Ortsteil Grebel bekommt place=hamlet und name=Grebel und population=200 In einem größeren Massstab sollte doch Blunder-Frubel erscheinen und in höherer Auflösung dann die Ortsteile Blunder, Frubel und Grebel. Also müsste doch für das Konstrukt Blunder-Frubel eine Extranode mit place=??? und name=Blunder-Frubel und population=12000 gesetzt werden, oder? Das ist doch genauso wie bei place=town und place=suburb Jetzt braucht man (solange bis es Gemeinde- und Gemarkungsgrenen gibt) eine Zuordung, dass Blunder zu Blunder-Frubel gehört. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
Hallo Marcus, Marcus Wolschon schrieb: Im mit den neuen TMC-Verkehrsmeldungen auch sinnvolle Navigations- Entscheidungen treffen zu können muss halt die Geschwindigkeit durch einen Stau vorhergesagt werden. Schliesslich ist es nicht immer Sinnvoll jeden kleinen Hänger zu umfahren. Die Geschwindigkeit 0 wäre eine ziemlich falsche Annahme und ich würde ungern raten, wo es kein Problem ist echte Messwerte zu sammeln. GoPal macht es so: für verschiedene Straßenklassen gibt es Durchschnittsgeschwindigkeiten. Für jeden TMC-Event gibt es eine Tabelle mit penalty-Werten, die auch editiert werden kann. Der penalty bewirkt, dass die Durchschnittsgeschwindigkeit in dem Abschnitt gesenkt wird und somit ggf. eine andere Route sinnvoller ist. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
Marcus Wolschon schrieb: Nur hat niemand den rohen Event-Code und s zur Hand wenn er im Auto sitzt. Außerdem kann ich Glücklich sein überhaupt mal 2 oder 3 Messwerte per email zu bekommen. nur bringen Dir die Messwerte nur dann etwas, wenn Du auch weißt, wie die Verkehrsbehinderung in TMC dargestellt wurde. Weil was nutzt es, wenn Du Die Meldung bekommst: ich bin zwischen A und B 30 min in Stau gestanden und TMC meldet stockender Verkehr. War es dann Stau oder stockender Verkehr. Nochmals zu GoPal: Dort wird übrigens -per Default- überhaupt nur für Stau und stockender Verkehr ein penalty vergeben und der Wert sieht eher nach Pi mal Daumen aus. Was ich sagen will: Einen exakten Reisezeitverlust kann man -so glaube ich- nicht berechnen. Für den Anfang reichen m.E. wirklich ganz grob geschätzte penalty-Werte, die man dann in der Praxis überprüfen und verbessern kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
Hallo Marcus, ich kenne die Alert-C und die einschlägigen TCM-Dokumente! Marcus Wolschon schrieb: Event-Codes: Die Eventcodes gibt es alle 2 mal. Einmal mit Stau-Laenge in Km und ein mal mit Verzögerung in einer Zeiteinheit. Einfach mal selbst in ISO14819-2:2003 nachsehen. Ich hab die PDFs im Wiki von Traveling Salesman unter TMC verlinkt. z.B. Code 106 stationary traffic for 10 km Code 113 stationary traffic for 10 km with average speed Q Es gibt aber auch z.B. den Code 101 stationary traffic und der wird nicht gerade selten verwendet, z.B. aktuell hier: TMC 1 12748 12747 101 1 25 19.12.09 11:10:00 A9 Nürnberg - München zwischen 56 Hilpoltstein und 55 Allersberg Stau. und da weißt Du eigentlich gar nichts! Du kannst hier nur annehmen, dass der ganze Abschnitt betroffen ist, musst die Länge ausrechnen und kannst dann dafür ein penalty anwenden. Doch dazu reicht auch ein Pi mal Daumen -Wert! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dev.openstreetmap.de down?
Hallo Georg, Georg Lutz schrieb: zumindest über http bekomme ich grad keine Connections. der Server selber läuft, aber der apache scheint gerade down zu sein! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit SPLITTER
Hallo, ich verschmelze immer einige Bundesländer der Geofabrik und mache mir daraus meine Garmin-Karten. Ist es da nicht einfacher, das germany-File zu nehmen und einen rechteckigen Teil auszuschneiden? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit SPLITTER
Hallo Jan, Jan Tappenbeck schrieb: Am 09.01.2010 18:31, schrieb Stefan Dettenhofer (StefanDausR): Hallo, ich verschmelze immer einige Bundesländer der Geofabrik und mache mir daraus meine Garmin-Karten. Ist es da nicht einfacher, das germany-File zu nehmen und einen rechteckigen Teil auszuschneiden? einfacher schon - aber der gesamte download schrägt mich immer ab !!! ich ziehe die daten fast täglich ! gruß jan .-) Ich bin gerade dabei, am dev-Server die NaviPOWM-Karten für germanyplus täglich erzeugen zu lassen, da fallen als Abfallprodukt auch OSM-Dateien in verschieden großen Rechtecken an. Welchen Koordinaten-Bereich brauchst du denn? Vielleicht habe ich was passendes. Ansonsten: Die OSM-Kacheln von Computerteddy ftp://ftp5.gwdg.de/pub/misc/openstreetmap/teddynetz.de/latest/osm/ kennst Du schon, oder? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit SPLITTER
Hallo Jan, Jan Tappenbeck schrieb: in der Regel Schleswig-Holstein und Hamburg und die andere eben Rheinland-Pfalz und Hessen. also ich könnte Dir täglich diese Ausschnitte in jeweils einer OSM-Datei (mit 0,1° Überlappung!) anbieten: N51-N57: E004-E009, E009-E012, E012-E017 N49-N51: E004-E009, E009-E012, E012-E017 N45-N49: E004-E009, E009-E012, E012-E017 Wenn Du (oder wer anders) einen dieser 9 Ausschnitte braucht, dann bitte melden, dann stelle ich die zum Download bereit. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService für Haiti online
Hallo, Alexander Zipf schrieb: Hallo eine neue OpenRouteService-Version für Haiti ist Online (Routing / Geocoder) unter; http://openls.geog.uni-heidelberg.de/osm-haiti/ Danke an Pascal, Joe und den Rest des Teams! Eine gute Sache! OSM Daten werden stündlich aktualisiert; danke Frederik Ich könnte auch aktuelle NaviPOWM-Maps generieren lassen, wenn Bedarf da ist. Was mein Ihr, würden die gebraucht werden? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService für Haiti online
Hallo Frederik, Frederik Ramm schrieb: Ob/inwiefern vor Ort NaviPOWM im Einsatz ist, weiss ich nicht; wenn das aber mit irgendeinem einfachen Commandline-Aufruf unter Linux geht, koennte ich das einfach in den Job mit einbauen. Wenn die Daten benötigt würden, ist es wahrscheinlich einfacher, wenn ich die Umsetzung direkt am devserver mache, denn da habe ich alle nötigen tools installiert. GermanyPlus läuft da schon täglich. Nebenbei: Hast Du das Nordamerica-Extrakt eingestellt? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService für Haiti online
Sven Geggus schrieb: Wenn Du mir ein haiti.osm.bz2 rüberkopierst kann ich das mal anwerfen. Kannst Du nicht die http://labs.geofabrik.de/haiti/latest.osm.bz2 mit in die /osm/geofabrik-extrakte/ am devserver kopieren? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] NaviPOWM-Karten für Haiti - war: O penRouteService für Haiti online
Hallo, die Daten von Haiti sind nun auch als NaviPOWM-Maps am devsever verfügbar: http://dev.openstreetmap.de/navipowmmaps/navipowm/ Man kann entweder die Einzelfiles direkt aus der Karte herunterladen oder alle zusammen in einer 7z-Datei. Ich lege noch einen cronjob an, so dass die Aktualisierung häufig erfolgt. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NaviPOWM-Karten für Haiti - war: Ope nRouteService für Haiti online
Hallo, Jonas Krückel schrieb: Ich lege noch einen cronjob an, so dass die Aktualisierung häufig erfolgt. Sehr cool, ich hab es zum Wiki hinzugefügt. Hast du eine genauere Angabe der Aktualisierungszeiten? Dann bitte noch hinzufügen. http://wiki.openstreetmap.org/wiki/WikiProject_Haiti#2010_Earthquake_Response der job läuft jetzt all 30 Minuten. Ich denke das reicht, oder? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NaviPOWM-Karten für Haiti - war: Ope nRouteService für Haiti online
Hallo, Stefan Dettenhofer (StefanDausR) schrieb: der job läuft jetzt all 30 Minuten. auf der Hauptseite http://dev.openstreetmap.de/navipowmmaps/ wird nun der Datenstand automatisch aktualisiert und ich habe auch Haiti eingebaut. Man kann sich die Daten auch über die Karte http://dev.openstreetmap.de/navipowmmaps/TileMap.htm herunterladen Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService für Haiti online
Hallo, Frederik Ramm schrieb: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Nebenbei: Hast Du das Nordamerica-Extrakt eingestellt? Ja, das gabs ja immer nur 1x die Woche, und ich dachte mir dann, wer das verarbeiten kann, der kann auch den kompletten Planeten verarbeiten. Hast Du das benutzt? Ich hatte (in größeren Zeitabständen) NaviPOWM-Karten daraus erstellt, aber nun habe ich ja alles auf den devserver gelegt, dann kann ich auch gleich das planet-file nehmen. Dann habe ich auch kein Problem mehr mit fehlenden Inseln etc. Ich kann es auch wieder einschalten, bloss zur taeglichen Berechnung nicht, dann haelt es den anderen Kram zu sehr auf. Falls ich doch Probleme kriege, melde ich mich wieder. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für NaviPOWM auf dem Dev-Server
Hallo zusammen, die aktuellen MAP-Files für NaviPOWM (0.2.3) stehen nun nur noch auf dem OSM-Dev-Server zur Verfügung! Alle Daten und Infos unter: http://dev.openstreetmap.de/navipowmmaps/ Die Karten werden dort automatisch generiert und die Aktualität dynamisch auf der o.g. Seite angezeigt. Ich kann die Karten nun häufiger erzeugen als bisher: GermanyPlus gibt es täglich! Wie oft soll ich die anderen Kontinente umsetzen? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM in 3sat nano
Hallo, Michael Rathai schrieb: In der gestrigen Folge von 3sat nano kam ein längerer Beitrag zu OSM: http://hstreaming.zdf.de/3sat/veryhigh/080819_vermessung_nano.mov oder http://wstreaming.zdf.de/3sat/veryhigh/080819_vermessung_nano.asx Der obige Beitrag wurde schon mehrmals wiederholt! Siehe hier: http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058992.html Der von Haiti ist neu. Danke! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karlsruhe Schema = volle Infos?
Hallo Sebastian, ich denke auch, dass auf kurz oder lang (fast) jede Straße zu einer Relation werden muss! Je mehr Attribute erfasst werden, in desto mehr kleine Weg-Abschnitte muss sie zerstückelt werden. Alleine das taggen von maxspeed generiert sehr viele Wegabschnitte. Die einzige Möglichkeit diese Abschnitte wieder zusammenzufassen ist eine Relation, die den Namen und/oder die ref der Straße enthält! Sebastian Hohmann schrieb: Wenn man sich jetzt noch auf eine Relation einigen könnte (und im Wiki dokumentieren), würde ich das in Zukunft auch so machen, denn diese Redundanz (am besten noch mit Stadt und PLZ) nervt doch ziemlich. Bei der PLZ ist es schon schwieriger! Es gibt etliche Straßen, die zu zwei (oder mehreren?) PLZ-Gebieten gehören. Gleiches gilt für die Stadt bzw. auch für den Straßennamen, wenn es sich nicht nur um innerstädtische Straßen handelt! Nehmen wir z.B. eine Kreisstraße, die durch mehrere Dörfer führt: Das einzige Attribut, das über die ganze Länge konstant ist, ist die ref, die man in die Relation packen kann! Es ändern sich sowohl der Straßenname als auch die PLZ und sonst so einiges. Natürlich könnte man jetzt mit mehreren Relationsebenen arbeiten, aber ich denke das wird für den Normaluser zu kompliziert! Daher mein Vorschlag: Man packt nur das / die Attribut(e) in die Straßenrelation, die auch auf der gesamten Länge konstant sind. Das sind sozusagen die Defaultwerte der beinhalteten Elemente. Alle anderen Attribute müssen an das Element selber! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistenz bei Netzwerken für Rad- u nd Wanderwege in Relationen
Sven Anders schrieb: Am Montag, 17. November 2008 09:03 schrieb Raphael Studer: On Mon, Nov 17, 2008 at 8:01 AM, Sven Anders [EMAIL PROTECTED] wrote: Am Sonntag, 16. November 2008 17:59 schrieb Brunner, Armin: Also statt gar nichts oder beispielsweise: rcn=yes rcn_ref=xxx Wäre nach meiner Ansicht korrekt: network=rcn ref=xxx Was haltet Ihr von dem Vorschlag? Was machst du wenn ein Weg gleichzeitig ein Regonaler Radweg und ein Nationaler Radweg ist? z.B. in Hamburg der Radweg Hamburg Bremen und die Radroute 10 liegen auf dem selben Webabschnitt. Dann kommt der Weg in beide Relationen. In die Radweg Relation(network=rcn) und in die Wanderrelation (network=rwn) Gut bei Relationen kann man das machen, ich tagge aber im Moment eher die Ways selber, und da geht das nicht. aber network= gehört nur an eine Relation und hat am way nichts zu suchen! Gleiches gilt auch für ref, wenn damit eine Wegbezeichnung gemeint ist und es mehrere davon gibt! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten
Tobias Wendorff schrieb: Jochen Topf schrieb: de:amtlicher_gemeindeschluessel=[AGS5] Wollt ihr das echt so nennen? Ich würde da etwas Internationaleres verwenden, z.B. communal_code oder communal_reference oder communal_key etc. Ich habe glaube ich schon mal community_index in einem Fachbuch gelesen. Warum nicht? Das ist doch ein guter Ansatz! de:AGS5 ist doch eindeutig! Man kann den Schlüssel auch jederzeit mit Hilfe der NUTS/LAU-Tabellen in die europäische Form umwandeln. Siehe auch meine Beiträge dazu weiter oben! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten
Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Warum nicht? Das ist doch ein guter Ansatz! de:AGS5 ist doch eindeutig! Man kann den Schlüssel auch jederzeit mit Hilfe der NUTS/LAU-Tabellen in die europäische Form umwandeln. Siehe auch meine Beiträge dazu weiter oben! Ganz einfach: Weil OSM nicht nur von Deutschen verwendet wird. Wenn irgendjemand aus dem Ausland irgendwann einen Router oder ein Tool schreibt, muss er wissen, dass wir in Deutschland de:amtlicher_gemeindeschluessel verwenden. Und wenn die ehemalige GKZ in 5 Jahren wieder in etwas Anderes, wie digitale Gemeindebezeichnung DGBz umbenannt werden würde, müsste die Datenbank wieder verändert werden - dies wäre zwar simpel, aber ... ich sehe jetzt das Problem nicht! Wir können doch froh sein, ein komplettes und vollständiges Datenmaterial zu bekommen! Wie ich schon geschrieben habe, kann man das ja -wenn mann will- jederzeit in das EU-weite Format umcodieren. Das kann per script laufen, also de:amtlicher_gemeindeschluessel eu:NUTS/LAU Von einem weltweit gültigen Schlüsselsystem weiß ich nichts. Also nehmen wir doch das was es schon gibt. Und wer weiß jetzt schon, was in 5 Jahren ist? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten
Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: ich sehe jetzt das Problem nicht! Wir können doch froh sein, ein komplettes und vollständiges Datenmaterial zu bekommen! Von komplett und vollständig möchte ich erst sprechen, wenn ich die Daten und den Umfang sichten konnte. hier http://tools.geofabrik.de/osmi/?view=kreisgrenzen kannst Du sie doch sichten... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport Kreisgrenzen von infasGEOdaten
Dominik Spies schrieb: Apropo Gemarkungen: Wie sind denn Gemeindegrenzen (und Gemarkungen - aber die müssen ja nicht immer übereinstimmen) eigtl. festgelegt? Sind das immer geordnete Mengen von Vermessungspunkten? Gibt es für jeden solchen Punkt Kennzeichen (Grenzstein)? Sind die in irgendwelchen offizielen Grenzurkunden oder so veröffentlicht? Als echte Vermessungsdaten, nicht als Übersichtskarte.. Oder sind diese Daten nur bei den Vermessungsämtern und nur gegen dicke Kohle zu haben..? Ich weiß nur, wie die in der DFK in Bayern definiert sind. Da sind es Attribute an der Flurstücksgrenze. Sie sind also parzellengenau erfasst! Die Linien der Flurstücksgrenzen wiederum sind (geradlinige) Verbindungen zwischen Grenzpunken. Das müssen aber nicht unbedingt Grenzsteine sein. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] API 0.6
Frederik Ramm schrieb: Wenn jemand in einem Forum mitliest, in dem das interessant sein könnte, gern auch dorthin übernehmen. habe es hier http://forum.pocketnavigation.de/thread.php?threadid=1123574 veröffentlicht! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern
Hallo Markus, Markus schrieb: Zu meiner Anfrage bei der Bayrischen Regierung gibt es nun eine Entscheidung: Bayern stellt als *Pilotprojekt mit OSM* die Luftbilder in 2-m-Auflösung für den gesamten Regierungsbezirk Oberpfalz (10.000 m²) zur Verfügung. Damit soll eine mögliche künftige Zusammenarbeit des Landesvermessungsamtes Bayern mit OSM geprüft werden. Bei Erfolg soll seitens der Bayr. Regierung geprüft werden, ob die Zusammenarbeit auch auf Bundesebene ausgeweitet werden kann. Die Nutzungswvereinbarung wird wahrscheinlich zum OSM-Wochenende vorliegen, die Daten sollen nächste Woche übermittelt werden. Ich werde berichten. Gruss, Markus toll, dass Du das geschafft hast! Die 2m-Auflösung reicht zumindest für Straßen und Wälder völlig aus! bei Gebäuden wird es schon knapp... Die Daten kann man sich auch schon mal online in Bayern-Viewer ansehen: http://www.geodaten.bayern.de/BayernViewer/index.cgi In welcher Form sollen den die Daten zur Verfügung gestellt werden? Meines Wissens sind das ja Orthofotos, die ins GK-System eingepasst sind. Zumindest nutze ich (u.a.) diese Daten selber in einem kommerziellen (selbstprogrammierten) System. Wenn die Daten zum abdigitalisieren freigegeben werden, dann wird man sie nicht ohne weiteres in JOSM hinterlegen können, oder? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM und OpenLayer
Hallo Markus, bei mir klappt es wunderbar! Vielleicht hast Du noch alte Daten im Cache? Gruß, Stefan Markus schrieb: Hilfe! - OL funktioniert nicht mehr...! Da hat endlich alles bestens funktioniert, Linien und Punkte wurden angezeigt, Texte und Fotos als Popup, und jetzt ist alles weg: http://www.lau-net.de/baerlocher/osm/Simmelsdorf.html http://www.gnu.franken.de/ke/trips/2008/20081123-signalstein.html Ich habe nichts geändert... Woran könnte das liegen? Wie kann ich das wieder gerade biegen? Gruss, Markus ___ 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] OSM Inspector - maxspeed
John07 schrieb: Danke, leider lädt das gerade sehr zäh, aber scheint am [EMAIL PROTECTED] Server zu liegen. Bitte an den Autor: Auch Mapnik als Layer auswählbar. Ansonsten, falls Geofabrik noch Platz und Rechenkapazität hat, könnten sie das ja vllt. einbauen und damit einen aktuelleren Service anbieten. Ich hoffe der ursprüngliche Autor ist dadurch dann nicht gekränkt. Hallo zusammen, die maxspeed-Karte wird gerade wieder neu gerechnet. Zoom 0-12 sind schon online. Ich habe dazu eine eigene Wiki-Seite angelegt: http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte Dort steht nun das Datum des Updates und eine Legende. Außerdem habe ich einige Werte ergänzt und Farben angepasst. Wenn jemand geeigneten WEBSpace zur Verfügung hat, lade ich gerne die Tiles auch dorthin hoch! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern
Hallo Martin, zumindest für die Stadt Regensburg gibt es hier http://www.statistik.regensburg.de/publikationen/amtliche_verzeichnisse.php u.A. ein Straßenverzeichnis, das man zur Kontrolle verwenden kann. Siehe auch hier: http://wiki.openstreetmap.org/wiki/Regensburg Martin Trautmann schrieb: Gäbe es aber vielleicht zumindest die Möglichkeit, ein entsprechendes Straßenverzeichnis zu bekommen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector - maxspeed
John07 schrieb: Stefan Dettenhofer (StefanDausR) schrieb: John07 schrieb: Danke, leider lädt das gerade sehr zäh, aber scheint am [EMAIL PROTECTED] Server zu liegen. Bitte an den Autor: Auch Mapnik als Layer auswählbar. Ansonsten, falls Geofabrik noch Platz und Rechenkapazität hat, könnten sie das ja vllt. einbauen und damit einen aktuelleren Service anbieten. Ich hoffe der ursprüngliche Autor ist dadurch dann nicht gekränkt. Hallo zusammen, die maxspeed-Karte wird gerade wieder neu gerechnet. Zoom 0-12 sind schon online. Ich habe dazu eine eigene Wiki-Seite angelegt: http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte Dort steht nun das Datum des Updates und eine Legende. Außerdem habe ich einige Werte ergänzt und Farben angepasst. Danke, habe auf der Diskussionsseite mal meine Wünsche ergänzt. Wenn jemand geeigneten WEBSpace zur Verfügung hat, lade ich gerne die Tiles auch dorthin hoch! Wie viel wird denn gebraucht? Ich bin sicher, dass sich hier jemand findet. Gruß Jonas Zoom 0-12 sind (aktuell) 158 MB in 60.633 Files und 300 Verzeichnissen Zoom 13 sind (aktuell) 263 MB in 179.196 Files und 274 Verzeichnissen Zoom 14 sind (bisher) 789 MB in 596.448 Files und 456 Verzeichnissen Der Speicherplatz ist nicht so das Problem, aber der Upload via FTP ist sehr zeitintensiv, da es sich um so viele Einzeldateien handelt. Vielleicht ist aber auch nur mein alter Rechner, den ich als WEB-Server benutze zu langsam. Ich bin gerade dabei, vor dem Transfer erst einmal alle leeren Kacheln (kleine PNG-Files) zu löschen, mal sehen, ob das was bringt. Falls Du eine Möglichkeit hast, können wir das gerne mal testen! Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern
Markus schrieb: Hallo Stefan, für die Stadt Regensburg gibt es ein Straßenverzeichnis kannst Du das bitte anfordern und dann eintragen: http://wiki.openstreetmap.org/wiki/Straßenverzeichnis#Bayern das man zur Kontrolle verwenden kann Ja, dazu hat Sven Anders ein super Tool gebaut. Gruss, Markus Ja, das momentan verfügbare SV ist ein mehrseitiges PDF-File, das man sich neben den Rechner legen darf. Eine Veröffentlichung ist nicht eingeschlossen. Ich werde aber mal sehen, ob ich offiziell eines bekomme (bzw. veröffentlichen darf) Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osm daten beschneiden
Christian Mayr schrieb: das geht mit osmosis und mit einem perl script http://wiki.openstreetmap.org/wiki/Osmosis leider finde ich kein beispiel für ein extrahieren mit einer bounding box hat da jemand einen beispielaufruf zur hand? gruesse Wenn es Dir nur um die beschnittenen OSM-Daten geht: Ich erzeuge regelmäßig 1°x1°-Kacheln, die ich dann in das MAP-Format für NaviPOWM umwandle. Ich könne auch die OSM-Rohdaten zum Download bereitstellen. Hinweis: Ich erzeuge nicht genau 1°x1° sondern etwas mehr, so dass eine kleine Überlappung besteht, da mir sonst im Grenzbereich Daten fehlen. Man sieht das z.B. auch daran, dass man nicht einfach Deutschland und Österreich zusammenkopieren kann. Da kann es Probleme (fehlende Daten) geben. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Inspector - maxspeed
Fabian Schmidt schrieb: Am 26.11.08 schrieb Stefan Dettenhofer (StefanDausR): Der Speicherplatz ist nicht so das Problem, aber der Upload via FTP ist sehr zeitintensiv, da es sich um so viele Einzeldateien handelt. Hilft denn sowas? tar cpf - dir | ssh [EMAIL PROTECTED] tar xpf - bzw. tar cpf - dir | ssh [EMAIL PROTECTED] ( cd targetdir tar xpf - ) Gruß, Fabian. Danke! Ich mache es momentan so ähnlich mit 7z-Files. Mein eigener Server läuft unter Windows. Die vielen Einzeldateien machen mich fertig: Ich lasse gerade alle leeren PNG-Files aus der Zoomstufe 14 mit einem BATCH-Befehl löschen: for /R .\14\ %%N IN (*.PNG) DO if %%~zN LSS 1300 del %%N das läuft nun schon seit 7 Stunden... Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Format umwandeln: GPX - DFK
Markus schrieb: Hallo! in meinem Bereich gibt es ein ziemliches Durcheinander der sich überlagernden Grenzen. Unsere Gemeindegrenze habe ich als GPX, und möchte sie gern von unserem örtlichen Vermesser prüfen und mit den Infas-Daten vergleichen lassen. Dort kann man aber nur DFK importieren. Wer kann mir das umwandeln? Gruss, Markus Ich habe einen Konverter geschrieben, der DFK lesen kann und dann z.B. nach DXF wandelt. In welchem System sind die DFK-Daten? Normalerweise sind die in GK-Koordinaten. Die müsste man auch noch nach WGS-84 konvertieren. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Firefox 3 und WMS
Mit welchen Abweichungen ist denn zu rechnen, wenn die Luftbilder (in GK) vom WMS-Server nach WGS-84 umgerechnet werden und dann vielleicht in JOSM noch nach Mercator? Wäre es da nicht sinnvoller, in JOSM eine GK-Projektion einzubauen? Diese ist lokal rechtwinkelig. Gruß, Stefan Frederik Ramm schrieb: Hallo, Chris66 wrote: Genau deswegen hatte ich ja den Vorschlag gemacht eines Zwischendings zwischen WGS84 und Mercator (lineare Skalierung in y-Richtung um Faktor 1.6/einstellbar ). Kommt nicht in Frage. Wir erfinden bei OSM schon genug Räder neu. Eine eigene Projektion braucht es nicht auch noch. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GK-Projektion
Hallo, in der Oberpfalz gilt EPSG:31468 Ich habe die Umrechnung GK_3(Zone 4)-WGS84 (also EPSG:31468 - EPSG:4326) mit den Sources von GEOTRANS gemacht. Man muss aber schon genau aufpassen, was man tut! GK-Koordinaten benutzen das Ellipsoid Bessel 1841 und als Datum Deutsches Hauptdreiecksnetz WGS-84 (EPSG:4326) benutzt das Ellipsoid WGS 84 und als Datum World Geodetic System 1984 Beim staatl. Vermessungsamt ist auch noch EPSG:4314 (DHDN) gebräuchlich, das benutzt das Ellipsoid Bessel 1841 und als Datum Deutsches Hauptdreiecksnetz EPSG:4326 und EPSG:4314 haben in Regensburg einen Offset von ca. 150m Zur prinzipiellen Umrechnung GK - WGS84 Du musst die transversalen Mercatorkoordinaten in geodätische umrechnen und dann einen Molodensky Shift ausführen, der den Ellipsoidübergang berechnet. Gruß, Stefan Dominik Spies schrieb: Hallo, ich hätte mal eine Frage zur GK-Projektion (wegen der LVA-Bayern Luftbilder). Würde man so eine Projektion in einen Editor einbauen, könnte man heweils nur einen Streifen anzeigen / bearbeiten, richtig? Laut http://www.gdi.bayern.de/home_data/Kopie%20von%20GDI-Web/Geowebdienste/geowebdienste.htm gibts die 2m DOPs in: EPSG:31464, 31468, 31494 über den WMS. Welche erhalten wir auf DVD? Wie sind überhaupt 31464 und 31494 definiert? Infos darüber habe ich nur insoweit gefunden, dass man sie nicht mehr benutzen sollte, da abgelehnt bzw. deprecated. 31468 wäre ganz normal GK4 (10.5°-13.5°) mit Bessel-Elipsoid. So, um jetzt ein WGS-84 Datum in ein x/y Wert auf den DOPs auszurechnen, müsste man erst in ein Bessel-Datum umrechnen und dann in GK4 projezieren, richtig? Für x/y - WGS-84 Datum einfach umgekehrt. Ich bin auf der Suche nach Formeln (incl. einer für nicht Mathematiker / Geographen verständliche) Erklärung, um sie in Programmcode umzusetzen. Gefunden habe ich bisher: http://www-ipf.bau-verm.uni-karlsruhe.de/trafo/trafo.pdf Die GK-Formel kapier ich wohl, Probleme bereitet mir der Eilpsoidübergang. Ein Elipsoid ist ja durch a,b, und f (Halbachsen + Abplattung) definiert.. Wie genau dazu jetzt die Formeln aus dem PDF bei 1.7 passen, bleibt mir noch verschlossen.. Kann mir da jemand helfen? Gruß, Dominik ___ 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] WGS-84 - GK; war: Firefox 3 und WMS
Hallo Frederik, wie ich schon an anderer Stelle mal geschrieben habe, benutze ich für die Transformation GK - WGS-84 die sources von GEOTRANS http://earth-info.nga.mil/GandG/geotrans/ Ich benutze diese unter Windows mit C/C++ und unter WinCE in C. Allerdings habe ich mit JAVA noch nichts gemacht. Es gibt auch ein online-Umrechnungstool, das dies GEOTRANS-Sources nutzt und in JavaSkript implementiert ist: http://www.orchids.de/florkart/skripte/GeoTrans.htm Wenn also Bedarf besteht, dann kann ich Dir die nötigen C-Sourcen zusammenstellen. Zur Genauigkeit der Umrechnung: - Höhe wird nicht berücksichtigt! - in Regensburg gelten ungefähr folgende Zusammenhänge: + im Rechtswert (GK) entsprechen 10 Meter 0,49'' (geogr.) + im Hochwert (GK) entsprechen 10 Meter 0,33'' (geogr.) - Umrechnungsbeispiele mit verschiedenen Systemen: Grundlage ist folgende GK-Koordinate: R=4507545.14 H=5431102.70 System E N mein Programm: 12g 06' 06,11'' 49g 01' 01,92'' www.IPF.uni.karlsruhe.de: 12g 06' 06,65'' 49g 01' 01,53'' www.orchids.de: 12g 06' 06,10'' 49g 01' 01,93'' MapBender (Intranet Stadt R): 12g 06' 06,25'' 49g 01' 01,86'' (GPS-Gerät: 12g 06' 05,8'' 49g 01' 02,1'') Fazit: Eine absolut genaue Umrechnung von GK nach WGS-84 ist m.E. nicht möglich! Es können sich -je nach verwendeter Formel- Abweichungen um einige Meter ergeben! Ich hatte auch geogr. Koordinaten und die GK-Koordinaten des staatl. Vermessungsamtes verglichen. Dort wurde aber kein Ellipsoidübergang berechnet (also geogr. Koordinaten mit Bessel-Ellipsoid!), daher waren die Ergebnisse viel genauer. Gruß, Stefan Frederik Ramm schrieb: Wenn mir irgendjemand eine simple Rechenvorschrift, in beliebiger Programmiersprache oder auch Pseudocode liefern kann, die Schritt fuer Schritt beschreibt, wie ich aus einer geographischen Laenge und Breite nach WGS84 einen Rechts- und Hochwert nach GKx bekomme, dann baue ich das sofort in JOSM ein. Aber bitte in dieser Anleitung keine Formulierungen wie und hier dann einfach den von-Neumann-Brennickmeyer-Algorithmus anwenden oder sowas ;-) nur Grundrechenarten, Trigonometrie und von mir aus LA. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
wenn man davon ausgeht, dass residential auch nur innerhalb geschlossener Ortschaften verwendet wird (so wie es sein sollte) und das überall 50 km/h impliziert, dann ist das ok. Man könnte dann noch bei living_street irgend etwas zwischen 5 und 10 km/h annehmen. Wobei diese Defaulttabellen dann in allen Anwendungen und Karten-Zeichenvorschriften gleichermaßen angewendet werden müssten. Das mit maxspeed wird aber besser! In meiner neuesten maxspeed-Karte habe ich übrigens extra Wien mit aufgenommen! Gruß, Stefan Wolfgang W. Wasserburger schrieb: wobei ich dies auf primary, secondary, tertiary und ggf. highway und Trunk beschränken würde. Bei residential gibt das eigentlich keinen Sinn. Im Moment kommt maxspeed allerdings reichlich selten vor ;-) lg Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
wenn physisch 2 Schilder da sind, ist die Sache klar! bei uns ist es aber manchmal so, dass ein Schild zweigeteilt (untereinander) ist: - neue Ort - der alte Ort durchgestrichen Gruß, Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: wie machst Du das eigentlich bei Ortschaften, die direkt ineinander übergehen? - Zwei Schilder knapp hintereinander - Zwei Ortsnamen angeben Du hast zwar nicht mich angesprochen, aber ich antworte mal: Ich persönlich mappe beide Schilder, da sie ja physisch existent sind. So kann man irgendwann auch mal eine Schildermastanalyse durchführen (der ADAC macht sowas ja gerne). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Ich bin eigentlich eher der Verfechter des expliziten taggen, d.h. einfach ein maxspeed an alle ways. Mir ist klar, dass es viele Gegenargumente dazu gibt, aber momentan ist das die eindeutigste Lösung. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
wie machst Du das eigentlich bei Ortschaften, die direkt ineinander übergehen? - Zwei Schilder knapp hintereinander - Zwei Ortsnamen angeben Ich habe bisher die zweite Variante gemacht, also Ort1/Ort2, wobei der Ort1 der ist, der (in Wegrichtung) neu anfängt und Ort2 der, der aufhört. Gruß, Stefan Alex Schulze schrieb: Ich jedenfalls tage immer die Ortseingangsschilder mit. Die jetzt ja auch schön in JOSM dargestellt sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Es kann schon sein, dass bei vollständiger maxspeed-Betaggung da etwas overhead erzeugt wird, aber es ist meines Erachtens trotzdem die einzige sinnvolle Möglichkeit. Alternativ müsste ja z.B. zusätzlich zur (rechtlichen) Ortsgrenze noch die beschilderte Ortsgrenze an Polygon erfasst werden, um z.B. die Fälle zu erfassen, bei denen einen BAB durch ein (rechtliches) Ortsgebiet geht. Desweiteren müsste dann einen Vorverarbeitung der OSM-Dateien erfolgen, die dann auch nichts anderes macht, als die maxspeed-Tags nach gewissen Regeln zu ergänzen. Dann kann man sie doch auch gleich direkt dran hängen. Ich gebe Dir recht, dass maxspeed vom Fortbewegungsmittel abhängen kann. Diesen Fall gibt es aber sowohl bei explizit ausgeschilderten Tempolimits als auch bei impliziten maxspeeds. Die maxspeed-tags müssen dazu erweitert werden, um das Fortbewegungsmittel definieren zu können (un die Richtungsabhängigkeit und die Geschwindigkeit pro Fahrspur, und ...) Gruß, Stefan Mario Salvini schrieb: das erinnert mich gerade an eine nicht ewig zurückliegende Diskussion ;) Vollständige maxspeed-Betaggung ist nicht nur sinnloser Overhead, sondern auch faktisch falsch, da nur explizit ausgeschilderte Begrenzungen für alle gelten, implizierte Maxspeeds aber vom Fortbewegungsmittel (vehicle_type) abhängig sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MaxSpeed-Erfassung - war: LKW-Routing (TV-Bericht)
Zur Erfassung (und Kontrolle) des maxspeed-Tags nutze ich NaviPOWM. Ich habe mir noch Buttons (mit koord465) erstellt, mit denen ich die Tags als Waypoints erfassen kann (s. hier): http://forum.pocketnavigation.de/thread.php?postid=2115770#post2115770 Diese kann ich in GPX wandeln und in JOSM einladen. Parallel kann ich auch noch loggen. Die Reaktion war aber ziemlich gering, so dass ich davon ausgehe, dass daran kein Bedarf besteht. Mit dem System habe ich zumindest in meiner Gegend die maxspeed-Tags erfasst. Die Karten für NaviPOWM stelle ich ja auch -genauso wie die maxspeed-Karte- bereit. Gruß, Stefan John07 schrieb: Florian Lohoff schrieb: On Tue, Dec 02, 2008 at 04:19:00PM +, Johann H. Addicks wrote: Will sagen: Unsere Straßen mögen zwar im Renderer oft schöner (runder) aussehen, aber die Datenbasis für's Routing ist bei Teleatlas und Co noch meilenweit vor uns. Es ist ja noch viel wilder - Das problem laesst sich ja schon schoen an maxspeeds sehen das dort nur wenig interesse ist das flaechendeckend zu taggen. Das waere ja typischerweise sogar schon fuer otto-normal-mapper interessant. Problem ist derzeit vermutlich hauptsaechlich das es keine schoene visualisierung gibt. http://wince.dentro.info/koord/osm/KosmosMap.htm kennst du, oder? Gut, kann man noch verbessern. Also hilf mit! http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte Bei den beschraenkungen die nur LKW interessieren wirds dann noch eine stufe heftiger - Wen interessiert schon ob die Brücke 3,60m oder 4,0m hoch ist - Das Auto passt immer durch. Und auch beschraenkungen der tonnage interessiert keinen Autofahrer solange man jetzt keinen Maybach sein eigen nennt (und Maybach Fahrer interessieren sich wohlmoeglich nicht fuer OSM). D.h. bei den maxspeeds gaebe es noch interesse - ist bloss schlecht gepflegt - und bei hoehe, breite oder gewicht interessiert es den normal-mapper nicht und es wird auch nicht visualisiert. Ich haette ja gerne noch einen view im OSM Inspektor fuer maxspeed und jegliche andere restrictions d.h. gewicht, breite, hoehe - Da die nicht so oft vorkommen koennte man die gemeinsam visualisieren. Würde ich mir auch wünschen. Ich würde aber nicht ganz so schwarz malen. Wenn es wirklich mal ein Navi gibt, dass mit OSM-Material LKW-Routen berechnet, dann hat das bestimmt auch OSB an Bord. Und damit würden sicher auch LKW-Fahrer Brückenhöhen etc. eintragen. Hab schon von einigen Leuten gehört, die auch Fehler an Teleatlas melden und sich dann ärgern, dass sie nicht ausgebessert werden. Bei OSM wäre das viel leichter und würde sicher ausgebessert werden. Wenn es eine einfache Lösung, wie OSB, auf normalen Geräten ohne Hack gibt, sehe ich sehr viel Potenzial für eine gute Datenpflege. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
ok, vielleicht findet sich ja mal ein guter Mittelweg. Zumindest bis alle geschlossenen Ortschaften eine Relation und ein Grenzpolygon haben, werde ich lieber ein paar mehr (evtl später überflüssige) maxspeed-tags anbringen: Wenn durch eine kleine geschlossene Ortschaft eine Durchgangsstraße (secondary, tertiary, ...) verläuft, dann setzte ich das maxspeed-tag innerhalb der Ortsschilder auf 50. Ich erlaube mir auch mal ein maxspeed=100 zu taggen, das nicht beschildert ist (default), damit klar ist, dass hier schon maxspeed erfasst ist. Man könnte natürlich auch ein maxspeed=default oder sonst was nehmen. Gruß, Stefan Mario Salvini schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Es kann schon sein, dass bei vollständiger maxspeed-Betaggung da etwas overhead erzeugt wird, aber es ist meines Erachtens trotzdem die einzige sinnvolle Möglichkeit. vollständige maxspeed-Betaggung würde heißen Jeder highway bekäme ein maxspeed=* maxspeed:hgv=* maxspeed:goods=* das is soviel Overhead dass es schon an Tagging-Wahnsinn grenzt ;) Alternativ müsste ja z.B. zusätzlich zur (rechtlichen) Ortsgrenze noch die beschilderte Ortsgrenze an Polygon erfasst werden, um z.B. die Fälle zu erfassen, bei denen einen BAB durch ein (rechtliches) Ortsgebiet geht. beschilderte Ortsgrenzen sind in den wenigstens Fällen lückenlos. Hier in meiner Gegend gibt es keine einzige Stadt wo an jedem die Stadt betreten/verlassenden Weg/STraße ein Ortsausgangsschild wäre. Eine Möglichkeit wäre: Alle Wegstücke markieren und mit in in die place-Relation (samt umschließendes Polygon und Stadtzentrum-Node) packen. Das Problem mit der Autobahn lässt sich aber noch viel einfach lösen, in dem man explizit in den Defaults festlegt, dass auf der Autobahn immer maxspeed=no gilt. (So wie es übrigens auch in den Default-Tabellen schon erfasst ist.) Desweiteren müsste dann einen Vorverarbeitung der OSM-Dateien erfolgen, die dann auch nichts anderes macht, als die maxspeed-Tags nach gewissen Regeln zu ergänzen. Dann kann man sie doch auch gleich direkt dran hängen. Wie wir schon festgestellt haben, gebraucht jedes Verkehrsmittel eigene Defaults. Dementsprechend ist auch die Vorarbeitung für jeden vehicle_type anders. Außerdem minimiert der Zwischenschritt das Fehlerpotenzial (menschen machen nunmal Fehler) bzw. minimiren den Aufwand der Pflege an den Stellen wo noch Fehler sind. Ich gebe Dir recht, dass maxspeed vom Fortbewegungsmittel abhängen kann. Diesen Fall gibt es aber sowohl bei explizit ausgeschilderten Tempolimits als auch bei impliziten maxspeeds. wenn da einfach nut ein rundes Schild (weißer Grund, roter rand) mit Zahl steht, dann gilt dass für alle Verkehrsteilnehmer. Klar kann man alles durch Zusatzschilder auf bestimmt Gruppen beschränken, aber der Großteil sind explizite Beschränkungen für alle. Die maxspeed-tags müssen dazu erweitert werden, um das Fortbewegungsmittel definieren zu können (un die Richtungsabhängigkeit und die Geschwindigkeit pro Fahrspur, und ...) und bis dahin macht eine vollständige maxspeed-Betaggung erst recht keinen Sinn, sondern erzeugt wie schon erwähnt nur falsche Daten. Gruß, Stefan Mario Salvini schrieb: das erinnert mich gerade an eine nicht ewig zurückliegende Diskussion ;) Vollständige maxspeed-Betaggung ist nicht nur sinnloser Overhead, sondern auch faktisch falsch, da nur explizit ausgeschilderte Begrenzungen für alle gelten, implizierte Maxspeeds aber vom Fortbewegungsmittel (vehicle_type) abhängig sind. ___ 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] Ortsgebiet
Warum sollte ich die extra kennzeichnen? Wenn sie überflüssig sind, dann bedeutet es doch, dass sie mit dem Defaultwert übereinstimmen und können dann maschinell bereinigt werden! Wenn das nicht möglich ist, dann taugt der Defaultwert auch nichts. Gruß, Stefan Marc Schütz schrieb: Dann markier bitte diese impliziten maxspeeds irgendwie, am besten maschinell auswertbar, so dass erkennbar ist, welche davon überflüssig sind. Wie wärs mit implicit_maxspeed=yes, oder gleich implicit_maxspeed=100 statt maxspeed=100? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Das meinst Du aber jetzt nicht ernst, so etwas hier vorzuschlagen, oder? Das PSF-Format ist nicht ganz triveal. Für POIs (GoPal 2.x bis 4.1) gibt es ja schon einen Konverter und entsprechende PSF-POIs. Gruß, Stefan André Reichelt schrieb: Sofern es nicht schon Konverter gibt, könnten villeicht mal ein paar Hacker versuchen, das Format zu entschlüsseln und den passenden Konverter zu entwickeln. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
was aber wiederum klar macht, dass solche Polygone nicht unbedingt als maxspeed-Default dienen können! Stefan Frederik Ramm schrieb: Hallo, Sascha Silbe wrote: Geschlossene Ortschaft nach StVO (die gelben Ortstafeln) und die Ausdehnung eines Ortes (- Adressen) sind nicht identisch. Genau, und built-up area ist einfach bebautes Gebiet - also was man typischerweise von einem Luftbild sofort einzeichnen kann. Der Begriff hat im Englischen nicht den scharf begrenzten Charakter von unserem geschlossene Ortschaft. Es ist also damit zu rechnen, dass jemand, der nicht aus Deutschland ist, eine Grenze, die mit built-up area getaggt ist, so veraendern wuerde, dass sie eben dem bebauten Gebiet entspricht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
Ja genau! Denn ein Ortsschild-Polygon ist nicht praktikabel. Es besteht dann auch immer die Verwechslungsgefahr mit der Ortsgernze. Eine Relation wäre für kleine Orte Ok, aber alle Starßen von Berlin in eine Relation zu packen, dürfte auch nicht benutzerfreundlich sein. Dann müssten pro Stadtbezirk Relationen aufgebaut werden, die dann wieder in einer Superrelation zusammengefasst werden... Also ein tag an alle ways innerhalb der Ortsschildgrenze ist für alle Anwendungen sinnvoll (auch für maxspeed!). Es ist ja auch zu beachten, dass jeder Weg am Ortsschild aufgeteilt werden muss! Gruß, Stefan Torsten Leistikow schrieb: Noch viel einfacher ist es, den Weg nicht in eine Relation zu packen, sondern die Information einfach an jeden betroffenen Weg per Tag anzuhaengen. Das ist auch leichter zu kontrollieren und es kann auch nicht so leicht kaputt gehen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen Aber Achtung, es gibt für Regensburg auch welche in sehr viel besserer Auflösung! Gruß, Stefan Tobias Wendorff schrieb: Ich bete nur, dass die Bilder nicht im Sommer aufgenommen wurden, da man sonst die Straßen und Wege vor lauter Vegetation nicht sieht. ___ 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] LKW-Routing (TV-Bericht)
Warum muss da gleich einen eigene Hardware mit? Eine gute Software würde doch schon reichen, oder? NaviPOWM ist ja schon einmal ein guter Ansatz! Gruß, Stefan Tobias Wendorff schrieb: Markus schrieb: Jedoch braucht man dazu erstmal Kunden. Gerät incl OSM-Karte 200 €: +1 Markus Ich würde eine Null hinten dran setzen. Für 200 EUR bekommst Du bei einer 1.000er Serie gerade mal ein geeignetes Touchscreen-DPL. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Ja die haben für die 0,2m-Auflösung den Maßstab begrenzt, da es noch Luftbilder in besserer Qualität gibt! Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann ich noch nicht mal die Vegetation erkennen :-) ___ 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] Luftbilder LVA Bayern - Vertrag unterschrieben
Nachtrag: hier http://stadtplan.regensburg.de/stadtportal.html kann man auch die Stadtgrundkarte mit allen Gebäuden dazu einblenden! Stefan Stefan Dettenhofer (StefanDausR) schrieb: Ja die haben für die 0,2m-Auflösung den Maßstab begrenzt, da es noch Luftbilder in besserer Qualität gibt! Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Du kannst Dir die Luftbilder 2007 für Regensburg doch z.B. hier http://stadtplan.regensburg.de/stadtplan.html ansehen! Stadtplan abwählen - Luftbilder (Orthofotos) - Bayern (2m Bodenauflösung) anwählen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschrieben
Die Qualität der 2m-Daten entspricht der hier http://www.geodaten.bayern.de/BayernViewer/index.cgi -Orthofotos (Es sind die selben Bilder, die ich auch für Regensburg habe) Stefan Hi Tobias, Komisch, ich bekomme da nur Bildchen in 1:10.000 und da kann ich noch nicht mal die Vegetation erkennen :-) Dann sollten wir auf jeden Fall sicherstellen, dass bei uns die Anleitung zur Nutzung der DOPs in JOSM und Potlatch eindeutig und nachvollziebar sind! Gruss, Markus -- http://wiki.openstreetmap.org/wiki/de:Luftbilder_aus_Bayern ___ 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] LKW-Routing (TV-Bericht)
Bei den Medion PNAs (Hersteller ist m.W. Mitac) ist das definitiv kein Problem! Du brauchst da nichts an der Firmware zu ändern. Er reicht die andere Software aufzuspielen und zu starten. Selbst die mitgelieferte Navi-Software ist so offen Programmiert, dass man da selbst Änderungen machen kann und darf! Man kann die Originalsoftware jederzeit wieder von DVD einspielen. Und Garantie/Gewährleistung ist innerhalb der ersten 2 Jahre überhaupt kein Problem! Gruß, Stefan Tobias Wendorff schrieb: André Reichelt schrieb: Tobias Wendorff schrieb: Für einen Gewerbetreibenden leider uninteressant, da mit solchen Eingriffen die Gewährleistung und Garantie verloren geht. Blödsinn! Ich habe ja an der Original-Software nichts geändert. Ich habe das Programm nur auf die Speicherkarte gepackt und starte es dann ganz normal über den Explorer. In den kommt man, wenn man beim hochfahren des Navis eine bestimmte Taste gedrückt hält. Blödsinn, aha. Die Garantie ist sowieso freiwillig. Wenn der Hersteller Spuren einer anderen Software auf dem Telefon sieht, kann er sofort von seiner Garantie zurücktreten, auch wenn er sie beim Kauf zugesichert hat . Die Gewährleistung ist aber verpflichtend, aber nach den ersten sechs Monaten muss der *Käufer* nachweisen, dass die Mängel am Gerät nicht durch die eingespielte Software entstanden sind. Solche Beweise werden von Seiten der Gerichte und Hersteller natürlich nur von Gutachtern anerkannt. Der PDA mit Auslieferung als Navigationssystem (und somit eine Beschränkung der Möglichkeiten) ist vergleichbar mit Brandings von Handys vieler Mobilfunkbetreiber. Durch Software-Eingriff wird die Funktion / das mögliche Potential beschränkt und/oder verändert. Ich würde abwägen: Wenn man wirklich nur eine Taste drücken muss, um das fremde Programm zu starten und keine Manipulation an der Firmware oder mitgelieferten Software durchführen muss, dann ist es sicherlich akzeptabel. Man kann das Gerät beim Einschicken ggf. einfach zurücksetzen. Sobald man jedoch Core-Programme umschreibt, austauscht oder gar die Firmware austauscht, fällt das Ganze unter Urheberrechtsverstoß, da Software geschützt ist. Heise hat vor einiger Zeit genau dazu einen Artikel geschrieben (irgendwo bei Heise-Mobile). Viel gravierender sehe ich allerdings die markenrechtliche Probleme; lies hierzu § 24 Abs. 2 MarkenG - bezüglich ähnlicher Eingriffe, nämlich dem Entfernen von SIM-Locks hat der BGH bereits geurteilt: Entfernung ohne Eingriff in die Software = Markenverletzung ___ 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] LKW-Routing (TV-Bericht)
Ich will nichts kompliziert machen, aber 1) gerade um der Lizenz gerecht zu werden, müssen die Daten frei verfügbar sein (oder zumindest müssen sie weitergegeben werden dürfen). 2) ein Vorteil von OSM ist ja gerade eine hohe Aktualität und da wäre es doch besser, die verfeinerten (kompilierten) OSM-Daten zum Download bereit zu stellen, als erst noch die Daten konvertieren zu müssen! Weißt Du wie bei Medion ein Kartenupdate funktioniert? Genau so, wie Du es beschrieben hast. Danach muss noch ein Lizenzschlüssel eingegeben werden. Du schreibst ja selbst von dem Problem, die Daten mit dem Gerät zu verkaufen! Gruß, Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Die OSM-Daten könnten dabei frei downloadbar sein. Ja, mach es dem Nutzer noch komplizierter. Navi unter'm Weinachtsbaum auspacken, ans Internet anschließen, große Datenmenge runterladen etc. Das ist was für Übernormalbenutzer, aber nicht für die Oma, die das Navi zur Orientierung braucht. Wo ist da ein Lizenzproblem? Wenn Du die OSM-Daten mitlieferst, sind sie ein Teil des verkauften Gerätes. Wenn Du sie natürlich nur zum Download anbietest, ist das was Anderes. ___ 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] Luftbilder LVA Bayern - Vertrag unterschrieben //?Vorgehensweise?
So wie es hier http://wiki.openstreetmap.org/index.php/Regensburg schon lange steht: Als Referenz für die Vollständigkeit der Daten (Straßen und Bezirke) können können Informationen des Statistikamts Regensburg verwendet werden. Kostenlose Verzeichnisse als PDF gibt es hier http://www.statistik.regensburg.de/publikationen/amtliche_verzeichnisse.php. Weitere geologische und geografische etc. Informationen können unter Regensburg Informationen und Zahlen http://www.statistik.regensburg.de/menue/informationen_u_zahlen.html entnommen werden. Alle diese Informationen dürfen für Openstreetmap frei verwendet werden. Die aktuellste und detaillierteste Karte gibt es von der Stadt http://stadtplan.regensburg.de/. Die Nutzungsbedingungen der Karte besagen, dass diese Karte nicht für OSM kopiert werden darf. Jedoch steht die Stadt Regensburg OSM sehr aufgeschlossen gegenüber. So lange die Vektordaten von OSM erhoben werden und nicht kopiert werden kann die Karte als Grundlage kostenfrei genutzt werden. Die selbe Aussage habe ich auch mündlich vom Vermessungsamt der Stadt Regensburg erhalten und sie von der Freigabe der Luftbilder unterrichtet. Stefan Tobias Wendorff schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Die Daten von Regensburg dürfen zu diesem Zwecke (Überprüfung) von hier http://stadtplan.regensburg.de/stadtportal.html benutzt werden. Es darf aber keine Grafik abgezeichnet werden. Zur *Überprüfung* bedeutet, dass vorher schon mal jemand die Straße benannt haben muss. Wenn wir in der Oberpfalz aber Geisterstraßen eintragen, dann müssen wir auch die Genehmigung haben, z.B. den Straßennamen aus der analogen Kartendatenbank zu entnehmen. ___ 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] Luftbilder LVA Bayern - Vertrag unterschrieben //?Vorgehensweise?
Die Daten von Regensburg dürfen zu diesem Zwecke (Überprüfung) von hier http://stadtplan.regensburg.de/stadtportal.html benutzt werden. Es darf aber keine Grafik abgezeichnet werden. Stefan Tobias Wendorff schrieb: Sven Geggus schrieb: Straßennamen können selbst durch Ortskundige ohne Spezialtechnik ergänzt werden. Oder mit einer freundlichen Freigabe von Stadtplänen etc. ___ 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] LKW-Routing (TV-Bericht)
Wieso? Man könnte doch die kommerziellen Daten strikt von den OSM-Daten trennen (2 unterschiedliche Dateien), die dann erst im Naviprogramm zusammengeführt werden. Die OSM-Daten könnten dabei frei downloadbar sein. Wo ist da ein Lizenzproblem? Stefan AFAIK ist eine solche Vermischung durch die aktuelle Lizenzpolitik von OSM nicht möglich. Stefan Dettenhofer (StefanDausR) schrieb: OSM-Daten könnten meines Erachtens im jetzigen Stadium höchstens eine verkaufsfördernde Zugabe sein, deren Wirkung aber zukünftig sicher nicht unterschätzt werden darf. Ich meine, wenn man spezielle Zusatzkarten (Karten aus Ländern, die bei kommerziellen Anbietern nur schlecht erfasst sind oder sehr teuer sind z.B. Wanderkarten) aus OSM gewinnt und diese als Ergänzung zu kommerziellen Karten genutzt werden können, dann wäre das schon eine tolle Sache. Gruß, Stefan Tobias Wendorff schrieb: Allerdings ist OSM natürlich noch lange nicht reif, diesen Markt zu decken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
OSM-Daten könnten meines Erachtens im jetzigen Stadium höchstens eine verkaufsfördernde Zugabe sein, deren Wirkung aber zukünftig sicher nicht unterschätzt werden darf. Ich meine, wenn man spezielle Zusatzkarten (Karten aus Ländern, die bei kommerziellen Anbietern nur schlecht erfasst sind oder sehr teuer sind z.B. Wanderkarten) aus OSM gewinnt und diese als Ergänzung zu kommerziellen Karten genutzt werden können, dann wäre das schon eine tolle Sache. Gruß, Stefan Tobias Wendorff schrieb: Allerdings ist OSM natürlich noch lange nicht reif, diesen Markt zu decken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachteil barometrischer Höhenmessung
Wenn es jemandem hilft: Ich habe ein Programm für WinCE geschrieben, mit dem man die Höhe und Position (und Geschwindigkeit, etc.) loggen und nach GPX konvertrieren kann. Das läuft auf meinem Medion wunderbar. Stefan Holger Issle schrieb: Du nimmst in Deinem Beispiel an, dass es schon einen Logger gibt, der zu den Trackpunkten automatisch Höhen aufzeichnet? Welche tun das nicht? ...wunder... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert werden weggelassen! Das hat auch einen ganz praktischen (historischen) Grund: Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst frühere Versionen von AutoCad konnte nicht vernünftig mit den ungekürzten Koordinaten arbeiten. Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den Rechtswert die Nummer des Meridianstreifens, auf den sich die Koordinaten beziehen! Hier ist noch eine Online-Umrechnung http://www.orchids.de/florkart/skripte/GeoTrans.htm Gruß, Stefan Marco Lechner schrieb: Hallo Markus, die von Dir angegebenen Koordinaten sind so keine Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind. Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte, da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung notwendig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Mit Geotrans (link s. unten) und den GK-Koordinaten (auf ganze Meter gerundet) erhalte ich: GK: R=4452306 H=5495775 WGS-84: 11.3387955°E 49.5968617°N Gruß, Stefan Marco Lechner schrieb: das ist mir schon klar - nur leider hat Markus nicht angegeben wo er sich denn ungefähr befindet = im Bereich 6° Ost: GK: 2452305.9 5495774.9 latlon/WGS84: 5d20'22.957E 49d35'48.46N im Bereich 9° Ost: GK: 3452305.9 5495774.9 latlon/WGS84: 8d20'21.382E 49d35'48.524N im Bereich 12° Ost: GK: 4452305.9 5495774.9 latlon/WGS84: 11d20'19.815E 49d35'48.628N jeweils mit proj gerechnet (wie im Wiki angegeben): $ cs2cs -E +init=epsg:31466 +to +init=epsg:4326 EOF 2452305.9 5495774.9 EOF für Meridianstreifen 3 bzw. 4 eben mit epsg:31467 bzw. epsg:31468 und einem Rechtswert (Input) von 3452305.9 bzw. 4452305.9 Marco P.S. Hoffentlich waren in den Ursprungskoordintaen Rechts- und Hochwert nicht vertauscht ;-) Stefan Dettenhofer (StefanDausR) schrieb: Das ist zwar im Prinzip richtig, aber in der Praxis werden oft gekürzte GK-Koordinaten verwendet, d.h. die erste Stelle in Rechts- und Hochwert werden weggelassen! Das hat auch einen ganz praktischen (historischen) Grund: Die Vermessungsämter arbeiten ja nur in ihrem Bereich und wissen daher, welchen Meridianstreifen sie benutzen und wie weit es zum Äquator ist. Die alten Rechnersysteme taten sich mit so großen Zahlen schwer, selbst frühere Versionen von AutoCad konnte nicht vernünftig mit den ungekürzten Koordinaten arbeiten. Man muss also vor den Hochwert (=Y) eine 5 schreiben und vo den Rechtswert die Nummer des Meridianstreifens, auf den sich die Koordinaten beziehen! Hier ist noch eine Online-Umrechnung http://www.orchids.de/florkart/skripte/GeoTrans.htm Gruß, Stefan Marco Lechner schrieb: Hallo Markus, die von Dir angegebenen Koordinaten sind so keine Gauß-Krüger-Koordinsten, da diese immer siebenstellig sind. Also entweder fehlt vorne was, was beim Rechtswert durchaus sein könnte, da Gauß-Krüger in Meridianstreifen aufgeteilt ist. Manchmal wird die erste Ordnungszahl weggelassen, die ist aber zur großräumigen Einordnung notwendig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kauß-Krüger WGS-84
Ich hab es zwar nicht getestet, aber hier: https://upd.geodatenzentrum.de/geodaten/gdz_rahmen.gdz_div?gdz_spr=deugdz_akt_zeile=3gdz_anz_zeile=6gdz_user_id=0 kannst Du auch Koordinaten-Dateien wandeln lassen. Stefan Tobias Wendorff schrieb: Oder Du findest jemanden, der cs2cs (etc.) auf seinem Linuxserver für alle laufen lässt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 3D-NMEA-Aufzeichnung - war: Nachte il barometrischer Höhenmessung
Hallo Markus, meine Tools habe ich hier http://wiki.openstreetmap.org/wiki/User:StefanDausR aufgeführt. Ich werde aber (bei Gelegenheit) noch eine genauere Beschreibung zu meinem Programm koord465 erstellen, die sich nur auf das loggen bezieht. Mein Programm ist über viele Parameter steuerbar, da ich es eigentlich zuerst speziell für GoPal entwickelt hatte um dort Koordinateneingaben zu ermöglichen. Es wurde immer erweitert und kann in Skins eingebaut werden. Die Tracking-Funktion ist mehr ein Abfall-Produkt. Gruß, Stefan Markus schrieb: Hallo Stefan, Ich habe ein Programm für WinCE geschrieben, mit dem man die Höhe und Position (und Geschwindigkeit, etc.) loggen und nach GPX konvertrieren kann. Das läuft auf meinem Medion wunderbar. Super! Damit können alle (Medion-) Navibesitzer bei OSM mitmachen. Kannst Du das Programm zum Download anbieten? Und im Wiki eine Beschreibung machen (deutsch und englisch)? Ich möchte die Beschreibung dann gern verlinken in http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo/neu Gruss, Markus ___ 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] 3D-NMEA-Aufzeichnung - war: Nachte il barometrischer Höhenmessung
Das ist schon richtig! Aber das Tracking mit koord geht auch ohne GoPal und man kann Höhe und Geschwindigkeit gleichzeitig aufzeichnen. Außerdem kann man bei der Konvertierung nach GPX noch eine Mindestanzahl von Sats bzw. einen max. HDOP angeben und das ganze läuft direkt auf dem PNA. Bei den GoPal GPX bekommst du auch pro Routenberechnung einen neue Datei. Aber viele Wege führen nach Rom. Gruß, Stefan Johann H. Addicks schrieb: Beschreibung zu meinem Programm koord465 erstellen, die sich nur auf das loggen bezieht. Die Tracking-Funktion ist mehr ein Abfall-Produkt. Naja, leider ist das Programm inzwischen für's Tracklogging überflüssig geworden bei den Medion-Navis. Nein, nicht weil GPS-Babel das TRK-Format selbst wandeln kann, sondern weil GoPAL jetzt selbst GPX-Dateien speichert. Nur leider jetzt ohne Angaben zu Fix/HDOP/VDOP... Oder kennt jemand einen Trick, wie man das zurückdreht? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D-NMEA-Aufzeichnung - war: Nachte il barometrischer Höhenmessung
Das geht genauso, wie es seit GoPal 2.x funktioniert hat: Das Verzeichnis \Storage Card\Tracks anlegen und schon werden dort -unabhängig von irgendwelchen anderen Einstellungen- *.trk-Dateien erzeugt, sobald GoPal läuft. Die TRK-Dateien sind aber wieder ohne Höhe! Also Du kannst dann entweder GPX und TRK parallel aufzeichnen und nachher zusammenführen, oder Du nutzt doch Koord und hast eine komplette Datei... Stefan Johann H. Addicks schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Oder kennt jemand einen Trick, wie man das zurückdreht? Bei den GoPal GPX bekommst du auch pro Routenberechnung einen neue Datei. Aber viele Wege führen nach Rom. Ja leider.. Deshalb fragte ich ja: Wie kann ich bei GoPal4.5 wieder TRK-Dateien aufzeichnen lassen? Wo ist besagter Weg nach Rom? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Ich denke, das Problem ist weniger die Rechenungenauigkeit, als die Verwendung verschiedener Algorithmen und unterschiedlicher Parametersätze. Einen schlechten Code erkennt man schon mal daran, dass die Rück-Umrechnung (GK-WGS84-GK) ungenaue Ergebnisse liefert. Hierbei solle es aber nur Abweichungen im cm-Bereich geben. Die verschiedenen Umrechnungsmethoden liefern aber m.W. lokal betrachtet einen absoluten Fehler im bereich von 1-3m. Der differentielle Fehler dürfte geringer sein Die Vermesser nutzen ja immer Referenzpunkte, auf die sie ihre Messung beziehen können. Die gemessenen Werte werden dann später erst in das vorhandene Punktraster eingerechnet und ausgeglichen. Miriam Tolke schrieb: Wolfgang W. Wasserburger [EMAIL PROTECTED] schrieb am Mi, 10.12.2008: Die Umrechnung beinhaltet jede Menge Funktionen (Winkelfunktionen und Wurzeln), die in Computern nicht exakt abgebildet werden und in verschiedenen Programmiersprachen unterschiedlich genau sind. Außerdem sind Iterationen drinnen. Je nach Abbruchbedingung gibt es so auch noch Abweichungen. Also ist nicht nur die Programmierung, sondern auch die Kodierung ein möglicher Grund für Fehler. Es ist sicher ein Unterschied die Konvertierung mal kurz in PHP oder Perl hinzurotzen oder guten Mathe-Libs sorgfältig in Java, C oder Fortran zu verwenden. Trotzdem, sollten nicht zumindest die vom Geodatenzentrum und vom USGS viel Sorgfalt verwendet haben und zumindest auf sechs Stellen deckungsgleich sein? Heutzutage wird doch auch mit GPS vermessen und durch Postprocessing Genauigkeiten im Millimeterbereich generiert. Und dann kommt es bei der Umrechnung zwischen den Systemen zu Ungenauigkeiten im Bereich von drei Metern (wenn ich mich nicht verrechnet habe)? Wie kommen die Vermessungsämter eigentlich auf ihre GK-Koordinaten? Passiert das schon im Empfänger? Ciao, Miriam ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84
Hallo Markus, ich hatte mal für Regensburg folgende Werte bestimmt: Im Rechtswert (GK) entsprechen 10 Meter 0,49'' (WGS-84) Im Hochwert (GK) entsprechen 10 Meter 0,33'' (WGS-84) Noch war zur Koordinatenverwirrung, da ich gerade mal wieder die DatRi-GRUBIS vor mir liegen habe, die den Datenaustausch der Vermessungsämter regelt: Feld 8: Rechtswert oder y-Wert Der jeweilige Rechtswert oder y-Wert wird in der Maßeinheit Zentimeter dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der Meridiankennziffer. Führende Nullen werden angegeben. Feld 9: Hochwert oder x-Wert Der jeweilige Hochwert oder x-Wert wird in der Maßeinheit Zentimeter dargestellt. Bei GK-Koordinaten erfolgt keine Angabe der 1000 km-Stelle. Führende Nullen werden angegeben. Also bei GK-Koordinaten sollte man immer vom Rechts- bzw. Hochwert sprechen, da die Vermesser X-Achse und Y-Achse anders sehen als die Normaluser! Markus schrieb: Hallo Miriam, das gleiche Ergebnis Ja, das hat mich auch irritiert. Damit ich eine Vorstellung der Differenzen bekomme, habe ich eine Tabelle gemacht, wieviel Nachkommastellen wie genau sind: http://wiki.openstreetmap.org/wiki/DE:Genauigkeit_von_Koordinaten (kann das bitte mal jemand prüfe?) Bei Deinen Beispielen beträgt die max. Abweichung Breite: 3,12m Länge: 4,35m*cos(Breite)=2,8m (wenn ich richtig gerechnet habe) Es würde also bei der dezimalen Koordinaten-Darstellung reichen, wenn man 5 Nachkommastellen angibt (der Rest gaukelt eine nicht vorhandene Genauigkeit vor). Und das gilt natürlich auch nur, wenn die ursprünglichen Messergebnisse vor der Umwandlung so genau waren. (in diesem Falle hat man mir 1 dm genannt) Gruss, Markus ___ 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] Durchgehende Kartengenerierung basteln (Windows)
Hallo Jan, ich mach das so ähnlich mit Kosmos (MaxSpeed-Karte) bzw. den NaviPOWM-Karten. Wo ist genau das Problem? Du kannst doch mit der call-Anweisung eine andere BAT-Datei aufrufen. Du musst nur aufpassen, dass Du immer im richtigen Arbeitsverzeichnis bist. Gruß, Stefan Jan Tappenbeck schrieb: Zunächst hatte ich die einzelnen Schritte in einzelnen Verzeichnissen abgelegt und das hat auch geklappt. Dann wolle ich alles in einem Batch ausführen (Faulheit) und da bin ich am aufrufen der unterschiedlichen Sub-Batchroutinen gescheitert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschriebe n - Bildqualität?
Hallo, ich habe mir gerade die Bilder von meinem Haus in JOSM (mit WMS-Plugin) angesehen und mit den Original 2m-Luftbildern des LVA verglichen. z.B. hier http://stadtplan.regensburg.de/ Der Qualitätsunterschied ist ja sehr groß! Sind die Quelldaten nicht besser oder passiert der Qualitätsverlust bein Transformieren oder stelle ich mich nur zu dumm an? Einzelne Häuser sind eigentlich nicht erkennbar. Gruß, Stefan Sven Geggus schrieb: Markus liste12a4...@gmx.de wrote: Sven Geggus wird den WMS-Server aufsetzen und die Daten ggf. in unser Format transformieren. Falls es der ein oder andere hier überhaupt nicht abwarten kann die Tirschenreuther Teichpfanne abzuzeichnen ;) Ab sofort läuft der WMS-Server! Im josm WMS Plugin einfach folgende URL eintragen (das ? ist wichtig): http://oberpfalz.geofabrik.de/wms4josm? Die Adresse des richtigen[tm] WMS Servers lautet http://oberpfalz.geofabrik.de/wms Die Konvertierung der Tiles für Potlach läuft derzeit noch, aber da sind mir auch in gewisser Weise die Hände gebunden, das muss der Author von Potlach einbauen. Authoren anderer OSM Editoren melden sich bitte per Email bei mir. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder LVA Bayern - Vertrag unterschriebe n - Bildqualität?
mea culpa! Ich war davon ausgegangen, dass die Orthofotos im Bayernviewer auch nur 2m Bodenauflösung hätten, das ist aber nicht so. (Und die Bilder die mir vorliegen haben 0,2m Bodenauflösung...) Nochmals Entschuldigung! Stefan Sven Geggus schrieb: Stefan Dettenhofer (StefanDausR) o...@dentro.info wrote: Der Qualitätsunterschied ist ja sehr groß! Sind die Quelldaten nicht besser oder passiert der Qualitätsverlust bein Transformieren oder stelle ich mich nur zu dumm an? Vermutlich beides :) Das WMS Plugin vom josm lädt die Bilder in besserer Qualität wenn man weiter reinzoomt. Ansonsten ist die Qualität leider wirklich nicht zum abmalen von Häusern geeignet. Da hätten wir Bilder mit 50cm Auflösung benötigt. kannst Du Dir ja leicht ausrechnen. Wenn ein Haus zum Beispiel 10mx10m ist, dann sind das ja gerade mal 5x5 Pixel. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder
Hallo Miriam, also ich finde, dass die Luftbilder in dem Bereich schon recht gut mit den bereits erfassten Straßen übereinstimmen. Es kann immer wieder einmal Abweichungen geben, aber eine größere absolute Genauigkeit, als 5-10m werden wir mit den verfügbaren Daten und GPS-Geräten nicht hinbekommen. Im Zweifelsfall würde ich mich auf mehrere GPS-Traces verlassen, denn eine ganz genaue Georeferenzierung der Luftbilder ist nicht so einfach zu bewerkstelligen. Eine lokale Verschiebung um ein paar Meter wird es da immer geben. Abweichungen in dieser Größenordnung ergeben sich ja schon bei den unterschiedlichen Umrechnungsverfahren (Parametern) von GK nach WGS-84. Gruß, Stefan Miriam Tolke schrieb: Hallo, anläßlich der Verfügbarkeit der neuen Luftbilder wollte ich mir gerade mal angesehen wie sich die mit denen von Yahoo und Google decken. Mangels Yahoo-Abdeckung in der Oberpfalz habe ich einen Punkt in Google Earth gesetzt und in JOSM eingeladen. Aus Erfahrung weiß ich, dass 1. Punkte in Google Earth/Maps ca. 2m weiter südlich und 2m weiter östlich liegen als meine GPS-Punkte. 2. Punkte in Yahho-WMS-Bildern ca. 4m weiter südlich und 4m weiter östlich liegen als meine GPS-Punkte. Verglichen mit dem Punkt aus GE liegen die LVA-Luftbilder ca. 7m nach Süden und 5m nach Osten verschoben. Und nachdem ich mir einige GPS-Traces in Regensburg über die LVA-Luftbilder gelegt habe (meine Erachtens schön zu sehen z.B. an Frankenstraße mit dengetrennten Fahrbahnen oder auch Am Europakanal), liegen die auch alle zumindest weiter nördlich als sie den Luftbildern nach sollten. Ist das im Import passiert, oder sind die beim LVA schon so? Klar wird gesagt GPS ist im Bereich von 10m ungenau. Nur zeigt meine Erfahrung, dass es ziemlich konstant 2-3m von den Google-Bildern sind. Außerdem halte ich es für unwahrscheinlich dass die Mehrzahl der OSM-GPS-Traces um den selben Wert abweichen. Grüße, Miriam ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NEUGIER
... und auch die, die Punkte verschieben oder mit Ortskenntnis Attribute hinzufügen... Stefan Guenther Meyer schrieb: Am Sonntag 14 Dezember 2008 schrieb Gary68: ich war heute neugierig und habe mal geschaut, wer so alles mitmacht in der oberpfalz (ich hoffe, man kann es lesen): sind doch ein paar fleißige dabei! na toll... und die, die schon in der oberpfalz gemappt, als es noch nicht interessant war, fallen dabei voellig unter den tisch, gruml... ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lagegenauigkeit der LVA-Luftbilder
so einfach ist das mit dem Umrechnen auch nicht! Auf wenige Meter genau ist es kein Problem, aber wenn man es genauer will, wird es kompliziert. Vor allem dann, wenn man nicht weiß, welche Parameter nun hier gültig sind. Die Vermessungsämter arbeiten -so weit ich weiß- nur mit GK-Koordinaten und daher stellt sich das Problem nicht. Wird mit GPS gearbeitet, so kann man sich immer auf einen genauen Referenzpunkt beziehen und die Messergebnisse dann damit einpassen. Eine flächendeckende und exakte Umrechnung wird es wohl nicht geben. Ein weiteres Problem ergibt sich ja aus der Verzerrung des Luftbildes selbst. Diese sind ja nicht auf unendlicher Höhe aufgenommen, daher gibt es an den Rändern der Einzelaufnahmen Verzerrungen. Das gesamte Orthofoto wird ja aus Einzelaufnahmen zusammengesetzt, die miteinander verrechnet und ausgeglichen werden müssen. Dieser Ausgleich müsste eigentlich auch noch auf die Höhe (ü. NN) ausgedehnt werden, denn beim Überflug mit konstanter Höhe ändert sich ja die Höhe über Grund und so werden höherliegende Orte größer dargestellt als tieferliegende. Gruß, Stefan Markus schrieb: Dann in WGS-84 umrechnen: http://wiki.openstreetmap.org/wiki/Gauß-Krüger und mit dem neuen JOSM-Tool +node einzeichnen, und mit den Daten und Luftbildern vergleichen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wanderwege war: nochmal LKW-Routing
Ich hatte mal versucht mit Kosmos einen Relations-Overlay zu machen, um Wanderwege etc anzuzeigen. Das geht schon, aber man kann noch nicht gut Attribute der Relationen darstellen sondern nur die der Wege, daher habe ich noch nicht weitergemacht. Gruß, Stefan Sven Geggus schrieb: Markus liste12a4...@gmx.de wrote: Der Fränkische Albverein ist schon mal sehr an OSM interessiert. Sie pflegen alle Wanderwege und haben dazu die Tracks und möchten die gern in OSM darstellen (haben aber niemanden, der weiss wie das geht). Wenn man SAC-scale Markierungen an Wege dranmacht werden die zumindest in Osmarender gerendert. Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW-Routing (TV-Bericht)
Hallo Garry, mir ging es nur darum, ob es ein Lizenzproblem (CC 2.0) mit den OSM-Daten geben könnte. Das es andere vertragliche Schwierigkeiten geben kann, steht auf einem anderen Blatt. Gruß, Stefan Garry schrieb: Stefan Dettenhofer (StefanDausR) schrieb: Wieso? Man könnte doch die kommerziellen Daten strikt von den OSM-Daten trennen (2 unterschiedliche Dateien), die dann erst im Naviprogramm zusammengeführt werden. Die OSM-Daten könnten dabei frei downloadbar sein. Wo ist da ein Lizenzproblem? Ein Lizensproblem dürfte von daher bestehen dass ein kommerzieller Kartenanbieter nicht oder nur zu wesentlich schlechteren Konditionen zulassen wird dass fremdes Kartenmaterial aufgespielt werden kann - durch entsprechende Knebelverträge. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
