[Talk-de] Umweltzonen?

[Steffen Grunewald]

Guten Morgen,

da die Umweltzonen im Vormarsch sind: gibt es schon Karten, die sie
auswerten?

Steffen

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

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

[Martin Koppenhoefer]

Am 23. August 2011 21:19 schrieb Dimitri Junker :
>>Bing war nicht gemeint ;-)
> Verrat doch einfach welche Satbilder wir nutzen dürfen die so genau sind.


in Italien nutze ich die Bilder vom PCN, in Spanien liegen auch gute
Bilder vor, in Frankreich Katasterdaten, in England glaube ich mich zu
erinnern, dass sie OS nutzen dürfen, in Deutschland gibt es wohl jetzt
teilweise von Aerowest Bilder, in den USA gibt es sowieso schon immer
gute Bilder, ...
sicherlich ist das noch nicht überall, aber es gibt viele Stellen, wo
gute Luftbilder vorliegen und genutzt werden dürfen.


> Nein, es muß nur für alle Straßen die Breite eingegeben werden. Ein Wald
> geht bei allen Straßen bis zu deren Rand nicht bei einer zur Mittellinie.


"muss für alle Straßen eine Breite angegeben werden": Breiten habe ich
bisher fast nie an Straßen gesehen, an Wegen schon eher. Nicht dass
ich das ausschließen will, dass wir da demnächst viel eintragen,
bisher gibts das nicht oft. Es gibt auch wie erwähnt keine Festlegung
bisher, wie man Gehwegbreiten, Bankett, Graben und Fahrbahn jeweils
taggen soll, bzw. worauf sich z.B. width bezieht (evtl. die reine
Fahrbahnbreite?).


> Ich wiederhole mich ungern, wenn die Flächengrenze nur über ihre Relation
> zur Straße bekannt ist, also nicht unabhängig mit hoher Genauigkeit
> vermessen wurde sollte sie so an die Straße gekoppelt sein, daß sie bei
> einer Korrektur der Straße automatisch mitkorrigiert wird. Und das geht
> derzeit mit vertretbarem Aufwand in OSM nur dadurch, daß man die Fläche an
> die Straße packt.


gibt es in Deutschland überhaupt noch so grob gezeichnete Straßen,
dass man bei einer Korrektur gleich die Flächen mitändern muss? Wenn
ich Flächen zeichne verfeinere ich die Straßen bei Bedarf an der
Stelle gleich mit.


>>In OSM würde dann die Telefonzelle im Park stehen, eigentlich steht sie
>>aber auf der Straße.
> Nein, denn wenn der Abstand Straßenmittellinie - Telefonzelle kleiner ist
> als die Straßenbreite wird sie in der Straße gerendert, nur in Josm wo die
> Straße eine Linie ist scheint sie im Park zu liegen. Aber wer Josm nutzt
> sollte das soweit verstanden haben, daß es ihn nicht verwirrt.


Topologisch liegt sie erstmal im Park --- wenigstens solange wir uns
nicht global darauf verständigen, dass Flächen nicht das bezeichnen
was sie umschließen, sondern dass man da erstmal noch analysieren
muss, ob eine Straße angrenzt, deren halbe Breite man dann schätzen
und abziehen muss.

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

[Garry]

Am 23.08.2011 21:19, schrieb Dimitri Junker:

Hallo,



Eher geschätzt und aus dem Bezug zu anderen Dingen (Fluchtlinien,
Formen, relative Position, etc.) abgeleitet, was schon ein bisschen was
anderes ist.


Leider nicht, Es wäre dann OK wenn diese Relation erhalten bliebe. Um beim
Standardbsp zu bleiben, wenn Du gemessen oder geschätzt hast, daß der
Waldrand 20m westlich der Straßenmitte ist kanst Du nicht einfach dort eine
neue Linie zeichnen, denn wenn später jemand erkennt, daß die Straße ungenau
getagt war und diese verschiebt bleibt der Waldrand an der falschen Stelle.
Dann kommt jemand anderes der den Waldrand korrigiert. In der Praxis ist 
es doch so dass der Waldrand
nicht konstant der Mittellinie folgt sondern einen eigenen Verlauf hat 
der durchaus auch der Orientierung dienen kann.



Bing war nicht gemeint ;-)


Verrat doch einfach welche Satbilder wir nutzen dürfen die so genau sind.
Manche Städte/Gemeinden haben hochaufgelöste, georeferenzierte 
Luftbilder zur Nutzung für OSM
zur Verfügung gestellt. Eine allgemeine Veröffentlichung der Links dazu 
ist aber nicht unbedingt gewünscht

um die Server nicht zu überlasten.




könnte man evtl. machen


Wir nähern uns



wobei es evtl. ein Problem gibt, wenn man eine Fläche an mehrere Straßen
angeschlossen hat


Nein, es muß nur für alle Straßen die Breite eingegeben werden. Ein Wald
geht bei allen Straßen bis zu deren Rand nicht bei einer zur Mittellinie.
Es gibt auch asymetrische Strassen mit z.B. 2+1Fahrstreifen, da wird man 
sich dann streiten
ob die Mittellinie in der geometrischen Mitte oder der 
"Richtungstrenner" ist.




Was genau verliert man denn, wenn man die Fläche nicht verbindet?


Ich wiederhole mich ungern, wenn die Flächengrenze nur über ihre Relation
zur Straße bekannt ist, also nicht unabhängig mit hoher Genauigkeit
vermessen wurde sollte sie so an die Straße gekoppelt sein, daß sie bei
einer Korrektur der Straße automatisch mitkorrigiert wird. Und das geht
derzeit mit vertretbarem Aufwand in OSM nur dadurch, daß man die Fläche an
die Straße packt.
Die Information zur Genauigkeit ist doch vielfach überhaupt nicht 
vorhanden. Wer einen GPS-Track
aufzeichnet sieht doch durch den Track gar nicht wie sich die Umgebung 
verhält. Warum soll er

deswegen die angerenzenden Flächen mitverschieben?




In OSM würde dann die Telefonzelle im Park stehen, eigentlich steht sie
aber auf der Straße.


Nein, denn wenn der Abstand Straßenmittellinie - Telefonzelle kleiner ist
als die Straßenbreite wird sie in der Straße gerendert, nur in Josm wo die
Straße eine Linie ist scheint sie im Park zu liegen. Aber wer Josm nutzt
sollte das soweit verstanden haben, daß es ihn nicht verwirrt.

Und wieder das Stichwort asymetrische Strassen...



