Re: [Talk-de] JOSM V 3376

[André Joost]

Am 28.07.10 20:50, schrieb Steffen:



Dann frage ich mal: Wie sind die Relationen dann zu taggen?



Stromleitungen: type=route route=power
Busrouten: type=route route=bus
Sammelbusrelation für Hin,Rück und Variante gleicher Nummer:
 type=line line=bus


Theoretisch gibt es ja in josm eine Vorlage für Relationen mit den 
Vorgaben Multipolygon, Abbiegerestriktion und Route. Nur irgendwie sagt 
er mir immer (Version 3329), die Auswahl wäre unpassend :-(


Wenn man da noch einen Relationstyp ÖPNV-Linie unterbringen würde, wäre 
alles paletti. Da könnte man im Routentyp auch die Freileitungen 
unterbringen (aber als Power und nicht als line)


Gruß,
André Joost


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] "Travelling salesman"-Router auf OSM-Datenbasis

[Johann H. Addicks]

Am 28.07.2010 08:18, schrieb Marcus Wolschon:


Hey, immer langsam. ;)
Daß es "Traveling Salesman" heißt, heißt nicht daß es das Traveling
Salesman problem löst.


O.k.

Gibt also kein bekanntes Programm, welches TSP-Routing auf OSM-Basis 
liefert?

Schade!

-jha-


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM: Zum Track zugeordnete Bilder geotaggen

[Daniela Duerbeck]

Ich benutze dafür den Geosetter.
http://www.geosetter.de/

Viele Grüße von Dani

P.S: Als Tipp: Selbst, wenn Du die Uhrzeit in der Kamera nicht ganz korrekt 
gestellt hast, ist es einfach, das hinterher zu korrigieren, sofern Du am 
Anfang jeder Photosession ein Photo Deines GPS-Geräts machst, das die Uhrzeit 
anzeigt. Dann hast Du nämlich den Versatz prima dokumentiert, denn Du hast ja 
die auf dem Bild festgehaltene Uhrzeit, sowie die Kamerainterne Uhrzeit in den 
Exif-Infos und kannst das dann automatisch anpassen lassen.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Umfrage zur Platzierung von Beschriftungen in Karten

[Augustus Kling]

Hallo zusammen,

ich versuche mich derzeit daran Beschriftungen automatisch in Karten zu
platzieren. Um die Qualität der Platzierungen beurteilen zu können, würde ich
gerne eure Meinung zu einigen Beispielkarten wissen.
Es geht nur um die Platzierung der Beschriftungen, nicht darum ob das restliche
Design der Karten ansprechend wirkt.

Bitte klickt euch durch eine kurze Umfrage (zirka 3 Minuten) um eure Meinung
abzugeben: http://www.youthencounter.eu/label-placement/umfrage-deutsch.php

Bei Interesse stelle ich den Algorithmus gerne zur Verfügung (voraussichtlich
gegen Ende September).

Nach der Ankündigung der Umfrage im OSM-Forum habe ich einige Kommentare
bekommen. Folgende Erklärungen sollten die offenen Fragen darin klären:
Die absolute Skala ist bewusst gewählt um beurteilen zu können, ob die Qualität
von unterschiedlichen Personen ähnlich eingeschätzt wird. Es geht mir
hauptsächlich darum zu sehen, welche Fehler eher toleriert werden als andere.
Natürlich im Hinblick darauf welche Fehler von unterschiedlichen Algorithmen
erzeugt werden.
Die Bilder enthalten bewusst Fehler oder sind Kompromisse – es ist nicht mein
Anliegen im Rahmen der Umfrage besonders gute Karten zu präsentieren.

Es wäre natürlich geschickter mehr Bilder zu haben (mit Hintergrund, nur
Beschriftungen, verschiedene Dichten an Objekten, …). Ich bin sehr dankbar für
eure Zeit, die ihr in die Bewertung steckt, und möchte keinen größeren Einsatz
eurerseits verlangen als unbedingt nötig. Daher die Einschränkung auf ein paar
Bilder.

Ein Rendering für alle Einsatzzwecke ist nicht beabsichtigt. Es geht darum
herauszufinden wie die Beschriftungen verschoben werden müssen, damit
Bezeichnungen für Punkte und Flächen zugeordnet werden können. Für Bezeichnungen
von Linien stellt sich die Frage wo die Bezeichnung stehen muss, damit sie
lesbar ist. Außerdem gilt es zu sehen wie viele Informationen untergebracht
werden können, bevor es verwirrend wird.
Sobald der Algorithmus diese Punkte und die Komplexität lösen kann, soll er dazu
dienen kleinere OSM-Dateien lokal zu rendern (also ähnlich Osmarenders
Einsatzgebiet ausgenommen ti...@home).

Freundliche Grüße
Augustus


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-15?q?_forward/backward?=)

[Tobias Knerr]

Am 28.07.2010 20:12, schrieb M∡rtin Koppenhoefer:
> die Richtung dreht auch der Editor selbst automatisch alle Nas lang
> (JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts
> dran vorbei: die Richtung ändert sich (zumindest derzeit) oft.

Die Richtung ändert sich natürlich, aber das ist ja nur dann ein
Problem, wenn manuelle Eingriffe an den Tags nötig werden. Und inwiefern
verbessert so etwas wie der Gruppierungs-Vorschlag da etwas? Wenn ich
zwei der "Richtungsways" verbinde und diese widersprüchliche Tags haben,
muss mich der Editor ebenfalls fragen, was ich denn jetzt am
Vereinigungsresultat haben möchte.

Wenn die Tags *nicht* widersprüchlich sind, könnte das der Editor das
jetzt auch schon erledigen. (Beispiel wären zwei Ways mit
entgegengesetzter Richtung, einer mit maxspeed:forward=60 und einer mit
maxspeed:backward=60.)

Also: Vereinigungen erfordern nur bei widersprüchlichen Angaben an den
Teilen manuelle Eingriffe, und diese manuellen Eingriffe sind bei jedem
Modell notwendig.

Tobias Knerr

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM V 3376

[André Riedel]

Am 28. Juli 2010 20:50 schrieb Steffen :
> Dann frage ich mal: Wie sind die Relationen dann zu taggen?

> [2] type=public_transport JOSM -> public_transport

Im Oxomoa-Schema
(http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema)
wurde entschieden, dass ein type nicht notwendig wäre, da man so und
so immer public_transport=* schreiben muss. Es ist aber nicht
verkehrt, es zu verwenden.

Da sich JOSM zuerst das type-Tag anschaut und hier ein für das
Programm unbekannter Wert verwendet wird, zeigt er nichts an.

> [3] public_transport=stop_area JOSM -> Öffentliche Verkehrsmittel

Auf Grund des oben genannten Schemas korrekt interpretiert.

André

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM V 3376

[Steffen]

--- Original Nachricht ---
Absender: André Joost
Datum: 27.07.2010 13:45

Am 27.07.10 12:55, schrieb Florian Gross:

André Joost glaubte zu wissen:


Soweit ich das überblicken kann, wird für Stromleitungen in DE nur
route=power benutzt. Da sollte es kein Missverständnis geben.


Anderer Meinung: http://wiki.openstreetmap.org/wiki/Stromleitung

flo, auch power=line verwendend


Kleines Missverständnis: Es ging nicht um Wegelemente (für die
power=line richtig ist), sondern um Relationen und deren type-tag.

Gruß,
André Joost


Dann frage ich mal: Wie sind die Relationen dann zu taggen?

[1] type=line JOSM -> Freileitung (Starkstrom)
[2] type=public_transport JOSM -> public_transport
[3] public_transport=stop_area JOSM -> Öffentliche 
Verkehrsmittel


Gruß Steffen

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-15?q?_forward/backward? =)

