Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 23. August 2011 02:02 schrieb Christian Müller :
> Am 22.08.2011 19:35, schrieb M∡rtin Koppenhoefer:
>> Gegenfrage: wieso sollte man es beim Rendern dem Zufall (der
>> Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört? Was
>> soll daran besser sein, wenn der Park auf dem Gehweg oder im Rinnstein
>> endet anstatt dort, wo er tatsächlich zu Ende ist? Gerade beim Rendern
>> von großen Zoomstufen ist es doch erwüscht, auch Details erkennen zu
>> können, eine Vergrößerung der Flächen potentiell bis zur Straßenmitte
>> (wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt)
>> schadet mehr als sie vermeintlich nützt.
>
> war hier nicht das credo, dass wir nicht für renderer taggen?


es geht mir nicht primär ums Rendern sondern darum, dass Flächen dort
eingetragen werden, wo sie sind. Das leitet sich m.E. aus dem
Flächenmodell so ab.


> und der Renderer überlässt nichts dem Zufall, er rendert an der Stelle die
> Fläche, an der die Straße aufhört.


wo "die Straße aufhört" ist sehr selten klar, da keine Breitenangaben
oder Angaben zu weiteren Bestandteilen der Straße in den Daten
vorhanden sind. Es ist nicht einmal klar, welche Teile der realen
Straße der osm-highway tag beschreibt, allerdings könnte man
argumentieren, es handele sich um die komplette Fahrbahn (seitliche
Barrieren und Teile dahinter würde ich eher nicht dazurechnen,
zumindest habe ich noch nie gesehen, dass die jemand im width-Tag
angegeben hätte).

Gruß Martin

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

Re: [Talk-de] living_street + alley?

[M∡rtin Koppenhoefer]

Am 22. August 2011 10:43 schrieb Sven Geggus :
> Peter  wrote:
> Ich fand highway=living_street von Anfang an bescheuert. In 99% der Falle
> in Deutschland sind das ganz normale residential roads. Die Tatsache, dass
> das eine Spielstraße ist sollte in einen eigenen Tag.


+-0
es spielt im Grunde keine Rolle, idealerweise machen es aber alle gleich ;-)

Wo Platz ist für einen Reitweg und 5 Klassen von Verbindungsstraßen
kann eine verkehrsberuhigte Zone auch nicht schaden, andererseits
werden Kraftfahrstraßen anders behandelt und es scheint mittlerweile
auch zu funktionieren (zumindest anfangs wurde man mit dem Rad da
trotzdem draufgeleitet, weil der Tag nicht ausgewertet wurde).

Gruß Martin

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

Re: [Talk-de] Eine Relation "aus der Not"

[M∡rtin Koppenhoefer]

Am 22. August 2011 20:48 schrieb Albrecht Will :
> Euer Vorschlag mit relation=site hat was. Leider ist diese Relation noch nicht
> am Laufen.


wie meinst Du das? Es gibt davon derzeit 128714 Stück.


> Ich werden mal die Flächen doch löschen und das Ganze als leisure=park und
> tourism=zoo eintragen.


Du kannst z.B. auch die Flächen alle in eine Multipolygon-Relation
aufnehmen und dieser tourism=zoo, einen Namen, etc. mitgeben, ohne bei
den Einzelflächen Informationen zu löschen, die sich darauf beziehen.

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 22. August 2011 11:54 schrieb Dimitri Junker :
>>sofern es ausser der Nähe eine Beziehung gibt.
> entweder die Fläche grenzt an die Straße, dann ist das eine Beziehung, oder
> sie grenzt nicht dran, dann ist aber klar, daß sie eine getrennte Linie
> braucht.


in der überwiegenden Zahl der tatsächlichen Fälle, wo ich in OSM
Flächen gefunden habe, die bis zur Straßenmitte gezogen waren, grenzte
die Straße nicht an die Fläche, wobei ich zugeben muss, dass es
eigentlich immer Interpretationssache sein kann, was man noch als
zugehörig sieht. Wenn man dem Vergröberungslager angehört dem jedes
Details ein Dorn im Auge ist auf dem Weg, möglichst große Gebiete in
JOSM laden zu können, dann wird man wohl auch noch das Gebüsch
jenseits von Leitplanke, Bankett und Entwässerungsgraben als Teil der
Straße (oder des Walds oder Felds, wie hier auch schon erwähnt) sehen
können.

Da es hier wohl unterschiedliche Ansichten gibt kann ich nur hoffen,
dass wenigstens genug Respekt für die Arbeit anderer da ist, um nicht
die Details anderer absichtlich zu löschen, damit die Nodedichte
gering bleibt.


> Mal ein Bsp. Wir haben einen großen Wald, eine Straße geht mitten durch,
> Dann werden wir wohl den Wald als eine Fläche zeichnen und die 1. Straße
> durch die Fläche durch. Hier macht es keinen Sinn den Wald entlang der
> Straße aufzuschneiden und dann parallel zur Straße 2 Waldgrenzen zu
> zeichnen.


doch, macht m.E. gelegentlich Sinn und mache ich dann auch.


> So genau ist die Grenze eines Waldes sowieso nicht definierbar
> (Endet der Wald am letzten Stamm oder am Ende der Kronen, die ggf. über die
> Straße ragen,...).


so genau in der Tat nicht, wenn Du Dir mal einen echten Wald ansiehst
wirst Du aber bemerken, dass es in der Realität weitaus größere
Schwankungen gibt als nur der halbe Kronendurchmesser eines Baums.


> In der klassischen Kartenwelt gibt es u.a. 2 Arten von Karten, Landkarten
> und Katasterkarten. OSM ist meiner Meinung nach mit ersteren vergleichbar.


-1, OSM ist sicherlich nicht mit einer Karte in einem bestimmten
Maßstab vergleichbar, und hier sehe ich auch die Ursache in der
Diskussion hier bzw. allgemein in der Diskussion mit Leuten, die gerne
die Details in OSM begrenzen wollen: eine Datenbank sollte man nicht
mit der gerenderten Karte in einem bestimmten Maßstab verwechseln.


> Wenn wir Katasterkarten machen wollen müßen wir ganz anders vermessen, da
> reichen GPS oder Stabilder nicht aus. Die meisten von uns mappen per GPS
> indem sie auf der Rechten Fahrbahn fahren oder sogar auf dem Bürgersteig
> gehen und zeichnen danach die Straße ein, ob sie dabei immer den Abstand zur
> Mittellinie korrigieren bezweifel ich.


der nächste kann das dann richten, ist ja iterativ. Wir haben heute
großflächig gute Luftbilder die eine ziemlich hohe Genauigkeit
ermöglichen, mit GPS keineswegs vergleichbar (aber auch schon vorher
war das Credo, sich nicht sklavisch nach dem GPS zu richten, s.z.B.
relative Genauigkeit).


>>Beim Routing spielen Flächen (ausser der Rand von highway-Flächen)
>>sowieso keine Rolle, die können da verbunden sein oder nicht.
> Es sei denn sie sind das Ziel, dann sucht der Router eine Verbindung
> zwischen Fläche und Straßenraum.


wenn es keine Verbindung gibt nimmt er das nächstgelegene Ziel auf
einer Straße. Wir zeichnen Hausnummern oder Telefonzellen ja auch
nicht auf die Straße sondern daneben, auch wenn gerade Telefonzellen
sich praktisch immer auf dem Gehweg befinden (und der ist im OSM
Modell derzeit Teil der Straße).

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 22. August 2011 11:54 schrieb Dimitri Junker :
> Aber nenn mir doch mal ein konkretes Bsp wo die getrennten Linien Sinn
> machen, also folgende Bedingungen erfüllt sind:
...


Gegenfrage: wieso sollte man es beim Rendern dem Zufall (der
Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört? Was
soll daran besser sein, wenn der Park auf dem Gehweg oder im Rinnstein
endet anstatt dort, wo er tatsächlich zu Ende ist? Gerade beim Rendern
von großen Zoomstufen ist es doch erwüscht, auch Details erkennen zu
können, eine Vergrößerung der Flächen potentiell bis zur Straßenmitte
(wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt)
schadet mehr als sie vermeintlich nützt.

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 22. August 2011 08:41 schrieb Christian Müller :
> Am 22.08.2011 07:10, schrieb Joerg Fischer:
> Ganz genau hinschauen muss er eher, wenn die Fläche /nicht/ an den Weg
> gepappt ist - denn dann ist es fast Zufall bei entsprechender Zoomstufe,
> ob der node in den Weg der Fläche eingefügt wird, oder in den Weg.


Maus mit Rad hast Du? Bei den Zoomstufen, bei denen es Zufall ist, wo
man den Node einfügt, sollte man ans Editieren nicht mal denken.


Gruß Martin

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

Re: [Talk-de] Hilfe bei einer Insel - Ergänzung

[M∡rtin Koppenhoefer]

Am 22. August 2011 16:18 schrieb Jan Tappenbeck :
> habe da noch einen Nachtrag - hatte mir nur eine Fläche aus einem Rechteck
> als Sandbox mal erzeugt in der Nähe vom KIRR und dieselben Tags wie vom o.g.
> [1] zugewiesen. Hier wurde nur der Name und auch nicht die Freistellung
> gerendert. (zwischenzeitlich wieder gelöscht!).
>
> Ich finde es mehr als merkwürdig.


Hallo Jan,

wie schon im parallelen Thread erklärt: die Küstenlinien
(natural=coastline) werden nicht wie die übrige Karte sondern in einem
separaten Prozess in Mapnik behandelt (shapefiles). Ist Dein Problem
in T@H auch vorhanden? Wenn nicht, dann einfach mal einen Monat oder
so abwarten, dann sollten die Änderungen in Mapnik auch angekommen
sein.

Wie ebenfalls bereits erwähnt, ist bei den Coastlines die Richtung des
Ways wichtig: links liegt das Land, rechts das Meer.

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 21. August 2011 20:06 schrieb Dimitri Junker :
> Zeichnet man dagegen eine parallele Linie
> zur Straße als Flächengrenze geht die Beziehung zwischen beiden verloren.


sofern es ausser der Nähe eine Beziehung gibt. Die räumliche Nähe hast
Du ja in jedem Fall, wenn Du aber die Fläche vergrößerst, damit sie
topologisch in das Straßenmodell passt, dann muss jeder, den die
Fläche interessiert, erstmal nachsehen, welche Straßen noch Kanten mit
der Fläche teilen, und dann (falls es dort eine Breite geben sollte)
die Straßenfläche abziehen.


> Man müßte also dann eine Relation o.ä. machen um Fläche und Straße zu
> verknüpfen.


wäre sicher am Eindeutigsten, wo es zutrifft, z.B. um Plätze in der
Stadt an Straßen anzubinden, pauschal würde ich aber gar nicht
unbedingt davon ausgehen, dass die Flächen die zur Zeit in OSM
gezeichnet sind, die Straße begrenzen. Wenn man das grundsätzlich
annehmen wollte, könnte man das auch über die Nähe berechnen.


> Ohne diese Verknüpfung könnte ein Renderer z.B. nicht wissen das
> er die Fläche unabhängig vom Zoomlevel immer bis an die Straße zeichnen
> soll


Fürs Rendern gibt es in der Praxis m.E. kein Problem, (ausser die
Fläche endet richtig weit von der Straße entfernt, dann wird man das
auch sehen wollen), da wir die Straßen in den meisten Zoomleveln
grafisch deutlich überhöhen.

Beim Routing spielen Flächen (ausser der Rand von highway-Flächen)
sowieso keine Rolle, die können da verbunden sein oder nicht.

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 15. August 2011 02:14 schrieb Christian Müller :
> Um nochmal auf den Zaun zurückzukommen.  Einfach gesprochen, wenn der
> eine Fläche einsäumt, lassen Mapper m.W. auch keinen Platz zur Fläche -
> hier ist das Verkleben ein Automatismus.


Die Ausnahme ist hier nur die Straße, wo einige behaupten, der
Mittelgraph wäre die Fläche (m.E. wird man irgendwann - und einige
machen das jetzt schon - Straßen zusätzlich als Fläche eintragen, und
dieses Thema löst sich von selbst), bei Zäunen gibt es kein Problem.


> Wir taggen den way mit
> barrier=fance und die Fläche, die er umschließt, auf demselben way mit
> landuse=*  -  da gibt es auch kein Niemandsland dazwischen.


das ist nicht unbedingt so: "Spaghetti-Mapping" geht sicherlich so,
aber man kann auch zweimal denselben Weg zeichnen, einmal als
Line-Feature (Zaun) und einmal als Flächenfeature (Landuse, leisure,
natural, etc.), was dann für Klarheit sorgt, wenn man weitere Tags
ergänzt (z.B. "name", wo ein Mensch noch einigermaßen sicher sagen
kann, dass sich das wohl auf die Fläche bezieht, ein Computer es aber
u.U. auch auf den Zaun beziehen würde). Als Verbesserung dieser
Methode würde man anstatt eines doppelten Weges ein Multipolygon für
die Fläche verwenden (mache ich persönlich z.B. so).

Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 14. August 2011 16:40 schrieb Christian Müller :
> Am 14.08.2011 15:57, schrieb Bartosz Fabianowski:
>> Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht
>> korrekt.
> Geographisch evtl. nicht, topologisch hingegen schon.


M.E. sollte man für die Topologie-Fanatiker eine Relation oder
irgendwas einführen, damit die Graphen-Flächen-Inkompatibilität
überwunden wird. Flächen bewusst falsch zu zeichnen, damit sie mit dem
Graphen-Modell der Straßen topologisch verbunden sind, sehe ich als
Irrweg. Erst recht, da dadurch das Editieren fehlerträchtig und
umständlicher wird.


> Der Wegesrand
> beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM
> durch eine Linie repräsentiert wird.


wobei es hier nicht darum ging, den "Wegrand" zu mappen, sondern um
angrenzende Flächen.


> Vorteile:
> - kein Niemandsland zwischen Straße und Gebiet


m.E. kein Vorteil, das gaukelt nur Vollständigkeit vor, wo eigentlich
Details hingehören (könnten) ;-)


> - mehr Übersicht im Editor (vgl. tausende nodes an einer Kreuzung)


m.E. das Gegenteil: völlig unübersichtlich, da alles auf eine Linie
läuft, auch wenn es gar nicht zusammengehört. Eine Linie für ein
Objekt ist m.E. übersichtlicher.


> - weniger nodes


das stimmt, aber ist nicht unbedingt ein Vorteil, es sind dadurch ja
auch weniger Informationen enthalten.


