You are not logged in.

#126 2015-09-06 16:58:28

RadFr
Member
Registered: 2014-08-14
Posts: 609

Re: Update OSM Carto

Jojo4u wrote:

Ich kann nicht ganz nachvollziehen warum die Änderung bezüglich Wald/Wasser auf Zustimmung stößt. Landuse ist großflächig. Kleine Parkplätze, Springbrunnen, Weiher werden ja auch nicht aus landuse=residential ausgeschnitten, oder?

Ich kenne das so, dass landuse und natural, egal in welcher Reihenfolge, ausgestanzt werden, amenity und leisure dagegen nicht.
Genauso sind Gebäude auf einer Fläche highway=* + area=yes auszustanzen. Das dies auch für landuse und natural gilt ist selbstredend.

Offline

#127 2015-09-06 17:57:52

free_as_a_bird
Member
Registered: 2010-01-26
Posts: 171

Re: Update OSM Carto

mboeringa wrote:

Gerne, weil ich sicher sei, hier sind einige Missverständnisse
...
Möglicherweise..., aber ESRI hat der kostenlose ArcGIS Editor for OpenStreetMap, und kann damit auch selbst einfach Extrakte einer Region machen. Auch unterstützt es dem Einfügen von ein *.osm XML file in ein File Geodatabase, und produziert dabei auch Multipolygonen.

Danke für den für Hinweis auf ArcGIS Editor for OpenStreetMap und die ausführlichen Erklärungen!

Offline

#128 2015-09-06 18:10:09

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,621
Website

Re: Update OSM Carto

RadFr wrote:

Ich kenne das so, dass landuse und natural, egal in welcher Reihenfolge, ausgestanzt werden, amenity und leisure dagegen nicht.
Genauso sind Gebäude auf einer Fläche highway=* + area=yes auszustanzen. Das dies auch für landuse und natural gilt ist selbstredend.

Wenn du möchtest, kann du das ja als Highlight von OSM begreifen. Dieses Alleinstellungsmerkmal der Geometriebehandlung gibt es wohl nur bei uns.
Versuche das mal jemanden begreiflich zu machen, der sich täglich mit GIS-Systemen beschäftigt. Dem schlackern dann nur die Ohren und er muss sich die Augen reiben.

Das einzige Argument, was ich hier von den "Verteidigern" höre, ist "das war schon immer so". Toll, damit gewinnt man selbstverständlich jede Diskussion.

Gruss
walter

Offline

#129 2015-09-06 18:17:46

RadFr
Member
Registered: 2014-08-14
Posts: 609

Re: Update OSM Carto

wambacher wrote:
RadFr wrote:

Ich kenne das so, dass landuse und natural, egal in welcher Reihenfolge, ausgestanzt werden, amenity und leisure dagegen nicht.
Genauso sind Gebäude auf einer Fläche highway=* + area=yes auszustanzen. Das dies auch für landuse und natural gilt ist selbstredend.

Wenn du möchtest, kann du das ja als Highlight von OSM begreifen. Dieses Alleinstellungsmerkmal der Geometriebehandlung gibt es wohl nur bei uns.
Versuche das mal jemanden begreiflich zu machen, der sich täglich mit GIS-Systemen beschäftigt. Dem schlackern dann nur die Ohren und er muss sich die Augen reiben.

Das einzige Argument, was ich hier von den "Verteidigern" höre, ist "das war schon immer so". Toll, damit gewinnt man selbstverständlich jede Diskussion.

Ich verteidige hier gar nichts. Was ist denn die Alternative? Die Flächen wieder per layer zu stapeln, was man immer noch findet.

BTW, warst Du nicht mal der große Zampano in Sache touching_inner?

Offline

#130 2015-09-06 18:49:32

slint
Member
Registered: 2008-12-22
Posts: 140

Re: Update OSM Carto