[M∡rtin Koppenhoefer]

Am 26. Juli 2010 21:33 schrieb Guenther Meyer :
>> einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die
>> auch keiner.
> natuerlich kann man das drehen nicht sperren. Aber man muss es in der Software
> auch nicht anbieten, nicht mal anzeigen. Denn es gibt keinen Grund, die
> Richtung ueberhaupt zu drehen.
>
> Das Problem entsteht doch nur dadurch, weil die Richtung einerseits als
> Referenz fuer diverse Tags genutzt wird, andererseits aber auch direkt z.B.
> die Richtung einer Einbahnstrasse darstellt. Und genau letzteres muss getrennt
> werden.
> schon klar.
> Im Prinzip laeuft alles auf das fehlerhafte Drehen eines ways zurueck.
> Aber warum was neues gross und aufwendig ausarbeiten, wenn man genausogut die
> Ursache des Uebels anpacken kann?
> wie bereits gesagt: ein way bekommt beim Anlegen eine Richtung, und die bleibt
> unveraenderlich so wie sie ist.
> Wenn die Editoren diese Referenzrichtung und das Drehen des Weges gar nicht
> erst anzeigen/anbieten, dreht die auch keiner.


-1, -1, -1

die Richtung dreht auch der Editor selbst automatisch alle Nas lang
(JOSM warnt dabei), sobald man zwei ways zusammenfügt. Es führt nichts
dran vorbei: die Richtung ändert sich (zumindest derzeit) oft.

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Behindertenparkplatz-Die Lösung

[M∡rtin Koppenhoefer]

Am 28. Juli 2010 08:16 schrieb Georg Feddern :
> Wenn Du mir jetzt noch eine Möglichkeit aufzeigst, wie man dann die
> Sonderstellplätze flächig *innerhalb* einer großen Parkfläche ohne
> Multipolygon-Relation eintragen kann (bei derzeitigem Renderer-Verständnis),
> wäre ich komplett einverstanden ...


hast Du mal ein Beispiel? Meiner Meinung nach sind Stellplätze immer
mindestens von einer Seite aus zugänglich (*g*), und dort wird man die
große Fläche entweder teilen oder eine Ausbuchtung reinnehmen. Oder
sprichst Du von Heli-Stellplätzen?

Gruß Martin

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] power=line (Re: JOSM V 3376)

[fx99]

Schaut mal hier nach:
http://dict.leo.org/ende?lp=ende&lang=de&searchLoc=0&cmpType=relaxed§Hdr=on&spellToler=&search=Buslinie

Am Englisch allein scheint es nicht zu liegen!
-- 
View this message in context: 
http://gis.638310.n2.nabble.com/JOSM-V-3376-tp5334585p5345826.html
Sent from the Germany mailing list archive at Nabble.com.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)

[steffterra]

Am 28.07.2010 um 16:38 schrieb Simon Kokolakis:

> Am 25.07.2010 20:43, schrieb steffterra:
> 
>> - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede 
>> Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und 
>> deshalb falsch ist. 
> 
> Das kommt auf die Interpretation des Objektes "way" an.

Daran scheitern sich die Geister. Es scheint aber einen weltweiten Konsens 
darüber zu geben, dass ein way in osm eine Straße repräsentiert und eben nicht 
eine Fahrspur. Das ist sicher geschichtlich zu sehen, daß man froh war, dass 
überhaupt eine Straße eingezeichnet wurde.
Daß das immer noch so gesehen wird, konnte ich in vielen persönlichen 
Gesprächen in unserer lokalen OSM-Gruppe und auch hier recherchieren. 
Hauptgrund dafür ist die visuelle Wahrnehmung des Objekts im Editor. Gestützt 
wird diese These auch dadurch, dass viele meinen, dass es völig ausreichend 
ist, alles mit tags und Relationen an _einem_ way abzubilden.

> Warum ist es falsch die einzelnen Elemente einer Straße als eigene
> oneways darszustellen?

Ich erweitere obige Begründung mit dem (für mich am verständlichsten) Argument 
der "baulichen Trennung". Im Wik ist z.B. definiert, dass bei baulicher 
Trennung der Fahrspuren einer Straße auch je ein way pro Fahrtrichtung 
gezeichnet werden _muß_. Das heisst im Umkehrschluss: Ohne bauliche Trennung: 
ein way.

Die baulichte Trennung teilt beide Fahrrichtungen so vn einander, dass man die 
Trennung in der Wirklichkeit auch sehen kann, da es nicht eine durchgehende 
Fahrbahndecke ist, sondern ein Grünstreifen oder andere bauliche Maßnahmen 
vorhanden sind. Da diese Trennung der Fahrbahnen auch Verkehrsregelungen 
automatisch nach sich zieht (man darf und kann halt nicht mehr wenden, etc.).

Wenn man nun Deiner Meinung nach grundsätzlich zwei ways zeichnen würde, dann 
impliziert das nicht nur die optische Wahrnehmung der baulichen Trennung, 
sondern erstellt nebenbei auch die Verkehrsregeln, wie wenn baulich getrennt 
wäre, dem aber nicht so ist, da durchgehende Fahrbahndecke. Die Folge ist, dass 
bei Abzweigungen und ähnlichem künstliche Verbindungen zwischen beiden 
Fahrspuren geschaffen werden müssten, die in der Realität so gar nicht 
vorhanden sind. Deshalb ein way für eine geschlossene Fahrbahndecke. Da es auch 
selten bauliche Trennungen zu Gehwegen und Radwegen gibt, wird hier ebenso 
verfahren: alles wird an dem einen way getaggt, ausser es ist ein Grünstreifen 
zwischen der Straße und dem Gehweg. Dann kann der Gehweg auch einzeln 
eingezeichnet und entsprechend getaggt werden.

> Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine
> Gruppierung von einzelnen (one)ways..

Deshalb heisst mein Vorschlag ja auch so. Um aber deutlich zu machen, dass es 
eben keine bauliche Trennung gibt, sollte alles nicht zu per Relation oder wie 
auch immer in einer Gruppe zusammengefasst werden, sondern dies auch visuell im 
Editor für die optische Wahrnehmung mit einer gemeinsamen Hintergrundfarbe 
kenntlich gemacht werden. Zudem ist auch im Modell enthalten, dass zunächst 
immer nur der datenway sichtbar ist, da auf ihm auch die richtungsunabhängigen 
Tags wie die der Straßenart und des Namens liegen, was die Straße eindeutig 
identifiziert. Erst wenn man auf den datenway klickt "gehen die anderen 
ways/Fahrspuren auf" und man kann detaillierter bis zur Fahrspur wenn nötig 
fein säuberlich getrennt taggen und ist dabei völlig flexibel, da so auf 
einfache Weise alles abgebildet werden kann, was nötig ist.
Der Editor und später auch der Renderer tragen jedoch maßgeblich dazu bei, dass 
eine Gruppe von ways als eine Straße und nicht als mehrere verschiedene 
Parallelstraßen interpretiert wird.

