Re: [Talk-cz] Mapy.cz s openstreetmap daty
Ahoj! On 2015-04-14, 17:48 GMT, Jan Martinec wrote: včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne každý renderer navíc je dobrá věc :) Mají? Na http://napoveda.seznam.cz/cz/mapy/mapy-licencni-podminky/ vidím „© Přispěvatelé OpenStreetMap“ (jen mimo ČR a SR) což mi připadá že o tomhle konkrétním changsetu z OSM (pokud ho opravdu použili) lžou. Mají. Když se mrkneš na mapu, tak v levém dolním rohu vidím (c) přispěvatelé OpenStreetMap a to bohatě stačí. No nevim, nemela by OdBL zarucovat, ze mame pravo dostat zdrojovou databazi? Zminka (c) Openstreetmap neni jedina podminka pouziti OSM dat. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-br] Classificação de rodovias no Brasil (Wille)
Acho que a sua classificação está ok, mas só nota que o CTB diz que a velocidade máxima nas arteriais é de 60km/h, nas coletoras é 40km/h e nas locais é 30km/h. Claro que não precisa ser sempre assim (não é um critério absoluto), mas acredito que seja essa a expectativa dos órgãos locais ao fazer a classificação (o que não impede que adotem outras definições/terminologias, e frequentemente adotam). O problema de usar o número de faixas como critério é que ele raramente se aplica igualmente a cidades diferentes, isso depende do projeto de cada cidade. Erechim, no RS, é uma cidade onde quase todas as ruas são de 4 faixas, esse critério então produziria uma alta densidade de primárias. Então, a densidade das vias primárias, secundárias e terciárias variaria muito de uma cidade pra outra, o que (pelo que entendi até agora) é pouco desejável (e isso indica que o objetivo principal da classificação é a orientação visual pela malha). Da mesma forma, há ruas estreitas que são consideradas importantes, pelo menos por órgãos oficiais (como é o caso do plano diretor de Porto Alegre). Eu reclassifiquei Porto Alegre há pouco tempo consertando os erros da minha classificação anterior, e comecei a esboçar as regras [1] (primeiro tentei avaliar a relação entre o plano diretor e a realidade física dessas vias para ver se havia uma correspondência). Primárias e secundárias aqui acabaram sendo as vias onde se anda a 60km/h (onde não tem placa, adotei a classificação do plano diretor; onde tinha, o resultado coincide), e a diferença é se elas vão de um núcleo urbano até outro ou se se limitam ao mesmo município (falta definir núcleo urbano; acho que poderiam ser as subprefeituras com sede física, por uma série de razões). As terciárias são as que começam nas primárias/secundárias em direção ao interior dos bairros (cuidado com esse conceito, na Europa essas vias realmente delimitam os bairros, no Brasil não, por isso eu mudei o conceito para célula residencial). Elas se distinguem das residenciais por serem ao mesmo tempo preferenciais, melhores que suas alternativas paralelas (melhor pavimento, ou mais largas) e por atravessarem longos trechos, geralmente cruzando a célula de uma ponta à outra, mas nem sempre. Isso garante uma baixa densidade de terciárias. A idéia é que a maioria das residenciais se ramificam a partir dessas terciárias, que elas são portanto as espinhas dorsais dos bairros. Infelizmente, essa avaliação exige bastante trabalho e ainda é um tanto subjetiva. Não há trunks por aqui pela classificação atual do OSM (que a meu ver são vias que pertencem sempre ao sistema viário intermunicipal). Também estou tentando (com o tempo que tenho) conseguir a classificação oficial das principais cidades brasileiras (as capitais) pra ver esses critérios produziriam um resultado similar, ou se precisam ser melhorados (meus critérios casam com o plano diretor daqui, mas podem não casar com outros planos diretores, especialmente o critério das terciárias). Consegui os de Brasília (bem fácil de mapear, e aparentemente daria o mesmo resultado), o de BH (que classifica todas as ruas do centro como arteriais, e portanto precisaria de alguma definição melhor para diferenciar umas das outras, mas fora dessa área parece dar o mesmo resultado também), e soube que São Paulo classifica as vias pela sua estrutura (N1, N2, N3), o que pode ser um problema. Vou publicar os links assim que tiver uma lista maior, mas aceito contribuições, quanto mais fontes oficiais tivermos para comparar, melhor. [1] https://wiki.openstreetmap.org/wiki/User:Ftrebien/Drafts/Classifica%C3%A7%C3%A3o_de_vias_em_Porto_Alegre 2015-04-14 13:52 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Pra áreas urbanas, a minha opinião é a seguinte: - motorway: mesmo contexto da área rural, via urbana sem interrupções que corta parte da cidade, com acessos em alça nas entradas e saídas. Vias de trânsito rápido do CTB. Exemplos no RJ: Linha Amarela, Linha Vermelha - trunk: via importante com muitas faixas de rolamento porém com interrupções. Trânsito quase expresso. Vias arteriais do CTB. Ex: Av. Presidente Vargas / Av. das Américas - primary: via com pelo menos 2 faixas de rolamento que corte os bairros. Vias coletoras do CTB. Ex: Av. Atlântica - secondary / tertiary: vias com importância menor frente às primaries, também coletoras. Ex: R. Barata Ribeiro - residential: Vias locais do CTB. - unclassified: Vias locais em áreas estritamente não-residenciais. - living_street: Vias que o pedestre ainda na pista / pistas internas de condomínios etc. - service: Ruas de serviço / acesso a estacionamento. []s Arlindo 2015-04-14 12:52 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2015-04-14 12:44 GMT-03:00 belnu...@pop.com.br: E como fica a classificação de vias dentro das cidades ? Quando se usa qual ( fora a Residencial , a Não Classificada e de Tipo Compartilhado ) ? Para as áreas urbanas precisa de uns 6 meses de
Re: [OSM-talk-fr] Petits changements dans le rendu QA
Bonjour, Il me semble que sue se rendu qa les carrés magenta ne disparaisse plus quand un route est ajouté. Et les pastilles ne change pas du tour gris au vert quand le cadastre vecteur existe. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Hallo Martin, vielen Dank für das Einmischen. Am 15.04.2015 um 12:14 schrieb Martin Koppenhoefer: Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist. Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme benutzt werden. soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung / Anschluss um Flüssigkeit Feststoffe zu transferieren), während Gisbert, soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die man entsorgen kann, in einem tag verquicken würde. Es gibt warscheinlich gar nicht so große Unterschiede, deshalb gehe ich davon aus, dass es auch ein gemeinsames Tagging gibt. Im Proposel gibt es nur amenity=sanitary_dump_station. Dann das ganze zum Anhängen an eine bestehende Einrichtung also Camping- Wohnmobilstellplatz und Häfen. sanitary_dump_station=yes Beides sagt aus, daß es eine Entsorgungsstation gibt. Da es aber verschiedene Arten der Entsorgung gibt sind noch 2 Zusatztags dazugenommen worden. sanitary_dump_station:suction=yes sanitary_dump_station:gravity=yes diese beiden Tags sagen für mich nur aus, daß in dem ersten Fall abgesaugt wird und im 2. Fall die Entsorgung durch ablassen der Flüssigkeit geschieht. Also für mich nur die Beschreibung der Technik bei der Entsorgung. Deshalb habe ich die Bilder die ich im letzten Jahr von solchen Stationen gemacht habe hochgeladen und eine Tabelle in seine Diskussionsseite geladen mit der Bitte diese so zu beschreiben wie er sie sieht um Differenzen zu finden. Bilder fand er nicht gut und stellte 3 Videos vor. Dabei gab es dann den Tag sanitary_dump_station:pumpout=yes der auf meine Frage warum er jetzt dies benutzt wurde daraus dann pump_out. Als ich ihm dann erklärte, dass ich für die Suche nach neuen Begriffen Taginfo benutze und da in dem Fall dann einzig Habor:pump-out gefunden hätte hat er es dann mit Bindestrich geschrieben. Ich habe dann versucht die englische Wikiseite zu überseztzen , die aber täglich ein bisschen geändert wird. Dann habe ich ein paar Prinzipbilder , natürlich aus meiner Sicht erstellt. Die sollten aber eigentlich auch zwischen hier und den Staaten übereinstimmen, denn die Videos zeigen eigentlich die selbe Art von Fahrzeugen. Und ob es drüben ein Bajonet am Entsorgungsschlauch gibt oder ob der Schlauch mit einer anderen Art an das Fahrzeug angebracht wird sollte fürs taggen egal sein. Die für mich wichtige Frage, ob man die in den neueren Fahrzeugen verwendeten Kassettentanks auch über das gleiche Loch in welches der Adapter für das Auslassende passt, entsorgt werden kann hat er noch nicht beantwortet. Natürlich ist unstrittig, dass die Entsorgungseinlässe, die ca. 1 m hoch liegen nicht für die Schlauchentsorgung funktionieren, und man diess anders beschreiben muß. Da es sich dabei aber nicht nur um hochgelegte Auslassbecken oder spezielle Toiletten handelt sondern auch um extra hochgezogene Rohre ist der von ihm kurzerhand erstellte Tag sanitary_dump_station:basin=yes irreführend. Anscheinend gibt es da eben das Problem, dass man nicht das Becken , welches wenn es in den Boden eingelassen ist andere Entsorgungsmöglichkeiten bietet als wenn es In einem Gebäude 1m hoch an der Wand hängt, beschreiben darf sondern das was dort entsorgt wird. Ausserdem gefällt ihm der tag sanitary_dump_station:chemical_toilet nicht so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur Benutzung durch Menschen sieht. chemical_toilet ist der zur Zeit am häufigsten benutzte Tag bei der Entsorgung Sieser wurde bisher mit amenity=waste_disposal waste=chemical_toilet getagt. Daher hatte ich diesen vorgeschlagen. Ich habe aber auch vorgeschlagen ganz auf den Tag zu verzichten da eigentlich 90% der hiesigen Entsorgungsstationen chemische Zusätze in den Fäkalien zulassen. Es gibt in Europa auf Länderebene Unterschiede welche Gifte enthalten sein dürfen, Aber das weiß man recht schnell wenn man in ein anderes Land reist. Da es aber bei uns Biologische Klärwerke gibt, die durch die Zugelassenen Chemikalien ihre Funktion verlieren bat ich um ein Tagg wie chemicals_ban oder forbit. Er führte daraufhin den Tag chemicals_restrictet ein und meite in den USA gäbe es nur Beschränkungen aber keine Verbote, außer in einigen Staaten, dort aber dann komplett. Das wäre aber ja maximal ein Tag der dann hier anders wäre als drüben. Sie könnten ja auch nebeneinander existieren. Gruß Gisbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-br] Classificação de rodovias no Brasil
Acho que algumas das nossas concepções sobre a classificação vão mudar quando o Carto (estilo oficial do OSM) passar a diferenciar as vias pavimentadas das não-pavimentadas, independente da sua classificação. Daqui a 12 dias (na próxima atualização do Debian) vou conseguir propor estilos gráficos para isso (ninguém fez realmente uma prova de conceito até agora, só alguns esboços) e quem sabe com isso o debate ande. Me parece que nossos vizinhos latino-americanos e africanos estão classificando todas as rodovias federais como trunk, independente da sua estrutura física ou do tipo de projeto. Basta dar uma olhada no mapa com nível de zoom 5 para ver isso: http://www.openstreetmap.org/#map=5/7.733/3.032 2015-04-13 16:30 GMT-03:00 Flavio Bello Fialho bello.fla...@gmail.com: Eu odeio esse assunto. Desde que eu entrei no OSM, ele sempre volta pelo menos uma vez por ano. O que mais me incomoda é que as discussões são longas, tomam tempo que podia ser melhor gasto em outras coisas e acabam não progredindo muito. Não é culpa de ninguém. É um assunto importante, mas cansativo. Não existe consenso. O artigo no wiki demonstra isso. Eu gostaria que existisse, mas não existe. Não existe nem consenso sobre o que é consenso nessa questão. Infelizmente, eu me sito obrigado a participar dessa discussão cada vez que ela aparece, porque ela afeta diretamente o meu trabalho no OSM. Acho que o mapa do Brasil não está maduro o suficiente para tomarmos uma decisão definitiva sobre a classificação de vias. No fim, quem trabalha no mapa vai ter que decidir conforme a sua consciência. Sugiro que não foquem o trabalho apenas na classificação, e sim em outras coisas mais críticas, como mapear as rodovias que não existem no mapa ou colocar as que existem no lugar certo (os dados importados do IBGE estão muito toscos), ou mapeando corretamente os cruzamentos e restrições de conversão, que também são importantes para o roteamento. Se for possível incluí-los, os tags lanes, maxspeed e surface podem ajudar bastante na classificação das rodovias no futuro (ou não, dependendo do critério; nesse caso, eles se tornariam ainda mais importantes). À medida que forem fazendo isso, se quiserem, ajustem a classificação das rodovias que forem editadas da forma que acharem melhor. Muita paz para todos. Espero ter contribuído com alguma coisa e desculpe se, por algum motivo, alguém se sentir incomodado com o meu comentário. Em 12 de abril de 2015 01:46, Gilmar Ferreira gilmar.al...@gmail.com escreveu: Concordo que o artigo seja editado para refletir mais claramente o que já é consensual na comunidade. Para alguém que está começando na comunidade, e eu estou começando, o artigo está confuso: não ficou muito claro o que era consensual. Gilmar Em sáb, 11 de abr de 2015 16:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Até onde me consta, o último debate amplo da comunidade que gerou consenso é o que consta na segunda seção deste artigo: [1] Esta seção foi primariamente editada por mim na época, sempre pedindo que a comunidade revisasse e criticasse, e fiz questão de apontar para as discussões na lista e inclusive de reconhecer publicamente aquilo que a comunidade considerou como erros meus, para que todos soubessem até que ponto devem interpretar essas recomendações de forma literal. O artigo foi recentemente editado pelo usuário Fbello [2], que participou das discussões sobre esse assunto aqui na lista. Ele colocou no topo do artigo uma tabela cuja origem eu desconheço e que não consta nos comentários de edição do wiki. Se é uma proposta, deveria ter escrito que é uma proposta, e não dar a entender que é o consenso da comunidade. Se ninguém se opuser, eu gostaria de mover essa seção para baixo e de listá-la como proposta em debate. Essas páginas principais do wiki deveriam ser tratadas como local de conhecimento consolidado, não como ponto de disputa ideológica. O critério por consenso para que uma via seja considerada expressa é o seguinte: (estou lendo direto do fluxograma no artigo) 1. Seja duplicada - tenha predominantemente pelo menos 2 faixas por sentido (pode ter 1 só em alguns poucos trechos curtos) 2. Tenha uma separação central entre as duas mãos - pode ser um canteiro, uma defensa, ou (em teoria, mas nunca vi na prática) até mesmo certos tipos de tartarugas [3] 3. Possua semáforos ou interseções em nível (aquelas que fazem o fluxo que entra/sai/atravessa a via parar completamente até conseguir uma brecha no tráfego). [4] Isso distingue essas vias das motorways onde há faixas para ingressar/sair, sem necessidade de parar (apenas dar sinal e esperar a boa vontade dos motoristas da faixa ao lado). O critério para diferenciar primárias e secundárias não-urbanas é simplesmente a presença/ausência de acostamento. Não é uma diferenciação muito importante (foi mencionado por alguns algumas vezes no meio do debate, posso conseguir o link se quiserem), então não
Re: [talk-au] Use of mapconnect data in OSM [SEC=UNCLASSIFIED]
On 15 April 2015 at 23:01, Ross i...@4x4falcon.com wrote: The issue is not with the licence. The current terms and conditions require permission to add data not owned by the contributor. Is there a source for this statement? I was under the assumption that in order to contribute data (whether your own or someone else's) into OSM, the data must comply with the contributor terms. Although the CTs agree to always give attribution, this (probably) still isn't compatible with the attribution required by CC-BY and the provide a link to the license and indicate if changes were made clauses of CC-BY. So my thinking is for data to be added to OSM under the current CTs it needs to waive these requirements of CC-BY and settle for attribution only (and perhaps a specific form of attribution). As you point out though this data is upto 8 years old and in many cases there is probably better or more current data available eg Tasmanian Estate Reserve. CAPAD is seems pretty good, http://www.environment.gov.au/fed/catalog/search/resource/details.page?uuid=%7B4448CACD-9DA8-43D1-A48F-48149FD5FCFD%7D ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-br] Classificação de rodovias no Brasil
Acho que, nas RAs onde há uma classificação oficial, deve-se tentar copiá-la tanto quanto possível. Eis o link: http://www.sedhab.df.gov.br/desenvolvimento-urbano/planejamento-urbano/pdl.html Vi que cada RA dá nomes diferentes a cada tipo de via, então acho que é necessário estudar cada RA para saber qual tipo atribuir. 2015-04-14 19:41 GMT-03:00 Ivaldo Nunes de Magalhães ivald...@gmail.com: Olá wille, como está o DF? Veja, não é meu propósito opinar sobre qualquer padrão aqui, pois tem gente mais gabaritada para isso, mas meus dedos cóçam quando vejo algo que não entendo claramente e aí tenho que escrever. Eu ordenei mais ou menos por uma lógica crescente de importância, procurando inclusive seguir o OSM (os desenhosinhos que representam os tipos de vias, acho eles bem intuitivos), tendo como parâmetro: separação de vias, a quantidade de faixas e o acostamento. Não levei em conta o asfaltamento. Eu queria algo assim, mas simples e pratico. Acho que pode ser feito. Meu empolguei e fiz algumas alterações, incluindo as suas sugestões. Até que ficou bom. Acho que vou seguir esse. Auto estrada: - duplicada (canteiro central entre as mãos); - mínimo 2 faixas por sentido; - acostamento em ambos os lados do sentido; - exemplo: Rodovia Castelo Branco (SP-270). Via expressa: - duplicada (canteiro central ou algum tipo de obstáculo entre as mãos, não pode ser tartaruga); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia Raposo Tavares (SP-280). Via primária: - não duplicada (sem canteiro central entre as mãos); - 1 ou 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-163/MS. Via secundária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido; - sem acostamento (acostamento menor que 1 faixa e não cabe 1 carro); - exemplo: Rodovia MS-320. Via terciária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido - sem acostamento e não asfaltada; - exemplo: Rodovia Benevenuto Ottoni/MS. Abraços Ivaldo Oi, IvaldoGostei muito desse seu resumo. Algumas correções: - Secundária não tem acostamento (ou, se tiver, é aquele acostamento que não cabe um carro e parte dele fica na faixa de rolamento). -Terciária não é pavimentada. Proponho que coloquemos esse esquema no wiki para complementar a página. abraços, wille On 11-04-2015 22:09, Ivaldo Nunes de Magalhães wrote: Alexandre, obrigado pela indicação. Já tinha visto essa imagem. No meu entender ela é de difícil interpretação e análise para o ambiente de produção do OSM, que requer uma decisão rápida. Acho que deveríamos convertê-lo numa tabela mais enxuta e simples, tipo: Auto estrada: - canteiro central entre as mãos (duplicada); - mínimo 2 faixas por sentido; - acostamento em ambos os lados do sentido; - exemplo: Rodovia Castelo Branco (SP-270). Via expressa: - canteiro ou algum tipo de obstáculo central entre as mãos, não pode ser tartaruga (duplicada); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia Raposo Tavares (SP-280). Via primária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-267/MS. Via secundária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 1 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-158/MS. Via terciária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 1 faixas por sentido; - sem acostamento; - exemplo: Rodovia BR-262/MS. Isso é um exemplo de uma classificação simples, mas clara. Ivaldo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
Concordo com Flavio. A exigência de acostamento dos dois lados em cada sentido da via não estava no fluxograma. Portanto o que diferencia autoestrada de via expressa é a presença ou não de canteiro central ou de obstruções. wille Em 2015-04-15 02:40, Flavio Bello Fialho escreveu: Ivaldo, A tua idéia é boa. Eu só sugiro uma pequena modificação: A diferença entre motorway (auto-estrada) e trunk (via expressa), do modo que eu mapeio, é que a motorway não tem cruzamento em nível (uma rua ou retorno atravessando a rodovia) e a trunk tem. Isso faz bastante diferença na segurança da via. Fora isso, o teu esquema é coerente e está compatível com o que eu acredito que normalmente se faça. Bom trabalho! Em 14 de abril de 2015 19:41, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Olá wille, como está o DF? Veja, não é meu propósito opinar sobre qualquer padrão aqui, pois tem gente mais gabaritada para isso, mas meus dedos cóçam quando vejo algo que não entendo claramente e aí tenho que escrever. Eu ordenei mais ou menos por uma lógica crescente de importância, procurando inclusive seguir o OSM (os desenhosinhos que representam os tipos de vias, acho eles bem intuitivos), tendo como parâmetro: separação de vias, a quantidade de faixas e o acostamento. Não levei em conta o asfaltamento. Eu queria algo assim, mas simples e pratico. Acho que pode ser feito. Meu empolguei e fiz algumas alterações, incluindo as suas sugestões. Até que ficou bom. Acho que vou seguir esse. Auto estrada: - duplicada (canteiro central entre as mãos); - mínimo 2 faixas por sentido; - acostamento em ambos os lados do sentido; - exemplo: Rodovia Castelo Branco (SP-270). Via expressa: - duplicada (canteiro central ou algum tipo de obstáculo entre as mãos, não pode ser tartaruga); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia Raposo Tavares (SP-280). Via primária: - não duplicada (sem canteiro central entre as mãos); - 1 ou 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-163/MS. Via secundária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido; - sem acostamento (acostamento menor que 1 faixa e não cabe 1 carro); - exemplo: Rodovia MS-320. Via terciária: - não duplicada (sem canteiro central entre as mãos); - 1 faixa por sentido - sem acostamento e não asfaltada; - exemplo: Rodovia Benevenuto Ottoni/MS. Abraços Ivaldo Oi, IvaldoGostei muito desse seu resumo. Algumas correções: - Secundária não tem acostamento (ou, se tiver, é aquele acostamento que não cabe um carro e parte dele fica na faixa de rolamento). -Terciária não é pavimentada. Proponho que coloquemos esse esquema no wiki para complementar a página. abraços, wille On 11-04-2015 22:09, Ivaldo Nunes de Magalhães wrote: Alexandre, obrigado pela indicação. Já tinha visto essa imagem. No meu entender ela é de difícil interpretação e análise para o ambiente de produção do OSM, que requer uma decisão rápida. Acho que deveríamos convertê-lo numa tabela mais enxuta e simples, tipo: Auto estrada: - canteiro central entre as mãos (duplicada); - mínimo 2 faixas por sentido; - acostamento em ambos os lados do sentido; - exemplo: Rodovia Castelo Branco (SP-270). Via expressa: - canteiro ou algum tipo de obstáculo central entre as mãos, não pode ser tartaruga (duplicada); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia Raposo Tavares (SP-280). Via primária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 2 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-267/MS. Via secundária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 1 faixas por sentido; - acostamento em 1 dos lados do sentido (direito); - exemplo: Rodovia BR-158/MS. Via terciária: - Sem canteiro central entre as mãos (não duplicada); - mínimo 1 faixas por sentido; - sem acostamento; - exemplo: Rodovia BR-262/MS. Isso é um exemplo de uma classificação simples, mas clara. IVALDO ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br [1] -- Flávio Bello Fialho bello.fla...@gmail.com Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- wille http://wille.blog.br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Fände es ja schön wenn auch alle meine Fragen beantwortet werden. Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu sein und auf meine Vorschläge wird sich gar nicht erst eingelassen Am 15.04.2015 um 09:27 schrieb Alexander Matheisen: On Di, 2015-04-14 at 22:34 +0200, fly wrote: Am 14.04.2015 um 21:13 schrieb Michael Reichert: Am 2015-04-14 um 19:43 schrieb fly: railway:signal:main:state:forward=* Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Nein, nur meiner Logik entsprungen. du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang sei, oder wie soll ich das jetzt verstehen? Naja, war ja ein Volltreffer und wie willst Du es denn anders interpretieren ohne die fehlenden Information der Sonderbehandlung ? Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal:TYP:state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene Richtungen eingetragen werden können, würde die Tags noch komplizierter machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass immer die Richtung im Tag benötigt wird. Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der Richtung soll dann Schluß sein ? Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir können jedes Signal einzeln eintragen. Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter auf diversen Kanälen diskutiert und sowohl für Mapper als auch die Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. Zumindest Links wären dann wohl angebracht. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor du solchen Unsinn schreibst. Siehe zB :lanes-Tagging Was ist bitte an folgendem Beispiel Unsinn ? railway=signal signal:main=* state=* height=* ref=* direction=95 Lektüreempfehlung: http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert für Nicht-Bahnaffine. Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und versuche dann mein Glück Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. Wenn du ein wenig im Internet recherchieren würdest, würdest du recht schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter Anfang, ebenso die auf den ORM-Wikiseiten bei jedem Signal vorhandenen Links zu weiterführenden Informationen. Wenn du dennoch damit überfordert bist, dann lass es doch einfach. Es zwingt dich doch niemand, Bahnsignale einzutragen. Genau, es sind alles Links zu externen Seiten, und auch dort nur Fachabkürzungen und weitere Links. Zu den Beispielen am Ende habe ich schon Kommentare abgegeben. Das ist mir alles doch recht dürftig und absolut nicht für eine größere Gemeinschaft geeignet. Unter solchen Voraussetzungen frage ich mich halt warum das alles in OSM soll. TMC wurde ja schon erwähnt als abschreckendes Beispiel. fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-ro] Copaci adaugai in mod agresiv pe harta
Nerelevant... Atata vreme cat tagurile exista si au fost create de catre creatorii osm, nu conteaza cat de des sunt folosite. Ca nu au fost folosite suficient de mult, asta denota lipsa de cunostinte, lipsa de interes etc. Si Rares, nu trebuie sa imi demonstrezi mie nimic... O zi buna, Razvan On 15.04.2015 15:56, Filip Chirita Rares Cristian wrote: Lista completa de taguri OSM se poate gasi aici: https://taginfo.openstreetmap.org/ Dupa cum puteti vedea din cloud-ul acela imens de taguri, desi Highway e proeminent, in jur de 75% din tagurile de pe langa *nu *au legatura cu rutarea sau drumurile. De fapt, sunt sigur ca daca ai vedea toate datele din spatele OSM, ai fi foarte enervat. Momentan, pe tine te enerveaza ca poti vedea copaceii pe OSM.ORG http://OSM.ORG, ceea ce nu e decat modul in care e creat engineul de randare Mapnik. Din nou, daca vrei sa vezi alte exemple de harti, fara copaci, exista multe alte alternative. Rares 2015-04-15 14:29 GMT+03:00 Alex Morega a...@grep.ro mailto:a...@grep.ro: Poți face multe lucruri cu datele din OSM. De exemplu, eu am făcut un set de hărți cu trasee montane[1], și îmi prinde bine că sunt multe informații care nu au legătură cu rutarea pe șosele: poteci montane, cabane, refugii, vârfuri, șei, râuri, landcover complet. Mă bate gândul să afișez și liniile de înaltă tensiune, pot fi utile la orientare. Tot ce vezi pe harta aia provine din OSM, mai puțin curbele de nivel, care într-adevăr nu își găsesc locul acolo. -- Alex [1] http://haihui.grep.ro On 15 Apr 2015, at 14:14, Rădulescu Răzvan radulescu.raz...@gmail.com mailto:radulescu.raz...@gmail.com wrote: Daca nu exista intentia sa se foloseasca si pentru rutare, atunci nu mai existau taguri de limita de viteza, de surface , de nr. lane, etc. Nu mai exista intentia ca aceste taguri sa fie diversificate tocmai pentru putea ajusta cat mai mult posibil rutarea si din partea hartii, nu numai a navigatoarelor. Rutarea pe aceasta harta este ca si cireasa de pe tort. Majoritatea celor care o cauta, o cauta sa o utilizeze pe diferite navigatoare, nu ca un simplu atlas. Pana si diferite firme de taxi acum utilizeza osm... On 15.04.2015 12:14, Filip Chirita Rares Cristian wrote: OSM este o baza de date, nu un engine de rutare. Baietii care fac engine-urile si hartile respective se vor asigura ca nu arata copacii. Daca intri pe hartile de la ITO World sau Stamen, de exemplu, vei vedea putine harti care arata copaci, pentru ca au filtrat informatia. The more data, the better, cat timp informatia e luata calumea (survey sau surse acceptate) si introdusa calumea. Rares 2015-04-15 10:02 GMT+03:00 Ciprian Talaba cipriantal...@gmail.com mailto:cipriantal...@gmail.com: Anatolie are dreptate, OSM este o baza de date geografica, nu o harta: We would encourage users to contribute their data and knowledge to OpenStreetMap, project with free geographic data for the world (de aici: https://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service) Harta care o vedem pe osm.org http://osm.org este un produs generat pe baza acestor date, *dupa* ce acestea au fost filtrate. Acelasi lucru este valabil pentru orice motor de rutare bazat pe OSM, va folosi doar acele informatii necesare, deci nu vad unde este problema cu adaugarea copacilor. Ba chiar incurajez acest lucru atat timp cat informatia este corecta. --Ciprian 2015-04-15 9:40 GMT+03:00 lulumob lulu...@gmail.com mailto:lulu...@gmail.com: Salutare! Ma simt si eu cu musca pe caciula pentru zona asta: http://www.openstreetmap.org/#map=17/47.01160/27.44100 https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=!3m4!1e1!3m2!1s5Ff16tmOqBadNX6jN-e19w!2e0?hl=ro https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=%213m4%211e1%213m2%211s5Ff16tmOqBadNX6jN-e19w%212e0?hl=ro Si mie mi se pare cam exagerat ce s-a facut in Bucuresti, in sensul ca s-a pus carul in fata boilor. Sunt multe lucruri mai importante care lipsesc. Pe de alta parte, cred ca orice informatie corecta e utila si ca, intr-adevar, ar trebui ca softul sa filtreze ceea ce e inutil. Daca vreau navigatie pentru masina poate nu ma intereseaza copacii, daca fac geocaching poate nu ma intereseaza soselele. Exagerez putin, dar ideea cred ca se intelege. Si eu am mai marcat candva tomberoane de gunoi, banci, stalpi, lumini stradale si tot felul de lucruri mai putin importante, dar am facut-o ca exercitiu, constient ca utilitatea pentru majoritatea utilizatorilor e scazuta. Pentru un biciclist ca mine, insa, un stalp sau un copac pe o campie poate fi un reper important. Sunt
Re: [Talk-us] PennLive.com using OSM without attribution?
Just received an email from nick the writer of the article saying he would take care of it today. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* On Tue, Apr 14, 2015 at 10:26 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: I sent him a email, i'll let you know when i get a reply. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* On Tue, Apr 14, 2015 at 6:27 PM, James Mast rickmastfa...@hotmail.com wrote: http://www.pennlive.com/projects/2015/pa-turnpike-tunnels/ Just happened to see this article talking about the future of the Allegheny Tunnels along the PA Turnpike (I-76/I-70). About 2/3rd down in the article, they have a screenshot of OSM there showing the possible new alignments for the PA Turnpike. My question is, is this allowed with the current license, or do they still need to have the attribution on the image (or right below it)? If somebody that is more knowledgeable in this would like to contact them about this if they are in the wrong, please, be my guest. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [Talk-us] PennLive.com using OSM without attribution?
Just received an email from nick the writer of the article saying he would take care of it today. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* On Tue, Apr 14, 2015 at 10:26 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: I sent him a email, i'll let you know when i get a reply. *Regards,* *Hans* *http://www.openstreetmap.org/user/TheDutchMan13 http://www.openstreetmap.org/user/TheDutchMan13* On Tue, Apr 14, 2015 at 6:27 PM, James Mast rickmastfa...@hotmail.com wrote: http://www.pennlive.com/projects/2015/pa-turnpike-tunnels/ Just happened to see this article talking about the future of the Allegheny Tunnels along the PA Turnpike (I-76/I-70). About 2/3rd down in the article, they have a screenshot of OSM there showing the possible new alignments for the PA Turnpike. My question is, is this allowed with the current license, or do they still need to have the attribution on the image (or right below it)? If somebody that is more knowledgeable in this would like to contact them about this if they are in the wrong, please, be my guest. -James ___ Talk-us mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Classificação de rodovias no Brasil
2015-04-15 12:30 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Da última vez, concordamos em rebaixar a classificação quando a estrutura for precária, mas não parece ser esse o caminho seguido pelas outras comunidades pelo mundo. Talvez os outros países não tenham tanta diversidade quanto aqui. Temos estradas ótimas e estradas péssimas. Utilizar critério de importância (que é bem subjetivo) vai igualar estrada boa com estrada ruim; critério de administração da via (federal, estadual, municipal) vai, novamente, igualar rodovias boas com ruins. Da forma que vejo utilizar características físicas (que é o acordo de cavalheiros a que chegamos anteriormente) é o que melhor encaixa no Brasil, tanto é que o DNIT usa esse critério em seus mapas, assim como os mapas comerciais. Mesmo não tendo legenda, conseguimos identificar no Google Maps, Bing, Here, etc o que é uma via que oferece melhores condições de trafegar. Reparem que locais que são mapeados com a nossa convenção atual ficam muito próximos do DNIT e dos mapas comerciais. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
2015-04-15 11:35 GMT-03:00 wille wi...@wille.blog.br: Assim, não tem nada a ver com o fato da rodovia ser federal ou não. Eu prefiro que continuemos usando o padrão que definimos no passado e que está bastante claro para rodovias, apesar de ser ainda nebuloso para vias urbanas. Já que tem bastante gente interessada, também acho que os próximos 6 meses (é sério quando falo isso) devem ser gastos com as vias urbanas, mantendo o que já foi discutido antes sobre as rodovias. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
Eu concordo que não devemos sair mudando classificações enquanto debatemos (o lugar ideal seria o fórum, eu tentei mais ninguém quis continuar o debate lá, ele sempre acaba aqui na talk-br), mas um problema de que não podemos fugir no longo prazo é o de como a classificação urbana e a interurbana devem se corresponder/combinar, ou seja, de como esses dois sistemas se conectam. Se optamos por critérios estruturais para decidir a classificação intermunicipal, então por que é importante poder representar no mapa uma trunk ou uma primary sem pavimentação? [1] Ou seria isso uma contradição? O problema é que nossas ferramentas atualmente não prevêm essa combinação. Deveriam prever? Se não prevêm e deveriam, isso deveria afetar nossa forma de classificar? Da última vez, concordamos em rebaixar a classificação quando a estrutura for precária, mas não parece ser esse o caminho seguido pelas outras comunidades pelo mundo. Ontem descobri uma ferramenta usada pelo Partido Pirata para tomar decisões de forma colaborativa, o Loomio (https://www.loomio.org/). Quem sabe poderíamos usar pra essa discussão. Eu acho que a classificação africana tem muito a contribuir nesse debate. Mas ela não cita qual o critério pras vias trunk, apenas motorways e depois de primary em diante. Mesmo assim, há várias trunk mapeadas. O que ela cita é um critério de conectividade (é recorrente esse tipo de critério em outros pontos do wiki do OSM): primárias conectam cidades grandes, secundárias conectam essas cidades às capitais regionais, terciárias conectam pequenos povoados e são as principais vias urbanas. De novo, o critério importante fica subjetivo - é difícil o pessoal do HOT, à distância, saber quão relevante a via realmente é localmente, não acha? A menos que se julgue pela pavimentação ou pela largura da via ou pelo seu comprimento, que são aspectos visíveis na imagem do satélite, ou que se tenha uma referência oficial (o lugar ideal pra guardá-la seria o wiki, pra que mais gente possa consultar). Mas enfim. Talvez o que precisamos discutir é quais coisas cada via deve conectar para ser considerada importante. Mas melhor ainda seria se a nossa classificação urbana magicamente correspondesse às classificações urbanas publicadas pelas prefeituras, daí teríamos uma fórmula que se aplicaria aos municípios que não publicam tal classificação. [1] https://github.com/gravitystorm/openstreetmap-carto/issues/110 2015-04-15 11:57 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2015-04-15 11:35 GMT-03:00 wille wi...@wille.blog.br: Assim, não tem nada a ver com o fato da rodovia ser federal ou não. Eu prefiro que continuemos usando o padrão que definimos no passado e que está bastante claro para rodovias, apesar de ser ainda nebuloso para vias urbanas. Já que tem bastante gente interessada, também acho que os próximos 6 meses (é sério quando falo isso) devem ser gastos com as vias urbanas, mantendo o que já foi discutido antes sobre as rodovias. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
Oi, Fernando O esquema africano de classificação de rodovias leva em conta a importância socioeconômica da rodovia e não sua infraestrutura: http://wiki.openstreetmap.org/wiki/Highway_Tag_Africa Assim, não tem nada a ver com o fato da rodovia ser federal ou não. Eu prefiro que continuemos usando o padrão que definimos no passado e que está bastante claro para rodovias, apesar de ser ainda nebuloso para vias urbanas. abraços, wille Em 2015-04-15 11:12, Fernando Trebien escreveu: Acho que algumas das nossas concepções sobre a classificação vão mudar quando o Carto (estilo oficial do OSM) passar a diferenciar as vias pavimentadas das não-pavimentadas, independente da sua classificação. Daqui a 12 dias (na próxima atualização do Debian) vou conseguir propor estilos gráficos para isso (ninguém fez realmente uma prova de conceito até agora, só alguns esboços) e quem sabe com isso o debate ande. Me parece que nossos vizinhos latino-americanos e africanos estão classificando todas as rodovias federais como trunk, independente da sua estrutura física ou do tipo de projeto. Basta dar uma olhada no mapa com nível de zoom 5 para ver isso: http://www.openstreetmap.org/#map=5/7.733/3.032 2015-04-13 16:30 GMT-03:00 Flavio Bello Fialho bello.fla...@gmail.com: Eu odeio esse assunto. Desde que eu entrei no OSM, ele sempre volta pelo menos uma vez por ano. O que mais me incomoda é que as discussões são longas, tomam tempo que podia ser melhor gasto em outras coisas e acabam não progredindo muito. Não é culpa de ninguém. É um assunto importante, mas cansativo. Não existe consenso. O artigo no wiki demonstra isso. Eu gostaria que existisse, mas não existe. Não existe nem consenso sobre o que é consenso nessa questão. Infelizmente, eu me sito obrigado a participar dessa discussão cada vez que ela aparece, porque ela afeta diretamente o meu trabalho no OSM. Acho que o mapa do Brasil não está maduro o suficiente para tomarmos uma decisão definitiva sobre a classificação de vias. No fim, quem trabalha no mapa vai ter que decidir conforme a sua consciência. Sugiro que não foquem o trabalho apenas na classificação, e sim em outras coisas mais críticas, como mapear as rodovias que não existem no mapa ou colocar as que existem no lugar certo (os dados importados do IBGE estão muito toscos), ou mapeando corretamente os cruzamentos e restrições de conversão, que também são importantes para o roteamento. Se for possível incluí-los, os tags lanes, maxspeed e surface podem ajudar bastante na classificação das rodovias no futuro (ou não, dependendo do critério; nesse caso, eles se tornariam ainda mais importantes). À medida que forem fazendo isso, se quiserem, ajustem a classificação das rodovias que forem editadas da forma que acharem melhor. Muita paz para todos. Espero ter contribuído com alguma coisa e desculpe se, por algum motivo, alguém se sentir incomodado com o meu comentário. Em 12 de abril de 2015 01:46, Gilmar Ferreira gilmar.al...@gmail.com escreveu: Concordo que o artigo seja editado para refletir mais claramente o que já é consensual na comunidade. Para alguém que está começando na comunidade, e eu estou começando, o artigo está confuso: não ficou muito claro o que era consensual. Gilmar Em sáb, 11 de abr de 2015 16:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Até onde me consta, o último debate amplo da comunidade que gerou consenso é o que consta na segunda seção deste artigo: [1] Esta seção foi primariamente editada por mim na época, sempre pedindo que a comunidade revisasse e criticasse, e fiz questão de apontar para as discussões na lista e inclusive de reconhecer publicamente aquilo que a comunidade considerou como erros meus, para que todos soubessem até que ponto devem interpretar essas recomendações de forma literal. O artigo foi recentemente editado pelo usuário Fbello [2], que participou das discussões sobre esse assunto aqui na lista. Ele colocou no topo do artigo uma tabela cuja origem eu desconheço e que não consta nos comentários de edição do wiki. Se é uma proposta, deveria ter escrito que é uma proposta, e não dar a entender que é o consenso da comunidade. Se ninguém se opuser, eu gostaria de mover essa seção para baixo e de listá-la como proposta em debate. Essas páginas principais do wiki deveriam ser tratadas como local de conhecimento consolidado, não como ponto de disputa ideológica. O critério por consenso para que uma via seja considerada expressa é o seguinte: (estou lendo direto do fluxograma no artigo) 1. Seja duplicada - tenha predominantemente pelo menos 2 faixas por sentido (pode ter 1 só em alguns poucos trechos curtos) 2. Tenha uma separação central entre as duas mãos - pode ser um canteiro, uma defensa, ou (em teoria, mas nunca vi na prática) até mesmo certos tipos de tartarugas [3] 3. Possua semáforos ou interseções em nível (aquelas que fazem o fluxo que entra/sai/atravessa a via parar completamente até conseguir
[Talk-de] Schreibfehler in deutschem Copyright-Text
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Im deutschsprachigen Text von http://www.openstreetmap.org/copyright ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite www.openstretmap.org/copyright (ein e zuwenig in der street) angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten und allgemein: Wo kann man einen solchen Fehler melden oder direkt korrigieren? Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB 0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179 GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV IAYdXXF7thBp//wR4bOV =2VNC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Association OSMfr pour réserve citoyenne ?
Bonjour, Je reprends ce vieux fil après avoir creusé la question, résultat de ma recherche : http://wiki.openstreetmap.org/wiki/R%C3%A9flexion_pour_agr%C3%A9ment_en_tant_qu%27association_%C3%A9ducative A discuter à l'occasion de la réunion parisienne du 24, si vous le voulez. Jean-Marc : tu indiquais essayer de voir avec un contact chez Wikimedia-fr pour récupérer leur dossier. Cette piste a t'elle débouchée ? Je suis preneur de leur dossier, cela pourrait être intéressant car comme nous je ne pense pas qu'ils puissent montrer un historique et un périmètre d'action si étendu que cela. PI, l'agrément de Wikimedia-fr est tout récent : http://www.zdnet.fr/actualites/wikimedia-france-agreee-association-educative-par-l-ducation-nationale-39808183.htm Brice Le 10/02/2015 15:44, Jean-Marc Gailis - Janis Marks Gailis a écrit : Je vais essayer de voir avec un contact chez Wikimedia-fr pour récupérer leur dossier. Jean-Marc Gailis Le 10 février 2015 à 15:19, Christian Quest cqu...@openstreetmap.fr a écrit : A première vue, ça me semble une bonne idée. Vincent et/ou Brice, vous voulez dégrossir le sujet ? Le 10/02/2015 14:53, Vincent Bergeot a écrit : Le 10/02/2015 09:03, Brice MALLET a écrit : Une démarche officielle de la part de l'association vous semble t'elle possible ? Si oui, en profiter pour engager une démarche de demande d'agrément (http://www.education.gouv.fr/cid21129/les-associations-agreees-et-ou-subventionnees-par-l-education-nationale.html) on peut voir que wikimedia france est référencée dans la liste des associations agréées au niveau national. On peut donc supposer (si c'est un raccourci désolé) que OSM-fr peut démarcher pour la demande d'agrément de part les similitudes entres les projets (je sais qu'il y a des différences aux niveaux des associations : employeuse pour wikimedia-fr et non employeuse pour OSM-fr). Si il doit y avoir une demande, n'est-il pas possible de récupérer le dossier de wikimedia-france et de l'adapter ? (à quand un wiki des demandes de subventions et dossiers :) ) Concernant l'intérêt de l'agrément : cela facilite la possibilité d'intervenir en classe et c'est une reconnaissance par l'éducation nationale (AMHA pas de subventions possible). Bonne journée -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Association OSMfr pour réserve citoyenne ?
On 2015.04.15. 18:14, Brice MALLET wrote: Jean-Marc : tu indiquais essayer de voir avec un contact chez Wikimedia-fr pour récupérer leur dossier. Cette piste a t'elle débouchée ? Malheureusement, je me suis heurté à un refus. Jean-Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] Classificação de rodovias no Brasil
Eu concordo que devemos manter a recomendação atual por pelo menos mais 1 ano, mas não acho que devemos nos privar de discutir o que seria o mundo ideal - aquele em que as ferramentas fazem tudo aquilo que nós, mapeadores e usuários do mapa no dia-a-dia, queremos que elas façam. Até porque isso poderia dar origem a uma recomendação de uma etiqueta do tipo future_highway=* onde colocaríamos a classificação da via num futuro próximo. Vou lançar ideias, que não tive tempo de melhorar porque não consegui ainda os planos diretores da maioria das capitais. Se nós mapeássemos algumas vias não-pavimentadas como trunk em certas situações, mas elas fossem desenhadas de outra forma no mapa e os roteadores as evitassem por não serem pavimentadas, estaríamos nos preocupando com a sua classificação elevada? Preferiríamos atribuir a elas sua importância simbólica/futura/pretendida pelo governo ou ficar com a sua importância atual? O melhor caminho entre São Paulo e Georgetown, na Guiana, é por uma sequência de BRs (262, 163, 364, 319, 174 e 401) ligando algumas capitais (Campo Grande, Cuiabá, Porto Velho, Manaus, Boa Vista). Não deveriam essas vias aparecer no mapa no nível 5, quando se vê o país inteiro de uma vez só, mesmo que não fossem pavimentadas? (na verdade elas são, mas poderiam não ser) Em outros países vizinhos e mesmo na África, vias trunk aparecem nesse nível e conectam cidades que são bem menos importantes, mesmo sob uma ótica regional. Mas a ferramenta tem que saber o que desenhar... é factível exigir isso, ou seria uma análise complexa demais para a ferramenta? A quais das seguintes características a noção de importância está mais atrelada então? 1. Número de pessoas que usam a via 2. Capacidade/qualidade da via (quase sempre, mas nem sempre, relacionada à anterior) 3. Número de pessoas que poderiam vir a usar a via = número de pessoas nas localidades que a via conecta 4. Quão ricas essas pessoas são, ou quão forte é a economia na área (importante descartarmos isso como critério ao discutir a classificação urbana, se é que concordamos em descartá-lo) 5. Se o local tem valor histórico ou não, mesmo que seja afastado (ex.: ruínas no meio da floresta) 6. [escreva sua noção aqui] Acho o critério 3 interessante, especialmente para estabelecer uma similaridade de importância entre povoado (place=village) e bairro (place=suburb), ambos tipicamente têm o mesmo número de pessoas e, segundo mais de um sistema de classificação por aí, implicariam que suas principais vias de acesso são highway=secondary. Se você subir para o nível municipal, você teria highway=primary como as conexões entre as cidades grandes (place=town/city). Dentro das cidades, as primárias seriam as continuações dessas conexões até o seu núcleo. Onde fica o núcleo seria discutível, na maioria dos casos é quase óbvio (geralmente uma avenida principal que se liga às rodovias na entrada da cidade, ou um grande entroncamento numa cidade grande), em outros não. Talvez as cidades possam ter mais de um núcleo - seria interessante discutir isso. Mas o mais legal dessa abordagem é que ela não pressupõe uma diferença entre meio urbano e meio rural, nem mesmo as condições das vias, apenas a localização dos núcleos populacionais e os principais caminhos entre eles. 2015-04-15 12:52 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2015-04-15 12:30 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Da última vez, concordamos em rebaixar a classificação quando a estrutura for precária, mas não parece ser esse o caminho seguido pelas outras comunidades pelo mundo. Talvez os outros países não tenham tanta diversidade quanto aqui. Temos estradas ótimas e estradas péssimas. Utilizar critério de importância (que é bem subjetivo) vai igualar estrada boa com estrada ruim; critério de administração da via (federal, estadual, municipal) vai, novamente, igualar rodovias boas com ruins. Da forma que vejo utilizar características físicas (que é o acordo de cavalheiros a que chegamos anteriormente) é o que melhor encaixa no Brasil, tanto é que o DNIT usa esse critério em seus mapas, assim como os mapas comerciais. Mesmo não tendo legenda, conseguimos identificar no Google Maps, Bing, Here, etc o que é uma via que oferece melhores condições de trafegar. Reparem que locais que são mapeados com a nossa convenção atual ficam muito próximos do DNIT e dos mapas comerciais. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[OSM-talk-fr] Fwd: PROPOSITION DE TAGS POUR LES TRACES GPS
-- Message transféré -- De : FOFANA BAZO BAGNOUMANA fofana.13b...@gmail.com Date : 15 avril 2015 15:45 Objet : PROPOSITION DE TAGS POUR LES TRACES GPS À : Discussions sur OSM en français talk-fr@openstreetmap.org Bonsoir à tous, Nous avons récupérer une grande quantité de traces gps sur le Togo, et souhaiterions les uploader après nettoyage dans la base osm. Mais une question/préoccupation nous es revenue et nous aimerions avoir l'avis des uns et des autres sur cela. Lors de l'envoi, il nous est proposé 1_une fenêtre pour l'attribut, et avec les amis, nous avons suggérer procéder de la sorte Nom du pays,région administrative,préfecture. 2_Dans la fenêtre description nous avons choisi point de départ_point d'arrivée. Explication: la description se rapporte au nom de la dernière entité administrative dans laquelle la collecte à été effectuée. Que pensez-vous cette procédure?? -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am Mittwoch, 15. April 2015, 15:00:40 schrieb fly: Fände es ja schön wenn auch alle meine Fragen beantwortet werden. Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu sein und auf meine Vorschläge wird sich gar nicht erst eingelassen Wie es in den Wald schallt… Für meinen Geschmack nehmt ihr euch da beide nichts. Es sind diverse Gegenargumente gekommen, auf die auch nicht wirklich eingegangen wurde. Ich persönlich bin da eher leidenschaftslos, und am Tagging-Schema auch nicht beteiligt gewesen, also versuche ich es jetzt nochmal von neutraler Seite aus. Wenn hier beiden Seiten die Lust am Diskutieren vergeht kann ich es aber vollkommen verstehen, als wirklich konstruktiv habe ich nur wenige Teile der ganzen Diskussion empfunden. Am 15.04.2015 um 09:27 schrieb Alexander Matheisen: On Di, 2015-04-14 at 22:34 +0200, fly wrote: Am 14.04.2015 um 21:13 schrieb Michael Reichert: Am 2015-04-14 um 19:43 schrieb fly: railway:signal:main:state:forward=* Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Nein, nur meiner Logik entsprungen. du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang sei, oder wie soll ich das jetzt verstehen? Naja, war ja ein Volltreffer und wie willst Du es denn anders interpretieren ohne die fehlenden Information der Sonderbehandlung ? Ich kann mich Michaels Verwunderung hier nur anschließen. Warum soll man virtuelle Probleme diskutieren, wenn du doch genug echte Probleme ausgemacht haben willst? Lasst uns dann doch auch bitte realitätsnahe Probleme diskutieren, Streitpunkte gibt es ja scheinbar genug, das man nicht noch unnötig neue erfinden muss. Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal:TYP:state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene Richtungen eingetragen werden können, würde die Tags noch komplizierter machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass immer die Richtung im Tag benötigt wird. Die Richtung würde nur dann nicht benötigt, wenn in beide Richtungen das gleiche Signalbild gezeigt würde. Das ist so unwahrscheinlich, das man es völlig ignorieren kann. Also braucht es immer die Richtung. Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der Richtung soll dann Schluß sein ? Es gibt zwei Möglichkeiten: 1) beides an einem Node, dann heißt das jeweil eine Tag-Ebene mehr. Fände ich prinzipiell auch gut, weil es z.B. Schneepflug-Signale gibt, die quasi ausschließlich im Doppel auftreten: ein Mast, an einer Seite steht hoch, an der anderen Seite runter. Wenn man das sinnvoll vereinheitlichen kann: gerne, immer her damit. Wie würdest du denn so ein Signal eintragen? Hier siehst du sowas bildlich: http://walter-klan.de/signale/08)_ne-signale.html#Ne_7 2) 2 Nodes wie gehabt. Kürzere Tags, dafür liegt das halt nicht direkt übereinander. [Signalrelationen] Zumindest Links wären dann wohl angebracht. Kann ich mir nichts drunter vorstellen, insofern würde ich das auch lesen. Nach meiner Erfahrung ist aber alles, was man ohne Relation erschlagen kann, ein Gewinn. associatedStreet ist schon schlimm genug, da muss man nicht noch mehr von dem Zeug erfinden. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor du solchen Unsinn schreibst. Siehe zB :lanes-Tagging Was ist bitte an folgendem Beispiel Unsinn ? railway=signal signal:main=* state=* height=* ref=* direction=95 -es sollte IMHO tatsächlich states und nicht state sein, denn es gibt die Gesamtmenge der
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
You can also see how others are tagging Sanitary Dumps: http://www.sanidumps.com/maps/index.php?id=18 --- The top level tags sanitary_dump_station are enough for rendering. However someone with a given style of boat or motorhome can use use only some of the sites. They may have boat holding tank needing a pumpout, a boat or motorhome with a cassette, or a motorhome with a gravity fed hose. These are incompatible systems. A given site may accept one, two or three of the systems. A given site may restrict or even ban tank holding chemicals, but these rules are complex and hard to tag. I prefer just a warning that a given site may have a restriction that needs to be checked locally. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-be] How to create a map from OSM with QGIS - Comment créer une carte à partir d'OSM avec QGIS
I downloaded the boundary files from [1] and when I opened them the aspect ratio's where not what I expected due to the incorrect projection I had to manually change the projection to the correct one. regards m [1] https://osm.wno-edv-service.de/boundaries/ On Wed, Apr 15, 2015 at 6:47 PM, Marc Ducobu marc.duc...@gmail.com wrote: What is the problem ? On 15 April 2015 at 18:47, Marc Ducobu marc.duc...@gmail.com wrote: No I didn'nt do something special. On 13 April 2015 at 10:06, Marc Gemis marc.ge...@gmail.com wrote: Thanks a lot ! When I did some experiments with QGIS, I was struggling with the projection. Did you had to do anything special ? regards m On Mon, Apr 13, 2015 at 9:52 AM, Marc Ducobu marc.duc...@gmail.com wrote: Hello, I write a tutorial explaining how to create a map with QGIS and the OSM data. For this work I create a QGIS style that highlight the cyclist infrastructure. The idea is to invite cyclists at the map party, show them the map at the beginning of the party and at the end show them the improved map. For the moment the tutorial is in french : http://blog.champs-libres.coop/carto/2015/04/10/creer-une-carte-cycliste-avec-osm-et-qgis.html and if I have the time I will translate it in english. The QGIS is on github : https://github.com/Champs-Libres/QGIS-OSM-styles. Feel free to use it and improve it ! - - - - - Salut, J'ai écrit un tutorial expliquant comment créer une carte avec QGIS à partir des données OSM ( http://blog.champs-libres.coop/carto/2015/04/10/creer-une-carte-cycliste-avec-osm-et-qgis.html ). La carte met en avant certaines infrastructures cyclistes. L'idée est de l'utiliser lors de la mapping party de bxl : montrer l'état de la carte avant l'événement, améliorer les données OSM et le voir sur la carte. Les styles QGIS se trouvent sur github https://github.com/Champs-Libres/QGIS-OSM-styles, n'hésitez pas à l'utiliser et pourquoi pas à l'améliorer ! Marc ___ 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 -- et en avant pour de folles aventures... -- et en avant pour de folles aventures... ___ 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: [Talk-de] Schreibfehler in deutschem Copyright-Text
Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei Google. Auf welcher Seite ist der Original-Fehler? (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link) Volker 2015-04-15 19:03 GMT+02:00 Mark Obrembalski m...@obrembalski.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Im deutschsprachigen Text von http://www.openstreetmap.org/copyright ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite www.openstretmap.org/copyright (ein e zuwenig in der street) angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten und allgemein: Wo kann man einen solchen Fehler melden oder direkt korrigieren? Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB 0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179 GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV IAYdXXF7thBp//wR4bOV =2VNC -END PGP SIGNATURE- ___ 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-lt] Užmiršti žemėlapiai : Open Street Maps
http://www.radiocool.lt/uzmirsti-zemelapiai-open-street-maps/ ___ Talk-lt mailing list Talk-lt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lt
Re: [OSM-talk-fr] Fwd: PROPOSITION DE TAGS POUR LES TRACES GPS
De mon point de vue, la localisation et les points de départ et d'arrivée ne sont pas super importants puisque ces infos sont contenues dans la trace gpx. En revanche, indiquer le matériel utilisé pour l'enregistrement de la trace, ainsi que le mode de locomotion, me semble utile. Stf Le 15/04/2015 18:02, FOFANA BAZO BAGNOUMANA a écrit : -- Message transféré -- De : *FOFANA BAZO BAGNOUMANA* fofana.13b...@gmail.com mailto:fofana.13b...@gmail.com Date : 15 avril 2015 15:45 Objet : PROPOSITION DE TAGS POUR LES TRACES GPS À : Discussions sur OSM en français talk-fr@openstreetmap.org mailto:talk-fr@openstreetmap.org Bonsoir à tous, Nous avons récupérer une grande quantité de traces gps sur le Togo, et souhaiterions les uploader après nettoyage dans la base osm. Mais une question/préoccupation nous es revenue et nous aimerions avoir l'avis des uns et des autres sur cela. Lors de l'envoi, il nous est proposé 1_une fenêtre pour l'attribut, et avec les amis, nous avons suggérer procéder de la sorte Nom du pays,région administrative,préfecture. 2_Dans la fenêtre description nous avons choisi point de départ_point d'arrivée. Explication: la description se rapporte au nom de la dernière entité administrative dans laquelle la collecte à été effectuée. Que pensez-vous cette procédure?? -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF ___ 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-de] Schreibfehler in deutschem Copyright-Text
Am 15.04.2015 um 19:24 schrieb Volker Schmidt: Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei Google. Auf welcher Seite ist der Original-Fehler? (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link) Wie Mark es korrekt schreibt: Die Zielseite enthält den Schreibfehler im _Text_ : Zitat: Du kannst dies tun, indem du auf www.openstretmap.org/copyright http://www.openstreetmap.org/copyright verlinkst. Der dahinterliegende Link ist allerdings korrekt. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-fr] Association OSMfr pour réserve citoyenne ?
Bonjour, je n'ai pas beaucoup avancé. Cependant, j'ai évoqué la question avec un conseiller pédagogique et on peut sans doute voir pour une entrée par des agréments académiques quand il y a des interventions osm en milieu scolaire, pour appuyer un agrément national. Toujours intéressé, merci pour la page wiki, je n'y avais pas pensé :( Brice MALLET a écrit : Bonjour, Je reprends ce vieux fil après avoir creusé la question, résultat de ma recherche : http://wiki.openstreetmap.org/wiki/R%C3%A9flexion_pour_agr%C3%A9ment_en_tant_qu%27association_%C3%A9ducative A discuter à l'occasion de la réunion parisienne du 24, si vous le voulez. Jean-Marc : tu indiquais essayer de voir avec un contact chez Wikimedia-fr pour récupérer leur dossier. Cette piste a t'elle débouchée ? Je suis preneur de leur dossier, cela pourrait être intéressant car comme nous je ne pense pas qu'ils puissent montrer un historique et un périmètre d'action si étendu que cela. PI, l'agrément de Wikimedia-fr est tout récent : http://www.zdnet.fr/actualites/wikimedia-france-agreee-association-educative-par-l-ducation-nationale-39808183.htm Brice Le 10/02/2015 15:44, Jean-Marc Gailis - Janis Marks Gailis a écrit : Je vais essayer de voir avec un contact chez Wikimedia-fr pour récupérer leur dossier. Jean-Marc Gailis Le 10 février 2015 à 15:19, Christian Quest cqu...@openstreetmap.fr a écrit : A première vue, ça me semble une bonne idée. Vincent et/ou Brice, vous voulez dégrossir le sujet ? Le 10/02/2015 14:53, Vincent Bergeot a écrit : Le 10/02/2015 09:03, Brice MALLET a écrit : Une démarche officielle de la part de l'association vous semble t'elle possible ? Si oui, en profiter pour engager une démarche de demande d'agrément (http://www.education.gouv.fr/cid21129/les-associations-agreees-et-ou-subventionnees-par-l-education-nationale.html) on peut voir que wikimedia france est référencée dans la liste des associations agréées au niveau national. On peut donc supposer (si c'est un raccourci désolé) que OSM-fr peut démarcher pour la demande d'agrément de part les similitudes entres les projets (je sais qu'il y a des différences aux niveaux des associations : employeuse pour wikimedia-fr et non employeuse pour OSM-fr). Si il doit y avoir une demande, n'est-il pas possible de récupérer le dossier de wikimedia-france et de l'adapter ? (à quand un wiki des demandes de subventions et dossiers :) ) Concernant l'intérêt de l'agrément : cela facilite la possibilité d'intervenir en classe et c'est une reconnaissance par l'éducation nationale (AMHA pas de subventions possible). Bonne journée -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Fwd: PROPOSITION DE TAGS POUR LES TRACES GPS
Ok merci, Mais est-ce que ces infos ne sont pas utiles pour des requêtes? On 15/04/2015 18:50, Stéphane Péneau wrote: De mon point de vue, la localisation et les points de départ et d'arrivée ne sont pas super importants puisque ces infos sont contenues dans la trace gpx. En revanche, indiquer le matériel utilisé pour l'enregistrement de la trace, ainsi que le mode de locomotion, me semble utile. Stf Le 15/04/2015 18:02, FOFANA BAZO BAGNOUMANA a écrit : -- Message transféré -- De : *FOFANA BAZO BAGNOUMANA* fofana.13b...@gmail.com mailto:fofana.13b...@gmail.com Date : 15 avril 2015 15:45 Objet : PROPOSITION DE TAGS POUR LES TRACES GPS À : Discussions sur OSM en français talk-fr@openstreetmap.org mailto:talk-fr@openstreetmap.org Bonsoir à tous, Nous avons récupérer une grande quantité de traces gps sur le Togo, et souhaiterions les uploader après nettoyage dans la base osm. Mais une question/préoccupation nous es revenue et nous aimerions avoir l'avis des uns et des autres sur cela. Lors de l'envoi, il nous est proposé 1_une fenêtre pour l'attribut, et avec les amis, nous avons suggérer procéder de la sorte Nom du pays,région administrative,préfecture. 2_Dans la fenêtre description nous avons choisi point de départ_point d'arrivée. Explication: la description se rapporte au nom de la dernière entité administrative dans laquelle la collecte à été effectuée. Que pensez-vous cette procédure?? -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF -- Fofana B. Bazo, Géographe, contributeur OpenStreetMap, Membre fondateur de la Communauté OSM_BF ___ 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-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-cz] Mapa historických objektů
Zdravím, s novou, krásnou a lehce zapamatovatelnou URL adresou si dovoluji představit projekt mapy historických objektů. Webová stránka je http://gk.historic.place/ , mapa ČR http://gk.historic.place/historische_objekte/translate/cs/index-cs.html Projekt si klade za cíl renderovat historické objekty - od výklenkových kapliček po hrady. K dispozici je i český překlad, který je možné upravovat na adrese https://wiki.openstreetmap.org/wiki/DE:Historical_Objects/Translations/table.cs . Jelikož se jedná původně o německý projekt, vychází se právě z němčiny, ovšem anglická verze je pro porovnání k nalezení zde https://wiki.openstreetmap.org/wiki/DE:Historical_Objects/Translations/table.en Vzhledem k tomu, že nejsem v této oblasti zcela kovaný, prosím o kontrolu a případnou revizi překladu. Má-li někdo možnost projekt více zviditelnit, určitě mu to neuškodí. Díky! :-) xkomczax ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [talk-au] Use of mapconnect data in OSM [SEC=UNCLASSIFIED]
On 15/04/15 23:14, Andrew Harvey wrote: On 15 April 2015 at 23:01, Ross i...@4x4falcon.com mailto:i...@4x4falcon.com wrote: The issue is not with the licence. The current terms and conditions require permission to add data not owned by the contributor. Is there a source for this statement? Go back to all the discussions in the 12 months prior to the licence change. This was one of the major sticking points for a number of contributors. I was under the assumption that in order to contribute data (whether your own or someone else's) into OSM, the data must comply with the contributor terms. Although the CTs agree to always give attribution, this (probably) still isn't compatible with the attribution required by CC-BY and the provide a link to the license and indicate if changes were made clauses of CC-BY. So my thinking is for data to be added to OSM under the current CTs it needs to waive these requirements of CC-BY and settle for attribution only (and perhaps a specific form of attribution). As you point out though this data is upto 8 years old and in many cases there is probably better or more current data available eg Tasmanian Estate Reserve. CAPAD is seems pretty good, http://www.environment.gov.au/fed/catalog/search/resource/details.page?uuid=%7B4448CACD-9DA8-43D1-A48F-48149FD5FCFD%7D ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-it] open expo 2015
Ci ha pensato Pab09 http://www.openstreetmap.org/user/Pab09 img src=http://gis.19327.n5.nabble.com/file/n5840765/20150416_Selezione_001.png; border=0 alt=aggiornamento mappa expo/ http://www.openstreetmap.org/changeset/30131290 - - Le ultime dal mio blog: Perchè una mappa degli alberi? -- View this message in context: http://gis.19327.n5.nabble.com/open-expo-2015-tp5817169p5840765.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] open expo 2015
Io intanto ho recuperato questa mappa FRONTE https://drive.google.com/file/d/0BytcIAPEPdQxNWI4dTZGblUzZFE/view?usp=sharing e RETRO https://drive.google.com/file/d/0BytcIAPEPdQxNmFNczllT0hIMFk/view?usp=sharing - - Le ultime dal mio blog: Perchè una mappa degli alberi? -- View this message in context: http://gis.19327.n5.nabble.com/open-expo-2015-tp5817169p5840766.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: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
Bonsoir, Le 15/04/2015 23:37, George Kaplan a écrit : Je viens de voir la nouvelle dans les flux RSS du site de d'osm-fr. J'ai lu avec attention et des questions me viennent sur cette annonce : Je vois que sur http://bano.openstreetmap.fr/ , le dossier /data n'a pas été mis à jour aujourd'hui alors qu'un nouveau nommé /BAN_odbl a fait son apparition, contenant des données datées de ce jour. Est-ce que ça veut dire que le dossier /BAN_odbl est maintenant l'emplacement des fichiers BANO ? Non, c'est juste un concours de circonstances, cf. mon message de ce matin sur les outils de màj quotidiens de BANO (de minuit à ~05:00 chaque matin) qui sont momentanément en mode manuel (et à l'heure qu'il est ils tournent). Christian gère cette partie, et, disons, il a été comme occupé par le lancement de la BAN ces derniers temps ;) Est-ce que le terme BANO est maintenant obsolète et remplacé par BAN Odbl ? Non. BANO s'appuie massivement sur OSM comme source, la BAN ODbL pas du tout. La convergence des licences permet à partir de maintenant d'imaginer la construction d'une base sous ODbL tirant le meilleur parti des 2 bases. Christian a la main sur tes autres points. La page Contribuer ne mentionne pas la possibilité de corriger une erreur en ajoutant l'adresse dans OSM, est-ce que cette absence est volontaire ? Les outils de géocodage disponibles sur http://adresse.data.gouv.fr/ utilisent-ils la BAN ou son sous-ensemble Odbl ? Je voulais aussi consulter la licence gratuite de repartage mais son URL ( https://adresse.data.gouv.fr/static/BAN_Licence_de_repartage.pdf ) renvoie une erreur 404. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
Bonsoir, Je viens de voir la nouvelle dans les flux RSS du site de d'osm-fr. J'ai lu avec attention et des questions me viennent sur cette annonce : Je vois que sur http://bano.openstreetmap.fr/ , le dossier /data n'a pas été mis à jour aujourd'hui alors qu'un nouveau nommé /BAN_odbl a fait son apparition, contenant des données datées de ce jour. Est-ce que ça veut dire que le dossier /BAN_odbl est maintenant l'emplacement des fichiers BANO ? Est-ce que le terme BANO est maintenant obsolète et remplacé par BAN Odbl ? La page Contribuer ne mentionne pas la possibilité de corriger une erreur en ajoutant l'adresse dans OSM, est-ce que cette absence est volontaire ? Les outils de géocodage disponibles sur http://adresse.data.gouv.fr/ utilisent-ils la BAN ou son sous-ensemble Odbl ? Je voulais aussi consulter la licence gratuite de repartage mais son URL ( https://adresse.data.gouv.fr/static/BAN_Licence_de_repartage.pdf ) renvoie une erreur 404. George. Le 15 avr. 2015 à 23:03, Pierre Béland pierz...@yahoo.fr a écrit : voir http://www.20minutes.fr/high-tech/1587935-20150415-france-enfin-fichier-unique-adresses-postales-tant-mieux#xtor=RSS-176 Le nouveau fichier présenté par Christian :) Pierre ___ 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] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
Le 15/04/2015 23:37, George Kaplan a écrit :
Bonsoir,
Je viens de voir la nouvelle dans les flux RSS du site de d'osm-fr.
J'ai lu avec attention et des questions me viennent sur cette annonce :
Je vois que sur http://bano.openstreetmap.fr/ , le dossier /data n'a
pas été mis à jour aujourd'hui alors qu'un nouveau nommé /BAN_odbl a
fait son apparition, contenant des données datées de ce jour. Est-ce
que ça veut dire que le dossier /BAN_odbl est maintenant l'emplacement
des fichiers BANO ?
Est-ce que le terme BANO est maintenant obsolète et remplacé par BAN
Odbl ?
Comme l'a indiqué Vincent, c'est un concours de circonstance... un petit
pépin hier sur la base postgres de BANO et les scripts ont généré des
fichiers vides.
On remet ça en ordre rapidement.
La BAN ne signifie pas l'arrêt de BANO mais une convergence dans la
limite de ce que permettent les licences.
Les données ODbL d'OSM (ou en opendata) ne peuvent pas être versées dans
la BAN.
Un sous ensemble de la BAN est diffusé en ODbL (c'est même OSM FR qui en
est officiellement chargé par la convention qui a été signée aujourd'hui
avec l'IGN, La Poste et Etalab).
La page Contribuer ne mentionne pas la possibilité de corriger une
erreur en ajoutant l'adresse dans OSM, est-ce que cette absence est
volontaire ?
Oui. Comme indiqué ci-dessus, les contributions faites directement dans
OSM sont sous licence ODbL et empêcheraient leur rediffusion dans les
bases commercialisées par l'IGN et La Poste.
Dans les mois à venir, nous allons travailler sur un outil de
contribution qui permettra de faire d'une pierre deux coups: contribuer
à la BAN et à OSM.
Il va falloir être un petit peu patient car avant cela il faut mettre en
place des API autour de la BAN qui pour l'instant n'existent pas
vraiment. Les derniers ont été surtout occupés à trouver le bon
équilibre pour ce partenariat, pour respecter les contraintes de l'ODbL,
respecter les modèles économiques de l'IGN et La Poste. Le travail sur
le plan technique ne fait que démarrer.
Dans l'immédiat donc, aucun changement pour les BANOistes qui dégomment
du rouge... il va même y en avoir plus par l'apport des nouvelles
données sur les zones où le cadastre est encore en raster.
Les outils de géocodage disponibles sur http://adresse.data.gouv.fr/
utilisent-ils la BAN ou son sous-ensemble Odbl ?
Oui, d'ailleurs c'est indiqué dans les réponses json et l'attribution
sur la carte, exemple:
https://api-adresse.data.gouv.fr/search/?q=39%20rue%20du%20caire%2075002
{type: FeatureCollection, version: draft, query: 39 rue du
caire 75002, attribution: BAN, licence: ODbL 1.0, .
Quelques précision sur ce sous ensemble:
- il y a autant d'adresses dans les 2 diffusions
- seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le
libellé d'acheminement
Pour les mises à jour, on devrait démarrer sur un cycle hebdomadaire,
puis à terme quotidien.
Je voulais aussi consulter la licence gratuite de repartage mais son
URL ( https://adresse.data.gouv.fr/static/BAN_Licence_de_repartage.pdf
) renvoie une erreur 404.
Oups... mea culpa...
Il devrait y avoir d'autres articles, ouvrez l'oeil ;)
--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] Classificação de rodovias no Brasil
Não me foi solicitado, mas para dar alguma força extra ao processo de votação abstrato que está em curso, por mínima que seja essa força, eu quero manifestar que esses posicionamentos (abaixo) me pareceram os mais razoáveis. Eu não preciso estar envolvido na discussão propriamente dita, a cerca da classificação de rodovias, para opinar que* pretender mudanças de tal magnitude, sem identificação e consolidação da vontade comunitária majoritária, só traria prejuízo ao projeto OSM visto como um todo.* *Não às mudanças da noite pro dia!* Nunca me envolvi em tal trabalho de classificação de vias, mas imagino o quão imenso ele é, para estar recebendo mudança de estatuto ao nascer do sol. A comunidade precisa de ferramenta eficaz para o processo decisório. Alexandre Magno Em 15 de abril de 2015 13:37, Fernando Trebien fernando.treb...@gmail.com escreveu: Eu concordo que devemos manter a recomendação atual por pelo menos mais 1 ano, mas não acho que devemos nos privar de discutir o que seria o mundo ideal - aquele em que as ferramentas fazem tudo aquilo que nós, mapeadores e usuários do mapa no dia-a-dia, queremos que elas façam. Em 15 de abril de 2015 12:30, Fernando Trebien fernando.treb...@gmail.com escreveu: Eu concordo que não devemos sair mudando classificações enquanto debatemos (o lugar ideal seria o fórum, eu tentei mais ninguém quis continuar o debate lá, ele sempre acaba aqui na talk-br), mas um problema de que não podemos fugir no longo prazo é o de como a classificação urbana e a interurbana devem se corresponder/combinar, ou seja, de como esses dois sistemas se conectam. Em 15 de abril de 2015 11:35, wille wi...@wille.blog.br escreveu: Assim, não tem nada a ver com o fato da rodovia ser federal ou não. Eu prefiro que continuemos usando o padrão que definimos no passado e que está bastante claro para rodovias, apesar de ser ainda nebuloso para vias urbanas. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Obviamente, a votação inicial de cada mandato também seria por voto igualitário. Aparentemente resta o problema de carecermos de critérios objetivos. Na realidade, a comunidade já tem critérios relativamente objetivos (ao menos matemáticos) dados por ferramentas estatísticas diversas. A escolha entre critérios e a associação deles a pesos seria o aleatório (subjetivo) que viria com cada mandato. Alexandre Magno Em 15 de abril de 2015 21:57, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: *Era: Re: [Talk-br] Classificação de rodovias no Brasil* Resta aquele problema do voto igualitário, ou dos critérios para o voto não igualitário. Pelo que entendi do vídeo promocional, o Loomio só trabalha com voto igualitário, apesar de deixar explícito e facilmente visível quem votou o quê. Para usar o Loomio com critérios de voto não igualitário, e de uma maneira simples, talvez fosse adequado eleger árbitros, para mandatos curtos e temporários durante os quais ele estaria declarando e aplicando seus mesmos critérios de pesagem de votos em três escrutínios para cada objeto de votação. Ao início do curto e temporário mandato do árbitro, ele sempre faria uma votação, também de três escrutínios, para os critérios pretendidos e declarados por si para a pesagem dos votos. O árbitro poderia ter mandato dimensionado em dias ou quantidade de votações completas (incluindo aquela inicial). Ele poderia ser eleito e reeleito quantas vezes se candidatasse e a comunidade o elegesse pelo voto igualitário. Alexandre Magno Em 15 de abril de 2015 21:35, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: A comunidade precisa de ferramenta eficaz para o processo decisório. Em 15 de abril de 2015 12:30, Fernando Trebien fernando.treb...@gmail.com escreveu: Ontem descobri uma ferramenta usada pelo Partido Pirata para tomar decisões de forma colaborativa, o Loomio (https://www.loomio.org/). Quem sabe poderíamos usar pra essa discussão. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Ivaldo, você quis mesmo postar na thread O processo decisório da comunidade? Eu entendo que Flávio refere-se ao assunto da classificação de vias, e não é este o assunto desta thread. Alexandre Magno Em 15 de abril de 2015 23:10, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Nisso eu sou tentado me sentir como o Flávio: Eu odeio esse assunto. Desde que eu entrei no OSM, ele sempre volta pelo menos uma vez por ano. O que mais me incomoda é que as discussões são longas, tomam tempo que podia ser melhor gasto em outras coisas e acabam não progredindo muito. Não é culpa de ninguém. É um assunto importante, mas cansativo. Não existe consenso. O artigo no wiki demonstra isso. Eu gostaria que existisse, mas não existe. Não existe nem consenso sobre o que é consenso nessa questão. Infelizmente, eu me sito obrigado a participar dessa discussão cada vez que ela aparece, porque ela afeta diretamente o meu trabalho no OSM. Acho que o mapa do Brasil não está maduro o suficiente para tomarmos uma decisão definitiva sobre a classificação de vias. No fim, quem trabalha no mapa vai ter que decidir conforme a sua consciência. Sugiro que não foquem o trabalho apenas na classificação, e sim em outras coisas mais críticas, como mapear as rodovias que não existem no mapa ou colocar as que existem no lugar certo (os dados importados do IBGE estão muito toscos), ou mapeando corretamente os cruzamentos e restrições de conversão, que também são importantes para o roteamento. Se for possível incluí-los, os tags lanes, maxspeed e surface podem ajudar bastante na classificação das rodovias no futuro (ou não, dependendo do critério; nesse caso, eles se tornariam ainda mais importantes). À medida que forem fazendo isso, se quiserem, ajustem a classificação das rodovias que forem editadas da forma que acharem melhor. Muita paz para todos. Espero ter contribuído com alguma coisa e desculpe se, por algum motivo, alguém se sentir incomodado com o meu comentário. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-us] NPF is Using OSM
The National Park Foundation is using OSM in the site http://findyourpark.com/ with attribution! -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Dass in den USA die Sani Statiionen so wenig beschrieben sind ist kein Grund alles darauf zu reduzieren. Schau dir die Portale der Camping- und Wohnmobilkataloge in Deutschland an dann siehst du was dort alles angegeben wird. Die Toplevel Tags reichen für ein einfaches Rendering, aber was gibt dir das Recht, deshalb zu einem frühen Zeitpunkt weltweit einen Automatischen Edit anzustoßen wo du dich noch nicht einmal ausreichend mit dem Thema beschäftigt hast. Du stellt mir die lapidare Frage Können wir mit dem Editieren mit den Grundtags beginnen, auch wenn den Zusatztags noch im Unklaren sind und hast schon längst einen automatischen Edit angestoßen, der mehrere vorher gebrauchte Tags umschreibt. Dabei werden auch Zusatztags benutzt die du vorgestern anscheinend gewürfelt hast. Ich finde das schade, da du dich ja anscheinend noch nicht einmal ausreichend mit dem Thema beschäftigt hast. Sonst hättest du wenigstens auf die Bilder auf der englischen Talkseite beschreiben können. Wenn du meinst die Toplevel reichen, aber gleichzeitig meinst, dass es zu Kompliziert ist Die Unterschiede darzustellen, dann könnte ich behaupten warum taggen wir die Entsorgungsstationen überhaupt. Jeder gute Campingplatz hat eine und wenn man ankommt wird man schon erkennen ob das mit meinem Campingfahrzeug geht. Ich habe versucht mit dir über Grundlagen zu diskutieren, aber darauf bekomme ich dann die Antwort, dass es zwischen uns keine vernünftige Diskussionsbasis gibt, weil es die Sprachbariere gibt und das Thema Abwasser ja erheblich stinkt und man deshalb manches lieber nicht beschreibt, Wie taggst du eigentlich waste=excremente um,welches ja genauso oft vorkommt wie waste=gray_water oder waste=chemical_toilet? Im Moment fühle ich mich deshalb ziemlich hintergangen. Wie ich schon in der Diskussionsseite des Wikis auf die Frage geantwortet habe bin ich auf keinen Fall für einen automatischen Edit. Aber anscheinend muß man das System OSM und die Lücken kennen um weltweit etwas ändern zu können. Warum bist du daran interressiert, diesen Tag so schnell in eine dir genehme Form zu bringen. Dann bemühe dich darum dies zu erklären. Mit welchem Kreis ist der Edit besprochen? Wo ist dokumentiert was durch was ersetzt wird? Ich bin wie ich mehrfach erwähnte für ein einheitliches Taggen. Aber dann sollte es vernünftig und verständlich beschrieben sein. Nach Möglichkeit nicht nur Englisch(oder US - Amerikanisch) Auch bei heiklen Themen sollte auf Hintergründe eingegangen werden um auch Mappern, die sich nur wenig mit dem Thema beschäftigt haben, die Möglichkeit des Mappens zu geben. Gisbert Am 15.04.2015 um 19:37 schrieb Bryce Nesbitt: You can also see how others are tagging Sanitary Dumps: http://www.sanidumps.com/maps/index.php?id=18 --- The top level tags sanitary_dump_station are enough for rendering. However someone with a given style of boat or motorhome can use use only some of the sites. They may have boat holding tank needing a pumpout, a boat or motorhome with a cassette, or a motorhome with a gravity fed hose. These are incompatible systems. A given site may accept one, two or three of the systems. A given site may restrict or even ban tank holding chemicals, but these rules are complex and hard to tag. I prefer just a warning that a given site may have a restriction that needs to be checked locally. ___ 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
Re: [Talk-br] O processo decisório da comunidade
*Nada impede* que a cada eleição de árbitro houvesse quadros de candidatos assim: Candidato 1, critérios de arbitragem: a) Voto igualitário (e eu quero muito o voto igualitário) b) [enunciado do critério 1.b] c) [enunciado do critério 1.c] Candidato 2, critérios de arbitragem: a) Voto igualitário (eu aceito, vamos lá) b) [enunciado do critério 2.b] c) [enunciado do critério 2.c] Candidato 3, critérios de arbitragem: a) Voto igualitário b) [enunciado do critério 3.b] c) [enunciado do critério 3.c] ... Alexandre Magno Em 15 de abril de 2015 22:15, Tarcisio Oliveira tarci...@ymail.com escreveu: Acho valida sua ideia, mas, se for para votar, creio que todos devam ter voto igual, por mais que o cara aparentemente não entenda da coisa. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Não somente. Peguei carona na deixa de Fernando Trebien sobre o Loomie. Não tenho algo a contribuir na discussão de classificação de vias. Se houvesse votação lá, por voto igualitário, eu não votaria. Se houvesse votação lá, por voto não igualitário, com critérios que me colocassem no lugar certo (lá embaixo), aí eu votaria, porque a consciência não pesaria e eu ainda participaria numa medida menos injusta para os demais. Eu quase não tenho mapeamento acumulado, e em classificação de vias, menos ainda. Alexandre Magno Em 15 de abril de 2015 23:20, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Uai, mas o processo decisório não sobre classificação de rodovias?? senão foi, ignora. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] O processo decisório da comunidade
*Era: Re: [Talk-br] Classificação de rodovias no Brasil* Resta aquele problema do voto igualitário, ou dos critérios para o voto não igualitário. Pelo que entendi do vídeo promocional, o Loomio só trabalha com voto igualitário, apesar de deixar explícito e facilmente visível quem votou o quê. Para usar o Loomio com critérios de voto não igualitário, e de uma maneira simples, talvez fosse adequado eleger árbitros, para mandatos curtos e temporários durante os quais ele estaria declarando e aplicando seus mesmos critérios de pesagem de votos em três escrutínios para cada objeto de votação. Ao início do curto e temporário mandato do árbitro, ele sempre faria uma votação, também de três escrutínios, para os critérios pretendidos e declarados por si para a pesagem dos votos. O árbitro poderia ter mandato dimensionado em dias ou quantidade de votações completas (incluindo aquela inicial). Ele poderia ser eleito e reeleito quantas vezes se candidatasse e a comunidade o elegesse pelo voto igualitário. Alexandre Magno Em 15 de abril de 2015 21:35, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: A comunidade precisa de ferramenta eficaz para o processo decisório. Em 15 de abril de 2015 12:30, Fernando Trebien fernando.treb...@gmail.com escreveu: Ontem descobri uma ferramenta usada pelo Partido Pirata para tomar decisões de forma colaborativa, o Loomio (https://www.loomio.org/). Quem sabe poderíamos usar pra essa discussão. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Acho valida sua ideia, mas, se for para votar, creio que todos devam ter voto igual, por mais que o cara aparentemente não entenda da coisa. Tarcisio On 15-04-2015 22:04, Alexandre Magno Brito de Medeiros wrote: Obviamente, a votação inicial de cada mandato também seria por voto igualitário. Aparentemente resta o problema de carecermos de critérios objetivos. Na realidade, a comunidade já tem critérios relativamente objetivos (ao menos matemáticos) dados por ferramentas estatísticas diversas. A escolha entre critérios e a associação deles a pesos seria o aleatório (subjetivo) que viria com cada mandato. Alexandre Magno Em 15 de abril de 2015 21:57, Alexandre Magno Brito de Medeiros alexandre@gmail.com mailto:alexandre@gmail.com escreveu: /Era: Re: [Talk-br] Classificação de rodovias no Brasil/ Resta aquele problema do voto igualitário, ou dos critérios para o voto não igualitário. Pelo que entendi do vídeo promocional, o Loomio só trabalha com voto igualitário, apesar de deixar explícito e facilmente visível quem votou o quê. Para usar o Loomio com critérios de voto não igualitário, e de uma maneira simples, talvez fosse adequado eleger árbitros, para mandatos curtos e temporários durante os quais ele estaria declarando e aplicando seus mesmos critérios de pesagem de votos em três escrutínios para cada objeto de votação. Ao início do curto e temporário mandato do árbitro, ele sempre faria uma votação, também de três escrutínios, para os critérios pretendidos e declarados por si para a pesagem dos votos. O árbitro poderia ter mandato dimensionado em dias ou quantidade de votações completas (incluindo aquela inicial). Ele poderia ser eleito e reeleito quantas vezes se candidatasse e a comunidade o elegesse pelo voto igualitário. Alexandre Magno Em 15 de abril de 2015 21:35, Alexandre Magno Brito de Medeiros alexandre@gmail.com mailto:alexandre@gmail.com escreveu: A comunidade precisa de ferramenta eficaz para o processo decisório. Em 15 de abril de 2015 12:30, Fernando Trebien fernando.treb...@gmail.com mailto:fernando.treb...@gmail.com escreveu: Ontem descobri uma ferramenta usada pelo Partido Pirata para tomar decisões de forma colaborativa, o Loomio (https://www.loomio.org/). Quem sabe poderíamos usar pra essa discussão. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br smime.p7s Description: Assinatura criptográfica S/MIME ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Gosto da sua ideia de voto igualitário, independente da curva de maturidade da pessoa no assunto. Isso porque excelentes idéias surgem quando há heterogeneidade de pensamentos. Da mesma forma, um grupo fechado, com formas de pensar meio que pré-determinadas se torna meio perigoso... tendencioso é a palavra certa. Não gosto muito da ideia de o que foi decidido no passado deve permanecer intocável. Isso realmente não é válido. As coisas mudam e idéias novas surgem, ou uma nova forma (simplificada) de entender um velho problema pode surgir como solução para uma questão. Quanto ao sistema de votação, mesmo sendo (talvez, não sei) algo padronizado aqui, acho lento, muito burocrático e improdutivo. Desculpe a franqueza. Talvez fosse melhor focar em grupos de trabalho com tarefas específicas e distintas, com prazo para apresentação de propostas. Por exemplo: um grupo poderia trabalhar na definição dos parâmetros (que não podem ser infinitos, mas poucos) focadas na clareza e facilidade de entendimento do assunto. É isso. *Ivaldo* ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Em 15 de abril de 2015 22:42, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Gosto da sua ideia de voto igualitário, independente da curva de maturidade da pessoa no assunto. Isso porque excelentes idéias surgem quando há heterogeneidade de pensamentos. Da mesma forma, um grupo fechado, com formas de pensar meio que pré-determinadas se torna meio perigoso... tendencioso é a palavra certa. Eleições periódicas e votações para determinação de quórum afastariam essa possibilidade, se o quórum começasse bem auto por imposição da implantação do sistema. Não gosto muito da ideia de o que foi decidido no passado deve permanecer intocável. Isso realmente não é válido. As coisas mudam e idéias novas surgem, ou uma nova forma (simplificada) de entender um velho problema pode surgir como solução para uma questão. No sistema de governo que estou idealizando e tentando transmitir a vocês, coisas poderiam mudar, mas só depois que tal fosse querido o suficiente na comunidade. Esse querer suficiente seria determinado por essa máquina legislativa em transformação por tempo indeterminado. Com o princípios corretos, ela não viciaria. Quanto ao sistema de votação, mesmo sendo (talvez, não sei) algo padronizado aqui, acho lento, muito burocrático e improdutivo. Desculpe a franqueza. Talvez fosse melhor focar em grupos de trabalho com tarefas específicas e distintas, com prazo para apresentação de propostas. Eu tive em vista o uso do Loomio. Por exemplo: um grupo poderia trabalhar na definição dos parâmetros (que não podem ser infinitos, mas poucos) focadas na clareza e facilidade de entendimento do assunto. É isso. Grupos de trabalho também precisam de um processo decisório perante toda a comunidade. Alexandre Magno ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [OSM-talk] [Talk-us] PennLive.com using OSM without attribution?
It's been fixed. Thanks for handling the e-mail part Hans. -James From: hans.dekryge...@gmail.com Date: Wed, 15 Apr 2015 05:55:34 -0700 To: rickmastfa...@hotmail.com CC: talk@openstreetmap.org; talk...@openstreetmap.org Subject: Re: [Talk-us] PennLive.com using OSM without attribution? Just received an email from nick the writer of the article saying he would take care of it today. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 On Tue, Apr 14, 2015 at 10:26 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: I sent him a email, i'll let you know when i get a reply. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 On Tue, Apr 14, 2015 at 6:27 PM, James Mast rickmastfa...@hotmail.com wrote: http://www.pennlive.com/projects/2015/pa-turnpike-tunnels/ Just happened to see this article talking about the future of the Allegheny Tunnels along the PA Turnpike (I-76/I-70). About 2/3rd down in the article, they have a screenshot of OSM there showing the possible new alignments for the PA Turnpike. My question is, is this allowed with the current license, or do they still need to have the attribution on the image (or right below it)? If somebody that is more knowledgeable in this would like to contact them about this if they are in the wrong, please, be my guest. -James ___ Talk-us mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] PennLive.com using OSM without attribution?
It's been fixed. Thanks for handling the e-mail part Hans. -James From: hans.dekryge...@gmail.com Date: Wed, 15 Apr 2015 05:55:34 -0700 To: rickmastfa...@hotmail.com CC: t...@openstreetmap.org; talk-us@openstreetmap.org Subject: Re: [Talk-us] PennLive.com using OSM without attribution? Just received an email from nick the writer of the article saying he would take care of it today. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 On Tue, Apr 14, 2015 at 10:26 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: I sent him a email, i'll let you know when i get a reply. Regards, Hans http://www.openstreetmap.org/user/TheDutchMan13 On Tue, Apr 14, 2015 at 6:27 PM, James Mast rickmastfa...@hotmail.com wrote: http://www.pennlive.com/projects/2015/pa-turnpike-tunnels/ Just happened to see this article talking about the future of the Allegheny Tunnels along the PA Turnpike (I-76/I-70). About 2/3rd down in the article, they have a screenshot of OSM there showing the possible new alignments for the PA Turnpike. My question is, is this allowed with the current license, or do they still need to have the attribution on the image (or right below it)? If somebody that is more knowledgeable in this would like to contact them about this if they are in the wrong, please, be my guest. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [talk-au] Use of mapconnect data in OSM [SEC=UNCLASSIFIED]
On 4/15/2015 6:01 AM, Ross wrote: Hi Simon, The issue is not with the licence. The current terms and conditions require permission to add data not owned by the contributor. This is incorrect. An appropriate license is sufficient. Some obviously appropriate licenses are CC0, PDDL, ODC-BY and the ODbL itself. The issue is that CC BY (and BY-SA) 2.0, 2.5 and 3.0 require a form of attribution that is not practical for most map uses, so we need permission. This would have been true even without the license change, as we were never meeting the requirements of those versions of CC BY. We have permission for many Australian sources, and I believe for all CC BY Australian sources that were in use at the time of the license change. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
Re: [OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
Merci à vous 2 pour ces clarifications (c'est la licence Odbl commune aux 2
jeux qui m'a induit en erreur).
Je me projette un peu dans l'avenir et j'imagine une représentation
cartographique présentant les écarts entre BANO et BAN Odbl : que l'erreur soit
dans l'une ou l'autre source, on identifierait donc les adresses douteuses à
vérifier sur le terrain. C'est envisageable comme méthode ?
George
Le 16 avr. 2015 à 00:55, Christian Quest cqu...@openstreetmap.fr a écrit :
Le 15/04/2015 23:37, George Kaplan a écrit :
Bonsoir,
Je viens de voir la nouvelle dans les flux RSS du site de d'osm-fr. J'ai lu
avec attention et des questions me viennent sur cette annonce :
Je vois que sur http://bano.openstreetmap.fr/ , le dossier /data n'a pas été
mis à jour aujourd'hui alors qu'un nouveau nommé /BAN_odbl a fait son
apparition, contenant des données datées de ce jour. Est-ce que ça veut dire
que le dossier /BAN_odbl est maintenant l'emplacement des fichiers BANO ?
Est-ce que le terme BANO est maintenant obsolète et remplacé par BAN Odbl ?
Comme l'a indiqué Vincent, c'est un concours de circonstance... un petit
pépin hier sur la base postgres de BANO et les scripts ont généré des
fichiers vides.
On remet ça en ordre rapidement.
La BAN ne signifie pas l'arrêt de BANO mais une convergence dans la limite de
ce que permettent les licences.
Les données ODbL d'OSM (ou en opendata) ne peuvent pas être versées dans la
BAN.
Un sous ensemble de la BAN est diffusé en ODbL (c'est même OSM FR qui en est
officiellement chargé par la convention qui a été signée aujourd'hui avec
l'IGN, La Poste et Etalab).
La page Contribuer ne mentionne pas la possibilité de corriger une erreur
en ajoutant l'adresse dans OSM, est-ce que cette absence est volontaire ?
Oui. Comme indiqué ci-dessus, les contributions faites directement dans OSM
sont sous licence ODbL et empêcheraient leur rediffusion dans les bases
commercialisées par l'IGN et La Poste.
Dans les mois à venir, nous allons travailler sur un outil de contribution
qui permettra de faire d'une pierre deux coups: contribuer à la BAN et à OSM.
Il va falloir être un petit peu patient car avant cela il faut mettre en
place des API autour de la BAN qui pour l'instant n'existent pas vraiment.
Les derniers ont été surtout occupés à trouver le bon équilibre pour ce
partenariat, pour respecter les contraintes de l'ODbL, respecter les modèles
économiques de l'IGN et La Poste. Le travail sur le plan technique ne fait
que démarrer.
Dans l'immédiat donc, aucun changement pour les BANOistes qui dégomment du
rouge... il va même y en avoir plus par l'apport des nouvelles données
sur les zones où le cadastre est encore en raster.
Les outils de géocodage disponibles sur http://adresse.data.gouv.fr/
utilisent-ils la BAN ou son sous-ensemble Odbl ?
Oui, d'ailleurs c'est indiqué dans les réponses json et l'attribution sur la
carte, exemple:
https://api-adresse.data.gouv.fr/search/?q=39%20rue%20du%20caire%2075002
{type: FeatureCollection, version: draft, query: 39 rue du caire
75002, attribution: BAN, licence: ODbL 1.0, .
Quelques précision sur ce sous ensemble:
- il y a autant d'adresses dans les 2 diffusions
- seuls 2 champs ne sont pas proposés en ODbL: le libellé AFNOR et le libellé
d'acheminement
Pour les mises à jour, on devrait démarrer sur un cycle hebdomadaire, puis à
terme quotidien.
Je voulais aussi consulter la licence gratuite de repartage mais son URL (
https://adresse.data.gouv.fr/static/BAN_Licence_de_repartage.pdf ) renvoie
une erreur 404.
Oups... mea culpa...
Il devrait y avoir d'autres articles, ouvrez l'oeil ;)
--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-br] O processo decisório da comunidade
Eu penso que a questão não nem tanto a ver com o nível de entendimento do votante a respeito do assunto sendo votado. É muito mais respeitar o esforço de quem tem mais participação, atividade proveitosa no OSM. Aliás, uma coisa ou outra, ou um pouco de ambas, sendo isso decidido por mandato como decorrência da eleição da pessoa do árbitro. A comunidade elegeria o árbitro por voto igualitário, já prevendo o jeito dele arbitrar. Na primeira votação arbitrada em um mandato, o árbitro seria obrigado ao menos a uma quantidade X de opções declarando critérios de arbitragem. Poderia ser X = 3; ou seja, a primeira votação de cada mandato, ainda voto igualitário, três escrutínios como todas as votações, obedecendo a quórum mínimo como todas as votações, elegeria uma dentre três anunciações de critério de pesagem de votos, as mesmas anunciações que o candidato a árbitro já deveria ter declarado no período de sua campanha (não devendo mudar, sob pena de perda automática de mandato). Alexandre Magno Em 15 de abril de 2015 22:15, Tarcisio Oliveira tarci...@ymail.com escreveu: Acho valida sua ideia, mas, se for para votar, creio que todos devam ter voto igual, por mais que o cara aparentemente não entenda da coisa ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Nisso eu sou tentado me sentir como o Flávio: Eu odeio esse assunto. Desde que eu entrei no OSM, ele sempre volta pelo menos uma vez por ano. O que mais me incomoda é que as discussões são longas, tomam tempo que podia ser melhor gasto em outras coisas e acabam não progredindo muito. Não é culpa de ninguém. É um assunto importante, mas cansativo. Não existe consenso. O artigo no wiki demonstra isso. Eu gostaria que existisse, mas não existe. Não existe nem consenso sobre o que é consenso nessa questão. Infelizmente, eu me sito obrigado a participar dessa discussão cada vez que ela aparece, porque ela afeta diretamente o meu trabalho no OSM. Acho que o mapa do Brasil não está maduro o suficiente para tomarmos uma decisão definitiva sobre a classificação de vias. No fim, quem trabalha no mapa vai ter que decidir conforme a sua consciência. Sugiro que não foquem o trabalho apenas na classificação, e sim em outras coisas mais críticas, como mapear as rodovias que não existem no mapa ou colocar as que existem no lugar certo (os dados importados do IBGE estão muito toscos), ou mapeando corretamente os cruzamentos e restrições de conversão, que também são importantes para o roteamento. Se for possível incluí-los, os tags lanes, maxspeed e surface podem ajudar bastante na classificação das rodovias no futuro (ou não, dependendo do critério; nesse caso, eles se tornariam ainda mais importantes). À medida que forem fazendo isso, se quiserem, ajustem a classificação das rodovias que forem editadas da forma que acharem melhor. Muita paz para todos. Espero ter contribuído com alguma coisa e desculpe se, por algum motivo, alguém se sentir incomodado com o meu comentário. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Aliás... é verdade... ela viciaria à medida que *o coletivo* cometesse erros viciantes. Por exemplo, em momentos que estivesse difícil atingir quórum, a maioria poderia se ver tentada a diminuí-lo através de votação legislativa, e isso seria viciante. Não vejo como escapar desse *risco*. Podemos ser otimistas quanto a isso, ou não. Outra maneira de viciar: votações legislativas onde os votantes não consigam captar a tempo, no decorrer dos três escrutínios, que estão optando uma lei viciante. E uma terceira maneira viciar: uma lei viciante que já exista não ser notada a tempo de correção efetiva. Alexandre Magno Em 15 de abril de 2015 22:59, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Em 15 de abril de 2015 22:42, Ivaldo Nunes de Magalhães ivald...@gmail.com escreveu: Não gosto muito da ideia de o que foi decidido no passado deve permanecer intocável. Isso realmente não é válido. As coisas mudam e idéias novas surgem, ou uma nova forma (simplificada) de entender um velho problema pode surgir como solução para uma questão. No sistema de governo que estou idealizando e tentando transmitir a vocês, coisas poderiam mudar, mas só depois que tal fosse querido o suficiente na comunidade. Esse querer suficiente seria determinado por essa máquina legislativa em transformação por tempo indeterminado. Com o princípios corretos, ela não viciaria. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Cada escrutínio teria de ter um quórum que, se não atingindo, anularia toda a votação. Cada escrutínio também teria a mesma duração imutável, votada nos primórdios. Um problema é: inicialmente esta proposta teria de ser aceita por voto igualitário *como um pacote* a ser aperfeiçoado através de votações legislativas segundo demandas da comunidade ou de árbitros. Alexandre Magno Em 15 de abril de 2015 22:04, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Obviamente, a votação inicial de cada mandato também seria por voto igualitário. Aparentemente resta o problema de carecermos de critérios objetivos. Na realidade, a comunidade já tem critérios relativamente objetivos (ao menos matemáticos) dados por ferramentas estatísticas diversas. A escolha entre critérios e a associação deles a pesos seria o aleatório (subjetivo) que viria com cada mandato. Alexandre Magno Em 15 de abril de 2015 21:57, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: *Era: Re: [Talk-br] Classificação de rodovias no Brasil* Resta aquele problema do voto igualitário, ou dos critérios para o voto não igualitário. Pelo que entendi do vídeo promocional, o Loomio só trabalha com voto igualitário, apesar de deixar explícito e facilmente visível quem votou o quê. Para usar o Loomio com critérios de voto não igualitário, e de uma maneira simples, talvez fosse adequado eleger árbitros, para mandatos curtos e temporários durante os quais ele estaria declarando e aplicando seus mesmos critérios de pesagem de votos em três escrutínios para cada objeto de votação. Ao início do curto e temporário mandato do árbitro, ele sempre faria uma votação, também de três escrutínios, para os critérios pretendidos e declarados por si para a pesagem dos votos. O árbitro poderia ter mandato dimensionado em dias ou quantidade de votações completas (incluindo aquela inicial). Ele poderia ser eleito e reeleito quantas vezes se candidatasse e a comunidade o elegesse pelo voto igualitário. Alexandre Magno Em 15 de abril de 2015 21:35, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: A comunidade precisa de ferramenta eficaz para o processo decisório. Em 15 de abril de 2015 12:30, Fernando Trebien fernando.treb...@gmail.com escreveu: Ontem descobri uma ferramenta usada pelo Partido Pirata para tomar decisões de forma colaborativa, o Loomio (https://www.loomio.org/). Quem sabe poderíamos usar pra essa discussão. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Classificação de rodovias no Brasil
Não me atentei para essa questão de cruzamentos para as auto-estradas, nem sabia que era um parâmetro delas. Vou incluir na minha listinha, conforme você sugeriu. *Ivaldo* ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] O processo decisório da comunidade
Uai, mas o processo decisório não sobre classificação de rodovias?? senão foi, ignora. *Ivaldo* ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [talk-au] Use of mapconnect and CAPAD data in OSM
Thank you Simon. I would be interested in chasing an appropriate license to allow uploading this data. The way I read the license it seems that the intent is that anyone can use the data for non-commercial or commercial uses provided they attribute it correctly. I do not know what OSM requires or who to ask. A clear answer would be nice. I think I understand the limitations of the information. I was specifically interested in boundary data, particularly for National Parks and conservation reserves. While I admit the exact boundary can sometimes be important, for the majority of map users I think naming the reserve and roughly outlining the boundaries may be enough. I have noticed that, while many of the reserves in Western Australia are named in the OSM data there are lots that do not appear. I think that even with the limitations of the MapConnect data set it could improve the current OSM data set. I did look at Ross's suggestion of the 2014 CAPAD data set. From my initial look and my local knowledge it seems to be complete and more current. Thanks Ross. The data set is fairly big so it needs to be broken up to be useful. Thanks all for your input Warren On 15/04/2015 8:00 PM, talk-au-requ...@openstreetmap.org wrote: Send Talk-au mailing list submissions to talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Use of mapconnect data in OSM [SEC=UNCLASSIFIED] (simon.coste...@ga.gov.au) -- Message: 1 Date: Wed, 15 Apr 2015 11:39:03 + From:simon.coste...@ga.gov.au To:talk-au@openstreetmap.org Subject: Re: [talk-au] Use of mapconnect data in OSM [SEC=UNCLASSIFIED] Message-ID:56a3257c-0055-48c9-a8b5-ad0c0f418...@ga.gov.au Content-Type: text/plain; charset=us-ascii The data in Mapconnect can be up to 8 years old. It originally came from both CAPAD and the states/territories, and was generalised to be consistent with a cartographic map at a scale of 1:250,000. CAPAD has come from the states / territories, and probably from the national park authorities rather than the mapping agency. There will be differences. I would also be keen to hear what the limitations in the CCBY licence is. If you want to use the data in Mapconnect then I can chase up an alternative licence/permission to use if the current license doesn't work. Thanks, Simon Simon Costello Branch Head, National Location Information | EGD Management Environmental Geoscience Division | GEOSCIENCE AUSTRALIA Phone: +61 2 6249 9716tel:+61%202%206249%209716 Fax: +61 2 6249 tel:+61%202%206249%20 Email:simon.coste...@ga.gov.aumailto:simon.coste...@ga.gov.au Web:www.ga.gov.auhttp://www.ga.gov.au/ Cnr Jerrabomberra Avenue and Hindmarsh Drive Symonston ACT GPO Box 378 Canberra ACT 2601 Australiax-apple-data-detectors://3 Applying geoscience to Australia's most important challenges On 7 Apr 2015, at 10:03 pm, talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org wrote: Send Talk-au mailing list submissions to talk-au@openstreetmap.orgmailto:talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.orgmailto:talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Use of mapconnect data in OSM (Andrew Harvey) 2. Re: Use of mapconnect data in OSM (Ross) 3. Use of mapconnect data in OSM (Ross) (Warren) mime-attachment mime-attachment mime-attachment ___ Talk-au mailing list Talk-au@openstreetmap.orgmailto:Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by
Re: [Talk-cz] Mapy.cz s openstreetmap daty
Ahoj Pavle, pokud data pouze do určitých vrstev zobrazí bez úprav, tak nemusí vlastní veřejnou kopii dat nabízet. Opravy je pak i pro ně nejjednodušší řešit přímo přes databázi OpenStreetMap. Přitom, pokud jsou schopní nabízet a uživatele získat na základě nějaké přidané hodnoty ve formě dalších vrstev, tak jim ODbL zveřejnění dat k těmto vrstvám nenařizuje. Takže podle mého laického vnímání je to zcela v pořádku. Měj se pěkně, Pavel On Wednesday 15 of April 2015 16:20:42 Pavel Machek wrote: Ahoj! On 2015-04-14, 17:48 GMT, Jan Martinec wrote: včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne každý renderer navíc je dobrá věc :) Mají? Na http://napoveda.seznam.cz/cz/mapy/mapy-licencni-podminky/ vidím „© Přispěvatelé OpenStreetMap“ (jen mimo ČR a SR) což mi připadá že o tomhle konkrétním changsetu z OSM (pokud ho opravdu použili) lžou. Mají. Když se mrkneš na mapu, tak v levém dolním rohu vidím (c) přispěvatelé OpenStreetMap a to bohatě stačí. No nevim, nemela by OdBL zarucovat, ze mame pravo dostat zdrojovou databazi? Zminka (c) Openstreetmap neni jedina podminka pouziti OSM dat. Pavel ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] Article de 20 minutes - La France a enfin son fichier unique d'adresses postales
voir http://www.20minutes.fr/high-tech/1587935-20150415-france-enfin-fichier-unique-adresses-postales-tant-mieux#xtor=RSS-176 Le nouveau fichier présenté par Christian :) Pierre ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-cz] Mapy.cz s openstreetmap daty
-- Původní zpráva -- Od: Radek Kuznik ra...@aktovka.net Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 15. 4. 2015 8:49:15 Předmět: Re: [Talk-cz] Mapy.cz s openstreetmap daty Cau, pisou v clanku http://www.novinky.cz/internet-a-pc/366953-mapy-cz-ukazou- detailne-cely-svet-chystaji-i-dalsi-vylepseni.html (http://www.novinky.cz/internet-a-pc/366953-mapy-cz-ukazou-detailne-cely-svet-chystaji-i-dalsi-vylepseni.html) Po pečlivém srovnání kvality podkladů jednotlivých dodavatelů jsme se rozhodli pro data OpenStreetMap, která jsme obohatili naším mapovým klíčem. Ano. Ale toto platí všude kromě České republiky. U nás mají podklady vlastní. Marián R. Dne 15. dubna 2015 8:20 Marián Kyral mky...@email.cz (mailto:mky...@email.cz) napsal(a): -- Původní zpráva -- Od: Jan Martinec j...@martinec.name(mailto:j...@martinec.name) Komu: talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org) Datum: 14. 4. 2015 19:50:03 Předmět: Re: [Talk-cz] Mapy.cz s openstreetmap daty On 04/14/2015 06:22 PM, Miroslav Suchý wrote: On 04/14/2015 05:51 PM, Jan Martinec wrote: OSM data používá Seznam i v ČR, úplně potichu s tím vyjeli - jakýkoli changeset z OSM se obratem objevuje na Mapy.cz - poprvé jsem si náhodou všiml před pár měsíci tady, za OSM planet lagují cca o pár týdnů: To bych si dovolil nesouhlasil. Možná ty changesety sledují a berou jako zdroj informací co se kde změnilo. Ale rozhodně je nekopírují a už vůbec je automaticky nepřebírají. Ten changeset na Kačerově přebrali i s chlupama (předtím v OSM nebylo vůbec nic, a poté to Seznam zcela nezávisle zmapoval _identicky_ s OSM, včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne - každý renderer navíc je dobrá věc :) Nevím jak to mají v Seznamu rozdělené, ale asi bude hodně záležet na lidech. Někdo třeba monitoruje OSM, jiný ne. Případně záleží na obsahu daného changesetu. Těžko říct, možností je hodně. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org) https://lists.openstreetmap.org/listinfo/talk-cz (https://lists.openstreetmap.org/listinfo/talk-cz) ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] wpt_symbol, wpt_description
2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] code FANTOIR avec nom de rue et de résidence
On peut toujours avoir un nom de résidence en plus du numéro dans un champ d'adresse. Souvent d'ailleur le numéro n'existe que dans le référentiel mais on ne le voit pas sur le terrain, et notamment pas dans le cas des résidences où ce numéro théorique ne suffit pas à désigner un numéro de batiment. Bref on a encore un champ addr:building_name même si en principe il ne désigne que le nom d'un seul batiment dans une résidence qui peut parfois en avoir plusieurs (mais là encore le numéro public peut ne pas suffire non plus, ou bien il peut y avoir parfois plusieurs numéros publics dans la résidence mais qui ne suffisent pas à les distinguer. Une résidence c'est un nom pour l'ensemble (indépendamment des rues) et des batiments et accès désignés (hall ou porte d'entrée) ayant leur numérotation au sein de la résidence. Les numéros publics et noms des rues sont à part et sont souvent difficilement observables sur le terrain (d'autant plus que le réfenreitl public souvent ignore la composition réelle de ces résidences et omet des numéros ou omet d'ajouter des bis/ter/... ou un lettrage en cas de confusion En pratique les batiments et accès d'une résidence sont numérotés avec des lettres (A/B/C...) ou une désignation numérique comme secteur 2 qui vient compléter le numéro dans la rue sans amiguité (mais le nuémro et le nom de rue peuvent aussi ne pas être indiqués du tout si on a mis le nom de la résidence et le numéro d'accès. Une résidence c'est aussi un périmètre, un polygone (plus qu'un point d'adresse), mais on n'a pas de tag correct pour le classer (landuse=residential c'est pour des zones plus étendues, qui sont liés à l'occupation des sols et pas au découpage administratif, donc pas adapté pour les polygones de résidences qui peuvent en plus inclure des parties non résidentielles, comme un parc ou une zone d'entreprises, à caractère industriel ou commercial, et même parfois des secteurs encore agricoles avec des champs cultivés !) J'ai habité dans le passé une telle résidence qui incluait plusieurs batiments, des zones non baties laissées en fermage agricole, un secteur boisé, un étang, une pépinière, et une ferme encore en activité, ainsi qu'un bout d'une petite zone industrielle. Avec pour le tout plusieurs rues/routes, et aucun batiment n'affichait le numéro public de ces rues, juste le nom de la résidence et les numéros ou noms de batiments ou de lieux-dits. Autre exemple avec les secteurs de La Défense (difficile à classer pourtant en considérant La Défense comme une seule et même résidence). Au mieux on peut les désigner comme des neighborhoods... Bref la base d'adresses avec noms de rues et numéros c'est une chose mais ça ne suffit pas et ce n'est pas la seule façon de désigner le terrain (et ce n'est pas toujours observable, et même pas toujours utilisé non plus pour le courrier ou pour faire publicité des lieux: ouvrez les annuaires Pages Jaunes ou même les Pages Blanches et regardez les diférentes façon d'y désigner les adresses, ces inscriptions n'émanent pas de l'autorité publique masi de ce que les résidents qui y sont inscrits ont voulu faire apparaître et utilisent ne pratique aussi pour leur courrier !). ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-ro] Copaci adaugai in mod agresiv pe harta
Salutare! Ma simt si eu cu musca pe caciula pentru zona asta: http://www.openstreetmap.org/#map=17/47.01160/27.44100 https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=!3m4!1e1!3m2!1s5Ff16tmOqBadNX6jN-e19w!2e0?hl=ro Si mie mi se pare cam exagerat ce s-a facut in Bucuresti, in sensul ca s-a pus carul in fata boilor. Sunt multe lucruri mai importante care lipsesc. Pe de alta parte, cred ca orice informatie corecta e utila si ca, intr-adevar, ar trebui ca softul sa filtreze ceea ce e inutil. Daca vreau navigatie pentru masina poate nu ma intereseaza copacii, daca fac geocaching poate nu ma intereseaza soselele. Exagerez putin, dar ideea cred ca se intelege. Si eu am mai marcat candva tomberoane de gunoi, banci, stalpi, lumini stradale si tot felul de lucruri mai putin importante, dar am facut-o ca exercitiu, constient ca utilitatea pentru majoritatea utilizatorilor e scazuta. Pentru un biciclist ca mine, insa, un stalp sau un copac pe o campie poate fi un reper important. Sunt de acord ca, daca softul nu poate filtra fara eforturi baza de date, ar trebui sa fim mai ponderati cu astfel de informatii. -- View this message in context: http://gis.19327.n5.nabble.com/Copaci-adaugai-in-mod-agresiv-pe-harta-tp5840499p5840673.html Sent from the Romania mailing list archive at Nabble.com. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-cz] Mapy.cz s openstreetmap daty
Cau, pisou v clanku http://www.novinky.cz/internet-a-pc/366953-mapy-cz-ukazou-detailne-cely-svet-chystaji-i-dalsi-vylepseni.html Po pečlivém srovnání kvality podkladů jednotlivých dodavatelů jsme se rozhodli pro data OpenStreetMap, která jsme obohatili naším mapovým klíčem. R. Dne 15. dubna 2015 8:20 Marián Kyral mky...@email.cz napsal(a): -- Původní zpráva -- Od: Jan Martinec j...@martinec.name Komu: talk-cz@openstreetmap.org Datum: 14. 4. 2015 19:50:03 Předmět: Re: [Talk-cz] Mapy.cz s openstreetmap daty On 04/14/2015 06:22 PM, Miroslav Suchý wrote: On 04/14/2015 05:51 PM, Jan Martinec wrote: OSM data používá Seznam i v ČR, úplně potichu s tím vyjeli - jakýkoli changeset z OSM se obratem objevuje na Mapy.cz - poprvé jsem si náhodou všiml před pár měsíci tady, za OSM planet lagují cca o pár týdnů: To bych si dovolil nesouhlasil. Možná ty changesety sledují a berou jako zdroj informací co se kde změnilo. Ale rozhodně je nekopírují a už vůbec je automaticky nepřebírají. Ten changeset na Kačerově přebrali i s chlupama (předtím v OSM nebylo vůbec nic, a poté to Seznam zcela nezávisle zmapoval _identicky_ s OSM, včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne - každý renderer navíc je dobrá věc :) Nevím jak to mají v Seznamu rozdělené, ale asi bude hodně záležet na lidech. Někdo třeba monitoruje OSM, jiný ne. Případně záleží na obsahu daného changesetu. Těžko říct, možností je hodně. Marián ___ 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-us] Importing Tesla Superchargers
On Mon, Apr 13, 2015 at 4:11 PM, Charles Samuels o...@charles.derkarl.org wrote: On Monday, April 13, 2015 03:35:20 PM Bryce Nesbitt wrote: Having done a few up to dating scripts: I recommend looking for nearby amenity=charging_station, not name= Supercharger. In fact you may want to make this even more fuzzy, checking for either tag. And That might conflict with a nearby non-Tesla charger. use name:Supercharger not name=Supercharger. What's the difference? I already use a case-insensitive substring search for supercharger. OSM mappers will often change things like a name tag. While it is possibly nobody will ever mess with the data you left in OSM, but chances are periodically someone will hand edit the nodes you left. Here's a supercharger with all the bells and whistles mapped out[1]. * The charging problem is all about current. The big old transformer that supports a Tesla DC station was added to the north of the screen wall. * The original node form Tesla was in the walled area. * I use a single node for all the chargers that I have mapped including Tesla. If a charging site has limited amps going to the vehicle, then the J connector style can require a long time for a partial charge. Hence, this is not like a gas station where a single node is good enough. For example, an EV charger may be tied up for four hours in low amp settings. Tesla is changing the game with a 10 minute charge time. * The real address on the site is 444 South Watson Road[2]. The addressing authority did not send the address to the USPS so you will not find 444 as a valid USPS address via address correcting software. 444 is a valid Buckeye AZ address for emergency calls or for the utility company. If the address was submitted to USPS, then you'd receive a code saying that 444 was a valid address along with additional information saying that the USPS will not deliver mail to that site. 444 is on the south side of the walled area. * The 416 address is for the Carl's Jr. I have not added that photo to the OSM wiki yet. I am not sure if it would help. Perhaps Carl's Jr. is the operator/sponsor of the charger? If so, then that would be a savvy business move. Sponsoring the Tesla charger may help Carl's Jr. compete with the truck stops to the west of the location. USPS would deliver mail to the 416 address. * I put the Buckeye Supercharger name on the industrial landuse that I added to cover the switching cabinets. All the addresses and names would help someone find the location. Nominatim has already picked up the information. * I used Key Pad Mapper 2 to record all the reference numbers on each terminal. It looks like there is significance to the As and Bs in use[3]. * I used an idea that I picked up from Bryce on his Duro repair stations. I changed the original source tag to website. I added source as survey. Let's say that you program sets the source tag to auto or the program's name. If a mapper takes the time add the detail, then your program could use the survey tag as an indicator to discontinue the updates to the tags. * Feel free to hack and whack on the nodes that I created. It won't hurt my feelers and I won't stop mapping if you do. The wiki page is a mess right now[4]. I have found that it is a confusing topic to get straight as I am not an EV vehicle driver. I think there needs to be a US or North America section of the page that has a focus on what is used here. You all can hack and whack on the wiki page too. * One of the problems is that in a pinch, a regular RV socket can be used to charge the vehicles. That may mean that RV and EV tags could merge some day. * I'd encourage you to continue your efforts. Once you have the Tesla stations done, then you can try your hand at all the other chargers. I added a great deal of detail for a couple of SemaConnect Network chargers. I personally wouldn't do that in the future. Having an assisted editing system like what your are trying to develop would be a great help to enhance limited data that a mapper might include. All the other chargers require some sort of membership to a network unless the government is pushing a free one[5]. Such a deal! Spend $30K + on an EV and get free parking at a basketball or baseball game. ;-) HTH, Greg [1] http://www.openstreetmap.org/changeset/30205831 [2] http://wiki.openstreetmap.org/wiki/File:Cs_us_tesla_buckeye_charger.png [3] http://www.teslamotorsclub.com/showthread.php/42481-How-does-a-Supercharger-work [4] http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station [5] http://www.openstreetmap.org/node/3184125857 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-it] Proposta istituzione nuove chiavi per le scuole italiane
Simone Saviolo wrote Mah. Una cosa internazionale è l'ISCED. Tutto il resto che vogliamo descrivere è necessariamente peculiare per l'Italia. Mi sembra sufficientemente definito e utilizzato. +1 Concordo con quanto proposto da Luigi: in fondo già ora tagghiamo la scuola (intera area) come amenity=school e l'edificio come building=school (per il fatto che è un edificio con caratteristiche adatte, un edificio costruito a forma di scuola). Per me, se una certa struttura ospita un liceo classico, un magistrale e un liceo piscopedagogico, siamo davanti ad una struttura (edificio + cortile etc.) che ospita tre scuole. L'unico problema che vedo è: come indichiamo l'intera area? Esiste qualcosa tipo landuse=school? Lo si potrebbe fare eventualmente coincidere con l'unica scuola che sta in una struttura. dubbio che ormai ho da molto tempo e che avevo cercato di risolvere ben prima del problema posto dal CM...mai risolto neanche con l'ausilio della ML In Italia le possibilità sono infinite per quanto concerne le scuole (ed altri servizi): -area che delimita una sola scuola (in uno o più edifici) -area che delimita due o più scuole in due edifici diversi (con nomi e/o livelli differenti) ma condividenti lo stesso giardino (e spesso anche servizi quali ensa segreteria, presidenza parcheggio etc etc) -area che delimita uno o più edifici scolastici che ospitano più scuole (con nomi e/o livelli differenti). -unica scuola divisa tra più aree aree (con magari alcune di queste in condivisione con altri istituti con nome e/o livello differente) -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti e posti in aree differenti -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti ma che in alcune aree sono anche in condivisione con altri istituti (non appartenenti allo stesso circolo/circoscrizione e con nome e spesso anche livello differente) Essendoci tre codici, concordo. Ma valutiamo cmq bene quali sono questi codici: su building=school io consumatore ho ben chiaro che ref si riferisce al codice dell'edificio e non dell'istituto. anche per me sarebbe così In fondo però forse è meglio cmq usare un namespace, onde evitare problemi in futuro. in che senso? ciao Aury - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Proposta-istituzione-nuove-chiavi-per-le-scuole-italiane-tp5840407p5840676.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: [OSM-talk-fr] Problème cadastre.openstreetmap.fr
Super merci Vincent, je vais pouvoir reprendre une activité ajout de bâtiments normale. ;-) Nicolas - Nicolas Moyroud Site web libre@vous : http://libreavous.teledetection.fr - Le 14/04/2015 22:34, Vincent de Château-Thierry a écrit : Un redémarrage plus tard, ça semble rentré dans l'ordre. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cz] Mapy.cz s openstreetmap daty
-- Původní zpráva -- Od: Jan Martinec j...@martinec.name Komu: talk-cz@openstreetmap.org Datum: 14. 4. 2015 19:50:03 Předmět: Re: [Talk-cz] Mapy.cz s openstreetmap daty On 04/14/2015 06:22 PM, Miroslav Suchý wrote: On 04/14/2015 05:51 PM, Jan Martinec wrote: OSM data používá Seznam i v ČR, úplně potichu s tím vyjeli - jakýkoli changeset z OSM se obratem objevuje na Mapy.cz - poprvé jsem si náhodou všiml před pár měsíci tady, za OSM planet lagují cca o pár týdnů: To bych si dovolil nesouhlasil. Možná ty changesety sledují a berou jako zdroj informací co se kde změnilo. Ale rozhodně je nekopírují a už vůbec je automaticky nepřebírají. Ten changeset na Kačerově přebrali i s chlupama (předtím v OSM nebylo vůbec nic, a poté to Seznam zcela nezávisle zmapoval _identicky_ s OSM, včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne - každý renderer navíc je dobrá věc :) Nevím jak to mají v Seznamu rozdělené, ale asi bude hodně záležet na lidech. Někdo třeba monitoruje OSM, jiný ne. Případně záleží na obsahu daného changesetu. Těžko říct, možností je hodně. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
On Di, 2015-04-14 at 22:34 +0200, fly wrote: Am 14.04.2015 um 21:13 schrieb Michael Reichert: Am 2015-04-14 um 19:43 schrieb fly: Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig namespace-Tags begegnen, dann ist es doch leicht anders: emergency=fire_hydrant fire_hydrant:type=underground railway=signal railway:signal:... railway:signal:main:state:forward=* Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Nein, nur meiner Logik entsprungen. du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang sei, oder wie soll ich das jetzt verstehen? Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal:TYP:state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene Richtungen eingetragen werden können, würde die Tags noch komplizierter machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir können jedes Signal einzeln eintragen. Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter auf diversen Kanälen diskutiert und sowohl für Mapper als auch die Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. Wenn möglich sollte doch der ein oder andere Tag auch mit weniger Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). state:main:forward=* bzw wenn möglich sogar nur state=* height[:TYPE][:DIRECTION] Eindeutig ist das ganze doch schon durch railway=signal Das macht die Zuordnung interessiert mich der key für den Benutzer etwas einfacher, aber andere Dinge wir ref fallen da trotzdem aus der Reihe[1]. Welche Benutzer*innen meinst Du ? Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen Schlüssel schon eine Menge Platz aus und die wichtige Information steht am Ende. Ich sehe nicht, dass der Verzicht auf railway: bei den key-Namen eine große Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das überblicken kann, zu Kollisionen mit anderen Taggings führen würde. Wolltest wohl zu keinen Kollisionen schreiben Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in eckigen Klammern): - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) [distant] - ein Geschwindigkeitsanzeiger [speed] und/oder Geschwindigkeitsvoranzeiger [speed_limit] - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger [route](bei Streckenverzweigungen und mancherorts auch bei Gleiswechseln) - eine Haltetafel [stop] (die mit dem H) - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals [minor]. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor du solchen Unsinn schreibst. Lektüreempfehlung: http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert für Nicht-Bahnaffine. Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und versuche dann mein Glück Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. Wenn du ein wenig im Internet recherchieren würdest, würdest du recht schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter Anfang, ebenso die auf den ORM-Wikiseiten bei jedem
Re: [Talk-it] Proposta istituzione nuove chiavi per le scuole italiane
2015-04-15 9:02 GMT+02:00 Aury88 spacedrive...@gmail.com: -area che delimita una sola scuola (in uno o più edifici) in OSM: area dei limiti di sopra (incl. edifici, spazi esterni, ...) -area che delimita due o più scuole in due edifici diversi (con nomi e/o livelli differenti) ma condividenti lo stesso giardino (e spesso anche servizi quali ensa segreteria, presidenza parcheggio etc etc) 2 aree distinte, che si sovrapongono dove gli spazi sono in condivisione -area che delimita uno o più edifici scolastici che ospitano più scuole (con nomi e/o livelli differenti). più aree sovraposti, una per ogni scuola -unica scuola divisa tra più aree aree (con magari alcune di queste in condivisione con altri istituti con nome e/o livello differente) Diviso in più aree: multipoligono, il resto analogo di sopra. -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti e posti in aree differenti da risolvere tramite un nuovo tag, per esempio operator, network, ecc. -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti ma che in alcune aree sono anche in condivisione con altri istituti (non appartenenti allo stesso circolo/circoscrizione e con nome e spesso anche livello differente) in analogia di sopra Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-cz] Mapy.cz s openstreetmap daty
On 2015-04-14, 17:48 GMT, Jan Martinec wrote: včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne každý renderer navíc je dobrá věc :) Mají? Na http://napoveda.seznam.cz/cz/mapy/mapy-licencni-podminky/ vidím „© Přispěvatelé OpenStreetMap“ (jen mimo ČR a SR) což mi připadá že o tomhle konkrétním changsetu z OSM (pokud ho opravdu použili) lžou. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Reality is merely an illusion, albeit a very persistent one. -- Albert Einstein ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-at] [Talk-de] wpt_symbol, wpt_description
Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Am 15. April 2015 um 09:27 schrieb Alexander Matheisen alexandermathei...@ish.de: Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter auf diversen Kanälen diskutiert und sowohl für Mapper als auch die Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. für Mapper ist das m.E. einfacher als 2 und mehr genau übereinander liegende Nodes, die man einerseits nicht so einfach erstellen kann (manuelle Koordinateneingabe erforderlich), und wo man später leicht die weiteren Nodes übersieht. Wenn man hingegen nebeneinanderliegende Nodes mappt, stimmt es topologisch nicht (sind ja nicht mehrere Positionen sondern dieselbe). Für Auswerter könnte man es banal so machen: jede Node-relation wird zu einem eigenen Node an derselben Stelle umgewandelt (wobei man dann an dieser Stelle topologisch wieder ein Problem einführt, aber als Resultat nichts schlechteres erhält als bei genau übereinanderliegenden Nodes, und einen Vorteil hat gegenüber dicht beieinanderliegenden Nodes) --- oder man müsste sich was eigenes überlegen ;-). Praktikabel ist das in jedem Fall. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-ro] Copaci adaugai in mod agresiv pe harta
OSM este o baza de date, nu un engine de rutare. Baietii care fac engine-urile si hartile respective se vor asigura ca nu arata copacii. Daca intri pe hartile de la ITO World sau Stamen, de exemplu, vei vedea putine harti care arata copaci, *pentru ca au filtrat informatia. *The more data, the better, cat timp informatia e luata calumea (survey sau surse acceptate) si introdusa calumea. Rares 2015-04-15 10:02 GMT+03:00 Ciprian Talaba cipriantal...@gmail.com: Anatolie are dreptate, OSM este o baza de date geografica, nu o harta:* We would encourage users to contribute their data and knowledge to OpenStreetMap, project with free geographic data for the world *(de aici: https://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service ) Harta care o vedem pe osm.org este un produs generat pe baza acestor date, *dupa* ce acestea au fost filtrate. Acelasi lucru este valabil pentru orice motor de rutare bazat pe OSM, va folosi doar acele informatii necesare, deci nu vad unde este problema cu adaugarea copacilor. Ba chiar incurajez acest lucru atat timp cat informatia este corecta. --Ciprian 2015-04-15 9:40 GMT+03:00 lulumob lulu...@gmail.com: Salutare! Ma simt si eu cu musca pe caciula pentru zona asta: http://www.openstreetmap.org/#map=17/47.01160/27.44100 https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=!3m4!1e1!3m2!1s5Ff16tmOqBadNX6jN-e19w!2e0?hl=ro Si mie mi se pare cam exagerat ce s-a facut in Bucuresti, in sensul ca s-a pus carul in fata boilor. Sunt multe lucruri mai importante care lipsesc. Pe de alta parte, cred ca orice informatie corecta e utila si ca, intr-adevar, ar trebui ca softul sa filtreze ceea ce e inutil. Daca vreau navigatie pentru masina poate nu ma intereseaza copacii, daca fac geocaching poate nu ma intereseaza soselele. Exagerez putin, dar ideea cred ca se intelege. Si eu am mai marcat candva tomberoane de gunoi, banci, stalpi, lumini stradale si tot felul de lucruri mai putin importante, dar am facut-o ca exercitiu, constient ca utilitatea pentru majoritatea utilizatorilor e scazuta. Pentru un biciclist ca mine, insa, un stalp sau un copac pe o campie poate fi un reper important. Sunt de acord ca, daca softul nu poate filtra fara eforturi baza de date, ar trebui sa fim mai ponderati cu astfel de informatii. -- View this message in context: http://gis.19327.n5.nabble.com/Copaci-adaugai-in-mod-agresiv-pe-harta-tp5840499p5840673.html Sent from the Romania mailing list archive at Nabble.com. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro -- Life is not the amount of times you breathe, is the moments that take your breath away. To all things comes an end. And to all things comes a beginning. Cred in inspirat, nu in expirat. in vise, nu in somn. In trait, nu in existat. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-at] wpt_symbol, wpt_description
wpt_symbol kommt vom GPS Gerät und wurde offensichtlich beim Import in OSM vergessen zu entfernen. Analog dazu scheint mir wpt_description und name die automatisch erstellte Laufnummer zu sein. Ele ist dann die Höhe, welche aber anscheinend nicht gemessen wurde, weil sie immer auf 0.00 steht. Ich würde die Tags konträr zu Martins Meinung entfernen, da sie entweder Unsinnige Werte enthalten (die elevation ist an diesen Punkten sicher nicht 0) und der vergebene Name und Symbol aus der Aufzeichnungsphase stammen und keinen Bezug zur Wirklichkeit haben ( City (small) !? ) Am 2015-04-14 um 23:09 schrieb Rainer Fügenstein: hallo, bin heute auf meiner radtour durch einen wald gekommen, dessen polygon in OSM ein paar seltsame nodes enthält: http://www.openstreetmap.org/way/90024483 z.b.: http://www.openstreetmap.org/node/1043478866 http://www.openstreetmap.org/node/1043478911 deren tags scheinen keinen sinn zu machen. tags löschen? mfg ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] wpt_symbol, wpt_description
On 15.04.2015 08:56, Martin Vonwald wrote: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Ich finde das sehr wohl relevant, denn OSM ist ein Gemeinschaftsprojekt. Da kann nicht jeder machen, was er will, sondern alle Beiträge müssen so sein, dass sie gemeinschaftlich nutzbar sind. Map Notes für Treffpunkte oder hier wohnt Susi sind genauso ein Missbrauch wie Tags, die nur der Ersteller selber interpretieren kann. In einem Gemeinschaftsprojekt ist auch die Kommunikation wichtig. Wenn etwas unverständlich ist, dann muss es besprochen werden. Unklare Tags allerdings nicht in der Talk-AT-, sondern passender in der Tagging-Mailingliste. Zu aller erst sollte man aber den User kontaktieren, der die Daten angelegt hat. Im konkreten Fall ist das Max6. Ob er antwortet, steht in den Sternen, da er seit 4 Jahren nichts mehr editiert hat. Aber man kann es versuchen. Tatsächlich sind die Tags aber gar nicht so unklar, denn eine Google-Suche offenbart, dass sie das Relikt eines damaligen Potlatch-Bugs sind. Also kann man sie bedenkenlos löschen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] Problème cadastre.openstreetmap.fr
Bonjour, De: Nicolas Moyroud nmoyr...@free.fr Super merci Vincent, je vais pouvoir reprendre une activité ajout de bâtiments normale. ;-) Bien ;) Le 14/04/2015 22:34, Vincent de Château-Thierry a écrit : Un redémarrage plus tard, ça semble rentré dans l'ordre. Cependant, le redémarrage n'a pas tout redémarré : concrètement la mise à jour nocturne en automatique est désactivée, donc si vous voulez actualiser les données sur une commune, passez par http://cadastre.openstreetmap.fr/fantoir/ . vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cz] Mapy.cz s openstreetmap daty
-- Původní zpráva -- Od: MatějCepl mc...@cepl.eu Komu: talk-cz@openstreetmap.org Datum: 15. 4. 2015 11:03:05 Předmět: Re: [Talk-cz] Mapy.cz s openstreetmap daty On 2015-04-14, 17:48 GMT, Jan Martinec wrote: včetně tý neveřejný lávky do depa...tak určitě). Ale já s tím problém nemám: licenci (zdá se) dodržují, attribution mají, proč ne každý renderer navíc je dobrá věc :) Mají? Na http://napoveda.seznam.cz/cz/mapy/mapy-licencni-podminky/ vidím „© Přispěvatelé OpenStreetMap“ (jen mimo ČR a SR) což mi připadá že o tomhle konkrétním changsetu z OSM (pokud ho opravdu použili) lžou. Mají. Když se mrkneš na mapu, tak v levém dolním rohu vidím (c) přispěvatelé OpenStreetMap a to bohatě stačí. Marián Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Reality is merely an illusion, albeit a very persistent one. -- Albert Einstein ___ 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-at] wpt_symbol, wpt_description
On 2015-04-15 10:57, Stefan Kopetzky wrote: [...] Deshalb halte ich den existierenden evolutionären OSM-Ansatz für einfach überlegen. Genau das ist es auch aus meiner Sicht: Ein selbst regulierendes System - grundsätzlich evolutionär, was auch solche Diskussionen, wie diese, miteinschließt. In diesem konkreten Fall wären die Tags mit offensichtlich falschen Werten, wie ele, ohne wenn und aber gelöscht. Und wenn das ganze, so wie Friedrich schreibt, aus einem ehemaligen Potlach-Bug stammt, dann wäre das wirklich zu löschen. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Am 15.04.2015 um 10:34 schrieb Jo: Sind das nicht die tags die man im GPX XML findet? +1 Deswegen auch mit Tendenz zum löschen, vermutlich versehentlich hereingekommen. Kann man mal den Original-Autor fragen was das Tag soll? Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Proposta istituzione nuove chiavi per le scuole italiane
dieterdreist wrote 2015-04-15 9:02 GMT+02:00 Aury88 lt; spacedriver88@ gt;: -area che delimita una sola scuola (in uno o più edifici) in OSM: area dei limiti di sopra (incl. edifici, spazi esterni, ...) questa era facile :-P -area che delimita due o più scuole in due edifici diversi (con nomi e/o livelli differenti) ma condividenti lo stesso giardino (e spesso anche servizi quali ensa segreteria, presidenza parcheggio etc etc) 2 aree distinte, che si sovrapongono dove gli spazi sono in condivisione \quote le uniche aree distinte per certo (forse) sono gli edifici...il giardino appartiene alle due entità...dovrei fare un perimentro esterno scuola 1 ed un altro sovrapposto scuola 2 anche se so che in realtà di per se esiste una separazione netta per quanto concerne le strutture in cui ci sono le due scuole? avrei preferito un tag landuse=school e poi trasferire il tag amenity agli edifici in modo da rendere neutrale il giardino... poi c'è da considerare che magari gli edifici delle due scuole sono distinti ma in uno è presente la segreteria/mensa di entrambi e/o ce la mensa... come si fa...di per se la scuola si fa da un altra parte.. -area che delimita uno o più edifici scolastici che ospitano più scuole (con nomi e/o livelli differenti). più aree sovraposti, una per ogni scuola si può fare? davo per scontato che fosse disincentivato se non vietato sovrappore way...sopratutto se con tag uguali...perchè non due relazioni multipoligono con i dati delle due scuole applicati alla stessa way chiusa perimetrale (suolo outer per entrambi)? -unica scuola divisa tra più aree aree (con magari alcune di queste in condivisione con altri istituti con nome e/o livello differente) Diviso in più aree: multipoligono, il resto analogo di sopra. perchè non relazione multipoligono applicata ai vari perimentri e poi un altra relazione multipoligo sul perimetro dell'area condivisa con un'altra scuola con i dati di quest'ultima? -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti e posti in aree differenti da risolvere tramite un nuovo tag, per esempio operator, network, ecc. \quote ecco io qui ho dei forti dubbi...non potrei definire tendenzialmente questa unione sempre tramite relazione multipoligono inserendo qui i tag comuni a tutti (quindi operator e network che suggerisci tu e in più il nome della circoscrizione ) e poi mettere tutto il resto, per caratterizzare le singole aree, sulle way perimentrali tramite tag o tag di relazioni (in caso d aree condivise tra più stituzioni?)... ti chiedo se vanno bene queste proposte non per far il bastian contrario, ma perchè mi sembra più ordinato usufruire del multipoligono come metodologia/espediente per evitare le sovrapposizioni di way (che, almeno io, tramite editor online, non potrei selezionare singolarmente) o per creare una sorta di gerarchizzazione-unione delle informazioni/enti...e solo che non so se sia lecito l'utilizzo del multipoligono per questo genere di problematiche non prettamente geometiche. un ultimo dubbio è sul nome della scuola...se una scuola è chiamata scuola materna sempronio il tag name è scuola materna sempronio o solo sempronio e il resto lo ometto venendo già descritto dagli altri tag? come si comporta la ricerca della stringa scuola sempronio o materna sempronio? ma forse è il caso di lasciare questa domanda ad un'altra discussione - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Proposta-istituzione-nuove-chiavi-per-le-scuole-italiane-tp5840407p5840699.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-at] Einladung zur Mapping-Party am BarCamp Graz
Hallo, wir vom OSM-Stammtisch Graz haben vor, am heurigen BarCamp Graz¹ wieder eine Mapping-Party zu veranstalten. [1] http://barcamp-graz.at/ Fr 17.4.-So 19.4., FH Joanneum Graz, Alte Poststraße 152 Sie wird am Freitag Nachmittag stattfinden, ich habe ~16:00 als Startzeitpunkt angepeilt. Aber wie das bei BarCamps so ist, ist das nur ein Richtwert ;-) Geplant ist, die Umgebung Richtung Gemeindepark Eggenberg² zu begehen, und danach wieder an der FH die erfassten Dinge einzutragen. [2] https://www.openstreetmap.org/way/23621642#map=17/47.06843/15.40492 Wir hoffen auf schönes Wetter und freuen uns auf zahlreiches erscheinen! lg, Michi -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station Ich kann zum Beispiel den Unterschied sanitary_dump_station:suction=yes und sanitary_dump_station:pump-out=yes nicht erkennen. da scheint es auch gar keinen zu geben. suction (Absaugen) steht hier: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dsanitary_dump_station#Tagging_the_Facility_Type als Erklärung für pump-out (auspumpen), auf der Wikiseite kommt das Wort sonst nicht vor. Laut taginfo kommt der tag sanitary_dump_station:suction weltweit 6 mal vor (pump-out 9x) Es wäre schön wenn es noch andere Camper oder Bootsführer gäbe, die dort mit drüber schauen. +1 ich kenne mich da leider gar nicht aus, melde mich hier nur zu Wort, weil Bryce mich um Hilfe gebeten hatte, die Sprachbarrieren zu überwinden, er kann wohl etwas Deutsch, es reicht aber nicht, um die Diskussion auf Deutsch zu führen. Soweit ich das verstanden habe will er gerne das tagging vereinheitlichen und dokumentieren, weil es wohl derzeit sehr fragmentiert ist. Er versucht daher ein allgemeingültiges Schema zu etablieren, das man weltweit einsetzen kann. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.
Am 14. April 2015 um 17:33 schrieb gmbo g...@kilometerfresser.eu: Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist. Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme benutzt werden. soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung / Anschluss um Flüssigkeit Feststoffe zu transferieren), während Gisbert, soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die man entsorgen kann, in einem tag verquicken würde. Ausserdem gefällt ihm der tag sanitary_dump_station:chemical_toilet nicht so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur Benutzung durch Menschen sieht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] wpt_symbol, wpt_description
On Wed, 15 Apr 2015 08:56:34 +0200 Martin Vonwald imagic@gmail.com wrote: 2015-04-14 23:09 GMT+02:00: deren tags scheinen keinen sinn zu machen. tags löschen? Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! Unschön da nicht dokumentiert, aber irgendwas wird sich derjenige, der sie eingetragen hat, schon dabei gedacht haben. Ob die Tags Sinn machen? Keine Ahnung, ist auch irrelevant. Any tags you like! Nur weil ich einen Tag nicht verstehe, lösche ich ihn nicht! * Warum Plural? Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. Solange man die Arbeit anderer nicht zunichte macht, darf man eintragen was man will (der erste der mir jetzt mit Datensparsamkeit kommt, bekommt das hier: http://i.imgur.com/iWKad22.jpg). Man kann ein Projekt mit so vielen Teilnehmern wie OSM natürlich komplett anarchistisch durchziehen, wie du es scheinbar für gut hältst. Ohne Planung ist das ganze halt nicht besonders effizient und führt auf Dauer zu Konflikten, Mehrarbeit und unnötiger Komplexität (mit einem Rattenschwanz an weiteren Problemen). Es gibt also durchaus Argumente, die man zwar mit Facepalms wegwischen versuchen kann; aber man wird sich damit nicht nur Freunde machen. PS: Bei der Verknüpfung von Freier Arbeit und Verantwortungslosigkeit (NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?), finde ich einen Facepalm schon wesentlich angebrachter. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Sind das nicht die tags die man im GPX XML findet? Die haben tatsächlich nichts verloren in OSM. Polyglot 2015-04-15 9:40 GMT+02:00 Peter Barth osm-p...@won2.de: Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ 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
Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description
Am 15. April 2015 um 08:56 schrieb Martin Vonwald imagic@gmail.com: Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. jein. Ich fände es ehrlich gesagt schon ein Problem, wenn die Offenheit des Projektes dadurch gefährdet würde, dass (hypothetisch) absichtlich undokumentierte Codes zur Anwendung kämen, um den Inhalt der tags zu verschleiern, z.B. proprietarymaps:123:12=Q34F5 (rein fiktives Beispiel). Deshalb kann ich Deine Ausführungen nicht pauschal unterschreiben, finde im konkreten Fall aber die Schwelle noch nicht überschritten. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] [Talk-de] wpt_symbol, wpt_description
Am 15. April 2015 um 08:56 schrieb Martin Vonwald imagic@gmail.com: Weil die Unsitte in weiten Bereichen OSMs einzieht, dass jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist nicht und wird - solange ich dabei bin - nicht erforderlich sein, von irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen. jein. Ich fände es ehrlich gesagt schon ein Problem, wenn die Offenheit des Projektes dadurch gefährdet würde, dass (hypothetisch) absichtlich undokumentierte Codes zur Anwendung kämen, um den Inhalt der tags zu verschleiern, z.B. proprietarymaps:123:12=Q34F5 (rein fiktives Beispiel). Deshalb kann ich Deine Ausführungen nicht pauschal unterschreiben, finde im konkreten Fall aber die Schwelle noch nicht überschritten. Gruß, Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] [Talk-de] wpt_symbol, wpt_description
Sind das nicht die tags die man im GPX XML findet? Die haben tatsächlich nichts verloren in OSM. Polyglot 2015-04-15 9:40 GMT+02:00 Peter Barth osm-p...@won2.de: Hallo, Martin Vonwald schrieb: Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben undokumentierte Tags. C'est la vie! [...] sry Martin, aber dem kann ich mich nicht anschließen da die Tags offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die beiden zumindest sind dokumentiert und wie gesagt offensichtlicher Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das schon nach Tagging für irgendeinen Renderer an. Wenn dann ein City (Small) an einem Wald klebt .. Gruß, Peda ___ Talk-de mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it] Proposta istituzione nuove chiavi per le scuole italiane
2015-04-15 12:39 GMT+02:00 Aury88 spacedrive...@gmail.com: 2 aree distinte, che si sovrapongono dove gli spazi sono in condivisione \quote le uniche aree distinte per certo (forse) sono gli edifici...il giardino appartiene alle due entità...dovrei fare un perimentro esterno scuola 1 ed un altro sovrapposto scuola 2 anche se so che in realtà di per se esiste una separazione netta per quanto concerne le strutture in cui ci sono le due scuole? al solito farai 2 perimetri, uno per ogni scuola, che comprende sia l'edificio che gli altri spazi (forse devi tagliare un edificio con relazione MP). avrei preferito un tag landuse=school e poi trasferire il tag amenity agli edifici in modo da rendere neutrale il giardino... ma non è neutrale il giardino, appartiene a tutte le 2 scuole. poi c'è da considerare che magari gli edifici delle due scuole sono distinti ma in uno è presente la segreteria/mensa di entrambi e/o ce la mensa... come si fa...di per se la scuola si fa da un altra parte.. si, questo dipende dal livello di dettaglio che vuoi mappare. Ci riparliamo quando arriviamo a quel livello di dettaglio ;-) più aree sovraposti, una per ogni scuola si può fare? certo, lo devi fare anche nel altro caso (giardino / parcheggio condiviso). davo per scontato che fosse disincentivato se non vietato sovrappore way...sopratutto se con tag uguali...perchè non due relazioni multipoligono con i dati delle due scuole applicati alla stessa way chiusa perimetrale (suolo outer per entrambi)? si, non parlavo di way, parlavo di aree, quindi in pratica farei relazioni MP.scuola con i dati di quest'ultima? -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti e posti in aree differenti da risolvere tramite un nuovo tag, per esempio operator, network, ecc. \quote ecco io qui ho dei forti dubbi...non potrei definire tendenzialmente questa unione sempre tramite relazione multipoligono inserendo qui i tag comuni a tutti (quindi operator e network che suggerisci tu e in più il nome della circoscrizione ) in realtà ci si vuole un tag che dice circoscrizione, altrimenti hai un insieme di cose con un nome, ma non sai di cosa si tratta. un ultimo dubbio è sul nome della scuola...se una scuola è chiamata scuola materna sempronio il tag name è scuola materna sempronio o solo sempronio e il resto lo ometto venendo già descritto dagli altri tag? L'ultima parola ha il mappatore, ma per me il nome sarebbe Scuola Materna Sempronio come si comporta la ricerca della stringa scuola sempronio o materna sempronio? non ci interessa, spero che si comporti bene, senno dovrebbe essere migliorata ;-) Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-de] Ankündigung: Aufzeichnung Radio-OSM Folge 042 am Montag 20.4.2015
FYI: wir planen im Moment die aktuelle Folge 042 mit der Antwort auf alle Fragen in OSM ;-) am Montag Abend 20.04.2015 aufzuzeichnen. http://podcast.openstreetmap.de/ueber/ Dieses Mal ist wieder ein Streaming via Xenim vorgesehen (http://streams.xenim.de/osm/) so dass ein live zuhören möglich sein sollte. Wer via Mumble aktiv teilnehmen will findet die Info hierzu unter http://podcast.openstreetmap.de/mitmachen/ . Die geplanten Themen findet Ihr wie immer im Trello (ist noch nicht abgeschlossen und entwickelt sich gerade noch): https://trello.com/b/YvlitJTs/radioosm-contentplanung. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-ro] Copaci adaugai in mod agresiv pe harta
Daca nu exista intentia sa se foloseasca si pentru rutare, atunci nu mai existau taguri de limita de viteza, de surface , de nr. lane, etc. Nu mai exista intentia ca aceste taguri sa fie diversificate tocmai pentru putea ajusta cat mai mult posibil rutarea si din partea hartii, nu numai a navigatoarelor. Rutarea pe aceasta harta este ca si cireasa de pe tort. Majoritatea celor care o cauta, o cauta sa o utilizeze pe diferite navigatoare, nu ca un simplu atlas. Pana si diferite firme de taxi acum utilizeza osm... On 15.04.2015 12:14, Filip Chirita Rares Cristian wrote: OSM este o baza de date, nu un engine de rutare. Baietii care fac engine-urile si hartile respective se vor asigura ca nu arata copacii. Daca intri pe hartile de la ITO World sau Stamen, de exemplu, vei vedea putine harti care arata copaci, *pentru ca au filtrat informatia. *The more data, the better, cat timp informatia e luata calumea (survey sau surse acceptate) si introdusa calumea. Rares 2015-04-15 10:02 GMT+03:00 Ciprian Talaba cipriantal...@gmail.com mailto:cipriantal...@gmail.com: Anatolie are dreptate, OSM este o baza de date geografica, nu o harta:*We would encourage users to contribute their data and knowledge to OpenStreetMap, project with free geographic data for the world *(de aici: https://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service) Harta care o vedem pe osm.org http://osm.org este un produs generat pe baza acestor date, *dupa* ce acestea au fost filtrate. Acelasi lucru este valabil pentru orice motor de rutare bazat pe OSM, va folosi doar acele informatii necesare, deci nu vad unde este problema cu adaugarea copacilor. Ba chiar incurajez acest lucru atat timp cat informatia este corecta. --Ciprian 2015-04-15 9:40 GMT+03:00 lulumob lulu...@gmail.com mailto:lulu...@gmail.com: Salutare! Ma simt si eu cu musca pe caciula pentru zona asta: http://www.openstreetmap.org/#map=17/47.01160/27.44100 https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=!3m4!1e1!3m2!1s5Ff16tmOqBadNX6jN-e19w!2e0?hl=ro https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=%213m4%211e1%213m2%211s5Ff16tmOqBadNX6jN-e19w%212e0?hl=ro Si mie mi se pare cam exagerat ce s-a facut in Bucuresti, in sensul ca s-a pus carul in fata boilor. Sunt multe lucruri mai importante care lipsesc. Pe de alta parte, cred ca orice informatie corecta e utila si ca, intr-adevar, ar trebui ca softul sa filtreze ceea ce e inutil. Daca vreau navigatie pentru masina poate nu ma intereseaza copacii, daca fac geocaching poate nu ma intereseaza soselele. Exagerez putin, dar ideea cred ca se intelege. Si eu am mai marcat candva tomberoane de gunoi, banci, stalpi, lumini stradale si tot felul de lucruri mai putin importante, dar am facut-o ca exercitiu, constient ca utilitatea pentru majoritatea utilizatorilor e scazuta. Pentru un biciclist ca mine, insa, un stalp sau un copac pe o campie poate fi un reper important. Sunt de acord ca, daca softul nu poate filtra fara eforturi baza de date, ar trebui sa fim mai ponderati cu astfel de informatii. -- View this message in context: http://gis.19327.n5.nabble.com/Copaci-adaugai-in-mod-agresiv-pe-harta-tp5840499p5840673.html Sent from the Romania mailing list archive at Nabble.com. ___ Talk-ro mailing list Talk-ro@openstreetmap.org mailto:Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org mailto:Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro -- Life is not the amount of times you breathe, is the moments that take your breath away. To all things comes an end. And to all things comes a beginning. Cred in inspirat, nu in expirat. in vise, nu in somn. In trait, nu in existat. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-it] Proposta istituzione nuove chiavi per le scuole italiane
dieterdreist wrote ma non è neutrale il giardino, appartiene a tutte le 2 scuole. mi sono scordato di dirlo, ma il giardino a cui mi riferisco io in realtà tra le altre cose è usato anche da una palestra...naturalmente non nell'orario di esercizio delle scuole. si, non parlavo di way, parlavo di aree, quindi in pratica farei relazioni MP.scuola con i dati di quest'ultima? ok, perfetto mavo stupidamente per scontato che per aree sovrapposte intendessi way chiuse sovrapposte e non una way chiusa appartenete a più relazioni MP. nn ho capito la domanda. -insieme di scuole appartenenti allo stesso circolo o circoscrizione con nomi e/o livelli differenti e posti in aree differenti da risolvere tramite un nuovo tag, per esempio operator, network, ecc. \quote ecco io qui ho dei forti dubbi...non potrei definire tendenzialmente questa unione sempre tramite relazione multipoligono inserendo qui i tag comuni a tutti (quindi operator e network che suggerisci tu e in più il nome della circoscrizione ) in realtà ci si vuole un tag che dice circoscrizione, altrimenti hai un insieme di cose con un nome, ma non sai di cosa si tratta. scusa e per questo che volevo mettere comunque il tag operator e/o network alla relazione multipoligono...solo che invece di applicarlo alle singole scuole lo volevo applicare alla relazione che le accomuna...non va bene? un ultimo dubbio è sul nome della scuola...se una scuola è chiamata scuola materna sempronio il tag name è scuola materna sempronio o solo sempronio e il resto lo ometto venendo già descritto dagli altri tag? L'ultima parola ha il mappatore, ma per me il nome sarebbe Scuola Materna Sempronio perfetto. grazie mille ciao, Aury - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Proposta-istituzione-nuove-chiavi-per-le-scuole-italiane-tp5840407p5840706.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-ro] Copaci adaugai in mod agresiv pe harta
Poți face multe lucruri cu datele din OSM. De exemplu, eu am făcut un set de hărți cu trasee montane[1], și îmi prinde bine că sunt multe informații care nu au legătură cu rutarea pe șosele: poteci montane, cabane, refugii, vârfuri, șei, râuri, landcover complet. Mă bate gândul să afișez și liniile de înaltă tensiune, pot fi utile la orientare. Tot ce vezi pe harta aia provine din OSM, mai puțin curbele de nivel, care într-adevăr nu își găsesc locul acolo. -- Alex [1] http://haihui.grep.ro On 15 Apr 2015, at 14:14, Rădulescu Răzvan radulescu.raz...@gmail.com wrote: Daca nu exista intentia sa se foloseasca si pentru rutare, atunci nu mai existau taguri de limita de viteza, de surface , de nr. lane, etc. Nu mai exista intentia ca aceste taguri sa fie diversificate tocmai pentru putea ajusta cat mai mult posibil rutarea si din partea hartii, nu numai a navigatoarelor. Rutarea pe aceasta harta este ca si cireasa de pe tort. Majoritatea celor care o cauta, o cauta sa o utilizeze pe diferite navigatoare, nu ca un simplu atlas. Pana si diferite firme de taxi acum utilizeza osm... On 15.04.2015 12:14, Filip Chirita Rares Cristian wrote: OSM este o baza de date, nu un engine de rutare. Baietii care fac engine-urile si hartile respective se vor asigura ca nu arata copacii. Daca intri pe hartile de la ITO World sau Stamen, de exemplu, vei vedea putine harti care arata copaci, pentru ca au filtrat informatia. The more data, the better, cat timp informatia e luata calumea (survey sau surse acceptate) si introdusa calumea. Rares 2015-04-15 10:02 GMT+03:00 Ciprian Talaba cipriantal...@gmail.com: Anatolie are dreptate, OSM este o baza de date geografica, nu o harta: We would encourage users to contribute their data and knowledge to OpenStreetMap, project with free geographic data for the world (de aici: https://wiki.openstreetmap.org/wiki/Why_OSM_and_not_another_collaborative_mapping_service) Harta care o vedem pe osm.org este un produs generat pe baza acestor date, *dupa* ce acestea au fost filtrate. Acelasi lucru este valabil pentru orice motor de rutare bazat pe OSM, va folosi doar acele informatii necesare, deci nu vad unde este problema cu adaugarea copacilor. Ba chiar incurajez acest lucru atat timp cat informatia este corecta. --Ciprian 2015-04-15 9:40 GMT+03:00 lulumob lulu...@gmail.com: Salutare! Ma simt si eu cu musca pe caciula pentru zona asta: http://www.openstreetmap.org/#map=17/47.01160/27.44100 https://www.google.ro/maps/@47.012585,27.438911,3a,75y,142.29h,80.95t/data=!3m4!1e1!3m2!1s5Ff16tmOqBadNX6jN-e19w!2e0?hl=ro Si mie mi se pare cam exagerat ce s-a facut in Bucuresti, in sensul ca s-a pus carul in fata boilor. Sunt multe lucruri mai importante care lipsesc. Pe de alta parte, cred ca orice informatie corecta e utila si ca, intr-adevar, ar trebui ca softul sa filtreze ceea ce e inutil. Daca vreau navigatie pentru masina poate nu ma intereseaza copacii, daca fac geocaching poate nu ma intereseaza soselele. Exagerez putin, dar ideea cred ca se intelege. Si eu am mai marcat candva tomberoane de gunoi, banci, stalpi, lumini stradale si tot felul de lucruri mai putin importante, dar am facut-o ca exercitiu, constient ca utilitatea pentru majoritatea utilizatorilor e scazuta. Pentru un biciclist ca mine, insa, un stalp sau un copac pe o campie poate fi un reper important. Sunt de acord ca, daca softul nu poate filtra fara eforturi baza de date, ar trebui sa fim mai ponderati cu astfel de informatii. -- View this message in context: http://gis.19327.n5.nabble.com/Copaci-adaugai-in-mod-agresiv-pe-harta-tp5840499p5840673.html Sent from the Romania mailing list archive at Nabble.com. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro -- Life is not the amount of times you breathe, is the moments that take your breath away. To all things comes an end. And to all things comes a beginning. Cred in inspirat, nu in expirat. in vise, nu in somn. In trait, nu in existat. ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [talk-au] Use of mapconnect data in OSM [SEC=UNCLASSIFIED]
The data in Mapconnect can be up to 8 years old. It originally came from both CAPAD and the states/territories, and was generalised to be consistent with a cartographic map at a scale of 1:250,000. CAPAD has come from the states / territories, and probably from the national park authorities rather than the mapping agency. There will be differences. I would also be keen to hear what the limitations in the CCBY licence is. If you want to use the data in Mapconnect then I can chase up an alternative licence/permission to use if the current license doesn't work. Thanks, Simon Simon Costello Branch Head, National Location Information | EGD Management Environmental Geoscience Division | GEOSCIENCE AUSTRALIA Phone: +61 2 6249 9716tel:+61%202%206249%209716Fax: +61 2 6249 tel:+61%202%206249%20 Email: simon.coste...@ga.gov.aumailto:simon.coste...@ga.gov.auWeb: www.ga.gov.auhttp://www.ga.gov.au/ Cnr Jerrabomberra Avenue and Hindmarsh Drive Symonston ACT GPO Box 378 Canberra ACT 2601 Australiax-apple-data-detectors://3 Applying geoscience to Australia's most important challenges On 7 Apr 2015, at 10:03 pm, talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org wrote: Send Talk-au mailing list submissions to talk-au@openstreetmap.orgmailto:talk-au@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-au or, via email, send a message with subject or body 'help' to talk-au-requ...@openstreetmap.orgmailto:talk-au-requ...@openstreetmap.org You can reach the person managing the list at talk-au-ow...@openstreetmap.orgmailto:talk-au-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-au digest... Today's Topics: 1. Re: Use of mapconnect data in OSM (Andrew Harvey) 2. Re: Use of mapconnect data in OSM (Ross) 3. Use of mapconnect data in OSM (Ross) (Warren) mime-attachment mime-attachment mime-attachment ___ Talk-au mailing list Talk-au@openstreetmap.orgmailto:Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks. - ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