Ich find das Problem liegt einfach an den Grunddatenstrukturen. Multipolygone sind halbherzig über Relationen gelöst und noch viel halbherziger in den Editoren unterstützt. Ein Flächentyp als eine der Grunddatenstrukturen neben Nodes und Linien wäre da meiner Meinung nach sinnvoller. Auch versteh ich nicht so ganz warum die Punkte von einer Linie selbst wieder Nodes sein müssen, aber das ist eine andere Diskussion.

Offline

#131 2015-09-06 20:10:10

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: Update OSM Carto

slint wrote:

Auch versteh ich nicht so ganz warum die Punkte von einer Linie selbst wieder Nodes sein müssen, aber das ist eine andere Diskussion.

Darüber ist keine (lange) Diskussion notwendig. Ist ganz einfach: Nur die Nodes besitzen Koordinaten und stellen so den Verlauf der Linie dar.

Offline

#132 2015-09-06 20:29:35

slint
Member
Registered: 2008-12-22
Posts: 140

Re: Update OSM Carto

Man könnte auch statt einer Liste von Verweisen auf Nodes mittels Node ID eine Liste von Koordinaten machen (Eine Node ID ist genauso 64 bit groß bei OSM wie eine Koordinate wenn man effizient speichert)

Offline

#133 2015-09-06 20:40:40

Garmin-User
Member
Registered: 2009-10-01
Posts: 645

Re: Update OSM Carto

slint wrote:

Man könnte auch statt einer Liste von Verweisen auf Nodes mittels Node ID eine Liste von Koordinaten machen (Eine Node ID ist genauso 64 bit groß bei OSM wie eine Koordinate wenn man effizient speichert)

Gut, benötigt weniger Speicherplatz. Durch die Referenzierung direkt auf die Nodes ist aber sichergestellt, dass verbundene Wege einen eindeutigen gemeinsamen Node haben. Getrennt gehaltene Koordinaten wären durch Rundungsfehler nicht verbindbar oder würden bei Überlappungen falsch verbunden werden können. (Oder zusätzliche Strukturen sind wieder notwendig, um Verbindungen auszudrücken.)

Offline

#134 2015-09-06 22:57:31

Nakaner
Moderator
From: Karlsruhe
Registered: 2011-09-03
Posts: 2,945
Website

Re: Update OSM Carto

mboeringa wrote:

ESRI inc., der Entwickler des Format "Shapefile", hat sich schon zehn(!) Jahre her verabschiedet von dieses Data Format, weil es nicht länger ausreichte (nur 2GB max, die Name der Felder nur 10 Karakter, keine RDBMS "relations" möglich). Stattdessen, gibt es File Geodatabase, mit 1TB/Feature Class Limit und altere "Goodies" für GIS.

Ich weiß wirklich nicht, warum Shapefile in Open Source Community, bisher so viel genutzt wird. ESRI hat ein kostenlose API (für Software Entwickler, sehe auch diesen ESRI Blog Beitrag) zur Verfügung, zum arbeiten mit File Geodatabase... QGIS unterstützt File Geodatabase heute, aber viele andere Projekte nicht. Keine Ahnung warum, obwohl File Geodatabase offensichtlich ein Bißchen mehr Kompliziert ist (dafür ist aber auch der API).

Für die Leute, die in diesem Thread zum ersten Mal von File Geodatabase gelesen haben:

Die API mag zwar kostenlos sein, aber sie ist nicht frei. Würden wir auf die Freiheit sch***, würden wir alle Google Maps verwenden und keiner wäre Mapper beim OpenStreetMap-Projekt.

File Geodatabase ist ein unfreies Format, das deshalb auch nur von ganz wenigen freien Programmen gelesen werden kann.

Viele Grüße

Michael


Werdet Mitglied in der OSM Foundation und bestimmt über die Zukunft der Foundation und des Projekts mit. Ab 42 Mappingtagen in den letzten 365 Tagen ist es kostenlos. Jetzt beitreten ("Active Contributor Membership")!
Moderator im Bereich users: Austria

