You are not logged in.

#51 2011-12-05 15:06:20

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,847

Re: Jetzt schon Bürgersteige mappen?

viw wrote:

Was sind denn Datenbankebenen? Also ich denke in OSM besteht alles aus Punkten. manche Punkte werden für Linien benutzt andere Punkte werden sogar als Begrenzug für Flächen benutzt. Mehr gibts nicht.

Ok, Datenbankebene war wohl der falsche Begriff. Ich dachte an so etwas wie layer im Sinne einer grafischen Anwendung, um für verschiedene Themenbereiche verschiedenen Abbildungsebenen vorzuhalten, die wie transparente Folien übereinanderliegen und nach Bedarf ein- oder ausgeblendet werden. Da alles in OSM nur aus Punkten (nodes) besteht, sind die ways streng genommen schon Relationen, welche Bezüge zwischen Punkten beschreiben.

viw wrote:

...
Daher war ich ja der Meinung jede Eigenschaft in einen eigenen Weg zu packen und aus der Summe aller Wege zwischen zwei Punkten wird dann das richtige Element generiert.

Der Ansatz hat was. Aber da bekommen wir wieder das Problem, den richtigen Weg aller übereinanderliegenden bei der Bearbeitung zu erwischen. JOSM, Potlatch usw. müssten gänzlich andere Arbeitsweisen und -hilfen entwickeln. Wie filtere ich einen Weg über n Punkte zur Bearbeitung heraus? Und wie mache ich das, wenn von meiner Änderung an diesem way nur eine Teilstrecke über n-x Punkte betroffen ist? Wie sehe ich, welche Eigenschaften des ways über n punkte für den gesamten way (oder mehr) oder nur für einen Teil gelten?

Last edited by hurdygurdyman (2011-12-05 15:07:16)


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#52 2011-12-05 21:39:06

tippeltappel
Member
Registered: 2009-06-24
Posts: 861

Re: Jetzt schon Bürgersteige mappen?

viw wrote:
tippeltappel wrote:

Hi Chris
Sehr schöne Beispiele!

Das Platzlinientagging ist ein Mißbrauch von wichtigen Tags.
barrier=line und barrier=net lassen sich ja noch rausfiltern. Aber es ist trotzdem (vorsichtig ausgedrückt) keine wünschenswerte Verwendung des Tags.
highway=path für die Spielfeldlinien !?! Das kann ja wohl nicht sein! Das ist nicht akzeptabel!


Die Pollerorgie konnte ich nicht erkennen, nur die P-Orgie. wink

Das vereinzelte Mappen von Parkplätzen führt in Vektorkarten mit Suchfunktionen zu absolut undiskutablen Ergebnissen. In kleinen Handgeräten ist die Kapazität der Listen zum einen begrenzt, zum anderen macht die Auflistung der einzelnen Parkbuchten das Suchergebnis unbrauchbar. Wie soll man da noch eine Übersicht über die Parkplätze im näheren Umkreis erhalten? Der Mapper hat keine Möglichkeit eingebaut, mit der die für verschiedene Karten unbrauchbare Anhäufung von P durch Filterung dezimiert werden könnte. Eine große Fläche für amenity=parking ist wesentlich sinnvoller. Die einfassende Rasenfläche gliedert den Platz doch wohl genug. Und wenn das partout nicht reicht, dann muß das vor einiger Zeit diskutierte Taggingschema für die einzelnen Stellflächen bemüht werden, damit man diese Detailanzeigen rauswerfen kann. So ist es jedenfalls nicht sinnvoll.
Wenn diese Unsitte um sich greift, kann man entweder Straßen mit Parkbuchten irgendwann vor lauter P nicht mehr sehen oder man ist gezwungen die P früher auszublenden, stärker zu verdrängen oder was auch immer. Das wiederum erschwert dann die Parkplatzsuche mit Hilfe einer Rasterkarte, weil man dann möglicherweise so stark in die Karte hinein zoomen muß, daß die Gesamtübersicht beeinträchtigt wird. Diese Detailverliebtheit wird der Karte irgendwann also schaden.

Gruß
tippeltappel

Ich gebe dir bei den ersten Einschätzungen recht. Beim Parkplatz teile ich deine Meinung nicht! Schon gar nicht mit der begründung das der der Garmin irgendwann keine Kapazität hat. Das ist genau wie im anderen Thread geschrieben, alles was kleiner 4m Durchfahrtshöhe ist, ist hgv=no. Weil wir von richtigen Lkw sprechen.
Genauso muss es Lösungen für Parkplätze geben. Bei Openlayers werden auch Cluster gebildet. Wer also weniger "P"s haben möchte muss nur vorher nach bestimmten Regeln zusammenfassen.
Und nur weil die Erstellung von Karten immer schwerer wird auf Informationen zu verzichten halte ich für Falsch. Die Wirklichkeit ist nicht immer einfach. Man muss sie nachher vereinfachen. Wenn ich diesen Schritt aber bei der Datenerfassung schon gehe, dann werde ich später die Details nicht wieder hinzufügen können.

PS Dein Einfahrtsproblem kannst du vielleicht reduzieren in dem du alles was service=driveway und und service=parking_asile getagt ist rauswirfst.

