Introdução

A motivação da qual me levou a escrever este “pequeno testamento” foi a inexistência de uma definição clara e imediata do uso da etiqueta network no contexto de transportes público, sobretudo no que toca ao autocarro.

O estado atual

Wiki

Na página wiki Key:network, como se trata de um termo “banda-larga” em que é usado em diversos áreas e contextos, na explicação do seu uso em transportes públicos perde-se um pouco das suas especificadades da sua aplicação em alguns contextos, em particular no de rotas de autocarros. Nesta página, o termo network é definido de forma vaga e como tal, na definição usada, uma rede de transportes públicos pode significar:

• a rede de operação de uma empresa de transporte público ou o aglomerado de várias (o que é similar a operator=*) ;
• a abragência geográfica (e.g. antigo sistema de coroas que existia em Lisboa até Abril de 2019);
• um sistema de bilhética.

Uma vez que existe ambiguidade nesta definição, a qual também se encontra na página wiki dedicada aos Transportes Públicos, uma primeira leitura mais superficial indicaria que cabe a cada comunidade escolher o que significa a etiqueta para cada dado contexto.

No entanto, ao aprofundar-mos a nossa pesquisa e lermos a secção relativa às relações network da página wiki Buses , sendo estas relações então aplicadas no âmbito de transporte público rodoviário, temos uma explicação melhor e mais precisa do que esta etiqueta pretende formular neste assunto. Citando a página:

A network relation can be used to link each member of a network together. The network relation represents existing networks (i.e. a common fare system) . Network relations can be hard to work with, and have therefore been deprecated in some places (for example Germany). Using network=* on each bus route and route master relation is preferred over network relations.

Ora esta explicação fala num sistema de bilhética comum, que no contexto da AML e, com alguma extensão, do distritito de Lisboa, este sistema pode ser encarado como o que é oferecido pelos passes intermodais Lisboa VIVA / Navegante, nomeadamente os títulos Navegante Municipal e Navegante Metropolitano.

Uma Proposta

Formulação

No link mencionado no final da secção anterior temos as várias modalidades de passe Navegante, das quais se configuram em duas categorias:

1. Os usuais: Navegante Municipal; Navegante Metropolitano
2. Caracter Social: Navegante 12; Navegante +65; Navegante Família; Navegante Municipal Família.

Para o efeito de etiquetagem, optando pela simplicidade, só interessar-nos-á a primeira categoria uma vez que os passes da segunda são apenas variantes dos da primeira onde diferem apenas no preço.

Aponta-se também que a proposta que será de seguida definida poderá ser extendida para outras Comunidades Intermunicipais, algo que será explorado nos exemplos nas secções mais posteriores.

Em paragens/estações

Seja uma paragem que se encontre na AML, no território de um munícipio X desta. De imediato, por se encontrar dentro da AML, vem que um dos valores para network vai ser Navegante Metropolitano .

No que toca aos Navegantes Municipais, há algumas subtilezas a ter em conta, especialmente quando se fala de paragens que integrem rotas de carreiras suburbanas que partam de Lisboa. Este facto é relevante pois são aplicadas restrições às operadoras destas carreiras para que não façam saídas e/ou entradas em Lisboa ao sair e/ou entrar em Lisboa, respetivamente. Este mesmo facto é mencionado no local das paragens onde costuma estar escrito “Apenas Entradas” ou “Apenas Saídas”, respetivamente.

Portanto, ao partir de uma paragem caso seja possível apanhar um meio de transporte que pare no mesmo município X donde se partiu, então podemos adicionar o valor Navegante X à etiqueta.

Exemplificando: digamos que se apanha numa paragem de entradas apenas no Lumiar (portanto Município de Lisboa) em que todos os autocarros que operem essa mesma paragem só parem a seguir para sair nos concelhos vizinhos (Odivelas ou Loures). Assim, a paragem não terá a etiqueta com o valor Navegante Lisboa pois não é possível sair na paragem e não é possível entrar na paragem sem depois sair fora do Município de Lisboa.

Em Rotas

Seja uma carreira que se encontre na AML. Aplicando o mesmo princípio de entrada e saída no mesmo município explicado acima associamos os mesmo valores que seriam aplicados a paragens. No contexto de rotas teremos de ver se, dentro do que as mesmas abrangem, é possível entrar e sair com um passe Navegante associado.

Para alguns exemplos deste esquema, ver secção “Mais exemplos”.

Justificação

Usar o sistema de passes como base da etiqueta network=* é mais informativo e útil face ao uso de network=Carris Metropolitana, uma vez que vão haver (assumindo que o sistema de passes se mantiver) algumas descrepâncias entre a rede de operação da Carris Metropolitana e a abragência dos passes, em particular do passe mais geral, o Navegante Metropolitano. Essa questão é ilustrada, para ser mais específico, nas carreiras interregionais em que cuja operação será eventualmente assegurada pela Carris Metropolitana (ler secção “A Grande Lisboa em Lotes” e competências delegadas na AML ) mas que não se inserem (pelo menos parcialmente) no quadro dos passes supramencionados. Exemplos de algumas carreiras deste género são:

• AML -> Torres Vedras (Barraqueiro do Oeste, Mafrense e Boa Viagem)
• AML -> Arruda dos Vinhos / Sobral de Monte Agraço (Boa Viagem)
• Bucelas -> A-de-Camondes (Rodoviária de Lisboa)
• AML -> Vendas Novas (Rodoviária do Alentejo)

Um outro ponto a favor desta abordagem é que não só permitiria incluir outros modos de transporte coletivo de passageiros que são também abrangidos por estes passes (tais como comboio e barco) como também permitiria uma melhor claridade e diferenciação das outras “redes” de transporte que têm uma tipologia diferente das previamente mencionadas. Alguns exemplos concretos seriam o transporte turístico (e.g. Yellow Bus Tours) e os autocarros de longo curso (e.g. Rede Expresso e Flixbus).

De se notar que estas duas abordagens entram em conflito uma com a outra dado que usufruem da mesma etiqueta com interpretações diferentes desta (i.e. network enquanto rede de operação vs network enquanto sistema de bilhética). Como tal, será impossível de fazer menção a estes dois usos através da mesma etiqueta. Desse modo, para garantir a menção da Carris Metropolitana na base de dados do OSM, sugiro o uso da etiqueta brand=Carris Metropolina para resolver esta problemática. Não obstante, faço os seguintes pontos: a) não seria possível usar a chave brand para um sistema de bilhética; b) esta abordagem é conforme com o que a própria entidade afirma ser (ler Perguntas Frequentes#O que é a Carris Metropolitana?).

Mais exemplos

Pretende-se então ilustrar em casos concretos, com exemplos mapeados e não mapeados, de como seria efectuada a etiquetagem caso fosse aplicado o esquema proposto.

1. Rodoviaria de Lisboa, Carreira 362
   • operator=Rodoviária de Lisboa
   • network=Navegante Loures; Navegante Metropolitano
2. Carris, Carreira 736
   • operator=Carris
   • network=Navegante Lisboa; Navegante Odivelas; Navegante Metropolitano
3. Mafrense, Carreira 209
   • operator=Mafrense
   • network=Navegante Mafra;Navegante Metropolitano
4. Lisboa Transportes, Carreira 128
   • operator=Lisboa Transportes
   • network=Navegante Amadora; Navegante Metropolitano
5. Barraqueiro do Oeste, Carreira 701 (não mapeado)
   • operator=Barraqueiro do Oeste
   • network=Navegante Mafra; Navegante Metropolitano; Passe Linha Torres Vedras; Passe Linha CIMO
6. Rodoviária de Lisboa, Carreira 331
   • operator=Rodoviária de Lisboa
   • network=Navegante Loures; Navegante Odivelas; Navegante Metropolitano

Notas e detalhes técnicos

• Quando a Carris Metropolitana eventualmente for encetar as suas funções bastariam as seguintes alterações: a) substituir no valor da chave operator as operadoras anteriores pelas que começarão a sua explorarão nos lotes designados (ver acima para mais informações); b) adicionar a etiqueta brand=Carris Metropolitana .
• Nos exemplos acima, algums do exemplos apresentam carreiras que partem de/terminam em Lisboa mas que no entanto não estão integradas na rede Navegante Lisboa devido ao facto de serem carreiras suburbanas em que o passageiro não pode entrar e sair dentro da zona Lisboa, i.e. não se pode circular exclusivamente em Lisboa. Isto pode acontecer porque: a) só a paragem terminal é que se encontra em Lisboa e todas as restantes se encontram fora desta; b) as paragens à saída de Lisboa são de “entradas apenas” e à entrada de Lisboa são de “saídas apenas”.
• Similarmente à AML, algumas das Comunidades Intermunicipais que rodeiam a mesma introduziram passes intermodais dentro das suas regiões, como é o caso da OesteCIM, onde existem passes intraregionais e interregionais (entre OesteCIM e AML).
  • A única menção que encontrei dos nomes dos passes da OesteCIM foi no site da Barraqueiro do Oeste. Como tal, usei tal nomenclatura no exemplo 5.