Offline

#135 2015-09-08 15:14:23

Tirkon
Member
From: Ostfriesland / Germany
Registered: 2009-01-27
Posts: 291

Re: Update OSM Carto

wambacher wrote:

Das einzige Argument, was ich hier von den "Verteidigern" höre, ist "das war schon immer so". Toll, damit gewinnt man selbstverständlich jede Diskussion.

Stimmt nicht. Ich habe ausführlich begründet, warum die alte Form für OSM die bessere ist:
http://forum.openstreetmap.org/viewtopi … 91#p532191

Offline

#136 2015-09-08 15:55:29

chris66
Member
From: Germany
Registered: 2009-05-24
Posts: 9,832

Re: Update OSM Carto

slint wrote:

Ein Flächentyp als eine der Grunddatenstrukturen neben Nodes und Linien wäre da meiner Meinung nach sinnvoller.

Ist ja für API 0.7 angedacht, weiß aber nicht wie da der Stand ist.


Mapper aus dem Münsterland.

Offline

#137 2015-09-08 16:44:54

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,621
Website

Re: Update OSM Carto

Tirkon wrote:

Stimmt nicht. Ich habe ausführlich begründet, warum die alte Form für OSM die bessere ist:
http://forum.openstreetmap.org/viewtopi … 91#p532191

Ja, hast du. Meine Zusammenfassung dessen ist: "Es ist zu kompliziert für normale Mapper".

Das ist mit Verlaub auch eine Frage der Unterstützung durch die Editoren.
In Josm (ja, schon wieder - aber einen besseren Editor kenne ich halt nicht) ist ein Multipolygon mit zwei Klicks + einer Tastatureingabe erzeugt: Outer auswählen, Inner auswählen, STRG B und das war es schon. Hat noch nicht einmal weh getan.

Sollten das iD und Potlatch nicht können, sind die ein Problem. Und wenn sie es können um so besser.

Gruss
walter

Offline

#138 2015-09-08 17:07:15

Basstoelpel
Member
Registered: 2008-11-02
Posts: 1,061

Re: Update OSM Carto

wambacher wrote:

In Josm (ja, schon wieder - aber einen besseren Editor kenne ich halt nicht) ist ein Multipolygon mit zwei Klicks + einer Tastatureingabe erzeugt

Auch das finde ich noch eine sehr rudimentäre Unterstützung. Man muß wissen daß es MPs gibt und sie aktiv erstellen.
Würde der validator landuse Überlagerungen anmosern und ich davon ausgehen können, daß ein Klick auf (alles) Reparieren zuverlässig sinnvolle MPs erzeugt, dann hören die Beschwerden über komplizierte MPs vielleicht irgendwann mal auf.

Baßtölpel

Offline

#139 2015-09-08 17:48:50

Rogehm
Banned
From: Rösrath / Köln
Registered: 2014-05-07
Posts: 2,809

Re: Update OSM Carto

wambacher wrote:

Sollten das iD und Potlatch nicht können, sind die ein Problem. Und wenn sie es können um so besser.

Ein klacks mit Potlatch.  Neues MP mit 2 Teichen:
Waldstück anklicken > Advanced Mode: Add to: New Relation > Multipolygon auswählen > Role:outer > fertig (wer möchte, mit Namen... )
Teiche anklicken > Advanced Mode: Add to  > MP auswählen > Role:inner > fertig    ....  30 Sek für ein MP mit 2 Inner
ID: keine Ahnung     Hier sehe ich das größte Hindernis. Oder hat hier auch jemand eine schnelle Lösung?


Gruß   Rolf
“Ich kann freilich nicht sagen, ob es besser wird, wenn es anders wird. Aber soviel kann ich sagen: es muss anders werden, wenn es besser werden soll!”  Georg Christoph Lichtenberg (1742-1799)

Offline

#140 2015-09-08 17:49:21