De fakto hat man an Kreuzungen aber fast immer Sondersituationen (die
Flächen weichen abgerundet zurück, um der Straße mehr Platz zu geben,
ist auch ein Nebenschauplatz zugegebenermaßen).

Wenn wir mal so genau messen reden wir weiter.
Gerade an Kreuzungen weicht der Wald häufig erheblich zurück und gibt 
dadurch auch deutliche Orientierungshilfen aus der Luft.


Garry

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

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

[Dimitri Junker]

Hallo,


>Eher geschätzt und aus dem Bezug zu anderen Dingen (Fluchtlinien,
>Formen, relative Position, etc.) abgeleitet, was schon ein bisschen was
>anderes ist.


Leider nicht, Es wäre dann OK wenn diese Relation erhalten bliebe. Um beim 
Standardbsp zu bleiben, wenn Du gemessen oder geschätzt hast, daß der 
Waldrand 20m westlich der Straßenmitte ist kanst Du nicht einfach dort eine 
neue Linie zeichnen, denn wenn später jemand erkennt, daß die Straße ungenau 
getagt war und diese verschiebt bleibt der Waldrand an der falschen Stelle.

>Bing war nicht gemeint ;-)


Verrat doch einfach welche Satbilder wir nutzen dürfen die so genau sind.


>könnte man evtl. machen


Wir nähern uns


>wobei es evtl. ein Problem gibt, wenn man eine Fläche an mehrere Straßen
>angeschlossen hat


Nein, es muß nur für alle Straßen die Breite eingegeben werden. Ein Wald 
geht bei allen Straßen bis zu deren Rand nicht bei einer zur Mittellinie.


>Was genau verliert man denn, wenn man die Fläche nicht verbindet?


Ich wiederhole mich ungern, wenn die Flächengrenze nur über ihre Relation 
zur Straße bekannt ist, also nicht unabhängig mit hoher Genauigkeit 
vermessen wurde sollte sie so an die Straße gekoppelt sein, daß sie bei 
einer Korrektur der Straße automatisch mitkorrigiert wird. Und das geht 
derzeit mit vertretbarem Aufwand in OSM nur dadurch, daß man die Fläche an 
die Straße packt.


>In OSM würde dann die Telefonzelle im Park stehen, eigentlich steht sie
>aber auf der Straße.


Nein, denn wenn der Abstand Straßenmittellinie - Telefonzelle kleiner ist 
als die Straßenbreite wird sie in der Straße gerendert, nur in Josm wo die 
Straße eine Linie ist scheint sie im Park zu liegen. Aber wer Josm nutzt 
sollte das soweit verstanden haben, daß es ihn nicht verwirrt.

>De fakto hat man an Kreuzungen aber fast immer Sondersituationen (die
>Flächen weichen abgerundet zurück, um der Straße mehr Platz zu geben,
>ist auch ein Nebenschauplatz zugegebenermaßen).


Wenn wir mal so genau messen reden wir weiter.

>sieht aber vermutlich auch ein bisschen komisch aus, wenn man dann
>rechtwinklig bis zur eigentlichen Position, wo die Fläche beginnt nicht
>mehr parallel zu laufen, erstmal einen Sprung machen muss, oder?


muß man nicht, das kann der Renderer automatisch machen.

Gruß
Dimitri

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

Re: [Talk-de] Android

[Dimitri Junker]

Hallo,

Nach vielem testen, googeln,... ist der Stand jetzt der: es gibt kein 
Navit.xml, man kann dies aber aus den apk extrahieren, da gibt es 3 je nach 
Bildschirmauflösung. Wenn ich dort den Pfad ändere und es nach sdcard/navit 
kopiere wird dies bei Download ignoriert. Aber zur Anzeige der Karte wird es 
wohl ausgewertet, aber so, daß bei mir keine Karte mehr angezeigt wird.

Für heute habe ich genug von Navit

trotzdem Danke
Dimitri


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

Re: [Talk-de] GPS-Tracks als WMS?

[Sebastian Klemm]

Hallo Christian,

Am 23.08.2011 22:24, schrieb Christian Knorr:
> fast perfekt :) Danke schonmal. Aber mir fehlt die Möglichkeit alle Tracks 
> auf 
> einmal zu sehen, in einer Übersichtskarte.

Ja, steht seit längerem auf der Todo-Liste.
Bisher fehlte noch die richtige Idee das ganze auch schnell genug
hinzubekommen - eine Reduzierung der Trackpoints reicht leider nicht.
Ein Vorausberechnen von transparenten Tiles war mir bisher zu aufwändig
bzgl. der nötigen Einarbeitung...

Grüße
Sebastian

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

Re: [Talk-de] GPS-Tracks als WMS?

[Christian Knorr]

(Sorry, Quoting tuts nicht)

Hallo Sebastian,
fast perfekt :) Danke schonmal. Aber mir fehlt die Möglichkeit alle Tracks auf 
einmal zu sehen, in einer Übersichtskarte. Meine Software (injooosm) ist nicht 
performat genug für sowas, weil dann alle Tracks immer wieder neu berechnet 
werden (um die Trackpunkte zu bestimmen). Deshalb kam mir die Idee mit dem 
Layer.

Chris...

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

Re: [Talk-de] GPS-Tracks als WMS?

[Sebastian Klemm]

Hallo Christian,


Am 12.08.2011 20:45, schrieb Christian Knorr:
> Ich würde gerne einen Layer 
> erzeugen, damit ich meine gefahrenen Kilometer über die OpenStreetMap legen 
> kann. Lokal (auf dem HeimServer) reicht mir.

Wenn Dir eine "selbstgestrickte" Webanwendung (PHP/MySQL) mit OpenLayers
reicht, kannst Du phpMyGPX probieren:
http://phpmygpx.tuxfamily.org/

> Ein Einmal-Durchlauf sollte es nicht werden. Ich würde gerne am Wochenende 
> die 
> (Tages-)Tracks in einen Ordner schmeißen, der überwacht wird und dann die 
> Kacheln upgedatet werden.

Ein einfacher Batch-Import ist möglich.

Grüße,
Sebastian

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

Re: [Talk-de] Android

[Michael von Glasow]

Michael Zimmermann wrote:

On Mon, 15 Aug 2011 02:04:14 +0200
Dimitri Junker  wrote:

Das erhöht den Aufwand für die Portierbarkeit auf andere Systeme...


