Holger Schöner wrote:
Und wir erlauben, das auch auf die von uns
hochgeladenen Daten anzuwenden,
Wo steht das?
Was WIR zusichern, steht in 1.(a):
|If you contribute Contents, You are indicating that, as far as
|You know, You have the right to authorize OSMF to use and
|distribute those
Holger Schöner wrote:
In den (aktuellen) Contributor Terms sichern wir ja zu, dass die von uns
beigetragenen Daten unter CC BY SA 2.0, ODbL, und jeder anderen
zukünftigen OSM-Lizenz weiter verbreitet werden dürfen.
Ich glaube, da liest du zuviel in die CT hinein. OSMF sichert zu, die Daten
nur
Felix Hartmann wrote:
Sprich für die User wird es großteils (Ausnahme Garmin - weil
hier ja das Format geknackt ist) - keine kostenlosen Karten geben.
Dieses Argument höre ich hier nicht zum ersten Mal. Die Wirtschaft
funktioniert aber etwas anders:
Nehmen wir mal an, es gäbe für
Felix Hartmann wrote:
As I stated, my goal is to have OSM to continue under CCBYSA2.0
As I see it CCBYSA is not a goal but a tool. Before asking us to work with
- and to give our new data to - your project, it would be fair to tell us
what your real goals are. Then ask some layers if CCBYSA is
bernhard zwischenbrugger wrote:
Sometimes it's a bit delayed because of a problem with
delayed minute diffs (http://planet.openstreetmap.org/minute-replicate/)
Perhaps the replay could be a bit faster. I think, that as it is now the
delay will never get smaller again.
Norbert
Sven Geggus wrote:
Ich denke gegen name:de kann niemand was sagen der wirklich darüber
nachgedacht hat.
... solange name:de eine deutsche Form des landessprachlichen Namen ist.
name:de ist IMHO vorgesehen für lokalisierte Nutzungen der OSM-Daten.
Historische Daten haben dort z.B. in Straßennamen
Christian Schmitt wrote:
Wir haben irgendwann mal beschlossen aus dem Steuertopf amtliche
Kartenwerke erstellen zu lassen. Für deren Benutzung werden wir
paradoxerweise abermals zur Kasse gebeten.
Daran ist doch nichts paradox. Der Teil, der von den wenigen Nutzern
bezahlt wird, muss eben
Guenther Meyer wrote:
bei den adressen hat's komischerweise funktioniert:
da haben sich ein paar leute zusammengesetzt und ein klares schema
ausgearbeitet, und es wird benutzt.
beim oepnv-schema ist es glaub ich aehnlich...
In diesen Fällen haben die Macher auch OSM verstanden und aufgepasst,
Guenther Meyer wrote:
ich finde, es sollte einfach zusammengepackt werden, was sinngemaess
zusammengehoert.
Aber das kann man an einem Wort (...schule) sicherlich nicht. Haupt-,
Baum- und Delfin-Schulen haben genau *nichts* miteinander zu tun.
Norbert
Martin Czarkowski wrote:
Es scheinen Flüsse und Bäche zu sein, aber so viele auf einem Fleck?
Ab Zoom 12 sieht das doch ganz ok und richtig aus.
Wenn das überall in dieser Dichte wäre, würde das die Karte total
verunstalten.
Tut's ja schon in Teilen der US und GB.
Ich finde, dass die
Sven Geggus wrote:
Ich finde, dass die waterway Linientypen in z12-captionless nicht mehr
dargestellt werden sollten. Flüsse, die in z0-z11 zu sehen sein müssen,
sind so groß, dass sie auch als Flächen (mit riverbank) erfasst sind (bzw.
bald sein werden).
Das Problem ist ein Vollständig
Sven Geggus wrote:
Mir scheint, dass dort alles (Rinnsale, Bäche, Flüsse, Ströme)
in einem Topf zusammengemischt wurde.
Siehe anderes Posting von mir. Wir brauchen endlich definierbare
Flußbreiten in Mapnik.
In der mapnik-Karte tritt das Problem doch gar nicht so sehr auf. In den
Mirko Küster wrote:
Nein denn er will ja garnicht erst von bicycle=yes weg sondern alles andere
soll sich bitte eine entsprechend neue Definition suchen. Er klebt an seiner
Definition, Begründung weil etabliert.
*Warum* sollte er denn auch von bicycle=yes weg? Wenn es mal einen Grund
gäbe,
Mirko Küster wrote:
Nebulös ist da garnichts. In Verbindung mit Guidepost kein access. Ganz
einfach.
Ich glaub' jetzt hast du's ;-)
Also: Ab heute müssen alle Auswertungen umgestellt werden, damit sie (wenn
gleichzeitig Guidepost vorhanden ist) nicht mehr von der Bedeutung access
ausgehen.
Ab
Tobias Knerr wrote:
... informell ... sinnvoll ... oft ... erfolgt durchaus auch ... die paar
Ausnahmen ... m.E. ... die meisten Tags ...
Konzept?
Norbert
___
Talk-de mailing list
Talk-de@openstreetmap.org
Mirko Küster wrote:
So wie vorgestern highway=gate zu barrier=gate wurde, vorvorgestern claas=*
zu highway=*. Solange dokumentiert und bekannt kann sich jeder wie bei jeder
anderen Änderung darauf einstellen. Das Problem liegt jetzt wo?
Darin, dass highway=gate nicht plötzlich eine zusätzliche
Sarah Hoffmann wrote:
Würde er
bedingungslos alle Wege mit bicycle=* ins Routing aufnehmen, würden
einige Leute sehr nass werden.
Vielleicht sollte er eben zusätzlich zum Haupttag bicyle=yes auch die
beschreibenden Nebentags z.B. highway= auswerten (schon allein um eine
schöne Farbe für den Weg
Mirko Küster wrote:
Kommt drauf an was hinten rauskommt. Ein generelles mauern wegen ist so
bringt aber auch nicht weiter.
Ulf mauert doch nicht. Er hat - wie auch andere - versucht dir
klarzumachen, wo das Problem liegt. Das derzeitige bicycle=yes kann
(noch!) bei echtem Bedarf einmal zu
Sarah Hoffmann wrote:
Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten
benutzt wird, während ein Untertag nur in Kombination mit anderen Tags
anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl
etabliert, auch wenn es nicht im Datenbank-Schema
Steve Bennett wrote:
The most important thing, imho, is that different people who set out to tag
the same thing do it the same way.
This is only the secondmost important thing, because it can be corrected
or consolidated later. It is more important, that every tag is only used
for equal
bernhard wrote:
But it seams that all XAPI Servers are very slow or out of function.
All ROMA and TRAPI servers seem to be (near) down. So the TaH clients all
connect to XAPI or API. This makes a) XAPI and (less) API slow and b)
brings the renderspeed down to about 200 Z12-tiles per hour.
Shaun McDonald wrote:
sport = billard
billard = pool
or
sport = billard
billard = snooker
There are currently no such tags in OSM Wiki, should we suggest these
tags ot is it ok to just start using them? How will then other people
know how to tag their billiard clubs?
Just start
Shaun McDonald wrote:
It's
better to have a few ways to tag something and then decide which is
the best method after you have tried a few.
That is not the point. I believe, that it is ok to test some methods to tag
something. But not before this something is defined. It's nonsense to
look in
Tirkon wrote:
Danke für die Antwort. Allerdings habe ich den Speichermodus von
Potlatch benutzt und dennoch hatte die Änderung den Status in
Bearbeitung.
Auch im Speichermodus schließt Potlatch das changeset nicht bei jedem
save (nicht einmal, wenn du Potlatch beendest). Wenn du wert auf das
John Smith wrote:
2009/8/28 Roy Wallace waldo000...@gmail.com:
How about this...just tag a node (must be on a way) where the stop
sign/line is in reality, with the following:
stop:forward=yes, or
stop:backward=yes, or
stop=yes (for a node on a oneway=yes way, else implies the stop sign
Jonas Häggqvist wrote:
Which it is at literally every single point in space along most Danish
cycleways. This seems like a poor plan.
But else the mapping would mean: there is no connection.
This is why I think, creating a new way for the cycleway is often a poor
plan.
Norbert
Martin Koppenhoefer wrote:
2009/8/14 Konrad Skeri kon...@skeri.com:
Are there any progress on the left/right situation on cycleway=lane/track
that
are only on one side of the street?
yes, there is a solution for cycleway=track. Map it separately and tag
highway=cycleway. track can be
David Earl wrote:
So I say: keep it simple, keep it compatible. Carry on with the simple,
established tags we already have, but just clarify the default use
classes which apply to each highway tag, PER COUNTRY, and tag exceptions
to these according to evidence on the ground. Add specific legal
David Earl wrote:
So what you're saying is that
- each editor and data consumer has to have its own set of national
rules and defaults rather than defining them centrally (so inevitably
they'll end up different);
The editors must have some way to set defaults, the consumers will get a
full
Greg Troxel wrote:
For highway=cycleway, clearly bicycle=designated is implied.
Do you really think, that this is the case for *every* way tagged as
cycleway? Others have expressed the opinion, that bicycle=yes foot=yes
should be tagged as highway=cycleway too.
One advantage of Highway=path is,
Garry wrote:
... eine unglückliche Krücke die den üblichen tagging Gepflogenheiten
wiederspricht einen Grundtyp
anzugeben und in weiteren Tags den Zustand und die zulässigen
Nutzungsarten zu beschreiben.
... eine glückliche Krücke, die den üblichen tagging Gepflogenheiten
entspricht, das
Martin Koppenhoefer wrote:
wenn man sie als solche identifiziert, kann man sie ja verschieben.
Wer kann das? Mit welchen Geräten? Genau das sind doch meine Fragen. Die
OSM-Community kann es jedenfalls nicht.
Mein Garmin mit OSM hat
uns sauber auf
Tobias Wendorff wrote:
Eine Frage daher: Was hält uns daher eigentlich ab, die Straße als
Fläche einzuzeichnen und zusätzlich eine Strippe drüberzulegen, bis
die Anwendungen auch Flächen als Straße interpretieren können?
Die Genauigkeit der Datenerhebung. Die Strippe deutet wenigstens an, dass
Martin Koppenhoefer wrote:
Am 15. Juli 2009 19:11 schrieb Norbert Hoffmann nhoffm...@spamfence.net:
Die Genauigkeit der Datenerhebung. Die Strippe deutet wenigstens an, dass
es sich nur um einen ungefähren Verlauf handelt (auf einer Karte o.ä. kommt
es ja auch nicht so drauf an). Eine
Martin Koppenhoefer wrote:
mit ein bisschen Übung (und evtl. Unterstützung durch den Editor z.B.
durch ein eingeblendetes Raster zum Abschätzen des Maßstabs) wird man
allerdings deutlich höhere Genauigkeiten als +/-5 m hinbekommen. Damit
würdest Du ja implizieren, dass man eine Straße die z.B.
Mario Salvini wrote:
yes, it's all about designation. normal roads are designated for
motor_vehicles. But these roads are only designated for bicycles.
I would say: Normal roads are designated for all kinds of traffic and so
are cycleroads (but with special restrictions for motor_vehicles and
Stephan Wolff wrote:
Und die Übertragung der Regeln auf die Lowzoom-Karten steht auch noch aus.
Genauer wohl: die Übertragung auf z12 captionless. Der Rest ergibt sich
dann doch von alleine. Oder habe ich das stitching von z11-z6 falsch
verstanden?
Norbert
Heiko Jacobs wrote:
Wenn ich mir das gerade so druchlese, werde ich auch nicht so ganz
schlau draus, welche Stellschraube ab 11 zu drehen ist, sprich in
welcher Datei was zu ändern ist.
Ich verstehe das so, dass captionless-z12 das einzige ist, was für dich
noch anzupassen wäre. Die Tiles für
Heiko Jacobs wrote:
Modifizierungen für tracks z12-z17 und andere schmale Wege z12-z14
sind hochgeladen. Jetzt liegt das Schicksal in der Hand der
Style-Updates der clients, wann und wo man was sieht...
Kann da beim Hochladen etwas schief gegangen sein? Mir ist gerade
aufgefallen, dass einige
Martin Koppenhoefer wrote:
Am 26. Mai 2009 09:24 schrieb Mario Salvini salv...@t-online.de:
weil du z.B. theoretisch bei jeder Bordsteinkante dann einen Link-Way
zwischen Straße und Radweg machen müsstest.
dieses Problem ist allerdings grundsätzlich ungelöst und existiert
auch an anderer
Falk Zscheile wrote:
Besser finde ich Radwege als eigenen way einzuzeichnen, wenn er
baulich getrennt ist. Für nicht baulich getrennte Radwege bietet sich
cycleway=left, cycleway=right, cycleway=both[1] an.
Dann verliert man aber die Möglichkeit zwischen cycleway=track und
cycleway=lane zu
Nop wrote:
Jetzt hast schon in dem einfachen Beispiel Relationen, von denen Du
mehrfache Werte zulassen würdest und andere, von denen Du keine oder nur
einfache Vererbung haben willst - und keine definierte Regel, wie man
das unterscheiden könnte und auch keine Möglchkeit ein die beiden oder
Bernd Wurst wrote:
Einen faktischen Unterschied zwischen kombiniertem Fuß-/Radweg und Radweg mit
Fußgänger frei kann ich verkehrsrechtlich als Laie irgendwie nicht erkennen.
Den kann man aber so oder so nicht ausdrücken.
Nur wenn man (wie du) darauf besteht, beides als cycleway/foot=yes zu
Mario Salvini wrote:
So
highway=path + bicycle=designated + motor_vehicle=yes
is nonsense. If anything, it could be highway=track ...
is not a so unworldly situation out there.
And even then this is not the bicycle-street you talk of. Those are
physically mostly residentials with special
Mario Salvini begriff:
und wäre sie nicht als Radstraße ausgeschildert wäre es eine normale
Wohnstraße ohne Linien und um die 5m Fahrbahnbreite.
So sieht es wohl bei den meisten (allen?) Fahrrad*straßen* aus. Und für
Beschilderung gibt es nun mal andere als den highway-Tag.
Norbert
Mario Salvini schrieb, es sei
im OSM-Universum eine Fahrradstraße am besten mit highway=cycleway
motor_vehicle=destination foot=yes abgebildet.
Für die Kieler Fahrradststraßen ist das sicherlich nicht am besten. Die
destination-Einschränkung für KFZ wäre falsch, und außerdem besitzen hier
auch
Andy Allan wrote:
And nobody pays attention. The main problem is that two-way roads have
no inherent, real-world, direction - neither side of the road is the
right or the left. Or rather, both sides of the road are the right or
the left, depending on which way you are facing.
And that's why in
Andy Allan wrote:
And every time using :left and :right comes up, we all have a big
discussion about it and then nobody pays any attention and it comes up
again a few months later.
Perhaps this is because the concept leftright is so simple - and the
aversion against editors, that are not totally
Garry wrote:
Sobald hier der Wunsch aufkommt etwas für die Router im Taggingschema zu
optimieren kommt gleich
immer der Einwand wir taggen nicht für den Router und für Router
benötigt man sowieso eine Vorverarbeitung.
Du wünschst also etwas für Router zu optimieren? Sorry, das ist doch nun
Garry wrote:
Genauso ist es in OSM jetzt schon.
Osmarender und Mapnik stellen in bau befindliche Straszen dar,
so sie highway=construction construction=... getaggt werden.
... mittels eines doch recht umstrittenen Verfahrens durch Missbrauch
einer Highway-Kategorie.
Derjenige, der eine
André Reichelt wrote:
Gibt es Argumente dagegen?
Die jetzigen Lowzooms zeigen den Mappern doch recht gut, wie die Erfassung
der Welt vorankommt. Außerdem erkennt man einige Renderfehler, die bei der
Mapnik-Methode (jedes Zoomlevel wird seperat gerendert) erst in Zoom 12
auffallen. Wer würde sich
Frederik Ramm wrote:
There were some misconceptions about how multipolygon relations should
be used. Multipolygon relations have one outer way and 1-n inner
ways. We noted down and agreed on the following:
...
Was there some talk about what should happen with the old relations?
Everything tagged
Johann H. Addicks wrote:
Wie funktioniert es, Namen von Ortschaften/Gemeinden
a) für die geonames-Suche vollständig zu schreiben
b) auf der Karte aber keine Bandwürme beschriftet zu bekommen?
SO sollte es gehen: Du änderst im key name und löschst name, aus dem
key openGeoDB:auto_update.
Norbert
Frederik Ramm wrote:
Das wurde doch gemacht!
Bei mir hier ist population vom GeoNames-Import eingetragen.
Incl. openGeoDB:auto_update=population. :)
Hm, ich hatte den Eindruck, dass das nur sporadisch vorhanden waere,
das war auch mit Anlass zu meiner Nachfrage nach dem Stand der Dinge.
Kann
Garry wrote:
Durch die Nichtdarstellung schliesst Du eine ganze Gruppe an Anwendern
(die die mit der jeweiligen
Baustelle zu tun haben) die besonders Interessante Daten für OSM zur
Verfügung stellen könnten.
Niemand hindert dich oder andere daran, für speziell an Baustellen
Interessierte,
Tordanik wrote:
Für „abandoned“ kommt dein Einwand eher zum Tragen. Ich sehe aber nicht
wirklich einen Unterschied in der Darstellung der Realität, ob ich eine
ehemalige Straßenbahnschine als „abandoned railway“ beschreibe oder als
einen „tram-railway, der im abandoned-Status ist“.
Für mich gibt
Garry wrote:
Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche
Strecken vielen
gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt.
Das ist doch auch gut so. Ich möchte, dass mein Navi mich über Straßen
routet und nicht über Baustellen.
Norbert
Tordanik wrote:
Im Bau befindliches Atomkraftwerk:
power=generator
power_source=nuclear
status=construction
Hast du einen speziellen Gegenvorschlag?
Zu jedem Objekttyp wäre doch eine Erfasung analog zu highway und rail
möglich:
power=construction
construction=generator
Thomas Hieber schrieb (über Relationenunterstützung durch Render-SW):
type=multipolygon -- Wird genutzt um Löcher in Flächen zu erstellen
(z.B. Lichtungen im Wald)
Eigentlich ist multipolygon so definiert worden, dass die Renderer es gar
nicht verstehen müssen (Uhrzeigersinn / gegen den
Matthias Urlichs wrote:
It's certainly conceivable that it's a sync problem, but not particularly
likely: I assume that the window between deleting an old version of a
polygon and uploading the new version is not _that_ large.
I think, its a problem with the amount of waypoints. Might the edit
Jacques Nietsch wrote:
Eine andere ernst gemeinte Frage an die 'alten Haasen' hier: warum
gibt es zu diesem Thema eigentlich keine Gruppe im Usenet? Oder gibt
sie es doch?
Die Mailingliste selbst wird als 'gmane.comp.gis.openstreetmap.region.de'
bei gmane (news.gmane.org) angeboten.
Norbert
Martin Simon wrote:
Falls es kein grundlegendes logisches Problem gibt: lasst uns bitte
nicht wieder um die unzulänglichkeiten eines Renderers herum mappen...
Genau das macht aber die derzeitige Multipoligon-Relation. Ein See (mit
Loch=Insel) wird logisch erst durch die Relation beschrieben.
Gerald.Oppen wrote:
Nach Deiner Argumentation wäre eine primary auch keine Strasse wenn sie
für LKWs durch ein entsprechendes Flag gesperrt ist(z.B. wegen den
Mautflüchtlingen).
Oder willst Du den highway-tag nur auf die Anwendung für PKWs beschränken?
Nein. Aber meine Argumentation lautet ja
Gerald.Oppen wrote:
Unsinn ist es statische Daten dynamisch machen zu wollen und damit
zusätzlichen
Aufwand zu schaffen.
Der Prozess Idee-Planung-Bau-fertige Straße ist nunmal dynamisch. Für mich
muss sich das dann auch in einer Änderung des highway-values
wiederspiegeln (sofern denn
Guenther Meyer wrote:
warum dann ueber das highway-tag?
Weil genau dieses tag die Art des Objektes beschreibt.
das besitzt werte wie motorway, primary, secondary, residential, ...
sowas wie planned oder under construction passt rein semantisch schon gar
nicht da rein.
IMHO muß diese
Guenther Meyer wrote:
das highway-tag in der form ist mir eh schon lange ein dorn im auge...
da muss man nicht noch mehr reinpacken, und es noch schwammiger machen.
Schwammig wird der highway-tag, wenn man zusätzlich noch andere tags
auspressen muss um seine Bedeutung zu ermitteln.
Norbert
Gerald.Oppen wrote:
Das ist so Murks!
Der Strassentyp steht in der Regel schon mit der ersten Planung fest.
So wurden mir schon einige meiner Einträge für in Bau oder Planung
befindlichen Strassen wieder überschrieben
und damit in meinen sämtlichen verwendeten Anwendungen wieder unsichtbar
Guenther Meyer wrote:
sorry, aber diese herangehensweise erscheint mir unlogisch.
ein highway=primary und was in der art construction=yes sollte das ganze
sinnvoll beschreiben.
Warum ich das für falsch halte, habe ich ja schon geschrieben:
Wenn eine Baustelle mit highway=primary getagged
Dermot McNally wrote:
I became aware of the new scale bar on the slippy map through another
thread over on dev. It's certainly nice to have one, and it was an
obvious absence that google maps (and others) had but OSM didn't.
Shouldn't a scale bar change its length, when scrolling the map
80n wrote:
I've made the following changes:
1) State borders are thicker
2) Secondary roads are narrower and the colour saturation has been reduced
3) Railway lines are a little blacker.
What do you think?
It looks much better. Have you done the changes only for the test or are
they going out
maning sambale wrote:
More work cleaning up some missing ways due to GML linestring errors.
Still, BEAUTIFUL!
Looks really nice. But there seems to be something in the data, that
prevents rendering since the 4th.
There must have been hundreds of tries until now.
From
Christoph Eckert wrote:
Zwar ist es als Motivationshilfe
unverzichtbar, aber wir mappen doch, um die Daten hinterher für ganz
verschiedene Anwendungen zur Verfügung zu haben. Navigation beispielsweise
(show me the way to the next beverages store). Oder
Peter Miller wrote:
Ok, so how do I tag a section of highway that is going to be grubbed up and
returned to nature (which is happening for short sections of the A14 at
Haughley Bends)?
I am currently using the following coding:
highway=trunk
construction=disused
Does that seem ok?
I think
Andy Robinson wrote:
Something
like highway=trunk and proposed=true would be good enough for me.
If you make that highway=proposed and proposed=trunk only those, that want
to render proposed streets, have to change their rulefiles.
Andreas Jacob wrote:
Zoomstufen
Wie ist eigentlich der zeitliche Rahmen für das Rendern der Zoomstufen
ab 11 abwärts (10, 9 etc.)? Einmal wöchentlich scheinen diese nicht
gerendert zu werden.
In der Mapnik-Karte werden auch die niedrigen Zoomstufen AFAIK wöchentlich
neu gerendert. Bei [EMAIL
75 matches
Mail list logo