Basstoelpel
Member
Registered: 2008-11-02
Posts: 1,061

Re: Update OSM Carto

Allein das Wort Multipolygon läßt die Leute das Konzept schwierig finden. Ich bin dafür, Up Goer Five-artige Sprache in OSM anzustreben. https://xkcd.com/1133/ Ein einfacheres Wort für MPs könnte Mehrfachflächen sein und MPs erstellen Flächen herausnehmen. Wenn wir unter uns sind, können wir ja weiter 1337 speaken.

Baßtölpel

Offline

#141 2015-09-08 22:00:44

Tirkon
Member
From: Ostfriesland / Germany
Registered: 2009-01-27
Posts: 291

Re: Update OSM Carto

Eines wurde offensichtlich noch nicht verstanden. Hier wird immer noch mit allen Mitteln versucht, den Mapper ein Multipolygon erzeugen zu lassen. Mir ist klar, dass man Dinge wie ÖPNV Linien nicht ohne Relationen erschlagen kann. Aber hier haben wir ein Problem, bei dem es bisher ohne Relationen und Multipolygone funktionierte. Warum soll man das Bilden der Multipolygone nicht demjenigen überlassen, der sie versteht, nämlich dem GIS Anwender. Es hilft auch nicht, wenn der Editor das Bilden der Multipolygone übernimmt, wenn der Mapper deren Wesen nicht versteht. Selbst wenn er diesen Editor bedienen lernt, hat er das Problem bei Änderungen,  bei dem er den Relationseditor und Relationen verstehen muss.

Bisher malte der Mapper einen Wald und dann den See, der darin liegt. Das war für ihn intuitiv. Es ist für ihn logisch, dass der Wald da aufhören muss, wo der See beginnt. Er hat damit mitgeteilt, was er über die Örtlichkeit weiß. Warum also muss er uns noch explizit mitteilen, dass im See kein Wald ist, und das bei jedem See im Wald aufs Neue? Als wenn das nicht genug wäre, fordern wir dazu das Verständnis eines Datenkonstuktes, den er ansonsten nicht braucht. Wozu? Um den Mapper mit unnötigem Firlefanz zu frusten? Denn wenn der alte Renderer das richtig interpretierte, kann es auch eine andere Software. Man könnte dafür Algorithmen angeben, so dass es dem GIS Datennutzer leichter fällt, dies richtig zu implementieren. Man könnte auch eine Datenbank vorhalten, in der alles GIS-gerecht von OSM abgeleitet ist, während es hier mappergerecht, also möglichst einfach zugeht.

Nicht nur bei diesem Problem sollte es unser zukünftiges Credo sein, das Mappen so einfach und intuitiv wie möglich zu gestalten, um möglichst vielen Mappern die Mitarbeit zu ermöglichen.

Last edited by Tirkon (2015-09-08 22:23:26)

Offline

#142 2015-09-08 23:22:57

Pfad-Finder
Member
Registered: 2010-02-11
Posts: 628

Re: Update OSM Carto

Tirkon wrote:

Nicht nur bei diesem Problem sollte es unser zukünftiges Credo sein, das Mappen so einfach und intuitiv wie möglich zu gestalten, um möglichst vielen Mappern die Mitarbeit zu ermöglichen.

Ich hätte es nicht besser ausdrücken können. Die hier im Forum versammelte Mapper-Elite wird nie in der Lage sein, abseits der eigenen Hotspots - wo inzwischen jeder HKTS gemappt ist - eine Basisabdeckung in der Fläche zu schaffen. Schon im Berliner Speckgürtel ist teilweise weniger als die Hälfte aller regelmäßig genutzten Waldwege erfasst! Das wird nur mit Hilfe von "Laienmappern" möglich sein, für die a) die Zugangshürden möglich niedrig sein sollten und b) möglichst bald ein Erfolgserlebnis sichtbar sein sollte. Bäume im See/Teich sind wahrscheinlich kein Erfolgserlebnis.

