all the other
data sources are listed, too - considering the large number of sources,
it's clearly resonable to have a separate page for sources.
Technically, they don't provide the license URL directly (only
indirectly through the link to OSM), but I don't consider that a
relevant problem.
Tobias
so lässt sich in einem Schilderwald auch eindeutig beschreiben,
welches Zusatz- zu welchem Hauptschild gehört.
Tobias Knerr
[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_sign
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
Monate zu
früh dran. ;)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
(Wertstoffhöfe
auf mehr Zoomstufen sichtbar), POI-Suchen (wo gehts zum nächsten
Wertstoffhof) oder dergleichen automatisierte Auswertungen aufbauen will.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
beste Platz für diese
Information ist - Wikipedia wird aber auch nicht allen Anforderungen
gerecht und ist eben insbesondere keine Datenbank.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
JOSM. Wenn die Schlüssel und Werte in den OSM-Daten
irgendwann einmal nur noch von Programmen geschrieben und gelesen
werden, dann kann man sich auf Feinheiten der Syntax verlassen.
Momentan ist das nicht gegeben.
Tobias Knerr
___
Talk-de mailing list
Talk
Perfektion und
Verbreitung.
Insofern muss die verrückten Ideen jemand anderes übernhemen. Ich
erwarte bis 2020 neben einer Qualitätssteigerung ohnehin vor allem auch:
Überraschende Einfälle, an die ich jetzt noch gar nicht denke. :)
Tobias Knerr
___
Talk
.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Relevanzkritiker die
Forderung, dass Aussagen in WP durch Quellen zu belegen sind, durchaus
gut finden.
Die Anforderung, dass ein anderer Mapper eine Information verifizieren
kann, indem er sich selbst vor Ort begibt, ließe sich durchaus als
OSM-Entsprechung zu den Quellenangaben in der Wikipedia sehen.
Tobias
ausdrücken ließen; beispielsweise Mo-Fr 3h, Sa 1h und sonst gar
keine Höchstparkdauer.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
.
openstreetmap.de, btw, is not officially part of the project.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
:
http://wiki.openstreetmap.org/wiki/Proposed_features/maxspeed_none
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
hat das Programm also Recht, vgl. auch:
http://wiki.openstreetmap.org/wiki/DE:Road_Signs#Zusatzzeichen
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
gelöscht werden, sondern
von der Anwendung ausgefiltert werden sollen. Dieser tolerante Ansatz
macht das momentane OSM-Projekt für mich schon einmal deutlich
angenehmer als WP.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
Key:barrier standardmäßig implizierte access=no
angenommen werden muss.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Geschmack
access:(11:00-12:00) = destination
access:(18:00-20:00) = destination
Das access durch die passende Verkehrsmittelklasse, z.B. motorcar,
ersetzen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org
Falk Zscheile schrieb:
Am 28. April 2010 20:07 schrieb Tobias Knerr o...@tobias-knerr.de:
Wie für jedes andere Tag auch finden sich Implikationen bei
barrier=*-Tags in prinzipiell maschinell parsbarer Form in den
Key/Value-Templates im OSM-Wiki.
[...]
Für die meisten Werte fehlt diese
Bearbeiten betreffen.
Im Moment jedenfalls gehe ich nicht davon aus, dass von Hand erfasste
Geodaten zu existierenden, aber irrelevanten Objekten die Qualität der
sonstigen Daten in OSM jemals großflächig beeinträchtigen und damit
Relevanzhürden notwendig machen werden.
Tobias Knerr
allen betroffenen Mappern Bescheid gäben, bekämen wir wohl
einen netten Lynchmob zusammen. ;-)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
mit Lizenzen
nicht auskennt, kann durchaus glauben, dass die Nennung von OSM ausreicht.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
waren. Wenn selbst eine doch eher zentrale Seite wie DE:FAQ
nicht durchgehend auf dem aktuellen Stand gehalten werden kann, sehe ich
bei großflächig angelegten Übersetzungen schwarz.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
: Selber billiger anbieten. ;-)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
bei unserem Schema im Schlüssel. Davon sollten wir definitiv
nicht abweichen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Frederik Ramm schrieb:
Tobias Knerr wrote:
Elektrofahrzeuge sind eine Verkehrsmittelart, und Verkehrsmittelarten
stehen bei unserem Schema im Schlüssel.
Das wuerde ich so grundsaetzlich nicht sagen. Du hast zwar recht, dass
es so ist, aber es ist nicht so, weil sich irgendjemand das
/Key:source:maxspeed
Tobias Knerr
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at
nicht drauf oder ist ein solcher Fall in unserem
Schema nicht möglich?
Solche Dinge sind mit Basisschlüssel-Basiswert-Paaren (also unserem
etablierten Schema ohne Verwendung von Proposals) in der Tat nicht möglich.
Tobias Knerr
[1]
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features
ich derzeit keinen
überzeugenden Grund, warum ich mir die Mühe machen sollte, neben dem
klassischen Schema auch advanced multipolygons in einer Anwendung zu
unterstützen. Jedenfalls einer Anwendung, die nur physische Objekte und
keine Grenzen oder dergleichen verarbeitet.
Tobias Knerr
[Kopie eines Eintrags von stephan75 im OSM-Forum unter
http://forum.openstreetmap.org/viewtopic.php?id=6954 ]:
An dem Wochenende 04.-06. Juni 2010 findet in Lüneburg eine Konferenz
bzw. ein Workshop-Wochenende unter dem Projektnamen Skillshare statt.
Es handelt sich um eine sog.
phrases it.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Sven Geggus schrieb:
Landen die erfassten Adressdaten eigentlich wenigstens in der OSM Datenbank
wenn Nein haben die nämlich gar keine Erlaubnis die Luftbilder zu verwenden.
http://lists.openstreetmap.org/pipermail/talk-de/2010-March/065613.html
Es ist in Arbeit. Momentan also: Nein.
Tobias
hat), eine *geplante* Synchronisierung
als Tatsache hinzustellen:
Wie soll eine Datenübernahme von OSM zu OA lizenzrechtlich möglich sein?
Eure Lizenz hat schließlich keine Share-Alike-Bestimmung.
Tobias Knerr
___
Talk-de mailing list
Talk-de
- prinzipiell auch über eine Tabelle -
und verhindert unnötigen Streit.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
einfachen konvexen Polygonen
korrekt. Bei konkaven Polygonen wie
Guckst du hier: http://osm.org/go/0DKSJsuLE--
oder gar Multipolygonen hat man ein schwieriges Problem vor sich.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
. Dafür sprechen gewisse Artefakte -
etwa, dass Bäume, die zwischen Straße und Haus stehen, an die Hauswand
tapeziert werden.
Übrigens, ich bin auch beeindruckt. Google ist schon ein passabler
Konkurrent. ;)
Tobias Knerr
___
Talk-de mailing list
Talk-de
Jan Tappenbeck schrieb:
es gibt Treppen mit einer Rampe für Kinderwagen und Fahrräder.
highway=steps, dazu dann eben eines oder mehrere der folgenden Tags:
ramp:stroller=yes - Rampe für Kinderwägen
ramp:bicycle=yes - Rampe für Fahrräder
ramp:wheelchair=yes - Rampe für Rollstühle
flag. This information is then used to add Bs next to Bot edits in
history/watchlist/... and for a Hide bots filter in these lists.
Instead of making this a property of an account, we could also implement
bot flags for individual edits by attaching a bot=yes to the changeset.
Tobias Knerr
hätte. Die
konkreteren Mängel intuitive Benutzungsmöglichkeit und
anfängerfreundliche Doku hätten problemlos für sich stehen können.
Insofern war die Kritik einfach unnötig konfliktträchtig formuliert.
Tobias Knerr
___
Talk-de mailing list
Talk-de
-than-Potlatch editing is possible.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
(primarily
high-detail, low-abstraction rendering). But detailed information like
that should be mapped *in addition* to ways, maybe similar to
waterway=riverbank. I don't think that there is an established tag, but
any tag that /isn't/ highway=* (or anything else already in use) should
work.
Tobias
genug, dass
ich es da einsetzen würde. Abkürzungen sind ein Muss, und
Tippfehlertoleranz ist man inzwischen eigentlich auch gewohnt...
Tobias Knerr
PS: Funktioniert das mit dem , lauf überhaupt? Gibt schließlich
mehrere Orte mit dem Namen.
___
Talk-de
://forum.openstreetmap.org/viewtopic.php?pid=53150
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
associate with a tag, the
more probable it is that someone's implicit assumptions are different
from yours. That's why a largely meaningless object like path has a
certain appeal.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http
künstliche Beschänkungen in den Daten lösen.
Übrigens: Bei mir findet Nominatim für Wilhelmstrasse problemlos auch
Wilhelmstraßen, was die ganze Diskussion ziemlich theoretisch macht..
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
And yes, the effect is limited to the OSMWiki.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
sowie nach IL-Links
zu parsen (evtl. mit aus den Wikipedia-Interwiki-Bots entlehntem Code?)
und dann auf die vom OLM-Benutzer gewünschte Sprachvariante zu linken.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org
aus irgendeinem Grund die Zugehörigkeit zum Gebäude nicht ohnehin
eindeutig durch Verortung im building-Polygon zum Ausdruck kommt (also
fast nie).
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
wird, als wenn man eines der
Ziele zurückstellen würde, sollte aber klar sein.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Tags was
sinnvolles dabei gedacht hat. Also immer den konkreten Fall beurteilen,
wenn man fremden Tags begegnet.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
aufs Material verzichten kann (das von der Bauart oft schon
weitgehend vorgegeben wird) und mit einem Zusatztag auskommt.
Die Höhe ist auch wichtig. (m.E. wichtiger als der genaue Typ). Würdet
Ihr eher height oder barrier:height verwenden?
height, siehe Antwort auf Falks Mail.
Tobias Knerr
maxheight:physical eingeführt?
(Falls es diesbezüglich wirklich unterschiedliche Interpretationen gibt
und Diskussionsbedarf besteht, bitte ich um Abspaltung unter geändertem
Betreff.)
Tobias Knerr
[1] http://wiki.openstreetmap.org/wiki/Key:height
___
Talk-de
... verwenden würde.
Lösungen wie
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
lassen sich z.B. problemlos auch auf smoking übertragen
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
, Proposal o.ä.; hat
gerade an die 200 Verwendungen:
http://wiki.openstreetmap.org/wiki/Key:fence_type
Gefällt euch die dortige Werteliste? Sollte man den so lassen,
erweitern, bestimmte Aspekte verbessern (welche?) oder lieber komplett
neue Schlüssel definieren?
Tobias Knerr
, Proposal o.ä.; hat
etwa 200 Verwendungen:
http://wiki.openstreetmap.org/wiki/Key:fence_type
Gefällt euch die dortige Werteliste? Sollte man den so lassen,
erweitern, bestimmte Aspekte verbessern (welche?) oder lieber komplett
neue Schlüssel definieren?
Tobias Knerr
nur in einem Teil des Außenbereichs ist dann nicht möglich.
Ich fände also etwas nach Art von smoking:outside=yes/no/separated
besser, das man zum normalen smoking-Tag hinzufügen kann, wenn es einen
Unterschied zwischen drinnen und draußen gibt.
Tobias Knerr
dortige XAPI-Link[2]
geht auch.
Tobias Knerr
[1] http://osmdoc.com/de/tag/barrier/wood_fence
[2] http://www.informationfreeway.org/api/0.6/*%5Bbarrier=wood_fence%5D
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo
eine von deiner Meinung abweichende Projektregel von vornherein die
Aufnahme in die Datenbank verhindert hätte, könntest du das nicht.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
://rurseekatze.bplaced.net/olm2/?zoom=18lat=50.25935lon=10.96494layers=B0TT
Klammern und das de:-Präfix werden in der Nähe dort auch verwendet,
scheinen also nicht die Ursache zu sein.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
gehört hat. Dem ist es dann natürlich ganz und gar nicht
klar, dass man dort auch abgeben kann.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Richtung entwickelt haben.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Norbert Hoffmann schrieb:
Tobias Knerr wrote:
... informell ... sinnvoll ... oft ... erfolgt durchaus auch ... die paar
Ausnahmen ... m.E. ... die meisten Tags ...
Konzept?
Aussage deiner Mail?
Falls du mit dem zerpflückten Zitat etwas sagen wolltest wie wenn es
nicht durchgehend
Neuerfinden von
Tags, noch mit den bereits jetzt unterschiedlichen Bedeutungen abhängig
von den begleitenden Tags (z.B. crossing, parking) zurecht. Auch wenn
man guidepost jetzt noch umbiegen könnte, für die anderen existierenden
abweichenden Bedeutungen gilt das kaum mehr.
Tobias Knerr
some experimentation, have turned out to
be the inferior choice.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
-Nutzern leichter
fällt, ein Forum zu bedienen, als umgekehrt.
Gleichzeitig darf das gerne als Diskussionsanstoß dienen, wie man am
besten mit unseren gespaltenen Kommunikationsmedien umgeht.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
there are different representations (such as long segments and
short segments) that represent reality equally well, choosing the one
that is easier for applications isn't a problem at all, but rather a
good idea.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
to be in metres.
Ich weiß nicht, was du damit aussagen willst, die Stellen zu zitieren,
die meine Aussage belegen: Bestimmte, metrische Einheiten kann man
weglassen (weil sie als Default angenommen werden), andere Einheiten nicht.
Tobias Knerr
___
Talk-de
die Aufgabe der meisten
Datennutzer.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
strenge Anwendung, die die Werte benutzt.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
der Meinung ist, dass die entsprechende Information überhaupt
vorhanden sein sollte.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Standpunkt stellt, dass sowohl die
Unterscheidung zwischen explizit und implizit als auch die sonstige
Info, die mit innerorts noch einher geht, irrelevant ist, dann *ist*
das die am einfachsten auszuwertende Lösung, die es realistischerweise
geben kann.
Tobias Knerr
Sascha Silbe schrieb:
On Wed, Jan 06, 2010 at 04:46:23PM +0100, Tobias Knerr wrote:
[Innerorts über spezielles Tag an jedem Weg markieren]
Möchtest du lieber Bounding-Polygone auswerten?
Ja! Vorverarbeitung ist sowieso nötig (zumindest wenn man in mehr als
nur ein paar Städten routen
nur eine Geschwindigkeitsbeschränkung (mit integrierter Angabe
des Grundes) taggen wollen oder die innerorts-Eigenschaft mit
sämtlichen anderen Auswirkungen - das bringt natürlich alles ein wenig
durcheinander. Bei sauberer Trennung gibt es hier aber kein Problem.
Tobias Knerr
muss m.E: schon klar sein, ob 30er-Zonen traffic zones sind (dann
*kein* zusätzliches maxspeed, ebensowenig wie maxspeed=50 bei DE:urban)
oder ob sie einfach nur eine Variante der expliziten Geschwindigkeits-
Beschilderung sind (dann DE:urban und maxspeed=30).
Tobias Knerr
this
by manually positioning a label, either.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
OSM data *itself* - with features such as
changeset list, data layer, XML export, etc.. And for that purpose, we
don't need closed rendering styles.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Dave F. wrote
Tobias Knerr wrote:
In order to truly show what's possible, we would need to completely
redesign that front page into a featured products catalogue [...]
It doesn't have to be completely redesigned, just a link saying:
And here's some other great ways in which OSM can be used
?
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Ort warst. Insofern
ist es sehr nützlich, dass OSM nicht nur Straßen, sondern auch
Hundekottütenspender verzeichnet. ;)
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
das
auch dann, wenn man uns gegebenenfalls nichts nachweisen könnte.
(Mal abgesehen davon, dass ich mir systematisch reproduzierte Fehler,
veraltete Informationen, geloggte Serverzugriffe und dergleichen
durchaus als Grundlage einer Beweisführung vorstellen könnte. Aber
IANAL, zum Glück.)
Tobias
verschiedenen
Teilthreads diskutiert werden.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Florian Lohoff schrieb:
On Tue, Dec 22, 2009 at 08:52:59PM +0100, Tobias Knerr wrote:
Ich finde beides unnötig kompliziert und unflexibel - das passiert eben,
wenn man Relationen um jeden Preis vermeiden will.
Guck dir einfach mal die grossen relationen unserer Deutschen Aussengrenzen
die Luftbilder bereitstellt.
Die Idee urheberrechtlich womöglich nicht schützbar, also setzen wir
stattdessen auf Nutzungsbedingungen liegt ja auch der ODbL zugrunde.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
/wiki/Proposed_features/Railway), insofern
wäre das wohl die naheliegendere Wahl.
Ansonsten Zustimmung: Die Existenz eines passenden und auch gerenderten
Tags kann dem Taggen für den Renderer durchaus den Boden entziehen.
Tobias Knerr
___
Talk-de mailing
Möglichkeiten:
a) da stehen wirklich mysteriöse Straßenampeln an der Schiene
b) es handelt sich um einen Fehler in den Daten.
Aus keinem der beiden Fälle ergibt sich ein besonderer Handlungsbedarf
für den Renderer. Ist also nicht dein Problem. :)
Tobias Knerr
is that it only works in renderers
designed with the intention to display /everything/. I'd expect good
rendering styles to be limited to a selected subset of the available
information.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http
* bessere
Lösung anzubieten hat.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
die
CC-by-SA-Forderung nach einer Namens- und Lizenznennung reasonable to
the medium.
Tobias Knerr
PS: Ich finde es sehr fragwürdig, dass inzwischen bei jedem schaut mal,
was da tolles mit OSM gemacht wird als erste Reaktion eine Lizenzrüge
kommt - und das anscheinend jetzt sogar schon unabhängig
permission to distribute it under both licenses, but a user can of
course decide to only publish modifications under one of the two licenses.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
been touched by a larger number of
contributors, and of course there will be a larger amount of data in the
database overall).
So unfortunately, we need to decide soon - and in absence of reliable
empirical data available, only theory is available.
Tobias Knerr
be at a disadvantage.
I'm not sure about attribution, either. Wouldn't the fork have to
attribute OSM as well, making attribution significantly less convenient?
Tobias Knerr
___
legal-talk mailing list
legal-t...@openstreetmap.org
http://lists.openstreetmap.org
* wegabstrahiert werden.
Mit Trennung kann man durchaus häufig vorkommende Wertbestandteile im
Ergebnis ausmachen. Da kann man dann schon was mit anfangen - z.B.
Aussagen darüber treffen, wie häufig die Mapper die XX off-Konstrukte
verwenden (statt Intervalle zu splitten).
Tobias Knerr
information. It's not really possible for an automated process to do
anything else.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ausprobiert.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
or poi or whatever just as well as amenity) is
a method to work around this.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Steve,
SteveC wrote:
How is insulting people going to help things?
By letting them know FUD and BS will be shot down.
I understand that most statements you are responding to seem stupid,
unnecessary or inappropriate to you. You might even think that those who
posted them should really know
Ben Laenen wrote:
Tobias Knerr wrote:
There is a concept that covers all of these and uses oneway:bicycle:
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_fo
r_access_tags
The bicycle:oneway structure, to my knowledge, hasn't been part of a
solution that can be used
variant, to my knowledge, hasn't been part of a
solution that can be used to express all of these cases yet and is
mostly just there as a solution for this single situation (opposite
traffic on oneway ways). Imo, that's a too limited perspective.
Tobias Knerr
dargestellten Gebildes. Dieser
Logik nach ist das alles beim width-Wert eines highway-Ways mit
einzubeziehen.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
weitere Dinge, die deswegen nicht darstellbar sind.
Eine Definition dazu waere hilfreich, egal wie sie
ausfaellt, sonst ist die Auswertung sehr schwierig.
Absolut richtig.
Tobias Knerr
___
Talk-de mailing list
Talk-de@openstreetmap.org
http
just what's on the ground).
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
(or DE:cycleway or any other value that isn't exactly
cycleway) for German cycleways, as that would still be one meaning
per tag.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
601 - 700 of 1076 matches
Mail list logo
