[Talk-br] Ponte Laguna
A ponte de Laguna já é duplicada. Solicitei em vários Fóruns de gps que alguém gravasse um track, inclusive do novo túnel do Formigão, mas sem retorno até o momento. Flávio, obrigado pela ajuda com a relação da rodovia. Obrigado a todos pelas explicações do número de sala (addr). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
merci, c'est exactement ce que je cherchais (pour GraphHopper)! Julien Le 22/07/2015 16:01, Marc Gemis a écrit : Pour osrm, voir http://project-osrm.org/ Pour graphhopper: https://graphhopper.com/#contact m 2015-07-22 15:14 GMT+02:00 Julien Demade dem...@no-log.org mailto:dem...@no-log.org: Cela doit effectivement revenir à cela (je pencherai pour une vitesse moyenne trop haute): mais où sont ces réglages, à qui signaler le problème? Le 22/07/2015 13:22, Marc Gemis a écrit : Il y a plusieurs possibilités: 1) Ou les donnés des feux et des obstacles manque dans OSM 2) Ou les algorithmes ont des erreurs, e.g. la vitesse moyenne est trop haute. 3) ?? just my .5 cents m 2015-07-21 15:16 GMT+02:00 Julien Demade dem...@no-log.org mailto:dem...@no-log.org: Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit dehttp://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ca] Highway recoding
On 2015-07-22, at 10:39 AM, Daniel Begin jfd...@hotmail.com wrote: Since then, the document (a) is used by some contributors to recode primary roads to trunk because it is cited in the Canadian tagging guideline (c). IMHO, the problem is that this document (a) defines 3 Route Categories (Core, Feeder, Northern and Remote) that does not fit with OSM highway definitions. I prefer looking at OSM highway as “infrastructure categories” –my understanding of OSM definitions– rather than as “strategic categories” as described in (a) and partially promoted in (c). However, both are of interest as long they are applied consistently (d). In my opinion, the strategic category approach better fits the spirit of the British classification system that OSM highway tagging is based on. There is no regard whatsoever for access control there - I think there are even some controlled access secondary roads. It's the approach I've been using for my tagging in the Maritimes. I (and apparently others) have been using that National Highway System map to define trunk roads in the absence of any other Canadian equivalent to the British trunk system. Just my 2 cents…. JPK___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Potlatch 2 : une interface qui s'affiche par défaut sur OSM
Bonjour, Sans doute utilise-t-il Internet Explorer (quelle version ?). Le support d'iD n'est pas optimum pour toutes les versions du navigateur de Microsoft. Voir à utiliser Firefox, ou Chrome/Chromium. Bruno Le 22 juillet 2015 16:40, Pierre-Yves Berrard pierre.yves.berr...@gmail.com a écrit : Le 22 juillet 2015 16:34, Nicolas Cucchietti nicolas.cucchie...@cddpnr06.org a écrit : Donc ma question, si quelqu'un peut y répondre, c'est : *Savez-vous s'il y existe un moyen de régler le problème d'interface que je rencontre ? Si oui, comment ? Si non, alors existe-t-il un moyen de mettre l'interface Potlatch 2 en français par défaut ?* Merci d'avance à ceux qui pourront m'aider... je suis un peu perdu... Bonjour, Il faut configurer l'éditeur préféré dans les options d'osm : Monsieur le Maire doit aller sur son compte ( https://www.openstreetmap.org/user/[MonsieurLeMaire]/account) et choisir ID dans un des menus déroulants. Pierre-Yves ___ 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] Potlatch 2 : une interface qui s'affiche par défaut sur OSM
Bonjour Pierre-Yves et Bruno, Merci pour vos réponses. Vous avez certainement raison tous les deux raisons car le Maire a souhaité utiliser l'ordinateur de la mairie pour rentrer des données dans OSM : la mairie du village s'est créé son propre compte. Il me semblait bien avoir utilisé Internet Explorer pour me rendre sur OSM, je n'en connaissais pas la version et ne savais pas que iD-Editeur pouvait ne pas être optimisé pour les anciennes versions du navigateur de Microsoft... Par ailleurs, il est possible également que Potlatch 2 soit l'interface préféré du compte de la mairie, ce dont je n'ai pas prêté attention. Je contacterai sous peu la mairie pour vérifier si le problème est résolu. Merci encore ! Vous m'avez été d'une aide précieuse. Je vous tiens au courant des suites. *Nicolas Cucchietti* Stagiaire pour le Conseil de Développement du PNR des Préalpes d'Azur Tourisme Durable - Projet Itinérance ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] Ponte Laguna
Consultando outras fontes, ali a via a Via Expressa , verde estaria toda duplicada, agora precisa de track´s pra desenhar tudo ali, o Bing deve demorar pra atualizar tudo isso ali.. ___ Anor C. A. de Souza Concórdia SC 49-8866-3290 Claro49-8808-4963 Vivo49-9975-2560 Tim Date: Wed, 22 Jul 2015 12:39:14 -0300 From: hcto...@gmail.com To: talk-br@openstreetmap.org Subject: [Talk-br] Ponte Laguna A ponte de Laguna já é duplicada. Solicitei em vários Fóruns de gps que alguém gravasse um track, inclusive do novo túnel do Formigão, mas sem retorno até o momento. Flávio, obrigado pela ajuda com a relação da rodovia. Obrigado a todos pelas explicações do número de sala (addr). ___ 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-pt] Conduta errática de um utilizador
2015-07-22 14:22 GMT-03:00 Rui Oliveira racoqs...@gmail.com: O utilizador ddtuga voltou a fazer uma edição errada optando por não responder à segunda mensagem que lhe tinha enviado anteriormente Comente sempre nos changesets dele, que dá para todo mundo ver (e fica documentado que houve tentativa de contato). Do que eu olhei as edições, não são destrutivas. Talvez exista um pequeno descuido em algumas situações, mas não parece haver má intenção em nada. Se mesmo após várias tentativas ele não responder e continuar a gerar os mesmos erros, pode enviar uma mensagem ao DWG explicando a situação e pedindo um 0 hour block (é apenas uma forma de forçá-lo a ler a mensagem do DWG). ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [Talk-pt] Conduta errática de um utilizador
Eu acho que ele lê, mas não responde mesmo. Não sei te falar porque. Aqui sempre acontece a mesma coisa com alguns usuários. Tem situação que infelizmente só acaba sendo corrigida com a ajuda do DWG. O interessante é que mesmo após ver que a pessoa leu a mensagem do DWG, ela continua a não responder. Mas parece que começa a dar mais atenção no que está fazendo. ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[Talk-it] bridge AND embankment
Per caso ho scoperto che ci sono circa 300 casi in Norditalia di ways con bridge=* embankment=yes vedi: http://overpass-turbo.eu/s/axW Quando ho incontrato il primo caso ho pensato che si tratta di un errore per caso. Ma con 300 casi in Norditalia (e migliaia altrove) forse non è un errore, ma intenzione. Per mio avviso un way può essere o su un ponte (bridge=yes o qualche altro valore) o su un terrapieno (embankment), ma non entrambi. In casi dove un corso d'acqua passo sotto un way che è su embankment, si tratta di un buco nel terrapieno e non di un ponte (tagging: tunnel=yes|culvert del percorso d'acqua) Volker ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] bridge AND embankment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 22/07/2015 19:38, Volker Schmidt ha scritto: Per caso ho scoperto che ci sono circa 300 casi in Norditalia di ways con bridge=* embankment=yes vedi: http://overpass-turbo.eu/s/axW Quando ho incontrato il primo caso ho pensato che si tratta di un errore per caso. Ma con 300 casi in Norditalia (e migliaia altrove) forse non è un errore, ma intenzione. Per mio avviso un way può essere o su un ponte (bridge=yes o qualche altro valore) o su un terrapieno (embankment), ma non entrambi. In casi dove un corso d'acqua passo sotto un way che è su embankment, si tratta di un buco nel terrapieno e non di un ponte (tagging: tunnel=yes|culvert del percorso d'acqua) Volker Boh! Forse sono dei ponti fatti con terrapieno ed un tubo di diametro 1,5/2 metri passante. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVr9ZqAAoJEMTPIIVov0Zta8oH/RzjADwj9VOYbAWLBB/c0hqk M3UWDGHEeM04ZOP4WVKA9eQGj0f0QWIRGdgYjacHRX9R36E/6g4mJM5y3tYKcGPw KIKOFT+Ct7DwL9c4MVRf2QGOZz60R4vGgxb6PjX9rVqEcfZ5Arvs8pd00//aloA7 NrPvcM7z5x7nXjjIJyEs4msmU4hohRHQQUiWHvxUgar3MftsGvhW5s69G+q/Vn4+ 9pyew5i9u7oqxZLa75ZiJZY7X0E5aLNQFp0O0avxNs44cuEcxD6GrOW291g/cNFt u/KGskt3/fH1zXxcdU4+XArtSAqDtfm9eHqWJjKn8YqUy9l0HdOu2OxSw2ckpUY= =Rii9 -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] bridge AND embankment
Direi sono tutti da correggere. Purtroppo è un bel lavoretto: 400+ in Italia 200+ in GB 600 in Germania 250 in Francia 100 in Spagna 170 in Scandinavia e Paesi Baltici 130 negli USA Non si può fare in modo automatico. I casi sono troppo variegati. Porterò il problema alla lista tagging internazionale. Volker ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-pt] Conduta errática de um utilizador
Francisco, Penso que esse caso da rotunda não é porque é para peões mas sim uma tentativa de pintar a borda da rotunda. Aqui está o multipolígono. [1] Já vi casos assim, em especial na baixa do Porto onde isto é muito comum encontrar passeios ou simplesmente áreas onde não percorram veículos com highway=pedestrian. [2] [1] - http://www.openstreetmap.org/relation/5384913 [2] - http://www.openstreetmap.org/way/210822943 No dia 22 de julho de 2015 às 19:48, f.dos.san...@free.fr escreveu: Rui, As nossas mensagens cruzaram-se, vamos la insistir para que ele responde. Também o que pode acontecer é que ele não consulta a sua caixa email, pouco provável dado que usa um editor online obrigando identificar-se. Ou talvez a barreira da língua : é capaz ser um emigrante vejo que há edições nos EUA. O uso do Potlatch 2 também pode estar condicionado a sua plataforma/navegador web, o iD não esta disponível dependente das versões. Vou verificando alguns dos outros changeset, há outras coisas estranhas, parece-me pouco provável que os peões circulam dentro da rotunda : - http://www.openstreetmap.org/way/361744172 Francisco ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt -- Um Abraço, Marcos Oliveira ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [Talk-it] bridge AND embankment
22.07.2015 - 20:52 - Martin Koppenhoefer: Am 22.07.2015 um 19:38 schrieb Volker Schmidt vosc...@gmail.com: Per mio avviso un way può essere o su un ponte (bridge=yes o qualche altro valore) o su un terrapieno (embankment), ma non entrambi. +1 ciao, Martin +1 GLi embankment possono esserci prima e dopo il ponte ma non assieme al ponte. Direi sono tutti da correggere. Ciao Damjan ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ca] Highway recoding
Thank Tristan for your suggestions concerning the documentation. I agree that there's so much that needs to be added to the map that I don't see tinkering with highway classifications as a priority. That is why clarifying definition is necessary since some users are currently tinkering with trunk/primary tagging. I am not comfortable with using the strategic categories approach for trunk since it implies we will find very different road types when looking at them around Toronto or in Yukon, while all lower classes will probably look very similar wherever you are. Contrarily to JPK, I did not find any strong relationship between UK strategic road classification (e) and OSM (f). However, the important point is to agree on the definitions and have them clearly state in the wiki. So far, I understand we have 2.5 votes for tagging trunk/motorway all roads identified as core route in document (a); 0.5 against (I am still torn between the two approaches!-) More comments would be appreciated Daniel a) http://www.comt.ca/english/NHS-report-english.pdf e) https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/31 5783/road-classification-guidance.pdf f) http://wiki.openstreetmap.org/wiki/Key:highway From: Tristan Anderson [mailto:andersontris...@hotmail.com] Sent: July-22-15 13:17 To: Daniel Begin; talk-ca@openstreetmap.org Subject: RE: [Talk-ca] Highway recoding As I've always understood it, highway=trunk is used for core routes in document (a) that Daniel mentioned. It ignores routes marked as feeder and northern/remote. highway=primary is for each province's network of primary highways that aren't motorways or trunks. I don't exactly agree with the above definitions but they were already in place when I got here so I've been using them. For one thing, document (a) was published in 2005, and things change. I'm also not entirely comfortable with the fact that the most a city-maintained road could ever hope for is secondary. Toronto's Black Creek Drive should, in my mind at least, have a higher classification than Highway 108 north of Elliot Lake. In general, OSM higways should be based on how important they are to the overall road network, independent of any official classification. On the other hand... I kinda like the way Canadian cities look with their simple networks of orange thoroughfares. London, Paris and Washington are an incomprehensible mess of roads with varying classifications which don't seem to be of benefit to the end user. The eight-level hierarchy of highway classifications OSM gives us to work with is overkill. At least Canada is consistent, which is more than can be said for a lot of countries. Plus there's so much that needs to be added to the map that I don't see tinkering with highway classifications as a priority. So here's what I suggest: the definitions above are good guidelines but need not be followed religiously. If anyone thinks a specific road should be promoted or demoted, let's discuss it here and make it happen. As for the wiki pages. In (b), Canada is listed twice. I think the entire lower row can be deleted and the upper row still stands. Maybe a note could be added saying there is some flexibility to the trunk/primary guidelines. In (c), the section on trunk roads should be changed. Trunk roads do not need to be limited access. Most of them are not. I also don't think people should be told to tag anything surface=paved/unpaved. Instead surface should be whatever it is (asphalt, concrete, gravel, etc). The Sub-national and below section needs to be rewritten or copied over from (b). And now you have my two cents too. Comments? _ From: jfd...@hotmail.com To: talk-ca@openstreetmap.org Date: Wed, 22 Jul 2015 09:39:28 -0400 Subject: [Talk-ca] Highway recoding I would like to have community's point of view on this topic. Recently I have seen most primary roads in my area being recoded as trunk by at least two users. They both refer to a governmental document (a) to justify their edits but I disagree with their interpretation. I have asked them to discuss their interpretation with the OSM community but they did not; so let's do it I thought there was an agreement on highway tagging scheme in which provincial primary highway that does not meet freeway standards should be identified as primary road, as described in Highway:International equivalence (b). For instance provincial highways 2-14 in Ontario, 100-series highways in Quebec, Highway 95 in BC were initially tagged as primary road. Since then, the document (a) is used by some contributors to recode primary roads to trunk because it is cited in the Canadian tagging guideline (c). IMHO, the problem is that this document (a) defines 3 Route Categories (Core, Feeder, Northern and Remote) that does not fit with OSM highway definitions. I prefer looking at OSM highway as infrastructure categories -my
Re: [OSM-talk] Antennas and radio networks supports mapping
Op 15 jul. 2015, om 14:15 heeft Dave Stanley da...@dbsconsult.co.uk het volgende geschreven: As for the antennas mounted on a mast/tower, you then may need to consider the frequencies and operators that use the antennas. In some cases there will be multiple frequencies and operators. Physically, you would need the antenna height above ground level, direction, possibly which leg it is on and so on. In the Netherlands we are facing the same problem with our GSM antenna’s. Our country has the highest density of mapped GSM antenna’s (currently over 11.000) and you should see the worldwide mapping of the GSM 900 frequency: https://dl.dropboxusercontent.com/u/17226226/OSM/gsm/gsm900-wereldwijd.png We are using two solutions for mapping multiple antenna’s on one post: 1. Use technology=GSM 900;GSM 1800;UMTS Together with height=50;68;57 Or 2. technology:1=GSM 900 technology:2=GSM 1800 technology:3=UMTS height:1=50 height:2=68 height:3=57 An example of this last style is here: https://www.openstreetmap.org/node/599560623 https://www.openstreetmap.org/node/599560623 Try to avoid using man_made=tower for structures that are definitely NOT a tower. And use mast:type instead of tower:type. In an upcoming change of the carto style for the standard rendering, all man_made=tower will be shown and this will lead to an overflow of towers on the base map if you are using the wrong tagging. See my earlier post. Marc. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] Highway recoding
As I've always understood it, highway=trunk is used for core routes in document (a) that Daniel mentioned. It ignores routes marked as feeder and northern/remote. highway=primary is for each province's network of primary highways that aren't motorways or trunks. I don't exactly agree with the above definitions but they were already in place when I got here so I've been using them. For one thing, document (a) was published in 2005, and things change. I'm also not entirely comfortable with the fact that the most a city-maintained road could ever hope for is secondary. Toronto's Black Creek Drive should, in my mind at least, have a higher classification than Highway 108 north of Elliot Lake. In general, OSM higways should be based on how important they are to the overall road network, independent of any official classification. On the other hand... I kinda like the way Canadian cities look with their simple networks of orange thoroughfares. London, Paris and Washington are an incomprehensible mess of roads with varying classifications which don't seem to be of benefit to the end user. The eight-level hierarchy of highway classifications OSM gives us to work with is overkill. At least Canada is consistent, which is more than can be said for a lot of countries. Plus there's so much that needs to be added to the map that I don't see tinkering with highway classifications as a priority. So here's what I suggest: the definitions above are good guidelines but need not be followed religiously. If anyone thinks a specific road should be promoted or demoted, let's discuss it here and make it happen. As for the wiki pages. In (b), Canada is listed twice. I think the entire lower row can be deleted and the upper row still stands. Maybe a note could be added saying there is some flexibility to the trunk/primary guidelines. In (c), the section on trunk roads should be changed. Trunk roads do not need to be limited access. Most of them are not. I also don't think people should be told to tag anything surface=paved/unpaved. Instead surface should be whatever it is (asphalt, concrete, gravel, etc). The Sub-national and below section needs to be rewritten or copied over from (b). And now you have my two cents too. Comments? From: jfd...@hotmail.com To: talk-ca@openstreetmap.org Date: Wed, 22 Jul 2015 09:39:28 -0400 Subject: [Talk-ca] Highway recoding I would like to have community’s point of view on this topic… Recently I have seen most primary roads in my area being recoded as trunk by at least two users. They both refer to a governmental document (a) to justify their edits but I disagree with their interpretation. I have asked them to discuss their interpretation with the OSM community but they did not; so let’s do it I thought there was an agreement on highway tagging scheme in which provincial primary highway that does not meet freeway standards should be identified as primary road, as described in Highway:International equivalence (b). For instance provincial highways 2-14 in Ontario, 100-series highways in Quebec, Highway 95 in BC were initially tagged as primary road. Since then, the document (a) is used by some contributors to recode primary roads to trunk because it is cited in the Canadian tagging guideline (c). IMHO, the problem is that this document (a) defines 3 Route Categories (Core, Feeder, Northern and Remote) that does not fit with OSM highway definitions. I prefer looking at OSM highway as “infrastructure categories” –my understanding of OSM definitions– rather than as “strategic categories” as described in (a) and partially promoted in (c). However, both are of interest as long they are applied consistently (d). I would like to get a consensus from the Canadian community on trunk/primary roads tagging scheme and eventually clarify available documentation (b, c) accordingly. I might also add Tristan Anderson definitions on forestry roads (talk-ca 15-07-15). Comments are obviously welcome J Daniel a) http://www.comt.ca/english/NHS-report-english.pdfb) http://wiki.openstreetmap.org/wiki/Highway:International_equivalencec) http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelinesd) The Canadian tagging guideline defines trunk as a roadway that has limited access; while OSM Features (wiki) defines trunk as “high performance roads that don't meet the requirement for motorway” which means there is no/little access limitations! ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-pt] Conduta errática de um utilizador
O utilizador ddtuga voltou a fazer uma edição errada optando por não responder à segunda mensagem que lhe tinha enviado anteriormente https://www.openstreetmap.org/changeset/32804919#map=17/38.63427/-9.10626 A seguinte ligação https://www.openstreetmap.org/way/169205373 Tem uma via desligada da rotunda... Depois de lhe ter proposto o editor iD, voltou a usar o Potlatch2 Devido a o utilizador se recusar a responder à minha segunda mensagem, devemos começar a ponderar se devemos ou não considerar este caso vandalismo (não no tradicional, mas noutro aspecto em que o utilizador ignora os reparos e continua a editar menosprezando todas as regras). 2015-07-22 15:28 GMT+01:00 Rui Oliveira racoqs...@gmail.com: Outra via desligada de sesimbra da autoria do mesmo utilizador entretanto corrigida por mim https://www.openstreetmap.org/way/23147929#map=19/38.44192/-9.09702 Original em imagem em anexo: 2015-07-22 0:04 GMT+01:00 f.dos.san...@free.fr: Concordo. Na mesma zona outro caso de 2 ways que se cruzam sem nó em comum : http://www.openstreetmap.org/way/354349615 http://www.openstreetmap.org/way/354349617 Acho que é fazer complicado por pouca coisa : um total de 4 ways pour uma secção de 50 metros donde o asfalto é só um ... Darei uma ajuda com os outros changeset amanhã. Francisco - Mail original - From: Rui Oliveira racoqs...@gmail.com To: OSM Portugal talk-pt@openstreetmap.org Date: 22/07/2015 00:22:44 Subject: Re: [Talk-pt] Conduta errática de um utilizador Bom Acho sinceramente que era bom organizarmos todos um esforço para rever uma boa parte dos edits do utilizador ddtuga. O utilizador editou esta zona massiva e de grande tráfego de lisboa: http://www.openstreetmap.org/changeset/32036136 Se reparerem uma grande maioria das vias convergem numa só via ao mesmo nível ou se intersectam. E no caso das vias no OSM todas as que se cruzam (exceptuando pontes e tuneis), devem estabelecer uma intersecção por pelo menos um ponto. Aqui está um exemplo errado no mesmo edit: http://www.openstreetmap.org/way/354345472#map=19/38.74723/-9.11852 No link anterior, a ligação da avenida da ucrânia devia estabelecer uma intersecção com a primeira via da avenida salgadnho zenha até intersectar a segunda via. Mas se editarem com mais atenção poderão ver que só intersecta na última via. outro exemplo: http://www.openstreetmap.org/way/353908596#map=19/38.74979/-9.11892layers=D A via assinalada que começa na avenida cidade de bratislava e vai ligar até à avenida Francisco salgado zenha devia intersectar todas as vias sobre a qual se cruza e não acontece. 2015-07-21 22:46 GMT+01:00 Rui Oliveira racoqs...@gmail.com : Bem, tive a ver os últimos edits e parece que este utilizador deixa vias desligadas de forma ocasional, a juntar aos anteriores, aproveito para reportar que o changeset 28917934 relativo a uma edição do mesmo perto de sesimbra tambem tem uma via desligada http://www.openstreetmap.org/changeset/28917934 Vou corrigir este. em anexo para futuras referencias anexo a imagem tirada. 2015-07-21 21:58 GMT+01:00 f.dos.san...@free.fr : Olá, Olhei com atenção para o changeset 32765923, houve alguns erros más o conteúdo é bom. A geometria das estradas foi melhorada : gosto mesmo da maneira que as estradas fazem curva (mais nós na estrada, melhora fica a curva). Os 3 grandes erros que podem ver nas imagens .PNG em anexo são : 1) Via sozinha, provavelmente por causo do erro 3) um way ficou sem ligação a rede. Erro que salto aos olhos e que o Rui descobriu. - http://www.openstreetmap.org/way/142465228 2) Duplo via a direita, também por causo do erro 3) temos agora 2 ways para virar a direita - http://www.openstreetmap.org/way/361488409 3) Faixa de rodagem feito como um way separado. - http://www.openstreetmap.org/way/361488408 Aqui temos uma má prática : desenhar um way quando se trata de uma faixa de rodagem. Só devemos desenhar way separados quando há realmente uma separação física. Aqui só temos uma avenida única com 4 faixas de rodagem : - http://www.openstreetmap.org/way/337119731 Para descrever as faixas de rodagem temos as chaves lanes : - http://wiki.openstreetmap.org/wiki/Lanes Vou então corrigir esses erros, ficam as imagens se alguém quer referir aos objetos de origem. Francisco ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org
Re: [Talk-ca] Highway recoding
On 7/22/2015 11:43 AM, Daniel Begin wrote: So far, I understand we have 2.5 votes for tagging trunk/motorway all roads identified as “core route” in document (a); 0.5 against (I am still torn between the two approaches!-) More comments would be appreciated Such an approach would be inconsistent with how highways are tagged in BC and expectations of locals. It would also make BC quite different than across the boarder in Washington. I can think of several motorways and trunk roads which are not on the list in the PDF, and many of the roads on the list are primary, or in at least one case, secondary. Some of the roads not on the list are more important in the transportation network than ones on it. The criteria being proposed are also inherently unverifiable. We map the world, not what a government database says. What about new roads? There's a new route that's opened up, and it's a mix of trunk and motorway, but it's not listed in the NHS report. To tag it primary when less significant roads constructed to a lower standard are tagged as trunk and motorway would be absurd. Because it has a lot of freight, it probably will become a NHS road at some point. Does its classification magically change when nothing has changed on the ground? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-it] Editor ID e ortofoto PCN
PCN non consente l'impiego di un proxy che crea tiles e li distribuisce
Whoots [1] potrebbe essere una soluzione: (è un tipo di proxy, ma non
distribuisce dei tile)
http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/OI.ORTOIMMAGINI.2006.32,OI.ORTOIMMAGINI.2006.33/http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/ortofoto_colore_06.map
[1] http://whoots.mapwarper.net/
2015-07-21 9:09 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com:
sent from a phone
Am 21.07.2015 um 08:59 schrieb Volker Schmidt vosc...@gmail.com:
Probabilmente discusso qua già mille volte: le ortofoto PCN si possono
utilizzare, al livello tecnico, con ID?
no, iD non legge WMS e PCN non consente l'impiego di un proxy che crea tiles
e li distribuisce (credo, l'aveva fatto Luca D. e lo hanno imbruttito).
ciao
Martin
___
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-cz] mapa s popisky
zdravíčko, chtěl bych si udělat mapku výletu, poradí někdo prosím nějaký jednoduchý udělátor, kde by si šlo různě označit cesty a body, resp. přidat vlastní, a napsat k tomu legendu? obtahovat čáry na obrázku v GIMPu apod. se mi tak úplně nechce :-) K. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-it] Editor ID e ortofoto PCN
sent from a phone
Am 22.07.2015 um 09:32 schrieb Martin Raifer tyr@gmail.com:
Whoots [1] potrebbe essere una soluzione: (è un tipo di proxy, ma non
distribuisce dei tile)
http://whoots.mapwarper.net:80/tms/{z}/{x}/{y}/OI.ORTOIMMAGINI.2006.32,OI.ORTOIMMAGINI.2006.33/http://wms.pcn.minambiente.it/ogc?map=/ms_ogc/WMS_v1.3/raster/ortofoto_colore_06.map
[1] http://whoots.mapwarper.net/
molto bello. Per farlo funzionare dovremmo probabilmente comunque convincere il
PCN di collaborare: Se ricordo bene bloccano dopo un po' gli IP che accedono
troppo
ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] Looking for well mapped rural area and well mapped town/city
On Mon, Jul 20, 2015 at 12:04 PM, Mateusz Konieczny matkoni...@gmail.com wrote: I am looking for well mapped rural area. I located some places but all are either missing major features (like part of landuse) or quality of mapping (especially landuses) is poor. I am interested in places mapped better than my current test locations maybe relevant: http://bestofosm.org/ -- -S ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Looking for well mapped rural area and well mapped town/city
I can recommend most of East Yorkshire in the UK http://www.openstreetmap.org/#map=13/53.8689/-0.6582. It's very well mapped, most fields are traced, landuse, buildings, etc.. Tony On 22 July 2015 at 10:30, Simone Cortesi sim...@cortesi.com wrote: On Mon, Jul 20, 2015 at 12:04 PM, Mateusz Konieczny matkoni...@gmail.com wrote: I am looking for well mapped rural area. I located some places but all are either missing major features (like part of landuse) or quality of mapping (especially landuses) is poor. I am interested in places mapped better than my current test locations maybe relevant: http://bestofosm.org/ -- -S ___ 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-br] RES: Ajuda para responder dúvidas de usuários novos
Ok, aguardo. Abraço. 2015-07-21 21:56 GMT-03:00, Nelson A. de Oliveira nao...@gmail.com: Reinaldo, Claiton, agradeço a disposição de vocês! Vou entrar em contato com vocês depois sobre isso. Abraço! ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Atenciosamente, Claiton Neisse 55 8147 1030 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
A y réfléchir, il est même probable qu'un cycliste occasionnel préférera un itinéraire plus direct avec des pauses plus ou moins forcées et qu'un vélotafeur préférera un itinéraire plus long mais avec moins de pauses... d'où au final un gain de temps quitte à pédaler un peu plus. Tout dépend en fait de la priorité qu'on donne au temps et aux efforts voire à la sécurité. Les meilleurs calculateurs permettent de choisir entre ces 3 critères, mais comme toujours pour que les calculs soient pertinents, il faut beaucoup un haut niveau de détails dans les données. Le 21/07/2015 18:36, Julien Demade a écrit : Bonjour La durée d'un parcours à vélo dépend avant tout du cycliste lorsqu'il n'y a pas d'obstacles à une progression continue. En ville, on s'arrête tous les 100m (feux, croisements, passages piétons, etc.), ce qui lisse énormément les temps de parcours (c'est aussi ce qui explique qu'on aille souvent aussi vite à vélo qu'en voiture). Généralement tout le monde se retrouve au feu. Julien Le 21/07/2015 17:49, Jean-Claude Repetto a écrit : Le 21/07/2015 17:33, Julien Demade a écrit : Pour Christian: je ne dis rien des itinéraires, qui sont pas mals (il y a de toute façon généralement beaucoup de possibilités correctes, et l'avantage d'ailleurs d'avoir deux solutions de routage est de rendre sensible au fait qu'il n'y a pas une et une seule bonne solution); quant aux durées, si elles ne sont vraiment pas fiables (on est quand même dans du 40% de marge d'erreur...), il ne paraît pas pertinent de les indiquer (de même qu'il ne paraîtrait pas pertinent d'indiquer des itinéraires non fiables). Encore une fois: 40% d'erreur, on n'est pas dans l'ordre du détail. Et je suppose que cela vaut pour toutes les zones urbaines? Bonjour, Je ne suis pas cycliste, et encore moins Parisien, mais je suis très étonné par ta question. Il me semble que la durée d'un parcours en vélo dépend en premier lieu du cycliste lui-même. Entre un sportif de 20 ans et un retraité de 70 ans, la durée doit bien varier du simple au double, sinon plus ? Donc le logiciel de calcul doit forcément pouvoir être paramétré en fonction des possibilités physiques du cycliste. 40% de différence, c'est négligeable ... Jean-Claude ___ 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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSRM-talk] U-turns in Map-Matching Algorithm
Hi all, looking at the code in plugins/match.hpp [1], I noticed that candidates resulting in a U-turn are allowed but wouldn't you say that these candidates are actually pretty unlikely compared to candidates that don't result in a U-turn? Am I missing something here? Thanks. Best, Matthias [1] https://github.com/Project-OSRM/osrm-backend/blob/master/plugins/match.hpp#L104 -- Matthias Schwamborn University of Osnabrück Tel.: +49-541-969-7167 Institute of Computer Science Fax:+49-541-969-2799 Albrechtstr. 28 E-mail: schwamb...@informatik.uos.de D-49076 Osnabrück, Germany http://cs.uos.de/schwamborn/ signature.asc Description: OpenPGP digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Il y a plusieurs possibilités: 1) Ou les donnés des feux et des obstacles manque dans OSM 2) Ou les algorithmes ont des erreurs, e.g. la vitesse moyenne est trop haute. 3) ?? just my .5 cents m 2015-07-21 15:16 GMT+02:00 Julien Demade dem...@no-log.org: Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit de http://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ 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-cz] mapa s popisky
2015-07-22 10:48 GMT+02:00 Karel Volný ka...@seznam.cz: zdravíčko, chtěl bych si udělat mapku výletu, poradí někdo prosím nějaký jednoduchý udělátor, kde by si šlo různě označit cesty a body, resp. přidat vlastní, a napsat k tomu legendu? obtahovat čáry na obrázku v GIMPu apod. se mi tak úplně nechce :-) K. Tak, zcela jistě by takovou věc šlo naprogramovat v Leafletu nebo OpenLayers... P. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Cela doit effectivement revenir à cela (je pencherai pour une vitesse moyenne trop haute): mais où sont ces réglages, à qui signaler le problème? Le 22/07/2015 13:22, Marc Gemis a écrit : Il y a plusieurs possibilités: 1) Ou les donnés des feux et des obstacles manque dans OSM 2) Ou les algorithmes ont des erreurs, e.g. la vitesse moyenne est trop haute. 3) ?? just my .5 cents m 2015-07-21 15:16 GMT+02:00 Julien Demade dem...@no-log.org mailto:dem...@no-log.org: Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit dehttp://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto: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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-ca] Highway recoding
I would like to have community's point of view on this topic. Recently I have seen most primary roads in my area being recoded as trunk by at least two users. They both refer to a governmental document (a) to justify their edits but I disagree with their interpretation. I have asked them to discuss their interpretation with the OSM community but they did not; so let's do it I thought there was an agreement on highway tagging scheme in which provincial primary highway that does not meet freeway standards should be identified as primary road, as described in Highway:International equivalence (b). For instance provincial highways 2-14 in Ontario, 100-series highways in Quebec, Highway 95 in BC were initially tagged as primary road. Since then, the document (a) is used by some contributors to recode primary roads to trunk because it is cited in the Canadian tagging guideline (c). IMHO, the problem is that this document (a) defines 3 Route Categories (Core, Feeder, Northern and Remote) that does not fit with OSM highway definitions. I prefer looking at OSM highway as infrastructure categories -my understanding of OSM definitions- rather than as strategic categories as described in (a) and partially promoted in (c). However, both are of interest as long they are applied consistently (d). I would like to get a consensus from the Canadian community on trunk/primary roads tagging scheme and eventually clarify available documentation (b, c) accordingly. I might also add Tristan Anderson definitions on forestry roads (talk-ca 15-07-15). Comments are obviously welcome J Daniel a) http://www.comt.ca/english/NHS-report-english.pdf b) http://wiki.openstreetmap.org/wiki/Highway:International_equivalence c) http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines d) The Canadian tagging guideline defines trunk as a roadway that has limited access; while OSM Features (wiki) defines trunk as high performance roads that don't meet the requirement for motorway which means there is no/little access limitations! ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Après un regard d'un peu plus près, les emplacements semblent correspondre assez bien avec l'imagerie, j'ai vu des écarts jusqu'à 5m, mais globalement bien en dessous. Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure, montrer qu'on sait bien importer, j'ai du mal à voir à quoi ça sert… Pour moi, si on perd le coté humain de la base de données (comprenez, un humain peut modifier les données), on a tout perdu. JB. Le 22/07/2015 00:43, Vincent Frison a écrit : Le 21 juillet 2015 22:00, Vincent Frison vincent.fri...@gmail.com mailto:vincent.fri...@gmail.com a écrit : Je ferai aussi quelques tests en variant le rayon, je vous tiendrai au courant des résultats... Avec un rayon de 2 mètres : Total of created trees: 29947 Total of updated trees: 574 Total of multi matching trees: 28 Avec un rayon de 5 mètres : Total of created trees: 29767 Total of updated trees: 754 Total of multi matching trees: 281 Maintenant je met à jour les éléments existants au lieu de les effacer. La mise à jour consiste à mettre la même position (la même que l'arbre importé) et de rajouter un tag ref:FR:Nice:trees=* avec l'identifiant de leur jeu de données. Par contre la gestion des multi matching trees (ie. les arbres existant qui matchent plus qu'un seul arbre importé) est très basique puisque je met à jour l'élément avec les valeurs du 1er arbre importé tout simplement (pour les autres éléments importés je créé donc un nouvel élément). Mais bon, avec un rayon de 2 mètres ça ne concerne moins d'1/1000e des arbres.. et surtout je rappelle qu'en plus on parle de décalages inférieurs à 2 mètres donc bon je pense que c'est tolérable. Et du coup je pense qu'il faut garder un rayon faible comme 2 mètres. Au niveau des 1188 arbres visibles sur Overpass il faut voir que: - certains arbres municipaux ne sont pas référencés - certains arbres existants ne sont pas des arbres municipaux - certains arbres existants peuvent être municipaux (et référencés) mais éventuellement trop mal positionnés (et dans ce cas là je pourrai pas faire grand chose) Mais effectivement je vais devoir creuser un peu pour mieux comprendre ;) ___ 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-cz] LPIS a fence=no
2015-07-21 23:03 GMT+02:00 Pavel Machek pa...@ucw.cz: Kdyz tam plot vidim, je to jednoduche, pridam do mapy barrier=fence. Ale i to ze tam plot neni je dulezita informace, protoze v takovem pripade vim ze tam jde projit, a ze uz to nemusim jezdit znovu kontrolovat. Pridavam fence=no. Pomoc vitana :-). Pomoc s cim? (What's the question?) Projit louky v mistech ktera Te zajima, a otagovat bud barrier=fence nebo fence=no. No, nevím, ale mě to připadá podobně ulítlý, jako cpát všude noexit=yes. To bychom pak mohli mít na každém objektu tisíce tagů s hodnotou no, protože je přec důležité, že (např.) tady nežijí krtci, nebo tak něco. A co to ma spolecneho s LPIS? Pri rucnim zakreslovani se da ocekavat, ze kdyby tam byl plot tak ho mapper otaguje. Pavel Tím si nejsem tak jistý P. ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-it] bridge AND embankment
sent from a phone Am 22.07.2015 um 19:38 schrieb Volker Schmidt vosc...@gmail.com: Per mio avviso un way può essere o su un ponte (bridge=yes o qualche altro valore) o su un terrapieno (embankment), ma non entrambi. +1 ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-pt] Conduta errática de um utilizador
Francisco lá me respondeu, mas desta vez tive que ser um pouco assertivo, e referir que se continuasse em não comunicar com a comunidade poderia levar a que as edições dele fossem consideradas vandalismo e apagadas. (sim usei um pouco de bluff) Conclusão trata-se de um editor de 13 anos de idade. Pelo que me respondeu, acha normal deixar as vias editadas de um dia para o outro, é só mais tarde completa las. Apesar de lhe ter explicado numa mensagem anterior que há pessoas que dependem dos lados em tempo real e deve deixar tudo o que editar concluído. Recusou se a admitir que deixou vias abertas como as que encontrei no porto e sacavem. É diz que não gosta do id por isso não o vai usar. E ainda me acusou de ao corrigir o trabalho dele estragar uma avenida em lisboa e de andar em parte a perseguir as edições deles só para implicar. Assim de repente e com esta atitude, penso que será muito difícil devido a diferenças de faixas etárias lhe explicar que ele está errado em tudo o que disse (já passei por essa idade). Francisco queres tentar a sorte? Tens mais paciência que eu. Talvez a velha máxima bom polícia / má polícia., funcione. Em 22/07/2015 19:48, f.dos.san...@free.fr escreveu: Rui, As nossas mensagens cruzaram-se, vamos la insistir para que ele responde. Também o que pode acontecer é que ele não consulta a sua caixa email, pouco provável dado que usa um editor online obrigando identificar-se. Ou talvez a barreira da língua : é capaz ser um emigrante vejo que há edições nos EUA. O uso do Potlatch 2 também pode estar condicionado a sua plataforma/navegador web, o iD não esta disponível dependente das versões. Vou verificando alguns dos outros changeset, há outras coisas estranhas, parece-me pouco provável que os peões circulam dentro da rotunda : - http://www.openstreetmap.org/way/361744172 Francisco ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Le 22/07/2015 16:36, Jérôme Seigneuret a écrit : Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Oui, certes. Mais si tu mets 5 minutes à trouver dans les données quel arbre a été abattu, parce qu'il y en a 52 dans la zone, que le gps n'est pas assez précis, qu'il faut compter à partir de la bordure nord-est, mais qu'ils sont pas alignés, du coup ça marche pas. Chaque pavé d'une rue, c'est une réalité. Chaque arbre des forêts aussi. Pourtant, c'était une blague à la mode il y a pas si longtemps. Il y a d'autres façons de cartographier pour ça : landuse, landcover. Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Oui, ils ont même parfois un SIG pour gérer ça. Mais c'est pas un argument pour rentrer toutes les données dans OSM. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. Bof, change le mot « intérêt » en « inconvénients dépassent les avantages ». ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ca] Highway recoding
Bonjour Paul, You actually highlight what makes me uncomfortable with the “strategic” approach applied in many part of Canada. You are concerned about the road network in BC; I am concerned about the network in QC. Until few months ago, there were no trunk here; they are now everywhere. IMO, OSM classification mostly aims at describing the road infrastructures, not the strategic/economic importance a local government says about them (almost quoted you!-). I understand that Tristan has similar concerns about the consequences of such approach in road classification; even if he suggested that the current definitions (using strategic approach) are good guidelines (but need not be followed religiously). Other comments on the subject Daniel From: Paul Norman [mailto:penor...@mac.com] Sent: July-22-15 15:59 To: talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Highway recoding On 7/22/2015 11:43 AM, Daniel Begin wrote: So far, I understand we have 2.5 votes for tagging trunk/motorway all roads identified as “core route” in document (a); 0.5 against (I am still torn between the two approaches!-) More comments would be appreciated Such an approach would be inconsistent with how highways are tagged in BC and expectations of locals. It would also make BC quite different than across the boarder in Washington. I can think of several motorways and trunk roads which are not on the list in the PDF, and many of the roads on the list are primary, or in at least one case, secondary. Some of the roads not on the list are more important in the transportation network than ones on it. The criteria being proposed are also inherently unverifiable. We map the world, not what a government database says. What about new roads? There's a new route that's opened up, and it's a mix of trunk and motorway, but it's not listed in the NHS report. To tag it primary when less significant roads constructed to a lower standard are tagged as trunk and motorway would be absurd. Because it has a lot of freight, it probably will become a NHS road at some point. Does its classification magically change when nothing has changed on the ground? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[OSM-talk-be] Mapper of the month
Hello Belgian mappers, It is already the 22nd of the month, but it is still July. So here our mapper of the month: Marc Gemis! FR: http://osm.be/fr/content/contributeur-du-mois-marc-gemis NL: http://osm.be/nl/content/mapper-van-de-maand-marc-gemis A special thank goes to the translators in this holiday-months! Best greetings, Jorieke ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] OSM / NWB datasessie met Rijkswaterstaat
Hierbij mijn wensenlijstje voor datasets tijdens de dataproeverij op 19 september: 1. Het Nationaal Wegwijzerbestand. Dat lijkt me namelijk erg nuttig voor OSM om die data, vooruitlopend op de beschikbaarstelling t.z.t. met een hopelijk voor OSM geschikte licentie, te kennen. Ik voer af en toe bestemmingen in voor snelwegen. Maar ik weet dat er diverse OSM'ers heel druk aan de slag zijn met het taggen van verkeersborden. 2. Datasets obv MIRT. Hoewel mogelijk erg (te?) beleidsmatig kan het mooi zijn om sommige MIRT stadia aan te laten sluiten op OSM tags. Het indiceren van een gebied in OSM obv MIRT kan misschien helpen om de actualiteit van OSM verder te vergroten, doordat eerder bekend is welke wegen in de nabije toekomst voorzien gaan worden van relevante wijzigingen 3. Ik zag een dataset met Waddenplaten. Als eenmalig wadloper (Holwerd-Ameland) weet ik inmiddels dat de huidige weergave in OSM niet bijster slecht is, maar nog wel iets beter kan. 4. Het voorgaande is te combineren met vaargeulen: mijn terugtocht (na de eenmalige wadloop) van Ameland naar Holwerd liep door een vaargeul die redelijk in OSM staat, maar vast niet precies genoeg 5. Informatie van http://vaarweginformatie.nl/. Geen idee welke datasets dat precies zijn, maar globaal doordenkend kunnen bijvoorbeeld de brugbedientijden niet alleen voor vaartuigen maar ook voor voertuigen interessant zijn. 6. Verkeersgegevens van het NDW. Actuele verkeersdata is interessant voor app-bouwers (de OSMAND's van deze wereld). De historische verkeersdata kan misschien nuttig zijn om maximumsnelheden te verbeteren in Nederland. @allen: graag jullie toevoegingen aan bovenstaand lijstje doorgeven! Cheers, Johan ps ik heb NWB (wegen vaarwegen spoor), Wegkenmerken (weggeg en wkd), Digitaal Terrein bestand/BGT en Kerngis niet genoemd, omdat die sowieso al aan bod komen op 19 september Op 17 juli 2015 16:33 schreef Milo van der Linden m...@dogodigi.net: Voor een snelle lijst met RWS geodata kun je ook terecht op: http://geoservices.rijkswaterstaat.nl/wmsbrowser.txt Op 17 juli 2015 15:05 schreef Gert-Jan van der Weijden gee...@dds.nl: Beste ontwikkelaars en mappers, Op zaterdag 19 september a.s organiseren we met Rijkswaterstaat CIV (centrale infovoorziening) in het LEF Future centre van RWS (langs de A12, naast de sneltram) een dag waarbij we in ieder geval kijken hoe OSM en het Nationaal Wegenbestand (NWB) van elkaars sterke punten kunnen profiteren. 2 aandachtspunten: 1. Om die dag in het LEF te kunnen houden hebben we een flinke deelname vanuit de community nodig: jullie dus. Daarom horen we graag bijtijds wie er komt. Mede om die reden hebben we een OSM Meetup Group in het leven geroepen: http://www.meetup.com/OpenStreetMap-Nederland/ De teller staat al op 11 deelnemers, maar dat mag best verdubbeld worden! 2. Als onderdeel van die dag willen we ook een RWS-dataproeverij organiseren, waarbij van een aantal RWS datasets de makers/beheerders ons van alles kunnen vertellen over het wel en wee van die datasets. Aan jullie de taak daar een datasetwensenlijst voor op te stellen! Via http://tinyurl.com/rws500 krijg je in een keer (wel even geduld hebben met laden) een overzicht van de datasets waar RWS eigenaar van is. Graag met een reply in deze thread, of met een comment in de bovengenoemde Meetup. En natuurlijk liefst met een motivatie er bij waarom je jouw favoriete datasets wilt proeven. De toptien willen we half augustus aan RWS doorgeven. groeten, Gert-Jan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl -- [image: http://www.dogodigi.net] http://www.dogodigi.net *Milo van der Linden* web: dogodigi http://www.dogodigi.net tel: +31-6-16598808 ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-be] Mapper of the month
Congratulations and much thanks. I like very much to know someone frol the community a little better thanks to these interviews. Nicolas À mer. juil. 22 17:38:59 2015 GMT-0400, Jorieke Vyncke a écrit : Hello Belgian mappers, It is already the 22nd of the month, but it is still July. So here our mapper of the month: Marc Gemis! FR: http://osm.be/fr/content/contributeur-du-mois-marc-gemis NL: http://osm.be/nl/content/mapper-van-de-maand-marc-gemis A special thank goes to the translators in this holiday-months! Best greetings, Jorieke ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Envoyé depuis mon Jolla ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-ja] 奈良世界遺産マッピングパーティ 第二回春日大社（7/25）
いいだです。 お返事遅れてすみません。 別便でお伝えしたとおり、以下に掲載しました。 https://openstreetmap.jp/node/754 あと、このイベントを https://openstreetmap.jp/ の記事として投稿する （してもらう）にはどのように連絡すればよいのでしょうか？ このTalk-ja MLで依頼いただくか、 あるいは僕に直接、メール, Twitter, Facebookメッセージあたりで連絡いただければ掲載します。 イベントのお知らせ協力はぜひ行いたいので、 申請方法はもうちょっと洗練させたいですね。 （なにがいいだろう？） 2015年7月18日 9:20 Yasushi Ish yasushi...@gmail.com: OSMマッパーの皆様 お世話になってます、Code for Nara の石塚です。 奈良でも世界遺産をターゲットにマッピングパーティを行います。 次は来週末 7/25（土）に第二回として春日大社をターゲットに行います。 下のページで募集していますので皆様の参加をお待ちしています。 https://code4nara.doorkeeper.jp/events/28188 # 京都の山下さんのイベントを参考に企画させていただいてます。 あと、このイベントを https://openstreetmap.jp/ の記事として投稿する （してもらう）にはどのように連絡すればよいのでしょうか？ Yashishi ISHIZUKA ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-pt] Conduta errática de um utilizador
Eu costumo fazer como estava Antes, isto é assim que existe uma bifurcação de saída ou entrada numa via rápida faço a ligação perto e não como está depois, extendendo a via até ser suprimida e só assim se faz a ligação. Mas os casos que tenho visto de forma diferente da minha forma de agir tenho deixado (como é o caso da edição que referiste acima). Não me importo de começar a fazer como está na imagem Depois, pois acho que as duas abordagens podem ser consideradas aceitáveis. Resta acordarmos qual é o melhor deles e uniformizarmos, numa Wiki ou coisa do género. 2015-07-22 23:44 GMT+01:00 f.dos.san...@free.fr: Ok mensagem enviado. Olhando para os últimos changeset reparei num assunto que mereça ser discutido aqui. Reparem para as alterações : - https://www.openstreetmap.org/changeset/32810120 Sobretudo os ways : - http://www.openstreetmap.org/way/345536214 - http://www.openstreetmap.org/way/26650852 O .PNG mostra a situação antes e depois do changeset : a passagem A4-A28 acaba mais tarde e a passagem A28-A4 começa mais cedo. Fica então a questão para ser debatida : qual é o melhor local para colocar o inicio e o fim duma entrada/saída ? O que encontrei neste assunto : - http://wiki.openstreetmap.org/wiki/Talk:Lane_assist/Examples/Motorway_exit#Setting_the_split_.28location_of_the_motorway_junction_node.29 In France (joedalton85) it's a custom to set the split (the motorway_junction node) at the start of the deceleration lane. In Italy (Simone) it depends on the situation. In several situations the split is set at the middle of the deceleration lane. In Germany (Martin) the split is set where the restricted zone starts. Francisco - Mail original - From: Rui Oliveira racoqs...@gmail.com To: Lista de discuss#227,o para Portugal talk-pt@openstreetmap.org Date: 22/07/2015 21:22:50 Subject: Re: [Talk-pt] Conduta errática de um utilizador Francisco lá me respondeu, mas desta vez tive que ser um pouco assertivo, e referir que se continuasse em não comunicar com a comunidade poderia levar a que as edições dele fossem consideradas vandalismo e apagadas. (sim usei um pouco de bluff) Conclusão trata-se de um editor de 13 anos de idade. Pelo que me respondeu, acha normal deixar as vias editadas de um dia para o outro, é só mais tarde completa las. Apesar de lhe ter explicado numa mensagem anterior que há pessoas que dependem dos lados em tempo real e deve deixar tudo o que editar concluído. Recusou se a admitir que deixou vias abertas como as que encontrei no porto e sacavem. É diz que não gosta do id por isso não o vai usar. E ainda me acusou de ao corrigir o trabalho dele estragar uma avenida em lisboa e de andar em parte a perseguir as edições deles só para implicar. Assim de repente e com esta atitude, penso que será muito difícil devido a diferenças de faixas etárias lhe explicar que ele está errado em tudo o que disse (já passei por essa idade). Francisco queres tentar a sorte? Tens mais paciência que eu. Talvez a velha máxima bom polícia / má polícia., funcione. ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[OSM-talk-fr] Tags vides
Salut à tous, Je suis nouveau sur cette liste, et même nouveau dans le merveilleux monde d'OSM à vrai dire ^^ Pour me présenter rapidement, je suis développeur web à tendance full Javascript, j'habite Bordeaux et ma couleur préférée est le rouge. Bref, je suis en train de développer une application qui permettra, entre autres, de contribuer à OSM et évidemment, j'ai des questions (je suis nouveau rappelez-vous) ! Je vais commencer par une facile, juste pour dire bonjour sur la liste : Admettons que j'affiche une carte, fond OSM, nodes OSM. Je veux modifier les tags d'un des nodes, pour ça je présente un formulaire avec les tags existants ET potentiellement d'autres comme le name par exemple. Je rempli des trucs mais ne touche pas au tag name qui je le rappelle n'existe pas dans la base OSM pour ce node. Dans ce cas, j'imagine que je ne dois pas prendre en compte ce tag et ne pas l'ajouter au node puisqu'il est vide. Mais, si le tag existait déjà (name = toto) et que je le vide dans le formulaire... Je le supprime du node ou je l'envoie vide (chaîne de caractère vide) ? Alors alors ?! Merci d'avance pour vos lumières :) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] 8/22 開催。京都世界遺産マッピングパーティ：第５回上賀茂神社
京都の山下です。皆さんこんにちわ。 京都の世界遺産を毎月一か所ずつターゲットにして、 楽しみながら 自由な地図である OpenStreetMap に書いていく マッピングパーティ、第５回は上賀茂神社をターゲットにして 8/22 に開催します https://openstreetmap.doorkeeper.jp/events/28687 皆さんのご参加をお待ちしています！！ -- 山下康成＠京都府向日市 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk-fr] durée des trajets à vélo dans Paris
Pour osrm, voir http://project-osrm.org/ Pour graphhopper: https://graphhopper.com/#contact m 2015-07-22 15:14 GMT+02:00 Julien Demade dem...@no-log.org: Cela doit effectivement revenir à cela (je pencherai pour une vitesse moyenne trop haute): mais où sont ces réglages, à qui signaler le problème? Le 22/07/2015 13:22, Marc Gemis a écrit : Il y a plusieurs possibilités: 1) Ou les donnés des feux et des obstacles manque dans OSM 2) Ou les algorithmes ont des erreurs, e.g. la vitesse moyenne est trop haute. 3) ?? just my .5 cents m 2015-07-21 15:16 GMT+02:00 Julien Demade dem...@no-log.org: Bonjour Je voulais signaler un problème quant à la durée indiquée sur OSM des trajets à vélo dans Paris (problème possiblement plus général, je ne sais pas): elle est beaucoup trop brève, ne tient pas du tout compte du fait qu'on ne roule pas aussi vite en milieu urbain que sur une route de campagne (feux, circulation, croisements, etc.). Pour donner un ordre de grandeur, un trajet indiqué sur OSM comme prenant à peu près 30-40mn (suivant que l'on utilise GraphHopper ou MapQuest), est indiqué sur un autre calculateur d'itinéraires (qui donne lui des durées fiables) comme prenant environ 50mn (il s'agit de http://www.geovelo.fr/). Bref, tel quel le planificateur d'itinéraire vélo est inutilisable, ce qui est dommage! Comme je n'ai malheureusement aucune idée de la nature du problème, et donc encore moins de la façon de le résoudre, je me contente de le signaler, en espérant qu'il y a plus compétent que moi - ce dont je ne doute pas! Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr ___ 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] Potlatch 2 : une interface qui s'affiche par défaut sur OSM
Avant de vous expliquer mon problème, je vais d'abord présenter le contexte. Je suis un étudiant-stagiaire qui travaille jusqu'à fin août pour un Conseil de Développement, une association de citoyens. J'ai pour mission principale d'organiser des ateliers participatifs et des cartoparties autour d'OpenStreetMap auprès des habitants d'une zone spécifique sur laquelle intervient le CdD pour divers projets citoyens. J'ai appris sur le tas à utiliser l'interface iD-Editeur d'OpenStreetMap et anime donc des cartoparties aux thématiques variées sur cette interface. Après 3 mois d'utilisation + une formation spécifique OSM, je pense être suffisamment calé avec iD-Editeur pour passer à l'utilisation de JOSM. Mais là n'est pas la question pour laquelle je vous sollicite. J'ai animé il y a quelques jours une cartopartie avec iD-Editeur pour les habitants d'un petit village où le maire était présent. Tout s'est bien passé. *Mais quelques jours plus tard, le maire me rappelle pour me dire qu'il voulait rentrer des données dans OSM, mais qu'il ne pouvait pas car il s'affichait par défaut l'interface Potlatch 2, et qu'il ne pouvait pas aller sur l'interface iD-Editeur.* Je suis donc retourné à la mairie le lendemain, et comme me l'avait expliqué le maire, seul Potlatch 2 s'affiche et je ne suis pas arrivé à changer d'interface = *en cliquant pour choisir ID-Editeur, OSM me re-balance toujours Potlatch 2.* Certes, je pensais alors me former seul à utiliser Potlatch 2 pour ensuite former individuellement Mr le maire. *Le problème, c'est que Potlatch 2 est en anglais. *Et dans la région où je travaille, personne n'a envie de s'embêter à apprendre la langue de Shakespeare pour ensuite apprendre à utiliser OSM (personnellement, j'aurai réagi de la même façon). Donc ma question, si quelqu'un peut y répondre, c'est : *Savez-vous s'il y existe un moyen de régler le problème d'interface que je rencontre ? Si oui, comment ? Si non, alors existe-t-il un moyen de mettre l'interface Potlatch 2 en français par défaut ?* Merci d'avance à ceux qui pourront m'aider... je suis un peu perdu... *Nicolas Cucchietti* Stagiaire pour le Conseil de Développement du PNR des Préalpes d'Azur Tourisme Durable - Projet Itinérance ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Importation des arbres municipaux sur Nice
Après, je me pose la question de l'intérêt d'importer une zone comme ça, avec des arbres espacés de moins de 1m : http://hpics.li/85d8ec5. Il y en a plusieurs. Tu aurais des statistiques de distances ? Moi et QGis, on essaye de s'aimer, mais c'est pas toujours facile. À part compliquer la contribution, foirer le rendu, rendre impossible toute correction humaine ultérieure Je vois pas comment les corrections ne serait pas faisable... L'import a un intérêt pour la gestion des arbres. Les arbres plantés en touffe à moins d'un mètre c'est une réalité du terrain aussi... Pour une commune l'intérêt est de gérer les plantations. Il me semble qu'avec l'age on peut aussi déterminer des arbres remarquables. Quand à la hauteur c'est plus dur à déterminer et à maintenir dans le temps. Sauf mettre la date de la prise de la hauteur car elle évolue dans le temps. Ca a aussi un intérêt environnemental: - étude des pollens - accueille de la faune Un intérêt patrimonial, paysager, ... On pourrait aussi gérer l'état de santé même si rien n'existe pour le moment dans OSM mais là on est plus dans la gestion. Peut être avec des ref=* pour gérer l'abattage d’arbres dangereux et l'élagage ajouter un facteur de croissance automatique par espèce pour déterminer un planning prévisionnel d'entretien. Bref les possibilités sont grandes même si certains n'en trouve pas l'intérêt. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Potlatch 2 : une interface qui s'affiche par défaut sur OSM
Le 22 juillet 2015 16:34, Nicolas Cucchietti nicolas.cucchie...@cddpnr06.org a écrit : Donc ma question, si quelqu'un peut y répondre, c'est : *Savez-vous s'il y existe un moyen de régler le problème d'interface que je rencontre ? Si oui, comment ? Si non, alors existe-t-il un moyen de mettre l'interface Potlatch 2 en français par défaut ?* Merci d'avance à ceux qui pourront m'aider... je suis un peu perdu... Bonjour, Il faut configurer l'éditeur préféré dans les options d'osm : Monsieur le Maire doit aller sur son compte ( https://www.openstreetmap.org/user/[MonsieurLeMaire]/account) et choisir ID dans un des menus déroulants. Pierre-Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cz] mapa s popisky
Ahoj, znám relativně dobře dvě možnosti pro tvorbu vlastní mapy. Legendu jsem ale zatím nikdy neřešil... leda v GIMPu :D S tiskem nápodobně :( 1) Google maps / drive. Aktivně je používám už skoro rok. Jako vrstva pozadí je některá z map Googlu (doprava / satelit / reliéf atd.). Umí vlastní vrstvy, v nich libovolně objekty typu bod, čára, oblast. Pro vše se dá nastavit barva nebo ikonka, dají se zobrazit názvy, přidat delší popisky. Ikonky se dají nakreslit a importovat vlastní, což mapu náležitě graficky pozvedne :) Import a export je ve formátu KML, dá se konvertovat sem tam s GPX a OSM. Klidně tedy lze sebrat nějaký objekt z OSM nebo si vycucnout trasy ze Seznamu (export jako GPX), pokud je to jen pro vlastní použití, tak co... Hlavní plus je možnost sdílení s vybranými lidmi a snadné ovládání. V příloze je ukázka. 2) Lze si udělat něco vlastního s použitím Leaflet.js http://leafletjs.com/ Dá se s tím udělat všechno viz výše, na vlastních stránkách / vlastním serveru (ocení milovníci samostatnosti!), plus WMS/TMS tuším, a tak vůbec obecně je to něco s čím lze manipulovat programově, takže není nutné narážet na náhodná omezení. Není to ale i pro babičku a maminku, pro ty leda na koukání. Eventuálně existuje plugin pro wordpress, který usnadňuje některé úkony... Hezký den! Vláďa Dne 22.7.2015 v 10:48 Karel Volný napsal(a): zdravíčko, chtěl bych si udělat mapku výletu, poradí někdo prosím nějaký jednoduchý udělátor, kde by si šlo různě označit cesty a body, resp. přidat vlastní, a napsat k tomu legendu? obtahovat čáry na obrázku v GIMPu apod. se mi tak úplně nechce :-) K. ___ 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