Offline

#143 2015-09-09 07:11:16

RadFr
Member
Registered: 2014-08-14
Posts: 609

Re: Update OSM Carto

Basstoelpel wrote:

Allein das Wort Multipolygon läßt die Leute das Konzept schwierig finden. Ich bin dafür, Up Goer Five-artige Sprache in OSM anzustreben. https://xkcd.com/1133/ Ein einfacheres Wort für MPs könnte Mehrfachflächen sein und MPs erstellen Flächen herausnehmen. Wenn wir unter uns sind, können wir ja weiter 1337 speaken.

Baßtölpel

Ändert es etwas, wenn das Wort geändert wird, nein.
Die Eindeutschung macht es auch nicht leichter. wink

Tretet mal den Leuten in den A..., die unnötige MPs und solche, die gar keine sind (MP mit 1 Element) produzieren. Wurde hier im Forum mehrfach angesprochen.

Offline

#144 2015-09-09 07:29:37

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,281
Website

Re: Update OSM Carto

Basstoelpel wrote:

Allein das Wort Multipolygon läßt die Leute das Konzept schwierig finden.

Ich würde mir ja zunächst saubere Begriffsdefinitionen wünschen...

http://www.opengeospatial.org/standards/sfa

Denn in vielen Fällen ist ein Multipolygon nicht das, was wir wollen (Wald-See-Problematik) sondern echte Polygone... Aber eh das soweit ist, wird noch viel Wasser die Spree herunterfließen... neutral

Sven

Offline

#145 2015-09-09 08:04:04

viw
Member
Registered: 2010-05-15
Posts: 2,623

Re: Update OSM Carto

streckenkundler wrote:
Basstoelpel wrote:

Allein das Wort Multipolygon läßt die Leute das Konzept schwierig finden.

Ich würde mir ja zunächst saubere Begriffsdefinitionen wünschen...

http://www.opengeospatial.org/standards/sfa

Denn in vielen Fällen ist ein Multipolygon nicht das, was wir wollen (Wald-See-Problematik) sondern echte Polygone... Aber eh das soweit ist, wird noch viel Wasser die Spree herunterfließen... neutral

Sven

Bei uns sind Multipolygone jene Dinge dies aus mehreren Elementen bestehen. Es ist dabei egal wieviele Flächen daraus nachher entstehen. Also wenn wie bei den Grenzen Ein land aus mehreren Wegen gebildet wird, ist das genauso ein Multipolygon wie wenn es nur ein Inner und ein Outer für einen Wald mit See gibt.

Offline

#146 2015-09-09 08:25:09

streckenkundler
Member
From: Lübben (Spreewald)
Registered: 2012-08-09
Posts: 4,281
Website

Re: Update OSM Carto

viw wrote:

Bei uns sind Multipolygone jene Dinge dies aus mehreren Elementen bestehen. Es ist dabei egal wieviele Flächen daraus nachher entstehen. Also wenn wie bei den Grenzen Ein land aus mehreren Wegen gebildet wird, ist das genauso ein Multipolygon wie wenn es nur ein Inner und ein Outer für einen Wald mit See gibt.

... und das ist das, was mich ärgert... Es spricht ja erst mal nichts dagegen, Polygone auf die eine oder andere Weise zu bilden.