> Gegenvorschlag:
> 
> Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur,
> Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als
> oneways. Wenn man unbedingt mitgeben will dass diese Elemente
> zusammengehören und eine (baulich ungetrennte) Straße darstellen dann
> gruppiert man sie in einer Relation. associatedStreet wäre da eine
> Möglichkeit.

kann es sein, dass Du damit das Proposal der Linienbündel wiedergibst?

Während dieses Threads bin ich mehrfach auf die Unterschiede meines 
Gruppierungs-Modells zum Linienbündel-Modell eingegangen, denn es hat auch 
Gründe, warum sich dieses nicht durchgesetzt hat. Und dass sind nicht der 
Editor und der Rednerer alleine.

Danke für Dein Feedback,
steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)

[Simon Kokolakis]

Am 25.07.2010 20:43, schrieb steffterra:

> - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede 
> Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und 
> deshalb falsch ist. 

Das kommt auf die Interpretation des Objektes "way" an.
Warum ist es falsch die einzelnen Elemente einer Straße als eigene
oneways darszustellen?

Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine
Gruppierung von einzelnen (one)ways.

Gegenvorschlag:

Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur,
Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als
oneways. Wenn man unbedingt mitgeben will dass diese Elemente
zusammengehören und eine (baulich ungetrennte) Straße darstellen dann
gruppiert man sie in einer Relation. associatedStreet wäre da eine
Möglichkeit.

Beste Grüße,
Simon

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] seek in osm files II

[Gary68]

haben mal ein germany.osm geprüft:

der größte weg benötigt 52k zeichen, 
die größte relation 140k...

da muss die blockgröße von ursprünglich 1024 etwas angehoben werden :-)


ansonsten steht der code soweit, alle prüfungen bisher bestanden. 

ciao und danke für die hilfe soweit 


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] power=line (Re: JOSM V 3376)

[Sebastian Klein]

Georg Feddern wrote:

JOSM kann jetzt eigentlich nur
-  in der Relationsliste bei 'type' generell auf die Übersetzung 
verzichten (schade, aber wohl am geeignetsten)
- dort einen Sonderhack speziell für "type=line" einbauen (mit absoluten 
Bauchschmerzen)
- oder die beiden 'line' müßten unterschiedlich aussehen (noch 
unschöner, da ja jetzt bereits 'hysterisch' ;-) gewachsen)


oder:

- "line" mit Hilfe von Kontext-Strings auf 2 verschiedene Arten 
übersetzen lassen (-> http://josm.openstreetmap.de/changeset/3389)



Sebastian

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-1?q?_forward/backward?=)

[steffterra]

Am 28.07.2010 um 08:05 schrieb Guenther Meyer :

ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer  
Fahrspurtagging

gab's schon mal ein Konzept, dass ohne separate ways auskommt...
Das ist also nichts neues.


Die seperaten ways helfen hier aber auch bei dem Problem der  
richtungsanhängigen ways und eben nicht nur bei der Abbildung von  
Fahrspuren!


Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke.


sehe ich im Moment nicht wirklich
Vorteile - und wesentlich einfacher wird's auch nicht.


Wenn man alle Aspektev mit einbezieht eben schon. Vergleiche  
einfach mal
die nötigen Tags in den Beispielen. Ist doch wesentlich klarer als 
 die
Latte an einem way, der dann ncoh die Gefahr birgt durch ein  
einfaches
Drehen des way komplett über den Haufen geschmissen zu werden. Abe 
r das

wurde auch alles schon einmal besprochen.



die Drehproblematik ist wirklich hinreichend behandelt; ebenso dass  
es keines

neuen Schemas bedarf, um *diese* in den Griff zu kriegen.


Das mag für Dich gelten, ich kenne hier aber keine Diskussion des  
letzten Monats, das es zu irgendeinem Konsens brachte.


Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-)

Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere  
denken schon. Aus diesem Grund entstand mein Engagement für dieses  
Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich  
geschildert.


Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich  
Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu  
erklären, dass doch alles in Butter ist. Mache bitte gerne  
_diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine  
andere Möglichkeit.


Aber bitte demotiviere nicht andere, neue, evtl. bessere  
Lösungsansätze zu verfolgen.


Danke für Dein Verständnis!




In JOSM werden alle drei ways zu einer Gruppe
zusammengefasst und mit einer Farbe hinterlegt, dass dies auch  
optisch

für die Wahrnehmung eine Straße bleibt.


Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt  
bilden?

Relation?


Es steht doch da: sie werden zu einer Gruppe zusammengefasst. Diese
Gruppierungsfunktion durch eine gemeinsame ID (_ähnlich_ wie bei
Relationen, ist aber bei weitem nicht so aufwändig, da automatisie 
rt durch

den Editor) die sich aus den beteiligten ways durch einen einfachen
Algorithmus errechnen liese, habe ich auch schon ausführlich in me 
inem

Startposting beschrieben.



Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache
Relation. Die automatische Erstellung durch den Editor aendert daran  
genau

nichts.


Woher weißt Du dass es nichts anderes ist? Wäre das technisch die  
Lösung, das gewollte so umzusetzen?


Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle  
_dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ 
sinnvoll), die dieses Model bietet.



Warum willst du was neues erfinden, wenn es genau das, was du
brauchst, bereits gibt?


Hmm dann nenne es eine _neue_ Relation, wenn "mein Modell" mit der  
Gruppierung technisch dasselbe wäre.
Doch sollte sie so umgesetzt Erden, wie es in meinem Eingangsposting  
steht: benutzerfreundlich. Wie es benutzerfreundlich wäre, steht auch  
dort.


Hmm kann ja doch noch konstruktiv werden. Hängt ein wenig von Deiner  
Antwort ab. Freue mich auf Deinen Vorschlag zur technischen Umsetzung  
_dieses_ Modells mit einer Relation, die in allen Situationen  
funktioniert.


Für den Anfang würde mir schon reichen, wenn Du dies anhand der  
Beispiele zeigst, die ich in meinem (vor?)letzten Posting dazu  
beschrieben habe, als ich das bisherige und das tagging im neuen  
Modell erklärt habe.


Vielen Dank im Voraus!  (keine Ironie!)

Gruss, steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und?linker Seite

[steffterra]

Am 28.07.2010 um 07:42 schrieb Tirkon :


Tobias Knerr  wrote:


Das geht aber nicht: Die beiden Begriffspaare bezeichnen völlig
unterschiedliche Konzepte, sie sind nicht austauschbar.
In Fällen, wo man forward/backward verwendet, kann man ohne
Bedeutungsunterschied nicht left/right verwenden - und umgekehrt.

