Re: [Talk-at] GeoImage in HiRes (!)
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 Contents under our current licence terms. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] GeoImage in HiRes (!)
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 unter o.a. Lizenzen zu verbreiten. Wir sichern zu, dass die Daten zu der aktuell(!) gültigen Lizenz kompatibel sind. Bei Lizenzänderungen muss also weiterhin der User um seine Zustimmung zur Weiterverwendung gefragt werden. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
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 Garmins (und nur für Garmins) kostenlose Karten, die auch funktional den derzeit verkauften Navteq-Karten fast gleichwertig wären. Welch Folgen hätte das? Für Garmin wäre es günstiger selbst diese OSM-Karten statt der (auch im Einkauf) teureren Navteq-Karten auf ihre Navigationsprogramme zu optimieren (TTS-Ausgaben, Fahrzeitschätzungen etc.). Der Preis für diese Karten würde fallen müssen um mit kostenlosen Karten konkurrieren zu können. Mit billigen Kartenupdates hätte nun aber Garmin ein Verkaufsargument gegenüber z.B. TomTom und Navigon, die darauf selbst nachziehen müssten. Auch deren User hätten einen Nutzen. Was OSM also erreichen kann, ist den kommerziellen Wert von Geoinformationen zu senken. Und das auch noch je freier die Lizenz - umso besser. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Let's prepare to Fork OSM to a CCBYSA 2.0 continuation
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 the right tool to achieve this goals. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Live Ticker
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] name:de oder old_name in ehemals deutschen Gebieten?
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 nichts zu suchen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NACK Gemeindegrenzen Baden-Württemberg für OpenStreetMap
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 gerade nicht aus dem Steuertopf genommen werden. Die 99% Nichtnutzer sind's zufrieden. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
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, dass nicht an der Bedeutung von bestehenden Tags herumgeändert wurde. warum geht sowas bei POIs nicht? Es geht sicherlich. Aber nicht indem man die Bedeutung eines Tags (hier im Beispiel shool) ändert und damit tausende von vorhandenen POIs entwertet. Norbert PS: Und *nein*, dass man auf die alte Bedeutung schließen kann indem ein Nebentag ausgewertet wird, ist keine Lösung. Es zeigt nur auf, dass genau so eine Bedeutungsveränderung stattfinden soll. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Porto Velho und Palmas
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 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). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flußbreiten (was: Zwischen Porto V elho und Palmas)
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 anderes! Ein karthograph hat mir erklärt, dass Flüsse auf karten generell in ihrer wirklichen Breite dargestellt werden und im gegensatz zu Straßen nicht überbreit. Das habe ich in osmarender realisiert, sodass ein Fluß mit Breitenangabe (nur falls erfasst natürlich) im richtigen Maßstab gezeichnet wird. Dann sind aber die Breiten, die genutzt werden wenn keine Angabe gemacht wurden, in z12-captionless *viel* zu groß. Immerhin ist lt. tag-Beschreibung im Wiki ein waterway=stream überspringbar und ein waterway=river schmaler als 12m. Drain dürfte normalerweise vergleichbar zu river sein. Norbert PS: Der Graben hinter meinem Haus wird übrigens von professionellen Kartographen nur in Detailkarten eingezeichnet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Porto Velho und Palmas
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 Mapnik-Styles werden kleine Gewässer doch nur in Maßstäben dargestellt, in denen sie auch sinnvoll sind. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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, dann wäre es aber möglich. Natürlich soll sich alles *andere* einen *anderen* Tag suchen. Das verhindert viel sinnloses Gehopse bei der Datenauswertung. Wenn du jetzt aber bicycle=yes mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Eine Möglichkeit die doch keiner hier in betracht zieht. Wann soll die kommen? Wie geschrieben: bei Bedarf. Der existiert aber nicht wirklich. Wer ein altes key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da Gegenwind von denen, deren Arbeit da teilentwertet werden würde. Da wird doch nichts verwässert weil beide Tags zusammen einen anderen dokumentierten Kontext ergeben. Deine Forderung an alle Datenauswerter jetzt und zukünftig einen nebulösen Kontext auszuwerten statt eine eindeutige Bedeutung vorzufinden, ist keine Verwässerung? Ein bicycle=yes kann auf einem Guidepost kein access sein. Ergo kannst du Guidepost bei einer Routinganwendung guten gewissens ignorieren. (Und komm' nicht mit abhängig vom Haupttag - was soll das sein?) Schon tausende male geschrieben. Und schon genausooft mit Es gibt bei OSM kein Konzept 'Haupttag'. Dafür wäre es nötig technisch durchzusetzen, dass jedes Element einen und genau einen dieser Tags bekäme. Dem ist nicht so. beantwortet. Gruß, Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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 morgen müssen ... Ab übermorgen müssen ... - sinnloses Gehopse! Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Haupt-Tags (was: guidepost)
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 http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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 andere Bedeutung bekommen hat - du aber für bicycle=yes zusätzlich zum bisherigen hier kann man Fahrrad fahren heute auch hier sind Infos für Fahrradfahrer, morgen hier kann man Fahrräder kaufen, übermorgen an diesem Kirchturm hängt ein Fahrrad (gibt's wirklich) usw einführen willst. - sinnloses Gehopse! Nö ganze normale Enetwicklung in einem offenem System. Wenn du kein Gehopse willst dann musst du von offen auf verabschiedete Standarts umschwenken. Lerne Lesen. *sinnloses* Gehopse. offenhohl Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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 auszusuchen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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 access:bicycle=yes o.ä. gewandelt werden, denn für genau diesen Fall ist es definiert. Wenn du jetzt aber bicycle=yes mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Wer ein altes key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da Gegenwind von denen, deren Arbeit da teilentwertet werden würde. Norbert (Und komm' nicht mit abhängig vom Haupttag - was soll das sein?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
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 festgeschrieben ist. highway=* ist ein Haupttag. tourism=* eines. information=guidepost ist keines und bicycle=* sicherlich auch nicht. Und du schreibst also vor, das je way oder node nur genau einer dieser Haupttags genutzt werden darf? Ich nehme an, du überarbeitest jetzt auch alle Knoten, an denen derzeit z.B. amenity *und* shop vorhanden sind. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] no rendering of amenity=veterinary
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 features in reality. If people use the same tag for different meanings the information is lost. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMXAPI stable?
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. Norbert PS: Mumin doesn't show data for tah.openstreetmap since some days ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] sports=billiard and sports=snooker ?
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 using them. You don't need to have a vote on a tag to be able to use it. Right, no vote is needed. But I would recommend some entry in the Wiki, where the semantic of this tag is explained. Else we will have the problem in the future that we have them in the db - but nobody knows if it is billard clubs or only the billard table in my cellar (just beside my winecellar and the swimming pool :). Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] sports=billiard and sports=snooker ?
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 the db for used tags if you do not know what objects those tags are used for. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Was bedeutet Changesets in Bearbeitung?
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 Beenden des changesets legst, dann kannst du es perAdvanced/Close changeset (links unten) manuell machen. Für das Speichern der Daten in der Datenbank macht das aber sowieso keinen Unterschied. Ein changeset ist keine Datenbanktransaktion! Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
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 applies in both directions) +1 You are still trying to tag for routing software, or trying to compare a stop sign with a oneway segment, this really should be dealt with as a bigger issue of lanes rather than the hacks people seem to be coming up with. No, Roy wants to tag the semantics of the stop-sign. If this really simplifies the task of the data consumers, it's all the better. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cyclelane on left/right
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cyclelane on left/right
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 considered deprecated ;-) But don't forget to connect the cycleway to the road wherever it is possible to change from one to the other. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
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 designations only where expert knowledge is available and different from the default interpretation. I say: forget all defaults and store all those values in the database. Those only partly documented defaults are the cause of the discussed problems. The process of tagging may be as simple as it is now. Let the user choose which country he is in (or which country's rules are in his head while editing) and than the editor can add those defaults. What we win with this method is, that the apps working with the data need not know anything about country borders or specific legals and changing some default in the WIKI will no longer invalidate data. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
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 dataset. So they must know the defaults plus the interpretation of the tagger(!) *now* but not later. - we have to massively increase the amount of data we store by saying for every road that it is open 24 hours a day (because some aren't) and has a 44 tonne weight limit (or whatever it is by default in your country) except for the few cases where it isn't; all cycleways don't permit llama pack animals (because some in Peru do) and all motorways explicitly do or don't permit horse drawn vehicles. The most common values (by highest count) can be left out from the *db* and only be stored once. So yes, there must db-wide-defaults. - we can't type a simple tag any more, we have to go via a menu or a form because there are so many of them. Every highway would have to carry maybe thirty or forty tags giving use cases, Shure you can tag cycleway and nothing else, but you'll have tell the editor once, what a cycleway means to you. and every time we realise we are missing a use case (say we discover motorways in Ecuador permit learner drivers to use them [please don't tell me this isn't the case - it's only an example]) we have to add tags to every other highway in the world to say that there learner drivers can't, otherwise we're assuming a default. If you'll need to update any record in the table for this is a question of design. - and that we have to update almost every way in the system already why? and change every bit of software we already have why? Norbert playing advocatus diaboli ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
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, that there is no implication besides not wide enough to be a track. norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Höherwertige Straßen in Orten - cons truction
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 als Grundtyp zu erfassen, was wirklich existiert - und nicht was daraus einmal werden soll. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
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 der richtigen Seite angezeigt :) Heißt dein Smiley jetzt, dass du selbst weißt, dass das absolut nichts über die Genauigkeit der Daten aussagt? Mein Garmin mit OSM-Karte hat mein Auto auch schon auf parallel verlaufende Radwege geraten. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
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 es sich nur um einen ungefähren Verlauf handelt (auf einer Karte o.ä. kommt es ja auch nicht so drauf an). Eine Erfassung als Fläche täuscht eine Genauigkeit vor, die mit Hobbymitteln derzeit wohl nicht zu erreichen ist. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
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 Erfassung als Fläche täuscht eine Genauigkeit vor, die mit Hobbymitteln derzeit wohl nicht zu erreichen ist. das ist m.E. ein Nullargument, da es für alle Flächen und sowieso für alle Dinge zutrifft, die wir eingeben. Der Unterschied liegt darin, dass z.B. landuse aber auch Gebäudegrundflächen eine zusätzliche (ungenaue) Information beschreiben. Flächig erfasste Straßen täuschen diese Mehrinfo nur vor. Eine Erfassung hier ist die durchgehende Fahrbahn, hier die Abbiegespur ist bei Genauigkeiten von +/- 5m beispielsweise eine Nullinfo. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
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. real 8 m breit ist, evtl. in OSM mit 3 oder 13 m Breite zeichnen würde. Das ist aber Quatsch. Man würde versuchen, sie ungefähr mit 8 m Breite zu zeichnen, real dann aber vielleicht auch nur 7,20 m oder 8,50 m zeichnen. Damit kann man aber gut leben. Du hast mein Beispiel nicht gelesen/verstanden: |Eine Erfassung |hier ist die durchgehende Fahrbahn, hier die Abbiegespur ist bei | Genauigkeiten von +/- 5m beispielsweise eine Nullinfo. Mit der Information hier ist /meine/ Richtungsfahrbahn kann man schlecht leben, wenn dort in Wirklichkeit der Gegenverkehr fließt. Warum sollen solche Falschinformationen in OSM? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Bicycle boulevards
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 some special rules for bicycles). That's why it's highway=cycleway + motor_vehicle=yes (instead of an implied motor_vehicle=designated for normal roads. That's why I would call it highway=residential + designation=cycleroad. Norbert PS: I know only the cycleroads here in Kiel. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] railway in osmarender
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway in osmarender
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 die lowzoom-Stufen bastelt daraus der Serverprozess sobald ein z12 geändert wurde. Damit diese Tiles nicht zu überfrachtet werden, ist captionless-z12 ja auch etwas vereinfacht: z.B. sind Straßen breiter und auf die flächigen Bestandteile ist ganz verzichtet worden. Das solltest du wohl für deine (IMHO optisch ansprechenden) Änderungen so weiterführen. Im SVN sind jedenfalls Dateien osm-map-features-z*.xml für 6 bis 17 Und an 12 bis 17 habe ich bisher erfolgreich gebastelt. Hätte vermutet, dass ich an den entsprechenden 6 bis 11 weiter machen müsste... Die werden derzeit wohl nicht benutzt. Allerdings liegt auch ein captionless-z12.xml und caption-z*.xml für 0 bis 11 drin ... Die Captions sind ja vor Kurzem neu gerendert worden, da ist wohl nichts weiter zu tun. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
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 Clients jetzt z17 scheinbar mit den Styles von z16 rendern (nur entspechend größer: http://www.informationfreeway.org/?lat=54.316772877520904lon=10.138690702138852zoom=17layers=BF000F Die Nordhälfte ist ok, im Süden siehts falsch aus. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing - Separater Radweg und andere Probleme
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 Stelle (z.B. Autobahnabfahrten). Dort ist das aber kein Problem, solange Autobahn und Ausfädelspur gemeinsam als *ein* way gemapped werden und die Trennung da erfolgt, wo kein Wechsel mehr möglich ist. Ich plädiere für das gleiche Vorgehen (= eigenständiger cycleway nur da, wo kein Übergang vom Radweg auf die Straße möglich ist). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradwege
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 unterscheiden. Es gibt aber auch den Vorschlag :right/:left als suffix zum key zu benutzen: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left . Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ref tag bei ways erforderlich wenn eine relation existiert?
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 auch eine andere-Ref zu erzeugen. Nehmen wir noch eine neue, unbekannte Relation hinzu (ich darf ja jederzeit neue Typen eintragen oder den Way weiteren Relationen zuordnen), und das Chaos ist komplett. Relativiert sich dieses Problem nicht dadurch, dass es doch eigentlich nur genau einen Relationstyp (route=road) gibt, der genau dafür geschaffen wurde vererbbare Eigenschaften zusammenzufassen. Die anderen Relationen (z.b. bus) definieren doch andere Objekte, die den Weg nur nutzen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Foot-Access auf cycleway? (Routing (Re: Hilfe, meine Stadt hat Flecken))
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 taggen. Alle anderen können das sehr wohl. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] overuse of highway=path
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 access restrictions and priority rules. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Fahrradstraße.
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße.
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 die Fahrradstraßen noch getrennte Fußwege. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [tagging] RFC :left/:right (asymmetrical roadside features)
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 real-world you would say Look in the direction to the railstation and then the church is on your left. If you want to describe objects with a handedness you'll need some concept of sides. If you call it left/right, green/red or nearer to some related point at the side/farther from ... doesn't really make a difference. Perhaps, if always the same proposal is made (Let's use the order stored in the db to define a /direction/ of a way and then use right and left to /name/ the sides.) this is the most user friendly method? Norbert has followed the discussions for only the last 1 1/2 years ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] RFC :left/:right (asymmetrical roadside features)
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 key-ignorant is not so easy to understand. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] construction
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 wirklich Unsinn. Router benötigen für ihre Aufgaben nun wirklich keine nicht vorhandenen Wege. Du versuchst nur das Tagging für *deine* Belange zu optimieren. Und die Probleme hast du nur deshalb, weil du unbedingt mit dem Schraubendreher einen Nagel einhauen willst (= eine *von anderen* für Routing auf vorhandenen Straßen entwickelte Navi-Karte als Notizzettel für deine Erfassung von Baustellen und Planungen benutzen willst). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
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 Kategorie missbraucht, bist doch du. Ein highway=primary war bisher (und wird immer noch genau so verstanden) eine existierende, benutzbare Straße mit impliziten Eigenschaften (maxspeed, access etc). Diese werden auch von den die Daten auswertenden Anwendungen für Karten und Routen z.B. so genutzt. Du meinst jetzt durch ein neues tag alle diese Eigenschaften außer Kraft setzen zu müssen und verlangst von allen diesen Geisterfahrern sich dir anpassen zu müssen. Du verstehst den Gegenwind? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tracks durch Felder
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 schon z.B. ganz Europa in Zoom 12 ansehen wollen? In Zoom 5 sieht man derzeit z.B. noch, dass irgendwie in einem Streifen mitten durch Frankreich in N-S-Richtung die Z12-Captionless-Tiles leer gewesen sein müssen - inzwischen größtenteils nachgerendert. Ab etwa Zoom 7 sieht man einige schwarze Klötze. Auch hier ist beim Rendern der hohen Zoomstufen was falsch gelaufen. Mir gefällt es so, wie es ist: Mapnik-Layer für die bis auf die erkennbaren Details vereinfachte Karte in allen Zoomstufen und Osmarender-Layer als Hilfsmittel für die Erfassung (viele Informationen aber optisch etwas überladen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] SOTM relations workshop: results
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 for the renderer until now will have the semantics of e.g. a lake in the lake or a building inside of a bulding. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Beschriftung
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
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 es sein, dass all jene Staedte, die schon vor dem Import einen eigenen Node hatten, keine Bevoelkerungszahl verpasst bekommen haben? Ich schätze, dass viele Mapper den (wegen der langen Namen doppelten) OpenGeoDB-Ort gelöscht haben. Bei mir in der Gegend habe ich mir die Mühe gemacht, den alten Ort zu löschen (sofern ohne zusätzliche Infos), den GeoDB-Ort zu verschieben und name aus auto_update rauszunehmen. Sowas in der Art erwarte ich von einer zukünftigen Datenübernahme automagisch. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
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, auch spezielle Karten (...) herzustellen. Die Daten ja sind in beiden Fällen vorhanden. Nur nach dem Vorschlag von Tordanik müssten *alle* Altanwendungen geändert werden, um nicht plötzlich Alt- und Plan-Daten als Ist-Zustand misszuverstehen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
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 es im 2. Fall nichts mehr, das einen Status haben könnte. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
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 power-source=nuclear Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations, Site und Gewerbeparks
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 Uhrzeiger / tags nicht beim Polygon, sondern an beiden ways). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Bad coastline
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 from the 21st be a joining of the many ways the coastline consisted before? Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Zu viel Traffic!
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Multipolygon und Landuse
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. natural=water muss also Attribut der Relation sein. Der äußere way benötigt _kein_ Attribut (er alleine bestimmt ja auch nichts) und der innere way könnte bei Bedarf z.B. mit natural=wood getagged werden. Ein zusätzlicher way mit identischen nodes ist eigentlich unnötig. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
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 auch: Setze highway=primary nur dann, wenn auch ein Primary-Highway existiert. Eine Baustelle oder gar nur ein Plan *ist kein* Primary-Highway. Straßensperren für LKWs ändern dagegen nichts an der realen Existenz der Straße. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
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 physikalisch nicht Vorhandenes überhaupt in die db gehört). Du dynamisierst statt dessen die *Bedeutung* des values (und nennst das dann statisch). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
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 Information aber genau dort hinein. Für den IST-Zustand bedeuten diese Inhalte nämlich: Dies ist (noch) gar keine Straße! Bei nicht vorhandenen Straßen die Standardwerte einzutragen würde die Semantik des highway-tags verändern (verwässern, verfälschen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet! )
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 (Dass der Name highway für alle Arten von Tracks nicht glücklich ist, sei unbenommen.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
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 gemacht die ich bereits in der Praxis verwende- auch um bei diversen baupolitischen Entscheidungsträgern zu zeigen was mit OSM geht! Mit highway=construction wird der Vorteil von OSM die aktuellen (Planungs-)Zustände wiederzugeben zu nichte gemacht. Zu highway=construction gehört deshalb ja auch construction=primary bzw. das Zutreffende. Meiner Meinung nach muss construction ein Flag sein - Vorzugsweise mit einem Wert für In Plannung und In Bau der dann den Renderer anweisst die Strasse gestrichelt bzw. transparent darzustellen wie Wenn eine Baustelle mit highway=primary getagged würde, dann wäre plötzlich die Bedeutung dieses Eintrages geändert. Bisher ist highway=primary eine größere befahrbare Straße. Wäre construction ein zusätzlicher key, dann können sich plötzlich auch noch Schlammwüsten, Pläne in einer Schublade oder unausgegorene Ideen in den Köpfen einiger Leute dahinter verbergen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [KA-Geo] Strassen in Bau (highway = construction ist ungeeignet!)
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 würde, dann wäre plötzlich die Bedeutung dieses Eintrages geändert. Bisher ist highway=primary eine größere befahrbare Straße. Wäre construction ein zusätzlicher key, dann können sich plötzlich auch noch Schlammwüsten, Pläne in einer Schublade oder unausgegorene Ideen in den Köpfen einiger Leute dahinter verbergen. ... und wenn construction gesetzt ist, dann WIRD das eine entsprechende strasse. wenn alles fertig gebaut ist, einfach das construction flag entfernen, und gut is. ... und die Routingprogramme müssen wissen, dass highway=primary nicht immer zum Routing herangezogen werden darf (und so weiter und so fort). Wenn es (noch) keine Straße ist, dann halte ich es für Unsinn es als Straße zu taggen und noch Ausnahmekeys zu erfinden. die renderer muessens dann halt auch entsprechend darstellen. Und das würden sie auch tun, wenn du nicht eine andere als die schon genutzte Methode Baustellen zu kennzeichnen verwenden würdest. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Oh look, a scale bar. But...
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 vertically? Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Recent (last few weeks) [EMAIL PROTECTED] render changes
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 to the wild? Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Naga City in OSM Re: GML to OSM
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 http://tah.openstreetmap.org/Tiles/info.php?x=3449y=1891z=12 Requested at 2008-04-05 04:00:18, by koelly:tahCltReReq:NoData, with priority 1. Current state is Active (out to client). Taken by client at 2008-04-09 00:41:39. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Darstellung von Getränkemärkten
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 Garmin-Karten. Oder eigene Druckwerke. Bei all diesen Sachen ist es unerheblich, ob der Getränkemarkt, den ich eingetragen habe, vorher auf der Slippymap auftauchte oder nicht. Wichtig ist, dass die Information da ist. Für /eigene/ Druckwerke mag das gelten (dann wird OSM aber nur als kostenloser Speicherplatz benutzt. Aber in all deinen anderen Beispielen hilft eine private Bezeichnung gar nichts. /Information/ wird eine Zeichenkette erst dann, wenn sie mit einer festgelegten Bedeutung verknüpft wird. Und die Stelle, an der diese Verknüpfung bisher vorgenommen wird, ist Map Features. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Mapping Mottram and Tintwistle proposed bypass
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 highway=disused disused=trunk would be more consistent to construction and proposed. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Mapping Mottram and Tintwistle proposed bypass
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. Norbert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Radwanderwege, Flussbreite, Zoomstufen, josm
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 PROTECTED] gibt es keinen festen Zeitrahmen. Wer kann und will rendert mal einige Tiles und das auch noch nach ganz unterschiedlichen Regeln. Als besonders anschauliches Beispiel siehe: http://tah.openstreetmap.org/Browse/?x=134y=92z=8layer=tile (dort sind in den 9 angezeigten Kacheln wohl 4 unterschiedliche lowzoom-Versionen im *aktuellen* Einsatz. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