> - geringere DB Größe / weniger Ressourcenverbrauch


ja, am kleinsten wird sie, wenn man alles löscht ;-)


> -> das ist z.B. interessant, wenn ein großes Datenset in den Editor
> geladen wird,
>  oder man die Daten für mobile Geräte fit machen möchte


dazu braucht man Informationen nicht weglassen: Editoren könnten auch
mit größeren Datenmengen umgehen, wenn sie dafür optimiert werden und
für mobile Geräte muss man die Daten sowieso konvertieren, d.h. dass
man da ansetzen könnte.


Gruß Martin

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

Re: [Talk-de] wieder mal - Flächen und Wege

[M∡rtin Koppenhoefer]

Am 14. August 2011 15:57 schrieb Bartosz Fabianowski :
> Es gibt hier keinen "etablierten Standard".


leider ;-)


> Das gängige Argument fürs
> Aneinanderkleben ist daß die Landnutzung da anfängt wo die Straße aufhört.


ja, wobei hier m.E. Äpfel mit Birnen gemischt werden. "Korrekte"
Flächen sind nunmal die, die den wahren Umriss beschreiben.


> Das Gegenargument dazu ist daß wir ja nur die Mittellinie der Straße mappen.
> Die Landnutzung dagegen fängt erst am Wegesrand an. Ein Aneinanderkleben ist
> daher IMHO geographisch nicht korrekt.


ja eben


> Zudem macht es das Editieren
> schwieriger.


+1

Gruß Martin

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

Re: [Talk-de] Garmin GPSmap 62 ....

[M∡rtin Koppenhoefer]

Am 15. August 2011 11:42 schrieb NopMap :
> Leider hat das 62 nicht den genialen Empfang den die alten 60er hatten.


+1
auch mit neuester Firmware finde ich die Bedienung darüberhinaus
völlig unbefriedigend. Beim alten 60er hat man alles im Griff, kann
z.B. sofort sehen, ob man gerade loggt oder nicht, und kann das auch
bequem jederzeit an- und ausschalten, während man beim neuen 62er
weniger Optionen hat. Einzelne Waypoints nachträglich zu editieren
(oder z.B. einzelne löschen) geht AFAIR überhaupt nicht. M.E. völlig
unverständlich, wieso die eine gute Bedienung so kaputt gemacht haben.

Gruß Martin

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

Re: [Talk-de] OSM auf BILD.de

[M∡rtin Koppenhoefer]

Am 18. August 2011 17:14 schrieb Wolfgang :
> aber die einzigen, die konkret dagegen vorgehen könnten, sind die
> Lizenzverweigerer. Allen anderen wäre im Hinblick auf die Lizenzumstellung und
> die Aufforderungen an (Noch-)Nicht-Zustimmer widersprüchliches Verhalten
> vorzuwerfen, was wahrscheinlich zum Verlust des Anspruchs auf das by-sa führen
> würde.


Wer den CT zugestimmt hat, hat der OSMF ein nicht exklusives Recht an
den Daten übertragen, so dass die OSMF gegen Lizenzverstöße vorgehen
kann/könnte.

Gruß Martin

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

Re: [Talk-de] Baumreihen, Alleen an Straßen

[M∡rtin Koppenhoefer]

Am 11. August 2011 23:26 schrieb Christian Müller :
> Am 11.08.2011 21:13, schrieb Albrecht Will:
> OSM sammelt Daten der Realität.


+1


> Auf dein Beispiel bezogen: Ein Baum der Allee könnte fehlen, nicht alle
> Bäume haben evtl. den gleichen Abstand, etc. pp.  Weiterhin, wenn Du mit


+1


> natural=tree_row
> denotation=avenue


m.E. kann man gleich einzelne Bäume mappen
natural=tree
denotation=avenue

Das geht praktisch genauso schnell, zumindest bei Kurven ;-) wie
parallele Linien, und ist viel realistischer und lässt sich bei Bedarf
auch viel besser (auch einzeln) verfeinern. Man braucht allerdings
rel. gute Luftbilder (die es mittlerweile oft gibt).


> Es gab eine ganze Zeit lang viele Proposals, welche zum Ziel hatten, die
> Erfassung von Linienbündeln zu vereinfachen.  ...  Andere waren dafür, selbst 
> für jede Fahrspur eine Linie zu
> erfassen und den gemeinsamen Bezug über eine Relation darzustellen.
>
> Heute ist ein Mix in OSM zu finden -


naja, beides ist eher noch nicht in OSM angekommen.

Gruß Martin

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

Re: [Talk-de] Garmin-Geräte aus den Staaten

[M∡rtin Koppenhoefer]

Am 9. August 2011 19:42 schrieb Henning Scholland :
> Netzteil gibts nicht. Gewährleistung weiß ich net, wie Garmin sich da muckt.
> Ob das den Aufwand und die Zeit, die dann dein Bekannter beim Zoll
> verbringen darf und deinen Aufwand die Ersparnis rechtfertigt???


Lohnen dürfte sich das evtl. dann, wenn man es selbst mitbringt.
Problem ist aber z.B., dass man das Gerät evtl. patchen muss, damit
man deutsch als Sprache einstellen kann (ist nicht besonders
schwierig, aber vielleicht nicht ganz legal?). Auch ist die eingebaute
Basemap dann vermutlich Nordamerika und nicht Europa (habe selbst so
ein amerikanisches 60csx, vor 3 Jahren war das trotz Zoll noch
deutlich attraktiver).

Gruß Martin

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

Re: [Talk-de] Baumreihen, Alleen an Straßen

[M∡rtin Koppenhoefer]

Am 10. August 2011 14:38 schrieb Christian Müller :
> Vereinzelte Bäume taggst Du mit
> natural=tree
> auf nodes.


+1, solange man das "vereinzelte" nicht ausgrenzend meint, sondern im
Sinne von "einzelne".

Für Alleebäume ist ausserdem
denotation=avenue vorgeschlagen (als Zusatz).

Gruß Martin

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

Re: [Talk-de] Relation Analyzer noch state of the art?

[M∡rtin Koppenhoefer]

Am 3. August 2011 16:04 schrieb Andreas Tille :
> Die in dem anderen Mail beschriebene Methode der Aufspürung von Lücken
> per Relation Sortieren ist mir unklar.  Eventuell könnte man sowas
> innerhalb von JOSM noch leicht eleganter lösen als mit der Web-Anwendung,
> aber eigentlich ging's schon ganz gut mit dem RA.


In JOSM geht das Finden von Lücken so:

1. Relation im Relationeneditor öffnen (z.B. eines der Member
anclicken und im tag-Fenster den Relationen-Eintrag auswählen und den
Bearbeiten-Button anklicken).

2. Ggf. noch nicht geladene Member nachladen (Button links im Relationeneditor).

3. Im Relationeneditor linke Seite den Sortieren-Button anklicken
(A-Z). Es sollten vorher alle Member der Relation geladen sein.

4. Die rechte Spalte der einzelnen Way-Member zeigt an, welche Ways
miteinander verbunden sind und wo evtl. noch Lücken sind.

Gruß Martin

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

Re: [Talk-de] Gab es in einem Bereich schon einmal Nodes?

[M∡rtin Koppenhoefer]

Am 2. August 2011 12:53 schrieb M∡rtin Koppenhoefer :
> Du könntest z.B. in Potlatch1 "u" drücken und sehen, ob nach einigem
> Warten ein paar rote (=gelöschte) Ways auftauchen.


Sorry, Du suchst wohl nodes? PL1 findet nur ways. Versuchs mal mit OWL:

http://matt.dev.openstreetmap.org/owl_viewer/map

auf die Stelle sehr weit reinzoomen und das tile anclicken.

Alternativ: Einen alten Planet runterladen und mit Osmosis die Stelle
ausschneiden, die Dich interessiert. Dann z.B. in JOSM öffnen.

Gruß Martin

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

Re: [Talk-de] Gab es in einem Bereich schon einmal Nodes?

[M∡rtin Koppenhoefer]

Du könntest z.B. in Potlatch1 "u" drücken und sehen, ob nach einigem
Warten ein paar rote (=gelöschte) Ways auftauchen.

Gruß Martin

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

Re: [Talk-de] Digitalradio.de - Karte ohne Attributierung?

[M∡rtin Koppenhoefer]

>> Schlimmer noch: Es werden die Tiles vom Hauptserver gezogen.
> Das mit dem Tileserver verstehe ich nicht - entschuldigt, aber damit
> habe ich mich noch nicht so recht beschäftigt.
> Wo ist da das Problem bzw. was ist der Vorteil, den anderen Server zu
> verwenden?


der Tileserver auf OSM.org ist ein Service für die Mapper und eine
Demo, was in unseren Daten steckt. Die Nutzungsbedingungen sind hier:
http://wiki.openstreetmap.org/wiki/Tile_usage_policy

Für private Seiten mit wenigen Zugriffen kann man den Dienst nutzen,
aber wenn man eine professionelle Seite mit vielen Zugriffen betreibt,
darf man das nicht mehr. Dann sollte man entweder einen Tileserver von
Dritten benutzen (mapquest erlaubt z.B. die Nutzung, daher der Hinweis
darauf), oder einen eigenen Server aufsetzen.


> Und Mapquest ist doch ein kommerzieller Dienst, wenn ich das richtig sehe?


die Nutzung ist kostenlos, betrieben wird das von AOL.

Gruß Martin

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

Re: [Talk-de] Welche MaxHeight wird angegeben ?

[M∡rtin Koppenhoefer]

Am 29. Juli 2011 11:16 schrieb Wolfgang :
>> ja klar, aber wenn sein Fahrzeug schmaler ist als 4 m (2,50m ist AFAIK
>> die Maxbreite für reguläre Fahrzeuge) dann würde er vielleicht noch
>> durchkommen, aber laut Daten schon nicht mehr.
> Er soll sich aber nicht ins Guiness-Buch der Rekorde für das höchste Fahrzeug,
> dass jemals diese Unterführung passiert hat, qualifizieren, sondern da heil
> und sicher durchkommen. Deshalb in ausreichendem Abstand von der Mitte mit
> etwas Sicherheit (*abrunden*) messen. Wenn die Durchfahrtshöhe auf 4m Breite
> ausreicht, wird der Fahrer mit dem 2,50m breiten Fahrzeug durchkommen, es sei
> denn die Durchfahrt liegt in einer scharfen Kurve.


M.E. ist 4m Breite zu viel Toleranz da normale Fahrzeuge nicht mehr
als 250cm haben dürfen und tatsächlich auch noch etwas weniger haben.

Gruß Martin

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

[Talk-de] Altitude im Wiki

[M∡rtin Koppenhoefer]

Da diese Seiten wohl auf deutschsprachige Initiative entstanden sind,
melde ich mich mal hier.

Brauchen wir diese Seiten im Wiki?
http://wiki.openstreetmap.org/wiki/Altitude

m.E. ist "alt" für Höhendaten auf der Oberfläche nicht sinnvoll, es
gibt ja bereits "ele" dafür.

Was haltet Ihr davon, das jeweils in ele zu ändern?

"alt" ist praktisch nicht in Gebrauch:
http://taginfo.openstreetmap.org/keys/alt#values
und darüberhinaus bietet es Verwechslungspotential mit "alt" für alternative.
s.z.B. hier:
http://taginfo.openstreetmap.org/keys/ref%3Aalt#values

Gruß Martin

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

Re: [Talk-de] Welche MaxHeight wird angegeben ?

[M∡rtin Koppenhoefer]

Am 28. Juli 2011 08:03 schrieb Georg Feddern :
> um diese Fälle abzudecken zu können, müsste man tatsächlich eine math.
> Formel angeben


hatte ich ja geschrieben: Bogenform. Üblicherweise wird es ein
Korbbogen (mit 3 oder 5 Einsatzpunkten) oder alte Bögen evtl. Spitz-
oder Rundbogen  sein. Damit kann man in Verbindung mit der
Scheitelhöhe und der Basisbreite schon mal ganz ordentlich abschätzen,
ob man durchpasst oder nicht.
Andere Bogenformen auch hier: http://de.wikipedia.org/wiki/Bogen_(Architektur)


 - oder die maxheight in Abstufungen zur gegeben Breite
> angeben
> z. B. maxheight:forWidth2=x, maxheight:forWidth2.5=y, maxheight:forWidth3=y
> usw.
> Wenn man sich dann noch auf ein einheitliches Format einigen könnte, dann
> könnte man das evtl. sogar auswerten.


ja, die Auswertung dieser Syntax wäre schön einfach. Maxheight ist
dann allerdings, sofern es keine Schilder gibt, nicht der richtige
Tag, da es die rechtliche Zulässigkeit und nicht die tatsächliche
Geometrie beschreibt.

Gruß Martin

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

Re: [Talk-de] Welche MaxHeight wird angegeben ?

[M∡rtin Koppenhoefer]

Am 28. Juli 2011 00:33 schrieb Wolfgang :
> Wenn nichts dran steht und die Höhe 4m unterschreitet, ca. 2m von der Mitte
> auf beiden Seiten messen und den niedrigeren Wert abgerundet übernehmen.
>
> Der Fahrer eines entsprechenden Fahrzeuges sollte mit der Problematik vertraut
> sein und da dann heil durchkommen.


ja klar, aber wenn sein Fahrzeug schmaler ist als 4 m (2,50m ist AFAIK
die Maxbreite für reguläre Fahrzeuge) dann würde er vielleicht noch
durchkommen, aber laut Daten schon nicht mehr.

Gru0 Martin

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

Re: [Talk-de] Prozess auf Heimserver starten

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 20:37 schrieb Frederik Ramm :
> nohup meinprogramm.sh&
>
> oder Du installierst Dir "screen", das ist etwas komfortabler, weil Du da
> beim Wieder-Einloggen wieder die gleiche Shell-Sitzung zurueckholen kannst
> und so direkt siehst, was das Programm evtl. ausgegeben hat.


nachdem man sich durch die 2500 Zeilen manpage gelesen hat ;-)

Man kann übrigens auch bereits laufende Programme anhalten und in den
Hintergrund schicken:
mit strg+z hält man das laufende Programm an
mit bg 1 (oder einer anderen Nummer, je nach Ausgabe von jobs) kann
man den Befehl dann in den Hintergrund schicken, mit fg 1 wieder
hervorholen.
jobs zeigt die Befehle mit Nummern und Status (angehalten/fertig/etc) an.

Gruß Martin

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

Re: [Talk-de] JOSM: gibt es ein Werkzeug - Flächen zu prüfen

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 14:26 schrieb fx99 :
> sieht für mich auch gut aus.
> Hab den Weg mal in ein MP reingepackt, auch da heißt es geschlossen!