Nota final sobre casos de uso

Friso, para terminar esta entrada, que, de um ponto de vista do consumidor de dados, ter estes dados estruturados desta forma permitirá “extrair” as várias interpretações supramencionadas nesta entrada de diário sem criar um esquema totalmente novo de etiquetas:

• uma procura por operadora, usando a etiqueta operator, e mostraria a rede de operação;
• uma procura por sistema de bilhética, usando a etiqueta network, e mostraria a abragência que um passe teria;
• uma procura por marca, usando a etiqueta brand, e mostraria o todo da rede incluindo todas as redes de operação das operadoras que federam para formar a respetiva marca;
• uma procura das rotas de transporte público que se encontrem inseridas numa dada região geográfica e mostraria que rotas estavam a abranger essa mesma região.

Post Scriptum: Todos os links para sites externos ao OSM foram arquivados no Wayback Machine para futura referência.

Esse ano tive uma oportunidade incrível de poder participar do HOT Data Quality Intership, ter sido escolhido para poder participar dessas doze semanas foi a melhor coisa que me aconteceu esse ano, eu senti como se todo meu trabalho no OpenStreetMap tivesse sido reconhecido naquele momento. Gostaria de agradecer a todos que compartilharam seus conhecimentos nos treinamentos e também para os coordenadores do projeto Sam e Becky muito obrigado!!

Sem duvida foi uma experiencia que levarei para a vida, conheci pessoas incríveis e de vários países diferentes…

Sem duvida é um programa único para mapeadores do OpenStreetMap e ajuda a comunidade a crescer, ao dar essa oportunidade de inspirar e dar suporte para que jovens como eu possam aprender mais sobre o OSM e o ecossistema em volta não tem preço, imagino que assim como eu meus colegas continuaram a contribuir para o OSM em suas comunidades locais…

Aqui devo ressaltar a importância de programas como Data Quality Intership em poder financiar e impactar as comunidades locais ao redor do mundo, talvez seria interessante expandir o programa para os hub de mapeamento. O futuro do OSM não está em equipes fechadas e mantidas por empresas que muitas vezes não conhecem a realidade do que estão mapeando, o futuro do OSM passa por financiamos o trabalho dos jovens voluntários e suas comunidades dando oportunidade de aprender e aperfeiçoar suas habilidades, comunidades locais bem estruturadas sabem o que falta no mapa e o que querem mapear, conhecem melhor a região.

Para o futuro pretendo continuar a aplicar o que eu aprendi durante essas 12 semanas e ajudar a comunidade brasileira, pretendo continuar a mapear com os projetos no TaskManager, ainda estou me planejando para ter uma base mais solida para 2022 mas pretendo continuar com meu trabalho mapeando cidades do meu estado.

Hoje estou completando dois anos como contribuidor do OpenStreetMap então para comemorar farei uma breve retrospetiva sobre esse ultimo ano. 2021 não foi um ano fácil para os brasileiros com a negligencia do governo atingimos a marca de 600k mortos pela Covid-19, além da volta da fome e a inflação alta mas com diria Belquior posso me considerar um sujeito de sorte, editar no OSM me deu forças para aguentar muitas coisas, mapear esse ano foi como uma terapia. Esse ano também tive a oportunidade de conhecer projetos e pessoas incríveis!

Estáticas

Alguns números:

• 22.503 Edições enviadas
• 170.425 Edifícios mapeados
• 15.202 Km de vias mapeadas
• 9.926 Pontos de interesses mapeados
• 4.323 Km de rios mapeados

O que aconteceu com o Mapeia.Space?

É uma historia complicada, primeiro tivemos que mudar apos o DAMN mudar totalmente a forma de trabalhar e como o Hot TM parecia ter amadurecido na questão de desempenho então resolvemos mudar para o Tasking Manager o que aconteceu é que tivemos que começar do zero novamente… tivemos um problema com nossa hospedagem na mesma epoca recebi o convite para poder usar o HOT Tasking Manager (Obrigado Wille e Vitor George por essa oportunidade) desde então foram 7 projetos publicados. Então não havia por que manter uma instância própria do Tasking Manager então o mapeia.space acabou sendo encerrado apesar de que tentei criar uma organização em torno do Mapeia para promover mapeamento o que também acabou não dando certo mas no final acabou dando como fruto a pesquisa de uso de mapas online.

Você pode visitar o perfil do OSM Brasil no Tasking Manages link

Importação?

Durante esse ano em especial no segundo semestre usando o Maproulette e base de dados aberta do governo adicionei dados sobre a PRF (Policia Rodoviaria Federal) e escolas do Maranhão, (isso explica meu numero de edições) até agora foram cerca de 6k escolas adicionadas no mapa acho que torna o Maranhão o estado do Brasil com o maior numero de escolas mapeadas no OSM está sendo um trabalho exaustivo por isso eu me limitei em alguns casos somente adicionar o nome da escola. Gostaria de reforçar o mapeamento das escolas não somente para o acesso a educação mas também porque as escolas são usadas como ponto de votação para as eleições!

• Projeto PRF
• Projeto Escolas do Maranhão

Data Quality Intership

Esse ano estou tendo a oportunidade única de poder participar do HOT Data Quality Internship, estou tendo a oportunidade de aprender bastante e conhecer novas pessoas! está sendo uma experiencia incrível e foi a melhor coisa que me ao logo desse ano.

Algumas curiosidades

Algumas curiosidades que gostaria de compartilhar com vocês:

• Fui selecionado como Mapeador do Mês pelo OSM Bélgica link
• Quer conhecer um pouco do meu setup link
• Aprendi a reconhecer Motel e AABB por imagens de satélite (uma dica, motel tem sempre uma pequena via de entrada e outra para a saída)
• Também consigo reconhecer alguns tipos de hospitais e escolas
• Meu principal entretenimento enquanto mapeava foi a CPI da Covid
• Não consegui completar nenhuma meta que me propus a fazer no ano passado!
• dos 74 países que já editei no OSM 27 tem alguma lei que criminaliza a homossexualidade e desses 20 tem penas de 8 anos a perpétua e 6 com pena de morte
• Todo meu trabalho é mantido graças a doações, muito obrigado a quem pode ajudar!

Agradecimentos

Gostaria de agradecer a todos que me apoiaram durante esse ano em especial a galera do Mastodon por serem essas pessoas incríveis e não deixaram eu desistir de continuar meu trabalho, em especial ao Claus e a Lous. Ana Raquel por ter me apoiado nos momentos mais difíceis e sempre estar lá para escutar e me motivar, obrigado por ter sido minha amiga e ter me acolhido nos tempos difíceis. e como já é de costume queria agradecer ao Karl por todo apoio e suporte que me deu esse ano!

Sem vocês esse trabalho não seria possível, acredito que melhorando aos poucos o OpenStreetMap podemos sim fazer um mundo melhor e mais acessível para todos! muito obrigado e que venha mais um ano como mapeador ;)

Eu gostaria de inicio explicar que se trata de um exercício de imaginação de como poderíamos melhorar a UX/UI no perfil do OSM, isso quer dizer que algumas mudanças foram com base na minha experiencia e ainda faltam algumas coisas que não explorei, como os Diários, configurações e Mensagens, adoraria receber o feedbacks de vocês!!

Mais social e pessoal

