> On 8. Apr 2018, at 10:00, Florian Lohoff <f...@zz.de> wrote: > On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote: >>> Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr >>> Von: "Florian Lohoff" <f...@zz.de> >> >> Wenn das width-tag fehlt, wird je nach >> Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.
sorry, errechnet wird da dann gar nichts, es wird geraten / geschätzt, weil man ja auch mit lanes getaggt keine Angaben zur Spurbreite hat, genauso wenig wie Straßenklassen feste Breiten haben. > > Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch > und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und > hatte das nie zu tun. > es war mit mapnik lange Zeit nicht möglich, Stileigenschaften parametrisch zu definieren (z.B. die Linienbreite aus der Datenbank zu nehmen), soweit ich weiß geht das jetzt aber. In Qgis geht es z.B. sicher. > Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an > den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real > erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu > tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das > als Fläche separat erfassen. solange die Breite unverändert gleich bleibt geht es schon mit einer Linie und Breitenangabe, nur wenn die Breite sich halt ändert wird es schwierig. Plätze waren in OSM z.B. historisch sehr lange schlecht repräsentiert/abbildbar, quasi waren sie zunächst vergessen worden, weil es eben um die Verbindungen ging, und weniger um die Form. > Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe > ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei > egal welcher Genauigkeit einfach topologisch falsch ist und bleibt. so hart würde ich es nicht sagen, weil man m.E. durchaus auch für das Verbinden argumentieren könnte, wenn es vorwiegend um ein vereinfachtes Topologiemodell ginge und man keine Details unterhalb des landuse levels hätte und wollte. Ich kenne OSM auch noch aus Zeiten vor der Verfügbarkeit von guten Luftbildern, als man noch ausschließlich mit Notizen, Fotos und GPS gearbeitet hat, bzw. gab es schon grobpixelige Yahoo bilder mit zig Metern Lageungenauigkeit (und es gab Mapper, die alles mühsam erarbeitete auf diesen Luftbildern „zurechtschob“, ähnlich wie heute mit Bing, nur auf anderem Video), und ich war auch damals schon dagegen , beim Flächenzeichnen eine Abkürzung zu nehmen, von der klar war, dass sie das Eintragen von weiteren Details ziemlich erschweren würde. >> (OSM war >> /ist ein Hobbyprojekt, ein Projekt von und für die crowd nicht wahr?) > > Also bisher hatte ich immer (>10 Jahre) die Möglichkeit auf Rechnern zu > Arbeiten die die OSM Daten verarbeiten konnten. Ich habe lange für QA > Zwecke OSRM Instanzen laufen gehabt die den ganzen Tag routen getestet > haben etc. Ich habe mal ein auf PostgreSQL/PostGIS basierendes Datenbankend > für > osmarender gebaut. So abwegig ist das mit den OSM Daten zu arbeiten nicht. +1, es ist (war) eher die Komplexität der einzelnen tools und Abhängigkeiten und der Aufwand, alles mögliche einzurichten, die viele m.E. davon abgehalten haben, selbst Dinge mit den Daten zu machen, als die Hardwareanforderungen. Hobbyisten haben meistens keinen Bedarf an weltweiten detaillierten Daten, vielen reicht ein regionales Gebiet aus für ihre Bedürfnisse (danke Geofabrik und andere), und das dauert selbst auf schmalbrüstiger, veralteter Konsumerhardware nicht soo lang, das durchzuwursten. Auch wenn für sich genommen die einzelnen Schritte nicht so schwer sind, so sind es oft doch einige. Es gibt und gab aber immer auch schon rel. simple tools (in der Bedienung ) mit denen man schon sehr viel machen kann, z.B. maperitive, osmarender, overpass turbo, und mittlerweile sind auch klassische GIS tools wie QGis gut auf OSM vorbereitet. > >> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten, >> heute scheinbar nicht mehr so wichtig. Vor zehn Jahren gab es schon noch >> ein paar mehr Leute, denen es wichtig war, dass die Gesamtdaten auch auf >> kleine Geräte passten und dort verarbeitbar waren. um die Daten auf kleine Geräte zu packen kann man sie bearbeiten / filtern und bei Bedarf die Genauigkeit reduzieren. Das sollte kein Argument sein, um absichtlich weniger in die db einzutragen als man eigentlich gut fände. Gruß, Martin _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