JOSM kann seit kurzem auch darstellen, ob ein Weg geschlossen ist
(sieht man am Icon z.B. im Selection-fenster)

Gruß Martin

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

Re: [Talk-de] Grundriss der Kathedrale zu Budweis (Budějovice)

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 16:28 schrieb RalfGesellensetter :

> In der Karte fiel mir auf, was die Daten bestätigen:
> http://www.openstreetmap.org/api/0.6/map?bbox=14.4644844,48.964659,14.4844853,48.98466279995

bitte keine API-Links posten, vor allem wenn es nicht nötig ist, sonst
holen sich zig Leute von der ML diesen viele MB großen Bereich unnötig
von der API. Lieber auf Tiles verlinken:
http://www.openstreetmap.org/?bbox=14.4644844,48.964659,14.4844854,48.9846628&layers=M

oder auf ein einzelnes Objekt:
http://www.openstreetmap.org/browse/way/49532596

Gruß Martin

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

Re: [Talk-de] Welche MaxHeight wird angegeben ?

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 16:22 schrieb RalfGesellensetter :
> Fazit: Im Zweifel die offiziell angegebene (wie bei maxspeed auch)
> - nicht die physikalisch mögliche. Sonst: Toleranz einplanen.


ja, maxheight ist die legale Beschränkung, für die tatsächlichen Maße
gibt es maxheight:physical
http://wiki.openstreetmap.org/wiki/Key:maxheight:physical

oder auf dem Durchgang getaggt height (für die vertikale Ausdehnung
des Features)

Gruß Martin

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

Re: [Talk-de] Welche MaxHeight wird angegeben ?

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 15:03 schrieb Jan Tappenbeck :
> wenn man eine Bogendurchfahrt hat, dann ist am Rand die Durchfahrtshöhe
> anders als in der Mitte (idr).
>
> Wie würdet Ihr dieses bei maxheight anschreiben ?


Du könntest den mittleren Wert als maxheight an den highway setzen und
an der niedrigen Stelle einen Node setzen mit dem maxheight der
seitlichen Höhe (ggf. für die Durchfahrt auch einen Way zeichnen, der
die 3 nodes verbindet, z.B. barrier=entrance, bzw. wenn Du die Mauer
schon hast dann den Durchfahrtsteil absplitten und mit
barrier=entrance taggen).

Alternativ müsste man ein Proposal machen, wie man das alles
parametrisch (mit Breite, Bogenform und mittlerer sowie seitlicher
Höhe) an einen Node hängen kann.

Beides wird natürlich derzeit AFAIK nirgends ausgewertet.

Gruß Martin

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

Re: [Talk-de] 3x3D // Re: 3D-Objekte aus Umgebungsbildern

[M∡rtin Koppenhoefer]

Am 27. Juli 2011 02:01 schrieb RalfGesellensetter :
> Am Dienstag, 26. Juli 2011 schrieb Markus:
>> Ja, Martin Koppenhöfer hat sich dazu viele Gedanken  und ein Datenschema
>> gemacht.
>
> Danke, Martin, Walter und Markus!


bevor hier bei manchen ein falscher Eindruck entsteht: es gibt
unzählige Beiträge zum Thema 3D und OSM, es gibt sogar einen Viewer
von der Uni Heidelberg um OSM in 3D anzusehen:
http://wiki.openstreetmap.org/wiki/DE:OSM-3D Mein Verdienst ist das
alles nicht ;-)

Startpunkte für eine Recherche könnten z.B. die Seiten in der 3D-Kategorie sein:
http://wiki.openstreetmap.org/wiki/Category:3D

Gruß Martin

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

Re: [Talk-de] 3x3D // Re: 3D-Objekte aus Umgebungsbildern

[M∡rtin Koppenhoefer]

Am 26. Juli 2011 20:50 schrieb Markus :
>> Ich dachte dabei an Tags wie Farbe der Wand/des Dachs, Dachform, Höhe
>> bei Gebäuden, deren Umrisse bereits erfasst sind.
>> Ist so etwas schon einmal diskutiert worden?
>
> Ja, Martin Koppenhöfer hat sich dazu viele Gedanken  und ein Datenschema
> gemacht.


Die Initiative ging von Marek aus, der verschiedene Baumtypen zur
parametrischen Modellierung sowie Brückentypen vorgeschlagen hat. Im
Bereich building und Unterseiten (und proposals) gibt es im Wiki auch
schon ein paar Konzepte, wobei das nicht alles gleich gut
funktioniert.

Einen Anfang für das Konzept einer parallelen und eng verknüpften
3D-Datenbank gibt es hier, ist aber noch eine frühe draft-Phase:
http://wiki.openstreetmap.org/wiki/OSM-4D

Gruß Martin

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

Re: [Talk-de] Naturschutzgebiet

[M∡rtin Koppenhoefer]

Am 25. Juli 2011 20:09 schrieb Michael Bemmerl :
> Markus schrieb:
>> Wie schreibt man "Betreten verboten" in die DB?
> Wie wär's mit access=no?


Braucht man das? Den genauen Status geben doch die Tags für das
Naturschutzgebiet schon an, access=no ist so unscharf, dass man es
hier m.E. besser weglässt.

Gruß Martin

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

Re: [Talk-de] Naturschutzgebiet

[M∡rtin Koppenhoefer]

Am 26. Juli 2011 15:02 schrieb tshrub :
>
>> # Nationalparks (class 2) mit ?? = nationalpark (weiß grad nicht)
>
> falsch!
> das kann man nicht _ergänzend_ nehmen, da nicht 2x
> ein Schlüssel (boundary) verwendet werden darf.


man kann aber problemlos 2 multipolygon-relationen erstellen.

Gruß Martin

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

Re: [Talk-de] Mappen per Bing?!

[M∡rtin Koppenhoefer]

Am 26. Juli 2011 16:31 schrieb Bernd Wurst :
> Am 26.07.2011 14:37, schrieb M∡rtin Koppenhoefer:
>> auch bei Straßen in Wohngebieten und bei allen anderen Straßen kann
>> man die für die Nutzer wichtigen Informationen (selbst die Gewissheit
>> ihrer Existenz) aus (in der Regel nicht topaktuellen) Luftbildern oft
>> nicht ablesen, daher ist road auch besser für solche Straßen, die man
>> in der Realität nicht kennt. Ich hatte durchaus schon den Fall, dass
>> - eine Straße durch Erdbeben nicht mehr passierbar war,
>> - sich in einem Einbahnstraßenlabyrinth befand wo man ohne diese
>> Einbahnstraßenregelungen mit der reinen Straßeninfo als Autofahrer
>> wenig anfängt
>> - eine Straße nur für Anlieger passierbar war
>> - eine Straße nur für Fußgänger passierbar war (Poller)
>
> Und du bist dir sicher, dass da *NICHTS* (verwertbares) einzutragen
> wirklich grundsätzlich besser ist?


Straßen, die es nur noch auf den Luftbildern aber nicht mehr in der
Realität gibt kann man in keinem Fall ohne aktuelle Ortskenntnis
finden ;-)

Ich sehe das ja auch so, dass die erkennbaren Informationen aus den
Luftbildern genommen werden sollten. Du hattest geschrieben,
highway=road würde von vielen Routern nicht berücksichtigt. Meine
Antwort darauf ist, dass das so auch gut ist. Wenn z.B. einzelne
residential Straßen fehlen und man die per road aus dem Luftbild
nachträgt, dann ist es m.E. besser, man routet Autos erstmal nicht
über diese Straßen (sondern über den Rest) bis jemand geprüft hat, wie
die Lage dort vor Ort ist. Wenn man die gleich als residential
einträgt geht sie erstmal unter, wenn nicht jemand gezielt nach
Straßen ohne Namen fahndet.

Wenn natürlich alles fehlt (in Deutschland unwahrscheinlich) obwohl
brauchbare Luftbilder vorliegen, dann ist eine vermutete motorway bis
tertiary sicherlich viel besser als gar nichts (oder eine road, die
ignoriert wird), weil man da ziemlich sicher davon ausgehen kann, dass
sie befahrbar ist.

Gruß Martin

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

Re: [Talk-de] Mappen per Bing?!

[M∡rtin Koppenhoefer]

Am 26. Juli 2011 08:39 schrieb Bernd Wurst :
> Bei (klar zu erkennenden) Feldwegen stellt sich natürlich die Sinnfrage
> schon, ob man das vom Luftbild einzeichnen sollte. Schließlich kann man
> die für Feldweg-Nutzer wichtigen Informationen aus den Luftbildern oft
> nicht ausreichend ablesen.


+1
auch bei Straßen in Wohngebieten und bei allen anderen Straßen kann
man die für die Nutzer wichtigen Informationen (selbst die Gewissheit
ihrer Existenz) aus (in der Regel nicht topaktuellen) Luftbildern oft
nicht ablesen, daher ist road auch besser für solche Straßen, die man
in der Realität nicht kennt. Ich hatte durchaus schon den Fall, dass
- eine Straße durch Erdbeben nicht mehr passierbar war,
- sich in einem Einbahnstraßenlabyrinth befand wo man ohne diese
Einbahnstraßenregelungen mit der reinen Straßeninfo als Autofahrer
wenig anfängt
- eine Straße nur für Anlieger passierbar war
- eine Straße nur für Fußgänger passierbar war (Poller)

Gruß Martin

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

Re: [Talk-de] Naturschutzgebiet

[M∡rtin Koppenhoefer]

Am 26. Juli 2011 14:10 schrieb Falk Zscheile :
> Was in einem bestimmten Naturschutzgebiet erlaubt bzw. verboten ist
> entnimmt man am Besten der Verordnung, welche das Naturschutzgebiet
> festsetzt.


+1


> Pauschale Aussagen sind daher problematisch. Aber ein Blick
> ins Gesetz hilft weiter hier weiter:
>
> § 23 Naturschutzgebiete
> (1) Naturschutzgebiete sind [...]
> (2) Alle Handlungen, die zu einer Zerstörung, Beschädigung oder
> Veränderung des Naturschutzgebiets oder seiner Bestandteile oder zu
> einer nachhaltigen Störung führen können, sind nach Maßgabe näherer
> Bestimmungen verboten. Soweit es der Schutzzweck erlaubt, können
> Naturschutzgebiete der Allgemeinheit zugänglich gemacht werden.
>
> § 23 Abs. 2 Satz 2 BNatSchG geht also davon aus, dass ein Betreten des
> Naturschutzgebietes grundsätzlich verboten ist (access=no) und ein
> Betreten explizit erlaubt werden muss.


wieso? Ist das Betreten von vornherein eine "nachhaltige Störung"?
Nachhaltig wäre die Störung doch nur, wenn man beim Betreten etwas
stört oder beschädigt und diese Störung auch noch anhält, nachdem man
das Gebiet bereits wieder verlassen hat.

Gruß Martin

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

Re: [Talk-de] Mappen per Bing?!

[M∡rtin Koppenhoefer]

Am 25. Juli 2011 14:49 schrieb Frederik Granna :

> Ok, dann bin ich jetzt schlauer :) Ist es bei Potlatch2 möglich Tags für den
> Changeset zu vergeben?


Für Changesets werden nicht tags sondern jeweils ein Kommentar
(Comment) vergeben (Randbemerkung: es "gibt" wohl auch Flags, d.h. für
automatische Edits soll man als Bot-Flag bot=yes setzen). Das geht in
Potlatch wohl grundsätzlich auch (wie die meisten aktiven Mapper nutze
ich JOSM), aber wie genau müsste jemand anders erklären. In JOSM setzt
man den Kommentar beim Hochladen des Edits, wobei man auch bisherige
Kommentare auswählen kann (auch per automatischem Vervollständigen
wird man unterstützt) bzw. von diesen ausgehend einen ähnlichen
Kommentar setzen kann.

Gruß Martin

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

Re: [Talk-de] Mappen per Bing?!

[M∡rtin Koppenhoefer]

Am 25. Juli 2011 14:28 schrieb Frederik Granna :

> Ich meinte eher diese History:
> http://www.openstreetmap.org/browse/way/22965249/history   .


genau die zeigt ja den Changeset-Kommentar an, wenn er denn gesetzt
wird (wie Du in Deinem Beispiel z.B. an der Version 12 sehen kannst).
Je genauer man dort einträgt, was man weshalb gemacht hat, um so mehr
wird auch dem nächsten Mapper klar, was gelaufen ist. Wenn man wie
sysrun einfach nichts schreibt, ist das halt wenig hilfreich. Ein
Beispiel könnte z.B. sein: "D-Brandenburg, Tracing roads from Bing, no
local knowledge" oder so.

Gruß Martin

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

Re: [Talk-de] Mappen per Bing?!

[M∡rtin Koppenhoefer]

Am 25. Juli 2011 13:29 schrieb Frederik Granna :
> ich wollte mal Fragen was so Best-Practice beim Mappen per Bing-Luftbilder
> ist.
>
> Ich habe gestern einige Gegenden in Brandenburg/Sachsen-Anhalt gefunden die
> recht "ungemappt" sind und dort einige Straßen eingetragen.
> Bei einigen Straßen kann ich per Bing leider keine richtige Klassifizierung
> vornehmen. Ich habe da dann "unclassified" eingetragen.


Dafür gibt es highway=road. "Unclassified" ist bereits eine
Klassifizierung (ist zugegebenermaßen etwas verwirrend am Anfang), und
zwar unterhalb "tertiary", daher sollte man das nicht für Straßen
verwenden, die man noch klassifizieren muss. Bitte wenn es geht,
ändere das in "road".



> Ist es hier dann auch sinnvoll noch "fixme=*" zu setzen?


bei "road" ist "fixme" wohl schon implizit, aber schaden kann es m.E.
auch nicht.


> Bei jedem meiner Einträge habe ich "source=Bing" gesetzt.


kann man machen, wobei viele Mapper auch sagen, dass solche
Quellangaben besser im Changeset-Kommentar aufgehoben seien, also
direkt dem Edit zugewiesen werden, und nicht dem Map-Objekt.


Gruß Martin

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