Wieso? Was meinst Du mit anderes System? Dieser fixe Pfad ist ja wohl ser
Systemspeziefisch, also wäre eine Pfadauswahl doch wohl Systemunabhängiger.
Und wenn da wirklich ein Programmierer Probleme hat eine Pfadauswahl
einzubauen dann könnte man ja ein einfaches Konfigurationsfile nutzen. So
ist es unbrauchbar!


Die Karten samt Pfaden sind in der navit.xml hinterlegt, und die 
unterscheidet sich ohnehin schon von Plattform zu Plattform. Auf Windows 
CE ist beispielsweise ein Kartenausschnitt von München im Paket 
enthalten und konfiguriert...



Hi,
dann suche mal nach navit.xml (configfile)
darin dann nach maps und passe dir den Pfad an

hab aber keine Ahnung wo das auf einem Android liegt


Im APK-File; soweit ich weiß, wird das irgendwohin extrahiert und dann 
diese Kopie benutzt (würde auf /data tippen).


Ansonsten gibt es die Möglichkeit, eine eigene navit.xml auf der 
SD-Karte abzulegen, die dann Vorrang hat. Die muss auf der SD-Karte 
unter /navit/navit.xml liegen. In der kannst Du dann jeden beliebigen 
Pfad für die Kartendaten konfigurieren. Haken an der Sache: ob das mit 
der navit.xml auch funktioniert, wenn die SD-Karte nicht als /sdcard 
gemounted ist, weiß ich nicht...


Im navit-Bugtracker sind zwei Tickets offen, um Navit auf SD 
installieren zu können [1] [2] und so auch ohne Rooting an die 
Konfigurationsdateien zu kommen.


Wenn das alles nichts hilft, bleibt Dur nichts anderes, als noch ein 
Ticket aufzumachen und auf die Problematik hinzuweisen. Evtl. kann man 
ja, anstatt den Pfad /sdcard hart zu codieren, den tatsächlichen Pfad 
aus der Systemkonfiguration auslesen (z.B. aus der mtab). Irgendwie 
müssen ja auch andere Android-Apps mitbekommen, welchen Pfad die SD bzw. 
der integrierte Speicher hat, also muss das irgendwo hinterlegt sein...


Michael

[1] http://trac.navit-project.org/ticket/818
[2] http://trac.navit-project.org/ticket/918


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

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

[Joerg Fischer]

Christian Müller wrote:

> Am 22.08.2011 20:30, schrieb Joerg Fischer:
> >Das fiel mir nur auf weil das Routing von openrouteservice
> >und meinem Garmin merkwürdig und unlogisch war.  Da waren dann residentials
> >und footways übereinander gelegt, Parkpätze und Fußgängerzonen und IIRC
> >sogar Gebäude, alle fröhlich auf gemeinsamen Nodes.

> Das ist total off-topic, sorry.

Nein. Deine Empfehlungen zum Editieren führen IMHO genau da hin.

> Beispiel, wo es richtig wäre:  Stelle Dir zwei parallele Straßen
> vor, zwischen denen sich ein Marktplatz befindet.  Du willst doch
> sicher auch, dass ein Router den Weg über den Marktplatz findet,
> wenn dieser zu den Straßen hin nicht baulich getrennt, sprich offen
> ist.  Würdest Du den Marktplatz nicht an die Straßen kleben, gäbe es
> für den Router keine Verbindung.

Ich lege zwischen die beiden Straßen einen highway=service, und zwar da, wo
üblicherweise die Belieferung des Marktes erfolgt.  An den kann ich dann
sogar dran schreiben für welche Art von Fahrzeugen der Markt befahrbar ist,
und eine ungefähre Geschwindigkeit, usw.  Routing quer über Flächen ist
übrigens ein großes Problem, lies mal das Archiv der Mailingliste.  Die
Chancen das _Deine_ Lösung mit den meisten Routern nicht funktioniert sind
hoch.  Was soll ein Navi an der Stelle eigentlich ansagen?  "Fahren Sie im
Winkel von 22° nach rechts, achten sie auf heute möglicherweise
herumstehende Verkaufsbuden, versuchen Sie dann am Ende des Marktes die
Gasse zu treffen."

> >>   ) um einen node in mehrere ways einzufügen - node zeichnen, "J" drücken
> >>   ) um durch mehrere mögliche "overlapping ways" zu wechseln - eine der
> >>Tasten "/" "#" "*" probieren
> >>   ) siehe   http://wiki.openstreetmap.org/wiki/Potlatch_2/Shortcuts
> >>   ) know your editor..
> >Und das findest Du intuitiv und fehlerfrei? Auch für Anfänger? Ich nicht.
> Du mischt hier zwei paar Schuhe zusammen.

Ich mische gar nichts, das sind exakt Deine Empfehlungen!

> Leuten, die ihren Editor offenbar nicht kennen, nur die Hilfen an
> die Hand gegeben, die sie schon längst hätten mal lesen sollen - der

Du, meine ersten Edits sind aus dem Frühjahr 2007, ich weiß so ungefähr was
ich tue.

> urteilen, ob das gerechtfertigt war.  Aber vielleicht hast Du ja
> tatsächlich erfolgreich Mapper verdrängt, welche die Datenqualität
> in deinem Gebiet erhöht auf längere Sicht erhöht hätten.  Weiß man

Du möchtest die Ebene sachlicher Diskussion nun verlassen?

> Wie wäre es mit Bäumen+Typbestimmung?

Ich seh schon, wir brauchen eine Relevanzdiskussion. Kannst Du Dir
möglicherweise vorstellen, das nicht alle Daten die irgendwie einen
Zusammenhang mit Koordinaten haben, gleich nach OSM gehören?

> indoor-routing (teilweise schon begonnen).

Fällt Dir eine praktische Anwendung dafür ein? Fluchtpläne in der Oper oder
so? Relevanz für OSM?

> Gebieten mit guten Sat-Bildern auf lange Sicht Straßenlampen,

Ok.

> Gulli-Deckel

Wozu? Nur weil es theoretisch geht?

Jörg

-- 
There are only 10 types of people in the world:
Those who understand binary, and those who don't...


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

Re: [Talk-de] Android

[Michael Zimmermann]

On Mon, 15 Aug 2011 02:04:14 +0200
Dimitri Junker  wrote:

> Hallo,
> 
> >Das erhöht den Aufwand für die Portierbarkeit auf andere Systeme...
> 
> 
> Wieso? Was meinst Du mit anderes System? Dieser fixe Pfad ist ja wohl ser 
> Systemspeziefisch, also wäre eine Pfadauswahl doch wohl Systemunabhängiger. 
> Und wenn da wirklich ein Programmierer Probleme hat eine Pfadauswahl 
> einzubauen dann könnte man ja ein einfaches Konfigurationsfile nutzen. So 
> ist es unbrauchbar!
Hi,
dann suche mal nach navit.xml (configfile)
darin dann nach maps und passe dir den Pfad an