OpenStreetMap é uma plataforma que engloba não só o mapa mais também seus mapeadores e suas comunidades. para começar optei por dar um ar de personalização maior para o perfil, trazendo uma foto maior do usuário e uma capa dando um maior espaço para personalização, para que possam demostrar mais suas paixões além do mapa. Trazendo uma experiência mais familiar como em outras redes sociais dei um maior destaque para o botão de seguir e substituindo a função “adicionar como amigo” que nos dias de hoje está meio em desuso para não se dizer “cringe”, Uma boa função seria poder escolher e gerenciar quem pode te seguir e a partir disso quem pode te mandar mensagem também, dando mais controle ao usuário de quem pode segui-lo e mandar mensagem pode diminuir o numero de spam. Outro ponto seria mostrar quais organizações a pessoa participa assim ficariam mais fácil para outros mapeadores identificarem mapeadores pagos por exemplo.

Mais estatísticas por favor!

Uma das coisas que falta no perfil do OSM é estatísticas isso serve até para conhecer melhor quem é o dono perfil mais também para empregadores futuros

Gamefication

Como motivar mais os mapeadores? dado objetivos a serem cumpridos! Umas das coisas que mais me motivaram em continuar mapeando foi completar todas as Bagdes do Missing Maps. Não falo somente em um sistema de bagdes e metas mas também um sistema de pontuação com base no que for editado ou adicionado. Outro ponto seria bagdes por participação em mapathons promovidos pelas comunidades locais e internacionais demostrando que o mapeador é uma pessoa ativa na comunidade.

Perfil de Organizações e times

Da mesma forma em que o Github tem paginas especificas para organizações o OSM também deveria ter, isso facilitaria conhecer quem são as organizações que trabalham no OSM, quem participa e onde participam, a intenção é centralizar melhor as informações. Hoje se formos ver cada aplicação do OSM tem uma maneira diferente de dividir seus times e acompanhar seu desempenho o que proponho é que sejam criados times direto no OSM e disponibilizado via API para outras aplicações

Versões: English /

French /

HOT website (English)

Juntamente com as comunidades/contribuintes locais do Vietname, Madagáscar e Moçambique, e os Centros Mapas Abertos (Ásia-Pacífico, e África Oriental e Austral), tenho muito prazer em partilhar convosco a colaboração Projecto: Localização como um facilitador de inclusão e participação (também disponível em Francês, Português e Espanhol).

Resumo dos detalhes do projecto:

Contexto

A barreira linguística e a omissão do inglês coloca os não falantes de inglês em desvantagem sistémica nas comunidades de mapeamento aberto e nas actividades humanitárias de mapeamento aberto que o HOT tenta apoiar, resultando numa falta significativa de participação e impacto (Gayton, 2021) .

Motivação

Acreditamos que a localização linguística permitirá a inclusão e participação de grupos subrepresentados no mapeamento, diálogos e outras actividades humanitárias de mapeamento aberto.

Objectivo

O nosso objectivo é desenvolver dados de base para informar uma estratégia de localização*** auto-sustentável para colmatar a lacuna entre linguagem e acessibilidade dos recursos de cartografia aberta que servem as comunidades envolvidas no trabalho humanitário / de desenvolvimento (ver Países Prioritários do HOT).

Metodologia

Iremos realizar pequenas experiências (isto é, fluxos de trabalho de tradução, e compromissos) com comunidades locais para testar como a localização de recursos poderia funcionar nas principais línguas de 3 países prioritários: Vietname (Tieng Viet), Madagascar (francês) e Moçambique (português).

Linha do tempo (sujeito a alterações)

• June-Julho: brainstorming inicial, preparação e análise dos requisitos (completo)
• *Agosto - Setembro:** Compromissos com as comunidades como colaboradores nas experiências (completo)
• Outubro - Novembro:** Experiências/Translações em curso

1. As comunidades identificam e dão prioridade aos recursos que são importantes para elas e querem localizar para contribuir para o OpenStreetMap e o Open Mapping
2. A Equipa da Comunidade HOT apoia na tradução utilizando o tradutor automático
3. As comunidades revêem o primeiro passo de tradução e finalizam o recurso na sua língua para promover nas suas comunidades

*Médio de Novembro - Dezembro:**

1. Resultados de experiências e insights publicados
2. Proposta inicial de estratégia de localização
3. Revisão comunitária

Como se pode envolver:

• Leia o documento do projecto e comente o seu pensamento directamente no documento, neste diário ou no Humanitarian Open Mapping CommunityWG Forum topico
• Sugira pessoas ou organização(ões) (ou artigos/iniciativas) que pensa poder aconselhar-nos em relação a este projecto (comente ou partilhe-as neste tópico).

Agradecimentos especiais aos colaboradores da comunidade local:

• Vietname: Tony, Huy e Grab Vietnam Map Operation Team
• Madagáscar: Faneva e Dolly
• Moçambique: Rodolfo Júnior, Pechiçoane Pechiço, Dinércia Macaringue, Edmilson Fuel, Daniel Mapsanganhe, Emerson Lopes, Rosário Mulhui e Vânia Muianga.

Se desejar saber mais sobre isto e quiser ter uma conversa, por favor, sinta-se à vontade para me enviar uma mensagem.

Obrigado e esperamos poder colaborar convosco neste projecto! :)

=Arnalie

Como já falando no texto anterior o OpenStreetMap não é tão amigável com o usuário comum mas serve muito bem para os cartógrafos, também recebi muitos comentários que o OSM não é um produto final e sim uma base de conhecimento compartilhada e até algumas comparações com linux… Mas usar o OSM não deveria ser difícil ou depender do rebrand de grandes empresas, acredito que tem como atingir o usuário comum e ganhar mercado e sendo opensource e ainda trazer mais mapeadores para a comunidade.

A alguns venho trabalhando no que seria um cliente ideal em que eu realmente usasse e recomendaria para meus amigos e colegas isso venho crescendo desde que eu li o artigo The Mobile Map App Part I: The Void então descidir criar um rascunho:

Só que para tirar essa ideia do papel eu preciso de sua ajuda, caso você tenha alguma experiencia em Flutter ou React e queria levar o OpenStreetMap a um novo patamar por favor entre em contato: gustavo22soares@pesso.al

English Version link

Disclaimer: Todo o texto que você lerá abaixo é baseado em uma pesquisa feita online voltada ao mercado Brasileiro. link para um resumo da pesquisa feita

Não é novidade - ou não deveria ser - que o OpenStreetMap tem uma grande importância no compartilhamento de informação de um local. É uma ferramenta de impacto social para minorias e políticas de ajuda humanitária. Apesar dos grandes esforços dedicados por milhares de mapeadores que se dedicam a cada dia melhorar os mapas, somado ao esforço diligente das grandes BigTechs para promover seus próprios serviços, o OSM está longe de ser o mapa mais popular do mundo. Ou, pelo menos, uma referência tão grande quanto sua irmã Wikipédia.

Uma mina de ouro escondida

Fora um grupo de afissurados em geotecnologia, o OSM é totalmente desconhecido para o publico geral. Como pudemos observar na pesquisa feita, cerca de 68% dos participantes nunca tinha ouvido falar do OpenStreetMap. Apesar de muito provavelmente já terem tido experiências prévias com um dos vários pontos de contato (Tesla, SnapMap, BigMaps, Apple Maps, Facebook, Strava, Mapbox), mesmo assim a maioria das pessoas não conheciam o OpenStreetMap.

Se você se você se preocupa se as pessoas veem seu trabalho no OpenStreetMap, a resposta é simples assim: claro que sim! Elas só não sabe de onde vem!

O principal motivo para essa omissão é que empresas frequentemente tentam esconder nossas contribuições nas linhas mais pequenas e obscuras de termos de serviço enquanto constroem sua própria base dados proprietária dando migalhas para a comunidade. Não preciso citar nomes né?

Mas isso não é uma prática exclusiva das grandes corporações, quantas vezes aplicativos como Maps.me, OSMAnd, OrganicMaps param para lembrar seus usuários que os dados que estão usando veio do OpenStreetMap?

A verdade é que ninguém quer contar sobre sua galinha dos ovos de ouro!

Nem todo mundo quer mapear