Re: [Talk-de] Insel im Meer - Inselgruppe

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 22:05 schrieb Dimitri Junker :
> Hallo,
>
>>man könnte das auch mit einer Multipolygon-Relation machen (
>
> meiner Meinung nach wäre das falsch, die Grenze einer Inselgruppe ist nicht
> die Summe der Küstenlinien. Meiner Meinung nach gehört das Meer auch dazu.
> Man müßte also entweder eine eigene Begrenzung einzeichnen, was aber keinen
> Sinn macht, da die Grenze nicht so genau definiert sein dürfte, oder man
> faßt sie einfach per Relation zu einer Gruppe zusammen, aber eben nicht als
> MP. Man könnte sich auch an den Hoheitsgewässern orientieren, aber so
> einfach ist das auch nicht.


ja, wenn das Meer auch dazugehören soll ist man bei einer ähnlichen
Situation wie bei anderen geographischen Features auch: es gibt dafür
keine geeignete Methode bisher. Bei einer alten Diskussion ist soweit
ich mich erinnere die Idee herausgekommen, eine Relation mit mehreren
(aber durchaus nicht allzu vielen) Nodes (oder auch ways) zu machen,
wo man sagen kann: dieses Objekt gehört noch dazu, dieses nicht mehr
(über Rollen). Mit einer konvexen Hülle kann man dann ungefähr das
Gebiet bestimmen.

Gruß Martin

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

Re: [Talk-de] Verzeichnisstruktur für Metatiles

[M∡rtin Koppenhoefer]

Am 23. Juli 2011 11:39 schrieb Kolossos :
> Hintergrund:
> Mein Ziel ist es täglich selber optimierte Listen für tirex-batch zu
> erzeugen, dort rein sollen alle Dateien in die in letzter Zeit auch lesend
> zugegriffen wurde, die aber ein gewisses Alter haben. Die Liste will ich
> räumlich sortieren (Z-Kurve) und die Liste soll alle verschiedenen Styles
> und Zoomlevel enthalten


kennst Du tirex-tiledir-check ? Damit kannst Du Listen der vorhandenen
Tiles erstellen und als csv speichern.

Gruß Martin

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

Re: [Talk-de] Place

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 20:05 schrieb Chris66 :
> Am 24.07.2011 19:55, schrieb M∡rtin Koppenhoefer:
>
>>> Doppelte Erfassung sollte vermieden werden.
>> die Erfassung mit Node und Polygon nicht "doppelt",
>> sofern man das über eine Relation zusammenbringt.
> Welchen types ?


egal, das ist von Relationentyp völlig unabhängig. Zugegebenermaßen
ist für MP-Relation derzeit kein label-node vorgesehen, aber das
könnte man ja ändern, ansonsten könnte man z.B. eine place-relation
erfinden, die site-relation passt definitionsgemäß m.E. nicht, hätte
aber einen label-Node in ihrer Definition.

Gruß Martin

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

Re: [Talk-de] Place

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 19:51 schrieb Chris66 :
> Am 24.07.2011 13:38, schrieb ludwich:
> Doppelte Erfassung sollte vermieden werden.


wie ausgeführt ist die Erfassung mit Node und Polygon nicht "doppelt",
sofern man das über eine Relation zusammenbringt.


> Da die Flächenerfassung einer Stadt meist bereits durch die admin-Grenze
> gegeben ist, ist es IMHO ausreichend das (Stadt-)Zentrum als
> place-Node zu mappen.


-1, admin ist die administrative Grenze (d.h. alles, was dort
verwaltet wird, eingeschlossen Wald und Flur), place bezeichnet den
Ort (d.h. ohne Wald und Flur). Das sind 2 verschiedene Dinge.

Gruß Martin

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

Re: [Talk-de] Insel im Meer - Inselgruppe

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 18:26 schrieb Chris66 :
>> man könnte das auch mit einer Multipolygon-Relation machen
>> (type=multipolygon, place=archipelago)
>
> So wird es ja derzeit oft gemacht.
> Ostfriesische Inseln:
> 
>
> Ist ok[1], solange die Inseln klein sind und die Coastline jeweils nur
> aus *einem* Way besteht.
> 
> (Die Relation lädt bei mir jetzt schon seit 5 Minuten)


das liegt daran, dass die db sich alle Members zusammensuchen muss,
und würde sich mit einem anderen Relationstyp auch nicht ändern.


> [1] Wobei MPs eigentlich dazu gedacht sind Polygone mit Löchern zu
> definieren, nicht um Objekte zusammenzufassen.


Das ist ein Mythos. Multipolygone sind Konstrukte, um aus ways
Polygone zu definieren. Die Mindestanforderung ist ein outer way.
"Löcher" braucht man nicht, wenn man sie hat braucht man allerdings
Multipolygone. Für das o.g. Beispiel Inselgruppe kann man mit einer
Multipolygonrelation ein Objekt (die Inselgruppe) konstruieren, das
aus mehreren für sich geschlossenen Polygonen besteht, und diesem dann
die entsprechenden Tags zuweisen (Inselgruppe, z.B.
natural=archipelago, name=foo)

Gruß Martin

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

Re: [Talk-de] Routen Editieren

[M∡rtin Koppenhoefer]

mit rel2gpx.pl kann man Routen-relationen aus OSM in ein gpx wandeln.

Gruß Martin

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

Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 09:09 schrieb Walter Nordmann :
> access=private, wie in der Dornbreite 247ff, bitte nur, wenn da wirklich ein
> Schild "privat" steht.


"privat-Durchgang verboten" müsste da m.E. stehen (wenn da nur
"Privatstraße" steht, dann heisst das noch nichts für den access, der
kann durchaus trotzdem rechtlich garantiert sein). Wobei eine
Einfriedung (Zaun etc) auch ohne Schild und auch wenn das Tor offen
steht eindeutig und verbindlich signalisiert, dass es sich um einen
privaten Bereich handelt.

Gruß Martin

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

Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 06:46 schrieb Thomas Reincke :
> Ich finde, dass alles
> - was ein Straßenschild hat
> - oder nicht nur über einen abgesenkten Bordstein angebunden ist
>
> highway=residental bzw. living_street ist


kleinere / schmale Wege sind bei mir highway=service, service=alley
(öffentliche Wege) bzw.
Zufahrten service=driveway (und ggf. access=private / permissive /
destination), weitere Service-Unterkategorien findet man im Wiki.

Living_street sind dagegen üblicherweise über einen abgesenkten
Bordstein angebunden. Es handelt sich dabei (in D) ausschließlich um
entsprechend gekennzeichnete verkehrsberuhigte Bereiche.

Gruß Martin

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

Re: [Talk-de] Insel im Meer - Inselgruppe

[M∡rtin Koppenhoefer]

2011/7/23 Dimitri Junker :
> was hältst Du von:
> 


finde ich im Ansatz interessant, kann man aber im Detail noch diskuttieren.
Ich würde auf der Ebene region_type nicht differenzieren zwischen
verschiedenen topographischen Grenzen (mountain_range, valley,
maritime), sondern das nur topographical nennen (und da gehören
Inselgruppen mit dazu m.E.). Insgesamt gibt es aber gerade bei diesen
topographischen Gebieten das Problem, dass man sie nicht besonders
geeignet sind für unsere Datenstruktur. Einen genauen Way zu zeichnen,
der die Grenze der schwäbischen Alb markiert, geht nicht und wäre auch
als Näherung nicht geeignet. Diskussion hierzu gibt es im
Talk-de-Archiv.


Für andere Dinge funktionierte es dagegen gut:
politische Grenzen
kirchliche Verwaltungsgrenzen
Wahlbezirke (wozu sollte man die in OSM haben?)
Postleitzahlen-Grenzen (sofern es geschlossene Gebiete sind)
Telefon-Vorwahl/Vermittlungs-Bereiche (sofern es das heutzutage noch so gibt)

nur dass diese Probleme auch bereits anders gelöst / definiert sind
(key:boundary).

Katastergrenzen wie Gemarkung, Flur und Flurstück könnte man damit
machen, ist allerdings schwierig, verwendbare Quellen zu bekommen, und
auch nur bedingt geeignet für OSM (da es keine Quellen gibt, und wenn
es die Quellen gäbe, könnte man sie auch mit OSM kombinieren ohne
alles in die DB von OSM zu importieren). Evtl. sind diese auch
administrativ und brauchen gar keine eigene Rubrik?

Bei sowas wie Telefon oder Post funktioniert das Proposal so wie im
WIki auch nur für einen Provider, bei mehreren Unternehmen mit jew.
eigener Struktur müsste man das ggf. auch anders machen.

Der Verlust von admin_level ist nicht nur ein Vorteil wie im Proposal
angepriesen, es ist auch ein Nachteil, weil nicht mehr klar ist,
welche Hierarchie-ebenen der einzelnen Staaten zueinander vage
korrispondieren.

Habe das Proposal nur überflogen, aber es ergeben sich bereits massig
Anmerkungen und Fragen. Wenn ein Proposal mit potentiell so
einschneidenden und weitreichenden Auswirkungen 2 Jahre lang praktisch
still steht, dann müsste man als allererstes mal einen Realitätscheck
machen, was alles angepasst werden müsste, um der letzten Entwicklung
Rechnung zu tragen.

Gruß Martin

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

Re: [Talk-de] Insel im Meer - Inselgruppe

[M∡rtin Koppenhoefer]

Am 23. Juli 2011 22:38 schrieb Chris66 :
> Schöner wär's in der Tat IMHO, wenn man pro Insel eine Relation hätte
> (oder schon als Boundary-MP hat),


oder einfach einen geschlossenen way?


> und diese in eine Sammelrelation (type=collection, place=archipelago
> oder so) packen täte.


man könnte das auch mit einer Multipolygon-Relation machen
(type=multipolygon, place=archipelago)

Gruß Martin

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

Re: [Talk-de] Place

[M∡rtin Koppenhoefer]

Am 24. Juli 2011 13:38 schrieb ludwich :
> ich habe gerade die Frage ob das Tag "PLACE =" besser als
>
> Punkt oder
> Fläche oder
> Punk und Fläche
>
> verwendet werden sollte.
>
> Ich habe da so mitgenommen das die "erste Erfassungswelle" die Punktversion 
> genutzt hat, nun sind viele Orte mit ihrer Landuse=Residential-Fläche erfasst 
> das heißt, die Info der Punktversion könnte in die Fläche wandern und dies 
> ersetzen.


place bezeichnet bei Orten AFAIK den im Zusammenhang bebauten Bereich
(Siedlung). Das wird eher selten genau mit landuse=residential
übereinstimmen (da es auch div. andere landuses in Siedlungen gibt).


> Andererseits bietet die Punktversion den Vorteil, dass der User den Ortskern 
> manuell zuordnet - bei einer Flächeninformation kann dieser nur errechnet 
> werden.


+1, beim Errechnen aus der Polygon-Geometrie verliert man
Informationen verglichen mit einem manuell platzierten Node.


> Meiner Meinung nach sollte man eine Verknüpfung der beiden Merkmale nutzen. 
> So können Renderer und Router diese Informationen zum Druck sowie für 
> Verzeichnisse/Indexe sauber ableiten.


+1, wird bereits getan: dazu den Node in die Relation der Fläche
übernehmen und mit der Rolle "label" versehen. (Ist wohl nicht 100%
etabliert und erfordert eine Relation, die man sonst oft nicht
bräuchte).


> Mir ist aufgefallen, das Mapnik bei Punkt und Flächeninfo zwei Ortsnamen 
> rendert.


Je nachdem, wie die Informationen in der db sind, ist das ggf. eine
vorübergehende Unzulänglichkeit der Mapnik Renderregeln.


> NAVIT scheint nur die Punktinformation für die Ortsnamen heranzuziehen.


s.mapnik


> Das Wiki lässt beide Varianten zu, es bleibt also ein durcheinander das die 
> Komplexität erhöht.


klar sind beide Varianten zulässig. Bisher werden von den meisten
Applikationen vor allem Nodes ausgewertet, Flächen haben aber einen
Mehrwert, da man bei Nodes die Ausdehnung nur schätzen kann. Je mehr
die Form von einem Kreis abweicht, um so mehr hilft eine Fläche bei
der Bestimmung der realen Ausdehnung.

Gruß Martin

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

Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen

[M∡rtin Koppenhoefer]

Am 23. Juli 2011 19:13 schrieb Jan Tappenbeck :
>
>
>  HI !
>
> bei knapp werdendem Bauland ist es teilweise in Mode in zweiter Reihe zu
> bauen. Diese Grundstücke werden dann mit Straßen erschlossen.
>
> Stellt sich die Frage - ab wann sind diese Straße in OSM darzustellen ???
>
> Meine Meinung ist das bis zwei Häuser dieses nicht erforderlich ist -
> dannach wie in [1] sollte das erfolgen.
>
> Wie ist Eure Meiung diesbezüglich ???


alle Straßen erfassen. Wieso auch nicht? Wieso sollten Straßen, die
weniger als 3 Häuser erschließen nicht erfasst werden? Ich erfasse
auch Straßen, die gar keine Häuser erschließen.

Gruß Martin

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

Re: [Talk-de] Landuse im Autobahn-Kreuz

[M∡rtin Koppenhoefer]

Am 22. Juli 2011 11:42 schrieb Robert S. :
> Aber der ganze landuse/landcover-Bereich bräuchte sowieso mal sowas wie ein
> Gesamtkonzept - und nicht nur immer ergänzende Proposals.

http://wiki.openstreetmap.org/wiki/Proposed_features/landcover

Gruß Martin

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

Re: [Talk-de] Insel im Meer

[M∡rtin Koppenhoefer]

Am 23. Juli 2011 17:26 schrieb Markus :
> @ Frederik:
> Die Punkte durch Küstenlinen zu ersetzen erscheint mir sinnvoll.


was Punkte und Polygone angeht, ist die Lage nicht ganz so
offensichtlich, wie sie vielleicht scheint. Bei den Bundesländern
bspw. scheint es so, als ob sich beides durchgesetzt hat. Der Node
wird in die Relation als Rolle label aufgenommen. Auch bei anderen
Places wie Städten macht es wohl doch Sinn, auch einen Node zu haben,
da sich nur aus dem Polygon dass
(politische/topografische/strukturelle) "Zentrum" nicht unbedingt
ergibt.


> Du schreibst: "die Kuestenlinie wird beim Standard-Import
> ja rausgeworfen". Was bedeutet das? wird eine Küstenlinie an sich nicht
> gerendert? nur wenn da noch weitere Attribute dranhängen? warum?


gemeint ist, dass osm2pgsql im standard-Stil natural=coastline nicht
importiert (wenn da nicht noch was dran hängt, was doch noch zum
Import führt). Das deshalb, weil sie nicht gebraucht werden. Die
Küstenlinien (bzw. eigentlich die Landmasse) rendert mapnik mit Hilfe
von Shapefiles, die vorher schon aus den OSM-Daten generiert werden
(so wird besser sichergestellt, dass die Polygone geschlossen sind und
das Land nicht "überflutet" wird).
Seit einiger Zeit ist allerdings eine Option eingebaut, um die
Küstenlinien doch zu importieren.


> Wenn der Renderer flächengrössen-abhängige Regeln kann, dann wäre das m.E.
> ein erster Ansatz, Inselnamen klassifiziert zu rendern.


das geschieht bereits.


> Wobei dann noch die Problematik mit der Dominaz zu lösen wäre:
> Mit Dominanz meine ich:
> - geografische Bedeutung bezüglich der Umgebung
> - Entfernung zwischen Inseln bzw. zwischen Insel und Küstenstädten
> - Bedeutung (politisch, wirtschaftlich, etc) in Bezug zu anderen Orten


Diese "Dominanz" ist (noch?) nicht klar, d.h. um das zu machen
bräuchte man zusätzlich zu den bisher weitgehend fehlenden Daten auch
erstmal eine Festlegung, was man wie werten und gewichten will, vor
allem erstmal welche Indikatoren überhaupt berücksichtigt werden
sollen. Als Anhaltspunkt und einigermaßen verbreitet könnte man die
Einwohnerzahlen nehmen, ggf. in Kombination mit der Fläche und solchen
Dingen wie ob es sich um eine Verwaltungszentrum / Hauptstadt handelt.

Gruß Martin

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

Re: [Talk-de] Eigene Karten rendern

[M∡rtin Koppenhoefer]

Am 20. Juli 2011 12:04 schrieb Andreas Tille :
> Wenn irgendwer derjenige ist, der das Privileg hat, seine Karte als
> Default auf osm.org dargestellt zu bekommen, dann muß er damit rechnen,
> daß es Leute gibt, die Fehler finden und den Wunsch äußern, daß sie
> korrigiert werden.  Für sowas sollte eigentlich auch ein Bugtracking
> System her, in dem das Problem und die Diskussion dazu geloggt werden.


Es ist ja soweit ich weiss grundsätzlich auch durchaus erwünscht, dass
man konstruktive Verbesserungsvorschläge ins trac einstellt. Die URL
ist
trac.openstreetmap.org --- für die Mapnik-Render-Regeln muss man als
Komponente "mapnik" auswählen. Klar ist aber auch, dass es die
Regelmaintainer nie allen gleichzeitig Recht machen können, und von
daher nicht jeder Vorschlag auch umgesetzt werden wird.

Gruß Martin

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

Re: [Talk-de] eBay Verkauf Seekarte ...

[M∡rtin Koppenhoefer]

Am 19. Juli 2011 07:51 schrieb NopMap :
> Bedeutung der Lizenz hattest. Es ist völlig legitim, kostenlose OSM-Karten
> zu einem unverschämten Wucherpreis anzubieten, wenn man Dumme findet, die
> sie kaufen. :-)