hab aber keine Ahnung wo das auf einem Android liegt
Hab hier ein netbook

micha

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

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

[Martin Koppenhoefer]

Am 23. August 2011 14:41 schrieb Frederik Ramm :
> On 08/23/11 14:41, Christian Müller wrote:
>> Da OSM keine Katasterkarte ist und vermutlich auch nicht sein wird, hat
>> /für mich/ topologisch korrektes Mappen (also wie stehen Objekte in
>> Bezug zu anderen Objekten) einen wesentlich höheren Stellenwert, als das
>> submetergenaue Taggen der Flächenausdehnungen von Flächen, deren Grenzen
>> nicht klar definiert sind und nur durch amtliche Bestätigung überhaupt
>> eine Belastbarkeit erfahren würden.


Rechtlich belastbar müssen die Grenzen ja auch nicht sein (dafür gibt
es die amtlichen Katasterkarten), den Anspruch habe ich auch nicht.
Topologisch korrektes Mappen finde ich auch *sehr* wichtig, daher
würde ich am liebsten die Straßenflächen auch als solche drin haben,
dann würde sich die Diskussion erübrigen, bis wo man Flächen zeichnet.
Die Graphen haben aber auch viel Wert, so dass man wohl irgendwann
beides haben wird (gibt es z.T. ja schon, wird sicherlich nicht
flächendeckend weltweit sein, aber in Städten durchaus denkbar).


> ich hatte schon mit einer Reihe von Leuten zu tun,
> die vollen Zugriff auf Katasterkarten hatten und *trotzdem* lieber zu OSM
> gegriffen haben.


klar, je nachdem, was man machen will, sind Katasterkarten u.U. ungeeignet.

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

[Georg Feddern]

Moin,

Christian Müller schrieb:

Am 23.08.2011 02:26, schrieb Martin Koppenhoefer:

Gemeint war:
Flächenausdehnungen bewusst falsch zu zeichnen.


[...]

Falls OSM doch irgendwann zur Katasterkarte mutiert, also fast alles 
als Flächen erfasst wird, erübrigt sich der Wunsch nach korrekter 
Topologie innerhalb der Basisgeometrie, die wäre dann automatisch 
gegeben.  Dann wird aber vermutlich ein linienhafter Routing-Layer 
übrig bleiben, der nicht mitgerendert wird.  Damit hätten wir dann 
auch die Routing-Leute von den Flächenerfassern getrennt,  *freu*.




+1
Schöner Traum - schade dass auch ich gerade wieder aufgewacht bin ... ;-)



ich halte es für einen Irrweg, der weitere Verfeinerungen erschwert 
und dem Mapper der dort etwas ändern will unnötige Komplikationen 
bereitet.


Andere halten das für einen sehr guten Weg, der ihnen das 
Editieren/Programmieren/Abbilden erleichtert und zudem die Qualität 
der Daten  erhöht.


Nachdem ich im Laufe der Zeit beide Varianten selber ausprobiert habe 
und je nach Gegebenheit beim Weiterbearbeiten der Daten Anderer bereits 
ausgiebig über beide Varianten geflucht habe ;-)besteht mein 
derzeitiger Kompromiß darin, die Variante je nach Gegebenheit zu wählen.
Unscharf begrenzte Flächen wie residential, industrial klebe ich 
durchaus an die "begrenzende" Straße.
Andere, eher scharf begrenzte Flächen wie Weide- oder Ackerflächen, die 
durch Zaun oder Knick zur Straße begrenzt sind oder neben einem 
ländlichen baulich getrennten straßenbegleitenden Fuß-/Radweg liegen, 
klebe ich dagegen nicht an den Weg.

Von daher dürfen also gerne beide Lager über mich herziehen. ;-)

Gruß
Georg

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

Re: [Talk-de] coastline/ maperitive - Unterschied Daten vonxapioder aus germany.osm

[André Joost]

Am 23.08.11 13:55, schrieb Jan Jesse:



Deine Erklärung mit den Polygonen leuchtet ein. Dann scheint das
Fluten Norddeutschlands unvermeidlich, da ich recht große Gebiete
ausschneide (0.5x0.5 °). Auf einer Länge von 100 km wird bestimmt
keine konstistente Küstenlinie da sein. Was kann ich da tun? Du
sagtest, Mapnik nutze spezielle Shapefiles. Sind die irgendwo zu
bekommen?


Sicher doch, ist hier erklärt:





Ich meine gelesen zu haben, dass man so was dann einfach
konvertieren kann.

Dann könnte ich die coastline aus meiner *.osm rausschneiden, und
eine intakte einsetzen. Oder liege ich da auch gleich wieder falsch?


Ich weiß jetzt nicht, was maperitive mag und was nicht. Ich bin 
irgendwann mal von Kosmos auf Mapnik umgestiegen, weil es um Längen 
besseren Output liefert. Ausserdem passt in die Datenbank viel mehr rein 
als Maperitive oder andere selber verwalten können. Da ich tief im 
Binnenland wohne, habe ich mit den Küstenlinien allerdings noch nie 
Konflikte gehabt.


Die Küstenlinie wird nicht aus den Rohdaten ausgeschnitten und ersetzt, 
sondern einfach ignoriert ;-) und stattdessen die Shapefiledaten 
benutzt. Einfach umwandeln und untermischen könnte problematisch werden, 
wenn sich originäre und konvertierte OSM-IDs dann in die Quere kommen. 
Deswegen habe ich mir z.B. die externen SRTM-Höhendaten in eine eigene 
parallele Datenbank geschaufelt.


Gruß,
André Joost




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

Re: [Talk-de] Baut Yorii Fantasiewelten?

[André Joost]

Am 23.08.11 14:25, schrieb Frederik Ramm:

Hallo,

On 08/23/11 12:11, Dimitri Junker wrote:

Ist da mittlerweile was passiert?


Er hat nicht geantwortet.


Ich hatte ihm auch geschrieben, und er hatte mir damals
zurueckgeschrieben, dass er nicht gewusst habe, dass das auf der Karte
direkt erscheint, und was er denn tun muesse, um es wieder zu loeschen.



Hier hat auch einer seinen Spieltrieb ausgelassen:



Sollte man mal drauf achten, ob das sein einziger edit bleibt.

