links (als Tag).
Dann ist es aber eben nicht Key:maxspeed, also spielt das für diese
Seite keine Rolle.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Meinungsäußerungen in der Umfrage auf der Wiki-Seite: Welche Syntax
findet ihr besser?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
denn z.B.
gegen eine Kooperation mit Keepright, statt noch eine neue Karte
aufzumachen?
Das als subjektiver Eindruck eines Testtools-Nur-Nutzers.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
in talk
diskutiert wurde.
todo.pl ist keine slippy map, sondern ich möchte vor dem mappen mir eine
karte ausdrucken
Ok, das ist noch einigermaßen eine Marktlücke. Die Dinge, die mir für
den Zweck einfallen würden, hast du ja auch schon auf deiner Liste.
Tobias Knerr
Martin Koppenhoefer schrieb:
Am 25. Juli 2009 17:51 schrieb Tobias Knerr o...@tobias-knerr.de:
Ich würde immer noch amenity=water + drinkable=no nehmen (bzw.
erfinden).
meine Vorschläge amenity=service_water oder raw_water waren das
Ergebnis einer LEO-Suche und Selektion für Brauchwasser
/viewtopic.php?pid=19366#p19366
Ein fountain ist es jedenfalls nicht (in der OSM-Bedeutung, das
Wörterbuch ist egal), und drinking_water ja offensichtlich auch nicht.
Sollte man natürlich dokumentieren, wenn es häufiger gebraucht wird.
Tobias Knerr
___
Talk-de
Fehlervermeidung bei primitiven Anwendungen
ist es aber wohl die sicherste Option.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
, bicycle_parking etc.) verlinkt, places nicht.
capacity wird anscheinend zigmal häufiger verwendet, wird von den
JOSM-Presets eingesetzt etc. Ich sehe eigentlich nichts, was für
places spricht?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
da durchaus eine große Bandbreite gibt.
Tobias Knerr
[1] Das große ß wird vermutlich noch bei kaum jemandem korrekt
dargestellt. ;)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
).
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
perfekte Ausstattung anlegen. :)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
auch Flächen sein können: This Tag should be used together with other
Tags that normally are used to mark a linear feature. Und linienförmige
Kindergärten hab ich noch nicht gesehen.
Es schadet natürlich nichts, falls mal wieder jemand meint, was
umdefinieren zu müssen...
Tobias Knerr
vorgeschlagenen site-Relation, aber das oben
sollte als Basisausstattung reichen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
steckts weniger klar auch drin (da dort ein oneway=no
für einen Nicht-Einbahn-Link gesetzt wird).
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
an Ways getaggte incline=* zu finden? Das ist doch
sogar auf http://wiki.openstreetmap.org/wiki/Tag:highway%3Dincline
verlinkt und ziemlich ausführlich dokumentiert (ganz im Gegensatz zu
highway=incline und =incline_steep, wo mich schon mal interessieren
würde, was bitte steep ist).
Tobias Knerr
für den Rest der Welt hat? Oder
wo kommt die Zahl her?
Ich hätte ja nicht mal auf DE nachgesehen, weil es eigentlich keinen
Grund gibt, hier international uneinheitlich vorzugehen. Dachte ich...
Tobias Knerr
___
Talk-de mailing list
Talk-de
einbauen würden wir es ja
ohnehin nicht, oder?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
hängen wie an ein highway=yes.
Also: Tagdokumentationen erstellen und loslegen!
(Oder kurz: +1)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Tags plötzlich falsch werden -- es ist durch die
gespeicherte Zuordnung ja klar, nach welcher Auffassung sie erfasst wurden.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Interpretation stützen.
Wenn also die Eindeutigkeit der Interpretation sichergestellt würde,
hätte die Idee als Experiment zumindest meine Unterstützung.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org
eine Auswertung
durch eine hinreichend vielseitige Anwendung sogar in Konfliktphasen
noch möglich, da die jedem Einzelfall zugrundeliegende Definition klar ist.
Eine solche Lösung täte dem dezentralen Charakter des Konzepts keinen
Abbruch und wäre technisch unschwer realisierbar.
Tobias Knerr
Tobias Wendorff schrieb:
Am Do, 25.06.2009, 21:40 schrieb Tobias Knerr:
Eine solche Lösung täte dem dezentralen Charakter des Konzepts keinen
Abbruch und wäre technisch unschwer realisierbar.
Also sollte man dann beim Mappen erst den passenden Tag jeder einzelnen
Schule ermitteln und
unangebracht.
´ oder ` oder ' haben ja alle 3 ihre Darseinsberechtigung
‘ (U+2019) auch, finde ich. Dieses Thema ist übrigens nichts für Leute
mit weniger präzisen Schriftarten. ;)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
jemand umsetzen.
Ob es dir persönlich die Arbeit wert ist, musst du natürlich selber
wissen. Ein paar mögliche und bestehende Anwendungen sind ja schon
genannt worden.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
Einheiten in einer Condition anders gehandhabt
werden soll als bei max*-Values?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
/Extended_conditions_for_access_tags
Passt das so (außer dem Diskussionspunkt mit den Attributen/Operatoren
und der opening_hours-Syntax? Ggf. gerne noch was ändern, gerade an der
Begründung/Argumentation im Syntax-Abschnitt.
Tobias Knerr
___
Talk-de mailing list
was hintereinander steht, und-verknüpft
ist. genauer spezifizierte einschraenkungen haben vorrang vor allgemeinen.
Bei dieser Auswertungslogik stimme ich zu, das habe ich ja auch im
Ursprungsproposal so dargestellt.
Tobias Knerr
___
Talk-de mailing list
Talk-de
Erkennungsmerkmal zu haben - die ist bei rein
numerischen Werten sonst implizierbar.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
/w/api.php
Also vielleicht mal das /w weglassen?
und als Benutzer meinen OSM-Login.
OSM-Login oder OSM-Wiki-Login?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
, um die
Fläche aus dem Routing zu nehmen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Richtungen befahrbar sein.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Martin Koppenhoefer schrieb:
Am 10. Juni 2009 15:51 schrieb Tobias Knerr o...@tobias-knerr.de:
Martin Koppenhoefer schrieb:
inwiefern ist es für das Routing ein Problem, wenn es 2 anstatt einer
Möglichkeit gibt?
An einer der 2 Möglichkeiten kann man die Einbahnstraßeneigenschaft
nicht
absolut inkompatibel mit deinem eingangs
geäußerten Wunsch, dass die Flächen in heutigen Renderern ohne Anpassung
der Renderregeln auftauchen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
würden mich auch einfache subjektive Meinungen also
durchaus freuen.
Tobias Knerr
PS: Das kommt natürlich auch noch auf talk, aber auf den
deutschsprachigen Kanälen (ML, Forum) wird deutlich häufiger Bedarf an
solchen Ausdrucksmöglichkeiten angemeldet, warum auch immer -- daher
zuerst hier
auch eine etwas detailliertere Einstufung als
Steigung und steile Steigung.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
):
- funktioniert nicht nur für access, sondern z.B. auch maxspeed
- kompatibel mit Zugangsrechten (Lieferverkehr von x bis y frei)
- erlaubt komplexere Intervalle (mehrere an-aus-Zyklen am Tag,
Wochentage etc.)
- recycelt vorhandene Syntax
Tobias Knerr
___
Talk
in Mapnik) prinzipiell möglich und
sinnvoll ist, wäre eine solche Rendering-Verbesserung vielleicht der
konfliktärmste Ansatz.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
/Proposed_features/Extended_conditions_for_access_tags
motorcycle:forward:time{7:00-9:00;16:00-18:00} = no
(angenommen, der Weg geht in die Richtung, die manchmal beschränkt ist)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
.
Falls es zutrifft: Dieses Usability-Problem ließe sich dadurch beheben,
dass an Stelle des Bereich korrekt, Größe ist wahrscheinlich
akzeptabel auch ein Hinweis auf fehlenden / unsinnig kleinen Rahmen
gezeigt würde.
Tobias Knerr
___
Talk-de mailing
ohne spezialisierte Botaccounts, aber mit ausreichendem Aufräumdrang -
einschließlich aller Auswirkungen, die großflächige Edits eben haben
(schlechter nachvollziehbare History und so). Dann imo schon lieber
einen CreatedByRemoveBot o.ä. das machen lassen...
Tobias Knerr
Frederik Ramm schrieb:
Tobias (Knerr) nannte als Nachteil die schlechter nachvollziehbare
history durch grossflaechige Changesets.
Erklaere, inwiefern die History eines Objekts besser nachvollziehbar
ist, wenn ein Bot das created_by-Tag entfernt hat, als wenn ein Benutzer
diese
eben amenity, ob der Name nun passt
oder nicht. Hier eine Unterteilung einzuführen, erhöht nicht die
Ausdruckskraft des Tags, sondern zwingt einen nur, sich neben dem
Wert-Namen auch noch den Schlüssel zu merken.
Tobias Knerr
___
Talk-de mailing list
Talk
ist bei entsprechendem Willen kein
Aufwand. Wenn neue Tags nicht berücksichtigt werden, liegt das entweder
daran, dass der Entwickler höhere Anforderungen hat, die noch nicht
erfüllt sind (Icon vorhanden o.ä.), oder daran, dass er es schlicht
nicht berücksichtigen will.
Tobias Knerr
auch noch Platz für weitere Einschränkungen.
Und wieso hier jetzt access:destination im Key und nicht im Wert?
Wieso access:destination, aber oben nicht vehicle:hgv oder so?
Es gelingt mir bisher nicht, da ein durchgängiges System zu erkennen.
Tobias Knerr
/Conditions_for_access_tags
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
hätte nichts dagegen, so
gut gefällt mir dieses Keyanhängsel hier nämlich keineswegs.
Tobias Knerr
PS: Wenn es nach mir gegangen wäre, hätte ich dieses Thema mit Rücksicht
auf das Risiko längerer Diskussionen erst in ein paar Tagen
angesprochen, wenn ich wieder etwas mehr Zeit habe. Eventuell können
Kontaktinformationen und produzieren keine Migrationshindernisse.
Tobias Knerr
* geht das juristisch? Sie sind ja von unseren Karten abgeleitet und
müssten deshalb CC-BY-SA sein. Ist trotzdem ein wenn die Daten, von
denen ich das abgeleitet habe, unter einer anderen Lizenz stehen werden,
darf man meine
Tobias Wendorff schrieb:
Tobias Knerr schrieb:
* geht das juristisch? Sie sind ja von unseren Karten abgeleitet und
müssten deshalb CC-BY-SA sein. Ist trotzdem ein wenn die Daten, von
denen ich das abgeleitet habe, unter einer anderen Lizenz stehen werden,
darf man meine Beiträge auch unter
uns
übernehmen (weil unsere v2 upgradebar ist), wir aber nicht von ihnen.
Wir können das aber sowieso schon deshalb nicht, weil wir uns
Lizenzwechseloptionen nicht verbauen wollen. Viele lizenzrelevante
Inhalte, die wir brauchen könnten, gibts dort eh nicht, oder?
Tobias Knerr
unnötig kompliziert. Hängt am selben Pfahl ist eine in
der Praxis unwesentliche Information, für die man nicht das Tagging
verkomplizieren sollte. Wenns wirklich interessiert, kann man ja eine
Relation same_pole machen. ;-)
Tobias Knerr
___
Talk-de mailing
_passieren_ will,
egal aus welcher Richtung. Dass die Router das üblicherweise noch nicht
draufhaben, ist ein anderes Thema, aber von der Definition her ist das
doch klar?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
auch gut möglich sein. Ähnlich
übrigens für oneway:blabla -- bei oneway scheint es die anfängt
mit-Interpretation noch nicht zu geben?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
/wiki/Proposed_features/Conditions_for_access_tags
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Hinsicht
nur eine einmalige Begutachtung stattfinden muss.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Claudius schrieb:
Am 11.05.2009 17:42, Tobias Knerr:
Bernd Wurst schrieb:
Was haltet ihr dennoch von folgender Verkomplizierung:
Man sollte Reports eine Gewichtung geben können.
Das ist ein Feature, das man - falls es jemand schreibt - erfahrenen
Benutzern (sprich: Leuten mit Account
vergleichbare Techniken speichern, wenn die Anmeldung ein
Problem ist, aber trotzdem der volle Feature-Umfang bereitstehen soll.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
konfigurierbar machen und
e1) Konfiguration einem Account zuordnen
e2) Konfiguration über Cookie speichern (nur auf einem Rechner, wird
eventuell gelöscht ...)
Ich habe neben e1) auch e2) und d) schon erwähnt. a) und b) finde ich
nicht so toll. Welche Option bevorzugst du?
Tobias Knerr
stattdessen
auch den Wert des note-Tags in der Relationenliste an.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
lulu-...@gmx.de schrieb:
OSM soll auch für Sehgeschädigte nutzbar gemacht werden.
Dafür wurden zwei neue deutschsprachige Mailinglisten eingerichtet.
Warum deutschsprachig? Steht da irgendeine lokale Aktion/Verein
dahinter? Ansonsten ist das ja eher weniger eine regionale Problematik.
Tobias
den unterschiedlichen Werten für building gibts
schon lange, wird zigtausendmal verwendet und sollte lächerlich einfach
umsetzbar sein (prüfen auf building=* statt building=yes).
Ich sehe hier keinerlei Grund, sich an die Renderer anzupassen statt
umgekehrt.
Tobias Knerr
unterscheiden braucht.
Allerdings gibts auch noch Vorrangregelungen, so was hier:
http://de.wikipedia.org/wiki/Datei:Zeichen_308.svg
Die bräuchten eine from-to-Unterscheidung, und eigentlich sind sie vom
Konzept her das gleiche, oder?
Tobias Knerr
___
Talk-de
auch
die verkehrsberuhigung durch inseln an den seiten? Die stellen
das selbe ja quasi physisch her ;)
Die verschiedenen traffic_calming-Varianten mappen wir, ja. Aber ohne
Vorrangregelung brauchts da ja keine komplizierten Konstrukte für.
Tobias Knerr
finde b) weit einfacher und weniger konfliktträchtig.
Tobias Knerr
PS: Es ist wohl jedem klar, dass none nicht unbegrenzt heißt, sondern
kein(e). Aber keine Höchstgeschwindigkeit kann man sehr wohl als
(nach oben) unbegrenzte Geschwindigkeit auffassen. Dass man es auch
anders auffassen kann, stimmt
Werte durch numerische Werte (ggf. mit expliziter Einheit) ersetzen
wollen. Das ist nicht zu schwer auszuwerten, ist auf Key:maxspeed als
Beispiel erwähnt, die explizite Auszeichnung von nicht-km/h wird auf Map
Features verlangt und ist m.E. generell eine gute Idee.
Tobias Knerr
gedacht.)
Ich weiß jetzt nicht, wie deine Radrille aussieht, aber passt sie
ungefähr auf eine Radrampe wie in dem Draft da erwähnt?
http://wiki.openstreetmap.org/wiki/Proposed_features/Steps_features#Ramps
Tobias Knerr
___
Talk-de mailing list
Talk-de
diskutieren wir
in Monaten noch.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
politische Vorzüge
durch die Wahl eines eigenen Schlüssels (- Abkürzung der Diskussion).
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
.
Bei einer Filterung (hier ist mehr Information, als ich brauche)
stimme ich voll und ganz zu. Das ist aber was ganz anderes als hier
fehlt Information, lasst uns raten -- in so einem Fall sollten einfach
die fehlenden Infos explizit in die Daten rein.
Tobias Knerr
nötigen Codes beim
Auswerter wenig gewonnen.
Wenn man wirklich nicht mehr als eine einfache Tagumsetzung verlangt,
schätze ich, dass das wegen des geringen Aufwands sehr schnell in
Anwendungen Einzug halten kann.
Tobias Knerr
___
Talk-de mailing list
to be user
where really no speed limit at all is valid.
http://wiki.openstreetmap.org/wiki/Proposed_features/maxspeed_none
Für kein Schild daher bitte ggf. eine eigene Bezeichnung ausdenken, um
Verwirrungen zu vermeiden.
Tobias Knerr
___
Talk-de mailing list
denn daran zuviel Bedeutung? Von
geschützt oder so hab ich nirgends was gefunden.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
man mit
maxspeed:de etc. aber tun. Und genau das kann man z.B. mit deutschen und
italienischen Namen (name:de, name:it) tun, dort ist das aber im
Gegensatz zu maxspeed gewollt.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
Geschwindigkeit rausfinden, auch wenn man sich nicht für Zonen
interessiert (was häufig gewünscht sein wird).
Und mit anderen maxspeeds funktionierts auch noch.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo
nichts für
diese Geräte:
http://wiki.openstreetmap.org/index.php/Proposed_features/information
Wenn jemand einen geeigneten englischen Begriff dafür kennt, dann
tourism=information + information=der_begriff.
Tobias Knerr
___
Talk-de mailing list
Talk-de
Betrachten der History jedesmal nachzusehen, was du denn da gemacht
hattest, wirst du ja nie absichtlich eine leere Commit-Message wollen.
Richtig? ;-)
Wenn JOSM wenigstens eine history für die box hätte...
Das sollte natürlich nachgerüstet werden.
Tobias Knerr
).
Sie geht auf das Datenbankproblem adäquat ein.
Also im Ernst: Warum nicht? Ich würde sofort mit Freude zustimmen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
unnötige Arbeit wäre).
Wenn wir PD/CC0 hätten, wäre es natürlich kein Problem, dass der
Luftbildbereitsteller die Daten auch nutzen darf, das könnte man dann
auch gerne offensiv bewerben und als Ansporn für die Freigabe der Bilder
in die Waagschale werfen.
Tobias Knerr
Rechtsauffassung hier ist, dann sollte das dokumentiert werden.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Johann H. Addicks schrieb:
Tobias Knerr schrieb:
Meiner unwesentlichen Meinung nach sollten Anwendungen versuchen,
Implikationen unterstützen, wie sie etwa im Wiki auch genannt werden.
Wenn ich es richtig verstanden haben, dann sprechen wir in diesem
konkreten Fall über ein Fehlrouting
das ist juristisch-theoretisch dann wirklich
doof, wenn der dortige Server ausfällt).
Wir sollten allerdings aufpassen, keine Bilder von Martina Nolte
einzubinden. ;-)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
Jan Tappenbeck schrieb:
Wie wäre es mit einer Funktion die, vergleichbar der Historie, die
passende Kachel in OpenStreetBug öffnet. Das erleichtert die Suche !
OpenStreetBugs-Plugin bekannt? Wenn ja: Welche Aktion willst du
durchführen, die dort nicht möglich ist?
Tobias Knerr
hast du dir denn eine Umsetzung deiner Web-basierten Lösung gedacht?
Mit vorgerenderten Kacheln nehme ich an?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Fläche oder noch als Node zeichne.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
-Relation an (also ein
eigener Relation-Typ mit from-via-to-Mitgliedern). So was würde dann
auch diesen Fall hier abdecken können.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
incline-Tags. (Siehe ebenfalls
Diskussionsseite highway=steps.)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
rum ist,
was solls: ist nicht halb so schlimm wie bei Einbahnstraßen.
Wie willst du sicherstellen, dass zukünftige Treppen wenigstens meistens
richtig eingegeben werden? Die Wiki-Seiten werden nicht unbedingt gelesen.
Tobias Knerr
___
Talk-de mailing
+ step_count=1
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
ein solches Objekt bezeichnen -- dokumentiert ist
das leider nicht.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
,
dass andere Werte als Fallback wie yes zu behandeln sind). Verwendet
wird es durchaus auch, die 50.000 Fälle in Europa sind zwar gegenüber
730.000 building=yes nicht ganz so beeindruckend, aber ignorieren würde
ich die sicher nicht wollen.
Tobias Knerr
Jens Herrmann schrieb:
Tobias Knerr wrote:
Es gibt einen Schlüssel für die Anzahl der Stufen einer Treppe:
step_count (http://wiki.openstreetmap.org/wiki/DE:Key:step_count).
Super, danke. Spricht was dagegen das gleich auf DE:Map Features beim
Eintrag für highway=steps mit dazuzuschreiben
selbsterklärend hielt und sich daher eine Definition gespart hat:
http://wiki.openstreetmap.org/wiki/Key:service
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Jens Herrmann schrieb:
Es handelt sich um einen Hahn in einer Wand der
Brauchwasser liefert. Welches Tag soll man dafür nehmen?
Dazu gabs auch einen Thread im Forum mit ein paar mehr Antworten:
http://forum.openstreetmap.org/viewtopic.php?id=2923
Tobias Knerr
://wiki.openstreetmap.org/wiki/Proposed_features/Administration
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
schreiben und die entsprechenden Optionen zu deaktivieren? Das kann
doch wohl nicht wahr sein.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
die Erfassung detaillierterer Daten.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
eigentlich nicht klar, warum das damals nicht gemacht wurde.
Vielleicht noch mal nachhaken?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
hervorragendes Bindeglied zwischen unserer Datenbank und einer externen
Adress-/Branchen-/Telefonbuch-DB besteht, ist das eine natürliche Grenze
für Informationen, die ich in OSM erwarten würde.)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
-Dokumentationsschema, mit
Tagwatch und vergleichbaren Anwendungen
* der Länge der entstehenden Tags
Gefällt mir alles ganz und gar nicht.
Tobias Knerr
[1]
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
___
Talk-de
, brauche ich den eigentlichen Way ja grade nicht
auftrennen.
Tobias Knerr
* ich will damit nicht behaupten, dass man die wirklich in naher Zukunft
mappen muss... *g*
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org
, Auswertung, Tagwatch, ...) sinnvoll, die
selben Tags zu verwenden, die auch bei Einzelobjekten möglich sind --
was entweder den Einsatz von Relationen oder eines in der API noch nicht
vorhandenen Konstrukts verlangt.
Tobias Knerr
___
Talk-de mailing list
Talk-de
501 - 600 von 722 matches
Mail list logo
