Am 25.07.2010 um 14:04 schrieb Bodo Meissner <b...@bodo-m.de>:

Am 25.07.2010 12:41, schrieb Guenther Meyer:

Die Angabe "kleine Parkmoeglichkeiten taggen wir nicht" steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit "Parkplaetzen" zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese "Stellplaetze"
dokumentiert wurde.
Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine
Begruendung fuer obsolet.

+1

+ 1


Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra:

und wie man das am
besten Neuusern verklickert, die geneigt sind aus obigem Grund
natürlich überall ein amenity=parking hinzubauen und einen Key f ür die
Art des "Parkplatzes" (disabled, women, parent, motorbike) hinbauen.


in dem man den Wikitext entsprechend anpasst.
Was soll denn bitteschoen kaputtgehen?

+1

+ 1

Ich kann schon nachvollziehen, daß es Unklarheit schafft, wenn jetzt einzelne Stellplätze ohne Zusatztags als amenity=parking bezeichnet werden. Um das zu vermeiden, würde ich im Wiki dokumentieren, daß einzelne S tellplätze oder Parkplätze mit geringer Kapazität immer ein capacity-Tag haben sollen. Das könnte auch von Editor-Presets unters tützt werden. Bei Parkplätzen, die nach der bisherigen Beschreibung im Wiki keine ausreichende Größe haben, kann man nicht argumentieren , daß die Erfassung (Schätzung) der Kapazität nicht praktikabel oder zu aufwändig wäre. Bei Parkplätzen ohne capacity können wir annehmen, daß es sich entsprechend der alten Beschreibung um "größere" Parkplätze handelt. (Andernfalls ist es ein Fehler im Tagging.) Dann müßte man bei Bedarf nur noch den Renderern beibringen, ab irge ndeiner Kapazitätsgrenze eine Unterscheidung zu machen.
Insoweit sehe ich da auch kein wirkliches Problem.

+ 1

Allerdings wird mit diesem Vorschlag nicht die Frage beantwortet, wie man auf einem großen Parkplatz mit mehreren Stellplätzen/ Parkständen die Bereiche kennzeichnet, die bestimmten Fahrzeugen ode r Fahrzeugnutzern vorbehalten sind. Möglicherweise kann man das mit parking:lane lösen. Falls das zu kom pliziert ist, braucht man eben (wie bereits gesagt) geeignete Presets.

Angenau diesem Punkt scheiden sich eben die Geister. Ein einzelner Node ist halt einfacher auf einer Fläche zu taggen.

Mein Gedanke ist derzeit, so vorzugehen:

1.Area mit normalen Parkständen: amenity=parking
capacity:standard=360

2.Area mit Parkständen für Behinderte:
amenity=parking
capacity:disabled=2

3. Area mit Parkständen für Eltern:
amenity=parking
capacity:parents=18

4. Area mit Parkständen für Frauen:
amenity=parking
capacity:women=20

Alle 4 Areas in eine Relation für den gesamten Parkplatz, um zu zeigen, dass alle Areas zusammen gehören:

amenity=parking
capacity=40

Damit wäre erreicht:
1. Die Spezialparkplätze sind eindeutig zu lokalisieren.
2. Da es sich faktisch um Flächen handelt, ist "area" nicht falsch.
3. Durch die Relation ist klar, dass alles zu einem Parkplatz gehört.

Das setzt natürlich voraus, dass "parking" als Überbegriff für ausgewiesene Parkplätze anerkannt wird!

Alternative:

1. Gesamtparkplatz in eine Area mit allen Zufahrtswegen, etc. Und das multipolygon als "inner" taggen. 2. Alle Spezialparkstände und auch die Fläche der normalen Parkstände jeweils als "outer" vom mulipolygon mit obigen tags versehen.

Auch dann ist alles zusammengefasst und dennoch sind die einzelnen Bereiche gleichwertig nebeneinander getaggt.

Beide Varianten funktionieren natürlich auch mit jeweils eigenen tags, dad capacity sollte aber dennoch nicht fehlen.

Deshalb wären alle Varianten gleich aufwändig.

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

Antwort per Email an