Re: [Talk-de] amenity=education? //Re: VHS Außenstellen taggen // Re: OSM an der VHS - OSM-DVD
Am 22. Juni 2011 13:05 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: in der db gibt es auch erst 62: http://taginfo.openstreetmap.org/search?q=amenity%3Deducation#tags kleiner Nachtrag: in der education-Familie (als Keys) gibt es allerdings schon ein paar mehr: http://taginfo.openstreetmap.org/search?q=education#keys Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnen in der Straße und Straßenbahnen (war: DE:zone)
Am 22. Juni 2011 14:22 schrieb phobie omlists.pho...@safersignup.com: tram und light_rail hat wegen des identischen Gleiskörpers eigentlich nichts im railway-Key zu suchen. -1, das siehst Du schon am Wort Gleiskörper. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22. Juni 2011 14:43 schrieb fly lowfligh...@googlemail.com: +1, ich war schon immer für highway=cycleroad (o.ä.) aber bisher (=in den letzten Jahren) war die Mehrheit dafür, das nicht zu machen. das gehört in eine zusatz tag analog zu motorroad=yes. -1, warum? Gehört highway=pedestrian auch in einen Zusatztag? Und highway=cycleway? Es ist eine eigene Klasse, und daher gehört es auch in keinen Zusatztag. highway=living_street würde ich auch als Unfall definieren und in ich nicht. Warum sollte das ein Fehler gewesen sein? highway=* (meist residential) und living_street=yes konvertieren ! Warum? Was ist der Vorteil? Ich setzte immer zusätzlich ein living_street=[highway] (residental). jeder kann ja taggen, wie er will, aber m.E. erzeugst Du damit nur unnötige Redundanzen... Zu tram: Ich kenne bis heute keine bessere Möglichkeit um zu beschreiben, das Bahnschienen in der Straße verlaufen. Ist zwar nicht erlaubt funktioniert aber mit railway=* + highway=* an einer Linie und ist ja auch richtig, da die Linie ja eben beides ist. wenn die Richtung der Straße dieselbe ist wie die der Schienen ist es m.E. richtig, wenn wir aber von einer Kreuzung sprechen, dann fahren keine Autos auf den Schienen in Schienenrichtung, und dann halte ich ein highway=* auch für ungeeignet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22. Juni 2011 16:12 schrieb phobie omlists.pho...@safersignup.com: On 22.06.2011 11:33, Walter Nordmann wrote: Wir haben klare Regeln, was Bulk-Uploads betrifft und ich bin der Meinung, dass diese hier auch gelten: Die stehen wo? http://wiki.openstreetmap.org/wiki/Automated_Edits http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct [...] besser aber noch in der Tagging-ML Oh die kannte ich noch gar nicht, ist ja wohl auch noch relativ neu. jein, ganz neu ist die nicht mehr, gibts seit Oktober 2009. Ich bin nun beigetreten. sehr gut. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22. Juni 2011 17:05 schrieb Gerhard Hermanns herma...@ptt.uni-due.de: Am 22.06.2011 14:57, schrieb M∡rtin Koppenhoefer: Zu tram: Ich kenne bis heute keine bessere Möglichkeit um zu beschreiben, das Bahnschienen in der Straße verlaufen. Ist zwar nicht erlaubt funktioniert aber mit railway=* + highway=* an einer Linie und ist ja auch richtig, da die Linie ja eben beides ist. wenn die Richtung der Straße dieselbe ist wie die der Schienen ist es m.E. richtig, wenn wir aber von einer Kreuzung sprechen, dann fahren keine Autos auf den Schienen in Schienenrichtung, und dann halte ich ein highway=* auch für ungeeignet. auch wenn es jetzt etwas off topic ist, möchte ich hier doch gerne auf ein Kuriosum aufmerksam machen, das es z.B. in Mülheim a. d. Ruhr gibt: Hier fährt die Straßenbahn auch mal ENTGEGEN der Fahrtrichtung der Autos. klar, das war durchaus mit enthalten in der obigen Beschreibung. Ich bezog mich auf Stellen, wo eine Straße von Schienen gequert wird, und dort für den Bereich der Querung die Schienen in der Straße verlaufen. Dann ist highway=* auf den Schienen m.E. Quatsch in unserem Graphen-Modell für Wege, wobei durchaus für den Bereich innerhalb der (Straßen-)Fahrbahn in einem Flächenmodell auch dort Straße ist, wo die Schienen laufen. Gruß Martin Bsp: http://maps.google.com/maps?q=Westbahnhofstra%C3%9Fe,+T%C3%BCbingen,+Deutschlandhl=deie=UTF8ll=48.515339,9.074659spn=0.000223,0.000654sll=37.0625,-95.677068sspn=34.999041,85.693359t=hz=21 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landmasse Italien, Relation 957374
Ich wollte nochmal auf die Landmasse-Relationen hinweisen. Irgendjemand Gutmeinendes hat diese Monster erstellt und zu allem Überfluss auch noch als Multipolygon getaggt. D.h. dass diese Dinger bei jedem die db verstopfen (meint: unnötig belasten), der irgendwo eine Küstenlinie drin hat. Konkret gehts mir um diese Relation: http://www.openstreetmap.org/browse/relation/957374 tags (da der Link fast sicher nicht gehen wird): land_area=administrative name=Italia type=multipolygon (habe ich geändert, s.u.) Members: 2056 Wir haben ja extra den Shapefile-Coastline-Prozess, um solche Auswüchse zu verhindern. M.E. sollte man einen anderen Type als multipolygon wählen, damit die Dinger wenigstens nicht standardmäßig importiert werden. Wie man schon an obigem Link erkennen kann (der jeweils timeoutet), sind solche Monster eine Belastung für die db (und bringen auf der Habenseite nichts oder nur sehr sehr wenig). Ich vermute, dass sie auch inhaltlich falsch sind (da AFAIK administrativ die Basislinie und nicht die Küstenlinie entscheidend ist). Habe die Relation mal von type=multipolygon auf type=landmass geändert, damit man wenigstens nicht automatisch belästigt wird, aber m.E. braucht man das gar nicht. Ich bitte ausserdem die Mitmapper, in ihrem Bereich ähnlich vorzugehen. Gibt's hierzu Proteste oder andere Kommentare? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22. Juni 2011 20:58 schrieb Heiko Jacobs heiko.jac...@gmx.de: Da es highway=pedestrian (auch da kann Fahrzeugverkehr zugelassen sein) und living_street schon länger gab, hätte highway=cycleroad prima da reingepasst. Nun denn *schulterzuck*, mit bicycle_road=yes wird die Welt auch nicht untergehen ... stimmt zwar, aber geschickt ist es nicht unbedingt, wenn man z.B. wegen eines einzelnen Keys der höchst selten vorkommt in seiner Datenbank eine eigene Spalte aufmachen muss. Ich sehe die Uneindeutigkeit von cycleroad ein, d.h. highway=bicycle_road wäre wohl günstiger. Abgesehen davon: welcher highway-Wert wird zur Kombination mit dem Attribut empfohlen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] highway=emergency_bay
2011/6/22 David Paleino da...@debian.org: Noto tristemente come praticamente solo io abbia mappato colonnine :/ credo di aver mappato al meno una ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Bootsrutsche
Am 21. Juni 2011 08:35 schrieb Stephan Wolff s.wo...@web.de: Am 21.06.2011 01:23, schrieb M∡rtin Koppenhoefer: Stimmt, bei Tag:barrier=bollard steht es so. Aber egal ob foot=yes nötig oder optional ist, falsch ist es nicht. sehe ich auch so Da ein Poller ein Hindernis aber kein Verkehrszeichen ist, beschreiben die access-tags hier 100.000-fach die physikalische aber nicht die rechtliche Beschränkung. das sehe ich nicht unbedingt so. Ein Poller ist durchaus ein Zeichen, dass KfZ dort nicht durchfahren dürfen, und bezeichnet somit einen Fußgängerbereich, so ähnlich wie z.B. auch ein nicht abgesenkter Bordstein das tut. Vor allem aber ist ein yes keine Beschränkung, sondern eine Erlaubnis und sagt aus, dass man da durchgehen _darf_ als Fußgänger. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bootsrutsche
Am 21. Juni 2011 13:31 schrieb Florian Lohoff f...@zz.de: On Tue, Jun 21, 2011 at 12:27:09PM +0200, M∡rtin Koppenhoefer wrote: das sehe ich nicht unbedingt so. Ein Poller ist durchaus ein Zeichen, dass KfZ dort nicht durchfahren dürfen, und bezeichnet somit einen Das halte ich fuer falsch - durchfahren koennen ist richtig - durchfahren dürfen ist falsch. Nur weil es nicht durchpasst heisst das nicht das ich nicht darf. Es gibt Elektromobile mit PKW zulassung die da super durchpassen und es gibt keinen Grund das sie es nicht duerften. wenn PKW-Zulassung bedeutet, dass sie diesen gleich gestellt sind, dann dürfen sie m.E. nicht durch. Google mal nach entsprechenden Gerichtsentscheiden. Was ich gefunden habe waren jeweils Hinweise, dass ein Schild nicht erforderlich ist, um einen als solchen erkennbaren Fußgängerbereich für Autos legal nicht befahrbar zu machen. Wie gesagt: an einem Bordstein muss auch kein Schild stehen, um den Gehweg zum Gehweg zu machen. Da muesste eigentlich ein Verbotsschild stehen. dann wäre es sicher noch eindeutiger, und man findet diese Schilder daher oft auch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Antw.: Generator für Icons gesucht
mal eine ganz andere Frage - kennt jemand von Euch ein Tool mit welchem man automatisch Icons erstellen kann. Es sollten nur die allgemeine Parameter wie Größe, Rahmenfarbe, Hintergrund und die zu verwendenden Texte anzugeben sein - der Rest soll alleine funktionieren ! M.E. kannst Du Dir mit Imagemagick ein Script zusammenschustern, das genau so was macht. Beispiele gibts im Web. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bootsrutsche
Am 20. Juni 2011 01:15 schrieb Stephan Wolff s.wo...@web.de: -1, access ist irreführend, da es eine rechtliche Beschränkung bezeichnet. Bei Punktobjekten in einem Weg wird mit access meist eher die physikalische als die rechtliche Beschränkung beschrieben. Ein nicht passierbares Hindernis (z.B. ein von beiden Seiten zugängliches, aber verschlossenes Tor) erhält access=no m.E. in der Regel access=private, weil wer den Schlüssel hat kann ja durch. Das ist durchaus auch eine rechtliche Beschränkung. bzw. foot=no, ein für Fussgänger und Radfahrer passierbares Hindernis (z.B. ein Poller in der Straßenmitte) ein foot=yes, bicycle=yes auch ohne explizite Freigabe. wozu sollte man das bei einem Poller angeben? M.E. ist das implizit und ich ergänze da auch kein foot=yes. Was wir hier brauchen ist ein tag, der ein physisches Feature (Bootsrutsche) beschreibt, ggf. als Attribut am Wehr, evtl. aber auch besser als eigenen Way (je nachdem, in welcher Detaillierung man mappt / schon gemappt ist). Es gibt viele kleine Wehre, die auch ohne Zusatzeinrichtungen befahrbar sind. In Wasserwanderkarten wird dann ein anderes Symbol verwendet. Die Befahrbarkeit gehört als Attribut an das Wehr. ja, wie oben geschrieben sollte beides (Attribut und expliziter way) möglich sein, je nachdem, was Sinn macht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trainingsgelände und Tribünen
Am 20. Juni 2011 15:18 schrieb fly lowfligh...@googlemail.com: Für das Gesamtareal fällt mir nur: landuse/leisure=club_yard operator ist immer ganz OK für das Gesamtareal. Es gibt neu einen Vorschlag für club als Haupttag (mein Vorschlag wäre association), der wohl auf Verein abzielt. Ich setze bei größerem Sportgelände meist leisure=stadium für das Gesamtgelände und leisure=pitch für das Spielfeld. Für Tribünen wäre building=stands möglich. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trainingsgelände und Tribünen
Am 20. Juni 2011 15:32 schrieb Chris66 chris66...@gmx.de: Am 20.06.2011 15:21, schrieb M∡rtin Koppenhoefer: Ich setze bei größerem Sportgelände meist leisure=stadium für das Gesamtgelände und leisure=pitch für das Spielfeld. leisure=sports_centre geht m.E. auch. +1, oops, das wollte ich eigentlich schreiben (nicht Stadion)... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Kartenbereich aus API-Export rendern
Am 20. Juni 2011 18:23 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Zumindest bei mir leuchten dann alle Warnleuchten auf. So wird das auf einem von mir verwalteten Linux-System ganz sicher nicht in Betrieb gehen. Bei obiger Anleitung ist es total wurscht ob der gisuser ein Superuser ist, denn es darf ohnehin jeder ohne Passwort als Superuser einloggen. vor 5 Mails hattest Du noch geschrieben, dass Du keine Postgresdb brauchst/willst, und nun sorgst Du Dich, dass sich jemand Unauthorisiertes dort als Superuser einloggen könnte und evtl. Daten kaputtmacht? Kommt natürlich immer an, in welchem Umfeld man den Rechner betreibt, ob er z.B. von aussen erreichbar ist, ob man in einer feindlichen Umgebung operiert, wie sensitiv die Daten sind, etc., aber wenn das alles nicht gegeben ist? Persönlich würde ich abwägen wie lange es dauert, die Daten neu einzulesen (Du wolltest AFAIR ein Rechteck mit ca. 2km importieren, das sollte Sekunden dauern) und wie lange es dauert, die DB abzusichern (einschl. Einarbeitung in die Doku der Rechteverwaltung). Dieses jeder darf sich ohne Passwort einloggen bezieht sich doch nur auf User des Computers (evtl. je nach Einstellungen, aber auf Ubuntu (sicher eher nicht sicher, alleine schon angesichts der vielen Bugs, die auf unreife Software hindeuten) kommst Du in der Standardkonfiguration nicht einfach von aussen (LAN) an die db - connection refused). Da ich zugegebenermaßen keine Ahnung von Systemsicherheit habe (o.g. beruht auf Ausprobieren) würde ich mich allerdings nicht beschweren, wenn hier ein paar Tips kämen, wie man das ganze sicherer machen kann, und ob ich mich mit vorigen Annahmen evtl. täusche. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] VHS Außenstellen taggen // Re: OSM an der VHS - OSM-DVD
Am 20. Juni 2011 22:32 schrieb RalfGesellensetter r...@gmx.de: Hallo Markus, hallo Liste In dem Zusammenhang stellt sich mir die Frage, wie Volkshochschulen und andere Bildungseinrichtungen zu taggen sind. Ich meine, dass dafür nur arts_centre vorgesehen ist, aber wie verfährt man mit Außenstellen, die auch anders genutzt werden (z.B. Gemeinsachftshäuser, Schulen,...) - könnte man die irgendwie als Dependenzen einer Relation hinzufügen? Du könntest ein Multipolygon machen, und würdest manche Sachen an die einzelnen Polygone hängen (wie Name der einzelnen Gebäude) und andere wie operator ans Multipolygon. Hat aber sicher unerwünschte Nebeneffekte, z.B. wenn man anfängt, räumlich entfernte Dinge zusammenzufassen. Im Prinzip verlassen wir uns darauf, dass man aus einer gleichen oder ähnlichen Bezeichnung im name oder operator-tag, oder ggf. über andere tags einen Bezug herstellen kann. Für die Fort- / Aus- / Weiterbildungseinrichtungen könnte man einen amenity-Wert erfinden und subtags verwenden. school würde ich nicht nehmen. Wie wärs mit education (oder evtl. adult_education wenn man es begrenzen will). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bootsrutsche
Am 21. Juni 2011 00:42 schrieb Stephan Wolff s.wo...@web.de: Im Wiki wird foot=yes, bicycle=yes ausdrücklich empfohlen, sonst sei access=no impliziert. foot=yes wird fast 135000 mal für nodes verwendet und meint in fast allen Fällen den physikalischen Zugang. siehs Dir nochmal an, da steht dass foot und bicycle implizit durchdürfen. Wie man einen bollard im Router implementiert wird aber ggf. derjenige entscheiden, der den Router programmiert, bspw. ob er da auch Rollstühle durchschickt, oder Motorräder, oder Pferde. Mit dem access=no wären die ausgeschlossen, jedenfalls Pferde und Motorräder, was in vielen Fällen auch rechtlich richtig sein dürfte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Copyright mappe con più di 15 anni
2011/6/20 Alessio Zanol nar...@infinito.it: Richard Fairhurst: OSM is hosted in England Wales and OSMF is a company registered in England Wales. That's the ultimate arbiter I'm afraid. Voi che ne pensate? come procediamo? io credo che abbia ragione Richard: il server sta in Inghilterra e quindi la legge importante e quella. Poi oltre alla legge dipende anche della comunità di OSM che preferisce nel dubbio di non prendere dei dati che forse si potrebbe legalmente prendere (per esempio non è chiaro se una foto aerea si può tracciare o meno, ma in OSM vale la dirittiva che tracciamo solo le foto aeree dove abbiamo esplicito permesso). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Bootsrutsche
Am 19. Juni 2011 06:32 schrieb Johannes Huesing johan...@huesing.name: Daher habe ich mal angefangen, das Wehr mit access=canoe zu versehen, bis jemandem was Besseres einfällt. -1, access ist irreführend, da es eine rechtliche Beschränkung bezeichnet. Was wir hier brauchen ist ein tag, der ein physisches Feature (Bootsrutsche) beschreibt, ggf. als Attribut am Wehr, evtl. aber auch besser als eigenen Way (je nachdem, in welcher Detaillierung man mappt / schon gemappt ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderwegeverlauf und Kartenwerk der Landesvermessung
Am 18. Juni 2011 11:28 schrieb Peter Wendorff wendo...@uni-paderborn.de: Porsche verkauft nicht in erster Linie sein Logo, sondern Porsche wirbt mit seinem Logo. Deshalb darf das nicht widersprüchlich verwendet werden. Beim GR ist zwar auch nicht in erster Linie das GR oder das spezifische Symbol zu schützen, sondern eigentlich die Ausschilderung vor Ort - und die Karten, die man mit der Routenzusammenstellung verkaufen kann. was ist denn beim GR genau geschützt? Das Zeichen als Marke für Wanderwege? Die Ausschilderung vor Ort (so könnte man argumentieren) nutzt du aber als Trittbrettfahrer aus, wenn du das gleiche Symbol in eigenen Karten verwendest. Wieso, man nutzt das Symbol ja nicht für andere Wanderwege sondern für eben die, für die das Zeichen auch geschützt ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Licenza e militari
2011/6/19 Elena ``of Valhalla'' elena.valha...@gmail.com: On 2011-06-18 at 23:40:47 +0200, Sasha wrote: Avrei bisogno di un un chiarimento sulla licenza if you alter or build upon our maps or data, you may distribute the result only under the same licence.. Il caso pratico: se lavoro su dati OSM aggiungendo layer di vari gradi di segretezza e vendo il risultato all'amministrazione della difesa, il risultato secondo CC-BY-SA deve o può (may) essere pubblico? il risultato deve essere rilasciato sotto licenza CC-BY-SA (puoi - may - redistribuire, ma solo - only - con quella licenza) niente ti vieta di impegnarti per contratto a non distribuire il lavoro che hai fatto ad altri (per gli impegni che prendi tu autore la CC-BY-SA non si applica) e poi son cavoli dell'amministrazione della difesa se vuole distribuire (sotto CC-BY-SA) o tenere il segreto (uso solo interno) -1, secondome, se lavora sopra dati OSM (quindi produce un'opera derivato) il risultato deve essere rilasciato in CC-BY-SA e quindi altri contratti a parte per vietare la distribuzione sono vietati dalla licenza cc-by-sa. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Precisione GPS BT747A+
2011/6/18 ale_z...@libero.it ale_z...@libero.it: scarto tra i 10 ed i 20cm. Ebbene, verificando con Josm, ho misurato uno scarto di 1,44m credo (ma non sono sicuro se questo è ancora così) che la misurazione in JOSM non è molto precisa, perchè si basa sulla proiezione dello schermo. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-legal-talk] CTs are not full copyright assignment
2011/6/17 Dermot McNally derm...@gmail.com: On Friday, 17 June 2011, Olaf Schmidt-Wischhöfer o...@amen-online.de wrote: I read your other mail on that topic. I don't personally have any objection to addressing weaknesses in the definition of active contributor. If we take the voting issues seriously we should also have a voting system that is open (i.e. transparent, open source, registers transactions, ...), breaks usernames down to natural persons (would probably require external verification services or maybe a system like CaCert where mappers can certify/authenticate each other by personal contact and passport verification). cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Refreshzyklen von OpenCycleMap
Am 17. Juni 2011 14:19 schrieb Dennie Reinhold rhinh...@googlemail.com: Ich habe indes sogar das Gefühl, OCM sei in den letzten beiden Wochen nochmals langsamer geworden als zuvor schon. Fürs Radln benutze ich gerne meine iPhone+GeoGuide-Kombination. Mit letzterem kann man im Voraus einer Tour die entsprechenden Kacheln herunterladen (was eben schnell mal mehrere hundert MB sind). Vor einem Monat war das recht schnell gemacht, heute früh hingegen habe ich nach einer Std. laden abgebrochen. Eine Woche zuvor ähnliches. Dann liegt es an Dir ;-) (Nicht alleine natürlich). Ist wohl klar, wenn mehrere Leute jeweils hunderte von MB an tiles herunterladen (wobei noch nicht gerenderte Tiles dadurch erstmal gerendert werden müssen, also die Renderwarteschlange belasten), dann bricht ein nicht ganz großes System unter diesem Ansturm zusammen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Paralleler Weg
Am 17. Juni 2011 15:38 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! hat einer von Euch schon mit der aktellen Version einen parallelen Weg erzeugen können ?? Habe 4138 gezogen und in den News wird Umschalt+P dafür aufgeführt - im Pull-Down ist das aber noch für Objekte Teilen (Werkzeuge 2) reserviert. Teilen ist bei mir (und glaube auch im Default) nur p, während die neue Funktion, die auch über einen Button erreichbar ist, ALT+SHIFT+P als Kombination zum Wechsel in den Mode hat. Aufgepasst: diese Funktion generiert ways, die auf dem Bildschirm parallel sind, keineswegs parallele Ways (das reicht vermutlich meistens als Annäherung trotzdem). Gruß Martin PS: SHIFT=UMSCHALT ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Info per classificazione centro cinofilo
2011/6/17 Alex nyr...@gmail.com: Ciao a tutti, sto mappando la zona in prossimità di un Centro Cinofilo che vorrei identificare come tale sulla mappa. Ho provato a dare un'occhiata sul wiki e non ho trovato occorrenze di kennel club. c'è questa pagina: http://wiki.openstreetmap.org/wiki/Animal che però potrebbe anche contenere dei suggerimenti meno ideali (non l'ho letto tutto, ma c'è un avviso all'inizio della pagina) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Question about contributor terms and derived contributions
2011/6/16 Andreas Perstinger andreas.perstin...@gmx.net: If there is just *one* single object near your way which isn't based on a ccbysa node/way, then you could always argue IMHO that you've measured the location of your way from this object (JOSM has a measurement tool with you can use for distances and angles). AFAIR this is not reliable or precise. AFAIR it is not suited to enter precise data you measured on the ground. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can I say yes to the ODbL if I can't account for 100% of my data?
2011/6/16 Toby Murray toby.mur...@gmail.com: On Thu, Jun 16, 2011 at 4:37 AM, Graham Stewart (GrahamS) gra...@dalmuti.net wrote: and that the source tag is certainly recommended, but not enforced. There is no such thing as an enforced tag in OSM. If you choose not to use a tag then that is your choice. Not using a source tag when basing your mapping on an external source is a poor choice. And not just for copyright reasons. It also lets other mappers know how much to trust the data. When I come across data that seems like it might be a little off to me I treat things that have a source=survey tag much differently than things that have a source=random import tag. You can also put this information in the change-set-comment. IMHO this is where this belongs to. AFAIK the source-tag is disputed and it is recommended to use the changeset comments. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can I say yes to the ODbL if I can't account for 100% of my data?
2011/6/17 Steve Bennett stevag...@gmail.com: On Fri, Jun 17, 2011 at 3:00 AM, M∡rtin Koppenhoefer Source is disputed? By whom? I've never heard any dispute about it? I put a source tag on every single object I create, and try and update it when I modify it. It is not completely useless but I observed that in general the more versions an object has, the less reliable the source tags on it are. Maybe you are an exception and do update every object you touch and you verify always the source on it, but most mappers actually don't. IMHO changeset comments really don't work well (in Potlatch at least), it depends how often you upload. For small edits where you just enter that place you have recently been to, I find them perfect. Bigger edits will usally get more generic comments, but when tracing from aerial imagery I include the provider and if known the year of the images. and it's far too easy to include the wrong objects in a changeset. either way you can miss some parts of your edit. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] OSM Karten auf Kindle
Am 16. Juni 2011 11:46 schrieb Kay Drangmeister k...@drangmeister.net: da Du von optimal sprichst wird man um einen eigenen grau-Stil nicht drum rum kommen. Notfalls geht auch der Standard-Stil (farbig), aber eben nur bei echter Not. Ich habe den bw-noicons-Stil erstellt (siehe z.B. http://toolserver.org/~osm/styles/?zoom=6lat=50.29635lon=10.89844layers=F0FFF0FFF0B00F ), der aber dafür erstellt wurde als Hintergrundlayer für andere farbige, transparente Layer, z.B. die Powermap http://toolserver.org/~osm/styles/?zoom=10lat=52.47943lon=8.39905layers=F0FFF0FFF0B00T zu dienen, und dabei natürlich möglichst kontrastarm zu sein. ja, den kenne ich, der ist aber im Endeffekt genau dasselbe wie der farbige Stil, wenn man letzteren auf dem Kindle betrachtet ;-) Was man machen müsste (ist aufwendig) ist ein dedizierter schwarz-weiss-Stil, wo man z.B. auch Raster verwendet, um Farben zu ersetzen. Was du brauchst ist hingegen eine möglichst kontrastreiche Karte. Da ich den bw-style automatisch generieren lassen kann, wäre es ohne weiteres möglich, in diesem Prozess auch den Kontrast (oder Gamma) anzupassen. Wenn das helfen würde - email :-) Kannst Du mit Deinem Script auch Raster erstellen lassen oder Stricharten ummappen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nochmal Kindle
Am 16. Juni 2011 13:58 schrieb Wolfgang Barth wolfg...@barthwo.de: Weniger als die Stilfrage ist es vor allem mein Problem, wie man mit dem Kindle am besten in so einer Karte navigiert. Ich hab leider keine Ahnung wie man dem Kindle die optimale Nutzung seiner Navigationstasten beibringen kann oder gar der im Menü aufrufbaren Vergrößerungs-Funktion, die es für pdf gibt. m.E. wäre die Vergrößerung am besten über die Blättern-Tasten implementiert, das Vergrößern aus dem PDF-Menü ist nicht sinnvoll (umständlich und nicht ausreichend, das impliziert ja, dass man mehr Daten schickt als man braucht für den Fall, dass jemand vergrößert (braucht auch unnötig Batterie/Rechenpower fürs Verkleinern)). Wenn man dedizierte Karten für ein Device macht, sollten diese idealerweise an die Hardwaremöglichkeiten angepasst sein (Auflösung). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Karten auf Kindle
Am 16. Juni 2011 13:09 schrieb Kay Drangmeister k...@drangmeister.net: Am 16.06.2011, 12:30 Uhr, schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Kannst Du mit Deinem Script auch Raster erstellen lassen oder Stricharten ummappen? Jein. Ich lasse (per imagemagick) farbige Icons in grau umrechnen, das kann sicherlich auch s/w rastern (z.B. halftone), das würde dann auch Flächen (mit Patterns) betreffen, aber die hohe Bildqualität von mapnik ergibt sich u.a. sehr stark aus dem guten Antialiasing, das nunmal mit Graustufen arbeitet. D.h. für dünne Linien fällt mir da keine gute Lösung ein. Dicker machen? dicker machen hilft nur wenig. Das Kindle (z.B.) bietet allerdings Graustufen (16), die m.E. fürs AA ausreichen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Kartenbereich aus API-Export rendern
Am 15. Juni 2011 09:36 schrieb Frederik Ramm frede...@remote.org: Muss ich die Küstenlinien und die ganzen anderen großen Files laden, wenn ich ein Gebiet rendern will, welches eigentlich fernab einer Küstenlinie ist? Nein, in dem Fall aenderst Du einfach die Hintergrundfarbe der Karte (Map background=xx im osm.xml) auf grau oder weiss oder was immer Deine Landflaeche haben soll. In der Default-Einstellung ist diese Hintergrundfarbe blau, und die Landflaechen kommen ueber die Shapefiles rein, aber wenn Du kein Meer hast, kannst Du Dir das sparen. +1, die großen Shapefiles sind 2 Küstenlinienversionen (unterschiedlich detailliert je nach Zoom), Städte und Grenzen für lowzoom-renderings (AFAIR bis z4 bzw. 5 oder 6, brauchst Du auch nicht) und vereinfachte Siedlungsflächen, alle 3 von Natural Earth, brauchst Du alle nicht, musst allerdings die entsprechenden Zeilen in den Regeln auskommentieren, sonst gibts einen Fehler, dass er die Dateien nicht findet. Was den User angeht: ich benutze einfach den normalen User und mache den zum Datenbanksuperuser. Das funktioniert problemlos, ob es Sicherheitslücken öffnet, weiss ich aber nicht genau. Eine Anleitung zum Installieren/Konfigurieren gibt es auch bei Richard Weait ( http://weait.com/content/build-your-own-openstreetmap-server ) und im Wiki auf deutsch unter DE:How to minutely hstore von Peter Körner. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Karten auf Kindle
Am 15. Juni 2011 23:06 schrieb Wolfgang Barth wolfg...@barthwo.de: Hat jemand eine Idee oder sogar Anleitung wie man sich selber in paar OSM Karten (so Stadtplan-Niveau ungefähr) optimal für den Kindle aufbereitet? Es würde ein Maßstab so Zoomlevel 15 oder 16 reichen. da Du von optimal sprichst wird man um einen eigenen grau-Stil nicht drum rum kommen. Notfalls geht auch der Standard-Stil (farbig), aber eben nur bei echter Not. jpg-Export kann man nutzen dafür. Aber dann hat man viele Dokumente und es ist unpraktisch zu navigieren. ja, hier wäre eine openlayers-version fürs Kindle optimal ;-) Weiss jemand, ob man die Tasten per Javascript abfragen kann? Anstatt zu blättern könnte man zoomen und sich mit den Pfeiltasten in Sprüngen bewegen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Kartenbereich aus API-Export rendern
Am 14. Juni 2011 09:26 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Wolfgang wolfgang at ivkasogis.de writes: Die Arbeit steckt darin, dass du den Stil aus Layern erst selbst zusammensetzen musst. Habe ich probiert. Stil für highway=residential basierend aus drei Linien. Eine weiße in der Mitte und zwei schwarze außen. Die Übergänge zwischen den Straßen sehen jetzt besch... aus. Die schwarzen Linien ragen in die kreuzenden Straßen. Was mache ich falsch? oft rendert man erst eine etwas dickere schwarze Linie (für alle Straßen im Gebiet), (das nennt sich casing), und erst danach mit weiss (oder sonst wie) die eigentliche Straße darüber. Zuletzt die Beschriftung. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal/Vorschlag: sport=table_football //Re: Kicker-Kneipe (pub features wie Billiard, Dart usw.)
Am 14. Juni 2011 10:55 schrieb RalfGesellensetter r...@gmx.de: Am Montag, 13. Juni 2011 schrieb M∡rtin Koppenhoefer: Amenity finde ich extrem ungeeignet, und auch sport oder leisure als Haupttag sind nicht m.E. weniger geeignet. Eher als subtags. Hi, Jan. Nach einigem Suchen habe ich hier genau diese Verfahrensweise gefunden: http://wiki.openstreetmap.org/wiki/Key:sport Since this is a non-physical tag it should be combined with one of these (physical) tags: ... tourism=hotel (swimming, golf, tennis, ...) amenity=restaurant (10pin, ...) amenity=pub (billiard, darts, pinball, ...) Also, einen Flipperautomat kann man schon taggen (amenity=pub,sport=pinball), aber für Tischfußball fehlt noch die Einigung auf ein englischsprachiges Tag (table_soccer oder table_football wie es in der Wikipedia heißt). Ich habe hier eine Diskussion angestoßen/ein Proposal eingereicht: http://wiki.openstreetmap.org/wiki/Talk:Key:sport#Proposal:_Table_Football.2FSoccer_in_Pubs http://wiki.openstreetmap.org/wiki/DE_talk:Key:sport M.E. ist Flippern keine Sportart, genausowenig wie Kampftrinken oder Mensch-ärgere-dich-nicht-spielen. Das haben auch die Mapper bisher so gesehen (nur 3 mal wurde sport=pinball verwendet, bzw. 5 mal wenn man Kombinationen miteinbezieht). http://taginfo.openstreetmap.org/search?q=sport%3Dpinball#tags Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Krankenhausgebäude und -fläche korrekt taggen
Am 14. Juni 2011 00:13 schrieb Garry garr...@gmx.de: Am 13.06.2011 21:16, schrieb Johann H. Addicks: p.s. Diesen Auszug gab's in Z15: http://osm.org/go/0MGgqLbd-- Ich sehe da nichts schlimmes daran - ein halbes Dutzend (jedes mit einer gewissen Eigenberechtigung) auf ein paar Hektar verteilt, kommt nur in grösseren Städten vielleicht 2-3mal/Stadt vor - wo ist das Problem? Ich finde das auch nicht tragisch, im Gegenteil ist es m.E. richtig, die Krankenhauskonzentration anzuzeigen. Wenn man sich über cluttering aufregen will, finde ich die Parkplatzzeichen deutlich störender. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Resorts = landuse=residental ??
Am 14. Juni 2011 01:00 schrieb Wolfgang wolfg...@ivkasogis.de: Aber für ein Hotel passt residential einfach nicht. Lesenswert: http://de.wikipedia.org/wiki/Wohngebiet Hotels, sonstiges nichtstörendes Gewerbe, , auch hier das Hotel als Gewerbe auf einer Stufe mit Tankstellen und im Text der deutliche Unterschied zwischen dauerhaftem Wohnen und anderen Aufenthaltsformen. seltsam, dass Du das als Argument gegen residential ansiehst, dass auch im deutschen Baurecht Hotels in Wohngebieten zulässig sind. Eine Stufe mit Tankstellen würde ich das nicht gerade nennen (Umweltverträglichkeitsgutachten, etc.). Sogar in reinen Wohngebieten (strenger als residential in OSM) können kleine Betriebe des Beherbergungsgewerbes als Ausnahme zugelassen werden, in allgemeinen Wohngebieten fällt das kleine weg, und in besonderen Wohngebieten (Gebiete zur Erhaltung und Entwicklung der Wohnnutzung) sind Hotels generell zulässig. http://www.gesetze-im-internet.de/baunvo/__4a.html Es handelt sich bei Hotels ja um Gewerbe, von daher passt landuse=commercial vielleicht wirklich besser als residential. Landuse ist aber sowieso nicht so gut auf alle Arten von Fällen vorbereitet, z.B. Krankenhäuser, Universitäten, Schulen, Sportanlagen, Stadien, Veranstaltungshallen, Diskotheken, Museen, Kirchen, etc. sind ebenfalls noch unklar, industrial ist sehr unscharf, da es nicht zwischen Industrie und Gewerbe unterscheidet, ... Am besten wäre wohl landuse=hotelzone. landuse=accomodation ? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Moderiertes Webformular für POIs statt Potlatch oder Yellow Pages
Am 14. Juni 2011 11:28 schrieb RalfGesellensetter r...@gmx.de: hin und wieder tauchte der Vorschlag auf, dass kommerzielle POI-Betreiber (Kneipiers, Hoteliers) ihre spezifischen Angebote (Biersorten, Öffnungszeiten) komfortabel (und evtl. kostenpflichtig) in einer seperaten Datenbank pflegen (können) sollten. das gibt es schon zuhauf: separate z.T. kostenpflichtige POI-Datenbanken ;-) Wie wäre es hingegen mit einem speziellen Frontend für Geschäftsleute, die ihre Einrichtung benutzerfreundlich in einem Webformular darstellen möchten (nur OSM-relevante Informationen, keine Webvisitenkarte oder sowas!). Interessant wäre das sicherlich, einen special interest Editor zu haben, z.B. spezialisiert auf die Eingabe von Läden oder Restaurants oder sonstigem Gewerbe mit Maske zur Eingabe von Adresse und Kontaktdaten, Öffnungszeiten, sowie ggf. Checkboxen/Dropdowns für Zusatzattribute (z.B. Cuisine). Etwas, wo man ohne Vorwissen oder Anleitung einen POI in OSM eingeben kann, weitgehend ohne Eingabe von Freitext. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternativen und Linienbegleitend
Am 14. Juni 2011 08:32 schrieb Jan Tappenbeck o...@tappenbeck.net: Am 14.06.2011 07:31, schrieb Georg Feddern: = wäre dann für soetwas landuse=forest als way und NICHT als AREA passender ??? das halte ich für Vollquatsch. Landuse ist eine Fläche, keine Linie. Ein Wald ist eine Fläche und keine Linie. Aber wenn ich erst einmal damit anfange Knicks mit diesen flächen Objekten zu definieren ziehe ich mir vermutlich den Ärger der Gemeinschaft auf den Hals weil alles grotten schlecht aussieht. kommt vermutlich drauf an, wie Du es machst. Ich halte Flächen für nicht unbedingt schlecht (kenne aber die Knicks auch nicht), weil sie die Breite und Ausdehnung bereits beinhalten. Je mehr man klar macht, um so weniger muss geraten werden. Wie das dann im Rendering aussieht (ob man es überhaupt darstellt) steht auf einem anderen Blatt. Und jeden Knick als Fläche auszugestalten finde ich übertrieben ! und warum ? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum Ort in braunton (Zarpen)
Am 14. Juni 2011 13:13 schrieb Jan Tappenbeck o...@tappenbeck.net: kann mir einer sagen warum Mapnik http://www.openstreetmap.org/browse/way/117599601, im Gegensatz zu anderen Orten mit landuse=residental, in einem braunton statt grauton rendert ?? Du solltest dort mal ein bisschen aufräumen. Mach alle Tags, die nur für das Multipolygon ohne die inner ways gelten an die Relation und nur was für den kompletten outer way gelten soll bleibt am way. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Resorts = landuse=residental ??
Am 14. Juni 2011 12:01 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Dienstag 14 Juni 2011 11:39:39 schrieb M∡rtin Koppenhoefer: Am 14. Juni 2011 01:00 schrieb Wolfgang wolfg...@ivkasogis.de: Aber für ein Hotel passt residential einfach nicht. Lesenswert: http://de.wikipedia.org/wiki/Wohngebiet Hotels, sonstiges nichtstörendes Gewerbe, , auch hier das Hotel als Gewerbe auf einer Stufe mit Tankstellen und im Text der deutliche Unterschied zwischen dauerhaftem Wohnen und anderen Aufenthaltsformen. seltsam, dass Du das als Argument gegen residential ansiehst, dass auch im deutschen Baurecht Hotels in Wohngebieten zulässig sind. Eine Stufe mit Tankstellen würde ich das nicht gerade nennen (Umweltverträglichkeitsgutachten, etc.). Ist im Text aber so dargestellt. In der Aufzählung unter sonstiges nichtstörendes Gewerbe steht auch Tankstelle, und sonstiges bindet das Hotel mit ein. stimmt nicht. Tankstellen sind zusätzlich zu sonstigem nichtstörendem Gewerbe aufgezählt, so wie es auch die BauNVO macht. Wie das in anderen Ländern geregelt ist, hängt aber vom Land ab. (residential=(allgemeines/reines/besonderes?) Wohngebiet nach deutschem Recht) ist daher nicht unbedingt für alle Implikationen / Besonderheiten gültig. Wie üblich sollte man nicht übertreiben. Es gibt kleine Hotels, die in einem Wohnblock z.B. die 2. und 3. Etage belegen. Dafür wird kaum jemand den Landuse ändern wollen. ist ja nichtmal erforderlich, damit es ein reines Wohngebiet bleibt. Eine Gerberei dürfte man da aber nicht mal im 3. Stock betreiben... Die Hotelzone von Miami Beach oder s'Arenal de Palma (Mallorca) würde ich dagegen eher nicht als residential taggen. Das Ambiente unterscheidet sich doch etwas, speziell abends... +1 daher sind wir uns ja einig: ein landuse für Hotel-areale wäre nicht schlecht. Falls es ums subtaggen geht, wäre allerdings zu prüfen, ob commercial nicht besser als Hauptgruppe geeignet ist als residential. Wegen mir kann man das aber auch umgehen, indem man gleich einen Haupttag im landuse einführt (wir haben ja sowieso bisher auch für alles einen Extratag, s. brownfield etc.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternativen und Linienbegleitend
Am 14. Juni 2011 14:35 schrieb Jan Tappenbeck o...@tappenbeck.net: Am 14.06.2011 14:38, schrieb fly: Am 13.06.2011 20:28, schrieb Jan Tappenbeck = wäre dann für soetwas landuse=forest als way und NICHT als AREA passender ??? was Du meinst ist eine Allee!!! Schau mal ins Wiki barrier=hedge_bank da ist auch ein Bild ! was er verlinkt hat war keineswegs eine Allee sondern eine Baumreihe, schau mal ins Wiki, da ist auch ein Bild (sogar 2): https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row Dein hedge_bank hat allerdings trotzdem seine Berechtigung, weil es - wie ich das feature in Wikipedia verstanden habe - ja ein Wall und Bäume darauf sind. Wenn es nur lineares Gestrüpp/Bäume sind (also ohne Wall), dann kann/sollte man hedge benutzen. tree_row würde ich dagegen eher als durchlässig sehen, wie eine Allee oder die Baumreihe auf dem anderen Bild. In der von Dir erstellten Wikiseite steht am Ende, dass das flächenhafte Erfassen keinen Sinn mache. Dem kann ich nicht beipflichten. Oder sind die Knicke immer gleich breit? Flächenhaftes Erfassen hat mehrere Vorteile, z.B. kann man damit Objekte im Knick erfassen, was bei einer Linie nur bedingt geht (und weniger Aussage haben wird, weil unklar bleibt, wo genau sich das Objekt befindet). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte zum heutigen Mühlentag (PR)
Am 14. Juni 2011 15:50 schrieb fly lowfligh...@googlemail.com: Und die komplette Adressinformation an jedes Haus zu hängen ist einfach nur Wahnsinn. Gerade dafür gibt es Relationen. Ich habe hier getrocknete und frittierte Algen, die essen sich wie Chips... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Kartenbereich aus API-Export rendern
Am 14. Juni 2011 17:43 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Dazu kommt, dass ich als Quelle auf jedem Fall ein kleines OSM-File nutzen will. Ich werde mit meiner DSL-Light-Verbindung keine Planet-Files ziehen! wie schon erwähnt: die Datenbank bietet Dir auch für kleine Files diverse Vorteile. Bis zu ein paar hundert MB osm-file (und das ist schon ganz schön viel, selbst in dichten Gebieten viel mehr als die erwähnten 2km²) kann man auch ohne slim mode auf kleinen Systemen in wenigen Sekunden die DB füllen und Indices erstellen. Irgendwie werde ich dieses SQL-Dingens zudem in Zukunft mit eben dieser OSM-Datei aktualisieren müssen. Auch sowas sollte gehen. genau darum geht es doch: die osm-Datei in die Datenbank einlesen und zum Rendern vorbereiten (Multipolygonrelationen parsen, Flächen berechnen, Renderreihenfolge vorberechnen, etc.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mail an User betreffs Lizenzwechsel erfolgt
Am 14. Juni 2011 18:49 schrieb Christoph Eckert c...@christeck.de: Moin, Wow! Dürfen wir jetzt Karlsruhe neu mappen? einerseits dürfte von meinem initialen Zeuch nicht mehr so viel übrig sein, andererseits kämen wir so mal wieder an topaktuelle Daten ;-) . joa, blos dass Dein initiales Zeuch je nach Lesart u.U. sich auch viral auf die folgenden Bearbeitungen auswirkt. Irgendwie basiert vermutlich halb +½ Karlsruhe irgendwie auf Deinem Mapping. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Bing Maps are amazing.
2011/6/13 Stephan Knauss o...@stephans-server.de: needs Silverlight that is really amazing... I don't have silverlight so I only get their dumb standard map... cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with OSM import to postgis
2011/6/13 Zolt Egete xphreaks...@gmail.com: Are there any alternatives to osm2pgsql maybe something that ? There are alternatives to osm2pgsql (e.g. imposm, osmosis) but they do not do the same thing so it depends what you want to do with your database (which scheme you want to have) which you should choose. Actually osm2pgsql should work nonetheless, have you tried another version of the planet or extract? Did you run md5 sum on your data prior to importing it to verify if your file is OK? ./osm2pgsql -U postgres -s -u -S default.style -d gisa -C 2500 /home/zsolt/tmp/planet-100127.osm Maybe the reason is the -u option? Looking at the help this should not be needed since 2007 and maybe even can cause some harm: -u|--utf8-sanitize Repair bad UTF8 input data (present in planet dumps prior to August 2007). Adds about 10% overhead. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with OSM import to postgis
2011/6/13 Zolt Egete xphreaks...@gmail.com: Hello Thank you for the quick reply I will give it a try without the -u option not to use the UTF-8 sanitize and will let you know the results as soon as I have some As far as other map files are concerned I have downloaded a few ones but this is the only one which I could unpack (have used pbzunzip2, bzip2, bunzip2) but all the time I have got corrupt archive messages. Also the MD5 sum of the downloaded file where not consistent with the md5 hash sum from the servers (I do not yet know the reason why) I have downloaded the other day the latest planet file which is almost 17GB large and have started to unpack this morning with the following command pbunzip2 -d -k planet-latest.osm.bz2 pbzip2: *ERROR during decompression: -4 and the error have shown after 200GB is unpacked, but I can still see the process going on, despite for the error and now it is on 227 GB Do you think this can impose a problem with the unpacked OSM file ? yes, the md5 check should pass OK, otherwise I suspect there is a problem with your download. I suggest you try first a smaller extract to test your setup, e.g. one of geofabrik. You also don't have to unpack the file, you can pipe it with bzcat to osm2pgsql. See the wiki for details. Another option is using pbf files (binary), see the wiki. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with OSM import to postgis
the official site should work: http://planet.openstreetmap.org/ the latest is this: http://planet.openstreetmap.org/planet-latest.osm.bz2 and the md5 is here: http://planet.openstreetmap.org/planet-latest.osm.bz2.md5 cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with OSM import to postgis
2011/6/13 Zolt Egete xphreaks...@gmail.com: C:\Users\z.egete\tmp\osm2pgsqlosm2pgsql -U postgres -S default.style -d gisa -H 10.1.1.63 D:\planet-100127.osm osm2pgsql SVN version 0.69-21289M I have tried with (-s, -u as well separately and have used -C 3000 at one time but no success) Any hint about it ? There is no way you can use it without the -s (slim) option if you have just 3GB of RAM. I'd really consider using a smaller extract then the planet (it would take weeks to import it even if you manage to do it). My suggestion: download a pbf extract from geofabrik and cut a BB with pbftoosm cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Erwassen von Erdwällen (Knicks)
Am 13. Juni 2011 19:09 schrieb Jan Tappenbeck o...@tappenbeck.net: In OSM sind die verwendeten hedges allerdings in der Regel mehr als Feldertrennung zu interpretieren - wir Norddeutschen sagen dann da mehr Knick [1] (bewachsener Erdwall) zu - würde ich auch gerne in die Karten (insbesondere nach Bing) aufnehmen, da die Karten dann mehr einen topografischen Charakter bekommen - oftmals werden da jetzt schmale Flächen mit natural = scrub oder landuse = forest als Ersetz verwendet. Hier jetzt meine Fragen: * ist barriere = hedge auch als Knick zu interpretieren ?? barrier=hedge ist laut wiki A hedge is a line of closely spaced shrubs and tree species, planted and trained in such a way as to form a barrier or to mark the boundary of an area. also in etwa: eine Reihe dicht gepflanzter/gewachsener Büsche und Bäume die so gepflanzt/zugeschnitten sind, dass sie ein Hindernis bilden oder eine Fläche begrenzen/markieren. * kann es zu routing Problemen kommen wegen dem barriere ?? wenn die Hecke sich mit einem Weg schneidet über den geroutet werden soll, dann evtl. schon. Wäre allerdings schlechtes mapping, da Wege nicht (ohne Öffnungen) durch Hecken führen, bzw. wenn doch, dann wäre es ja auch richtig dass der Router das bemerkt. * man kann in Feldern damit gut etwas darstellen - aber wie ist das wegebegleitend ? Hier führt dieses sicherlich zu Zeichenproblemen und durch die Kompaktheit zu Renderproblemen das sollte fürs Mappen eigentlich egal sein, oder? - deshalb die Frage ob nicht im Bereich von Wegen ein Way-begleitendes Tag wie bei den Radwegen [4] passen wäre ?? Beispiel: highway=track hedge = both / right / left ? m.E. sind sämtliche dieser begleitenden tags im Grunde unerwünschte Notbehelfe, von daher würde ich das nicht verwenden. Tags sollten sich auf das beziehen was gemappt ist, nicht auf das, was daneben liegt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kicker-Kneipe (pub features wie Billiard, Dart usw.)
Am 13. Juni 2011 18:26 schrieb RalfGesellensetter r...@gmx.de: Liebe Liste, unter http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpub fehlen m.E. jegliche Hinweise auf das Taggen von Billard- oder Tischfußball-Einrichtungen in Kneipen. amenity=billard oder amenity=kicker/table_soccer oder sport=billiards oder leisure=darts? ich finde das auch durchaus taggenswert, aber ich würde das eher in Form eines Attributs machen. Amenity finde ich extrem ungeeignet, und auch sport oder leisure als Haupttag sind nicht m.E. weniger geeignet. Eher als subtags. wie wärs mit table_soccer=yes / Anzahl (z.B. 1, 2, etc.) das könnte man problemlos an jede Kneipe / Vereinsheim, Sportheim, Jugendclub, etc. dazutaggen, ohne dass es sich mit den anderen tags in die Quere kommt. Bei billiard sollte man zumindest pool und carom unterscheiden, es gibt aber da zig Varianten: http://en.wikipedia.org/wiki/Glossary_of_cue_sports_terms der generische Ausdruck ist wohl cue_sports. Man muss aber nicht unbedingt für alle Varianten gleich einen Tag vorschlagen, such erstmal was für die Variante, die Du brauchst (evtl. pool) und lass den Rest sich entwickeln. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Kartenbereich aus API-Export rendern
Am 13. Juni 2011 19:56 schrieb Frederik Ramm frede...@remote.org: - Wie muss ich diese anpassen, dass damit aus einer OSM gerendert werden kann? Wie gesagt, das ist praktisch unmoeglich oder wuerde *sehr* viel Handarbeit bedeuten. Wesentlich mehr als die voruebergehende Installation einer PostGIS. und einiges würde trotzdem nicht einfach so gehen, z.B. das Sortieren der Flächen nach Größe vor dem Rendern. Postgres zu benutzen heisst ja nicht, dass man gleich mit riesigen Datenmengen umgeht, im Gegenteil, bei kleinen Gebieten macht es wesentlich mehr Spass, weil man da nur mal eben ne Minute warten muss, und nicht gleich 2 Wochen, bis die Daten drin sind. Wenn man das nicht will, wäre vielleicht Osmarender eine Alternative, da kann man hinterher das Ergebnis (z.B. Überlappungen) ganz gut von Hand nachbearbeiten. Apropos: ich kämpfe gerade auch mit Postgres: ist es normal, dass ein kleiner Server (8 GB Ram, Platten nur 7200 U/min ohne Raid, Prozessor Intel Xeon Dual core) für 6 Stunden diffs (ca. 400K nodes) einspielen 14 Stunden braucht? Oder habe ich da irgendwo Mist gebaut? Der Import hatte auch schon weit über ne Woche gedauert. Ich habe die extra-attribute drin (lediglich Version der Objekte), dann hstore mit allen tags und coastlines (sollte nicht viel ausmachen). Wenn ich mir mit htop die Nutzung ansehe, dann komme ich nicht über ca. 700 MB im RAM (das sollte in etwa den shared buffers entsprechen), ich habe jetzt mal die option -C 7500 dazugenommen (node cache), bringt aber nicht viel und den RAM nutzt er trotzdem nicht. Wo könnte ich denn da noch was tunen, oder ist mit der Kiste sowieso kein Land zu gewinnen? Die db hat nach dem Import ca. 670GB auf der Platte belegt, während des initialen Imports sogar zeitweise (mit tmp-tabellen) ca. 960 GB. Die Prozessoren langweilen sich die meiste Zeit (osm2pgsql, ca. 3-5% Auslastung) während auch bei Osmosis (changefiles) nur einer wirklich auf 100% läuft, der andere dümpelt da auch (bzw. ist da das Verhalten zyklisch: mal ist einer ganz ausgelastet und der andere nicht, dann laufen beide auf ca. der Hälfte, das wechselt sich alle paar Sekunden/Minuten ab). Für Tipps wäre ich sehr dankbar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Piazza attraversata da una strada
2011/6/13 Maurizio maurizio.dani...@gmail.com: Il 13 giugno 2011 12:51, Gioele Barabucci gio...@svario.it ha scritto: c'è una procedura standard che mi permetta di marcare una piazza attraversata da una strada? La piazza è attraversata nella sua lunghezza da una strada che congiunge via Tizio a via Caio. I due lati della piazza sono zona pedonale/parcheggio. Le abitazioni che si affacciano sulla piazza hanno indirizzi come piazza Sempronio 3, quindi la strada che taglia la piazza non ha nome. secondome la strada che taglia la piazza fa parte della piazza (e quindi porta lo stesso nome = tag name) Direi che toponomasticamente la strada che attraversa la piazza sia parte della piazza stessa, quindi la way sarà: +1 E poi l'area pedestrian Piazza Sempronio con la way Piazza Sempronio che l'attraversa. intendevi connettere, vero? +1 l'area pedestrian si dovrebbe connettere ad ogni strada che passa sopra. Poi dissegnerei i lhighway=pedestrian, area=yes dove veramente finisce la piazza (perchè è un area, e quindi il confine è quello reale, non come nel caso di una strada dove dissegniamo un way al centro). Nel caso che dei edifici limitano la piazza creo nodi uniti tra edificio e piazza. Da questo discorso risulta anche che le strade che entrano in piazza lo fanno quasi mai nel angolo del way che rappresenta la piazza. Invece questi punti comuni distano dal angolo della piazza al meno la meta larghezza della strada (se non c'è marciapiede). Primo esempio che mi viene in mente: Piazza Castello a Torino [1] [1] http://www.openstreetmap.org/?lat=45.071005lon=7.685928zoom=18layers=M +1 bel esempio ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
Am 10. Juni 2011 13:27 schrieb Markus Straub markus.straub...@gmail.com: 2011/6/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 9. Juni 2011 20:29 schrieb Markus Straub markus.straub...@gmail.com: Nein man kann mit dem Motorrad definitiv nicht durchfahren (die Fläche wird ja fast komplett durch den Sommergastgarten genutzt), auch mit dem Rad wäre es schwierig und außerdem illegal. illegal (d.h. eine Straftat) ist es ziemlich sicher nicht, evtl. ist es nicht erlaubt, das ging aus Deiner bisherigen Beschreibung allerdings nicht hervor. Physisch nicht möglich ist nochmal was anderes (nicht access). gibt es das: highway=footway area=yes eine area finde ich im Falle einer schmalen Gasse eher ungeeignet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Botanischer Garten
2011/6/12 Jacques Nietsch jacques.niet...@gmx.de: Wie tagt man einen botanischen Garten? Ich habe nirgendwo etwas gefunden wo hast Du denn gesucht? Im Wiki gibt es einen Vorschlag: leisure=garden garden:type=botanical http://wiki.openstreetmap.org/wiki/Proposed_features/Garden_specification Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 10. Juni 2011 14:38 schrieb fly lowfligh...@googlemail.com: ... In der Datenbank bräuchte man den 1. Koordinatenbereich, wo der operator anzutreffen ist (kann von der ganzen Welt bishin zu einer Stadt variieren) 2. Name 3. die main-tags, mit welchen der operator zu verknüpfen ist ( zb postbox, vendingmachine, postoffice, building, ... bei der Deutschen Post AG). das ist alles ein Riesenaufwand, weil die Liste permanent nachgeführt werden muss. Das geht vermutlich gerade noch so für Unternehmen in der von Dir genannten Größe, aber universell ist das nicht verwendbar. Für building müß man noch ein bischen besser filtern, da sonst schnell eine zu große Liste entsteht ! wieso, was hat das mit building zu tun? Building ist m.E. ein Tag, um eine bauliche Anlage als solche zu deklarieren (ggf. mit genauerem Gebäudetyp). Ich weiß, dass das ein ganze Stück Arbeit erfordert, aber es würde wohl viel mehr Eindeutigkeit schaffen als Monster-Relation-Kombinationen, oder wie stellt Ihr Euch denn so eine Relation für die Post, die Deutsche Bahn bzw andere große, weltweit tätige Konzerne vor ? Ja, nicht als Relation, die alle Objekte enthält, die irgendwie dazugehören, sondern als Zeiger (URI) auf die Entität/Relation vom Einzelobjekt aus. Wenn man das mit den Relationen macht, die wir in OSM derzeit haben, dann zeigt auch die Relation wieder auf das Einzelobjekt, daher geht das so im Moment nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Botanischer Garten
Am 12. Juni 2011 18:22 schrieb Jacques Nietsch jacques.niet...@gmx.de: Ich habe in How to Map, TagInfo und im Wiki unter Botanisch gesucht. ich würde auf englisch mit der Wikisuche herangehen, taginfo ist in der Tat auch sehr gut geeignet, aber diese How to map A und selbst die mapfeatures-Seite bringen meistens nicht viel, um spezielle Tags zu finden. Dazu kommen zu viele Tags neu dazu, und sind die Torwächter der Mapfeatures zu sehr darauf bedacht, die Seite übersichtlich zu lassen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie verbessert man die qualitaet des routings in OSM? (war: Berliner Abbiegebeschränkungen)
Am 10. Juni 2011 17:52 schrieb Chris66 chris66...@gmx.de: zB: Sollen Autos über tracks geroutet werden? wenn das nicht mal in Deutschland überall gleich ist (da die Landesgesetze unterschiedlich sind), wie soll man das weltweit hinbekommen? Sollen Fußgänger über Piers geroutet werden? (Oft sind Fährlinien über man_made=pier mit dem Wegenetz verbunden, aber fast kein Router berücksichtigt das). so was hängt wohl auch damit zusammen, dass man_made ungünstig gewählt ist: idealerweise hat man alle Objekte, über die geroutet werden soll, im highway namespace. Kann aber natürlich, wenn man das entsprechend kommuniziert / dokumentiert, trotzdem gemacht werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] pagina eventi sul wiki
2011/6/11 Luca Delucchi lucadel...@gmail.com: Ricordo a tutti che quando si modifica la pagina degli eventi sul wiki [0], non bisogna eliminare gli eventi passati ma spostarli nella pagina di quelli passati [1] [0] http://wiki.openstreetmap.org/wiki/WikiProject_Italy/Events [1] http://wiki.openstreetmap.org/wiki/WikiProject_Italy/PastEvents come si relaziona quella pagina con questa linkato dalla main page: http://wiki.openstreetmap.org/wiki/Current_events ? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Wie Wege zu Gärten taggen?
Am 10. Juni 2011 14:03 schrieb fly lowfligh...@googlemail.com: Am 10.06.2011 10:59, schrieb Chris66: Ob ein Weg zu einem Schrebergarten oder zu einem Supermarkt führt ist erstmal egal. +1 ganz egal ist es m.E. nicht, da ein Weg zu einem Supermarkt quasi öffentlichen Charakter hat und stark frequentiert sein dürfte, was bei einem Schrebergarten oft nicht der Fall ist. Wenn Autos nicht erlaubt/möglich sind: highway=path Das halte ich bei eim 3m breiten Weg für falsch. Dies ist dann wohl ein track. kommt immer drauf an, wenn man z.B. nur über Treppen da hin kommt, ist es ein path / footway m.E. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] lavori di manutenzione, API, il 23.06.2011
il giovedì 23.6. l'API di OSM non sarà disponibile ca. dalle 9:30 fino alle 21:30 (niente richieste API, editare, diff-updates). Invece il wiki, le liste mail ed help.openstreetmap.org dovrebbero continuare a funzionare. Il motivo è lo spostamento di alcuni servers dal University College of London in un altro centro calcoli al Imperial College. Più dettagli anche sulla pagina http://wiki.openstreetmap.org/wiki/Servers/June_2011_Maintenance che verra aggiornata di seguito. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Rendering error on Mapnik
2011/6/9 Hendrik Oesterlin hendrikmail2...@yahoo.de: There is a rendering error in India http://www.openstreetmap.org/?lat=13.01lon=75.31zoom=8layers=M screenshot at http://oesterlin.ile.nc/div/mapnik_error.png I did not figure out the reason for this. I guess this is a problem in the current coastline shapefiles. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering error on Mapnik
2011/6/9 Saphy Mo saphy...@yahoo.com: I think you are right. What should I do? Can I avoid all shapefile and use just only information as OSM in the database? Or should I wait until better shapefile will be accessible? First thing would be to check the coastline, if it still has this error or was corrected in the meantime. I am not sure if the shapefiles with coastlines can be avoided (in Mapnik, Osmarender and other renderers don't need shapefiles). There is an option in osm2pgsql to import coastlines (which per default are omitted), but you will likely end up with broken coastline geometry (because somewhere in the world it always will be broken) and maybe performance problems. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 8. Juni 2011 18:19 schrieb Garry garr...@gmx.de: Am 07.06.2011 16:42, schrieb Frederik Ramm: anderen aufzudiktieren, wie sie ihre Arbeit machen sollen. Das klingt aus Deinem Mund jetzt sehr paradox... naja, wenn ich naturgemäß auch mit dem Rest Deiner Mail weitgehend übereinstimme, hier widerspreche ich doch gern: Frederik ist prinzipiell ziemlich liberal und laisser-faire-mäßig unterwegs, da ist aus meiner Sicht nichts Paradoxes an seiner Aussage. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik - Rendern von Dünen
Am 9. Juni 2011 12:37 schrieb Chris66 chris66...@gmx.de: Am 09.06.2011 12:08, schrieb Jan Tappenbeck: kann mir einer sagen wo ich Renderwünsche hinterlegen kann ? Auf http://trac.openstreetmap.org Komponente Mapnik wählen. Hätte gerne das die Dünen auch dargestellt werden - natural=dune. Problem: Es gibt Sand- und GrasDünen, soll der Renderer Dünen also rötlich oder grünlich darstellen ? Sanddünen könnte man als natural=sand taggen, das wird auch schon gerendert. natural=sand halte ich für Unsinn, wenn man irgendwann mal eine Logik im Tagging von Grundelementen erzielen will. M.E. könnte man Bodennutzung und Bedeckung so aufteilen: landuse= Nutzung landcover= Bodenbedeckung (manche würden da lieber surface verwenden, was aber auch Probleme hat). natural würde ich für geografische Features benutzen, also so was wie Dünen, Strände, Gipfel, Höhlen, Klippen, Buchten, Pässe, ... Im Großen und Ganzen ist das so auch in den Tags umgesetzt, ein paar Ausreisser gibt es aber, und sand ist einer davon. Ich würde das natural für die Düne verwenden, und den Sand in landcover (oder notfalls/zusätzlich(?) in surface, wenn die komplette Oberfläche des getaggten Polygons Sand ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problematik der Ortsnamenzusätze
Am 8. Juni 2011 09:13 schrieb Walter Nordmann walter.nordm...@web.de: Aus diesem Grunde sollten Tags wie name=Gemeinde Kleinkleckersdorf einfach in name=Kleinkleckerdorf umgewandelt werden. Das gleiche für Dortmund, Stadt. Grundsätzlich gibt es ja immer die Möglichkeit, beides festzuhalten, z.B. mit dem tag official_name: http://wiki.openstreetmap.org/wiki/Key:official_name Ich bin mir nicht so sicher, ob der richtige Name z.B. des Landkreises Zollernalbkreis Zollernalb ist. M.E. ist evtl. auch Landkreis Tübingen der Name des Landkreises Tübingen, nicht Tübingen, dito für den Regierungsbezirk Tübingen. Anwendungen, die mit sowas Probleme haben, sind m.E. zu optimieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik - Rendern von Dünen
Am 9. Juni 2011 13:50 schrieb Jan Tappenbeck o...@tappenbeck.net: Am 09.06.2011 12:37, schrieb Chris66: Am 09.06.2011 12:08, schrieb Jan Tappenbeck: kann mir einer sagen wo ich Renderwünsche hinterlegen kann ? Aufhttp://trac.openstreetmap.org HI ! Mit welchem PWD logge ich denn da mich ein ? Es gibt ja zwei ! ich hoffe, die löschen nicht gleich alle Deine Daten und sperren den Account, wenn Du es einmal falsch eingegeben hast... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 9. Juni 2011 17:23 schrieb Garry garr...@gmx.de: Das Paradoxe ist dass er durch Androhung von Account-Sperren die Durchsetzung/Unterdrückung von Tags unterstützt... jetzt bin ich doch neugierig geworden, um welche Tags gehts da? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Resorts = landuse=residental ??
Am 9. Juni 2011 18:43 schrieb Wolfgang wolfg...@ivkasogis.de: Das sind nun Hotelanlagen (Resorts) im großen Stil - würdet Ihr diese mit Landuse=residental erfassen ?? So lange ich nichts bessere finde, ja. comercial würde auch passen. Hotels sind im weitesten Sinne eher mit Bürogebäuden verwandt, häufig auch optisch. Jein, m.E. passt residential besser. Typologisch sind Hotels klar eine eigene Klasse (wobei es natürlich auch da verschiedene Standarduntertypen gibt, z.B. Atriumhotel). Der Unterschied von Büros und Hotels ist schon sehr groß, angefangen von der Anzahl der Bäder / Steigstränge, über Geschosshöhen und Achsmaße, Nebenräume bis zu den Service-Angeboten. Hotels sind nachts meist belegt, Büros leer, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationen für Betreiber (und evtl. für alles?)
Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
Am 9. Juni 2011 20:29 schrieb Markus Straub markus.straub...@gmail.com: Hi, wie taggt ihr folgendes: Gässchen in einer Innenstadt (Altstadt) die keine offiziellen Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren werden können weil es keine Gehsteigabsenkung gibt und die Fläche außerdem von Gastgärten belegt ist. highway=pedestrian? highway=footway? Das selbe Frage stellt sich generell für größere Flächen die innerstädtisch klar dem Fußgänger gewidmet aber nicht als Fußgängerzone gekennzeichnet sind - quasi großflächige Aufweitung des Gehsteigs. m.E. highway=service, service=alley, evtl. noch mit width. Mit dem Motorrad könnte ich doch da durchfahren, wenn ich Dich richtig verstehe? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
wenn es _auf dem_ Gehweg ist, dann natürlich footway oder ähnliches. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege zu Gärten taggen?
Am 9. Juni 2011 23:02 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Hallo, wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt? Ich tendiere hier zwischen highway=track oder highway=service. ich würde eher service nehmen, auf dem Land aber vielleicht auch mal track, kann beides passen, je nach Situation. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Am 8. Juni 2011 15:14 schrieb tshrub my-email-confirmat...@online.de: ein Gebüsch ist bei jeder Größe ein Orientierungspunkt. ja, stimmt. ich dachte damit erstmal an Zwischengröße und die Auflösung mit der man mappt - bei farmland oder landuse=forest kann man auch davon ausgehen, das typische Elemente enthalten sind (Gebüsch, kleine Lichtung, ...), bei z.B. field wird es schon konkreter - und ich dachte an eine ökologische relevanz eines Gehölzes, was als Wertung auch orientierend und Aufnahmekriterium sein kann. Kleine Gebüsche, z.B. 10qm, werden dann wohl als Fläche kartiert? Ein Punktsymbol für die Basis, wie bei Bäumen, habe ich nicht gesehen, für eine 10qm Auflösung gibts wohl nichts. Ja, würde ich grundsätzlich als Fläche machen (dadurch wird die Größe ja auch klar). m.E. regelt sich das von selbst. Je größer ein Objekt / Fläche ist, um so eher wird man sie auch kartieren, aber ich würde kleinere Gebüsche nicht grundsätzlich ausschließen wollen, nur weil sie evtl. keine eigene ökologische Relevanz haben. M.E. gibt es da keinen Regelungsbedarf, mit dem man vermeintlich Unrelevantes ausschließen muss. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] maneggio
2011/6/7 emmexx emm...@tiscalinet.it: Quali tag usare? Se possibile 2 soluzioni: - temporanea, indicazione puntuale della presenza dello stesso - definitiva, con indicazione dell'area occupata dallo stesso. forse trovi qualcosa nel key sport? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Airspace Co.
2011/6/7 Lester Caine les...@lsces.co.uk: Perfect example of something that should be possible to implement as a completely separate database, but which can overlay any other OSM data? +1 cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Zwischen Forest und Scrub
Am 7. Juni 2011 23:42 schrieb tshrub my-email-confirmat...@online.de: Charakteristisch ist, das Wald oder Gebüsch eine eigenes Klima bilden kann, sprich: der Wind da nicht durchpfeifen kann, daher eine Mindestbreite beim Gebüsch. ein Gebüsch ist bei jeder Größe ein Orientierungspunkt. Entsprechend sind ein paar Bäume kein Wald und man könnte sie hier einzeln mappen. Mindestflächen für Wald können z.B. 1ha sein (nach Kartieranleitungen und Landesforstgesetzen). ja, kleinere Baumflächen sind kein Wald, aber einzeln mappen ist bei mehr als ein paar Bäumen m.E. auch nicht sinnvoll (bzw. wer das tun will, kann das ruhig machen, aber das werden die wenigsten sein) dazu kommt, dass, wenn die Bäume dicht stehen, sie teilweise auch nicht auseinanderzuhalten sind. landcover=trees ist in jedem Fall richtig, ob man landuse=forest nur für echten Wald benutzt, oder für alle Arten von Baumbestand, finde ich nicht so wichtig, die Größe hat man bei Polygonen ja und kann anhand dessen beurteilen, ob es ein echter Wald ist, oder nur ein paar Bäume. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] Phase 4 and what it means
2011/6/6 Mike Dupont jamesmikedup...@googlemail.com: On Sun, Jun 5, 2011 at 6:12 PM, Stephan Knauss o...@stephans-server.de wrote: On 05.06.2011 02:09, Frederik Ramm wrote: Frederik the great is only interested in remapping Silesia (Schlesien) http://en.wikipedia.org/wiki/Frederick_the_Great#Warfare I guess you are confusing Frederik the Great with Frederick the Great ;-) Osm fork now has the resources to host the tiles and also does not have the bandwidth problems that osm does. I guess that's clear ;-) For the issue of supposed last minute-acceptors (mentioned by James Livingston): it would really help to block decliners (i.e. move to the next phase) ASAP to make things more transparent. Cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Was ist falsch an dem Multipolygon
Am 3. Juni 2011 22:01 schrieb Jan Tappenbeck o...@tappenbeck.net: so wie jetzt ??? Alles so taggen wie es gemeint ist, d.h. an den outer way alles das, was für diesen way gelten soll dito für den inner way an die Multipolygon-relation alles das, was für die Relation gelten soll (also für die Fläche(n), die von den outer ways umschlossen wird, abzüglich der Flächen, die die inner ways beschreiben). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 5. Juni 2011 02:12 schrieb Frederik Ramm frede...@remote.org: M?rtin Koppenhoefer wrote: Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) Kommt drauf an, beide Methoden haben ihre Vor- und Nachteile und ihre Berechtigung. Im Prinzip stimme ich dem auf kurze Zeit gesehen zu. Sicherlich hat (vor allem kurzfristig) auch das Wiederverwenden von Geometrie in der Nähe bestimmte Vorteile, trotzdem würden mich die Implikationen interessieren, die sich für den Mapper daraus ergeben: Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem Hinweis, dass das die Verarbeitung beschleunigt bzw. den Speicherbedarf reduziert), indem man die Waldgrenze löscht und den Wald per Multipolygon über eine in der Nähe verlaufende Straße umdefiniert? Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig kompliziert wird (und je nach Größe der entstehenden Multipolygone neben der Ungenauigkeit auch erheblicher Verarbeitungsmehraufwand entsteht, da selbst kleine Kacheln ggf. riesige Multipolygone enthalten, die weit über den eigentlichen Kachelbereich hinaus gehen). M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als dass es das Mapping vereinfacht und beschleunigt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Am 6. Juni 2011 12:52 schrieb Jan Tappenbeck o...@tappenbeck.net: kann mir einer sagen wie man so ein Zwischending zwischen landuse=forest und natural=scrub taggen würde?? Konkret geht es um eine Fläche auf dem Darß (Zingst) im Bereich http://www.openstreetmap.org/?lat=54.43426lon=12.7108zoom=17 Kann mir einer weiterhelfen ? Ich würde dort wo konkret Bäume stehen landcover=trees taggen, und evtl. landuse=forest (in dem von Dir geposteten Bereich hat das durchaus noch eine ziemliche Dichte, die Bäume stehen schon noch zusammen in einem Wäldchen). Wenn nur noch wenige Bäume in einem Gestrüpp stehen, würde ich scrub dafür verwenden und ggf. zusätzlich die Bäume einzeln mappen (natural=tree). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
On 06/06/11 12:12, M?rtin Koppenhoefer wrote: Meinst Du damit, dass sie gleichwertig sind, und dass es demzufolge in Ordnung ist, wenn man Stellen, wo jemand den Wald an der tatsächlichen Wald-Grenze enden lässt, vereinfacht / generalisiert (z.B. mit dem Hinweis, dass das die Verarbeitung beschleunigt bzw. den Speicherbedarf reduziert), indem man die Waldgrenze löscht und den Wald per Multipolygon über eine in der Nähe verlaufende Straße umdefiniert? Ja, aber nicht als Selbstzweck. Wenn jemand in einer Gegend etwas mappen will und in seiner Arbeit davon behindert wird, dass jemand anders jedes Polygon an seiner vermeintlich tatsaechlichen Grenzen enden liess, dann hat derjenige durchaus das Recht, das an den Stellen zu aendern, die er aus anderen Gruenden anfassen muss - eben weil es keine Frage von richtig oder falsch, sondern eine des persoenlichen Stils ist. das verstehe ich jetzt nicht, inwiefern man durch genauere Grenzen behindert werden kann, wo Flächen nicht mit Straßengraphen verbunden sind. Hättest Du da mal ein Beispiel? Den persönlichen Stil (gut dass Du es ansprichst) gibt es durchaus. Es ist unumgänglich gewisse Abstraktionen einzuführen. Wo man aber mit wenige Clicks stundenlange Arbeit von anderen kaputtmachen kann in einem Punkt, der wie Du sagst sowohl als auch richtig ist (sein kann), da erfordert es der Respekt vor der Arbeit der anderen, dass man den persönlichen Stil etwas an das anpasst, was man schon vorfindet (solange es nur um Stil und nicht um Verbesserungen geht). Dieses Thema ist da ganz gut vergleichbar mit der Frage, wie sog. straßenbegleitende Radwege gemappt werden sollen. Da ärgert es mich z.B. auch ziemlich, wenn (wie vor einiger Zeit geschehen) ein Mapper einen explizit gemappten Radweg (einschl. weiterer Details wie Fahrbahnoberfläche, kreuzende Einfahrten, leicht abweichende Verkehrsführung, etc., --- der Weg war da über Jahre und von zig Mappern weiterverfeinert) löscht und durch ein schnödes cycleway=track ersetzt. Auf die 2. Anfrage per PM antwortet der dann: da war kein Platz. Wie? Wo war da kein Platz? Dass die Topologie fürs Routing dadurch teilweise zerschossen wurde sei nur am Rande erwähnt (Zugang zu einem Fußgängerplatz der als Durchgang durch den Block auch von Fahrrädern genutzt wird). Es ist sicher eine Frage des Maßstabs (und der damit einhergehenden Generalisierung), wie man mappt. Der Maßstab wird in OSM durch die Genauigkeit dessen vorgegeben, was die Koordinaten hergeben, und evlt. von den bestehenden Renderings (Mapnik derzeit bis z.18 ca. 1:2000, andere Karten nutzen OSM probeweise sogar bis Z.21) , sehe ich nicht, inwiefern man einer Reduktion der Detaillierung und stärkeren Generalisierung im Bereich der Daten der Datenbank Positives abgewinnen könnte. Eine derart grobe Generalisierung wie man sie gelegentlich antrifft ist m.E. sinnvoll für z14 und weniger. Langfristig (und so habe ich die Aussage gemeint) ist es dennoch keine gute Idee m.E., weil wie erwähnt weiteres Verfeinern unnötig kompliziert wird Ja, das wird oft behauptet, aber je nach Art des weiteren Verfeinerns, dass man im Sinn hat, kann es eben auch genau andersrum sein. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Aus meiner Sicht wird das in Städten auf jeden Fall kommen, weil man anders ein sauberes Rendering, das auch Informationen zur realen Form transportiert, nicht erhalten kann. Wenn ich die Strassengeometrie verfeinere, bin ich vielleicht ganz froh, wenn die Waldgeometrie dabei automatisch mitverfeinert wird, statt dass ich jeden Zusatznode, den ich platziere, dreimal setzen muss. da der Wald nichts mit der Straße zu tun hat, muss ich den auch nicht verfeinern, wenn ich an der Straße schraube. Straßenkurven haben daher z.B. bei mir oft auch mehr Punkte als ein Waldrand. Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden, aber diesen Zaun könnte ich nicht mal einzeichnen ohne dass ich einen Topologie-Fehler einbaue, solange die Nachbar-Fläche an der Straße hängt. M.E. bremst uns diese Mappingtechnik mittel- und langfristig eher, als dass es das Mapping vereinfacht und beschleunigt. Ja, das behauptest Du immer wieder, aber das ist halt eine Beurteilung, die Du fuer Dich treffen kannst, aber nicht fuer andere Mapper; die werden eventuell davon eben nicht gebremst, sondern denen geht die Arbeit schneller von der Hand. sicher gehen einem manche Bearbeitungen schneller von der Hand, wenn man sie ungenau macht. Ich will in dieser Sache niemandem etwas vorschreiben, aber ich wehre mich auch dagegen, wenn *andere* hier Vorschriften aufstellen (a la na gut, voruebergehend darfst Du das so machen, aber Du musst Dir schon bewusst sein, dass das schlechter ist...). ist meine ehrliche Meinung. (Habe ich durch das m.E. ja kenntlich gemacht). Ich schreibe nur deshalb auch immer wieder zu diesem Thema, weil ich zutiefst davon überzeugt bin, dass kleinere Teile besser
Re: [Talk-de] Insel mit Röhrrich
Am 6. Juni 2011 16:03 schrieb Jan Tappenbeck o...@tappenbeck.net: ich habe eine Insel die komplet aus Röhrich besteht und derzeit hat diese die Tags natural = coastline. Regulär würde ich jetzt natural = wetland wetland = reedbed setzen - aber wie verträgt es sich mit coastline ?? m.E. eher schlecht. coastline ist ein lineares feature (eine Linie, wobei es ein Sonderfall ist und man da evtl. auch widersprechen könnte, weil ja damit Land vom Wasser getrennt wird und bei einer Insel sich dadurch ein Polygon definiert) während natural=wetland oder landuses für Flächen sind. Am Eindeutigsten wäre wohl ein Polygon für das natural (und weitere Tags wie Namen etc.) zu verwenden, d.h. multipolygon m.E.. Da beide tags als key natural haben, ist sowieso keine andere Möglichkeit praktikabel. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichflächen
Am 6. Juni 2011 16:37 schrieb Torsten Leistikow de_m...@gmx.de: Jan Tappenbeck schrieb am 06.06.2011 12:28: landuse = meadow scheidet wohl wegen fehlender Nutztierhaltung - selten und wenn vorübergehend nur Schafe ! Da sehe ich nun wirklich keinen Widerspruch. +1, meadow ist eine Wiese, die kann genauso gut auch gemäht werden, im Gegenteil, eine Weide wäre pasture / range / grazing land und eher nicht als meadow zu taggen. man_made=dyke waere sicherlich auch ok, ist hier aber halt nicht ueblich. ich würde es ergänzen, weil es eindeutig einen (Schutz)Damm beschreibt, der Wasser abhalten soll. Das embankment sagt lediglich aus: hier ist eine künstliche Erhöhung wobei der Zweck durchaus unterschiedlich sein kann (z.B. Verkehrsbauten). Haeufig genug gibt es auch Wege auf der Deichkrone, so dass die Kombination von highway=* und embankment=yes naeherliegend erscheint. man muss sich ja nicht entscheiden, es ist durchaus beides gleichzeitig möglich. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Am 6. Juni 2011 17:31 schrieb Garry garr...@gmx.de: Eine deutliche Trennung zwischen landuse und natural/landcover sollte daher auch mit Unterstützung der Renderer eingeführt werden. solange die Mapper nicht mitziehen werden sich die Renderer garantiert nicht bewegen, und es scheint, als wäre ich fast der einzige, der gelegentlich mal noch ein landcover mit-taggt. Für Dein Problem ist das allerdings auch kaum ausreichend, Du müsstest irgendwie das Alter (Pflanzdatum, auch ungefähr) der Bäume unterbringen (bzw. die durchschnittliche Wuchshöhe - nicht gerade ein dauerhaftes Attribut allerdings). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 6. Juni 2011 17:42 schrieb Frederik Ramm frede...@remote.org: Dass eine als einzelne Linie gezeichnete Grenze genauer ist als die Verwendung der Strassengeometrie, ist mitnichten erwiesen. OK, verstanden. Gut, es gibt im OSM-Umfeld natürlich _alles_ ;-) Auf dem Weg zu einer guten Annäherung ist man aber i.d.R. schon mit dem gröbsten Wald näher als mit gar keiner echten Flächengrenze. Dass jemand keine Lust hat, eine Strassengeometrie zu verfeinern, wenn sich dadurch tonnenweise Ueberschneidungen mit dem angrenzenden Wald ergeben und er die von Hand zusaetzlich korrigieren muss. Wieso sollte das jetzt ein Problem sein, wenn die Straße z.T. durch das Waldpolygon führt (bis es jemand richtet), während bei der anderen Methode die komplette Straße im Wald läuft? Man muss ja nicht alles alleine machen, diese tonnenweisen Überschneidungen haben keine negativen Auswirkungen, ausser, dass sie Ungenauigkeiten aufzeigen, die man zukünftig noch durch Verfeinerung beheben kann. Ich glaube, Du hast da eine etwas verkorkste Perspektive. Du scheinst anzunehmen, dass alles, was jemand vom Luftbild abmalt, automatisch hochgenau und detailliert ist. Ich wage mal die Behauptung: Der Fehler, in Metern, den ich einbaue, wenn ich den Strassen-Way als Begrenzung meines Waldes nehme, ist im Durchschnitt geringer als der Fehler, den ich einbaue, wenn ich das (Bing-)Luftbild nicht vorher ordentlich an GPS-Tracks justiere. Klar, die Lagegenauigkeit von Luftbildern ist nicht grundsätzlich gut, und Fehler aus der Orthorektifizierung des Luftbilds kann man auch durch nachträgliches Justieren (Verschieben) nicht mehr beheben. Da haben wir in Italien einen gewissen Vorsprung, weil wir mit dem PCN wirklich flächendeckend einheitliche Luftbilder haben (2006) und für manche Gebiete auch von 2008, die sehr gut positioniert und vorverarbeitet sind. Bing bietet einem im Vergleich in der Fläche deutlich weniger und schlechter (Position/Alter) (in Rom aber z.B. z21 was für Details schon nicht zu verachten ist). Viele Dinge kann man aber auch ohne Luftbilder genau zeichnen, oft sogar aus dem Gedächtnis (bzw. anhand von Fotos und Aufzeichnungen, die man vor Ort gemacht hat). Wie genau man mappt hat höchstens zu einem Teil mit den Bildern zu tun, die man als Vorlage hat, eher mit den Details, die einem bei der Begehung auffallen. wenn man die Straßen zusätzlich als Flächen eintragen will, ist die Lage sicher eindeutig. Das ist eine ganz andere Baustelle. m.E. ist das genau dieselbe Baustelle: wenn man jetzt alle Flächen an die Straßen hängt, wird man sie später alle wieder abhängen müssen. Informationen zur realen Form zu transportieren, ist unter Umstaenden aber etwas anderes als sauberes Rendering. Und sauberes Rendering bekommt man ganz bestimmt auch ohne Strassen als Flaechen hin. Aber das ist, wie gesagt, wieder eine andere Geschichte. jein, solange die Straßen regelmäßig sind, braucht man praktisch keine Straßenflächen (selbst Spurerweiterungen -reduktionen folgen ja Gesetzmäßigkeiten), wenn aber der Verkehrsraum seine Linearität verliert und zu einer weitgehend ungerichteten Fläche wird, dann geht es ohne natürlich nicht. Eine Karte ist kein Luftbild. Auch eine sehr gute Karte nicht. +1. Klar, ein Zaun der an der Straße langläuft müsste evtl. verfeinert werden Wenn wir es mit einem Zaun zu tun haben, dann hoert das natuerlich auf, dass man die Strasse als Waldrand benutzen kann. Aber dann haben wir das gleiche Ding mit dem Zaun; man koennte dann einfach den Zaun als Waldrand benutzen, oder man koennte argumentieren, dies sei ungenau und der Zaun stehe ja ausserhalb des Waldes.. jetzt wirst Du allerdings ein bisschen rhetorisch ;-) Ein Waldrand ist sicherlich nicht auf den cm oder einzelnen Meter genau zu bestimmen. Sofern man aber zwischen Wald und xy noch etwas anderes erkennen kann (dazu zähle ich auch z.B. Gestrüpp, einen Straßengraben oder anderen Wasserlauf, eine Böschung, etc.), ist in der vorläufig endgültigen Karte an dieser Stelle xy auch nicht mit dem Wald verbunden. Du behauptest immer wieder, dass es ungenauer sei, den Strassen-Way als Waldrand zu verwenden, aber das ist eine unzulaessige Verallgemeinerung. Oder sagen wir: Es ist vielleicht genauer, aber nicht richtiger - genauso wie eine Loesung mit fuenf Nachkommastellen in der Matheklausur genauer ist, aber nicht richtiger. Es freut mich schon, dass es wenigstens vielleicht (das bedeutet vermutlich - s. Anfang D. Mail -, wenn es sorgfältig gemacht ist?) genauer ist. Der Umkehrschluss ist dann, dass es (bei jeweils sorgfältiger Herangehensweise) ungenauer ist, wenn man die Straße verwendet. D.h. dass es zwar immer noch Gründe gibt, trotzdem die Straße zu verwenden (Ersparnis von Aufwand), aber - solange man eine genaue Karte anstrebt - dieser Zustand vermutlich eben doch nur ein Übergangszustand sein wird. Es geht nicht um rhetorische Spitzfindigkeiten, das Argument war, dass echte Flächengrößen mehr
Re: [Talk-de] Name einer Insel anzeigen lassen ...
Am 6. Juni 2011 20:13 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! auch wenn gleich der Spruch kommt Wir taggen nicht für die Renderer - aber irgendwie muss es doch möglich sein für [1] im Ausschnitt [2] den Inselnamen in den Standardkarten anzeigen zu lassen ! Aber wie ?? place=island http://wiki.openstreetmap.org/wiki/Island das island=yes kannst Du vielleicht auch weglassen (bzw. weiss ich nicht genau, was es bedeuten soll, seltsamerweise wird das auf nodes vor allem im Binnenland getaggt: http://taginfo.openstreetmap.de/keys/island#map ) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] CreateIMG per Linux, si chiama GARMINUX
2011/6/6 Stefano Salvador stefano.salva...@gmail.com: grazie a te e a Marco, adesso corro a provarlo :-) +1 un eventuale problema da un lato completamente diverso: probabilmente il nome ti potrebbe creare problemi perchè Garmin è un trademark. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] CreateIMG per Linux, si chiama GARMINUX
2011/6/6 Stefano Droghetti stefano.droghe...@gmail.com: Il 06/06/2011 19:00, M∡rtin Koppenhoefer ha scritto: un eventuale problema da un lato completamente diverso: probabilmente il nome ti potrebbe creare problemi perchè Garmin è un trademark. GARMUX va meglio? ^_^ Dovresti aspettare cosa ti scrive il loro avvocato per essere sicuro, per me vanno bene entrambe le parole ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-de] Kloster, Priorat, Stift, etc.
Am 4. Juni 2011 15:04 schrieb fly lowfligh...@googlemail.com: Am 03.06.2011 19:01, schrieb M∡rtin Koppenhoefer: Also, dass place_of_worship einer Kirche entspricht ist ja wohl nicht Dein Ernst oder hast Du schob buddistische, islamische ... Kirchen gefunden. je nach Kloster wird da ja auch ein religion=christian dazuzutaggen sein in unseren Breiten, und dann sieht es aus wie eine Kirche. Meiner Meinung ist hier mal wieder ein alter tag am Bröckeln. Ist nicht eine unterkategorie von place_of_worship nötig ? place_of_worship=monastry place_of_worship=church place_of_worship=chapel place_of_worship=tempel evtl., wobei temple ziemlich generisch ist, aus dem Blickpunkt ist chapel und church vermutlich auch dasselbe. monastery würde ich eher nicht reinnehmen, weil ich nicht pauschal das gesamte Kloster zum Anbetungsort erklären würde. M.E. ergibt sich das daraus, dass es innerhalb des Klosters spezielle Orte dafür gibt, die dann den worship tag bekommen (Klöster sind nur zum Teil ein sakraler Ort). Dann kann man auch wieder alle Gebäudetypen mappen oder was machst Du mit dem Glockenturm einer Kirche ? dafür hätte ich gerne Gebäudeteile, zumindest solange es sich nicht um ein eigenständiges Gebäude handelt. Nach bisherigem Modell würde der Turm integriert werden, z.B. buidling:subtype=de:Zentralbau_mit_Kuppel. Man könnte z.B. building:part verwenden und die Teile zu einem Multipoligon oder einer building-relation (die wäre für viele Dinge nicht schlecht) zusammenfügen. http://taginfo.openstreetmap.de/search?q=building%3Apart#keys (fast 2000 Treffer) Eine Variante wäre building=part part=xy, kommt aber bisher nur 3 mal vor. ich da aber auch noch nach, wenn ein pauschales building=monastery allgemein als sinnvoll angesehen wird, und man definieren kann, welche Teile damit getaggt werden sollten. Damit widersprichst Du Dir ja selbst ! Lass es lieber weg. naja, es gibt ja immerhin bereits 176 davon, und wenn jemand den Ort nicht genau kennt und erstmal pauschal etwas als dem monastery zugehörig kennzeichnen will, warum nicht (kann man ja später verfeinern). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Scholarship program to State of the Map 2011
2011/6/3 Richard Welty rwe...@averillpark.net: for countries in the visa waiver program (most (all?) of the EU, Japan, South Korea, Australia, others, see link below) visas are not required, but an ESTA (Electronic System for Travel Authorization) is. +1, you need an electronic passport (RFID) with biometric data stored on the chip. When you enter the country, authorities will also take a photo of you and take your fingerprints, all of which they consider an effective weapon in the war on terror (Tom Ridge). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] regionale Bezeichnungen in Städten
Am 3. Juni 2011 12:10 schrieb Jan Tappenbeck o...@tappenbeck.net: in vielen Orten gibt es zusammenhängende Bereiche die im Volksmund einen Namen haben - Lübeck: Finnlandsiedlung, Musikerviertel etc. - deren Abgrenzung vielleicht auch nicht immer ganz eindeutig ist. Hat einer von Euch eine Idee wie man solche Bereiche taggt ??? Es sind ja im Grunde keine administrativen - oder soll das ein Landusebereich sein dem man dann einen Namen zuweißt !?!? wenn der Name nur vor Ort bekannt ist, könntest Du z.B. loc_name verwenden. Da es keine administrativen Ortsnamen sind, kommt m.E. irgendwas aus dem place-Bereich in Frage (allerdings gibt es bei den fest etablierten tags bisher hierfür keine festen values, vor kurzem war mal neighbourhood und ein paar andere im Gespräch auf tagging). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kloster, Priorat, Stift, etc.
Die gegenwärtige Beschreibung von Klöstern finde ich ziemlich ungelungen: http://wiki.openstreetmap.org/wiki/DE:Tag:historic%3Dmonastery M.E. wird die Logik dort umgedreht: der historic-tag wird in einer Art verwendet, die nicht dem üblichen entspricht (nämlich für eine Anlage, die _nicht_ mehr Kloster ist, was z.B. bei archäologischen Stätten und anderen historic values nicht so gemacht wird), und der building-tag wird für eine aktuelle Funktion (nämlich ein Kloster, das als solches dient) vorgeschlagen, wobei building normalerweise eine Gebäudetypologie und nicht notwendigerweise die aktuelle Nutzung beschreibt. Anders rum würde ich es sinnvoller finden: building=monastery für jedes Gebäude, das ein Kloster ist (bzw. als solches gebaut wurde) und historic (oder ein besser treffender tag, meinetwegen auch amenity, da nicht alle Klöster unbedingt historisch sein müssen) für die Funktion / Institution. Ich arbeite z.Zt. an einem Proposal, das die Anlagen genauer beschreiben helfen soll. Für Anregungen und Mitarbeit bin ich dankbar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kloster, Priorat, Stift, etc.
bin auf einem brauchbaren Diskussionsstand angelangt und freue mich über Kommentare: http://wiki.openstreetmap.org/wiki/Proposed_features/monastery Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Busspur mit Fahrraderlaubnis
Am 3. Juni 2011 14:48 schrieb o...@kokolakis.org: On Thu, 02 Jun 2011 16:26:27 +0200 Markus Straub markus.straub...@gmail.com wrote: wie taggt man korrekterweise eine Busspur auf der man auch Radfahren darf? Offiziell scheint es nichts zu geben, aber mit etwas Recherche komm ich auf folgendes: highway = * busway = lane cycleway = share_busway Busway kenn ich jetzt nicht. Ich würde es einfach mit den access-keys beschreiben. highway=bla access=no bus=official bicycle=official Da es sich um eine Spur zu handeln scheint, geht das so nicht im Fall, dass es nicht baulich getrennt ist, und man daher mit dem gegenwärtigen Datenmodell keinen eigenen Way zur Verfügung hat. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 3. Juni 2011 14:36 schrieb fly lowfligh...@googlemail.com: Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. ja, das ist eine große Hilfe (davor war das Trennen mit komplexeren Operationen aus Löschen, Kopieren, Teilen und Einfügen ja eine rechte Qual), teilweise wird man aber Probleme mit Relationen bekommen (die nach dem Auftrennen beide Teile als Member haben). Es ist einfach keine gute Idee, landuses an Straßen zu hängen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kloster, Priorat, Stift, etc.
Am 3. Juni 2011 17:24 schrieb malenki o...@malenki.ch: M∡rtin Koppenhoefer schrieb: bin auf einem brauchbaren Diskussionsstand angelangt und freue mich über Kommentare: http://wiki.openstreetmap.org/wiki/Proposed_features/monastery Ohne etwas gelesen zu haben (sry, wenig Zeit atm): warum nicht als amenity=place_of_worship taggen? Natürlich plus brauchbare zusätzliche Tags. Hatte ich auch eine Weile so gemacht, finde ich aber eigentlich unbefriedigend, weil man in Klöstern praktisch immer Kirchen und Kapellen findet, und sich dann seltsame Schachtelungen ergeben (und weil praktisch alle aktuellen Anwendungen das als Kirche interpretieren). Auch Bruder Vincent (Mapper und Ordensbruder, in OSM FrViPo oder so ähnlich) war dagegen ;-). M.E. ist es sinnvoller, Klöster extra zu definieren. Man könnte ja auch Wegkreuze und Schreine als PoW mappen, macht man aber auch nicht... Klöstern u.a. sind doch hauptsächlich Stätten, in denen Jene(s) Höheren Wesen, das/die manche verehren verehrt werden/wird. je nach Religion, es gibt ja nicht nur christliche Klöster... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kloster, Priorat, Stift, etc.
Am 3. Juni 2011 17:46 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 3. Juni 2011 17:24 schrieb malenki o...@malenki.ch: Ohne etwas gelesen zu haben (sry, wenig Zeit atm): warum nicht als amenity=place_of_worship taggen? gerade zum Thema gefunden, das Klosterpendant zum cycleway=track ;-) http://www.openstreetmap.org/browse/way/41205143 amenity = place_of_worship;grave_yard;place_of_worship;place_of_worship Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