Das Treppengeländer ist nun mal rechts, nicht "vorwärts".
Das Laufband bewegt sich vorwärts, nicht "links" oder "rechts".

Beide Angaben nehmen Bezug auf die Richtung des OSM-Ways, aber sind
inhaltlich unterschiedlich.


Genau!

forward/backwards ist eine Richtungsangabe entlang des Weges, forward
in Richtung des Weges, backward entgegengesetzt. left/right ist eine
Seitenangabe, die sich ergibt, wenn man in Richtung des Weges schaut.

Wendet man sich von Straßen ab und nimmt zum Beispiel eine Mauer, auf
der es keinen Richtungsverkehr gibt, deren Weg auf OSM dennoch eine
Richtung hat. Diese kann auf der rechten Seite rot und links schwarz
sein. Spätestens hier kann man mit forward/backward keinen Blumentopf
mehr gewinnen.

Aber auch mit Straßen kann man verdeutlichende Beispiele basteln.
Nehmen wir zum Beispiel eine Einbahnstraße mit zwei Fahrspuren:

Düsseldorf Köln
West   Wegrichtung -<-<-<   Ost
  forward -<-<-<
  backward->->->
===
   -<-<-->->   Ost
  forward ->->->
  backward-<-<-<
===
   ->->->links->->->
- - - - - - - - - - - - - - - - - - - -
   ->->->rechts   ->->->
===
   Regenrinne

Jetzt liegt Köln in Richtung forward, Düsseldorf backward und die
Regenrinne ist rechts.


+111 :-)

Wenn Du das jetzt noch jeweils bei diesen keys ins Wiki schreiben  
würdest, wäre das ne runde Sache und die Diskussion war nicht umsonst!


Danke!
Ich helfe gerne beim Fragen zum Wiki, falls nötig. Zu mehr habe ich  
leider keine Zeit und mit einem Proposal genug Arbeit das  
menschengetecht aufzuarbeiten :-)


Grüße, steffterra 
___

Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] seek (perl) in osm dateien

[Frederik Ramm]

Hallo,

Jacques Nietsch wrote:

Jeder Algorithmus der mit Blöcken arbeitet ist fehlerbehaftet, da mit
gewisser Wahrscheinlichkeit eine Blockgrenze mitten in einen Tag fällt.


Du musst einfach nur Blocks lesen, die mindestens zweimal so gross wie 
die groesste Zeile sind, und dann den den naechsten Zeilenwechsel in dem 
Block finden.



1: Eine Indexdatei erstellen, die die Positionen der Zeilenanfänge enthält.
Das kann man mit Perl oder f(lex) machen und sollte sehr schnell gehen.


Wir machen doch den ganzen Eiertanz nur, weil wir eben nicht die ganze 
Datei durchlesen wollen. "Sollte sehr schnell gehen"... der folgende 
Code, der *nichts* mit den Daten macht:


#!/usr/bin/perl

open(P, "planet.osm");
while()
{
   # nix
}
close(P)

braucht bereits eine gute halbe Stunde. Wenn man einfach nur die Stelle 
finden will, an der die erste Relation oder der erste Way auftauchen, 
dauert das mindestens 20 Minuten. Mit der binaeren Suche und seek() ist 
das in Sekunden erledigt.


Bye
Frederik

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gemeindegrenzen im Regierungsbezirk Freiburg

[bundesrainer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 28.07.2010 13:07, schrieb fly:
> Gibt es da irgendwo Quellen ?
> Ansonsten würde ich die PLZ-Grenzen einzeichnen und die vorübergehend auch als
> administrative Grenzen verwenden.

Würde ich auch empfehlen. Zur Zeit dürften die (abgesehen vom Versatz
und leichter Verzerrung) am besten sein.

Alternativ oder ergänzend (wo es keine PLZ-Grenzen gibt) bietet die
Wikipedia grobe aber brauchbare Grenzverläufe.

Beste Grüße,
Rainer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJMUBQvAAoJEPT/XJzV1tNzrMYH/2Ls2gvINFG41p4NOXXY3L0Y
ElBnUBJkRAZx+L4xYUkCn4a4ju0xa25k79xPtW+1wyYmS43mpxsTxsZ46sS3B+wy
i4IeK089lUV+lBBKWEGrpLM/DvIKlrpHjHshB7CE5WQKPUph7aW+MyzG9sGzf2eB
LxbxB0XBCMCiNCJoAttSv7zwJ1lxqH5veqCevNaa8C9y1t/PO5OzUYHFwJXMAXhp
uu2rwF/ronMnz0E6+JNbApwyBoaQwsfCJPL9DtcrheEUdaZb1eQSAwi0y6xCLwYZ
PJByEaOYPR7P0h1f2TlA7KMd57chlhgs94rTb0J/p7NnUPEwBOwU997mFMq1XdI=
=zZZL
-END PGP SIGNATURE-

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Gemeindegrenzen im Regierungsbezirk Freiburg

[Stefan Schwan]

Hallo!

Am 28. Juli 2010 13:07 schrieb fly :
> Hi
>
> Im Regierungsbezirk Freiburg fehlen noch etliche Gemeindegrenzen. Besonders im
> Elztal und im Baar-Kreis sind fast keine Grenzen vorhanden.
>
> Gibt es da irgendwo Quellen ?
> Ansonsten würde ich die PLZ-Grenzen einzeichnen und die vorübergehend auch als
> administrative Grenzen verwenden.

Im Kreis Konstanz habe ich damit angefangen es genau so zu machen.

Gruß,
Stefan

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Gemeindegrenzen im Regierungsbezirk Freiburg

[fly]

Hi

Im Regierungsbezirk Freiburg fehlen noch etliche Gemeindegrenzen. Besonders im
Elztal und im Baar-Kreis sind fast keine Grenzen vorhanden.

Gibt es da irgendwo Quellen ?
Ansonsten würde ich die PLZ-Grenzen einzeichnen und die vorübergehend auch als
administrative Grenzen verwenden.

Gruß colliar

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Wayfinder & Linux? Spielt da schon jemand?

[Nils Faerber]

Hallo!
Nachdem der Wayfinder Kram freigegeben wurde und da wohl auch schon
rudimentärer OSM Support drin ist wäre es natürlich interessant, das
Teil mal in Aktion zu sehen.
Mich interessiert vor allem der Linux basirte Teil und dort vor allem
Clients - im Zweifelsfall auch Android.

Spielt damit schon jemand hier herum?
Wenn ja, mit welchem Ergebnis?

Viele Grüße
  nils

-- 
kernel concepts GbRTel: +49-271-771091-12
Sieghuetter Hauptweg 48
D-57072 Siegen Mob: +49-176-21024535
http://www.kernelconcepts.de


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] [JOSM] Befehlstack

[Chris66]

Hi,
beim Update auf die aktuelle "tested" 3376 stört mich neben dem
Filterbug, dass in dem Fenster "Befehlsliste" nun auch die per Strg-y
"rückholbaren" Schritte angezeigt werden (nur durch eine kaum sichtbare
Linie von den wirklich durchzuführenden Schritten getrennt).