Gruß,
André Joost


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

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

[Martin Koppenhoefer]

Am 23. August 2011 13:10 schrieb Dimitri Junker :
>>allgemein in der Diskussion mit Leuten, die gerne die Details in OSM
>>begrenzen wollen:
> Ich will nichts begrenzen, die Begrenzung kommt durch die Meßungenauigkeit.
> Ich habe im Physikstudium gelernt, daß es Unsinn ist Details anzugeben die
> unter der Meßungenauigkeit liegen. Details unter 10m sind also in OSM meist
> geraten.


Eher geschätzt und aus dem Bezug zu anderen Dingen (Fluchtlinien,
Formen, relative Position, etc.) abgeleitet, was schon ein bisschen
was anderes ist.


>>gute Luftbilder
> So genau sind die auch nicht, weder die Auflösung und schon garnicht ihre
> Georeferenzierung.


Bing war nicht gemeint ;-)


> Was hälst Du davon: Man gibt der Fläche eine zusätzliche Eigenschaft:
> street_border=middle
> oder
> street_border=outer
> oder von mir aus auch Prozentzahlen,...


könnte man evtl. machen (wobei es evtl. ein Problem gibt, wenn man
eine Fläche an mehrere Straßen angeschlossen hat). Eine Alternative
wäre, den Bezug über eine Relation herzustellen. M.E. braucht man
gemeinsame Nodes bei Flächen eher selten (ausser highway-Areas, die
oft allerdings sowieso schon Schnittpunkte haben), d.h. ich sehe das
eher als Ausnahme, und daher wäre m.E. die Relation angemessen.

Was genau verliert man denn, wenn man die Fläche nicht verbindet? M.E.
ist das Verbinden halt ein bisschen willkürlich, weil immer wird man
es sowieso nicht machen können: Sobald es einen begrenzenden Zaun oder
eine Hecke gibt, muss die Fläche m.E. dort aufhören.

Auch das Telefonkabinenbeispiel zeigt m.E., dass man dann dafür andere
topologische Fehler einbaut. Z.B. ein Park, der bis zur Straße
gezeichnet ist, wo aber eine Telefonzelle auf dem Gehweg steht. In OSM
würde dann die Telefonzelle im Park stehen, eigentlich steht sie aber
auf der Straße.


> So würde man das Datenmodell einfach halten, würde unnötige Probleme beim
> Mappen verhindern hätte aber alle Details enthalten.


alle Details hätte man nur, wenn sich nichts auf der Straße befindet
und der Straßenrand jederzeit identisch mit der Flächenbegrenzung
wäre, und die Straßenbreite eingetragen ist. Dann müsste man "nur"
noch für alle Flächen jeweils die Straßen abziehen damit man die
Flächengröße bekommt. De fakto hat man an Kreuzungen aber fast immer
Sondersituationen (die Flächen weichen abgerundet zurück, um der
Straße mehr Platz zu geben, ist auch ein Nebenschauplatz
zugegebenermaßen).


> Weicht die Fläche
> irgendwo vom Straßenrand ab wird sie natürlich durch zusätzliche Nodes
> markiert, da die nicht zu einer Straße gehören braucht es dort auch keine
> Breitenangabe.


sieht aber vermutlich auch ein bisschen komisch aus, wenn man dann
rechtwinklig bis zur eigentlichen Position, wo die Fläche beginnt
nicht mehr parallel zu laufen, erstmal einen Sprung machen muss, oder?


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

[Frederik Ramm]

Hallo,

On 08/23/11 14:41, Christian Müller wrote:

Da OSM keine Katasterkarte ist und vermutlich auch nicht sein wird, hat
/für mich/ topologisch korrektes Mappen (also wie stehen Objekte in
Bezug zu anderen Objekten) einen wesentlich höheren Stellenwert, als das
submetergenaue Taggen der Flächenausdehnungen von Flächen, deren Grenzen
nicht klar definiert sind und nur durch amtliche Bestätigung überhaupt
eine Belastbarkeit erfahren würden.


Ich sehe das aehnlich; ich hatte schon mit einer Reihe von Leuten zu 
tun, die vollen Zugriff auf Katasterkarten hatten und *trotzdem* lieber 
zu OSM gegriffen haben.


Bye
Frederik

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

[Talk-de] OSM in Tagesschau-Berichterstattung Libyen

[Claudius]

Tagesschau.de verwendet eine OSM-basierte, kommentierte Übersichtskarte 
von Tripolis in der Libyen-Berichterstattung: 
http://www.tagesschau.de/ausland/libyen1280-magnifier_pos-1.html


Quellenhinweis zu www.OpenStreetMap.org ist vorhanden, nur die 
CC-BY-SA-Lizenzangabe fehlt meines Erachtens.


Claudius


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

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

[Christian Müller]

Am 23.08.2011 02:26, schrieb Martin Koppenhoefer:

Gemeint war:
Flächenausdehnungen bewusst falsch zu zeichnen.


Schon wieder "falsch" ;-).  Wir haben fast keine Möglichkeit, die 
Flächenausdehnung korrekt zu erfassen - OSM ist keine Katasterkarte.  
Hier ist warum:


1) Oft wissen wir nicht, wem Land gehört, das auf Luftbildern zu sehen 
ist - das wäre für die Flächenausdehnung aber wichtig, denn oft endet 
die Fläche und ihre Nutzung mit der Grundstücksgrenze.  Solche Daten 
können wir mit dem Anspruch auf Korrektheit bestenfalls vom Amt einholen.


2) Das Abschätzen einer Fläche per Luftbild hat keine 
Vermessungsgenauigkeit.  Selbst genaues Abzeichnen führt damit nicht zur 
Belastbarkeit der Daten (für amtliche/rechtliche/sonstige Zwecke) - 
damit stellt sich die Frage, welchen Mehrwert genaues Abzeichnen hat, 
auch im Zshg. mit 1)


3) Tags in OSM präzisieren oft gar nicht, wo genau eine Fläche aufhört.  
D.h. das Datenmodell (vgl. Frederiks mail) schreibt nicht in letzter 
Instanz vor, was "richtig" oder "falsch" im Sinne des Datenmodells ist.  
Z.B. wird ein Wohngebiet als "landuse=residential" kodifiziert, aber es 
gibt keine genauere Definition dazu, in welchen Grenzen ein Wohngebiet 
existiert.  Es wird weder definiert, dass wir uns dabei an irgendeine 
amtliche Katasterkarte halten, noch, dass wir überhaupt nur Gebiete als 
"Wohngebiet" taggen, die amtlich so gewidmet worden sind.  Ein Vergleich 
amtl. Katasterkarten mit OSM-Daten wird hier erstaunliche Differenzen zu 
Tage treten lassen.



