Unterwegs mit Garmin in Scharnhorst auf Parkplatzsuche:
Ah, hier ist einer eingezeichnet, hingefahren, Mist, Privatparkplatz.
Ah, hier ist noch einer, hingefahren, schade, nur für Anwohner.
Ah, hier ist noch einer, hingefahren, wieder nix, Privat.
http://www.openstreetmap.org/?lat=51.55285&lon=7.54407&zoom=17&layers=M
Hmmm, vielleicht mal hier hin fahren:
http://www.openstreetmap.org/?lat=51.5384&lon=7.55561&zoom=17&layers=O
Grüße,
Chris
PS: Gottseidank nur ein (Alb)-Traum
Das hist ist auch nicht von schlechten Eltern:
http://www.openstreetmap.org/?lat=52.260533&lon=8.899966&zoom=18&layers=M
mal den “data layer” anschalten oder mit einem Editor ansurfen - da ist jeder einzelne PKW-Stellplatz als Polygon eingemalt. Ist vermutlich ein bissschen schwierig zu editieren, die Ecke, aber was will man da auch noch editieren… man kann nur hoffen, dass die Mapper da das auch aktuell halten koennen - nicht auszudenken, wenn auf einem der Stellplaetze dann doch mal ein Blumenkuebel aufgestellt wuerde
Dir mangelt es an Dreistigkeit. Ich parke mit dem Auto da wo es mir gefällt. Ist schließlich für den Grundstückeigentümer eine Ehre das ich da mein Auto abstelle.
Wenn die wenigstens mit access=private markiert wären könnte man sie schön ausfiltern. Leider sind die meisten
in Scharnhost mit access=unknown getaggt. Da war der Satellit wohl nicht scharf genug um die Schilder lesen
zu können.
Hmmm, ich hatte das parking_space Proposal so verstanden, dass es amenity=parking ergänzen soll.
Ich finde aber dort kein amenity=parking.
moin moin, chris
auf der mapnik-karte, die du heute früh geposted hast, sind aber ca 80% privat (hellblau) im gegensatz zu offen/undefiniert (blau)
http://www.openstreetmap.org/?lat=51.55285&lon=7.54407&zoom=17&layers=M
gruss
walter
ergänzen ist in dem sinn gemeint, dass du entweder das eine oder das andere verwenden kannst, daher amenity=parking weiterhin nicht als “veraltet” gilt. es bedeutet nicht, dass du beides gleichzeitig auf einen parkplatz anwendest.
Wenn ich mich recht erinnee, dann soll man den gesamten Parkraum als amenity=parking eintragen und den einzelnen Stellplatz dann als parking_space.
du kannst es auf die relation geben. das steht nur deswegen im proposal, weil es für für site-relationen momentan noch keine einigung gibt, ob man den amenity-wert draufmappt oder als value auf den key “site=”.
Du hast das Proposal damals so angepasst, dass die alte Bedeutung von amenity=parking erhalten bleibt. Das war eine gute Entscheidung, und ohne die Möglichkeit, amenity=parking weiter normal zu verwenden, hätte ich (und wahrscheinlich auch andere) nie zugestimmt.
Warum du jetzt darauf bestehst, dass man entweder das eine oder das andere anwenden soll, ist mir nicht klar. Die von dir vorgeschlagene site=parking-Relation wird nun mal kaum unterstützt und ist bei einem normalen oberirdischen Parkplatz auch nicht wirklich von Vorteil gegenüber einer Fläche. Sollte sich die Situation bei der Softwareunterstützung ändern, können wir noch mal darüber reden, aber aktuell spricht einfach nichts für den Verzicht auf amenity=parking.
Wer unbedingt eine Relation will, kann natürlich die verwenden, aber sollte sich zumindest nicht beschweren, wenn jemand eine amenity=parking-Fläche dazumalt.
So würde ich es derzeit auch machen.
Bist Du mal auf den Daten Layer gegangen? Da siehst Du dass die hellblauen P’s access=unknown sind.
Also nicht abwärtskompatibel mit allen existierenden Anwendungen.
Um Deine Parking-Spaces anzuzeigen müssen alle Anwendungen angepasst werden.
Wobei eine generalisierte Auswertung darin besteht, die site-parking Relation auszuwerten
und aus den vielen kleinen Parking Spaces einen Parkplatz zu bauen. Bin mal gespannt,
wann die erste Anwendung das hinbekommt. 
Chris
eine redundante erfassung macht gar keinen sinn. wo steht das im proposal-text? alles was dort steht ist “This new tagging scheme is not meant to replace amenity=parking. You can stick to the current scheme if you like to keep it simple.” das bedeutet nicht eine gleichzeitige verwendung, sondern man kann entweder das eine oder das andere verwenden. wem details nicht so wichtig sind, verwendet amenity=parking, wer gerne details mappt, das neue schema.
Im Proposal wird amenity=parking weder in seiner Bedeutung verändert noch abgeschafft (in früheren Versionen des Proposals wäre das mit der vorgeschlagenen Einführung von amenity=parking + parking_type=space/entrance ja noch anders gewesen). Das Tag amenity=parking wäre für eine hypothetische Anwendung, die sich ausschließlich an deinem Proposal orientiert, also schlicht unbekannt.
Daher kann man amenity=parking gleichzeitig mit den Tags und Relationen aus dem Proposal verwenden, ohne dass Konflikte entstehen. Und angesichts der Popularität von amenity=parking bei Mappern und Anwendungen ist bis auf weiteres meine Empfehlung, das auch zu tun.