Gibt es einen Schalter mit dem man das alte Verhalten wiederherstellen
kann? Ich möchte dort nur die Aktionen sehen, die beim Drücken auf
"Upload" hochgeladen werden.

Chris


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Ulf Lamping]

Am 28.07.2010 10:58, schrieb Georg Feddern:

;-) vor allem fröhlich dabei, zu übersehen, dass Du anscheinend - Frage
und Thread betreffend - das falsche Plugin (resp. die eingebaute
Funktion) ausprobiert hast? ;-)


Nee, sorry, ich hab den falschen Thread zum beantworten erwischt ...

> JOSM: Zum Track zugeordnete Bilder geotaggen

Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM: Zum Track zugeordnete Bilder geotaggen

[Ulf Lamping]

Am 27.07.2010 15:58, schrieb Falk Zscheile:

Am 27. Juli 2010 15:46 schrieb Andreas Tille:

ich benutze als Erinnerungshilfe gerne Fotos, die ich dann mit den
Trackdaten über die Uhrzeit synchronisiere.  Da ich aber später manche
Bilder eventuell noch in anderem Zusammenhang benutzen möchte, wäre es
schön, wenn die einmal auf diese Art gestgestellten Geokoordinaten der
Bilder auch gleich in diesen gespeichert würden und man könnte sich
einen extra Arbeitsschritt mit anderen Programmen sparen.

Hat JOSM so eine Funktionalität zum setzen der entsprechenden EXIF Tags?



Das Plugin heißt photo_geotagging.


Hab's gerade (aus Eigeninteresse) selber mal ausprobiert und nach ein 
bisschen rumprobieren:


1) gpx Datei laden (Datei / Öffnen)
2) Fotos laden (Datei / Öffnen) - es hilft dabei, mit Shift "alle 
Bilder" zu selektieren
3) Nächsten Dialog mit "Korrelieren" Button abschließen (nicht mit den 
anderen Einstellungen rumspielen)


Jetzt sollte der GPS-Track und eine Reihe von "Kamera" Icons an den 
richtigen Stellen zu sehen sein.


4) Oben rechts in den Ebenen rechte Maustaste auf den Eintrag 
"Georeferenzierte Bilder/Koordinaten in Bild speichern" klicken


5) Im Dialog Einstellungen nach Bedarf durchführen und auf Ok drücken

... fröhlich sein!

Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[hike39]

Am 28.07.2010 03:39, schrieb Florian Gross:

Johann H. Addicks glaubte zu wissen:

Hallo, entsinne mich, dass das Plugin "Piclayer" früher einmal eine
Funktion hatte, um geladene Bilder nicht nur zu zoomen und zu drehen,
sondern auch zu verschieben (Icon mit blauen Cursorpfeilen), siehe auch
Bebilderung unter
http://wiki.openstreetmap.org/wiki/DE:Piclayer/Anleitung
Aktuell vermisse ich diese Funktion jedoch.
Wo kann die sich versteckt haben? Oder habe ich meinen Josm vergurkt?


Schau mal hier: http://omploader.org/vNTJlYQ/Bildschirmfoto-21.png

Bei mir ist es die rote Fahne mit der weißen Hand.

flo


Wie bist Du an diesen Button gekommen? Das ist doch kein Bestandteil von 
PicLayer. Ich arbeite schon länger sehr intensiv mit diesem Tool, aber 
dieses ist mir noch nicht aufgefallen.


Hike39


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Probleme mit Seen und Inseln

[Willi]

Am 27. Juli 2010 21:45 schrieb Martin Koppenhoefer:

> Landuses, die bis zur Straßenmitte gezogen werden sehen zwar erstmal
> in üblichen Rendering-zoomstufen praktisch gleich aus wie welche, die
> genau sind, aber zum einen vereinfachen die "genauen" das weitere
> Editing ungemein (mit genau meine ich gar nicht mal unbedingt
> lagegenau, da wir hierfür oftmals nicht die Grundlagen haben, sondern
> in erster Linie topologisch genau), und zum anderen sind die landuses
> auf der Straße schlicht falsch.

In OSM werden Straßen durch Linien dargestellt, die in der Straßenmitte liegen. 
Die Straße hat eine Breite. Wenn diese nicht mit "width=" angegeben ist, so 
wird bei der Kartenerstellung ein Standardwert genommen. Wird nun eine Linie, 
die zu einer Straße gehört, mittels einer Relation:multipolygon auch zur 
Darstellung eines angrenzenden Waldes verwendet, so heißt das meines Erachtens 
nicht, dass der Wald bis zur Straßenmitte geht, sondern, dass er an die Straße 
angrenzt und dies ist somit eine korrekte Darstellung. Wie jede Kartografierung 
ist es eine dem Zweck dienende Vereinfachung der tatsächlichen Verhältnisse. 
Selbst wenn ich weitere Details wie Straßengraben und Abstandsfläche 
kartografiere, liegt immer noch eine Vereinfachung der Wirklichkeit vor, denn 
diese Objekte bestehen ja wiederum aus anderen kleineren Objekten. Wie sehr ein 
Kartograf vereinfacht oder detailliert ist wie vieles in OSM dem einzelnen 
Kartografen überlassen. 

Willi


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschiebe n" weg? [gelöst]

[Jacques Nietsch]

Mea culpe!

ich hatte das mit dem 'aktivieren' falsch verstanden.
Wenn man explizit das 'grüne Häkchen' auf dem PicLayer setzt,
dann geht es. Nur einfach den Fokus setzen reicht nicht!

Danke für die Mühe,

Jacques

Am 28.07.2010, 11:10 Uhr, schrieb Jacques Nietsch :


Hallo flo,

Am 28.07.2010, 10:48 Uhr, schrieb Florian Gross  
:



Jacques Nietsch glaubte zu wissen:

CHrEbmZaq4HayLUzCNrSDV
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?


Was gerne vergessen wird: Die Ebene mit dem Bild muß aktiviert
sein, damit verschieben usw. klappt.


Das stimmt, aber ich hatte es nicht vergessen  :(



flo


Jacques



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht

[André Riedel]

Am 28. Juli 2010 11:05 schrieb Tirkon :
> Für OSM müsste jetzt für jede mögliche Kombination von Nachbarn die
> gemeinsame Grenzlinie ermittelt werden und in einen Weg umgewandelt
> werden, der dann mit boundary = administrative und admin_level=9
> getaggt wird. Damit wäre schon viel erreicht. Wenn dann noch
> zusätzlich entsprechend des ursprünglichen Polygons der Gemarkung auf
> diesen Wegen eine Gemarkungs-Relation errichtet werden könnte mit
>
> type = multipolygon
> admin_level = 9
> boundary = administrative
> de:amtlicher_gemeindeschluessel = x
> name = Name der Gemarkung oder x
> sowie den Tags der Gemarkung, wäre das noch die Krönung. Alternativ
> kann dieser letzte Punkt auch in Handarbeit ausgeführt werden.

Mit dem Python-Programm Ogr2Osm [1] werden automatische Multipolygone
erstellt. Man kann zu dem eine Übersetzungsdatei angeben, bei der
Shape-Attribute in OSM-Tags gewandelt werden. Dies lässt sich aber
auch im Nachhinein mit JOSM erledigen.

Ciao André

[1] http://wiki.openstreetmap.org/wiki/Ogr2osm
 (c) Iván Sánchez Ortega, 2009

 python ogr2osm.py [options] [filename]

 Options:   
   -e, --epsg=...   EPSG code, forcing the source data projection
-p, --proj4=...  PROJ4 string, forcing the source data projection
   -v, --verboseShows some seemingly random characters dancing
in the screen
for every feature that's being worked on.
   -h, --help   Show this message
   -d, --debug-tags Outputs the tags for every feature parsed
-a, --attribute-stats Outputs a summary of the different tags /
attributes encountered
-t, --translationSelect the attribute-tags translation method.
See the translations/ diredtory for valid values.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] power=line (Re: JOSM V 3376)