die Karten zu einem "unverschämten Wucherpreis" anzubieten halte ich
nicht für "legitim", legal und lizenzkonform ist es allerdings. Auf
das oben verlinkte Angebot trifft "Wucherpreis" m.E. aber überhaupt
nicht zu, die Karte wird inkl. Stick für 1,-EUR und 2,99 Versand
angeboten, was daran Wucher sein soll erschließt sich mir nicht.

Gruß Martin

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

Re: [Talk-de] Insel im Meer

[M∡rtin Koppenhoefer]

Am 19. Juli 2011 00:40 schrieb Markus :
>> Eine Verfeinerung wäre abwärtskompatibel durch ein Zusatztag
>> zB. island:level=1-10 oder so möglich.


-1


> Besser fände ich eine Klassifizierung nach gewichteten Messgrössen:
> - Fläche


gibt es schon, man muss dazu die Insel als Fläche eintragen und nicht
als node wie man es vielfach noch vorfindet


> - Einwohnerzahl


gibt es schon: population


> - jährlicher Personenverkehr (Flugzeug, Schiff, Bahn)


ist das eine Inseleigenschaft oder eine Eigenschaft der jeweiligen
Straße/Schiene/Flughafen? M.E. letzteres. Wer so was auswerten will,
kann sich das ja zusammensuchen, aber m.E. fehlen uns dazu überwiegend
Quellen.


> - jährlicher Güterverkehr (Flugzeug, Schiff, Bahn)


dito, s.o.


> - Dominanz


was meinst Du damit? Auf die Fläche bezogen? Auf die Höhe über Meer?
Auf die Einwohnerzahl? Auf das Durchschnittseinkommen? Auf das
Steueraufkommen? Auf die Geburtenrate? Auf die Abwasserkosten?


> - Bruttosozialprodukt


gibt es nur bei unabhängigen Inseln, nicht bei solchen, die Teil einer
größeren Volkswirtschaft sind.

Gruß Martin

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

Re: [Talk-de] Sommeraufgabe 2011

[M∡rtin Koppenhoefer]

Am 19. Juli 2011 10:48 schrieb Chris66 :
> Also, es gibt ein Gebäude beschildert mit Kennedybollevard 302-654 (das
> heisst die Hausnummern sind Wohnungsnummern).


wenn es Wohnungsnummern sind: evtl. ist addr:housenumber der falsche
Tag (es gibt einen Vorschlag im Wiki für Wohnungsnummern)? Vermutlich
meintest Du allerdings: jede Wohnung hat eine Hausnummer?


> Dieses hat mehrere Eingänge mit den entsprechenden Ranges:
>
> Eingang 1 : 302-352
> Eingang 2 : 354-402
> Eingang 3 : 402-446
>
> etc.
>
> Ich könnte nun:
> (a) Jede Wohnung einzeln als addr:-Node mappen (ca. 100 Stück)


ja, wenn Du dazu Lust hast ;-)


> (b) eine addr:interpolation quer über das Gebäude legen


ja, bzw. mehrere


> (c) an den Eingängen Nodes mit:
>   addr:housenumber=302-352
>   addr:interpolation=even
> ich würde momentan (c) bevorzugen, Nachteil: Nominatim kann
> vermutlich keine Single-Node-Interpolation.


eher nicht.

Gruß Martin

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

Re: [Talk-de] Gesperrte Wege im Nationalpark Harz

[M∡rtin Koppenhoefer]

Am 13. Juli 2011 22:16 schrieb Sven Geggus :
> Peter  wrote:
>
>> Diese Wege tauchen bei zoom=13 auf, sind ab 15 dann gerötet.
>> Das sehe ich als Bug, die kann man auch ab 13 rot machen.

>> Verbotene Wege sollte man bei Feld Wald Wiesen Wanderwegen eher
>> gar nicht darstellen
>
> Ich bin absolut dagegen eine solche Form von Selbstzensur zu üben.


Gegen Zensur, ob selbst auferlegt oder von aussen, bin ich
selbstredend auch, aber aus den genannten "kartographischen" Gründen
könnte man durchaus überlegen, ob man Wege, die sowieso grundsätzlich
nicht betreten werden dürfen, wirklich schon in Z13 darstellen will,
dort aber die access-Attribute noch ignoriert, und erst in Z15 genauer
darstellt, dass bestimmte Wege eben gar nicht genutzt werden dürfen.
Oder ob man eben die Wege erst dann darstellt, wenn man auch genügend
Platz hat darauf hinzuweisen, dass sie nicht benutzt werden dürfen.
Bestimmte service werden (bzw. wurden) auch erst ab Z.15 dargestellt.

Gruß Martin

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

Re: [Talk-de] Auswirkungen der Lizenzumstellung auf Wegerelationen

[M∡rtin Koppenhoefer]

Am 13. Juli 2011 11:46 schrieb Chris66 :
>> Also mal abgesehen davon, dass an einer Routenrelation nun absolut gar
>> nichts kreatives ist,
>
> Und Bing Abmalen ist dagegen kreativ?


ja ist es. "Abmalen" halte ich alllerdings nicht für das richtige
Wort. Lass mal 3 Leute dieselbe Gegend von einem Luftbild
digitalisieren und vergleiche die Ergebnisse. Bei Gebäuden und evtl.
Straßen mögen die noch sehr ähnlich sein, beim Rest aber ziemlich
sicher nicht.

Gruß Martin

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

Re: [Talk-de] Logicbot - Lizenz

[M∡rtin Koppenhoefer]

Am 13. Juli 2011 00:33 schrieb Stefan Schwan :
> Diese Art der Änderung ist sicherlich nicht als schöpferische Leistung
> schutzwürdig und daher beim Aufräumen ignorierbar - es ist aber
> trotzdem extrem lästig, die inzwischen größtenteils "gelben" Wege zu
> checken!


+1


> Ich empfand die Aktion schon damals als Vandalismus und trage meine
> Boolean Werte nach wie vor als "true" und "false" ein.


ja, es lebe der Pluralismus. Wieso sollte man sich auf einen Wert
verständigen (yes ist 62mal so häufig wie true bei oneways) wenn man
genausogut mehrere verschiedene Werte für dasselbe verwenden kann.

Gruß Martin

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

Re: [Talk-de] Landuse im Autobahn-Kreuz

[M∡rtin Koppenhoefer]

Am 12. Juli 2011 06:27 schrieb Jan Tappenbeck :
> Wenn das Area aber alleinstehend ist, dann kann man das später ggf.
> einfacher umtaggen als wenn es mit dem angrenzenden Bereich verknüft ist.


Es spielt für das Ändern der Tags keine Rolle, ob und wie die Flächen
verbunden sind. Das Verbinden der Flächen ist Teil der Topologie: wenn
die Flächen "im echten Leben" verbunden sind, dann sollten sie es auch
in OSM sein. Wenn sie nicht verbunden sind (also noch etwas Flächiges
dazwischen ist), dann wäre es auch falsch, sie in OSM zu verbinden.

Gruß Martin

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

Re: [Talk-de] Insel im Meer

[M∡rtin Koppenhoefer]

Am 15. Juli 2011 14:26 schrieb M∡rtin Koppenhoefer :
> Für Inselgruppen fehlt hingegen noch ein Tagging-vorschlag (AFAIK),
> d.h. da könnte man helfen.


Vorschlag für den Key: "natural" (das sehe ich als Hauptkey für
geografische Features, s. dort z.B. was es schon gibt: Gipfel, Quelle,
Höhleneingang, Strand, Bucht, etc.).

Gruß Martin

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

Re: [Talk-de] Insel im Meer

[M∡rtin Koppenhoefer]

Am 12. Juli 2011 16:23 schrieb Markus :
> Hier steht, dass man die Coastline der Insel mit place=island bezeichnen
> soll, plus den Namen dazu:
> http://wiki.openstreetmap.org/wiki/DE:Tag:place=island
> Wenn ich mir aber unsere Mapnik-Karte anschaue, funktioniert das nicht so
> richtig. Woher weiss Mapnik, wann eine Insel "klein" und wann sie "gross"
> ist? Wie können wir ihm helfen, das besser zu erkennen?


wenn die Insel als Fläche und nicht als Punkt drin ist, dann hat
Mapnik eine gewisse Vorstellung von der Größe (abhängig vom
Breitengrad ist das nicht überall genau gleich).

Für Inselgruppen fehlt hingegen noch ein Tagging-vorschlag (AFAIK),
d.h. da könnte man helfen.

Gruß Martin

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

Re: [Talk-de] Landuse im Autobahn-Kreuz

[M∡rtin Koppenhoefer]

Am 11. Juli 2011 19:02 schrieb Robert S. :
> 2011/7/11 Jan Tappenbeck 
> Die reine Fahrbahnfläche ist mit area:highway [1] zu erfassen; das geht aber
> eigentlich nur, wenn auch ausreichend hochauflösende Luftbilder verfügbar
> sind.


kann man machen. "ist zu erfassen" finde ich beim derzeitigen Stand
allerdings deutlich übertrieben (gerademal 474 Straßenstücke sind
bisher so erfasst, das macht einer allein in rel. kurzer Zeit).


> Der ganze Straßenbereich bekommt dann landuse=grass


?? Da möchte ich gerne widersprechen: wieso sollte eine Straße
landuse=grass bekommen? landuse ist m.E. highway oder ähnlich, surface
dann je nachdem Asphalt, Schotter oder Gras.


, weil ja nicht direkt an
> der Asphaltkante das Straßenbegleitgrün (Gebüsch/Strauchwerk/Bäume etc.)
> losgeht, sonder es immer einen Grünstreifen gibt der z.B. Beschilderung,
> Leitplanken oder auch einen Entwässerungsgraben aufnimmt.


Eben. Gerade weil es diese ganzen Elemente gibt, ist landuse=grass für
eine Straße doch Quatsch.


Gruß Martin

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

Re: [Talk-de] Geänderte Wegführung bei Radrouten

[M∡rtin Koppenhoefer]

Am 11. Juli 2011 08:37 schrieb Andreas Tille :
> Das würde ich früher oder später wahrscheinlich mal ins Auge fassen,
> ändert jedoch nicht die Tatsache, daß die Schilder nach wie vor an
> der nicht mehr offiziellen Route angebracht sind.


solange die Schilder da sind, würde ich die Route auf jeden Fall
drinlassen (wenn sie auch so befahrbar ist, und vor allem auch
angesichts der Tatsache, dass Du Dir selbst nicht sicher bist). Die
Wegqualität hat sich ja nicht von einem Tag auf den anderen geändert.

Ob und welche Route jetzt "offiziell" ist weisst Du nach Deinen
bisherigen Mails auch gar nicht, das ganze beruht bisher nur auf einem
"Verdacht" und "alles nur Vermutungen". Wenn Du Gewissheit willst,
könntest Du mal versuchen, jemanden auf dem Amt anzurufen (die
schicken Dich da auch gern weiter, wenn sie nicht zuständig sind, mit
ein bisschen Beharrung kommt man normalerweise an die Infos die man
braucht).

Gruß Martin

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

Re: [Talk-de] OSM Daten im 50km Radius ermitteln

[M∡rtin Koppenhoefer]

ich würde ein pbf z.B. von der Geofabrik laden welches das komplette
Gebiet abdeckt und dann mit
pbftoosm -b=12.62,42.3,13,42.56 < eingabe.pbf > ausgabe.osm

eine BB ausschneiden. Geht rel. schnell und problemlos. Wenn Du
wirklich einen Kreis brauchst kannst Du danach noch weiter schnipseln,
oder vielleicht gibt es auch eine Polygon-Schneideoption, sieh Dir das
mal im Wiki an. Es gibt auch noch alternative pbf-Programme.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 7. Juli 2011 19:54 schrieb Robert S. :
> Hat man hier in Aachen auch anfangs gemacht^^ Und dann andere Flächen nicht
> per Multipolygon ausgeschnitten sondern einfach drüber gezeichnet...
> Inzwischen ist das in ein Multipolygon überführt worde - wobei man die
> residential-Fläche zumindest an den Bahnanlagen aufteilen  könnte.