Wir stellen fest, dass es also einen Interpretationsspielraum gibt.  In 
dem Sinne kannst Du nicht davon sprechen, dass es "falsch" wäre, Flächen 
bis zur Straße auszudehnen.  Das könntest Du doch überhaupt erst dann, 
wenn Einigkeit über die Grenzen bestünde, sprich eine Definition dazu 
durch Konsens entstanden wäre.


Im Sinne des Datenmodells kann eben die Aussage "das Wohngebiet wird 
durch die Straße begrenzt" selbst dann richtig sein, wenn dort noch ein 
Graben und eine Leitplanke dazwischen ist.  Solange es keine genauere 
Grenzdefinition von Gebieten durch das Datenmodell gibt, entscheiden wir 
durch Mapping-Praxis was evtl. mal Teil des fortlaufend spezifizierten 
Datenmodells wird.


Da OSM keine Katasterkarte ist und vermutlich auch nicht sein wird, hat 
/für mich/ topologisch korrektes Mappen (also wie stehen Objekte in 
Bezug zu anderen Objekten) einen wesentlich höheren Stellenwert, als das 
submetergenaue Taggen der Flächenausdehnungen von Flächen, deren Grenzen 
nicht klar definiert sind und nur durch amtliche Bestätigung überhaupt 
eine Belastbarkeit erfahren würden.


Falls OSM doch irgendwann zur Katasterkarte mutiert, also fast alles als 
Flächen erfasst wird, erübrigt sich der Wunsch nach korrekter Topologie 
innerhalb der Basisgeometrie, die wäre dann automatisch gegeben.  Dann 
wird aber vermutlich ein linienhafter Routing-Layer übrig bleiben, der 
nicht mitgerendert wird.  Damit hätten wir dann auch die Routing-Leute 
von den Flächenerfassern getrennt,  *freu*.



Grüßle,
Christian



ich halte es für einen Irrweg, der weitere Verfeinerungen erschwert und dem 
Mapper der dort etwas ändern will unnötige Komplikationen bereitet.


Andere halten das für einen sehr guten Weg, der ihnen das 
Editieren/Programmieren/Abbilden erleichtert und zudem die Qualität der 
Daten  erhöht.





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

Re: [Talk-de] Baut Yorii Fantasiewelten?

[Frederik Ramm]

Hallo,

On 08/23/11 12:11, Dimitri Junker wrote:

Ist da mittlerweile was passiert?


Er hat nicht geantwortet.


Ich hatte ihm auch geschrieben, und er hatte mir damals 
zurueckgeschrieben, dass er nicht gewusst habe, dass das auf der Karte 
direkt erscheint, und was er denn tun muesse, um es wieder zu loeschen.


Ich habe das dann aber aus irgendeinem Grund verlegt. Sorry. Das bloede 
ist, dass bei seinen Edits ja auch ein paar sinnvolle dabei zu sein 
schienen.


Ich schreibe ihn nochmal an und frage, was denn genau alles nur gespielt 
war. Dann loesche ich das.


Bye
Frederik

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

Re: [Talk-de] coastline/ maperitive - Unterschied Daten vonxapioder aus germany.osm

[Jan Jesse]

Hi,

> Welche Parameter hast du denn bei osmosis benutzt?

... omitmetadata - autsch. Hätte ich lesen können, dass da Version und 
Timestamp dazugehören. Elender Geiz. Danke.

Deine Erklärung mit den Polygonen leuchtet ein. Dann scheint das Fluten 
Norddeutschlands unvermeidlich, da ich recht große Gebiete ausschneide (0.5x0.5 
°). Auf einer Länge von 100 km wird bestimmt keine konstistente Küstenlinie da 
sein. Was kann ich da tun? Du sagtest, Mapnik nutze spezielle Shapefiles. Sind 
die irgendwo zu bekommen? Ich meine gelesen zu haben, dass man so was dann 
einfach konvertieren kann. 

Dann könnte ich die coastline aus meiner *.osm rausschneiden, und eine intakte 
einsetzen. Oder liege ich da auch gleich wieder falsch?

JJ





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

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

[Christian Müller]

Hi Jörg,

Am 22.08.2011 20:30, schrieb Joerg Fischer:

Das fiel mir nur auf weil das Routing von openrouteservice
und meinem Garmin merkwürdig und unlogisch war.  Da waren dann residentials
und footways übereinander gelegt, Parkpätze und Fußgängerzonen und IIRC
sogar Gebäude, alle fröhlich auf gemeinsamen Nodes.


Das ist total off-topic, sorry.  Deine Aussage stellt klar, dass hier 
Dinge zusammengebaut wurden, die _nicht_ zusammengehören.  Um die geht 
es uns nicht.  Wenn das routing nicht mehr funktioniert, wurden ganz 
klar Dinge geklebt, die nicht zusammengehören.


Beispiel, wo es richtig wäre:  Stelle Dir zwei parallele Straßen vor, 
zwischen denen sich ein Marktplatz befindet.  Du willst doch sicher 
auch, dass ein Router den Weg über den Marktplatz findet, wenn dieser zu 
den Straßen hin nicht baulich getrennt, sprich offen ist.  Würdest Du 
den Marktplatz nicht an die Straßen kleben, gäbe es für den Router keine 
Verbindung.




   ) um einen node in mehrere ways einzufügen - node zeichnen, "J" drücken
   ) um durch mehrere mögliche "overlapping ways" zu wechseln - eine der
Tasten "/" "#" "*" probieren
   ) siehe   http://wiki.openstreetmap.org/wiki/Potlatch_2/Shortcuts
   ) know your editor..

Und das findest Du intuitiv und fehlerfrei? Auch für Anfänger? Ich nicht.
Du mischt hier zwei paar Schuhe zusammen.  Es ging nicht darum, ob ich 
einen Editor intuitiv finde, sondern ob/wann ich Daten als qualitativ 
gut, sprich topologisch richtig, einstufe.  Ich habe Leuten, die ihren 
Editor offenbar nicht kennen, nur die Hilfen an die Hand gegeben, die 
sie schon längst hätten mal lesen sollen - der Programmierer schreibt 
doch so etwas nicht umsonst.




Und ich habe, wie schon beschrieben, bereits eine Menge solcher wilden
Konstrukte aufgelöst.


