Re: [Talk-de] Tiefgragen
für tiefgaragen kann auch das neue parking schema verwendet werden: http://wiki.openstreetmap.org/wiki/Proposed_features/parking tiefgaragen im konkreten: http://wiki.openstreetmap.org/wiki/Proposed_features/parking#Underground_parking flaimo Message: 1 Date: Sun, 06 May 2012 10:40:08 +0200 From: Kay Drangmeister k...@drangmeister.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Tiefgragen Message-ID: 4fa638e8.8090...@drangmeister.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Am 28.04.2012 18:44, schrieb Falk Zscheile: Am 28. April 2012 17:15 schrieb Kay Drangmeisterk...@drangmeister.net: gleich in's Wiki). Hintergrund: ich würde das gerne auf der Parkkarte korrekt darstellen. Aber gern doch. Mehr als zwei Beispiele habe ich leider nicht. 1. Beispiel: http://www.openstreetmap.org/browse/relation/2135015 Danke für die Beispiele, aber leider sind da keine Polygone in der mapnik-db drin. Die Europahalle ist eine Relation aus 4 Knoten (z.B. Eingänge, was die Driveway-Knoten darstellen sollen ist mir unklar). Somit kann ich da kein Flächenpolygon zeichnen (würde ich gerne). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garage und service=driveway verbinden?
habe ich vor fast genau einem jahr mal angesprochen: http://forum.openstreetmap.org/viewtopic.php?id=11563 Ich verwende momentan highway=service+service=driveway+driveway=garage+access=private für die kurzen zufahrten zu garagen und verbinde den way mit einem gebäude (building=garage) und setze auf den node dann building=entrance+access=private. zB http://osm.org/go/0JhN1krKU-- durch das zusätzliche driveway=garage gebe ich noch ein semantisches unterscheidungsmerkmal mit, durch welches man potentiell die kurzen wege in kartenstilen rausfiltern kann, wenn sie einem nicht gefallen. flaimo -- Message: 9 Date: Tue, 27 Mar 2012 05:32:01 + (UTC) From: Manuel Reimer manuel.s...@nurfuerspam.de To: talk-de@openstreetmap.org Subject: [Talk-de] Garage und service=driveway verbinden? Message-ID: loom.20120327t072816-...@post.gmane.org Content-Type: text/plain; charset=utf-8 Hallo, bei uns in Dorf sind seit neuestem einige Einfahrten zu privaten PKW-Garagen eingetragen. Getaggt mit highway=service und service=driveway. Nun beschwert sich keepright (vermutlich zu Recht) weil diese Einfahrten kurz vor den dazugehörigen Garagen enden. Sollte man sowas verbinden? Wenn ja: Den Knoten, an dem verbunden wurde, als building=entrace taggen? Wie verfährt man eigentlich korrekt, wenn neben der Einfahrt auch der Hauseingang liegt? Kurzes Stück footway von Einfahrt zur Haustüre? Oder würdet ihr Haustüren generell nicht mit der Karte verbinden? Gruß Manuel -- Message: 10 Date: Tue, 27 Mar 2012 09:08:34 +0200 From: Andreas Neumann andr-neum...@gmx.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Garage und service=driveway verbinden? Message-ID: 4f716772.1050...@gmx.net Content-Type: text/plain; charset=iso-8859-1 Am 27.03.2012 07:32, schrieb Manuel Reimer: Hallo, bei uns in Dorf sind seit neuestem einige Einfahrten zu privaten PKW-Garagen eingetragen. Getaggt mit highway=service und service=driveway. Nun beschwert sich keepright (vermutlich zu Recht) weil diese Einfahrten kurz vor den dazugehörigen Garagen enden. Sollte man sowas verbinden? Wenn ja: Den Knoten, an dem verbunden wurde, als building=entrace taggen? Wie verfährt man eigentlich korrekt, wenn neben der Einfahrt auch der Hauseingang liegt? Kurzes Stück footway von Einfahrt zur Haustüre? Oder würdet ihr Haustüren generell nicht mit der Karte verbinden? Gruß Manuel Theoretisch könntest du jeden Trampelpfad durch die Beeten in deinem Garten eintragen ;). Spaß beiseite: Ich verbinde Wege nur an Eingängen/Einfahrten mit Gebäuden. Male ich Luftbilder ab, kann ich nicht erkennen, ob da was ist und ich lasse die Wege auch vor dem Gebäude enden. Wie detailiert du einzelne Wege mappst, bleibt dir überlassen. Rein wegen der Menge, mappe ich kleine Wege und Zuwegungen nur bei Gebäuden und Grundstücken, die ich persönlich wichtig und wertvoll finde. MfG Andreas -- nächster Teil -- Ein Dateianhang mit Binärdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigröße : 260 bytes Beschreibung: OpenPGP digital signature URL : http://lists.openstreetmap.org/pipermail/talk-de/attachments/20120327/cd465123/attachment.pgp -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ende Talk-de Nachrichtensammlung, Band 68, Eintrag 81 * ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten
das ist durch namespaces – wie am anfang des proposals beschrieben – bereits gegeben: https://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Namespace schreib statt access: zB lanes: hin und du kannst das ganze für spurmapping verwenden (sogar parallel zu access: auf dem gleichen element, wenn es sein muss). flaimo -- Message: 1 Date: Thu, 23 Feb 2012 08:27:40 +0100 From: Martin Vonwald imagic@gmail.com To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten Message-ID: 8c57a600-069d-49ef-877d-6ca3f4f57...@gmail.com Content-Type: text/plain; charset=utf-8 Ich denke, ich werde dieses Proposal wieder aufwecken: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extended_conditions_for_access_tags#Splitting_conditions_and_values Wir brauchen in unterschiedlichsten Situationen Bedingungen und sollten nicht für jede Situation etwas eigenes erfinden. Martin Am 22.02.2012 um 23:15 schrieb Flaimo fla...@gmail.com: oder das hier: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Time_based_conditions flaimo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten
oder das hier: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5#Time_based_conditions flaimo Message: 2 Date: Wed, 22 Feb 2012 16:18:30 +0100 From: Tobias Knerr o...@tobias-knerr.de To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Tageszeitabhängige Geschwindigkeiten Message-ID: 4f450746.7020...@tobias-knerr.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Am 22.02.2012 15:58, schrieb tumsi: gibt schon ein Schema oder Proposal für das Eintragen von Tageszeitabhängigen Geschwindigkeiten? Bisher habe ich nur dies gefunden. http://wiki.openstreetmap.org/wiki/Proposed_features/Practical_maxspeed [...] Also ziemlich viel Wildwuchs, weswegen hier wohl mal ein ordentliches Proposal angebracht wäre. Ein Proposal gibt's schon: http://wiki.osm.org/Proposed_features/Extended_conditions_for_access_tags Das wäre dann die Variante maxspeed:(08:00-18:00) = 50 Das Proposal ist sehr allgemein gehalten, so dass man auch andere Attribute tageszeit-abhängig gestalten kann. Beispielsweise gibt es ja Dinge wie Lieferverkehr zwischen 6 und 10 Uhr frei oder zeitabhängige Einbahnstraßen. Außerdem kann man damit auch witterungsabhängige Maxspeeds (80 km/h bei Nässe) abbilden. Nur habe ich das aus zwei Gründen nicht mehr weiter verfolgt: Der erste ist, dass es viel Gegenwind wegen der Verwendung von Sonderzeichen in Schlüsseln gab. Der zweite ist das Fehlen jeglichen Engagements von Seiten derjenigen Entwickler, für die dieses Thema relevant wäre. Solange es keine Software gibt, die z.B. zeitabhängiges Routing durchführen kann, wird ohnehin kein Taggingschema als wirklich etabliert gelten können. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
das proposal zieht in erster linie aber auf parken entlang von straßen ab. wenn es dir um richtige parking lots geht, so könntest du auch das parking space proposal als vorlage hernehmen, sofern du entsprechend hochauflösende bing bilder zur verfügung hast. das ist nämlich schon approved und beinhaltet sowohl einen vorschlag für die rollenthematik (access:customer) als auch wie man es in relation zu sonstigen elementen stellt (site relation). gerendert wird es aber auch noch nicht. http://wiki.openstreetmap.org/wiki/Proposed_features/parking flaimo Message: 2 Date: Sat, 28 May 2011 00:08:11 +0200 From: Peter peter@gmx.net To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Kundenparkplatz Message-ID: irp7c5$apq$1...@dough.gmane.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Am 24.05.2011 18:15, schrieb Stephan Wolff: Am 24.05.2011 17:06, schrieb Peter: Am 23.05.2011 20:11, schrieb Stephan Wolff: Mir nicht. name=Kunden Rewe ist offensichtlich falsch. Seh' ich nicht das das falsch ist. das mit note/desc. mag ok sein, aber wenn man das nicht in der Karte sieht ist es fast nutzlos. [] OSM ist auch eine Karte, keine Datenhalde. Du hast das Grundprinzip von OSM nicht verstanden. OSM ist eine Datensammlung aus der (unter anderem) verschiedene Karten berechnet werden. Bei Bedarf werden die Regeln zur Kartendarstellung angepasst, nicht die Daten an die erw?nschte Darstellung. Ich hab' das schon verstanden. Was 'ne Unterstellung. Nur ist es so wenn 'die hohen Herren' das Werkzeug nicht geeignet bauen (mal harsch daher gesagt:-) dann geht der gemeine Mapper halt hin und macht was daraus was ihm geeignet scheint. So sind die Leute nunmal. Ich habe mal die Parkpl?tze (nur way) einer Gro?stadt gesucht: 400 St?ck, 20% haben Namen, ?ber den Daumen gepeilt sind die h?lfte(!) Kundenparkpl?tze, an den Namen erkennbar. access=customers haben 2(!) Ergo ist das ganze ein Dokumentationsproblem, oder am Editor (josm bietet weder in access noch in der Vorlage 'Parkplatz' was an) Ich werf' da keinem der t?tigen was vor (nur den Meckerern), das sind einfach Kleinigkeiten die vorkommen. Nun warte man bis das Parkplatz proposal erledigt ist, das mit access oder wie auch immer man den Parkplatz an den Laden bindet, dann die Renderer angepasst sind (wird dann name='' oder der zugeh?rige Laden angezeigt? Besser beides.) Danach kannst du dann hingehen und die gesch?tzt 5000 name='Laden' l?schen:-) Ich werde den einen Kundenparkplatz den ich erfasste dann h?chst pers?nlich korrigieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
und wieder wird das lustige wort überwiegend als argument genannt. ohne konkrete angabe in m2 oder km2 hat dieses wort keine aussagekraft. in linz hat einer überwiegend so definiert, dass er eine rießige fläche über die ganze stadt gespannt hat, ich definiere überwiegend in bezug auf klar erkennbare grundstücksgrenzen. beides ist per (quasi nicht vorhandener) definition absolut korrekt. flaimo Message: 7 Date: Wed, 25 May 2011 00:41:32 +0200 From: Stephan Wolff s.wo...@web.de To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Kein Micromapping mit landuse Message-ID: irhc4s$4c0$1...@dough.gmane.org Content-Type: text/plain; charset=UTF-8; format=flowed Der Zug steht ohne Zielangabe auf dem Rangiergleis :-) Die Au?engrenzen eines Wohn-, Industrie- oder Waldgebiets sind nicht ungenauer als die Grenzen der Einzelgrundst?cke, sondern stellen eine andere, zweifellos notwendige Informationsebene dar. landuse wird aktuell weit ?berwiegend als Gebiet verwendet und ist so auch im Wiki definiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
für sowas kann man dann die site relation verwenden, um die einzelnen landuse flächen zu einem logischen gebiet zusammenzufassen. und man ist unabhängig von einer einzelnen area mit ihren boundaries. gleiches konzept wie ich es bei meinem parking space proposal gemacht habe. wenn hoffentlich mal irgendwann der default style von mapnik diesen relationstyp auswertet, werden ganz plötzlich die microgemappten gegenden wunderbar auf der karte aussehen. flaimo Message: 5 Date: Wed, 25 May 2011 19:52:59 +0200 From: Stephan Wolff s.wo...@web.de To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Kein Micromapping mit landuse Message-ID: irjfmc$e4c$1...@dough.gmane.org Content-Type: text/plain; charset=UTF-8; format=flowed Offizielle Gebietsnamen (Industriegebiet S?d, Waldsiedlung) und ihre Grenzen sind Informationen die f?r die OSM-Datenbank wichtig sind. Diese Informationen kann man NICHT aus den Einzelfl?chen ableiten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
1) kunde ist kein zustand (condition) sondern eine rolle. conditions sind eher zeit- oder wetterbasierende einflüsse. 2) die notation berücksichtigt nicht UND-kombination von rollen 3) ich sehe keinen grund krampfhaft ein zweites paralleles access system nur für parking aufzubauen. diese information lässt sich auch mit dem bestehenden access schema mit operator=REWE und access=customers abbilden. wenn man unbedingt was feingradiger unterscheidbar machen will, dann wäre es besser die access thematik später gesondert (und nicht nur rein für parking) zu behandeln. meinen (langen) senf dazu findet ihr hier: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 dessen rollenkonzept ist bereits als tagging vorschlag in das akzeptierte proposal für parking spaces eingeflossen, wobei ich mich dort aber nicht auf ein fixes access schema festgelegt habe und die access tags als optional gekennzeichnet habe. http://wiki.openstreetmap.org/wiki/Proposed_features/parking flaimo Message: 9 Date: Tue, 24 May 2011 10:02:51 +0200 From: Kay Drangmeister k...@drangmeister.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Kundenparkplatz Message-ID: op.vvy7a1p0hiwlwc@afa-30100.empolis.local Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Nicht schlecht, kleiner Einwand: gibt es nicht Betreiberfirmen, eher bei gr??eren Parkh?usern, so dass dieses Tag daf?r passen w?rde und f?r die Kundenangabe ambig w?re? Ich hatte ja erfunden: parking:condition:area=customers parking:condition:area:customers=Tegut bzw. w?rde mittlerweile auch die Abk?rzung vorziehen: parking:condition=customers parking:condition:customers=Tegut Das ist eindeutig, verst?ndlich und die Verfeinerung gem?? akzeptierter Standards, aber ist insgesamt etwas geschw?tzig im Vergleich zu access und operator. Viele Gr??e, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
krampfhaft war ein bisschen die falsche wortwahl. was ich damit meine ist, dass die access thematik generell neu aufgearbeitet gehört, weil du im zuge des proposals vermutlich selber festgestellt hast, dass sich damit einiges nicht abbilden lässt. wenn jetzt für jedes element eine neue notation angefangen wird befürchte ich, dass sich das ganze so zerstreut, dass keine der neuen mapping schemen jemals ordentlich ausgewertet wird. nimmt man solche neuen access tags mit einem proposal huckepack mit, ist auch die gefahr groß, dass man das ganze nur aus dem einen blickwinkel des proposals betrachtet und dann später bei anderen bereichen erst wieder draufkommt, dass es nicht ganz passend ist. im falle von parking lanes hat man zugegebenermaßen das problem, dass es bereits access tags geben kann, die sich auf die straße selber beziehen. dann wird man nicht drumherum kommen einen weiteren prefix zu verwenden. das könnte man dann aber modular machen wie zB parking_prefix:diverse generelle access tags. dazu muss ich mir vermutlich selber noch gedanken in mienem access proposal machen. flaimo Message: 4 Date: Tue, 24 May 2011 13:19:48 +0200 From: Kay Drangmeister k...@drangmeister.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Kundenparkplatz Message-ID: op.vvzgfahmhiwlwc@afa-30100.empolis.local Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes Servus Flaimo, Am 24.05.2011, 11:45 Uhr, schrieb Flaimo fla...@gmail.com: 1) kunde ist kein zustand (condition) sondern eine rolle. conditions sind eher zeit- oder wetterbasierende einfl?sse. condition bedeutet Bedingung, d.h. eine Pr?misse oder Voraussetzung, unter der ein Parken erlaubt ist. Mit einem Zustand (state) hat das nat?rlich nichts zu tun, richtig. Siehe http://dict.leo.org/ende?lp=endelang=desearch=condition Kunde ist auch keine Rolle, diese hat der Fahrer, nicht der Parkplatz. Der Parkplatz hat nur die Einschr?nkung (Bedingung). 2) die notation ber?cksichtigt nicht UND-kombination von rollen Wie meinst du das? Wenn der Parkplatz z.B. f?r Anwohner oder mit Parkschein benutzbar ist? 3) ich sehe keinen grund krampfhaft ein zweites paralleles access system nur f?r parking aufzubauen. Da ist nichts krampfhaft dran. Access funktioniert wunderbar und wird in der Parkkarte auch unterst?tzt. Zus?tzlich, wo access nicht ausreicht, z.B. um f?r Anwohner auch nur mit Parkausweis S4 oder Mo-Fr 9-18h eingebbar zu machen, gibt es noch die M?glichkeit der verfeinerten conditions. wenn man unbedingt was feingradiger unterscheidbar machen will, dann w?re es besser die access thematik sp?ter gesondert (und nicht nur rein f?r parking) zu behandeln. meinen (langen) senf dazu findet ihr hier: http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
das problem hast du mit allen alteingesessenen tags, die aus zeiten stammen wo ein paar oldschooler noch alles selber mit gps ungenau gemappt und eingetragen haben. die wurden damals alle ziemlich schwamming definiert was jetzt, in zeiten von hochauflösenden bing bildern, natürlich zum problem wird. die tendenz geht aber nun mal eher zu mehr details und nicht weniger. deswegen werden diese elemente auch alle nun so verwendet und du wirst durch bloßes finger heben das nicht ändern können. wenn es dich stört musst du konstruktive vorschläge für ausweich tags liefern und nicht immer nur sagen nein, so mappt man das nicht. für einzelne parkplatzstellflächen habe ich noch rechtzeit ein proposal durchbekommen bevor die meisten anfangen diese mit einem amenity=parking zu mappen. bei landuse und natural=tree ist der zug aber meiner meinung nach abgefahren. der wird sich in richtung grundstück mapping hinbewegen. wenn du wieder was ungenaues haben willst, musst du wohl oder übel ein proposal für einen neuen tag starten. dabei sollte man dann vielleicht auch mal definieren was überwiegend bedeutet bzw. auf was für einen flächenmäßigen berechnungsradius sich das bezieht. mit dem unterbrechen der landuses bei straßen habe ich wiederum kein problem. abgesehen, dass im innerstädtischen bereich sowas dann viel leichter zu handhaben ist als zigfach überanderliegende flächen, kann man die lücken später immer noch mit weiteren landuse areas füllen, wenn sich die tendenz, wieder erwarten, doch wieder in die ungenaue richtung bewegt. vielleicht gibt es aber auch mal einen landuse=traffic in kombination mit area:highway (wofür ich schon ein proposal gestartet habe). dann wäre bereits alle vorbereitet und man muss nur noch die lücken mit diesen werten füllen. eine andere alternative wäre es den kartenrenderern eine art expand-funktion zu verpassen, sowie sie in photoshop bei selektionen verwendet werden kann. dann kannst du auch mit durchbrochenen landuses karten ohne lücken erstellen, wenn du sowas brauchst. bei karten mit straßen fällt es sowieso kaum auf außer man ist gerade auf dem höchsten zoom level. flaimo Message: 1 Date: Tue, 24 May 2011 16:32:24 +0200 From: Torsten Leistikow de_m...@gmx.de To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Kein Micromapping mit landuse (war: See in Wald in (L|N)SG) Message-ID: 4ddbc178.1030...@gmx.de Content-Type: text/plain; charset=UTF-8 Johannes Huesing schrieb am 24.05.2011 06:30: Diesen Weg hat man zu meinem Unmut schon beschritten, als man entschied, dass Feldwege nicht zu einem Feld geh?ren und die Landnutzung erst 3 Meter links und rechts der Wegmitte beginnt. Hat man das entschieden? Ich habe das nicht entschieden und mappe auch nicht so. In meinem Umland gibt es allerdings verschiedene Mapper, die zwischen verschiednene Flaechenelementen grundsaetzlich einen Streifen frei lassen. Da passt dann nateurlich auch noch ein kleiner Weg dazwischen. Warum diese Mapper das tun, weiss ich nicht. Ich vermute, dass ist den Unzulaenglichkeiten irgendeines Editors oder Validators geschuldet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 58, Issue 62
du führst hier ein veraltetes beispiel an. das habe ich getaggt und das war noch aus der zeit wo es noch keinen tag für einzelne stellflächen gab. ich bin momentan dabei meine alten mappings auf das neue parking schema umzustellen, zu der stelle bin ich aber noch nicht gekommen bzw. möchte noch warten bis die hausnummern für linz freigegeben wurden, damit ich den logischen parkflächen aussagekräftige namen geben kann. nach dem neuen schema kannst du weiterhin alles mit access=permissive oder access=private taggen, was auch vollkommen ok ist wenn dir das thema nicht so wichtig ist, du hast aber die mögllichkeit mit den zusätzlichen tags für rollen detailliertere informationen zu mappen, für wen genau die parkplätze sind. ob und wie routing programme das mal verwenden wird sich mit der zeit zeigen. potentiell könnten solche rolleninformationen aber nützlich sein um zB explizit elemente in eigenen kartenstilen auszublenden (mieterparkplätze) oder hervorzuheben (behindertenparkplätze). flaimo Message: 10 Date: Mon, 23 May 2011 16:49:54 +0200 (CEST) From: G?nther Zin. o...@fh15.homeip.net To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] Kundenparkplatz Message-ID: 34986.193.228.97.71.1306162194.squir...@zinsberger.dyndns.org Content-Type: text/plain;charset=iso-8859-1 Was haltet ihr davon (hab NICHT ich gemacht)? kleiner Unterschied: Mieter-Parkpl?tze statt Kundenparkpl?tze: http://www.openstreetmap.org/?lat=48.25943lon=14.28891zoom=17layers=O ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