Wenn Du den von Dir zitierten Text noch einmal genau liest, wirst Du feststellen,  daß ich durchaus die Möglichkeit für das Mappen einzelner Stellflächen sehe (auch wenn ich die auf Sonderflächen beschränken würde). Die Frage ist, wie man das macht. Der Parkplatz muß mit all seinen Details als Ganzes faßbar bleiben. Damit dem Bedarf nach Vereinfachung Rechnung getragen werden kann, gehört da eine große Gesamtfläche hin, in die dann - wie bereits mit anderen Worten beschrieben - Details zusätzlich eingefügt werden können. Es ist aber ein Unding nur Details zu mappen, denen dann Eigenschaften zu geben, die bislang für große Flächen benutzt wurden und dann zu sagen, da muß der Renderer jetzt irgendwie mit klar kommen und ein Ganzes draus machen.

Was die Kapazität der Suchergebnislisten betrifft, erweckt Deine Antwort bei mir den Eindruck, daß Du diese Funktion nicht kennst. Sonst würdest Du verstehen, daß diese Listen durch die Aufzählung einzelner Stellplätze unbrauchbar werden. Selbst wenn die Liste eine unendliche Kapazität hätte, wäre dem so.

Auf Bürgersteigflächen bezogen vertrete ich eine ähnliche Meinung. Wenn überhand nehmende Detailerfassung das Gesamtbild zerstört, dann läuft was falsch.
Wenn Verläufe von Bordsteinkanten erfaßt werden sollen, dann bitte nicht dadurch, daß Straßen oder Gehwege alle paar Meter aufgeteilt werden.
Wenn diese Daten so wichtig sind, warum erfaßt man sie nicht in einer separaten Linie rechts und links neben der Straße oder neben dem Gehweg? Es ist doch nicht notwendig, sämtliche Eigenschaften an ein und dieselbe Linie zu hängen. Wer diese Linien benötigt, der wertet sie aus und wer sie nicht braucht, der filtert sie raus. Und wo obendrein Gehwegflächen als notwendig erachtet werden, sind diese Linien dann eben die straßenseitige Begrenzung. Ich kann nur hoffen, daß diejenigen, die hier vehement für das detaillierte Micromapping eintreten und dafür Toleranz erwarten, denjenigen, die das nicht unterstützen und darauf bestehen, einfach faßbare Grundformen in der Karte zu erhalten, dieselbe Toleranz entgegenbringen, die klaren Grundstrukturen belassen und Details als zusätzliche Elemente einbringen.
In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.
In Bezug auf die Gehwege ist mein Kompromißvorschlag: für Gehwegflächen ein neues Taggingschema entwickeln, das klar von dem highway-Schema abgegrenzt und auch nicht mit highway=pedestrian verwechselt werden kann.

Wenn die in der Datenbank steckenden Informationen irgendwann nicht mehr auswertbar sind, dann ist ihr Wert = 0 und man hätte sich deren Erfassung sparen können.
Wie heißt das schöne Sprichwort? Weniger ist oft mehr!

Gruß
tippeltappel

Offline

#53 2011-12-06 05:15:16

hurdygurdyman
Member
Registered: 2009-12-10
Posts: 2,847

Re: Jetzt schon Bürgersteige mappen?

tippeltappel wrote:

...
Wenn die in der Datenbank steckenden Informationen irgendwann nicht mehr auswertbar sind, dann ist ihr Wert = 0 und man hätte sich deren Erfassung sparen können.

+1


Gruß Michael (hurdygurdyman)
Ich mappe für Menschen, die Karten verwenden, welche aus OSM-Daten gerendert wurden tongue http://de.wikipedia.org/wiki/KISS-Prinzip cool

Offline

#54 2011-12-06 09:29:55

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

Re: Jetzt schon Bürgersteige mappen?

tippeltappel wrote:

In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.

Ginge ja im Prinzip mit dem parking_space proposal, nur leider sieht dieses vor, bei Verwendung von amenity=parking_space auf das
amenity=parking zu verzichten, anstelle dessen die vielen kleinen Stellplätze per Relation wieder zu einem Gesamtobjekt
zusammenzufügen. Also nicht abwätskompatibel mit bestehenden Anwendungen ist.


Mapper aus dem Münsterland.

Offline

#55 2011-12-06 11:28:42

GeorgFausB
Member
From: Probstei, Schleswig-Holstein
Registered: 2008-10-14
Posts: 1,790

Re: Jetzt schon Bürgersteige mappen?

Moin,

chris66 wrote:
tippeltappel wrote:

In Bezug auf den Parkplatz ist mein Kompromißvorschlag: eine große Fläche als Parkplatz mappen und die Teilflächen als Stellplatzgruppen taggen.

Ginge ja im Prinzip mit dem parking_space proposal, ...

Also nicht abwätskompatibel mit bestehenden Anwendungen ist.

je nun, solange man mit parking_space wirklich nur Teilbereiche eines größeren Parkplatzes beschreibt, bleibt das ja abwärtskompatibel - schlicht und einfach, weil man dann jeweils unterschiedliche Objekte taggt.
amenity=parking wäre dann ja die site-Relation.
Erst wenn man den gesamten Parkplatz - fälschlicherweise? (*) - mit parking_space taggen will - erst dann ist es nicht mehr abwärtskompatibel.
Aber dort braucht man doch weder das parking_space noch eine site-Relation - das geht mit parking wie gehabt.

Gruß
Georg

(*) "It should not be used as a representation of one big single parking area. Highways should not cross this areas."

Last edited by GeorgFausB (2011-12-06 11:30:28)

Offline

Board footer

Powered by FluxBB