Da Du hier von mir gänzlich unbekannten Daten sprichst, ich also nicht 
weiß, was Du wo "aufgelöst" hast, kann ich auch nicht urteilen, ob das 
gerechtfertigt war.  Aber vielleicht hast Du ja tatsächlich erfolgreich 
Mapper verdrängt, welche die Datenqualität in deinem Gebiet erhöht auf 
längere Sicht erhöht hätten.  Weiß man nicht.  Dass sich niemand 
beschwert hat, muss ja nicht heißen, dass es alle gut fanden.  Auf jeden 
Fall hättest Du die Mapper, die für das falsche routing verantwortlich 
waren, pers. anschreiben können (vor oder nach edit)  ;-)




   Meist fällt das erst auf wenn man sich die Stelle
bei keepright anguckt oder weil das Routing nicht klappt und mich der
Garmin irgendwohin schickt wo ich garantiert nicht hin wollte.  Zu viele
Mapper erfassen im Stil von: "Hauptsache es sieht danach optisch auf der
Karte doll aus."


Es sollte "optisch doll" und korrekt.  Für mich ist das kein 
Widerspruch.  Wenn das routing nicht klappt, ist auch nicht richtig 
gemappt worden - oder der Router ist Schrott.




Was fehlt Dir denn noch, dass es den Datenbestand mehr als ein paar Prozent
vergrößern wird?


Wie wäre es mit Bäumen+Typbestimmung?  Wie wäre es mit indoor-routing 
(teilweise schon begonnen).  Oder gleichbleibend gutem Erfassungsstand 
in allen Gebieten?  Millionen von buildings dürften fehlen, weil sie 
nicht gerade in einer Gegend liegen, wo Microsoft Material gekauft 
hat..  Ich schätze außerdem, dass in den Gebieten mit guten Sat-Bildern 
auf lange Sicht Straßenlampen, Gulli-Deckel etc. zu finden sein werden, 
sowie, tada, als Flächen erfasste Straßen (vgl. river - riverbank)



Ja, aber ich denke immer noch, verbundene Wege erhöhen gerade die 
Komplexität.


der Rechnung ja, nicht aber des Speicherplatzes.



Gruß
Christian

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

Re: [Talk-de] Baut Yorii Fantasiewelten?

[Chris66]

Am 23.08.2011 12:11, schrieb Dimitri Junker:
> Hallo,
> 
>> Ist da mittlerweile was passiert?
> 
> 
> Er hat nicht geantwortet.
> 
>> Hat jemand eine Sperrung beatragt?
> 
> 
> Wie?

Meldung an die Data Working Group, aber nur bei schweren Fällen,
z.B. wenn Herr Yorii sein Welten nach Löschung neu aufbauen würde.







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

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

[Dimitri Junker]

Hallo,


>allgemein in der Diskussion mit Leuten, die gerne die Details in OSM
>begrenzen wollen:


Ich will nichts begrenzen, die Begrenzung kommt durch die Meßungenauigkeit. 
Ich habe im Physikstudium gelernt, daß es Unsinn ist Details anzugeben die 
unter der Meßungenauigkeit liegen. Details unter 10m sind also in OSM meist 
geraten.


>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

So genau sind die auch nicht, weder die Auflösung und schon garnicht ihre 
Georeferenzierung.

>sich nicht sklavisch nach dem GPS zu richten, s.z.B. relative
>Genauigkeit).


Endlich sind wir uns einig. "Die Fläche beginnt am Straßenrand und die 
Straße ist 3m breit" ist relativ und funktioniert gut
"Die Straßenmittellinie ist hier und die Fläche beginnt dort" sind 2 
absolute nicht miteinander verbundene Aussagen, funktioniert also nicht.

Was hälst Du davon: Man gibt der Fläche eine zusätzliche Eigenschaft:
street_border=middle
oder
street_border=outer


oder von mir aus auch Prozentzahlen,...

Ist eine Fläche mit street_border=outer getagt meckert JOSM wenn eine der 
Grenzen eine Straße ist deren Breite unbekannt ist.

So würde man das Datenmodell einfach halten, würde unnötige Probleme beim 
Mappen verhindern hätte aber alle Details enthalten. Weicht die Fläche 
irgendwo vom Straßenrand ab wird sie natürlich durch zusätzliche Nodes 
markiert, da die nicht zu einer Straße gehören braucht es dort auch keine 
Breitenangabe.

Gruß
Dimitri

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

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

[Dimitri Junker]

Hallo,


>Mir ist sehr wohl bewusst, dass das ein Kompromiss sein soll, um die
>Flächen mit dem Modell der Straßen in Einklang zu bringen, aber ich
>halte es für einen Irrweg, der weitere Verfeinerungen erschwert


Nein ist es nicht, es gibt 2 Methoden die beide ihre Vor und Nachteile 
haben. Was Du vorhast ist beide zu vermischen, das gibt Chaos. Entweder wir 
bauen ganz OSM auf Flächen oder gleich 3D um dann aber auch Straßen,... oder 
wir lassen es wie es ist. Mit den uns zur Verfügung stehenden 
Meßverfahrenist die derzeitige Methode besser. Wenn eine Fläche an eine 
Straße grenzt hat sie eine gemeinsame Grenze mit der Straße. Wird die Straße 
auch als Fläche getagt ist alles klar. Wird die Straße als Linie getagt muß 
diese auch als Flächengrenze dienen. Man könnte es natürlich wie bei Flüssen 
machen, also ggf Mittellinie und Ufer Taggen, aber den Mehrnutzen sehe ich 
da bei normalen Straßen (solche wo der Rand parallel zur Mittellinie läuft) 
nicht.

>und dem Mapper der dort etwas ändern will unnötige Komplikationen
>bereitet.