für die Mapper am einfachsten ist es, je Block bzw. falls erforderlich
noch feiner, die Nutzung anzugeben. Wenn sich was ändert oder man
andere Daten ermittelt kann man einfach und ohne die halbe Stadt zu
analysieren oder herunterzuladen das tag für den einen Bereich
anpassen, der einen interessiert.


> Argh!
> 1. Die Landnutzung ist flächendeckend. Schonmal zwischen einem Feld und
> einer Wiese einen Bereich gesehen, wo einfach *nichts* ist? Nein. Mich
> schüttelt es immer, wenn ich in den Daten oder auf den Karten solche 'weißen
> Kanten' sehe...


weisse Kanten sind erstmal überhaupt nicht schlimm. Wenn man dem
Ungenutzten eine "Nutzung" zuweisen will, kann man das ja gerne tun,
aber es wird eben weder residential noch farmland sein, sondern so was
wie "Brache" oder "ungenutzt" oder "Abstandsfläche", etc.


> 2. Eine Erfassungsmethode ist nicht schon deshalb abzulehnen, weil sie
> Arbeit macht.


klar


> 3. Die Erfassung von Landnutzung sollte schon vollständig erfolgen; also so,
> dass im Regelfall kein nachträgliches Einfügen mehr nötig ist. Eine
> unvollständige Erfassung von Landuse macht meist eher mehr Arbeit, als dass
> sie nützt.


das halte ich für Quatsch. OSM funktioniert iterativ, und m.E. sollte
man daran auch immer denken. "Vollständig" gibt es nicht. Das ist auch
der Grund, warum m.E. kleinere Stückelungen größeren Flächen
vorzuziehen sind: weil man sie viel einfacher weiter bearbeiten kann.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 7. Juli 2011 17:25 schrieb Johannes Huesing :
> M∡rtin Koppenhoefer  [Thu, Jul 07, 2011 at 05:09:48PM 
> CEST]:
>> +1, ich sehe das genauso. Landuses würde ich am (geschätzten)
>> Grundstücksende aufhören lassen und nicht mit der Straße verbinden.
>
> Und wenn die Straße zum Grundstück gehört, bei Feldwegen, Wegen
> durch Schrebergartensiedlungen und Waldwegen?


Bei Feldwegen gehört die Straße AFAIK normalerweise nicht zum
Grundstück, bei anderen Wegen muss man sehen. M.E. wird ein landuse
nicht in der Mitte des Weges enden, er wird grundsätzlich am Rand
enden, entweder man schließt den Weg mit ein, oder nicht.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 7. Juli 2011 16:04 schrieb Florian Lohoff :
> Solange das alles landuse ist sehe ich noch ein das das sinn macht.
> Sehe bloss immer haeufiger noch einen mix aus highway, landuse, amenity
> building etc ... Dann hat man wirklich gar keinen ueberblick mehr.


+1, ich sehe das genauso. Landuses würde ich am (geschätzten)
Grundstücksende aufhören lassen und nicht mit der Straße verbinden.
Das Verbinden sorgt für massenhaft Probleme und Intransparenz beim
weiteren Mappen und hat auch hins. der transportierten Information
Nachteile. Direkt angrenzende landuses nicht zu verbinden sehe ich
hingegen als topologischen Fehler an, der ebenfalls vermieden werden
sollte.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 7. Juli 2011 00:05 schrieb Stephan Wolff :
> Wie könnte man z.B. bei einer Bushaltestelle mit Bank und Unterstand die
> Lage der drei Einzelobjekte (Haltestellenmast am Fahrbahnrand, Bank hinter
> dem Fußweg, Unterstand 5 m in Fahrtrichtung) abbilden ohne eine bestehende
> Auswertung zu schädigen?


das kommt immer darauf an, wie die Auswertung aussieht, d.h. was wie
ausgewertet wird.


> Soll man eine Straßeneinmündung mit drei kleinen Verkehrsinseln mit allen
> Details erfassen, wenn dadurch zehn zusätzliche Wegstücke und fünf
> zusätzliche Abbiegerelationen nötig werden?


ja, m.E. sollte man die Details abbilden. Werden da wirklich so viele
Abbiegerelationen notwendig?


> Wie kann der Mapper erkennen, ob
> es dann Probleme bei der TMC-Auswertung gibt?


gefühlsmäßig würde ich vermuten, dass das keine Auswirkungen hat, aber
ganz genau habe ich mir TMC noch nicht angesehen.


> Selbst wenn keine bestehenden Daten geändert werden müssen, erschweren drei
> eng benachbarte Linien anderen Mappern die Arbeit und provozieren falsch
> verbundene Wege.


am einfachsten ist immer eine leere Karte zu editieren. Hat Deine Maus
kein Zoomrad? Was ist "eng benachbart"? Das ist doch nur eine Frage,
wie weit man reinzoomt.


> Fast jede Detailerfassung hat Vor- und Nachteile. Oft müssen wir mit den
> Nachteilen leben. Aber ich finde es legitim, auch Entscheidungen gegen
> Detailerfassung zu Gunsten eines einfacheren, generalisierten Datenmodells
> zu treffen.


ich nicht, wenn man dafür die Details anderer Leute löscht.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 12:27 schrieb Sven Sommerkamp :
> Würde man statt einem Waldstück jeden einzelnen Baum erfassen?
> Warum nicht?


ja, warum nicht.


> Vielleicht mit Pilzbewuchs und ohne als Tag?


warum nicht, wenn man Zeit, Lust und Interesse daran hat.


> Die Frage ist doch immer wieviel ist ausreichend und macht Sinn?
> Und ist ist das Konstrukt noch allgemein durchschaubar?


ja, wobei das bei der Aufnahme wieder der einzelne Mapper entscheidet,
während das Löschen m.E. mind. einen Dialog/Diskussion erfordert. Und
wenn jemand einzelne Bäume gezeichnet hat ist es m.E. eben nicht OK,
die alle zu löschen, eine Fläche drumrum zu malen und zu deklarieren,
das war davor zu detailliert und zu wenig abstrakt.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 11:53 schrieb Falk Zscheile :
> Aha, und das ist dann genauer/besser? Ich denke dieses Beispiel zeigt
> schön, dass hier irgendwo eine Grenze bei der Datengenauigkeit liegt.


Klar gibt es eine Grenze bei der Datengenauigkeit, aber die besteht
eben nicht nur in der absoluten Lage der Objekte sondern auch in der
relativen Lage und in der Konfiguration. Z.B. macht es einen
Unterschied, ob 5 Bänke in einer Reihe stehen, oder ob sie ein U
bilden. Auch kommt es darauf an, auf welcher Seite eines Weges /
Bushhaltestelle, Telefonzelle, Einmündung, etc. sie stehen (relative
Lage). Das ist m.E. viel wichtiger als die genaue Lage auf den cm.

Gruß Martin

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

Re: [Talk-de] Sommeraufgabe 2011

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 12:20 schrieb Jan Tappenbeck (OSM) :
> [1] http://wiki.openstreetmap.org/wiki/DE:Sommeraufgabe2011

nette Idee, ich habe mal ein paar Hinweise für Italien ergänzt. Hast
Du das auch im Forum gepostet?

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 11:24 schrieb Falk Zscheile :
> Vielleicht könnt ihr euch ja darauf einigen, dass die nahe beieinander
> stehenden Bänke über eine site-Relation zusammengefasst werden.


-1, wozu sollte das gut sein? Es ist ein Leichtes, nahe
zusammenstehende Bänke _im Postprocessing_ zusammenzufassen, in den
Daten will man die m.E. alle haben, und eine Relation erhöht unnötig
die Komplexität (dass die in der Nähe stehen ist bereits in den
Daten).


> Im übrigen ist das ein ungeklärtes Problem ob und welche
> Detailgrenzen/Abstraktionsgrad Daten haben sollten.


M.E. regelt das der Mapper. Hinterher die Abstraktion in den
Grunddaten (db) zu erhöhen halte ich für Vandalismus (*reiz*),
vorhandene Daten in der eigenen db-Kopie zu abstrahieren ist ggf.
wünschenswert.


> Solange man das
> aber noch einigermaßen mit GPS-Gerät erfassen kann ist meiner Meinung
> nach noch kein Platz für diese Diskussion :-)


man kann sowas wie Bänke durchaus auch per Foto erfassen, und dann
z.B. den ungefähren Abstand und die Lage erkennen, GPS ist da meistens
eher nicht genau genug, ovn daher ist das m.E. auch kein Kriterium.

Was die Abstraktion von Bänken grundsätzlich angeht macht man da ja
schon einiges, sonst müsste man die Bänke als area oder evtl. als
kurzen way eintragen, dann könnte man sich auch (analog zu cliff oder
retaining wall) auf einen Standard einigen, wo die Rückenlehne falls
vorhanden ist (bezogen auf die way-Richtung), und hätte die
Information, wie die Bank ausgerichtet ist.

Gruß Martin

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

Re: [Talk-de] Stammtische im Wiki-Terminkalender reduzieren?

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 09:47 schrieb Frederik Ramm :
> Was koennten wir tun, um die restliche OSM-Welt nicht so zu erdruecken?
> Sollten wir vielleicht einfach eine Extra-Kalenderseite "Regular pub meets
> in Germany" machen?


Ja, man könnte die Pub-meetings nach Ländern sortieren und auf
Unterseiten unterbringen. Andererseits ist das mit den Symbolen schon
ganz gut gelöst, so dass man die wichtigeren Termine eigentlich auf
einen Blick von den Stammtischen visuell unterscheiden kann. Ich finde
es ist durchaus auch eine gute Werbung für die Community, wenn viele
persönliche Zusammenkünfte dort eingetragen sind.

Dass das meiste in Deutschland stattfindet ist ja kein Zufall, die
Mapping-Community ist dort auch auch stärksten ;-), d.h. OSM spielt
sich wirklich zu einem großen Prozentsatz in deutschen Kneipen ab, das
kommt nicht nur dem Mexikaner so vor ;-)

M.E. sind wir gerade so am Limit angekommen was die Länge der Liste
angeht, d.h. die Unterseiten nach Ländern oder ein dynamisches
Ausblenden auf der Hauptseite sind beides gute Ideen für die nahe
Zukunft, wenn die Liste wie zu erwarten weiter wächst.

Gruß Martin

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

Re: [Talk-de] Redundanz?

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 10:50 schrieb Andreas Neumann :
> bevor ich einen Editwar beginnen, wollte ich nur klären, ob ich da
> falsch liege... Es geht darum, wenn mehrere Bänke an einem Platz stehen.
> Ich hab immer einen Node für jede Bank gesetzt. Nun geht ein User in
> Ilmenau durch und löscht die Bänke. Auf unserem Kirchplatz stehen
> jeweils Bäumchen mit Bänken, er machte daraus einen Baum mit Bank. Er
> verweist darauf, dass mehrere Bänke an einem Ort redundant sind und es
> ausreicht nur eine zu malen. Gibt es da eine Redundanz-Regel, die ich
> nicht kenne?


hm, Baum und Bank auf demselben Node mag OK sein, aber bei mehreren
benachbarten Bänken alle bis auf eine zu löschen ist m.E. Vandalismus.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 00:15 schrieb Wolfgang :
>> das width-tag willst Du wo genau anbringen?
>
> damit ließe sich die Breite des Bereiches zwischen den Fahrbahnen kennzeichnen
> ("Mittelstreifen"). Der Wert wird durch das Regelprofil festgelegt und ist auf
> langen Strecken einheitlich.


einerseits sehe ich es gerade bei Autobahnen schwierig an, dort vor
Ort genaue Maße zu erheben, und andererseits hast Du diese Breite
automatisch, indem Du dem Abstand der highway-ways jeweils die halbe
Breite abziehst. Der Sinn könnte darin bestehen, über einen weiteren
Wert die Plausibilität der Straßen-tags und -lage zu schätzen, aber da
kommt wieder Punkt 1 ins Spiel: die Mittelstreifenbreite kannst Du
schwer messen.


> Unsere Lage der Fahrbahnen der Autobahnen schwankt gegenüber den Luftbildern
> ständig hin und her, abgesehen von der ungenauen Lage der Luftbilder selbst,
> die aus GPS-tracks abgeleitet wird, die selbst wiederum eine Unsicherheit von
> 2-3m im Mittel haben,


die Luftbilder die wir haben, werden ziemlich sicher auch in
Deutschland irgendwann besser werden, wenn die Ämter das irgendwann
mal rausgeben. 2-3 Meter sind m.E. im Autobahnbereich schon sehr gut,
wenn wir das überall hinbekämen wäre ich ziemlich zufrieden.


> zudem soll hier eine imaginäre Mittellinie gezeichnet
> werden, die es in der Realität gar nicht gibt.


damit meinst Du den highway-way. Davon werden wir uns so schnell
sicher nicht verabschieden, d.h. den braucht man auf jeden Fall. Das
ist die Fahrbahnmitte, die ist zwar nicht markiert, aber "geben" tut
es die natürlich auch in der Realität.


> Meistens läuft die Linie auf
> dem Trennungsstreifen zwischen Haupt- und Überholfahrstreifen. Das ist aber
> weder bei 2 noch bei 3 Spuren die geometrische Mitte, vorausgesetzt, dass die
> Autobahn eine Standspur hat, die meines Wissens noch gar nicht getaggt wird.


Standspuren und Belag ausserhalb der Fahrbahn sorgen zugegebenermaßen
für gewisse Unschärfen, aber dem wird sich beim Detailierungswunsch
der Mapper sicher auch noch irgendwann jemand annehmen. Ob diese
Straßenlinie jetzt in der Mitte des asphaltierten Bereichs (erkennbar
in Luftbildern) oder in der der Fahrbahn läuft, spielt kaum eine
Rolle, vor allem, solange kein Spurmodell verbreitet ist.


> Hinzu kommt, dass OSM mit ausschließlich geraden Verbindungslinien arbeitet,
> die in den real gemappten Kurven der Praxis um bis zu 5m um die "Mitte"
> schwanken.


m.E. sollte man Kurven so fein es geht annähern, diese eckigen Kurven
sehen in der Tat schlecht aus und sorgen auch geringfügig für
Lageungenauigkeiten.