Em nossa pesquisa, 47,4% dos entrevistados não têm o costume de de contribuir com o mapa que usam. Isso não é uma surpresa, afinal nem todo mundo tem a paciência ou mesmo interesse em mapeamento. De acordo com outro estudo feito da pirâmide de conhecimento em gis (https://www.gislounge.com/defining-the-role-of-gis-and-needed-skills/) quanto mais conhecimento é exigido para a tarefa, menor é o numero de pessoas “habilitadas”.

o OpenStreetMap deu um grande salto com o ID para popularizar o mapeamento. Ferramentas como Zapto (https://zapto.openstreetmap.org.br/) para adicionar uma localização e iniciativas de trazer mais colaboradores como YouthMappers, Mapathons etc, [falta informação]

No âmbito do usuário comum ainda existe uma barreira grande para que ele possa contribuir efetivamente como um cliente. Se você não leva o produto para o máximo de pessoas usarem, não tem como saber o que deve ser adicionado ou atualizado no mapa!

Onipresença do Google

Não é segredo para ninguém o a BigG domina nossas vidas. Desde as pesquisas que você faz, a forma como você acessa a internet (provavelmente você deve está usando o Chrome agora mesmo) até como você se locomove na sua cudade, ela está lá.

Não há uma alternativa funcional ao Gmaps que funcione no Brasile mesmo para aqueles que tentam substituir acabam tendo o Gmaps como backup. A BigG conquistou esse grande monopólio usando sua posição no mercado de smartphones e ferramenta de pesquisa mais popular. Ela se consolidou como única provedora de mapa para muitas regiões, e com isso para muitas empresas que precisam de dados não tiveram outra opção a não ser render-se ao domínio da BigG e usar o GMaps em seus produtos. Isso leva muitas vezes o OSM para o banco de reservas, no posto de mapa para backend ou uma alternativa mais barata.

A falta de alternativas que tenham capacidade de concorrer diretamente é gritante, até mesmo considerando a comunidade ávida de mapeadores do OpenStreetMap. Hoje mesmo não sou capaz de recomendar nenhum dos clientes disponíveis para um colega ou amigo como uma alternativa melhor para o Gmaps.

As pessoas querem encontrar os endereços!

Se alguém me perguntasse “qual é a minha maior decepção com os clientes do OpenStreetMap?” diria que tenho dificuldade de encontrar endereço!

Isso é um problema serio no Brasil e outros países que insistem em manter suas bases de endereço proprietárias, que não tem como ser importada direto para o OSM.

Dentre os entrevistados, 55,7% disseram achar mais fácil buscar endereço online. Você consegue imaginar uma dessas pessoas usando um dos apps baseados no OSM para encontrar um endereço que ela não conhece e que ninguém se deu trabalho de mapear antes?

Isso leva o usuário a frustração e acaba tornando o OSM em uma ferramenta que não consegue cumprir sua própria função básica.

Projetos como Open Adresses (https://openaddresses.io/) tentam suprir essa falta, mas sua fonte de dados no Brasil não é muito precisa.

O OpenStreetMap por si só nunca quis ser um carro-chefe, e duvido que isso deva mudar a curto prazo. Precisamos de alguém que nos guie para frente, mas não se esqueça aqueles que vieram primeiro.

Resumindo, precisamos de um cliente feito para realidade brasileira…

Fizemos uma pequena pesquisa para conhecer melhor o uso dos mapas online e o conhecimento do OpenStreetMap no Brasil, cerca de 97 pessoas ao redor do Brasil responderam nossa pesquisa. acompanhe os resultado a abaixo:

Gostaria de agradecer a todos que responderam nosso questionário a Lules por ter trabalhado nessa pesquisa e aos meus apoiadores Claus Wahlers, Karl Prieb, Dobrado, Luiza Figueiro e a Gabriela Pires graça ao apoio de vocês esse trabalho pode ser feito!

Muito obrigado!

você pode baixar os dados da pesquisa por esse link

Esta recente demanda proseguida por mim consiste em ter a informação detalhada sobre todas as paragens das diferentes operadoras que operam no Terminal Rodoviário do Campo Grande recentemente realocado. Tal como era a situação anterior à deslocação, a este faltava-lhe informação crucial.

Detalhes introduzidos

Teve-se em conta as seguintes informações a introduzir no OSM:

• operadora associadas à paragem (nome completo em operator=*)
• rotas associadas à paragem (através da etiqueta route_ref=* )
• número de cais (recorrendo à etiqueta loc_ref=* )
• abreviatura da operadora em questão (usando a etiqueta ref:operator=* )

Operadoras

Este terminal aloja as seguintes Operadoras de Transportes de Passageiros:

• Joaquim Jerónimo - Santo António (também conhecida por “Santo António - Barraqueiro”)
• Rodoviária de Lisboa
• Isidoro Duarte
• Henrique Leonardo Mota
• Mafrense
• Ribatejana
• Boa Viagem
• Barraqueiro do Oeste
• Rodoviária do Oeste / Rodoviária do Tejo

Sendo as suas abreviaturas, respetivamente:

• JJSA
• RL
• ID
• HLM
• (não usado)
• BV
• BO
• RDO

Nota-se que estas siglas, juntamente com os números de cais e números de rota, foram baseadas em painéis informativos encontrados no terminal e em um survey efectuado no local. Como tal, no caso da Rodoviária do Oeste e da Rodoviária do Tejo, estas partilham a mesma sigla pois no painel a sigla é a mesma apesar de aparentarem ser operadoras distintas. (Para uma possível explicação de assim o ser, ler mais aqui )

Frisa-se também que no caso da Isidoro Duarte e da Henrique Leonardo Mota existem rotas a serem partilhadas pelas duas operadoras (presente neste nodo ) como será o caso da rota Campo Grande -> Guerreiros (a qual ainda não se encontra mapeada).

Uma nota sobre a etiqueta network=*

Um aspeto muito importante que notei durante esta tarefa, o qual até deixo uma breve nota nos objetos em questão, é que a etiqueta network=* tem vindo ser usada erroneamente para indicar que uma dada paragem/rota pertence à “rede” da própria operadora da qual faz parte ao invés de uma rede mais abrangente. Por exemplo, as paragens da Carris atualmente estão mapeadas com a terminologia network=Carris + operator=Carris. A partir deste de exemplo se vê que a etiquetagem utilizada é redundante e não adiciona nenhuma informação nova.

No caso de Lisboa, a rede deverá ser, por exemplo, o sistema de bilhética em comum entre as várias operadoras que operam dentro da Área Metropolitana de Lisboa que até este ano (2021) era da competência da OTLIS. Como tal, ainda não existe um nome comum para esta dita “rede” pois esta terá, num futuro próximo, o nome de Carris Metropolitana.

EDIT: Foi-me notado que no caso do Porto, ainda que não esteja mapeado na sua íntegra, a etiqueta tem sido usada para indicar a rede intermodal “Andante” que inclui operadores rodoviários e ferroviários.

De forma análoga, o Lisboa VIVA desempenha o mesmo papel na Região de Lisboa enquanto a Carris Metropolitana, caso implementada, correspoderia apenas à rede rodoviária. Colocado nestes termos, fará sentido incluir as duas redes na etiqueta network pois existirão inevitàvelmente “casos bicudos” em que uma rede não está necessàriamente incluída na outra (e.g. passes combinados; carreiras interregionais; acordos com comunidades intermunicipais ).

Desse modo, no contexto do OSM, creio que usar a etiqueta network=Carris Metropolitana para designar este facto quando for estabelecida a entidade em questão seria mais indicado do que etiquetar da forma pleonástica abordada no exemplo supramencionado.

Por fim

Quero referir que esta tarefa alia-se com uma outra, de também autonomia própria, que é a de completar o Terminal Rodoviário do Oriente, o qual de momento carece de informação sobre as paragens que não sejam operadas pela Carris.

A rede de postos de carregamento do OpenStreetMap está bastante completa, pelo que me tenho apercebido.

Hoje quis ver que postos havia em Esposende e no OpenStreetMap não estava nenhum registado. Nem um :-(

Por isso, fui sacar os postos da rede MOBI.E para comparar e ver o que poderia estar em falta.

Sacar Postos da rede MOBI.E

Abrir o site da rede MOBI.E.

Abrir as ferramentas de desenvolvimento e selecionar o separador Rede. Eventualmente por um filtro para só apanhar os pedidos que tenham ‘location’. Fazer um refresh da página para apanhar os pedidos feitos ao servidor. O pedido que é apanhado está no seguinte print screen.

Pode-se fazer copy e paste do JSON retornado e guardar num ficheiro. Ou, como se faz no passo seguinte, fazer o mesmo pedido na linha de comando.

Guardar o resultado num arquivo JSON

Com o botão do lado direito, emcima do pedido, pode-se copiar o pedido como “Copy as cURL”. Depois, na linha de comando, faz-se o poste do mesmo, acrescentando duas coisas: a opção -k para não se ter problemas com o certificado e a opção -o mobi-e.json.

O comando será algo do género:

curl 'https://ocpi.mobinteli.com/2.2/locations' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0' -H 'Accept: application/json, text/plain, */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Origin: https://www.mobie.pt' -H 'Connection: keep-alive' -H 'Referer: https://www.mobie.pt/' -H 'If-Modified-Since: Fri, 30 Apr 2021 15:46:14 GMT' -H 'If-None-Match: "1c097b-5c13283049500"' -k -o mobi-e.json

Transformar o JSON em CSV

O arquivo sacado está em JSON. É um enorme array com todos os postos elétricos. Pode-se transformar em CSV em Python, e aproveita-se para transformar coluna coordinates que está em JSON em duas colunas separadas. Fica assim supor fácil ler o CSV no QGIS ou noutra ferramenta. Também se conta (com a função len) o número de conetores em cada posto.

import pandas as pd
df = pd.read_json("mobi-e.json")
df['latitude'] = pd.io.json.json_normalize(df.coordinates)['latitude']
df['longitude'] = pd.io.json.json_normalize(df.coordinates)['longitude']
df['conetores'] = df.evses.apply(len)
df.to_csv("mobi-e.csv")

O mobi-e.csv pode-se adicionar ao QGIS.

Abrir o CSV no QGIS e comparar com os postos do OSM

No QGIS, adicionar uma camada de texto delimitada.

No QGIS, usando o plugin Quick OSM, fazer uma query com:

• amenity
• charging_station
• Portugal

Acrescentar o mapa OSM como fundo e visualizar no EPSG:3857.

Conclusão

Não há nenhum posto de carregamento em Esposende.

Nota para quem quiser ajudar a verificar as diferenças entre o OSM e a MOBI.E

Deixei um arquivo mobi-e.osm e mobi-e.shp (em zip) numa pasta do Nextcloud.

Converti as moradas da Madeira e dos Açores para *.shp, *.osm e *.json. São dados importados do INE e referem-se a alojamentos. Não incluem o comércio e indústria.

Para editar transformações de coordenadas, criei já tudo em EPSG:4326 (WGS84).

Estão disponíveis na nextcloud em:

• Moradas dos Açores, na pasta shps_wgs_84
• Moradas da Madeira, na pasta shps_wgs_84

Estão por lá também as scripts de importação.

Se preferirem trabalhar só com os pontos de entrega do correio, em vez de terem o mesmo ponto repetido para cada endereço, como acontece nos prédios, criei uma tabela entregas.

A tabela entregas mantém toda a informação, pois estou a agregar a informação das diferentes moradas num único ponto.

Criei uma pasta Pontos de Entrega Continente onde têm uma exportação por concelho.

Para quem usar o QGIS, criei nessa pasta um geopackage continente.gpkg que tem as duas tabelas: moradase entregas.

Também fiz um dump do Postgresql, que está nessa pasta em enderecos-202103291045.backup.

Atenção: as shapefiles têm limitações no comprimento dos atributos. Algumas agregações estão truncadas (pelo limite de 255 carateres do formato shapefile.

Criação de uma tabela só com os pontos de entrega

CREATE TABLE entregas (
	fid INT generated BY default AS identity primary key,
	geom geometry(POINT, 3763) NULL,
	numeros text NULL,
	pisos text NULL,
	fracoes text NULL,
	toponimos text NULL,
	tipos text NULL,
	edificios varchar NULL,
	codpostais varchar NULL
);

CREATE INDEX entregas_geom_idx ON entregas USING gist (geom);

CREATE OR REPLACE FUNCTION array_sort (ANYARRAY)
RETURNS ANYARRAY LANGUAGE SQL
AS $$
SELECT ARRAY(SELECT unnest($1) ORDER BY 1)
$$;

insert into entregas (geom, numeros, pisos, fracoes, toponimos, tipos, edificios, codpostais)
with unicas as (
	select geom, ARRAY_AGG(DISTINCT numero) as numeros, ARRAY_AGG(DISTINCT piso) as pisos, ARRAY_AGG(DISTINCT fracao) as fracoes,
	ARRAY_AGG(DISTINCT toponimo) as toponimos, ARRAY_AGG(DISTINCT tipo) as tipos, ARRAY_AGG(DISTINCT edificio) as edificios, ARRAY_AGG(DISTINCT postcode) as postcodes
	from moradas group by geom)
select geom, array_to_string(array_sort(numeros), ', ') as numeros, 
array_to_string(array_sort(pisos), ', ') as pisos, 
array_to_string(array_sort(fracoes), ', ') as fracoes, 
array_to_string(array_sort(toponimos), ', ') as toponimos, 
array_to_string(array_sort(tipos), ', ') as tipos, 
array_to_string(array_sort(edificios), ', ') as edificios, 
array_to_string(array_sort(postcodes), ', ') as codpostais
from unicas;

Com isto, passamos de 5 669 971 moradas, para 3 372 945 pontos de entrega.

Para sistematizar a importação do continente, podem-se usar as seguintes scripts:

Sacar índices, gerar uma script para sacar os zips e sacar os zips:

#!/bin/bash

wget https://inspire.ine.pt/AD/atom/CDG_AD_BNM_pc_Norte_Atom.xml
wget https://inspire.ine.pt/AD/atom/CDG_AD_BNM_pc_Centro_Atom.xml
wget https://inspire.ine.pt/AD/atom/CDG_AD_BNM_pc_AML_Atom.xml
wget https://inspire.ine.pt/AD/atom/CDG_AD_BNM_pc_Alentejo_Atom.xml
wget https://inspire.ine.pt/AD/atom/CDG_AD_BNM_pc_Algarve_Atom.xml

awk '/Addresses_[0-9]+_EPSG3763.zip/ {print $3}' *.xml | sed 's/href=/wget /' > saca.sh

mkdir zips; cd zips; bash ../saca.sh

A script cria uma pasta zips com 278 zips (um para cada concelho do continente).

Para o restante processamento, usa-se o GDAL e uma base de dados PostgreSQL, onde é criada uma tabela moradas.

Nessa pasta, corre-se a seguinte script que processa concelho a concelho. Para cada concelho, são acrescentados os respetivos endereços à tabela moradas.

Script processa.sh:

#!/bin/bash

for filename in *.zip
do
    base="${filename%.*}"
    unzip $filename
    echo "${filename%.*}"
    GML_ATTRIBUTES_TO_OGR_FIELDS=YES GML_SKIP_RESOLVE_ELEMS=NONE ogr2ogr -f PostgreSQL PG:'service=osm' GMLAS:$base.gml -nlt CONVERT_TO_LINEAR
    psql service=osm -f insere.sql
    rm $base.gml    
done

A script processa.sh recorre a uma script SQL insere.sql, que é a seguinte:

insert into moradas (ogr_pkid, geom, numero , piso , fracao , toponimo , tipo , edificio , postcode)
with designator as ( 
	select al.parent_ogr_pkid, json_object_agg(regexp_replace(ld.locatordesignator_type_href, 'http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/(.*)Identifier', '\1'), 
	ld.locatordesignator_designator) as designator 
	from address_locator al, address_locator_addresslocator_designator ld 
	where al.ogr_pkid = ld.parent_ogr_pkid 
	group by al.parent_ogr_pkid, ld.parent_ogr_pkid), 
buidname as (
	select al.parent_ogr_pkid, gns.spellingofname_text
	from address_locator al, address_locator_addresslocator_name alan, address_locator_addresslocator_name_locatorname_name alanln, geographicalname gn, geographicalname_spelling gns 
	where al.ogr_pkid = alan.parent_ogr_pkid and
	alan.ogr_pkid =alanln.parent_ogr_pkid and
	alanln.geographicalname_pkid = gn.ogr_pkid and 
	gn.ogr_pkid = gns.parent_ogr_pkid),
position as (
	select ap.parent_ogr_pkid, ap.geographicposition_geometry 
	from address_position ap), 
postcode as (
	select parent_ogr_pkid, pd.postcode 
	from address_component ac left join postaldescriptor pd on ac.href_postaldescriptor_pkid = pd.ogr_pkid 
	where href_postaldescriptor_pkid is not null), 
toponimo as (
	with tfnp as (
		select parent_ogr_pkid, json_object_agg( regexp_replace(partofname_type_href , 'http://inspire.ec.europa.eu/codelist/PartTypeValue/(.*)', '\1'), partofname_part) as partofname 
		from thoroughfarename_ad_name_thoroughfarenamevalue_nameparts 
		group by parent_ogr_pkid) 
	select ac.parent_ogr_pkid, tfnp.partofname 
		from address_component ac left join thoroughfarename tf on ac.href_thoroughfarename_pkid = tf.ogr_pkid 
		left join thoroughfarename_ad_name tfn on tf.ogr_pkid = tfn.parent_ogr_pkid 
		left join tfnp on tfnp.parent_ogr_pkid = tfn.ogr_pkid where href_thoroughfarename_pkid is not null) 
select a.ogr_pkid, p.geographicposition_geometry as geom, d.designator->>'building' as numero, d.designator->>'floor' as piso, d.designator->>'unit' as fracao, 
	t.partofname->>'name' as toponimo, t.partofname->>'type' as tipo, buidname.spellingofname_text as edificio, pc.postcode 
	from address a, position p, designator d, toponimo t, postcode pc, buidname
where a.ogr_pkid = p.parent_ogr_pkid and a.ogr_pkid = d.parent_ogr_pkid and a.ogr_pkid = pc.parent_ogr_pkid and a.ogr_pkid = t.parent_ogr_pkid and a.ogr_pkid = buidname.parent_ogr_pkid;

drop table address;
drop table address_building;
drop table address_component;
drop table address_locator;
drop table address_locator_addresslocator_designator;
drop table address_locator_addresslocator_name;
drop table address_locator_addresslocator_name_locatorname_name;
drop table address_metadataproperty;
drop table address_name;
drop table address_parcel;
drop table address_position;
drop table addressareaname;
drop table addressareaname_ad_name;
drop table addressareaname_gml_name;
drop table addressareaname_metadataproperty;
drop table addressareaname_situatedwithin;
drop table administrativeboundary;
drop table administrativeboundary_admunit;
drop table administrativeboundary_metadataproperty;
drop table administrativeboundary_name;
drop table administrativeboundary_nationallevel;
drop table administrativeunit;
drop table administrativeunit_administeredby;
drop table administrativeunit_au_name;
drop table administrativeunit_boundary;
drop table administrativeunit_coadminister;
drop table administrativeunit_condominium;
drop table administrativeunit_gml_name;
drop table administrativeunit_lowerlevelunit;
drop table administrativeunit_metadataproperty;
drop table administrativeunit_nationallevelname;
drop table administrativeunit_residenceofauthority;
drop table adminunitname;
drop table adminunitname_ad_name;
drop table adminunitname_gml_name;
drop table adminunitname_metadataproperty;
drop table adminunitname_situatedwithin;
drop table basicpropertyunit;
drop table basicpropertyunit_metadataproperty;
drop table basicpropertyunit_name;
drop table cadastralparcel;
drop table cadastralparcel_basicpropertyunit;
drop table cadastralparcel_metadataproperty;
drop table cadastralparcel_name;
drop table cadastralzoning;
drop table cadastralzoning_cp_name;
drop table cadastralzoning_gml_name;
drop table cadastralzoning_levelname;
drop table cadastralzoning_metadataproperty;
drop table condominium;
drop table condominium_admunit;
drop table condominium_au_name;
drop table condominium_gml_name;
drop table condominium_metadataproperty;
drop table geographicalname;
drop table geographicalname_spelling;
drop table inspireid;
drop table location;
drop table md_resolution;
drop table namedplace;
drop table namedplace_gml_name;
drop table namedplace_gn_name;
drop table namedplace_localtype;
drop table namedplace_metadataproperty;
drop table namedplace_relatedspatialobject;
drop table namedplace_type;
drop table postaldescriptor;
drop table postaldescriptor_metadataproperty;
drop table postaldescriptor_name;
drop table postaldescriptor_postname;
drop table postaldescriptor_situatedwithin;
drop table thoroughfarename;
drop table thoroughfarename_ad_name;
drop table thoroughfarename_ad_name_thoroughfarenamevalue_nameparts;
drop table thoroughfarename_gml_name;
drop table thoroughfarename_metadataproperty;
drop table thoroughfarename_situatedwithin;
drop table thoroughfarename_transportlink;

Depois deste processamento, na tabela moradas têm-se os endereços do INE para o continente, no sistema de coordenadas ETRS89/Portugal TM06.

Para exportar os endereços por concelhos, carrega-se a tabela dos concelhos do continente (gerada a partir da CAOP) na base dados. Com base nessa tabela, gera-se uma script com a exportação concelho a concelho.

Cada linha da script de exportação é gerada com (continente.sql):

select 'mkdir "' || concelho || '"; ogr2ogr -f "ESRI Shapefile" "' || concelho || '/' || dicofre || '.shp" PG:"service=osm" -sql "select m.* from moradas m, concelhos c where st_contains(c.geom, m.geom) and c.concelho = ' || '''' || concelho || '''"' from concelhos;

psql service=osm -t -f continente.sql > continente.sh
mkdir continente; cd continente
bash ../continente.sh

Finalmente, para se poder usar a tabela moradas no QGIS ou para a publicar através de serviços WMS ou WFS/QFS3, dá jeito ter uma chave primária e um índice espacial.

ALTER TABLE moradas ADD CONSTRAINT moradas_pk PRIMARY KEY (ogr_pkid);
CREATE INDEX moradas_geom_idx ON moradas USING gist (geom);

O resultado são 278 pastas, uma por concelho, e em cada pasta está a shapefile com os endereços desse concelho.

As pastas podem ser acedidas a partir uma nextcloud experimental para a comunidade OpenStreetMap PT, em importação dos endereços do continente. As shapefiles por concelhos estão nas pasta continente. Partilhei outras pastas, para incluir as scripts.

O backup no formato PostgrSQL das tabelas usadas (moradas e concelhos, derivada da CAOP 2020) está também nessa pasta, em enderecos-202103282354.backup.

Essas mesmas duas tabelas estão em continente.gpkg, que pode ser aberto no QGIS. Foi exportado com:

ogr2ogr -f GPKG continente.gpkg PG:'service=osm tables=moradas,concelhos'

Querem uma shapefile com as moradas todas? Eu criei uma, mas tem mais de 2Gb. Está em continente.shp.zip. Não tem índice espacial, para não ocupar mais espaço. Vai dar cabo de alguns softwares foleiros a correr em sistemas operativos duvidosos.

Para o continente, ficam assim disponíveis 5 669 971 endereços. Vou dizer por extenso: cinco milhões, seiscentos e sessenta e nove mil, novecentos e setenta e um endereços.

Bom trabalho!

Na importação das moradas do INE, estava a perder o “nome do edifício”, que é importante. Nalguns casos, os endereços não têm número, mas têm “nome do edifício”, como é ilustrado na imagem seguinte (em Beja).

Assim sendo, a query para passar das múltiplas tabelas criadas a partir do GML para uma única tabela passa a ser:

create table moradas as 
with designator as ( 
	select al.parent_ogr_pkid, json_object_agg(regexp_replace(ld.locatordesignator_type_href, 'http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/(.*)Identifier', '\1'), 
	ld.locatordesignator_designator) as designator 
	from address_locator al, address_locator_addresslocator_designator ld 
	where al.ogr_pkid = ld.parent_ogr_pkid 
	group by al.parent_ogr_pkid, ld.parent_ogr_pkid), 
buidname as (
	select al.parent_ogr_pkid, gns.spellingofname_text
	from address_locator al, address_locator_addresslocator_name alan, address_locator_addresslocator_name_locatorname_name alanln, geographicalname gn, geographicalname_spelling gns 
	where al.ogr_pkid = alan.parent_ogr_pkid and
	alan.ogr_pkid =alanln.parent_ogr_pkid and
	alanln.geographicalname_pkid = gn.ogr_pkid and 
	gn.ogr_pkid = gns.parent_ogr_pkid),
position as (
	select ap.parent_ogr_pkid, ap.geographicposition_geometry 
	from address_position ap), 
postcode as (
	select parent_ogr_pkid, pd.postcode 
	from address_component ac left join postaldescriptor pd on ac.href_postaldescriptor_pkid = pd.ogr_pkid 
	where href_postaldescriptor_pkid is not null), 
toponimo as (
	with tfnp as (
		select parent_ogr_pkid, json_object_agg( regexp_replace(partofname_type_href , 'http://inspire.ec.europa.eu/codelist/PartTypeValue/(.*)', '\1'), partofname_part) as partofname 
		from thoroughfarename_ad_name_thoroughfarenamevalue_nameparts 
		group by parent_ogr_pkid) 
	select ac.parent_ogr_pkid, tfnp.partofname 
		from address_component ac left join thoroughfarename tf on ac.href_thoroughfarename_pkid = tf.ogr_pkid 
		left join thoroughfarename_ad_name tfn on tf.ogr_pkid = tfn.parent_ogr_pkid 
		left join tfnp on tfnp.parent_ogr_pkid = tfn.ogr_pkid where href_thoroughfarename_pkid is not null) 
select a.ogr_pkid, p.geographicposition_geometry, d.designator->>'building' as numero, d.designator->>'floor' as piso, d.designator->>'unit' as fracao, 
	t.partofname->>'name' as toponimo, t.partofname->>'type' as tipo, buidname.spellingofname_text as edificio, pc.postcode 
	from address a, position p, designator d, toponimo t, postcode pc, buidname
where a.ogr_pkid = p.parent_ogr_pkid and a.ogr_pkid = d.parent_ogr_pkid and a.ogr_pkid = pc.parent_ogr_pkid and a.ogr_pkid = t.parent_ogr_pkid and a.ogr_pkid = buidname.parent_ogr_pkid;

Estações pluviométrica do Estado do Ceará fornecidas pela COGERH.

Fonte: http://i3geo.cogerh.com.br/i3geo/ogc/download.php#

No site da FUNCEME é possível baixar o histórico de cada estação. Site: http://www.funceme.br/produtos/script/chuvas/Download_de_series_historicas/DownloadChuvasPublico.php

man_made=monitoring_station monitoring:weather=yes weather:rain_gauge=yes

O INE disponibiliza um conjunto de moradas relativas a alojamentos, no formato ATOM

O serviço é apenas um índice. O serviço em si divide-se em partes:

• Norte
• Centro
• Lisboa
• Alentejo
• Algarve
• Madeira
• Açores
• Açores

Dentro de cada índice, há dois links para cada município com a mesma informação: um no sistema de coordenadas Portuguesas EPSG:3763 e outro em Europeias ETRS:4258.

Por exemplo, para o meu município, Ílhavo, terei que usar o índice da zona centro e descarregar:

wget http://inspire.ine.pt/AD/atom/gml/Addresses_0110_EPSG3763.zip

Não é fácil ler e transformar o GML em algo usável num editor de OSM. Mas como é um processo automatizável, aqui fica a descrição do processo. O que aqui fiz para Ílhavo, pode ser feito para qualquer outro concelho. Pode ser feito na linha de comandos. Vou usar o QGIS só para visualizar os dados.

Estou a utilizar o GDAL e uma base de dados PostgreSQL com Postgis.

Descompactar.

unzip Addresses_0110_EPSG3763.zip Inserir o GML em base de dados (num schema ilhavo)

GML_ATTRIBUTES_TO_OGR_FIELDS=YES GML_SKIP_RESOLVE_ELEMS=NONE ogr2ogr -f PostgreSQL PG:'service=osm schemas=ilhavo' GMLAS:Addresses_0110_EPSG3763.gml -nlt CONVERT_TO_LINEAR

Na base de dados, transformar as inúmeros tabelas numa única com as moradas e respetivos atributos.

create table ilhavo.moradas as with designator as ( select al.parent_ogr_pkid, json_object_agg(regexp_replace(ld.locatordesignator_type_href, 'http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/(.*)Identifier', '\1'), ld.locatordesignator_designator) as designator from ilhavo.address_locator al, ilhavo.address_locator_addresslocator_designator ld where al.ogr_pkid = ld.parent_ogr_pkid group by al.parent_ogr_pkid, ld.parent_ogr_pkid), position as (select ap.parent_ogr_pkid, ap.geographicposition_geometry from ilhavo.address_position ap), postcode as (select parent_ogr_pkid, pd.postcode from ilhavo.address_component ac left join ilhavo.postaldescriptor pd on ac.href_postaldescriptor_pkid = pd.ogr_pkid where href_postaldescriptor_pkid is not null), toponimo as ( with tfnp as (select parent_ogr_pkid, json_object_agg( regexp_replace(partofname_type_href , 'http://inspire.ec.europa.eu/codelist/PartTypeValue/(.*)', '\1'), partofname_part) as partofname from ilhavo.thoroughfarename_ad_name_thoroughfarenamevalue_nameparts group by parent_ogr_pkid) select ac.parent_ogr_pkid, tfnp.partofname from ilhavo.address_component ac left join ilhavo.thoroughfarename tf on ac.href_thoroughfarename_pkid = tf.ogr_pkid left join ilhavo.thoroughfarename_ad_name tfn on tf.ogr_pkid = tfn.parent_ogr_pkid left join tfnp on tfnp.parent_ogr_pkid = tfn.ogr_pkid where href_thoroughfarename_pkid is not null) select a.ogr_pkid, p.geographicposition_geometry, d.designator->>'building' as numero, d.designator->>'floor' as piso, d.designator->>'unit' as fracao, t.partofname->>'name' as toponimo, t.partofname->>'type' as tipo, pc.postcode from ilhavo.address a, position p, designator d, toponimo t, postcode pc where a.ogr_pkid = p.parent_ogr_pkid and a.ogr_pkid = d.parent_ogr_pkid and a.ogr_pkid = pc.parent_ogr_pkid and a.ogr_pkid = t.parent_ogr_pkid;

ALTER TABLE ilhavo.moradas ADD CONSTRAINT moradas_pk PRIMARY KEY (ogr_pkid);

Depois de criada a tabela, exportar a mesma para uma shapefile.

ogr2ogr -f "ESRI Shapefile" ilhavo.shp PG:"service=osm" "ilhavo.moradas"

E já temos uma shapefile de endereços de alojamentos pronta a usar!

Se for uma moradia (um ponto de entrega corresponde a um endereço):

Se for um prédio (um ponto de entrega corresponde a múltiplos alojamentos e há pisos e frações nos endereços):

No QGIS pode-se trabalhar a simbologia para as moradas aparecem claras (e com o número de moradas para cada ponto de entrega do correio).

No JOSM, basta arrastar para lá shapefile e fica-se com as mesmas à disposição para editar.

Deixo três exemplos:

• Ílhavo, com cerca de 22k alojamentos
• Águeda, com cerca de 22k alojamentos
• Braga, com cerca de 86k alojamentos

Tenho uma breve experiência usando dados abertos e públicos para melhorar o OpenStreetMap e quero compartilhar algumas dicas que para mim ajudaria não só no meu trabalho mais no compartilhamento de dados geográficos abertos. Aqui me refiro preferencialmente a prefeituras mas essas dias também são validas a outros órgãos públicos e empresas caso queiram.

defina uma licença

Um dos principais problemas quando encontro uma base de dados feita por uma prefeitura ou uma lista georreferenciada de equipamentos públicos é que nunca fica claro qual a licença dos dados, então como é recomendado pela comunidade do OSM que entre em contato com essas prefeituras, em um dos casos eu fui direto na prefeitura e os funcionários só me responderam que se está no site é de domínio público, oque deixa muito em aberto, em outro exemplo mandei e-mail perguntando se os dados poderiam ser adicionados no OSM, passado quase um ano e ainda não obtive uma resposta. A falta de uma licença clara gerar uma certa insegurança jurídica, duvido que uma prefeitura pediria para que os dados fossem removidos mas usuários mais puristas podem remover as alterações feitas com esses dados cinzas, mas para uma empresa pode ser mais complicado juridicamente usar dados sem uma atribuição correta. Então se você quer publicar geodados ou outros dados então opte por uma licença como [ODBL 1.0] (https://opendatacommons.org/licenses/odbl/1-0/) ou domínio publico. mas por favor não se esqueça de declarar sua licença!

Seja consciente

Não me estenderei nesse assunto mas outras pessoas irão confiar nos seus dados publicados então ao compartilhar tenha a certeza que esteja certo!

Use um git

Então você já definiu sua licença e quer publicar seus dados dar forma mais acessível possível? Por favor não construa um serviço próprio! Muitas prefeituras criam sub páginas quase impossíveis de acessar ou usam serviços proprietários que dificultam o acesso a esses dados, dois ótimos exemplos do que não fazer são caso da Prefeitura de Teresina, Piauí e de Canoas no Rio Grande do Sul. No primeiro caso o Teresina Geo utilizando o MyMaps da BigG, não é segredo para ninguém que Gmaps domina o mercado de mapas para o consumidor comum, então não é de se surpreender que uma prefeitura esteja usando mas o prolema é que não é um serviço apropriado ou acessível para usar os dados, um exemplo é que para pegar o dado de latitude e longitude você é obrigado a abrir o GMaps não dando opção para o usuário, a única forma de se baixar os dados é tendo uma conta da BigG, isso para mim é uma grande falta de respeito, porque eu tenho que criar uma conta em uma empresa estadunidense para poder baixar dados da cidade que moro? e que deveria ser acessíveis, tudo para se ter acesso ao um arquivo KML que com certeza não é a melhor opção para esse tipo de dado. Já no caso do GeoCanoas que usa uma solução proprietária da ESRI temos uma solução pesada e difícil acesso aos dados, o que levaram a criar uam pagina própria para baixar os arquivos o que acaba sendo um trabalho duplicado e conflitante já que muitos dados que estão disponíveis pelo serviço da ESRI não estão para download ou o arquivo para download está desatualizado. Nos dois casos apresentado nenhuma das prefeituras informa claramente qual a licença dos dados. Como podemos ver no caso do Geo Canoas é fácil ter bases de dados conflitantes e desatualizadas e para quem quer usar esses dados ainda mais difícil ter uma atualização coerente, digamos que a prefeitura tenha atualizado os dados como você poderia saber o que foi alterado? Ainda não tenho uma recomendação que possa suprir todas as necessidades de um sistema de geoprocessamento para uma prefeitura mas existe uma maneira de se compartilhar e versionar muito conhecida por programadores o git! aqui farei a recomendação do mais conhecido o Github mas saiba que existe outras opções livres e outo hospedadas como Gitlab e o Gitea. git é um serviço de versionamento, de uma maneira simples cada vez que você alterar o arquivo uma nova versão é criada podendo ser revertida e facilita ver o que foi modificado, claro que isso é uma explicação simplificada mas com um repositório git aberto fica mais fácil o gerenciamento e compartilhamento de informações entre todos da prefeitura e a população, centralizando a base dados. ok, já tenho meu repositório git e agora?

Geojson por favor

Geojson é um arquivo aberto para codificar dados geoespaciais apesar de ser mais comum com programadores geojson tem tudo para ser um arquivo padrão de compartilhamento de geo dados os motivos é que ele é um arquivo de texto, então com um bloco de notas eu consigo abrir e editar e também consigo abrir em qualquer editor gis mesmo online, tendo uma ótima compatibilidade aceitado desde pontos a multi polígnos não tem porque você adotar e por ser um arquivo de texto pode ser facilmente versionado! Uma forma de se criar e gerenciar arquivos de geojson é pelo site geojson.io nele você pode criar e gerenciar seus arquivos através do Github, você pode salvar seu arquivo geojson de duas formas no github como um arquivo no repositório ou como gist se você tem um projeto pequeno com o gist vocẽ perde muitas funções mas você pode adicionar rapidamente um mapa a um site como script.

O meu desconhecimento de uma ferramenta que dê uma vista histórica dos objectos em OSM numa determinada área, aliada à utilidade que vejo numa ferramenta deste tipo, levou-me a procurar criar algo que preenchesse essa curiosidade.
Apesar de ser uma solução simples, a parte conceptual, mais complicada que a técnica, visa apresentar no ecrã a informação de uma forma clara e elucidativa que dê uma ideia correcta da evolução dos objectos (de momento só nodes) ao longo do tempo numa área seleccionada:
Após seleção da área pretendida, é apresentada por ordem cronológica, uma lista com todos os objectos que ao longo da sua vida tiveram pelo menos uma tag válida. Tags como created_by ou source isoladas, não fazem um node autónomo. São considerados nodes autónomos além dos habituais amenity, shop, etc, aqueles que têm uma ou mais tags mesmo que integradas numa way (highway=stop, por exemplo). Seleccionando um destes elementos permite a visualização do histórico de versões desse objecto. Este histórico permite ver o tipo de evolução desse objecto: criação, alteração de tags ou de geometria, eliminação ou recuperação (undelete).
Clicando numa qulqauer versão, poderá ser validada no mapa as suas alterações de posição.
Clicando na opção de actualizar a lista de utilizadores, é preenchida a lista de utilizadores da área seleccionada, o que permite seleccionar as edições de um só utilizador nessa área.
Após selecionar o utilizador será necessário executar uma nova query, para apresentar os dados actualizados.
Quando não é selecionado um utilizador, é apresentada uma ocorrência por cada node da área; optando pela visualização filtrada por utilizador, serão listadas todas as intervenções do utilizador, podendo por isso repetir-se o node na lista, caso o utilizador tenha alterado esse node mais que uma vez. Parece-me ser esta a melhor abordagem.

(http://85.240.54.201/osh/)
Dados actualizados a 15 de Janeiro. Adequado para uso em desktop. Só contém dados de Portugal, continente e ilhas.

Como todos sabemos a escola pública vive sempre com grandes dificuldades financeiras e por isso é impossível que estas obtenham os programas informáticos de que necessitam, uma vez que o custo das diversas licenças se torna incomportável. Assim, a utilização de programas de dados abertos torna-se na melhor solução, uma vez que gratuitamente nos permite trabalhar diversas competências com os alunos. O curso de Técnico de Desporto, da Escola Secundária Jerónimo Emiliano de Andrade utilizou o UMAP para criar um mapa com os locais de nascimento dos jogadores de futebol da primeira liga portuguesa. Assim, será possível que toda a comunidade escolar perceba que o desporto, neste caso o futebol, é uma realidade intercultural e que fenómenos como o racismo, a xenofobia e a intolerância não podem pertencer a este mundo. O mapa intitula-se “Futebol em Portugal é intercultural!”

Hoje participei no primeiro Mapathon online dos Médicos Sem Fronteiras - Portugal. Foi o primeiro evento deste género realizado em Portugal pelos Médicos Sem Fronteiras e durante duas horas estivemos a mapear no ID e no JOSM uma área remota da Nigéria. Foi utilizada a plataforma Zoom para a videoconferência. Após um explicação inicial por João Antunes, dos Médicos Sem Fronteiras - Portugal, que explicou a extrema dificuldade que as equipas humanitárias enfrentam no terreno devido à falta de informação geográfica e cartográfica de algumas áreas do mundo, passamos a uma apresentação mais prática sobre as tarefas de mapeamento, sendo essa informação prestada por Renata Castro e Diego Paiva, da equipa Médicos Sem Fronteiras - Brasil. Foi utilizado o Tasking Manager da HOT (https://tasks.hotosm.org/) e escolhemos para mapeamento a task 9422 (https://tasks.hotosm.org/projects/9422), por ser uma das mais prioritárias no momento.