OSM macht hier aber sein eigenes Ding, ohne sich an grundsätzliche Definitionen und Standards zu halten (vergleiche Datentypen-Definition bei: http://www.opengeospatial.org/standards/sfa...

Es wird immer von freien und offen Daten geredet und gerne mal gegen unfreie Dinge gewettert (was ja auch durchaus berechtigt ist), dann sollte man aber auch mal den Mut beweisen und OGC-konform werden, so daß die eigenen Daten frei und offen verwendet werden können...

sorry die Luft mußte mal raus...

Sven

Offline

#147 2015-09-09 08:58:47

Pfad-Finder
Member
Registered: 2010-02-11
Posts: 628

Re: Update OSM Carto

streckenkundler wrote:

OSM macht hier aber sein eigenes Ding, ohne sich an grundsätzliche Definitionen und Standards zu halten..

Es heißt Openstreetmap, nicht Openlandusemap. Da hat damals wahrscheinlich keiner dran gedacht. hmm

Last edited by Pfad-Finder (2015-09-09 08:59:04)

Offline

#148 2015-09-09 09:53:48

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,621
Website

Re: Update OSM Carto

Pfad-Finder wrote:

Es heißt Openstreetmap, nicht Openlandusemap. Da hat damals wahrscheinlich keiner dran gedacht. hmm

falls du das nicht ironisch meinst:

Ja, das sind Altlasten, die vor vielen Jahren ( ~10!) entstanden sind und die wir nicht so einfach los werden können. Zu der Zeit gab es wohl noch kein OGC und es wurde danach leider die Chanche vertan, rechtzeitig auf den OGC-Zug zu springen.

Jeder ahnt was von der API-0.7 aber keiner traut sich ran. Weil im Vergleich zur lange überfälligen Anpassung der OSM-Datenstruktur der Lizenzwechsel ein Klacks war.

Eines macht den Wechsel aber mMn "einfach": Das Ziel (OGC) ist klipp und klar definiert. Das ist ein internationaler Standard, an dem es nichts zu rütteln gibt. Man muss "nur noch" OSM darauf umstellen ohne das Rad neu erfinden zu müssen.

Irgendwie erinnert mich OSM an französische Autos. Alles ist irgendwie anders - sie fahren,  aber keiner weiss, warum wink

Gruss
walter

ps: Ich fragen mich schon seit Tagen, was dieser Thread eigentlich soll. Mapnik ist geändert und das bleibt so. Punkt.

Offline

#149 2015-09-09 14:00:21

Tirkon
Member
From: Ostfriesland / Germany
Registered: 2009-01-27
Posts: 291

Re: Update OSM Carto

wambacher wrote:

Eines macht den Wechsel aber mMn "einfach": Das Ziel (OGC) ist klipp und klar definiert. Das ist ein internationaler Standard, an dem es nichts zu rütteln gibt. Man muss "nur noch" OSM darauf umstellen ohne das Rad neu erfinden zu müssen.

Ich kenne als nichtberuflicher GIS-Mensch nur den OGC Grundgedanken aber nicht die Einzelheiten. Könntest Du beschreiben, was das für das praktische Mapping bedeutet? Wird es schwerer oder leichter? Sind da Multipolygone wie beim See im Wald zwingend? Hat es in OSM Diskussionen gegeben, OGC-kompatibel zu werden? 

Wir sind ein Projekt zur Erfassung von Geodaten per Community. Und daher muss es Community-gerecht bleiben, so dass größtmöglicher Input durch Mapper gegeben ist. Wenn OGC dazu im Widerspruch steht, dann kann es für die OSM-Datenbank nicht das Ziel sein. Es könnte dann höchstens eine zweite Datenbank abgeleitet werden, die OGC-kompatibel ist. Wenn OGC aber eine Erleichterung für Otto Normalmapper darstellt, dann kann ich Dir nur zustimmen.

wambacher wrote:

ps: Ich fragen mich schon seit Tagen, was dieser Thread eigentlich soll. Mapnik ist geändert und das bleibt so. Punkt.

Das muss nicht zwingend so bleiben. Das Thema Mapperfreundlichkeit muss dringend auf den nächsten Konferenzen thematisiert werden. Bisher habe ich das nur am Rande getan und einigen Zuspruch erfahren aber niemals Ablehnung. Aber wenn jetzt die Basiserfassung von Homeareas davon betroffen wird, muss das wohl mehr in den Vordergrund gerückt werden.

Last edited by Tirkon (2015-09-09 14:01:47)

Offline

#150 2015-09-09 15:27:39

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,621
Website

Re: Update OSM Carto

Tirkon wrote:

Könntest Du beschreiben, was das für das praktische Mapping bedeutet? Wird es schwerer oder leichter? Sind da Multipolygone wie beim See im Wald zwingend?

Schwierig zu sagen. Einfacher wird es bestimmt nicht aber anders. Wie das mit den Wälder mit landuse=* und den Seeen mit natural=water sein könnte, kann ich ehrlich gesagt auch nicht 100%-ig sagen. Wenn wir auch noch Layer in den Daten hätten, wäre das kein Problem mehr, aber das kann ich mir in den nächsten Jahren nicht vorstellen.

Hat es in OSM Diskussionen gegeben, OGC-kompatibel zu werden?

Es gibt die ewige Diskussion über die API v0.7, die ja alles besser machen soll. Inwiefern der Begriff OGC inzwischen da eingeflossen ist, muss ich mal nachsehen. Der dort besprochene AREA-Type wäre auf jeden Fall ein wichtiger Schritt in die Richtung.

Wir sind ein Projekt zur Erfassung von Geodaten per Community. Und daher muss es Community-gerecht bleiben, so dass größtmöglicher Input durch Mapper gegeben ist. Wenn OGC dazu im Widerspruch steht, dann kann es für die OSM-Datenbank nicht das Ziel sein.

Garbage in - Garbage out sagt man wohl dafür. Oder konkret an die Nicht-OSM-ler: "Wir erfassen alles was wir wollen, wir erfassen alles wie wir es wollen und wenn ihr was braucht, seht gefälligst selber zu, dass ihr das irgendwie aus OSM rausbekommt. Und kommt bloss nicht auf den Gedanken, dass das mit "euren" Programmen mal so eben geht."

Wenn das ohne Kompatibilität zur GIS-Welt so weitergeht, ist OSM bald die grösste Datenmüllhalde des Planeten.

Es könnte dann höchstens eine zweite Datenbank abgeleitet werden, die OGC-kompatibel ist. Wenn OGC aber eine Erleichterung für Otto Normalmapper darstellt, dann kann ich Dir nur zustimmen.

Nein, das halte ich nicht für sinnvoll. Das Synchronisieren der Dateninhalte - das wäre dann ein permanenter Datenstrom wie bei denn Diffs - kann langfristig nicht funktionieren. Eine v0.7-basierende DB sollte das nicht notwendig machen. Sollte - ich sage nicht "wird".

Ich suche derzeit Programme/Editoren, die im OGC-Umfeld sowas wie Josm können, bin aber noch nicht fündig geworden. QGIS und der Geoserver können sowas aber es gibt sicher noch mehr. Es sollte deren aber sehr viel mehr Systeme geben. Ist halt "Neuland" - auch für mich.

wambacher wrote:

ps: Ich fragen mich schon seit Tagen, was dieser Thread eigentlich soll. Mapnik ist geändert und das bleibt so. Punkt.

Das muss nicht zwingend so bleiben. Das Thema Mapperfreundlichkeit muss dringend auf den nächsten Konferenzen thematisiert werden. Bisher habe ich das nur am Rande getan und einigen Zuspruch erfahren aber niemals Ablehnung. Aber wenn jetzt die Basiserfassung von Homeareas davon betroffen wird, muss das wohl mehr in den Vordergrund gerückt werden.

Mapnik ist per se nur eine Demo-Anwendung, die dem Mapper und auch Nicht-OSM-lern zeigen soll, was man mit den OSM-Daten anstellen kann. Mapnik ist kein "OSM-Produkt". Daraus jetzt die OSM-Referenz zu machen - in dem Sinne von "was Mapnik darstellt, ist korrekt" - halte ich für definitiv falsch.

Gruss
walter

Last edited by wambacher (2015-09-09 15:29:46)

Offline

Board footer

Powered by FluxBB