> Du willst also einen Wert, der zwischen 1 und 3 Meter beträgt, aus 2 Messungen
> ableiten, die im Einzelwert eine Unsicherheit von 3-5m haben, und das Ganze
> über eine Strecke von mehreren 100km. Mit einer so ermittelten Fläche liegst
> du um Lichtjahre schlechter als ein über den Daumen gepeiltes Ergbnis, alles
> andere wäre reines Glück.


wieso aus 2 Messungen? Jeder Track ist eine Messung, auf Autobahnen
hast Du meistens viele davon.


> Außerdem
> ist die Achse in der Realität besser zu erkennen als z.B. jede Gemeindegrenze,
> ganz zu schweigen von der "Fahrbahnmitte".

Die Fahrbahnmitte sehe ich bei 2 und 4 Spuren auf der gestrichelten
Linie, bei 3 Spuren in der Mitte der mittleren Spur. Finde ich
problemlos umzusetzen, während die "Achse" meistens schlechter zu
erkennen ist, sowas hier ist natürlich nochmal ein Sonderfall:
http://maps.google.com/maps?hl=de&ll=42.277158,14.018211&spn=0.001046,0.002642&t=k&z=19
http://maps.google.com/maps?ll=42.011694,13.807771&spn=0.002101,0.005284&t=k&z=18

die Spuren behalten normalerweise ihre Breite, die Mittelachse ändert
Ihre Breite öfters mal, sieh mal was hier z.B. los ist (in der Gegend
gibts noch mehr krasse Stellen):
http://maps.google.com/maps?hl=de&ll=40.685438,14.761569&spn=0.004288,0.010568&t=k&z=17

Gruß Martin

PS: Meiner Meinung nach kann man mit der Relation mehr aussagen,
besser rendern und routen und hat weniger Arbeit, aber mir ist es im
Prinzip egal wenn Du gerne die Trennflächen als Linien erfassen
willst, und man die Tags halbwegs verstehen kann, auch ohne Übersetzen
ins Deutsche, dann kann und will ich Dich nicht davon abhalten.

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

Re: [Talk-de] Der AIOTM (All-in-One-TileManager)

[M∡rtin Koppenhoefer]

Am 5. Juli 2011 12:05 schrieb UMAX974 :
> Hm,
> Aber der Mac ist wieder außen vor... ;( - Oder gibt es auch für den was?


Müsstest Du mal im App-Store nachsehen (SCNR).
Im Ernst, evtl. geht das Linux-Script auch auf dem Mac.

Gruß Martin

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

Re: [Talk-de] Windows: kacheln zippen und dann auf dem Server wieder entpacken

[M∡rtin Koppenhoefer]

Am 5. Juli 2011 12:41 schrieb Jan Tappenbeck :
> Am 05.07.2011 11:52, schrieb Frederik Ramm:
>>
>> Hi,
>>
>> On 07/05/11 11:46, Jan Tappenbeck wrote:
>>>
>>> Nun wende ich mich an Euch mit der Frage ob einer ein freies Packtool
>>> kennt das über Batch-Betrieb angesprochen werden kann und das dann auch
>>> mit einem entsprechenden Script entpackt werden kann - und das in dieser
>>> Konstellation auf funktioniert.
>>
>> Wenn ich Dich richtig verstehe, ist Dein Problem, dass Du kein
>> Commandline-Auspacktool fuer Zip-Dateien auf Windows hast?
>>
>> Ich habe "Windows Commandline Unzip" in Google eingegeben und fand als
>> ersten Treffer dies:
>>
>> http://stahlworks.com/dev/index.php?tool=zipunzip
>>
>> Hast Du das schon probiert?
>>
>> Bye
>> Frederik
>
> hi !
>
> ... umgekehrt - ich muss erst einmal auf windows7 packen und dann das
> richtige entpackscript auf dem zerver haben !
>
> hast Du mir dem Teil schon einaml das Bündeln von Dateien in verschachtelten
> Verzeichnissen realisiert bekommen ??



such mal nach tar bzw. komprimiere dann mit bzip (tar.bz2).

komprimieren mit bz2 geht z.B. so:
tar -cvjf archivname.tar.bz2 zusicherndedateibzwordnername

Entpacken auf dem Server sollte so gehen:
tar -xvjf dateiname.tar.bz2

Das ist rekursiv, d.h. die Ordnerstruktur wird beibehalten.

Gruß Martin

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

Re: [Talk-de] Der AIOTM (All-in-One-TileManager)

[M∡rtin Koppenhoefer]

Am 5. Juli 2011 11:09 schrieb UMAX974 :
> Ja, und genau, da liegt dann mein Problem, an dem ich regelmäßig scheitere.
> Ich kenne JOSM und arbeite gerne damit, aber mkgmap ist für mich einfach ein 
> Buch mit sieben Siegeln. Das Programm hat, wie man so schön sagt, keine 
> "usability". Kann man das Teil nicht so schreiben und gestalten, dass selbst 
> Dummys wie ich damit einfach klarkommen?


Als ich das das letzte Mal benutzt habe reichte es aus, das Programm
mit entsprechenden Parametern auszuführen, der Rest ging automatisch
(hatte allerdings einen kleinen Bereich gemacht, der kein Splitten
erforderte). Es gibt mittlerweile Skripte, die AFAIK alles automatisch
machen, sowohl für Win als für Linux. Sieh mal hier:
http://mce66.altervista.org/software.html#Open_Maps_for_Garmin_navigators

(das erste dort, bzw. Direktlink zur Windowsversion:
http://mce66.altervista.org/software/IMG-OSM-Country/CreateIMG-beta06.zip
)

Gruß Martin

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

Re: [Talk-de] Der AIOTM (All-in-One-TileManager)

[M∡rtin Koppenhoefer]

Am 4. Juli 2011 21:32 schrieb Boris Wagner :
> Am 04.07.2011 16:58, schrieb M∡rtin Koppenhoefer:
> Beim 60csx gehen mit der aktuellen FW auf jeden Fall Kartenfiles mit 4GB
> Größe. Da bin ich mir zu 100% sicher.


wie?

Ich habe die Firmware 4.00 (gem. Garmin Seite die aktuelle) und GPS SW
2.90s. Hängt das evtl. mit dem Gerät zusammen (dass die nicht alle
baugleich sind)?

Gruß Martin

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

Re: [Talk-de] Der AIOTM (All-in-One-TileManager)

[M∡rtin Koppenhoefer]

Am 4. Juli 2011 16:47 schrieb Boris Wagner :
> Am 04.07.2011 16:18, schrieb M∡rtin Koppenhoefer:
>>> 1. nicht größer als 4GB besser nur 3-3,5GB, damit man noch Platz auf der
>>> SD card für tracks, bzw. POI Daten hat.
>> ich fände eine Version unter 2GB besser, da man alles andere nur auf
>> einem eingeschränkten Kreis von Geräten nutzen kann.
> Welche Geräte können denn keine 4GB Kartenfiles lesen?
>
> Von eTrex über die 60 bis zu den aktuellen, Dakotas, Oregons, 62er, usw.
> Können das doch IMHO alle?


Auf meinem 60csx gehen (map)Karten über 2GB nicht, wohl aber gehen
Micro-SD-Karten bis 4GB (oder evtl. auch mehr). Das Problem ist wohl
das (virtuelle/interne) Filesystem des Garmin, welches keine Files
über 2GB erlaubt (addressieren kann). AFAIK habe ich die neueste
Firmware.

Gruß Martin

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

Re: [Talk-de] Der AIOTM (All-in-One-TileManager)

[M∡rtin Koppenhoefer]

Am 4. Juli 2011 15:52 schrieb UMAX974 :
> Das hatte ich fast befürchtet, dass jeder seine Sonderwünsche anbringt.
> Ich denke wir sollten dabei zwei Kriterien einhalten.
>
> 1. nicht größer als 4GB besser nur 3-3,5GB, damit man noch Platz auf der SD 
> card für tracks, bzw. POI Daten hat.


ich fände eine Version unter 2GB besser, da man alles andere nur auf
einem eingeschränkten Kreis von Geräten nutzen kann.

Gruß Martin

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

Re: [Talk-de] Operator bei Bundesstraßen und Autobahnen

[M∡rtin Koppenhoefer]

Am 1. Juli 2011 07:14 schrieb Christian H. Bruhn :
> Hallo!
>
> Es gibt in Deutschland ja einige Streckenabnschnitte von Bundesstraßen
> (z.B. Herrentunnel in Lübeck) und Autobahnen (z.B. A1 zwischen Hamburg
> und Bremen) die von privaten Unternehmen betrieben werden. Also kommt
> an diese Streckenabschnitte ganz klar ein entsprechender Operator.
>
> Nun gibt es ja auch die Sammelrelationen für Autobahnen bzw.
> Bundesstraßen; dort steht aber als Operator 'Bundesrepublik
> Deutschland' drin. Für die ganze Strecke ist das aber falsch.
>
> Wie soll man nun vorgehen? Die Information aus der Relation rausnehmen
> und alle Streckenabschnitte taggen?


Vermutlich wäre es am sinnvollsten, die Autobahn-Sammel-Relationen zu
löschen, sofern da kein Mehrwert im Vergleich zu den ref-Tags am
Objekt besteht (AFAIK gibt es den nicht). Von daher ist das Taggen der
einzelnen Streckenabschnitte mit operator m.E. sinnvoller, da keine
Unschärfen und Widersprüche entstehen.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 1. Juli 2011 06:26 schrieb Wolfgang :
> Hallo,
> Am Freitag 01 Juli 2011 01:27:44 schrieb M∡rtin Koppenhoefer:
>> vermutlich hast Du Dir die relation area nicht angesehen, 
> Das ist eine Möglichkeit, die ich aber aus Gründen der Zweckmäßigkeit für
> ungünstig halte. Bei unserer Erfassungsqualität schwankt diese Area gewaltig
> in der Breite, während in der Realität der Mittelstreifen über (mindestens)
> viele Kilometer die gleiche Breite hat., was durch das width-Tag wesentlich
> besser erfasst wird.


das width-tag willst Du wo genau anbringen?


> Lineare Bauwerke wie Straßen oder Mittelsteifen lassen sich durch die real als
> Mittelleitplanke vorhandene Achse besser abbilden als durch eine Fläche.


bei meinem Modell werden sie weder als Linie noch als Fläche
gezeichnet, sondern über tags sowie die Lage zwischen 2 ways indirekt
beschrieben.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 1. Juli 2011 00:48 schrieb Wolfgang :
> Hallo,
> Am Donnerstag 30 Juni 2011 19:28:47 schrieb M∡rtin Koppenhoefer:
>> Am 30. Juni 2011 18:40 schrieb Wolfgang :
>> > Ich halte es für sinnvoll, den Mittelstreifen zu mappen.
>>
>> +1. Nicht dass ich das für erste oder zweite Priorität halte, aber
>> prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation,
>> type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass
>> man nicht unnötig "Pseudogeometrie" eingeben muss, die dann doch
>> keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch,
>> wird man aber eher selten brauchen).
>
> Den Mittelstreifen als area zu erfassen, ist sicherlich möglich. In der
> Realität ist der Mittelstreifen allerdings ein ganz langes, schmales "Dings",
> das mit den Mittelpunktskoordinaten genau genug erfasst werden kann, ggf.
> unter Zuhilfenahme von "width".


vermutlich hast Du Dir die relation area nicht angesehen, und
zugegebenermaßen könnte man das proposal auch noch besser beschreiben.
Die Idee ist, dass man nur die beiden bereits bestehenden highways
einfügen würde und über die area-Relation beschreibt man im Normalfall
eine "virtuelle area" wo man über Tags z.B. definiert, aus was sie
besteht (hier z.B. Hecke). Optional kann man natürlich für diese Tags
auch eine Geometrie zeichnen, aber aus den Straßenbreiten ergibt sich
die Breite des Mittelstreifens meist von selbst. Man definiert so
gleichzeitig auch eine lineare Übergangsmöglichkeit z.B. für Fußgänger
(bzw. an der Autobahn würde man foot=no setzen, da verboten).


>> Auch "Achse" finde ich nicht so toll, den Begriff gibt es zwar im
>> Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar
>> in der Konstruktion und zum Bezug, aber in der Realität findet man
>> gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil
>> der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist).
> Ja, aber die Straße als Ganzes incl. aller Fahrsteifen, Standspur, Bankett,
> Graben, Böschung etc hängt ausschließlich an dieser Achse.


bei der Konstruktion / Herstellung vielleicht. In der realen Welt
sieht man sie nicht. Sie ist ein theoretisches /
vermessungstechnisches Konstrukt.


>> barrier=concrete halte ich für schlecht, weil das ein Material und
>> keinen Typ bezeichnet, wie wärs mit barrier=wall
>
> -1, gibt es schon als Wände, beispielsweise an Tunnelbauwerken.


das ist auch nichts anderes als eine Wand, daher ja der Vorschlag. Mit
entsprechender Höhe ist es klar definiert.


> visor != visier
> visor = Blendschutz, Nr.1 bei Leio


Dir ist schon klar, dass Blendschutz z.B. auch eine Sonnenbrille ist?


> aber schlage gerne was passenderes vor.

s.o. im Thread



>> dazu gibts allerdings schon Vorschläge (z.B. bridge relation),
>> jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen
>> explizit zu zeichnen.
>
> Zeichnen verlangt niemand. Nur die Angabe der Mitte einer Straße mit mehreren
> Fahrbahnen. Welcher Renderer das für welchen Maßstab nutzt, ist eine ganz
> andere Sache.


mit "zeichnen" meine ich, dass man einen expliziten Way mit expliziten
Nodes einträgt, wie Du das getan hast.


>> Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen
>> (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier
>> Straßen.
>
>  Sofort einverstanden. Aber bis das für alle Bauwerke weltweit gemappt ist,
> halte ich es für sinnvoll, dem Renderer für große Maßstäbe schon mal eine
> Möglichkeit des näherunsweise korrekten Zeichnens zu geben.


ja, aber bitte nicht so. Lasst es uns gleich so machen, dass es auch
weiterverwendbar ist.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 30. Juni 2011 18:40 schrieb Wolfgang :
> Ich halte es für sinnvoll, den Mittelstreifen zu mappen.


+1. Nicht dass ich das für erste oder zweite Priorität halte, aber
prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation,
type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass
man nicht unnötig "Pseudogeometrie" eingeben muss, die dann doch
keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch,
wird man aber eher selten brauchen).


> Die Begriffe habe ich
> mir mit Hilfe von Leo rausgesucht.


