Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 04/26/2015 10:03 AM, Borut Maricic wrote: Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Warum sollte ein Jungwald bzw. die Aufzucht nicht auch ein Wald sein? Also ich hab kein Problem damit, dass du zusätzlich Pflanzdatum oder durchschnittliche Bewuchshöhe der Bäume erfasst, wenn dir das ein Anliegen ist. Aber imo wird in einem Wirtschaftswald nun mal regelmäßig geschlägert und dann wieder aufgeforstet. Deshalb bleibt das trotzdem ein Wald. An den man dann eben bei Bedarf weitere Details antaggen kann, aber nicht stattdessen. Ev. wär das auch wieder ein Fall für die ewige landuse vs. landcover Diskussion. Das Land wird als Wald genutzt (landuse) und ist derzeit mit Jungbäumen bepflanzt (landcover). Für mich ist ein Wald ein Wald, egal wie alt die Bäume gerade sind. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-tr] Nepal Depremi için Destek Çağrısı
Selamlar, #NepalQuake / #NepalDepremi yardımlarının yerine ulaşmasında kullanılacak harita altlığının oluşturulması için, @hotosm 190 numaralı projeyi başlatmış durumda. http://tasks.hotosm.org/project/190 bulunağından proje ayrıntılarına ulaşabilir, internete bağlı bir bilgisayarla siz de haritalamaya katkı sağlayabilirsiniz. Esenlikle:) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.___ Talk-tr mailing list Talk-tr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-tr
Re: [Talk-at] Tagging der abgeholzten Waldflächen
Hallo Borut, borut.mari...@borut.eu (Borut Maricic), 2015.04.26 (Sun) 10:03 (CEST): Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Ein Beispiel aus meiner gestrigen Survey-Wanderung: http://umleoben.borut.eu/osm/landusefrage.jpg Ich habe solche Flächen bis jetzt meistens mit natural=scrub getaggt, bin aber damit nicht ganz zufrieden, da eigentlich wenig Gebüsch zu sehen ist. natural=fell scheint mir noch weniger passend aus. ich denke, das Auf- und Abholzen gehoert zum Wirtschaftswald dazu, also landuse=forest, natural=scrub faend' ich schon richtig. Das mit den fehlenden Gebuesch wird die Natur schon regeln. Und auch fuer die Baeume wird's keine 20+ Jahre brauchen, sage ich voraus... Pfirti, Marcus ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk-fr] bano-data sur github
Bonjour, Est-il normal que les fichiers bano[1] sur github ne soient plus mis à jour depuis un mois ? PY [1]https://github.com/osm-fr/bano-data ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On Sun, 26 Apr 2015 10:03:41 +0200 Borut Maricic borut.mari...@borut.eu wrote: Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Ein Beispiel aus meiner gestrigen Survey-Wanderung: http://umleoben.borut.eu/osm/landusefrage.jpg Ich habe solche Flächen bis jetzt meistens mit natural=scrub getaggt, bin aber damit nicht ganz zufrieden, da eigentlich wenig Gebüsch zu sehen ist. natural=fell scheint mir noch weniger passend aus. Die Frage hab ich mir auch schon öfters gestellt. Ansich werden solche Flächen zu landuse=forest gezählt, da das Schlägern typisch für kommerziell genutzte Wälder ist. Allerdings ist es aus Kartensicht natürlich wünschenswert, dass man solche Flächen deutlich von länger nicht gerodeten Flächen unterscheiden kann. Ich habe dafür auch schon natural=scrub verwendet, wenn es mir von der Vegetation her passend erschien. Bei solchen Kahlschlägen wie auf deinem Bild würde ich das aber nicht gerne nehmen wollen. Es gab mal die Idee für landuse=tree_nursery (http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_nursery), bzw. stattdessen wurde allgemeiner landuse=plant_nursery adoptiert. Da dies zumindest bei unseren Wäldern oft auch nicht 100% passend ist (die Pflanzen werden viel mehr sich selbst überlassen), ist das auch nicht ganz ideal. Vl. brauchen wir einfach einen neuen tag? natural=tree_stumps oder sowas... -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Tagging der abgeholzten Waldflächen
Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Ein Beispiel aus meiner gestrigen Survey-Wanderung: http://umleoben.borut.eu/osm/landusefrage.jpg Ich habe solche Flächen bis jetzt meistens mit natural=scrub getaggt, bin aber damit nicht ganz zufrieden, da eigentlich wenig Gebüsch zu sehen ist. natural=fell scheint mir noch weniger passend aus. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-br] Xanxerê-SC
Pessoal, Estou planejando realizar um evento de mapeamento com estudantes da USP amanhã acoplado a minhas aulas para ajudar a mapear áreas de Xanxerê e Kathmandu. Estou em contato com o pessoal local do HOT em Kathmandu que está direcionando as prioridades. Alguém conseguiu verificar com alguma entidade (por exemplo Defesa Civil) para definir as prioridades em Xanxerê? abs João Em 23 de abril de 2015 00:58, Nelson A. de Oliveira nao...@gmail.com escreveu: Os mapas daqui ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2007/mapa_urbano_estatistico/sc/cartoa1/xanxere/ (que são diferentes dos que estão na camada do IBGE urbano) possuem algumas outras informações (igrejas, alguns prédios públicos, separação de bairros, etc) que também seria interessante adicionar no mapa, caso alguém tenha disponibilidade. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-at] Tagging der abgeholzten Waldflächen
2015-04-26 16:12:09 Friedrich Volkmann (b...@volki.at): Ich stimme allen anderen zu, dass solche Flächen landuse=forest bleiben und daher nicht aus dem Wald-Multipolygon auszunehmen sind. Zusätzlich kann man sie aber natural=heath (wenn Gras überwiegt) oder natural=scrub (wenn Gestrüpp überwiegt, dazu gehören auch Hochstauden) taggen. [...] Um sicher zu sein, dass ich das richtig verstehe: Das bedeutet, dass solche Flächen *KEINEN* Eintrag (mit role=inner) in der Forest-Multipolygon-Definition haben sollen, sprich gar keinen Eintrag in der Multipolygon-Definition haben werden. (Ich glaube, dass einige Renderer im Web so etwas zurzeit nicht darstellen können, womit ich aber gut leben kann.) Ich finde aber gleichzeitig, dass - entsprechend dem Michaels Vorschlag - ein fixme=abgeholzt nicht schaden würde. Im Gegenteil: Aus meiner Sicht wäre das ein Indikator, dass die Fläche aus dem Multipolygon nicht zu entfernen ist (sprich, in die Multipolygon-Definition nicht einzutreagen ist). Bitte bessert mich aus, wenn ich das falsch verstanden habe. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On Sun, 26 Apr 2015 16:40:39 +0200 Borut Maricic borut.mari...@borut.eu wrote: Das bedeutet, dass solche Flächen *KEINEN* Eintrag (mit role=inner) in der Forest-Multipolygon-Definition haben sollen, sprich gar keinen Eintrag in der Multipolygon-Definition haben werden. Ja, das folgt aus der Definition von landuse=forest, denn dieses Tagging bezeichnet ganz allgemein wirtschaftlich genutzte Waldgebiete... was auch abgeholzte Flächen miteinschließt. Das Problem dabei ist, dass die Renderer das als dunkelgrüne Fläche darstellen und wir das alle mit Wald gleichsetzen, was nicht notwendigerweise der Realität entspricht, und dass es eben keinen speziellen tag für abgeholzte Flächen gibt. Das Ausnehmen der Flächen aus dem MP ist eine Form von tagging für den renderer und keine echte Lösung. Eine echte Lösung werden wir hier in der ML aber auch nicht finden bzw. durchsetzen können, nur einen Konsens wie wir mit solche Flächen umgehen... bestenfalls ;) Auf Grund der bisherigen Nachrichten scheint mir der momentane Konsens zu sein, den landuse=forest-Bereich unangetastet zu lassen und die gerodete Fläche zusätzlich als natural=scrub zu taggen. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] bano-data sur github
Pas normal... mais ce mode de distribution (expérimental) semble peu adapté vu le volume global et la quantité de changements. Je pensais stopper... Le 26/04/2015 11:23, Pierre-Yves Berrard a écrit : Bonjour, Est-il normal que les fichiers bano[1] sur github ne soient plus mis à jour depuis un mois ? PY [1]https://github.com/osm-fr/bano-data -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN
Encore un peu de neuf sur le rendu BANO sur les données BAN... Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Pour les différencier, j'ai mis : - en pointillé rouge les adresses BAN pour lesquelles un rapprochement a pu être fait avec FANTOIR mais pas avec OSM - en pointillé gris les adresse BAN pour lesquelles le rapprochement FANTOIR n'a pas pu être fait. C'est un premier jet ;) Exemple sur une commune au cadastre raster: http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.96311/2.19007 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-at] Meine Importe der Gewässer in der Obersteiermark
Einmal bis zweimal im Jahr importiere ich ein oder zwei der obersteierischen Bachsysteme. Als Quelle nehme ich dabei die von Michael Maier ins OSM-Format umgewandelten OGD des Landes Steiermark. Vor einigen Tagen habe ich wieder mit so einem Import angefangen (http://www.openstreetmap.org/changeset/30441753), was ich hier jetzt etwas verspätet anmelden will. Gleichzeitig nehme ich das als Anlass, meine Bearbeitungsschritte für die möglichen Interessierten grob zu skizzieren. Eventuell kann jemand auch eine oder andere Vereinfachung/Ausbesserung vorschlagen. ** Wie ich auf die Idee kam? Irgendwann fiel mir ein Bachsystem auf, das hier schön zu sehen ist: http://www.wanderreitkarte.de/index.php?lon=15.0645lat=47.2477zoom=12 und durch diese OSM-Änderung entstand: http://www.openstreetmap.org/changeset/17163173 So um die gleiche Zeit, oder etwas später, erfuhr ich, dass Michael Maier in seinem Github-Bereich https://github.com/species unter anderem eine Vielzahl der OGD des Landes Steiermark im OSM-Format zur Verfügung gestellt hat, z.B. auch diese Gewässer-Datei für den Bezirk Leoben: https://github.com/species/OGD-stmk-daten/blob/master/Gewaessernetz/osm/Bezirke/leoben.osm ** Wie ich vorgehe? A. Den OSM-Bereich ins josm laden Ich beschränke mich dabei aufs Einzugsgebiet (engl. drainage basin) eines oder zwei Bäche. Warum? Weil das spätere Integrieren mit schon eingezeichneten Gewässern und Wegen so zeitintensiv ist, dass man es leicht aufgeben kann, bevor die Aufgabe vollständig vollbracht ist (was mir teilweise auch schon passierte). B. Die Gewässer-Datei laden Eine Datei, wie die schon erwähnte leoben.osm, lade ich in eine zweite josm-Ebene. Hier gleich einige der Merkmale dieser OGD: - Die Positionen der Gewässer sind sehr ungenau (schätzungsweise so +-10m, was leicht die verkehrte Wegseite des parallel verlaufenden Weges bedeuten kann). - Jedes Gewässer ist in unzählige kleine Abschnitte zerstückelt. - Die vorhandenen Tags haben natürlich nichts mit OSM-Tagging zu tun. C. Die zu importierende Gewässer markieren Alle Abschnitte der Gewässer im anvisierten Einzugsgebiet markieren. Das ist meistens nicht so leicht und nimmt Zeit. D. Eine neue josm-Ebene erstellen und dorthin die markierten Gewässer kopieren Somit haben wir den Patienten auf dem OP-Tisch. Die josm-Ebene aus dem Schritt B kann jetzt aus dem josm-Editor entfernt werden. In der gerade erstellten Ebene mit den ausgewählten Gewässern tue ich - für alle Gewässer-Abschnitte - folgendes: - Tags entfernen, bis auf GEWNAM. - Tagname GEWNAM ins name umändern. - Tag name entfernen, wenn dessen Wert Unbenanntes Gerinne ist. - Alle Abschnitte, dessen Name gleich ist, kombinieren. Ich bediene mich dabei der mächtigen Suchfunktion im josm und wiederhole das, bis keine Abschnitte mehr existieren, die mit dem gleichen Namen verseht sind und noch nicht kombiniert sind. - Das ähnliche führe ich dann noch mit den unbenannten Abschnitten durch, was etwas schwieriger ist - man soll dabei ein bisschen erraten. - Ein source=CC-BY-3.0: Land Steiermark - data.steiermark.gv.at definieren. D. Integration (kann Tage bis Wochen dauern) Dieser Schritt ist zeitintensiv und komplex. Das kopieren der bisher vorbereiteten Daten aus der Ebene (D) in die Ebene (A) ist natürlich sofort fertig. Man soll aber bedenken, dass einige der Bäche (oder deren Teile!) schon eingezeichnet sind (und wahrscheinlich viel genauer, als es die sind, die aus dem Import kommen). Die schon da gewesenen darf man keinesfalls löschen, höchstens eventuell den Namen eintragen/ausbessern. Man löscht die überflüssigen Teile aus dem Import und koppelt die restlichen mit den schon existierenden zusammen. Weiter soll man sich noch speziell um kleine Seen und ähnliches kümmern - die entsprechenden Abschnitte aus Import löschen und die Ränder der Wasserflächen genau einzeichnen und entsprechend taggen. Und auch sehr wichtig: Die Positionen aller so importierten Gewässer anhand von geoimage.at, bing und womöglicher vor Ort Erkundung ausbessern. Nachdem Waterway-Teile einigermaßen brauchbar sind, bleibt noch die große Aufgabe, die sich überkreuzende highways und waterways auszubessern. Dabei bitte ein Gewässer nie generell mit layer=-1 versehen. Vielmehr folgendes, oder ähnliches verwenden: bridge=yes, layer=1, oder tunnel=culvert, layer=-1, oder bridge=simple_brunnel Das dritte Beispiel ist den meisten vielleicht unbekannt. Es handelt sich um einen Vorschlag, wonach unter ganz bestimmten Umständen die Knoten, die gleichzeitig einem highway und einem waterway gehören, so getagged werden können. Mehr darüber hier: https://wiki.openstreetmap.org/wiki/Talk:Key:bridge#Simple_one-node_brunnels_for_way_over_waterway E. Die Qualitätskontrolle Dafür gehe ich in die Wälder ;) , nutze aber auch den Dienst http://keepright.ipax.at Hier dazu ein Beispielgebiet, wo es nach einem meiner früheren Imports noch Nachholbedarf gibt: [1]. Nebenbei gesagt: Ich wundere mich oft, wie viel
Re: [Talk-br] Xanxerê-SC
Creio que não João, mas é uma ótima coisa a ser feito para direcionar os trabalhos. Mais tarde eu pesquiso quais as entidades que estão atuando por lá. Tarcisio Oliveira On 26-04-2015 11:17, Joao Porto wrote: Pessoal, Estou planejando realizar um evento de mapeamento com estudantes da USP amanhã acoplado a minhas aulas para ajudar a mapear áreas de Xanxerê e Kathmandu. Estou em contato com o pessoal local do HOT em Kathmandu que está direcionando as prioridades. Alguém conseguiu verificar com alguma entidade (por exemplo Defesa Civil) para definir as prioridades em Xanxerê? abs João Em 23 de abril de 2015 00:58, Nelson A. de Oliveira nao...@gmail.com mailto:nao...@gmail.com escreveu: Os mapas daqui ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2007/mapa_urbano_estatistico/sc/cartoa1/xanxere/ (que são diferentes dos que estão na camada do IBGE urbano) possuem algumas outras informações (igrejas, alguns prédios públicos, separação de bairros, etc) que também seria interessante adicionar no mapa, caso alguém tenha disponibilidade. ___ Talk-br mailing list Talk-br@openstreetmap.org mailto:Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br smime.p7s Description: Assinatura criptográfica S/MIME ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] JOSM Tile Cache
Hi Mike, There has been a major rework of the TMS cache back end in version 8168-8186. If you can still reproduce this problem with the current development build or with the upcoming release, then please don't hesitate to report it directly on the JOSM bug tracker! Paul On 23.04.2015 22:58, Mike Thompson wrote: I am using JOSM version 8109 on Windows 7. I would like to flush JOSM's OpenStreetMap (Mapnik) tile cache. With the OpenStreetMap (Mapnik) layer displayed, I right clicked on the map, and then clicked on Flush Tile Cache, but I still see outdated tiles (when compared to the openstreetmap.org website - I made sure both were on the same zoom level). I also tried, in conjunction with the above, removing and re-adding the OpenStreetMap (Mapnik) layer, as well as restarting JOSM. Finally I tried renaming the OpenStreetMap (Mapnik) folder in the following location: C:\Users\username\AppData\Local\JOSM\cache\tms (this is the location the imagery.tms.tilecache preference is set to). Only after doing this were the tiles updated. Does the Flush Tile Cache work? I saw a bug report[1] about something like this, but it was closed four years ago as fixed. If it is working, am I using it correctly? Thanks, Mike [1] https://josm.openstreetmap.de/ticket/6109 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN
Le samedi 25 avril 2015 11:06:36 Nicolas Dumoulin a écrit : Certaines adresses suffixées apparaissent en plus (genre des bis, ter, A/B/C), à vérifier sur le terrain (j'ai un doute pour certains). J'ai aussi retrouvée un numéro qui n'apparaissait pas sur BANO, il a l'air cohérent, j'irai vérifier sur le terrain. Après vérification sur le terrain, c'était bon. J'ai pu ajouter deux numéro qui manquait pas loin de chez moi. Ce qui serait donc top, ce serait de détecter ces numéros qui ne sont pas encore dans BANO mais sont compris entre deux numéros présents dans BANO. Par exemple, si le 3 et le 7 sont déjà dans BANO, le 5 qui n'y est pas encore m'intéresse :-) Comme ça, je n'aurais plus qu'à charger les points dans mon osmand et partir en balade pour vérifier et corriger le positionnement. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk] Removing redundant routing instructions
On 26 April 2015 at 12:35, Rob Nickerson rob.j.nicker...@gmail.com wrote: Hi all, In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. Although the road continues round the bend SatNav systems often think it is a junction and tell you to turn right/left in 100 yards/meters. I wonder whether it is possible to indicate this in OpenStreetMap so that routing engines can omit this redundant instruction. == Example picture == https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing In the example Oban Road [1] turns to the right to become the northern section of Sydnall Road. All main routers tell you to turn right. In my opinion this is a redundant instruction (or could be better worded). I've tried to add extra nodes so that the road naturally bends but the main routing engines still tell you to turn. == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? Regards, Rob [1] http://www.openstreetmap.org/directions?engine=osrm_carroute=52.45362%2C-1.48598%3B52.45341%2C-1.48944#map=18/52.45332/-1.48771layers=Q ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk I think the instruction is sometimes required and it is therefore better to have it in than not. I'm sure without it, drivers would miss the turn from Holborn Hill into Moor Road https://www.openstreetmap.org/directions?engine=osrm_carroute=54.2119%2C-3.2791%3B54.2112%2C-3.2735#map=18/54.21158/-3.27626 despite what's left of the white lines indicating this is how the main route goes. -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
Rob Nickerson rob.j.nicker...@gmail.com writes: I'm not sure I get your point about hint for router versus aid for navigation. I suspect this may stem from the don't tag for the renderer rule. If we look at the end use case the aim is to get a routing engine that provides an optimal route with user friendly route instructions. I can't believe this is an easy tag and as such I would expect the routing developers to be raising issues they cannot solve via code alone. This is one area where I would like my SatNav not to spew redundant instructions. [not all directed at you of course] I think the text of the rejected proposal could have been written better. I think declaring this a hint for the router is not really the right characterization and led to trouble. We're talking about encoding facts about the world that are useful for multiple purposes. Also, don't tag for the renderer is about not putting wrong tags in because some renderer will make it look how you want. Describing something accurately so that it can be rendered is totally ok, and the main thing we do. What's really going on is that on the ground, it is (often) clear to a driver what continuing on this road means, vs turning. This can be because of signs, or because of subtle geometry of curb cuts, or the widths of the continue vs turn roads, or various other clues. Somtimes, many of these clues can't be figured out from aerials, and certainly not From road vectors. So it makes sense to have a way to tag this so that the map data captures this on-the-ground truth. Often it's obvious from the geometry (and the obvious answer is right), and those cases don't need tags. I think for now we should avoid getting into rules about when it's not needed, and be ok with people adding the tags if they think it's confusing. I view this as similar to turn restrictions, except that instead of telling you what you can't do, it's documenting what it means to not turn. I would suggest something like turn_description=straight, or maybe =none, to be used on the from/to ways at any junction where the look-at-the-map-and-obvious-guess answer isn't right. They should be directional because perception is going to be different, and sometimes you'll need both. There's a further question about whether routers should announce. I'd say that if the road turns 90 degrees, it should, but it should say turn left to stay on Route 2 rather than nothing. I guess this is another wrinkle in tagging, and again is a fact about the world more than a router kludge. So I come down to turn_description=straight (road continues, obvious to driver) turn_description=stay_on_road (road continues, not obvious to driver) pgpeAG4FEkKW0.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
The difference between routing and navigation is that the routing algorithm will work out which road you need to be on, but it is the navigation aspect which makes translates the routing graph to useful instructions for a human. If the main road does a 90 degree left at a T-junction, something has to work out whether to say follow the road through the bend or turn left or something else or nothing at all. Anyone who implies that geometry alone is enough to make that decision, is confusing the two concepts IMHO. Arguments that it is not needed for routing are possibly correct, but short-sighted. The through_route idea doesn't change anything for the routing (although routing algorithms may add a time penalty for give-ways or sharp bends if they wish) but it adds a hint as to how best to describe the next move for the driver. A motorway exit is also an aid to navigation in that it affects only the (spoken) instructions, and not the route chosen by the routing engine. I would be in favour of reviving the old proposal. //colin On 2015-04-26 15:26, Rob Nickerson wrote: There already is a through_route relation, to show the path of the through route. It might not be well documented, but it is used (I believe)by mkgmap. There was a proposal, which was eventually rejected: http://wiki.openstreetmap.org/wiki/Proposed_features/through_route [2] IMHO it was rejected as it was seen as a hint for the router, not as an aid to navigation, and people don't understand the difference. Yeah I'm aware of that. In fact my example has been sat on my computer since that proposal and I've only just got back to looking at it!! This is in effect a revival of that proposal with a quite different example. I picked a different name as Through Route has a meaning in the UK - it means a route that takes you past a town whilst avoiding the congested city centre. If you think we should revive the through_route proposal then I'm happy with that instead. I'm not sure I get your point about hint for router versus aid for navigation. I suspect this may stem from the don't tag for the renderer rule. If we look at the end use case the aim is to get a routing engine that provides an optimal route with user friendly route instructions. I can't believe this is an easy tag and as such I would expect the routing developers to be raising issues they cannot solve via code alone. This is one area where I would like my SatNav not to spew redundant instructions. Best, Rob p.s. Is highway=motorway_junction a hint for router or an aid for navigation? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk [2] http://wiki.openstreetmap.org/wiki/Proposed_features/through_route ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 26.04.2015 10:03, Borut Maricic wrote: Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Ein Beispiel aus meiner gestrigen Survey-Wanderung: http://umleoben.borut.eu/osm/landusefrage.jpg Ich habe solche Flächen bis jetzt meistens mit natural=scrub getaggt, bin aber damit nicht ganz zufrieden, da eigentlich wenig Gebüsch zu sehen ist. natural=fell scheint mir noch weniger passend aus. Ich stimme allen anderen zu, dass solche Flächen landuse=forest bleiben und daher nicht aus dem Wald-Multipolygon auszunehmen sind. Zusätzlich kann man sie aber natural=heath (wenn Gras überwiegt) oder natural=scrub (wenn Gestrüpp überwiegt, dazu gehören auch Hochstauden) taggen. Die Vegetation wird im Sommer auf jeden Fall üppiger als auf deinem Frühlingsfoto. Spätestens wenn Bäume in größerer Zahl aufkommen, egal wie groß sie sind, kann man diese Flächen löschen. Bäume wachsen recht schnell, daher bringt es nichts sich in OSM über die 3m-Grenze beim Betretungsrecht Gedanken zu machen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] JOSM Tile Cache
Paul, Thanks for your reply and for the information. I test with the development version. Mike On Sun, Apr 26, 2015 at 8:20 AM, Paul Hartmann phaau...@gmail.com wrote: Hi Mike, There has been a major rework of the TMS cache back end in version 8168-8186. If you can still reproduce this problem with the current development build or with the upcoming release, then please don't hesitate to report it directly on the JOSM bug tracker! Paul On 23.04.2015 22:58, Mike Thompson wrote: I am using JOSM version 8109 on Windows 7. I would like to flush JOSM's OpenStreetMap (Mapnik) tile cache. With the OpenStreetMap (Mapnik) layer displayed, I right clicked on the map, and then clicked on Flush Tile Cache, but I still see outdated tiles (when compared to the openstreetmap.org website - I made sure both were on the same zoom level). I also tried, in conjunction with the above, removing and re-adding the OpenStreetMap (Mapnik) layer, as well as restarting JOSM. Finally I tried renaming the OpenStreetMap (Mapnik) folder in the following location: C:\Users\username\AppData\Local\JOSM\cache\tms (this is the location the imagery.tms.tilecache preference is set to). Only after doing this were the tiles updated. Does the Flush Tile Cache work? I saw a bug report[1] about something like this, but it was closed four years ago as fixed. If it is working, am I using it correctly? Thanks, Mike [1] https://josm.openstreetmap.de/ticket/6109 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki project: Article about the standard layer, with key
Nice work so far, but are the any plans on carto side and on the wiki side to support the taginfo feature projects ? All together we could leave the dumb work for the machines and use our brains for the creative part. On the wiki side I would like to have some extension of the taginfo box or even an additional feature to better show the supporting software on each tag page. Cheers colliar Am 20.04.2015 um 20:10 schrieb nebulon42: Great! I can offer some support regarding the symbols that have been redrawn by me. Why bother with PNG when we can have SVG versions? I will upload all of my icons that are currently used by osm-carto in coloured SVG versions to the wiki and collect them at this page: http://wiki.openstreetmap.org/wiki/User:Nebulon42/Icons (By the way it is easy to create a coloured Osmic icon collection like that by looking at https://github.com/nebulon42/osmic/blob/master/tools/export.md.) I will also replace any existing new symbols in your key page with these SVG versions. As I'm not able to replace all other usages of the new symbols (maybe not needed yet?) I could use some help with that. 0xE8F56581.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN
Le dimanche 26 avril 2015 17:20:07 Christian Quest a écrit : Encore un peu de neuf sur le rendu BANO sur les données BAN... Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Ça c'est cool ! Si j'ai bien compries, ça va bien aider dans les zones sans cadastre vectorisé. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk] Fwd: OSM OSM (or OSMSM (or something else better?))
-- Forwarded message --
From: pmailkeey . pmailk...@googlemail.com
Date: 26 April 2015 at 17:21
Subject: Re: [OSM-talk] OSM OSM (or OSMSM (or something else better?))
To:
Cc: diversity-t...@openstreetmap.org talk@openstreetmap.org
On 26 April 2015 at 11:12, Marc Gemis marc.ge...@gmail.com wrote:
Nice ideas, but impossible to realise IMHO.
try finding a good rendering for
highway = residential
maxweight = 7.5
cycleway:left = track
cycleway:right = lane
sideway=both
lanes = 5
lanes:forward=2
lanes:backward =3
lanes:bus:forward=1
turn:lanes:backward=left|through|right
lit = yes
and perhaps add some access rules to the mix as well.
and some parking lanes
I constantly have to toggle different styles in JOSM to keep a clear
picture of what's going on.
Or didn't you mean everything with everything :-)
I think you are not the first one with this idea, but as usual who is
going to do it
I guess the team behind the map is welcoming extra help, but they also
have other priorities than showing everything (that's what I've read
somewhere)
regards
m
I did mean everything with everything - if that's what the person wants to
view. Opting out of details of choice should be permissible by having ALL
selectable by checkboxes in groups of checkboxes. If I'm going on a bike
ride...
Highways (group) yes
motorways no (not permitted for bikes)
railways (group) No
Buildings (group) No
bike shops yes
POIs (group) no
Now let me recompute your hypothetical highway above (I take 'sideway' as
sidewalk) and am working left to right with driving on the left (UK)
Highway = residential - rendered as a way by showing houses along the way
('obviously fake' ones if no real ones present. Also, maxspeed assumed as
30 (in uk)
lit=yes - rendered as having street lighting at intervals - no additional
rendering of the way required. IF streetlights not present, to auto add
them at regular intervals. If some streetlights present, to auto fill in
gaps
Lanes=10 (not 5) (i.e. 5 plus all the others):
PCBffbbbCP
Pedestrian|Cycle|Bus|forward|forward|backward|backward|backward|Cycle|Pedestrian
Note the pink colouring to show an issue with the road. Hovering over the
issue should reveal the 7.5T limit
image attached
I'd propose a colouring scheme based on red/amber/green for the quality of
the road - so the 7.5T limit puts this road toward the red - hence pink
colouring. The distance between the lines representing the lanes should be
dependent on the line width. The line width could indicate lane width (6',
9', 12' [2,3,4m] narrow lane, wide lane, very wide lane)
I'm not sure why anyone needs to know the street is a residential road -
who cares as long as I can drive along it ? I've chosen a triangle for a
building as triangular buildings are so rare. The text 'fake house' would
be totally optional !
It's time we were mapping roads as they are, not as they're 'meant to be'.
Then maybe those people in London will realise just how bad the roads are
around the regions. It's also time we had a pothole tag
I think the point is, rendering with all the detail is easily possible -
and in a way that's easily interpretable by the COPs.
[COPs: Clapham Omnibus Passengers.]
--
Mike.
@millomweb https://sites.google.com/site/millomweb/index/introduction -
For all your info on Millom and South Copeland
via *the area's premier website - *
*currently unavailable due to ongoing harassment of me, my family, property
pets*
TCs https://sites.google.com/site/pmailkeey/e-mail
--
Mike.
@millomweb https://sites.google.com/site/millomweb/index/introduction -
For all your info on Millom and South Copeland
via *the area's premier website - *
*currently unavailable due to ongoing harassment of me, my family, property
pets*
TCs https://sites.google.com/site/pmailkeey/e-mail
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing redundant routing instructions
There already is a through_route relation, to show the path of the through route. It might not be well documented, but it is used (I believe)by mkgmap. There was a proposal, which was eventually rejected: http://wiki.openstreetmap.org/wiki/Proposed_features/through_route IMHO it was rejected as it was seen as a hint for the router, not as an aid to navigation, and people don't understand the difference. On 2015-04-26 13:35, Rob Nickerson wrote: Hi all, In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. Although the road continues round the bend SatNav systems often think it is a junction and tell you to turn right/left in 100 yards/meters. I wonder whether it is possible to indicate this in OpenStreetMap so that routing engines can omit this redundant instruction. == Example picture == https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing [2] In the example Oban Road [1] turns to the right to become the northern section of Sydnall Road. All main routers tell you to turn right. In my opinion this is a redundant instruction (or could be better worded). I've tried to add extra nodes so that the road naturally bends but the main routing engines still tell you to turn. == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? Regards, Rob [1] http://www.openstreetmap.org/directions?engine=osrm_carroute=52.45362%2C-1.48598%3B52.45341%2C-1.48944#map=18/52.45332/-1.48771layers=Q [3] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk [2] https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing [3] http://www.openstreetmap.org/directions?engine=osrm_caramp;route=52.45362%2C-1.48598%3B52.45341%2C-1.48944#map=18/52.45332/-1.48771amp;layers=Q___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] Traduction JOSM
Merci aux volontaires qui ont commencé à regarder :) Avant tout chose, un guide de traduction existe, il est recommandé de le lire avant de se lancer dedans: https://josm.openstreetmap.de/wiki/Fr%3ATranslations#Traductiondulogiciel Les 2 seules règles à respecter y sont expliquées (liées au caractère apostrophe et aux accolades). Réponses aux questions posées: Launchpad: on est conscients que ce n'est pas la plateforme ultime (design, ergonomie, etc.). Pendant longtemps des problèmes de performance nous ont poussé à envisager une migration à Transifex. Un manque de ressources + la résolution des problèmes de performance côté Launchpad ont avorté cette migration. Actuellement les traducteurs de 6 langues (allemand, ukrainien, tchèque, russe, espagnol, catalan) parviennent à maintenir les 100% de traduction avec cette plateforme + toute notre infrastructure derrière, il n'est donc pas prévu de migration vers une autre solution. Notez qu'il est aussi possible d'utiliser des logiciels de traduction spécialisés, l'interface web n'est pas une obligation pour les plus aguerris. Emplacement des messages: chaque message à traduire indique le fichier et la ligne (sans lien direct vers les sources il est vrai). Il y a plusieurs moyens de consulter le code source de JOSM en ligne: - https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm - https://github.com/openstreetmap/josm/tree/mirror/src/org/openstreetmap/josm - http://bazaar.launchpad.net/~openstreetmap/josm/trunk/files/head:/src/org/openstreetmap/josm/ Messages non rencontrés: le plus rapide est d'aller voir le code source. Une astuce qui peut aider à comprendre le contexte d'apparition/modification des messages est d'utiliser la fonction blame de Trac pour voir quand ont été fait les modifs et au titre de quel ticket, exemple: - https://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/data/validation/tests/RelationChecker.java?annotate=blame#L308 (cliquer sur le numéro de révision à gauche) Fréquence des mises à jour de traduction: les traductions sont mises à jour manuellement (et corrigées lorsqu'il y a des problèmes avec les apostrophes...) quelques jours avant la sortie d'une nouvelle version de JOSM. Par exemple les dernières mises à jour sont: - 25/04: https://josm.openstreetmap.de/changeset/8271/josm/ - 22/04: https://josm.openstreetmap.de/changeset/8246/josm/ Si une langue bénéficie d'un effort important de traduction, on peut par contre tout à faire faire des mises à jour anticipées à la demande. A+ Vincent Le 25 avril 2015 16:47, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le samedi 25 avril 2015 00:30:41 Vincent Privat a écrit : Il n'y a donc plus personne en France motivé pour participer à la traduction de JOSM ? :( Salut, Je viens d'en faire quelques uns, mais bon difficile de traduire des messages que je n'ai jamais rencontrés … -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 04/26/2015 11:38 AM, Stefan Tauner wrote: On Sun, 26 Apr 2015 11:23:31 +0200 Norbert Wenzel norbert.wenzel.li...@gmail.com wrote: Warum sollte ein Jungwald bzw. die Aufzucht nicht auch ein Wald sein? Weil wir Geodaten aufnehmen, die unter anderem zur Orientierung dienen und sich der optische Eindruck im Feld sowie die Begehbarkeit von Wald und Jungwald in den ersten paar Jahren doch ganz erheblich unterscheiden... ;) Ich hab kein Problem damit, dass du den optischen Eindruck erfassen willst. Ich hab nur ein Problem damit land*use* zu verändern, weil der Wald ein Jungwald ist. Daher der Vorschlag es mit Zusatztags zum Beispiel zur Bewuchshöhe oder Begehbarkeit einzutragen. Es ist eben ein Wald der gerade aufgeforstet wird. Und nicht etwas vollkommen anderes. Ja, keine der aktuell vorhanden Karten wird dir im Moment Zusatztags für Jungwald rendern, aber deshalb sollte man doch nicht sagen, es ist kein Wald, weil der aktuelle Defaultrenderer es sonst grün darstellt. Dein Vorschlag tree_nursery würde ja auch nicht gerendert werden im Moment. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] OSM OSM (or OSMSM (or something else better?))
Nice ideas, but impossible to realise IMHO. try finding a good rendering for highway = residential maxweight = 7.5 cycleway:left = track cycleway:right = lane sideway=both lanes = 5 lanes:forward=2 lanes:backward =3 lanes:bus:forward=1 turn:lanes:backward=left|through|right lit = yes and perhaps add some access rules to the mix as well. and some parking lanes I constantly have to toggle different styles in JOSM to keep a clear picture of what's going on. Or didn't you mean everything with everything :-) I think you are not the first one with this idea, but as usual who is going to do it I guess the team behind the map is welcoming extra help, but they also have other priorities than showing everything (that's what I've read somewhere) regards m On Sat, Apr 25, 2015 at 11:47 PM, pmailkeey . pmailk...@googlemail.com wrote: Hi All, OpenStreetMap =*O* *S*tandard *M*ap MapForTheRenderer=yes | I think the standard map should define how osm data is displayed (not what is displayed)*1 DisplayEverything=yes | I think the standard map should display all data*2 DisplayOptions=yes | I think the standard map should offer the viewer the options to not display data types and features - such as labels / symbols / both / neither.*3 Preset standard maps*4 *1 The SM should allow zoom in to two adjacent buildings such that the text for [name] for both is clearly and fully displayed. It should define what areas mask other areas. It should not define what symbols are used though. *2 I think the SM should be capable of displaying the entire contents of OSM *3 The SM should offer users a means of not showing certain information - for preferences and clarity. *4 Preset standard map options should be available - such as cycling shows the cycling info but still using standard map symbols. It should also allow the user to add or remove displayed data - just like the 'normal' standard map does. This should not interfere with user groups designing their own maps and symbols driven by osm data but merely allow a standard map view of the user's selected data. Them's my thoughts ! -- Mike. @millomweb https://sites.google.com/site/millomweb/index/introduction - For all your info on Millom and South Copeland via *the area's premier website - * *currently unavailable due to ongoing harassment of me, my family, property pets* TCs https://sites.google.com/site/pmailkeey/e-mail ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Osmose QA available on Germany (english)
Am 26.04.2015 um 11:50 schrieb Frédéric Rodrigo: Hi, We have finish the coverage of Germany by Osmose QA. Osmose QA is a Quality Assurance tool. It detects and reports errors based on more than 200 rulesets. The major issue with osmose is that it invokes the notion of being authoritative when it is not, and by that motivates mappers to fix things (well actually break them) which are simply false positives. This is mainly a language issue in that you keep on using error all over the place instead of potential issue or whatever that is not such an absolute. Simon signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Tagging der abgeholzten Waldflächen
Hello Borut, Sunday, April 26, 2015, 10:03:41 AM, you wrote: BM Wie taggt ihr die Flächen, die abgeholzt sind und vor allem BM mit Baumstumpfen überseht sind? so kam die stadt stockerau zu ihrem namen: stocker-au. mfg ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-gb-westmidlands] Cycle parking
Quick question. What is the capacity of the following cycle parking rack? (The image shows a cycle rack consisting of 6 hoops/stands) https://drive.google.com/file/d/0B6J5ZA1hu93ba09qLTlnZFJMSkk/view?usp=sharing I have my view but just want to confirm with others. Cheers, Rob ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[OSM-talk] Removing redundant routing instructions
Hi all, In the UK (particularly in rural areas) it is common to find a road that turns 90 degrees to the left or right without a junction (that is the road just continues and white lines mark it as such). Meanwhile another road may come in from the other side with a 'give way' style junction. Although the road continues round the bend SatNav systems often think it is a junction and tell you to turn right/left in 100 yards/meters. I wonder whether it is possible to indicate this in OpenStreetMap so that routing engines can omit this redundant instruction. == Example picture == https://drive.google.com/file/d/0B6J5ZA1hu93bZmx2NTIxaHdfMUE/view?usp=sharing In the example Oban Road [1] turns to the right to become the northern section of Sydnall Road. All main routers tell you to turn right. In my opinion this is a redundant instruction (or could be better worded). I've tried to add extra nodes so that the road naturally bends but the main routing engines still tell you to turn. == Question == Could we benefit from a new route relation? For example a route_continues relation? Would others find this useful? Regards, Rob [1] http://www.openstreetmap.org/directions?engine=osrm_carroute=52.45362%2C-1.48598%3B52.45341%2C-1.48944#map=18/52.45332/-1.48771layers=Q ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Osmose QA available on Germany (english)
Hi, We have finish the coverage of Germany by Osmose QA. Osmose QA is a Quality Assurance tool. It detects and reports errors based on more than 200 rulesets. http://osmose.openstreetmap.fr http://wiki.openstreetmap.org/wiki/Osmose Germany coverage was done by split the country in two parts. One is checked by the Osmose Czech server and the other by the USA server sponsored by Mapbox. If some one is interested in running a specific server for Germany it will be much appreciated and save the other servers to support other areas. Fell free to report over checked errors or check rules no adapted to your country. We also take ideas (and code) for new rules. The Osmose QA team. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Tagging der abgeholzten Waldflächen
2015-04-26 11:54:08 Norbert Wenzel (norbert.wenzel.li...@gmail.com): [...] Ich hab nur ein Problem damit land*use* zu verändern, weil der Wald ein Jungwald ist. Daher der Vorschlag es mit Zusatztags zum Beispiel zur Bewuchshöhe oder Begehbarkeit einzutragen. Es ist eben ein Wald der gerade aufgeforstet wird. Und nicht etwas vollkommen anderes. [...] Die Multipolygone mit landuse=forest sind aber überseht mit inneren Flächen aller möglichen Varianten, z.B. natural=grassland, natural=scrub, landuse=meadow, landuse=residential... Ist das störend? Auf meinen GPS-unterstutzten Wanderungen, die teilweise sogar weglos verlaufen, ist es eine große Erleichterung, solche Flächen erkennen zu können. Auch wenn ich die GPS-Karten teilweise selbst erstelle und daher prinzipiell selbst entscheiden kann, was und wie ich auf der Karte darstellen will, wäre es - so glaube ich - vom Vorteil, wenn dieses Problem von vielen Seiten beleuchtet wird und ein Konsens-Vorschlag gefunden werden kann. (Ansonsten läuft man die Gefahr, auf irgendeine statistisch unübliche Art taggen zu anfangen, um dann davon eigene Karten zu erstellen, was auch einer art Tagging für den Renderer wäre). ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 26/04/15 10:03, Borut Maricic wrote: Wie taggt ihr die Flächen, die abgeholzt sind und vor allem mit Baumstumpfen überseht sind? Es gibt wenig Gras und wenn, dann meistens ausgetrocknet. Da und dort sind die neuen sehr kleinen Bäumchen zu sehen. In 20+ Jahren könnte das wieder ein Wald werden. Ein Beispiel aus meiner gestrigen Survey-Wanderung: http://umleoben.borut.eu/osm/landusefrage.jpg Ich habe solche Flächen bis jetzt meistens mit natural=scrub getaggt, bin aber damit nicht ganz zufrieden, da eigentlich wenig Gebüsch zu sehen ist. natural=fell scheint mir noch weniger passend aus. Aus der Diskussion folgernd würde ich folgendes vorschlagen: natural=scrub mit fixme=abgeholzt solange, bis man sich auf einen neuen Tag dafür geeinigt hat. Aber die neue Fläche NICHT aus dem landuse=forest-MP ausnehmen, da die Landnutzung als Forst ja nach wie vor besteht. lg, Michi -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Removing redundant routing instructions
There already is a through_route relation, to show the path of the through route. It might not be well documented, but it is used (I believe)by mkgmap. There was a proposal, which was eventually rejected: http://wiki.openstreetmap.org/wiki/Proposed_features/through_route IMHO it was rejected as it was seen as a hint for the router, not as an aid to navigation, and people don't understand the difference. Yeah I'm aware of that. In fact my example has been sat on my computer since that proposal and I've only just got back to looking at it!! This is in effect a revival of that proposal with a quite different example. I picked a different name as Through Route has a meaning in the UK - it means a route that takes you past a town whilst avoiding the congested city centre. If you think we should revive the through_route proposal then I'm happy with that instead. I'm not sure I get your point about hint for router versus aid for navigation. I suspect this may stem from the don't tag for the renderer rule. If we look at the end use case the aim is to get a routing engine that provides an optimal route with user friendly route instructions. I can't believe this is an easy tag and as such I would expect the routing developers to be raising issues they cannot solve via code alone. This is one area where I would like my SatNav not to spew redundant instructions. Best, Rob p.s. Is highway=motorway_junction a hint for router or an aid for navigation? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On Sun, 26 Apr 2015 11:23:31 +0200 Norbert Wenzel norbert.wenzel.li...@gmail.com wrote: Warum sollte ein Jungwald bzw. die Aufzucht nicht auch ein Wald sein? Weil wir Geodaten aufnehmen, die unter anderem zur Orientierung dienen und sich der optische Eindruck im Feld sowie die Begehbarkeit von Wald und Jungwald in den ersten paar Jahren doch ganz erheblich unterscheiden... ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Osmose QA available on Germany (english)
Le 26/04/2015 12:40, Simon Poole a écrit : Am 26.04.2015 um 11:50 schrieb Frédéric Rodrigo: Hi, We have finish the coverage of Germany by Osmose QA. Osmose QA is a Quality Assurance tool. It detects and reports errors based on more than 200 rulesets. The major issue with osmose is that it invokes the notion of being authoritative when it is not, and by that motivates mappers to fix things (well actually break them) which are simply false positives. This is mainly a language issue in that you keep on using error all over the place instead of potential issue or whatever that is not such an absolute. It's the first time I hear this argument. But we can evol on this, it's not a problem for me. Nevertheless we try to only show issues when there is no problem with the definition of what it may be. We already remove rules cause of this, or disable some specifically for country of different local mapping usage. Regards. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] bano-data sur github
Lorsque j'ai eu le temps de chasser du rouge, la lecture du diff quotidien de github m'aidait bien : je vérifiait que mes changements produisaient de nouveaux rapprochements, et j'ai aussi debuggué des oscillations par exemple quand une moitié de rue était nommée rue Jules Verne et l'autre moitié rue de Jules Verne, il arrivait que le rapprochement se fasse un jour sur deux avec chaque moitié de rue. C'était assez facile à repérer et corriger. Ça reste une justification indirecte de github : Il y a sans doute d'autres outils pour faire ces contrôles. Art. Le 26 avr. 2015 5:10 PM, Christian Quest cqu...@openstreetmap.fr a écrit : Pas normal... mais ce mode de distribution (expérimental) semble peu adapté vu le volume global et la quantité de changements. Je pensais stopper... Le 26/04/2015 11:23, Pierre-Yves Berrard a écrit : Bonjour, Est-il normal que les fichiers bano[1] sur github ne soient plus mis à jour depuis un mois ? PY [1]https://github.com/osm-fr/bano-data -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 26.04.2015 16:40, Borut Maricic wrote: Ich finde aber gleichzeitig, dass - entsprechend dem Michaels Vorschlag - ein fixme=abgeholzt nicht schaden würde. fixme heißt, dass was zu tun (nämlich zu fixen) ist. Das ist aber gerade nicht der Fall: Im Gegenteil: Aus meiner Sicht wäre das ein Indikator, dass die Fläche aus dem Multipolygon nicht zu entfernen ist (sprich, in die Multipolygon-Definition nicht einzutreagen ist). Ich finde es schlimm, dass heute schon so viel durch selbsternannte Korrigierer ohne Ortkenntnis und ohne nachzufragen verpfuscht wird, dass man schon auf alles ein note=stimmt wirklich, bitte so lassen setzen muss. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] kresleni vodniho toku s vodni nadrzi
Ahoj! prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? Ten druhy... aby bylo jasne, jakym smerem ta voda v te nadrzi tece. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Traduction JOSM
Le 25 avril 2015 10:01, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : - j'ai traduit quelques items vides mais je ne sais pas si ça a bien été pris en compte : il faut attendre une nouvelle version de JOSM ça vient d'être pris en compte pour la prochaine version: https://josm.openstreetmap.de/changeset/8278/josm A+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-gb-westmidlands] Cycle parking
Good. Something a bunch of OSMers agree on - that's novel! Rob On 26 Apr 2015 22:09, Andy Robinson ajrli...@gmail.com wrote: 6x2 *From:* Rob Nickerson [mailto:rob.j.nicker...@gmail.com] *Sent:* 26 April 2015 12:00 *To:* talk-gb-westmidlands *Subject:* [Talk-gb-westmidlands] Cycle parking Quick question. What is the capacity of the following cycle parking rack? (The image shows a cycle rack consisting of 6 hoops/stands) https://drive.google.com/file/d/0B6J5ZA1hu93ba09qLTlnZFJMSkk/view?usp=sharing I have my view but just want to confirm with others. Cheers, Rob -- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4800 / Virus Database: 4311/9633 - Release Date: 04/26/15 ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN
Bonjour, Le rendu est bien et très intuitif car similaire à l'ancien. Cependant, le rendu BAN n'apparaît pas pour les niveaux de zoom 17 ou 18 : c'est une question de temps mise en place ou de lisibilité ? D'autre part, il y a des adresses BAN qui concernent des lotissements - avec des numéro 5000 - . Vu qu'aucune route ne porte ce nom, il n'y aura jamais de rapprochement possible (?), si c'est le cas, est-ce qu'il est pertinent de les laisser en rouge ? Patrick Le 26/04/2015 17:20, Christian Quest a écrit : Encore un peu de neuf sur le rendu BANO sur les données BAN... Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Pour les différencier, j'ai mis : - en pointillé rouge les adresses BAN pour lesquelles un rapprochement a pu être fait avec FANTOIR mais pas avec OSM - en pointillé gris les adresse BAN pour lesquelles le rapprochement FANTOIR n'a pas pu être fait. C'est un premier jet ;) Exemple sur une commune au cadastre raster: http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.96311/2.19007 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015
Sorry voor cross-posting. Kort voor Koningsdag zijn de BAG van April 2015 en een nieuwe BRT Top10NL via PDOK beschikbaar gekomen. NLExtract heeft dezen gezwind in PostGIS ingelezen en ter download beschikbaar gesteld: Top10NL: http://data.nlextract.nl/top10nl/postgis/apr2015/ BAG: http://data.nlextract.nl/bag (ook CSV) Hartelijke groet, --Just ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-fr] (sans objet)
Le dimanche 26 avril 2015 22:01:09 Parvillers OSM a écrit : Bonsoir Christian, Où retrouver la légende complète ? Les points bleus, bleus clairs, gris Bonsoir, Dans les crédits de la carte en bas à droite, il y a un lien BANO vers le wiki. https://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_(BANO) Les couleurs sont expliquées à la section Légende -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] (sans objet)
Sur le wiki, clique sur le lien BANO dans les attributions... et ça t'amène sur https://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29 Le 26/04/2015 22:01, Parvillers OSM a écrit : Bonsoir Christian, Où retrouver la légende complète ? Les points bleus, bleus clairs, gris Merci Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Pour les différencier, j'ai mis : - en pointillé rouge les adresses BAN pour lesquelles un rapprochement a pu être fait avec FANTOIR mais pas avec OSM - en pointillé gris les adresse BAN pour lesquelles le rapprochement FANTOIR n'a pas pu être fait. C'est un premier jet ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-gb-westmidlands] Cycle parking
6x2 From: Rob Nickerson [mailto:rob.j.nicker...@gmail.com] Sent: 26 April 2015 12:00 To: talk-gb-westmidlands Subject: [Talk-gb-westmidlands] Cycle parking Quick question. What is the capacity of the following cycle parking rack? (The image shows a cycle rack consisting of 6 hoops/stands) https://drive.google.com/file/d/0B6J5ZA1hu93ba09qLTlnZFJMSkk/view?usp=sharing I have my view but just want to confirm with others. Cheers, Rob _ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4800 / Virus Database: 4311/9633 - Release Date: 04/26/15 ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-cz] Podklady do iD editoru
Ahoj, zveřejnil jsem skriptík, který načítá obrázky z WMS služby, kešuje a předkládá jako XYZ dlažidce. [1] Vložil jsem tedy odkaz do dokumentace iD a k UHUL+CUZk /freemap [2], klidně ho používejte, kde bude třeba a doporučte případným začátečníkům co dělají v iD. Mohlo by to taky ulevit zátěži UHUL serverů, ale zatím mám kešnuto tak 70 MB :) Hezký den, Pavel osm.zby.cz [1]: https://github.com/zbycz/php_wms2tile [2]: http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/freemap#WMS_UHUL_-_ortofotomapa ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-es] Muros New Jersey
Hola: Llevo ya un tiempo incluyendo en el mapa los muros New Jersey que suele haber junto a carreteras. Usaba, sin pensar demasiado en ello, los valores por defecto que aparecen en Josm. Hoy se me ha ocurrido hacer una búsqueda en Taginfo y he visto que hay dos opciones: 1. barrier=wall, wall=jersey_barrier -- 324 apariciones 2. barrier=jersey_barrier -- 534 apariciones. Escribo de memoria, pero creo recordar que yo mismo he usado las dos opciones.Tampoco he sabido encontrar si Osmand reconoce ambas, una o ninguna, que podría ser una guía. ¿Sería bueno optar por una? ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [OSM-talk-fr] Rendu BANO: visualisation des adresses de la BAN
Oups... je vire les numéros en 5xxx, 9xxx et 0 de ces entourages... Le 26/04/2015 19:38, Patrick Proy a écrit : Bonjour, Le rendu est bien et très intuitif car similaire à l'ancien. Cependant, le rendu BAN n'apparaît pas pour les niveaux de zoom 17 ou 18 : c'est une question de temps mise en place ou de lisibilité ? D'autre part, il y a des adresses BAN qui concernent des lotissements - avec des numéro 5000 - . Vu qu'aucune route ne porte ce nom, il n'y aura jamais de rapprochement possible (?), si c'est le cas, est-ce qu'il est pertinent de les laisser en rouge ? Patrick Le 26/04/2015 17:20, Christian Quest a écrit : Encore un peu de neuf sur le rendu BANO sur les données BAN... Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Pour les différencier, j'ai mis : - en pointillé rouge les adresses BAN pour lesquelles un rapprochement a pu être fait avec FANTOIR mais pas avec OSM - en pointillé gris les adresse BAN pour lesquelles le rapprochement FANTOIR n'a pas pu être fait. C'est un premier jet ;) Exemple sur une commune au cadastre raster: http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/48.96311/2.19007 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-at] Tagging der abgeholzten Waldflächen
Am 26.04.2015 17:09, schrieb Stefan Tauner: Ja, das folgt aus der Definition von landuse=forest, denn dieses Tagging bezeichnet ganz allgemein wirtschaftlich genutzte Waldgebiete... was auch abgeholzte Flächen miteinschließt. Das stimmt so nicht (mehr). Früher stand landuse=forest tatsächlich für die forstwirtschaftliche Nutzung, aber inzwischen heißt es einfach nur noch Wald - mit allen daran hängenden Assoziationen. Die entsprechende Änderung wurde vor Jahren durchgedrückt (Wieso taggen wir die Wälder denn zweimal als Wald?!?) und mit großflächigen Edits zementiert. Das Problem dabei ist, dass die Renderer das als dunkelgrüne Fläche darstellen und wir das alle mit Wald gleichsetzen Das hängt aber damit zusammen, dass sich die Bedeutung des Tags mittlerweile verändert hat. Wenn man die Situation wirklich bereinigen will, dann muss man sich m.E. ein neues Tag suchen (landuse=forestry oder so) und das dann konsequent dokumentieren und nutzen. Sonst wird das Chaos nur noch größer. Viele Grüße, Tobias ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk] Event Calendar on Wiki
I added an event (OSM Basics @ Colorado State University...) to the wiki (by editing the calendar template as the instructions state), yet it doesn't show up on the main wiki page with the other events. Did I do something wrong? Mike ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-cz] Hromadná kontrola relací
Dne 24. dubna 2015 22:12 Petr Vejsada o...@propsychology.cz napsal(a): Ahoj, Dne Pá 24. dubna 2015 16:17:38, Václav Kubíček napsal(a): Potřeboval bych to pro pěší turistické trasy, nejlépe po okresech. Je nějaká jednoduchá možnost jak to rozběhat doma? pokud nemáš doma rozběhanou databázi s mapovými daty, tak, myslím, *jednoduchá* možnost není. Vyžaduje to nainstalovat a zprovoznit dost software (PostgreSQL, PostGIS, GDAL, PROJ, GEOS a ještě nějaké další podpůrné knihovny - záleží na tvém současném vybavení). Pěší turistické trasy by neměl být problém vyrobit (po okresech). Co je to turistická trasa? To je relace type=route,route=hiking? Myslím, že tyto relace by neměly mít díry, ale mají, protože jsou nekompletní. Zato ocásky, myslím, jsou OK - existují na trasách různé odbočky a zacházky. Klasická turistická (žlutá) značka bez ocásků je kct_yellow=major kdežto např. odbočka na vrchol (ocásek ale správně) by bylo kct_yellow=peak. Lukáš -- Petr Díky Vašek __ Od: Petr Vejsada o...@propsychology.cz Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 23.04.2015 02:36 Předmět: Re: [Talk-cz] Hromadná kontrola relací Ahoj, myslím, že jsem to vymyslel :). Například relace 4596026 je v pořádku. Relace 4152287 ne. Dělám to, jako obvykle, rovnou z databáze. Když mi pošleš seznam relací, které chceš otestovat, nebo lépe když mi pošleš způsob jakým poznám, které relace se mají testovat, tak to udělám. Dělám to z tabulky pro Mapnik: select -osm_id as relation_id,case when st_geometrytype(st_linemerge(st_collect(way))) = 'ST_LineString' then true else false end as valid from gis.cz_line where osm_id 0 group by osm_id; Vlastně ještě jednoduší, máš to ke stažení na http://pedro.poloha.net/osm/relace.csv.xz http://pedro.poloha.net/osm/relace.csv.xz -- Petr Dne Út 21. dubna 2015 10:30:27, Václav Kubíček napsal(a): Ahoj, nevíte jestli existuje nějaký nástroj nejlépe na hromadnou kontrolu lineárních relací? Potřeboval bych nějak upozornit, zda jsou cesty v relaci někde přerušené nebo se v ní vyskytují ocásky (někdo protáhl cestu a nevšiml si že je na ní relace). Díky Vašek ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk] Wiki project: Article about the standard layer, with key
On 26 April 2015 at 16:11, colliar colliar4e...@aol.com wrote: Nice work so far, but are the any plans on carto side and on the wiki side to support the taginfo feature projects ? From the carto side not at the moment, see https://github.com/gravitystorm/openstreetmap-carto/issues/961 . It is currently not possible to generate the list of supported tags automatically, and nobody has volunteered to maintain the list manually. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Event Calendar on Wiki
On Sun, Apr 26, 2015 at 11:22 AM, Mike Thompson miketh...@gmail.com wrote: I added an event (OSM Basics @ Colorado State University...) to the wiki (by editing the calendar template as the instructions state), yet it doesn't show up on the main wiki page with the other events. Did I do something wrong? I see it listed on the wiki main page. You have it scheduled for April 27th. -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-fr] (sans objet)
Bonsoir Christian, Où retrouver la légende complète ? Les points bleus, bleus clairs, gris Merci Afin d'aider à compléter les noms de rues manquants dans OSM, j'ai ajouté l'entourage des adresses BAN sur le même principe que celles du cadastre. Pour les différencier, j'ai mis : - en pointillé rouge les adresses BAN pour lesquelles un rapprochement a pu être fait avec FANTOIR mais pas avec OSM - en pointillé gris les adresse BAN pour lesquelles le rapprochement FANTOIR n'a pas pu être fait. C'est un premier jet ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-it] Modello lettera mancata attribuzione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 19/04/2015 12:11, aborruso ha scritto: Cesare, ho creato un modello minimale, per il caso più tipico di mancata attribuzione: http://bit.ly/1O4wmVG Come avevo precedentemente scritto, ho creato la pagina dedicata, per il momento è una sandbox presso il mio profilo wiki.openstreetmap [0] (ho usato un link breve erchè senno diventava una pagina e mezza come testo), in attesa di modifiche ulteriori ed aggiunte, prima di proporre lo spostamento. Non è un gran che di pagina, ma siate liberi di modificarla se siete registrati sulla wiki, e ovviamente non mancate di segnalare la modifica, a fini di evitare casini di modifiche delle modifiche. Chiedo, è da ritenersi una pagina che va bene anche ad uso internazionale? Perchè in tal caso c'è da creare la pagina in inglese, e come si sà non è il mio forte, al momento.. [0] http://tinyurl.com/p3eqsvf - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVPRmhAAoJEMTPIIVov0ZtBEcH/jIBA9pswDhL9xWbwlw0jSg9 dslHAlbqVUPU++qXcDxvNDOviBhRUqFaFxOrftMag66Yv7CRubvNEfuu/Q5aX9lM R2l019GI3FiLl6KGseKs7Q9+twhbcSaXKC1kLubdaT+gOyBs2A5HYciKEXJuvmMA G65IJD6esk4Lair8kJBfn6gg0lWi0aBHDivYqgG/BqI8eKq7fgAo8pPniLZ5KX7N LQpZDHTDrg+fiRrQiOWpKegz8Bug/Mo9ytA/1O/sNIG6CvCDifqDJOfxTUudQ5m3 BZ8dFYgDfd/t5V6phv31jsyvITHOdJ/fy4q5AEYPvmdB2dLfyS1kvQoWcAAt8/M= =gWbR -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Modello lettera mancata attribuzione
Il giorno 26 aprile 2015 19:00, girarsi_liste liste.gira...@gmail.com ha scritto: Chiedo, è da ritenersi una pagina che va bene anche ad uso internazionale? C'è già qualcosa: https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution/Example_email A mio avviso bisognerebbe fare un lavoro di integrazione per uniformare a livello internazionale. Ciao! Carlo P.S.: Mi son permesso di sostituire il vecchio contenuto su Google Docs con un link al wiki, per evitare che vengano apportate modifiche sulla vecchia pagina. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[OSM-talk-be] De Haan virtual village
Hi all Seaside village De Haan/Le Coq is launching a virtual tour in their city (in Dutch): http://dehaan.liquifi.be/websites/2/templates/105/news_events_template.aspx?news=339web=2 They are presenting it to the press and the public tomorrow at 19:00 in Sunparks De Haan (http://www.openstreetmap.org/?mlat=51.28237mlon=3.06453#map=18/51.28237/3.06453). I imagine it will be a bit like Street View. Perhaps we could ask them for permission to use the imagery to map from? Ideally they should also use OpenStreetMap if there is an overview map of course, but I don't see that happening too soon if they have already worked out the project. Groeten Ruben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [Talk-de] Hundekottütenspender tagging
Am 26.04.2015 um 00:24 schrieb Andreas Goss andi...@t-online.de: Vorher war da der Text aus dem proposal: Vending machines do appear more and more in very different kinds. As they are increasingly a part of everybody’s life, there is also a need to bring them on maps or in to routing devices. In most cases there should also be given a hint to the type of goods the machine offers. das ist eine extrem schlechte Definition weil gar nichts gesagt wird. Klingt eher nach einem Reasoning Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-cz] kresleni vodniho toku s vodni nadrzi
Ahoj, prosim o nazor jak kreslit vodni tok (napr. waterway=stream) s vodni nadrzi (napr. natural=water, water=pond). Konkretne vidam dve reseni, jejichz rozdil je v tom, zda WAY ne/prochazi tou nadrzi: pritekajici WAY konci spolecnym bodem s CLOSED WAY te nadrze a na vystupu zase zacina nova WAY spolecnym bodem - a druhe reseni, pri kterem ta WAY vodniho toku prerusena neni. Ve druhem pripade se pak stava, ze ma WAY s CLOSED WAY spoolecne 0-2 body (zadny, vstupni nebo vystupni, oba). A cele to treba je a nebo neni v relaci... Jaky je tedy spravny postup? S díky VOP ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] Tagging der abgeholzten Waldflächen
On 26.04.2015 19:59, Tobias Knerr wrote: Das stimmt so nicht (mehr). Früher stand landuse=forest tatsächlich für die forstwirtschaftliche Nutzung, aber inzwischen heißt es einfach nur noch Wald - mit allen daran hängenden Assoziationen. Die entsprechende Änderung wurde vor Jahren durchgedrückt (Wieso taggen wir die Wälder denn zweimal als Wald?!?) und mit großflächigen Edits zementiert. Durchgedrückt, wo? Hab ich eine Abstimmung verpasst? Solang sich nur in DE ein paar Kobolde aufführen, kann uns das in AT egal sein. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
