Re: [talk-ph] [HOT] Typhoon Hagupit / Ruby Activation
Dear OSM-PH mappers, [cc: HOT list] It's been almost a week since we started this activation. Fortunately, minimal loss to lives were reported (NDRRMC count is 18). However, the Northern and Eastern Samar was heavily damaged, over 1 million people were affected and economic loss estimate is ~2B Php. Thanks again to HOT's Activation group especially to Mark Cupitt for leading this activation. Once again, the U.S. Department of State’s Humanitarian Information Unit (HIU) facilitated access to pre-disaster imagery through the MapGive initiative. We received tremendous support from many volunteers [1], although not as big as Haiyan/Yolanda, but still, a lot of mapping was done in the last 7 days (167 mappers). At its peak, we have 75 mappers in a single day. What is interesting is that many of these volunteers seems to have come from Philippine-based volunteers (top 5 map changes country breakdown: PH-393,539; Mali-912; unknown-727; Bahamas-102; Liberia-54). A good indication of progress with our local advocacy efforts during the year. Due to minimal international media coverage, it is likely that remote mapping support from international mappers will decline in the coming days. However, the response is not yet over, the American Red Cross (ARC) and International Federation of Red Cross and Red Crescent Societies (IFRC) continues to use our map to support on the ground initiatives within their area of operation, Nick Brown's YPDR team is on their way to Eastern Samar and OSM is their basemap, as well as many UN agencies through UNOSAT [2]. Also last night, we were able to contact friends from Leyte and Northern Samar. Some of them are are also coordinating LGU response. Specifically, Northern Samar's PPDO requested we continue to update the maps within the province. All tasks are published in the wiki coordination page [3]. Aside from the published tasks, another important mapping is the proper geolocation of settlements. For those familiar with the area, please go over the town/city placenames check if these were properly located. Thanks! [0] http://mapgive.state.gov/ [1] http://resultmaps.neis-one.org/osm-changesets?comment=ruby#9/12.0930/124.8610 [2] http://www.unitar.org/unosat/maps/69 [3] http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Typhoon_Hagupit_%28Ruby%29#Published_Tasks_in_the_Task_Manager -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
Op de AGIV website[1]heeft de straat [3] de naam Nieuwe Baan. Is ook zo te vinden in OSM. Volgens deze foto [2] is het echter Nieuwebaan (1 woord). Waar geven we de voorkeur aan ? Gebruik ik eventueel alt_name ? [1] http://geo-vlaanderen.agiv.be/gdiviewer/?simple=false [2] http://xian.smugmug.com/OSM/OSM-2014/2014-12-06-Eindhout/i-BkWNtXz/A [3] https://www.openstreetmap.org/way/239233827 Verder, wat doe ik met de grens ? Zijn de borden langs de straatkant bindend ? Of staat er er maar bij benadering ? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
ok bedankt, dank blijf ik eraf. Dan nu nog de vraag: waar loopt de grens? 2014-12-11 13:13 GMT+01:00 Gilbert Hersschens gherssch...@gmail.com: Marc, de enige juiste schrijfwijze is wat je in CRAB vindt (gebruik de LARA tool om alle details te zien). Ik heb dat ook al meermaals aan de hand gehad in Geel en Gis ambtenaar neemt in principe steeds de gegevens van CRAB over. Gilbert Op 11-dec.-2014 13:07 schreef Marc Gemis marc.ge...@gmail.com: Op de AGIV website[1]heeft de straat [3] de naam Nieuwe Baan. Is ook zo te vinden in OSM. Volgens deze foto [2] is het echter Nieuwebaan (1 woord). Waar geven we de voorkeur aan ? Gebruik ik eventueel alt_name ? [1] http://geo-vlaanderen.agiv.be/gdiviewer/?simple=false [2] http://xian.smugmug.com/OSM/OSM-2014/2014-12-06-Eindhout/i-BkWNtXz/A [3] https://www.openstreetmap.org/way/239233827 Verder, wat doe ik met de grens ? Zijn de borden langs de straatkant bindend ? Of staat er er maar bij benadering ? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
Ben even gaan piepen in CRAB. Staat daar ook als Nieuwe Baan. Het straatnaambordje is dus fout. Je kan dit via CRAB/LARA doorgeven. De foto kan je in LARA uploaden. Werkt redelijk goed. Ik heb dat al een paar keren gebruikt. Het kan ook voorkoomen dat er discrepanties zijn tussen GRB en CRAB, want dat zijn 2 afzonderlijke databases. Meestal is CRAB de winnaar. Welke grens bedoel je ? Tussen Eindhout en Laakdal ? Eindhout (en Veerle) is een deelgemeente van Laakdal. MvG Gilbert 2014-12-11 13:31 GMT+01:00 Marc Gemis marc.ge...@gmail.com: ok bedankt, dank blijf ik eraf. Dan nu nog de vraag: waar loopt de grens? 2014-12-11 13:13 GMT+01:00 Gilbert Hersschens gherssch...@gmail.com: Marc, de enige juiste schrijfwijze is wat je in CRAB vindt (gebruik de LARA tool om alle details te zien). Ik heb dat ook al meermaals aan de hand gehad in Geel en Gis ambtenaar neemt in principe steeds de gegevens van CRAB over. Gilbert Op 11-dec.-2014 13:07 schreef Marc Gemis marc.ge...@gmail.com: Op de AGIV website[1]heeft de straat [3] de naam Nieuwe Baan. Is ook zo te vinden in OSM. Volgens deze foto [2] is het echter Nieuwebaan (1 woord). Waar geven we de voorkeur aan ? Gebruik ik eventueel alt_name ? [1] http://geo-vlaanderen.agiv.be/gdiviewer/?simple=false [2] http://xian.smugmug.com/OSM/OSM-2014/2014-12-06-Eindhout/i-BkWNtXz/A [3] https://www.openstreetmap.org/way/239233827 Verder, wat doe ik met de grens ? Zijn de borden langs de straatkant bindend ? Of staat er er maar bij benadering ? ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Wochennotiz 229
Two Belgian entries this week: Mapper of the Month address import. see http://blog.openstreetmap.de/blog/2014/12/wochennotiz-nr-229/ m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Wochennotiz 229
Lol, I get a mention in the Wochennotiz, but nobody actually takes the effort to reply something decent on my questions to the import@ list. 2014-12-11 19:57 GMT+01:00 Marc Gemis marc.ge...@gmail.com: Two Belgian entries this week: Mapper of the Month address import. see http://blog.openstreetmap.de/blog/2014/12/wochennotiz-nr-229/ m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
2014-12-11 13:46 GMT+01:00 Gilbert Hersschens gherssch...@gmail.com: Welke grens bedoel je ? Tussen Eindhout en Laakdal ? Eindhout (en Veerle) is een deelgemeente van Laakdal. op de foto zie je een bordje met Eindhout-Laakdal. Dit staat ten westen van het beekje. De administratieve grens ligt een eindje verder naar het oosten. Ik vermoed dus dat het beekje de grens vormt. Maar hoe betrouwbaar zijn die bordjes feitelijk ? Heeft iemand daar ervaring mee ? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
Die bordjes staan niet altijd perfect op de grens. Soms worden ze enkele meters verschoven om palen te sparen, of andere borden zichtbaar te houden (zo staan de grensborden van de gewesten en provincies typisch een 10-tal meters uit elkaar). Gewoon voor kwalitatief onderzoek (jammer genoeg mogen we deze data nog niet importeren voor zover ik weet), kan je de GRB basiskaart gebruiken. De grijze lijnen die je kan zien zijn gemeentegrenzen, maar dat is nog maar een voorlopige import die nog verbeterd moet worden. Maar, je zal zien dat de gemeentegrenzen vaak parallel lopen met de perceelsgrenzen. Die perceelsgrenzen zijn wel van goede kwaliteit, en zo kan je dus afleiden hoe groot de fout van verschillende bronnen is op verschillende plaatsen. Het is ook zo dat grenzen in België soms oorspronkelijk bepaald zijn a.d.h.v. natuurlijke elementen (zoals een beekje), maar dat die grenzen niet mee geëvolueerd zijn (bijvoorbeeld als de beek verlegd wordt). 2014-12-11 13:46 GMT+01:00 Gilbert Hersschens gherssch...@gmail.com: Welke grens bedoel je ? Tussen Eindhout en Laakdal ? Eindhout (en Veerle) is een deelgemeente van Laakdal. op de foto zie je een bordje met Eindhout-Laakdal. Dit staat ten westen van het beekje. De administratieve grens ligt een eindje verder naar het oosten. Ik vermoed dus dat het beekje de grens vormt. Maar hoe betrouwbaar zijn die bordjes feitelijk ? Heeft iemand daar ervaring mee ? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Straatnaam vs AGIV Website administratieve grens
bedankt je voor uitleg. Ik laat de grens dan maar liggen 2014-12-11 21:34 GMT+01:00 Sander Deryckere sander...@gmail.com: Die bordjes staan niet altijd perfect op de grens. Soms worden ze enkele meters verschoven om palen te sparen, of andere borden zichtbaar te houden (zo staan de grensborden van de gewesten en provincies typisch een 10-tal meters uit elkaar). Gewoon voor kwalitatief onderzoek (jammer genoeg mogen we deze data nog niet importeren voor zover ik weet), kan je de GRB basiskaart gebruiken. De grijze lijnen die je kan zien zijn gemeentegrenzen, maar dat is nog maar een voorlopige import die nog verbeterd moet worden. Maar, je zal zien dat de gemeentegrenzen vaak parallel lopen met de perceelsgrenzen. Die perceelsgrenzen zijn wel van goede kwaliteit, en zo kan je dus afleiden hoe groot de fout van verschillende bronnen is op verschillende plaatsen. Het is ook zo dat grenzen in België soms oorspronkelijk bepaald zijn a.d.h.v. natuurlijke elementen (zoals een beekje), maar dat die grenzen niet mee geëvolueerd zijn (bijvoorbeeld als de beek verlegd wordt). 2014-12-11 13:46 GMT+01:00 Gilbert Hersschens gherssch...@gmail.com: Welke grens bedoel je ? Tussen Eindhout en Laakdal ? Eindhout (en Veerle) is een deelgemeente van Laakdal. op de foto zie je een bordje met Eindhout-Laakdal. Dit staat ten westen van het beekje. De administratieve grens ligt een eindje verder naar het oosten. Ik vermoed dus dat het beekje de grens vormt. Maar hoe betrouwbaar zijn die bordjes feitelijk ? Heeft iemand daar ervaring mee ? m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] OSM France BANO project... openaddresses in France
On Thu, Dec 11, 2014 at 1:20 AM, Imre Samu pella.s...@gmail.com wrote: Hi Christian, As I read OKFN article [1] about BANO project ( November 17, 2014 ) It's not perfectly clear to me what it is the BANO license ? ( only ODBL or Dual licensed ? ) BANO is ODbL only. The article you refer is about another similar project but different from the one discussed in this thread. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Toevoegen aan adres-node?
Bij de BAG import zijn ook alle adrestags meegekomen, en mijn vraag is of ik aan zo'n adrestag wat mag toevoegen? Nu ik bezig ben (zie links hieronder) met al die amenity en shop tags, zou het praktisch zijn om aan zo'n adrestag ook de overige eigenschappen van dat adres toe te voegen. Dus als ik het adres van de bakker weet, mag ik dan aan die adrestag ook shop=bakery vastmaken? Kijk ook even hier om te zien waarom dit bij me opkwam: http://mijndev.openstreetmap.nl/~marczoutendijk/mzfiets/ en hier om wat meer te lezen: http://forum.openstreetmap.org/viewtopic.php?id=28807 Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Toevoegen aan adres-node?
On 12/11/2014 08:34 PM, Marc Zoutendijk wrote: Bij de BAG import zijn ook alle adrestags meegekomen, en mijn vraag is of ik aan zo'n adrestag wat mag toevoegen? Waarom denk je hier toestemming voor nodig te hebben? Nu ik bezig ben (zie links hieronder) met al die amenity en shop tags, zou het praktisch zijn om aan zo'n adrestag ook de overige eigenschappen van dat adres toe te voegen. Dus als ik het adres van de bakker weet, mag ik dan aan die adrestag ook shop=bakery vastmaken? Zolang er niet meerdere features zijn op het zelfde adres is het prima om de tags aan de adres node te hangen. Als er verschillende features op hetzelfde adres zitten is het beter de adres node te dupliceren voor elke afzonderlijke feature en deze binnen de pandcontour te verdelen. Mvg, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Railway in Sydney .. tagged light_rail
Hi, I've noticed that the main north line railway line in Sydney is tagged railway=light_rail .. that does not make sense to me. It is of the standard gauge for Australia and carries freight! .. so should be tagged railway=rail? Ref http://wiki.openstreetmap.org/wiki/Railways#Types_of_railway_line - I'm not including lines of less than standard gauge, or those not capable of carrying freight. Just the normal train lines in Sydney. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Railway in Sydney .. tagged light_rail
Hi, Now that I've posted .. I cannot find it! Let me scan again later when I have more time to check that I have it wrong/right.. Original Message Message-ID: 548a4bce.7010...@gmail.com Date: Fri, 12 Dec 2014 12:58:38 +1100 From: Warin 61sundow...@gmail.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: talk-au talk-au@openstreetmap.org Subject:Railway in Sydney .. tagged light_rail Content-Type: multipart/alternative; boundary=090801040101020004030307 Hi, I've noticed that the main north line railway line in Sydney is tagged railway=light_rail .. that does not make sense to me. It is of the standard gauge for Australia and carries freight! .. so should be tagged railway=rail? Ref http://wiki.openstreetmap.org/wiki/Railways#Types_of_railway_line - I'm not including lines of less than standard gauge, or those not capable of carrying freight. Just the normal train lines in Sydney. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Railway in Sydney .. tagged light_rail
Hi, Found it .. it is in the route relation ! route=rail would be more appropriate? rather than route=light_rail ? Don't know thence the question. Original Message Message-ID: 548a4bce.7010...@gmail.com Date: Fri, 12 Dec 2014 12:58:38 +1100 From: Warin 61sundow...@gmail.com User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: talk-au talk-au@openstreetmap.org Subject:Railway in Sydney .. tagged light_rail Content-Type: multipart/alternative; boundary=090801040101020004030307 Hi, I've noticed that the main north line railway line in Sydney is tagged railway=light_rail .. that does not make sense to me. It is of the standard gauge for Australia and carries freight! .. so should be tagged railway=rail? Ref http://wiki.openstreetmap.org/wiki/Railways#Types_of_railway_line - I'm not including lines of less than standard gauge, or those not capable of carrying freight. Just the normal train lines in Sydney. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Regras brasileiras de validação no JOSM
Olá Nélson,
Demorei todo esse tempo, mas lá vai o meu primeiro feedback.
Parabéns pela ideia, estou usando junto com as outras validações.
Encontrei alguns pormenores que pretendo citar assim que acontecerem.
O primeiro segue abaixo :
A regra
node[highway =~ /give_way|mini_roundabout|stop|turning_circle/][name] {
throwWarning: tr(objeto não deve possuir {0}, {1.key});}
está apontando erro em todas as paradas de ônibus que possuem name=*,
deve ser por causa do stop como critério de busca, já que elas são
highway=bus_stop.
Att,
Marcelo
Em 28 de janeiro de 2014 23:10, Nelson A. de Oliveira nao...@gmail.com
escreveu:
Quem está com a última versão estável do JOSM já dá utilizar as regras
de validação diretamente pelo próprio JOSM.
As regras estão disponíveis em
http://josm.openstreetmap.de/wiki/Rules/Brazilian-Specific
Notem que na descrição das regras tem Community rules. Seria bom
vocês darem algum feedback sobre as regras (já que elas são feitas
para e pela comunidade brasileira).
Vejam se concordam, se possuem dúvida, sugestões, novas coisas que
podem ser testadas/validadas, etc.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
--
São Pedro recebe Seu Lunga no céu perguntando:
Morreu, Seu Lunga?
Não, vim passar o Natal!
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Buchten/Meeresarme mappen
... und vor allem sollten die vor-Ort mapper einbezogen werden. Also die Diskussion sollte auf die tagging Liste gebracht werden. Volker 2014-12-11 8:32 GMT+01:00 Markus liste12a4...@gmx.de: Moin Mark, um unfallfrei etwas beizutragen (Schottland!) :-) Dazu und zu vergleichbaren Themen hatten wir ja schon mehrere Diskussionen, die mangels schlüssigem Konzept alle irgendwann im Sand verliefen. Es wäre wirklich super, wenn wir das mal erfolgreich angehen könnten! (und nein, ich habe bisher keine Lösung gesehen) Die Schwierigkeit scheint mir folgende zu sein: Aus lokaler Sicht: ich kann doch meine Bucht einfach so mappen?! sieht alles ganz simpel aus, und es gibt schon mehrere Buchten, die kunstvoll und mit viel Akribie schön gemappt wurden. Sobald man aber etwas über den Tellerrrand rausguckt, wird es ziemlich komplex. Und weder Renderer noch Mapper kommen dann weder mit der grundsätzlichen noch mit der praktisch entstehenden Komplexität zurecht. Probleme sind (u.a.): _Unschärfe_ Methodisch scheint es nicht sinnvoll zu sein, ein unscharfes Gebilde durch eine scharfe Linie begrenzen zu wollen. So wie ein Berg nicht ausreichend durch seinen Gipfel beschrieben werden kann, oder ein Ort nicht durch sein Zentrum, aber beides auch nicht durch eine ungefähre Grenzlinie, ist die Definition von Bucht ebenso nicht ganz trivial. _Aufwand_ Wenn dafür auf der einen Seite die Küstenlinie hergenommen wird, und auf der anderen Seite eine willkürliche Gerade, dann gibt es an den zwei Schnittpunkten Konflikte ohne Ende. Damit meine ich nicht so sehr politische Bewertungen, wo denn nun die Bucht endet - sondern wie man Mappingfehler mit praktisch vertretbarem Aufwand korrigieren kann. Je komplexer wir das Mappen gestalten, desto weniger Mapper werden damit zurecht kommen. Je weniger Mapper mitmachen, desto schneller veraltet die Karte :-( _Küstenlinie_ Die Küstenlinie wird ausserhalb der DB gehändelt und wesentlich seltener gerendert als normale Objekte. Das führt dann automatisch zu unbeherrschbaren unschönen Artefakten. Wenn man jetzt die Küstenlinie auch noch zur Begrenzung von Buchten macht, vervielfacht man das Problem. Das Problem gibt es auch bei Landesgrenzen wo diese als Küstenlinie definiert sind, oder bei landuse wenn dieses an Küstenlinien geklebt wird. _Hierarchische Abhängigkeit_ Buchten können riesig sein (Rotes Meer, Golf von Aden) oder miniklein (Badebucht, z.B. https://en.wikipedia.org/wiki/ Children%27s_Pool_Beach). Das erfordert ein Konzept zur Unterscheidung, um die Verschiedenheit vernünftig auf den Zoomleveln darzustellen. Etwas ratlos, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bearbeitung von Landnutzungen im ländlichen Raum.
Hallo, ich bin seit längerer Zeit dabei, die Landnutzung in Nordfriesland mit zu bearbeiten. Doch häufig gerate ich bei der agrarischen Landnutzung (Tags:farmland / meadow / orchard) auch an Grenzen. Diese werden auch im Wiki (DE:Land use and areas of natural land) noch unter dem Abschnitt Offene Fragen behandelt. Würde gerne Kontakt zu weiteren Usern aufnehmen, wie wir die offenen Fragen systematisieren können, um eine deutlichere Klassifikation heraus zu arbeiten. Ich denke, dass hierzu unter Umständen auch auf Gemeindeebene die offiziellen Stellen mit eingeschaltet zwecks Bearbeitung der Geometrien werden sollten. Außerdem besteht nach wie vor der Bedarf einer verbesserten Regelung im Bereich, wie mit den Nodes zwischen einzelnen Flächen und solchen zwischen Flächen und Linien (beispielsweise Straßen und Flüssen etc.) umgegangen werden soll. Mag jemand mit arbeiten? Grüße, goegeo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Hey Früher habe ich auch alles getrennt, mittlerweile versuche ich so viel wie möglich auf eine Linie zu reduzieren. Am 09.12.2014 um 09:01 schrieb Martin Vonwald: Einfachste Lösung wäre wohl: Bei Grüninseln: lanes=2 + traffic_calming=island +1 Leider wird traffic_calming and Linien nur selten unterstützt. eventuell auch noch ein Punkt mit highway=crossing. Bei Mehrzweckspur: lanes=3 + lanes:both_ways=1 + (optional falls irgendwie ersichtlich) turn:both_ways=left turn:both_ways=left;merge_to_right ? Nebenbei, ich verwende das :lanes*-Tagging auch für Bushaltebuchten. Funktioniert super. cu fly Am 9. Dezember 2014 um 00:44 schrieb Tirkon tirko...@yahoo.de: Moin, in einer Ortsdurchfahrt sind die beiden gegenläufigen Richtungsfahrspuren mehr oder weniger in der Mitte durch eine sogenannte Mehrzweckspur getrennt. Den Begriff hat die Verkehrsbehörde über die Presse verbreiten lassen. Diese mittlere Spur unterscheidet sich von den beiden Richtungsfahrbahnen durch einen leicht helleren Asphalt. Sie wird immer wieder durch bepflanzte Verkehrinseln unterbrochen, wobei teilweise eine Überquerungshilfe für Fu0gänger/Radfahrer eingebettet ist. Die Inseln sorgen dafür, dass die mittlere Mehrzweckspur - wie beabsichtigt - nicht vom fließenden Durchgangsverkehr befahren wird. Die Mehrzweckspur dient laut Presse zum Ein- und Ausfädeln von Linksabbiegern auf/von Grundstückseinfahrten und kleinen Nebenstraßen sowie zum gelegentlichen Überholen. Nur an wenigen Stellen ist die Mittelspur durch weiße Streifen von den durchgehenden Richtungsfahrspuren getrennt, nämlich wenn sie beampelt zur echten Linksabbiegespur auf größere Straßen mit Richtungspfeilen auf der Fahrbahn wird. Momentan ist die Straße bei OSM als zwei getrennte Richtungswege eingetragen, was dem funktionalen Charakter entspräche. Wollte man sie streng nach den Regeln mappen, müsste man sie suboptimalerweise wegen der vielen Inseln ständig verzweigen und zusammenführen. Gibt es da eine bessere Möglichkeit? ergänzende Info: Unmittelbar neben der Straße verläuft noch eine Güterzugstrecke mit zig Bahnübergängen durch den Ort. Bisweilen sind Bushaltestellen zwischen Bahn und Straße eingefügt. Dieses ganze Paket wird beidseitig von abgesetzen Fuß-/Radwegen eingerahmt, wobei einer keine entsprechende Beschilderung aufweist. Seit die Straße mit der Mehrzweckspur versehen wurde, läuft der Verkehr deutlich reibungsloser. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte
Am 11. Dezember 2014 um 15:06 schrieb fly lowfligh...@googlemail.com: Bei Mehrzweckspur: lanes=3 + lanes:both_ways=1 + (optional falls irgendwie ersichtlich) turn:both_ways=left turn:both_ways=left;merge_to_right ? Guter Punkt! Für's Einfädeln passt das merge_to_right . ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 229 2.12.–8.12.2014
Hallo, die Wochennotiz Nr. 229 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-229/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 229 2.12.–8.12.2014
Der richtige Link: http://blog.openstreetmap.de/blog/2014/12/wochennotiz-nr-229/ Liebe Grüße Benjamin On 11.12.2014 18:33, wn reader wrote: Hallo, die Wochennotiz Nr. 229 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-229/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] applicazione per condividere posizione
Proprio in questi giorni, pensando anche io a usi per le emergenze e ricerca dispersi, mi sono confrontato direttamente con lo sviluppatore di Oruxmaps per apportare delle migliorie o meglio delle finezze che potrebbero essere utili in scenari o contesti di questo genere. Non è solo un parere mio che tutte le soluzioni in giro, che prevedono la presenza della rete dati, non sono affidabili, per ovvi motivi: in zone impervie/montagna sulla rete dati non si può fare affidamento. E quindi vanno pensate necessariamente soluzioni con mappe offline, con la sola presenza del segnale GPS/GLONASS -- View this message in context: http://gis.19327.n5.nabble.com/applicazione-per-condividere-posizione-tp5826715p5826949.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] applicazione per condividere posizione
Ma il segnale Ggs/Glonass ci aiuta solo a trovare la nostra posizione. Come facciamo poi a condividerla con quella degli altri in assenza di una rete? - Original Message - From: Davide Mangraviti davide...@inwind.it To: talk-it@openstreetmap.org Sent: Thursday, December 11, 2014 4:19 PM Subject: Re: [Talk-it] applicazione per condividere posizione Proprio in questi giorni, pensando anche io a usi per le emergenze e ricerca dispersi, mi sono confrontato direttamente con lo sviluppatore di Oruxmaps per apportare delle migliorie o meglio delle finezze che potrebbero essere utili in scenari o contesti di questo genere. Non è solo un parere mio che tutte le soluzioni in giro, che prevedono la presenza della rete dati, non sono affidabili, per ovvi motivi: in zone impervie/montagna sulla rete dati non si può fare affidamento. E quindi vanno pensate necessariamente soluzioni con mappe offline, con la sola presenza del segnale GPS/GLONASS -- View this message in context: http://gis.19327.n5.nabble.com/applicazione-per-condividere-posizione-tp5826715p5826949.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it - Nessun virus nel messaggio. Controllato da AVG - www.avg.com Versione: 10.0.1434 / Database dei virus: 4235/8214 - Data di rilascio: 11/12/2014 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] applicazione per condividere posizione
Mi riferivo alla rete dati, sulla quale si basano le offerte di servizi che fanno real time tracking. Mi pare più realisitica la possibilità di poter condividere la sola posizione, magari mandando via rete GSM un SMS, con dentro le coordinate, che si basano in genere su gmaps, che tutti leggono. Con la possibilità poi di vedere la posizione su base OSM, ma quello è un altro discorso. Quando mi trovo a consigliare servizi a persone che partono seriamente per avventure, montagna ect.. sono sempre propense ad indirizzarle verso servizi tipo questo: http://www.findmespot.eu/it/ -- View this message in context: http://gis.19327.n5.nabble.com/applicazione-per-condividere-posizione-tp5826715p5826963.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
2014-12-10 23:19 GMT+01:00 Marco_T toto...@libero.it: Segnalo un odierno -34... Forse è dovuto a questo changeset: http://www.openstreetmap.org/changeset/27380218 Correzione con Osmose History viewer: http://osmhv.openstreetmap.de/changeset.jsp?id=27380218#map=7 Saluti. -- Marco_T Ciao, Simone F. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] applicazione per condividere posizione
La scatolina la trovi in internet 30€... se non ricordo male la settimana scorsa era in offerta a 12, ovviamente senza adesivo spot. -- cascafico.altervista.org twitter.com/cascafico Syncthing Node ID 2M2D4D6-Q7QSYGE-VGLD4YO-KR62AOJ-F6MUSUA-AQRF27C-XVQP63G-4ADMFAA Il 11/dic/2014 18:29 Davide Mangraviti davide...@inwind.it ha scritto: Mi riferivo alla rete dati, sulla quale si basano le offerte di servizi che fanno real time tracking. Mi pare più realisitica la possibilità di poter condividere la sola posizione, magari mandando via rete GSM un SMS, con dentro le coordinate, che si basano in genere su gmaps, che tutti leggono. Con la possibilità poi di vedere la posizione su base OSM, ma quello è un altro discorso. Quando mi trovo a consigliare servizi a persone che partono seriamente per avventure, montagna ect.. sono sempre propense ad indirizzarle verso servizi tipo questo: http://www.findmespot.eu/it/ -- View this message in context: http://gis.19327.n5.nabble.com/applicazione-per-condividere-posizione-tp5826715p5826963.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Josm logo nuovo......
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Non l'ho visto passare in lista, ma per chi usa Josm versione sperimentale(io l'ho scaricato oggi l'aggiornamento), sicuramente ha notato il nuovo logo. Risultato vincitore dal recente JOSM/Graphic Contest. http://wiki.openstreetmap.org/wiki/JOSM/Graphic_Contest#Results - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUigNpAAoJEMTPIIVov0ZtyigH/jcvr8Uyn+mwU2f/QjkyQwjn OkEQXdi9SXvsOAe1N5lt6Tbn04Kp1FBsnOG3v+wiHLYw0AD96ygICZN3tpldtn7A z+zhKB39mOeoqBXFRBznJm+AdmQyLeJcGd4CrsDzXsb5QRUfXhiQ3vdCCsdW/Go2 3d8cAisPJsGyKAyrceSB8/grwWYwlmDryapqw+24Rc2je4we/H6GxXkrtAz50GOa TOYaTGd26xC6AWm1zF7XV3sA5mtpamZzWpeGqhby+st9HagimSCqtZ6LfNIvfAzk O7yqwXdGyzjE84qjVshVAnKcGxaTpuuBmwGnBXxD9a+Kf89KPwSmKBYFuihYBvE= =zjqR -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] applicazione per condividere posizione
Il 11/12/2014 18:29, Davide Mangraviti ha scritto: Mi riferivo alla rete dati, sulla quale si basano le offerte di servizi che fanno real time tracking. Mi pare più realisitica la possibilità di poter condividere la sola posizione, magari mandando via rete GSM un SMS, con dentro le coordinate, che si basano in genere su gmaps, che tutti leggono. Con la possibilità poi di vedere la posizione su base OSM, ma quello è un altro discorso. Ho letto che hai contattato lo sviluppatore di Oruxmap, puoi indicare che migliorie hai proposto? Un pulsante SOS che manda in automatico la posizione via SMS? Come dicevi queste soluzioni vanno bene dove c'è la copertura dati. In zone non coperte restano solo le soluzioni con collgamento satellitare. Quando mi trovo a consigliare servizi a persone che partono seriamente per avventure, montagna ect.. sono sempre propense ad indirizzarle verso servizi tipo questo: http://www.findmespot.eu/it/ tornando all'argomento principale della discussine, segnalo altre due applicazioni GPSies e GPSLogger (è senza mappa ma è molto semplice) -- Dario Zontini ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
Simone F. wrote Forse è dovuto a questo changeset: http://www.openstreetmap.org/changeset/27380218 Correzione con Osmose History viewer: http://osmhv.openstreetmap.de/changeset.jsp?id=27380218#map=7 Molte correzioni le condivido. Su alcune ho notato che sono state cancellate alcune voci collegate a pagine non italiane di wikipedia. A me pero' sembra che alcune di quelle pagine esistono. Mah..forse mi sbaglio nell'interpretare la tabella. Grazie. Ciao. -- Marco_T -- View this message in context: http://gis.19327.n5.nabble.com/Diminuzione-Tag-totali-wikipedia-tp5824663p5826983.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
Il 11 dicembre 2014 22:07, Marco_T ha scritto: Simone F. wrote Forse è dovuto a questo changeset: http://www.openstreetmap.org/changeset/27380218 Correzione con Osmose History viewer: http://osmhv.openstreetmap.de/changeset.jsp?id=27380218#map=7 Molte correzioni le condivido. ad esempio? la rimozione dei tag ridondanti è ridondante :-) quindi poteva anche non farla anche perché ci sono stati degli effetti collaterali: nelle relazioni 2507329, 2139733 e 2139593 oltre alla modifica relativa a wikipedia, il campo note è passato da http://forum.openstreetmap.org/viewtopic.php?id=16094 a http://forum.openstreetmap.org/viewtopic.php?id e magari anche in altre -- Daniele Forsi ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] applicazione per condividere posizione
No, non era nelle mie intenzioni l'idea di trasformare quella gran bella app che è Oruxmaps, in un telefono per persone anziane con il tasto SOS A parte le battute, ho chiesto se potesse aggiungere la possibilità di interpretare indirizzi del tipo http://maps.google.com/maps?q=lat,lon per creare dei waypoint al volo. La modifica sarà presente nell'aggiornamento prossimo. All'altro suggerimento sta ancora lavorando ciao Davide Dario Zontini wrote Il 11/12/2014 18:29, Davide Mangraviti ha scritto: Mi riferivo alla rete dati, sulla quale si basano le offerte di servizi che fanno real time tracking. Mi pare più realisitica la possibilità di poter condividere la sola posizione, magari mandando via rete GSM un SMS, con dentro le coordinate, che si basano in genere su gmaps, che tutti leggono. Con la possibilità poi di vedere la posizione su base OSM, ma quello è un altro discorso. Ho letto che hai contattato lo sviluppatore di Oruxmap, puoi indicare che migliorie hai proposto? Un pulsante SOS che manda in automatico la posizione via SMS? Come dicevi queste soluzioni vanno bene dove c'è la copertura dati. In zone non coperte restano solo le soluzioni con collgamento satellitare. Quando mi trovo a consigliare servizi a persone che partono seriamente per avventure, montagna ect.. sono sempre propense ad indirizzarle verso servizi tipo questo: http://www.findmespot.eu/it/ tornando all'argomento principale della discussine, segnalo altre due applicazioni GPSies e GPSLogger (è senza mappa ma è molto semplice) -- Dario Zontini ___ Talk-it mailing list Talk-it@ https://lists.openstreetmap.org/listinfo/talk-it -- View this message in context: http://gis.19327.n5.nabble.com/applicazione-per-condividere-posizione-tp5826715p5826986.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-cat] EPSEB - Geòmetres sense fronteres
Bon dia. Fa potser cosa d'un mes, es va parlar de fer alguna mena d'activitat a la UPC impulsar la tasca de l'èbola del HOT. Al final es va fer alguna cosa? He estat mirant i al campus diagonal-sud de la UPC hi ha l'Escola Politècnica Superior d'Edificació de Barcelona, on entre altres estudis hi ha la Eng. Geomàtica i Topografia. En aquesta facultat hi ha una associació d'estudiants que m'ha cridat bastant l'atenció:«Geòmetres sense fronteres». Hi ha algú d'aquesta facultat a la llista? Si no és així, la meva intenció és apropar-me un dia d'aquests a veure si coneixen el tema del HOT i OSM. Potser hi ha sort i enganxem algú més al projecte. ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
[Talk-ca] Road designations
I have a question for the group regarding the designation of various roads within city regions. Specifically, with reference to primary, secondary, and tertiary roads. What exactly is the criteria being used to designate a road as one or the other? I know that the wiki provides guidance, but it does not appear that the guidance is always followed. For example, this is an area inside Montreal: As you can see, there are two secondary one-way roads here (orange) and a yellow tertiary road connecting them together in the lower right. I cannot fathom why that roadway would be tertiary - it's just a simple connection between the roads and should likely not be considered tertiary. Especially given the guidance on the wiki *The highway http://wiki.openstreetmap.org/wiki/Key:highway=tertiary tag is used for roads connecting smaller settlements, and within large settlements for roads connecting local centres. In terms of the transportation network, OpenStreetMap tertiary roads commonly also connect minor streets to more major roads.* Here is another example along the same roadway in Montreal: Here we see a similar connection as before, but this one is designated as a residential road. But we also get to see a very interesting thing occur - the two one-way secondary roads suddenly transform into two tertiary one-way roads. The problem here is that there does not seem to be a reason for that changeover in the road type; the road continues as two one-way roads through the Parc industriel d'Anjou area. The position of the change also appears to be random or arbitrary. I'm seeking a bit of clarification. I like to be cautious with changing road types in regions just in case there is a reason I am not aware of for them to be designated in this way. Thanks, Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Road designations
Your example road looks like an edit in progress: someone changing the road from tertiary to secondary and leaving it unfinished. (Lord knows I've done that plenty of times: starting an edit, discovering it's *much* bigger or more complicated than I thought it was when I started it, and having to stop midway through and come back to it later -- sometimes much later.) Changing road types can be a messy process, especially when you're dealing with a CanVec import that breaks the road into individual segments at each intersection. In the first case, the connection should be a secondary_link, not a tertiary or tertiary_link, I think. In the second case, it would be appropriate to continue the edit, changing the rest of the road from one to the other, whichever you think is the best type for the road in question. The map is never in a finished state. On Thu, Dec 11, 2014 at 9:10 AM, Adam Martin s.adam.mar...@gmail.com wrote: I have a question for the group regarding the designation of various roads within city regions. Specifically, with reference to primary, secondary, and tertiary roads. What exactly is the criteria being used to designate a road as one or the other? I know that the wiki provides guidance, but it does not appear that the guidance is always followed. For example, this is an area inside Montreal: As you can see, there are two secondary one-way roads here (orange) and a yellow tertiary road connecting them together in the lower right. I cannot fathom why that roadway would be tertiary - it's just a simple connection between the roads and should likely not be considered tertiary. Especially given the guidance on the wiki *The highway http://wiki.openstreetmap.org/wiki/Key:highway=tertiary tag is used for roads connecting smaller settlements, and within large settlements for roads connecting local centres. In terms of the transportation network, OpenStreetMap tertiary roads commonly also connect minor streets to more major roads.* Here is another example along the same roadway in Montreal: Here we see a similar connection as before, but this one is designated as a residential road. But we also get to see a very interesting thing occur - the two one-way secondary roads suddenly transform into two tertiary one-way roads. The problem here is that there does not seem to be a reason for that changeover in the road type; the road continues as two one-way roads through the Parc industriel d'Anjou area. The position of the change also appears to be random or arbitrary. I'm seeking a bit of clarification. I like to be cautious with changing road types in regions just in case there is a reason I am not aware of for them to be designated in this way. Thanks, Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca -- Jonathan Crowe http://www.jonathancrowe.net ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Osmose Česká republika
No, tak jsem se na to díval a samozřejmě to není ani triviální a ani jednoznačné. Když je v RUIAN barák a AM na koleji na nádraží a podle fotek na místě žádná stopa baráku není, tak nevím, jestli by se neměl ponechat spíš ten z UIR :-(. Node 2757558529 (na kolejích, RUIAN) VS node 296787181, na baráku, ovšem podle RUIAN je na tom místě úplně jiná adresa. Je jich necelá tisícovka, http://pedro.poloha.net/osm/uir.csv (jak je u mě zvykem, odděleno svislítkem). Ještě jsou 2 s ref:ruian místo ref:ruian:addr, ty zatím nestojí za řeč. Sloupec je_poi říká, zda je UIR AM na POI; na ty mám zakázáno sahat ;-). Dne Út 9. prosince 2014 13:44:37, Petr Vejsada napsal(a): Ahoj, Dne Út 9. prosince 2014 08:19:03, Kasparek Tomas napsal(a): Ahoj, koukal jsem se na chybu Multiple numbers 841/8a in way Barvy, podle vseho jsou to stare adresy blbe umistene se zdrojem uir_adr. Petre, nestalo by za to zkusit to nejak automatizovane zpracovat - zatim co jsem videl, v podstate pri duplicite to co je uir_adr smazat, RUIAN zatim vzdy vypadal mnohem lepe (predevsim umistenim). nj, tohle je moc daleko - našel by to do, tuším, 80 metrů. POdívám se na to, pokud nezapomenu ;). -- Petr ___ 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: [Talk-cz] Osmose Česká republika
On Fri, Dec 12, 2014 at 04:06:24AM +0100, Petr Vejsada wrote: tak jsem se na to díval a samozřejmě to není ani triviální a ani jednoznačné. Když je v RUIAN barák a AM na koleji na nádraží a podle fotek na místě žádná stopa baráku není, tak nevím, jestli by se neměl ponechat spíš ten z UIR :-(. Node 2757558529 (na kolejích, RUIAN) VS node 296787181, na baráku, ovšem podle RUIAN je na tom místě úplně jiná adresa. Je jich necelá tisícovka, http://pedro.poloha.net/osm/uir.csv (jak je u mě zvykem, odděleno svislítkem). Ještě jsou 2 s ref:ruian místo ref:ruian:addr, ty zatím nestojí za řeč. Sloupec je_poi říká, zda je UIR AM na POI; na ty mám zakázáno sahat ;-). OK, diky za zpracovani, beru si to jako bojovy ukol nacelniku, zkusim se na to o vikendu podivat :-) -- Tomas Kasparek e-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kaspa...@jabber.cz Bozetechova 1, 612 66web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgpGnzvW5mlMC.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop?
Etienne Trimaille wrote
Au niveau de la requête, tu peux spécifier le format de sortie, dont CSV,
mais il faut spécifier les colonnes avant :
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29
Merci mais je ne sais pas trop comment modifier la requête construite par le
wizard pour obtenir les données en CSV:
http://postimg.org/image/4u33f2qfd/
Voici la requête:
===
[out:json][timeout:25];
// gather results
(
// query part for: “shop=bicycle”
node[shop=bicycle]({{bbox}});
way[shop=bicycle]({{bbox}});
relation[shop=bicycle]({{bbox}});
);
// print results
out body;
;
out skel qt;
===
Merci.
--
View this message in context:
http://gis.19327.n5.nabble.com/Envoyer-requetes-a-OSM-et-recuperer-bike-shop-tp5826779p5826902.html
Sent from the France mailing list archive at Nabble.com.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop?
En utilisant le wiki et la requête donnée, j'ai trouvé ça :
http://overpass-turbo.eu/s/6to
Il faut choisir les colonnes à mettre dans l'export CSV, et pour cela, je
ne peux pas deviner lesquelles sont utiles :)
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29
On Thu, Dec 11, 2014 at 10:33 AM, Shohreh codecompl...@free.fr wrote:
Etienne Trimaille wrote
Au niveau de la requête, tu peux spécifier le format de sortie, dont CSV,
mais il faut spécifier les colonnes avant :
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29
Merci mais je ne sais pas trop comment modifier la requête construite par
le
wizard pour obtenir les données en CSV:
http://postimg.org/image/4u33f2qfd/
Voici la requête:
===
[out:json][timeout:25];
// gather results
(
// query part for: shop=bicycle
node[shop=bicycle]({{bbox}});
way[shop=bicycle]({{bbox}});
relation[shop=bicycle]({{bbox}});
);
// print results
out body;
;
out skel qt;
===
Merci.
--
View this message in context:
http://gis.19327.n5.nabble.com/Envoyer-requetes-a-OSM-et-recuperer-bike-shop-tp5826779p5826902.html
Sent from the France mailing list archive at Nabble.com.
___
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: [OSM-talk-fr] fichier roads / champ : maxspeed incomplet
Bonjour, [living_street] = 10, en France c’est 30 Km/h Petite correction, c'est 20 km/h. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop?
Merci. Ça marche avec ça: [out:csv(::id, amenity, name, addr:housenumber,addr:street,addr:postcode,addr:city)] En revanche, on voit que la plupart ont juste le champ name rempli, donc moins utile que je ne pensais pour les contacter. -- View this message in context: http://gis.19327.n5.nabble.com/Envoyer-requetes-a-OSM-et-recuperer-bike-shop-tp5826779p5826916.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Bonjour, Le 10/12/2014 18:58, JB a écrit : 576721028K et 57672B077H... l'un génère un non rapprochement, l'autre est tout simplement ignoré. J'arrive pas à mettre la main sur le deuxième ? (Sinon, c'est pas exagéré de mettre un neighbourhood + highway avec le même nom ?) Ils sont homonymes, mais l'un en lieu-dit, l'autre en voie. Le rapprochement est actuellement sur le lieu-dit mais serait plus cohérent sur la voie. 152360150N et 152360018V même nom même type, l'un produit un rapprochement l'autre un non rapprochement... Pas mal ! J'aurais juste mis doublon pour celle qui n'a pas d'adresse et arrêté d'y penser… Après, un coup d'œil montrerait que l'orthographe est la même. (Ça rappelle des bons souvenirs, cette zone. J'ai dû y tracer quelques chemins !) J'ai ajouté l'item 'Voie doublon (même type et même nom)' pour ce cas, qui n'est pas isolé : j'en compte 7500 sur la totalité du Fantoir, dont une majorité de lieux-dits. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Fwd: Envoyer requêtes à OSM et récupérer bike=shop?
On 11 Dec 2014, at 10:33, Shohreh codecompl...@free.fr wrote:
Merci mais je ne sais pas trop comment modifier la requête construite par le
wizard pour obtenir les données en CSV:
La réponse était dans ce message que je croyais avoir envoyé à la liste, oups
From: Yves Pratter yves.prat...@gmail.com
Subject: Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop?
Date: 10 Dec 2014 11:38:52 CET
To: Marc Gemis marc.ge...@gmail.com
On 10 Dec 2014, at 09:22, Marc Gemis marc.ge...@gmail.com
mailto:marc.ge...@gmail.com wrote:
excusez-moi pour mon pouvre français…
Pas de problème, tu peux aussi écrire en anglais ;-)
Une example pour shop=bicycle à Anvers
dessous data . C'est quelque chose comme ça que vous voulez ?
Presque ;-)
Je pense qu’il a besoin d’une sortie en CSV…
http://overpass-turbo.eu/s/6sb http://overpass-turbo.eu/s/6sb
/*
This has been generated by the overpass-turbo wizard.
The original search was:
“shop=bike in Antwerpen”
*/
[out:csv( ::lat, ::lon, name, phone, addr:housenumber, addr:street,
addr:postcode, addr:city, website)][timeout:25];
// fetch area “Antwerpen” to search in
{{geocodeArea:Antwerpen}}-.searchArea;
// gather results
(
// query part for: “shop=bike”
node[shop=bicycle](area.searchArea);
way[shop=bicyle](area.searchArea);
relation[shop=bicyle](area.searchArea);
);
// print results
out body;
;
out skel qt;
Avec un résultat comme ça :
@lat @lonnamephone addr:housenumberaddr:street
addr:postcode addr:city website
51.20947944.4294467 Vélo co + 32 (0)3 298 95 88 124
Plantin en Moretuslei 2018Antwerpen http://www.velo-en-co.be/
http://www.velo-en-co.be/
51.21816044.3977965 De Ligfiets +32 3 293 74 56 23
Steenhouwersvest2000Antwerpen
http://www.ligfiets.be/index.php?selectie=deligfietsantwerpen
http://www.ligfiets.be/index.php?selectie=deligfietsantwerpen
51.19978584.4072691 iBike Antwerpen +32 3 257 56 95 215 Lange
Lozanastraat 2018Antwerpen
http://www.ibike.be/over-ibike/winkels1/ibike-antwerpen/
http://www.ibike.be/over-ibike/winkels1/ibike-antwerpen/
51.23287514.4238604 Odiel Odette +32 3 283 04 56 102
Viaduct-Dam 2060Antwerpen http://www.odielenodette.com/
http://www.odielenodette.com/
Après formatage ça devrait donner ça :
@lat @lonNom Téléphone N° Rue Code postal Ville
Site web
51.20947944.4294467 Vélo co + 32 (0)3 298 95 88 124
Plantin en Moretuslei 2018Antwerpen http://www.velo-en-co.be/
http://www.velo-en-co.be/
51.21816044.3977965 De Ligfiets +32 3 293 74 56 23
Steenhouwersvest2000Antwerpen
http://www.ligfiets.be/index.php?selectie=deligfietsantwerpen
http://www.ligfiets.be/index.php?selectie=deligfietsantwerpen
51.19978584.4072691 iBike Antwerpen +32 3 257 56 95 215 Lange
Lozanastraat 2018Antwerpen
http://www.ibike.be/over-ibike/winkels1/ibike-antwerpen/
http://www.ibike.be/over-ibike/winkels1/ibike-antwerpen/
51.23287514.4238604 Odiel Odette +32 3 283 04 56 102
Viaduct-Dam 2060Antwerpen http://www.odielenodette.com/
http://www.odielenodette.com/
Le problème, c’est pour les objets qui n’ont pas les champs addr:housenumber,
addr:street, addr:postcode, addr:city, il faut faire du géocodage inverse
avec nominatim
Il faut écrire un petit outil ou demander à Martin Raifer de rajouter ça à
Overpass :-)
—
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop?
On 11 Dec 2014, at 12:51, Shohreh codecompl...@free.fr wrote: En revanche, on voit que la plupart ont juste le champ name rempli, donc moins utile que je ne pensais pour les contacter. J’ai aussi envoyé une réponse, mais toujours pas à la liste : re oups ! Begin forwarded message: From: Yves Pratter yves.prat...@gmail.com Subject: Re: [OSM-talk-fr] Envoyer requêtes à OSM et récupérer bike=shop? Date: 10 Dec 2014 12:13:33 CET To: Marc Gemis marc.ge...@gmail.com On 10 Dec 2014, at 11:38, Yves Pratter yves.prat...@gmail.com wrote: Le problème, c’est pour les objets qui n’ont pas les champs addr:housenumber, addr:street, addr:postcode, addr:city, il faut faire du géocodage inverse avec nominatim Une requête pour une adresse connue, on retrouve évidemment la même : http://nominatim.openstreetmap.org/reverse?format=xmllat=51.2094794lon=4.4294467zoom=18addressdetails=1 reversegeocode timestamp=Wed, 10 Dec 14 10:54:27 + attribution=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyrightquerystring=format=xmllat=51.2094794lon=4.4294467zoom=18addressdetails=1; result place_id=41057642 osm_type=node osm_id=2978748155 ref=Vélo co lat=51.2094794 lon=4.4294467 Vélo co, 124, Plantin en Moretuslei, Zurenborg, Antwerpen, Antwerp, Flanders, 2018, Belgium /result addressparts bicycleVélo co/bicycle house_number124/house_number roadPlantin en Moretuslei/road neighbourhoodZurenborg/neighbourhood city_districtAntwerpen/city_district cityAntwerp/city countyAntwerp/county stateFlanders/state postcode2018/postcode countryBelgium/country country_codebe/country_code /addressparts /reversegeocode La même en français : http://nominatim.openstreetmap.org/reverse?format=xmllat=51.2094794lon=4.4294467zoom=18addressdetails=1accept-language=fr,en cityAnvers/city stateFlandre/state countryBelgique/country Et pour un magasin sans adresse (c’est plus intéressant) : reversegeocode timestamp=Wed, 10 Dec 14 11:03:16 + attribution=Data © OpenStreetMap contributors, ODbL 1.0. http://www.openstreetmap.org/copyrightquerystring=format=xmllat=51.2476754lon=4.4591991zoom=18addressdetails=1accept-language=fr,en; result place_id=11473420 osm_type=node osm_id=1107574324 ref=Schoten cyclo shop lat=51.2476754 lon=4.4591991 Schoten cyclo shop, Oudebareellei, Merksem, Anvers, Flandre, 2170, Belgique /result addressparts bicycleSchoten cyclo shop/bicycle roadOudebareellei/road city_districtMerksem/city_district cityAnvers/city countyAnvers/county stateFlandre/state postcode2170/postcode countryBelgique/country country_codebe/country_code /addressparts /reversegeocode Les pages jaune belges donnent : SCS Schoten cyclo shop Oudebareellei 120 2170 Anvers 0474 29 72 30 http://www.scsfietsen.be Et leur site web confirme l’adresse : 120, Oude Bareellei 2170 Merksem (pour nous les français) Tient, ils utilisent city_district Il ne reste plus qu’à rajouter les n° de rue dans OSM, le téléphone, adresse web… ;-) — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fichier roads / champ : maxspeed incomplet
Bonjour, Grace à vos documents, j'ai pu renseigner le champ speed de mon reseau routier pour plusieurs types de voies. Cependant, mon reseau routier contient des labels de types de voies non recensés dans vos documents. Voici la liste de ces types ci dessous : bridleway construction crossing cycleway disused footway path pedestrian platform raceway steps virtual -- Quel valeur de vitesse me conseilleriez vous de renseigner pour ces types de voie? Merci d'avance. -- View this message in context: http://gis.19327.n5.nabble.com/fichier-roads-champ-maxspeed-incomplet-tp5826810p5826924.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Sauf que dans que visiblement il n'y a pas de rapprochement sur le lieu dit du tout, même pas d'erreur, il n'apparait nulle part dans les 4 listes. Et la voie est affiché non rapproché, liste 3. Le 11 décembre 2014 13:52, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonjour, Le 10/12/2014 18:58, JB a écrit : 576721028K et 57672B077H... l'un génère un non rapprochement, l'autre est tout simplement ignoré. J'arrive pas à mettre la main sur le deuxième ? (Sinon, c'est pas exagéré de mettre un neighbourhood + highway avec le même nom ?) Ils sont homonymes, mais l'un en lieu-dit, l'autre en voie. Le rapprochement est actuellement sur le lieu-dit mais serait plus cohérent sur la voie. 152360150N et 152360018V même nom même type, l'un produit un rapprochement l'autre un non rapprochement... Pas mal ! J'aurais juste mis doublon pour celle qui n'a pas d'adresse et arrêté d'y penser… Après, un coup d'œil montrerait que l'orthographe est la même. (Ça rappelle des bons souvenirs, cette zone. J'ai dû y tracer quelques chemins !) J'ai ajouté l'item 'Voie doublon (même type et même nom)' pour ce cas, qui n'est pas isolé : j'en compte 7500 sur la totalité du Fantoir, dont une majorité de lieux-dits. vincent ___ 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: [OSM-talk-fr] fichier roads / champ : maxspeed incomplet
On 11 Dec 2014, at 15:11, image93 lcel...@cci-paris-idf.fr wrote: bridleway - chemin de randonnées à cheval construction - en construction crossing cycleway - réservé aux vélo (ça roule à combien 20 km/h ?) disused - plus en service footway - voie piétonne path - sentier de randonnée pedestrian - zone piétonne (je ne sais plus ;-) platform - plateforme d’un arrêt de bus par exemple raceway - circuit automobile, kart… piste d’athlétisme steps - escalier virtual - sert au routage mais n’existe pas physiquement Quel valeur de vitesse me conseilleriez vous de renseigner pour ces types de voie? Tu devrais t’en sortir avec ça, et il y a le wik et/ou taginfo ;-) — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fichier roads / champ : maxspeed incomplet
Ok super. Je vous remercie beaucoup. Le 11 décembre 2014 15:22, Yves Pratter-2 [via GIS] ml-node+s19327n5826926...@n5.nabble.com a écrit : On 11 Dec 2014, at 15:11, image93 [hidden email] http:///user/SendEmail.jtp?type=nodenode=5826926i=0 wrote: bridleway - chemin de randonnées à cheval construction - en construction crossing cycleway - réservé aux vélo (ça roule à combien 20 km/h ?) disused - plus en service footway - voie piétonne path - sentier de randonnée pedestrian - zone piétonne (je ne sais plus ;-) platform - plateforme d’un arrêt de bus par exemple raceway - circuit automobile, kart… piste d’athlétisme steps - escalier virtual - sert au routage mais n’existe pas physiquement Quel valeur de vitesse me conseilleriez vous de renseigner pour ces types de voie? Tu devrais t’en sortir avec ça, et il y a le wik et/ou taginfo ;-) — Yves ___ Talk-fr mailing list [hidden email] http:///user/SendEmail.jtp?type=nodenode=5826926i=1 https://lists.openstreetmap.org/listinfo/talk-fr -- If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/fichier-roads-champ-maxspeed-incomplet-tp5826810p5826926.html To unsubscribe from fichier roads / champ : maxspeed incomplet, click here http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=5826810code=bGNlbGF0aUBjY2ktcGFyaXMtaWRmLmZyfDU4MjY4MTB8LTE0Nzc1OTE1ODU= . NAML http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- *Laurent Celati* *Géomaticien, Pôle territoire économie aménagement mobilité * Département Projets de Territoires et Collectivités CCI Seine-Saint-Denis 191, avenue Paul Vaillant Couturier - 93005 Bobigny Cedex Tél. 01 48 95 10 72 - Fax. 01 48 95 11 58 -- Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à c...@cci-paris-idf.fr c...@ccip.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme privé, son contenu est sous la seule responsabilité de son auteur. -- View this message in context: http://gis.19327.n5.nabble.com/fichier-roads-champ-maxspeed-incomplet-tp5826810p5826928.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] fichier roads / champ : maxspeed incomplet
Pour highway=disused, limite à 0km/h on ne peut normalement pas avancer dessus c'est comme s'il n'y avait pas de route, juste de la déco... Mais normalement il devrait y avoir une barrière ou un obstacle. Ce tag n'est pas recommandé tel quel. Pour les raceways normalement ce devrait être un circuit fermé inaccessible au public sans limitation autre que le règlement spécifique de chaque course. Sinon c'est une route normale temporairement fermée pendant les courses et soumise au code normal et qui devrait utiliser un autre tag pour l'usage non temporaire. Si ce n'est pas le cas il devrait y avoir une limite explicite. Les steps ne sont pas faits pour vehicules, et les piétons ne sont pas sensés y courir et les engins roulants interdits sauf aménagement et signalisation spécifique pour usage sportif. Ce sont des escaliers. Pas de limite précise mais si tu veux estimer le temps de parcours prends 3 à 5km/h environ et pas plus... C'est déjà beaucoup aussi bien en montée qu'en descente pour ne pas se casser la figure et c'est encore moins si l'escalier est long en comptant les pauses. Les moteurs de routage pouf véhicules les ignore de toute façon. Les cycleways ont rarement des limites mais s'ils sont partages par les piétons la limite est celle de la marche et la prudence, pas plus de 7 km/h. C'est rare de voir une limite d'autant plus que les vélos n'ont pas de compteur de vitesse obligatoire. Même chose pour les bridleways (pour les chevaux et attelage équestres...) s'ils peuvent courir c'est un champ de course fermé et pas ce type de voie. partout ailleurs ce sont les autres usagers autorisés les plus lents voire immobiles qui déterminent la vitesse... Pas de limite précise donc. On voit donc que c'est en fonction de l'accessibilité qu'il faut se baser car les usagers non motorisés n'ont pas de compteurs et le plus petit reste prioritaire faute de protection. Pour les paths il n'y a généralement rien d'indiqué. C'est l'état du chemin qui de termine la vitesse mais on doit toujours s'attendre a y voir des pietons ou cyclistes au milieu. Le chemin est a éviter sauf en destination finale sinon il faut un véhicule adapté pour aller plus vite sans casser les suspensions et un savoir faire de pilote et rien ne garantie l'État de la piste ou l'absence d'ornières ou de trous et flaques même si c'est bien gravillons ou empierré au début. Plus loin cela n'est souvent qu'un chemin de terre. Si on ne peut pas passer ailleurs c'est une situation exceptionnelle on ne peut rien prévoir si on s'y engage et on devra peut-être faire marche arrière au pas sans pouvoir faire facilement demi-tour et rien ne garantie les conditions de visibilité ou de pente d'une vraie route ni même un gabarit standard suffisant pour pouvoir passer un véhicule ou braquer avec un véhicule long ou la tenue du terrain avec le poids. En pratique on s'intéresse aux limites sur les highways de type motorway, trunk, primary, secondary, tertiary, unclassified et (obsolète) road et les variantes en *_link, plus les résidential. Il y a aussi les highway=service soumis à réglementation spécifique mais si c'est ouvert c'est souvent juste une voie de parking en destination finale avec des piétons ou des accès de livraison ou vers des stations service. On y roule au pas sauf indication contraire souvent a 30 km/h environ. Ce n'est pas fait comme une voie de passage normal. Sinon ce sont des voies réservées pour bus avec leur signalisation spécifique a taguer explicitement et on n'a pas besoin de valeur par défaut (donc non limité réellement en vitesse absolue si rien n'est mis et l'accès n'est pas interdit). Comme ce n'est pas pour de longues distances pas la peine d'estimer le temps mais considérer la voie comme ayant une longueur nulle pour qu'elle soit partout le point de départ ou d'arrivée possible de l'itinéraire et ignorer la voie pour tout le reste comme si elle n'existait pas. Le 11 déc. 2014 15:12, image93 lcel...@cci-paris-idf.fr a écrit : Bonjour, Grace à vos documents, j'ai pu renseigner le champ speed de mon reseau routier pour plusieurs types de voies. Cependant, mon reseau routier contient des labels de types de voies non recensés dans vos documents. Voici la liste de ces types ci dessous : bridleway construction crossing cycleway disused footway path pedestrian platform raceway steps virtual -- Quel valeur de vitesse me conseilleriez vous de renseigner pour ces types de voie? Merci d'avance. -- View this message in context: http://gis.19327.n5.nabble.com/fichier-roads-champ-maxspeed-incomplet-tp5826810p5826924.html Sent from the France mailing list archive at Nabble.com. ___ 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
[OSM-talk-fr] Mise à jour majeure du rendu R25
Bonjour, Un petit message pour annoncer une nouvelle mise à jour majeure du petit rendu R25. Un an et demi après sa création et plus de six mois après la dernière mise à jour, voilà quelques nouveautés pour la V6. Pour ceux qui ne connaissent pas R25, il s'agit une feuille de style destinée à Maperitive qui produit un rendu topographique avec une surcouche touristique, un rendu qui rappelle celui auquel les randonneurs sont habitués en France, sans en être une copie. Des exemples, des tutoriels et les sources sont disponibles ici : http://osm107.openstreetmap.fr/jbtopo/ . Un usage grandeur nature en a été fait pour le topoguide du circuit de la Gaume Buissonnière, l'équivalent d'un GRP chez nos voisins Belges (http://gaumebuissonniere.host22.com/). Au menu de cette version, une part belle faite au « petit patrimoine » dans la surcouche touristique avec l'apparition, entres-autres, des éléments classés monuments historiques, des lavoirs, des chapelles, des œuvres d'art, des aqueducs, etc. Un marquage minimaliste des panneaux d'information. Également une amélioration de la lisibilité des points d'eau potable ou non et une meilleure distinction d'avec les châteaux d'eau et stations d'épuration ; l'assombrissement du rouge des voies privées (à force d'en avoir des retours… je ne sais pas si ce sera la dernière modification…) ; le rendu des murs d'enceinte de manière dissymétrique, et beaucoup de petits affinements du style et de la cohérence des données rendues. La légende mise à jour est visible ici : http://osm107.openstreetmap.fr/jbtopo/legende.png Les autres rendus sur la page de démonstration n'ont pas été régénéré. Si vous voulez voir ce que ça donnerait sur une zone précise, n'hésitez pas à demander. JB. PS-HS : Pour information, le créateur de Maperitive galère en ce moment à essayer de gérer l'application de la TVA du pays dans lequel est vendu un « produit internet », le financement de son activité géo étant principalement couvert par des ventes de cartes (ScalableMaps). L'évolution de Maperitive et d'Azurite (son successeur) est un peu ralentie depuis quelques semaines, mais des améliorations sont toujours prévues. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Le 10/12/2014 11:31, Vincent de Château-Thierry a écrit : J'ai des voies prévues qui sont dans FANTOIR, mais sur le terrain, elle ne sont pas encore construites (ni même en construction). Je ne veux pas mettre voie inexistante, sinon, elle risque être oublié un jour elles sont construites. Ce serait bien d'avoir un libellé pour justifier le fait qu'elles ne sont pas rapprochées !! Je n'avais jamais encore rencontré ce cas, où Fantoir anticipe à ce point. = je vais rajouter 'Voie pas encore construite' comme entrée dans les listes, car ça ne recouvre aucun des cas déjà connus. J'ai le cas sur deux communes : elles existent en avance sur le FANTOIR et dans le filaire de Toulouse Métropole (https://data.toulouse-metropole.fr/les-donnees/-/opendata/card/12693-filaire-de-voirie) mais pas encore sur le cadastre. Ces voies sont prévues dans une ZAC pour laquelle les nouvelles voies et les pavés constructibles ont été définis dès le départ, elle sont ensuite réalisées sur le terrain en fonction de l'avancement des lancements des ensembles immobiliers. 310560108YALL DE LA NESTE 310560001GRUE DE L'ADOUR 310690015RRUE ALCYONE 310690665XRUE MAIA 310690302CRUE ELECTRA 310690718ERUE DU NADIR 310691190TRUE DU ZENITH 310691066HRUE VEGA 310690016SRUE ANTARES 310690828ZRUE DES PLEIADES Lenny ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Le 11/12/2014 15:22, Tetsuo Shima a écrit : Sauf que dans que visiblement il n'y a pas de rapprochement sur le lieu dit du tout, même pas d'erreur, il n'apparait nulle part dans les 4 listes. Et la voie est affiché non rapproché, liste 3. Dans BANO toutes les adresses de la 'Boucle de la Ferme' sont rattachées au Fantoir du lieu-dit (57672B077H) et non à celui de la voie (576721028K). C'est le ref:FR:FANTOIR du node place=neighbourhood : https://www.openstreetmap.org/node/3214656990 chronologiquement rencontré en 1er, qui s'impose ici. Sachant qu'il concerne un lieu-dit, est qu'on est dans un traitement de rapprochement de voies, ça n'est pas cohérent, mais jusque là j'avais clairement laissé de côté le fait que l'on puisse trouver des Fantoir homonymes, mais de type différents (voie et lieu-dit) dans une commune. Je vais déplacer (mais pas ce soir) la prise en compte des Fantoir dépourvus de tag 'highway' (typiquement les nodes place=*) en fin de traitement, pour laisser leur chance prioritairement aux Fantoir associés à un highway. Et la logique devra être inversée pour le rapprochement des nodes place=*, où les Fantoir de lieux-dits seront à privilégier. Le ticket existe déjà : https://github.com/osm-fr/bano/issues/78 vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nominatim et les phrases spéciales : on comment trouver simplement (?) quelque chose dans OSM
Bonjour, On avait évoqué ce sujet en juin 2013 (à propose des gares SNCF). J’ai écrit un message en septembre 2013 qui est resté à l’état de brouillon. C’est gràce au ticket de Pierre Béland sur github Ability to search features similarly to Xapi https://github.com/twain47/Nominatim/issues/186 que j’ai recreusé la question. Et au passage j’ai « redécouvert » ce que j’avais formulé l’année passée ;D Comme il ne semble pas à l’ordre du jour de rajouter une syntaxe « [amenity=restaurant] » il me semble important de revoir ces phrases d’un point de vue francophone. L’erreur avait été de traduire trop fidèlement les phrases anglaises, ce qui produit un résultat inexploitable voir délétère. Des volontaires (et si possible pas que des français, il faut tenir compte des spécificités régionales) pour faire le ménage dans ce fichier ? Et aussi proposer des améliorations de code de Nominatim (car je ne vois pas comment on peut trouver uniquement une gare ferroviaire sans faire une recherche sur 2 tags). — Yves Le 7 juin 2013 à 16:06, Marc SIBERT m...@sibert.fr mailto:m...@sibert.fr a écrit : Si tu cherches une gare, c'est un lieu qui *a* un nom : lyon part-dieu et qui *est* une gare (en. station) essaie : [station] Lyon Part-Dieu http://tile.openstreetmap.fr/?q=[station]%20lyon%20part-dieu Je m'interrogeais à l'époque sur le manque de doc de la syntaxe [tag] et pour cause, elle n'existe pas ;-) En fait il suffit d'écrire en langage naturel : Gare ferroviaire près de Lyon Mais il y a plusieurs bémols : D'une façon générale, la traduction faite pour ces phrases spéciales est faite littéralement, terme par terme. Je m'explique : j'utiliserais plutôt : gare près de lyon, plutôt que gare ferroviaire… métro à paris, plutôt que Station de métro à…, plutôt que Bouche de métro à… fruits à… ou légumes à…, plutôt que Marchand de fruits et légumes à… … Il y a des erreurs de traductions : Cascade à la place de Source (tag natural=spring) l'intérêt/l'utilité de certaines phrases : Eau près de Annecy. La traduction du tag natural=water est correcte, mais je chercherais plutôt lac près de…, étang près de…, voir plan d'eau… Bordel, peut-être utile mais il y a probablement d'autres phrases à ajouter ou retraduire avant ;-) éboulis à … ? Est-ce que la recherche sur des tags synonymes fonctionne ? Cimetière à… amenity= grave_yard et landuse= cemetery xxx phrase pour un seul tag : pas suffisant, il faudrait rechercher une combinaison de tag (cf. station de métro ?) cas particuliers des gares sur Lyon : sort aussi les station de métro !! cas particulier des écluses , des ponts : lock_name et bridge_name pas indexés.___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] MAPS.ME proが本日無料
MAPS.ME liteの更新が来ていたので更新したら、MAPS.ME Pro が本日無料とのこと。 早速インストールしてみました。 地図も更新されているようです。2ヶ月ぶりくらいかな。 ribbon ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-ht] Rapo sou rankont ak kek manb nan kominote OSM ayiti
M’ta renmen pataje avek ou yon ti rapò sou rankont nou te genyen samdi 6 epi dimanch 7 desanm nan Haiti Communitere. 1e jounen an nou te pataje lide ansanm pou cheche yon definisyon inivèsèl sou OSM an Ayiti: “OSM se yon inisyativ ki kolaborativ,ouvè pou tout moun e ki benevol pou kreye yon kat mondyal.” Nou te vin mete nou dakò sou enpòtans kreye yon strikti pou tout kominote OSM nan ayiti ka kominike e kowòdone aksyon mapping nan peyi a. 2èm jou a, nou te monte diferan atelye ki tap reflechi sou divès sije tankou atelye estrikti, atelye kominikasyon e atelye mapping altènativ. Atelye Estrikti: Atelye sa te komanse brase lide sou kijan nou ka etabli yon estrikti anndan kominote a. Klike sou lyen sa https://docs.google.com/document/d/1oePrw-rjQ9T_6JZZ_g_YlHSZR1wdp184wwKxYTndwSc/edit?usp=sharing, wap jwenn yon dokiman ki gen kek repons. Ou menm ou ka komante e di kisa ki merite chanje e kisa nou dwe ajoute pou nou jwenn yon bon rezilta. Si ou gen yon lide pou kreye yon fowòm an liy pou debat sijè sa, fe nou konnen. Atelye mapping altènativ : Atelye sa te chita sou definisyon mapping altenativ yo te di: “Yon altènativ kolaborativ lokal pou anrichi baz done jewo-katografik pou yon devlopman dirab”. Nan refleksyon yo ,yo di tou ke nou dwe genyen yon metod ki mache ak reyalite nou pou nou fe katografi,konsa nap rive jwenn pi bon rezilta. Si sa enterese w pou w konnen plis e komante sou koze mapping altenativ la ale sou lyen sa https://docs.google.com/presentation/d/1mPJM47o8OJBeytxD7RfCJAEWDpgWUL-xUd9XWkaTqo4/edit?usp=sharing Atelye Kominikasyon: Nou te pale sou kijan nou ta dwe kominike ak yon manyè ki pi efikas a tout moun ki nan kominote OSM nan e sou kijan tou nou ka fe tout moun an Ayiti kom aletranje konnen nou e konnen travay ke nap fe sou Ayiti. Pou sa nou chita sou 2 kalite kominikasyon sa yo ki se:Kominikasyon enten e Kominikasyon eksten. Kominikasyon enten: - Nou pral toujou itilize talk.ht e voye sms - Nan atelye kominikasyon an ,nou te pale tou kijan moun ka itilize paj Whatsapp la si ou vle fe pati gwoup sa pou toujou kenbe enfòme sou aktivite osm nan ayiti voye nimewo ou (38990990). Nou te di paj Whatsapp la pa pou fe lot diskisyon ki pa enpotan pou kominote ayiti a. - Nou kreye yon Google drive pou tout moun ka we dokiman yo sou estrikti nou e kote nou pral mete tou kontak ak manm OSM, kontak medya, kontak patnè enstitisyonel Pou kominikasyon enten e eksten: a)Nou kreye yon paj facebook pou tout contributè an Ayiti ki Rele Communaute OSM Haiti. Pou paj Facebook la https://www.facebook.com/OSMAyiti Nou te di ou ka envite zanmiw pou like paj la pou kominote ya gen plis vizibilite. Pa ezite poste sou paj sa tout aktivite OSM – fok nou bay vizibilite nou! · Pou kominikasyon eksten: · blog https://communauteopenstreetmaphaiti.wordpress.com/ Se pa tout moun ka mete pos sou blog la, paske li enpòtan pou nou toujou verifye sa nou poste, paske li dwe kanpe pwofesionèl. Pou kounye a gen kek administratè men tout moun ki gen aktivite mapping ka montre lemond antye ke nou aktif, voye yon foto ak yon ti deskripsyon sou imel blog.osm.ha...@gmail.com pou ke nou ka poste’l pou ou. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