[André Joost]

Am 28.07.10 10:36, schrieb Georg Feddern:

Moin,

André Joost schrieb:






Eher derjenige, der route=line mit Starkstromfreileitung übersetzt hat.



Hat ja niemand. ;-)

Übersetzt wurde in Launchpad für die GUI nur "line" mit "Freileitung
(Starkstrom)" im Zuge der Combo-Box "Line type" bei "Man Made/Powerline".

JOSM versucht aber, in der Relationsliste eine sprechende Bezeichnung
für die Relation anzugeben.
Und wenn weder 'name' noch 'description' angegeben wurde, nimmt er den
'type' (einen Datenbegriff!) dafür - und der ist nun 'line'.


Stimmt so nicht:
Meine Freileitungsrelationen sind im Relationsfenster mit "Route" 
klassifiziert. Name ist natürlich auch vorhanden, der steht aber in 
Klammer und Anführungszeichen dahinter. Streiche ich den Namen, wird er 
durch den ref-tag oder die Relations-ID ersetzt.
Nur wenn ich type=route durch type=line ersetzte, steht im 
Relatioseditor "Freileitung(Starkstrom)".



Und dazu sucht JOSM die passende Übersetzung in der Übersetzungstabelle
... und findet eine, nur leider eine falsche ...



Eine reale Hochspannungsleitungs-Relation mit type=line findet sich
jedenfalls weltweit nicht per XAPI-Abfrage.


Darum geht es ja auch gar nicht ...


Solange es keiner der deutschen Ünbersetzung entsprechend benutzt, ist 
die Rückabwicklung schmerzfrei zu bewerkstelligen.




Ist halt das Problem, dass hier dieselbe Zeichenkette (hier dasselbe
Wort in derselben Schreibung) automatisch in zwei verschiedene
Zeichenketten übersetzt werden müßte - und das geht nicht, da die
Übersetzung wohl nur nach Zeichenkette ohne ID/Verweis aufgesetzt ist.
Vielleicht wird auch der Fundort innerhalb des Programms bei der
Übersetzung als Verweis verwendet - aber s. o., es gibt gar keinen
Fundort, da es sich um einen internen Daten-Begriff handelt, nicht um
einen GUI-Begriff.

JOSM kann jetzt eigentlich nur
- in der Relationsliste bei 'type' generell auf die Übersetzung
verzichten (schade, aber wohl am geeignetsten)


Da wäre ich dann auch für. Bis vor wenigen stable-Versionen lief es ja 
noch einwandfrei. Oder man muß wirklich für die etablierten 
Relationstypen eigene Übersetzungen hinterlegen.


Gruß,
André Joost




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochgeladene Tracks auf Karte anzeigen

[Manuel Reimer]

yzemaze wrote:

ist schon live, allerdings wird silverlight benötigt
http://www.bing.com/community/blogs/maps/archive/2010/07/12/bing-maps-adds-open-street-maps-layer.aspx


*pfui*. Mich stören ja schon diese Kartensysteme, die Java benötigen. 
Sollte heutzutage wirklich alles mit Javascript möglich sein.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[hike39]

Am 28.07.2010 10:09, schrieb Jacques Nietsch:

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?


Hallo,
also bei mir hat gestern noch alles funktioniert. Nur eine Funktion 
vermisse ich sehr: die Möglichkeit das Bild zu verzerren, z.B. zu einem 
Trapez. Aber wenn ich das richtig mitbekommen habe, wird dieses Plugin 
nicht weiterentwickelt.

Hike39



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] seek (perl) in osm dateien

[Manuel Reimer]

Jacques Nietsch wrote:

Jeder Algorithmus der mit Blöcken arbeitet ist fehlerbehaftet, da mit
gewisser Wahrscheinlichkeit eine Blockgrenze mitten in einen Tag fällt.


Stimmt. Dafür gibt es aber einen ganz einfachen Fix.

Man merkt sich einfach jeweils den letzten Block, den man gelesen hat, 
hängt den neuen mit dem alten zusammen und sucht über diesen String.


Gruß

Manuel


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Jacques Nietsch]

Hallo flo,

Am 28.07.2010, 10:48 Uhr, schrieb Florian Gross  
:



Jacques Nietsch glaubte zu wissen:

CHrEbmZaq4HayLUzCNrSDV
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 8bit

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?


Was gerne vergessen wird: Die Ebene mit dem Bild muß aktiviert
sein, damit verschieben usw. klappt.