Das mußt Du mir erklären, wenn ich z.B. eine Waldfläche bis zur Straße habe 
und will einen zusätzlichen Waldweg eintragen lege ich den Weg über den Wald 
und füge einen Kreuzungsknoten mit der Straße ein, der ist dann zwar auch 
Teil der Waldgrenze, das stört aber nicht. Bei Deiner Methode müßte ich den 
Wald aufschneiden, also 3 parallele Wege erzeugen, müßte sehr weit 
reinzoomen um nicht fälschlich den Kreuzungsnode mit dem Waldrand statt der 
Straße einzufügen.
Anderes Bsp.: Ich mappe eine Straße und stelle fest, die ist schon in OSM 
drin, aber ungenau. Also füge ich zusätzliche Nodes in die Straße ein. 
Grenzt jtzt eine Fläche an diese Straße wird diese automatisch mit 
verfeinert. Da der Mapper durch das Anfügen an die Straße die Aussage 
gemacht hat, daß sie bis an die Straße reicht ist das OK. Läuft die Grenze 
aber mehr oder weniger parallel zur Straße weiß ich nicht, ob da jemand die 
Grenze wirklich unabhängig gemappt hat, ich sie also nicht anfassen sollte, 
es sei denn ich mappe sie getrennt von der Straße erneut. Also lasse ich sie 
wie sie ist. Dummerweise wird es dann wahrscheinlich stellen geben wo die 
neu gemappte Straße die Flächengrenze kreuzt. Was mache ich da? Staht da 
wirklich noch ein Baum des Waldes oder ein Haus der Siedlung auf der anderen 
Straßenseite, dann muß ich die Fläche teilen oder wurde die Flächengrenze 
einfach Pi mal Daumen parallel zur Straße gezeichnet, dann sollte ich sie 
mitverschieben. Also auch hier zusätzliche Arbeit und Fehlermöglichkeiten.

Gruß
Dimitri

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

Re: [Talk-de] Baut Yorii Fantasiewelten?

[Dimitri Junker]

Hallo,

>Ist da mittlerweile was passiert?


Er hat nicht geantwortet.

>Hat jemand eine Sperrung beatragt?


Wie?

Gruß
Dimitri

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

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

[Dimitri Junker]

Hallo,

>wieso sollte man es beim Rendern dem Zufall (der
>Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört?

bei der 1-Linien Methode sollte der Renderer sie immer bis an die Straße 
zeichnen egal wie breit er die Straße zeichnet, man sieht also immer, daß 
die Fläche bis an die STraße reicht. Bei der 2 Linienmethode wird in hohen 
Zoomstufen die Straße ja meist zu schmal gezeichnet, es entstünde also eine 
Lücke zwischen Straße und Fläche die falsch ist, bei niedrigen Zoomstufen in 
denen Straßen zu breit gezeichnet werden würde sie in die Straße reinragen.


>(wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt)


Also für jemanden der die Wirklichkeit möglichst genau abbilden will wäre es 
ja wohl das letzte eine Straße in hohem Zoomlevel als Haarlinie zu zeichnen.
Straßen haben über lange Strecken eine konstante Breite. Es ist also 
leichter diese als Tag zu setzen als die Straßenränder einzeln zu mappen. 
Die Straßenbreite durch abzählen der Schritte beim Überqueren messen ist 
genauer als per GPS beide Ränder zu mappen. Für die Straße ist es also 
besser bei der 1-Linienmethode zu bleiben.
Renderer: Straßen werden immer über Flächen gezeichnet -> es macht keinen 
sichtbaren Unterschied ob die Fläche bis zur Straßenmitte oder bis zum 
Straßenrand gezeichnet wird.

Sonstige Auswertungen. Willst Du wissen wie groß Dein Grundstück ist 
solltest Du einen Lageplan bei der Stadt holen, dafür ist OSM eh zu ungenau.

Wenn irgendwann in ferner Zukunft GPS o.ä. genau genug wird damit es Sinn 
macht Straßenränder zu mappen könnte man Tools schreiben die automatisch die 
Straßenlinie aufblähen. Dabei könnte dann auch definiert werden welche 
Flächen danach bis zum Straßenrand und welche zur Straßenmitte gehen sollen. 
Wälder zum Straßenrand, Ortsgrenzen bis zur Straßenmitte aber ggf mit 
Nachfrage,... Haben wir dann schon parallele Flächengrenzen wird es 
komplizierter.

Gruß
Dimitri

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

Re: [Talk-de] coastline/ maperitive - Unterschied Daten von xapioder aus germany.osm

[André Joost]

Am 23.08.11 11:17, schrieb Jan Jesse:



Was ich sehe, ist die richtige Küstenlinie, die wir uns jetzt mal als
Schlangenlinie vorstellen. Außerdem gibt es scheinbar eine weitere
Küstenlinie, stark vereinfacht eine Gerade, die unsere Schlangenlinie
natürlich regelmäßig kreuzt.


Ja, das entsteht eben, wenn aus einem geschlossenen Polygon einige 
Elemente fehlen. Da werden Anfangs/Endpunkte der vollständigen Wege 
einfach miteinander verbunden. Die Linie ist aber in den Daten nicht 
"da", sondern nur beim Renderer, wenn er die Polygone zusammensetzen will.


Welche Parameter hast du denn bei osmosis benutzt?

Gruß,
André Joost





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

Re: [Talk-de] coastline/ maperitive - Unterschied Daten von xapioder aus germany.osm

[Jan Jesse]

Hi,


> Von: André Joost [mailto:andre+jo...@nurfuerspam.de]
> Hi,
> 
> Versuch es mal mit der europe.osm.pbf und schneide selber aus, mit den
> diversen Optionen, die osmosis bietet.
> 

Genau das habe ich, soweit ich es eben verstanden habe, schon getan. Keine 
Abhilfe.

Auf den gerenderten Tiles sind auch eindeutig Küstenlinien zu sehen, und eine 
Überflutung aufgrund einer Lücke kann ausgeschlossen werden (auch nicht hinten 
herum).

Was ich sehe, ist die richtige Küstenlinie, die wir uns jetzt mal als 
Schlangenlinie vorstellen. Außerdem gibt es scheinbar eine weitere Küstenlinie, 
stark vereinfacht eine Gerade, die unsere Schlangenlinie natürlich regelmäßig 
kreuzt. Dadurch werden die Flächen jeweils zwischen beiden Küstenlinien zu 
Inseln, die Flächen außerhalb zu Wasser. M.E. wird hier richtig gerendert, aber 
die Daten sind falsch. Genauer gesagt, die vermutete stark vereinfachte 
Küstenlinie gehört da nicht hin, oder meine styles greifen da was unsinniges ab.

Und mein Problem: Ich bekomme diese (gerade) Küstenlinie nicht zu sehen.

Frage: Kann mir jemand die osmosis-Optionen nennen, die es erlauben, einen 
Ausschnitt zu generieren, den JOSM auch einliest? Das was ich da produziert 
habe, hat scheinbar keine Versionsnummern mehr, und wird von JOSM abgelehnt ...

Grundlage wäre wie vorgeschlagen europe.osm.pbf

Und noch eine Frage: Wenn die unterstellte gerade Küstenlinie da sein sollte, 
müsste ich sie dann nicht auch in den Daten, die die XAPI-liefert, zu sehen 
bekommen?

JJ

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