das geht leider oft schief, besser hier oder auf tagging mal nachfragen.


> Im Straßenbau ist es in D üblich, die
> Mittellinie der Autobahn als "Achse" zu bezeichnen, das passt möglicherweise
> nicht unbedingt im Englischen Sprachbereich.
>>
>> http://www.openstreetmap.org/browse/way/118720117
>> highway=axis
> Mittellinie einer mehrspurigen Straße, ich habe kein Problem mit einer
> Umbenennung


hier würde ich doch gerne nochmal nachhaken, weil die Achse "einer
mehrspurigen Straße" haben wir in OSM bereits als way mit "highway=*"
drin. Von daher finde ich "highway" als key eher ungeschickt, weil man
dann schonmal bei "nichtmehrbahnigen" Straßen die Mittellinie taggen
könnte.

Auch "Achse" finde ich nicht so toll, den Begriff gibt es zwar im
Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar
in der Konstruktion und zum Bezug, aber in der Realität findet man
gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil
der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist).

Dir geht es ja um "mehrteilige" Straßen, also solchen, die aus
mehreren Fahrbahnen bestehen.


>> barrier=beam_barrier
> Barriere zum Schutz des Gegenverkehrs. beam_barrier = Leitplanke, concrete =
> Betonbarriere, ...


barrier=concrete halte ich für schlecht, weil das ein Material und
keinen Typ bezeichnet, wie wärs mit barrier=wall (oder ggf.
jersey_barrier, dem spezifischen Ausdruck für die Teile)? Anstatt
beam_barrier würde ich guard_rail verwenden. Beides ist hier
dokumentiert im Wiki:
http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types




>> visor=hedge
> Sichtschutz. scrub halte ich für übertrieben, Knick past auch nicht, am
> ehesten ist es IMO eine Hecke (diese Grünzeug-Kette, die ab und zu geschitten
> wird).


Hecke ist OK, aber Visier? Ich glaube Du meintest etwas anderes ;-)


Da stellt sich jetzt allerdings das übliche Problem bei barrier:
welche Ebene taggt man, oder stapelt man? Unten Leitplanke oben Hecke
(oft gibts auch unten Mauer, dann Zaun, und ggf. oben noch
Stacheldraht). Oder Stützmauer mit Zaun oben drauf, etc.
Dafür habe ich bisher auch keine detaillierte Lösung.


> ps. noch was:
> bridge=seperated -/- combined (an der Achse)


lieber "separated" ;-)


> Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt
> wird nur "da ist Brücke". Ob das jetzt ein Bauwerk ist oder zwei oder mehrere
> parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts
> dazu gefunden.


dazu gibts allerdings schon Vorschläge (z.B. bridge relation),
jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen
explizit zu zeichnen. Dieser separated/combined Ansatz würde ja
sowieso wieder nur für bestimmte Fälle funktionieren. M.E. ist eine
saubere Brücken-Einheit irgendwann an der Zeit, wo man noch viel mehr
Zeugs dazutaggen kann, vom Baujahr über den Namen bis zu Details wie
Konstruktionstyp, Auflager / Widerlager / Zugverankerungen etc.

Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen
(analog sonstiger Gebäude), nicht einen Way in der Mitte zweier
Straßen.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 30. Juni 2011 14:19 schrieb Roland Spielhofer :
> Am 30/06/2011 13:06, schrieb M∡rtin Koppenhoefer:
>> Gegenvorschlag für "visor": central_reservation (scheint gem.
>> Wikipedia BE zu sein):
>>
>> http://en.wikipedia.org/wiki/Central_reservation
>
> Im Straßenbau ist "Median" gebräuchlich und wird auch von vielen
> Non-English-Natives verwendet.


Gem. Wikipedia ist das amerikanisches Englisch. Dazuhin ist das ein
sehr vieldeutiges Wort.

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 30. Juni 2011 13:02 schrieb M∡rtin Koppenhoefer :
> Am 30. Juni 2011 12:32 schrieb Frederik Ramm :
> Vermute dass "visor" nicht richtige Wort ist, ich stelle mir da eher
> die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor,
> ganz sicher bin ich mir allerdings auch nicht.
>
> M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch
> spricht, mal auf tagging nachzufragen, bevor man irgendwelche
> Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht
> passen.


Gegenvorschlag für "visor": central_reservation (scheint gem.
Wikipedia BE zu sein):

http://en.wikipedia.org/wiki/Central_reservation

Gruß Martin

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 30. Juni 2011 12:32 schrieb Frederik Ramm :
>   hab ich da was verpasst:
>
> http://www.openstreetmap.org/browse/way/118720117
>
> highway=axis
> barrier=beam_barrier
> visor=hedge
>
> oder ist jemand da einfach nur erfindungsreich? Gab es dazu mal ne
> Diskussion zum Thema Mapping von Autobahn-Mittelstreifen?


Dazu gabs m.E. keine Diskussion (muss ja auch nicht unbedingt).

Ich finde das Mappen von solchen Dingen durchaus hilfreich, allerdings
ist highway=axis m.E. murks und überflüssig (das ist kein highway
sondern eine barrier). Für Leitplanken verwende ich persönlich
"barrier=guard_rail" (gibts ca. 273 im planet), beam_barrier bisher
erst 75 mal.

visor=hedge ist vermutlich Unsinn, ist auch im Wiki nicht dokumentiert
und hat erst 42 Vorkommen:
http://taginfo.openstreetmap.de:8001/keys/visor#values

Vermute dass "visor" nicht richtige Wort ist, ich stelle mir da eher
die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor,
ganz sicher bin ich mir allerdings auch nicht.

M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch
spricht, mal auf tagging nachzufragen, bevor man irgendwelche
Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht
passen.

Gruß Martin

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

Re: [Talk-de] prüfen von Relationsvollständigkeiten

[M∡rtin Koppenhoefer]

Am 29. Juni 2011 09:01 schrieb André Joost :
> Am 29.06.11 08:40, schrieb Hermann Peifer:
>> Bei manchen Fahrrad-Routen, die ich gerade aufnehme koennte man locker
>> auf >100% der ausgewiesenen Laenge kommen, weil die Route teilweise
>> beidseitig von secondary (u.ae.) highways verlaeuft, z.B.
>> http://osm.org/go/0NWjZsM0?relation=29135
> ja, irgendwo hat alles seine Grenzen.


+1


> Sobald man Plätze hinzufügt, stimmt
> die "Länge" auch nicht mehr.


oder man teilt den Platz (dann ist der Unterschied zwischen Teilstück
des Perimeters und mittig über den Platz praktisch zu
vernachlässigen), was für den highway-area-Teil dann eine Relation
erfordert.


> Ich zeichne deshalb auch immer nur eine Fahrtrichtung ein, und überlasse es
> dem Nutzer, die STVO-konforme Fahrbahnteilfläche zu nutzen.


Wenn man sehr penibel ist kann man auch ähnlich den Bus-Relationen
eine Hin- und eine Rückrichtung machen.

Gruß Martin

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

Re: [Talk-de] nudism=designated

[M∡rtin Koppenhoefer]

Am 29. Juni 2011 00:25 schrieb Stephan Wolff :
>> http://www.openstreetmap.org/browse/node/287134792
> Das ist ein node mit 3 tags:


besser als ein Node wäre eine area

Gruß Martin

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

Re: [Talk-de] Hausnummern und Zufahrt

[M∡rtin Koppenhoefer]

Am 28. Juni 2011 19:45 schrieb fly :
> Wenn das nur private Zufahrten sind (highway=service):

und service=driveway
und access=private/permissive/(destination)

Gruß Martin

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

Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?

[M∡rtin Koppenhoefer]

Am 28. Juni 2011 09:07 schrieb Chris66 :

> Ok, laut Wiki dürfen mit pedestrian auch Plätze getaggt werden, die
> keine echten (Zeichen 242) Fussgängerzonen sind.


highway=pedestrian ist eine Straße, die von Ausnahmen (z.B. Lieferung)
abgesehen für Fußgänger ist. Mit area=yes wird es zur Fußgängerfläche
(ggf. kann man bicycle=yes und anderes ergänzen, je nachdem, wie es
vor Ort geregelt ist). "Zonen" gibt es bisher meines Wissens in OSM
nicht, und ich sehe auch nicht, wozu man das brauchen sollte. Eine
Zone ist ein Gebiet aus mehreren pedestrians und ergibt sich von
selbst.

Gruß Martin

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

Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed

[M∡rtin Koppenhoefer]

2011/6/28 André Joost :
> Am 27.06.11 20:22, schrieb malenki:
>
>>
>> proposed != construction
>>
>
> Leider steht im aktuellen Mapnik-Stil:
>
>>  &maxscale_zoom12; &minscale_zoom12; ([highway] =
>> 'proposed' or [highway]='construction') and
>> ([construction]='motorway' or
>> [construction]='motorway_link')


--> http://trac.openstreetmap.org

Gruß Martin

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

Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?

[M∡rtin Koppenhoefer]

Am 27. Juni 2011 20:51 schrieb Chris66 :
> Am 27.06.2011 20:18, schrieb M∡rtin Koppenhoefer:
>
>> ein weiterer mittiger Weg ist überflüssig. M.E. ist das tagging mit
>> highway=footway für diese Flächen nicht ganz optimal, würde pedestrian
>> vorschlagen.
> -1
> Es sei denn die Flächen sind als "echte" Fussgängerzone ausgeschildert.


wieso? M.E. ist ein footway was kleines, die Startbahn auf einem
Verkehrsflughafen als footway auszuzeichnen oder footway für Flächen
zu verwenden finde ich seltsam. Im Endeffekt ergibt sich die Größe
allerdings aus der Größe ;-)

Gruß Martin

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

Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?

[M∡rtin Koppenhoefer]

Am 27. Juni 2011 19:37 schrieb Jan Torben Heuer :
> Ich würde gerne die Flächen um routingfähige Wege erweitern, weis aber nicht
> wie. Es müssten ja quasi für den Renderer unsichtbare Wege sein die dann aber
> doch von OSM-Routing engines verstanden werden als Wege. Im moment sieht das
> Routingergebnis so aus: http://derp.co.uk/37b0b.info
>
> Ich würde statt die eingehenden Wege mit der Asphaltfläche zu connected lieber
> auf den Asphalt mittig einen Weg legen. Jemand eine Idee wie ich das dann
> korrekt Taggen müste?


ein weiterer mittiger Weg ist überflüssig. M.E. ist das tagging mit
highway=footway für diese Flächen nicht ganz optimal, würde pedestrian
vorschlagen. Wenn die Flächen an allen Stellen wo sie auf Wege treffen
mit denen verbunden sind, dann wird mit normalen Routern jetzt schon
damit geroutet (allerdings an den Kanten entlang und nicht in der
Mitte), d.h. da muss man eigentlich nichts mehr dran machen.

Wie Peter auch schrieb: da müsste am Router gearbeitet werden, nicht
an der Karte.

Gruß Martin

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

Re: [Talk-de] Luftbilder für JOSM

[M∡rtin Koppenhoefer]

Am 27. Juni 2011 15:42 schrieb Steffen Heinz :
> Am 27.06.2011 15:21, schrieb fly:
> funktionier nicht an allen Stellen :( dann muss das Gebiet "Abfotografiert"
> werden (mit einem entsprechenden Tool) dann und nur dann kann es verkleinert
> werden, gedreht verzerrrt usw
> (gerade in "meinem" Gebiet ist das bei ca 50% der Satellitenbilder
> erforderlich)


m.E. kann man die Bilder mal ein bisschen rumschieben und hoffen, dass
sie dann besser passen, aber drehen und verkleinern/vergrößern,
stauchen und ähnliches halte ich nicht für sinnvoll. Das wird nie ganz
stimmen. Wenn die Bilder schlecht weiterverarbeitet wurden, dann sind
die Fehler die aus dieser Verarbeitung stammen, jetzt fest in den
Fotos drin. Entweder man schätzt sie noch für brauchbar ein, oder man
sucht sich bessere ;-)

Gruß Martin

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

Re: [Talk-de] ebook-Karte auf Kindle

[M∡rtin Koppenhoefer]

Am 27. Juni 2011 13:51 schrieb Barthwo :
> Das oben erwähnte Garmin GPSmap 60 kenne ich nicht, aber vielleicht ist das
> Verhalten bei Sonnenlicht bei dem ja besser als bei dem IBEX.


wenn Deine Beschreibung des IBEX zutrifft dann ist das Garmin 60 um
Längen besser: ich hatte noch nie Probleme bei Sonnenlicht, im
Gegenteil ist es da sogar besser ablesbar. Leider gibt es nichts
Vergleichbares mehr von Garmin mit schnellerem Chip (das 62 ist
ziemliche Grütze m.E. und Touchscreen will ich auch nicht bei einem
GPS) (Bedienung mit Handschuhen, "blind", Schutz vor versehentlicher
Bedienung, etc.).

Gruß Martin

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

Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed

[M∡rtin Koppenhoefer]

Am 27. Juni 2011 17:29 schrieb Manuel Reimer :
>> Sollten nicht eher diejenigen ein Spezialoverlay erstellen, die die
>> Daten sehen wollen und nicht diejenigen, die es nicht sehen wollen?
>
> Klar sollte das. Schon weil man mit einem Overlay erheblich leichter Daten
> einfügen als überpinseln kann.


ja, am besten wir liefern weisse tiles aus, dann kann jeder das
überblenden, was er haben will ;-)


> Wenn wirklich jemand unbedingt die geplanten Trassen auf openstreetmap.de
> haben muss, dann kann ich mich gerne daran versuchen, da einen passenden
> OpenLayers-Layer für zu basteln. Wäre das fest auf die Tiles gerendert,
> taugen diese nicht mehr für das Anzeigen einer Karte ohne diese Elemente.


Overlays sorgen leider auch für viele Probleme: verdeckte Elemente/
Beschriftungen, schlechteres Antialiasing, Erhöhung des
Speicherbedarfs und der Downloadzeit (overhead), ...

Nicht dass ich falsch verstanden werde: geplante Straßen müssen m.E.
nicht unbedingt sein, aber grundsätzlich sind Overlays keine
gleichwertige Lösung zu einem dedizierten Stil. "Spezialoverlays" sind
halt ein schwammiger Begriff: für den einen gehören z.B. geplante
Autobahnen zum Standardset einer Straßenkarte, für andere ist das
"Spezialzeugs". Auf eine gemeinsame Linie werden wir hier vermutlich
nie kommen, d.h. ganz jedem kann man es nicht Recht machen.

Gruß Martin

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