You are not logged in.
More information: https://help.openstreetmap.org/question … the-moment
Sounds like OSM should seriously start considering creating a press reviews page on its website
We have a collection of media reports about OSM in the wiki: OpenStreetMap in the media
The GigaOm link is already on there. ![]()
gibt schon sowas wie livemusic=yes?
Es gibt
8 live_music = yes
1 live_music = Sa, Su
1 live_music = Sunday
http://taginfo.openstreetmap.org/keys/live_music#values
Nachtrag: Es gibt außerdem 25 mal "music_genre" als Schlüssel.
BBO wrote:Gibt es derzeit Probleme? Beim Durchlauf gestern Abend sind hier alle Grasflächen auf der Slippy Map schwarz gerendert worden.
Ups, du hast recht. Müssen wir mal nachforschen.
Ich vermute einen Zusammenhang mit einem Patch, der weitere Tags als "Grasfläche" erkennt.
Als Erklärung hierzu vielleicht noch den Link auf issue 58: Es handelt sich um ein Problem beim Grafikkartentreiber.
Der Patch führt nur dazu, dass es diesmal mehr Flächen betroffen hat, ist aber nicht direkt verantwortlich.
Geoguesser: http://www.geoguessr.com/
Liest du zufällig xkcd? ![]()
Wegen eines unausgereiften Editors alteingesessene Tags umändern?
Nein: Anlässlich der Einführung eines neuen Editors feststellen, dass die "alteingesessenen" Tags eigentlich ganz unabhängig vom Editor ziemlich verbesserungswürdig sind. ![]()
Die Idee von der Mailingliste ist:
1. Man hat keine implizit richtungsabhängigen Tags mehr.
2. Bei explizit richtungsabhängigen Tags beschränkt man sich auf die Werte forward/backward/left/right.
Dadurch wäre es sehr einfach, auch unbekannte richtungsabhängige Tags korrekt zu behandeln. JOSM tut das ja bereits, eben auf Grundlage der Annahme, dass ein alleinstehendes Wort aus der o.g. Liste Richtungsabhängigkeit signalisiert. Auch Mappern wäre die Richtungsabhängigkeit klarer, wenn sie durch ein gesondertes Tag verdeutlicht würde - es ist ja nicht offensichtlich, dass cliff oder coastline niemals bedeutungserhaltend umgedreht werden können.
Als Bonus würde man das nicht wirklich verständliche "-1" los. Und bei manchen Werten - nämlich bei Rolltreppen, Flüssen oder wo man sonst Sonderwerte wie 'wechselnd' hat - braucht man nicht einmal einen neuen Schlüssel, denn das ist implizit gar nicht ausdrückbar.
Von daher finde ich den Vorschlag gar nicht so doof und wäre dafür zu haben.
I've read about Osmosis, but I couldn't figure out how to actually get the object structure in java, rather than transforming the data to some other format I have no use for
Did you find this?
http://forum.openstreetmap.org/viewtopi … 12#p213212
I think you need to implement another interface method in the sink that has been added since then, but the basics should still be correct.
Gibt es derzeit Probleme? Beim Durchlauf gestern Abend sind hier alle Grasflächen auf der Slippy Map schwarz gerendert worden.
Ups, du hast recht. Müssen wir mal nachforschen.
Ich vermute einen Zusammenhang mit einem Patch, der weitere Tags als "Grasfläche" erkennt.
Da scheint es Teile zu geben die nur für Linux kompiliert wurden.
Ja, das ist korrekt. Das Programm an sich ist zwar in Java geschrieben und du könntest auf deinem System auch z.B. die Exportfunktionalität nach .obj oder .pov nutzen. Für hardwarebeschleunigtes Rendering mit OpenGL werden allerdings die nativ kompilierten JOGL-Bibliotheken verwendet.
Im Verzeichnis lib/jogl/ liegen solche kompilierten Versionen für Linux, Windows und Mac OS. Ich habe sie nicht selber übersetzt, sondern die Builds von der JOGL-Website verwendet. Dort stehen außer den genannten noch Versionen für Android (auf ARM) und Solaris zur Verfügung, aber soweit ich sehe leider keine für OpenBSD. Ob es prinzipielle Probleme dabei gäbe, JOGL für OpenBSD zu kompilieren, oder ob sich einfach keiner darum kümmert, weiß ich nicht.
Ach ja, ist der Output da zufällig von 0.1.9? Das beschriebene Problem sollte auch aktuelle Versionen betreffen, aber wenn du schon experimentierst wären mir Erkenntnisse zur aktuellen Version natürlich lieber. ![]()
oneway:(00:00-12:00) = -1
oneway:(12:00-24:00) = 1
Das war mal ein Proposal, es wurde aber nie angenommen. Zudem sind verschiedene Entwickler dagegen Sturm gelaufen wegen der Sonderzeichen in Keys, der dadurch entstehenden unendlichen Anzahl möglicher Keys etc.
Diese andere Variante hier entspricht dem einzigen Mapping-Standard, der ein akzeptiertes Proposal im Rücken hat:
oneway:conditional = yes @ (12:00-04:00); -1 @ (04:00-12:00)
Mit der Auswertung sieht es da allerdings generell noch schlecht aus. Daher ist das zusätzliche oneway=reversible als high-level-Angabe sicher eine gute Idee.
INFO: Osmosis Version 0.40.1
Ein Hinweis nebenbei: Erst seit 0.42 hat Osmosis Unterstützung für 64-bit IDs. Das macht bei dem von dir geposteten Skript zwar glaub ich keine Probleme, aber falls du auch noch andere Osmosis-Aufrufe nutzt, solltest du daran denken.
Besser die Brücke als Relation oder als Fläche erfassen.
Das würde ein besseres Rendering erlauben (eben als eine, nicht als zwei Brücken), auch wenn es wie so vieles momentan leider noch nicht ausgewertet wird.
(Edit: 2. Link korrigiert, danke @reneman)
Zum Testen kann man das sicher mal machen, aber die richtige Lösung dauert wohl etwas länger, wenn man Bugs und Notes parallel einlesen und kommentieren können möchte (neue Reports natürlich nur als note).
Wenn man vermeiden will, zusätzliche Funktionalität einzubauen: Ein neues Plugin als leicht angepasste Kopie des alten Codes machen und für alte Bugs weiterhin das alte Plugin nehmen?
Auf lange Sicht braucht man sowieso nur noch die notes-Funktionalität.
Ich hatte als Passauer Gelegenheit, den Abschlussvortrag zu dieser Arbeit zu besuchen. Mir hat das Konzept gut gefallen, auch wenn die Implementierung natürlich noch raue Ecken hat. Es wäre prima, wenn man sich mit Bildverarbeitung das Mapping etwas erleichtern könnte.
Auto hab ich aber leider auch nicht - ist denn keiner experimentierfreudig hier? ![]()
Ist ID bei euch auch so fürchterlich langsam und zäh zu bedienen? Auf meinem Netbook kann man damit nicht arbeiten. Nach jedem klick vergehen mehrere Sekunden bevor etwas passiert. Potlatch und Josm lassen sich dagegen flüssig bedienen.
Auch bei mir langsam und ruckelig, und das auf einem Desktop-PC. Wenn man ausreichend reinzoomt, dann ist er gerade so bedienbar, aber es macht keinen Spaß.
Trotzdem schön, dass wir jetzt eine Flash-freie Option im Browser zur Verfügung haben. Das Medienecho war ja auch recht positiv; Mapbox hat eine Liste von Artikeln zusammengetragen, die auch noch nicht mal auf OpenStreetMap in the media stehen.
Danke, die Seite "Editor usage stats" kannte ich noch nicht. Diese unübersichtliche Sammlung von Zahlenkolonnen auf dem Stand von 2011 sollte auch mal jemand überarbeiten.
![]()
Tordanik: Schön, dass Du´s liest
Ich dachte, area:highway=<value> bzw. street:area=<value> kann genau so betrachtet werden wie die anderen landuse=<value>
Die habt Ihr schon, oder?
Einheitlich gefärbte oder texturierte Flächen haben wir schon, ja. Aber bei Straßenflächen will man ja etwas anderes: Dort sollen die Fahrspuren und sonstige aus den Tags am Way abgeleitete, richtungsabhängige Informationen weiterhin sichtbar bleiben - nur muss die Straße als Ganzes ihre Form verändern. Die Lösung dafür muss also gesondert programmiert werden.
Eigentlich muß die Frage nach street:area=<value> direkt an Tordanik gestellt werden.
Der liest hier mit. ![]()
Ich würde mir durchaus wünschen, in OSM2World Straßenflächen zu unterstützen - meines Wissens ist derzeit area:highway=<value> das Tag der Wahl. Derzeit ist dafür allerdings noch keine Unterstützung vorhanden, weil die Programmierung recht komplex ist.
Wer sich für ein paar Details z.B. zur ins Auge gefassten Hardware interessiert, kann sie im Mailinglisten-Post von Frederik nachlesen:
http://lists.openstreetmap.org/pipermai … 01968.html
Ich frage mich gerade, wie man wohl Weinlagen und Anbaugebiete taggt. Eine Weinlage (wie z.B. der Nacktarsch http://de.wikipedia.org/wiki/Nacktarsch ) besteht aus einer Ansammlung von Weinfeldern. Hier würde sich wohl ein site-Relation anbieten. Oder eher eine boundary-Relation?
Aus dem Bauch heraus würde ich eine Grenze vorschlagen, da das beim Bearbeiten der darin liegenden Weinfelder weniger stört.
Kann man da eine exakte Grenze angeben oder ist das der noch nicht so wirklich gelöste Fall "unscharfes geografisches Gebiet"?
crop=Riesling
Ein Wert wie "Riesling" ist m.E. zu detailliert für den crop-Schlüssel, wo sonst ja Werte wie "coffee" oder "bananas" (nicht etwa "Cavendish") stehen.
Also ich würde das wohl auch nicht eintragen, da gibt es lohnendere Info. Aber wenn, dann passt doch inscription?
Gar nicht! Wieso soll OSM unbedankt Werbung für eine Firma machen?
Ist es denn Werbung, einen Supermarkt oder Verkaufsautomaten einzutragen? Ich sehe die Inschrift einer Parkbank schlicht als objektiven Fakt an.
More global statistics: http://osmstats.altogetherlost.com/index.php?item=nodes
I don't know any public statistics for individual extracts. Based on the size of Geofabrik's Europe pbf extract (10.1 GB) compared to that of the Planet (20 GB), I would agree with Chris' 50-60 % estimate for Europe, though.
I have the same problem. My JOSM tells me:
Ihre Java-Version wird bald von aktuellen JOSM-Versionen nicht mehr unterstützt, Sie sollten sie auf Version 7 oder besser aktualisieren!My Java-Version is:
java version "1.7.0_21" OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-0ubuntu0.12.04.1) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)Who knows the solution for this problem?
I have almost the same Java version on Ubuntu, and I'm not getting the warning (I'm on JOSM 5924 though). There was at least one bug before version 5883 where that message was displayed incorrectly. So considering that you are already on version 7 (aka 1.7), I believe this is a false alarm.
digby's problem is most likely genuine, though. Unfortunately, I don't know much about Macs, but I hope someone finds a solution.
Wie wär's mit umtaggen auf man_made=flood_light_pole. Sieht man aber dann auf keiner Karte.
Wenn umtaggen, dann käme noch in Frage:
man_made=lamp
lamp:type=floodlight
per http://wiki.openstreetmap.org/wiki/Prop … tures/lamp
Sieht man zwar sicher auch auf keiner Karte, aber ist zumindest Teil eines recht durchdachten Schemas.
Sieht nach einem Versuch aus, den Kronendurchmesser zu erfassen. Also beim Umtaggen eventuell mit eintragen?
In der unteren per iframe eingebundenen Karte ist die Werbung tatsächlich zu sehen.
Ich vermute mal, das es etwas mit diesem Aufruf zu tun hat:http://www.map-generator.net/extmap.php?name=Modellbahnkiste%20innenstadt&address=Kirchenallee%2025%20Hamburg&width=500&height=400&maptype=map&zoom=14&hl=de&t=1275296285
Ah, das ändert natürlich die Sachlage. Die Karte wird also nicht direkt von Google eingebunden, sondern über den Umweg von "map-generator.net". Dieser Dienst schiebt dem Nutzer dabei anscheinend Werbung unter. Das haben auch andere schon festgestellt - via Websuche findet man einige Treffer. "Zufällig" verwenden die Betreiber von map-generator auch noch die Werbevermittlung aus dem Hause Google, wodurch der Eindruck entsteht, Google selbst würde diese Werbung den eigenen Karten beilegen. Das ist aber nicht der Fall, die offizielle Einbindefunktion von Google ist derzeit wohl werbefrei.
Also: Kein neues Argument gegen Google, sondern nur ein Drittanbieter mit zweifelhaften Geschäftspraktiken, von der Werbeeinblendung erfährt man nämlich auf deren Webseite soweit ich sehe nichts. Dieselbe Masche könnte man auch mit OSM abziehen.
Zeigt mal wieder, dass ein einfacher Link viele Gerüchte aufklärt...