Das stimmt, aber ich hatte es nicht vergessen  :(



flo


Jacques


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht

[Tirkon]

Moin,

eine der wenigen Dinge, die wir nicht mappen können, sind Grenzen.
Dazu sind wir auf Hilfe von Außen angewiesen. Für das nordwestliche
Niedersachsen liegen die amtlichen Grenzen aller Kommunen und deren
Ortsteile in Form der sogenannten Gemarkungen mit einer Genauigkeit
von 5 Metern vor. Sven Geggus hat das amtsübliche Shapeformat
inzwischen in das *.osm Format umgesetzt. Soweit sich das mit der
OSM-typischen GPS-Genauigkeit überprüfen lässt, ist diese Umsetzung
hochgenau gelungen. Dafür erst einmal einen recht herzlichen Dank an
Sven.

Die Shape Dateien haben aber von OSM abweichende Datenstruktur, welche
sich in der *.osm Datein darstellt, wie folgt:

Jede Gemarkung besteht aus einem rechts umlaufenden geschlossenem Weg
(Polygon), welcher mit dem Namen und weiteren Eigenschaften der
Gemarkung getaggt ist. Dadurch stoßen an den Grenzen zweier
benachbarter Gemarkungen zwei gegenläufige Wege aufeinander, wodurch
dann auch doppelte Nodes entstehen. Die doppelten Nodes lassen sich
mit der Reparaturfunktion von JOSM entfernen, so dass die
gegenläufigen Wege nun dieselben nodes benutzen. Nur an den
Außengrenzen des Importes als auch bei den Nordseeinseln sind dann
einfache Wege vorhanden, da es dort keine Nachbarn gibt.

Für OSM müsste jetzt für jede mögliche Kombination von Nachbarn die
gemeinsame Grenzlinie ermittelt werden und in einen Weg umgewandelt
werden, der dann mit boundary = administrative und admin_level=9
getaggt wird. Damit wäre schon viel erreicht. Wenn dann noch
zusätzlich entsprechend des ursprünglichen Polygons der Gemarkung auf
diesen Wegen eine Gemarkungs-Relation errichtet werden könnte mit 

type = multipolygon
admin_level = 9
boundary = administrative
de:amtlicher_gemeindeschluessel = x
name = Name der Gemarkung oder x
sowie den Tags der Gemarkung, wäre das noch die Krönung. Alternativ
kann dieser letzte Punkt auch in Handarbeit ausgeführt werden. 

Aus diesem Konstukt kann ich dann mit Ortskenntnissen und in
Handarbeit die Ortsteile-, Kommunen- und Landkreisgrenzen sowie die
Außengrenze des Importes in die niedersächsische Außengrenze und die
Grenzen der Anrainer des Importgebietes einbauen. Viele Gemarkungen
sind heute keine administrative Einheit mehr. Von daher muss dort der
admin_level entfernt werden. Von daher macht also ein Upload auch nach
solch einer Umsetzung keinen Sinn.  

deutsche Grenzen im OSM Wiki:
http://wiki.openstreetmap.org/wiki/DE:Grenze

Im Vergleich mit früheren Grenzinporten (Dresden) zeigt sich, dass
dieses Problem bei solchen amtlichen Importen aus Shapedateien immer
wieder auftritt. Ein Programm oder Script könnte also zusammen mit dem
Verfahren von Sven auch später diesen Dienst leisten.

Wenn ich als Laie Sven richtig verstanden habe, wäre dies gleichzeitig
ein erster Weg, um für die vorhanden Formatwandlungsprogramme im
Geobereich einen OSM Ausgang bzw einen shp2osm Konverter zu bekommen.
Über dieses Thema hat er ausführlich auf der letzten Fossgis 2010
referiert:
http://www.fossgis.de/konferenz/2010/attachments/71_osm-datenaufbereitung-fossgis-2010.pdf

Bitte habt Verständnis dafür, dass ich die unfertige *.osm Datei nicht
streuen möchte. Bei früheren Importen wurden diese mehrfach in
diversen unfertigen Formen hochgeladen und musste dann - teilweise in
mühevoller Handarbeit - von Frederik wieder entfernt werden. Wenn
jemand diese Aufgabe angehen möchte, sende ich die Datei daher privat
zu.


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Abbiegerelation bei Auffahrten

[Thomas Ineichen]

Hallo Martin,

> Am 25. Juli 2010 23:38 schrieb Thomas Ineichen :
>> http://www.openstreetmap.org/?lat=50.3743&lon=7.69686&zoom=17&layers=M
>>
>> Eine  Strasse,  die  erst mehrere Meter *nach* der Auffahrt bzw. *vor*
>> der Ausfahrt den Typ wechselt? Laut 'note' ist das Zwischenstück keine
>> Schnellstrasse,  aber  dann  müssten  doch die Auf-/Ausfahrt im Norden
>> sowie  die  Ausfahrt im Süden auch Primary sein? So jedenfalls scheint
>> mir das Tagging unlogisch..

> Schnellstraße (Kfz-straße) ist ein unabhängiges Attribut, einfach
> zusätzlich: motorroad=yes

Die Primary ist sowohl mit 'motorroad=yes' als auch mit 'note = Dieses
Teilstück  ist  keine  Schnellstraße!  Bitte  nicht  mehr  in  "trunk"
ändern!' getagged:

http://www.openstreetmap.org/browse/way/52981819


(Sehr schön ist das motorroad-Rendering mit Osmarender sichtbar:
http://www.openstreetmap.org/?lat=50.37423&lon=7.69717&zoom=17&layers=O
)


> ich würde in dem Fall durchgängig highway=trunk verwenden, dass
> highway um das Netz geht, haben wir ja mittlerweile geklärt.

Eben..  solange  nach  der  Kreuzung  die  ersten 50 Meter als 'trunk'
gemapped  sind,  komme  ich  mit  dem  Fahrrad  sowieso  nicht auf das
primary-Zwischenstück  -  egal  ob die Primary eine Motorroad ist oder
nicht.


Gruss,
Thomas



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Georg Feddern]

Moin,

Ulf Lamping schrieb:

Am 28.07.2010 10:09, schrieb Jacques Nietsch:

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?


Hab's gerade (aus Eigeninteresse) selber mal ausprobiert und nach ein 
bisschen rumprobieren:


1) gpx Datei laden (Datei / Öffnen)
2) Fotos laden (Datei / Öffnen) - es hilft dabei, mit Shift "alle 
Bilder" zu selektieren
3) Nächsten Dialog mit "Korrelieren" Button abschließen (nicht mit den 
anderen Einstellungen rumspielen)


Jetzt sollte der GPS-Track und eine Reihe von "Kamera" Icons an den 
richtigen Stellen zu sehen sein.


4) Oben rechts in den Ebenen rechte Maustaste auf den Eintrag 
"Georeferenzierte Bilder/Koordinaten in Bild speichern" klicken


5) Im Dialog Einstellungen nach Bedarf durchführen und auf Ok drücken

... fröhlich sein!


;-) vor allem fröhlich dabei, zu übersehen, dass Du anscheinend -  Frage 
und Thread betreffend - das falsche Plugin (resp. die eingebaute 
Funktion) ausprobiert hast? ;-)


Bei *Piclayer* muss vor allem die/eine Piclayer-Ebene *aktiv* sein.
Leider werden die PicLayer-Buttons nicht disabled, wenn dies nicht der 
Fall ist.


Gruß
Georg


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Florian Gross]

Jacques Nietsch glaubte zu wissen:
> CHrEbmZaq4HayLUzCNrSDV
> Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
> Content-Transfer-Encoding: 8bit
>
> Hallo,
> wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
> mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).
>
> Bei mir tut sich bei KEINEM Button irgend etwas!
> Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?

Was gerne vergessen wird: Die Ebene mit dem Bild muß aktiviert
sein, damit verschieben usw. klappt.

flo
-- 
>Aber ich bin sicher, das sich hier ein totaler Spinner ohne dein Wissen an
>den Rechner gesetzt hat und sich deines guten Namens bedient hat...
>oder irre ich mich???  |||  Um meinen Namen zu missbrauchen, muß man sich
nicht an meinen Rechner setzten. Insbesondere muß man kein "SCNR" in das
Posting schreiben. [Nelko Piplica und Hendrik Brummermann in dag°]


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochgeladene Tracks auf Karte anzeigen

[Chris66]

> Über gpswandern.de gehts auch:
> 
> 
> 
> Hier kann man dann auch OSM als Untergrund wählen.

Und mittels mtype auch direkt im Link als Parameter mitgeben:



Chris


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Ulf Lamping]

Am 28.07.2010 10:09, schrieb Jacques Nietsch:

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?


Hab's gerade (aus Eigeninteresse) selber mal ausprobiert und nach ein 
bisschen rumprobieren:


1) gpx Datei laden (Datei / Öffnen)
2) Fotos laden (Datei / Öffnen) - es hilft dabei, mit Shift "alle 
Bilder" zu selektieren
3) Nächsten Dialog mit "Korrelieren" Button abschließen (nicht mit den 
anderen Einstellungen rumspielen)


Jetzt sollte der GPS-Track und eine Reihe von "Kamera" Icons an den 
richtigen Stellen zu sehen sein.


4) Oben rechts in den Ebenen rechte Maustaste auf den Eintrag 
"Georeferenzierte Bilder/Koordinaten in Bild speichern" klicken


5) Im Dialog Einstellungen nach Bedarf durchführen und auf Ok drücken

... fröhlich sein!

Gruß, ULFL

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] power=line (Re: JOSM V 3376)

[Georg Feddern]

Moin,

André Joost schrieb:

Am 28.07.10 03:36, schrieb Johann H. Addicks:

Am 28.07.2010 02:55, schrieb Florian Gross:



Wer hat sich das denn ausgedacht?


Jemand, der "Buslinie" (dt.) nach "bus line" (engl.) übersetzt hat?



Wohl eher von "Linienführung", wobei er vermutlich eine Unterscheidung 
zur 'route' (Gesamte Linie mit allen Linienführungen und 
Fahrtrichtungen) gesucht hat ...




Eher derjenige, der route=line mit Starkstromfreileitung übersetzt hat.



Hat ja niemand. ;-)

Übersetzt wurde in Launchpad für die GUI nur "line" mit "Freileitung 
(Starkstrom)" im Zuge der Combo-Box "Line type" bei "Man Made/Powerline".


JOSM versucht aber, in der Relationsliste eine sprechende Bezeichnung 
für die Relation anzugeben.
Und wenn weder 'name' noch 'description' angegeben wurde, nimmt er den 
'type' (einen Datenbegriff!) dafür - und der ist nun 'line'.
Und dazu sucht JOSM die passende Übersetzung in der Übersetzungstabelle 
... und findet eine, nur leider eine falsche ...


Von den 2638 Relationen dieses Typs liegen nämlich längst nicht alle 
in DE, sondern auch in frankophonen Nachbarländern.

Die Red Line Metro in Abu Dhabi ist z.B. eine railway=light_rail.
Immerhin ist der Ersteller der Relation aber ein Deutscher ;-)

Eine reale Hochspannungsleitungs-Relation mit type=line findet sich 
jedenfalls weltweit nicht per XAPI-Abfrage.


Darum geht es ja auch gar nicht ...

Ist halt das Problem, dass hier dieselbe Zeichenkette (hier dasselbe 
Wort in derselben Schreibung) automatisch in zwei verschiedene 
Zeichenketten übersetzt werden müßte - und das geht nicht, da die 
Übersetzung wohl nur nach Zeichenkette ohne ID/Verweis aufgesetzt ist.
Vielleicht wird auch der Fundort innerhalb des Programms bei der 
Übersetzung als Verweis verwendet - aber s. o., es gibt gar keinen 
Fundort, da es sich um einen internen Daten-Begriff handelt, nicht um 
einen GUI-Begriff.


JOSM kann jetzt eigentlich nur
-  in der Relationsliste bei 'type' generell auf die Übersetzung 
verzichten (schade, aber wohl am geeignetsten)
- dort einen Sonderhack speziell für "type=line" einbauen (mit absoluten 
Bauchschmerzen)
- oder die beiden 'line' müßten unterschiedlich aussehen (noch 
unschöner, da ja jetzt bereits 'hysterisch' ;-) gewachsen)


Gruß
Georg


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] seek (perl) in osm dateien

[Jacques Nietsch]

Hallo Frederik,

Am 27.07.2010, 20:42 Uhr, schrieb Frederik Ramm :


Hallo,

Gary68 wrote:

bin schon am probieren. trivial ist was anderes... die buffer sizes
müssen sehr groß gewählt werden, was anscheinend zunächst zu problemen
führt...


Du kannst es bei Bedarf so bauen, dass die Buffergroesse dynamisch  
erhoeht wird, wenn nichts gefunden wird.


Jeder Algorithmus der mit Blöcken arbeitet ist fehlerbehaftet, da mit
gewisser Wahrscheinlichkeit eine Blockgrenze mitten in einen Tag fällt.

Mein Vorschlag wäre zweistufig zu arbeiten.

1: Eine Indexdatei erstellen, die die Positionen der Zeilenanfänge enthält.
Das kann man mit Perl oder f(lex) machen und sollte sehr schnell gehen.
2: Binärsuche über die Indexdatei und dann mittels seek-read aus der  
Datendatei lesen




Bye
Frederik



Gruss
Jacques


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] PicLayer in Josm - Button "Verschieben" weg?

[Jacques Nietsch]

Hallo,
wo wir gerade beim Thema sind, ich habe gestern das erste mal versucht
mit diesem Plugin zu arbeiten. JOSM(3376) und Piclayer(21706).

Bei mir tut sich bei KEINEM Button irgend etwas!
Mache ich etwas falsch, oder hat das Piclayer Plugin ein Hau?

Gruss
Jacques

Am 28.07.2010, 01:51 Uhr, schrieb Johann H. Addicks :

Hallo, entsinne mich, dass das Plugin "Piclayer" früher einmal eine  
Funktion hatte, um geladene Bilder nicht nur zu zoomen und zu drehen,  
sondern auch zu verschieben (Icon mit blauen Cursorpfeilen), siehe auch  
Bebilderung unter

http://wiki.openstreetmap.org/wiki/DE:Piclayer/Anleitung
Aktuell vermisse ich diese Funktion jedoch.
Wo kann die sich versteckt haben? Oder habe ich meinen Josm vergurkt?

-jha-<>___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochgeladene Tracks auf Karte anzeigen

[Chris66]

>> 
> 
> Cool!
> 
> Wenn google jetzt noch OSM Tiles anzeigen würde ;-)

Über gpswandern.de gehts auch:



Hier kann man dann auch OSM als Untergrund wählen.

Chris


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Hochgeladene Tracks auf Karte anzeigen

[yzemaze]

On 28.07.2010 08:47, Tirkon wrote:
> Chris66  wrote:
> 
>> Wenn google jetzt noch OSM Tiles anzeigen würde ;-)
> 
> Irgendwo hatte ich gelesen, dass Bing maps das bald anbieten will.
> Weiß jemand, wann das erfolgen soll?

ist schon live, allerdings wird silverlight benötigt
http://www.bing.com/community/blogs/maps/archive/2010/07/12/bing-maps-adds-open-street-maps-layer.aspx

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] AIO EUROPA -vom 27.07 läuft wieder!

[UMAX974]

Ach ja und wieder eine kurze "Wasserstandsmeldung" die AIO von Gestern (27.07) 
läuft wieder problemlos am etrex Legend Cx ;) Freu!!
UMAX974



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] power=line (Re: JOSM V 3376)

[André Joost]

Am 28.07.10 08:50, schrieb Walter Nordmann:


edwin? ;)


Falscher Film ;-)

Gruß,
André Joost



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de